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
|
Subject 01/04/2021: This month in KISS (#7)!
From Dilyn Corner <dilyn.corner@k1sslinux.org>
Date Thu, 1 Apr 2021 08:00:00 -0500
Welcome to month 7! A lot of small things have happened.
[0.0] Index
________________________________________________________________________________
- repo-bin [1.0]
- zig [2.0]
- Small things [3.0]
- Fun notes [4.0]
[1.0] repo-bin
________________________________________________________________________________
Y'all may have noticed that Dylan stopped providing firefox-bin - relevant
commit
https://github.com/kisslinux/repo/commit/cbd962343faadd36d31623b729350c0143ee453e
I know that I personally switched to a source-based distrubtion for more
'control' over how my packages are built, and many of you probably had a similar
inclination. But that doesn't change the fact that many users are on old or slow
hardware, and some packages take quite a long time to build (on my 2014 Macbook
Pro, chromium takes FORTY hours. FORTY!).
I recently acquired a far more powerful computer - chromium now takes less than
an hour to build. As a result, I have looked into providing binaries for the
larger packages we have, including some in community. These packages won't be
modified from their source-based counterparts, and will be built using the same
set of flags the release tarballs are made with. The current list of packages I
will aim to provide are: chromium, clang, cmake, firefox{-esr}, llvm,
qt5-webengine, and rust. More can be added to this list if need be. The goal is
not to turn KISS into a binary distribution, just to save users some time. It
may become the case one day that binary options will exist for EVERY package,
but I don't know if I have the time or interest in doing this (though I will be
investigating it).
Currently, firefox is available in $/kiss-community/repo-bin - I have several
more packages ready to go, I just didn't push them. I am currently on vacation
in Tennessee, and will push them when I return later this month. To use these
packages, simply prepend repo-bin/repo to your KISS_PATH so that they come
before $/kiss-community/repo and $/kiss-community/community - you can also fork
them into your own repo if you'd prefer to only use bins of some of the
packages. How wonderful!
[2.0] zig
________________________________________________________________________________
zig recently became buildable on KISS! Unfortunately, zig requires that llvm be
built with all the targets, and our build in repo/extra currently only targets
host and AMDGPU. Because of the size increase in the llvm package if we make the
change required (over 100MB larger), and the fact that it would only be to
support zig (which would live in community), I have decided to not accept zig
into the community repository. However, you can find zig at $/Ominitay/kiss-zig
or $/mmatongo/kiss-lang
You can find my reasoning here $/kiss-community/repo-main/issues/31
!!!UPDATE!!!
It was discovered that some tweaking could be done to the zig build which allows
it to be built with the version of llvm provided by the main repos! Anyone
looking to do cross-compiling with zig will still have to build llvm by
removing the -DLLVM_TARGETS_TO_BUILD line and rebuid zig, but you can find zig
now over in community. Along with zig, lld has been merged as an optional
replacement linker for the usual ld! If you already have llvm installed, maybe
check it out.
[3.0] Small things
________________________________________________________________________________
Mozilla seems to be moving firefox closer and closer to a GTK+2-free future.
While I was under the impression that this would be happening at the end of
December with the firefox 86 release, I should have known better. But the
no-gtk2 patch that we have seems to work just fine (considering how heavily
they're rewriting some parts of the code), and I hope to continue with the patch
until Mozilla blesses us with a firefox that doesn't *entirely* rely on
decades-old codebases. RIP gtk+2, and may you never return to repo/extra.
In a similar vein, there is no clarity on when projects will stop relying on
python2; chromium seems to be the last holdout, and who knows when that will
change. If Google spent as much time on python2 as they do most of their other
projects, they probably could've dropped the requirement years ago.
Void Linux and Gentoo have recently finalized their transition from libressl
back to openssl, the best argument for this about-face being 'difficulty to
maintain patches for compatibility'. The question was asked if KISS' ssl
implementation will change, and the answer is 'no'. We have very few packages
which require crypto libraries, and even fewer which actually require patches
(rust requires a version bump, qt5* require small amounts of patch adjustment).
Until using libressl becomes untenable, there is zero good reason to switch. You
can find some of the discussions around here in the IRC logs:
https://freenode.logbot.info/kisslinux/20210228#c7068386
[4.0] Fun notes
________________________________________________________________________________
A recent libva update saw a change in the headers relating to protected content,
which caused some breakage with chromium. As far as I know, we were one of the
first distros to have a patch ready for this problem - very exciting. Even more
exciting, however, was the fact that this patch made its way all the way to an
Arch PKGBUILD! We're a real distro now, folks.
$/archlinux/svntogit-packages/blob/packages/chromium/trunk/PKGBUILD#L94
Dante Haversham has become the latest to embark on the illustrious path of
rewriting our package manager in nonshell. First to the finish line wins praise,
glory, and the knowledge that their contribution to the community is unique and
will never be upstreamed :) They aim to have it be the same spirit as
$/dylanaraps/k but 'a lot simpler', which are some of the best goals as far as
I'm concerned. Find it here https://git.sr.ht/~dante/rpkg
|
