IRC channel logs


back to list of logs

<cogrendel>When trying to install texlive I get the error `TLS error in procedure 'read_from_session_record_port': Resource temporarily unavailable`. I have tried to install from a different substitute with the same results. Has anyone else experienced this?
<cogrendel>I get this error between 5% and 20% through the download on every attempt.
<platoxia>I'm not really doing anything right now...I'll give it a go and let you know.
<platoxia>cogrendel, it installed okay for me
<platoxia>corendel, try doing a guix pull as root then try it again.
<cogrendel>platoxia: thanks for checking. Hrmmmm I wonder what my problem is.
<cogrendel>Ok will do
<lfam>cogrendel: Can you upload the full failing command and output to
<cogrendel>lfam: sure thing
<lfam>cogrendel: But what command did you run? :)
<cogrendel>`guix package -i texlive`
<cogrendel>I'm still experiencing the same failure on attempts after my guix pull :(
<lfam>In general, the source code of texlive-texmf is a problem for us. It's very large (as you can see, > 2 GiB), so for a long time we did not serve it or the built package of texlive-texmf. Users had to use --fallback to download it from the upstream source and build it themselves, locally. A few days ago we decided to try serving it again, but it seems unreliable :(
<lfam>Please use --fallback as the error message suggests
<lfam>This options means "If Guix was expecting a substitute but something went wrong, build it locally".
<cogrendel>lfam: I have tried with fallback before, but it fails as well. It still has to download the > 2 GiB file. Trying again right now.
<lfam>If it fails again with --fallback, please paste the full command and output
<lfam>That "killing process 11204" may break the --fallback
<lfam>The final workaround is this:
<lfam>guix build --no-substitutes --source --expression='(@@ (gnu packages tex) texlive-texmf)'
<lfam>That will build the source of texlive-texmf without resorting to substitutes. This means it will download it from the upstream FTP server. Unfortunately, FTP is not very reliable either :(
<cogrendel>lfam: OK, thanks for the help!
<lfam>cogrendel: I reported it here: <>
<cogrendel>lfam: Excellent, thank you. So it appears that fallback will work and it probably would have worked before. It first attempts to download a large file from the guix mirror and fails, at which point I interrupted the process my first time.
<cogrendel>I shouldn't have though because it then tries to download it from the upstream ftp server, which succeeds.
<lfam>Ah, great
<lfam>I mean, "great"
<cogrendel>lfam: Thanks for the help, I appreciate it.
<taohansen>if not xpra, does anyone have X11 forwarding working for them?
<taohansen>i've got a Gentoo system connecting into my GuixSD system at the office fine over regular SSH but X11 forwarding fails
<taohansen>SSH config:
<OriansJ>taohansen: you need to ensure the /etc/ssh/sshd_config on the server is set to enable X11
<taohansen>OriansJ: that would be my GuixSD system
<Apteryx>lfam, cogrendel: I had the same problem yesterday attempting to download texlive (download failed after 15% about -- 1 m 40 about).
<buenouanq>taohansen: yes, works great
<buenouanq>there's a problem right now with services not starting on boot
<buenouanq>$ herd status ssh-daemon
<buenouanq>$ herd start ssh-daemon
<taohansen>buenouanq: status of my ssh-daemon is started as root. is there any chance it being a root process and not a user-process might be the issue?
<buenouanq>no, that's normal
<taohansen>strange then. not sure what could be the issue at this point
<taohansen>spent a few hours on it last night
<buenouanq>get rid of the other config and do everything in your config.scm
<buenouanq>restart it
<buenouanq>the ssh service I mean, with herd
<buenouanq>and then, what is the actual error you get when you try?
<buenouanq>because I do get xauth issues unless I use -Y (instead of -X)
<taohansen>buenouanq: i'll do all this when i'm home. leaving the office now. i'll report results
<taohansen>thanks for your help
<buenouanq>of course
<buenouanq>hope we can figure it out for you
<buenouanq>my openssh service looks exactly like yours and works
<buenouanq>tzselect isn't installed nor found with -s
<Apteryx>Is there any free software friendly dynamic DNS service available? I've been using, it work well, but their stuff isn't open it seems.
<efraim>sneek: later tell civodul I'm not sure about qglwidget, upstream probably didn't drop it between 5.9.1 and 5.9.3 so it's probably on our side
<sneek>Will do.
<efraim>sneek: botsnack
<buenouanq>texlive sure takes a long time to build
<lfam>Apteryx: I don't know your criteria but I like
<ng0>Apteryx: 1984 offers ddns in their FreeDNS service.
<catonano>good morning guixers ! The site publishing the mailing lists seems to be not reachable right now
<NewGnuGuy>catonano: Not responding to ping either. I reported it on #fsf
<NewGnuGuy>catonano: it should work now
<civodul>Hello Guix!
<sneek>civodul, you have 1 message.
<sneek>civodul, efraim says: I'm not sure about qglwidget, upstream probably didn't drop it between 5.9.1 and 5.9.3 so it's probably on our side
<efraim>I didn't check if qt5.9.4 had it before pushing it
<civodul>ok, i wonder what happened
<civodul>i briefly looked at the build log and didn't see anything obvious
<buenouanq>man, it's still going
<buenouanq>texlive is a monster
<rekado>what do you all use texlive for?
<rekado>there are still a couple of packages that I think could be using texlive-tiny instead.
<rekado>unfortunately my laptop is falling apart, so I can hardly work on anything.
<rekado>my file system is corrupted again so I can’t install anything into the store (“structure needs cleaning”), but I can’t run e2fsck because my display backlight is dead, and I cannot see anything before Linux has booted and the VGA output becomes active.
<clacke[m]>I use context, only for the pdf recombination and booklet formatting options to texexec.
<civodul>rekado: bah!
<civodul>rekado: i use texlive for Beamer slides, reports, things like that
<civodul>i definitely use a small subset of the big 'texlive' package, but i really need that subset :-)
<efraim>civodul: it might have been removed
<civodul>it's marked as "obsolete", but hopefully they'd only actually remove it in 6.0 or something?
<civodul>maybe we need a build flag like -DENABLE_OBSOLETE/
<efraim>They add and drop things at random times
<civodul>at least the file qtbase-opensource-src-5.9.3/include/QtOpenGL/QGLWidget exists
<civodul>according to
<civodul>actually /gnu/store/6m9d41ifwf6fj6ys4y21gpz7bn220qml-qtbase-5.9.3/include/qt5/QtOpenGL/QGLWidget exists
<civodul>hmm i'm confused
<catonano>sneek later tell NewGnuGuy Thanks !
<sneek>Got it.
<efraim>Could be related to the install directories and search paths then
<wigust>Hello Guix, we couldn't have a package without a licence at all, could we?
<rekado>wigust: not in the package collection that’s part of Guix itself.
<rekado>wigust: no explicit license means “all rights reserved”, which is non-free.
<wigust>rekado: OK, thank you.
<rekado>in your own collection of modules, however, you can create a new license “all-rights-reserved” and use that with your packages.
<wigust>rekado: OK, will keep it in mind. I'll ask a developer to include a licence to publish with in Guix package collection.
<civodul>wigust: more generally, this person should be aware of the above issue: if what they want is to make it free software, then they have to explicitly state it
<efraim>I sometimes use #f while I'm packaging, its accepted in the license field
<wigust>civodul: The developer is probably aware (he does Emacs stuff), but it's a one little file script.
<wigust>efraim: Thanks for the tip, I use this too. Most usually I see this autogenerates by Python packages importer.
<ng0>Can someone give me a short explanation of our certbot/LE service? Does it simply renew certs and you need to create the cert by manual request before running the service?
<ng0>well the description just says renewal.. and the code just reads like this
<ng0>so I supposed the first request has to be done by hand.
<JorgeMorais>Hi. I have just compiled guix from a recent git checkout. Then I ran “make -k "-j$(nproc)" check”. It reported one failure: “FAIL: tests/derivations.scm” and it appears to have hanged just after “PASS: tests/builders.scm”. It is silent for more than 15 minutes and does not appear in ‘top’.
<JorgeMorais>Wait a minute, it finished. Let me see if I can fix the failure.
<jlicht>hi guix!
<wigust>jlicht: o/
<catonano>hi jlicht !
<ng0>what's the default mcron user, root?
<ng0>info mcron I guess, but asking is cheap.
<ng0>if certbot renew succeeds with it, I'd think it is root
<jlicht>ng0: afaik, by default root
<jlicht>unless you specify #user
<jlicht>but I only tried using the GuixSD mcron-service, so not sure if applicable to your case
<ng0>it's GuixSD. I've used it for a while but never looked into it. And I need to do this thing although I'm currently not at my best level.. so I think I know it but better safe than configure the system twice.
<ng0>85.5% substitutes on greendragon. cool :) I think the last percentage of packages are packages with problems or long testsuites
<g_bor>Hello guix!
<jlicht>Is there anything keeping us from building mcron{,2} with a more up-to-date guile? It would allow us to work on job definitions interactively, but maybe there is some drawback I'm not seeing.
<jlicht>hi g_bor!
<g_bor>I would like to reference the version of an input in my package. How can I do that?
<rekado>I was asked if Guix can create Amazon Machine Images (AMIs). I know nothing about this. Has anyone tried running a GuixSD-produced virtual machine image on Amazon compute services?
<jlicht>g_bor: if a package has two versions available, there are usually multiple symbols to refer to these version. So you should look at the `define-public <pkg-version1>' and `define-public <pkg-version2>' for example, and use the exported symbol of the version you would like to use in your list of inputs. E.g. `(("python" ,python-2)) vs `(("python" ,python-3))
<wigust>Could I make a search both on help-guix and guix-devel in one query?
<civodul>wigust: i don't think so!
<civodul>rekado: marusich may know AMIs :-) but you could ask on help-guix i guess
<wigust>ACTION found 'gource' origin tarball's hash is wrong because of but is OK. As I remember we had a disussion about that, don't we?
<wigust>So github/.../archive is autogenerated?
<mbakke>wigust: yes, we've had quite a few cases of that recently. lfam asked GitHub support and they recommend not relying on the archive tarballs.
<wigust>Shouldn't we have a warning in the linter for this?
<wigust>ACTION knows about that, but forgets about archive or release url is bad
<wigust>As I remember there was even a guile script to check all packages in the collection for this.
<wigust>For the record
<Apteryx>wigust: yes, I made that script when it wasn't sure how many of our packages were affected by patch to Github's git that introduced changes in their autogenerated tarballs. You can find it here:
<JorgeMorais>Hi. I have just compiled guix from source and issued “sudo make install DESTDIR=/stow/guix/”. However, the installation image is entirely contained in /usr/local/{bin,etc,lib,libexec,sbin,share}. Where are /gnu/store and /var/guix, which exist in the pre-compiled tarball?
<JorgeMorais>I searched the manual and the web and found no answer.
<wigust>JorgeMorais: 'Binary Installation' manual section?
<snape>JorgeMorais: shouldn't env variables come first?
<JorgeMorais>snape: DESTDIR is not an environment variable, it is a make variable
<snape>oh right, then I don't know :p
<JorgeMorais>wigust: That section is for installation from the pre-compiled tarball, AFAIK.
<wigust>JorgeMorais: Yes, this is what people use to install Guix for the first time on the foreign distro.
<JorgeMorais>Oh wait. I found something new in that manual section, towards the end
<JorgeMorais>Please wait a minute.
<snape>JorgeMorais: what about 'make DESTDIR=/tmp/stage install'?
<JorgeMorais>What would be the advantage of that?
<snape>DESTDIR is prepended
<snape>instead of appended
<snape>as says the docs
<rekado>JorgeMorais: note that you won’t be able to use pre-compiled binaries from our build farm if the store is not at /gnu/store.
<JorgeMorais>I use GNU Stow. It manages symlinks so you can install a package under its own directory and then create symlinks in the expected file system locations. In this case I install in /stow/guix, and then Stow will create symlinks according to the layout generated by make install - which in this case is /usr/local/{bin,etc,lib,libexec,sbin,share}
<ng0>so you will use a package manage to manage a package manager?
<rekado>JorgeMorais: what about /gnu/store? Binaries embed absolute file names of dependencies in /gnu/store. You will only be able to use them if /gnu/store can be resolved.
<clacke[m]>I've been considering to play with userspace name spaces to solve that
<JorgeMorais>rekado: If make install had created “/stow/guix/gnu/store”, then Stow could symlink it into /gnu/store. The problem is that make install has not created “/stow/guix/gnu/store”. But wait a minute, I am reading a manual section I had not found before.
<snape>I thought there was some work going on to hack the binaries so to change /gnu/store location and, say, give user access to it. Does anyone know if there is any progress?
<clacke[m]>it would help us use guix to create AppImages as well
<JorgeMorais>ng0: I am bootstrapping Guix by compiling it from source and stowing it with GNU Stow because the precompiled Guix tarball has not worked for me.
<civodul>JorgeMorais: how did it not work?
<ng0>okay, in that case it would help to figure out why it didn't work.. unless you want to follow the stow path
<wigust>Also as an another way many distroes have a guix package in their repositories.
<rekado>snape: this already works, though it’s quite a hack. Pjotr has a couple of notes for rewriting store references.
<ng0>could someone revert ? I don't have the weekend to work on a fix, I'm a bit sick.
<mbakke>ng0: what's the problem with it?
<snape>JorgeMorais: it seems that you should use prefix instead of DESTDIR (see
<ng0>the gnurl commit? see the discussion around it on the -devel ML. tl;dr doesn't work like this
<ng0>what's worse, breaks build in non-reproducible way.. but that's a cURL thing.
<ng0>background: Amirouche reported an issue with ca-certificates by gnURL inside GNUnet which I thought I had resolved. So my first attempt passed with this on my side, but given this thread I need to test more.
<JorgeMorais>snape: I tried with prefix, but libtool refused to install libraries in the Stow package (/usr/local/stow/lib IIRC). I searched the web and people recommended DESTDIR to placate libtool.
<JorgeMorais>I will try recompiling guix.
<snape>JorgeMorais: why do you want to use stow? I mean, what's the problem with installing Guix at the root?
<mbakke>ng0: I see. I can revert it tomorrow if nothing else comes up.
<JorgeMorais>snape: Stow has some advantages in the general case such as easy, reliable and efficient uninstallation; parallel installations – e.g. multiple versions of the same package; and easier distribution. It became routine. In this case, the only advantage is easy, reliable and efficient uninstallation. Anyway I really don't think Stow is the problem here (the problem is that make install does not create the store), but I will test
<snape>JorgeMorais: I thought 'make uninstall' was pretty easy
<efraim>Just got the email, gcc7.3 released
<JorgeMorais>snape: make uninstall will not work after you erase or modify the build dir. Stow allows you to have several parallel versions of one package, without having to keep the build dir (for later uninstallation) of each version, which would be inefficient.
<ng0>mbakke: thanks
<snape>But really, Guix uninstallation is as simple as rm -rf three directories, because its binaries aren't in /usr/bin. And having different versions of Guix doesn't make sense because Guix provides that feature already.
<wigust> /gnu /var/guix and what? :-)
<snape>/run/guix, I guess
<rekado>be that as it may, let’s not pretend that Stow has no use here. If Guix cannot be installed like any other package in Stow then that’s an odd restriction that we should aim to remove.
<snape>rekado: it has much less use than with other packages
<rekado>I agree, but this doesn’t mean that we can’t make it work. It is not an outlandish request to have Guix install cleanly with Stow.
<JorgeMorais>Now please excuse me, I will be AFK for lunch. It should take about 30 minutes. Meanwhile the computer is running “make -k check” on Guix.
<cogrendel>Is the `arguments` field of a package definition documented more fully somewhere? In the package reference section of the manual it says it is a list of key value pairs, but I am not sure where to find possible keys and their meaning.
<cogrendel>*keyword-value pairs I mean
<rekado>the arguments field depends on the build system.
<cogrendel>rekado: I see, so should I look in the respective build system for the possibilities?
<adamvy>cogrendel: For gnu-build-system it looks like all the arguments are defined in guix/build-system/gnu.scm:276 they're just keyword arguments to gnu-build. I would imagine other build systems have similar structure.
<cogrendel>adamvy: Ah great, thanks for the direction. I was looking in `(guix build gnu-build-system)` and was getting confused.
<JorgeMorais>Hi. This time I installed directly over / (“sudo make install”) and still there is no “/gnu” or “/var/guix”. I configured with “./configure --infodir='$(datarootdir)/guix_info' --localstatedir=/var”, compiled with “make -k "-j$(nproc)"” and checked with “make -k check”. The test suite reported two failures (tests/derivations.scm) and 720 passes.
<wigust>sneek later tell civodul It's possible to make a search query on multiple mailing list, just add another &idxname=another-mailinglist to the url parameters like ""
<sneek>Got it.
<civodul>oh nice
<sneek>civodul, you have 1 message.
<sneek>civodul, wigust says: It's possible to make a search query on multiple mailing list, just add another &idxname=another-mailinglist to the url parameters like ""
<efraim>squeak-vm's cmake stuff is too old to recognize aarch64
<efraim>interesting, nix is using extlinux on aarch64
<ng0>what'S the Gnus mailinglist for questions these days? I'm stuck on something a very old config of mine accepted as valid.
<wigust>ng0: or