IRC channel logs


back to list of logs

***fxbjqywmr is now known as jje
<sturm>Any tips for having both Python 2.7 and 3.5 available at the same time? It seems my `python2.7` command has disappeared now I've locally installed 3.5. Or maybe I'm confused...
<sturm>Or is this really where I need to look at `guix environment`? Do `python2.7` and `python3.5` symlinks not really coexist as they do in say Debian?
<geemili>sturm: I have python2.7 and python3.5 both installed.
<sturm>thanks geemili, I'll do some experimenting - if I install python@2.7 it does seem to remove `python2.7` from my path and vice versa. I could have sworn I had them both at one stage, like you.
<sturm>sorry remove `python3.5` I mean
<geemili>sturm: Have you tried installing `python` and `python2`?
<sturm>geemili: ah clever! This worked: `guix package -i python@3.5 python@2.7`. Thanks!
<geemili>sturm: Glad that worked for you, but you can just do this: `guix package -i python python2`
<geemili>python2 is it's own package, without needing a version specifier
<sturm>geemili: oh, I don't seem to have a `python2` package, maybe it's newish?
<sturm>my packages list is probably a few weeks old
<sturm>geemili: I can't see that package here
<geemili>sturm: Oh. I thought it existed. Just ignore me then.
<sturm> Do you know if it bothers Python having both 2.7 and 3.5 site-packages on the PYTHON_PATH?
<sturm>Hmm just tested and it does seem to try to load 3.5 libraries into 2.7 if I have two `export PYTHONPATH=...`entries, one for each version.
<JamesRichardson>Has anyone installed guixsd onto a linode?
<albertoefg>sneek: help
<albertoefg>sneek: later ask lfam to pm to play hedgewars
***jim_ is now known as jje
<sturm>JamesRichardson: You might be interested in cwebber's experiments with installing GuixSD on Rackspace:
<bavier>JamesRichardson: paroneayea has been trying to do such a thing recently
<baconicsynergy>So, I'm still getting the hash mismatch for module-import-compiled on the live media. amz3 somehow got it to work earlier but never said how...
<baconicsynergy>i mean, for guix pull
<bavier>baconicsynergy: use the --fallback option
<civodul>Hello Guix!
<Apteryx>Hi Guix! Any idea how to inspect the effect of a substitute* rule on the source files?
<jmd>Apteryx: diff the old and new versions?
<Apteryx>I guess I could run the build command in the interpreter with a breakpoint at the right place?
<Apteryx>jmd: But when is the altered source kept? In the built derivation, there is no more sources.
<jmd>guix build -K
<Apteryx>jmd: Will this work if my build doesn't fail?
<Apteryx>(-K being --keep-failed)
<Apteryx>civodul: Hi :)
<jmd>What I do, in those circumstances is to force it to fail at the relevance phase.
<civodul>or just Ctrl-C in the middle of the build
<Apteryx>OK! I'll try this! Thanks both :)
<jmd>rekado: The image on is cropped on my browser.
<Apteryx>The problem now is that I already successfully built it once, so I cannot interrupt the build process... it just quickly print the built derivation URL in the store.
<Apteryx>Nevermind, I just tweeked the source enough to trigger a rebuild with make and then I was set.
<rekado>civodul: I see that the update to 4.9 has been reverted and an update to 4.8.15 has been pushed.
<rekado>civodul: should I rebase version-0.12.0 on top of master and revise the package addition/upgrade count?
<civodul>rekado: you definitely need the linux-libre "downgrade", as well as a few other commits (translations & doc at least)
<civodul>whether you rebase or cherry-pick is up to you :-)
<civodul>i *think* rebasing is safe
<jmd>Rebasing to a branch currently published will give problems if you ever push to that branch again.
<civodul>rebase or merge, either way is fine with me
<rekado>I was thinking: rebase on top of master, force push. “version-0.12.0” only becomes stable with tagging the release.
<rekado>civodul: thanks for the documentation fixes!
<jmd>rekado: Did you see my earlier comments about ?
<rekado>jmd: about the image being cropped?
<rekado>jmd: the big one or the small one (on the sub-pages)?
<jmd>Both actually.
<rekado>how wide is the browser window?
<jmd>The window is wide, but it looks like the .css limits it somehow.
<rekado>I see that it doesn’t behave well when the browser window is about 600px wide.
<rekado>I don’t see this in Icecat or epiphany
<jmd>I'm using torbrowser
<jmd>On the main page I see "Bootstrappable Bui"
<civodul> <- this light is green
<jmd>On the movation page I see "Bootstrappable Builc"
<jmd>rekado: Also you might want to add a link to on the motivation page.
<rekado>civodul: yay
<rekado>jmd: okay, thanks. I’ll investigate this after the release. Will also add the link.
<JamesRichardson>Hello Guix!
<JamesRichardson>I've successfully installed GuixSD on a Linode.
<JamesRichardson>I'll attempt to reproduce such, take notes and write up something.
<JamesRichardson>If there's interest and I can actually repeat the process.
<rekado>v0.12.0 tagged, release branch created, jobset for release branch created on hydra
<rekado>bleh, I get test failures during “make distcheck”
<rekado>builders, derivations, packages, union, lint, containers
<rekado>maybe that’s related to running inside of “guix envirnoment --container”…?
<rekado>so I guess I’ll actually have to do this on my GuixSD laptop, adding an external drive to prevent running out of space.
<rekado>copying over the store now, then bind-mount to /gnu and restart the daemon. Then I should have sufficient space for building the images.
<rekado>(and to get texlive…)
<jmd>rekado: I appreciate the hard work you're doing on this no-fun job.
<rekado>thanks :)
<janneke>jmd, rekado: +1
<rekado>I think a big part of the difficulty is because I’m doing this for the first time
<jmd>Hmm. We'll have to make a rule that nobody should ever do anything for the first time.
<jmd>(anyway I'm certainly glad it kept you away from the Weihnachtsmarkt)
<civodul>reproducible initrd: vs. :-)
<geemili>How do I update GuixSD?
<jmd>guix pull
<geemili>jmd: Should I do a `sudo guix pull`?
<geemili>jmd: Thanks!
<rekado>geemili: “sudo guix pull” updates the guix command for the root user.
<rekado>to update your packages do “guix package -u .” as the user whose packages you want to update.
<rekado>for the system profile use “guix system reconfigure /path/to/config.scm”
<rekado>civodul: distcheck failed with an error at the very end:
<rekado>ERROR: files left in build directory after distclean:
<rekado>Is this related to 5a5fc61f072eaa7fe9bfa65dbbd4c6215d88626c ?
<jmd>rekado: It looks like the author forgot to add those to CLEANFILES
<rekado>jmd: ah, I see. I’ll add them to CLEANFILES in nix/
<jmd>sounds like a plan!
<civodul>rekado: one second
<civodul>rekado: i just pushed the fix to master, you can cherry-pick it
<rekado>civodul: is it a problem that this happens after the tag for v0.12.0?
<civodul>rekado: it's best if the tag really corresponds to the checkout used for 'make dist'
<civodul>i think it's ok if you delete the remote tag, it hasn't been there for long
<civodul>what i do is keep a local tag, and push it only once 'make dist' has succeeded
<civodul>distcheck even
<rekado>I see.
<rekado> says to first push the tag, then run distcheck.
<rekado>(I ran “make check” before pushing the tag, though)
<civodul>ah silly me, apologies!
<jmd>The Soyuz numbering system!!
<rekado>no problem.
<rekado>while make distcheck is running I’ll work on the text of the announcement
<davexunit>release time!
<djLeGit>Hello guix!
<djLeGit>I have a quick question about the nginx-service as described in the manual
<djLeGit> describes that the passed config file should match what is given to `nginx-service`
<djLeGit>does this imply that, if I only pass a config, I should have the default log and run dirs specified in my config file?
<davexunit>djLeGit: correct, you will need to figure those appropriately
<davexunit>the nginx service needs work, but I would recommend passing files in vhost-list instead
<djLeGit>davexunit: Could you link to me a piece of the manual that describes this?
<djLeGit>please :-)
<davexunit>I don't know if it does
<davexunit>read the source
<davexunit>guix will generate the right config for user/group, where the pid file goes, the default log and run dir, etc.
<davexunit>if you don't want to do that by yourself, use vhost-list
<djLeGit>davexunit: I found some pretty good pointers in the manual in the master branch. Thanks for the guidance
<paroneayea>bavier: I am cwebber, depending on the context fwiw ;)
<paroneayea>there's another "cwebber" in the free software area (also known as chris webber) who has the username cwebber here, unfortunately
<paroneayea>nice person though
<civodul>djLeGit: for the record, the code is at
<civodul>djLeGit: but this is WIP, there are improvements to this submitted to the mailing list
<civodul>you might want to chime in :-)
<djLeGit>civodul: thanks!
<paroneayea>I don't think 8sync will really be usable by anyone else until next release, but maybe it's time to package it for guix anyway
<djLeGit>on a totally different note: are per-user services something that is somewhere on the guixSD roadmap?
<civodul>there are no concrete plans but it's been discussed a few times
<paroneayea>djLeGit: I think we've discussed it before, I don't think anyone has plans to work on it but it could maybe be possible if we can reduce assumptions that the services can control the user / have to be root iirc? I think probably first would be making "persistent profiles" work nicely
<civodul>paroneayea: persistent profiles?
<paroneayea>civodul: persistent environments, sorry
<paroneayea>I guess it isn't related.
<civodul>yeah, not sure :-)
<djLeGit>paroneayea: what would be the difference between persistent environments and profiles?
<paroneayea>djLeGit: well, environments are profiles :)
<paroneayea>djLeGit: just currently they don't stick around
<paroneayea>djLeGit: so here you'd want to be able to say, "hey, set up an environment here, and keep it at that directory"
<paroneayea>and you'd be able to upgrade it and etc
<paroneayea>one of those things that's generally wanted here, but nobody's gotten to
<paroneayea>would make using guix for development environments a lot nicer
<paroneayea>especially if your development environments happen to pull in texlive ;)
<djLeGit>Can't live with texlive, can't live without it ;)
<paroneayea>djLeGit: anyway, are you new here? if so, welcome!
<djLeGit>paroneayea: I've lurked several times before, using different handles ;)
<djLeGit>the dev ML is pretty high volume :O
<djLeGit>how many more-than-once contributors does guix have?
<paroneayea>I don't know djLeGit, though maybe is the closest to metrics there are to look at
<paroneayea>not that I advocate Black Duck ;)
<paroneayea>tl;dr: "it's busy!"
<paroneayea>we're now over 40 contributers per month, impressive!
<djLeGit>Looking good!
<djLeGit>davexunit: The nginx vhost related stuff works like a dream :D
<davexunit>cool! (I wasn't sure if it would)
<djLeGit>although I don't think ngingx call these things vhosts. Seems more apache like
<djLeGit>I've been trying to run away from apache's config hell for ages ;)
<jmd>Apache certainly has a knack of making jobs which should be rather simple into a very complicated affair.
<davexunit>djLeGit: yeah it's a bad name
<davexunit>but what to change it to? that's the question I can't answer
<davexunit>that name doesn't feel write either
<davexunit>er, right*
<djLeGit>meh, it is probably good enough. At least it's not confusing as to what it refers to
<davexunit>I agree that it's too apache-like. nginx doesn't use the term "virtual host" anywhere in its documentation.
<davexunit>I'm to blame for giving it this name :)
<djLeGit>is it possible to configure guix (not guixSD) to use different paths instead of /var and /gnu/store?
<davexunit>djLeGit: yes, but there are consequences.
<davexunit>if you use something other than /gnu/store, you will not be able to use any of our pre-built binaries.
<djLeGit>davexunit: that is to be expected :-)
<djLeGit>the short of it is that I would like to try to get a guix running on top of Replicant
<davexunit>but there are configure switches for all of these things
<davexunit>so do as you please :)
<davexunit>djLeGit: that would be very cool
<djLeGit>davexunit: I know! Abysmal build times, here I come :D
<davexunit>if you could somehow do the builds on a more powerful arm machine first...
<davexunit>but finding any ARM chip that do build software quickly is unlikely
<rekado>do you know what this means?
<rekado>guix package: error: build failed: while setting up the build environment: unable to make filesystem `/gnu/store' private: Invalid argument
<rekado>background: I bind mount /mnt/gnu to /gnu (because there’s more space on the system at /mnt)
<davexunit>no clue
<civodul>rekado: this has to do with clone(2) and MS_PRIVATE
<rekado>looks like “mount(0, "/gnu/store", 0, MS_PRIVATE, 0)” fails
<civodul>now i can't tell you why that happens :-/
<rekado>I can work around this for now
<djLeGit>Is anyone using an ssd cache + large spinning rust with GuixSD?
<civodul>ACTION has everything on an SSD
<djLeGit>civodul: All the more power to you :-)
<civodul>i suppose someone willing to speed up builds could have /tmp on SSD and /gnu/store on a spinning disk
<rekado>civodul: is it normal that after gnupload I can’t immediately download from
<civodul>rekado: yes, it can take a few minutes
<civodul>normally we receive a notification by email
<rekado>ah, good. It’s fine now
<rekado>got a little impatient.
<civodul>i did receive it
<civodul>yeah, i know that feeling
<civodul>i share the stress you experience ;-)
<jmd>I'm having trouble getting guix system container to do anything sensible.
<efraim>do we package libdns under a different name?
<efraim>the gnupg-2.1.17 release notes say it removes support for adns and uses & bundles libdns
<jmd>efraim: We have bind. Is that what you mean?
<efraim> i think
<efraim>from the README: dns.c is intended to be dropped into existing project builds. The included Makefile is mostly for development and testing.
<jmd>and what does it do?
<efraim>it bills itself as "A non-blocking DNS resolver library in a single .c file"
<jmd>I suste
<jmd>suspect we don't have it.
<ng0>I figured that "look, a work in progress package / please anyone finish this if you'd like to" doesn't work at our size yet, so expect some action on old threads/patches in the next hours/days/weeks :)
<ng0>is there anything wrong about this: (add-before 'check 'fix-tests (lambda _ (with-directory-excursion "tests" (substitute* '("kakasi-1" "kakasi-4" "kakasi-5" "kakasi-6" "kakasi-7") (("/bin/echo") "echo"))))) nevermind any parens I might've forgotten, this is taken out of context .. this fails at kakasi-4, not -1
<rekado>civodul: after make distcheck I have quite a few po files that have changes. Should these be committed or should I ignore them?
<ng0>i think I can take the shortcut and do it with find-files
<civodul>rekado: ignore them :-)
<ng0>no, find files doesn't work in this case. is there any mistake in the (add-before) I wrote? otherwise I have to look at the files more closely
<rekado>argh! I didn’t notice (package-arguments guix-0.11.0) in guix-devel!
<rekado>already pushed the +1 commit
<rekado>and the remote refuses my naughty attempt to rewrite the commit
<civodul>you can do a +2, that's ok :-)
<civodul>or you can delete the branch and re-push it
<rekado>but there’s already a hydra evaluation for the branch
<ng0>the guile backtrace reads as if line 11 of tests/kakasi-4 is causing some error, line 11 does read: . ./ , where in the folder is a simple file which includes two variables
<ng0>if I leave kakasi-4 out, the substitute succeeds.. curious.
<civodul>rekado: we can cancel it and restart it
<ng0>what's GNU od?
<ng0># test for encoding
<ng0># (require: GNU echo, GNU od)
<ng0>ah.. some basetool I suppose
<civodul>part of Coreutils
<ng0>how do I make it accessible to the build system?
<ng0>this failed: ret=`cat tmp|od -t oC -w80|head -1|sed -e 's/^0* //'`
<rekado>civodul: hmm, the tag is on a commit on that branch, and the uploaded release tarball uses it
<rekado>but maybe this doesn’t matter because I won’t throw away my local commits.
<rekado>feeling dizzy
<civodul>rekado: if in doubt, just make an additional commit, that's fine
<civodul>would that work?
<civodul>once you're done, we'll discuss the release process ;-)
<civodul>i'm going offline for 30mn or so
<ng0>what's with this weird kakasi-4 file that it defeats all rules of substituting
<ng0>i'll try to fix this in the next weeks.. this is weird.
<ng0>good night everyone
***roptat_ is now known as roptat
<davexunit>ACTION stomps floor and chants "guix re-lease! guix re-lease!"
<jmd>ACTION serves davexunit with an antisocial behaviour order
<davexunit>darn :(
<newdan>Is there gonna be a release soon? :D
<jmd>newdan: At Christmas ... if you're good.
<rekado>still building…
<civodul>cool, lemme know if you need something
<rekado>I need disk space :)
<civodul>heh :-)
<efraim>way off topic, is there a compose + key combo for € ?
<rekado>civodul: guix-binary.mips64el-linux.tar.xz cannot be built because it wants to build guix, but I don’t have a mips64el machine. Same problem for armhf, I think.
<efraim>compose + e + =
<civodul>rekado: yes, we need to make them on
<civodul>rekado: is that with the tip of version-0-12-0?
<rekado>that’s with v0.12.0 +1
<civodul>c8e2219cfb914429b6409dbef1491652b910f70b, right?
<rekado>(I deleted and recreated the branch with the fixed commit)
<rekado>c8e2219cfb914429b6409dbef1491652b910f70b, right
<civodul>rekado: tarballs for arm & mips are being built!
<civodul>well, the mips box has a clock issue
<civodul>mark_weaver: could you fix the clock on hydra-slave0?
<rekado>civodul: when they are built on hydra, how does the signed upload work?
<rekado>or are these just substitutes that I can download in the process of building the guix-binary tarballs?
<civodul>rekado: yeah these are just substitutes
<efraim>I should probably change that
<rekado>civodul: thanks for the clarification.
<civodul>efraim: indeed!
<civodul>oh, funny there's 1 test failure on armhf
<rekado>yeah, I *just* ran into it!
<civodul>on arm?
<civodul>mine was on tests/
<civodul>i suspect is non-deterministic
<rekado>oh, sorry, I’m being stupid
<rekado>it was “tests/” when creating the disk image for x86_64
<civodul>oh neat
<rekado>ACTION finds it hard to stay concentrated
<lfam>I'd like to interject to say Thank you! rekado and civodul for working on the release!
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, albertoefg says: to pm to play hedgewars
<civodul>hey lfam :-)
<civodul>rekado: do you manage to build one of the two images?
<rekado>I’m still building the i686 image
<rekado>it’s pretty slow here on my laptop
<rekado>would have been great to do this on the office workstation in a container, but that led to test failures.
<ng0>do we have chmod -R for our (chmod) function?
<efraim>i've never checked before
<ng0>ah. i meant chown
<ng0>well, question for both
<lfam>ng0: They're both documented in the Guile procedure index:
<efraim>lfam: have you sent an email to the exim people about getting early access to the next release for CVE-2016-9963, or are we waiting for the 25th with the rest of the plebians?
<rekado>civodul: the i686 image is ready now :)
<lfam>efraim: Yes, we will have early access to the fix
<civodul>rekado: awesome! the arm tarball is running tests again
<ng0>so one problem I have: the gnunet-service needs to create files after it is started (bootstrap servers etc). I chmod and chown stuff in advance, but things like /var/lib/gnunet/hostlist/learned.txt get created by root, therefore they are rw only by root and no one else, preventing a bootstrap to ever happen
<ng0>ialso suid, but I know I miss the two binaries for gnunetdns group
<ng0>this is however very unrelated to bootstrap in my experience
<civodul>by "root" or by some unprivileged "gnunet" user?
<civodul>i'd expect the latter
<ng0>ah, harmut just wrote I should look at postgres service more closely
<civodul>paroneayea, davexunit: BTW, there's a form of "persistent environments" in master:
<civodul>ng0: yeah, many services have similar requirements
<civodul>Cuirass also
<davexunit>civodul: neat!
<davexunit>I have some thoughts about improving usability here, but this is a great start! thank you!
<ng0>the reason for the system service is so that gnunet can be run as a system service (user gnunet, group gnunet; additionally one gnunetdns group fo
<paroneayea>civodul: oh!
<paroneayea>nice :D
<paroneayea>civodul: I will have to try this
<ng0>the reason for the system service is so that gnunet can be run as a system service (user gnunet, group gnunet; additionally one gnunetdns group) and users (people, accounts, etc) can just be added to the gnunet group and run the functions. the problem I'm facing is that somehow suid seems not to be enough, and I have to replicate what we did for gentoo in some other way, where I'm now positive postgres service
<ng0>may be of help
<civodul>davexunit: yes that was just a low-hanging fruit, and i was tired of redownloading the stuff for my environment at work :-)
<davexunit>yes, me as well.
<davexunit>I will have to start using this.
<buenouanq>All I want for Christmas is gnunet@10.2 ;_;
<buenouanq>the world needs this as soon as possible
<ng0>one way to speed this up: read the bugtracker and get involved fixing the cadet bugs
<jmd> How do I set the default keymap?
<nliadm>I'm trying to run weechat from guix (on top of fedora) and it can't do https. Setting SSL_CERT_{FILE,DIR} doesn't work, either
<civodul>rekado: same test failure in tests/ on arm but i don't have access to test-suite.log
<ng0>civodul: i don't see in gnu/services/cuirass where cuirass switches the user
<lfam>Tor users, I got this security advisory from Debian today:
<lfam>nliadm: How's it fail?
<nliadm>script: error downloading list of scripts: curl error 60 (server certificate verification failed. CAfile: none CRLfile: none) (URL: "")
<civodul>ng0: the #:user argument to 'make-forkexec-constructor'
<ng0>lfam: 0.2.5.x i don't see how this affects guix
<civodul>lfam: thanks for the heads-up; it's low on details ;-)
<lfam>ng0: Click on the CVE number to see this page:
<lfam>I don't know Tor's release strategy, so I don't know what versions are vulnerable and which aren't. It's just a "heads up" :)
<nliadm>it looks like weechat is built against openssl, so it should be honoring those environment vars. and the files they're pointing to exist
<lfam>nliadm: And do the SSL_CERT variables point to something that exists?
<lfam>Ah :)
<lfam>We've had similar problems with other users of libcurl
<lfam>nliadm: Can you file a bug?
<ng0>civodul: hm.. aha! this is exactly what I did not set. so and setuid.. I need to setuid 2 binaries to gnunetdns, I suppose setuid is also documented somewhere
<nliadm>just an email to bug-guix ?
<nliadm>okay, I'll send one when I get a chance
<efraim>lfam: I pushed the update to tor without seeing that it had a CVE attached to it
<efraim>their email to debian-security listed the 0.2.9.something as the "upgrade to" version for testing/sid
<lfam>efraim: Okay, thanks for looking into this :)
<ng0>WOO. i finaly get more output than before.. I hope i'm getting this done by 2016-12-31
<rekado>ERROR: In procedure copy-file: Success
<rekado>oh… I think I *cannot* build the disk image for x86_64 at all on this laptop
<rekado>the guest gets a kernel panic because I’m using Libreboot and the CPU feature for virtual extensions is broken
<rekado>I’ll try again building this on my workstation in the office
<rekado>gah, how annoying
<civodul>rekado: that error suggests ENOSPC, no?
<civodul>(an error-report bug i've become used to)
<rekado>but I still have about 6GB left on /
<civodul>on /tmp as well?
<civodul>if you managed to build the i686 image, i'd expect the x86_64 one to work as well?
<rekado>I’m not thinking straight today, feeling sick
<rekado>I just kicked off the build on the remote; let’s see how far it gets.
<lfam>civodul: Some serious bugs in Nagios were disclosed today: <> <>
<civodul>rekado: sorry that this is so tricky; it's usually a little less hard
<civodul>lfam: thanks for the heads-up! i can't handle 'em right now :-/
<civodul>i haven't deployed it yet though
<lfam>What do you think we should do given the comment in the package definition "Newer versions such as 4.2.3 bundle a copy of AngularJS."?
<civodul>dunno, i don't think we could unbundle it in a meaningful way
<civodul>we'd need the npm importer and all that--out of reach
<civodul>rekado: the test failure on arm may be determinstic; entering debugging mode...
<civodul>we should have caught it earlier, that sucks
<rekado>civodul: bleh :(
<rekado>should I delete the tag?
<rekado>then we can try this again once the arm error is fixed.
<civodul>rekado: no, keep the tag, the tarball is out there already
<civodul>we'll see
<rekado>I’ll try to finish this tomorrow morning. Even on the workstation space doesn’t seem to be onough
<rekado>16G /tmp and 19G for /
<civodul>wait, you need 3G or so, not more
<rekado>yeah, it’s really weird
<rekado>dunno what’s going on :-/
<rekado>is it the --image-size argument?
<civodul>could be
<rekado>I’m running ./pre-inst-env guix system disk-image --image-size=850MiB gnu/system/install.scm
<civodul>try 900MiB
<rekado>okay :)
<civodul>i should have mentioned it earlier i guess :-)
<civodul>re arm/mips, at worse the binary tarballs will be built from one commit later, no big deal
<civodul>anyway, surely everything will be ready tomorrow!
<rekado>I’m going to get some sleep now lest this headache gets any worse
<rekado>thanks for all the help!
<civodul>sleep well!
<civodul>it's well deserved
<rekado>…and the disk image just built :)
<rekado>more tomorrow :)
<rekado>ACTION –> zzZZ
***jz is now known as Guest2791
<buenouanq>how can I deal with something that is looking for things via explicit paths?
<buenouanq>an installer wants to run chmod, but it's actually doing /bin/chmod or something I think
<civodul>buenouanq: patch out the absolute file names
<civodul>there are examples of that in the packages
<civodul>rekado: for tomorrow: 64b5e4137649be75c6f4ea37991be95a23844a95 fixes the issue
<civodul>we could cherry-pick it in version-0.12.0, then change guix-devel to refer to that, then build the two missing tarballs from there