1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Subject This month in KISS (#6)!
From Dilyn Corner <dilyn.corner@k1sslinux.org>
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 keys.gnupg.net --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 k1sslinux.org, the new website
for KISS.
I, like probably many of you, have some attachments to previous names
(getkiss.org 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 k1ss.net. But I'm a stickler for names, and
my distate for certain TLDs runs deep. k1sslinux.org has a nice ring to it,
matching the likes of other esoteric or enthusiast distros a la Arch, Void, and
Alpine. If/when k1ss.org 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
change.
[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
have!
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 git.k1ss.org, 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://git.k1sslinux.org (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
https://fossil.k1sslinux.org 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
curious!
Fossil is an alternative VCS to git. You can learn about fossil at
https://fossil-scm.org/home/doc/trunk/www/index.wiki
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.
|
