IRC channel logs

<daviid>rlb: what is the recommended debian prms for libs?

<rlb>Hmm, I'll have to check -- been so long since I didn't just hand that over to debhelper I don't recall :)

<rlb>From just looking at my /usr/lib/... it's 0644 i.e. u=rw,go=r, but I can go poke around policy if you like.

<daviid>sorry to bother you, thanks

<rlb>No worries, happy to help.

<rlb>and of course "chown root:root" in that case.

<rlb>i.e. /usr/lib/...

<rlb>I suspect they just fall under the general 0644 default now: https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners

<daviid>rlb: actually these are part of g-golf examples, not installed, but (their source code) distributed - i am curious, adding chown root:root would it not require root privs at make tiume?

<daviid>ok, i'll use 0644 and patch, thanks

<rlb>Oh, and https://www.debian.org/doc/debian-policy/ch-files.html#libraries "Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped", while talking about "non public" libs, also implies 0644 for public libs.

<daviid>ok thanks

<daviid>rlb: this is what i have now - https://git.savannah.gnu.org/cgit/g-golf.git/commit/?h=devel - i temporarily commented the sugestion to add "chown root:root" which would (have to) be run at insatall target, currently, g-golf examples are not installed ... many thanks for your kind help, and i have abother quiz :), in a min

<daviid>any autotool chain pro ofc, not just rlb, here is my quiz - i added this manyally written Makefile - https://git.savannah.gnu.org/cgit/g-golf.git/tree/examples/gtk-4/demos/Makefile?h=devel - so that the layout-manager-2 example, in its (demos layout-manager-2-init) module, can call (system (string-append "cd " path "; make")), great. Now, I would like that when running 'make clean' in the main repo dir, it would also call

<daviid>"examples/gtk4/demos/make clean", i just tried to add this to the toplevel (git repo) Makefile.am: "cleam:\n\texamples/gtk4/demos/make clean", but it doesn't seems to work - any hint? thanks

<daviid>i tried this - clean-local:\n cd $(top_srcdir)/examples/gtk-4/demos\n make clean - but i get infinte loop, then hitting C-c -> Makefile:733: clean-recursive] Interrupt

<daviid>i could manually list the files to be deleted ofc, but i'd rather call the <subdir>/make clean, as the Makefile may evolve in time ..

<daviid>and that's what i did, fine for now

<wklew>is there a way to have guile treat compile warnings as errors? e.g. possibly unbound error warnings

<wklew>unbound variable*

<rlb>daviid: yes, that's why it's typically only done during the "install" step, i.e. perms in the work tree aren't critical, and *shouldn't* be "complete".

<rlb>i.e. I probably wouldn't care if the shared lib had execute permission in my dev tree.

<rlb>probably or might not? Never really thought about it -- pretty sure I generally just end up with whatever gcc and/or libtool does, depending on the project.

<rlb>(in the dev tree)

<cow_2001>somehow all the tests pass https://kaka.farm/~stagit/guile-srfi-123/log.html

<cow_2001>(now that codeberg is down https://status.codeberg.org/status/codeberg i am using stagit)

<cow_2001>if anyone has anything to say about it, please do when https://codeberg.org/kakafarm/guile-srfi-123/ is up again

<cow_2001>i mean, as an issue or whathaveyou

<apteryx>lloda: my "test" was using that change to build a bunch of r7rs SRFI https://lists.gnu.org/r/guile-devel/2023-12/msg00071.html

<apteryx>lloda: if I was into adding a new test for define-library, would test-suite/tests/r7rs.test be a suitable place?

<apteryx>*if I were to add

<graywolf>daviid: Thanks :) Now it loads for me as well. Maybe it was just an outage (albeit a weird one).

<lloda>i think so

<cwebber>glad to hear it was a fluke

<cwebber>too busy putting out the NEXT exciting guile-land announcement to have time to stop to solve a hosting issue ;)

<graywolf>cwebber: would you mind if I (when I have some time) put somewhere online the documentation and link to it from guix's manual? There are currently five info manuals linked from Guix's documentation that do not have any HTML version. That sadly makes them non-browsable when using the HTML version of Guix's manual.

<graywolf>I think I should not be doing this without your permission, hence asking first.

<cwebber>graywolf: I think that would be great

<cwebber>and you have my permission

<cwebber>endoresement, I should say

<graywolf>kk :)

<graywolf>thx

<cwebber>thank you!

<apteryx>there's also this one which would be nice to merge before the next release; it improves our SRFI 64 doc a little with suggestions from Arne: bug#75041

<ajarara>if I want to display process output as it arrives (e.g. not `(display (read-string (open-input-pipe "echo before; sleep 10; echo after")))` having all output arrive at once), how do I do that? I'd have to feed the read pipe into current-output-port. But.. how?

<dsmith>ajarara, Seems to be a FAQ

<dsmith>ajarara, See pipeline: https://www.gnu.org/software/guile/manual/html_node/Pipes.html#index-pipeline

<dsmith>Wow! 218 nicks in #guile! That's almost as maany as in #scheme (220)

<ajarara>climbing!

<dthompson>and unlike #scheme the vibes aren't trash :)

<ajarara>pipeline feeds stdout into stdin of the next thing in the pipeline. I just want it to write to stdout (this is a guile script that runs commands in series, but conditionally and with some processing in between)

<rlb>cow_2001: not sure the context (and hadn't seen srfi-123 yet), but for guile, another way to do that might be goops, which would mean extensibility for other types if someone wanted that...

<rlb>ACTION whistles innocently...

<rlb>ajarara: I haven't messed with guile's subprocess stuff much in a bit, but generally, you either need to arrange for the last process in a pipeline to share guile's stdout, or you'll need to "shovel" the lines from guile, either via your main thread after launching the subprocess, or a shovel thread of some kind.

<rlb>So for pipeline (haven't used it yet), presumably you'd need to read lines from the input-port and write them to current-output-port.

<rlb>(and of course be careful about "lines" if you don't control the source, since they could be arbitrarily large -- DOS, etc.)

<ajarara>shoveling some bytes to and from on the main thread sounds like it'd work. lemme try it!

<rlb>(...also be nice to have a get-in equivalent of some sort (alongside ref*) allowing provision of a default, and fixing the asymmetry with ref.)

<ajarara> https://paste.debian.net/1346480/ - this works well so far.

<graywolf>ajarara: It can be made more efficient by using bytevectors instead of individual ports. I personally am using https://git.wolfsden.cz/guile-wolfsden/tree/wolfsden/ports.scm#n27

<rlb>ajarara: yep - if there's going to be "a lot" of data, you'll probably want to read bigger chunks in most languages (guessing guile too).

<graywolf>(Of course feel free to keep your version if you prefer, whatever suits you :) )

<graywolf>s/individual ports/individual characters/

<ajarara>ACTION thumbs up

<daviid>rlb: right, I decided to care :) because Matija Obid, who's working on making g-golf and its examples available on NixOS, reported this ... Ofc they could fix that as building the example pkgs, but why not fixing it upstream ... done now so ok. I just left the chown root:root as a comment, since i have no install target for the examples for now ... tx again for your help

<daviid>graywolf: yw!

<rlb>certainly

<rlb>daviid: fwiw, one way to get root ownership without root in archives if you ever need it is via fakeroot. i.e. "fakeroot bash -c 'PREFIX=/some/where make install && tar -C /some czpSf some.tgz some'". Another on linux-ish is (though I'm not really familiar with it now) unshare and friends.

<rlb>Then the "chown root:root ..." will "work", at least as far as the archive contents are concerned -- you were never *actually* root.

<rlb>oops -- "tar -C /some czpSf where.tgz where"

<daviid>rlb: i'll make a note to myself with the above, tx

IRC channel logs

2025-01-23.log