- CRUX - lists.crux.nu

ports/xorg (3.7): [notify] mesa: 24.0.8 -> 24.1.0; iris driver now depends on libclc
by crux＠crux.nu 01 Jun '24

01 Jun '24

Commit hash: d77b2046c2094e8f63a4703eb5328008b1c8dbf9 Author: Tim Biermann <tbier(a)posteo.de> Date: Sat Jun 01 12:41:39 2024 UTC+02:00 URL: https://git.crux.nu/ports/xorg/commit/d77b2046c2094e8f63a4703eb5328008b1c8d… Commit message: [notify] mesa: 24.0.8 -> 24.1.0; iris driver now depends on libclc

1 0

ghostscript does not compile
by Steffen Nurpmeso 25 May '24

25 May '24

./pdf/pdf_sec.c: In function 'apply_sasl': ./pdf/pdf_sec.c:186:25: error: assignment to 'char **' from incompatible pointer type 'char *' [-Wincompatible-pointer-types] 186 | NewPassword = Password; | ^ ./pdf/pdf_sec.c:187:20: error: assignment to 'int *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 187 | NewLen = Len; | ^ make: *** [pdf/pdf.mak:169: obj/pdf_sec.o] Error 1 make: *** Waiting for unfinished jobs.... =======> ERROR: Building '/usr/ports/built/ghostscript#10.03.1-1.pkg.tar.zst' failed. Happens to happen if you have libidn installed. Pffff. A nice Sunday. --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

..OpenBSD imported perl 5.38.2..
by Steffen Nurpmeso 14 May '24

14 May '24

Hello. I mean i have no problem with turning CRUX into a rolling release, practically, but i just do not have the stamina / time for the many overlays necessary to have "my own perl" ("my own python", etc) -- it affects so many other things. Also gcc 14.1 was released, 3.8 is still 13.2 (i am, too). I thought i maybe update locally, ArchLinux went to pkgver=14.1.1+r1+g43b730b9134 _commit=43b730b9134af60a8f1c5b107d625f7127ff23c5 (note AlpineLinux moved gcc to gcc-13.2.1_git20240309.., they always have these git snapshots for years .. on [edge] it says # secfixes: # 13.2.1_git20231014-r0: # - CVE-2023-4039). 'Seems to me that moving away from regular gcc balls to git snapshots seems a good direction, others do this for years, and gcc itself does simply not release bugfix updates for some time, (years; literally, as long as i look) it seems. It is not my problem, but i see you merging 3.7 into 3.8 all the time, you surely have tools for all the conflicts.. I would remark that having "depends on:" for perl and python, and having "needs rebuild for:" to have easily addressable inter- dependencies would be a cool thing for the future that CRUX hopefully has. Ciao, --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/contrib (3.7): [notify] openmpi: fixed build issues, new dependency: prrte
by crux＠crux.nu 27 Apr '24

27 Apr '24

Commit hash: 4bfaaf8a3a5ba353a1f7d73b22f09c55912f55f8 Author: Tim Biermann <tbier(a)posteo.de> Date: Sat Apr 27 12:23:19 2024 UTC+02:00 URL: https://git.crux.nu/ports/contrib/commit/4bfaaf8a3a5ba353a1f7d73b22f09c5591… Commit message: [notify] openmpi: fixed build issues, new dependency: prrte

1 0

ports/opt (3.7): [notify] ruby: updated to version 3.3.1
by crux＠crux.nu 23 Apr '24

23 Apr '24

Commit hash: 64b79ee210f56d368564558b2f3a858b67b59297 Author: Juergen Daubert <jue(a)jue.li> Date: Tue Apr 23 05:26:45 2024 UTC+02:00 URL: https://git.crux.nu/ports/opt/commit/64b79ee210f56d368564558b2f3a858b67b592… Commit message: [notify] ruby: updated to version 3.3.1 includes security fixes, see https://www.ruby-lang.org/en/news/2024/04/23/ruby-3-3-1-released/

1 0

3.8: libxcrypt is in /usr/lib
by Steffen Nurpmeso 18 Apr '24

18 Apr '24

Hello. It seems square if pam_unix is in /lib/security to have the libxcrypt needed to login via PAM is in /usr/lib. I am all in favour of keeping the thoughtful and useful, in my opinion, possibility to have a / that is functional with only /sbin, /bin and /lib, so that /usr can actually be mounted from somewhere, and if over NFS! That is currently broken on 3.8. P.S.: ach it would be nice if CRUX would step to 3.8 finally so lots of overlay mess could vanish again. --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 1

qemu-all: how to make -bios EFI aka EDK2 work for x86 (again)
by Steffen Nurpmeso 16 Apr '24

16 Apr '24

Hello. Just in case someone stumbles upon that. I had removed my EDK2 package long ago, after realizing that it now ships with QEMU by default. However, since the (second to) last (i think) update it no longer worked for x86, i had no time to look around though. 'Turns out that it still works .. like so: if [ -n "$vmefi" ]; then case "$vmsys" in x86_64|i386) vmefi="${QEMU_EFI}"/edk2-$vmsys.fd if [ ! -f "$vmefi" ]; then if [ -f "${QEMU_EFI}"/edk2-i386-vars.fd ] && [ -f "${QEMU_EFI}"/edk2-$vmsys-code.fd ]; then cat "${QEMU_EFI}"/edk2-i386-vars.fd "${QEMU_EFI}"/edk2-$vmsys-code.fd > $vmefi chmod 0644 $vmefi ^ Ie, just cat(1) together those two files into the one the -bios command line expects! Maybe someone has a better approach though, i would believe most of you however operate all this through a myriad of other software monsters that drive this for you. else echo >&2 '$vmefi: missing firmware files!' fi fi #vmefi="${QEMU_EFI}"/$vmsys.fd ;; aarch64|arm) vmefi="${QEMU_EFI}"/edk2-$vmsys.fd #vmefi="${QEMU_EFI}"/$vmsys.fd ;; *) echo >&2 '$vmefi: unsupported $vmsys='$vmsys syno ;; esac if [ ! -f "$vmefi" ]; then echo >&2 '$vmefi: no such edk2-ovmf firmware: '$vmefi syno fi vmefi='-bios '$vmefi fi P.S.: one final thanks to beerman for the *excellent* tips he has given to me before going psycho: both, adv_windowlist and umatrix where *absolutely* top tips for which i am very thankful. --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/opt (3.7): [notify] apache: updated to version 2.4.59
by crux＠crux.nu 05 Apr '24

05 Apr '24

Commit hash: 496136c882bee301500133a018833a5b92e23f49 Author: Juergen Daubert <jue(a)jue.li> Date: Fri Apr 05 01:48:57 2024 UTC+02:00 URL: https://git.crux.nu/ports/opt/commit/496136c882bee301500133a018833a5b92e23f… Commit message: [notify] apache: updated to version 2.4.59 includes security fixes, https://downloads.apache.org/httpd/CHANGES_2.4.59

1 0

core/lzlib: please --enable-shared (and install minilzip[_shared] .. as lzip?)
by Steffen Nurpmeso 04 Apr '24

04 Apr '24

Hello. Sorry for disturbing again, but i just stumbled over this fact that CRUX does not build+install the shared library, yet "our" (sorry!) bsdtar is supposed to support .lz for pkgmk out-of-the-box. Ie, bsdtar links with the static library, but since it has no dependency (.. - it is in core?), updated of lzlib are not reflected by nothing. While --enable-shared would do that trick (it is fine lz is so small but still fantastic, yes!), the anyway-built minilzip (and, with --enable-shared, *also* minilzip_shared is not addressed by "make install", but keeps on lingering and being forgotten in the base dir, even though it is a fully functional lzip program by itself (ie, it seems to me, it *is* lzip). It would therefore be "super-duper" "hip" "cool" and very "beer"ig, if that thing would simply be used as lzip(1) (which we do not have around otherwise) by install(1)ing it into $PKG/usr/bin/ (there is even a manual in doc/, .. as minilzip.1, though). When testing a 800KB tar archive the resulting bytes of "mini"lzip and plzip are identical: $ cmp pl.tar.lz mini.tar.lz #?0|kent:y$ ^ = $? Btw (and sorry SiFuh, prtverify i also use via githook!), prtverify checks if (f ~ /(\.(rar|svn|tgz|tar.(bz2|gz|xz)|zip)|CVS|REPO|index.html)$/) and thus does not allow the lz(ip) that pkgmk supports. Cool it is maintained!! In hindsight to that static-only lzlib "redundant dependencies" seem overly exact, maybe? Maybe "INFO" not "WARN"? Having an idea *why* it is redundant -- that would be cool! (Having a possibility to get an idea which dependency is de facto missing, that would be tremendous. But would not have catched bsdtar/lzlib then, because that is also in core?) Pkg stuff is very complicated... Good night from Germany, P.S.: (i now have a plzip port; if it would be me i would very likely include that in lzlib as lzip, since parallelism-less seems so bogus in todays world, and with these large files everywhere; though "our" bsdtar links lzlib and "can", *i think*.) --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

Re: Switching away from XZ
by Steffen Nurpmeso 04 Apr '24

04 Apr '24

Jörg Sonnenberger wrote in <2251035.t9SDvczpPo(a)p200300d2af268706b5d68789594dae47.dip0.t-ipconnect.de>: |On Thursday, April 4, 2024 12:17:14 AM CEST Jonathan Schleifer wrote: |> Someone else came to the same conclusions as I, but hopefully wrote it |> down more understandable than me, as obviously I have failed to bring |> across the point given the respnses so far: |> https://joeyh.name/blog/entry/reflections_on_distrusting_xz/ |> |> I think we should really discuss this... | |One thing we need to discuss for sure is the blame game currently |being played by quite a few parties. "You merged a Jia Tan commit, |you must be a plant as well!" Personally, I find the danger of that kind of |attitude turning away a lot of volunteers a lot more harmful. Surely things like [1] make up a thing. He publically mentioned his mental health issues multiple times, and -- sorry if i got that thread starter wrong even -- that may make people think of Jekyl and Hyde who then gets himself what he is actually worth, with schizophrenically (i am not an expert as you see) raising alert signs to others, like explicitly mentioning mental health issues. Sometimes you look back and clearly see signs of help calls that you have read over in the past, too. Speaking things out from all sides is one thing that is missing in our current society, in my opinion. (Letting aside the "it is all lies", anyhow.) As i am not an expert i should not comment, like all the others. I would think "that" jiat75 is "harmless" then, except for a few things, and then AlpineLinux would have been right with staying at 5.6.1 and doing autoreconf -fis, no, and i would be wrong with having reverted to 5.4.0 locally. As xz is a good tool that was used, also by me, many billions of times, i would guess. And it is pretty cool to have it around! At least *that* has been spoken out then once. Things really should be spoken out more often. Of course that is pure speculation, as anything else. I personally .. wait for the release he announced to happen soon, it will surely remove the traps. I do not know, as can be heard. For the CRUX-Linux i love to use (BSD-like, .. a bit) the built-package format can be chosen freely (gz, bz2, xz, lz [and zst]). I use zstd as it decompresses very fast, always, etc etc. Also it is RFC-standardized (whereas the poor creator/maintainer of lzlib tried multiple times, yet still has to face that IETF gum wall, for example; but may succeed next time to get the RFC established, IETF comments for improvements at least came in last time). [1] https://xkcd.com/2347/ --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