- CRUX - lists.crux.nu

Lots of useless python3 dependency piling up
by Steffen Nurpmeso 06 May '25

06 May '25

Hello. I have interrupted downloads (it is only "port-up.sh -qd" here, which resolves all dependencies), because by accident i was looking, and suddenly the entire Unicode CLDR data was being downloaded. I understand that few people do the ports, and that things like mesa etc have exploding needs for dependencies. But for opt/libxkbcommon i then see a python3-jinja2 dependency, and that wants python3-babel python3-markupsafe python3-wheel and that goes on, but already -babel wants the entire CLDR. Now i tried, *without* jinja2, to build opt/libxkbcommon exactly as via Pkgfile, and that is meson setup build libxkbcommon-xkbcommon-1.9.0 -D enable-wayland=false -D enable-bash-completion=false --prefix=/usr --libexecdir=/usr/lib --wrap-mode nodownload -D b_lto=true -D b_pie=true -D enable-docs=false plus $ meson compile -C build -j 4 INFO: autodetecting backend as ninja INFO: calculating backend command to run: /usr/bin/ninja -C /tmp/x/build -j 4 ninja: Entering directory `/tmp/x/build' [354/354] Linking target bench-x11 plus $ DESTDIR=.xx meson install -C build and, maybe much to my surprise, it simply works. As far as i can tell. I have no idea of meson, but that interested me a bit, and i saw meson.build:python = pymod.find_installation('python3', modules: ['jinja2'], required: false) and that plain seems to say that jinja2 is *not* required, and that gives the bitter taste of someone having the desire to install dozens of mega packages on people's boxes for no reason i understand. It would be *very* nice if not each and every package needs to become overlayed to avoid this immense stacking up of python3 subpackages. Ciao, and a nice Sunday i wish you all!! P.S.: unless you need it to keep on running, the argument to "mode" in the below is only 0755, not the entire string. I have overlayed it, but if you consider the code quality of the CRUX scripts and package system in the past, and compare it with that, it is hard to imagine new users and developers come over. if ! /bin/mountpoint -q /run ; then /bin/mount -n -t tmpfs -o mode="0755,nosuid,nodev,exec" tmpfs /run || { printf "$(BOLD "$(RED)")" "[ERROR]"; exit 1; } fi --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)

2 2

ports/opt (3.8): [notify] python3-wheel: do not force a bytecode level, read message
by crux＠crux.nu 05 May '25

05 May '25

Commit hash: a96c9627397ac65c1d257be3c591bc16b45a30e8 Author: Tim Biermann <tbier(a)posteo.de> Date: Mon May 05 07:06:13 2025 UTC+02:00 URL: https://git.crux.nu/ports/opt/commit/a96c9627397ac65c1d257be3c591bc16b45a30… Commit message: [notify] python3-wheel: do not force a bytecode level, read message installer will compile bytecode level 0 and 1 by default.[1] Forcing it to compile level 2 will overwrite the default, not providing level 0 and 1 entirely. This is a problem since pythons runtime might compile level 0 and 1 bytecode the first time it loads a module [2] which leads to files not tracked by pkgutils db. Removing a package with those symptoms will leave these files behind, which might trigger undesired behavior, like triggering certain tests while the cause is not even installed.[3,4] To fix this, the following solution is proposed: - run a script like pkg-not [5]: pkg-not /usr/lib/python3.12/site-packages - rebuild affected ports with a forced overwrite of existing files: prt-get update -fr --aargs="-f" python3-someaffectedport This commit message stands for all following python related commits. [1]: https://installer.pypa.io/en/stable/cli/installer/ [2]: https://docs.python.org/3/faq/programming.html#id72 [3]: https://lists.crux.nu/archives/list/crux@lists.crux.nu/thread/ZIYNRJQCJ6KAB… [4]: https://github.com/xkbcommon/libxkbcommon/blob/7df431ac4d0d36639876318a4c69… [5]: https://git.crux.nu/tools/prt-utils/issues/1

1 0

And a question on python3 module updates
by Steffen Nurpmeso 03 May '25

03 May '25

Hello once more. I only wanted to know whether there is a way to cause automatic python3 module rebuilds after a python3 update. If i do $ prt-get dependent python3 doxygen nftables python3-setuptools python3-flit-core xorg-xcb-proto that isn't it. However, after updating python (only about 30 MB instead of whatever i said last, iirc something over 50, thank you), the mesa compile failed, because python3-pyyaml and then -mako then -markupsafe where no longer usable by the mesa build. I never used pip3 before, but .. i cannot seem to find anything that would be right for the task there. Now i wonder whether a combination of find /usr/lib/pythonXXXX/site-packages -maxdepth 1 -type d and pkginfo -o would do what i need? (Or can't we skip compilation during build, so that the pycache directories do not exist? Or .. ??) Thanks for any hint, a nice Sunday i wish from Germany, --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

perl 5.36.3 CVE patch
by Steffen Nurpmeso 29 Apr '25

29 Apr '25

Hello. This was posted on ossec, and applies with lots of offset. From 87f42aa0e0096e9a346c9672aa3a0bd3bef8c1dd Mon Sep 17 00:00:00 2001 From: Karl Williamson <khw(a)cpan.org> Date: Wed, 18 Dec 2024 18:25:29 -0700 Subject: [PATCH] CVE-2024-56406: Heap-buffer-overflow with tr// This was due to underallocating needed space. If the translation forces something to become UTF-8 that is initially bytes, that UTF-8 could now require two bytes where previously a single one would do. (cherry picked from commit f93109c8a6950aafbd7488d98e112552033a3686) --- op.c | 1 + 1 file changed, 1 insertion(+) diff --git a/op.c b/op.c index 69ff030e88eb..298b2926338a 100644 --- a/op.c +++ b/op.c @@ -6881,6 +6881,7 @@ S_pmtrans(pTHX_ OP *o, OP *expr, OP *repl) * same time. But otherwise one crosses before the other */ if (t_cp < 256 && r_cp_end > 255 && r_cp != t_cp) { can_force_utf8 = TRUE; + max_expansion = MAX(2, max_expansion); } } --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 1

CruxEX 3.8 Linux Live System based on CRUX 3.8 released 250421 :: Build 250427
by C A Exton 29 Apr '25

29 Apr '25

*CruxEX 2025 64 bit Linux Live System* is based on CRUX 3.8 (latest version, released 250421). CruxEX 3.8 2025 uses the LXDE Desktop environment. I have replaced the original CRUX kernel with “my” special kernel 6.14.2-amd64-exton with support for “extra everything”. UNIQUE CruxEX 3.8 Build 250427 is – as my previous CRUX-remasters – unique in the world. I.e. there is no other CRUX Live CD/USB (as far as I know). In any case, not for downloading. The good thing with CruxEX is that it is a live system (which CRUX original isn’t) and that you can run CruxEX super fast from RAM. Also that you can install CruxEX to hard drive in about 5 minutes and then have a ready-to-go CRUX desktop system. You can after that install any (extra) desktop environment you like. NOTE also: To make CRUX original ready for everyday use will normally take 2 – 3 days! ABOUT Refracta Snapshot With Refracta Snapshot you can very easy create you own CRUX Live Installable System. I mean change everything to your liking and then create a new ISO. That can be done after a hard drive installation using Refracta Installer. If you have plenty of RAM you can even create a new ISO while running CruxEX live! Study ALL INSTALLED packages in CruxEX 3.8: https://cruxex.exton.se/cruxex-3.8-installed-packages-250427.txt <https://cruxex.exton.se/cruxex-3.8-installed-packages-250427.txt> Watch this enthusiastic YouTube VIDEO ABOUT CruxEX 3.7: https://www.youtube.com/watch?v=EYV59WBWXps <https://www.youtube.com/watch?v=EYV59WBWXps> SCREENSHOTS 1. The LXDE Desktop for the live user in Build 250427: https://cruxex.exton.se/cruxex-3.8-vbox-250427.jpg <https://cruxex.exton.se/cruxex-3.8-vbox-250427.jpg> 2. The LXDE Desktop for root in Build 250427: https://cruxex.exton.se/cruxex-3.8-root-fullscreen-vbox-250427.jpg <https://cruxex.exton.se/cruxex-3.8-root-fullscreen-vbox-250427.jpg> 3. Installing Grub in VirtualBox: https://cruxex.exton.se/cruxex-3.8-vbox-grub-install-250427.jpg <https://cruxex.exton.se/cruxex-3.8-vbox-grub-install-250427.jpg> 4. The Live boot screen: https://cruxex.exton.se/cruxex-3.8-live-boot.jpg <https://cruxex.exton.se/cruxex-3.8-live-boot.jpg> READ MORE: https://cruxex.exton.se/ <https://cruxex.exton.se/>

1 0

[ANN] CRUX 3.8 released
by Tim Biermann 21 Apr '25

21 Apr '25

Greetings, everybody, we are pleased to announce the final CRUX 3.8 release. Noteable changes include glibc 2.40, gcc 14.2.0 and binutils 2.43.1. Release notes: https://crux.nu/Main/ReleaseNotes3-8 Handbook: https://crux.nu/Main/Handbook3-8 Changelog: https://git.crux.nu/system/iso/src/commit/8f8f0cf3c27b87bbf154a5c4381aecd33… For download links see: http://crux.nu/Main/Download The ISO is available via BitTorrent: http://crux.nu/files/crux-3.8.torrent The HTTP/FTP mirrors will take some time to update. Please enjoy! Best regards, Tim (for the CRUX team)

1 0

[ANN] CRUX 3.8-rc5 available for testing
by Tim Biermann 07 Apr '25

07 Apr '25

Greetings, all, There is a new test ISO available for the upcoming CRUX version 3.8. One noteable change is on the infrastructure side of things. We used giteas CI/CD system to build the iso.[1] If this goes well we will consider to keep exploring this option. It can be found here: https://git.crux.nu/system/iso/releases/tag/3.8-rc5 Additionally, there is one more repository striving to be an ongoing action. A fork of CRUX-ARM Release[2] called crux-rootfs[3], which allows builds for both x86_64 and ARM64 currently. It has a CI/CD pipeline integrated which tries to build a current version every week. Besides that it will also create LXC/LXD images as well as ready to deploy docker containers.[4] On a short note: A lot of appreciation for sepen and pitillo that created and maintain the CRUX-ARM release repository! rootfs and LXC/LXD images: https://git.crux.nu/system/crux-rootfs/releases/tag/3.8 OCI/Docker containers: https://git.crux.nu/system/crux-rootfs/packages According to how it goes, this will be the final rc, so please keep sharing your experience with it. Regards, Tim (for the CRUX team) [1] https://git.crux.nu/system/iso/actions/runs/6 [2] https://github.com/crux-arm/crux-arm-release [3] https://git.crux.nu/system/crux-rootfs [4] https://git.crux.nu/system/crux-rootfs/actions

1 0

ports/opt (3.7): [notify] fuse3: updated to version 3.17.1
by crux＠crux.nu 24 Mar '25

24 Mar '25

Commit hash: 6413c15a8fe0a69a66c415f772f6f6d9f6acd239 Author: Juergen Daubert <jue(a)jue.li> Date: Mon Mar 24 03:45:31 2025 UTC+01:00 URL: https://git.crux.nu/ports/opt/commit/6413c15a8fe0a69a66c415f772f6f6d9f6acd2… Commit message: [notify] fuse3: updated to version 3.17.1 ABI has been changed, run revdep to find affected ports

1 0

ports/contrib (3.7): [notify] gimp: 2.10.38 -> 3.0.0; check for changed dependencies
by crux＠crux.nu 17 Mar '25

17 Mar '25

Commit hash: d80fb059fbddb648ea997319f2d0afb5f5c201b5 Author: Tim Biermann <tbier(a)posteo.de> Date: Mon Mar 17 11:26:49 2025 UTC+01:00 URL: https://git.crux.nu/ports/contrib/commit/d80fb059fbddb648ea997319f2d0afb5f5… Commit message: [notify] gimp: 2.10.38 -> 3.0.0; check for changed dependencies

1 0

ports/contrib (3.7): [notify] python3-click: 8.2.0 -> 8.1.8; downgrade as 8.2.0 got taken down
by crux＠crux.nu 13 Mar '25

13 Mar '25

Commit hash: f84b843c619c7f80871c73c988c7fd8ee07e8f9f Author: Tim Biermann <tbier(a)posteo.de> Date: Wed Mar 12 07:01:19 2025 UTC+01:00 URL: https://git.crux.nu/ports/contrib/commit/f84b843c619c7f80871c73c988c7fd8ee0… Commit message: [notify] python3-click: 8.2.0 -> 8.1.8; downgrade as 8.2.0 got taken down

1 0