<cybersyn>Is there a way I can use build options such as "--with-graft" for specific packages during a system reconfiguration? <roptat>apteryx, no, I haven't seen them <roptat>it's weird, because there has never been more than one version of the po file, so there's only one possible Italian manual <iskarian>does anybody have an idea of what would be involved in adding go module support to the go build system? <Gooberpatrol66>What is the purpose of "hint: Consider setting the necessary environment variables by running: <Gooberpatrol66>Alternately, see `guix package --search-paths -p "/root/.config/guix/current"'." <leoprikler>Gooberpatrol66: it means your Guix profile is currently not sourced or environment variables within it have changed <leoprikler>running the second snippet lets you inspect what exactly would be added where, running the first sets up the environment variables in a potentially destructive manner <apteryx>iskarian: preparing a directory hierarchy of the module artifacts to serve via a local GOPROXY during the build, or something similar <apteryx>sneek later tell civodul ah, perhaps it was just grafts; it's flew through it and is now at building guix at the tag + 1 commit <iskarian>apteryx: forgive my naivety, but why not let go fetch the modules itself? <apteryx>this could be done to build the cache, I suppose; but there's beauty in deriving those artifacts from the canonical sources (usually, a git repo). <apteryx>this makes it clear what the sources are and its hash. Alternatively there could be some go-fetch method to use as the origin, which would fetch all what is needed from the proxy and compute the hash from it (my understanding is that one of those things is a .zip which contains the sources) <apteryx>I think it'd be nice if each go package would carry their goproxy cache layout in the store (perhaps under the gocache/ directory); that way it'd be trivial to setup a goproxy file hierarchy by simply building a file union of these <apteryx>iskarian: avalenn is also interested in that topic <sneek>civodul, you have 2 messages! <sneek>civodul, apteryx says: ah, perhaps it was just grafts; it's flew through it and is now at building guix at the tag + 1 commit ***zap1 is now known as zzappie
<wonko7>is there a way to list an installed package's content? <mothacehe>wonko7: you can run something like: tree $(guix build hello) to inspect a package content <Noclip>pocketroid: Reminds me of the movie "2012". <Noclip>pocketroid: "2012 is a 2009 American science-fiction disaster film directed by Roland Emmerich." <pocketroid>Peer review and recommendation is valuable for me. If it is not worth watching, i am happy to ignore it too <Noclip>I liked the movie when I watched it (many years ago) but that doesn't mean that you also have to like it ... <pocketroid>Recently saw a norwegian sequel disaster film. Saw the original, several years ago when it was new. The Wave is the first one, or Bølgen <pocketroid>It is simple and not revolutionary, but fun to hear some norwegian and see some unique landscape <pocketroid>Based on real stuff tho, a tsunami and other natural disasters are, in general, ignored. The movie is a good vehicle to spread awareness <tissevert>I have no idea but if there's no licence issue you could try and write the package for it ? <tissevert>it's a great way to start learning about guix <Noclip>tissevert: That was too much I guess xD <Noclip><tissevert "was my answer bad ?"> No, I think it was good. <tissevert>hmmm : / but that's the point of guix, though, right ? it enables anyone to write their own package pretty easily, first in a crappy way to just get things working and then contributed them to the community <tissevert>it was more like an invitation to join the fun <Noclip>tissevert: And PotentialUser-15 has the freedom to reject your invitation. Don't blame yourself for that. <tissevert>no, but I know how hard it is to feel included and I don't want to repel potential users by making them feel guix is a select club of people who must all be able to write their own packages (especially when I haven't shared any one of mines yet) <Noclip>If people are interested in guix that's nice but if they aren't that's also okay. We don't want (and need) to force anyone to stay here. <Noclip>"I don't want" might fit better than "We don't want" as I can't speak for others ... <Noclip>tissevert: "to repel potential users" That irony ... xDD <tissevert>well yes, because that's exactly what happened <jeko>I noticed I have duplicates in some env vars on Ubuntu <jeko>I checked .bashrc and .profile to find places where I set those env vars <jeko>but I can only see it once <jeko>Noclip: nop, I'm physically sit in front of the system which I freshly turned on few minutes ago <Noclip>Sitting in front of it doesn't mean that you couldn't use tmux on it. Tmux isn't just usefull for ssh ... <jeko>Noclip: yeah sure. Well I don't use Tmux <Noclip>However tmux seems to duplicate my user specific parts inside PATH. That's why I was asking about tmux. Don't know what's going on on your system if you aren't using tmux. <tissevert>Noclip: it doesn't do it here, maybe the way you included things from .profile / .bashrc ? what's your setup ? <jeko>I read things about login/interactive/… shells could be related? <Noclip>tissevert: It also does this for those parts of PATH set by guix. <tissevert>hmm that's the main origin I can think of for that kind of issues, but then I have never tried guix + ubuntu so I have no idea if there are any special interaction there <tissevert>hmmm, yeah, because guix sets it from the profile somewhere and if the profile gets re-sourced from a mere (non-login) shell it could cause that, couldn't it ? <jeko>I know there is at least the fact that Ubuntu uses .profile instead of .bash_profile <Noclip>I'm using guix on top of ubuntu (linux mint) currently. <overclucker>maybe you could set your path without inheriting $PATH <tissevert>according to bash's manpage both are attempted for sourcing (first .bash_profile then .profile) when a login shell is spawned, it's ok to use both and not an ubuntu idiosyncrasy <Noclip><overclucker "maybe you could set your path wi"> Is having parts twice in PATH an issue? <jeko>tissevert: for XDG_DATA_DIRS, if I set it in .bash_profile, Ubuntu does not display icons in the dock or in its app list. so I set XDG_DATA_DIRS in .profile <tissevert>(I mean not both at the same time, that would be a source of confusing, but either one of them) <jeko>tissevert: I think I use bash but how can I check that ? <tissevert>echo $SHELL or getent passwd <YOUR-USER-NAME> should give you some information about it <Noclip>Isn't dash significantly different from bash? <Noclip><jeko "tissevert: I think I use bash bu"> help should also tell you that. <tissevert>that was a long shot but I find it hard to believe that ubuntu modifies the bash package they distribute to ignore .bash_profile <civodul>mothacehe: you too are in the bioinfo business? ;-) (and speak Russian?) <tissevert>jeko: you use a login manager like GDM or I don't know which one ubuntu uses ? maybe that's the one sourcing .profile but not .bash_profile ? <mothacehe>civodul: hehe, I'm running a small Cuirass server, building a bunch of Guix channels mostly as a proof of concept ... and learning Russian between fixing two Cuirass SQL queries :p <jeko>tissevert: I have no idea if it's the root cause but yeah I use a login manager, GDM as I keep the default one <tissevert>personnally, I have to manually source .bash_profile from my .xsession because startxfce4 doesn't source .bash_profile on its own <jeko>tissevert: maybe if you use ~/.profile it will do the job haha <tissevert>civodul: bioinfo ? is there a double meaning to «порядке» ? <tissevert>hmmmm maybe ? but I'm pretty sure I tried that already I had a hard time figuring a proper initialisation scheme for my session so I'm not touching it now that it works <jeko>I am going to remove the sourcing of my guix-extra-profiles from .profile to see what happened <tissevert>plus, .bash_profile and .profile are documented, they are in bash's manual, I haven't found any resource on .profile itself as a «common» source of truth for shells and X sessions so I see no reason to trust this to happen automatically <jeko>it needs to be in .profile haha <jeko>no more dupplicates, I guess the dupplications came from me I must have forgotten something I did. <jeko>anyway the reason I checked my env vars was <jeko>git : 'remote-https' n'est pas une commande git. Voir 'git --help'. <tissevert>[because it's in french ? ; )] anyway… what's this remote-https command ? do you have special alias command for git or something ? I didn't know there were environment variables to configure git <sneek>raghavgururajan, you have 1 message! <sneek>raghavgururajan, pineapples says: I'll wait, if I have to :) Thank you for your hard work! <jeko>tissevert: oh it does it only in the Guix repository I cloned <tissevert>jeko: what do you mean ? who does it ? git ? you installed git from a local copy of the guix repository ? <jeko>tissevert: I mean git pull returns the remote-https message only when I run it in my local guix repo <jeko>hmmmmmm I think see something. I install git in my default profile <jeko>and I install git-send-mail in an extra profile <jeko>git --exec-path points to the git-core in the extra profile <efraim>mothacehe: It looks like pjotrp[m] just deleted that module <jeko>I remove git:send-mail from my custom extra profile and I don't get the error anymore <tissevert>(but still doesn't fix your weird duplicates in $PATH) <jeko>yeah but after a new login I don't get the duplicates so I think it's on me but I can't remember what I did (which I did more than once because I noticed it several times) <mothacehe>civodul: yeah I noticed them, they are quite frequent <civodul>do we have to enable substitutes on build nodes? <mothacehe>I didn't investigate them yet, but they occur when the farm start to build a big batch of derivations <civodul>that's how they get prerequisites, right? <civodul>i see it also fetches *-guile-builder et al as substitutes; there's a possibility that this won't work, depending on file size and --cache-bypass-threshold <civodul>in practice it should almost always be fine with the settings we have on berlin, but it's not guaranteed <civodul>i'll probably merge wip-ungrafting later today, it's in good shape in terms of substitute availability <mothacehe>mmh I see, this part probably needs some polishing. I also need to add temporary gcroots for the substitutes on the workers. <civodul>ah yes, those things can be gc'd before workers have had a chance to fetch them <civodul>mothacehe: yup, it's gonna be nice :-) <mothacehe>yup, sometimes the substitutes fetching fails, and I suspect this is a possible cause <mothacehe>"Failed to add ... to store" messages in /var/log/cuirass-remote-server.log typically <JennaS>Hi. Does anyone know how to fix the thing where guix won't boot because it couldn't find any free drivers <leoprikler>JennaS: the issue is most likely graphics. Try to start from the bare-bones template, it won't have GDM, but you at least get a shell <leoprikler>it's one of the templates, that comes with the installation CD <JennaS>Also my graphics are AMD so I doubt that should be a problem <JennaS>Ohh well you see the bootable image won't boot <leoprikler>humm, in that case it seems you really are out of luck <JennaS>I have a Ryzen 7 3700x with integrated graphics <JennaS>I have been trying to install guix for months hoping one day it will get fixed but so far no luck <leoprikler>that sounds very new and "requires blobs to run" to me <JennaS>yes it's definitely not old but it's supported by pretty much everything else <JennaS>I only have this issue with guix <leoprikler>hmm, did you check trisquel or any other GNU supported distro? <leoprikler>in particular anything with the linux-libre kernel <JennaS>but I'm almost sure it's a kernel thing because it seems to really hate my hardware <leoprikler>Guix by default uses linux-libre and the upstream kernel is not package inside the Guix repo <leoprikler>Your hardware really wants that upstream kernel, though. <JennaS>So what now. Any cool distros to check out? <Dr8128>Maybe NixOS is something for you. <Dr8128>It is the other functional distro. <leoprikler>You can use Guix as a package manager on your favourite distro, but if you really want to have your system managed with Guix while also using non-free software you might seek out channels, that provide packages for them. <leoprikler>You'll have to decide on which solution limits you the least <Dr8128>Does Guix work on the Gazelle from system76? <Dr8128>I have ordered it and I'd love to use Guix on it. I do not need wireless, luckily, I heard wireless often does not work without blobs. <Dr8128>It also has the IME disabled which is nice. Still proprietary BIOS AFAIK, though. <leoprikler>I think the graphics card might be an issue there as well <apteryx>civodul: release artifacts successfully built! <Dr8128>If it is, will I still be able to boot into the terminal without graphical environment? <Dr8128>I do not really need X or Wayland. I am not using it now either. <apteryx>I'll smoke test in a VM and if it looks OK I'll push them to the alpha FTP and send a mail to guix-devel <JennaS>does guix have a list of supported hardware <leoprikler>You will have to test that on your own, I've seen both. <mjw>That link works for me. <raghavgururajan>leoprikler: I was packaging a telegram client for automating stuff with bots. Would you be able to have a look to see if patches are good? #48091 :) <roptat>AppAraat[m], the link from the manual works for me too <leoprikler>I'll try to have a look at them, but I can't promise you speed. If anyone else wants to have a go, they're free to take them. <raghavgururajan>leoprikler: Regarding propagating glin-networking in libsoup, is the comment ";; Provides GIO modules at run-time." look good? <apteryx>now at the boot time it says Booting Guix 1.3.0rc1-1-$commit insteadof 1.3.0rc1; that's expected, right? <apteryx>With the system running 1.3.0rc1 + 1 it means it will know the 'guix' package as 1.3.0rc1, which is what we want (IIUC) <apteryx>one idea for the VM: enable spice-vdagent service to enable sharing keymap, clipboard, and dynamic resolution (when used via something like GNOME Boxes or one page of QEMU command line options) <apteryx>other mainstream distros come with it (e.g., Ubuntu); it provides a better experience out-of-the-box. <wonko7>how do I find the iwd binary which isn't in my path because it's in /libexec? <pineapples>I am working on upstreaming a python package, and `guix lint' is returning a message that `python-setuptools' shouldn't be a native-input of my package, which begs the question: for what reason this lint check exists? Is `python-setuptools' part of the python build environment? ***Kimapr4 is now known as Kimapr
<wonko7>for iwd; the profile in which it's installed has a GIT_EXEC_PATH which mentions libexec, but nothing for iwd <wonko7>also when starting it from /gnu/store/.. it fails because it can't find dbus <apteryx>civodul: do you use build-aux/announce-gen to prepare announcements for RCs as well? <apteryx>hmm, I can't find the 'gnupload' script in the tree; where does it come from? <civodul>apteryx: i think those messages were +/- handcrafted <civodul>which doesn't mean it's an example to follow ;-) <civodul>but announce-gen is not well suited to our needs <civodul>it would probably make sense to have an in-tree gnupload.scm <apteryx>roptat: I've streamlined po/doc/local.mk a bit on the version-1.3.0 branch, if you'd like to take a look <rekado_>raghavgururajan: commit 207cba8114d354737b231e510d6110ea2a42e07b has this date: Wed Apr 18 23:21:11 2012 +0200 <rekado_>that is the official starting point, though the seed that sprouted into Guix may have germinated for a few months in a different environment. <efraim>I have a file that evaluates to a file-union and apparently I can't install a non-package object, how can I protect it from garbage collection? <roptat>apteryx, you added a comment about make-download-po-files-rule before make-update-po-files-rule, was it intended? <leoprikler>raghavgururajan: I'd personally be happier if it fits right next to glib-networking, but yeah, that's one way to phrase it <leoprikler>It'd probably be better to separate the propagated inputs into two "blocks" if we can't, block 1 required by pc block 2 required at runtime <apteryx>roptat: good eye, seems I forgot to update that comment; it should read 'make-update-po-files-rule'. Thank you. <apteryx>how much time should we give ourselves before the final release? Does 2 weeks sound reasoable? (let's say, 17th of May). This is to allow time for users to test and for reported issues to be fixed. <roptat>apteryx, mh, if we take 2 more weeks, I think we can relax the string freeze <roptat>in "msgcat $< > $@", doesn't $< correspond to only the first dependency? Shouldn't it be $^ instead? <leoprikler>raghavgururajan: In 48091, why did you split {04,05}/11 into two packages? Does 04/11 on its own build? <raghavgururajan>leoprikler: [1] I wanted to make only selective changes per commit. [2] Yes <apteryx>roptat: you're right, that should be $^, reading the Make manual <roptat>apteryx, assuming you fix these two issues, it should be good (not tested, just read the patch ^^) <apteryx>roptat: weird that I got it building with that mistake; shouldn't it have caused failures? <roptat>no, it would just have missed some translations in the pot file <roptat>the manuals would have built fine, but mostly untranslated <roptat>I wonder, does that mean you update the po and pot files every time you run "make"? <roptat>well, everytime doc/guix.texi is modified <roptat>yeah, seems so: in a clean repository, the first make starts with "/gnu/store/sl69bi5hq8jx5dcis9g05043p3wmnllb-profile/bin/msgmerge --update --lang=es po/doc/guix-manual.es.po po/doc/guix-manual.pot" <raghavgururajan>leoprikler: I think those inputs were not included because packages that depended on it, might not required those features. So I wanted to have those features available as intended by the upstream. Also, those didn't seem optional, it was mentioned in 'install_required' and not in 'extras_requires'. <apteryx>roptat: the string freeze on version-1.3.0? 2 weeks is conservative I think <roptat>I think we tried to avoid rebuilding the po files everytime (it's already annoying to have to checkout the po directory with a fresh checkout) by having these -update rules that did not talk about the pot/po files directly <leoprikler>raghavgururajan: do they work as intended if you put all into one environment? If so, I'd rather not propagate them <raghavgururajan>leoprikler: Isn't python package looks for run-time dependencies in PYTHONPATH? <roptat>most likely, the reason we run doc-pot-update is to have the pot files in the release archive, so the translation project can pick them up, but with weblate, it's no longer necessary I think <leoprikler>In a similar manner, what's the failure mode if they're not given? Does it produce a horrible backtrace or does it fail gracefully? <apteryx>roptat: re rebuilding pot files on .texi changes; perhaps I'm missing the work flow of the translator here; would that get in teh way? <roptat>it wouldn't get in the way of the translator: I'm rebuilding the pot files continuously to push them to the weblate repo anyway <roptat>but it would get in the way of the contributor, who would have to either ignore the changes in the po/ directory, or commit them together with the doc changes <roptat>that includes the pot *and* the po files, which might make things more difficult to review also <raghavgururajan>> leoprikler: In a similar manner, what's the failure mode if they're not given? Does it produce a horrible backtrace or does it fail gracefully? <raghavgururajan>I didn't add them for tgcli. Since I was touching that package to update, I wanted to add them for any future dependencies of it, could use them if needed. <apteryx>roptat: I think for that problem we have to find a way so that doc-po-update is not run when simply doing 'make' <apteryx>it should be ran on demand only, or when doing 'make dist' <roptat>apteryx, the target is not run, but "make" builds the translated manual, which depends on the po file, which depends on the pot which depends on doc/guix.texi <roptat>when we had custom-named targets, we could break this cycle, as the translated manual would depend on the po file, that had no make rule <leoprikler>raghavgururajan: No, it suffices if the package, that needs that feature propagates or something else propagates the package in question. Propagated inputs are weird and we ought to use them sparingly. <raghavgururajan>Continuation for previous one: So I don't have any package that requires those features, for testing. <leoprikler>Thus if it's not used by any consumer at the moment, better not propagate it (my personal intuition) <leoprikler>Can you try manually importing a python module/running a function, that would trigger an issue of those modules missing? <apteryx>roptat: I see. Perhaps the translated manuals could be not build by default? <leoprikler>If getting on such a code path is non-trivial, we might not need that input either <apteryx>I don't see a way to fix that depenency problem otherwise (and not have the po directory filled with changes on the first 'make') <raghavgururajan>leoprikler: May be I can drop that patch for now, as it is not immediately required. I could send that patch separately to guix-patches. <roptat>if we do that we may not notice when they break, and notice only later, when guix pull is broken because of them <roptat>on second thought, they're annoying to build, so maybe we could have them built right after the download-po target? That should be enough <leoprikler>You might as well leave it be until you find a consumer, that really needs it. Alternatively, if you want to have it right now (for whatever reason), you could rename the current variant to "-minimal" and form another package, that propagates it plus "required" dependencies. <apteryx>roptat: couldn't we leave it to our CI to build them; I don't understand how 'guix pull' would break if we don't build them out of the box <leoprikler>Either way you're probably right in that discussion about that would deserve its own thread. <roptat>apteryx, the issue is that sometimes the translation is incorrect, and texinfo fails to build the translated manual. If we don't build them, we don't notice, and texinfo fails when building the translated manual during guix pull <apteryx>roptat: nevermind, what I said doesn't make sense. To be useful the translations need to be included in the binary package. <roptat>but I think this is an issue with the po files, which it might suffice to check right after download-po <roptat>just like we now run "msgfmt" after download-po <roptat>(we had a broken translation for guix itself once, and that also broke guix pull because msgfmt failed to create a .mo file) <roptat>so, it's fine to not build the translated manual with "make", but we should still add them to "make dist" and such <apteryx>right, I think this must be already the case <roptat>nope, not yet, the translated manuals are built with "make" <roptat>should they be part of info_TEXINFOS_DIST (or whatever automake expects) instead? <roptat>I don't remember (dist_info_TEXINFOS?) <roptat>mh, that doesn't seem to be doing anything <apteryx>roptat: there's already a TRANSLATED_INFO variable; perhaps it can be made a dist_info_TEXINFOS one instead? <roptat>no, because it contains contributing.texi, which is not a full info manual <apteryx>I'll look into it later today and check here if you had ideas :-) <roptat>I'll try to make a patch or something <leoprikler>raghavgururajan: w.r.t. 48028, do you think I can push the changes to libsoup (inputs+homepage, not the test stuff) to master? <roptat>apteryx, mh, did you commit a .version file? <raghavgururajan>leoprikler: Sure thing. Also, test stuff can go to c-u as well, if you are up for it. :) <leoprikler>I don't think I have the equipment to check testing. <leoprikler>I should probably have checked this harder already, but oh well, I just hit enter and pushed <Noclip>How do I create a link inside a compiled package? <leoprikler>If you just made me push something extremely dangerous to master, I swear…! <Noclip><leoprikler "If you just made me push somethi"> Should I be afraid of upgrading currently? <raghavgururajan>leoprikler: If I cherry-pick those two commits into wip-gnome, should I keep the sign-off line? <Noclip>I would like to create a link from "./sbin/bees" to "./lib/bees" after the compilation. How can I do that? <mdevos>Noclip: for a symlink, there's the symlink procedure <apteryx>roptat: no! Why? It's ignored per our .gitignore <roptat>oh, is it generated automatically then? <roptat>I was surprise to find one in my checkout of the version-1.3.0 branch <roptat>(but I found it after bootstrap, configure and make) <Dr8128>How many of you use RYF hardware? <Dr8128>I just learned about it a few days ago, I think it s very cool but I think most people nowadays are not much into freedom. <roptat>apteryx, so dist_info_TEXINFOS doesn't seem to do anything "doc/guix.fr.info" is no longer a valid target, although I can still build the texi files <Dr8128>I think that the next laptop I buy will be one that is RTY certified. <Dr8128>raghavgururajan: Do you also avoid non-free devices? <raghavgururajan>> Dr8128: I think that the next laptop I buy will be one that is RTY certified. <Dr8128>Yeah, I really appreciate the FSF and the GNU <raghavgururajan>Dr8128: You mean devices with non-free software? If so, yes, I avoid them. <pineapples>Speaking of which, are there low-power, linux-libre-friendly ARM workstations? <apteryx>roptat: yes it's generated at autoconf time IIUC <apteryx>(it comes from AC_INIT in configure.ac) <roptat>so, to have the *.info target for the translated manuals, we need to have them in info_TEXINFOS, but that builds them when running "make" <Noclip><raghavgururajan "(X200-T)"> Thinkpad x200 Tablet? <Noclip>raghavgururajan: nice, X230 Tablet here! <Noclip><raghavgururajan "Yeah, its BIOS is non-free right"> I think nckx is using the x230T too and was talking about it having a non-free bios once. <Noclip>raghavgururajan: Does your built in wifi work with linux-libre? <pineapples>Sadly, Raptor Computing Systems' offerings are too expensive and power-hungry for my taste <Noclip>I think nckx also said it is not working on the x230T. <raghavgururajan>pineapples: I think workstations cannot be low-power consuming, as workstations are intended for high performance. <Noclip>raghavgururajan: Is a raspberry pi (or a similar product) a workstation? <pineapples>raghavgururajan: I would like to disagree here; the M1 ARM processor by Apple Inc. meets both the above-mentioned criterions; though, it is, obviously, riddled with nonfree firmware, so it's out of the equation for me <Noclip>pineapples: That Apple processor is probably free of free software xD <civodul>it's fun to see 207cba8114d354737b231e510d6110ea2a42e07b from here <Noclip>civodul: That's the first commit of the history of guix? <civodul>Noclip: yes, raghavgururajan & rekado_ mentioned it earlier <tissevert>(define (instantiate server derivation) #f) ^^ <civodul>twas little more than an experimental experiment back then <civodul>much of this code is still around actually <tissevert>has anything changed in the configure process for guix since the first video on http://guix.gnu.org/fr/videos/ ? I can ./bootstrap but not ./configure --local (./configure without any option is fine though) <tissevert>configure: error: unrecognized option: `--local' <tissevert>my bad… I don't know I managed to pause right between the 'l' and the 's' <tissevert>when I came back to the video I thought the command was complete and tried to run that <tissevert>I'm so terribly sorry for asking before realizing something so stupid <roptat>it's fine, we're here to help :) <roptat>tissevert, tu ne t'échaperas pas si facilement :p <Noclip><tissevert "it looked like a proper command"> I definitely does. <roptat>tissevert, but don't feel ashamed, we all do stupid mistakes from time to time :) <Noclip><mdevos "Noclip: for a symlink, there's t"> Looks like that's not in the guix manual?! <tissevert>yeah but I wish I could keep mine secret instead of broadcasting them on a public channel <mdevos>Noclip: I think 'symlink' is part of guile <tissevert>roptat: you speak french too ? ok, who doesn't speak french here ? raise your hand, come on, don't be afraid <mdevos>the implementation of Scheme that Guix uses <roptat>tissevert, I take care of most of the French translation <Noclip><mdevos "Noclip: I think 'symlink' is par"> Mhh, that actually makes a lot of sense. I was just too stupid to think of that. xD <tissevert>I'd love to lend a hand on this, I love translations and I'm a native french speaker <roptat>(I'm also a native French speaker) <Noclip>tissevert: I don't speak french. 🤚 <mdevos>Noclip: there is plenty of stuff in guix/build/utils.scm that is not documented in the manual <roptat>so please, fix my stupid mistakes in the translation :) <civodul>apteryx: regarding ".qcow2" in the VM image file name: make sure to update the manual accordingly <tissevert>Noclip: thanks your participation, proceed to the next counter where my associate will give you an edible french-auto-translator (comes in strawberry or banana flavour) *tissevert points at roptat <bone-baboon>I have cloned the Guix repository and have run `./bootstrap` when I try to run `./configure --localstatedir=/var/` I get the error "configure: error: GNU libgcrypt not found; please install it". I have run `guix package --install --no-substitites libgcrypt` and it was successful. Then I opened a new terminal emulator. I still get the same error with I try to configure. <roptat>bone-baboon, mh, the best way to get the dependencies is to run configure (and later make) in a guix environment: "guix environment guix" <roptat>this will ensure you have all the dependencies ready for the guix package <roptat>(most likely you are missing gcc-toolchain or glibc in your profile) <roptat>but using guix environment is better: you don't pollute your profile with packages you need only to build guix <tissevert>bone-baboon: that's where the «--ad-hoc coreutils findutils which» part becomes useful in the video tutorial I suppose, if you're watching it too <roptat>oh right that's "guix environment --pure guix" with --ad-hoc packages if you need more stuff in the environment (otherwise it might pick up broken things from the host distro) <andreas-e>tissevert: C'était quand même drôle de t'arrêter entre "local" et "statedir", merci de t'occuper du divertissement des participants! :-) <tissevert>andreas-e: et encore, t'as loupé quand j'ai essayé de scroller la vidéo du tuto pour revoir la ligne «guix environment…» <tissevert>(c'est un bonus pour mes abonné·es Fédiverse) <Noisytoot>bone-baboon, roptat: If you are not on guix system, use "guix environment --pure guix" <andreas-e>tissevert: Où tu contribues aussi à ma bonne humeur avec tes messages de bonjour entourés d'emojis floraux. <tissevert>what tutorial are you following ? (I looked for a text documentation rather than a video but found none so I had to pause The National and listen to the video instead) <bone-baboon>tissevert: I am reading the Contributing section of the Guix manual. <tricon>What is the "Guix-en" way of regenerating the OpenSSH host keys? (/etc/ssh) <tissevert>I was looking for it, thank you so much ! I had seen it once, I thought it was in the cookbooks and couldn't find it back so I settled on the video <tissevert>wait, it's incomplete, the line demonstrated there to start the development environment lacks the dependency packages <civodul>tricon: hi! there's no "Guix way" for that; just run ssh-keygen as you would do on another distro <tricon>civodul: Roger, thank you for the clarification. I had moved /etc/ssh in hopes that restarting the service would auto-gen them as that is the case with some distros/versions. I shall do as you have advised. Much appreciated! <civodul>the openssh service has an "activation snippet" that calls ssh-keygen for you if host keys aren't already there <civodul>it's a convenience for the first-time use of the service <tricon>When I restarted ssh (herd restart sshd), it wouldn't come up after renaming /etc/ssh; but it's probably more correct just to directly regen the keys as you mentioned. <andreas-e>What do I need to install for getting the man pages of C? I am looking to do "man sprintf". <stikonas>man pages of C are probably man pages of glibc <mdevos>Does anyone know a procedure for line-wrapping I could use from etc/commtter.scm.in? <simonsouth>andreas-e: If memory serves those are in the "man-pages" package. <andreas-e>stikonas: That is also true; I suppose they have been split off because everybody needs glibc, but only few programmers need these man pages. <rekado_>mdevos: you could abuse stexi->plain-text <stikonas>description: This package provides traditional Unix "man pages" documenting the Linux kernel and C library interfaces employed by user-space programs. <rekado_>mdevos: (with-fluid* *line-width* 30 (lambda () (stexi->plain-text (texi-fragment->stexi "hello world, thou art so cruel, but I don't care because this line is really much, much too long. I wonder if I can do something about this.")))) <rekado_>you’ll need (texinfo) and (texinfo plain-text) for this. <rekado_>but perhaps it’s easier to just implement this from scratch <civodul>apteryx: hey! did you send a call for testing? i'll happily relay it so we have more bugs to chew :-) *vagrantc sees the 1.3.0rc1 tag! <andreas-e>Does it ungraft texlive? This one is a problem for my updates since I am running low on disk space, and with grafting I have it twice. <vagrantc>ah, source tarball not yet at ftp.gnu.org or alpha.gnu.org ? <sneek>Welcome back vagrantc, you have 1 message! <sneek>vagrantc, leoprikler says: that's much more a guile question in principle yes, but you'd need to hack extra machinery into resolve-module (more or less) <vagrantc>leoprikler: what was that a response to? :) <tissevert>while checking my new package definition, I received the message : updater 'github' failed to find upstream releases <tissevert>what can I do about it ? is that a flaw in my package definition ? how does it search for upstream releases ? what prevented the updater to find any ? *vagrantc didn't know there was a github updated <tissevert>ok well then upstream package does indeed lack releases, which is why I provided a simple commit as argument to git-reference <tissevert>is that bad ? can't a package be included when it doesn't have releases ? <tissevert>so they all have this warning when they're linted but it's ok ? <bone-baboon>In the Guix repository to run `.configure --localstatedir=/var/` in addition to the packages listed in the Running Guix Before It Is Installed section of the manual I also had to install: pkg-config, guile, sqlite, libgcrypt, gcc-toolchain and make. Should these additional packages also be listed in that section of the manual? <pkill9>bone-baboon: i would have thought those would be added to the environment if you run `guix environment guix` <jackhill>tissevert: my (unofficial) thoughts on the refresh lint, if it can be fixed then fix it, but sometimes (sounds like in your case) the problem isn't in your package definition, but that the refresher doesn't yet support what your upstream developers are doing. In that case I think it's fine to ignore it. <jackhill>In the same way, we also have a number of packages that have archival lint becasue they aren't yet supported by Software heritage (progress is being made in that area thanks to the excellent disarcve by samplet) <Noclip>What went wrong here?: "Wrong type to apply: (symlink "/lib/bees" "/sbin/bees")" <bone-baboon>pkill9: I did not run `guix environment guix`. I just looked at that section again. It mentions guix environment and --ad-hoc so I guess readers could figure it out. An unclear required package that I had to ask about was gcc-toolchain. <Noclip><Noclip "What went wrong here?: "Wrong ty"> I guess I forgot to put "string-append out" in front of it. Will retry it with that ... <apteryx>seems the artifacts were rejected from GNU FTP; did you see some emails about it? I think it sent it to all maintainers <apteryx>I ran gnupload like so: gnupload --to alpha.gnu.org:guix release-1.3.0rc1/*.[xlg]z <apteryx>civodul: re updating the manual, we can't because of the string freeze (on version-1.3.0), correct? <apteryx>roptat: thanks for the patch! I'll try it shortly <bone-baboon>When I run `./pre-inst-env guix challenge /gnu/store/5ds5bli4p6gja2yzmzzc0sik1kzrasp9-guix-extra` it says it can not be found. <bone-baboon>When I run `./pre-inst-env guix challenge` the error does not happen. <bdju>it seems the lf (file manager) package is missing its man page <bdju>I found the file lf.1 in my gnu store, but the man command failed to find it <bdju>/gnu/store/lzv19amrp3zmqk9rfr19ja1rsp9gi50p-lf-13/src/github.com/gokcehan/lf/lf.1 <lfam>bdju: It's in the wrong directory <lfam>It should be in '/gnu/store/...-lf-13/share/man/man1' <lfam>Almost all Go packages in Guix include their source code, which is what you are seeing <lfam>If `lf` is an end-user program, and not like a library, then it probably shouldn't include a copy of its source code <lfam>Specifically, the #:install-source? option <bdju>lfam: interesting. yeah, it's an end-user program. <lfam>It's too bad it doesn't seem to have any build scripts, just using the Go tools <lfam>But, it's not hard to make the Guix package do the right thing <apteryx>roptat: ok! The work day is keeping me busy but thanks for the link I'll process these together when I get a chance <roptat>apteryx, now I'm wondering if we need to have a target that updates the po files <roptat>weblate only needs the pot, and updates the po files itself <roptat>so maybe we could not have any po target, that would be much simpler than what I did <apteryx>that sounds like a good idea if it works :-) <leoprikler>raghavgururajan: I think cherry-picking voids the signature, so you may want to rewrite the commit, but since it's already in master I don't particularly care (it's no longer relevant for review imo) <apteryx>but as a developer perhaps it's sometimes useful to be able to test that process locally? <apteryx>in case something stops working on weblate side? <leoprikler>vagrantc the question you asked in #guile, sneek is still lazy when it comes to remembering channels <roptat>apteryx, I don't think so, if something breaks at weblate, our translators will not be able to work on the translation anyway <roptat>and it's not too hard to "make doc-pot-update" and manually update a given po file from there if weblate is broken <bone-baboon>civodul: In regards to bug#48045 I have sent an email with further details. <leoprikler>vagrantc: the question was whether you can tell guile to shut up about some autocompilation stuff <Noclip>Is it possible to put "(let ((out (assoc-ref %outputs "out")))" directly below "(arguments"? <Noclip>I tried that but guix build failed with "Invalid keyword: let" <leoprikler>Noclip you probably want (arguments (let ((...)) `(#:keyword argument ...)) <leoprikler>though perhaps something weird happens and (let ...) is already parsed as a list and not as a sexp <leoprikler>either way i don't think what you're trying to do is necessarily a good idea. There is a reason why we use lamba*s everywhere <Noclip><leoprikler "either way i don't think what yo"> If I need to put a lambda in front of the let that would be also fine. <roptat>Noclip, no lambda, the arguments argument must evaluate to a list <Noclip>My issue is that I have "(let ((out (assoc-ref %outputs "out")))" currently 3 times inside my package definition and I would like to invoke it only once. <leoprikler>I think it works if you do `(#:phases (let ((out (assoc-ref %outputs "out"))) ...)` but again, what you're doing is not really a code smell <leoprikler>i.e. binding out like that in three different phases <roptat>oh, and I don't think you can bind %outputs outside of the sexp, so you can't have that common value for each argument <roptat>I don't think you can do (arguments (let ((out (assoc-ref %outputs "out"))) `(#:phases ...))) for instance, because at that point %outputs is not defined <roptat>so if it's for phases only, then you can do what leoprikler showed you <bone-baboon>I am trying to run `guix build --no-substitutes --keep-failed strace` but strace is in the store because I previously ran `guix package --install strace`. This is in regards to bug#48094. <Noclip>Is there a difference beween %outputs and outputs? <leoprikler>The latter is bound as an argument, but other than that not really <Noclip><roptat "so if it's for phases only, then"> It's for two phases and the make-flags. <roptat>I think you have to use %outputs for the make flags, but you should use outputs (an argument to the lambda of the phase, instead of the global variable) <leoprikler>Oh, if you really want to wrap more arguments (I don't know why, but it might perhaps come in handy) you might do `(,@(let (some stuff) `(#:kw arg #:kw arg))) <bone-baboon>It would be nice to have an option for guix build like `--force` that tries to build a package and if it exists and the build was successful it removes the existing package from the store and replaces it with the newly (locally) built package. <roptat>replacing the store item sounds scary though <leoprikler>either way, doing that is a little silly, as successful --check already indicates all-green <leoprikler>I think replacing the store item is handled by gc repair <Noclip>Won't --check fail if the result is different (not deterministic)? <leoprikler>Yep, but if the result is different there is no way of telling who is correct <roptat>yeah, I understand the motivation if it's to replace a broken item, but if it's to somehow take advantage of non-determinism to "update" a package, that's the scary part <leoprikler>Issues with determinism should be raised on bug-guix <Noclip>leoprikler, roptat: That's my current definition: <roptat>so, let's fix the non-determinism issue <roptat>then there's no need to replace the store item with a new result as it is the same :) <roptat>Noclip, it's not shocking that you had to use assoc-ref multiple times <bone-baboon>roptat: Thank you. I was overlooking `--check`. I am now able to build strace even though it was in the store. <leoprikler>Noclip: the indentation of (path ) is a little off, perhaps indicating some weirdness <leoprikler>Also try to split description into multiple lines. <Noclip><roptat "Noclip, it's not shocking that y"> So I should just keep it that way? <leoprikler>btw. let-binding out for make-flags appears to be overkill <Noclip>If you (the expert) prefer it that way I will of course keep it. <mikoto-chan>is guix supported on 32-bit hardware and is the package manager binary-based? <Noclip>The last thing I want to do is putting a lot of time in making my definition worse ... <leoprikler>Guix is supported on some 32 bit architectures (I assume you mean i686) and it is source-based with substitutes. <mikoto-chan>do you think a baytrail tablet with 2GB of RAM can handle it if I use only lightweight programs? <leoprikler>probably, depends on what programs you want to fit into 2GB of RAM <Noclip>mikoto-chan: "is the package manager binary-based?" Yes and no xD <leoprikler>If your text editor is Emacs and the rest is just a shell (or some lightweight desktop, that is not GNOME), I'd still say yes <leoprikler>I personally find that GNOME easily eats 2GB of RAM, so that's out. <Noclip>1 GB RAM is more than enough to run a full linux desktop system with a modern web browser and office software. <bone-baboon>leoprikler: roptat: In addition to helping me with bug#48094 which `--check` has done, the other motivator for the `--force` idea that I mentioned is the situation where a package has a substitute in the store and `guix build --no-substitutes --force <package>` creates a package that is different. Then I would prefer that the locally built package replace the substitute. This is because I would have more trust in the pack <leoprikler>I can see where you're coming from, but I personally want to have a little more distance between the user and fucking (pardon my language) the store. <Noclip>bone-baboon: I think the point is that different packages shouldn't occure in the first place and if they do that's a bug inside guix (or the package definition). <leoprikler>Going through gc is in my opinion fine, as you can still ask guix to build everything locally afterwards (and be doubly sure that only local packages with the AMA-Gütesiegel were used). <bone-baboon>Noclip: You are right. While I was writing my last message I missed leoprikler and roptat talking about non determinism being a bug. <leoprikler>I think your worries are still warranted given that there are some big buggy elephants (Emacs, and sadly also Guile, though I think the latter may have been fixed) <Noclip>bone-baboon: I think I have an idea how you could do that package replacement: Delete enough stuff to make the package collectable by the garbage collector then delete only that package with the garbage collector and reinstall all the other packages again with --no-substitues. <Noclip>That should effectively only rebuild and replace the collected package. <Noclip>So you basically un-reference all dependent packages, delete the critical package and then re-reference everything again. <Noclip>At which point every package will still be available in the store except for the critical one. <Noclip>leoprikler: Emacs is non-deterministic? <bone-baboon>I have run `guix challenge` and have packages that differ. If these non determanistic packages are bugs then should I check for them in the bug tracker and if they are not already reported should I report them on the bug mailing list? <Noclip>leoprikler: Are the guix repo and the official build farm maintained by the same people? <leoprikler>bone-baboon yes, and please attach relevant diffoscope output <Noclip>bone-baboon: I think there are always some non-deterministic packages but reporting them sounds like a good idea. <leoprikler>Cuirass is very much adjacent to Guix and I personally trust ci.guix.gnu.org <leoprikler>At the same time it is just a machine in the sky building packages all day, so take that with a grain of salt. <leoprikler>If you own a company and don't want free copies of the GPL handed out to all your users, you better run your own CI :) <Noclip>leoprikler: Is ci.guix.gnu.org not building for arm32? <leoprikler>I believe arm32 support was recently dropped, but I don't know the rationale behind it. <Noclip>I saw arm32 support (with prebuild packages) as an advantage of guix over nix. <Noclip>Would a raspberry pi (for example) be able to build a linux kernel in just a few hours? <Noclip>Or would that probably take several days? <civodul>leoprikler: that's because yesterday i merged master into wip-ungrafting, and that's the tip of the wip-ungrafting branch <leoprikler>ah, so Savannah shows the tip of the merged branch? <lfam>leoprikler, Noclip: We stopped building for armhf (aka arm32) in December, basically because we couldn't build for it quickly enough and it was slowing down the entire distro. And because it seemed like almost nobody was using it <lfam>But, we never stopped "supporting" it <lfam>However, we are in the process of getting two armhf build machines back into the build farm <lfam>I'd bet there are benchmarks online about how long a distro kernel build takes on the various Pis <lfam>You can check the "Systems" on this page to see that we are not building armhf packages for e.g. the master branch <bone-baboon>Noclip: You could estimate the time to build the Linux kernel using the concept of standard build units from Linux From Scratch. <Noclip><lfam "However, we are in the process o"> Nice <lfam>Yeah, but I wouldn't count on armhf working in well in Guix, in the long term. Unless somebody steps up to focus on it :) <lfam>It's kind of a dead-end for distros because there is almost no hardware that can be used in a build farm and the hobbyist market has completely moved to aarch64 <lfam>It's going to stay around as a low-power platform for embedded and industrial use, but that doesn't really help a project like Guix <leoprikler>until all of computing becomes absorbed by RISC-V <Noclip><leoprikler "until all of computing becomes a"> Except for ms windows xD <Noclip>I think it's funny how microsoft developed integrated windows x86 emulation support for arm CPUs so that people can also use all the proprietary trash with windows on arm. <Noclip>leoprikler: Did someone already port guix over to RISC-V? <tissevert>oh no I messed up the license Oo I had started the package by copy-pasting it from another local package <tissevert>what's the best way to fix an already submitted package ? <lfam>tissevert: Yes, just send a revised patch with a note about what changed <lfam>If you are generated the patch with `git format-patch` or `git send-email`, you could add something like '--subject-prefix=v2' <lfam>Oh, there is also the option '-v, --reroll-count=' <tissevert>I'll generate it with format-patch but send it by hand with my usual mail client <lfam>Sure, whatever works for you <tissevert>so in that case which of the above option should I use ? -v ? --reroll-count ? --subject-prefix ? (I imagine the latter to be only for send-email, is that correct ?) <lfam>They all should work for both format-patch and send-email (they take most of the same options) <lfam>I didn't mean to cause confusion :) <lfam>subject-prefix is more general and can display anything <lfam>-v | --reroll-count are specifically for specifying a "version" of the patch <bone-baboon>When I reported bug#48094 I was asked to get further logs. I ran `guix build --no-substitutes --check` and the build failed. Then I looked for logs in `/tmp/guix-build-strace-5.8.drv-0/` but I do not see them. Could it be that "Since the “dumping logs” phase failed" there are no logs: https://issues.guix.gnu.org/48094 <lfam>Just try it and look at the Subject line of the generated patch tissevert <lfam>bone-baboon: You can always capture a log like this: `guix build foo 2>&1 | tee log` <lfam>Beyond that, I don't understand what you're asking <lfam>You didn't mention that you used --keep-failed, so this type of test-suite log would not be preserved anyways <lfam>If you did that and the logs are not there, maybe it is because of that error <lfam>It's weird that a locale issue would make it crash like that <bone-baboon>lfam: Sorry that was a typo I did use `--keep-failed`. <lfam>Do you have the Guix locales set up correctly? Is this on Guix System or another distro? <lfam>It would also be nice to understand the environment you are building in. As mentioned in the bug report, this test suite is very sensitive <Noclip>bone-baboon: If a guix building process fails it should tell you the location of the log file. It's usually as bzip compressed file inside the store. <lfam>This is a different log Noclip <lfam>Also, those logs are not kept in the store, but in /var/log/guix <bone-baboon>lfam: Guix System. How would I check if I have locale setup correctely? In my system configuration there is `(locale "en_US.utf8")`. <Noclip><lfam "Also, those logs are not kept in"> Oh, you're right. Usually I only look at this long base64 string and what's behind it but not at the rest of the path. <lfam>You would know if it was not. You'd see warning messages about it every time you used the guix command <lfam>bone-baboon: I'm going to try building strace and see what happens <bone-baboon>lfam: What do you mean by "environment you are building in"? I have a x86_64 computer with Guix System installed on it. The `uname` and `guix describe` output where in the bug report. Is there more information that I can provide that would be helpful? <lfam>Another key piece of information is the file system used for the build directory <lfam>I mentioned it earlier, by the way, but Linux 5.9.3 is what 1.2.0 was released with. I assume you're still using that older kernel because you are still working through build issues to update, but I just wanted to warn you that you're using something that's kind of old <lfam>I mention it because sometimes people don't realize that they aren't updating the system <bone-baboon>lfam: Yes thank you. After you mentioned that I rebooted the computer and that brought it to 5.11.16. <lfam>Okay. That's a significant change that might affect the behavior of strace's test suit <lfam>Also I see there are new releases of strace. We should probably update <bone-baboon>lfam: I will do a `guix pull` and then try to build strace again. <lfam>You could check in `mount` the filesystem type being used for the build directory <bone-baboon>lfam: From the system configuration the file system of / is ext4. <lfam>Okay, and /tmp is part of '/'? Not a separate filesystem? <lfam>ext4 is the most typical filesystem for this kind of thing so it should be fine <bone-baboon>lfam: The only other partition is /boot/efi which is vfat. <lfam>It's still building on my end <lfam>The strace package could use some work <lfam>The 'disable-failing-tests' phase is a no-op <lfam>It actually has an effect in the newest (unpackaged) version <lfam>Oh, my test setup was bogus. It does have an effect in 5.8 too <bone-baboon>I am doing a pull and then I will try building strace. <lfam>Alright, it crashed for me in the same way <lfam>I built /gnu/store/9p8impni1c2xd3iykjdab9x1ss99213s-strace-5.8.drv on berlin.gnu.org <bone-baboon>lfam: Are you able to get the logs in `/tmp/guix-build-strace-5.8.drv-0/`? <lfam>I didn't use --keep-failed <lfam>If it didn't work for you, it's unlikely to work for anyone else <lfam>Someone needs to look at the code that dumps the logs and see what it tries to do <lfam>bone-baboon: Did you google the error message yet? <lfam>There are several results for "guix scm_from_utf8_stringn" <lfam>Maybe there is something to learn <bone-baboon>lfam: When I do an internet search for "scm_from_utf8_stringn" the only relevant thing I get on the first page of search results is documentation for Guile. I prefer not to use or promote Google search. <lfam>I suggested searching for "guix scm_from_utf8_stringn" <lfam>You can use whatever search engine you wish but you will hobble yourself if you don't use google <lfam>And that's fine, but the rest of us will just do the google searches for you <bone-baboon>lfam: Adding guix to the front of the search only added Guix documentation to the search result. I will try another search engine. Thank you for bringing to my attention the difference in search results. <lfam>Oh, I guess that's one of the advantages of google. It's learned that I'm looking for guix things <lfam>There's a lot of hits in our IRC logs <lfam>Maybe there are irrelevant, I don't know <lfam>I mean "Maybe they are ..." <civodul>sneek: later tell apteryx i've just emailed you regarding the gnupload failure; sorry for the delay! <bone-baboon>lfam: So the searching that was not giving me good results was with duckduckgo and when I tried searching with searx.ir I get much better search results. The searx results included results from Google search. I think I will try swithching to searx. I also noticed more censorship with duckduckgo search results recently. <bone-baboon>lfam: Thank you for giving me that extra little push to try another search engine. <lfam>Cheers. It's good to have so many search engines <lfam>I wonder if it's related to the custom 'patch-tests' phase of that package <merazi>My apologies if this is a stupid question but... Should I worry about the number of generations on my Guix system? Is having a lot of generations bad for the system in any way? I'm a bit concerned... <jackhill>lfam: interesting. Hmm, no activity on the gentoo ticket since 2019… <jackhill>No idea, I haven't looked at the package yet :) <lfam>merazi: The only negative effect is that each generation uses some disk space <lfam>Eventually you will need to remove some of the old generations and free space with `guix gc` <jackhill>lfam: I suspect it is a little bit more subtle of a problem since the same package version used to work. Probably a dependency change: https://ci.guix.gnu.org/build/261590/details Acording to git log apstream-glib was last touched in October by none other than nckx :) <lfam>jackhill: It could be related to the ungrafting commits that were deployed today <lfam>It's not good that that 'patch tests' phase is undocumented <lfam>It should have a comment explaining itself <bone-baboon>Should `guix pull --no-substitutes` be building things like groff and python? I used `--no-substitutes` because I am trying to build the packages I use locally on my system. <lfam>Those are dependencies of basically everything <bone-baboon>lfam: What is `guix pull --no-substitutes` building the dependencies for? I know what the dependencies are if I do `guix build --no-substitutes strace` for example. <lfam>They are dependencies of Guix itself, either directly or transitively <nckx>Noclip: Coreboot supports the X230T, but the BIOS chip is (physically) very difficult to flash compared to the X230T. You can't clip the chip but need to solder wires to it. And indeed, the factory firmware comes with a restrictive WLAN whitelist of non-free cards. I use a USB one. <lfam>bone-baboon: So, `guix pull` updates Guix, thus you need its dependencies <lfam>If they aren't dependencies of Guix itself, they are used to build profiles. Groff is like that <lfam>This is the same reason that `guix remove foo` sometimes has to build or download things. Because the programs used to build the profile must be available <apteryx>civodul: thanks for the tip! retrying the upload <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, civodul says: i've just emailed you regarding the gnupload failure; sorry for the delay!