<pkill9>the error is: guix environment: error: build failed: some substitutes for the outputs of derivation `/gnu/store/7a3n0hkfm57jp53087n1akbabxj7yngs-fastboot-7.1.2_r6.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source <pkill9>and more specifically: guix/ui.scm:1579:12: In procedure run-guix-command: <pkill9>Bad Read-Header-Line header: #<eof> <pkill9>is this a bug in Guix's substituting code? <lfam>pkill9: It sounds like a network problem. Did you try again? <pkill9>hmm i'm getting a similar error when running guix pull <mange>Which makes sense if it's a network problem. <lfam>Okay, the options are to use --fallback or to use --substitute-urls appropriately <pkill9>does --substitute-urls append to the configured substitute urls, or replace them all? <apteryx>oh, the pypi importer is not recursive <vagrantc>it would require comparing against what's already in guix, at the very least, and probably becoming version-aware <mange>You can write your own wrapper that calls the pypi import code. I did that for the elpa importer a while ago. <apteryx>vagrantc: oh, comparing against what is in guix is a nice safety check (to prevent packaging something that already exists) <apteryx>it seems berlin is returning problematic answers: Bad Read-Header-Line header: #<eof> <pkill9>yeah berlin is down, berlin.guixsd.org just gives a 502 error when i visit it in browser <lfam>I've reported the problems with berlin to the sysadmins <apteryx>Guix has mostly integration tests rather than unit tests, right? Is there a clear organization between both, how are they mingled together? ***Server sets mode: +cnt
<civodul>i realize i never really got when to use "whilst" instead of "while" <ng0>does anyone of you have a package definition for "gdbus-codegen"? <ng0>oh, it is in glib:bin, right? <snape>I think we should stop building core-updates and staging at each commit, on Cuirass, and instead trigger them manually <snape>because it's ressource consumming ***rekado_ is now known as rekado
<rekado>snape: do you think we should have an admin interface, or should all admins do this via direct manipulation of the database? <snape>I'm not a fan of database manipulation because it's hard to keep track of what has been done. But it's the only thing we can do right now. <snape>I'd love the configuration to be more deterministic: i.e. change the Cuirass service conf, so that it updates the database. Unfortunately it won't work right now <snape>the admin interface would be a lot of work too <rekado>what would be difficult about an admin interface? <rekado>we’d need user authentication, but we could get that from the proxying web server. <snape>well, nothing then :-) I don't know about the proxying web server <rekado>we don’t connect directly to the cuirass web interface; we just pass requests that arrive at nginx through to the application web server. <rekado>we could have a URL that requires user authentication, have nginx take care of that, and then pass the user name through to the application. <rekado>isn’t pretty but it would allow us to ignore the problem and move ahead more quickly <snape>right. but it's almost the same as entering the SQL requests manually <rekado>if the admin web interface allowed the user to control whether a branch is built or not by simply clicking on the thing I would feel much more comfortable with it than running some sqlite command in an ssh session. <snape>yes, but it's fundamentally the same. Also, the SQL request isn't complicated at all. <snape>but you're right, an admin interface is preferable <snape>FYI the request would be: update inputs set revision = '<revision>' and branch = NULL where specification = '<revision>' and name = '<input-name>'; <rekado>I’m confident I *will* do this wrong at some point :) <rekado>if it were the only thing I suppose the SQL way is fine, but we should probably also have an admin way of restarting failed builds and other little things. <snape>s/specification = '<revision>'/specification = '<specification name>'/ <snape>rekado: forget about my query, it crashed my server <civodul>snape: i'm not sure building core-updates is consuming on berlin <civodul>we really need some monitoring actually <civodul>but my impression is that the build machines are often idle <civodul>right now half of them have a load of 0 <snape>Yeah I don't know. I created a ticket about it, if you think it's useless, maybe you can reply, and we'll close it, no need to work on useless things :-) <civodul>in Cuirass proper we could measure things time of commit to time of evaluation completion <civodul>and then time of evaluation completion to time of build completion <snape>According to the web interface, the first eval has 1357 pending builds <snape>I don't quite understand why half of the machines have a load of 0 then <snape>Also civodul, could you create a ticket that explains your 'time of commit to time of evaluation, etc' idea? Otherwise I'm 90% sure that I'll forget about it <snape>if you prefer I can create it too <roptat>this file should be reachable via the GUILE_LOAD_PATH (or GUIX_PACKAGE_PATH) as thorwill/packages/custom.scm <roptat>to be more clear, GUIX_PACKAGE_PATH needs to point to the directory containing thorwill/packages/custom.scm <thorwil>roptat: ah, now i start to get the relation between paths and module naming, thanks! ***slyfox_ is now known as slyfox
<civodul>seen in an Emacs-Guix package buffer: "This package is *from the future*" <janneke>civodul: did you get that while i did make a lot of progress, i'm again stuck on wip-bootstrap? <civodul>janneke: no! i only got that you did make a lot of progress :-) <rekado>is anyone here familiar with multipathd and would like to test a Guix system service? <rekado>(I need one for berlin.guixsd.org) <ehmry>does guix run okay in virtualbox? do guest additions and the kernel modules work? <janneke>civodul: i suspect that i created a circular dependency; i can bootstrap everything up to gcc-mesboot <janneke>then i added gcc-mesboot, glibc-mesboot and binutils-mesboot to %boot0-inputs <civodul>janneke: if modules A and B import each other, the key thing is to make sure that the top-level on A does not depend on effects of the top-level of B, and vice versa <janneke>and when i want to build gnu-make-boot0 (on x86), guix just 'hangs' <janneke>civodul: so, on x86_64 i can do: ./pre-inst-env guix build --system=i686-linux gcc-messboot; but on my x86 guix hangs <civodul>janneke: i can test on commit 9edb354bba6fbd477bbdd2b8fa32cb550300716e? <civodul>"./pre-inst-env guix build -s i686-linux gcc-mesboot" works for me on x86_64 <civodul>janneke: could you try to find out on your i686 machine what it's doing? either via strace, or by adding 'pk' here and there <janneke>civodul: i'm already on: 6325c7b2370c08d1db26992573968e8671f7eacb now <janneke>oh, wait: my personal guix archive...didn't push to savannah yet; wait <janneke>is it OK to pull there from you, i can push to savannah too... <civodul>alright i'm at 6325c7b2370c08d1db26992573968e8671f7eacb <civodul>it prints a bunch of ";; WARNING" lines <civodul>and then it fetches substitutes for the former(?) bootstrap binaries <rekado>my biggest concern with multipathd is that I don’t know if /gnu/store may be on that device and how it interfaces with the device mapper configuration. <janneke>yeah -- so i only made bootstrap changes for i686-linux <janneke>and i don't know how to test them other than in my x86 vm <civodul>rekado: will it be / or /gnu/store on the multipath device? <rekado>we could use the big storage already, but only through one of the HBAs. <civodul>meaning performance wouldn't be as good as it could be? <rekado>yes, and it would not be redundant. <civodul>IIUC multipathd needs to be running by the type the mapped device is created (or accessed), right? <civodul>so we'd probably need a statically-linked multipathd in the initrd <civodul>ideally we'd restart it after switch-root though <civodul>it should be doable but there are probably pitfalls <civodul>did you try mounting it by hand, to make sure we understand what needs to be done? <civodul>that is, starting multipathd with an appropriate multipath.conf, creating the the mapped device, and then mounting it *civodul has never used multipath i/o <rekado>I haven’t tried mounting the mapped device on GuixSD yet. <rekado>building a statically linked variant seems challenging; maybe we can do without as many inputs <grafoo>hej! i'm trying to patch a package using (patches (search-patches "0001-foo.patch")). <grafoo>do i need to add anything else to the package definition? <grafoo>there is no patch phase appearing in the build logs. <rekado>grafoo: patches are applied when creating the source tarball. <grafoo>rekado: so is need to import the tarball again into the store and use that one afterwards? <rekado>grafoo: no, you can just inherit from the original package, override the “source” field with a variant that adds the “patches” field. <civodul>janneke: it's allocating, so it could well be expanding its stack without bounds due to infinite recursion <civodul>janneke: does "guix graph -e '(@ (what) ever)'" complete, and does it show a reasonable graph? <civodul>rain1: you need to make more free space, for instance by running "guix gc" <grafoo>i think i'm just doing this. but it doesn't seem to work. <grafoo> (base32 "1r3pxn7cx3grb8myb4q1b0pk447pc06cifd0v7ym13xw00372dlx")) <grafoo> (patches (search-patches "0001-fix-netinet-ip.h-include.patch")))) <rekado>grafoo: could you please paste the complete package definition to a paste service? <rekado>grafoo: thanks. Could you also tell us what you mean by “doesn’t seem to work”? Do you get an error message? <rekado>also, where did you add that package definition and what did you try to build it? <grafoo>rekado: i'm building the package with `GUIX_PACKAGE_PATH=$PWD guix build perftest` <grafoo>the scheme file for the package and right next to it is the patch file. <rekado>so it needs to have a module definition at the top, and the module name needs to match the file name. <rekado>is the file name “my-packages.scm”? <grafoo>also building python-clustershell works fine. <grafoo>no error really but the patch doesn't seem the get applied <rekado>are you sure it’s actually building your package variant? <grafoo>there is no existing perftest package in the guix repo. <janneke>civodul: on x86, ./pre-inst-env guix graph gcc-mesboot works! <grafoo>rekado: is there a way to step through all the phases of guix build manually? <rekado>grafoo: this also wouldn’t help you here. <rekado>these are two different derivations: one for the (patched) source archive, another for the build. <rekado>this should show you that the source code is unpacked, patched, and repacked. <rekado>civodul: building a statically linked subset of multipathd looks difficult. <grafoo>rekado: yes the tarball exisits and is patched. <rekado>I wonder if we could remount devices instead: mount /gnu/store from /dev/sdb1, then start multipathd, which creates /dev/mapper/foo from /dev/sdb1 and /dev/sdc1, and then remount /gnu/store from /dev/mapper/foo. <rekado>grafoo: then there’s no problem, is there? <snape>the Shepherd changes are awesome! Should we update our Shepherd package? <civodul>snape: we need changes on the guix side to take advantage of them, and more testing <civodul>after than we can make a Shepherd release <civodul>but yeah, it's a long overdue improvement! <ecbrown>here's an error message: guix weather: error: perl-text-markdown-discount-unbundle.patch: patch not found <ecbrown>debian testing + guix: i do guix pull, then want to see what i have to build or what can be pulled <jonsger>ecbrown: thats a know problem of the release tarball I think <ecbrown>guix package -u is going about its business, so no matter *ecbrown had to give up on guixsd on 15inch macbook pro, though it runs great on macbook air 11, even camera works <grafoo>rekado: my bad. i didn't get that the include was not only in the header file. <grafoo>at least i learned a little bit about the patch process. <grafoo>another somewhat related question... <jonsger>Sleep_Walker: I played a little around in home:sleep_walker:guile, but I didn't get gnutls using guile2.0 for gnutls-guile <grafoo>is there a way to switch on/off a specific configuration when installing a package from source? <grafoo>kind of like use flags work in gentoo. <jonsger>oh thats nice. what machine do you have? <rekado>grafoo: the way to do that is to create a custom package definition. That new definition can inherit all fields from an existing definition. <rekado>a related feature is graph rewriting. <rain1>that's great, i was able to pull and reconfigure and stuff after guix gc <civodul>rain1: what happened to ssh? (i missed previous discussions) *civodul works on an implementation of channels <rain1>i don't know i had it working then i rebooted and it was gone <grafoo>rekado: alright. thx for clarification. <janneke>civodul: hah, this doesn't finish on x86: ./pre-inst-env guix graph --type=bag mescc-tools-boot <civodul>janneke: that means a cycle is introduced by the implicit inputs <janneke>and is pretty big on x86_64, i'll have alook later *janneke needs to go afk for ~an hour <civodul>janneke: also, that it behaves different on i686 and on x86_64 with "-s i686-linux" means that some package recipe must not be quite right, or the system conditional is not evaluated at the right time <janneke>hmm, but that's (partly?) the idea right, we only want to modify the i686-linux bootstrap... <civodul>yes but we should get the infinite recursion just as well when using "-s i686-linux" on x86_64 <civodul>OriansJ: that compiler is truly impressive <civodul>i would never have thought it was possible to implement in "only" 5k lines of asm <rekado>hmm, multipath does not work. Says my drives are busy, but they are not mounted. <rekado>I can mount the drives the old-fashioned way but multipath will not map them. <rekado>it worked after removing the wwid alias from the config file… <rekado>I also needed to run “kpartx -avp-part /dev/mapper/mpatha” before being able to mount the thing. <rekado>but now I have /dev/mapper/mpatha-part1 and can access the external storage via multipath. <rekado>the idea to mount the underlying disk directly is probably a dead-end. <rekado>we cannot run multipathd and have it map the devices when they are mounted. <civodul>we could run it before they are mounted, from the initrd <rekado>so I can’t just start with the store mounted from /dev/sdb1, then map the multipath device from /dev/sdb and /dev/sdc, and then remount /gnu/store from /dev/mapper/mpatha-part1 <rekado>embedding a statically linked multipathd in the initrd probably also won’t work. <rekado>at least I haven’t been able to make it work, even after patching the Makefiles. <roptat>I'm trying to use a snippet on a source archive whose first entry is a symlink to the source directory <roptat>the result is an archive with that single symlink... <roptat>I tried removing the symlink, but then the snippet fails because it tries to repack the archive from that symlink *rekado looks at multipath-tools-boot in Debian <civodul>roptat: you can remove the symlink *and* rename the actual directory to that name :-) <vagrantc>OriansJ: awesome news regarding stage0/hex0, etc. ! <ecbrown>would an offload build server ever require more than 4G of RAM? <ecbrown>i can move DIM over to the machine, but thought i would ask <apteryx>has anyone broken icons? I've installed hicolor-icon-theme and it got better, but some are still missing, such as in the tooltips that appear when visiting Emacs' menus. <apteryx>I'm testing currently on Linux Mint 18, which is configured to use the 'hicolor' icon set. I have the hicolor-icon-theme installed in Guix. <vagrantc>ecbrown: yes, some builds require more than 4GB of ram <vagrantc>though many don't ... so it may depend on what you're buildingf <vagrantc>and it also may depend on how much swap you allocate ... qtwebkit recently failed for me with 8GB of ram and no swap <ng0>ecbrown: yes, depending on what you build <ng0>julia is one of the worst examples <ng0>in general you'll be good with 4-8GB RAM <vagrantc>speaking of which, did either of the substitute servers build qtwebkit yet? <ng0>maybe a made up number of 80% of software requires less than 1GB to build <vagrantc>does either hydra.gnu.org or berlin.guixsd.org have a way to search for the last build of package X ? it seems to just be by commit <amz3>regarding bootstraping sorry <ecbrown>vagrantc: yeah that's the sort of package i'm worried about <ecbrown>i have offload build working ok for a guixsd build machine, but not for a larger machine (16G) running debian <ng0>ecbrown: I have an 8GB offloader, usually without swap <ng0>except for julia it manages most of the buildable packages <ngz>Hello. In ".profile", I source "$GUIX_PROFILE/etc/profile". Unfortunately I have to unset "GI_TYPELIB_PATH" and "XDG_DATA_DIRS" in the same file or Gnome Shell crashes. Is it a known issue? Is there any workaround? <sneek>Welcome back ngz, you have 1 message. <sneek>ngz, wigust says: Try instead of unsetting - set them to what they were before sourcing ‘~/.guix-profile/etc/profile’ [1]. For me setting XDG_CONFIG_DIRS and XDG_DATA_DIRS after sourcing [1] works. <amz3>ecbrown: why is julia a killer? <ecbrown>amz3: i think it compiles its own clang/llvm, blas etc. <amz3>ecbrown: it's unlikely they re-implement blas <amz3>ecbrown: sorry, I should not start my that kind of conversation, my POV is anything but scheme is a diversion, I might be too much zealous <amz3>ecbrown: I was interested to know what makes julia as language or platform shine <ecbrown>basically C/C++/Fortran with a REPL, and 1 based arrays <ecbrown>of course that's a drastic simplification, but someone who luv's lisp should appreciate the importance of a REPL <amz3>ecbrown: guile 3.0 will compile to assembly AFAIU which I think is a similar trick to what julia does <amz3>ecbrown: yes, of course REPL is great tool. see jupyter for example. or for instance what CERN did to bring a REPL to C++ <rain1>how would I get ssh on the latest guix? <amz3>ecbrown: in practice it means for people like me a faster language, i don't know the other implications <ecbrown>rain1: guix pull && guix package -i openssh i suppose <amz3>rain1: maybe guix package -A lsh? <rain1>i can't ssh in to my guixsd VM <ecbrown>rain1: just an inquiry, are you installing a desktop machine? There are some error reports of ssh-daemon not starting at boot time <rain1>yes i am, i must be bumping into that error! <rain1>i didn't know if it was a bug or if i misconfigured something <ecbrown>unfortunately, i do not know how to fix it. <ecbrown>cant "ssh buildhost guile" dammit. must be some .bashrc crap <ecbrown>hmmmmm.... i think guixsd "cheats" here and source's in /etc/bashrc.... <rain1>im not sure how to do my own modifications to the guix packages repo <rain1>i tried to git clone it then set GUIX_PACKAGE_PATH to that dir, then guix build -K mrustc as a test <taylan>hmm, I can only log in to GNOME with root right now. if I log in with my normal user, GNOME or X11 seems to crash and I'm back in the login manager soon after. I moved away my GNOME autostart scripts but still have the same problem. what else might be causing this?.. <amz3>taylan: hey! good to see you around! sorry i can not help. <taylan>sadly I only drop in sporadically these times. busy with lots of stuff :) *taylan laments about software that won't say what its problem is <roptat>rain1: you should use pre-inst-env from your git checkout <rain1>thank you, i will make sure to do ./pref-inst-env for all this. but even after doing that my guix build command gives the same errors <ngz>taylan: Do you source $GUIX_PROFILE/etc/profile in ".profile"? <taylan>ngz: I don't! good catch, thank you <taylan>I have a very... "intricate" ~/.profile (in fact, it's located at ~/etc/profile) <taylan>my obsessive tidiness keeps biting me in the behind <ngz>taylan: It probably will not solve your issue. The problem is some environment variable is set, and Gnome doesn't like it. I had to unset GI_TYPELIB_PATH and XDG_DATA_DIRS to be able to go past GDM. <ngz>It's not pretty, but at least I can log in. <lfam>Does anyone know how to run Guix's dropbear system test? I tried `make check-system TESTS=dropbear` but it says "Running 0 system tests...\nTOTAL: 0" <lfam>Some other tests do work, for example the dicod test <roptat>rain1: have you unset GUIX_PACKAGE_PATH? <rain1>i didn't unset it, i will try again without it set <snape>what is the status of Chromium? <snape>lfam: I can't run them either, I believe it's a bug <lfam>snape: It's currently maintained "out of tree", mostly or fully by mbakke, if I understand correctly <snape>lfam: what prevents it to be included to the main tree? <taylan>ngz: in my case it wasn't ~/.profile after all. it was something in ~/.config or some such. I renamed all the XDG directories and was able to log in (with my GNOME settings gone of course) <taylan>localized the problem down to ~/.cache ***Server sets mode: +cnt
<taylan>I removed a bunch of stuff from ~/.cache that seemed useless and now it works, lol. <taylan>maybe it was a strange GNOME bug where some program couldn't deal with its own cached data from an old version <lfam>Has anyone had issues in Epiphany with HTML5 video, h264 video, and MP3 playback? None of these are currently working for me. Did they used to work? <rekado>lfam: they used to work and no longer do. <rekado>in the past it was enough to install gstreamer plugins, but this no longer seems to be the case. <lfam>I'll try it again and do some debugging. It used to be enough to install gst-plugins-{good,base,ugly}? <rekado>I have these installed and gst-libav. <rekado>GST_PLUGIN_PATH is set to $HOME/.guix-profile/lib/gstreamer-1.0 <rekado>and GST_PLUGIN_SYSTEM_PATH=/home/rekado/.guix-profile/lib/gstreamer-1.0:/home/rekado/.guix-profile/lib/gstreamer-1.0 <rekado>(don’t know why it’s listed twice) <lfam>It was pointed out to me that tomorrow is the last day of support for Firefox 52, which is what Icecat is based on <lfam>Hm, I installed the plugins I mentioned, and gst-libav, and then exported GST_PLUGIN_SYSTEM_PATH like Guix suggested, and now MP3 playback and Youtube (HTML5 or h264?) works for me on Debian <snape>I think I'll reply to the thread and talk about Chromium inclusion <lfam>Okay :) It does seem like something we could offer sooner than we can get our Rust packaging ready to go <lfam>I wonder if the Epiphany package should come with some or all of those plugins, rather than expecting the user to install them manually <snape>indeed, as propagated inputs <lfam>It would be awesome if Epiphany could refer to them directly (plain inputs) <snape>yes, but more difficult probably *snape is trying to install them <lfam>Nice thing is that the MP3 patents expired, gst-plugins-ugly is probably not necessary anymore <lfam>For the most common codecs, that is <apteryx>lfam: cool, I didn't know about MP3 patents expiration :) <lfam>Yeah, they got moved to gst-plugins-good from gst-plugins-ugly a couple months ago :) <lfam>Hm, adding the plugins as plain inputs doesn't work on its own <lfam>But, why did it used to work??? <snape>lfam: I don't have the icon theme. Do you know what needs to be installed/ <lfam>snape: My profile has adwaita-icon-theme and hicolor-icon-theme installed <civodul>rekado: i see in guile-debbugs release on the "GNU Spotlight"! \o/ <lfam>rekado: Do you have a rough idea of when media playback stopped working for you in Epiphany? <rekado>lfam: no, sorry. It’s been a couple of weeks already. I always wanted to investigate but never found enough time. <rekado>I’m currently working on 0.0.3 with full support for searching debbugs and mailutils integration. <rekado>(I’m developing this together with mumi) <rekado>still debugging that http-post problem where Guile considers mail headers in the payload as HTTP headers. <snape>lfam: installing them works, thank you! *snape switch from GNU Icecat (now unsupported) to Epiphany <civodul>rekado: excellent! lemme know if i can be of any help for that bug <civodul>i think it'll help greatly when we have mumi <jonsger>civodul: I'm almost finished with guile-gcrypt on opensuse. so you can start to integrate it to guix :P <janneke>civodul: some good progress again with the bootstrap; the guix graph was helpful <janneke>it turned out that inheriting from grafted `binutils' somehow pulled in dependencies, using package/inherit fixed that <civodul>binutils is not grafted in current master, we should consider rebasing wip-bootstrap <janneke>would it be OK to just rebase on master and do a hard reset? <civodul>janneke: sure; the convention for "wip-" branches is that they may be rebased anytim <janneke>good, i'll have a go with that after my attempt to drop %bootstrap-make and %bootstrap-diffutils again <jonsger>rekado: maybe I could host one of the ARM machines at SUSE. I can ask :) <rekado>jonsger: we would appreciate that a lot! <jonsger>I have no idea if they do something. We host a lot for opensuse, but I don't know about "foreign" FOSS projects