IRC channel logs

2023-09-15.log

back to list of logs

<janneke>ACTION rebases and updates hurd-team
<gabber>issues.guix.gnu.org is unavailable right now (502 Bad Gateway)
<lechner>bjc / jpoiret / ulfvonbelow / thanks!
<mbakke>sneek: later tell civodul I'm looking at 7b11cfd19e9cae1b8308fae974307168c1766723 and notice it uses seemingly top-level references to grep and gawk: did file-append gain input knowledge or was that an oversight? :-)
<sneek>Got it.
<mbakke>NPM is crazy ... I built NoVNC with 'npm install' and got a /tmp/core-js-banners saying "thank you for using core-js!"
<jackhill>you're welcome, I guess :)
<jackhill>mbakke: some context maybe: corejs dev has had some … challenges https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md
<mbakke>jackhill: thanks for the link, now I feel bad about complaining ... glad to see they are doing better now: https://opencollective.com/core-js
<lilyp>remember that GNU parallel asks you to cite it on each invocation, even if you have no paper to cite it in
<lilyp>(and it doesn't honour XDG base dirs, which means more clutter in your $HOME)
<damo22>do you have to cite it per thread?
<damo22>:P
<mirai>set an alias for parallel :)
<mirai>I'd try asking if upstream would be interested in adding XDG support since that'd be the better thing
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, mbakke says: I'm looking at 7b11cfd19e9cae1b8308fae974307168c1766723 and notice it uses seemingly top-level references to grep and gawk: did file-append gain input knowledge or was that an oversight? :-)
<bumble>curl -I https://issues.guix.gnu.org # HTTP/1.1 502 Bad Gateway
<civodul>mbakke: good point! the reviewer wasn’t paying attention i guess, oops!
<civodul>you’re around to fix it?
<civodul>ACTION restarted mumi
<mbakke>civodul: fixed on my local branch
<mbakke>civodul: it gave me an idea, though: would it be possible to create an input-append macro that looks at the current package inputs?
<mbakke>it would be an ergonomic alternative to this-package-input and search-input-file
<mbakke>both of which are "clumsy" compared to file-append
<cbaines>morning all :)
<cbaines>qemu-minimal looks to be broken https://data.guix.gnu.org/gnu/store/zn390q1p6alvklsymfjs7kk286dg0jmn-qemu-minimal-8.1.0.drv
<andreas-e>Hello cbaines! Congratulations for the NLNet grant! When does it start, or has it already? These are exciting news!
<cbaines>andreas-e, thanks, and it's started in that it's agreed, now the work just needs doing :)
<cbaines>I'm still doing QA/substitutes stuff at the moment though, as that still seems to not be in a great state
<andreas-e>cbaines: It is very nice when it works, but seems to be somewhat fragile, with frequent timeouts or 50x errors on the frontend. I do not know whether these come from bugs in the backend sometimes, however.
<cow_2001>Really should consider bittorrenting the qcow2s here: https://guix.gnu.org/manual/en/html_node/Running-Guix-in-a-VM.html
<civodul>definitely
<civodul>if you’re familiar with BitTorrent, you’re welcome to give a hand
<nikolar>cow_2001: what exactly do you mean by that
<nikolar>the downloads on the guix website?
<cow_2001>Put a magnet link or something like that in the manual, and keep a torrent client running that seeds the file.
<cow_2001>civodul: How?
<cow_2001>I could generate a torrent file here in transmission.
<cow_2001>Eventually... when the 60KB/s download finishes...
<cow_2001>Might be something bad on my end, though.
<civodul>cow_2001: i guess that entails (1) getting a seeder (?) service to run on Guix infra, and (2) updating the web page with the magnet link
<civodul>#1 can be done as a patch in maintenance.git
<civodul>#2 is a patch in guix-artwork.git
<cow_2001>guix repo has transmission and aria2!
<cow_2001>Ooh!
<jpoiret>heh, if the images are bit reproducible you could even consider building it yourself and then sharing via torrent :)
<civodul>that too!
<jpoiret>not sure if that's the case
<civodul>yeah, i don’t think so :-)
<cow_2001>This is exciting!
<cow_2001>3MB/s
<cow_2001>I only have a guix installed by apt on a debian-ish installation.
<cow_2001>So it's per user.
<cow_2001>Oh wait, I am downloading the qcow2 ~_~
<nckx>It is very tempting to waste a week trying to adapt this for Guix: https://makelinux.github.io/kernel/map/
<nckx>Nominative determinism.
<cow_2001>nckx: Oh!
<cow_2001>Copying the image into the working copy!
<nikolar>i'd love to help with the torrent thing
<cow_2001>Yeah, I'm clueless. Never wrote a Guix system setup.
<avalenn>I didn't know that guix shell had a cache. Interaction with "-f" can be surprising.
<avalenn>> The cache is also invalidated, when using --file or --manifest, anytime the corresponding file is modified.
<avalenn>I am not sure of that anyway.
<civodul>avalenn: how surprising?
<avalenn>I did "guix build -f myfile.scm" "guix shell -f myfile.scm --container" "vi myfile.scm" rinse, repeat
<avalenn>and the second guix shell invocation gives me old package
<avalenn>not sure I am able to reproduce but something fishy was ongoing
<civodul>so you think the cache wasn’t invalidated?
<civodul>seems to work for me
<civodul>one way to check is to set GUIX_PROFILING=rpc
<civodul>on cache hit, it’ll print that 0 RPCs were made
<avalenn>civodul: --rebuild-cache solved the problem, so I guess, but I have no other proof
<zamfofex>civodul: From my experiences, ‘guix shell’ caches per “packages specified verbatim on the command line”. If you specify the same packages, it doesn’t matter what file you specify in ‘-f’, it seems to always reuse the cache.
<avalenn>I confirm : https://bpa.st/W2RA
<somenickname>Hmm, my mcron job to run a Bash script to update the Git mirros works now, but it is setup for 1AM but it actually runs at 7AM.
<avalenn>somenickname: timezone ?
<graywolf>Hi :) Why does guix git authenticate check from newest commit to the oldest? From security point of view, that seems like somewhat unusual order, so I am curious what is the reason? Would anyone know?
<sneek>graywolf, you have 1 message!
<sneek>graywolf, nckx says: Hmm… (call-with-input-file "/home/wolf/src/guix/.guix-channel" (@@ (guix channels) read-channel-metadata)) but I see what you mean :-/
<somenickname>avalenn: The system was always set to Europe/Berlin.  I wonder if it maybe because it has no RTC.
<civodul>avalenn: hmm, what am i supposed to see? :-) cache miss on the first run, but we don’t know about the second one, right?
<civodul>graywolf: what makes you think it checks from newest to oldest? i traverses from the last known authentic commit to the latest one
<avalenn>civodul: I change the file, guix shell does not rebuild anything, I make rebuild-cache and it rebuilds my package
<civodul>avalenn: where do you change the file at https://bpa.st/W2RA ?
<civodul>i think i’m missing something
<avalenn>the paste is not sufficient
<avalenn>I will try to explain it better a bit later
<avalenn>when I can think clearly
<civodul>here “touch guix.scm” leads ‘guix shell’ to invalidate its cache
<civodul>heh, np :-)
<civodul>ACTION -> lunch
<graywolf>civodul: Hm? commit-difference returns a list with newest commit at the head no? And that list is then proccessed in order.
<minima>hi, i'd like to generate a guile script via a g-exp; i know how to do it by including the script in the g-exp; however, since the script is somewhat long, i wanted to keep it into a separate file and copy it over at build time; here's a MVE https://bpa.st/LRAA
<ulfvonbelow>I would think that the order mostly matters for the sake of intuitive error reporting
<minima>basically, if i use `computed-file' i need to handle the guile shebang "manually"
<minima>whereas `program-file' won't work (because of the way i copy the file over with `copy-file'?)
<graywolf>ulfvonbelow: But at each commit you parse untrusted data from .guix-authorizations. That is fine as long as there are no bugs, but there are always bugs. I am not sure "intuitive error reporting" is great reason to operate on untrusted data in security areas.
<ulfvonbelow>program-file is for turning a gexp into a guile script, and computed-file is for turning a gexp into a derivation builder. The particular error you're seeing is because within a gexp, #$output expands to (getenv "out"), which returns #f when it's invoked outside of a derivation build.
<lechner>ulfvonbelow / thank you for explaining that!
<minima>thanks ulfvonbelow!
<ulfvonbelow>ah. I suppose from an attack surface reduction perspective, reducing it to only one possibly-malicious commit that ever needs to be checked makes some sense. For what it's worth, I think the more intuitive error reporting would be to report the earliest unauthorized commit also.
<ulfvonbelow>since some might read "commit X and what comes after it are suspect" and think it means that what comes before it isn't also suspect
<graywolf>Hm, that is also a good point, I did not realize that
<lechner>mirai / Hi, thanks for your comments on the proposed Rspamd service. Are Thomas or Saku ever here? https://issues.guix.gnu.org/61740
<janneke>hmm the modify-services in my devel-hurd.tmpl now gives
<janneke>Wrong number of arguments to #<procedure apply-clauses (clauses service deleted-services)>
<ulfvonbelow>of course, the bestest error reporting would be to avoid whack-a-mole error checking and report all the errors at once
<ulfvonbelow>ACTION glares at profile collision reporting
<janneke>hmm, what could have changed?
<lechner>janneke / is this related to #65184, #64106 or #63921
<lechner>?
<janneke>lechner: thanks, hmm the bug doesn't tell us the commit that was pushed
<nckx>Whatever happened to your bot that would slightly reduce the chances of people joining IRC channels #65184, #64104 and #63921 at the expense of more convenience?
<janneke>guess it was f66fa5f917e76935187935b09ae7ac037b8b35f8
<janneke>lechner: thanks, yes f66fa5f917e76935187935b09ae7ac037b8b35f8 caused this breakage
<janneke>now to find out why
<janneke>oh wait, maybe it's a make clean-go thing
<lechner>#555
<cow_2001>Abandoned the idea of running the image. It is rather old anyway. I have no idea what I'm doing. I want to get a guix system vm that has a fairly desktopy desktop. Running ``guix system vm desktop.tmpl'' currently.
<lechner>bot testing #65184, #64106 or #63921
<nckx>cow_2001: Those aren't very mutable, but fine for testing/tasting Guix System (and other use cases). I've mirrored the qcow2 if you want. Its age isn't that important, since the point is that you can mutate & upgrade.
<nckx>ACTION hides some botsnacks in the bug tracker.
<lechner>bot testing #65184, #64106 or #63921
<mooncake>"(modify-services … (delete …)) should delete all matching service types" https://issues.guix.gnu.org/65184
<mooncake>"`modify-services` no longer affects multiple instances of the same service" https://issues.guix.gnu.org/64106
<mooncake>"Activation snippets in reverse order, prevent boot" https://issues.guix.gnu.org/63921
<lechner>okay, standoff is over
<cow_2001>I see that guix system vm would have the same back as the host's
<cow_2001>Saves space.
<nckx>Yes.
<cow_2001>How do I pin stuff so that guix gc would not erase them?
<nckx>Look at the --root argument of many Guix commands.
<cow_2001>Thank you!
<janneke>lechner: thanks, yeah -- fixed with a make clean-go make-go
<janneke>ACTION notes that dependencies for go files would be nice
<lechner>janneke / 👍
<lechner>janneke / what do you mean by that, please? wouldn't proper prerequisite handling of scm->go be sufficient?
<janneke>lechner: yeah, build dependencies that's what i meant
<lechner>janneke / they are coming. i rewrote make in Guile and am currently porting the Guix Automake files
<janneke>lechner: no...is that for real?
<lechner>yes, except i use BLAKE3 hashes instead of mtime
<janneke>omg, that sounds amazing
<lechner>janneke / WIP http://paste.debian.net/1292022
<mooncake>Exception: #<&compound-exception components: (#<&error> #<&origin origin: "scm_from_utf8_stringn"> #<&message message: "input locale conversion error"> #<&irritants irritants: 0> #<&exception-with-kind-and-args kind: decoding-error args: ("scm_from_utf8_stringn" "input locale conversion error" 0 #vu8(60 63 120 109 108 32 118 101 114 115 105 111 110 61 34 49 46 48 34 32 101 110 99 111 100 105 110 103 61 34 85 84 70 45 56 34 63 62 10 10 60 33 68 79
<mooncake>32 80 85 66 76 73 67 32 34 45 47 47 87 51 67 47 47 68 84 68 32 88 72 84 77 76 32 49 46 48 32 84 114 97 110 115 105 116 105 111 110 97 108 47 47 69 78 34 32 34 104 116 116 112 58 47 47 119 119 119 46 119 51 46 111 114 103 47 84 82 47 120 104 116 109 108 49 47 68 84 68 47 120 104 116 109 108 49 45 116 114 97 110 115 105 116 105 111 110 97 108 46 100 116 100 34 62 10 60 104 116 109 108 32 120 109 108 110 115 61 34 104 116 116 112 58 47 47 119 119 119
<mooncake> 57 57 47 120 104 116 109 108 34 32 120 109 108 58 108 97 110 103 61 34 101 110 34 32 108 97 110 103 61 34 101 110 34 62 10 60 104 101 97 100 62 10 32 32 60 116 105 116 108 101 62 100 101 98 105 97 110 32 80 97 115 116 101 122 111 110 101 60 47 116 105 116 108 101 62 10 32 32 60 108 105 110 107 32 114 101 108 61 34 115 116 121 108 101 115 104 101 101 116 34 32 116 121 112 101 61 34 116 101 120 116 47 99 115 115 34 32 104 114 101 102 61 34 47 112 9
<mooncake> 115 34 32 47 62 10 60 47 104 101 97 100 62 10 10 60 98 111 100 121 62 10 10 9 60 99 101 110 116 101 114 62 60 97 32 104 114 101 102 61 34 47 34 62 60 105 109 103 32 115 114 99 61 34 47 105 109 97 103 101 115 47 100 101 98 105 97 110 46 112 110 103 34 32 97 108 116 61 34 34 32 98 111 114 100 101 114 61 34 48 34 32 104 115 112 97 99 101 61 34 48 34 32 118 115 112 97 99 101 61 34 48 34 32 104 101 105 103 104 116 61 34 54 49 34 32 47 62 60 47 97 62 6
<mooncake>98 114 32 47 62 10 10 60 100 105 118 32 105 100 61 34 116 105 116 108 101 98 97 114 34 62 100 101 98 105 97 110 32 80 97 115 116 101 122 111 110 101 60 47 100 105 118 62 10 10 10 10 10 10 60 100 105 118 32 105 100 61 34 99 111 110 116 101 110 116 34 62 10 10 10 10 10 10 9 10 9 10 10 9 10 9 10 9 10 9 10 9 10 9 10 10 10 10 10 60 104 49 62 80 111 115 116 105 110 103 32 49 50 57 50 48 50 50 32 102 114 111 109 32 97 110 111 110 121 109 111 117 115 32 1
<janneke>did you look at spike121s potato make at all?
<lechner>no, i only looked at Zig's build system, but ended up settling on something more like Haskell's Cabal
<janneke>OK
<lechner>but it's all up in the air. i am making changes all the time. guix is my guinea pig. https://codeberg.org/lechner/bespoke
<nckx>Ooh, a make that silently breaks 'touch foo', I like your brand of evil.
<lechner>no more rebuilds on checkouts
<janneke>ACTION was a big fan of scons for that
<janneke>but in the end we didn't use it for our (lilypond) build system
<lechner>there is a lot of cool stuff out there but ultimately make in Guile is the only thing that allows seamless integration
<lechner>no more shell scripts!
<lechner>no more shell quoting, either
<janneke>lechner: also, no more "elaborate kludges" such as my recent #65456
<lechner>civodul provided the kick i needed https://toot.aquilenet.fr/@civodul/110737394740976033
<lechner>much less sophisticated though
<lechner>sorry, sometimes the bot chokes #65456
<mooncake>"[PATCH 0/2] Split guix build into more steps for 32bit hosts." https://issues.guix.gnu.org/65456
<pkill9>lechner: does that replace the 'make' binary and the makefile too?
<lechner>janneke / i saw the five-way split in the Makefile, but isn't that related to a an exhaustion within Guile?
<lechner>pkill9 / you have a local ./make file
<janneke>lechner: hehe, does he (civudul) ever otherwise? ;)
<pkill9>ahh
<janneke>lechner: i don't know, i'm rooting the import cycle analysis by ... jpoiret and/or possibly others
<pkill9>i thought a while ago that a guile make system would be nice, nice to see someone created it :)
<janneke>*rooting for ... to fix it
<lechner>pkill9 / they are a little cryptic because i'm experimenting with higher levels of abstraction a la Automake. Here is an example of the pure 'make' engine except the recipes can now also be lambdas https://codeberg.org/lechner/bespoke/src/commit/93260a336ca7e8e80adf387665e3b2c66b638067/examples/autoconf/make#L30
<mooncake>"bespoke/make at 93260a336ca7e8e80adf387665e3b2c66b638067 - bespoke - Codeberg.org" https://codeberg.org/lechner/bespoke/src/commit/93260a336ca7e8e80adf387665e3b2c66b638067/examples/autoconf/make#L30
<lechner>there is a Sqlite3 db in .make for state
<janneke>ACTION clones bespoke .. and wonders if it could (be made to) work on mes
<lechner>janneke / please just remember that it's brand new. ideas and patches are welcome
<lechner>janneke / as for mes, sure. the only prerequisites are sqlite3 and irregex, but i'm happy to make any changes there, such as using plain regexes and a text file with state info. (diff-sexp failed to live up to my expectations.)
<janneke>lechner: sure, i'll keep that in mind
<civodul>ACTION sees a pretty bytevector in the backlog
<civodul>graywolf: yes you’re right! ‘authenticate-commits’ doesn’t autenticate them from old to new, my bad
<civodul>it processes them by batch, which sounds weird, but the end result is yes or no for the whole range
<lechner>civodul / one of the bot's specialties. maybe the download was too big. patches welcome https://codeberg.org/lechner/guix-helper-bot
<mooncake>"lechner/guix-helper-bot - guix-helper-bot - Codeberg.org" https://codeberg.org/lechner/guix-helper-bot
<lechner>actually it was UTF-8 related
<janneke>sneek: later tell samplet: have you seen this very new make in guile? -- https://codeberg.org/lechner/bespoke
<sneek>Got it.
<mooncake>"lechner/bespoke: A Make tool in GNU Guile - bespoke - Codeberg.org" https://codeberg.org/lechner/bespoke
<janneke>sneek: botsnack
<sneek>:)
<graywolf>civodul: So RCE based on just reading and parsing .guix-authorizations is considered impossible? In that case I guess it is fine. :)
<lechner>civodul / debpaste.el submits UTF-8 code incorrectly. I don't want to mention the link again, but it's probably the copyright character in Debpaste no. 1292022
<nckx>Regardless, the bot should spew any exception to a control channel (assuming you have one, or a PM to its owner) or a log file. Not stdirc.
<avalenn>What is the idiomatic way to concatenate content at the end of a file ?
<lechner>nckx / it was based on the premise that being a public nuisance would attract more patches, or calls for a power-off
<nckx>Well, I mean, sure, yes.
<janneke>mooncake: source?
<lechner>that should be implemented
<lechner>it's licensed under Affero!
<bjc>having a bot that derefs things like bug numbers is useful. but there is no bot so useful that dumping voluminous errors to a public channel warrants its existence
<lechner>janneke / https://codeberg.org/lechner/guix-helper-bot
<mooncake>"lechner/guix-helper-bot - guix-helper-bot - Codeberg.org" https://codeberg.org/lechner/guix-helper-bot
<bjc>and, frankly, "be a public nuisance" is no way to run a service
<lechner>okay, i turned it off again
<janneke>lechner: thanks, /me looks
<janneke>ACTION just wrote/resurrected snuik for #bootstrappable and some other channels -- https://gitlab.com/janneke/snuik
<nckx>I *am* a fan of the bot, but contributions should be 100% voluntary, not 99% + grrr stop dumping bvs in the channel. ☺
<bjc>👆
<lechner>sorry, it's not a level of service i can provide
<lechner>i also reboot to often
<janneke>ow crap, rekado also wrote an irc library -- why didn't i know that
<lechner>yeah
<lechner>janneke / i would be happy to merge our two projects, perhaps after you take over guile-irc
<lechner>i don't think rekado wrote it, but he is currently the upstream maintainer
<lechner>reluctant upstream maintainer, is my take
<lechner>you and i could probably have it
<lechner>it came from here https://github.com/fbs/guile-irc
<nckx>I've never used Guile IRC, but ‘redirecting’ what feels like all of stdout/stderr to the IRC port sounds like an error-prone choice.
<lechner>thanks, i never wanted to have a net negative effect on the operations of this channel
<lechner>let's be happy
<nckx>I mean, I thought the whole point of exceptions was that they aren't in-band content. (display (compute-something) irc-port) shouldn't see a backtrace…
<nckx>I am?
<lechner>not with exceptions
<nckx>I am not criticising your effect on the channel at all.
<nckx>I'm critiquing guile-irc from the funnest place: ignorance.
<lechner>i am not arguing. there simply isn't an "out-of-band." i am unable to provide that level of service
<janneke>lechner: i would welcome any code stealing or project merging but was kinda happy to be "done" with snuik for now
<janneke>ACTION also has quite some things on their plate -- don't we all ;)
<lechner>janneke / no problem, actually, i just like you and hope we might be able to cooperate on something
<civodul>nckx: #vu8(87 104 97 116 39 115 32 119 114 111 110 103 32 119 105 116 104 32 98 121 116 101 118 101 99 116 111 114 115 63) if i may
<lechner>nckx / i will accept a patch to redirect all bot exceptions to your email. or better yet, you can have the bot
<janneke>lechner: likewise, we'll see where it goes
<lechner>ACTION hands over bot
<civodul>(even better than rot13)
<cow_2001>Oh.
<cow_2001>Now I see. guix system vm won't allow me to install new packages.
<nckx>civodul: lol. Now I have to find a REPL.
<nckx>#vu8(73 115 32 116 104 105 115 32 111 110 101 32 111 102 32 116 104 101 32 109 101 110 116 97 108 32 116 111 108 108 115 32 111 102 32 71 117 105 108 101 32 109 97 105 110 116 97 105 110 101 114 115 104 105 112 63)
<nckx>At least rot13 is efficient.
<ulfvonbelow>but it's only half as strong as rot26
<nckx>There doesn't appear to be a satisfying rotUTF-8.
<nckx>lechner: I don't want the bot, so it's dropped on the floor now. Poor bot.
<nckx>‘I don't host public services’ has served me well so far.
<lechner>you are a public service, at least in this channel
<civodul>nckx: #vu8(89 101 97 104 44 32 119 101 32 103 101 116 32 117 115 101 100 32 116 111 32 105 116 46)
<civodul>we really need an ERC plugin for bv encoding
<nckx>lechner: …and my uptime and reliability is correspondingly atrocious. 😃
<rekado>I only washed off some bit rot from fbs’s guile-irc
<civodul>i’m sure Big Tech will eventually come up with ChatBV
<nckx>(Thanks though.)
<nckx>It's going to be JWTs over WebSockets though.
<lechner>civodul / #vu8(84 104 101 32 99 104 97 110 110 101 108 32 98 111 116 32 99 111 117 108 100 32 104 101 108 112)
<nckx>Hehe.
<civodul>heh, true! :-)
<lechner>nckx / your uptime is exemplary, actually.
<lechner>plus, you hardly ever eat
<nckx>You're thinking of sleep.
<nckx>As a totally real human, I consume an average amount of food to maintain my weak organic shell.
<lechner>either way, i'm glad you're back
<nckx>Thanks!
<nckx>avalenn: Sorry, missed your question. (let ((port (open-file "my-file" "a"))) (output-something port))
<nckx>cow_2001: Yes, that's the issue. ‘guix system vm’s aren't ‘self-hosting’: the are a (very useful) product, but they don't simulate a complete computer with a mutable root block device like some people define VM. The qcow2 image does.
<nckx>It's a regular Guix System installed on a mutable block device that you can ‘guix pull’ & ‘guix system reconfigure’.
<avalenn>nckx: thanks, I looked for something more straightforward, but I falled back to open-file indeed
<nckx>Oh, it seemed straightforward to me, must be guile-brain.
<ulfvonbelow>if I'm making one small change across every single build system, should that go in one commit, or in 40 or so different commits?
<nckx>I also forgot close-port but I'm sure you didn't.
<lechner>nckx / that's the part that wasn't straightforward
<lechner>ulfvonbelow / what's the change, please?
<nckx>What else is garbage collection for.
<lechner>guile brain
<ulfvonbelow>modifying the lower procedure so that all packages are introduced explicitly into the bag's argument field, leaving none introduced by the bag->derivation builder's defaults.
<lechner>ulfvonbelow / my take is, one commit with a nice commit message, but i am probably totally alone
<lechner>the changes are obviously related, and require an explanation. also reverting would be easier, if needed
<ulfvonbelow>in almost all cases, this means adding a keyword argument (guile (default-guile)) to the lower procedure, and ensuring that whatever was passed there is in the bag arguments
<ulfvonbelow>in some cases it also means including other packages, like qtbase
<lechner>i think all that should be mentioned and correlated in a nicely written commit message
<nckx>ulfvonbelow: I agree with lechner, one commit.
<nckx>Just don't round down the commit message, indeed.
<lechner>yay, not alone
<avalenn>Do you have some tip for debugging builder script ? The generated scheme code seems ok to me but it fails.
<avalenn>I think substitute* macro is too much for me today
<lechner>nckx / what's the alternative, forty commit messages with guix(xyz-build-system): modified XYZ build system ?
<ulfvonbelow>if you've got emacs, emacs-guix has a lovely M-x guix-scheme-mode to prettify thebuilder scripts
<nckx>lechner: I guess, but we both agree that's excessive.
<nckx>avalenn: Does ‘looking at the builder until you spot the stupid error’ count? Because otherwise no.
<ulfvonbelow>also, if you're having trouble with substitute*, I recommend opening up a 'guix repl', running (use-modules (guix build utils)), creating a file, and tinkering with it
<nckx>M-hm. Or ask for help here.
<lechner>the extra set of parentheses in substitute* can be a bit weird
<nckx>They aren't that extra.
<lechner>i know
<lechner>they just look extra
<ulfvonbelow>regular expressions are like usb type A ports: it should be a 50% chance you plug it in the right way, but for me it's more like 10%
<nckx>Regular exceptions.
<ulfvonbelow>every time I use extended, it's basic, and every time I use basic, it's extended
<lechner>try irregex
<nckx>substitute* has one or two, which is great, because what regexps needed were exceptions.
<lechner>oh, in the shell
<ulfvonbelow>I recall substitute* having weird behavior with line endings
<avalenn>this is not the extra set of parentheses, I think it have to do with string literal quoting or something like that
<nckx>ulfvonbelow: There's a manual that says ‘basic (or obsolete) regular expressions’ and I cry every time I read it. If only.
<avalenn>or not
<avalenn>it "works for me" in guix repl, why not in the builder ? :-(
<bjc>you sure the path is right? that bites me all too often
<lechner>avalenn / i use regexp-quote without embarassment "I am reading the same patch for the third time by now and you are still using (regexp-quote ...)" https://lists.gnu.org/archive/html/bug-guix/2023-05/msg00527.html
<avalenn>in fact, it has nothing to do with regexp, just a bad file name
<bjc>all too often =)
<avalenn>I seem to be unable to properly read error messages
<bjc>tbf, guile goes out of its way to make them hard to read
<lechner>our messages are lousy
<rekado>lechner: doesn’t look like guile-irc dumps the exception into the IRC channel. It’s this code: https://codeberg.org/lechner/guix-helper-bot/src/branch/history/scm/scan/generic-urls.scm#L58
<lechner>rekado / did i say otherwise?
<rekado>hmm?
<lechner>i admitted to dumping exceptions into the channel willfully in order to attract fixes
<rekado>oh, well, I haven’t read your message. I just looked where that behavior comes from.
<lechner>yeah, due to the large variety of web pages out there, the bot encounters a lot of weird things, but it's no way to run a service
<rekado>I think silent failure is completely acceptable here
<lechner>i probably agree. initially, the idea was that exceptions were bugs in the bot, but they really are mostly bugs in the real world
<nckx>rekado: I was the one who assumed it was a guile-irc default.
<nckx>Glad to hear it's not.
<avalenn>bjc: I would not mind lousy error messages if I was able to dump to REPL at the point of the error
<lechner>that's often the problem. racket at least gets the line numbers right
<bjc>ACTION idly wonders how much work it'd be to port guix to racket
<ulfvonbelow>take a drink every time you "Unknown file: (_ _ _ _)"
<nckx>bjc: First, you must defeat civodul in physical hand-to-hand combat, so it's not trivial.
<bjc>there's some environment variable to at least stop the 80 character elision, but i can't remember what it is
<nckx>COLUMNS
<bjc>it should be *off* not limited at all
<nckx>But setting it in the right (buld) environment is the fun part.
<nckx>AFAICT everyone agrees.
<bjc>and, y'know, it should have been off in 1989 or whenever guile was first birthed. in 2023 it's insane
<nckx>AFAICT everyone agrees.
<graywolf>Can't guix just always set it as default? Since "everyone agrees"? :)
<bjc>i have been trying real, real hard to not get into hacking guile to fix its many annoyances ever since finding guix =)
<cbaines>yay, qemu-minimal has been built \o/ https://data.guix.gnu.org/gnu/store/zn390q1p6alvklsymfjs7kk286dg0jmn-qemu-minimal-8.1.0.drv
<nckx>graywolf: I don't know if this is the reason (ignoring extreme solutions like patching Guix's guile), but modifying the build environment is a no-no.
<cbaines>(it only took 12 tries)
<nckx>bjc: Maybe that was the cunning plan all along.
<lechner>cbaines / i am glad to read it
<lechner>monitors may have been smaller in 1989
<bjc>they were. i was there
<bjc>i also remember, quite distinctly, compiler error output still not being limited
<bjc>because that's an insane proposition
<nckx>It is a very cutesy Guile thing to do though.
<graywolf>bjc: I was not there, so now I feel less old, thanks :D
<nckx>I was there, but I don't think I could count to 80.
<nckx>Terminal tangents aside, even accepting Guile's special headcanon that people want their terminal output cropped: the build output isn't atty. It makes even less sense.
<lechner>why don't we lead by example by turned off the release manuals on the web?
<lechner>turning
<nckx>Example of what?
<nckx>I agree with the body but don't understand the header.
<lechner>implementing changes for which there is no reasonable opposition
<nckx>There was some opposition.
<nckx>(I wrote a patch to do just that, didn't make it to the bug tracker though.)
<nckx>I also didn't have the energy to start The Conversation.
<lechner>it's the biggest hurdle to using Guix. never mind contributing
<lechner>at one point, the manual had the wrong bug address in the instructions
<graywolf>I thought the biggest hurdle is mail workflow :P
<bjc>the manual has a link to the dev version at the top now, right?
<nckx>Yeah, apparently we'll be drowned in contributions if we replace/augment mail with a complex Web-based thing.
<bjc>the number of contributions is less a concern than the number of accepted contributions, and has a negative effect on them
<bjc>but i got nothing for fixing the throughput of acceptances other than, maybe, debbugs is bad, or maybe the way we use debbugs is bad
<bjc>i'd guess the problem is more fundamental than that, though i have no idea what it is
<lechner>someone fixed the throughput of acceptances?
<bjc>no. it needs fixing
<nckx>There's a threadnought about it which I haven't managed to slog myself through just yet.
<rekado>that was 9cadac9787a03093550a1132bf7d20eb4eaf4df9
<bjc>i'm curious how debian manages everything. they surely get more tickets than we do, and they use debbugs. are they also drowning?
<lechner>no
<lechner>but the bug numbers are now in the seven digits
<rekado>bjc: not that it makes a huge difference, but they use a different debbugs instance.
<rekado>the GNU instance is an ad-hoc fork
<ulfvonbelow>the main issues I have with the patch-based workflow are the requirement to send a cover letter in order to get a bug number, and the fact that 'git send-email' doesn't seem interested in gpg-signing the patches themselves
<lechner>rekado / it was a fork. they lost the source code
<bjc>ACTION blinks
<bjc>they lost it?
<rekado>yes, that’s what I mean by “ad-hoc fork”
<rekado>bjc: they deployed something and modified it in place
<roptat>hi guix!
<nckx>o/
<rekado>it’s not like there ever was a maintained source tree for these changes.
<rekado>roptat: hi!
<avalenn>Debian has no single workflow of acceptance, they have per-package maintainers
<rekado>ulfvonbelow: you may send everything all at once, attaching your patches to the initial email.
<lechner>i am hoping to reimagine Debbugs in Guile and just had a conversation with the FSF sysops about it
<rekado>ulfvonbelow: I just don’t think this will work with git send-email
<rekado>lechner: extending mumi or replacing it?
<lechner>merging
<lechner>it seemed like a missing piece until you said you were happy to abandon it
<lechner>abandon mumi
<rekado>I talked to Glenn Morris about this in 2020
<rekado>the conclusion was “the future of debbugs.gnu.org is down to whoever wants to do the work”
<rekado>for me there was little incentive to replace the email-juggling backend
<rekado>I’d be perfectly fine with a few tweaks and customizations
<lechner>we can start a club https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26380#11
<lechner>having maintained other piece of Debian infrastructure in Perl, and knowing Debbugs well, I thought was a good candidate to break through the ice
<nckx>lechner: Are these GNU-exclusive bonus features that important? What are they?
<rekado>somebody’s workflow must depend on them
<lechner>nckx / you mean Debian exclusive? the GNU version is from 2007
<nckx>With something as ancient as debbugs, rewording the copyright message would probably break $omeone's workflow.
<nckx>lechner: No, features of the GNU fork, the ones that are keeping the installation stuck in 2007.
<nckx>The fork must be worth something to someone.
<lechner>yeah, I am not sure
<avalenn>nckx: inertia
<lechner>it was more negligent than that
<lechner>it's GPL-2 software
<nckx>Oh.
<nckx>Yes, clearly not AGPL, or they'd be in big trouble.
<lechner>i consider the GNU instance inferior. as far as I know, it lacks a SOAP interface. they probably just removed the Debian sanity checks for distributions, maintainers and a host of other things
<nckx>avalenn: OK, to me ‘fork’ implies a nontrivial distance travelled down a different road.
<lechner>looks like we do have SOAP at GNU now https://gitlab.com/npostavs/debbugs/-/commits/gnu-reconstruction
<lechner>that is from here https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26380#20
<lechner>f0a45d7d3146ad8406b5bb1b11934852610e5f2f is the last commit from Don Armstrong, the Debian maintainer
<graywolf>It is somewhat funny that debbugs.gnu.org cannot be hosted on savannah...
<lechner>you read this? https://savannah.nongnu.org/task/?14517
<graywolf>yep
<lechner>rekado / i believe mumi would be key because much of what is being argued about could be alleviated by presenting patches differently to different people
<rekado>lechner: initially mumi used guile-debbugs, which I wrote as a SOAP client
<rekado>I abandoned it because it would truncate the original emails
<rekado>then we moved to downloading the mbox files
<rekado>and that broke debbugs.gnu.org, so we were offered rsync access to get the unmodified emails
<graywolf>"that broke debbugs.gnu.org" :-O
<podiki>howdy guix-ers
<rekado>graywolf: yeah, the perl thing got too busy preparing mbox files to respond to our requests.
<graywolf>oh...
<janneke>mbakke: if guix 1.4.0-12.f8ecf2b666 (on hurd-team) fails to build then doesn't that indicate a problem on master?
<janneke>hurd-team only has two commits before that: 1.4.0-11, and the 25-file-limit self build that i've tested thorougly (before rebasing hurd-team)
<nckx>Hi podiki.
<mbakke>janneke: master has a different .drv, the breakage could occur after the update
<mbakke>janneke: reading the test (tests/packages.scm:496), it seems i586-gnu disappeared from %supported-systems
<podiki>hi nckx what's new? (i too haven't taken the plunge into The Great Thread, though obviously care a lot about these issues...)
<nckx>Nothing much, been dealing mainly with Libera stuff in my scarce IRC time. That and sarcasm.
<somenickname>How can I track the progress of Emacs 29.1? Someone said that it is already in the pipeline but I have no clue how cuirass is to be used
<janneke>"mbakke: it seems i586-gnu disappeared from %supported-systems" ahh, interesting
<janneke>mbakke: sure it has another .drv, because we did `make-update-guix-package" on hurd-team?
<janneke>it would be interesting to see what happens after make update-guix-package on master
<podiki>somenickname: last I heard it is ongoing on the emacs-team branch, working to get everything in a reasonable state
<podiki>somenickname: the original patch I believe https://issues.guix.gnu.org/65000
<nckx>somenickname: I don't think CI is the place to track this, since it's not some automated pipeline, it a group of people deciding when to merge the ‘emacs-team’ branch into ‘master’. lilyp is probably the person to ask what, if anything, is blocking that.
<nckx>Emacs itself builds fine: https://ci.guix.gnu.org/search?query=system:x86_64-linux%20spec:emacs-team%20emacs&border-low-id=1812840
<podiki>but if you enjoy combing through builds... https://ci.guix.gnu.org/jobset/emacs-team and https://qa.guix.gnu.org/branch/emacs-team (probably better if it is up to date)
<janneke>mbakke: there are some recent "Remove i586-gnu from supported-systems." commits
<nckx>Oofsies. guix.t.g is on qa.? I should definitely get it building things then…
<janneke>i wonder if any of these were in the guix closure for the hurd?
<janneke>hmm, none of those seem to be in the guix closure
<andreas-e>nckx: Since the very start of QA!
<nckx>That machine is stable (and busy) for months, then something about building all Guix packages crashes it within days. But this is good motivation, ngl.
<somenickname>Is it a VPS or your own server?
<nckx>It's a box in my house.
<somenickname>Well, in that case over provisioning isn't the case
<somenickname>maybe hw issues as of run a benchmark?
<somenickname>I assume building all Guix packages will mean 100% usage of the machine
<mirai>civodul: Hi! I've been taking a stab at writing a “healthcheck” service within shepherd + fibers, this is a skeleton of what it looks like: <https://paste.centos.org/view/f7cf016a>
<nckx>Yes, but it can handle sustained 100% load in other contexts. I think the kernel isn't handling OOM well, or something like that. I've enabled pstore_blk to inspect the panic output but haven't actually given it a block device yet. I'll do that then.
<mirai>Looking at <https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n422> and surrounding blocks, it looks like there are already some channels in place
<nckx>I also suspect btrfs for some irrational but intuitive reason.
<mirai>Can I talk to other channels within my service fibers?
<andreas-e>nckx: What would be useful would be to include it into the bordeaux build farm. We are short on x86 machines. I suppose right now this would make a bigger difference than having a third build "farm".
<andreas-e>How many cores does it have?
<lilyp>somenickname, nckx, podiki: I'm just waiting for complaints and fixes rn, Emacs itself is good to go, but a bunch of packages (e.g. emacs-ess IIRC) are not
<nckx>‘Only’ 8. It's not an impressive machine. Linking it to public build farms isn't an option at this time, sorry.
<podiki>lilyp: one needs to switch to emacs branch to test? i guess I can check if my packages all build/native-compile on that branch
<nckx>You can use time-machine without ‘switching’ wholesale.
<podiki>right, I would do that and build my emacs manifest
<lilyp>Actually, cbaines posted a link to QA, there's only like 15 new broken packages on x86
<podiki>i'd want to check using 29.1 to native compile too
<lilyp>ahh, sure, that's not caught on CI
<andreas-e>nckx: This is the same as for harbourfront. And with the guix build coordinator written by cbaines, the public part reduces to the client connecting to the coordinating machine. So this is probably not much more public than showing the build results on a public page.
<nckx>Which I don't 😉
<nckx>IDK, it feels off to add a machine that routinely runs & builds non-free software to an official build farm.
<nckx>Actually s/runs & //, since I'm sure other machines in the bordeaux rotation use proprietary firmware too.
<lilyp>Uhm, what's that about building nonfree software on our build farms?
<andreas-e>nckx: I see. I am not sure about the proprietary firmware. I think they do not, actually.
<nckx>Cool.
<nckx>I'm misremembering then.
<mirai>sneek, later ask civodul: <https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n242> doesn't seem to match with the description of waitpid return value <https://www.gnu.org/software/guile/manual/html_node/Processes.html#index-waitpid>, can you confirm this?
<sneek>Got it.
<nckx>lilyp: Something best avoided I'd say.
<andreas-e>This is the main reason we do not have more machines in the bordeaux build farm... I had access to a half-rack of machines, but they required firmware for the broadcom network chip, so we did not use them.
<andreas-e>However, I am not sure for our ARM machines.
<nckx>This machine has a Realtek wireless adapter, apart from that it's free-as-in-FSF.
<nckx>I could get rid of it if I reshuffled the home network a bit.
<janneke>hmm, guix shell -D guix on the hurd now depends on glibc-2.35?
<janneke>ah, from /gnu/store/y0h5w5bzgqprxq64hpbasjw56j6yyz5b-glibc-utf8-locales-2.35.drv
<janneke>crap
<somenickname>Andronikos: test
<ulfvonbelow>how would one go about properly "conditionally" using a module from within a module? E.g. try loading the module, and if it's not available, use some alternative definitions.
<mirai>cond-expand?
<ulfvonbelow>seems a bit burdensome to put an entire big old define-module form inside of cond-expand
<mbakke>maybe (false-if-exception (use-modules ...))
<ulfvonbelow>will the use-modules in that case be evaluated at compile-time or run-time?
<mbakke>ulfvonbelow: both, if I parse eval-when docs correctly...
<reepca>nckx: I don't suppose you've seen anything stuck in the guix-devel moderation queue for a day or so?
<nckx>Definitely not a day.
<nckx>Aha.
<nckx>Nice to see you again!
<reepca>o/
<reepca>hmmm... now I'm wondering whether it not showing up is a self-hosted email thing, or I messed something up when trying to get gnus to reply to an imported mbox file
<nckx>Nono, you were right, it was stuck.
<nckx>But you must have sent it right after I did my daily duties yesterday.
<reepca>oh good, I worry because gmail bullies me so
<nckx>Gmail is a bottom-tier provider nowadays, it's just strange to adjust to that because of their size.
<cow_2001>I am back to the qcow2 guix system from the site. Reading the manual I see that system-wide upgrading it needs a /etc/config.scm, which is not there.
<nckx>Because it's supplied by the user.
<janneke>mbakke: this commit removes i586-gnu from dummy-package's supported systems
<janneke>0e08ad7f19 gnu: linux-libre-headers: Remove i586-gnu from supported-systems.
<cow_2001>I imagined it was used to generate the system in the first place?
<nckx>Yeah, I'm looking.
<janneke>should we submit a bug or would cbaines or civodul like to chime in?
<janneke>FAIL: test-name: package-transitive-supported-systems, implicit inputs
<janneke>ah there was a bug https://issues.guix.gnu.org/65755
<geri>hey, im trying to set up bspwm for guix, i made sxhkdrc w/ mixed-text-file, bspwmrc with mixed text + program-file and "startx" the same way, but how do i properly make startx thing available in PATH as a runnable script?
<geri>(also if there's a way to do mixed-text-file and ensure the output has executable bit set i'd be happy to know)
<janneke>ACTION sends mail to the closed bug and sees how that goes
<euouae>Hello
<nckx>As long as it's not archived, it should work.
<nckx>Hello vowelperson.
<euouae>oh please like you're any better
<cow_2001>nckx: Here it is! guix system list-generations
<euouae>I'm reading on guix package <https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html> specifically --export-manifest and --export-channels. The command `guix package --export-manifest` recommends to look at the info from `guix describe` and info guix(Replicating Guix).
<nckx>I'm glad you beat me to it, I'd only just finished downloading the qcow2.
<euouae>But it seems more appropriate to recommend `guix package --export-channels` instead of `guix describe`; moreover, the Replicating Guix section does not mention --export-channels
<nckx>(I always thought there was a Cuirass job for these images, but I didn't find it…)
<geri>nckx: consonant person :D
<euouae>Shouldn't it be the case that the guix tip & info section mentions --export-channels, or even uses it instead of guix describe?
<nckx>Best buds ♪
<nckx>cow_2001: The file name is just a convention, by the way, there is no place in Guix that forces you to use /etc/config.scm.
<cow_2001>nckx: Thank you!
<nckx>ACTION proposes /etc/guix/system.scm and keeping it under git.
<vivien>When I reply to or send a v2 of a patch for a team, should I add the X-Debbugs-Cc: header each time, or does debbugs manages it itself?
<geri>i haven't p much ever touched /etc in guix system
<geri>~/.config/guix/manifests/system.scm ftw
<nckx>That is also a valid life choice.
<reepca>the nice thing about /etc/config.scm is how short it is
<somenickname>Mine is in ~/projects/system/guix-desktop/system.scm which I edit through an Emacs bookmark since the path is just to long
<nckx>It fails even at that, with the extra ig. ‘Conf, I guess?’
<euouae>con.scm for the cons pun?
<somenickname>geri: Do you have a home.scm file as well?
<geri>i actually have them as cli.scm and desktop.scm so it's usable in cli-only environments somenickname
<somenickname>ah
<somenickname>Do you use scm for your configs or do you just copy the whole directory?
<somenickname>for example just using stow instead of mixed-file or something like that
<geri>bspwm/sway i have as a single scheme file, mpv and emacs are uploaded as directories
<geri>emacs for portability, mpv cause was too lazy to rewrite the thing when migrating to guix home :D
<geri>there's also stuff like shell scripts that i upload to store using black magic
<somenickname>me, too.  Wish there would be a default function that copies whole dirs to ~/.config
<geri>i use home-xdg-configuration-files-service-type + local-file #:recursive? t
<somenickname>Can I see your config.  That is way simpler than what I have.
<euouae>Are guix packages signed?
<euouae>I'm a bit confused because there's a discussion about security and bit-by-bit comparisons, and I always thought that stuff is more appropriately dealt with via public-key infrastructure
<nckx>They are.
<euouae>Alright, it's just additional stuff they're remarking on
<geri>somenickname: i dont have a public git repo for it, but here's cli.scm https://0x0.st/HOH1.scm
<nckx>euouae: Signing (public key or other) doesn't address those issues, it just proves the package was built by someone with the private key.
<euouae>nckx: Yes I agree
<euouae>Hmm... I see
<euouae>It's talking about some kind of resilience in the case one server goes rogue
<somenickname>geri: Thanks
<somenickname>is local-file from Guile or Guix?
<savoritiasm>public key signing of packages or source code and reproducible packages are two different things
<somenickname>wish I could just go over the var/func and get manual
<savoritiasm>but both of them relate to security of course
<nckx>They interact in useful ways but they are indeed separate.
<geri>from guix, you can read more in G-expression page in the info page somenickname
<geri>s/info page/info/
<bumble_>geri that is an amazingly small config file
<geri>it's only cli stuff
<geri>desktop is actually 1.5 times larger than that
<euouae>Okay, one more question. I'm on bare-bones.scm, and yet `package install emacs` pulled in some graphical dependencies, like libpng or cairo?
<euouae>I think I also saw fonts being downloaded
<euouae>How come? Is the build not lean enough or is this some dependency even on terminal?
<nckx>Hmm, am I correct that guix-publish doesn't listen on IPv6 by default? I'm surprised.
<geri>im p sure on gentoo it wouldn't pull those
<savoritiasm>really? interesting
<geri>try emacs-no-x-toolkit maybe
<geri>or emacs-no-x
<reepca>packages and their inputs don't automagically change depending on the system guix happens to be running on top of
<euouae>geri, yeah there's definitely --without-png etc on emacs ./configure
<nckx>euouae: Being ‘on’ bare-bones.scm doesn't mean anything in the context of packages. emacs is emacs, anywhere.
<nckx>Maybe ‘emacs-no-x’ is closer to what you want.
<euouae>aha
<nckx>These are not Gentoo profiles or presets or whatever. Across the same Guix version, Guix packages are self-contained (functional, even, one might say) constants, for everyone.
<euouae>Yes I did get confused from gentoo profiles
<nckx>That said, ‘guix size emacs-no-x | grep font-’ still pulls in as many fonts as regular emacs.
<euouae>What does that mean?
<geri>:(
<nckx>This something that could be optimised if someone cares enough to do so.
<euouae>Alright. I'm compiling a list of things I'll report/try to fix so I'll add that one too
<euouae>That one goes to the package maintainer right?
<nckx>euouae: ‘guix size’ shows the closure of the package, that is, all store items that are required to run the package. And all items that need to be present/downloaded/built when installing it.
<nckx>euouae: Yes.
<nckx>But note that this isn't Gentoo; IMO, ‘package x isn't lean enough!’ bug reports are considered low priority to put it delicately.
<nckx>People aren't going to sacrifice free time to reduce perceived bloatez.
<geri>oh btw, can someone drop their config that sets up ovmf for virt-manager
<euouae>nckx: Ah that's true, that is wasted time isn't it
<savoritiasm>what you may be interesting for customized installation of packages is transformations and parametized packages
<euouae>I've become too touchy of extraneous dependencies on this slow connection
<savoritiasm>second one if it ever happens. hasnt been merged yet
<mirai>what can I do about this message?
<mirai>WARNING: (#{ g107}#): imported module (fibers) overrides core binding `sleep'
<geri>i remember debian can be updated completely offline w/ cd drives lol
<euouae>savoritiasm: got it! thanks
<savoritiasm>euouae: https://guix.gnu.org/en/blog/2023/parameterized-packages-for-gnu-guix/
<euouae>ah looks a bit like gentoo
<geri>euouae: what download speed do you usually get
<nckx>euouae: Well, I just meant that, without a patch to go with it, don't hold your breath. Not that the effort wouldn't be appreciated. It *is* unexpected that something called -no-x pulls in fonts.
<euouae>geri ~ 400KBps
<euouae>nckx, oh I will contribute a patch definitely
<euouae>I do know lisp and I've contributed stuff before in other projects
<euouae>I thought you meant /don't bother with a patch/
<euouae>but OK
<geri>euouae: i get between 500 and 1M, i get your pain
<somenickname>geri: I want that as well but never figured out how.  I think it also requires changed to the virt-manager package to support it (some flag or something, not sure anymore)
<nckx>euouae: No, sorry, I was trying to set expectations, not discourage you.
<geri>only reference to ovmf in the whole guix manual is in (info "(guix) Invoking guix system"), but it uses qemu-system instead of libvirt
<nckx>Yeh I use it all the time… with QEMU >:)
<geri>evil...
<geri>i honestly never used anything other than qemu w/ virt-manager, maybe i should learn the original after all...
<nckx>I assume virt-manager is ‘better’ if you have long-lived, more fixed VMs, that you actually want to manage as entities/profiles etc. I don't.
<geri>i watch anime in vm's B)
<somenickname>why
<nckx>So the anime cannot escape into the real world.
<geri>^
<nckx>OK, so after the IPv4-only hitch, guix.t.g is back up on a different host and currently at a dismal 9.8% coverage ☹ That should improve swiftly. OTOH, this host *is* a VPS, so we'll see if it's viable.
<somenickname>which provider?
<nckx>Contabo.
<nckx>ACTION away.
<somenickname>nckx: I am looking for VPS provider for my mail server.  I heard Contabo is really bad as of cheap overprovisioned vms.  What is your experience with it?
<mitchell>Does anyone know why the python documentation isn't packaged?
<mitchell>like make texinfo
<geri>i see a bunch of python-*-documentation packages
<geri>for example for numpy
<mitchell>but what about the core language?
<geri>dont see that, only tk and idle outputs that have no descriptions
<mitchell>it's odd because I can build the docs no problem if I want to download a bunch of texlive packages. just python-sphinx and texinfo additionally required
<mitchell>I don't think it's a licensing thing. Possibly a lack of interest?
<somenickname>wasn't there a guix-offtopic channel?
<civodul>janneke, cbaines: i replied to https://issues.guix.gnu.org/65755; you can push the change or i’ll do it later
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, mirai says: <https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n242> doesn't seem to match with the description of waitpid return value <https://www.gnu.org/software/guile/manual/html_node/Processes.html#index-waitpid>, can you confirm this?
<civodul>mirai: the “integer status” matches http://www.gnu.org/software/libc/manual/html_node/Process-Completion-Status.html#Process-Completion-Status
<civodul>the ‘status:’ procedures are akin to the W* macros in C
<rekado>mitchell: I didn’t know this was available.
<rekado>mitchell: we don’t include it in the python package itself for obvious reasons, but we probably wouldn’t reject a patch to add a separate package for the Python documentation.
<vivien>Is the example desktop.tmpl system usually slow to boot?
<vivien>I have been waiting for 7 minutes now with a "Booting from Hard Disk..." screen
<mirai>civodul: right, it gets extracted out from the pair when spawn-command is used (for example)
<geri>vivien: how are you running it
<mirai>I managed to write this “healthcheck” shepherd service using fibers <https://paste.centos.org/view/6ff247d2>
<geri>i usually get booting from hard drive when running stuff created with guix system image w/ improper mounting setup
<vivien>geri, sudo qemu-system-x86_64 -nic user,model=virtio-net-pci -enable-kvm -m 2048 -device virtio-blk,drive=myhd -drive if=none,file=....qcow2,id=myhd
<mirai>and some shepherd.texi undocumented procedures
<geri>did you enable ovmf?
<mirai>there's an annoying WARNING: (#{ g107}#): imported module (fibers) overrides core binding `sleep' message that I've no idea how to deal with
<nckx>somenickname: There's the boringly-named #guix-offtopic, but mildly ‘off topic’ chatter is tolerated here so long as everyone's cool with it.
<vivien>I don’t know what ovmf is
<klm`>When I `guix build beignet`, it complains about no ICD loader found. Is this working for anybody else?
<geri>like here (info "(guix) Invoking guix system"), if you use emacs
<geri>it's the thing needed to launch stuff with UEFI in virtual machines
<nckx>somenickname: Yeah, they are very budget.
<geri>otherwise only bios and desktop.tmpl sets efi bootloader, so i guess thats why it cant boot
<nckx>somenickname: They fill a niche but it's not for most folks.
<nckx>(Re: Contabo.)
<nckx>klm`: It shouldn't work for anyone else :) It fails for me, as it should.
<nckx>ACTION 's never heard of ICD…
<vivien>geri, now I have a logo for TianoCore
<somenickname>ncikx: Ah forgot the "#".  Why is that even a thing for every channel.  Never understood it.
<vivien>Oh now I have "UEFI Interactive Shell v2.1"
<Noisytoot>Contabo don't allow running IRC servers (but apparently you can ask them for an exception)
<nckx>somenickname: It's a type prefix, but #-type channels are the only ones in common use nowadays.
<vivien>I have a list of things under "Mapping table"
<vivien>And then a "Shell>" prompt
<vivien>What should I write here?
<civodul>mirai: you could use (web client) instead of curl while you’re at it :-)
<nckx>somenickname: Furthermore, some commands ‘operate’ on either a user or a channel, and how would you differentiate between channels and users otherwise.
<klm`>nckx: ok, so it's the same for everyone else at least. So, nobody is maintaining Intel's beignet? I suppose OpenCL is slowly dying …
<somenickname>nckx: Type as of "@" + for users?
<nckx>Similar yes.
<somenickname>Ah I understand
<nckx>Although, eh, different. @ are more ephemeral badges of dishonour.
<somenickname>yeah but basically to understand #guix is a channel and not some user with privileges?
<nckx>But exactly: other ‘modern’ platforms require an explicit ‘@’ prefix for users, so ‘#’ is just the same thing in the other direction.
<mirai>civodul: via a #$(program-file …) right? Originally I started with (web client) but it doesn't know about timeouts, http-head would simply hang the program if something was amiss
<janneke>civodul cbaines: will do, thanks!
<nckx>somenickname: Yes, because # is not ever a valid user ‘prefix’.
<nckx>It always denotes ‘yo this be a channel name’.
<janneke>and thanks for the fix, civodul
<andreas-e>klm`: I just went to the git of beignet, which was "archived" in January. So it looks as if even Intel is not maintaining its own software...
<janneke>jpoiret: headsup, i'll also rebase and reset hurd-team after
<mitchell>rekado: I am in the process of sending an email to guix-patches as we type
<andreas-e>Does this mean we should drop it from the distribution?
<somenickname>nckx:  Thanks for the heads up.  Now I am aware of that as well.  I really like IRC.  It is simple and does the job.  Only thing I wish would be multiline text and maybe support for code.
<Noisytoot>@ is already used in IRC as a prefix for ops
<nckx>Of course, there are also the #$ (gexp-channel) and #~ (ungexp-channel) operators.
<geri>vivien: i managed to launch my own guix image by removing all mapped-devices and just making it as simple as possible
<geri>only /boot/efi and /, using labels for devices
<nckx>ACTION corrects typo whilst nobody's looking.
<klm`>andreas-e: Yes, I think you're right. It's ashame, OpenCL is nice. I guess they're all moving on to Vulkan now. Which is massively complex and which I also cannot get to work on my machine.
<vivien>You mean, in the operating system definition or the qemu command-line?
<geri>(info "(guix) Instantiate an Image") may or may not helm, i haven't checked yet
<geri>in the os definition vivien
<geri>rip
<vivien>I alt-f4ed the wrong window
<geri>:D
<geri>happens all the time
<geri>that said, does anyone have any experience launching personal guix images w/ encrypted filesystem?
<nckx>Noisytoot: That's the dishonour to which I was referring.
<nckx>I can't find ocl_icd.h anywhere.
<civodul>we have a big big problem my friends: commit e6dc1d399663b9fab30ded8bcb716a5b1dbf8743 changed the ‘match-record’ indentation
<nckx>fatal: repository 'https://www.khronos.org/registry/OpenCL/' not found — yeah, this smells like a well-maintained ‘ecosystem’ ☹
<cow_2001>I was thrown into bournish saying that /dev/vda1 was somehow corrupt and that I should run e2fsck with some different e2fsck -b ? Did a guix system reconfigure using this: https://0x0.st/HOHh.scm
<cow_2001>Booted with the last configuration
<mitchell>/dev/vda1 is for virtual machines no?
<cow_2001>I guess so, yes.
<mitchell>so you should use /dev/sdXN
<cow_2001>I am using qcow2
<mitchell>oh
<cow_2001>1.4.0, trying to upgrade
<nckx>I knew I shouldn't have deleted that .qcow2…
<cow_2001>This is the first version, the one that came with the qcow2: https://0x0.st/o7m1.scm
<cow_2001>Found it using guix system list-generations
<vivien>lilyp, what do you mean, "pcre to pcre-2 goes unnoticed :("? editorconfig-core-c uses pcre2, is that bad?
<lilyp>I mean that you forgot to mention that change in the ChangeLog
<geri>mitchell: or nvmewhatever, hdX if hard drive
<klm`>nckx: Neither can I, ocl_icd.h is gone. Maybe used in an older version of opencl-headers perhaps?
<geri>cow_2001: try using labels instead of vda maybe
<nckx>I don't know, and I don't know how <https://github.com/OCL-dev/ocl-icd> fits into this.
<geri>that said this image might be dead
<geri>nckx: which .qcow2
<nckx>It doesn't ship an ocd_icd.h but it seems to generate one in a Ruby script(!).
<nckx>geri: The one that cow_2001 is fighting.
<andreas-e>klm`: It explains why it does not build. I have added a configure flag and pushed it like this.
<nckx>I downloaded it earlier, then deleted it, then downloaded it again, then made the same mistake I won't make again today.
<geri>ah xd
<andreas-e>That said, beignet now builds, but might not work; could you give it a try?
<andreas-e>If it does not work, we may have to package the missing bits.
<janneke>civodul: whenever i customarily hit paredit's M-q after editing something guix, most everytime i see indentation and comments make a small indentation "dance" so...
<vivien>lilyp, oh, silly me, it’s a wrong fixup!
<janneke>maybe the use of guix style is slowly fixing that?
<andreas-e>klm`, nckx: I found this project: https://github.com/OCL-dev/ocl-icd
<nckx>Didn't I link to that?
<janneke>ACTION would have hoped/thought emacs was in wider use tho
<nckx>Anyway, I'm packaging it to see if it fixes beignet, but ugh, if it tries to make me learn Ruby…
<klm`>andreas-e: wow that was fast :-) I see you disabled the ICD loader, I think you generally want that. The ICD will let you have multiple OpenCL drivers installed on the system, and choosing one at runtime. It's building now with your patch - I'll see if I can get beignet OpenCL running with it just to see.
<andreas-e>Well, this was the easiest way forward. Otherwise it looks like we need an additional input, which is not yet packaged.
<nckx>Adding ocl-icd as an input to beignet seems to fix the build.
<nckx>klm`: ☝
<klm`>wow you guys are really good at this … From OCL-dev/ocl-icd's README I didn't even think it was related.
<lilyp>janneke: I'm using emacs, but no paredit, so no dance to notice
<lilyp>ACTION → zzz
<nckx>klm`: Yeah, it doesn't even contain the file we're looking for—it's generated at build time: https://github.com/OCL-dev/ocl-icd/blob/master/icd_generator.rb#L488
<nckx>Nutso.
<nckx>OK, it built successfully but I have no idea what Beignet or OpenCL are and what now.
<nckx>I stumbled upon the GitHub purely by chance.
<civodul>janneke: M-q reveals all the discrepancies between “the rule” and reality
<civodul>and sometimes between Emacs and ‘guix style’ too
<cow_2001>Looked up fdisk -l /dev/vda and realised it has vda1 for EFI(Don't know what's that all about?) stuff and vda2 for / stuff. Changed vda1 to vda2 in the config.scm. Now it works.
<civodul>it’s a mess :-)
<nckx>cow_2001: What what's all about?
<klm`>nckx: I can try it if you give me a patch. Otherwise, you can try running `env OCL_ICD_ENABLE_TRACE=true clinfo`
<cow_2001>nckx: It tried to look up / in /dev/vda1 instead of /dev/vda2.
<nckx>klm`: I'm just going to push it to master, it's an improvement on the current ’doesn't build’ status quo. That's easier to test anyway.
<janneke>civodul: sure, but/and i've learnt not to change indentation gratuitously, esp when making a smallish change
<nckx>cow_2001: Sure. I thought your question was more about the existence/usage of an ESP.
<klm`>nckx: ok, thanks a lot! thanks andreas-e too for looking into this. much appreciated!
<civodul>janneke: it Would Be Nice if we could assume that M-q isn’t going to change everything
<janneke>yeah
<cow_2001>Extra Sensory Perception?
<janneke>someone will prolly find some neat solution to this when the time is ripe for it
<cow_2001>Oh, especially.
<civodul>someone will throw machine learning at it
<cow_2001>No, my brain is too tired for coherent conversation. I need sleep.
<geri>good night?
<nckx>cow_2001: EFI System Partition.
<nckx>Your vda1.
<cow_2001>Yes, good night is where I should end it for now. Good night and thank you!
<geri>night-night)
<klm`>I'm off to sleep too. nckx looking forward to try your patch. Thanks for your help!
<nckx>I was just about to push it :)
<geri>i switched to bspwm and ibus-daemon still gives me a "keymap changes do not work on plasma wayland" message lol
<nckx>Done.
<nckx>Wait, whut. There's another ‘fix build’ commit. How could anyone have out-typed me adding ocl-icd…?
<nckx>OK, they didn't, but… andreas-e: I went ahead and reverted your work-around.
<geri>ill go reboot ig... also sleep soon, so have fun everyone
<nckx>I think it was a bit premature.
<nckx>klm`: https://paste.debian.net/plainh/c592110d 🤷
<somenickname>nckx: Someone questioned if Guix packages are signed and you answered yes.  I don't understand.  You mean as if the Git commits?
<nckx>somenickname: The git commits are signed but not what I meant.
<andreas-e>nckx: Well, sure, since you added ocl-icd, we can use it.
<ryan77627>Hey, very simple question that I am probably just missing the correct page for. If I trust a substitute server using `guix archive --authorize < signing_key.pub`, how would one undo that? Does it go away on reboot? Does it disappear when I rebuild since it isn't in my system config.scm?
<nckx>somenickname: And true, packages aren't really signable objects, but the substitutes (binary builds of packages and other things) are signed, and equivalent to ‘packages’ in other parlance.
<andreas-e>nckz: Or does your pasted message mean we cannot use it actually? Well, let klm` try it out.
<nckx>ryan77627: If you use authorized-keys, then it will be overwritten on reconfigure (maybe also reboot; not sure).
<nckx>Otherwise, remove it manually from /etc/guix/acl. I recommend using an editor that matches brackets. :)
<ryan77627>nckx: Perfect, thank you!
<somenickname>nckx: How does this work with the substitutes signing it?  Is that the reason for the pub key in the channels?
<nckx>andreas-e: Right, but I'd already linked to ocl-icd when you removed support for it. Anyway, no biggie, and yes, I'm not sure if it was for nought or… not.
<nckx>Does this require specific hardware?
<nckx>I'm hoping it doesn't require proprietary software, which that error message implies.
<nckx>somenickname: The channel key is for GPG commit signature verification. Substitutes are verified using /etc/guix/acl (coincidentally what ryan77627 mentioned above), preloaded with the default keys at https://git.savannah.gnu.org/cgit/guix.git/tree/etc/substitutes
<mooncake>"substitutes\etc - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/etc/substitutes
<nckx>They are signed by ‘guix publish’ on the substitute server.
<nckx>There is no relation between commit and substitute signing.
<mitchell>I sent a patch for adding python documentation https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66018
<mooncake>"#66018 - Add python-documentation - GNU bug report logs" https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66018
<nckx>Thanks!
<somenickname>what is the purpose if git commit signature and for substitutes?
<somenickname>s/if/of
<nckx>Commit signing: did a person trusted by the project (=another, older committer, and Savannah) push all these commits to the new guix I'm pulling; substitute signing: was this binary blob built on a machine that controls a secret key I have previously trusted (or the project defaults I accepted when first installing).
<mitchell>somenickname: https://www.cisa.gov/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF for all the gory details
<nckx>Mapping higher-level meaning onto that is more personal. Does it mean ‘is this software trustworthy?’ Maybe, in certain dimensions, and those dimensions will differ per human polled.
<mitchell>whoops https://arxiv.org/pdf/2206.14606.pdf meant to share this link
<somenickname>mitchell: Why do they always need so many pages
<mitchell>too many software supply chain interest
<nckx>somenickname: Because you have so many questions :)
<nckx>(Which is fine.)
<mitchell>I agree that first link in a bunch of government nonsense but it is interesting to see what they are thinking about
<somenickname>nckx: Yeah because I am hungry of knowledge and want to know how everything works which helps to better understand overall the whole project/world.  Sadly, we can't download the knowledge of other persons to accelerate development (yet) (but maybe this is a good thing, or not)
<nckx>Speaking of government if not nonsense, I'm surprised oriansj hasn't piped up yet. Must be asleep or in a holding cell.
<nckx>somenickname: Yeah… that technology would be abused instantly.
<somenickname>mitchell: Thanks for the link.  I will read it in the future
<somenickname>nckx: Speaking of questions, they require answers.  I appreciate that you answer my questions which for other people may sound dumb.  But it shows how much people care about something.
<nckx>I do not think they sound dumb at all.
<nckx>I'd only s/require/politely invite/ 😉
<somenickname>Sometimes I think myself they are stupid over time I understand the whole machinery :D
<nckx>I'm going to do some stuff politely inviting constant reboots, so bye for now.
<somenickname>bye
<lrustand>Hi, I'm having trouble booting Guix on my laptop. I get "waiting for partition <uuid> to show up" directly after grub. Also in the rescue shell I try to list /dev and see that my nvme is not showing up. But obviously grub was able to access it and load the initrd and kernel
<lrustand>I've used the same config.scm on a different machine and it worked there
<lrustand>Difference is that on the other machine I used the installer to do the initial install, but on the laptop I just use "guix system init" from a foreign distro
<mitchell>You likely have a different UUID on this machine
<lrustand>I have changed the uuid
<somenickname>Okay, so blkid returns what Guix wants?
<lrustand>Yes. I also tried using /dev/nvme1n1p4 and ussing filesystem label, and none of them work
<mitchell>i always use lsblk --fs
<lrustand>mitchell: nice
<lrustand>learned something new
<somenickname>mitchell: That is acutllay better, nice.
<mitchell>lsblk has a lot of options. its very nice to preprocess input into awk and friends
<lrustand>But when I am in bournish rescue shell, I don't see my nvme under /dev. That is probably why guix can't find it
<lrustand>But I can't understand why it wouldn't be able to see it
<lrustand>I even added the-channel-which-shall-not-be-named, just in case it needed some kind of firmware, but alas
<mitchell>My first guess would be you need some kernel config option enabled which isn't in the default defconfig
<mitchell>have you ever run guix on this machine?
<lrustand>nope
<mitchell>linux in general?
<lrustand>But I have ran a lot of other distros without needing anything special
<lrustand>I'm on arch right now
<mitchell>if you tried the linux kernel from that other place and it still didn't work that is very odd
<lrustand>Yes, both kernel and firmware
<somenickname>how about booting trisquel to see if it is an issue with the libre kernel?
<somenickname>I mean just a quick boot from USB to see if this works out without any problems just to be sure
<lrustand>Yeah, I could try
<lrustand>But it did happen with the non-free kernel also
<somenickname>non free Guix or other distro?
<mitchell>yea i'm trying to think what could be different between guix and arch in this case
<mitchell>the only other thing that comes to mind is grub
<mitchell>does grub need to do anything to prepare nvme for the kernel? I wouldn't think so
<lrustand>mitchell: I'm actually using grub from arch. I just added a new entry for my guix partition
<mitchell>oh
<somenickname>ah
<lrustand>copy-pasted the entry that guix generated
<mitchell>ah
<mitchell>Grub passes kernel arguments
<mitchell>to the initrd
<mitchell>to tell it which generation to boot
<mitchell>are you doing that as well?
<lrustand>I copied the whole entry from guix, including the kernel parameters
<mitchell>I guess you did make it to the shell
<lrustand>Here is the grub entry: https://0x0.st/HOXj.txt
<somenickname>This is too advanced for me,  Can't help any further.
<mitchell>So you have 1 hard drive with 3-ish partitions? grub, arch, and guix
<lrustand>more or less
<lrustand>I have also swap and another not in use partition
<mitchell>I don't know where I was going with this line of questioning
<mitchell>it shouldn't matter to the kernel's ability to recognize devices
<mitchell>can you read the outputs of /proc/dmesg and see if nvme is ever mentioned?
<mitchell>not /proc/dmesg ... what is the file dmesg reads?
<mitchell>kmsg
<lrustand>Can't I just use the output from dmesg?
<mitchell>can you run dmesg?
<mitchell>i wasn't sure if you had it
<lrustand>Oh, you mean in the rescue shell
<mitchell>yea
<lrustand>okay, brb rebooting
<lrustand>There was too much output to fit in one screen, and no grep, less, head or anything like that to limit the ouput
<mitchell>nothing except scheme ;)