Subject This month in KISS (#6)!
From    Dilyn Corner 
Date    Mon, 8 Mar 2021 20:43:00 -0500

Welcome to the return of our monthly update! There are just a few things to
discuss, but I hope you find them interesting.

At the head, for those of you who use signature verification on the repos: my
gpg key has finally found its way onto a keyserver! If you haven't had the
chance to add my key yet, you can do so with these great one-liners:

gpg --keyserver --recv-key DA4AB731D4C3F13D
echo trusted-key DA4AB731D4C3F13D >> /root/.gnupg/gpg.conf

[0.0] Index

- The new domain                                                           [1.0]
- Wiki updates                                                             [2.0]
- Mirror...s?                                                              [3.0]
- KISS-static                                                              [4.0]
- Community                                                                [5.0]

[1.0] The new domain

As you may have noticed, most of the links floating around (at least that I have
direct access to) have been adjusted! Welcome to, the new website
for KISS.

I, like probably many of you, have some attachments to previous names
( is a personal favorite), and I know that many-a-domain had been
setup in the interim, hosted by the likes of $/armaanb and $/mcpcpc, the latter of
whom graciously offered to give me But I'm a stickler for names, and
my distate for certain TLDs runs deep. has a nice ring to it,
matching the likes of other esoteric or enthusiast distros a la Arch, Void, and
Alpine. If/when becomes available, I certainly would like to nab it.
We'll see what happens.

It was also great fun updating /etc/os-release. It marks, I think, the official

[2.0] Wiki updates

The versions of the wiki and website published with the package manager have
been updated to include the changes to the site, along with the fixes to the
wiki - no longer should pages that definitely exist 404
(#/wiki/software/wpa_supplicant), and several pages are no longer hidden from
view (#/wiki/kernel/firmware).

Additionally, some new articles are in the works. Some on Wayland, another the
options within the kernel - a large undertaking, but one I've been meaning to do
for quite some time. Remember: if you have an idea for something you would like
to see in the Wiki, don't hesitate to submit a PR or start an issue for an idea!
While I don't want the Wiki to be a replica of references that already exist,
relevant information to KISS is always welcome! Even if it's short - the efistub
article is great, and it's only 88 lines. The most important things in a wiki
article are correctness and relevance. Simple and accurate are good goals to

I will try to keep the docs distributed with kiss as up-to-date as possible, but
not so frequent as to drive you mad with updates.

[3.0] Mirror...s?

In August of last year, Dylan rolled out, a git mirror of the
official repositories. I have spent the last week dusting off my webserver
knowledge, and would like to announce the official repository mirrors! They are
now hosted at (https specifically for those who DEMAND
security). It's hosted on a cute little linode in Newark, NJ that is, bless it,
running KISS! The server itself is setup with caddy (subject to change) with
repositories generated by stagit, and changes to the GitHub repositories should
be pushed almost immediately to their mirrors through the use of some git hooks.
I have mentioned several times now my interest in alternative VCS for KISS.
Right now, I have a fossil mirror of the repositories setup at Currently, kiss is not equipped to use fossil
repositories, and I haven't decided to what extent this should be pursued by me
or left as an exercise for a motivated user. But they're there for those who are

Fossil is an alternative VCS to git. You can learn about fossil at

As it stands, the repositories should be cloneable. Don't push to them though,
please. Primary work will remain on GitHub, at $/kiss-community

[4.0] KISS-static

I don't want to use these posts to shill my own stuff too heavily, but Dylan was
never around to see this production come to fruition! I'll just mention it
briefly. $/dilyn-corner/KISS-static is a fully functioning static tarball of
KISS, clocking in at 18MB compressed. You can do all the things you would
normally want to do on KISS... Except build packages. If you want that, you'll
have to grab the lib tarball available on the releases page. At the very least,
KISS-static would make for a wonderful little recovery system. The repository at
the GitHub page is *rough*, mind you, but everything in the core directory
should build with no problems. Have fun :)

[5.0] Community

For some parting words, something to say about the community repository! Here
are some general guidelines I'd like to stick to (and these will probably be
cross-posted to other places):

1) If you can, sign your commits! Not only because "Verified" stamps are cool as
hell, but also because signature verification is great, and trusting each other
is a great thing to do :)

2) Make sure you include a package manifest (either within the PR itself or
linked to at a pastebin) with all new packages and package version changes.
This at least pretends to certify that the package builds; I don't have the
energy or patience to build every package. Manifests are not required for
relver bumps, and relver bumps should only be done if an update has to be made
to a package AND that update requires the package be rebuilt.

3) Expect an Issue tracker in the future - either a persistant one or one to
appear regularly - tagging users who have out-of-date packages. Packages left
out of date for 'sufficiently long' will be dropped and buried at
$/kiss-community/kiss-graveyard, where they can be summarily resurrected
(reverting the commit which drops them also works).

4) I currently maintain several HUNDRED packages! It's not unbearable, but it's
certainly a lot. If you would like to take over any of my packages in community,
feel free to submit a PR (appending a space to the relver). Some of the packages
maintained by $/git-bruh are also de facto maintained by me, although I imagine
who-maintains-what will be cleared up as updates roll in.