IRC channel logs
2018-01-25.log
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>corendel, try doing a guix pull as root then try it again. <cogrendel>platoxia: thanks for checking. Hrmmmm I wonder what my problem is. <lfam>cogrendel: Can you upload the full failing command and output to paste.debian.net? <lfam>cogrendel: But what command did you run? :) <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: 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. <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 <OriansJ>taohansen: you need to ensure the /etc/ssh/sshd_config on the server is set to enable X11 <Apteryx>lfam, cogrendel: I had the same problem yesterday attempting to download texlive (download failed after 15% about -- 1 m 40 about). <buenouanq>there's a problem right now with services not starting on boot <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? <taohansen>strange then. not sure what could be the issue at this point <buenouanq>get rid of the other config and do everything in your config.scm <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 <buenouanq>my openssh service looks exactly like yours and works <Apteryx>Is there any free software friendly dynamic DNS service available? I've been using duckdns.org, 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 <lfam>Apteryx: I don't know your criteria but I like nsupdate.info <ng0>Apteryx: 1984 offers ddns in their FreeDNS service. <NewGnuGuy>catonano: Not responding to ping either. I reported it on #fsf <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>i briefly looked at the build log and didn't see anything obvious <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: 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 :-) <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>actually /gnu/store/6m9d41ifwf6fj6ys4y21gpz7bn220qml-qtbase-5.9.3/include/qt5/QtOpenGL/QGLWidget exists <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. <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. <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>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 <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. <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>rekado: marusich may know AMIs :-) but you could ask on help-guix i guess <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. <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 <snape>JorgeMorais: what about 'make DESTDIR=/tmp/stage install'? <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. <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. <mbakke>ng0: what's the problem with it? <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. <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. <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. <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. <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. <sneek>civodul, you have 1 message. <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: info-gnus-english@gnu.org or emacs-devel@gnu.org