August 2023 - CRUX - lists.crux.nu

Thoughts on making Crux more `alive' and `attractive'.
by Hans Bezemer 16 Mar '24

16 Mar '24

Dear fellow Crux-users, Recently there was some discussion in the IRC channel about how to make crux more `alive' and `attractive'. Being a relative new user I would like to share my thoughts. First of all, Crux has a lot of good things to offer: It's simplicity and script based orientation are unique. The package management through ports is simple but effective. Also there is some good documentation (but may be improved). And (last but not least) there's a friendly and helpful community. When I started out with Crux it took a while before I had everything up and running. Although I had used Arch for some while, went through the LFS-book twice, there was still a lot of ground to make up before I had my laptop configured the same way when using Arch. I had to hone several skills: building my own kernel, creating some udev rules, setting up networking using wpa_supplicant only (I know nm is at hand) and so on. Although the somewhat steep learning curve belongs to the way Crux works, there can be some minor improvements made which may help newcomers finding their way around more easily. First of, maybe Crux can become a rolling distro, with a new iso every month / 2 months. In practice it already seems to be. There are unofficial updated iso's and once you got everything installed everything can be kept up-to-date. As a new user I used the official iso (which is good practice I think), but after building the kernel, running a sysup was a bit of a showstopper. Almost all of the packages needed to be updated. When using the more recent unofficial iso, this is obvious not the case. Secondly, there is a lot of good documentation -especially on the Crux specific parts- but having two sources (Handbook and wiki) is somewhat confusing sometimes. Maybe merge the handbook into the wiki with an entry for installing Crux (like the installation guide on the Arch wiki)? The guide will walk the new user through a basic installation with links to several options (e.q. encrypting harddrive, using different bootloaders). At the end of the guide there can be some links to other entry (how to install packages, e.d.). It would be helpful if there is a basic `how to compile your own kernel'-tutorial. Something along the lines of `make defconfig', enabling audio and video support, untick some of the wlan firmware drivers, etc. Copying the bzImage and System.map and updating the boatloader. Lastly a guide on creating and maintaining your own repo (which is part of the charm of using Crux I think), would be very helpful. Beerman / Tim's guide would be a great starting point IMHO. https://gist.github.com/TimB87/6cf010c0c10d67faf98ae03e62ffb029 As for the documentation, for the most part it's a matter of reorganizing. Maybe a `further reading' section can be added at the end of an entry, with links to useful sources like the Arch wiki / offical kernel documentation and so on. The goal here is to keep it simple (of course ;-)) I'll be happy to help out with (re)writing some parts. What do you think? Would this be helpful? Or are there other / better options? Kind regards, Hans

9 13

prt-get nicetohave
by jmcquah＠disroot.org 29 Aug '23

29 Aug '23

Hi all, I'm using the subject line of a 15-year-old thread [1] to restart this discussion, even though the metadata field is more commonly called "Optional" these days. The feature in question is even more expansive than what Jose proposed in [1]. I've been developing for prt-get the additional logic to recognize optional dependencies when it sorts the install targets. A few months ago, Tim raised the issue that a sysup operation would sometimes update vulkan-loader AFTER some of the ports that optionally depend on it, unaware of the eager linking that the maintainers try to document using the "Optional" metadata field. In response to Tim's comment, I started adding to the prt-get source code the ability to respect optional dependencies. Here's Johannes acknowledging that this feature is not something we can accomplish using the existing 'depinst' command: On Thu May 1 12:17 UTC 2008, Johannes Winkelmann wrote: > > prt-get depinst pinentry --optional=gtk,qt3 > > Note that this would be the same as running > > prt-get depinst pinentry gtk qt3 > err, no wait. There's no guarantee that gtk an qt3 will be installed > before, so this would indeed need additional code. On Thu May 1 14:13 UTC 2008, Johannes Winkelmann wrote: > It'll calculate the dependecies of all ports specified on the command > line, but since there's no dependency relationship between qt3 (or > gtk) and pinentry qt3 may as well be installed after pinentry, thus > not installing the optional pinentry stuff. Interestingly, this 15-year-old example no longer gives us a good test case, because the current Pkgfile for pinentry explicitly disables the gtk2, qt, and qt5 interfaces. So instead I tested my forked prt-get using a more recent example, libxkbcommon which optionally enables x11 support. You can find my report under the doc/ directory of [2], i3-softdeps.test is the filename. Users of gtk or qt5 who want the corresponding pinentry interface might resort to creating their own port, calling it pinentry-gtk or pinentry-qt5, respectively. But in FS#1576 Tim expressed his preference for flexible Pkgfiles, rather than letting a large number of nearly-identical ports clutter up the portdb. On Mon Aug 29 07:35 UTC 2022, Tim Biermann wrote: > I am making up this example: having a port named rust-clang for > example that overlays opt/rust because a user wanted a rust binary > compiled by clang and linked by lld is not what I ideally want to see. > We don't need to reproduce Archs AUR where people add things like > that. It could be a concious decision by opt/rust to detect both clang > and lld, then set the flags to make that happen. ... > I am very much pro "fluid Pkgfiles" which can suit all use-cases. It > minimises the need to bump a ton of dups. Although most maintainers these days follow Tim's lead and attempt to suit all use-cases with the ports they care for, this practice was less widely accepted at the time thread [1] was active. Anton [3] speaks to the then-common practice of writing build() with no branching logic, performing identically no matter what system is used to run pkgmk. On Tue Aug 29 16:16 UTC 2006, Anton wrote: > What is CRUX? ISO images? No. Pkgutils? No - they are really not > necessary, you can write simple scripts in shell using tar with > similar functionality. Pkgfiles? Bingo! Indeed, Pkgfiles is really > valuable thing in CRUX. That's it, Pkgfiles should be as KISS as > possible. If they are not, then it's not CRUX anymore. A few years later, Tilman expresses a subtler form of this preference for rigid Pkgfiles with his contribution to thread [1]. On Thu May 1 20:51 UTC 2008, Tilman Sauerbeck wrote: > Danny started using Optional as an alias for nice-to-have. So it's a > different name for the same thing, and apparently it's not supposed to > introduce pkginfo-i-grep-something games in build() per se. But now the pendulum has swung in the other direction, and instead of a portdb cluttered with thousands of near-duplicate Pkgfiles (KISS because non-fluid), we have a trimmed-down portdb that hides its versatility inside fluid Pkgfiles. The prt-get that we inherited is better suited for a portdb shaped along the lines of Anton's or Tilman's remarks, and less suited for a portdb whose maintainers make full use of the "Optional" metadata field and "if-prt-get-isinst-something games in build()". Before incorporating into an official release of prt-get any code from my softdep fork [4] or its sister fork that merges "install" and "update" [2], we should address the question of a possible increase in maintenance burden. On Thu May 1 16:52 UTC 2008, Juergen Daubert wrote: > TBH I don't know why/who/when this field was introduced. And TBH I > don't like it at all. In many cases it's not really maintainable, > cause the maintainer isn't able to test all the possible options a > program is providing, e.g php or apache. Back in 2008 when "Optional" was still new, Juergen had a valid point that if prt-get acquired the ability to do something with the field, maintainers might feel obligated to populate it to the best of their ability. These days the field is in widespread use even with no official support in prt-get; maintainers just got in the habit of having a convenient place to record their "if-prt-get-isinst-something games in build()". And if build() is designed and tested only for a narrow range of configurations, what then? Most likely, the downstream users who want that particular port configured differently will create their own port, either keeping it in a private overlay or adding to the proliferation of near-dups on the portdb. Either way, the downstream user experience in this latter scenario is not ideal. But does it really relieve the CRUX team from having to "test all the possible options"? On the contrary! In the scenario where the portdb starts getting cluttered with near-dups that are on radically different version bump schedules, maintainers might feel pressured to restore order by incorporating the various compile-time options into the build() of the official port. And in the scenario where everyone's private overlay is cluttered with near-dups that reflect their particular use-case, the official maintainers might still find their inboxes flooded with support requests asking how to accomplish in build() something specific to that use-case. To my mind, inflexible Pkgfiles (or the softdep-ignorant prt-get which encourages them) only offer the illusion of distributing the maintenance burden among the broader CRUX community. The core CRUX team still ends up working just as hard, perhaps moreso when they help troubleshoot the problems of someone who tried making an unofficial port just because the official one is not flexible enough for the desired use-case. So why not let our official tools acknowledge the current reality of fluid Pkgfiles and widespread use of the "Optional" field? With prt-get able to respect those optional dependencies that the maintainer has bothered to test, the downstream user is better equipped to avoid build errors, like the `prt-get depinst i3` failure that Matt pointed out in [5], or to feel tempted to throw together yet another dup that hard-codes the desired dependencies for their use-case. -- John [1] https://lists.crux.nu/pipermail/crux-devel/2008-May/003366.html [2] https://git.crux.nu:82/farkuhar/prt-get/src/branch/mixed-upinst [3] https://lists.crux.nu/pipermail/crux-devel/2006-August/001912.html [4] https://git.crux.nu:82/farkuhar/prt-get/src/branch/softdeps [5] https://libera.irclog.whitequark.org/crux/2023-08-21 (16:36)

3 4

Fonts and UIM
by lain. 26 Aug '23

26 Aug '23

Due to the simplicity of CRUX, I really found myself loving this distro even more than Artix, because Crux doesn't stand in the way of anything at all. There's lots of configuration I have to do by myself, including even audio, but in return I learn a lot about Linux I previously didn't know about. However, there are still 2 struggle points I want to address: the system font, and the uim IME. Due to where I live and my profession, I rely on CJK (Chinese, Japanese, Korean) a lot, and the default absolutely sucks at displaying characters correctly. For illustration: https://fair.moe/cruxfontvsartixfont.png This is the same screen, but the left side is how it's shown on CRUX directly, the right side is how it's shown on Artix Linux via an SSH connection to my CRUX laptop. The right side is the correct way of writing these characters, the left is not. I think I can change the font in /etc/rc.conf, but not sure which font is the one to go with, and how I can check it without rebooting each time, especially because there's no documentation available that covers it, at least nothing I could find on crux.nu. The second problem is uim, or just all the IME's in general. I have installed uim on my OpenBSD laptop, and it works without any issues. But when I copy over the exact same configuration to CRUX, it doesn't. On OpenBSD I noticed it was running "/usr/local/libexe/uim-helper-server" alongside uim-xim, which CRUX didn't. For obvious reasons, I can't just copy the binary from OpenBSD to CRUX, but I can from Artix to CRUX, which I did. Even though uim-helper-server is running alongside uim-xim now, still no CJK input is possible. For the IME engine, I installed Anthy on both OpenBSD and CRUX. -- lain. Did you know that? 90% of all emails sent on a daily basis are being sent in plain text, and it's super easy to intercept emails as they flow over the internet? Never send passwords, tokens, personal information, or other volunerable information without proper PGP encryption! If you're writing your emails unencrypted, please consider sending PGP encrypted emails for security reasons. You can find my PGP public key at: https://fair.moe/lain.asc Every good email client is able to send encrypted emails. If yours can't, then you should consider switching to a secure email client, because yours just sucks. My recommendations are Claws Mail or NeoMutt. For instructions on how to encrypt your emails: https://unixsheikh.com/tutorials/gnupg-tutorial.html

2 2

Docker compose as a docker CLI plugin
by Vitaly Sinilin 22 Aug '23

22 Aug '23

Hi, May I suggest adding a symbolic link into the docker-compose port, so that the command "docker compose" (no dash) will be available in CRUX in addition to "docker-compose". (AFAIK the no dash version is the official one nowadays.) It should be as simple as adding the following lines into the docker-compose Pkgfile: mkdir -p ${PKG}/usr/lib/docker/cli-plugins ln -s /usr/bin/${name} ${PKG}/usr/lib/docker/cli-plugins/ -- Vitaly Sinilin <vs(a)kp4.ru>

3 4

ports/contrib (3.7): [notify] libetonyek: dropped boost-1.80 dependency, depend on contrib/boost
by crux＠crux.nu 17 Aug '23

17 Aug '23

commit 9470b4ebe8c4c7468e23cfff1014d5124148218c Author: Tim Biermann <tbier(a)posteo.de> Date: Thu Aug 17 19:20:03 2023 +0200 [notify] libetonyek: dropped boost-1.80 dependency, depend on contrib/boost diff --git a/libetonyek/.footprint b/libetonyek/.footprint index b1c601985..d5ae59487 100644 --- a/libetonyek/.footprint +++ b/libetonyek/.footprint @@ -15,7 +15,6 @@ drwxr-xr-x root/root usr/include/libetonyek-0.1/libetonyek/ -rw-r--r-- root/root usr/include/libetonyek-0.1/libetonyek/EtonyekDocument.h -rw-r--r-- root/root usr/include/libetonyek-0.1/libetonyek/libetonyek.h drwxr-xr-x root/root usr/lib/ --rwxr-xr-x root/root usr/lib/libetonyek-0.1.la lrwxrwxrwx root/root usr/lib/libetonyek-0.1.so -> libetonyek-0.1.so.1.0.10 lrwxrwxrwx root/root usr/lib/libetonyek-0.1.so.1 -> libetonyek-0.1.so.1.0.10 -rwxr-xr-x root/root usr/lib/libetonyek-0.1.so.1.0.10 diff --git a/libetonyek/.signature b/libetonyek/.signature index 18f9efdca..2f96aea4e 100644 --- a/libetonyek/.signature +++ b/libetonyek/.signature @@ -1,7 +1,7 @@ untrusted comment: verify with /etc/ports/contrib.pub -RWSagIOpLGJF36EaeuK0D2C9vEcHnK/QN71F+y3mZvefLSTKFnYfZvfRl9MunxGbKZDeG9uxTY5sEHUcfxYmjoYV1FQ15AZABQQ= -SHA256 (Pkgfile) = 317c4bbe5270ce99d4d23778be1865ff5a7a401569355d42ebf475c9b4a7ffd6 -SHA256 (.footprint) = 57ee578ffca9a5b5be3eedf3917c93dddd88357e5a4e5859a8e7b32d0634f111 +RWSagIOpLGJF31tq8X+TLXYOpfDltaW4X6QzRjwANWIXUaMVKK9v/DLT7ildJwfwHVcyeJRMOG+/dd8i/HNB/c1dm8IvrJrSiAA= +SHA256 (Pkgfile) = 6e3fb0fdcceb31783627aba3b9f31c9f59660dc8e8c7bf8ec574fb18848a537e +SHA256 (.footprint) = eb56d9ffd779b394632588dac96dba30cde7c8b262907e05358d8f0c45926f59 SHA256 (libetonyek-0.1.10.tar.xz) = b430435a6e8487888b761dc848b7981626eb814884963ffe25eb26a139301e9a SHA256 (0001-allow-0-size-message.patch.1) = 805673f9d4dec4f6533c9811cd88ddf8b379ca281f417ebe5bbea4f93ce67fb5 SHA256 (libetonyek-bundled-soname.patch.0) = 48d1167d8cd3f16d355d253ee6c4f4b25e0c581b77d6cafcd62f013d3431d584 diff --git a/libetonyek/Pkgfile b/libetonyek/Pkgfile index 1367b658d..ce46e2082 100644 --- a/libetonyek/Pkgfile +++ b/libetonyek/Pkgfile @@ -1,11 +1,11 @@ -# Description: Library and a set of tools for reading and converting Apple Keynote presentations +# Description: a library that parses the file format of Apple iWork documents # URL: https://wiki.documentfoundation.org/DLP/Libraries/libetonyek # Maintainer: Tim Biermann, tbier at posteo dot de -# Depends on: boost-1.80 glm liblangtag librevenge mdds +# Depends on: glm liblangtag librevenge mdds name=libetonyek version=0.1.10 -release=3 +release=4 source=(https://dev-www.libreoffice.org/src/$name/$name-$version.tar.xz 0001-allow-0-size-message.patch.1 libetonyek-bundled-soname.patch.0 @@ -22,10 +22,6 @@ build() { patch -Np0 -i $SRC/ubsan.patch patch -Np0 -i $SRC/warnings.patch - # boost 1.81.0 breaks libetonyek - CXXFLAGS="-I/usr/opt/boost-1.80/include $CFLAGS" - CPPFLAGS="-I/usr/opt/boost-1.80/include $CFLAGS" - autoreconf -fvi ./configure --prefix=/usr \ @@ -36,4 +32,6 @@ build() { --without-docs make make DESTDIR=$PKG install + + find $PKG -iname '*.la' -delete } diff --git a/libetonyek/boost.patch b/libetonyek/boost.patch deleted file mode 100644 index 3553afb8b..000000000 --- a/libetonyek/boost.patch +++ /dev/null @@ -1,36 +0,0 @@ -diff -Naur libetonyek-0.1.10.orig/configure.ac libetonyek-0.1.10/configure.ac ---- libetonyek-0.1.10.orig/configure.ac 2023-01-28 15:58:44.501436820 +0100 -+++ libetonyek-0.1.10/configure.ac 2023-01-28 16:39:38.681363319 +0100 -@@ -102,7 +102,7 @@ - boost/none.hpp \ - boost/numeric/conversion/cast.hpp \ - boost/optional.hpp \ -- boost/spirit/include/phoenix.hpp \ -+ boost/phoenix.hpp \ - boost/spirit/include/qi.hpp \ - boost/variant/recursive_variant.hpp \ - boost/variant/variant.hpp \ -diff -Naur libetonyek-0.1.10.orig/src/lib/contexts/KEY1DivElement.cpp libetonyek-0.1.10/src/lib/contexts/KEY1DivElement.cpp ---- libetonyek-0.1.10.orig/src/lib/contexts/KEY1DivElement.cpp 2023-01-28 15:58:44.474769901 +0100 -+++ libetonyek-0.1.10/src/lib/contexts/KEY1DivElement.cpp 2023-01-28 16:39:07.884404770 +0100 -@@ -8,7 +8,7 @@ - */ - - #include <boost/spirit/include/qi.hpp> --#include <boost/spirit/include/phoenix.hpp> -+#include <boost/phoenix.hpp> - #include <memory> - - #include "KEY1DivElement.h" -diff -Naur libetonyek-0.1.10.orig/src/lib/contexts/KEY1StringConverter.cpp libetonyek-0.1.10/src/lib/contexts/KEY1StringConverter.cpp ---- libetonyek-0.1.10.orig/src/lib/contexts/KEY1StringConverter.cpp 2023-01-28 15:58:44.478103266 +0100 -+++ libetonyek-0.1.10/src/lib/contexts/KEY1StringConverter.cpp 2023-01-28 16:39:23.404551864 +0100 -@@ -11,7 +11,7 @@ - - #include <boost/fusion/include/std_pair.hpp> - #include <boost/spirit/include/qi.hpp> --#include <boost/spirit/include/phoenix.hpp> -+#include <boost/phoenix.hpp> - - #include "KEY1StringConverter.h" -

1 0

core/openssh: switch to HTTPS?
by Steffen Nurpmeso 12 Aug '23

12 Aug '23

they do offer https (for some years, 1-2 after let's encrypt shew up iirc). Ciao. P.S.: next CRUX with new perl, gcc and glib? (Thinking about doing an overlay for some time already, maybe i switch in September then.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0

ports/core (3.7): [notify] openssl: update to 3.1.2, security fixes
by crux＠crux.nu 02 Aug '23

02 Aug '23

commit ca8c7df6565529b6484dc6dfa4bb5a6abed3563b Author: Juergen Daubert <jue(a)jue.li> Date: Wed Aug 2 09:06:06 2023 +0200 [notify] openssl: update to 3.1.2, security fixes diff --git a/openssl/.signature b/openssl/.signature index b62e4e67..46386f91 100644 --- a/openssl/.signature +++ b/openssl/.signature @@ -1,6 +1,6 @@ untrusted comment: verify with /etc/ports/core.pub -RWRJc1FUaeVeqnRuHvKkmrpUyCzCwbCjJpHTvX8/kHFJZuCpBP+xU11ZeGBE6J/1uiciqiaFdDOrSMHO/9TNAYHDOSFXg5PR6gQ= -SHA256 (Pkgfile) = feaf8b9c6754344a8b10b6d5c24b6c4f22fa9442e2120febdb27bc6875f649fb +RWRJc1FUaeVeqtT1WgRG3C3orxR6wFCkGUSokeyAfGczzigaCXRG9sbMjMkxVlLs0mql3kEUr3QHXwutt/n3zlA8p+wh3lt1DA8= +SHA256 (Pkgfile) = b17fe67b4b4489816d144c055941641deebc981eb666cf19a274da5de91cb7ba SHA256 (.footprint) = 045754d7d1ea38a8d0bd1f875bc5ec09fc1dd432ea2a730f6645af41752baf35 -SHA256 (openssl-3.1.1.tar.gz) = b3aa61334233b852b63ddb048df181177c2c659eb9d4376008118f9c08d07674 +SHA256 (openssl-3.1.2.tar.gz) = a0ce69b8b97ea6a35b96875235aa453b966ba3cba8af2de23657d8b6767d6539 SHA256 (mksslcert.sh) = d01cfd061b792f4f7444429582c5c9e83aaa7fc63cafd05669fd3f2970dff779 diff --git a/openssl/Pkgfile b/openssl/Pkgfile index 6dd665df..3f01df32 100644 --- a/openssl/Pkgfile +++ b/openssl/Pkgfile @@ -3,7 +3,7 @@ # Maintainer: CRUX System Team, core-ports at crux dot nu name=openssl -version=3.1.1 +version=3.1.2 release=1 source=(https://www.openssl.org/source/$name-$version.tar.gz mksslcert.sh)

1 0