IRC channel logs

<Apteryx>This is giving deprecated warning: (bootloader (grub-configuration (device "/dev/sdX"))) (device should be target) but the manual examples haven't been updated it seems. (See: 6.2.1 Using the Configuration System)

<ng0>civodul: hua

<ng0>master is giving me something different now

<ng0>one moment

<ng0>but I think I'll try with a clean go first

<civodul>Apteryx: check the manual from current master

<civodul>(or ignore it for now :-))

<Apteryx>I thought I was, I'm using 'guix pull' :)

<civodul>'guix pull' doesn't update the manual (yet)

<ng0>I thought about writing an package definition for just the manual

<Apteryx>Ah, OK! Thanks.

<ng0>by now I've written enough texinfo to simply read the source, but it could help

<Apteryx>ng0: I think when guix pull updates it we'll be well covered.

<ng0>sure, but it would also be usefull for providing an up to date online version of it, for example

<ng0>that was my primary intention

<Apteryx>It could be interesting to offer multiple versions of the manual at the current online location, with the default being the currently used one (latest stable), but also one tracking latest master, etc.

<Apteryx>Like when you browse Python doc online you can easily switch between releases (2.7.X to 3.6.X).

<efraim>civodul: I ran the math again, we had more failures than last week. yesterday's number was ~6.8%, last week was ~6.6%

<efraim>our current 7.77% is an anomaly

<Apteryx>Re-enabled this in my .bash_profile for now: export INFOPATH="$HOME/src/guix/doc:$INFOPATH"

<ng0>so far it seems like I had to clean go

<ng0>yep

<efraim>why do we have our default llvm 3.8 and not 3.9?

<efraim>The computer I found on the side of the road is so new it has sata ports on the motherboard!

<oriansj>i7 with 256GB of Ram too?

<efraim>1 gig DDR2 with a slot for a second stick

<efraim>Side of the motherboard says LGA775

<oriansj>so 2007ish

<efraim>that's actually newer than my previous newest castoff desktop

<oriansj>good

<efraim>Easiest way to check the CPU is still going to be to fire it up and check the BIOS, having a really hard time with the heat sink

<sneek>Okay.

<efraim>sneek: forget it

<sneek>Okay.

<oriansj>sneek: did you just respond to sink?

<ng0>sneek: sink the ship

<efraim>motherboard, according to newegg, core2duo era

<efraim>max 2GB ram, but gigabit ethernet

<pmikkelsen>I just sent half a dozen of patches to guix devel, but something went really wrong and they did not come together, sorry :(

<civodul>pmikkelsen: no problem, that happens

<civodul>git send-email is dangerous ;-)

<pmikkelsen>indeed

<civodul>efraim: 7.7% today? damnit, what happened? :-)

<pmikkelsen>civodul: i noticed that a lot of packages suddently need libcap in their inputs, but i have no idea why. the patches i sent were all needed for me to reconfigure my system

<civodul>weird

<pmikkelsen>for me, the elogind service fails to start and i cannot login to my system, does this happen to anyone else?

<efraim>the change from wingod/elogind to elogind/elogind had issues with libcap apparently

<efraim>civodul: ^

<efraim>not sure why that happened though

<efraim>I think I got all the libcap build failures, and I think seek is the only package left broken still from the autoconf change

<efraim>I can't fix seek, it depends on gengeopt and it FTBFS on aarch64

<roptat>hi, I created an iso file for guixsd, which boots fine on virtualbox, but I can't follow the installation instruction

<roptat>I'm supposed to run "herd start cow-store /mnt", but it can't find the cow-store service

<roptat>I'm using the gnu/system/examples/vm-image.tmpl from a recent clone

<roptat>any idea?

<roptat>I used "guix system vm-image --file-system-type=iso9660 vm-image.tmpl" to generate the iso file

<Apteryx>Can the guix closure from guix pull be reused by 'guix system reconfigure ...'? I'm just wondering why it's rebuilding Guile 2.2.2.

<janneke>roptat: not really an idea, what does `herd status' say?

<roptat>it lists a lot of started services and user-home is stopped

<janneke>roptat: ah, i see. cow-store is only present in the installation image, not in vm-image.tmpl

<efraim>Apteryx: it may be related to the recent file CVE and replacement, make sure you have substitutes enabled

<Apteryx>efraim: OK! Thanks.

<roptat>janneke: oh, ok

<roptat>I see there's gnu/system/install.scm, would that work?

<janneke>roptat: possibly...it depends on what you need

<janneke>if the vm image already boots, why would you need to `install' anything?

<roptat>it boots when I specify the iso FS, but I'm not sure it would with ext4. Isn't it supposed to be for qemu?

<roptat>or do you think it would work as a disk for virtualbox?

<janneke>roptat: i think that you can follow the `installing GuixSD in a VM' section and convert the qemu-cow image to a virtualbox image

<roptat>ok, thanks

<janneke>roptat: or use it directly with qemu/kvm

<janneke>the install.scm possibly works too, but is not so nice i think

<civodul>efraim: re elogind, is is that elogind should propagate libcap?

<efraim>i checked, it didn't before

<jbrielmaier>guixhpc seems to be a nice project :)

<civodul>heh, thanks jbrielmaier

<civodul>ACTION tries to finally address the UUID mess

<civodul>well, insofar as it can be addressed

<civodul>because it's a mess that goes way beyond GuixSD :-)

<davexunit>UUID issues?

<davexunit>for disks?

<civodul>davexunit: yes

<civodul>those file system people have different formats for the string representation of UUIDs

<civodul>and those tool people compare strings, rather than actual bytes

<rekado_>cuirass no longer builds: sh: build-aux/git-version-gen: /bin/sh: bad interpreter: No such file or directory

<civodul>rekado_: the "cuirass" package?

<rekado_>yes, the package

<civodul>hmm!

<efraim>sneek: later tell lfam for install in the go-build-system, you can use '(if (file-exists? "bin") (copy-recursively...) [else] (delete-file-recursively ... ', we have a couple in (gnu packages gcc), but it looks like you already build with 'go install' into %output

<sneek>Okay.

<efraim>sneek: botsnack

<sneek>:)

<ng0>I can confirm that the -lcap patches pmikkelsen sent are required to make a system build succeed, at least udisk doesn't build without it

<janneke>ld: cannot find -lcap

<janneke>builder for `/gnu/store/hh27yl1lycwfdsypq84lv487k104623m-accountsservice-0.6.43.drv' failed with exit code 1

<ng0>exactly.

<janneke>ACTION tries to guix system init ...

<ng0>there are patches for that, the most recent ones pmikkelsen sent, if you want to apply them to your copy.

<janneke>thanks..but i'm still on a usb disk

<janneke>i really wanted to install vanilla 0.13 but that didn't work, after a guix pull now this

<ng0>I don't know right now which commit could be good to pull from

<janneke>it would be nice if we had at least one obvious way to install guixsd that works

<ng0>well it works.. but sometimes this happens.

<janneke>yeah, timiing is everything...;-)

<ng0>you could create a module somewhere which creates variants that resemble those patches and export GUIX_PACKAGE_PATH to that directory

<ng0>I'm adding them right now to my path as I need to test stuff

<efraim>You can pull again, I pushed a bunch of lcap patches a few hours ago

<efraim>Not sure everything is fixed though

<ng0>at e9ba22d6e197e449b98f187a9b74459c392d32d6 it still happens for me

<ng0>with clean-go and everything

<janneke>efraim: thanks...pulling again

<dustyweb> https://status.fsf.org/notice/262096 https://twitter.com/fsf/status/905435942315491328

<dustyweb>> Guix, an outgrowth of #GNU, is proving to be an excellent solution for making scientific results reproducible: https://u.fsf.org/2ax

<dustyweb>"outgrowth" is an amusing phrasing, but nice to see a nod from the FSF

<janneke>dustyweb: nice

<reed_>Hi all. I just tried to run a guix pull command and recieved the following error:

<reed_>"guile-git is missing but it is now required by 'guix pull'. Install it by running..."

<reed_>I am fine installing it and proceeding, but one of the main reasons I chose guixsd is because I thought it would help me avoid installing dependencies manually one at a time and then forgetting why I needed them in the first place

<reed_>Is there a better way for me to proceed than to simply install guile-git a la carte

<janneke>efraim: udisks-2.1.8 fails to build during guix system init

<janneke>ld: cannot find -lcap

<ng0>ACTION reviews the lcap patches

<wigust>reed_: I could assume 'system reconfigure' will be a way.

<reed_>i'll give that a shot

<civodul>dustyweb: neat!

<reed_>wigust: I just ran a guix reconfigure and still get the same error when I try guix pull

<civodul>reed_: i can sympathize; the current 'guix pull' in flawed in that it occasionally requires such things (rarely though)

<civodul>we'll fix it!

<reed_>Awesome!

<ng0>can someone apply: 28368 28367 28369 28371 28370 28366 ? The builds succeed

<ng0>they should fix what janneke reported

<efraim>ng0: They all build nicely?

<ng0>yes, no build fails

<ng0>MM needs to be applied before NM though

<efraim>ok

<efraim>patches pushed

<ng0>thnaks

<ng0>and thanks pmikkelsen!

<pmikkelsen>thanks for reviewing and pushing so quick!

<ng0>pmikkelsen: if all of them have been applied, could you close?

<ng0>updating xfce4 is tricky

<ng0>some weeks or months later, next try

<efraim>I closed them also

<ng0>ok

<ng0>how did we manage xfce4 depending on gtk2 and gtk3?

<ng0>I mean, how did we solve it again?

<ng0>xfce4 is in the process of moving to gtk3 wit hthe new versions, but it seems not to be resolved completely

<janneke>thank you pmikkelsen, ng0, efraim!

<efraim>I really need to figure out working with debbugs and emacs

<efraim>I'd really love to use mutt, but have it be debbugs

<ng0>yeah.. that would be great

<ng0>I just have tons of emails

<janneke>ugh...now guix pull gives me:

<janneke>ERROR: Wrong number of arguments to #<procedure display-error (_ _ _ _ _ _)>

<janneke>In guix/discovery.scm:

<janneke> 112:22 1 (_ . _)

<janneke>/me: rm -rf .cache/guix

<ng0>do we have gdbus-codegen hiding in some other package or do I need to package it?

<ng0>new xfce4-panel fails without it to configure

<ng0>I'll try and look at other missing inputs

<janneke>also: guix pull: warning: failed to load '(.cache guix pull pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq build-aux build-self)':

<lfam>sneek: botsnack

<sneek>lfam, you have 1 message.

<sneek>lfam, efraim says: for install in the go-build-system, you can use '(if (file-exists? "bin") (copy-recursively...) [else] (delete-file-recursively ... ', we have a couple in (gnu packages gcc), but it looks like you already build with 'go install' into %output

<sneek>:)

<ng0>I think I really need to package gdbus-codegen

<lfam>efraim: Yeah, but `go install` doesn't work for what counts as a Go "library", only for the end-user executable programs

<lfam>Go doesn't really have a good story for "installing" things

<ng0>ah, glib "bin"

<lfam>`go install` with the GOBIN variable will install an executable to GOBIN. `go install -pkgdir=foo` will install the library objects to foo, but it installs the full dependency graph of the library you're building, instead of just that library, so it's not very useful for us.

<ng0>now I'm one failure further.

<lfam>You're really supposed to keep all your Go stuff in the same directory, or roll your own tooling

<lfam>ng0: That's how progress is made :)

<ng0>yeah…

<ng0>in the end I see myself with one mega patch updating all of xfce4 because everything depends on everything

<ng0>I thought I could avoid that.. but doesn't look like it

<ng0>yay

<ng0>succeeded

<jose1>habla español spañi

<sneek>Welcome back jose1, you have 1 message.

<sneek>jose1, alezost says: according to <https://wiki.archlinux.org/index.php/Font_configuration#Presets> you can also use ~/.config/fontconfig/conf.d instead of /etc/fonts/conf.d

<jose1>habla español

<ng0>ACTION sighs

<ng0>I think xfce4 depends on more packages in itself

<ng0>more work

<ng0>but I fixed my original issue, that's positive

<ng0>Enough for today. g'day

<ng0>oh, one last thing.. unless it's not already known, the emacs install phase patch or whatever it was (didn't follow the thread) makes "make" in guix.git spit out many lines of: gnu/packages/emacs.scm:3202:4: warning: possibly wrong number of arguments to `version' followed by backtrace: ERROR: In procedure public-lookup: Module named (system repl debug) does not exist

<ng0>ACTION off to watch twin peaks

<lfam>sneek: later tell ng0: No spoilers, please ;)

<sneek>Got it.

<ddp>good luck

<ddp>just wanted ep 16 a few nights ago.

<ddp>s/wanted/watched/

<lfam>Yes, you can only keep a cherry pie from spoiling for so long ;)

<ddp>is there a #twinpeak irc channel?

<lfam>#blacklodge

<ddp>thanks

<lfam>ddp: I'm joking, I don't know if that channel exists :)

<ddp>it does!

<ddp>tee, hee, hee

<lfam>Heh

<pmikkelsen>Can anybody who has a GuixSD system with gnome confirm that they can login with the latest master? I can't for some reason, but I will try to investigate

<ddp>can install the GuixSD system on the latest Fedora LXDE?

<ddp>s/can/can i/

<lfam>ddp: GuixSD is a full operating system, so you wouldn't install it on Fedora. Instead, you'd install it instead of Fedora, or next to Fedora (dual-boot). If you just want the Guix package manager, that will work fine on Fedora or basically any GNU / Linux distro

<janneke>ddp: epronk has undertaken quite some efforts to install GuixSD on ubuntu's LXC. He hasn't cracked it yet but got quite far. Is LXDE related?

<lfam>I think LXDE is a desktop environment. Similar name to LXC, but not a similar technology

<janneke>while GuixSD offerings on legacy distros can be great for people to get acquinted with GuixSD, I agree that it feels wrong, kinda alike running gnu/linux vm's on windows

<janneke>*acquainted

<lfam>We offer a few ways to try it out now. You can boot the VM image and the installer in QEMU

<ddp>okay, i see

<lfam>If you just wanna boot a VM to try it out, I recommend the GuixSD 0.13.0 Virtual Machine Image from this page: https://www.gnu.org/software/guix/download/

<lfam>You can also use the installer image, and even install it in QEMU, depending on what you want

<pmikkelsen>regarding my bug about not being able to login, I have tried updating elogind from 232.2 to 232.4, as there was a fix for some cgroup stuff.. Will be back in a few minutes when I have reconfigured

<efraim>looks like someone's been busy on oss-sec, another CVE for each of openjpeg, graphicsmagick and libarchive

<efraim>I don't think I'll be able to take care of them before I go to bed tonight

<lfam>efraim: I'll do the libarchive bug now

<efraim>lfam: thanks

<dustyweb>efraim: oof

<dustyweb>only the libraries used by nearly everything, huh?

<dustyweb>thank goodness we have grafts these days

<lfam>Something is weird with the current libarchive packaging

<lfam>There is an unused libarchive-3.3.1 package

<janneke>yay, my remotely issued guix system init finally finished

<lfam>I wonder if 3.3.1 is affected by this bug

<civodul>howdy lfam!

<lfam>Hi civodul!

<civodul>what's up? :-)

<lfam>Working on some build systems and trying to stay sane ;)

<lfam>Taking a break to apply some security updates

<civodul>heheh, that's an original way to take a break ;-)

<civodul>so does the Go build system beat the Crates/Rust thing?

<janneke>i very much like the `herd start ssh-daemon' option in `Preparing for Installation'!

<civodul>can be useful apparently :-)

<lfam>I haven't looked at Rust or Crates so I can't say :0

<lfam>I mean, :)

<janneke>civodul: yeah, i still had to find a bin/passwd somewher, but hey

<lfam>The situation is a bit of a mess. They Go people are definitely going their own way

<lfam>But it will work

<janneke>...and master was broken today, but wow amazing support and patching here

<lfam>janneke: What was broken?

<janneke>first i tried 0.13 without guix pull, that didn't work -- forgot details

<janneke>lfam: after guix pull, several things didn't build eg udisks-2 with an ld: cannot find -lcap error

<lfam>I sent the patch for libarchive to guix-patches

<lfam>Hmm

<janneke>lfam: pmikkelsen, efraim an ng0 conspired to fix it and now it succeeded

<lfam>Interesting that so many packages needed libcap all of a sudden. I wonder if, instead, libcap should be propagated from somewhere

<lfam>Like, what changed to break all those packages at once?

<janneke>good question, no idea

<janneke>i have no problem with this hickup at all, but it would not have been a grand ux for newcomers

<lfam>No, indeed

<janneke>on the contrary, the irc help and patch collaboration is heart-warming

<lfam>Installing from 0.13 should really work

<lfam>It's too bad that it didn't work

<janneke>lfam: the last hurdle before i decided to do guix pull instead of vanilla 0.13 was guix system init with --fallback

<janneke>guix-0.13 substitute failed to install

<janneke>but with --fallback, it failed to build

<janneke>lfam: guix-0.13: Testsuite summary for GNU Guix ... # FAIL: 2

<jonsger>janneke: that's kind of normal here if I buid guix from source...

<lfam>Please report these test failures so we can fix them :)

<lfam>It shouldn't be normal :)

<civodul>+1!

<civodul>lfam: to me the libcap thing also looks like a missing propagated input somewhere

<civodul>i haven't investigated though

<lfam>Yeah, that's I thought

<jonsger>lfam: I'll do that.

<cehteh>ACTION wishes for a much faster guile .. *yawn*

<cehteh>trying to update a guixsd test vm which i havent started for half a year or so

<janneke>lfam, civodul: how do i find/pick the git commit to reproduce that guix-0.13 build failure? how much i like to report bugs, i'm a bit reluctant to repeat the USB install process and try --fallback to read the failure log

<janneke>*much as i would like

<civodul>janneke: so it's guix-0.13.0 that fails to build from the USB key, right?

<civodul>do you have the failed store item handy?

<civodul>is it i686 or x86_64?

<janneke>civodul: yes...i don't think so but possibly?...x86_64

<janneke>civodul: how would i find that failed store item?

<civodul>so it should be /gnu/store/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0 no?

<civodul>this one is available on hydra

<lfam>Previous discussion of libcap in the context of elogind: https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00429.html

<janneke>ACTION thought that without --keep-failed, all build stuff is gone

<janneke>it tried to build: /gnu/store/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0 ... ah so yes!

<civodul>ok but substitutes for this are available, aren't they?

<janneke>unpacking; `/gnu/store/y7cgyi1syavy17kacn5s2adw20i8mglz-guix-0.13.0-checkout/gnu.scm' -> `./gnu.scm'

<lfam>Indeed, it looks like propagating libcap from elogind is the solution

<janneke>no...it failed to download several times and then i tried --fallback

<civodul>"wget -O /dev/null https://mirror.hydra.gnu.org/guix/nar/gzip/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0" works for me

<janneke>waitaminute

<janneke>yes, for me too, but this is in my log:

<janneke>Downloading http://192.168.32.121:8181/nar/gzip/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0 (152.9MiB installed)...

<janneke> guix-0.13.0 5.1MiB/s 00:10 | 50.2MiB transferred

<janneke>killing process 2640

<janneke>guix system: error: build failed: some substitutes for the outputs of derivation `/gnu/store/s033smmdkv3jcy259w92i42mwfx0bga4-guix-0.13.0.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source

<lfam>I guess there is a corrupted archive in that mirror?

<civodul>you used a different substitute URL?

<janneke>oh wait, that's our internal machine...

<janneke>ugh

<civodul>ah ha!

<janneke>i used this: guix system init --substitute-urls="http://192.168.32.121:8181 http://192.168.32.122:8181 http://janneke.lilypond.org:8080 https://mirror.guixsd.org" --no-grafts /mnt/etc/config.scm /mnt

<civodul>it's not running 'guix publish' with -C

<lfam>So we can ignore those test failures after all ;)

<janneke>local cache first...

<janneke>civodul: `-C' ?

<janneke>ACTION *blush*

<civodul>--cache rather

<civodul>i can tell it from the two lines you pasted :-)

<janneke>it's an ubuntu box, using the systemd thingy for guix publish...

<janneke>the systemd init has: ExecStart=/var/guix/profiles/per-user/root/guix-profile/bin/guix publish --user=nobody --port=8181

<janneke>no --cache

<civodul>when guix publish runs with --cache, it does not emit a Content-Length header, among other things

<civodul>so if there's more than 1 user of this cache, i recommend --cache

<civodul> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-publish.html

<civodul>(not that it really solves your problem, but hey!)

<janneke>i'm pretty confused...

<janneke>does this mean we should add --cache to: ./etc/guix-publish.service.in ?

<janneke>but now that we are rolling out guix/guixsd at verum we certainly have more than 1 client :-)

<cehteh>makes me reading about the cache thing too .. returning 404 on first attempt? wont it be nicer to have a switch to make the first attempt block as well?

<civodul>janneke: not "we", but "you" :-)

<civodul>it's not necessarily a good default

<civodul>cehteh: it could block for a long time, which is not desirable

<civodul>the --cache behavior is tweaked for servers with "enough" users

<janneke>civodul: hehe

<cehteh>how about a --block-timeout or so? block and wait for lets say 20 seconds or send 404

<cehteh>s/or/and send 404 when expired

<cehteh>is there some 'come back later' error code in http? like in smtp

<cehteh> https://httpstatuses.com/202

<civodul>in general narinfo requests should return immediately

<civodul>those 404 advertise a short TTL via Cache-Control anyway

<civodul>such that 'guix substitute' knows it can try again 5 minutes later

<cehteh>ah ok

<efraim>How long is our timeout when the substitute server is busy?

<civodul>there's actually no timeout on the client side

<civodul>there's a timeout in the nginx proxy config, but i don't know what it is off-hand

<civodul>it's in in guix-maintenance.git

<cehteh>grr i will never understand scheme

<cehteh>(guix-publish-service #:host "0.0.0.0" #:cache "/var/cache/guix/publish" #:ttl "30d" #:workers 6)

<cehteh>whats wrong there?

<civodul>"guix-publish-service" no longer exists i believe

<civodul>use (service guix-publish-service-type (guix-publish-configuration ...))

<civodul>see https://www.gnu.org/software/guix/manual/html_node/Base-Services.html#guix_002dpublish_002dservice_002dtype

<cehteh>ok

<cehteh>there is so much redundancy in these scheme stuff

<cehteh>ERROR: In procedure number->string: Wrong type argument in position 1: "30d"

<cehteh>.. so how do i define the --ttl there? documentation says it this way or?

<castilma>hey, I'm trying to build guix from git on a raspberrypi 3. make check fails with a bash segfault. http://paste.lisp.org/+7M2M is this a known problem?

<lfam>castilma: efraim (in this channel but perhaps not around currently) is leading the work to get Guix running well on aarch64.

<civodul>cehteh: it should be an integer, as explained at https://www.gnu.org/software/guix/manual/html_node/Base-Services.html#guix_002dpublish_002dservice_002dtype

<cehteh>(ttl 2592000) ... in hope it defaults to secondd

<civodul>yeah

<castilma>lfsm: aarch64==arm7hf?

<castilma>lfam: ^

<civodul>it's armv8

<cehteh>ah the documentation is a bit confising because of the 'see --ttl'

<lfam>castilma: aarch64 ~ armv8a

<lfam>My understanding is that Efraim is using Guix on some aarch64 boards, but I don't recall whether or not he's tested on a Raspberry Pi 3

<lfam>I wonder what is happening on line 7, and of what file?

<lfam>" Zeile 7: 11674"

<lfam>GUILEC / bin / bash: Line 7: 11674 Memory access error

<lfam>I wonder if it's a problem that host=armv7l-unknown-linux-gnueabihf even though the hardware is armv8a

<civodul>lfam: so armhf-linux binaries crash on aarch64?

<lfam>civodul: I think aarch64 is supposed to be able to run them, but I don't know the specifics (I don't have any relevant hardware).

<marusich>I'm not too familiar with dconf. I just know it's used as a way to store application preferences. I'm curious: is it stateful, in the sense that it manages preferences state outside of the store, or is it stateless, in the sense that its application preference data is stored in the store?

<janneke>ACTION built guix from a6d728b7a ... no problems

IRC channel logs

2017-09-06.log