IRC channel logs
2023-08-22.log
back to list of logs
<antipode>sneek: later tell amjoseph: it does: antioxidant. Even better, it doesn't use Cargo.lock either; it works like normal package definitions. <martin2020>I downloaded one, but I get errors when I try to run it. Does anyone else have experience trying to run AppImages? <lilyp>martin2020: you have to use patchelf to get the correct linker and libraries, but then it ought to work <adanska>what is this "new package style" that i keep seeing in commits? eg. a08592b055e9b6d9baf704e2405ba9ae38215e62 with syncthing. is there a new reference guide re writing packages? <adanska>i feel like thats not the whole picture though. <iyzsong>adanska: it's about using gexps for 'arguments', and remove labels for 'inputs'. 'guix style' can adjust that for old ones. <xelxebar>martin2020: Yeah, it's a tad annoying. As lilyp mentioned, you need to put glibc and all its dynamic libs in a guix shell. Then use patchelf --set-interpreter to set the ld.so to the one in your shell. <xelxebar>Then you can use LD_PRELOAD=$GUIX_ENVIRONMENT/lib the-executable to run the program. <xelxebar>Need to identify all the dynlibs with ldd or similar and then figure out which packages offer the corresponding so files. <podiki>martin2020: instead use -e '(list (@@ (gnu packages commencement) gcc) "lib")' <podiki>sneek: later tell martin2020 see ^ (or log) for using fhs container for appimages <adanska>iyzsong: ahh.. okay, thank you. reading the `guix style` page has answered most of my questions. thanks :) <jpoiret>spine-o-saurus: can be used, although it's quite experimental <jpoiret>usually Guix system uses the linux-libre kernel <jpoiret>for example, there is no isolation of build processes on the Hurd yet <attila_lendvai>if i add multiple sysctl-service-type to my services, then their sysctl entries will be merged, right? <iyzsong>attila_lendvai: only one instance of a service-type is allowed, other can extend it by 'extensions'. 'extensions' for the sysctl-service-type will be merged <attila_lendvai>this is such a confusing part of guix! and i've written multiple services already. i think it's mostly due to the unfortunate naming of the abstractions... service vs. simple-service vs. shepherd's service abstraction, all intermingling in the same context. <attila_lendvai>FTR, the solution is to add this as a service entry: (simple-service 'ipv6-config sysctl-service-type '(("net.ipv6..." . "..."))) <attila_lendvai>adding this seemingly very similar thing leads to an error: (service sysctl-service-type (sysctl-configuration (settings '(("net.ipv6...." . "..."))))) <andreas-e>Were the man pages for C moved? Commands like "man malloc" do not work any more. I have installed gcc-toolchain and not glibc into my profile. <civodul>andreas-e: hallo! i believe it's in the 'man-pages' package <civodul>"guix locate malloc.3.gz" confirms it <andreas-e>Thanks, civodul! The package has last been touched ages ago, I am surprised I somehow lost it from my profile. <jpoiret>attila_lendvai: simple-service creates a service *extending* the one you're giving it <jpoiret>as opposed to (service ...) creating a new service of the type given <jpoiret>maybe renaming `simple-service` to `simple-extension` could clarify that <cbaines>remind me why guile makes so many readlink system calls? <cbaines>I've heard of this issue, so I guess it's come up in relation to Guix, but I've noticed it specifically when looking at the build coordinator <andreas-e>cbaines: Hello! How often is the branch substitute availability recomputed? <civodul>cbaines: how 'bout i reconfigure bayfront? <andreas-e>(The background of my question is the i686 availability, which prevents new patches to be tested.) <andreas-e>Good! I wondered because yesterday the i686 availability hardly changed, but this must be due to only x86_64 packages being built. Thus my second question/suggestion :-) <cbaines>andreas-e, milano-guix-1 was down until yesterday, and the coordinator was offline overnight, so things are a bit behind, hopefully it'll catch up soon though <andreas-e>Right now the texlive packages are being built. The activity site turns into a fast-paced action film! <andreas-e>Is there a way to get an idea of the backlog? Like the number in the gray box for cuirass? <andreas-e>Or otherwise said: How much of the 22.6% missing to reach 100% substitute availability for i686 on master is due to build failures, and how much to scheduled builds? <cbaines>but I think for i686 it's just that the builds haven't happened yet <cbaines>I've discovered the secret setrlimit procedure in Guile now, so I've increased the open file limit, which should help to avoid the coordinator breaking, and hopefully allow me to track down why there's so many files/ports open sometimes <davidl>I have an issue where my guix package fails to build after pulling the channel but when I do guix build -f ./mypackage.scm. It throws an wrong type argument in position 1 expecting string - so hinting at a variable does not exist. What variables may be available during a guix build -f <mypkg> but not after the same file <mypkg> has been commited to the channel and guix pulled? <attila_lendvai>jpoiret, i'd call it service-extension. or anything else that contains the concept/word 'extend', if this mechanism is called extension in the manual and the rest of the codebase. <attila_lendvai>jpoiret, but i have a problem with the use of 'service' itself. i'd call guix services as components to avoid the confusion with stuff that runs as a process. <qeqpep2>Hi, this produces operating-system with many duplicate services: (operating-system (inherit installation-os) (services (operating-system-services installation-os))) <qeqpep2>A bug? How to completely override 'services' field of inherited os? <attila_lendvai>wtf, mingw-w64-x86_64-11.0.1 as a dependency of gzip-1.12 on x86_64-linux? (this is why guix build fails) <jpoiret>attila_lendvai: how did you see that? <attila_lendvai>jpoiret, my root issue is that guix is being built locally after a recent pull <attila_lendvai>is the former one a cross-compile for windows, thought? that'd be rather surprising to me. <jpoiret>i think guix is in the set of packages that is checked for xcompilation <andreas-e>attila_lendvai: Indeed this is the case. The derivation contains inputs such as gcc-cross-x86_64-w64-mingw32. <attila_lendvai>isn't that a waste of build infrastructure? i mean, it's pretty hopess, no? <jpoiret>I wouldn't bet on Guix working 100% but some parts might <Altadil>Did a recent commit broke guix ? I juste did guix pull but can reconfigure the system anymore. Seems sheperd-mcron fails to build. <andreas-e>Altadil: This sounds like a bug just was just repaired in the most recent commit. Can you try to pull once more? <Altadil>andreas-e: still no luck. I am on 552d070, acording to guix describe <ekaitz>hi! anyone here has thermald configured for personal use? It's like there's no way to add a configuration file to it <andreas-e>Altadil: Sorry to hear this, then I do not know. <Altadil>andreas-e: that’s fine, thanks for your help <jpoiret>Altadil: maybe it's that very commit that broke it, you could try pulling from a commit earlier <Altadil>jpoiret: going back to one commit before worked, thanks ! <janneke>(read to the end before starting to install/try things, because there's a small twist towards the end) <cbaines>does the latest commit on the master (804074681c03af4f534aff40cc5496112d92416c) branch still need reverting? <janneke>cbaines: i don't have that commit here? <cbaines>janneke, ah, I'm misusing magit, it's 552d0703776c532f25498d5cb852c3c497cb9252 <jpoiret>janneke: i've been writing my own elisp for this because i'm not satisfied by any of the existing solutions. but as you might have guessed, i'm not satisfied by my own code even <jpoiret>i dislike having to keep a state of which files are authorized to create an env automatically <janneke>for now i'm _really_ happy with this solution, but i've only been using it for a day now <janneke>guix shell with its authorize thingy, and now direnv on top of that ... <jpoiret>my own approach is having arbitrary .el being executed for files in a project, and adding helpers to simplify writing it instead <jpoiret>that way you have better control over the set-up, compared to .dir-locals.el and buffer-env/direnv <janneke>yeah, i'm not sure if i like the direnv "magic"; a manual guix shell also has its charm <janneke>but setting the emacs environment per buffer in an easy way that really helps me <hako>Hi Altadil, latest commit should work now, can you pull again? <hako>jpoiret: Thank you! Though really feeling stressed now... <Altadil>hako: pull and reconfigure completed. Everything seems fine. ^.^ <MatoHota-Tmp>I cannot use ./configure during a package build and get a C compiler cannont create executable <mirai>MatoHota-Tmp: you don't have a ./configure file in the source then? <mirai>confirm this by downloading the source directly <MatoHota-Tmp>I try to copy part of it - I hope I won't make too many mistakes <MatoHota-Tmp>configure: error: in '/tmp/guix-build-florist-22.1.drv-0/florist-22.1-20220106-1C034-src': <ngz>Hmm, in what environment should I run ./etc/committers? I tried guix shell guix, to no avail. <mirai>use a paste site (like paste.centos.org) <MatoHota-Tmp>florist is a software written in Ada that I try to package <MatoHota-Tmp>I had to package the compiler in a "gnat" package that install fine (I can even use it) <mirai>MatoHota-Tmp: well, you'd have to wait for a fortune-teller to appear here since there's no clue as to what exactly is configure complaining about <ngz>mirai: Sure, but all I get is "no code for module (guix gexp)" (and no t-shirt). <ngz>mirai: That's it! I didn't think of that because commiters.scm is a Shell script. Thanks. <podiki>cbaines: is there something up with the us east mirror? last few weeks (i think) often on downloading substitutes it will just timeout, other times be usual quick <ngz>mirai: BTW, I eventually understood your remark about `=' vs `prefix' in wrap-program, but I cannot answer as I don't use dblatex. <mirai>ngz: :) I was planning on replying with a snippet after I squashed my local commits <cbaines>podiki, I'm unsure, I don't have much visibility over how it's working. I can see some timeouts in the NGinx logs, so maybe it's having problems talking to bayfront sometimes <cbaines>it would be nice to have some metrics for the reverse proxying <ngz>mirai: Having a too large GUIX_TEXMF shouldn't hurt however, as long as the packages are not loaded (i.e., with \usepackage{...} or equivalent). So I assume `prefix' is a safe bet. <podiki>cbaines: i haven't found any pattern, often it just doesn't respond for a while so i kill and restart guix build or whatever is trying to get the substitute <podiki>usually that does the trick, very intermittent but happens often <cbaines>podiki, if you'd like to investigate, I can give you access to the VM? <civodul>andreas-e: hey! out of curiosity, what was the reason for removing hdf5@1.12? <civodul>i'm asking because a colleague of mine is adding it to the guix-hpc channel :-) <podiki>cbaines: thanks, but I don't think I would know where to start, my webhosting knowledge is pretty basic <ngz>mirai: Use (search-input-file "whatever.zip") instead of relying on input's name? <andreas-e>It is outdated, and a specialist told me "Only HDF5 1.14.x (currently, 1.14.2) should be kept." <mirai>ngz: so I simply put it as (inputs foo bar (origin …) baz …) ? <civodul>andreas-e: ah thanks, i hadn't seen this thread <civodul>in HPC outdated things may still be in use for a while :-) <civodul>(that said, i'm all for periodic cleanups) <ngz>mirai: You can also do as in texlive-xpinyin <andreas-e>I wanted to try removing other versions as well, but there are tons of strange (in the sense of: having lots of patches and tweaks) packages depending on hdf5@1.8 and hdf5@1.10, so I will give up. <andreas-e>civodul: So they are not essentially upwards compatible? In my algebraic world, most of the time one can just replace a library by a later release, sometimes with more or less trivial updates. <andreas-e>I am not opposed to reverting the commit in case someone needs the package. But the version will be EOL this autumn. <civodul>andreas-e: i don't know the details, it seems to be needed by simulation software colleagues are working on <civodul>dunno, i guess we should be more cautious with this kind of packages maybe <zamfofex>Hello, Guix! 👋 🎉 I noticed there has been some conversation about bringing Hurd substitutes to CI, but it seems it was building it for the incorrect system. Did y’all end up figuring out what was the issue? <hako>Certificate for logs.guix.gnu.org expired? <nikolar>zamfofex: is there an installer or a VM image I can play with <janneke>zamfofex: we're (slowly) trying to address that, severel steps were already taken... <janneke>but yeah, atm there's still a problem with hurd substitutes <janneke>sadly, because quite some packages do not build for the hurd yet, we still need hacks/workarounds <zamfofex>I see. I really wish I could be able to help more actively somehow. <janneke>hopefully that will become easier real soon <indigo-oce>how do I show the available versions of a package? <janneke>indigo-oce: guix show -- try: guix show guile <civodul>nckx, cbaines, apteryx: how do we renew guix.gnu.org on bayfront these days? <cbaines>do we know if it's the cert being out of date, or just NGinx serving an out of date cert? <civodul>"certbot renew" doesn't know about it <civodul>i restarted nginx recently for another expired certificate <civodul>problem is guix.gnu.org gets special treatment because it the site was initially hosted on berlin <cbaines>maybe try running /var/lib/certbot/renew-certificates civodul <janneke>indigo-oce: the command is guix show, so you'll use :guix show <package> <indigo-oce>janneke Oh... I have no idea how I missed that... well the version I'm looking for isn't there... <janneke>indigo-oce: you may alway try --with-version=PACKAGE=VERSION <cbaines>civodul, I think the configuration handles logs.guix.gnu.org, but not guix.gnu.org <cbaines>maybe this was never setup since the website was moved <civodul>cbaines: i did "certbot certonly -d guix.gnu.org" <civodul>why "renew" doesn't know about guix.gnu.org is a mystery to me <apteryx>guix doesn't build on i686 on cuirass: [530/722] compiling... 46.8% of 361 filesbuilding of `/gnu/store/cgfsl0qcgk0vmirys7iji663nfvrfks7-guix-packages-base.drv' timed out after 3600 seconds of silence <andreas-e>Concerning guile versions, is there a good reasons we have kept 2.2.4 without any dependents in addition to 2.2.7? <cbaines>civodul, I don't think guix.gnu.org is included in the certbot configuration, so it probably needs adding <janneke>apteryx: i have some hacks for the hurd to split-up building of guix go-files <apteryx>janneke: seems we could also just bump up the timeout for the packages derivation? <janneke>i think there's a memory problem on the hurd <apteryx>not sure how to affect the max-silent-time of a computed-file derivation? <cbaines>apteryx, I think max-silent-time is a bit of guix-daemon or store connection configuration, rather than being part of a derivation <apteryx>right; then I'm not sure where to specify it for (guix self) derivations <apteryx>what are properties for gexp->derivation? <cbaines>so you can set the default in the guix-daemon config, or change it on a store connection <cbaines>e.g. guix build changes it on the store connection if you pass --max-silent-time, e.g. guix build --max-silent-time=60 /gnu/store/cw6pgpr8yx23dgnkgbnzcran51fvl14i-guix-e318b62df.drv <apteryx>perhaps we should change '(max-silent-time 3600)' in (sysadmin build-machines) on guix-maintenance? <cbaines>apteryx, I'd maybe also step back a bit. I think the channel instance builds for i686-linux are broken because of memory issues, rather than a lack of time. <apteryx>ah! so it had hung by the time it timed out? <apteryx>there are some "out of memory!" messages <apteryx>janneke: I guess your hurd fix will come in handy for i686 as well :-) <janneke>right, that's what my hurd patches are for <janneke>the "26 steps" is prolly somewhat over the top, but 5 steps wasn't enough and i didn't feel like manually making a 10-way split :) <apteryx>ACTION merges the qt branch to master <ngz>mirai: it looks like expat <nikolar>zamfofex: I haven't seen if you responded, sorry <apteryx>it feels good to work with more nimble feature branches! <andreas-e>mirai: I have not seen it before; probably the non-copyleft procedure will be a good fit. <ngz>adreas-e: why non-copyleft and not fsf-free? <andreas-e>ngz: I did not know about fsf-free. But according to the documentation: "license that does not fit any of the ones above". I think it does fit non-copyleft. <janneke>ACTION is confused by git-send-email's --add-header feature <janneke> git send-email pets/*patch --to=65456@debbugs.gnu.org --smtp-pass='***' --add-header="X-Debbugs-Cc: maxim.cournoyer@gmail.com, ludo@gnu.org, dev@jpoiret.xyz" <janneke>failed to cc maxim, and instead sent mail to cbaines, rekado, nckx, zimoun -- sorry guys... <ngz>andreas-e: I admit this is confusing. `non-copyleft' is not a license per se. <janneke>ACTION had never ever such surprises before with git send-email... <janneke>aaand /me also included debugging code... <andreas-e>ngz: Well, logically my impression is that non-copyleft applies to all non copyleft licenses without their own entry; then fsf-free would apply to all copyleft licenses without their own entry. <ngz>andreas-e: Indeed. I certainly have mixed both at some point. I don't think it is not a big mistake, but still.. <andreas-e>Turns out, I have added fsf-free myself more than 10 years ago... And civodul has added non-copyleft some time later. <ngz>I don't think it is* <civodul>janneke: the Makefile.am LGTM (minus debugging statements :-)) but i have reservations regarding (guix self) <civodul>i think we should build in the same way on all platforms <andreas-e>The texlive page seems to imply that the software is mostly copyleft. <janneke>civodul: yeah, just saw them too and sent mail about that <janneke>civodul: aiui, apteryx's problems were with self.scm <civodul>ok, i missed the beginning of the conversation <janneke>you don't suggest we build 26-ways on every platform? <janneke>'twas just an hour ago here, /me included links <civodul>we could do the 26-chunk split on all platforms yes <civodul>rather than just on 32-bit platforms <civodul>a bit of a shame we have to do that at all :-/ <janneke>civodul: thanks for the quick feedback <civodul>so in fact, it's not split in 26 pars <civodul>because self.scm already splits in two module closures <efraim>can we read the headers and split them every X based on the number of other modules imported? <civodul>i think what we should do is profile and fix the damn compiler :-) <civodul>(which i did, but for very small gains) <efraim>checking with wc -l it looks like tex.scm is closing in on crates-io.scm <janneke>ACTION sent updated patches for 65456, but with one comment one line too far down, oh well <andreas-e>janneke: Will this also fix the problem of "guix pull" requiring more than 1GB of memory? <janneke>andreas-e: ah that could be, does that use guix/self.scm to compile? guess so... <apteryx>ah, it's unfortunate, I just noticed the new qtbase refers to python 3.10, which inflates its size by 74 MiB <efraim>I might have to work on splitting up crates-io more ... <mirai>is there some profiler for guile that could be used to find out what/where is it taking so much mem? <apteryx>lilyp: captured as shebangs in python test runner scripts <apteryx>eg /gnu/store/0bglkmf20a3l9ni2bbax368dxkfcg14l-qtbase-6.5.2/lib/qt6/libexec/sanitizer-testrunner.py <nikolar>Are there working guix hurd VM images or installer <nikolar>Oh I somehow missed that completely and it doesn't show up when you serch <janneke>(or hurd blog posts on guix.gnu.org) <nckx>ACTION considers neither janneke nor civodul noise :-) <nckx>janneke: That's weird though. <nckx>Did someone add some auto-CC-teams hook? <podiki>reviewing/pushing https://issues.guix.gnu.org/65330 for a new submitter; question on commit message, should it just be updating to 1.9.5-0.<commit>? or is there a different way for updating version to commit not tag? <podiki>nckx: mumi i think runs the teams script? or can be run separately to get the cc's, last I tried wasn't part of a hook though <janneke>nckx: omg, yes; there's etc/git/gitconfig which has <janneke>[headercmd] ... etc/teams.scm cc-members-header-cmd <janneke>etc/teams.scm cc-members-header-cmd pets/v2-0002-self-Build-gnu-packages-.go-in-26-steps.patch <janneke>so, it's by design, /me didn't f**k up :) <nckx>I'm 'core', hence my suspicion. <janneke>still sad that my manually-added cc to apteryx was stripped <nckx>Yes, that should be considered a bug (not sure whose). <nckx>ACTION goes back to dining o/ <janneke>the cc on the cover-letter worked, no no problem :) <podiki>ACTION sees just such commit messages for updates to version-revision.commit <apteryx>janneke: you manually added a X-Debbugs-CC header? <janneke> git send-email pets/*patch --to=65456@debbugs.gnu.org --smtp-pass='***' --add-header="X-Debbugs-Cc: maxim.cournoyer@gmail.com, ludo@gnu.org, dev@jpoiret.xyz" <apteryx>yes, and then etc/teams.scm would add its own X-Debbugs-CC, and then the GNU Debbugs instance discards all but the last one, IIRC. <apteryx>you may have more luck with 'mumi send-email', which goes to lengths at merging the X-Debbugs-CC <podiki>mumi send was pretty slick when I tried it, and think a few things were fixed since then too <apteryx>ACTION still uses patman for the ease of recording the associated bug number and documenting changes between patch series <janneke>apteryx: civodul just had a few comments on the split-build patches just here, LGTM on the Makefile.am patch (without debugging targets) and always do the 26-way split on the guix/self.scm patch <apteryx>janneke: I just wonder if instead of manually defining splits, we could have logic that automates a split? Perhaps future work <janneke>apteryx: in the makefile, yeah that would be nice <apteryx>we could even use Guile in our Makefiles to do so ;-) <janneke>which generates posix-compliment makefiles, afaik <apteryx>I think you can have canned recipes in a Makefile.am just fine <janneke>yeah, but we need automake not to complain, and a fall-back for non-guile-enabled or non-gnu make? <janneke>anyway, /me goes to push the patches <apteryx>it could be as simple as documenting that GNU Make with Guile support is required for building Guix <apteryx>which would help its adoption in places such as Debian, where a bug report has been opened for some time without activity ;-) <janneke>ACTION will mention some of this when closing the bug <janneke>it's kind-of silly anyway that we have .go build instructions in Makefile.am *and* in guix/self.scm <janneke>couldn't make's guile somehove infoke guix/self.scm? <apteryx>maybe! I'd rather the build system be self-contained too, but I haven't reviewed it all. <efraim>janneke: based on my past experiences building guix on (32-bit) powerpc the forced garbage collection will help immensely on memory constrained systems <janneke>efraim: let's hope these hacks work for some of these troubles <janneke>having some movement in this area may already help <janneke>jpoiret: headsup, i've rebased and reset hurd-team; and guix should build for the hurd on master! <vagrantc>ice-9/boot-9.scm:1685:16: In procedure raise-exception: <vagrantc>error: license:arphic-1999: unbound variable <vagrantc>ah, after running guix pull up to db02fcde386892b3a054d64403a4a5bfa1b7fce8 ... guix upgrade fails <ngz>vagrantc: Hmmm isn't arphic-1999 exported from (guix licenses)? <vagrantc>ngz: might be one of guile's inscrutibly wrong mismatched paren errors? <vagrantc>also guix remove ... fails with the same issue <janneke>hmm, fwiw /me just succeeded in pulling to db02fcde386892b3a054d64403a4a5bfa1b7fce8 <janneke>vagrantc: just running `guix build --system=i586-gnu guix' for now... <vagrantc>about the only working thing is "guix describe" for me <janneke>repairing unmatched parens in code ,that would be something <vagrantc>no idea what is wrong ... maybe something is corrupted in the store ... was my thought <janneke>ACTION is still building /gnu/store/gs4jbh0c8pd40x94x88mcalyi13b3lcl-guix-1.4.0-10.4dfdd82.drv <civodul>mirai: i think i'm missing context, could you explain more? :-) <mirai>civodul: the approach I'm taking with stdc++-docs is that patches are applied to the gcc sources directly in the gcc-5 and gcc-9 packages and autoreconf is only done in libstdc++-doc <mirai>this works fine for gcc-9 but gcc-5 is fussy in that it requires an older automake version (that is not packaged) <civodul>mirai: the way i'd do it is by patching the generated Makefile.in rather than Makefile.am <civodul>that way, no need to meddle with Autoconfmake <mirai>so I can workaround it by putting a conditional phase in makelibstdc++-doc that fires only for gcc-5 OR I do a substitution on gcc-5 sources directly <mirai>substitution as snippet in gcc-5 looks cleaner IMO <civodul>all i'm saying is that we should substitute Makefile.in, not Makefile.am <civodul>(similarly: configure, not configure.ac) <mirai>civodul: the patches were upstreamed btw so this funky business _shouldn't_ be needed for > GCC 13.2.0 <mirai>The gcc-* packages are still auto<thing> free fyi, all they're getting is either a snippet or a patch to the sources field <civodul>mirai: maybe i should look at your preliminary patch(es) when you think it's ready? <mirai>sure, all that's left after the gcc business is rewording/squashing <vagrantc>hrm. time to git bisect the results of guix pull ... <apteryx>I wonder if #54447 could be caused by the anti-DDoS mechanism in place on berlin's network? <apteryx>at least some of the cases (which I reported yesterday) seems to have to do with a broken connection <efraim>I'm seeing the arphic-1999 errors also with guix time-machine <civodul>apteryx: i don't think so; the anti-DoS thing must be on the edges of the network, when receiving incoming connectios <civodul>anyone working on the arphic-1999 unbound-variable issue? <vagrantc>got distracted by other things, like food <janneke>ACTION did a quick grep and didn't see anything obvious <janneke>also still running guix home reconfigure and guix pull... <civodul>most likely the newly updated 'guix' package is broken too <civodul>well i don't know, we'll have to check <civodul>that shouldn't prevent you from sleeping well in any case! <efraim>5898b2e8a3dbf7797e83b39a2783c5b543015725 its the 26 chunks that's the first broken commit, tested with time-machine <efraim>I have some things I'd like to try, but I guess getting guix pull working again first and then trying them would be best <civodul>i'm reverting and documenting the problem <efraim>ok. I'll see about playing with it later <civodul>whether the 'guix' package is also broken is another story <efraim>guix/self.scm is only used for guix-pull, so the guix package should be fine