IRC channel logs

<rlb>efraim: current main works fine on perotto with that patch (well it does fail in test-out-of-memory, but iirc that one's unreliable -- the build and other tests are fine).

<lechner>Hi, what happens, please, when a Guile program loads a shared ELF library which, in turn, loads a dynamic ELF module that calls libguile? Does that program run one or two Guile interpreters?

<lechner>That's how my Guile-PAM works, but I have trouble using it from a Guile program. https://juix.org/guile-pam/

<lechner>Looks like I'm having trouble setting GUILE_EXTENSIONS_PATH from the dynamic ELF module.

<lechner>Okay, I think it's one interpreter. Is there a way to detect from C whether Guile is running already?

<whereiseveryone>does guile have an environment variable similar to Python's PYTHONSTARTUP which sources the pythonrc file?

<whereiseveryone>looks like not:

<whereiseveryone>env | rg GUILE

<efraim>rlb: thanks. I'll take another look at applying that patch on guix and building for 32-bit. I might actually just not be applying it correctly

<lechner>whereiseveryone / That sounds like a reasonably feature request. Can you use a symbolic link or set HOME differently for the time being?

<lechner>Hi, is there a way to harden Guile scripts for use with setuid/setgid? I'm thinking about environment variables like GUILE_LOAD_PATH and GUILE_EXTENSIONS_PATH. Would that need to be addressed in ld.so(8) as it is for LD_LIBRARY_PATH?

<elpogo>lechner: re: "detect from C whether Guile is running already" did you try to access scm_thread struct's guile_mode member in C?

<Arsen> 10:49:39 <lechner> Hi, is there a way to harden Guile scripts for use with setuid/setgid? I'm thinking about environment variables like GUILE_LOAD_PATH and GUILE_EXTENSIONS_PATH. Would that need to be addressed in ld.so(8) as it is for LD_LIBRARY_PATH?

<Arsen>scripts cannot use setuid on linux

<Arsen>wrt the load_path variables, no, one would just need to use secure_getenv

<rlb>efraim: if nothing else, "patch -p1 < patch" should work. And note that debian builds from scratch (i.e. debian's orig.tar.gz comes from git, not the tar archives) in case that matters.

<rlb>(meaning debian's always bootstrapping)

<ekaitz>civodul: now i'm checking in what we did in PEG and i think you applied the wrong version of it

<civodul>ekaitz: heh, wonderful :-)

<civodul>if you send a patch fixing this, feel free to ping me!

<ekaitz>civodul: there was one there already

<ekaitz>the v5 has it

<ekaitz>civodul: reverting and applying v5 would fix it, and also add an interesting test

<ekaitz>civodul: are you around? i prepared the patches

<ekaitz>civodul: i just add the patches to the issue and cc-d you, they apply only the changes from v4 to v5 but without overwritting your touches

<lechner>Arsen / thanks!

<civodul>ekaitz: is that on bug-guile?

<ekaitz>civodul: you have been cc-d but it's 73188

<civodul>got it!

<civodul>there are no commit logs, but i guess i can fix that if that’s the only thing

<civodul>the one that says “fix …” doesn’t have a companion test case

<civodul>would be nice to have one so that the bug doesn’t come back to haunt us, WDYT?

<civodul>the HTML5 test case is neat!

<ekaitz>civodul: the test is the one that comes later, sorry

<ekaitz>the html5 one is supposed to test everything better

<civodul>ok

<ekaitz>civodul: now you are adding stuff, there's another patch that i sent to guile to document the GC environment variables

<ekaitz>hehe

<dsmith>sneek, where are you?

<dsmith>sneek, botsnack

<sneek>:)

IRC channel logs

2024-12-22.log