<CornBurglar>Hey, I'm trying to get guix working on Fedora 29, and am running into issues. I have installed guix via the package: https://copr.fedorainfracloud.org/coprs/lantw44/guix/ 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>I didn’t see anything promising when I did `guix package -s gold` *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>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. <Copenhagen_Bram>Compiling '/gnu/store/gobbletygook-python-3.7.0/lib/python3.7/various/directories/and/files.py'... <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>as in, when I add binutils to my environment manifest, and do a `which ld.gold` 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>build of /gnu/store/slrq9npngjf9npr10c9wfh84d2i01jh5-info-dir.drv failed <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 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." <dongcarl>Lemme get my uses sorted out, then I’ll add it haha <dongcarl>Btw has anyone had experience static linking libstdc++? <dongcarl>From what I understand I need the libstdc++ package <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. *dongcarl waits patiently <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>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>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 <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 <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 <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>I've seen that, and have found some IRC logs with people asking the same question about proxy... but noone got a definitive answer <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 | https://gnu.org/s/guix/ | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs and patches: https://issues.guix.info/ | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guixsd.org | FOSDEM's coming! https://gnu.org/s/guix/blog/2019/meet-guix-at-fosdem-2019 | This channel is logged: https://bayfront.guixsd.org/.well-known/logs/'
<tune>civodul: I think it's from a pull <tune>guix (GNU Guix) 86228e569baaf1de0bfbb692fb2821df23f98b4a <civodul>tune: are you getting substitutes from ci.guix.info? <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-* <mkpankov>guix pull: error: Git error: failed to connect to git.savannah.gnu.org: 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>roptat: no the openjdk11 is not yet reproducible. <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. <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>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>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>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 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>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>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... <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 :) <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>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
<g_bor>how can we get a guix graph for all packages? <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 <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>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>(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: https://copr.fedorainfracloud.org/coprs/lantw44/guix/ 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 <rekado>oh, haven’t received this email yet <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>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/libgcrypt.so ? <rekado>when using the install script the system libraries are not used. <CornBurglar>lrwxrwxrwx. 1 root root 15 Jul 14 2018 /usr/lib64/libgcrypt.so -> libgcrypt.so.20 <jonsger>and "ls -al /usr/lib64/libgcrypt.so*" <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: https://github.com/bitcoin/bitcoin/pull/15277. 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! <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>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: https://paste.debian.net/hidden/c9a3cbd2/ <dongcarl>My concern is mostly with the addition of `libstdc++.so.6` which we wanted to eliminate for our release binaries <bzp>Hello everyone, what hardware features do I need to install guixsd please? <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? <rekado>but the (current-guix) problem made that difficult <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>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 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-0.16.0.1585-5a2369/gnu/packages/patches/linkchecker-mark-more-tests-that-require-the-network.patch: 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>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 :( <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 <rekado>I just sent you a patch to test this <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 <rekado>installer/newt/user.scm was not added to the makefile *rekado sees in the logs that someone is hitting an error on issues.guix.info <serichsen>Yep, someone might be me. I'm just trying to look at issues. <rekado>serichsen: can you tell me which URL it is? <rekado>it’s an encoding error from Debbugs <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.