IRC channel logs


back to list of logs

<pkill9>i got an error when running `guix envronment --ad-hoc fastboot`:
<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>what does this mean?
<pkill9>is this a bug in Guix's substituting code?
<lfam>pkill9: It sounds like a network problem. Did you try again?
<pkill9>yeah a few times
<pkill9>i'll try again in a min
<pkill9>hmm i'm getting a similar error when running guix pull
<mange>Which makes sense if it's a network problem.
<pkill9>can you reproduce the issue?
<pkill9>maybe berlin is having issues
<pkill9>i get '502 bad gateway' when visiting
<mange>Yeah, me too.
<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?
<pkill9>ah it replaces them
<pkill9>ok now it's working when i run it with --substitute-urls=
<apteryx>oh, the pypi importer is not recursive
<apteryx>easy way to enable this?
<apteryx>(is there an easy way)
<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.
<mange>This message has my code wrapping the elpa importer: I wouldn't call it "easy", but it's not super difficult.
<apteryx>vagrantc: oh, comparing against what is in guix is a nice safety check (to prevent packaging something that already exists)
<apteryx>mange: thanks, I'll have a look
<apteryx>it seems berlin is returning problematic answers: Bad Read-Header-Line header: #<eof>
<apteryx>I need to use --fallback a lot
<mange>Yeah, I've been using --substitute-urls= today.
<pkill9>yeah berlin is down, just gives a 502 error when i visit it in browser
<lfam>I've reported the problems with berlin to the sysadmins
<apteryx>lfam: OK!
<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>Hello Guix!
<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?
<ng0>yep.. builds now
<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
<snape>isn't how Hydra works?
***rekado_ is now known as rekado
<rekado>snape: yes
<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.
<snape>oh yes got it
<snape>with NGINX's auth_basic
<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>I don’t understand that.
<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>yes, agreed
<snape>rekado: forget about my query, it crashed my server
<civodul>hey snape, web!
<civodul>*welcome back!
<snape>hey civodul, thanks!
<civodul>("web" too i guess)
<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
<civodul>that would be very useful
<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
<thorwil>hi! what's wrong with that i get a "guix package: warning: failed to load '(thorwil)': no code for module (thorwil)"?
<roptat>this file should be reachable via the GUILE_LOAD_PATH (or GUIX_PACKAGE_PATH) as thorwill/packages/custom.scm
*snape has to go
<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*"
<civodul>it's like a DeLorean, i told ya
<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 :-)
<civodul>what's the problem?
<rekado>is anyone here familiar with multipathd and would like to test a Guix system service?
<rekado>(I need one for
<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>so it could be a different thing
<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
<civodul>i don't have that commit
<janneke>(i worked all weekend ;-)
<janneke>oh, wait: my personal guix archive...didn't push to savannah yet; wait
<civodul>ah, see! :-)
<janneke>git clone
<janneke>is it OK to pull there from you, i can push to savannah too...
<civodul>that's ok, i updated my .git/config
<civodul>alright i'm at 6325c7b2370c08d1db26992573968e8671f7eacb
<civodul>so the command above still works
<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>i'm using "-s i686-linux" tho
<civodul>rekado: will it be / or /gnu/store on the multipath device?
<rekado>just /gnu/store
<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>*by the time
<civodul>so we'd probably need a statically-linked multipathd in the initrd
<civodul>and code to start it
<rekado>I see.
<civodul>ideally we'd restart it after switch-root though
<civodul>we can probably ignore that for now
<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>will do that now
<rekado>building a statically linked variant seems challenging; maybe we can do without as many inputs
<janneke>civodul: this is what strace -f looks like after a while:
<janneke>any hints on strategic `pk' places?
<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>"guix graph gcc-mesboot" i presume
<rain1>do you know how to address the error?
<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>(source (origin
<grafoo> (method url-fetch)
<grafoo> (uri "")
<grafoo> (sha256
<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`
<rekado>what does $PWD contain?
<grafoo>the scheme file for the package and right next to it is the patch file.
<rekado>can you show us the full file?
<rekado>it needs to be a Guile module
<grafoo>it is.
<rekado>so it needs to have a module definition at the top, and the module name needs to match the file name.
<grafoo>that's the complete file.
<rekado>is the file name “my-packages.scm”?
<grafoo>also building python-clustershell works fine.
<rekado>what’s the error you get then?
<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: no.
<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>try “guix build -S perftest”
<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!
<dustyweb>hello #guix
<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>for guix package -u
<ecbrown>guix package -u is going about its business, so no matter
<jonsger>with guix pull you should get rid of the problem. That's the commit fixing it:
*ecbrown had to give up on guixsd on 15inch macbook pro, though it runs great on macbook air 11, even camera works
<ecbrown>damned radeon
<grafoo>rekado: my bad. i didn't get that the include was not only in the header file.
<rekado>no worries!
<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.
<Sleep_Walker>jonsger: OK, I'll check
<Sleep_Walker>I switched to GuixSD completely already
<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>there is no other mechanism.
<rekado>a related feature is graph rewriting.
<rain1>that's great, i was able to pull and reconfigure and stuff after guix gc
<rain1>but how do i get ssh back?
<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.
<rain1> i hadn't changed my config
<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
<jonsger>stage0 on HN:
*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>jonsger: \o/
<civodul>OriansJ: that compiler is truly impressive
<janneke>civodul: ahhh, good!
<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
<civodul>but it's probably won't be trivial
<rekado>embedding a statically linked multipathd in the initrd probably also won’t work.
<rekado>it cannot be statically linked
<roptat>hi guix!
<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 :-)
<roptat>ah, good idea :)
<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
<ecbrown>ok, thanks.
<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 or have a way to search for the last build of package X ? it seems to just be by commit
<amz3>awesome news indeed
<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
<ecbrown>yeah julia is a killer
<amz3>julia the language?
<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
<ecbrown>suit yourself
<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
<ecbrown>that would be sweet!
<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>can you telnet localhost 22
<ecbrown>have you herd start ssh-daemon
<rain1>great! i'm in, thanks
<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....
<ecbrown>fixed it by rearranging my .bashrc
<ecbrown>gotta put export's at the top
<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
<rain1>but i got a lot of errors about source file newer than compiled and then this
<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.
<lfam>Any pointers, rekado?
<rekado>in the past it was enough to install gstreamer plugins, but this no longer seems to be the case.
<rekado>I don’t know why.
<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
<snape>oh, good
<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>Better late than never!
<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
<snape>ok thank you
<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>civodul: oh!
<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
<civodul>jonsger: awesome, thank you :-)
<civodul>that was fast!
<jonsger>when doing at work sure :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>janneke: ooh, good catch
<civodul>binutils is not grafted in current master, we should consider rebasing wip-bootstrap
<janneke>civodul: oh yes, we must do that
<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!
<lfam>That would be awesome!
<jonsger>I have no idea if they do something. We host a lot for opensuse, but I don't know about "foreign" FOSS projects