IRC channel logs

2018-04-09.log

back to list of logs

<dustyweb>did rhythmbox stop playing ogg vorbis files for anyone else?
<dustyweb>rekado: you're running stumpwm, right?
<dustyweb>stumpwm-with-slynk is not building for me...
<marusich>Hello, Guix!
<fredmanglis>Hi there. I did a `guix pull`, then did a `guix package -u` for both root and normal user. Both ran successfully for root, but the package update failed for the normal user. After rebooting, and trying to run `guix gc --optimize` it fails with:
<fredmanglis>guix package: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist
<fredmanglis>I've looked in `/etc/group` and the group exists. I've gone through the install instructions in the manual to try and recreate the group, but even groupadd says the group already exists
<fredmanglis>I have guix-0.14.0-8.bc880f9 currently on my system
<fredmanglis>I'd appreciate any help to fix that.
<catonano2>fredmanglis: last time I had a similar problem, it turned out I had messed up the permissions on my guix-latest link, having misused su or sudo to update the root's stuff
<zybell_>check for typos: In another thread that I dont find atm there was that error with the name 'guixbuld'(note the missing i).Otherwise restart nscd.
<catonano2>fredmanglis: right now I can't remember the exact path of the guix-latest link
<fredmanglis>catonano2: the link is usually in ~/.config/guix/latest
<catonano2>fredmanglis: right. Try to erase it, then from a locally checked out Guix do
<catonano2>./pre-inst.env guix pull
<fredmanglis>catonano2: Okay. I'll try that. I don't have an up to date checked out guix though.
<rekado>dustyweb: I’ve switched to GNOME a couple of days ago. I never got the stumpwm integration with Emacs to work.
<rekado>I finally understood why scalac won’t compile: it’s not written in Java but in Pizza.
<rekado>Pizza is a precursor of Generic Java; both are obsolete languages.
<catonano2>fredmanglis: then check it out but before trying my suggestion be sure to build the local Guix properly !
<catonano2>Ah
<rekado>Unfortunately, there are two problems: Pizza is released under the old Artistic License, and: it is written in Pizza.
<rekado>So this is a dead end, both technologically and legally.
<catonano2>I see. Not fun. So now you need a not self hosting Pizza compiler ?
<rekado>I think I’ll skip Pizza and look at ways to rewrite the Pizza/Java source files of the Scala compiler to valid Java.
<catonano2>Ok
<rekado>bah, some of the scala source files contain this notice:
<rekado>Permission is hereby granted to modify and use this software for research
<rekado> * and teaching purposes. Modification for commercial purposes requires
<rekado> * prior written permission by the author.
<catonano2>As for me I think I tamed Autoconf. I made it find libpq and substitute the complete path in a conf.scm.in file
<rekado>catonano2: in which project?
<catonano2>No one for now. But my plan is to complete this thing and then use it for guile-squee
<catonano2>I'd also like to try to consolidate g-golf
<catonano2>For now it's minimal, bare bones, I'd say
<catonano2>The step 0 is to have it properly set up with libpq
***Gamayun_ is now known as Gamayun
<catonano2>rekado: what are you going to do with that non commercial pizza code ?
<rekado>catonano2: I’m not going to use it.
<rekado>I don’t know yet how to move forward here; it may be possible to pre-process the sources to translate all non-standard syntax to plain Java.
<rekado>an alternative is to write a simple Scala-to-JVM-bytecode compiler.
<rekado>but that’s a lot of work.
<mbakke>fredmanglis: The issue you have is because your host distro uses the obsolete "nss_compat" library which is no longer supported in glibc 2.26.
<mbakke>The easiest fix is to install nscd.
<mbakke>Alternatively remove "compat" from /etc/nsswitch.conf.
<fredmanglis>mbakke: Thanks. That seems to have fixed the issue I was experiencing.
<Rnytom[m]>hi
<Rnytom[m]>could anyone make weechat work with ssl ?
<Rnytom[m]>I always get the "curl error 60..." when trying to downlaod scripts
<Rnytom[m]>The mailing list says libcurl uses GnuTLS, and that it looks in /etc/ssl/certs
<Rnytom[m]>So i checked that the folder is populated and it is... but I still can't make it work
<pkill9>is there a way to specify multiple grub entries? I want to add different kernel versions
<snape_ssl>Rnytom[m]: I'm using weechat, right now, with ssl
<fredmanglis>Okay. Now I get guix package: error: build failed: the user `guixbuilder01' in the group `guixbuild' does not exist
<fredmanglis>when I try to do `guix package --upgrade`
<Rnytom[m]>snape: do you get a curl error when weechat starts ? If no did you have to configure anything special ?
<snape>Rnytom[m]: I just followed https://weechat.org/files/doc/devel/weechat_faq.en.html#irc_ssl_freenode
<sneek>snape, you have 1 message.
<sneek>snape, thorwil says: thanks for the pointer to nscd!
<snape>I didn't see any error
<snape>Rnytom[m]: are you using GuixSD or a foreign distro?
<civodul>hello Guix!
<snape>hello civodul
<Rnytom[m]>snape: I'm using GuixSD, I also set the weechat.network.gnutls_ca_file according to the FAQ, but it doesn't seem to work
<snape>Oh. I'll try with GuixSD then
<snape_clone>Rnytom[m]: it works from GuixSD too
<snape_clone>Rnytom[m]: this is exactly what I did: https://paste.debian.net/1019377/
<Rnytom[m]>snape_clone: did you have to install nss-certs as a user ?
<snape>Rnytom[m]: no, nss-certs is installed globally
<snape>it's in the 'packages' field of 'operating-system'
<rnytom_>snape: connecting to freenode seems to work indeed
<rnytom_>but weridly I still get this error:
<rnytom_> error downloading list of scripts: curl error 60 (server certificate verification failed. CAfile: none CRLfile: none) (URL: "https://weechat.org/files/plugins.xml.gz")
<rnytom_>weirdly*
<snape>rnytom_: do you have that error with a clean ~/.weechat?
<rnytom_>snape: I'll try
<Rnytom[m]>snape: Ok, with a clean ~/.weechat, I don't get the error at startup, but still get it when I type /script
<snape>Rnytom[m]: Ok I have the error too
<Rnytom[m]>snape: The weird thing is that "curl -O https://weechat.org/files/plugins.xml.gz" works fine
<Rnytom[m]>I guess curl and libcurl handle certificates differently
<mbakke>fredmanglis: try restarting guix-daemon. If that doesn't work a reboot should fix it (provided nscd starts at boot).
<allana>Can anyone explain in simple terms the difference between a guix container and a docker container?
<fredmanglis>mbakke: cool. Let me try that.
<rekado>allana: a docker container really is a binary disk image.
<rekado>to run an application stored on that image docker uses Linux kernel features to mount the image and create separate namespaces for users, processes, and so on.
<mbakke>Rnytom: libcurl does not respect CURL_CA_BUNDLE (unlike curl) and instead expect consumers to override the built-in certificate path (which is unset in Guix).
<rekado>the “guix container” or “guix environment --container” features also use the kernel’s facilities to create separate namespaces, but it does not need a disk image.
<mbakke>Adding support for CURL_CA_BUNDLE in weechat should be straight forward though, if you'd like to get your feet wet.
<rekado>it mounts the /gnu/store in that isolated namespace instead.
<rekado>(or parts thereof)
<rekado>allana: what you download when you get a “docker container” is really that big binary blob providing a virtual disk.
<allana>rekado: Thank you for the explanation :-)
<snape>Rnytom[m]: At least, you have an easy workaround, which is to manually download the file and put it in ~/.weechat/script...
<snape>The issue seems to be known: https://weechat.org/files/doc/devel/weechat_faq.en.html#scripts_update
<snape>so it's probably not Guix specific
<mbakke>It seems setting weechat.network.gnutls_ca_file should do the trick.
<Rnytom[m]>mbakke: do you mean adding a patch in weechat's recipe ? Or suggesting a patch to weechat's devs directly ?
<Rnytom[m]>mbakke: I also thought setting weechat.network.gnutls_ca_file would work
<Rnytom[m]>but it doesn't seem to
<Rnytom[m]>snape: I already manually installed the script I need, but the sad thing is that when I run it, I get the exact same error (curl error 60)
<mbakke>I meant patching weechat to take the CA file from an environment variable. Upstreaming is preferred, but we could probably carry it if it fixes this issue.
<mbakke>I've actually patched "feh" and "newsboat" upstream to support CURL_CA_BUNDLE.
<Rnytom[m]>mbakke: ok thanks for the tip, I'll first try to see why setting weechat.network.gnutls_ca_file doesn't work
<g_bor>Hello guix!
<castilma>hi g_bor
<castilma>can someone tell me, what the point of installing guix through guix is? (guix package -i guix). how should that be able to install a newer guix? afaiu, a guix version only knows about software that existed when it was built. as an example. guix@0.14.23 can only know about guix@.014.22, right?
<rekado>civodul: I see a problem with the new guix pull.
<rekado>civodul: https://paste.debian.net/1019393/
<rekado>civodul: is there a minimum Guix version I need to use since this change?
<g_bor>rekado, civodul: Do we have to do anything about the GSoC slot request deadline?
<g_bor>Have we noticed the coordinator, how many slots we would like?
<roelj>Why does Guix generate a new qemu image on each invocation of “guix system vm-image ...”?
<civodul>rekado: what if you unset GUIX_PACKAGE_PATH?
<civodul>there's a minimum version, but it's a very old version: all we need is enough to build the trampoline
<rekado>g_bor: we already requested slots
<civodul>castilma: you are right, yes
<civodul>so "guix package -i guix" is not recommended in general
<rekado>civodul: I’m trying without GUIX_PACKAGE_PATH
<rekado>civodul: unfortunately, it still fails with the same error.
<rekado>admittedly, this is a very old Guix, which has only been used to let people run “guix pull”.
<rekado>now there’s a new user and so they use that old Guix to get started.
<civodul>hmm
<civodul>ACTION goes for lunch
<civodul>i'll investigate afterwards
<rekado>It’s a version where “guix pull” does not yet support “--commit”, only “--url”.
<rekado>no rush, enjoy your lunch!
<castilma>civodul: how do i keep guix updated on a non guixsd system? don't i need guix installed as package in the roots profile?
<snape>castilma: It depends on how you installed it. If you installed it with etc/guix-install.sh, you need to do 'guix pull' as root, and then restart the daemon.
<g_bor>rekado: thanks, that's what I needed to know. I've got to go now
***firewall is now known as Guest79497
<civodul>rekado: so it seems that compute-guix-derivation is somehow referring to the already-installed guix, which it shouldn't
<civodul>could you run: strace -o log -s 345 $(guix build /gnu/store/cm43vzv0hy960xpwp293pk9hwkhg7j9l-compute-guix-derivation.drv) /gnu/store/l8dcyqhir09vavnz274hhqz41vh06cwi-guix-source x86_64-linux
<civodul>on that same machine
<zybell_>line 33 is interesting
<zybell_>The dependency tree of that pkg I mean
<rekado>civodul: running it now
<rekado>civodul: here’s the log: https://bimsbstatic.mdc-berlin.de/akalin/PiGx/supplementary_material/log
<zybell_>unrelated question:how does line 340 of the log accord with the goal of reproducible builds?
<civodul>rekado: oh this is with Guile 2.0
<rekado>zybell_: as long as the output isn’t random, there’s no problem. You need randomness to access HTTPS resources, for example, but what you get won’t be random.
<zybell_>lines 669,679 seem to load something from another source after not finding in l8...
<rekado>civodul: oh. I thought that was okay.
<zybell_>rekado: Thought that would be done in a subprocess. My error.
<civodul>rekado: it's supposed to be ok, i found part of the bug already
<rekado>awesome!
<zybell_>but look at 669 and 679 where it seems to be an instance of pulling wherever it gets.
<civodul>rekado: could you apply https://paste.debian.net/1019421/ in a branch of yours, and then run "guix pull --url=that-repo --branch=that-branch"?
<rekado>will do
<civodul>great
<allana>Has anyone packaged docker community edition? I think it is licensed as Apache 2.0, but I am not sure about all of its dependencies, or if Apache 2.0 is an acceptable license.
<Sleep_Walker>allana: not yet, I would use that too
<rekado>allana: Apache 2.0 is an acceptable license. It’s called “asl2.0” in (guix licenses)
<allana>Thanks rekado
<roptat>civodul: did you see I sent an updated patch for translating the manual?
<civodul>roptat: maybe not, when was that?
<roptat>last week
<civodul>oh
<roptat>I still have an issue because the translation is updated as soon as the manual is modified
<roptat>what command do you run when you want to update guix and guix-package' translations?
<roptat>actually, how do you refresh .pot files currently?
<rekado>civodul: sorry, got side-tracked. Your patch appears to work, but then fails later during compilation of 106 files (for /gnu/store/y91iq7wmacl7x80flgipzmd95kd1qc52-guix-extra.drv) with “no code for module (json)”.
<rekado>civodul: this happens when trying to compile (guix docker), by the way.
<bavier`>rekado: I've seen that failure recently too; I removed '#:use-module (guile json)' from guix/docker.scm, since it's loaded dynamically
<bavier`>erm, actually no, I deleted '#:use-module (guix docker)' from gnu/system/vm.scm :/
<civodul>rekado: could you paste /gnu/store/y91iq7wmacl7x80flgipzmd95kd1qc52-guix-extra.drv?
<civodul>roptat: there's an 'update-po' target in po/guix{,-packages}
<rekado>civodul: https://bimsbstatic.mdc-berlin.de/akalin/PiGx/supplementary_material/y91iq7wmacl7x80flgipzmd95kd1qc52-guix-extra.drv
<roptat>civodul: ok I'll update my patch with something similar and then I think it will be perfect :)
<civodul>sure!
<civodul>i went looking for your message and starting answering unrelated messages
<civodul>always the same story :-)
<civodul>but i guess you can commit it and we can always tweak afterwards if there's anything annoying
<lisppsps>when I try to reconfigure my system, guix tells me that I forgot `(use-modules (gnu services xorg))' and when I add that line, guix tells me that 'xorg-server' is provided more than once.
<lisppsps>what am I doing wrong here
<hoplaahei>hi. I just ran my first guix system reconfigure. Nothing seems broken, but I received message: shepherd: Service user-homes could not be started. guix system: error: exception caught while executing 'start' on service 'term-auto': ERROR: find-long-options: unbound variable
<hoplaahei>Can this safely be ignored?
<zybell_>As long as you only login as root-
<zybell_>*.
<bavier`>hoplaahei: I think you can ignore that. the user-homes service will only start if there are new home directories that need to be created. iirc
<fredmanglis>So far so good. It looks like the reboot fixed the remaining issues.
<hoplaahei>bavier: ok thanks for the info. I think the term-auto and 'long-options' are separate messages though. I should've posted them on separate lines.
<civodul>rms on privacy: https://www.theguardian.com/commentisfree/2018/apr/03/facebook-abusing-data-law-privacy-big-tech-surveillance
<civodul>well already a few days old
<bavier`>GNU Taler is the only electronic payment system that I can feel excited about
<daviid>me too