<divoplade>I needed to register to speak to #guile, but I don't like the fact that I lock a username
<efraim>not a problem, just letting you know we've now all seen your nickserv password
<divoplade>OK it was automatically generated only for freenode so I don't care :)
<bluekeys_>Also, these conversations are logged, so for the sake of someone nicking your nick, it may be worth re-generating and changing it.
<brendyyn>failing to guix pull from a 484 day old system :/
<leoprikler>I think you might to pull intermediary commits first.
<refcfar>I see that there are several versions of `guile` in guix, all just named `guile`. How do I choose a specific version?
<refcfar>Another question: how can I inspect the source of the current system's available modules? Like when I `guix search guile` and see for example `location: gnu/packages/guile.scm:271:2` I would like to just quickly read the source code of that module.
<cbaines>yeah, the current rust packages do look weird, literally the only thing rust-serde contains is a couple of licenses, but that's not even relevant, as there isn't anything for those licenses to apply to!
<rekado>it’s because all inputs need to be available in source form when the leaf package is built; so for many packages that we have *nothing* is built, because they are only used as inputs for some other package that *is* built.
<stikonas>civodul: that's because rust doesn't really have a stable ABI, so no libraries
<janneke>civodul: i'm starting a daemon from a relocatable guix pack and it looks like that daemon "loses" it's mnt/file system view when the process that starts the daemon exits -- ring any bells?
<janneke>as long as the process that start the daemon lives, the daemon behaves fine
<PurpleSym>stikonas: Does that matter for guix though? A packages is rebuilt if any input changes anyway (unless grafted).
<stikonas>PurpleSym: well, depends on what you mean by matter. Same library is compiled into many different executables, so no space savings. Other than that I guess it doesn't matter
<leoprikler>It does, because it means, that Guix can't rebuild those packages separately.
<vits-test>psst.. prepare the nets. It may be dangerous now.
<madage>cbaines & efraim, since my rust patches caused such turmoil and I have others on the list, let me see if I grok things right: it is better to send as many rust changes as possible in one go, right?
<roptat>it lets you host a substitute server on your machine, so people can use it to fetch substitutes for chromium as long as they have allowed your public key
<bluekeys_>So, when it's built, do I just guix publish ungoogled-chromium and all is well in the world?
<roptat>simply "guix publish", is publishes your whole store, not just a few substitutes
<roptat>once you publish your substitutes, you still need to tell people to use your substitute server and give them your public key so they can start downloading trusted binaries from you
<roptat>the substitute servers are not decentralized (yet :)), so people still need a way to know where to fetch them; similarly you could claim to have built chromium from the source, but actually included a backdoor in there, so you need to trust the person who built it
<vits-test>Kimapr[m]: oh. Looks it just extracts. Not to store.
<roptat>hence the requirement for a public key (you need to generate the keys with "guix archive --generate-keys", then guix publish takes care of signing everything)
<efraim>madage: sorry, i'm in and out all day and idle on IRC. it's a toss-up. queueing many rust changes at once reduces the rebuilding but makes reviewing take longer :)
<vagrantc>make: *** No rule to make target 'etc/gnu-store.mount', needed by 'all-am'. Stop.
<nikita`>hi folx. i don't really have the capacity (or am i even still subscribed to the lists?) to reply to the email i just got about tor-browser on guix, so if the person is around who asked this (someone who goes by procmem): you should be able to infer from my long silence in guix that at least i am not working on tor-browser.
<vagrantc>why is it so hard to generate a workable upstream tarball for guix? :P
<vagrantc>there are so many small things that appear to sabotage the process
<nikita`>will still reply to the email in days/weeks whenever i don't fear not having enough money to make it through a month anymore
<nikita`>it's however interesting what people remember and nice to hear back offlist sometimes and in other places. while i'm mainly working in NetBSD now, I still appreciate the people and community i met here back then
<madage>efraim: that's what I was thinking and I take human reviewing time to be more 'expensive' than machine rebuilding time, so I'll try to strike somewhere in the middle but favoring reviewers where needed :)
<madage>and I'm always in and out, so no problem, take your time...
<civodul>vagrantc: ah so we need to add gnu-store.mount.in; do you have a patch for that or should i do it?
<civodul>it's hard because i guess this build system is becoming more and more foreign to Guix
<vagrantc>civodul: i haven't even figured out where it should be added, so if you get a chance :)
<rekado>I might package this when I go back to work at the end of November
<zimoun`>no, never used. Hum? interesting… I will give a look
<pineapples>Hi! I'm unable to wrap my head around as to why gnu-trivial-build-system's 'find-files' traverses the root of the GNU store when I ask it to copy files from (package (string-append (assoc-ref %build-inputs "package") "/")) to my "%output out" directory. I have to append any character to the slash mark to prevent guix build from attempting to copy the whole GNU store to my own package's build directory
<pineapples>roptat, It's that same package wrapper I was writing two weeks ago. I have come a long way, and made a lot of progress. I could say the wrapper is done, if it weren't for the gnu trivial build system's very oddity I'm dealing with rn.
<pineapples>roptat: Here's code that reproduces my issue: https://paste.debian.net/1168868 If you try to build this on your machine, the guix build command should yield the list of all directories in the GNU store (not the behavior I'm hoping for). If you append any character to "/" in the autoconf-src field, only the contents of the autconf directory will be displayed (the behavior I'm expecting)