15:58 <jaeger> OK, there's an rc3 ISO at https://crux.ninja/tmp/

15:58 <jaeger> farkuhar: will check it out this weekend

16:21 <SiFuh> jaeger: did you ever get around to testing that modular kernel configuration I provided?

16:22 <jaeger> Yeah, thought I had reported here that it seemed fine in my testing

16:22 <jaeger> If not, it seemed fine in my testing :)

16:23 <SiFuh> All good then

16:23 <jaeger> It's on the rc ISO in a contrib dir

16:28 <stenur> glibc .36? binutils .39?

16:31 <jaeger> No objections from me to testing them... would be nice to update before 3.7 if they're stable

16:32 <SiFuh> The contrib directory makes sense. Might be a good idea to check a README in the folder explaining it

16:32 <stenur> ..and i saw a FreeBSD cherry pick for zlib; this surely will become a CVE, too.

16:34 <stenur> (Committed 07-30: Fix a bug when getting a gzip header extra field with inflate())

16:35 <stenur> Ah! It is already a CVE! CVE-2022-37434. "Code to demonstrate the flaw is available at https://github.com/ivd38/zlib_overflow"

17:13 <jaeger> SiFuh: yeah, good call

17:16 <jaeger> jue, beerman: thoughts on glibc 2.36 and binutils 2.39? I can easily start testing them on my build box... I see that glibc 2.36 is listed as "released" but I'm not sure about binutils, the binutils site still says latest is 2.38

17:18 <beerman> jue and myself talked about it a few days ago. he tested it, and he needed to patch gcc and it broke sysvinit and hdparm with no patch in sight.

17:19 <beerman> jue wanted to make haste with 3.7, and i can only agree at this point. i have been rebasing way too long while filling in for other "maintainers"

17:20 <jaeger> hrmm, ok

17:20 <stenur> binutils came today

17:21 <stenur> He wrote "numerous bug fixes"

17:23 <stenur> From-scratch rebuilding "anything" with glibc .. that is too hard to try here. Only as a last resort. (And of course i only have a small set of ports after all.)

17:27 <jaeger> I don't mind rebuilding everything, that's just a set-and-forget operation that takes time... just depends on how many things break after, heh

17:43 <jue> jaeger: as beerman said, my experience with glibc 2.36 is not positive, besides the two at build time broken ports dhcpcd is broken at runtime, dunno what he problem is here

17:45 <jue> I'd expect problems with other ports as well

17:47 <jue> at all 3.7 is behind time IMO ;)

17:49 <jue> I'd suggest to make an official ANN for rc3 on the mailing list, the current state of 3.7 seems very stable to me

18:30 <farkuhar> jaeger: thanks for the follow-up. I'll add a sentence or two about SiFuh's kernel config in my draft of the 3.7 handbook.

18:32 <farkuhar> jue: your feedback on my proposed revisions would also be appreciated, if you've got time. https://git.sdf.org/jmq/Documentation/src/branch/master/crux-wiki

18:33 <SiFuh> farkuhar: You mean like 'a user contributed example of a modular kernel has been provided for those who get stuck or wish to test which modules are loaded on boot' kind of thing?

18:33 <farkuhar> SiFuh, that's exactly how I was going to describe it.

18:34 <SiFuh> Yeah I saw it here under the ISO -> /kernel/contrib/<here>

18:37 <jaeger> jue: fair enough, no objection from me

18:37 <jaeger> If nobody encounters problems with rc3 and we get all the documentation updates in that we want, I think we're good to go

18:42 <beerman> i'll be looking into injecting XDG_RUNTIME_DIR with pam_env.so

18:50 <SiFuh> https://liolok.com/set-environment-variables-with-pam-env/

18:55 <stenur> nebbich

18:57 <stenur> do yourself a favourite and use pam_xdg. It works fine, also in container. The binary is ~15 KB. Let dumb_runtime_dir be.

18:58 <stenur> It saw lots of changes, that was because of the FreeBSD maintainer doing things without asking directly for features. So there was a bit of ping pong.

18:59 <stenur> I use it ever since i wrote it. "session optional pam_xdg.so notroot

18:59 <stenur> " in /etc/pam.d/common-session

19:00 <stenur> But that .profile change was no good anyhow.

19:00 <stenur> Thanks for mentioning there was a new standard version available, beerman.

19:02 <stenur> Of course it is a bit larger, but it support Linux PAM and OpenPAM, and it does /run/user, which granted on CRUX noone needs no more ever since /etc/rc does /bin/mkdir -m 0755 /run/user

19:04 <stenur> P.S.: much to much woolding for such a thing.

19:05 <stenur> P.P.S.: regarding pam_env: please do not use that; it was me who thought about using it by then; but once enabled it does so much, in my opinion such a "monster" should not be enabled from distribution side out of the box.

19:06 <stenur> P.P.P.S.: alternatively someone could write a pam_simple_env, which only injects from a file in /etc/*