IRC channel logs


back to list of logs

<CornBurglar>Hey, I'm trying to get guix working on Fedora 29, and am running into issues. I have installed guix via the package: and enabled guix-daemon.service, but find that the service fails to start. journalctl shows the error at "libgcrypt version mismatch". Anyone know how I might resolve this?
<dongcarl>Any way to use gold linker in guix?
<dongcarl>I didn’t see anything promising when I did `guix package -s gold`
<CornBurglar>It's part of binutils isnt it
<apteryx>dongcarl: glad it helped!
<Copenhagen_Bram>guix pull --no-substitutes takes a REALLY REALLY long time
<Copenhagen_Bram>at least the first time, I hope
<apteryx>might be bulding guile
<apteryx>this takes forever
*apteryx slightly exaggerated
<tavoris>anyone know what's up with this when running tmux? "tmux: invalid LC_ALL, LC_CTYPE or LANG"
<tavoris>looks like LOCPATH just needed to be set properly
<apteryx>hmm, is even guix build silent nowadays?
<apteryx>It used to be verbose
<apteryx>(on core-updates)
<apteryx>or maybe core-updates is just foobared right not -- I'm trying to build cmake on it, and it just runs out of memory, without printing a single build message... Hum.
<apteryx>maybe some circular dependency?
<Copenhagen_Bram>when did python become compileable?
<Copenhagen_Bram>this thing says it's compiling python files
<Copenhagen_Bram>Compiling '/gnu/store/gobbletygook-python-3.7.0/lib/python3.7/various/directories/and/'...
<bavier>Copenhagen_Bram: compiling python to bytecode has been around for quite a while
<dongcarl>Still not sure how to get gold linker in guix
<dongcarl>it doesn't seem to be in binutils
<dongcarl>as in, when I add binutils to my environment manifest, and do a `which` in the environment, it says not found
<tune>can't seem to update right now
<tune>build of /gnu/store/slrq9npngjf9npr10c9wfh84d2i01jh5-info-dir.drv failed
<tune>but also
<tune>build of /gnu/store/slrq9npngjf9npr10c9wfh84d2i01jh5-info-dir.drv failed
<tune>oh it is the same
<tune>I noticed a while back that guix told me sshfs-fuse could be replaced with just sshfs or something, but now it's complaining about that package name when trying to update
<tune>between now and then I had a few working updates though. are these just upstream changes?
<Copenhagen_Bram>i wonder if there's a guix package for boinc and gridcoin
<Copenhagen_Bram>aww i don't see a package for boinc :/
<Copenhagen_Bram>is it possible to make package requests?
<Copenhagen_Bram>although i might try to learn to do it myself
*Copenhagen_Bram sees guix pull --no-substitutes fail, and runs guix pull --no-substitutes again in the hopes that it win't fail this time
<marusich>dongcarl, gold is part of binutils, but it isn't built in Guix at this time (at least, not on the master branch of Guix).
<marusich>If you run "guix edit binutils" you will find the following comment: ";; TODO: Add dependency on zlib + those for Gold."
<marusich>Perhaps you could try adding it?
<dongcarl>marusich: Thanks
<dongcarl>Lemme get my uses sorted out, then I’ll add it haha
<marusich>Sounds good!
<dongcarl>Btw has anyone had experience static linking libstdc++?
<dongcarl>From what I understand I need the libstdc++ package
<dongcarl>And that’s only defined for gcc4.9
<dongcarl>So I defined it for gcc8 (what I want)
<dongcarl>But it seems to fail to build
<dongcarl>Can anyone else confirm?
<dongcarl>Or confirm that I need libstdc++ for static linking it?
<marusich>I'm afraid I don't know about that, so hopefully somebody else does.
<marusich>Gotta run
*dongcarl waits patiently
<g_bor>hi guix!
<g_bor>dongcarl: I'm not sure about that, but I believe that libstdc++ is built as part of gcc8, gcc4.9 was the last version where the C dirver was used for builidng the compiler, later vesions require the C++ driver, and I believe that also libstdc++.
<g_bor>I didn't have a look at the build system to confirm this though...
<dongcarl>That might be the case... I’m asking because in my builds I specify “-static-libstdc++”, and running the same build with the same flags on my guix environment and on my normal arch machine yields binaries that look different to `ldd`
<dongcarl>The guix one seems to want the libstdc++ so, but the arch one seems content without it
<g_bor>it might be very well possible that our gcc8 definition only builds the dynamic libraries by default. If I remember correctly, that is the default setting for native builds, but can be overridden by a configure flag. I will have a look
<g_bor>it seems that I remembered incorrectly, a static libstdc++ is always built accoring to the doc here:
<g_bor>dongcarl: this might have some pointers for you:
<g_bor>the main points: g++ should be used, and -lstdc++ flag removed.
<tune>guix pull: error: Git error: failed open - '/home/brad/.cache/guix/pull/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/FETCH_HEAD' is locked: Permission denied
<tune>what's up with this error trying to guix pull
<rekado_>what are the permissions on /home/brad/.cache/guix/pull?
***rekado_ is now known as rekado
<rekado>I’m guessing that some “sudo” shenanigans led to some files there being root owned.
<tune>probably... this sort of thing keeps happening even though I update via aliases so it should always be the same commands and I'm pretty sure they're okay to use
<tune>drwxr-xr-x 13 brad users 4.0K Nov 11 03:46 pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/
<tune>I may have PATH issues or something
<tune>in my .zshrc I have a line "source ~/.profile" and this is my ~/.profile
<tune>anything wrong with this alias for updating system profile? alias sysupgr='sudo -E guix pull && sudo -E guix system reconfigure /etc/config.scm --fallback'
<tune>I often update system profile and then user profile from the same shell in a row also if that could be a problem
<tune>I did a pull with an older guix binary and now when I triy to pull again I get this:
<mkpankov>I'm trying guix on Ubuntu 18.04 and have problems installing "hello" package
<mkpankov>I'm behind proxy, and I use binary installation
<mkpankov>I've already defined http_proxy in daemon's environment but that doesn't seem to help
<civodul>Hello Guix!
<cbaines>hey civodul :)
<cbaines>mkpankov, are you running the guix-daemon as a systemd service?
<cbaines>mkpankov, I forget, does systemctl status show the environment variables?
<mkpankov>nvm, I've already checked them in /proc/pid/environ
<mkpankov>it's there
<cbaines>mkpankov, the only documentation I can find says setting http_proxy is the thing to do. I've never done this myself though.
<mkpankov>pgrep guix
<mkpankov>I've seen that, and have found some IRC logs with people asking the same question about proxy... but noone got a definitive answer
<mkpankov>oh, sorry about that paste :\
<tune> info-dir.drv is failing to build it looks like. anything I can do or do I have to wait?
<cbaines>tune, I think that's a known issue
<civodul>tune: is it from a Guix obtained with 'guix pull'?
<mkpankov>okay so using an insane hack of running my daemon with proxychains, it started downloading stuff
<mkpankov>next question would be "why it doesn't support https_proxy out of the box"?
*civodul pushes a GuixSD → Guix web site update
<mkpankov>installing glibc-utf8-locales and exporting GUIX_LOCPATH doesn't get rid of the locales warning, any idea what goes wrong?
***ChanServ sets mode: +o civodul
***civodul changes topic to 'GNU Guix | | videos: | bugs and patches: | paste: | Guix in high-performance computing: | FOSDEM's coming! | This channel is logged:'
<tune>civodul: I think it's from a pull
<tune>guix (GNU Guix) 86228e569baaf1de0bfbb692fb2821df23f98b4a
<civodul>tune: are you getting substitutes from
<tune>is this that problem where I look for an old guix to do a pull with to resolve it?
<tune>I think I had to do that sometime in the last few weeks
***jonsger1 is now known as jonsger
<civodul>tune: i did "guix pull --commit=86228e569baaf1de0bfbb692fb2821df23f98b4a -p foo" and then "./foo/bin/guix package -i sed -p bar" but that did not reproduce the error
<civodul>anyway, as a workaround, you can run "guix pull" from an older generation
<civodul>these are available as /var/guix/profiles/per-user/$USER/current-guix-*
<roptat>hi guix!
<serichsen>civodul: I wrote a bit about btrfs subvols yesterday:
<mkpankov>guix pull: error: Git error: failed to connect to Network is unreachable
<mkpankov>how do I make git inside of guix use my proxy?
***jonsger1 is now known as jonsger
<rekado>civodul: much support for the GuixSD -> Guix changes!
<g_bor>hello guix!
<g_bor>roptat: no the openjdk11 is not yet reproducible.
<civodul>rekado: yeah, at last!
<civodul>making progress :-)
<roptat>too bad
<civodul>serichsen: yes, i noticed; cbaines, did you see that? ↑
<civodul>i'm not familiar with btrfs but cbaines may have valuable feedback
<g_bor>roptat: wok is tracked on 34231.
<roptat>I've seen that, yes
<g_bor>I wanted to delay it a bit to have it figured out, but some requested to make the package available, so I discussed this with rekado. It actually makes sense to proved it, as the package is working fine.
<g_bor>And I obviously cannot write today :)
<roptat>I'll try to build it and push it today if everything's fine
<roptat>what about a session on reproducible jdk at the guix days before fosdem?
<g_bor>I believe thaat would be fine.
<cbaines>civodul, serichsen, yep, I did see it. Haven't thought about it yet though. I'll reply today hopefully as I have some time :)
<g_bor>One of the possible problems, that might not be revealed by rounds=2 is the possible filesystem ordering issue. Is there a way to tell the daemon to preform a specific build at an other directory instead of tmp?
<jonsger>hm. Strange formatting: "guix gc: freed 6.692,91797 MiBs"
<civodul>jonsger: that's how numbers are printed in your locale :-)
<jonsger>ehm. I mean more the level of detail. I think 6.693 MiB would be detailed enough
<g_bor>civodul: from later reports and support activities, it seems that the info-dir bug is biting us quite hard. Do we know about the status of that?
<g_bor>Can we somehow help?
<g_bor>my current understanding is that it is an indeterministic error in guile. Is that correct?
<civodul>g_bor: it's tricky to fix, but for now i'm trying to see how hard it's biting us
<civodul>if we're using guix pull and substitutes, we should all have it, or none of us
<civodul>and i haven't experienced it yet
<civodul>so i'm wondering what's going on
<civodul>roptat: re reproducible jdk, that's a session you could propose, for sure!
<rekado>I have been bitten by this, unfortunately, using “guix pull” even.
<g_bor>civodul: Related reports keep falling in on the ml, and also on irc. Most of the times it happens on guix pull, and a second pull from still working guix fixes the problem
<rekado>I can reproduce it right now: /run/current-system/profile/bin/guix environment --ad-hoc guile
<rekado> /run/current-system/profile/bin/guix --version says “0.16.0-8.7ba2b27”
<rekado>oh wait
<rekado>this was the result of reconfiguring from a different branch
<rekado>so not the result of “guix pull”.
<janneke>rekado: i don't have any insight about core/linux.scm other than that it seems a good idea :-)
<rekado>turns out that it may not work after all :)
<rekado>I’ll go ahead with splitting modules where it seems useful
<rekado>once that’s done maybe we’ll have a better view on how to cluster packages.
<g_bor>rekado: one way to do it woudl give us a chance to do this semi-automated. I belive we could find a nice compromise between the current situation and the one package per module approach.
<g_bor>What I have in mind is this:
<g_bor>If we have a look at the package graph, then it is a DAG.
<g_bor>It would be nice, if the package module graph would also have this propety, because then splitting modules would become easier.
<g_bor>The idea is this:
<g_bor>The current module structure gives us a partitioning of the graph.
<g_bor>I start from the assumption, that we only want to break up, and not merge modules.
<g_bor>That means that the resulting module structure is a refinement of this partitoning.
<g_bor>Then the structure of the DAG is layered. Given a set of packages we can always determine the packages that can be built give the set.
<g_bor>This layering gives us another partitoning.
<g_bor>The layering can be produced by a greed algorithm form the bootstrap binaries.
<g_bor>To have the DAG property, we know that the final module structure should be a refinement of the partitioning defined by the layers.
<g_bor>Finally it can be easily shown, that any common refinement of these two partitionings would do.
<g_bor>if this makes sense, that greatly depends on the layer structure of the current DAG.
<g_bor>I would expect this to result in much smaller core modules, and almost no changes around the leafs.
<g_bor>Furthermore it would allow us to split any moules without changing anything in the layers below, and only changing the use-modules above, but in a trivial way.
<rekado>we don’t have a module DAG yet. There are quite a few cyclic dependencies between modules.
<bgardner>g_bor: could you point me to the git issue related to the info dir bug you mentioned?
<wingo>guixfolk! hello!
<wingo>sry for being completely totally away these last months
<wingo>anyway i am looking forward to seeing people in brussels! i arrive thursday afternoon so i will miss the first guixday.
<g_bor>bgardner: yes, it is tracked at:
<g_bor>rekado: yes, I know that.
<g_bor>But the method I described would provide a semi-automated way to get there.
<g_bor>I am not sure about the non-package modules...
<bgardner>Thanks g_bor
<civodul>hey wingo, wb!
<civodul>i'm happy we'll meet on Friday then!
<civodul>i hope you had a good time over the last couple of months :-)
<wingo>it has been good! also i bought a house and moved so it has been a mess
<wingo>anyway, a 2019 goal is to get back into the hacking-for-fun side of things :)
<civodul>heheh, congrats on the new house!
<civodul>you're still in the same area?
<wingo>yeah, 100m away from where we were; weird move :)
<wingo>anyway. looking forward to catching up in bruxelles
<civodul>carrying pieces of furniture in the street? :-)
<civodul>rekado: re splitting, be careful with (gnu packages guile) as it's referenced from (guix …) modules too
<rekado>yes, I took care of it.
<rekado>I first move all the easy stuff away, leaving guile-git, guile-bytestructures, guile-sqlite3, guile-json, etc. untouched.
***Elon_Satoshi is now known as Copenhagen_Bram
<nckx>o/ Bonjour les Guix!
<g_bor>how can we get a guix graph for all packages?
<civodul>hey hey, hallo nckx!
<civodul>g_bor: we could get it, but the problem is that we don't have good tools to do anything with that
<civodul>you could run "guix graph $(guix package -A |cut -f1)" as a good approximation
<g_bor>thanks, civodul: I guess we can create those :)
<civodul>rekado: with all these commits, are you trying… to generate a SHA1 collision? ;-)
<nckx>Seems like I'm back just in time for FOSDEM. What an odd coincidence. Anyway: /me just guix pulled for the first time in months and it all went flawlessly, so I just wanted to thank y'all for that.
<g_bor>What I need is the module information, so that I can cluster it accoding to that, and a traversal method. It should not be that hard...
<jonsger>civodul: or maybe just becoming nr 1 contributor for the 1.0 release :P
<civodul>nckx: cool, welcome back!
<civodul>this is an exciting week
<nckx>Much seems to be happening; my in-box overfloweth [even more than usual].
<rekado>it’s just how procrastination works.
<rekado>there are still lots of cases of github archive URLs, a bunch of (zero? (system* …)) expressions, etc
<rekado>gotta clean everything up before 1.0!
<civodul>sneek_: later tell vagrantc they did it! :-)
<civodul>rekado: yup, all the cleanups are really welcome
<g_bor>wow, civodul: that's really great news!
<g_bor>civodul: when we are generating the graph, then is that deterministic? I mean can I count on getting the edges in the same order every time?
<rekado>g_bor: I expect this to be deterministic.
<civodul>g_bor: the output of "guix graph -t package" is not deterministic, because nodes are identified by the pointer value of <package> records
<civodul>but the output of "guix graph -t derivations" should be deterministic
<civodul>not sure about "-t bag"
<civodul>(now even when non-deterministic, it's semantically equivalent)
<civodul>rekado: should i push the package-for-guile-2.0 hack?
<CornBurglar>Hey, I'm trying to get guix working on Fedora 29, and am running into issues. I have installed guix via the package: and enabled guix-daemon.service, but find that the service fails to start. journalctl shows the error at "libgcrypt version mismatch". Anyone know how I might resolve this?
<rekado>civodul: I haven’t seen any proposed hack…?
<rekado>I worked around the problem by defining things explicitly in guile-xyz.scm
<civodul>oh you're too fast
<rekado>oh, haven’t received this email yet
<rekado>but it looks fine to me.
<civodul>ok i'll push it
<civodul>it may still be nicer to use package-with-guile-2.0 than manual inherits, if possible
<jonsger>oh we have an inofficial fedora package since 2013. Thats even older then the opensuse one...
<roptat>CornBurglar, can you send the full error message you get in journalctl? we might be able to help better with more details
<roptat>CornBurglar, you might also try to run "guix-daemon --build-users-group=guixbuild" manually to see if that gives you better error messages
<roptat>alternatively, you can use our installation script if that fedora package is broken
<jonsger>CornBurglar: and the output of "rpm -ql libgcrypt-devel"
<CornBurglar>guix-daemon --guild-users-group=guixbuild gives the same "error: libgcrypt version mismatch".
<CornBurglar>"rpm -ql libgcrypt-devel":
<CornBurglar>Also, I attempted to use the install script a couple weeks ago and ran into the same issue
<jonsger>CornBurglar: what is ls -al /usr/lib64/ ?
<rekado>when using the install script the system libraries are not used.
<CornBurglar>lrwxrwxrwx. 1 root root 15 Jul 14 2018 /usr/lib64/ ->
<jonsger>and "ls -al /usr/lib64/*"
<rekado>argh, conda is infuriating.
<rekado>I can’t install it because it insists that it needs “sudo”…
<dongcarl>apteryx bavier cbaines civodul dongcarl eubarbosa g_bor https janneke lfam mange marusich OriansJ pkill9 rekado roptat terpri: Hey all, I want to thank each one of you for helping me with Guix. This is really an amazing project. I have submitted my Bitcoin Core pull request to do the first step in a long series of step to integrate Guix into our release process: There's only a
<dongcarl>little more to do before we can use it properly. Also, if there's anything you want to add about Guix in the PR description, let me know!
<cbaines>interesting! thanks dongcarl :)
<dongcarl>Thank YOU! 😄
<Misha_B>is there a #:make-install-flags argument?
<cbaines>Misha_B, not for the gnu-build-system at least. However the #:make-flags are passed to make install.
<Misha_B>is it possible to have flags that are passed to 'make install', but not 'make' ?
<bavier`>Misha_B: that is usually accomplished by overriding the standard 'install' phase.
<Misha_B>when I try to run `sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild`, it says that /gnu/store/guix is a read only file system.
<Misha_B>I ran ./configure --localstatedir=/var on my local src
<rekado>“/gnu/store” is in fact a read-only file system
<rekado>does your Guix checkout live in /gnu/store?
<rekado>that’s not supported.
<Misha_B>no, it lives in ~/src/guix
<rekado>does it really say something about “/gnu/store/guix”?
<rekado>could you show us the full error message?
<Misha_B>ryan@r-tc ~/src/guix [dev]$ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
<Misha_B>error: creating directory `/gnu/store/guix': Read-only file system
***samplet is now known as Guest82414
<dongcarl>Question: While running the release build script for Bitcoin Core, I found that the resulting binaries show different linkage when I build on my Arch machine versus when I build inside the `guix environment` I created using this manifest:
<dongcarl>Specifically, the `ldd` outputs are here:
<dongcarl>My concern is mostly with the addition of `` which we wanted to eliminate for our release binaries
<dongcarl>Any help would be appreciated.
<bzp>Hello everyone, what hardware features do I need to install guixsd please?
<cbaines>bzp, there is some documentation on "Hardware Considerations"
<cbaines>do you have a specific concern?
<bzp>I can install guixsd on a virtual machine eg. parallel of macos
<bzp>how much ram memory do I need to install guixsd?
<cbaines>If you want to run guix pull on the machine, you'll need at least 1GB I think, 2GB is better if you have RAM to spare
<bzp>are still in the alpha phase or can be used stably, I want to install it on my home pc.
<cbaines>bzp, I think it's safe to use. Some features of Guix like being able to rollback add to that safety as well.
<bzp>I will install the basic system and twm with i3
<cbaines>On an unrelated note, I'm going to play with printer stuff in Gnome... I want to see if I can print my train ticket to Brussels from Guix!
<bavier`>bzp: I have been running GuixSD on my main machine for about 4 years now, and I've never had it break in any way that a simple roll-back or reboot couldn't fix.
<bzp>can they share their configuration files 'config.scm', please.
<bavier`>bzp: system config files are just scheme code, so code can be shared via modules, or via guix's record inheritence
<civodul>rekado: we're ENOSPC on pretty much all the build machines
<civodul>do you think you could reconfigure them with more aggressive GC?
<civodul>perhaps we should also remove some of the jobs that build big images
<cbaines>Wow... I've successfully managed to share my printer in to a QEMU VM! I never expected that to work...
<cbaines>And I've even got it appearing in the Gnome Control Center
<rekado>civodul: okay, will reconfigure them manually
<civodul>rekado: you're using the install.scm script?
<civodul>cbaines: heh :-)
<rekado>civodul: normally I do
<rekado>but the (current-guix) problem made that difficult
<civodul>rekado: hmm ok
<rekado>what’s the practical difference between “guix gc -F” and “-C”?
<civodul>i'm sure i really understood the (current-guix) problem in that context actually
<civodul>*i'm not sure
<civodul>rekado: "guix gc -F50G" means "do whatever it takes to ensure there's at least 50G available"
<civodul>it does nothing if there's already more than 50G available
<civodul>"guix gc -C50G" says "plz free 50G k tnx"
<rekado>I see
<civodul>-F is usually what you want
<rekado>I looked at the description in the manual but it didn’t click
*rekado has been missing clicks recently
<rekado>I’m building a more recent Guix first because the “guix” package is a bit too old to support the build node configuration.
<rekado>oh, that’s not good: tar: guix- file name is too long (max 99); not dumped
<rekado>I get this when running “make dist” in a git checkout.
<Misha_B>I'm getting an error in a package I'm writing where in the build section it says that /bin/sh is not found
<rekado>in the build container there is no /bin/sh
<Misha_B>do I add that to the inputs
<Misha_B>in the `patch-generated-file-shebangs` it said that `patch-makefile-SHELL: ./Makefile: changing `SHELL' from `/bin/sh' to `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'`
<rekado>there must be another invocation of /bin/sh which is not a shebang
<rekado>you may need to patch that in a build phase
<civodul>rekado: good news is that "guix lint linkchecker" catches it
<civodul>(bad news is that people don't listen to "guix lint")
<Misha_B>I see, there is an extra vars file that has '/bin/sh'
<rekado>civodul: I’m afraid the package-for-guile-2.0 procedure still won’t work :(
<civodul>could you send me a patch to test?
<civodul>i'll check tomorrow
<rekado>I exported it from guile.scm and used it in guile-xyz.scm, which uses guile.scm, but when compiling I get an error: package-for-guile-2.0: unbound variable
<civodul>hmm ok
<rekado>I just sent you a patch to test this
<civodul>cool, thanks
<civodul>well yeah, bleh as well
<rekado>I get another error trying to build a more recent Guix from a “make dist” tarball
<rekado>looks like a file may not be recorded in the makefile
<civodul>note that the file name length is not an error, it's just that the file is not included
<civodul>(so it's a future error)
<rekado>installer/newt/user.scm was not added to the makefile
*rekado sees in the logs that someone is hitting an error on
<rekado>so many bugs, so little time!
<serichsen>Yep, someone might be me. I'm just trying to look at issues.
<serichsen>Now I'm getting 504 Gateway Timeout.
<rekado>serichsen: can you tell me which URL it is?
<rekado>I’ll add it to my list then
<rekado>it’s an encoding error from Debbugs
<serichsen>rekado: thanks for looking into this
<tavoris>Hey anyone encountered this will autotools when making packages? "error: possibly undefined macro: AC_SEARCH_LIBS".
<rekado>serichsen: looks like this is an image attachment which isn’t properly handled. I’ll have a fix in a few minutes.