IRC channel logs

<User-31>Why is it that "guix weather ungoogled-chromium" reports 100% availability (1 of 1) but when I run "guix shell ungoogled-chromium" it tries to build it? (which took over 5hrs and I cancelled)

<winter>User-31: have you guix pulled some time in the last 8 hours per chance?

<winter>there was a bug until 8 hours ago that causes different derivations to be built with guix shell, see #61841

<fresas-con-nata>"‘guix shell’ computes different package derivation than ‘guix build’" https://issues.guix.gnu.org/61841

<winter>if you guix pull now, guix weather and guix shell should line up

<User-31>No, but I did yesterday (maybe 24hrs ago at this point). But maybe I'll try pulling anyway and see if that fixes it.

<civodul>yeah, it was fixed 5-10h ago

<winter>yup, (8 hours, I checked the log :)

<winter>nasty bug tbh, glad you added tests for it

<User-31>winter: That fixed it, thanks

<winter>glad to hear it

<gnucode>hey guix!

<lechner>gnucode / hi

<lechner>Hi, has anyone found a way to share one networked store among several thin clients?

<winter>NFS? Syncthing, if you don't need instantaneous changes? Hell, Ceph?

<winter>Ceph is probably... overkill

<lechner>winter / i'm more concerned about profile tracking and multiple daemons working the store. Does the daemon offer a socket connection?

<winter>Ah, *store*. I misread, apologies lechner.

<winter>Thought you just wanted a general networked FS.

<n8r>I'm so ecstatic, I got my guix system running, and nginx is working! Sorta...

<n8r>If I hit my domain, I get 403 forbidden, reading the `/etc/var/log/error.log` I have a handful of these errors:

<n8r>`2023/02/27 17:25:35 [error] 905#0: *1 "<foo path>/public/index.html" is forbidden (13: Permission denied), client: 192.168.xxx.22, server: www.domain.com, request: "GET / HTTP/1.1", host: "192.168.xxx.25"`

<n8r>My first thought is the nginx or herd needs to be given access to the `public` directory?

<winter>n8r: Do the permissions look sane right now? As in, does the user NGINX is running as have access to <foo path>?

<winter>I'd check that first :)

<winter>(So yes, you'd be correct that you should double check that.)

<n8r>got it! Had to put my website files in a directory owned by the nginx user, thanks for the help winter!

<platoxia>I understand the difference between running 'sudo guix system reconfigure' and s

<platoxia>...'sudo -i guix system reconfigure'

<platoxia>but what is the difference between running 'sudo guix system reconfigure' and just 'guix system reconfigure'

<platoxia>in normal disto's trying to run 'guix system reconfigure' would throw an error telling you to run it using sudo, but 'guix system reconfigure' actually reconfigures the system...so why use 'sudo guix system reconfigure' at all.

<platoxia>to clarify, I mean running a command *like* 'sudo guix system reconfigure', not that command specifically

<platoxia>I just ran 'guix system reconfigure' without 'sudo' and it went through all the steps to reconfigure the system then threw an error: "symlink: Permission denied: "/var/guix/profiles/system-18-link.new"".

<platoxia>Why not prevent running 'guix system reconfigure' without sudo?

<apoorv569[m]>lechner: Interesting. What is this command `guix shell -f guix.scm -- guix-helper-bot --nick=hot-potato --channel='#guix'`?

<apoorv569[m]>I don't see the --guix-helper-bot and --nick flag in the help page.

<apoorv569[m]>So you basically have to use -D flag to make it rebuild?

<apoorv569[m]>there is a --rebuild-cache flag maybe that also works?

<cnx>hello guix

<cnx>can anyone else confirms that time-machine is no longer working on master guix?

<winter>find:fwiw, might be best to eventually file an issue if nobody can confirm, so it can be tracked and/or confirmed as not a bug

<winter>*cnx

<cnx>yea i guess so

<lain_>graphviz's dot program is almost prohibitively slow to generate dependency graphs for guix

<lain_>is there currently any more efficient way to display dependency graphs?

<lilyp>you could try other algorithms like fdp or perhaps stuff it into igraph which IIRC has a graphviz parser

<lain_>lilyp thanks, I'm looking into them. Igraph supports writing to graphviz dot files, but not reading to them. In addition, fdp and sfdp both execute very quickly, but their (at least default) layouts are unreadable for large graphs (guix graph -t bag-with-origins guix). fdp and sfdp appear to be just as slow as dot if the -Kdot option is passed, so I'm guessing it's just an alias for the same command. I'm currently trying circo, but

<lain_> it hasn't finished yet (none of the dot layouts have finished either).

<lain_>Experimenting with dot2tex now. It produces good output (once you change the documentclass to standalone lol), but it still takes a while to generate

<unmatched-paren>hello guix ):

<unmatched-paren>oops, i mean :) of course :)

<Maya[m]12>unmatched-paren: you really unmatched the paren /j

<PurpleSym>Can someone please restart the GHC build on i686? I increased the max silent time, but it does not restart the job automatically. https://ci.guix.gnu.org/build/478772/details

<fresas-con-nata>"Build 478772" https://ci.guix.gnu.org/build/478772/details

<Kabouik>If my PC can't seem to be fast enough to build ungoogled-chromium (I run a guix packge -u yesterday and it's still not over, and I fear I may be putting heat strain on my CPU since this is a compact laptop), is there a way I can tell guix to fetch a pre-built binary from another substitute if it didn't find one in the first place?

<Kabouik>Perhaps I should just try to interrupt the update and run it again, in case a binary is now available in the default substitute

<Kabouik>(Erm, I see that I'm mistakenly using the word substitute, substitutes are actually the binaries and not the servers holding them, sorry.)

<attila_lendvai>Kabouik, what i usually do then is to immediately abort the reconfigure, and retry it the next day or whenever i remember to do it. there's ongoing discussion on creating a staging branch that will solve this issue.

<Kabouik>Thanks attila_lendvai. I think it would be wise to abort then, perhaps there are already substitutes available since I ran the upgrade yesterday, but there's a bit of sunken cost fallacy in my mind too because I'm 79% through.

<Kabouik>By the way, stil not clear to me, should I run a system reconfigure regularly even if I didn't change my config.scm, if some of the related packages have been updated, or will guix package -u be enough?

<jonsger>Kabouik: guix package -u only upgrades the packages in your user profile. With reconfigure you update all the packages and services used in your config.scm

<attila_lendvai>Kabouik, that depends. when you guix pull, then you may receive changes that would build up your system differently. if you want them applied, then you need to reconfigure.

<Kabouik>OK, thank you both.

<Kabouik>No substitute for ungoogle-chromium, I'll wait a little bit more then.

<irfus>Kabouik: `guix weather ungoogled-chromium` shows available substitutes for me. Have you pulled recently?

<Kabouik>Yesterday, but right, I forgot to pull again before trying my second upgrade irfus, thanks

<Kabouik>And guix weather will be useful.

<attila_lendvai>Kabouik, it may happen that your local guix pull state doesn't have substitutes because some pushed commits made the CI "skipped" building some package versions

<Kabouik>I'm pulling again as irfus suggested, this may have been the culprit too. I'll see when it's over.

<Kabouik>Yeah, it's simply downloading chromium now. I don't even use that as my main browser. :<

<lain_>running "guix pull" basically tells guix to check for the latest versions of all packages available. All commands relating to building, install, challenging, etc are based on packages from your most recent pull

<lain_>Kabouik ungoogled chromium is basically just stripped chromium. Chromium is needed to build it. You will not be left with a chromium package, only ungoogled-chromium

<Kabouik>Yes, this was just a stupid brain freeze from me when I tried upgrading again without pulling again.

<Kabouik>I meant ungoogled-chromium, just shortened it, sorry for the confusion

<lain_>oh lol, I was confused because of the ":<" face

<lain_>does anyone know what hardware the substitute servers use?

<nckx>lain_: Head node: AMD EPYC 7451 2 x 24-Core Processors | 192 GiB RAM | 100T storage + about 25 build nodes: AMD EPYC 7551P 32-Core Processor | 128 GiB RAM | ~500 GiB storage. Some nodes might be slightly heterogenous, I don't remember, but only in details.

<lain_>dang

<lain_>which server is that?

<nckx>Good point. Berlin. (ci.).

<lain_>who provides that?

<lain_>the fsf or some company?

<nckx>The MDC in Berlin, where Ricardo works.

<lain_>Thank you for the hardware Ricardo :)

<nckx>Hence why we don't have commercial-grade peering, but it's still a great deal.

<nckx>Indeed! They also offer Guix to their HPC users.

<nckx>the_tubular: Lie?

<lain_>is there a guix package mirror on the gnunet?

<lain_>that seems like it would be a good way to increase traffic to gnunet

<nckx>lain_: Berlin's raw x86 power distracts from the many generous 'smaller' donations though, so https://guix.gnu.org/en/donate/ :-)

<nckx>lain_: Not yet, but pukkamustard has been working on something that will facilitate that. https://issues.guix.gnu.org/52555

<rekado>there are two types of node; the head node is one of the more powerful ones, of which we have five or so.

<fresas-con-nata>"[RFC PATCH 0/3] Decentralized substitute distribution with ERIS" https://issues.guix.gnu.org/52555

<rekado>it’s funny how it all started

<rekado>the MDC had just decommissioned their first HPC cluster.

<rekado>so we had lots of old Sun hardware wasting space in the data centre

<rekado>disposing of hardware is always a very involved process, so I asked if I could use a rackful of servers for my purposes

<lain_> https://www.mdc-berlin.de/

<lain_>this?

<fresas-con-nata>"Max Delbrück Center" https://www.mdc-berlin.de

<rekado>yes

<lain_>Thank you for doing that

<rekado>that’s how the berlin build farm got started. Just a bunch of old Sun nodes.

<lain_>certainly increases the target audience for guix -from those who are willing to compile everything themselves to those who just want a free system

<rekado>by the time the IT budget was to be renegotiated the build farm had already been established enough to warrant replacement with new hardware

<rekado>and that’s how we were able to turn decommissioned hardware into new servers and storage.

<lain_>where did the name "ci" come from?

<nckx>One weird trick.

<rekado>“continuous integration”

<rekado>it’s neither integrating anything, nor is it continuous

<rekado>the name is aspirational

<lain_>I see

<nckx>Well, it runs the system tests, or used to. Those are a pain to run locally.

<lain_>How about bordeaux?

<lain_>Where is that located and what hardware does it have?

<lain_>nckx thanks for the link about ERIS, looks cool

<nckx>It's one of those Free D-16(?) systems.

<nckx>Hosted in... Bordeaux :-) By Igalia (through Andreas E). We're very creative at naming things.

<nckx>ACTION notices the /donate page is incredibly out of date.

<nckx>lain_: However, its nodes are... Hetzner, I believe. I'm a bit fuzzy on that one compared to berlin. Mostly cbaines manages bordeaux now.

<nckx>It's (and he's) also behind qa.

<lain_>quality assurance?

<nckx>Yes.

<lain_>Are most of the people involved in Guix located in Europe?

<nckx>Currently, best known as 'the thing that puts those badges on issues.guix.'

<nckx>Yes.

<lain_>interesting

<nckx>Historically but still so.

<nckx>It's a refreshing change :-)

<lain_>I'm so used to everything being American lol

<lain_>just so long as the talks are still in english >:)

<nckx>Nix also, although it's seen more capture (both corporate & American) since it grew.

<nckx>If you like French and other exotic continental accents, you're in luck.

<lain_>Guix being principled in it's freedom scares off American corporations lol

<lain_>french accents or language? lol

<lain_>french accents or language?

<unmatched-paren>lain_: accent as in method of pronunciation, in the talks, i believe :)

<unmatched-paren>not accent as in grave or acute

<nckx>I meant accents, but there's plenty of French when they think no one's looking.

<lain_>>:)

<nckx>unmatched-paren is here to keep an eye on them.

<unmatched-paren>Them Eurocrats won't get past me.

<lain_>I knew which version of the word he meant

<lain_>what's the difference between the build farm and the substitute servers?

<unmatched-paren>there is no difference

<lain_>there are more servers listed here than included as default substitute servers

<lain_> https://guix.gnu.org/en/donate/

<nckx>Those would sit behind one of the two, berlin or bordeaux.

<nckx>Again, that list needs a refresh.

<lain_>I see

<nckx>For example, sjd donates a POWER9 machine, so did OSUOSL, they are at ci.guix.gnu.org/workers

<lain_>Are the head nodes provided by MDC and the build nodes by others on the list?

<lain_>Or is everything ricardo told me from MDC, and build nodes are in addition to that?

<lain_>also is hydra the nixos build server?

<nckx>The x86 builds nodes are all Ricardo's rack. It's the other arches that are cobbled together and hosted across the world.

<unmatched-paren>lain_: i think hydra is the software nix uses for ci

<lain_>Okay

<unmatched-paren>cuirass is what we use; though i'm pretty sure we used to use hydra before cuirass was a thing

<nckx>Guix used to use it, for a long time (hence the 'hydra-slave's you are probably referring to).

<nckx>Yes.

<lain_>That's what I was referring to lol

<nckx>Hydra was written in Perl, like much of Nix, and bitrotting.

<unmatched-paren>ACTION shudders

<lain_>I read this article about building substitutes compatible with GNU/Hurd on your host Guix system

<lain_> https://guix.gnu.org/eo/blog/2020/childhurds-and-substitutes/

<lain_>Is something similar to this used by the build servers, or is MDC exclusively for x86?

<unmatched-paren>hurd does run on x86 (32-bit though)

<lain_>you're right, I read "cross compile" and went straight to architecture

<unmatched-paren> https://bordeaux.guix.gnu.org/ <- "i586-gnu substitutes are a work in progress"

<fresas-con-nata>"bordeaux.guix.gnu.org" https://bordeaux.guix.gnu.org

<nckx>ACTION takes a break from touchscreen typing, finds it tiring o/

<lain_>touchscreen?

<lain_>why not a keyboard?

<unmatched-paren>(i586-gnu is hurd on 32-bit x86, of course)

<lain_>unmatched-paren ah yes, the canonical triplet :)

<lain_>on an unrelated note, I think it would be helpful to include somewhere in the documentation that you can just disable all GPU drivers in GRUB settings if you have issues

<lain_>I have a 2022 laptop, and the usb installer wouldn't even boot unless I did this

<lain_>amdgpu is disabled by default, just added nouveau and radeon and everything worked

<lain_>I actually still have them all disabled lol

<nckx>lain_: All of my Guix System laptops have touchscreens, but that was not a Guix System laptop, and I'm glad to be home on one now.

<nckx>Maya[m]12: Thanks for prodding me to try magit again (again). I'm finding it tolerable and still haven't given up yet.

<lain_>what was it then? a pinephone or something similar?

<nckx>Galaxy S3.

<nckx>Literally a worse touchscreen than my ThinkPad.

<nckx>(From the same year, so no excuse.)

<rekado>some of the x86_64 nodes at the MDC are also building Hurd substitutes

<rekado>(or they used to)

<gabber>i've created a patch where i add a multitude of options to a service. can someone point me to a commit where something similar was done so i have a template for my commit message? TIA!

<lain_>running replicant?

<Maya[m]12>@nckx i have been using magit for a long time and i find it so tolerable i dont think ill ever learn git propper

<lain_>the cult of emacs lol

<nckx>A lot of people confuse ‘git proper’ or ‘knowing git good’ with ‘knowing the git CLI good’, and the CLI is generally acknowledged to be poor.

<mfg[m]>i used to use emacs for everything, until i tried neovim with lsp and tree-sitter support...

<mfg[m]>now i only use emacs to use magit and mu4e...

<lain_>I have no idea how to use emacs

<unmatched-paren>emacs is terrible with no configuration, but i find it better than neovim when evil is installed

<mfg[m]>since using neovim i also had to install evil, it's just impossible to get around otherwise :|

<Maya[m]12>I love the default emacs keybinds to be fair, especially since vim ones are useless on dvorak

<unmatched-paren>i would personally prefer it if my terminal, editor, and git ui were all in separate apps, but the emacs versions are just too good :)

<unmatched-paren>Maya[m]12: i use dvorak with vim keybindings -.o.-

<Maya[m]12>i find moving with hjkl on there not very pleasant

<nckx>The ‘emacs is only usable/pleasant if you configure it’ myth was harmful to me and kept me from giving it a chance for years. It's a great editor out of the box, and my (<500 line) .emacs is mostly mail client set-up and other QoL stuff (like skipping copyright headers :). The defaults are fine. Especially if you compare it to vim.

<nckx>There, I think we got all the Opinions in a raw now.

<nckx>*row

<lain_>my perspective is simply that I don't see what benefit learning how to use emacs would give me

<lain_>or how it would be better than just using vim and whatever other programs it replaces

<unmatched-paren>magit is the best git client, hands-down

<nckx>It might not be, for you.

<nckx>Eh, applies to both but was meant for lain_.

<unmatched-paren>i don't actually remember why i switched; i did it a few times, quickly going back to nvim, until i finally did find a configuration i liked

<unmatched-paren>i think it may have been a desire to use lisp for configuration

<unmatched-paren>though emacs lisp isn't nearly as sleek as scheme, nor are emacs's apis nearly as pleasant as guile's and guix's

<gabber>i went down that rabbit-hole a couple of years ago and let me tell you, it's one of the more addictive softwares out there. just thinking about having to edit files remotely in an unconfigured "vi" or nano or whatever-editor-there-might-be-installed makes me shiver in disgust. i'm happy i don't have to think about a future without my precious little malleable editor called GNU Emacs

<nckx>Since Guix was my first-ever intro to Scheme, and to Lisp on a computer screen, it took emacs to make me realise that Guix's good style was a choice.

<mfg[m]>gabber: true, TRAMP is absolutely amazing :)

<gabber>TRAMP, magit, debbugs, configure-the-darn-thing-at-cursor-point-without-lifting-my-fingers-even-once-from-the-homerow -- i might have wandered off to some less daunting profession were it not for projects like Emacs (and Guix, of course) that still give me hope that i might get a hold of my

<gabber> computing :)

<cbaines>nckx, none of the bordeaux builds happen on hetzner, although data.guix.gnu.org currently is hosted there

<cbaines>milano-guix-1 (in Milan) and bayfront and harbourfront (both in Bordeaux) are the build machines for x86_64-linux and i686-linux

<nckx>Impressive that it keeps up.

<nckx>Is harbourfront up again?

<cbaines>indeed, although that was the idea (be more efficient/performant, not necessarily do more with less hardware)

<cbaines>nckx, and yes, harbourfront is up now, it probably wasn't actually down/inaccessible, I think it was just very slow

<cbaines>I've just noticed the machine doesn't have swap, which is probably bad

<bjc>ime swap makes things worse for most things, at least on spinning rust

<bjc>i have not tried it on nvme/optane. napkin math says its probably ok there

<nckx>It improves other things, even on spinning drives.

<nckx>cbaines: IC. That's good, or better than the alternative anyway.

<nckx>bjc: Does NVME change the bottom line for things like zswap/zram?

<bjc>it might be ok on a build farm, i'm not sure. my servers have always been geared around interactive use, where swap is an absolute bane

<nckx>Sure.

<bjc>i assume compressing swap is beneficial. nvme is pretty fast, but uncompressing is also very fast with the right algorithm, and the reduction in iops is probably worth it

<bjc>this would definitely fall under "measure it under your load" for me, though

<nckx>If you're not too concerned with the latency of ‘interactive’ tasks, (real) swap really isn't the obselete relic it's painted as, even on modern machines. But it's very complex to model.

<nckx>Agreed.

<bjc>i mean, i stopped using swap in the late 90s, so the "relic" description seems apt to me ;)

<gabber>i've created my first patch for a service: https://termbin.com/wyewb does the message look ok? did i miss anything? there's no `lint` or `style` commands for services, right?

<nckx>You can save a byte: (dnsmasq-configuration) (dnsmasq-shepherd-service) → (dnsmasq-configuration, dnsmasq-shepherd-service) ! LGTM.

<nckx>As long as the texi validates (by building), and make as-derivation compiles your code, I think you're good.

<gabber>i compiled the texi (and had a look at it) and ran the service in a vm, this all works :)

<nckx>Even for packages I don't recommend blanket ‘guix style’ runs.

<nckx>Great!

<gabber>thanks for looking, will save the byte and send in the patch

<civodul>ACTION recommends blanket 'guix style' runs :-)

<gabber>may i (once again) ask for a merge (or at least more feedback) of #60732? it would be great to have it merged since i'm trying to lure more people on Guix's reproducibility train - and not needing them to configure extra channels before getting to work is a big plus

<fresas-con-nata>"[PATCH] gnu: Add package python-scapy" https://issues.guix.gnu.org/60732

<nckx>civodul: Yes, to force people to fix it. >:)

<nckx>gabber: Did you CC the ‘python’ team?

<nckx>I.e. ‘etc/teams.scm list-members python’.

<nckx>Don't use the ‘cc’ option, it's not fit for purpose in its current state.

<gabber>no, i didn't. should i "bump" the thread with a (mostly) blank email with them in CC?

<nckx>Yes, but with some context in case it doesn't show up in a thread for whatever reason.

<gabber>thanks, i will

<civodul>nckx: yup! muuuahaha

<civodul>i'm usually happy with the output actually

<nckx>I do object to mixing meaningful + ‘guix style’ changes in one commit, but probably so do you.

<lechner>ACTION provisions swap the size of 2 x RAM on all equipment

<zimoun>hi!

<zimoun>How could I tweak my /etc/hosts or something else for only accessing to softwareheritage.org? I would like to test the coverage, for real. :-)

<zimoun>Then add disarchive.guix.gnu.org or something like that.

<gabber>is your host behind some other firewall? maybe disallow all traffic (except for the host in question) there?

<nckx>zimoun: You can't use wildcards in /etc/hosts, so your best bet (that I can think of) is a local DNS resolver like dnsmasq that only answers that one query.

<nckx>Or… disable DNS resolution entirely and only add s.o to /etc/hosts, that could work.

<nckx>Yeah, do that.

<zimoun>disable DNS resolution and only add one, right?

<nckx>ACTION waits.

<civodul>ouch

<zimoun>civodul, ouch for me?

<nckx>zimoun: Do you have joins/parts hidden? :)

<nckx>All of Matrix just pinged off.

<nckx>zimoun: Yes. Keep localhost, too, or things will mysteriously break.

<civodul>maybe a bit more than Matrix no?

<nckx>Maybe.

<nckx>The non-[m] nicks I checked were all Matrix 🤷

<civodul>oh it's possible to be on Matrix yet have a non-[m] nick?

<nckx>Yes.

<civodul>incredible

<civodul>has anyone tried to run Gource on the Guix repo?

<lechner>Hi, I found a new uid on my computer. What's guixbuilder01, please? (in group guixbuild)

<gabber>lechner: a user who is allowed to build stuff through the deamon (i think)

<nckx>See ‘Build Environment Setup’, but it's not new.

<nckx>lechner: ☝

<lechner>isn't everything in the store supposed to be owned by root?

<nckx>Owned, yes.

<nckx>Built, no.

<nckx>lechner: Why did your bot ping off with Matrix?

<lechner>#5555

<nckx>Trust me.

<lechner>no idea. maybe he made new friends. some folks like sweets

<lechner>so what's this, please? http://paste.debian.net/1272426

<gabber>lechner: looks like a bug?

<zimoun>nckx: thanks. I do not know what “joins/parts hidden” means, anyway.

<nckx>Is that path valid? Looks like an interrupted build.

<nckx>If it's not registered in the database, it's considered garbage to be collected, and not harmful.

<nckx>If it is… uhm.

<lechner>it's valid http://paste.debian.net/1272428

<nckx>Well, then: uhm.

<zimoun>civodul: gource is fun on Guix :-)

<nckx>zimoun: Most clients announce it when a user joins or quits the channel. If you didn't see a long stream of ‘<nick> has quit’ above, you have them hidden :)

<nckx>lechner: ‘Valid’ != ‘I can ls it’.

<zimoun>ah yes, I have that hidden. :-)

<nckx>lechner: Can you ‘guix gc --references’ it?

<civodul>zimoun: ah, i should give it a try, those videos are always hypnotic

<nckx>ACTION looks up Gource.

<lechner>#5555

<snickerdoodle>"23.1.92; mail-archive-file-name not working" https://issues.guix.gnu.org/5555

<nckx>That's… a lot of bloom.

<lechner>the bot showed now sign of impairment in its controlling terminal

<gabber>sooo with Gource we can just watch you folks work Guix with nice techno music?

<nckx>snickerdoodle: disarchive.guix.gnu.org

<nckx>That was the only link-like thing anyone posted before it quit, so I suspect it choked on the quit flood.

<nckx>Or it was a coincidence.

<lechner>it works slowly, in part thanks to irregex

<nckx>zimoun: Does it take ages to render?

<lechner>nckx / nvm, thanks for explaining guix gc: error: path `/gnu/store/wkn1frkhfdxwrz949yrjqp2xlwr83ff3-guile-syrup-0.0-0.89c7a1d-checkout' is not valid

<lechner>also for the bot to choke you have to give a full URI https://disarchive.guix.gnu.org

<lechner>#5555

<snickerdoodle>"23.1.92; mail-archive-file-name not working" https://issues.guix.gnu.org/5555

<nckx>OK, so it was an interrupted build (the /gnu/store/$output is created build-user-writable, so it can install the package there, then chowned to root and registered in the DB). As far as Guix is concerned that directory doesn't exist, it's just trash, and will be removed if needed or GC'd.

<zimoun>nckx: no, on my machine it is fast – it takes seconds to read the log and then it’s ok.

<nckx>lechner: I expected that, I was just looking at the history.

<nckx>zimoun: Oh!

<lechner>now, if any guile cracks here are willing to help, i have not been able to get the pertinent info out of the exceptions in an elegant way https://does.not.exist

<zimoun>I did “gource -a 0.5 -s 1 .“

<nckx>ACTION does “gource -a 0.5 -s 1 .“.

<nckx>lechner: Was that supposed to splat a backtrace?

<nckx>zimoun: I am duly hypnotised, thanks.

<nckx>A little Ludo' is flying about doing a lot of work.

<lechner>nckx / not, but a poorly formatted Guile exception

<nckx>I guess the breaking broke.

<lechner>i ran a development version, which did not do anything

<lechner>now, if any guile cracks here are willing to help, i have not been able to get the pertinent info out of the exceptions in an elegant way https://does.not.exist

<snickerdoodle>Exception: #<&compound-exception components: (#<&external-error> #<&irritants irritants: (-2)> #<&exception-with-kind-and-args kind: getaddrinfo-error args: (-2)>)> https://does.not.exist

<zimoun>nckx: what is fun is if you move the cursor, bottom, then it restarts from fresh and after one or two minutes, the graph-tree is again full, or almost. :-)

<lechner>that -2 error is also not being translated via perror

<nckx>lechner: Did you look at exception-args (and exception-kind)? I think exception-kind is actually enough info here. Actually, personally, I don't think errors should be printed to the channel at all.

<nckx>If you insist, getaddrinfo-error, tls-error, … should say enough.

<nckx>zimoun: Thanks for that hint, I didn't know there was a draggable timeline hidden.

<nckx>It goes from one busy bee to a buzzing hive in a heartbeat.

<nckx>lechner: -2 is ENOENT, why would perror not handle that?

<nckx>-ENOENT, to be pedantic.

<nckx>lechner: strerror works for me.

<tux_life>Hi! Thank you for your help.... The install and upgrade succeded! :] I have a question: I would like to see which services are available, but the command "sudo guix system search cups" gives me an error: https://paste.debian.net/1272432/

<nckx>Don't forget to -.

<snickerdoodle>"debian Pastezone" https://paste.debian.net/1272432

<nckx>tux_life: Aside, does it work without sudo? Not needed here.

<nckx>I mean, it works fine with sudo here, it shouldn't fail like that of course.

<tux_life>nckx no...same result

<nckx>texi->plain-text 🤔 What does ‘guix describe’ say?

<tux_life>Generation 4 feb 28 2023 11:18:54 (current)

<tux_life> guix 3bb2078

<tux_life> repository URL: https://git.savannah.gnu.org/git/guix.git

<tux_life> branch: master

<tux_life> commit: 3bb2078a12d78a13f1e1520fe3705333a74ef6e3

<snickerdoodle>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3bb2078a12d78a13f1e1520fe3705333a74ef6e3

<lechner>nckx / my point was that the other errors are delivered in string form. also the "irritant" should be the URL

<lechner>ACTION thinks errors alert users to typos

<nckx><my point…> If you say so.

<nckx>lechner: OK, if the error is ENOENT or ECONNREFUSED (not, say, anything TLS) I agree with the typo reasoning a bit more.

<nckx>But if you get -2, -2 is what you get, you'll have to deal with that.

<lechner>please try your urls from a few days ago. that info was a lot better

<nckx>Any hint which?

<nckx>You know I'm a senile old coot.

<nckx>This was just -2: https://logs.guix.gnu.org/guix/2023-02-27.log

<snickerdoodle>"IRC channel logs" https://logs.guix.gnu.org/guix/2023-02-27.log

<nckx>Ah, this? https://logs.guix.gnu.org/guix/2023-02-27.log#111223

<snickerdoodle>"IRC channel logs" https://logs.guix.gnu.org/guix/2023-02-27.log#111223

<nckx>I ran ‘guix pull --commit=3bb2078’ (tux_life's commit) but ‘guix system search cups’ still works, so my assumption that someone committed invalid Texinfo seems bogus.

<nckx>tux_life: Does ‘LANG=C LC_ALL=C guix system search cups’ work? Now I'm just guessing.

<nckx>Hm, no it explicitly says "Unknown command". Do you have any… other channels, perhaps?

<tux_life>nckx Ohhhhhh yes!

<nckx>It does?

<nckx>Hum.

<nckx>‘Invalid command under current locale’ sure is a new one 😃 What was your locale? (‘guix shell glibc -- locale’)

<nckx>ACTION has to go, but at least you're unstuck.

<nckx>…or you were replying to ‘other channels’. In which case, try without them, etc.

<tux_life>nckx LANG=it_IT.utf8

<tux_life>LC_CTYPE="it_IT.utf8"

<tux_life>LC_NUMERIC="it_IT.utf8"

<tux_life>LC_TIME="it_IT.utf8"

<tux_life>LC_COLLATE="it_IT.utf8"

<tux_life>LC_MONETARY="it_IT.utf8"

<nckx>tux_life: You were quieted by a bot for pasting ‘a bloody huge wall of text’ (its words! not mine!). But if this is a locale problem, I suspect the Italian translation is broken, and needs to be updated. Bye!

<tux_life>nckx ok thank you!

<nckx>Confirmed, I'll fix it when I get back.

<ellysone[m]>anyone knows what to do in that case? Trying to install on the cloud

<ellysone[m]>```grub-install: error: failed to get canonical path of `aufs'.```

<civodul>ACTION got "guix build static-binaries-tarball" to pass on core-updates \o/

<janneke>\o/

<civodul>now hoping ci.guix can catch up

<civodul>well, this didn't introduce any rebuild, but previous evaluations failed

<janneke>shouldn't be too many x86 binaries left anyway

<zimoun>nckx: Thanks, the DNS stuff just works. :-)

<civodul>janneke: very good point! we don't really need those anymore actually

<civodul>except when porting to new platforms without full-source bootstrap

<janneke>civodul: sure!

<civodul>uh, the openssl change incurred mass rebuilds :-/

<lechner>Hi, does the store database that tracks links (guix gc --referrals) have any other info besides "validity" that would be interesting for juix.org?

<Guest39>is there an easy way to install chromium dependencies, e.g., libnss3 (which seems to be missing from nss)?

<apteryx>Guest39: what are you attempting to do?

<lechner>Guest39 / Hi, i see libnss3.so in nss on juix.org, for what it's worth

<Guest39>apteryx trying to run mermaid for what its worth..

<apteryx>is this hosted online or intended to be used locally?

<apteryx>ot get all the ungoogled-chromium dependencies in a shell, you can do 'guix shell -D ungoogled-chromium'. not sure if that helps

<nckx>But nss has libnss3.so, so this is not the issue.

<nckx>lechner: I don't know what you find interesting, but here's the schema: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/store/schema.sql

<snickerdoodle>"schema.sql\store\guix - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/guix/store/schema.sql

<Guest39>trying that already.l but in nss libnss3 is in ,output/lib/nss path, not what npm provided chromium requires

<nckx>You could amend LD_LIBRARY_PATH, or create a symlink.

<nckx>Are you using the FHS environment?

<nckx>OK.

<lechner>they had enough

<Guest39>sure, there are more libs in the dependency list, will try using ungoogled-chromium

<lechner>nckx / a link in the store?

<nckx>No…

<nckx>If you're using the store directory you're already using some mechanism that would let you simply add /nss, but I assume that Guest39 isn't pointing chromium directly at the store, but some symlink tree or so.

<nckx>Then again, running npm-provided chromia isn't a goal of Guix, although it should be possible to make it work.

<nckx>ACTION away.

<stellarskylark>Heya folks, I'm trying to write a service for GoToSocial, since I intend to switch to Guix in my server environment, but I'm having trouble getting Guix to build the config file. Here's a pastebin with the entirety of the services file (it's just GoToSocial atm), the way I'm calling it in my services list, and the error the derivation build is giving: https://pastebin.com/sRATpzsD

<snickerdoodle>"(define-module (skylar services) #:use-module (skylar packages) #:use-modu - Pastebin.com" https://pastebin.com/sRATpzsD

<Guest39>nckx trying to now indeed. thanks for suggestions

<stellarskylark>Error is all the way at the bottom btw

<euandreh>The latest update to xmonad removed its ".desktop" file. Was that intentional?

<euandreh> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=49a320aaa6fb4c20d6b30c56c35a8c7ffceed822

<snickerdoodle>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=49a320aaa6fb4c20d6b30c56c35a8c7ffceed822

<euandreh>This commit removes the "install-xsession" extra phase

<euandreh>xmonad now doesn't show as an option during login

<euandreh>Should this change be reverted?

<euandreh>(this change == the removal of this phase)

<winter>I'd be surprised if it was intentional, as it looks like a good chunk of it was automated.

<lechner>stellarskylark / i looked at your config but am not sure how to use define-configuration myself

<euandreh>winter: yeah, this makes sense

<winter>euandreh: your best bet would probably be to open an issue and cc the author, or even better, write a patch and cc the author

<lechner>euandreh / winter / as someone who struggles with the format of commit messages in Guix, where would you look other than write to the author?

<euandreh>winter: good reminder. I'm writing a patch, I didn't think to Cc the author

<lechner>i am struggling

<lechner>euandreh you can use X-Debbugs-CC

<lechner>shouldn't something like that be mentioned in the log?

<euandreh>lechner: I didn't understand what you're struggling with

<lechner>to me, our commit messages appear nearly useless. they duplicate functionality available with git diff -- $path but leave out tons of other stuff

<lechner>or git log -- $path for that matter

<lechner>or git blame

<stellarskylark>lechner / as near as I can tell I'm using it right? it's a pretty simple macro, maybe the problem is with the way I'm exporting things? I've been beating my head against this thing for...well, days, and then I put it down for weeks to preserve my sanity

<lechner>stellarskylark / i have my own issues with that macro (in the upcoming service for cachefilesd) but you are probably making a simple mistake ("Unbound") even though I cannot tell you so. your best bet is to wait for mirai, who understands services better than most people in this channel.

<stellarskylark>lechner / gotcha, I'll stick around until they can take a look, thanks!

<stellarskylark>or, well, try to -- I'm on my laptop and it suspends on lid close so I might just vanish at some point

<lechner>i think we should beg for a video on how to write services

<stellarskylark>please, my children are starving, and the only way I can possibly feed them is by writing a guix service...if you could possibly find it in your heart to release a comprehensive tutorial video, we would be eternally indebted to you

<lechner>okay thanks, i think that will do

<euandreh>stellarskylark: teach a person to fish, and they'll make videos for everyone. I'll help you write your service, and you make the tutorial video?

<lechner>i love it!

<unmatched-paren>stellarskylark: a service is formed by combining a <SERVICE-TYPE> object with a configuration object using the SERVICE procedure. so you need to (define FOO-service-type (service-type ...)) to create one

<euandreh>stellarskylark: is there a specific service you'd like to write/be written?

<unmatched-paren>the <SERVICE-TYPE> record needs a NAME, a DESCRIPTION, some EXTENSIONS, and a DEFAULT-VALUE

<unmatched-paren>(service-type (name "FOO") (description "blah blah blah") (extensions (list ...)) (default-value ...))

<unmatched-paren>sorry, NAME should be a symbol, not a string

<unmatched-paren>(name 'FOO)

<euandreh>fix the missing xmonad.desktop file I mentioned earlier: https://issues.guix.gnu.org/61872

<snickerdoodle>"[PATCH] gnu: xmonad: Re-add xmonad.desktop file." https://issues.guix.gnu.org/61872

<unmatched-paren>DEFAULT-VALUE is the value used as the configuration object if you just write (service FOO-service-type) rather than (service FOO-service-type CONFIG-OBJECT)

<winter>🎉 euandreh

<unmatched-paren>most services come with a <FOO-CONFIGURATION> record that's used as said configuration object

<unmatched-paren>for this you use the DEFINE-RECORD-TYPE* (note the asterisk) macro from (guix records)

<unmatched-paren>or DEFINE-CONFIGURATION, from (gnu services configuration)

<unmatched-paren>which allows you to define documentation and type checkers for each field, and is quicker

<unmatched-paren>if you want to create a <FOO-CONFIGURATION>, do something like this:

<unmatched-paren>(define-configuration foo-configuration (FIELD-NAME (FIELD-TYPE DEFAULT-VALUE) DOCUMENTATION) ...)

<unmatched-paren>(FIELD-TYPE DEFAULT-VALUE) can be replaced with just FIELD-TYPE if your field doesn't have a DEFAULT-VALUE

<nckx>stellarskylark: Should it be #~(string-append #$(symbol->string field-name) ": " #$value) ? You're generating ‘(string-append log-level …)’ where log-level isn't defined.

<nckx>*Shouldn't it be

<nckx>lechner: What's missing from the commit messages?

<lechner>motivation

<unmatched-paren>FIELD-TYPE is just a procedure that takes a value and returns a boolean that gets a ? appended

<lechner>test cases, complaints, references, external bug reports

<lechner>supporting documents

<nckx>Yes, the commit message above is bad and shouldn't have been committed. But what is missing from our guidelines?

<nckx>Add it.

<unmatched-paren>for instance: (floob (string "foobar") "...") uses the STRING? procedure to check its value

<nckx>lechner: None of that is discouraged in Guix.

<nckx>I think you're confusing ‘include a change log’ with ‘a change log is a good commit message’.

<unmatched-paren>you can't put, eg, (list-of string?) in FIELD-NAME, so you need to do a DEFINE if there's no procedure for the type you want

<unmatched-paren>anyway, once you've got a record, you can put a (FOO-configuration) value in the DEFAULT-VALUE field

<unmatched-paren>the EXTENSIONS are the most complex part; they're how you implement the actual functionality of the service

<nckx>unmatched draftin' a new Guix blog post in chat \o/

<unmatched-paren>each extension is a <SERVICE-EXTENSION> object, created with the SERVICE-EXTENSION procedure

<unmatched-paren>nckx: i do want to do a services one, but i suspect that won't happen until, like, June :)

<lechner>nckx / here is an example of the many thousands of commit messages I wrote for Lintian, but reasonable minds can disagree https://salsa.debian.org/lintian/lintian/-/commit/2dc42ac0dc2073d6537203cbb4fb82d82460d7ef

<snickerdoodle>"Exempt backports to bullseye from changelog-file-missing-explicit-entry. (Closes: #941656) (2dc42ac0) · Commits · lintian / lintian · GitLab" https://salsa.debian.org/lintian/lintian/-/commit/2dc42ac0dc2073d6537203cbb4fb82d82460d7ef

<winter><nckx> Yes, the commit message above is bad and shouldn't have been committed. <-- out of curiosity, what's bad about it? (other than not including a list of every package updated/similar, though that'd be included in a changelog.)

<unmatched-paren>since i still have to cover gexps, grafts and inputs, and packages and build systems

<lain_>When I try to run icecat I get "Segmentation Fault"

<unmatched-paren>winter: commit messages in Guix should follow the GNU ChangeLog format

<lain_>that is the only output

<unmatched-paren>which imo is excessively verbose

<unmatched-paren>extremely so

<lain_>happens even when I run "icecat --version"

<nckx>lechner: I'm not familiar with the lintian (Debian?) commit message format. How did it help you write this commit message?

<lain_>I don't recognize any other broken programs

<unmatched-paren>back to SERVICE-EXTENSION: you construct one like this: (service-extension SERVICE-TYPE VALUE)

<nckx>lechner: The ➤ stuff? That's just your prompt, no?

<lechner>lain_ / sounds like a null pointer

<lain_>how would I fix that?

<lechner>nckx / it was from fish

<unmatched-paren>SERVICE-TYPE is a, well, <SERVICE-TYPE> to extend, and VALUE is a one-argument procedure that's passed the configuration object and returns a value to configure SERVICE-TYPE with

<lechner>nckx / do we have commit messages in Guix that explain anything?

<unmatched-paren>services are simply composed of extensions of other services

<lechner>lain_ / gdb is popular

<unmatched-paren>we often extend "base" services like SHEPHERD-ROOT-SERVICE-TYPE and ACTIVATION-SERVICE-TYPE that you won't often see in config.scms

<lain_>lechner thanks, I'll look into it

<unmatched-paren>these provide basic functionality like daemon management (SHEPHERD-ROOT-SERVICE-TYPE) and arbitrary code execution on reconfigure (ACTIVATION-SERVICE-TYPE)

<winter><unmatched-paren> winter: commit messages in Guix should follow the GNU ChangeLog format <-- i know, and i agree that it's pretty uselessly verbose nowadays. a description including the motivation for the change would probably be thousands of times more descriptive

<winter>i'd assume that projects stick to the format even though we have VCS for a reason, though...

<unmatched-paren>stellarskylark: you got all that? :)

<nckx>lechner: I don't know, but you said you struggled with the ‘format of commit messages’. I don't think the Lintian one is very good, no. It's not very information-dense (that could be fixed), but worse, it hides what should be comments away in the commit message. Fragile tools like ‘git blame’ might dig it up later, or they might miss it because of a later unrelated indentation change or whatever. The motivation for the commit belongs there; the

<nckx>musings on future/better solutions don't.

<nckx>But I don't see how this is related to format.

<nckx>The requirement to include a change log does not absolve you from writing a good commit message.

<nckx>s/you/one/ :)

<stellarskylark>nckx / ah, yes, that fixed it! Still don't totally get gexp but I think that gets me closer to understanding them, thanks!

<nckx>The ‘commit messages that should have been comments’ problem is not rare, by the way, and Guix has plenty of examples.

<stellarskylark>unmatched-paren / that's a really helpful explanation yeah!

<unmatched-paren>stellarskylark: right, to go further i'll need to know exactly what it is you want to do :)

<nckx>stellarskylark: \o/ Glad I could be of service. I got the vibe that there might be more subtle quoting issues here, but didn't investigate.

<lechner>nckx / there is no way any upstream would accept the level of detail from that commit message as a code comment. that suggestion was, in my view, unrealistic

<nckx>Then you worked around an upstream restriction. That's reasonable. Pity.

<nckx>(Your message could have been made much shorter, IMO, but that doesn't invalidate your point.)

<nckx>I don't mean the entire message, of course, only the call to future/better solutions, or examples of flaws of the current one.

<lechner>the commit log for Guix suggest to me that no such messages are welcome, as do the responses I received here

<nckx>A better approach would be to submit such a commit message and see if it's accepted, not to guess.

<lechner>reviewers get stuck on colons

<nckx>You're changing the subject.

<lechner>i didn't mean to. my point is that our concept of what is acceptable is extremely narrow

<nckx>The example message (I don't mean to pin you down on a single example, it's just convenient to discuss specifics) takes too long to read for the information it conveys—I could not read 100 of these. But the information it contains is welcome.

<lechner>nckx

<nckx>lechner

<jlicht>donkey

<nckx>moo

<lechner>nckx / you do not read it until there is a problem

<lechner>our commit message have mathematical purity to them

<nckx>If there is a problem and I have to dive into the commit history to get *this* information, in your example, that's not good.

<lechner>where else would you turn?

<nckx>Hence the ‘comment’ comment.

<lechner>and why is any of the information in our commit messages helpful? it can be obtained with any of the git subcommands, especially because our diffs tend to be tiny

<ulfvonbelow>anyone else having test failures in kwayland?

<jlicht>is the perceived (real or not) issue that our commit messages don't bring enough context? Or just the 'writers block' of writing yet another Changelog-formatted blurb?

<unmatched-paren>lechner: i believe it's used to construct the CHANGELOG file

<stellarskylark>so, okay...gexp -- they produce a procedure that's run at derivation-building time, but can have unquoted sections which can access values available only at compile time. Symbols in a gexp are simply passed on unaltered if unquoted and thus need to be defined at derivation-building time. If they're not, then the likely solution is to convert it into a hard value. Is that about right?

<ulfvonbelow>I get: FAIL! : TestQtSurfaceExtension::testCloseWindow() 'processStateChangedSpy.wait()' returned FALSE. (), but searching through the archives doesn't tell me anything about it

<unmatched-paren>which is very helpful for the dozen people who read those :)

<nckx>lechner: Why do you imply that this commit message wouldn't be ‘acceptable’, as you call it, in Guix?

<lechner>unmatched-paren / now there is something people with a rolling release model consult all the time

<nckx>That's a big claim you're just glossing over.

<unmatched-paren>stellarskylark: gexps, as far as i understand them, are just sexps, except their "unquote" also builds anything with a defined gexp-compiler and results in a string (the path)

<unmatched-paren>unless there's something else i'm missing (apart from the existence of ungexp-native)

<unmatched-paren>something else == some other difference

<lechner>nckx / why don't we start mentioning the bugs being closed in the commit messages? then i might be able to find the comments to my patch submissions

<nckx>This already happens, so as an example of what you call ‘unacceptable’, it fails. If you want that to be mandatory, suggest changing the policy.

<nckx>I don't think you're able to point to a specific problem with our current rules that prevent you from including what you want to include.

<nckx>If you can, and it's something that has been mentioned above, I'll gladly stand corrected.

<nckx>I mean, as a reviewer, I'd object to the shout-out-to-my-homies at the end of your example as unneccesary, and try to shorten the chatty text by 50%, but that's not based on some rule.

<nckx>ACTION goes hunting for a bad Italian.

<stellarskylark>unmatched-paren / I think that makes sense, thanks

<stellarskylark>How do I see the logs for a shepherd service?

<euandreh>stellarskylark: /var/log/

<lechner>nckx / this reviewer's comment caused me to shorten my first patch submission in Guix, after being referred to the "community standards" https://issues.guix.gnu.org/55762#1

<snickerdoodle>"[PATCH core-updates] linux-pam: Update to 1.5.2" https://issues.guix.gnu.org/55762#1

<euandreh>stellarskylark: some services have their own file, otherwise they'll go to /var/log/messages

<nckx>Thanks! Will read.

<unmatched-paren>stellarskylark: I believe it's kind of misleading to suggest gexps are *inherently* about delaying code til build time, they're just very useful for implementing that (someone please correct me if i'm wrong)

<bjc>where is “The ‘gnu: foo: Update to x.y.z’ messages you see in the Guix

<bjc> commit history are standardised” coming from? i don't remember seeing this in https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs

<snickerdoodle>"Style of Change Logs (GNU Coding Standards)" https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs

<stellarskylark>euandreh / gotcha, thanks!

<bjc>sorry, didn't realize that would send a nl =/

<unmatched-paren>they're just used to construct the guile-builder script, which is the lowest layer of all in guix's build stack (see "Builder Configuration" <https://guix.gnu.org/en/blog/2023/dissecting-guix-part-1-derivations/>)

<bjc>to be clear: i follow that header line format, but i had to pick it up from reading the existing commit history, not from the gnu style guide

<lechner>Hi, with so many specialists for services listening, should this declaration work for a reasonably defined configuration? (service cachefilesd-service-type (cachefilesd-configuration))

<unmatched-paren>lechner: no

<unmatched-paren>the VALUE needs to be a one-argument procedure

<unmatched-paren>this procedure has to accept the configuration value of the service doing the extending

<unmatched-paren>and return an extension value to configure the service being extended with

<unmatched-paren>which is *not* the same value as the service's configuration, which is the one you use with (service TYPE CONFIG)

<unmatched-paren>for instance, take greetd

<unmatched-paren>it doesn't make much sense for a service to do (service-extension greetd-service-type (greetd-configuration ...))

<unmatched-paren>a service's SERVICE-EXTENSION api, if it even has one, will be completely different from its SERVICE api

<nckx>lechner: Ey, look, that reviewer makes the same ‘this should be a comment’ point as I did, above! They even suggest linking to a bug report as you mentioned earlier. They sound pretty clever, and handsome. I also agree with their implication that including upstream changlog highlights is not automatically of interest to the Guix codebase. No, we don't want everyone's ‘motivation’ for bumping each package. I thought you were talking about bugfixes/improve

<nckx>ments. Those *should* be motivated in that sense.

<lechner>okay, i'll accept your apology

<unmatched-paren>for instance, take SHEPHERD-ROOT-SERVICE-TYPE

<nckx>lechner: For?

<nckx>In the original bug?

<unmatched-paren>i don't know whether SHEPHERD-ROOT-SERVICE-TYPE has a SHEPHERD-CONFIGURATION record, but if it does, (service shepherd-root-service-type (shepherd-configuration ...)) would be used for configuring the operation of the guix-daemon

<lechner>unmatched-paren / how about this? (service cachefilesd-service-type (cachefilesd-configuration (cache-directory "/var/cache/fscache")))

<unmatched-paren>which you can't really "extend"

<lechner>nckx / it's okay. i feel we have become friends

<nckx>ACTION confused.

<lechner>nckx / actually, you are the mildest of all

<unmatched-paren>lechner: OH! i thought you were talking about service-extension!

<unmatched-paren>apologies, that should work :)

<nckx>I've been telling you that 90% of what you want to include is already OK to include under the current rules. Now that you finally seem to accept that, you make it sound like I was inconsistent.

<nckx>ACTION 90% may contain 100% made-up numbers. Consult your veterinarian.

<lechner>it's okay. projection works

<lechner>unmatched-paren / this is the error i get, but i think the service is working without parameters https://paste.debian.net/1272461/

<snickerdoodle>"debian Pastezone" https://paste.debian.net/1272461

<lechner>nckx / i am just trying to soften your perspective, and everyone else. hence the dessert madness

<nckx>I think you see us as more uptight than we are. 😉

<lechner>i like fruit-loops the best, by the way. you?

<graywolf>This might be slightly off topic question, but what do people prefer on their laptops? networkmanager or connman? Those seem to be only viable options for a laptop networking setup and honestly I have no idea which one to pick.

<unmatched-paren>graywolf: i use connman for the sole reason that it works well without polkit, which is unfortunately unusable on seatd (unfixable on seatd's side; polkit needs to switch from liblogind to libseat, which works with both (e)logind and seatd)

<lechner>graywolf / i have only had perfect success with networkmanager and believe connman is primarily for embedded devices. it also depends on whether you use gnome, i think

<unmatched-paren>it is a wee bit harder to set up because there doesn't seem to be a viable GUI/TUI

<unmatched-paren>there's no nmtui equivalent, sadly

<lechner>graywolf / that being said, i would also like to switch away from networkmanager, but my nfs services do not start with connman

<unmatched-paren>so you need to go through a bit of trial and error before you figure out how to connect to your wifi network...

<unmatched-paren>if you ask i'll tell you how to do it though

<graywolf>I currently use wpa_cli on my laptop, so I'm accustomed to the trial-and-error approach :D

<nckx>lechner: Within the dessert genre, I guess it was one of my favourites so far. None of this fancy French nonsense.

<graywolf>(I always confuse psk and passphrase when adding new network :/ )

<nckx>graywolf: I use NM. It just works. Reliably so. No other reason.

<unmatched-paren>graywolf: does wpa_cli do autoconnect?

<unmatched-paren>s/wpa_cli/wpa-supplicant/

<unmatched-paren>i could never get it to do it

<rekado>unmatched-paren: ungexp-native is an unquote that gives you a *native* package’s output directory, not a *target* package’s output directory

<graywolf>rc-service add wpa_cli; seems to work for me (on alpine :) )

<rekado>the motivation for gexps is explained in detail in the code staging paper: https://arxiv.org/pdf/1709.00833.pdf

<unmatched-paren>rekado: yup, i know; i was reflecting on the fact that there might be something else about gexps that i'd missed, apart from ungexp-native

<lechner>unmatched-paren / can you tell what's wrong with this service? Why do i see Invalid keyword: "/var/cache/fscache" when trying to configure cache-directory as above? http://paste.debian.net/1272464

<snickerdoodle>"debian Pastezone" http://paste.debian.net/1272464

<unmatched-paren>lechner: i don't know; i'd need to know more about the specifics of cachefilesd-service-type

<lechner>it's all in that paste

<rekado>unmatched-paren: there are more things that gexps can take care of

<unmatched-paren>ah

<rekado>they are extensible through define-gexp-compiler

<rekado>these compilers are ways to “lower” objects from one representation to another

<unmatched-paren>rekado: yeah, i said "except their unquote also builds anything with a defined gexp-compiler"

<rekado>ACTION can’t read

<rdrg109_>[Q] Where can I see a bunch of package definitions? I'm learning how to write my own packages, so I want to see lots of examples to have good examples on how I should write my own packages.

<lechner>thanks to everyone for working on Guix, by the way! i really feel like we are doing something great

<rekado>rdrg109_: “guix edit hello”

<unmatched-paren>rdrg109_: ``git clone https://git.savannah.gnu.org/cgit/guix.git && cd guix'' then peek in gnu/packages

<snickerdoodle>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git

<unmatched-paren>or just guix edit :)

<rekado>you can view any package definition with “guix edit <name>”

<rekado>rdrg109_: there’s also a tutorial in the Cookbook

<rdrg109_>Thanks everyone!

<unmatched-paren>rekado: to clarify, since i'm going to write Dissecting Guix 3 on gexps soonish, is all there is to gexps that:

<graywolf>Since connman-configuration is pretty barebone, could someone point me to an example how to edit the /etc/connman/main.conf ?

<joe214>hi when i try to mount my lvm volumes i get a error saying they dont exist but when i run vgdisplay they are listed, how do i mount them?

<lechner>are they active?

<unmatched-paren>(1) GEXP is QUOTE, except you can use UNGEXP and UNGEXP-NATIVE etc within them

<unmatched-paren>(2) UNGEXP is UNQUOTE, except that they also allow you to unquote anything with a gexp-compiler defined, which produces an output path

<unmatched-paren>(3) UNGEXP-NATIVE is the same, except it produces a native output rather than a target output?

<unmatched-paren>rekado: is there anything else i should know apart from the above?

<unmatched-paren>ACTION afk

<winter><unmatched-paren> (3) UNGEXP-NATIVE is the same, except it produces a native output rather than a target output? <-- (is there more to it than that, given the question mark? seems right to me)

<lechner>he is asking rekado for advice

<lechner>nckx / okay, no need to be so quiet. sorry i stirred up so much trouble

<nckx>ACTION giggles. You should see the PMs I just sent you. ‘Quiet’, indeed.

<lechner>busy bee!

<nckx>But it's better to discuss this in this channel, since rekado is here, and they know more about the current (or last) state of substitute rsyncability than I do. It was their thing.

<nckx>(lechner would like to mirror substitutes, somehow, somewhere.)

<lechner>actually, i would like to use multicast dns

<nckx>That escalated quickly.

<lechner>well, maybe in a second step

<lechner>sorry

<nckx>:)

<lechner>or i need to get on that german 50 MB/s research superhigh way that connects MDC with the networks most of you other folks are on

<lechner> https://www.dfn.de/en/

<lechner>200 Gbit/s

<lechner>i mean, i get 700kB/sec from MDC on a good day

<graywolf>If I need to create a config file in /etc, I can use (simple-service 'x etc-service-type ...) correct? How does ordering here works? If I create /etc/connman/main.conf using this simple service, how can I tell the actual connman service to start only after the config file is created?

<lechner>graywolf / check out unmatched-parens' config on sr.ht

<apteryx>lechner: any substitute in particular?

<lechner>apteryx / that i'd like to mirror or use?

<apteryx>I missed the context but I thought you were writing that substitute download speed is slow

<apteryx>berlin seems to peek at around 11 MiB/s here

<lechner>where are you?

<apteryx>montreal

<lechner>at home?

<apteryx>that's from the office, to ensure my meager link at home is not the limit

<cbaines>we're pretty close to setting up mirrors for bordeaux.guix.gnu.org

<cbaines>the nar-herder has the functionality, and mirrors effectively exist

<apteryx>cbaines: we could also simply expose rsync on berlin, no?

<apteryx>the annoyance for me is the size of the data set

<apteryx>22 TiB is not super convenient to sync

<cbaines>I'm unsure about the practicalities of that approach

<cbaines>with the nar-herder, you can easily distribute the narinfo information, and use a reverse caching proxy to handle the nars

<apteryx>cbaines: what problems do you foresee?

<nckx>I would prefer this mirror to be of berlin. Maybe set up the nar-herder there.

<lechner>i wasn't complaining as much as offering to help. FSF offered some space in Boston

<cbaines>well, having to have 22 TiB of space to run a mirror seems prohibitive, I guess you could try and selectively rsync things but I guess that requires some missing bit of software

<apteryx>lechner: for what it's worth, the office connects to the internet via this company: https://fibrenoire.ca

<snickerdoodle>"Internet par fibre optique, réseaux privés, VoIP et Cloud | Fibrenoire" https://fibrenoire.ca

<nckx>cbaines: What's missing?

<graywolf>lechner: I have to admit I'm not much wiser after looking (assuming https://git.sr.ht/~unmatched-paren/conf/tree/root/item/system.scm is the right file).

<snickerdoodle>"~unmatched-paren/conf: system.scm - sourcehut git" https://git.sr.ht/~unmatched-paren/conf/tree/root/item/system.scm

<nckx>apteryx: Where do you get 22T?

<nckx>I just told lechner 3T per compressor.

<Lumine>Good evening #guix

<lechner>Hi

<lechner>apteryx / https://www.peeringdb.com/net/2799

<snickerdoodle>"PeeringDB" https://www.peeringdb.com/net/2799

<cbaines>nckx, say you have 500GiB of space to serve nars, I guess you'd need some software to manage that, copying the right things from berlin and managing that subset of the available nars

<nckx>Yes, but why can't rsync do that?

<nckx>We haz ctimes.

<nckx>(I checked.)

<cbaines>maybe it can, I don't know much about the functionality

<nckx>I'm sure it can.

<cbaines>you probably wouldn't want your mirror to start replacing stuff for the master branch with builds for core-updates, just because they're more recent though

<cbaines>that would probably reduce it's effectiveness

<nckx>That's true, but I'm not imagining that cramped a machine.

<nckx>If you have ‘only’ a few 100G, yes, that would be a risk.

<ae_chep>So, a library B relies on A both internally and externally, should B's output not include A's output as well?

<cbaines>when I was designing the nar-herder, I wanted something flexible enough to handle both use cases (mirror using a caching reverse proxy, and mirror everything)

<lechner>ae_chep / we try to avoid that. i might conflict with other programs

<apteryx>nckx: that's about the total size of what's in /var/cache/guix/publish/

<apteryx>you could sync just one type of archives, e.g. zstd for about a third of that

<ae_chep>lechner: I see, thanks

<mirai>ae_chep: if library B generates a pkgconfig file that wants to include library A then it should propagate

<apteryx>and then you could use a max age limit to fetch only the things newer than a year, making this much smaller still

<mirai>you should propagate A into B

<apteryx>rescanning for new things could be on the expensive side though, given 8 TiB or so is still a lot of files

<winter><graywolf> If I need to create a config file in /etc, I can use (simple-service 'x etc-service-type ...) correct? How does ordering here works? If I create /etc/connman/main.conf using this simple service, how can I tell the actual connman service to start only after the config file is created? <-- I'm also unsure why lechner recommended

<winter>unmatched-paren's configuration, but I think you want to see if you can define connman's configuration with a gexp first, so that it'll be restarted once the store path to the configuration changes.

<mirai>winter: if connman service can read an arbitrary file, sure

<winter>i don't know if it can, but if it can, then that's preferred. else, i don't know how to setup the ordering properly wrt etc-service

<graywolf>I have no idea how to plug that inhere https://guix.gnu.org/manual/en/guix.html#index-connman_002dservice_002dtype though

<winter>or if things like restarting the service based on if that file changes is possible

<snickerdoodle>"GNU Guix Reference Manual" https://guix.gnu.org/manual/en/guix.html#index-connman_002dservice_002dtype

<mirai>regarding 'additional dependencies' on connman, #61587 but it only works with shepherd services

<snickerdoodle>"[PATCH 0/8] networking services refactoring" https://issues.guix.gnu.org/61587

<mirai>which you can have, simply extend shepherd service with something that creates the file you want

<mirai>add the symbol to shepherd-requirements and voila

<nckx>apteryx: /var/cache/guix/publish on which machine?

<nckx>I du's berlin's earlier; it's 6.6T.

<winter>mirai: can you do that right now (without the patch) with service extensions?

<nckx>*'d

<mirai>winter: no but actually yes

<nckx>And if you'd only mirror, say, zstd toots, 3T would currently ‘suffice’.

<mirai>apply the patches locally and use them

<mirai>bonus points if you can report back that everything is "working fine"

<nckx>apteryx: Rescanning is a good point, though. It's not something you could do hourly.

<winter>i meant without the patches, as in is the service extension system powerful enough to be able to do this without having to add the field for it

<nckx>rekado: Who did you set up/investigate rsync for again?

<mirai>winter: my question leans towards 'who knows?' since you're praying for the shepherd service to start faster than connman

<mirai>maybe it wins the race

<lechner>mirai / you are teasing

<winter>mirai: to be clear, i mean if it's possible to add a requirement to an existing shepherd service as-is without having to explicitly add the field for it as the above patch does?

<mirai>lechner: losing the race results in things like #57589 =)

<snickerdoodle>"Guix hangs on GDM with Wayland" https://issues.guix.gnu.org/57589

<mirai>winter: afaik no

<winter>ah, that's unfortunate. so similar shepherd-requirement fields would need to be added to ~every service to be able to add dynamic requirements like this

<mirai>winter: every shepherd service*

<mirai>non shepherd services do not have anything of the sort

<lechner>mirai / crazy

<winter>anything that provides a shepherd service*, yeah

<nckx>cbaines: Could you passwd me on berlin, too? It also appears affected.

<mirai>in a distant future we'll have a "Generally accepted service writing practices" manual

<graywolf>mirai: How would I go about applying those patches? Is there some manual page for that?

<mirai>graywolf: clone guix, create branch, download patches and apply with git am

<mirai>there's surely a more streamlined approach if you ask a maintainer

<mirai>I don't believe they're downloading the patches one-by-one from issues.guix

<jpoiret>there are a bunch of different approaches

<jpoiret>but they all require some prior set-up

<lechner>patch -p1 < $file ?

<jpoiret>you can pull from this branch https://git.guix-patches.cbaines.net/guix-patches/log/?h=issue-61587&qt=range&q=base-for-issue-61587..issue-61587

<snickerdoodle>"guix-patches - Patches for guix" https://git.guix-patches.cbaines.net/guix-patches/log/?h=issue-61587&qt=range&q=base-for-issue-61587..issue-61587

<mirai>lechner: git am or git apply (don't remember)

<mirai>patch doesn't preserve commit data

<jpoiret>git am for mbox files

<lechner>mirai / git apply does not commit

<graywolf>Hm, would creating new one-shot service, that basically just creates the file and then restarts connman work? I mean, it is ugly, but since I don't even have a running system yet, I would prefer to avoid patching guix (I'm sure it is reasonably easy once you know what you are doing, but I don't (yet?))

<lechner>i think it's git am all the way for our workflow

<mirai>graywolf: if you figure the "and then restarts" part let me know

<mirai>my attempts at that have ended with the shepherd hanging itself 🪝

<graywolf>mirai: Oh, I was hoping for something like (system* herd restart connman), the "shepherd hanging" part sounds scary. Well, will try and see :)

<unmatched-paren>ACTION back

<unmatched-paren>lechner, graywolf, winter: i don't change conmann's .conf file, unfortunately

<mirai>if you do try out the patches leave some feedback in the email thread

<mirai>additional feedback is useful to assert that the thing works as intended ™

<unmatched-paren>lechner: looking at that paste, shouldn't cache-directory be string rather than maybe-string?

<unmatched-paren>lechner: also, i don't think you need to include it in that match-record

<lechner>unmatched-paren / i'd like to leave it unset for final submission

<unmatched-paren>lechner: you can't do (mkdir-p #f), after all :)

<lechner>i simply have no other way to configure the service, because of the error mentioned afore

<unmatched-paren>i have no idea why it's doing that

<lechner>that option has to remain unset in some way as the folder will fill up the containing filesystem

<ieure>zaith5Ai

<ieure>ffff

<lechner>ACTION recommend diceware

<lechner>unmatched-paren / might i lose some of the benefits of the syntax acrobatics if the file you saw is included in my config via 'load'?

<unmatched-paren>lechner: not sure. might as well try -.o.-

<lechner>actually, that's what i have been doing

<unmatched-paren>o

<unmatched-paren>yeah, maybe try -L DIRECTORY

<unmatched-paren>and then use-modules as normal

<lechner>neither you nor mirai knows what's going on, so it's either a really stupid error or something totally unexpected

<gnucode>hey guix people!

<nckx>ACTION wavves.

<vagrantc>ACTION is not implemented in guix, but other messier languages

<vagrantc>well, i guess build systems... but you get the idea

<unmatched-paren>guix install vagrantc

<nckx>guix challenge vagrantc 💪

<ae_chep>Is it normal for the header of one of my dependencies to be placed at "C_INCLUDE_PATH/<name>-<version>/<name>/<name.h>" ? The <version> bit is throwing all of the `#include <name/something.h>` to miss.

<nckx>Which one?

<ae_chep>glib?

<ae_chep>or gmime that relies on glib?

<nckx>Yes, that looks correct.

<nckx>You'll notice that the ‘version’ is not 2.73.whatever.

<nckx>You're (=the consumer) expected to -I…/include/glib-2.0 or similar.

<nckx>For most people, the ‘build system will do this’.

<ae_chep>how do I become one of those people that the build system does this for?

<unmatched-paren>ae_chep: pkg-config

<ae_chep>Otherwise yes, the `-I.../2.0` is the fix. That I understand. I skimmed the package definitions in guix to see if there were such manipulations and that didn't seem to be the case

<nckx>ae_chep: pkg-config --cflags --libs glib-2.0 for example.

<ae_chep>Ah-

<ae_chep>ah- okay

<unmatched-paren>or just ``pkg-config --cflags glib-2.0''

<unmatched-paren>that'll produce the -I

<gnucode>nckx: josh waves back.

<nckx>ACTION doesn't do big fancy purjex that ‘compile’ and ‘link’ separately what.

<gnucode>also, in case you all missed it, mitchell created a new blog post. This one is super in depth, and really cool.

<gnucode> https://gnucode.me/creating-new-build-systems.html

<nckx>Typo: copy-builde-system, last line.

<nckx>If this implies I'm some kind of super-speed-reader, I'll gladly leave you with that delusion.

<nckx>But what I skimmed was great!

<unmatched-paren>gnucode: another typo: distrobutions :)

<nckx>That's just the long form of—oh.

<nckx>sneek: later tell zimoun: Thank you for the SWH report!

<sneek>Okay.

<unmatched-paren>Of "distri", of course.

<unmatched-paren>(that sounds like a plural... :))

<nckx> https://distr1.org/

<snickerdoodle>"distri: a Linux distribution to research fast package management" https://distr1.org

<gnucode>nckx: thanks! and unmatched-paren thanks!

<ellysone[m]>Is it possible to package bootstrap in guix?

<ellysone[m]>or is it like any other js packages, hopeless

<rekado>nckx: we set up the rsync daemon for the Chinese mirror

<rekado>I know nothing more about it

<unmatched-paren>ellysone[m]: it's "possible"

<unmatched-paren>if you want to do it... have fun >:)

<ellysone[m]>it's a real shame

<ellysone[m]>cuz it's a submodule

<rekado>unmatched-paren: your gexp summary looks good to me

<ellysone[m]>of core.sr.Ht

<unmatched-paren>rekado: cool, okay

<unmatched-paren>ellysone[m]: ah.

<ellysone[m]>well goodbye sourcehut on guix dream I guess

<ellysone[m]> https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/item/.gitmodules

<snickerdoodle>"~sircmpwn/core.sr.ht: .gitmodules - sourcehut git" https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/item/.gitmodules

<unmatched-paren>mhm, i think a lot of people would like that

<unmatched-paren>i mean, if you managed to assemble a team of people to do it it could be feasible

<ellysone[m]>And who exactly is going to do that much work unpaid?

<ellysone[m]>you'd need to like reimplement lighter versions of every js packages involved or have a miracle importer

<apteryx>nckx: /var/cache/guix/substitute on berlin

<rekado>ellysone[m]: bootstrap is available as a concatenated source file

<rekado>it’s not quite building it from the “preferred form”, but it’s source code in most of the ways that matter: https://raw.githubusercontent.com/twbs/bootstrap/v3.3.7/dist/js/bootstrap.js

<nckx>rekado: And they use it? (Sorry if you don't know.)

<nckx>apteryx: OK. Just to clarify, above, you said /publish/.

<nckx>22T is a bit prohibitive.

<rekado>nckx: I don’t know if they do.

<ellysone[m]>rekado: well that's good, now just need to package those https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00066.html and prey that their dependency trees ins't insane

<snickerdoodle>"Sourcehut packaging" https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00066.html

<rekado>ellysone[m]: it may be possible to simply not package those, dependent on where they are used

<nckx>rekado: Thanks. I'd check the logs but don't know what to look for. If it's rsyncd, then no, but maybe ssh? No dedicated user AFAICT. That's where I stopped looking.

<rekado>when faced with the npm problem my first thought is usually mutilating the package. It’s better to have a package with slightly degraded functionality than no package at all.

<rekado>nckx: no ssh; just rsyncd.

<nckx>OK. Nothing in rsyncd.log looks relevant.

<nckx>lechner: In any case, if the implication wasn't clear yet: you should ask SJTUG what they do. They used to use custom software specifically for mirroring Guix. Maybe they still do, and will bum you a copy.

<nckx>For free. Shocking, I know, but I've heard weirder.

<ellysone[m]>rekado: yeah you're right, I imagine we could cut down the minify,clean-css for instance, https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/item/srht/Makefile , wonder how far you can get like that

<snickerdoodle>"~sircmpwn/core.sr.ht: srht/Makefile - sourcehut git" https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/item/srht/Makefile

<lechner>nckx / okay, thanks! was there a consensus on size?

<lechner>Hi, does anyone else using buffer-env struggle to answer "Mark manifest.scm as safe to execute (y/n)?" when committing in Magit?

<nckx>apteryx: That directory does not exist.

<nckx>lechner: No, because there's no clear answer to that question. It depends on how much you want to cache, and which solution you choose to do so. I think it's better to talk to SJTUG first to nail down some of their variables.

<apteryx>nckx: hmm. 6.6T on /var/cache/guix/publish. Perhaps we've lost a bunch? Or I forgot which directory we should check

<apteryx>I think we've lost some

<apteryx>/dev/sdk2 100T 8.4T 92T 9% / this used to be around 23 TiB

<apteryx>even after a full gc

<nckx>I did not want this to be the explanation.

<apteryx>I think these are supposed to be pruned automatically by guix based on their ctime after a while... forgot where that's configured or what the valueis

<nckx>OK.

<apteryx>perhaps a large quantity of old substitutes got purged that way (to investigate). I don't see another explanation.

<nckx>I thought consensus was to use as much of the 100T as possible (with margins).

<ellysone[m]>rekado: after examining more closely the commits of core.sr.ht, I noticed that there the penultimate commit removed most of the js depenncies, there is actually one js dependency that is minify

<ellysone[m]>and it might not even be js

<ellysone[m]>it may refer to a go package

<ellysone[m]>and guix import go --recursive github.com/tdewolff/minify/v2, yields... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/4013dd9ccb46f3548114bb152a0795b62e8836c4>)

<apteryx>nckx: looking at frontend-services in (sysadmin services), it obeys (nar-ttl (* 180 24 3600))

<apteryx>180 days?

<rekado>I’m surprised by this. I also thought we wanted to cache as much as possible, let the 100T overflow.

<nckx>Or at least flow.

<nckx>Yeah, I don't think this is what we wanted to settle on.

<apteryx>reading the docs leaves me wondering what --ttl is actually useful for

<winter>ellysone[m]: I'm not the person you pinged, but I think I see the issue. I'll look into it and see if the fix is as simple as I think it is.

<winter>will ping you if I find it :)

<nckx>apteryx: Without --cache, it tells clients how long we expect substitute availability info to remain valid. And since it makes sense to tie that to --cache, we do.

<apteryx>ah, I think I see it; if an item was not *accessed* for TTL and is lacking its /gnu/store counterpart, it may be deleted (by guix publish itself?)

<nckx>Not sure if that's clear. Basically, --ttl alone sets the HTTP header for clients. It is useful.

<apteryx>given we now aggressively gc the store, this is more likely to happen

<nckx>That'll be it.

<apteryx>so this config hasn't changed in 2 years, but this side-effect just surprised us

<nckx>Yes. 180 days must have felt like forever in the bad old days.

<nckx>ACTION remembers them fondly.

<nckx>‘No builds? Ah, today is a GC day. Maybe tomorrow.’

<apteryx>maybe next week!

<nckx>Biggest GC lock.

<djeis>What do people actually recommend as a screen locker these days on guix system? Since it seems xscreensaver is broken beyond my ability to hack back in to shape.

<vagrantc>ACTION uses swaylock + swayidle ... but also uses sway :)

<djeis>Too attached to exwm to use wayland, for better it worse :)

<vagrantc>heh. was quite surprised that the guix installer tells me there are no security risks to enabling substitutes ... i would say there are not large security risks ... but none? that's silly.

<jfred>Question for those with more knowledge of Guix's internals than I have: when you build a package, does your `guix build` process fetch the package source or does it send something to guix-daemon instructing *it* to download the source?

<nckx>WARNING: the installer has detected that your computer appears to be running. This is a security risk.

<vagrantc>nckx: exactly!

<nckx>jfred: Simplified, but definitely the latter.

<nckx>djeis: What's wrong with xscreensaver?

<jfred>nckx: Perfect, thanks. I know I'm simplifying, just wanted to make sure I had a high-level understanding of where things happened

<vagrantc>huh. how does guix pull do it's magic ? it always pulls from a local cache ... but guix-daemon shouldn't have access to that ...

<vagrantc>there must be ways to extract things from the filesystem ... but i have always struggled to figure out how to do that. always end up dumping some files on some remote server and fetching them or whatever.

<vagrantc>oh no, the installer failed.

<vagrantc>i don't even know where to look for errors ... it just gave me a "something went wrong" blue screen.

<vagrantc>everything seemed fine ... downloading packages ... and then whatever error it displayed, it promptly hid it away from view

<lechner>sorry to read that

<vagrantc>think it was an intermitant network issue

<vagrantc>though, would be nice if the log of the install were dumped somewhere i could read it to actually look

<vagrantc>i started the install over ... i suspect just being able to retry the exact same configuration would have worked

<vagrantc>instead i had to re-select all the prompts and whatnot

<apoorv569[m]>I am getting this error while trying to pull my own channel with gpg signed commits and fingerprint. guix pull: error: Git error: cannot locate remote-tracking branch 'origin/keyring'

<apoorv569[m]>I don't know why it says `origin/keyring` I have clearly specified `(branch "master")`

<guixfren>hi, I'm packaging some software and I'm having trouble with libcurl-gnutls.so.4

<vagrantc>apoorv569[m]: you need to also check out origin/keyring alongside your master branch

<guixfren>since curl is built with gnutls support, can I just link libcurl.so.4 as libcurl-gnutls.so.4?

<vagrantc>apoorv569[m]: it looks for a branch named "keyring" in the same place you have the branch you specified.

<vagrantc>that is where it gets the keys to validate commits from

<apoorv569[m]>But I don't have any branch named keyring.

<vagrantc>exactly why it can't find it

<vagrantc>you either need to disable signature checking, or add a keyring branch

<apoorv569[m]>Oh! So its like I have to create a branch named keyring?

<vagrantc>yes, take a look at the branch in guix to know what it should look like

<vagrantc>just a bunch of key files

<apoorv569[m]>so I can't use master branch then? or can I leave the keyring branch empty?

<vagrantc>if you are asking it to validate signed commits, the keyring branch is where it gets the keys that it uses to validate

<apoorv569[m]>Ah! My public gpg key..

<apoorv569[m]>I see.

<vagrantc>so it needs to have whatever keys that were used to sign all the commits

<vagrantc>(including signed commits if you forked from another branch)

<apoorv569[m]>do the keyfile has to named in certain format?

<apoorv569[m]>or can I call it anyting?

<vagrantc>not sure exactly, but look at the keyring branch in guix for an exampl

<vagrantc>e

<vagrantc>surely it is documented somewhere, but i do not know off the top of my head

<vagrantc>apoorv569[m]: "Specifying Channel Authorizations" in doc/guix.texi ... or wherever that ends up on the guix manual

<vagrantc>apoorv569[m]: unless this is just a fork of guix and not a channel?

<AwesomeAdam54321>guixfren: Yes, it should work

<vagrantc>apoorv569[m]: good luck, gotta head out soon but surely others can help too

<apoorv569[m]>Yes, thank you! I think I got it.

<vagrantc>hrm. the install used about 1.3gb of disk space, and is stalled out on "substitutes:" ... with no further text.

<vagrantc>er, "substitute:"

<vagrantc>ACTION feels the pull of guix not wanting me to leave

<vagrantc>ah, there is a log on tty12

<vagrantc>and maybe a file somewhere...

<vagrantc>ACTION reports a bug and gets back to other things!

<vagrantc>ACTION waves

<guixfren>why does this: ("nghttp2:lib" ,nghttp2 "lib") return /gnu/store/zkkbi26n7vqqx60fvfj792pr5qz4ks88-nghttp2-1.44.0 as a path?

<guixfren>I thought it would return the -lib

<guixfren>but it doesn't?

<djeis>nckx: Most recent version moved the setuid part to a subprocess and the main process gives up any setuid power you give it. Additionally, it pushes its own package output folder onto the front of its PATH so it doesn't see the version of xscreensaver-auth in /run/setuid-programs even if I put it there. I then tried making a variant of the package that was missing its own xscreensaver-auth binary so it'd be forced to grab the one from

<djeis>/run/setuid-programs and then I ran into weirdness with unix_chkpwd.

<djeis>Which is a deeper bit of pam magic than I'm knowledgeable enough to debug.

<AwesomeAdam54321>guixfren: Because it refers to the nghttp2 variable

<djeis>More precisely, it pushes the libexec/xscreensaver/ folder of its install dir onto its PATH when it starts.

<AwesomeAdam54321>you can refer to it like this: `(,nghttp2 "lib")

<guixfren>I see

<guixfren>thanks

<winter>ellysone[m]: I actually cannot repro your issue at all.

<winter>What Guix commit are you on?

<winter>(`guix --version`, please)

<winter>Oh, I *can* repro it.

<winter>Cool.

<winter>Looking into it.

<guixfren>sorry for the question spam, but what is the best way to modify a package's '#:configure-flags'?

<guixfren>is there like a way to modify only some of the arguments when inheriting a package?

<iyzsong>guixfren: yes, see at-spi2-core in gtk.scm, it's substitute-keyword-arguments.

<winter>see the definition of ffmpeg-3.4 for an example guixfren -- you want `substitute-keyword-arguments` and `package-arguments`

<guixfren>right, thank you

<guixfren>I'm still pretty new to Guix

<guixfren>having a good time though

<guixfren>I'll try to contribute something once I learn my way around

<iyzsong>welcome, happy hacking!

<winter>how does one signify a snippet in the debbugs ui we use? trying to make my bug report look nice

<winter>i'd check but it's currently down :D

<nckx>djeis: …oh. I see. I'd say we ask ‘r0man’ who last updated it, but I have no idea who that is.

<nckx>winter: Snippet?

<nckx>Any other day I'd boop issues.guix but you're stuck with it until the morrow.

<winter>nckx: Like, a codeblock. I know it has a fancy view for them.

<winter>Also, achievement unlocked: bisecting Guix!

<winter>time-machine is nifty

<nckx>winter: Ah. It happens to know about the --8<---------------cut here---------------start------------->8--- (newline) codez (newline) --8<---------------cut here---------------end--------------->8--- as produced by emacs.

<winter>why is it always emacs,

<winter>lol

<nckx>I'm not sure optimising your mail for a particular Web site is a good waste of time though…

<winter>agreed, I can just use ``` to designate the start/end of the snippet ig

<nckx>winter: <why is it> That's the thing: it's not a forum, we don't want people adding noise to their mail to make it render differently on some site.

<lechner>ACTION does not like markdown

<nckx>Markdown was a prank and some people still haven't caught on.

<lechner>i'd recommend putting code after the message. otherwise people may not read all of it

<nckx>winter: What did you debug?

<nckx>It's probably what I was about to do, so that's good.

<mirai_>@lisp ... @end lisp

<mirai>perhaps texi could work for formatting emails

<nckx>Yes, we should force people who send Markdown mail to send Texinfo for a week.

<nckx>(Please use neither :)

<winter>nckx: `guix import` throwing an error where it can't find a variable, but it definitely should be able to as the given line it's throwing has the requisite variable in-scope

<nckx>Oh good.

<mirai>I think texi is more than enough for email needs

<winter>it was introduced some time recently, though, so bisecting

<nckx>Friends don't send friend Texinfo emails.

<lechner>Hi, is there a chance guix might switch to a format for store items that includes the output hash? the would be globally unique and reproducible. it would also save my scanner from looking at folders we know already

<winter><nckx> Oh good. <-- what was this to?

<mirai>(there's HTML as well)

<nckx>ACTION sets ban on mirai (Too. Far.)

<nckx>winter: That you're on it.

<mirai>:)))

<winter><nckx> (Please use neither :) <-- so should I just signify a "code block" with newlines? or w/e

<winter>guess it really doesn't matter

<winter>as long as it's readable

<nckx>lechner: Not a big one. There are many challenges with the ‘intensional store’, as it's been dubbed. One being that all builds are *not* reproducible, but would need to be :) There are some Nix experiments though (RFC 62) and ‘content-addressed derivations’ are becoming a thing. I think Guix is happy to watch what happens to Nix, to see if anything explodes, I mean learn.

<snickerdoodle>"RFC 62 - Systems for Interprocess Communication in a Resource Sharing Computer Network" https://datatracker.ietf.org/doc/html/rfc62

<nckx>winter: Yep, that's fine. Or --------------------. Or, if you really want that sweet HTML render on that one site, the markers I posted above (they are exact; pasted from emacs).

<winter>better link: https://github.com/NixOS/rfcs/pull/62

<nckx>snickerdoodle: Bootsnock.

<snickerdoodle>"[RFC 0062] Content-addressed paths by thufschmitt · Pull Request #62 · NixOS/rfcs · GitHub" https://github.com/NixOS/rfcs/pull/62

<nckx>winter: Botsnack.

<winter>ACTION tilts head

<winter>oh hey, 134 landed

<winter> https://github.com/nixos/rfcs/blob/master/rfcs/0134-nix-store-layer.md (grep Guix)

<snickerdoodle>"rfcs/0134-nix-store-layer.md at master · NixOS/rfcs · GitHub" https://github.com/nixos/rfcs/blob/master/rfcs/0134-nix-store-layer.md

<nckx>Yeah, I was reading it, tilting my head.

<nckx>Big deal?

<winter>ACTION shrugs

<winter>just always surprising to see an rfc land, i guess

<lechner>nckx / thanks for those references

<nckx><134> …oh yeah. I've read this before. Took a mo to swap in.

<nckx>But really I had the same ‘hmmm’ reaction then.

<winter><nckx> Big deal? <-- was this to 134?

<nckx>ACTION happily goes to bed, relieved of the self-imposed pressure to look at ‘guix import’.

<nckx>Yes.

<winter>idk, I think sharing that code properly may be nice

<lechner>wait, so Nix now does include the output hash?

<winter>> I do not expect Guix to be immediately sold on this plan...

<winter>guess he's right, though :)

<nckx>issues.guix restarted, but I'm really going to bed now.

<lechner>good night

<winter>thank you!

<jackhill> hi guix: QA says https://qa.guix.gnu.org/issue/61859 is failing, but I don't know why. What's wrong with that patch? It seems to be rebuilding more things than `guix refresh -l` indicates.

<snickerdoodle>"Issue 61859 Guix Quality Assurance" https://qa.guix.gnu.org/issue/61859

<winter>cc cbaines

<surpador> https://issues.guix.gnu.org/60827 also seems to be failing due to an attempt to build seemingly unrelated derivations- I wonder if it's a similar reason

<snickerdoodle>"[PATCH 0/3] Add perl-par, xforms, and dozenal package definitions" https://issues.guix.gnu.org/60827

<surpador>Hmm, looks like they're the same unrelated dervivations- openmpi, java-openmpi, padre

<XADE[m]>Is it normal for '/bin/ to be completely empty after 'guix system init ...' ??

<mmarshall540>XADE[m]: Mine just has a symlink to sh. I think it's normal.

<lechner>XADE[m] / yes, it's one of Guix's greatest accomplishments!

<thanos_apollon>Is it possible to encrypt a partition using guix system reconfigure?

<unmatched-paren>hello guix :)

<jpoiret>thanos_apollon: no

<jpoiret>Generally, guix doesn't handle stateful changes, except installing the bootloader

<cbaines>jackhill, surpador looks like those failures are due to some broken openmpi related packages

<cbaines>this particular breakage involved the derivations being different every time they're computed, the packages appear to have changed between every revision

<cbaines>they also fail to build, hence the failures being shown

<poselyqualityles>i'm making a package that has a pre-compiled binary, and patch-shebang does not seem to set the interpreter to the correct path. What is needed to make the build patch the binary with the correct interpreter path?

<AwesomeAdam54321>poseliqualityles: You need to use patchelf

<AwesomeAdam54321>It would be better to build the pre-compiled binary from source

<lain_>posleyqualityles "What would be unacceptable is for the documentation to give people instructions for installing a nonfree program on the system, or mention conveniences they might gain by doing so."

<lain_> https://www.gnu.org/distros/free-system-distribution-guidelines.html

<snickerdoodle>"Free System Distribution Guidelines (GNU FSDG) - GNU Project - Free Software Foundation" https://www.gnu.org/distros/free-system-distribution-guidelines.html

<lain_>This question is not really appropriate for the forum

<poselyqualityles>lain_ that's a good point, sorry about that

<poselyqualityles>AwesomeAdam54321 100% agree

<jpoiret>lain_: pre-compiled binary doesn't necessarily mean nonfree software

<lain_>It doesn't, but the same instructions could be applied to nonfree software

<jpoiret>guix probably shouldn't ship patchelf either

<jpoiret>or wget

<jpoiret>i don't agree with you here, and I don't think any reading of the FSDG quote you posted does either

<jpoiret>(the above two lines about wget and patchelf were sarcastic, i apologize for their passive-agressiveness)

<jpoiret>people are free to use free software for their endeavours, including if they want to install nonfree programs! we just don't help them install those, but as long as it's not related to it there should be no problem

<irfus>I also don't agree that "documentation" ins the same thing as people interacting over irc. That particular point from the guidelines doesn't apply. "Support" is broader, and I believe there is an (informal?) policy about that here, but I don't know clearly about that.

<tux_life>Hi! I would like to use dnscrypt-proxy. I use "sudo dnscrypt-proxy --resolver-name=SERVER_NAME" and change my /etc/resolv.conf ad indicated here: https://wiki.archlinux.org/title/Dnscrypt-proxy#Modify_resolv.conf. It works! But.. how can I achieve a similar result completely automatically, perhaps by configuring /etc/config.scm?

<snickerdoodle>"dnscrypt-proxy - ArchWiki" https://wiki.archlinux.org/title/Dnscrypt-proxy#Modify_resolv.conf

<jpoiret>tux_life: you'd need to create a service for dnscrypt if it doesn't exist yet

<tux_life>jpoiret it doesn*t exist. Ok...can you please link an example to create a service? I have no idea how to start. Thank you!

<gabber>how can i reconfigure my system (with all the channels and my old configuration) with a new patch i made? my attempts with `sudo [-E]` and `./pre-inst-env` fail -- "no code for module (gcrypt hash)", "no code for module (guix ui)", couldn't find my channels. how can i achieve that?

<irfus>tux_life: look at section 12.18 of the manual to get started with.

<ellysone[m]><tux_life> "jpoiret it doesn*t exist. Ok......" <- I do have one in my personal channel

<ellysone[m]>not ready for inclusion in guix proper though

<ellysone[m]>would someone knows what to do when herd literraly hangs when I try to interact with it?

<ellysone[m]>herd status, restart just stuck on a blinking cursor

<ellysone[m]>and I solved the problem

<ellysone[m]>Syslog was hogging 100% cpu on that machine (vultr vps), I had to kill with pkill via the kvm console, now I can herd status, restart etc

<ellysone[m]>note that I could not ssh into the machine while herd was hanging

<attila_lendvai>what if there's already a package named clasp, but i'd like to add the common lisp implementation under the same name?

<gabber>attila_lendvai: maybe call it clasp-cl or similar?

<attila_lendvai>it's so unfortunate that IT systems keep solving the namespace/lookup problem in a miriad different ways... the global guix package name list is yet another example of that.

<attila_lendvai>as an obivous first thing to consider here, the scheme module namespace/lookup could have been reused.

<gabber>i'm not sure i can relate. don't you like to refer to specific software by a name? or do you miss like another special character introducing a variant of a package? like clasp!Go vs. clasp!CL?

<gabber>isn't the package name primarily used for the CLI?

<attila_lendvai>gabber, i don't like it when there's a central authority that decides which software is called what. it's the same issue as having two functions under the same name in two different modules. just further qualify the lookup when needed...

<bjc>decentralization, globally unique names, and memorable names can't happen

<bjc>gns has attempts to make it easier

<attila_lendvai>i'd be completely fine with `guix package -i clasp` aborting and telling me to qualify which of the two clasp's i meant.

<gabber>if we rename the first to clasp-cpp and you'll add clasp-cl then we get (almost) that exact behaviour

<winter>FWIW ellysone[m], see #61885 for your guix import issue. I took some time to look into it, but someone more attentive than me figured out what was going on :D

<snickerdoodle>"`guix import go` fails outside of pre-inst-env" https://issues.guix.gnu.org/61885

<ellysone[m]>winter: oh yeah thanks you for taking the time

<winter>that issue was very weird to debug, at some point i could only reproduce it inside a development shell but outside of the shell it worked fine

<winter>no clue why

<winter>gonna see if i can repro that

<Guest337>Hello, please clarify this for me: Are configuration files still necessary when you use guix system? Or is the configuration solely implemented in config.scm? For example, I want to make a system where keybindings for mpv are automatically globally configured to my liking. Do I still need a mpv.conf for that?

<gabber>Guest337: you can join *all* your configuration files within config.scm

<gabber>this makes sense for some configurations, but might not make sense for things like ~/.emacs (since emacs relies on modifying that file itself and Guix produces only read-only config files)

<puddinghead>hey, i have a question

<Guest337>ok, that's cool. thank you

<gabber>Guest337: have a look at `simple-service` and `extra-special-file` in the manual

<puddinghead>i've been using an app with typing capabilities for a while. however, i can only use latin characters

<puddinghead>oh wait

<Guest337>gabber: will check that out

<puddinghead>how do i input foreign characters on gui apps?

<puddinghead>although tbh

<puddinghead>i think its more of a problem with how some programs are packaged

<gabber>i think this depends on your window manager(?) - i have a compose key which lets me create and input whichever characters come to mind

<puddinghead>i use xfce

<puddinghead>i've tested keepassxc and it allows me to input foreign characters, so does neovim

<lechner>puddinghead / which program is not working?

<bonz060`>Hi guys. I'm helping some install guix on a foreign distro (Linux Mint) and I keep running into: "guix install: error: git_libgit2_init: Function not implemented" when trying to do a guix install as the user. Things work as root. Can anyone help with this?

<nckx>lechner: ibus, mozc, Guix on Debian.

<tux_life>Hi! I know Guix is for advanced users and I'm a newbie/average user. But I really would like to learn how to configure the system in detail via the /etc/config.scm file. I read the manual, but unfortunately I am not able to understand many things. For example, I would like to define my own service and enable it on boot, but I really feel unable to

<tux_life>do so. Which service? A service not yet available: dnscrypt-proxy...

<tux_life>Also...how do you configure system files like /etc/resolv.conf? I assume you can achieve this by modifying some service...but which one? Network manager? Unfortunately I can't find any information about it.

<mirai>nscd

<mirai>its configured through operating-system

<nckx>bonz060`: How are you installing Guix? guix-install.sh?

<nckx>bonz060`: Is it possible the regular user has GUILE_LOAD_PATH set and root does not? This sounds like Guix is loading the wrong guile-git, or guile-git the wrong libgit2.

<puddinghead>lechner: sorry for being late, but it is a browsder

<bonz060`>Let me check

<mirai>what causes these make authenticate failures? (https://paste.centos.org/view/576e64b3)

<snickerdoodle>"Untitled - Pastebin Service" https://paste.centos.org/view/576e64b3

<mirai>occasionally some git pulls just break the previously working make authenticate

<mirai>also, is "git branch -d <patch-applied-upstream>" supposed to error out with "... is not fully merged." ?

<bonz060`>nckx: Nope. There's nothing off with GUILE PATHS or any of the environment variables.

<nckx>How did you install Guix? How are you becoming root? I'm downloading Mint but it's taking forever; ETA started at 10 minutes is now at 26.

<nckx>mirai: Did you rebuild Guix, and are you running in a guix shell -D guix? I can't even connect to paste.centos.org, something's wrong with my connection.

<bonz060`>nckx: First, my friend had installed Guix using apt. I uninstalled it and removed all the guix directories outlined here: https://www.mail-archive.com/help-guix@gnu.org/msg09629.html. I then ran the install script provided in the website (./guix-install.sh). For the install script, I used ftpmirror.gnu.org/gnu/guix to get faster download speeds.

<snickerdoodle>"Re: Repair / reinstall Guix package manager (foreign distro)" https://www.mail-archive.com/help-guix@gnu.org/msg09629.html

<mirai>nckx: yes

<mirai>it's the typical warning: this file was generated for autoconf 2.69.

<nckx>What's typical about it?

<rekado>mirai: if the branch’s commits had been rebased then the message “is not fully merged” is accurate but misleading

<nckx>mirai: We don't use ‘git merge’ for normal patches.

<mirai>nckx: typical as in "not a segfault" but a error message

<mirai>it always happens to me every now and then

<nckx>To me, that autoconf warning (error?) implies you didn't re-./bootstrap.

<mirai>some git pulls don't cause it

<attila_lendvai>i have compiled clang (CL compiler), and the `ldd clang` output contains: "libclang-cpp.so.15 => not found". any hints why it didn't get resolved to a store path?

<mirai>do I need to ./bootstrap after each git pull?

<rekado>attila_lendvai: we use a wrapper around ld for use with gcc that ensures that store locations are embedded in RUNPATH .

<nckx>mirai: Not every, but it's a good first step to debug autotools errors.

<rekado>how did you compile clang?

<nckx>(Note: I still can't open your paste, so that's all I can say.)

<mirai>nckx: distclean + bootstrap + configure fixes this when it happens

<attila_lendvai>rekado, hrm. i used the guix clang-toolchain package to compile clasp, using its own ninja based build system. didn't do much more than provided a shell with the right packages.

<nckx>It's a local issue, no need to re-paste.

<mirai>but the thing is it doesn't happen on every git pull

<attila_lendvai>rekado, it also needed binutils-gold for the linker

<nckx>I don't think distclean is needed, but yes, the rest all sounds correct.

<mirai>git pull + bootstrap + configure ?

<bonz060`>snickerdoodle: the problem is not a permission issue, but more like guix can't see git_libgit2_init

<attila_lendvai>rekado, this may be a hint that the wrapper script was not used? "clang-15: error: invalid linker name in argument '-fuse-ld=gold'" prior to adding the binutils-gold package

<jpoiret>mirai: bootstrap is basically autoreconf + translation files setup

<jpoiret>i usually only do `make`

<nckx>mirai: Does ‘automake --version’ in the build environment not match that given in your error message?

<jpoiret>yewscion: re: agda stdlib, do you have some agda-build-system, or just some ad-hoc package build for it?

<rekado>attila_lendvai: perhaps the sambamba package can help

<nckx>Really, it sounds like you're not consistently providing a ‘guix shell -D guix’.

<rekado>attila_lendvai: it’s using ld-gold-wrapper

<mirai>nckx: guix shell -D guix gives 1.16.3

<mirai>but where I am doing the make authenticate is 1.16.5

<nckx>And you error message?

<nckx>mirai: Well… there's your problem?

<mirai>idk... it sometimes works without complaining

<mirai>which is strange as it seems like it should have never worked?

<nckx>One (unsatisfying) explanation I can think of is that you're using ‘guix shell automake’ or so (or simply a Guix-installed ‘automake’ package) ~sometimes~, which != the version used by ‘guix shell -D guix’, which is older.

<nckx>It would also be nice if autotools weren't this pedantic about patch versions but there we are.

<nckx>bonz060`: snickerdoodle is a bot that posts URL titles.

<mirai>right, makes sense

<bonz060`>nckx: ah I see. Thanks for the clarification

<nckx>mirai: I don't have enough data to see a pattern in your sometimeses, but I bet there is one, somewhere :)

<gabber>how can i reconfigure my system with the patch i wrote yesterday? my attempts with sudo [-E] ./pre-inst-env fail due to the missing channels...

<bonz060`>nckx: the exact trace is: http://ix.io/4pAP

<nckx>bonz060`: And how are you becoming root? I don't think this is a permissions issue, no, but an environmental one.

<nckx>Thanks.

<mirai>unrelated to above, how does xvnc-service-type determine the user that gets the display ?

<mirai>the occasional SSH+X11 disconnects are maddening

<bonz060`>I became root with "sudo -s"; but when running the script, I ran it as "sudo ./guix-install.sh"

<nckx>I also can't connect to ix.io. Meanwhile, I'm (slowly) downloading an ISO :-/

<bonz060`>nckx: In particular, I installed guix by running: "sudo ./guix-install.sh"

<nckx>OK, that's correct. I should have clarified to ask how you're becoming root before successfully running ‘guix install’.

<nckx>Then ask you to paste the results of ‘env’ (in the same environment where guix fails) and of ‘env’ as root in the same environment where it succeeds, however you enter that one.

<temp64>Hi, I've just tried installing Guix but it refuses to boot and I seem to be missing firmware for my AMD APU and Wi-Fi card. My PC is running Ryzen 7 5700G and an X570 motherboard. Here's the screen at which my computer has been idling for about 20 minutes or so https://litter.catbox.moe/1kb4m0.jpg. I'm not sure why, the installer booted without any issues

<nckx>But since chances are I won't be able to see the paste… 🤷

<temp64>Where do I even begin fixing this?

<nckx>temp64: The installer doesn't have iwlwifi firmware either, so how did you install using this card?

<temp64>nckx: I plugged in my ethernet cable

<bonz060`>nckx: here's another paste: https://paste.debian.net/1272537

<snickerdoodle>"debian Pastezone" https://paste.debian.net/1272537

<nckx>temp64: OK. That wireless card won't be supported by Guix, it requires proprietary firmware which we don't ship or link to. I've replaced all my Intel cards with Atheros ones. The installer also boots with ‘modprobe.blacklist=radeon,amdgpu’ on the kernel command line (which you can edit in GRUB). I'm guessing the second one will give you graphics. However, they might be primitive, unaccelerated, etc., I don't know.

<mirai>maybe the config.scm was modified?

<nckx>temp64: If that works, and the result is usable, you can add it to the kernel command line in your system .scm and reconfigure.

<nckx>mirai: Modified?

<nckx>I think this is a fresh installation.

<mirai>that screenshot looks like what you'd get if you don't configure a login-manager

<mirai>at least my headless setup looks like that

<temp64>nckx: Alright, I'll try the GRUB thing first

<temp64>then install without selecting any DE if that doesn't work

<nckx>mirai: I'd expect to see a login: prompt in that case.

<mirai>or maybe I'm suffering from the a bug, who knows? I never get the prompt asking for a login (the TTY one)

<mirai>*from a bug

<mirai>but the daemons launch fine and I can SSH so

<mirai>nckx: O.o, I actually don't have that one in my headless machine

<mirai>dont get the prompt that is

<mirai>the screen just displays dmesg? messages I presume

<mirai>I use %base-services

<mirai>didn't delete anything from it

<haider>I have a question, the home service 'home-xdg-configuration-files-service-type'

<nckx>mirai: That should include (working!) getties, but now I'm should™-ing, which I try not to do. I don't use %base-services.

<graywolf>Is it possible to have a shepherd service depend on a specific file in /etc/ being changed (the change is done via etc-service-type, so within guix system reconfigure)? I have https://paste.vpsfree.cz/vd6:EOQu/ so far. It *does* work, however I cannot figure out how to link those two together. Is there a reasonable way to do so? My backup plan is to move teh file creation itself into the service, but

<graywolf>that seems more tricky to get right then using etc-service-type.

<winter>nckx: can you give #61885 a read and (if it looks good to you) apply the patch? an entire module is broken right now due to a cycle

<snickerdoodle>"`guix import go` fails outside of pre-inst-env" https://issues.guix.gnu.org/61885

<haider>Sorry, sent early. The service 'home-xdg-configuration-file-service-type' only accepts a file. How can I symlink automatically all files in a directory.

<winter>technically two modules i guess?

<nckx>winter: Yes, I was keeping an eye on this bug :) I thought you wanted to take another look, though, or did I misunderstand?

<bonz060`>nckx: thanks! Turns out on this system, LD_LIBRARY_PATH had been set wut! I really appreciate your help!

<nckx>GRR. I was 12 seconds away from typing that myself. :)

<nckx>Glad you found it yourself, that's more fun.

<winter>nckx: I posted the bug because that's all I was able to figure out, and Josselin figured out what was going on. There were some weird oddities with my reproduction of it yesterday, though that should be unrelated to the patch.

<winter>"weird oddities" lol

<winter>(guix pull should immediately make the new Guix available without having to exec the shell again, right? -- if not, then I'm unsure what's up there.)

<nckx>There should be a ‘notorious variables to watch out for’ list somewhere.

<winter>assuming the PATH is setup correctly

<winter>though I do find it strange how the bug didn't manifest in a pre-inst-env

<winter>wouldn't the same cycle occur?

<nckx>winter: Yes, it was the ‘oddities’ message that I interpreted as ‘I'm not sure this is the full story’.

<nckx>If it is, great.

<jlicht>I'm a bit out of the loop, but the openmpi stuff failing seems to be an ongoing thing on qa. Can I safely ignore it for getting patches merged?

<mirai>nckx: it includes agetty

<mirai>you're right

<temp64>nckx: Alright, I didn't see `modprobe.blacklist=radeon,amdgpu` on the installed version, here's my GRUB command line: https://litter.catbox.moe/18l5em.jpg. I removed the whole `modprobe.blacklist` entry and `quiet`, tried booting and my PC got stuck here: https://litter.catbox.moe/dihb57.jpg

<mirai>then I probably have the same bug as temp64

<temp64>hmm

<mirai>note that I'm using a dgpu for that one though

<nckx>I'm going to take a break because my connection's too bad to have sane conversations. I'll look at the bug. o/

<nckx>winter's bug…

<mirai>so its not really the APU

<mirai>but it is a Zen3 system

<temp64>oh, no problem. thanks for the help so far, nckx

<nckx>(For context: the last 9 messages all arrived *at once*, probably out of order. I need a rest :)

<dominicm>if I have a patch that works but I have questions on how to improve it, does that go to guix-devel or guix-patches?

<winter>cheers nckx

<attila_lendvai>rekado, it worked, thank you! the solution was to replace binutils-gold with ld-gold-wrapper in the inputs.

<surpador>haider: This is what I have, there's probably a better way to do it but this works for me: https://paste.debian.net/1272541

<surpador>The cfile and uncfile stuff is just so I can run `guix home reconfigure' from any directory

<haider>:surpador Thank you, I'll play around with it

<mirai> localhost shepherd[1]: Service term-console could not be started

<mirai>temp64: how did you partition the system

<temp64>mirai: 256MB /boot/efi, 4GB linux-swap and ext4 for a root partition

<temp64>mirai: not sure if you received the message before you DC'd

<mirai>can you resend?

<temp64>256MB /boot/efi, 4GB linux-swap and ext4 for a root partition

<temp64>is how I partitioned my pc

<mirai>ok

<gabber>dominicm: guix-patches automatically opens an issue on the tracker. if you only want feedback on the patch i'd suggest posting to guix-devel

<mitchell> `substitute-keyword-arguments` has surprising behavior where if the arguments you are substituting don't have the key word you are after. ie ((#:configure-flags flags) ...) it will not put your new #:configure-flags into the arguments.

<mitchell>so you have to write it as a weird append where you make a literal list of the newly introduced arguments and append it to the results of `substitute-keyword-arguments` for the keywords that the original package defined

<winter>i guess that somewhat makes sense

<mitchell>It makes sense but it would be nice if I could introduce new arguments using `substitute-keyword-arguments`

<winter>what about the append makes it look weird in the end, mitchell? (i actually do not know the syntax off hand,)

<gabber>maybe use it like cons* where you prepend whichever new arguments and as a last argument substitue-keyword-arguments of the ones already there?

<mitchell>For example https://paste.debian.net/1272549/ since the binutils does not have a :tests? flag I need to append it in this way rather than just having another field ((#:tests? _) #t)

<apteryx>has anyone researched the Intel ARC GPUs? Are they also reliant on non-free binary firmware to operate?

<mitchell>I guess its weird because I need to know what arguments the package i'm inheriting from defines instead of allowing `substitue-keyword-arguments` to take care of the magic.

<winter><gabber> maybe use it like cons* where you prepend whichever new arguments and as a last argument substitue-keyword-arguments of the ones already there? <-- looks like that's what they did at a glance

<winter>i'm sure there's dozens of ways to do it

<winter>you could probably write your own function to take care of it :)

<apteryx>re Intel ARC, seems to relie on non-free firmware...

<mitchell>Indeed I could! But I wasn't sure if there was a reason for this

<apteryx>some micro-controller firmware called "GuC"

<gabber>i'm also not sure but from what i saw Guix doesn't try to add too much magic™ to stuff, but relies on people knowing what they are doing and doing so explicitly. this can at times look and feel not as elegant as one would wish ;)

<winter>mitchell: if you do end up writing it, i'm curious what that kind of thing ends up looking like -- mind pinging me?

<winter>oh huh i thought this was a guile procedure

<winter>at least you can just modify the impl a tad in guix

<nckx>mitchell: Specify a default, e.g., ((#:tests? _ #f) #f). Appending looks weird and could be fragile in cases I haven't thought of yet.

<mitchell>nckx: I was just looking into that possibility now. I didn't realize there was a default option!

<nckx>Feel like documenting something today? 😊

<winter>i did see that in the definition just now, heh

<winter>nckx: how would it be fragile?

<gabber>they haven't thought of the cases yet :P

<mitchell>If the package later defines flags

<nckx>The case where your parent package later grows the same keyword you're appending is at best ambiguous.

<mitchell>then instead of appending you would over write

<nckx>Yep.

<nckx>ACTION still laggin'.

<winter>ah yeah

<mitchell>In my example it isn't so bad because the test? flag can only have one value anyway, but in other cases you want to add flags to a package which doesn't define any but may define some in future releases

<mirai>temp64: I recommend searching issues.guix.gnu.org

<mirai>if there's nothing there, open an issue

<mirai>I think term-console may be suspicious, and https://unix.stackexchange.com/a/384792 might be relevant

<graywolf>Is there a checklist for sending patches for services? https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html seems to be specific to packages.

<ellysone[m]><graywolf> "Is there a checklist for sending..." <- no, but you need to test them in guix vm, add a test in gnu/tests, run the test suie with make check-system TESTS="basic your-service"

<ellysone[m]>s/suie/suite/

<graywolf>That seems to require running guix system, so I'll put upstreaming the changes into my todo list :) thx

<nckx>Good news: you don't need to run Guix System for either of those.

<apteryx>neat, emacs-bash-completion now works well inside 'guix shell' (or other child processes)

<apteryx>interesting, Debian warns upon updates: "User sessions running outdated binaries:" with the users and which binaries they are running that are outdated

<graywolf>that's neat

<nckx>That is cool.

<nckx>mirai: What's suspicious, and which part of that SE answer should I be looking at?

<mirai>nckx: I skimmed over it but it mentions that /dev/console and tty0 are mostly the same but term-console service is for a serial-port?

<mirai>the naming is confusing at least, given the other term-ttyN names

<nckx>You mean it doesn't refer to /dev/console (like the others refer to /dev/ttyN)? I'll have to look at the code then.

<nckx>Oh good, a service with a honking ‘the documentation says x, but I observed y’ comment in the middle of it is always good news.

<mirai>for the record, I've never seen term-console work

<mirai>the service is always 'stopped'

<nckx>OK, it does rather seem to… conflate console & ttyS.

<nckx>mirai: What's your bug exactly? You have ‘console=’ set but the service fails? Or…?

<nckx>(nckx: it doesn't conflate them per se, but the name default-serial-port implied it did).

<mirai>console= isn't set

<mirai>not by default

<mirai>I didn't set it manually (yet)

<nckx>I mean in /proc/cmdline.

<mirai>I don't see it

<nckx>OK. I'm reading (gnu services base) in a Web browser so pardon my comprehension.

<jackhill>cbaines: ok, thanks. Spooky problem, but at least it's not something I caused with my patch :)

<jackhill>cbaines: an also only on some arches…

<nckx>mirai: If no console is specified on the kernel command line, this service is not supposed to start (start #f).

<nckx>If you do, it should.

<nckx>Shepherd itself doesn't (really) have the concept of conditional existence, only conditional start.

<mirai>oh, ok, makes sense

<mirai>it's somewhat confusing to see that always stopped

<mirai>makes it look like something went wrong

<nckx>Then again, I just remember you've been spending a lot of time in service-land and I might have misunderstood your question.

<nckx>If it doesn't spring to life when you *do* specify a console=, that would be a bug.

<lechner>Hi, I reconfigured my system and home, but X won't start anymore. As an EXWM user, I do so manually with a brief scripts to get the options just right for Xorg. Now the X server refused the connection. Does anyone else have a similar problem?

<lechner>this is with kernel 6.1.14

<mirai>nckx: then term-console in stopped state is a red herring as to why the prompt never appears

<nckx>If this is a regular Linux VT, then yes, I do think so.

<lechner>actually, it was a fluke. now it seems to work

<nckx>Unlikely, and unrelated, but is anyone here running their kernel without VT support? I think we have the pieces to make that possible in theory.

<nckx>I mean, even if you want ‘tty’s.

<mirai>temp64 said that this happened with a stock installation?

<mirai>my setup is stock kernel as well

<nckx>Yes, this was not related.

<mirai>no channels no nothing

<nckx>I'm asking out of curiosity and because of something I read, not related to your issues.

<nckx>mirai: And it's not a GPU firmware issue?

<nckx>The logs on the console are still updated after the point term-ttyX is started?

<nckx>If not, the login prompt might be there, just not rendering. That's happened.

<mirai>I'm using a radeon R5 240?

<mirai>text shows up on the screen

<mirai>kernel log

<mirai>and it doesn't seem frozen

<nckx>OK, discount that then.

<mirai>if I do stupid mistakes (like hanging shepherd) it will print something there

<nckx>:)

<nckx>And there are no getty processes running?

<mirai>mingetty ones from base services are up

<nckx>Huh.

<nckx>And you can switch VTs?

<nckx>Does this happen in a guix system vm of your system.scm? (Assuming it boots; they don't always.)

<mirai>I think I tried switching vts (keyboard)

<mirai>nothing seemed to happen

<mirai>as in, display stays unchanged

<mirai>haven't tried a chvt from ssh though

<lechner>mirai / do you have multiple video outputs?

<mirai>lechner: no

<nckx>The kernel won't switch to unallocated VTs, so I assume it's just that. chvt showing anything else would be weird.

<mirai>what I'm thinking is that mingetty could be broken perhaps?

<mirai>it hasn't received updates in quite a while

<mirai>2008?

<nckx>It definitely could, but it feels like the kind of assumption made out desperation, not plausibility.

<lechner>yeah, pencils have worked since 1810

<mirai>lechner: pencils have no moving parts

<nckx>I should have said likelihood. It's not implausible, just a bit too convenient for us :)

<mirai>well, computers don't but lets say "digital moving parts"

<lechner>apparently neither has had mingetty, since 2008

<lechner>ACTION reads backlog online

<nckx>mirai: You should meet my fan. She'd have something loud to say about that.

<mirai>nckx: rack-mount case fans?

<lechner>oh no

<lechner>i have loud fans too

<nckx>Laptop-mount laptop fan with delusions of rackdom.

<lechner>mirai / you ruled out kernel mode-setting issues with --console or --init ?

<lechner>what if you blacklist amdgpu, if that hasn't been suggested before

<mirai>lechner: no but does it matter for the login: prompt?

<mirai>text appears

<mirai>the screen lights up some pixels

<mirai>and they're not frozen

<graywolf>Hm, this is probably stupid question, but how do I restart quix machine? I've enabled elogind and now when I type reboot the system just hangs (after ...shepherd[1]: closing log).

<lechner>i think i didn't catch the exact symptoms. what's the last thing you see?

<mirai>unless the prompt for some reason needs KMS which would be bizarre

<mirai>lechner: kernel log

<lechner>mirai / if your screen blinks pixels, your refresh rate is off, your graphics card is broken, or your video cable is poor

<mirai>there's no graphical login

<lechner>even for text

<mirai>lechner: by light up pixels I mean that it is displaying stuff

<mirai>"text is scrolling"

<lechner>and the kernel log says what?

<mirai>pretty much what the temp64 screenshot had

<mirai>firmware missing blablabla

<lechner>404

<mirai>but that's because the system has just begun

<mirai>wait longer and other kernel messages will eventually appear

<lechner>that's good. can you take a picture with your phone?

<mirai>scroll up for temp64 link

<mirai>mine has been running for quite a while now

<lechner>that link is dead

<lechner>mirai / did you try 'nomodeset' ?

<mirai>but temp64 link is pretty much similar to what I see on a fresh boot

<lechner>actually, it isnt. extra do

<lechner>dot

<mirai>no

<lechner>what were the changes that led up to this?

<mirai>I could give it a try on the next restart

<lechner>\they were nice enough to mention us https://www.computing.co.uk/news/4076676/developers-ready-nixa

<lechner> https://www.computing.co.uk/news/4076676/developers-ready-nix

<lechner>nckx / googles-bot include final periods in urls 2023-02-28 message from temp64 with url from catbox.moe

<mitchell>"reducing complexity is complex" It's like a law of nature "Complexity cannot be created or destroyed, only moved around"

<mirai>entropy

<lechner>that is inconsistent with the laws of thermodynamics

<mitchell>Complexity can spread out

<mitchell>It's like Terry Pratchet says, we can only see 1/6 of the universe because the other 5/6 is all of the information describing it

<lechner>that is also true of embedded devices

<mitchell> https://github.com/paperclip4465/guix-embedded-example/blob/master/my-project/packages/embedded.scm speaking of...

<pjals>i look at the guix channel in forever and i see philosophy

<mitchell>it's definitely complex but also it's pretty nice from the usage side to just call `guix build k64f-provision`

<pjals>*for the first time in forever

<lechner>pjals / we solved all our technical challenges!

<mitchell>It's difficult to program in lisp without getting philisophical sometimes

<mirai>is this stream of text intelligible enough to get posted to ML? <https://paste.centos.org/view/5b622004>

<mirai>if someone's up for proof-reading

<ellysone[m]>a

<lechner>mirai / i took the liberty to edit constructively. please take what you like and disregard the rest. most importantly, please do not be offended. people have different styles, and i do not wish to argue. your text is fine the way you posted it here http://paste.debian.net/1272581

<graywolf>Is there a (local-file ...) variant for executable files? I ended up with (local-file ... #:recursive? #t), which seems to work, but is not exactly intuitive at first glance.

<mitchell>program-file

<mitchell>Perhaps that not exactly what you are after

<graywolf>My understanding from docs is that (program-file) takes piece of guile code, I cannot stuff bash into it.

<mitchell>You mean like local-file but the executable bit remains set

<mirai>lechner: thanks, I haven't completely read it yet but I'm sure to incorporate some of the edits you made here

<mirai>> That distinction is already commonplace in other distributions.

<mirai>do you have a source for this?

<mitchell>You can! make one file which has the bash code and the gexp #~(system* "bash" "-e" #$programs)

<mitchell>not exactly that but something along those lines

<mitchell>you may have to some staging of bash

<mitchell>can someone help me debug this service https://paste.debian.net/1272582/ It completely stops this vm from booting https://paste.debian.net/1272583/

<mitchell>it boots fine when the mosquitto-service is not included and mosquitto itself runs correctly with the generated config file

<mitchell>not "completely" but it stops after generating the ssh keys

<lechner>mirai / well, i think that's true for all distros using systemd, and certainly true for Debian. Also, "By default all remote mounts defined in /etc/fstab make use of this service" https://systemd.io/NETWORK_ONLINE/

<mirai>lechner: thanks

<Guest63>is it possible to get back ascii progression bars?

<lilyp>cbaines: any way of getting #59799 to actually build on CI?

<vdtoorn>Hello Guix, I want to import a python package that is not hosted on pypi, but on an internal (gitlab) server. I've gone throught the source code of the pypi importer and don't see any clues on how to import the

<vdtoorn>package?

<jpoiret>you'll probably have to write the package definition by hand

<jpoiret>it's not too complicated though

<vdtoorn>Thanks, what would be the correct way to get the wheel in the right place? Probably need to read the importer a bit better :)

<mitchell>If you use the normal python build procedure it's probably as simple as pointing the source at your internal gitlab server. If you need ssh auth to get at the code you can use git-checkout instead of `origin` and use the host ssh-agent to fetch the sources

<vdtoorn>Thanks a lot mitchell and jpoiret, I'll just do that, build the python package with guix. I was trying to get the CI-built package, but probably I'm overthinking it

<jpoiret>guix is source-based, so you won't be able to use CI-built packages

<mitchell>what CI? an internal one running on gitlab?

<jpoiret>the python importer basically just looks at the PyPI metadata and creates a package defnition corresponding to that that builds the package anew

<f3n1x>hi guixers of the world ! while on "guix home configure .." the process fails due to 'note: build failure may have been caused by lack of free disk space'. After double checking the available disk space, the question is... which partition does typically use for building stuff ? thanks, thanks, thanks

<civodul>f3n1x: hi! builds happen in /tmp

<civodul>or $TMPDIR as visible in the environment of guix-daemon

<f3n1x>uh... but there is plenty of disk space left there ! Weird... let me check again!

<rekado>why does “13.3.9 Fonts Home Services” speak of .nix-profile…?

<f3n1x>indeed, there are 45 GB left... I'm puzzled.

<ulfvonbe`>I don't suppose the build in question is ungoogled-chromium?

<f3n1x>Yes, bingo !

<civodul>rekado: uh no idea, sounds weird

<civodul>the example would be equally valid with ~/.guix-profile

<ulfvonbe`>f3n1x: throw out all preconception of what is "plenty" when dealing with ungoogled-chromium. 16GB RAM is not "plenty". 16GB RAM + 16GB swap is not "plenty". 50GB space for the build is not "plenty". It is an unholy monster.

<civodul>or ~/.local/fonts actually, whatever

<f3n1x>Oh.Holy shit ! i see ...

<ulfvonbe`>ungoogled-chromium's build system sets aside 50GB disk space *just as cache for the compiler to do link-time optimization with*

<ulfvonbe`>though that's just an upper limit, the actual amount used may be somewhat lower

<f3n1x>Next question, is there a way to be able to peacefully keep using 'guix home ...' and ungoogled-chromium ?

<civodul>f3n1x, ulfvonbe`: you really shouldn't be building ungoogled-chromium locally

<ulfvonbe`>substitutes are the only sane way for that beast

<mitchell>coward

<civodul>there was a bug recently in that area: https://issues.guix.gnu.org/61841

<f3n1x>nice to know... civodul !

<f3n1x>is there a way to instruct guix home to always use substitutes ?

<mitchell>like fail if they aren't there?

<f3n1x>ah... i see the magnitude of the issue-

<f3n1x>ACTION reading the bug report ... ^^

<f3n1x>at the time being,... is there a possible workaround ?

<Guest63>is it better to define channels and packages system wide or per user?

<apteryx>per user is more flexible, usually recommended

<surpador>Not high-priority by any means, but if someone wants to kill some time, could I get a review on <https://issues.guix.gnu.org/60827>? It's "failing" QA, but that's because of some unrelated openmpi derivations; the actual contributed packages build just fine, and I don't want to clog up the queue with a resubmission, especially since I'm not sure how to avoid the openmpi business :)

<ulfvonbelow>f3n1x: 'guix pull' should get you past that bug

<apteryx>is ruby-rubocop ok to update on master?

<apteryx>guix refresh -l says yes, but I seem to recall that many builds depended on it

<civodul>apteryx: check "./pre-inst-env guix build libreoffice" :-)

<acrow>Another fresh set of revisions posted to issue 60976. Hopefully moving ever closer to perfection. :)

<tux_life>Hi! I'm looking for a solution to use dnscrypt on boot. Im using "sudo dnscrypt-proxy --resolver-name=SERVER_NAME" and it works. But I would like to automate it via config.scm and I am not able to define my own service... Any advice?

<mirai>tux_life: my advice would be to write your own service :)

<mirai>look at the existing ones and see if there's one you can "adapt" for that purpose

<tux_life>Not easy for me, not easy at all. But thank you!

<vdtoorn>@mitchell sorry for my very late response, indeed we have a docker-based CI builder, useful for my collleagues

<tux_life>Does anyone know why the prompt colors are ignored by my zsh shell when I open a terminal? With "source ~/.zshrc" the colors are applied.

<Electnick>hello, how can I get distro name and version? I use -o, --operating-system print the operating system and got "GNU/Linux"

<winter><civodul> check "./pre-inst-env guix build libreoffice" :-) <-- am i missing how rubocop and libreoffice are related 😅

<civodul>winter: it's a Pro Tip™ to check whether you unintentionally triggered more rebuilds than expected

<tux_life>Electnick cat /etc/os-release

<guixfren>hi, I have a very strange issue trying to build a package

<guixfren>for some reason, it cannot find SDL_image.h

<guixfren>but when I create the environment from the package definition

<guixfren>and run the commands manually, then the build succeeds

<guixfren>turns out I had to use sdl-union on the inputs

<Electnick>tux_life: thanks but cat: /etc/os-release: No such file or directory

<Electnick>using inxi -S i got: System: Host: iish Kernel: 5.14.7-gnu x86_64 bits: 64 Desktop: i3 4.18.3 Distro: Guix. Then where inxi get the info of distro?. I am using gnu guix 1.3.0 and there is no /etc/os-release file

<Electnick>also hw-probe doesn't detect system. I run : ```sudo -E hw-probe -all -upload``` and got ``` ERROR: failed to detect Linux/BSD distribution```

<apteryx>winter: like all the roads lead to Rome, all the deps lead to LibreOffice

<apteryx>ACTION got sucked into a ruby updates galore again

<apteryx>ellysone[m]: why are you using the previous release? Guix is now at 1.4.0.

<apteryx>And I think it ships a /etc/os-release file now

<apteryx>if you use Guix System, that is

<cel7t>Hi I sent a patch to guix-patches@gnu.org however it's not showing up on issues.guix.gnu.org

<cel7t>Is this expected behavior, or has my patch been missed somehow?

<jackhill>cel7t: it may be in the moderation queue. Is this your first patch?

<cel7t>jackhill: Yep, this is my first patch

<jackhill>cel7t: awesome! Unfortunatley, thanks to spammers it will have to wait for a human to approve it (plus the usual processing delays), so I'd just be patient and it will probably get through eventually.

<cel7t>jackhill: No worries, I was just wondering if some kind of extra verification was required

<cel7t>Is there anyway to replenish inodes on btrfs?

<cel7t>I've once again run into the dreaded "In procedure symlink: No space left on device" build error

<apteryx>cel7t: there's no need, inodes are automatically allocated

<apteryx>perhaps you need to run btrfs balance to retrieve unallocated space though?

<apteryx>unallocated blocks

<cow_2001>meo: again, you?!

<cow_2001>okay, guix pull for the 100% very first time.

<cow_2001>no idea what's it i'm doing. FUN TIMES!

<winter> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/pull.scm#n442

<winter>this doc string looks out of date, there's no source argument

<winter>h

<winter>*hmm

<unmatched-paren>hello guix :)

<jgart[m]>hello (

<bumble[m]>how does one find which package would contain an unbound variable?

<bumble[m]>someone here shared a link to a web page that could be used to search packages in various channels and unfortunately I can't find a bookmark for that

<bumble[m]>specifically I'm looking for the variable "search-patches"

<indigo-oce>I have a T470s and I'm looking for what hardware will/won't work with the libre kernel... I'm assuming the wifi card won't work, but what other stuff? Is there a program or resource that can tell me what blobs I may need? Can't seem to find a good break-down. I've seen it mentioned that when distros install they only enable the blobs that are

<indigo-oce>required by the hardware... but idk how this is done. Surprisingly vague results from searching so far...

<bumble[m]>I found search-patches in gnu packages scm

<iyzsong>indigo-oce: there is h-node.org (have T480, but not T470s)..

<indigo-oce>iyzsong I saw this site recommended but I'm not sure how to use it... I see a T480 from the search results but no T470

<civodul>Hello Guix!

<irfus>bumble[m]: https://toys.whereis.xn--q9jyb4c/

<mroh>Hello civodul !

<cel7t><apteryx> "perhaps you need to run btrfs..." <- I'll try doing that

<mfg[m]>indigo-oce: try running a Guix or trisquel live iso and look at the dmesg output (if it boots)

<mfg[m]>why do i get redundnant progress bars of the form substitute: updating substitutes from 'xy' x%? Is there a bug report for that somewhere?

<civodul>mfg[m]: hi! redundant in what sense? could you paste the complete output somewhere?

<mfg[m]>sure: https://paste.debian.net/1272646/

<mfg[m]>though it's only redundnant for bordeaux and substitutes; not for ci.guix.gnu.org

<civodul>mfg[m]: hmm i see; i'm not sure there's much we can do, not easily at least

<bumble[m]>@irfus: thanks that's the one :)

<mfg[m]>civodul: Okay, i see. Thanks for looking :)

<bumble[m]>I wish to write a package to install "binary" anki, but binary anki includes a "lib" directory that must exist relative to anki binary (it seems)... but I'm novice and despite experimenting with different approaches, unable to write a package definition that copies "lib/" to the store beside anki binary

<bumble[m]>most recent attempt is seen here https://github.com/iambumblehead/guix-home/blob/main/guix.package.anki-bin.scm

<bumble[m]>feel free to share advice or criticism for me

<thanos_apollon>gnu morning guix!

<thanos_apollon><bumble[m]> "I wish to write a package to..." <- I like that! I had tried to do something similar with anki but just ended up using flatpak

<opty>nckx: hello, i modified two elogind libraries (sed 's/name=elogind/name=systemd') and so far so good \o/

<Arjanhehim[m]>is there any way to get a single package built from an older specific guix commit into a manifest?

<Electnick> hello, how can I get distro name and version? I use uname -o, --operating-system print the operating system and got ```"GNU/Linux"```

<Electnick> I am using gnu guix 1.3.0 and there is no /etc/os-release file.

<opty>Electnick: hello, what about /usr/lib/os-release?

<Electnick>opty: there is no /usr/lib on the gnu guix 1.3.0 i have installed. /usr only contains /usr/bin and there is no os-release in there

<rekado>there’s /etc/os-release on Guix System

<rekado>1.3.0 is very old

<Electnick>Gnu Guix 1.3.0 is not too far from 1.4.0 which is from nov 2022 what, 3 months ago?.

<Electnick>the issue is /etc doen't have os-release. I wonder if I had a bad installation process or anyone can confirm the same situation. The file contents of /etc in gnu guix 1.3.0

<mfg[m]>Well, /etc/os-release exists for me on Guix System

<mfg[m]>and 1.3.0 is from May 11, 2021

<Electnick>mfg[m]: Thanks. I don't know what could happen then.

<mfg[m]>If you really are on 1.3.0 you may want to update

<Electnick>mine is from Sun 17 Jan 2021 11:48:08 AM -03

<graywolf>Since the 1.3 and 1.4 is being discussed here, how does that work in guix? As far as I can tell guix pull just tracks the master no? So I'm bit confused what the 1.3.0 and 1.4.0 refers to. Is there some read up on this topic you could recommend?

<rekado>graywolf: releases are well-tested snapshots

<rekado>“guix pull” will not upgrade your system

<rekado>“guix system reconfigure” does

<graywolf>Hm, so in general I should avoid guix system reconfigure from "random" guix pull and instead I should stick to the v1.4.0 tag (or whatever the latest is)?

<rekado>no

<rekado>the opposite

<Electnick>checking my notes on that installation, the iso I installed is https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz (490mb). I don't remember is there was any upgrade. My bad,. Sorry.

<rekado>do reconfigure your system regularly

<graywolf>Then I'm confused :/ What is the point of those snapshots if I should still most of the time run "current" master?

<graywolf>Just to have some install medium from a well tested point?

<rekado>it’s a bad idea to run a system from 2021 without any updates

<graywolf>well yeah I would guess so

<rekado>you aren’t going to get any updates, not even security fixes, if you choose not to reconfigure

<rekado>graywolf: these snapshots are for installation

<rekado>for these snapshots we retain substitutes for much longer to make initial installation easy

<graywolf>Ah I see. Thank you for explanation :) And I did not realize the implication for substitutes.

<graywolf>Hm, I guess if I want to make my own new package, I do not need a channel right? I can do (package ...) right in the config.scm? Is that correct? Or will that blow up?

<rekado>you can do that, yes

<rekado>it would blow up as much as it would in a channel

<rekado>(i.e. it depends on the amount of explosives, not on the location)

<winter>is it considered bad etiquette to tell someone that a patch is a duplicate

<winter>*?

<winter>(i presume not, but want to make sure, as i can't find any examples)

<jonsger>winter: I think its a good, maybe provide a link to the duplicated patch...

<winter>yeah, was gonna do so jonsger

<winter>>.< debbugs doesn't strip html attachments from emails, leading my posts to have attachments that are just duplicates, ugh

<Reventlov>hey

<Reventlov>so let's say I want to use guix in a CI (Gitlab). I can, for example, use gitlab-runner shell executor in a guix-enabled environement (e.g. Ubuntu). Are there other options ? (e.g. do guix support gitlab runner and could be used as a build node directly ?)

<pjals>why would you want to use gitlab?

<winter>Reventlov: you can just run the binary installation script on their runners, if you want Guix in CI

<winter>(I believe that's what you're asking?)

<Reventlov>as this require root, i'll probably need a fully virtualized runner setup, hmm

<mirai>does SWH archive VCS data (can I "clone" it?)

<winter>mirai: unsure how you can clone that data specifically, but it does: https://archive.softwareheritage.org/browse/directory/c95078f3645abc050536d3aaf76cb5fb6eb6b288/?origin_url=https://github.com/libusb/hidapi.git&revision=7da5cc91fc0d2dbe4df4f08cd31f6ca1a262418f&snapshot=a61613c62c780bfabf67496d9fcd541878e752bb

<winter>(see "history," "tags," etc.)

<rekado>Reventlov: we’re using Guix in github actions; it involves installing Guix from scratch every time, and caching parts of /gnu/store

<winter>rekado: do GitHub's runners provide root? can't recall off the top of my head.

<winter>(if not, then Reventlov would need to do whatever trick you're doing to get Guix installed without root)

<lechner>f3n1x / Maybe you ran out of inodes yesterday? (instead of space)

<winter><cbaines> this particular breakage involved the derivations being different every time they're computed, the packages appear to have changed between every revision <-- (do we have an issue or a patch filed for this? that seems... dire.)

<graywolf>Before I take the final step and jump over to GuixSD, is there some "never to this" list of things I should avoid or be (more) careful about?

<graywolf>never do this*

<lechner>graywolf / where are you coming from?

<lechner>it also won't be your final step. it will be a new beginning

<graywolf>Right, sure :) I'm mostly interested if there is "common wisdom" what should I be careful about. Like, I assume manual change in /gnu/store are big no-no. I think I read somewhere not to touch /etc (except via reconfigure).

<graywolf>I would like to avoid bricking the machine or making some long-term mess on the filesystem. So I thought I would just ask :)

<lechner>i keep some mail server configuration in /etc/mail. do you have prior experience with linux?

<abrenon>hi guix

<lechner>hi abrenon

<graywolf>lechner: Plenty, currently running alpine laptop. But guix is bit foreign concept for me, so I want to be extra careful..

<abrenon>trying to build a haskell application from a guix shell environment (using runhaskell Setup.hs build), I get error messages during the link phase

<abrenon>such as "ld : ne peut trouver -lHSxml-1.3.14-BMgY89G5lTiLN8wPVkfaZq" (sorry for the french, "ne peut trouver" means "can't find")

<lechner>graywolf / it't will be exciting to you, but new. you are getting into a car like this https://www.youtube.com/watch?v=mYw81DtkkUU

<abrenon>does anyone know how to get a devel environment where I can compile my binary ? (all the previous steps of the compilation work, only assembling the binary fails)

<graywolf>lechner: lol that looks very uncomfortable :D

<mirai>do files like nginx.conf (or any curly brace block based configuration file) have some kind of specific type? (gitconfig is a INI-like file for instance)

<lechner>graywolf / it can be, for some

<lechner>abrenon / what is the error, please?

<abrenon>lechner: the whole message is https://paste.debian.net/1272686/

<abrenon>on this second run I had touched Main.hs, which got recompiled (showing that the compilation of hs modules in themselves, before linking, works)

<lechner>mirai / https://stackoverflow.com/questions/2936260/what-language-are-nginx-conf-files

<irfus>graywolf: thankfully guix seems to make bricking the machine *quite hard*. In my worst scenario so far, when I couldn't simply "switch-generation" and the store got messed up, guix was able to just verify and rebuild the corrupted/missing store items.

<mirai>lechner: I've seen it but that's just the description of it

<mirai>I'm asking whether files like these have some kind of name in common

<cbaines>winter, regarding the issue with the openmpi related packages, that was fixed in 9ae4846c502b75867b83180bb65d422ff838e4e6 after it was spotted

<lechner>abrenon / it's not finding your libraries, so your LD_LIBRARY_PATH should be adjusted. (sometimes people also use LIBRARY_PATH)

<irfus>graywolf, my own learning has been to not run `guix gc` too frequently. It really helps to have older system generations lying around a simple reboot and grub menu selection away.

<abrenon>I thought of something like that, I looked for L* in my env variables and stumbled upon LIBRARY_PATH, which, indeed, doesn't contain any libHS.* file

<singpolyma>Never run gc, just buy second drive ;)

<lechner>graywolf / on that note, i radically increased the size of my standard root partitions from 20-30 GB to 100-300 GB

<abrenon>two questions: when you say "sometimes people", do you mean developers ? is it like I can use one or the other ? or like, one or the other convention may be used and I have to figure out which one ?

<lechner>abrenon / what is the content of that variable, please? echo $LIBRARY_PATH

<abrenon>$GUIX_ENV and my home profile

<abrenon>which indeed doesn't have the libHS.*

<lechner>i am not sure it should

<abrenon>/gnu/store/98yxjbw7pb012pad3ghxbkvx4hzrn9ya-profile/lib:/home/alice/.guix-profile/lib

<abrenon>ok, no $LD_*, so I guess I don't have the choice

<lechner>are you in a development shell?

<abrenon>yes I am

<lechner>you can create the LD_ variable but for some reason i think it is falling out of use

<abrenon>before coming here, I thought maybe it was required to make another env with static output or something

<abrenon>but I found that the ghc-.* libs don't have such an output

<abrenon>and got really confused, sorry ^^ which is why I came to ask

<Kabouik>Is WebRTC supposed to work in Ungoogle Chromium ? https://web.parsec.app/ is giving me connection error, without much information more useful than "prefer the standalone client because the web app is very limited", only of course the standalone client is a .deb file.

<lechner>are you linking statically?

<abrenon>(building the whole package with guix build works flawlessly, it's just I thought I'd improve my dev process by getting the ability to recompile only what was needed, à la cabal, before producing the package with guix build)

<abrenon>hmmm I have no idea

<abrenon>I don't know what triggers a static or dynamic build

<abrenon>I'm just calling : runhaskell Setup.hs build

<abrenon>and I have no idea what the default is

<abrenon>or which I should prefer

<lechner>i think haskell binaries are a mix (unlike golang, which is all static)

<abrenon>ok

<lechner>i also have such problems often. development can be hard in Guix. Are you using the new 9.2 compiler from last week?

<lechner>cabal 3.6.2

<abrenon>nope

<abrenon>my system is from jan. the 30th

<lechner>well, the first thing i would do is pull. cabal 3.2 is over ten years old, i think. but it probably won't solve your issue

<abrenon>enabled dynamic loading with --enable-executable-dynamic (as found in guix build output)

<abrenon>it produces a binary, but of course that binary won't run because it fails to load shared libraries (still in the dev shell)

<abrenon>ok, I will upgrade just to get some fresher software, thanks for the info

<lechner>abrenon / again, that's because of (LD_)?LIBRARY_PATH

<abrenon>so if I find the correct /gnu/store/… folder to put there it will solve the problem ?

<lechner>i think it's either twenty of them, or a well-chosen location in your profile :)

<abrenon>how do I find which one ? how could we manage for guix shell to set that automatically (shouldn't it ?)

<lechner>you should be able to get the dynamic references to resolve with something like this (in Bash) LD_LIBRARY_PATH=$(profile)/lib:$LD_LIBRARY_PATH ./your-binary

<abrenon>during the setup phase, it apparently calls runhaskell Setup.hs configure with a --prefix option containing a <name-of-my-soft>-devel directory

<abrenon>shouldn't that contain everything ?

<abrenon>maybe what I'd like to do is just actually call guix build up to the configure part, then get dropped to a shell

<lechner>abrenon / guix shell currently doesn't! that deficiency is partly why i plan to propose a tracking of such settings required for the successful executions of machine binaries or scripts in package definitions. they would accumulate in the package shipping said binary. how to use that information is a separate issue that i hope to address with my upcoming exec-env kernel module

<abrenon>oh, cool : )

<lechner>that being said, i am relatively new. it is possible i missed an existing solution to those issues

<lechner>for now, however, you should be able to tinker with environment variables, but it may not be such a pleasant process (and has to be done every time you run the program)

<abrenon>well from where I stand your insight is still precious, even if you missed something

<abrenon>which is why I'm going to stick to guix build for now

<abrenon>but it's gonna be longer because my executable is behaving strangely (some line is apparently never run and I'd like to figure out why a lot)

<lechner>your issue, however, is merely about linking. languages like golang, rust and to some extent haskell use largely static binaries and are much easier to run (but also larger).

<lechner>is that a script?

<jpoiret>abrenon: is this your first time compiling some haskell program on guix?

<jpoiret>i've been using custom scripts to work on an haskell project with guix

<jpoiret>basically i mirrored the configure part of the build system

<jpoiret>and added the LD_LIBRARY_PATH parts so that I could run it from the build directory

<abrenon>lechner: no, not a script, a binary

<abrenon>yay, jpoiret has done the ugly part already ! \o/

<abrenon>can I have a look please ?

<jpoiret>yes, let me gather what's relevant

<lechner>i'd eventually like to be part of your team

<abrenon>(it's not my first time compiling haskell, but I usually just use guix build to hide away all the process; now as I was entering a possibly long hide-and-seek game with ugly putStrLn debug instructions, I wanted to speed up the process and avoid cluttering my /gnu/store/* for once)

<abrenon>jpoiret: thank you so much !! : )

<lechner>so as part of a larger debugging operation, this is extra frustrating to you

<abrenon>yep : )

<singpolyma>Are we talking about how cabal doesn't work inside guix shell ?

<lechner>kind of

<jpoiret>here's my ./configure.sh: https://paste.debian.net/1272694/

<graywolf>Is there a one-liner somewhere in guix (utils?) to execute a command and capture the output? Basically I'm looking for guile variant of `x=$(tty)'. Is there something like that already?

<abrenon>kind of, but I noticed that a long time ago and have written step 0 of what jpoiret did by sedding GHC_PACKAGE_PATH into a list of --package-db option to pass to runhaskell, unsetting GHC_HASKELL_PATH, and then calling runhaskell all the time pretending cabal doesn't exist

<singpolyma>Yeah, that's what I do. guix shell then GHC directly

<abrenon>well jpoiret's script looks very promising ! thanks for sharing

<jpoiret>and ./pre-inst-env.sh (but very specific to agda for some things): https://paste.debian.net/1272695/

<singpolyma>I don't have to change and env vars or pass any special switches that way

<abrenon>singpolyma: oh, interesting, so how do you do it ? (I remember for a simpler application having called ghc on the main module directly, but it messed up my beautiful src dir with a lot of .hi .o)

<singpolyma>abrenon: yes, exactly. I have a makefile that basically just does ghc main.hs

<singpolyma>And a clean rule find -name *.hi -o -name *.o -delete

<abrenon>tried it with my current program but it does some clever Paths_<my-app> with some virtual cabal-generated modules to get the version from within the haskell code

<abrenon>and so ghc -iapp -ilib app/Main.hs fails : (

<lechner>graywolf / for me it's a combination of system*, with-output-to-port and get-string-all https://www.gnu.org/software/guile/manual/html_node/Textual-I_002fO.html

<singpolyma>Ah, so there's a cabal dependency basically

<abrenon>yeah, you're right

<lechner>jpoiret / that cp -R for the package.db is annoying

<jpoiret>yep

<abrenon>jpoiret: trying your script, I still get the error loading shared libraries

<abrenon>when I try to run the executable I get

<jpoiret>the compiled executable?

<jpoiret>you need to use ./pre-inst-env.sh for that and adapt the paths to your specific app unfortunately

<abrenon>yes

<abrenon>oooohh I see, sorry I had missed the second script you uploaded

<lechner>my kernel module will make that pre-inst-env go away

<abrenon>I totally like the shebang of the second script !

<lechner>really, i think it should have been written in guile :)

<abrenon>now when you say "kernel module"… what exactly do you mean ?! what does linux have to do with it all ?

<apteryx>has anyone tried patman to manage their submissions? if you don't know what that is, you may want to read about it in the " [PATCH] doc: Document how to use Patman for patches submission" patch sent to bug #58813

<lechner>it intercepts the exec* family of syscalls to add exactly the environment needed for each executable https://www.man7.org/linux/man-pages/man3/exec.3.html

<mitchell>sounds fancy

<abrenon>so that would be a way to convince a process it's really living in the appropriate environment instead of having to forge a whole lotta env variable around it ?

<lechner>for now, it requires a file next to the executable that holds the variables needed. then we have to figure out how to construct that file

<antipode>lechner: Assuming I understand your goal here (letting the kernel set LD_LIBRARY_PATH path before starting the process), this is currently solved in Guix by (a) rpath or runpath, (b) patching dlopen instances, or (c) making a wrapper script with wrap-program.

<antipode>(a) and (b) are preferred over (c).

<lechner>i plan to propose that we propagate certain variables through the package definitions. it is a compromise that may or may not ease the reliance on profile, but it will eliminate any sort of wrapping

<lechner>(a) and (b) are not options for scripting languages, including Guile

<antipode>(b) can be done in Guile.

<antipode>And Guile could easily be modified to do (a).

<antipode>(There were some ideas in the ML for adding a #:compiled-file-name argument or such to #:use-module, and variations on that idea.)

<lechner>is that solution universal, i.e for Python etc?

<antipode>Furthermore, (b) is already done in guile-squee, as can be seen in its package definition.

<antipode>(b) is pretty universal for all languages that have an equivalent to 'dlopen'

<antipode>For (a): I don't see why it couldn't be done for Python, but I'm not familiar with how Python searches for whatever its equivalent of modules is.

<antipode>For (a): I implemented something like that for Perl in the past, but I didn't save it unfortunately.

<antipode>Basically, I wrote a procedure that looks for installed Perl scripts in the outputs of the package that is being build, and adds a "@inc = ["/gnu/store/dependency/...", ...]" line at the beginning of the script (I forgot the exact syntax).

<lechner>antipode / you mean this? https://github.com/guix-mirror/guix/blob/e9c1ea84fcf4a7f3da9aea9fbfe6136c75643c07/gnu/packages/guile-xyz.scm#L1071-L1074

<lechner>how can RPATH and RUNPATH, which are ELF features, be used for scripts, please?

<antipode>Yes, though I don't understand why you use the mirror instead of savannah.

<antipode>lechner: (1) they can't be, you need an equivalent of RPATH/RUNPATH instead of literally EFL's RPATH RUNPATH (e.g., the Perl script to set @INC at the beginning) (2) While RUNPATH/RPATH can't really be used in the script itself, it can be used in the libraries on which the script depends -- compiled Guile modules are in ELF!

<antipode>(Though Guile's linker doesn't support RPATH / RUNPATH ...)

<antipode>For Guile scripts, it's %load-compiled-path + %load-path instead of @INC.

<antipode>For Python, I assume something similar exists.

<antipode>Currently, some Guile software manually add %load-compiled-path / %load-path lines to their scripts, but in the future that could be done automatically by the distribution.

<antipode>(E.g., in Debian no such lines would be added, and in Nix and Guix they could be added in a post-install phase, and perhaps Nix could copy over Guix' code for such post-processing.)

<lechner>how about a shell script?

<antipode>The shell doesn't have a module system.

<antipode>Do you mean for setting PATH?

<antipode>If so, Nix has a tool for automatically replacing the program references with an absolute reference to the store.

<antipode>That tool could be packaged and used, instead of the manual 'substitute*' that is being done currently.

<antipode>If you mean something else, you'll have to elaborate, because sh doesn't have an equivalent to @INC/%load-path/$LD_LIBRARY_PATH/$LIBRARY_PATH.

<lechner>and i thought my kernel module was complicated!

<antipode>I just mean, IIUC, your plan is to include 'this env variable=that' information in ELF binaries and let the kernel use that. But the ELF linker is userspace, so I'd expect the response on kernel ML to be a ‘why not just add some setenv to main / why not modify ld-linux[...].so This can be done in userspace instead.’

<antipode>So you'll have to convince the kernel people instead.

<lechner>i think you are trying to intimidate me

<antipode>* 'So you'll have to convince the kernel people instead -> So you'll have to convince the kernel people, which appears pretty though to me.'

<lechner>i do not expect the module to have any utility outside Guix, and perhaps Nix

<antipode>Additionally, it can't be used in Guix, because Guix intends to support foreign distros, which probably wouldn't carry this Guix-specific kernel module, at least for a long time.

<antipode>‘i think you are trying to intimidate me’: Do you mean this literally, or do you mean 'the [situation / current solution / alternative proposed solution / ...] is rather intimidating'?

<antipode>(Looks like I misread the proposal a bit: ‘for now, it requires a file next to the executable that holds the variables needed.’)

<lain_>At what point in the installation process is it safe to abort (press ctrl+c)? I heard somewhere once that guix does all the linking in the very last step, and aborting at any other time is completely safe, but I forget where I heard that and don't know if it's true.

<jpoiret>installations should be atomic

<jpoiret>you should be able to ctrl+c anytime

<antipode>Summarised, while it might have fewer lines of code, a kernel module looks more complicated to me than currently-existing or proposed alternative solutions once taking in account compatibility issues, bootstrapping from another distribution, bootstrapping from something that isn't even Linux, cans of security worms (a separate environment variable file? Maybe a way to bypass permission bits?), social interaction (when upstreaming the

<antipode>..., API churn (when doing out-of-tree kernel module)

<lain_>thank you

<lain_>What about running guix install and sudo guix system reconfigure at the same time? Because it does allow you to do that, although it feels wrong.

<antipode>'guix system reconfigure' does system stuff, 'guix install' does 'user'-stuff.

<lain_>don't they both manipulate the store?

<antipode>Doing both at the same time should work perfectly fine.

<lain_>Okay, thank you

<antipode>Yes, but all store manipulation goes through the daemon, and the daemon doesn't care about whether it's 'guix system' or 'guix install'; all it cares about is building (and a little profile stuff)

<lain_>I see

<lain_>why isn't it possible to have 2 "guix install"s running at once then?

<antipode>* (building, substituting, offloading, gc)

<lain_>*permitted

<antipode>lain_: Are these two "guix install" done by the same user, or is this a multi-user system with two different users doing "guix install"?

<lain_>both scenarios

<lain_>I only know of the same user

<lain_>but I am interested in the answer for each

<antipode>In the first case: both "guix install" would modify the same profile ~/.guix-profile.

<antipode>First, it reads ~/.guix-profile to determine what the current packages are.

<antipode>Then it builds a _new_ profile in /gnu/store (via the daemon) that contains the current packages + the new packages.

<antipode>Lastly, it replaces ~/.guix-profile with a symlink to the new profile in /gnu/store

<lain_>Okay, I see why that would cause conflicts

<lain_>I assume that 2 different users can invoke 'guix install' at the same time?

<antipode>Yes, because

<lain_>different ~/.guix-profile s

<antipode> /home/foo/.guix-profile and /home/bar/.guix-profile are different.

<antipode>(Note: if you want to, you can have multiple separate profiles as a single user, by using the --profile/-p argument.)

<abrenon>jpoiret: thanks again, I'm having the time of my life debugging that executable with your script !

<lain_>interesting

<lain_>can user foo and user bar install the same program at the same time?

<bjc>i don't see why that would cause conflicts. putting items in the store should be idempotent. symlink generation is atomic. the only conflict would happen if the final profile symlink is swapped at the same time, but i don't see that as a particularly big deal, and is surmountable with locking

<antipode>lain_: Yes.

<lain_>Would the path in the store (including the hash) be the same?

<bjc>the entire point of the hash in the store is for content addressing. it guarantees that there are never conflicts

<lain_>If the build is reproducible the hash would have to be the same right?

<antipode>bjc: The problem is that (IIRC) no locking happens: if you do "guix install foo" and "guix install bar" concurrently, then "guix install bar" makes a profile containing 'old + bar', not 'old + foo + bar'.

<antipode>lain_: If both users are installing the exact (*) same version of the package, then yes.

<antipode>(*) This includes the exact same version of the dependencies of the package, transitively.

<lain_>Does the daemon overwrite the first version when the second user installs it, or just ignore it?

<lain_>I assume it ignores

<bjc>antipode: it shouldn't matter. the final profile is the summation of all installed packages based on the summation of all installed packages. simultaneous installs should be identical to installing quickly with undefined order between them

<bjc>what's the difference between "install foo, install bar" and "install bar, install foo"?

<antipode>bjc: There isn't. Remember, we are talking about concurrent installation here, not sequential installation.

<wdkrnls>Dear Guix, how do I get rid of these "note: source file X.scm newer than compiled X.go?

<lain_>If the order's different the hash will be different

<bjc>concurrent == sequential with undefined ordering

<lain_>But the hash could be the same if they were ordered alphabetically by the store paths

<bjc>so i'm asking why order matters

<antipode>bjc: ‘concurrent == sequential with undefined ordering’: That's err, false?

<bjc>what's the difference in this context?

<lain_>the hash will be different if the ordering's different

<bjc>no it won't

<antipode>concurrent: stuff running concurrently, like doing 'guix install foo&guix install bar' in the shell.

<antipode>sequential: 'guix install foo; guix install bar'.

<singpolyma>wdkrnls: find -name *.go -delete

<bjc>concurrency isn't parallelism

<wdkrnls>Is that what you would do for the guix repository?

<antipode>You are using a very different notion of 'concurrency' and 'parallelism' than I do, then.

<bjc>not that it matters in this case, anyway. that's at least one point of a "pure functional" package manager. the only thing that *should* matter is the inputs, which always create the same output

<antipode>'it shouldn't matter' != 'it doesn't matter'.

<lain_>f(1,2) != f(2,1)

<antipode>Guix isn't perfect.

<gnucode>hey guix people! Guess who's about to play with a Talos II? The goal for today is to set up a decent web browser on it.

<bjc>lain_: that's not the same thing an "pure functional"

<antipode>bjc: We are talking about "guix install", not "guix home reconfigure".

<lain_>bjc I didn't know that term, thanks :)

<antipode>"guix install" is imperative; for functional you need "guix shell" or "guix home reconfigure".

<bjc>install and reconfigure are highly synonymous. they're both responsible for creating profiles, the issue is where it puts them and how they're loaded. same as shell

<antipode>bjc: Unless this bug report has been solved, your claim that it doesn't matter is disproven by the bug report at <https://issues.guix.gnu.org/38649>.

<winter>cbaines: do you know why not using gexps would cause the derivations to be different *each time* they're calculated? that seems like a weird issue.

<winter>or am I misunderstanding the issue?

<mitchell>I think I saw something where calculated files were causing different derivations each time

<bjc>i'm not saying it doesn't matter. i'm saying it shouldn't, and i wanted to know why

<bjc>the reasons given earlier didn't make sense to me

<lain_>If there was a daemon responsible for writing the guix profile, would concurrent "guix install"s by the same user to the same profile be possible?

<bjc>or maybe there's some rationale about user confusion. or weird edge cases like installing multiple versions of things that i'm not aware of

<lain_>And the profile was in alphabetical order based on the store paths

<Guest6385>should I install Guix System through 1.4.0 ISO or would it be smarter to use the latest version?

<wdkrnls>Guest6385: I would stick to the ISO. One you get it installed you can upgrade.

<bjc>indeed, in #38649, ludo even says he's trying to avoid user confusion

<maximed>FWIW, I think that the race issue in concurrent 'guix install' could be solved by an atomic-compare-and-swap on the symlink.

<Guest6385>wdkrnls: Thanks

<wdkrnls>Guest6385: They do testing on the releases to make sure the installer works.

<lain_>Guest6385 if you download the 1.4.0 ISO and run "guix pull" "guix system reconfigure" "guix upgrade" it will be identical to the latest version. Installer version really doesn't matter so long as the substitutes are available

<Guest6385>wdkrnls: Yea that is what I thought, though I was not sure.

<antipode>(At least for commuting operations like 'guix install this' + 'guix install that', non-commuting operations like 'guix install this@0' + 'guix install that@1' appear unsolvable to me.)

<bjc>is there a symlink compare-and-swap operation these days?

<cbaines>winter, it's a combination of inheritance and how the arguments in the package definition end up in the derivation builder script

<cbaines>in this circumstance, there were #<gexp ...> things being written out in to the builder script for the affected packages, where the ... includes a memory address I believe, hence the builder derivation would be different every time it was computed

<Guest6385>if I use Guix as a server, can I seperate config.scm? Like for example I include nginx.scm and cgit.scm to prevent having a large file

<bjc>Guest6385: for reproducibility, you're best using a custom channel for that. but otherwise ‘load-file’ is available

<antipode>bjc: Complicated, but: <https://stackoverflow.com/questions/28417765/compare-and-swap-over-posix-compliant-filesystem-objects>. There is also a relatively new syscall, but I forgot the name so I don't know for sure if it can be used for atomic compare and swap.

<Guest6385>bjc: How does a channel help? Isn't it just for custom packages or packages not available? It is just configuration of those services.

<mitchell>Channels can contain any arbitrary scheme code which can be used in the creation of packages and services

<wdkrnls>My experience is that configuration files can create arbitrary scheme code which can be used to make packages and services as well...

<Guest6385>Ah, never seen someone use them that way

<wdkrnls>because they are scheme code, which is cool.

<bjc>antipode: ok. i've had to pull similar tricks in the distant past for locking over nfs (don't ask). i thought it'd be weird for something as high level as a file system object to get that kind of atomic operation

<bjc>Guest6385: channels are recorded as part of a system's provenance, and can thus be rolled back and shared the same as the rest of the system. ‘load-file’ introduces difficulties with that, which can be solved, but require extra, custom tooling

<antipode>bjc: atomic-compare-and-swap sounds pretty low-level to me for a file system operation (although it would be implemented in the kernel, not directly in the CPU+memory like the usual atomic-compare-and-swap, which might be where the disagreement over low-levelness comes from).

<bjc>the issue is going to be that you have to support arbitrary file systems through the vfs layer, which i see as… complex

<bjc>i suppose you could just punt on the syscall, like openat2 does, if it's not supported

<antipode>bjc: atomic swap already exists: renameat2 + RENAME_EXCHANGE (https://www.man7.org/linux/man-pages/man2/rename.2.html). It's not quite the same meaning of 'swap' though, and it doesn't have a 'compare', so I don't know if this syscall is sufficient.

<bjc>didn't know about that. thanks

<bjc>ah, there's an nfs caveat. go figure

<mitchell>Does anyone know how I can declare guile dependencies on a Channel? I want to write a activation services which uses this guile package https://github.com/paperclip4465/guile-mcumgr

<rekado>mitchell: a gexp can be extended with Guile packages

<rekado>it wouldn’t be a dependency for a channel, though

<civodul>in your activation snippets you would have (with-extensions (list guile-mcumgr) #~(begin (use-modules ...) ...))

<mitchell>I will give that a try!

<mirai>whats the rationale for service configurations to be managed by guix?

<mirai>why do we care for the configuration to be written in scheme?

<Guest6392>it checks for errors, reproducible

<bjc>proximally, it'd be hard to have a single config.scm which describes the entire system if the services configurations weren't in scheme

<bjc>you could use strings, but it'd be hard to read and manipulate

<lord_fauntleroy>hey guix, what's the most modern web browser packaged for power9 in guix?

<lord_fauntleroy>netsurf works, but it's javascript support is not so great.

<mirai>what's the goal though? To have 'introspection' on the configuration? An alternative to parsing the strings? Or simply turn everything to S-Expressions

<bjc>i wish i knew. it's not actually a decision i agree with. but i also don't know the full motivation

<mitchell>The biggest reason is that you can have services which are at higher level of abstraction which can generate these configs for the services it composes

<rekado>mirai: the goal is *not* merely to write configs in Scheme.

<mitchell>and if you have to generate configs anyway might as well be in scheme

<rekado>that would be a silly exercise in lossy translation

<Guest6392>you can use scheme to programmaticaly generate configs for example if someone has 2 different machines with different display you can adapt resolution

<mitchell>For example the cgit service generates nginx configs

<dthompson>composition of services is a big deal

<rekado>it’s much like asking what the point is of having package definitions at all when all you care about in the end is files in the file system.

<bjc>there are a hundred ways to skin that cat, though, like templating libraries a la puppet/ansible

<dthompson>guix services didn't compose well all that well in the first iteration

<bjc>and with those you don't give up fine-grained control

<dthompson>the service type re-architecture vastly improved things.

<rekado>system services (much like interconnected package definitions) are a higher level of abstraction for various system components

<dthompson>templating is a huge source of bugs

<rekado>system services in Guix go beyond just configuration of daemons

<dthompson>and also it's just text, you lose insight into the system

<bjc>i consider it a big deal to have to dumb my configs down so guix can handle it, though

<rekado>so in the end it’s about describing a complex system in a higher level language

<rekado>bjc: you don’t need to dumb things down

<bjc>it's also a lot of work to write the translation layers

<mitchell>Ludo gave a good talk on the subject circa 2019 but I cannot find the video now

<ulfvonbe`>in my experience system configuration is at its best when paired with a local repository, since there's always something that didn't make it into the current service definition

<mirai>rekado: sure, I should have added 'shepherd / daemon services' to the question

<dthompson>a lot of services have escape hatches for when you need it

<rekado>bjc: many services let you provide a text file as its configuration file

<bjc>rekado: that's just an escape hatch. it doesn't really answer the question. it just says "if you don't like it, here's a completely different thing"

<bjc>which, great! but not the question posed

<dthompson>I've spent many years doing system configure in the chef/ansible string template way

<dthompson>configuration*

<bjc>same. far, far too many years

<dthompson>guix is much much better :)

<mitchell>I've spent many years doing system configuration the Yocto way

<ulfvonbe`>meanwhile a heavily customized local set of *packages* means a nightmare of ungoogled chromium getting your cpu so hot you can actually smell the fumes from the nearest power plant

<mitchell>and guix is much better

<dthompson>I can only imagine how awful building chromium must be. I figured out how to build V8 last week and that was quite the mess to figure out and it takes like an hour to build.

<antipode>Except for quotation being neglected by service writers, a benefit of doing things with Scheme records is that you only have to worry about quoting rules once when implementing the service in Guix, and not always when using the service.

<mirai>disregarding the escape hatch for now, the thing is not everything is easily translatable to guix records

<civodul>mitchell: this talk? https://fosdem.org/2021/schedule/event/gnuguix/

<mirai>nginx.conf-esque files are one example

<dthompson>I actually would like a sexp nginx config representation at some point

<mirai>ini-like files do not map cleanly to records if they can have 'arbitrary' blocks

<mitchell>civodul: No, I haven't seen that one yet! I'm thinking of the one where you said it was funny that the operating system guys were only now learning what system services were

<dthompson>for arbitrary data, sexp trees representing the syntax of the target format is the way to go, imo.

<mirai>alists work on some of these cases

<dthompson>the translation layer will prevent escaping bugs and stuff

<civodul>mitchell: wait, there's also that one: https://archive.fosdem.org/2017/schedule/event/composingsystemservicesinguixsd/

<mirai>dthompson: then we're looking at the "Everything in scheme" world

<mirai>**Everything in sexps

<antipode>mirai: I'm not finding any search results for INI 'arbitrary' blocks

<mitchell>civodul: that's the one

<antipode>Where can I find documentation on what an 'arbitrary' block is?

<dthompson>mirai: yeah that's a good thing, imo!

<mirai>antipode: by arbitrary I mean when you can have [user-specified-name-here] data = value ....

<dthompson>and we can fall back on stringy things when we're short on time

<mirai>I can find something that can serialize/deserialize some file or text, provided a "description" of the format

<mitchell>dthompson: You can also write your own stringy compilers if you feel like the guix provided configuration abstraction isn't quite right

<antipode>mirai: Sounds like a straightforward case for alists to me. (record [...] (user-data `((data . "value"))))

<mirai>but that's not the same as expressing things in scheme

<antipode>(Most of the stuff is in [...], the user data in a separate alist.)

<mirai>that's just bindings to a parser

<dthompson>it is because you can define how scheme values translate to the output format

<mitchell>mirai: Isn't that what expressing things in scheme is?

<mirai>antipode: it is straightforward with alists (or lists in SRFI-233 format)

<mitchell>its bindings to a parser, but also a list that can be manipulated

<antipode>Bindings to a parser sounds like a nice thing on its own to me.

<dthompson>provided the syntax isn't daunting, I like to make sexp->whatever-format translators.

<antipode>mirair: I just wrote that?

<antipode>‘mirai: Sounds like a straightforward case for alists to me. (record [...] (user-data `((data . "value"))))’ + ‘(Most of the stuff is in [...], the user data in a separate alist.)’

<dthompson>I did one for graphviz dot format recently. helped me out.

<antipode>mirai: WDYM with ‘antipode: it is straightforward with alists (or lists in SRFI-233 format)’?

<dthompson>making schemey representations of foreign formats sounds like a good topic for a blog post

<mirai>antipode: but alists aren't really "the guix way to go" per "Relocating some procedures into (guix utils)" in guix-devel ML

<dthompson>the rationale + examples of it done well

<mirai>the alist escape route is what I do in mpd-service-type

<mirai>dthompson: the binding thing I was talking about was ASN.1

<antipode>mirai: I only proposed alists for the user-data stuff (which, IIUC, is by definition something you can't recordify).

<mirai>s/was/is

<mirai>antipode: right, there's always going to be that case

<mirai>escape hatches are inevitable

<antipode>mirai: Additionally, on ‘alists aren't really "the guix way to go"’: that e-mail explicitly mentions they are useful for define-configuration stuff: https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00331.html

<fruit-loops>"Re: Relocating some procedures into (guix utils)" https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00331.html

<dthompson>mirai: ah I'm not up-to-date on the context here

<antipode>(That e-mail considers alist? stuff ok for service stuff.)

<mirai>though the main essence of the question is: are we looking to represent everything as sexps or will a serializer-deserializer work as well

<antipode>It also only says that the _predicate_ alist? is bad in ‘real code’, it doesn't say anything about just using alists.

<antipode>That's the first time I have heard of that question.

<mirai>i.e. how to best represent nginx.conf for guix?

<bjc>one of the largest downsides to sexping-all-the-things is that you lose your ability to use a search engine to answer questions

<antipode>Records, maybe some alists for more free-form parts and as an escape hatch, and also an not-recommended file escape hatch.

<mirai>antipode: right, we can conclude that alists for user-data is not a problem

<bjc>especially for something like the nginx.conf, that's a gigantic loss

<mirai>that's just for user-data

<mirai>bjc: they needn't be mutually exclusive, escape hatches will be there

<antipode>It could be extended to non-user-data as an escape hatch. It's not like Guix can easily tell the difference anyway.

<bjc>i don't think that's an answer. there should be blessed ways of doing things

<antipode>Proposed blessed way = records, and alists for user data.

<bjc>and a hodge-podge is just more confusing. what happens when you start with sexps and have to move to a real config?

<mirai>bjc: that turns into a dicotomy of "all-as-string" vs "all-as-scheme"

<antipode>To my understanding, real config = records + some alists, which is rather S-expy, so I don't understand the question.

<bjc>i disagree. i think templating is the right solution to this problem

<mirai>bjc: the configs are serialized at the end of the day

<Reventlov>Re.

<Reventlov>How do I prevent this annoying message from showing up ? https://0x0.st/HzeA.txt

<Reventlov>( hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these lines: […] )

<antipode>bjc: But, string escaping, interpolation and inheritance?

<mirai>antipode: does nginx.conf look like something that maps cleanly to record+alists?

<Reventlov>the thing is installed, the env var is set…

<mitchell>bjc: I'm not sure what you are after. Guix services/system are already a foreign planet which you are not often going to find help from upstream packages. If you need that help you can always use `plain-file` and follow the arch wiki. How would templating solve this issue?

<bjc>antipode: learning tech is required for using it. templates aren't that complicated and can be wrangled

<bjc>everything is trade-offs. i disagree with the one made here, that's all

<mirai>some of the directives can nest in arbitrary order and depth

<antipode>bjc: Records are simpler than template and simpler to wrangle.

<bjc>until you have to leave what they can do, or you have to have better docs than what guix can offer

<antipode>mirai: alists could be nested.

<mirai>so nginx.conf would be a big gigantic alist?

<antipode>I don't know about the cleanness, but from what I remember, nginx.conf's grammar is structured and somewhat recursive, so it would work out, I think.

<antipode>mirai: No, it would be a big record. The alist would just be for escape hatch and for user data stuff.

<antipode>Looking at ‘(guix)Web Services’, this is already implemented to a limited degree, in 'global-directives'.

<mirai>antipode: locations can be nested for instance

<antipode>Yes.

<antipode>Agreed.

<antipode>But I don't follow the 'for instance'. Instance of what?

<jlicht>bjc: I'm confused; why don't you just use templating, if that's what you prefer? Or are you saying you'd like some form of templating to be the blessed default?

<mirai>antipode: nvm, I was mistaken

<mirai>you can have records with more records in them

<mirai>as a field

<antipode>Ok, I now follow.

<Guest6394>does someone have a guix home example configuration which is fairly new? AFAIK guix home has changed and most stuff is from several years ago

<Guest6394>Reventlov: I added that env var in .profile on the root acc as well as installed it on the root acc with just guix install glibc-locales. I do not have those warnings

<antipode>Guest6394: https://paste.debian.net/1272720/

<fruit-loops>"debian Pastezone" https://paste.debian.net/1272720

<Guest6394>thanks

<mirai>the interest in the representation of service configuration is that services usually follow some common patterns

<mirai>their config is: flat-like (tor.conf), ini-like (krb5.conf), bracket blocks (nginx.conf), XML or json

<mirai>it'd be convenient if we could have some sort of generic reusable facilities to easily generate configurations for these services

<mirai>rather than N+1 different implementations of the same wheel

<mirai>(not just generate, but a consistent pattern of usage as well)

<mirai>**usage pattern

<antipode>mirai: The package 'guile-ini' exists. Perhaps it could be used.

<mirai>antipode: what about SRFI-233? I know it's not in Guile (yet?™) but we could use the format to keep things portable/uniform for those concerned

<fruit-loops>"SRFI 233: INI files" https://srfi.schemers.org/srfi-233/srfi-233.html

<ellysone[m]><apteryx> "ellysone: why are you using..." <- Sorry what?

<tricon>fruit-loops: Interesting. For "configuration language" my own little programs, I ended up just creating list structures that I then consume into a record/GOOPS. One problem I have with plaintext configuration forms is that they either can't support anything generative or arguably complex aside from key: value, or such things become built into/on top of them, like with YAML/Jinja2, which becomes its own mess.

<tricon>Part of what I find so appealing about Guix is that it's configured in its base language.

<tricon>It ends up becoming much easier to program and reason about my configuration.scm once I understand the DSL than to attempt to map a plaintext DSL into a programming language.

<lechner>yeah, it's truly universal

<tricon>*For a "configuration language" for...

<winter>Is there any reason some code (e.g. (guix least-authority)) uses auto load and use-module?

<lechner>well, has the potential to be universal in the sense that it can configure all others

<tricon>lechner: yes.

<winter>oh, hm, some use #:select and #:autoload

<winter>guess I should look into the difference

<mitchell>let us know what you find!

<tricon>lechner: and that's a good point: Guile ends up becoming the lang "on top" of the plaintext DSL that the target service meagerly supports. Thus rather supporting the point that configuration is/is-often code.

<tricon>(or should be.)

<winter>ah i see, hm

<winter>interesting

<winter>guess my question still stands -- why isn't autoload just used for everything in that module?

<jpoiret>winter: autoload basically just defers the use-module invocation

<winter>e.g. file-system-mapping-source is only used in a gexp

<winter>yet is autoloaded

<winter>but also use-module'd in the gexp

<jpoiret>i don't know if there's a performance cost associated with it

<jpoiret>one thing though, is that you can't autoload macros

<mitchell>tricon: runtime configuraiton is just a form of extreme late binding. If you consider that the same program run with a different configuration file is a different program then there is no difference between patching the source at compile time or adjusting a config at runtime. It is just an optimization to not have to recompile everything

<tricon>mitchell: right, I would agree with that.

<mitchell>All i mean to say is there is no need to qualify the statement config = code

<ulfvonbe`>now I'm just imagining a config file that is a .so

<mitchell>ulfvonbe`: why not?

<mitchell>it may be one solution to getting suckless software to integrate with eachother lol

<mitchell>get them all to load a shared lib

<ulfvonbe`>heh suckless is what I was thinking of too

<tricon>mitchell: In all technical senses, I do agree. Colloqually I think it has value for those that see config as separate from code, which seems common among users of programs that are not programmers.

<mitchell>tricon: Yes i am dealing with the same issue at work. I have to be careful not to use the phrase "recompile the system" when describing guix reconfigure. recompilation implys security checks that config file swaps do not but my stance is that config file swaps should require the same security checks

<tricon>mitchell: Actually, I agree with you there as well.

<winter>civodul: Why does (guix least-authority) autoload file-system-mapping etc., but then only uses them within a gexp (which has (gnu system file-systems) in use-modules)?

<jpoiret>winter: well if they're only used in a gexp you can probably remove them

<mitchell>I can unsecure a system with a bad ssh config file just as easily as a bad ssh binary. even easier perhaps

<jpoiret>it might be an historical thing

<civodul>winter: it's used in an ungexp

<civodul>if you comment out the #:autoload form, you'll get unbound variable warnings

<tricon>I think Guix makes the code/config bridge, if you will, rather well: Do you have to be a Guile/Lisp programmer to use Guix SD? Nope. You can view the configuration files as "slots" to be filled. "Slotting" an SCM file isn't really any different than "slotting" an Nginx conf file.

<tricon>mitchell: I would love to be able to declare security assertions.

<mitchell>It's possible with guix

<mitchell>come up with some scheme code that inspects an os declaration for this or that "securty problem"

<mitchell>you could even chain several together from different organizations

<tricon>Right. One of the beautiful possibilities of its architecture.

<tricon>Composable security.

<tricon>Yes.

<mitchell>it is the dream

<jpoiret>winter: by the way, most questions about "why does X use Y" can be answered by a quick git blame (very easy with magit with a C-c M-g b)

<mitchell>It also gives a way to talk about audit results in concrete terms. The config.scm is what is is and you can pass it around and reproduce it compare proposed fixes

<lechner>okay, that's enough belly rubs :)

<lechner>we all agree it's best OS in the world!

<tricon>mitchell: Great point as well. What's great additionally is this becomes a foundation for user-friendliness: my typical friend may see the appeal of a private, web-based file sharing service, but they have no knowledge of how to run one. If I can hand him a mini-PC with Guix, and they can just add the lines they need to services, or I can share a config file, or someone writes an ncurses TUI, it becomes much easier to expand the

<tricon>decentralized web as originally envisioned.

<mitchell>Are you sure?

<lechner>actually, some of those things ought to go on the website

<lechner>tricon / please consider starting a marketing team

<tricon>lechner: I'll start spinning another plate ^_^

<jpoiret>currently trying to build sway on core-updates 🤞

<tricon>jpoiret: Godspeed.

<lechner>is there a needle on the core-updates acceptability meter?

<jpoiret>lechner: wdym?

<jpoiret>i'm just trying to see if there are issues with the programs I actually use first

<jpoiret>then i'll try the sample system configurations in vms

<jpoiret>can't wait to debug gnome

<lechner>i can't wait and have been following the sporadic messages, but cannot tell how much progress there has been in attempting to build and merge it

<jackhill>jpoiret: hehe. Oh that reminds me we should update gtk there as well

<jpoiret>well, andreas has been hard at work

<jpoiret>jackhill: no more with the core-updates patches! we need to just finish merging it and remove it

<jackhill>I guess not enough stuff depends on gtk yet that it can be done in master. Is wayland updated on core-updates?

<jackhill>ACTION checks notes

<jpoiret>jackhill: yes, we have 1.21

<jackhill>oh yeah, gst-plugins-bad should probably be replaced with gst-plugins-bad-minimal to reduce closure size in gtk.

<jackhill>ACTION has too many unfished patches :)

<jpoiret>protocols is 1.29

<jackhill>jpoiret: cool!

<jackhill>will be easier to work on master for me anyway where substittues are available?

<jpoiret>imo we should wait for the core-updates merge to happen before adding more patches

<jackhill>sounds reasonable

<jpoiret>the core-updates/staging branches will hopefully disappear and instead there'll be feature branches, which will allow for changes to get merged faster

<jpoiret>(and to not pile completely unrelated patches in a single unmanageable branch)

<jackhill>heh

<jackhill>odd: rnp uses github /archive URLs, but then offers PGP signatures https://github.com/rnpgp/rnp/releases

<fruit-loops>"Releases · rnpgp/rnp · GitHub" https://github.com/rnpgp/rnp/releases

<jackhill>I checked and it matches, but I wonder if github would still change them out from under.

<jackhill>even the oldest release they have matches. I wonder if tha means they'd be safe to use

<jpoiret>we don't really need to check signatures though, right?

<jpoiret>as long as we can provide a checksum

<jpoiret>first obstacle: building llvm on a thin laptop :( i'll probably wait until CI has substitutes for it

<jackhill>jpoiret: right, but it's helpful for me to know I'm putting in the right checksum. Also, it looks like `guix refresh` has some machineary for checking signatures https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-refresh.html

<fruit-loops>"Invoking guix refresh (GNU Guix Reference Manual)" https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-refresh.html

<graywolf>When running guix home reconfigure, I'm getting `Use of `load' in declarative module (#{ g136}#)...' Is that something to be worried about? It is just a warning, but I still would prefer not to have it there.

<nckx>Hi Guix.

<mitchell>graywolf: What are you loading?

<lechner>graywolf / i get those too, and do not know where they are coming from

<lechner>actually, i think they come from my own service modules

<nckx>jackhill: /archive/ URLs aren't stable, but you could (if you wish to go that far) validate the tarball signature, then compare its contents against a git-fetch which you use in Guix.

<graywolf>mitchell: Nothing as far as I can tell... https://paste.vpsfree.cz/TR-qmS8p/

<jackhill>nckx: yeah, that's what I though. It's sort of odd that they produced a signature over those unstable URLs…

<nckx>Not really, not many people know (or care…) that they're not static.

<mitchell>Does anyone know how to get $(guix vm) --magic-network-options to connect to my local network? i see i can forward ports in the ssh example but from the vm I can't ping the 192..0/24 network but I can ping google

<jackhill>academic quetion: supposing I has a stable tarball with a signature. How would I get guix to automatically check it. Do I have to specify the key-fingerprint somewhere? I would think it would be a pakcage property, but I can't find an example.

<mitchell>Do i need to so some socat magic or is there a qemu way to do it

<mitchell>jackhill: You could add a build phase before 'unpack which runs whatever you need to check it

<jpoiret>there are a couple of guix files which use load for good reason. The warning should be harmless graywolf, lechner

<nckx>jackhill: I don't recognise the functionality you describe as part of Guix… ‘guix refresh’ can verify GPG keys, but it's upstream-specific & you provide the keyring.

<jackhill>nckx: ah, not I think I just misread the refresh manual

<nckx>Sowwy.

<nckx>Having key( fingerprint)s checked into Guix would increase transparency.

<nckx>mitchell: I don't know, but do beware that ping isn't a reliable way to test this. It's unlikely your end goal is sending ICMP packets 😉

<mitchell>it's a start

<nckx>What?

<mitchell>sending icmp packets

<nckx>No.

<mitchell>actually i'm going to try adding the network to the route manually and see what happens

<nckx>It's a dead end not worth pursuing unless it's your end goal. You'll need to do more work to get ICMP to work than TCP.

<mitchell>how do you mean?

<nckx>Requires more privileges/set-up.

<mitchell>I want to send udp packets to an address on the local network

<nckx>Right. Then test UDP.

<mitchell>nckx: Do you some literature I could read about what I would have to set up? I always use ping to test the connection if the application doesn't work. You are saying this isn't a good way?

<nckx>By the way… the reason I said ‘I don't know’ above is that I can't create a VM (with working Internets) that *can't* access the LAN.

<nckx>That includes UDP, apparently.

<nckx>mitchell: nc -u host port (on the VM) → nc -lup port (on the LAN host), for example.

<jpoiret>civodul: about the cuirass time-outs, do you have any new info? I don't know how I could try to test this out locally/reproduce it, since it seems like a very "big CI" problem

<nckx>mitchell: Ping tests whether you can send ICMP packets, nothing more. Some networks block ICMP or otherwise mangle/limit it. Because it requires more privileges, it's not enabled by the same QEMU options. Etc. It's like trying to test whether you can import a T-shirt into your country by importing cocaine.

<nckx>Just… try the T-shirt.

<mitchell>Cocaine would be a good start though. It tests more edge cases

<winter><jpoiret> winter: by the way, most questions about "why does X use Y" can be answered by a quick git blame (very easy with magit with a C-c M-g b) <-- This doesn't help here as the questioned line was introduced when this module was.

<nckx>mitchell: If your end goal is importing coke I agree. My point is that's a rare use case, and that setting up a drug-traficking network is unreasonable overhead if you'll only use it for sending tees. What a silly example I chose.

<mitchell>All i'm saying is requirements change

<winter><civodul> if you comment out the #:autoload form, you'll get unbound variable warnings <-- I presume you're using autoload there to avoid the perf hit(?) of loading it immediately, even if the gexp is never used?

<nckx>They apparently have during this very conversation. You do you.

<mitchell>lol

<winter>wonder what kind of error you'd get if you removed the use-modules from the gexp but not the autoload

<nckx>ACTION thinks we have a foo-over-icmp tunnel in Guix but forgot what it's called.

<nckx>mitchell: So… does that netcat work?

<nckx>If possible to test, that is. I don't know what kind of device this is.

<jpoiret>winter: the (gnu system file-systems) is used both inside and outside of the g-exp

<jpoiret>hence the autoload outside and the use-module inside

<nckx>mitchell: And do you have generic ‘Internet access’?

<jpoiret>you can't remove the use-module inside the g-exp either, or procedures like `file-system-mount-point` won't be available

<winter>jpoiret: i'm confused as to why it's not just use-module'd outside of the gexp, then

<mitchell>nckx: I am compiling now

<winter>(why those specifically, that is)

<winter>i assume that has to do with the unbound variable stuff that ludo mentioned

<mitchell>I can ping the generic internet but i guess that doesnt mean much

<mitchell>ok that is working, I can see the link lights blinking when sending the data to the device

<nckx>mitchell: You can ping the Internet from within the VM? Then you can already do more than I can in the VM that can UDP my LAN just fine.

<nckx>It can't ping anything, for the reasons given above.

<mitchell>I have much to learn about networking

<winter>jpoiret: e.g. spec->file-system is only used within the gexp

<winter>but is autoloaded out of it

<winter>so i assume that's the unbound variable stuff

<nckx>mitchell: Random link but seems legit: https://superuser.com/questions/787400/ping-doesnt-work-when-using-qemu-user-mode-networking

<winter>i'll try poking at it and see if i can better understand it by randomly removing stuff

<winter>lol

<mitchell>nckx: That sounds exactly my issue except I suppose the router was filtering the local network. I would try to ping the router and it would resolve the hostname but the pings would fail

<nckx>Eh, fun. :-/

<nckx>Routers are generally hell-things.

<lechner>as far as the lights are concerned, i think the only knowledge to get gained is that there was no traffic when they remain dark

<lechner>be

<mitchell>Well if the lights at the destination blink in time with my hitting the keyboard I take it as a good sign

<nckx>Epistemology Thursdays at #guix.

<winter>the manual only mentions using source-module closure as done here, nothing about having to autoload outside of the gexp

<mitchell>my embedded example project is almost complete! Just need to finish the service which implements the firmware update and it'll be done and I can rest

<nckx>\o/

<lechner>that sounds like the hard part

<winter>ahh, ungexp... okay.

<unmatched-paren>hello guix :)

<mitchell> https://github.com/paperclip4465/guile-mcumgr It's almost done! the guile code works and i'm in the weeds debuggin the vm network. But the vm can update the device from the repl so its a good step

<fruit-loops>"GitHub - paperclip4465/guile-mcumgr: GNU Guile implementation of Zephyr's mcumgr tool" https://github.com/paperclip4465/guile-mcumgr

<nckx>Bizarrely, no Scheme or even Lisp submission yet: https://codegolf.stackexchange.com/questions/258511/longest-valid-parentheses

<lechner>ACTION wishes someone would write a Guile program that configures OpenWRT via UCI

<nckx>mitchell: This is neat. You may think you're almost done, but this looks like it's going to end in a guix deploy(-like) back-end.

<mitchell>nckx: indeed it is

<lechner>love it!

<mitchell>It's a service which uses this library to make sure the device at the end of the given address is running the correct firmware and to take steps up update it if it's not

<rekado>nckx: “(call-with-input-string…” oh, already too many characters

<nckx>:)

<patched[m]>I am attempting to build a package using the ant build system, but which specifies the build file in another directory than the root directory. How can I make ant-build-system use this? Even better, how would I go about to find out?

<mitchell> https://github.com/paperclip4465/guix-embedded-example Here is the project so far. It consists of an embedded device which measures the "room" temp and publishes the results to an mqtt broker running in a vm along with another program to log/process

<mitchell>Hopefully the mqtt broker service can be refined and contributed to guix

<nckx>patched[m]: It should suffice to (add-after 'unpack 'chdir (lambda _ (chdir "some/place/else"))). I don't use Java, so my amateur answer to how I found out was: have that hunch, then verify that some packages (e.g., java-forester) do that, by grepping gnu/packages. :)

<lechner>Hi, is 7 TB a good estimate for mirror space for one architecture, or is that for all of them?

<nckx>If I'm estimating right that should suffice for about a year's worth of all of architectures, if you stick to one compression method (lzip or zstd; I would go for zstd).

<nckx>ACTION didn't even use an envelope though.

<nckx>That's a lot more space than I was expecting you to get.

<lechner>Emacs scratch buffer?

<nckx>Not even.

<lechner>i think the gentleman is going to fall out of his chair. How about six months?'

<nckx>mitchell: I like this.

<mitchell>:3

<patched[m]>nckx: thanks!

<lechner>ACTION gently points out ZeroMQ as a faster alternative https://cds.cern.ch/record/1391410/files/CERN-ATS-2011-196.pdf

<winter>nckx: Did you come to a conclusion/figure out anything else with regards to the (gnu packages golang) breakage? I recall you saying you'd look more into it yesterday, did anything come of that? As I mentioned in the thread, I think it's the correct solution (at least in the short-term, because who knows if there are any other underlying issues that

<winter>such a cycle manifested), and should probably be applied ASAP if you agree.

<lechner>good bye, bot

<nckx>lechner: So that 3.0T figure I quoted was: *all* successful builds on berlin since 22 Aug 2023, all branches (including experiments/mistakes/…), all architectures, zstd-compressed. You can extrapolate from there. It's one big directory with .nars & .narinfos, there's currently little (nothing?) in way of filtering ‘I only want to mirror master/the past 6 months/…’.

<nckx>I think I must retract my suggestion to use rsync for this use case, it's going to be a tough fit. I read some SJTUG stuff; their ‘mirror’ is what I'd call a caching proxy: it's reactive, not proactive. This is also how my (very simple nginx) Guix cache works. IMO it's much easier & faster to get to a working set-up that way, that gives you 96% (or any other random number you prefer) of the speed-up of a full-sync mirror.

<lechner>nckx / i think that's the wrong way to calculate it. what about those packages that were not rebuilt in the past six months (if any)?

<nckx>To calculate what?

<nckx>It's not a calculation.

<lechner>that 3.0T figure ....

<nckx>I'm just telling you what we have, not what you wish we had. Those packages not built in the past six months aren't there.

<nckx>They have been GC'd, RIP.

<nckx>And yes, there's no way for your mirror to request specific .nars, including the closure of ‘all packages on current master’ etc. That's the rub.

<lechner>aren't there any that were not built in the past six months, meaning that downloaders would get a copy from before then?

<nckx>Not from berlin.

<lechner>because it only keeps the past 180 days?

<nckx>It shouldn't have, policy-wise, but that's what happened.

<nckx>No way to undo that.

<lechner>what if there are packages that were never rebuilt since then?

<nckx>They have been GC'd, RIP.

<lechner>should they not be rebuilt?

<lechner>will they ever be?

<lechner>SJTUG uses this, by the way https://github.com/sjtug/mirror-intel

<nckx>They are not currently scheduled to be rebuilt. Someone with a lot of spunk and free time and SQL knowledge and access to berlin could script together a script that could rebuild & cache them. I'm not currently aware of anyone with plans to do so.

<Guest6317>is nars a compressed file? cant find anything for it

<nckx>Guest6317: A nar itself is similar to tar, but the ones we serve over the network are compressed.

<Guest6317>ah got it

<Guest6317>which cmd handles that? I do not have a nar cmd

<nckx>lechner: Yes, that's what I was trying to steer you towards. Your opinion on a demand-driven caching proxy, like SJTUG or simpler, rather than a traditional pull-style mirror.

<Guest6317>what is SJTUG

<nckx>Guest6317: ‘guix archive’, but it's mostly internal. Users aren't *really* expected to pass around floppies with nars on them, although it's possible.

<nckx>Guest6317: https://mirrors.sjtug.sjtu.edu.cn/docs/guix

<lechner>that only illustrates what i am trying to say, however: the most recent copies of packages rebuilt in the past six month most certainly take up much more than just half of 7 TB. or conversely, the whole year may only take 3.5 TB when extrapolating from 3.0 TB

<nckx>Guest6317: In practice, whenever you see substitution happening, that's Guix downloading a nar and unpacking it for you, and that's all most users ever see of that.

<Guest6317>ah, that is why i never heard of it. always wondered what that /nar/ path means

<lechner>nckx / what was your comment to me about nars about, please?

<nckx>lechner: I did not claim it extrapolated linearly 😉

<nckx>Which comment?

<lechner>there's no way for your mirror to request specific .nars, including the closure of ‘all packages on current master’ etc. That's the rub.

<nckx>To me, that was the obvious answer to your ‘how could I know how much storage I'd need for the past 6 months, and [implied] download only that’.

<nckx>You can't, really.

<lechner>i can't get a list of available substitutes?

<Guest6317>if someone would archive all packages ever built, how much space would it require?

<nckx>lechner: You could list berlin's /var/cache/guix/publish/zstd over rsync. You'll get a list that looks like this: https://paste.debian.net/plainh/0ae41d1d To do anything more with that list, your mirror client has to be very clever, computing all derivations like ‘guix weather’ does.

<nckx>‘You could list’ is hypothetical here. But it could be arranged.

<lechner>i see

<nckx>I'm still trying to steer you towards caching.

<nckx>Guest6317: I have no idea, since we haven't been doing so. Many terabytes. The plan is not to delete anything from now on until we fill up 100T, then we'll have to see what we do then :)

<Guest6317>nckx: On the paste you send, what are the numbers after the time? I guess narinfo is what the nar contains like packages and which version?

<nckx>There are no numbers ‘after’, that's all time, find just likes to be very precise :)

<lechner>nckx / i do plan on caching

<nckx>Oh good.

<nckx>I do think that's the better approach, and with the size you were implying (even if you don't manage to get 7T 😉) churn shouldn't be too bad.

<Guest6317>nckx: Not an expert but kinda sounds not that hard to accomplish. there are nowadays 30TB SSDs (they also cost 30k) but over time it is probably not even going to be that unrealistic, though computing all packages would be another question

<nckx>lechner: I thought someone would give you a mere 500G out of pity or so.

<lechner>Guest6317 / those are microseconds or so

<nckx>Yep, just decimals bein' decimals.

<lechner>nckx / i am about to test the limits of the pity i was able to engender

<lechner>do you feel for me?

<Guest6317>do you cache by using rsync and mirror it?

<nckx>Guest6317: Yes, it's some metadata about the .nar archive itself. But not packages/version. You can see for yourself, by fetching any <hash>.narinfo you see there, e.g., https://paste.debian.net/plainh/d637ac81

<nckx>lechner: Always.

<nckx>Guest6317: No, my usage of ‘cache’ was to contrast with ‘rsync everything’. I use it to mean ‘on first request, fetch from upstream, then keep it as long as possible and there's interest’. Most traditional mirrors don't do this: they download the entire upstream using rsync unconditionally. We have too much data and too little metadata to make that realistic.

<lechner>nckx / okay, i hit send

<nckx>Guest6317: The only way to find out what's in a .nar is to download the .nar and look inside—much like .tar. Not efficient, and it's why guix doesn't have a ‘which package provides this file’ search yet. Might change. We'll see.

<nckx>lechner: Godspeed, and thanks.

<nckx>ACTION away.

<lechner>a nar browser is coming

<lechner>what i really need is the derivations

<Guest6317>Well, I asked since I plan to cache Guix as well so I do not hit upstream every time by reinstalling and testing in vms

<lechner>where are you located, please?

<Guest6317>and I think the manuals says something about using rsync

<Guest6317>lechner: Do you mean me or someone else?

<lechner>yes, in terms of geography

<Guest6317>germany and you?

<lechner>u.s.

<lechner>i get 700 kB/s from berlin on a good day

<Guest6317>lucky, storage here is twice as expensive

<lechner>i know. i am from berlin

<Guest6317>hm interesting, shouldn't it only affect ping? I dl full bandwidth

<Guest6317>oh so you are actual german as well but currently live in us?

<lechner>since 1992

<lechner>it's a peering problem. normally, i'd say facebook and friends aren't interested in the research data available via FDN, but in this case the issue appears to be in germany

<Guest6317>what is fdn?

<lechner>sorry, DFN. 200 Gb/s for science https://www.dfn.de/

<fruit-loops>"Startseite - DFN" https://www.dfn.de

<Guest6317>could you technically just rent a server and dl it from him?

<Guest6317>since I understand currently the problem is something with DFN since you are U.S. so you would just rent a german srv that has no problem dling it and from that you can dl it full speed. you do that once and after that slow bandwidth for incremental updates isn't that big of a deal

<Guest6317>or am I mistaken?

<Guest6317>cost would be something like max 5usd

<lechner>like you, i need the slow connection between the mirror and berlin, not the other way around

<lechner>for 4 TB ?

<Guest6317>well I meant you would just rent it to dl it full speed on your own srv

<Guest6317>with mirror you mean your own?

<lechner>also, for the benefit of anyone using the mirror i would prefer to be in a location that would inform me of court-authorized access (or shut down the server, if they can't)

<Guest6317>ah so you want to create a public mirror not just a local one for your lan?

<lechner>yes, i do not have an issue with multiple downloads, i do not think, since i cross-publish my stores locally. unlike your work on embedded equipment or virtual machines, i also do not download the same things twice

<Guest6317>ah got it, I want to create a local cache for my lan so I do not bother upstream that much with re-downloading stuff all the time

<Guest6317>in that case i am not experienced enough to be helpful

<lechner>i enjoyed our brief conversation. thank you

<jackhill>sneek: later tell lfam thanks for reviewing the certbot update!

<sneek>Will do.

<wdkrnls>Dear Guix, what does this error https://paste.debian.net/1272741/ tend to mean in a failed guix pull?

<fruit-loops>"debian Pastezone" https://paste.debian.net/1272741

<winter>Is that the entire output, wdkrnls?

<wdkrnls>Yes, I'm guessing I'm missing a (guix git-download) somewhere.

<wdkrnls>I just wish it reported where.

<wdkrnls>This was the entire contents of my failed channel derivation.

<Electnick>I wrote in linux-hardware forum about the package hw-probe does not detect Gnu GuixSD and instead put LFS LFS on topic Distro. https://forum.linux-hardware.org/index.php?page=hannpreeGuix Since the GNU GUIX system Distribution is different in many ways, it is difficult to get detected. I would appreciate If anyone here share the steps to easily detect the Gnu Guix Distro & version .

<winter>ah, so it's to test a channel, i see

<cel7t>Is there a way to remove all xfce4 packages from guix easily?

<apteryx>why do you want to remove them?

<apteryx>or you mean from your system?

<cel7t>yes

<cel7t>I'm mostly just using openbox and removing them will save space

<apteryx>I'd use 'guix graph' or 'guix size' on the openbox core packages to see where they are pulled in

<Electnick>celt7t: I would like to know too. Just I guess it is in the moment of installing only I selected i3 window manager and no more. Hope it help.

<cel7t>While installing I'd picked XFCE and Openbox, and since I'm not really using XFCE that much I was wondering if there's a straightforward way to remove it

<lilyp>just remove xfce-service-type and they're gone – you do need to follow up with a gc to also free up the space if you're particularly resource-constrained, but I think you just don't want them to bug you

<cel7t>I'm running a low-spec system so every gig helps

<cel7t>I see, thanks lilyp

<winter>wdkrnls: either way, might be worth filing a bug (or at least posting on the mailing list) that guix pull's errors aren't very nice when developing channels

<winter>i do wonder why that error mentions the repl, though

<wdkrnls>yeah, that would be a good idea

<wdkrnls>I'm mostly trying to update my system though so I can make installation media for a new hard drive.

<wdkrnls>My current one is failing.

<wdkrnls>Then, once I get that done I need to close the loop on a few bug reports / patches I have already made :/

<wdkrnls>The good news I think is that I guessed right with git-download. The bad news is that there is another problem.

<wdkrnls>Guix complains about one of the programs I packaged to try working with the gnome keyring from a window manager: lssecret.

<wdkrnls> https://github.com/gileshuang/lssecret

<fruit-loops>"GitHub - gileshuang/lssecret: List all secret items using libsecret (e.g. GNOME Keyring)." https://github.com/gileshuang/lssecret

<wdkrnls>(supported-package? #<package lssecret ...)

<wdkrnls>That software is in the public domain. Is that causing a problem here?

<cel7t>All guix install and guix remove operations are failing for me at the "building profile" phase with the error "In procedure symlink: No space left on device"

<cel7t>This error does not happen on my root account

<lechner>cel7t / root usually has an extra allocation

<wdkrnls>cel7t: Maybe you need to clear some space with `guix gc -F20G`?

<wdkrnls>Reading the code in packages.scm, it says that it's saying instead that the package doesn't work on my computer architecture?

<wdkrnls>guix build -f lssecret.scm works fine on my current revision...

<cel7t>wdkrnls: I'll give it a try

<lilyp>which packages.scm?

<wdkrnls>guix/packages.scm

<wdkrnls>Seems like I forgot (guix gexp) in my channel. Since my package definition uses a gexp, I can see that causing a problem. Whoops!

<lilyp>ah yeah, that trips me up too from time to time

IRC channel logs

2023-02-28.log