IRC channel logs


back to list of logs

***Guest75728 is now known as sturm
<baconicsynergy>sneek: tell me a joke
<sneek>me, baconicsynergy says: a joke
<baconicsynergy>good one!!
<baconicsynergy>u a sassy bot
<baconicsynergy>sneek: tell baconicsynergy that he's a loser
<sneek>baconicsynergy, baconicsynergy says: that he's a loser
<buenouanq>has anyone got spellcheck working in clawsmail on guixsd?
<buenouanq>none of the dictionaries I've installed show up
<bavier1>buenouanq: I've got the same issue; haven't bothered trying to figure it out yet.
<marusich>Has anyone seen an error like the following recently? "xgcc: error: unrecognized command line option ‘-marm’"
<sneek>marusich, you have 1 message.
<sneek>marusich, lfam says: Can you send a message to guix-devel about running on EC2? I'm interested
<marusich>I tried to build icedtea, and it failed because of that.
<bavier1>marusich: rekado fixed that recently, I think.
<janneke>morning Guix!
<marusich>Good morning!
<civodul>Hello Guix!
<csanchezdll>Hi civodul!
<thomasd>Hi #guix
<thomasd>I'm packaging `libksysguard', and some of the tests want to show GUI windows.
<thomasd>Currently, those tests fail with `QXcbConnection: Could not connect to display', is there a way to make this work, or should I disable those tests?
<thomasd>(I mean, they fail when the daemon builds the package)
<roelj>thomasd: That's unusual. Tests that show GUI windows? Should a user then interactively choose whether what he/she sees is correct?
<thomasd>they just spawn the windows and remove them. I'm not sure what exactly is being tested.
<thomasd>It's a KDE component, so it's not that surprising that they eventually test some calls to Qt.
<thomasd>the existing 'snorenotify' package seems to suffer form a similar problem, there tests are disabled with a comment `both tests fail, require display'
<roelj>thomasd: I think we can disable them.
<rekado_>has hydra stopped building things again?
<thomasd>roelj: thanks, will hopefully submit a patch shortly
<rekado_>oof, cannot build gcj now because HTTP-Message canne
<rekado_>*cannot be downloaded from CPAN
<efraim>keeping up with jasper is driving me crazy
<rekado_>the URLs for HTTP-Message have changed
<rekado_>will update them
<efraim>you're right, it has
<efraim>I didn't check that well enough yesterday
<civodul>rekado_: hydra has to stop regularly since a couple of weeks
<efraim>`guix build foo -S --check` isn't working for me to check the source urls of the packages I updated yesterday
<efraim>ERROR: In procedure open-file: Permission denied: "/gnu/store/r62hhdwn9pvkziwfa2gv4c2p0k1050hv-Email-Address-1.908.tar.gz"
<civodul>efraim: "-S --check" doesn't make sense in general because there's nothing to check
<civodul>that said, weird error!
<efraim>it redownloads the file
<efraim>i've started using it on spinning drives since its much faster than running guix gc and then redownloading
<civodul>indeed, i didn't know :-)
<civodul>how does this relate to GC though?
<civodul>"guix build -S perl-email-address --check" works for me
<efraim>I used to gc the source and then run `guix build foo -S --no-substitutes'
<wingo>ACTION looking forward to brave new build machine world
<efraim>here's what I was trying to run to check the sources of the perl files I updated `git log ee264bbf907f555a64d1832a02d9562b89cf2727 -n 37 | grep gnu\\: | awk '{print $2}' | cut -d':' -f1 | xargs ./pre-inst-env guix build --no-substitutes -S --check'
<civodul>wouldn't "guix lint -c source" work?
<efraim>yes, that seems to work better than my plan :)
<civodul>maybe you can do: guix lint -c source `guix package -A ^perl | cut -f1`
<efraim>i wanted to start with the ones I pushed yesterday since I forgot `guix import` adds the source to the store
<rekado_>even after rebuilding the daemon from latest master and restarting it I get the error "guix: offload: command not found"
<ecraven>I know I've asked this multiple times, but this really is something I'd love to have: if I provision a new VM with guixsd, how would I automatically put a few ssh keys into a user account's authorized_keys?
<civodul>rekado_: i suppose "guix offload" as root gives you that error, right?
<civodul>problem is a mismatch between the compile-time (offload hook can be built) and run-time ('guix offload' is missing) situations
<rekado_>I haven't used "guix offload" (I don't remember ever using it). The daemon runs as root (using "./pre-inst-env guix-daemon"), and on the same machine I do "./pre-inst-env guix build gcj" as a regular user.
<efraim>new gstreamer packages, thats always fun
<civodul>rekado_: the daemon invokes "guix offload" (as root) when it thinks it is available; the problem here is that it is not available in practice
<civodul>rekado_: could you investigate why "guix offload" as root doesn't work? could be missing guix/scripts/offload.scm, missing Guile-SSH, etc.
<rekado_>looks like it's because Guile-SSH isn't available.
<rekado_>in strace I see it looks for ssh/key in various directories
<rekado_>guix/scripts/offload* exists
<rekado_>is Guile-SSH a mandatory dependency?
<civodul>no, but again, if it's available at configure time, then the daemon considers that 'guix offload' is available
<civodul>so yeah, just "guix package -i guile-ssh" as root and you should be done
<civodul>sorry for the mess!
<rekado_>no problem, will install guile-ssh
<rekado_>ah, right, the latest guix package propagates guile-ssh, so it's available at configure time when configuring in "guix environment guix"
<efraim>do we actually have to install guile-ssh as root, or is it enough to use the daemon from a guix built in the past day or so?
<htgoebel>Hi guix,
<htgoebel>I apologise with the mess I made with merging python build system too early.
<htgoebel>I'm working myself through the failing packages, but how should I test them quicky? Some are not failing here or are fialing only on some platforms.
<roelj>htgoebel: It should've been tested on a separate branch.
<roelj>How's the new machine coming along? We could use it to help speed up the rebuilding of the python packages..
<civodul>roelj: mainly we need to add the Cuirass service to its config
<civodul>htgoebel: the failures that were reported on the list seem to be platform-independent
<civodul>efraim: the "guix-devel" package currently dates from before the guile-ssh thing
<civodul>though i'm planning to update it
<rekado_>are there any big problems (other than the yasm failure on i686) since the change to the python build system?
<civodul>Danny listed a few failures on the mailing list
<civodul>nothing really serious it seems
<rekado_>haven't received that email yet, but I'll take a look when I do.
<rekado_>I'll take a look at ipython and sympy
<rekado_>FWIW: python-numpy fails :-/
<rekado_>during the install-doc phase
<civodul>htgoebel: ↑
<rekado_>the error is "Can't locate TeXLive/ in @INC"
<rekado_> is part of texlive-bin
<rekado_>but that's not on the PERL5LIB path for some reason.
<rekado_>hmm, some of the commits are a bit messy
<rekado_>e.g. 2efabc5589dc641dce75702b99253a3fb40bb2eb
<rekado_>a lot of (unrelated?) changes in one commit
<civodul>indeed, that's not OK
<htgoebel>This does not look like being related to the python build system.
<rekado_>yes, it's quite odd.
<htgoebel>rekado: Not that old, is is part of the patch series for the new python build system.
<htgoebel>But if it's a perl error it seem to be unrelated
<rekado_>I wonder at what point it broke.
<rekado_>I don't see anything obvious.
<htgoebel>And python-numpy did just build okay on the current job
<rekado_>well, I just tried to build it on my workstation and it failed. Strange.
<htgoebel>BTW: I'm looking at gtk-doc an calibre, both take a lot of time to compile the inputs
<rekado_>I don't get a substitute for python-numpy; it's still queued on hydra.
<htgoebel>ACTION is looking forward to have the stages change to set CTEST_OUTPUT_ON_FAILURE by default soon
<htgoebel>The package dblatex (which is a python program) seems to be broken, effecting others. I'm looking at it
<civodul>rekado_: apparently there's a substitute for python2-numpy on x86_64, but not (yet?) for python-numpy
<thomasd>htgoebel: ah, I was just wondering CTEST_OUTPUT_... isn't the default today :)
<roelj>Can I just mv a profile to another directory?
<roelj>And expect it to still work?
<rekado_>civodul: this is strange. I really cannot build python2-numpy.
<rekado_>I'm on d0b9c34fb3e7485e10538fe705fb9f94dae6f0fc
<rekado_>the build for /gnu/store/bls4m7fy8nqdr7y2q8b0kr0fkqrdjzpz-python2-numpy-1.10.4.drv definitely fails.
<civodul>roelj: i would no longer be a GC root
<roelj>civodul: And I see the symlinks for rolling back break
<roelj>civodul: Thanks!
<rekado_>the substitute must be for an older derivation
<civodul>rekado_: on that d0b9 commit, python2-numpy is available for x86_64; maybe your substitute cache is stale
<civodul>you can try --substitute-urls=
<civodul>or remove the cached narinfo manually in /var/guix/substitute/cache
<rekado_>oh, that's good to know
<civodul>many things are going wrong today, and we all seem very confused as to what is really going wrong :-)
<rekado_>yeah, sorry to add to the confusion
<rekado_>sure enough: after removing the cached narinfos it's downloading the substitute.
<civodul>pheww :-)
<civodul>FWIW i've started a yasm build with -s i686-linux to see what happens
<rekado_>now it's building pandas from source :)
<rekado_>let's see if that's going to work
<civodul>lots of fun!
<civodul>i was about to reconfigure bayfront but i apparently messed up with networking
<civodul>i can no longer reach it
<civodul>i should have stayed in bed this morning, i tell you
<rekado_>hehe, I feel the same
<bavier>rekado: sympy failure is because the package lacks python 3.5 support
<civodul>mark_weaver: both yasm and nasm build on i686
<civodul>so i wonder what it is we're talking about
<htgoebel>Oh, I found a annoying difference between old and new python build system: The scripts no longer contains a PYTHONPATH to the script's own package :-(
<htgoebel>Where are the scripts wrapped?
<rekado_>oh, does this mean that all python packages that provide scripts will be broken?
<htgoebel>rekado: I'm afraid, yes :-((
<htgoebel>I really wonder why this did not occur earlier
<rekado_>bleh, hope I can find a work-around for the shared environment we have here
<rekado_>upgraded too early
<htgoebel>Hmm, maybe I'm wrong. Can somebody please check In python-build-system.scm, function "wrap", where PYTHONPATH is set.
<htgoebel>ACTION is confused now
<civodul>htgoebel: please take the time to investigate this
<davexunit>how about reverting the build system?
<davexunit>this is too big of a break
<htgoebel>civodul: I simply do not understand this code. (I now remember why I did not like scheme when studying)
<htgoebel>Okay, I was wrong: The ols build system apparently added the packages site-package *twice*, while he new one adds it only once.
<civodul>htgoebel: by "take the time", i mean "don't comment in real time" :-)
<civodul>i know from experience that this is stressful
<civodul>so if you think there's a potential for breakage, just try to reproduce the thing before and after the merge
<civodul>see whether there is indeed breakage
<civodul>double- and triple-check
<civodul>and then you can tell people about it :-)
<civodul>(free advice ;-))
<roelj>Is there a way to only download the source tarball for a package?
<roelj>Like guix download --source octave
<davexunit>guix build -S
<roelj>davexunit: Thanks!
<roelj>I think I can host a tarball mirror, because I have a VPS with 'unlimited' network traffic.
<roelj>I'll see if I can run a cronjob to download all sources once a day or so.
<davexunit>rekado: I noticed that Ardour released 5.5, so I updated the Guix package recipe. the application boots, but I don't know much about Ardour to know if there are regressions
<davexunit>would it be okay to push the update?
<rekado_>davexunit: if it starts that’s good enough. Thanks!
<rekado_>davexunit: I checked for a new release just a few days ago; must have just missed it.
<rekado_>davexunit: there was one ardour releases which was quite unstable, but that’s rare. Looking forward to using the new version.
<davexunit>rekado_: I would like to figure out how to use all this stuff at some point. I finally live somewhere where I can setup a drum set again and I'd like to record some stuff.
<davexunit>it's nice to see so much gnu/linux audio stuff packaged :) thanks for that!
<buenouanq>no puredata yet though ( ._.)
<buenouanq>I should learn how to package things and help.
<[df]>ACTION has been intending to package supercollider for a while
<[df]>I think there was some weird problem with qt last time I tried
<buenouanq>why would sc have anything to do with qt?...
<[df]>it has a qt-based ui
<ng0>I have to revert part of eaa45301f46f13a3f71bcae6089d312f31174801
<ng0>while the application builds, I forgot (due to the lack of an issue tracker at the moment) that the change to a new pcre broke some parts of libpsyc which need to be fixed
<ng0>i'll send a patch for this as I have no clue if git revert would do what I want.
<catern>is there an equivalent of for guix? an HTTP mirror of all source tarballs? or does the default GNU mirror have those?
<ng0>okay apparently I added psyclpc already in this state.
<ng0>so I'll revert to the point where it was functional, although there are no users (yet) of it
<ng0>so this is not really an revert, I shall call it "downgrade psyclpc" and explain why
<paroneayea>hello #guix
<davexunit>rekado_: I hadn't pulled the latest from master so I'm currently rebuilding a good portion of the world it looks like.
<paroneayea>I feel like my path of least resistance for now might be to try the Vultr route with the iso installer
<paroneayea>so now to figure out how to convert the installer image to .iso
<paroneayea>if anyone has experience and knows what command to run with Xorriso, let me know :)
<paroneayea>otherwise, time to traverse the docs...
<paroneayea> seems to have some info, I guess I'll try that route
<paroneayea>ACTION pulls "copying and pasting from stack overflow" meme-book down from shelf
<rekado_>buenouanq: puredata is available as “pd”.
<buenouanq>oh wow
<buenouanq>thank you
<ng0>patch sent
<paroneayea>so if I'm reading that post right
<paroneayea>probably the best thing to do is to mount the usb image on a loopback
<paroneayea>and then run the xorrisofs command on it to generate the ISO
<jmd>Suddenly it seems that installing a package requires rebuilding *everything*.
<jmd>Building it doesn't just installing it. Why is that?
<reirob>Hello. I am about to install GuixSD on a Libreboot ThinkPad X60s and I think that I made a mistake. In /mnt/config.scm for file-systems I think that I put something wrong. But now I started the installation with "guix system init --fallback /mnt/etc/config.scm /mnt" and it runs. After this I am supposed to reboot. But I am afraid that the reboot will not work and I have to go again through everything (it runs for hours and hours already)
<reirob>. Is there a way in which I can correct my error before rebooting?
<bavier>reirob: ^C, edit config.scm, and rerun 'guix system init ...'
<bavier>should be fine
<reirob>Thanks bavier. I hope that it will not have to rebuild everything
<bavier>reirob: it shouldn't need to, the build results will still be in the store
<reirob>Good :-)
<reirob>Will continue reading through the documentation. This stuff is new to me
<bavier>reirob: good luck. just ask here if you have any other questions
<reirob>Many thanks. I appreciate that!
<paroneayea>anyone here have experience with Xorriso?
<daviid>a monster!
<paroneayea>is the best route to mount the disk image under a loopback before burning with xorriso, or is there some way I'm not seeing to just have xorriso use the disk image as a source?
<paroneayea>daviid: it sounds like one...
<daviid>i really rerally reallly dislike thism kind of s/w, my 2c
<daviid>i just hate it
<paroneayea>daviid: huh?
<daviid>paroneayea: i tried and almost lost the control of my comnputer ... terrible
<paroneayea>ACTION lost
<daviid>sorry! i've had a baf experience with it
<paroneayea>oh ok
<paroneayea>why, did it write to /dev/sda or something?
<daviid>paroneayea: I can't remember exactly, sorry
<daviid>but it was a bad experience, enough so I immediately uninstalled and I don't think i will try it again
<daviid>ther exact oposite philosophy of what a s/w app would be, should do ...
<bavier>otoh, paroneayea, I hope for your success! :)
<daviid>paroneayea: for example, it started to analize the content of mu HD without asking, that sort of thing ...
<bavier>I unfortunately have no experience with xorriso beyond reading the manual
<daviid>I'm sorry, i think i confused xorriso with another s/w with a similar name! terrible brown bag on me!
<daviid>ACTION hides before xorriso authors shoots :)
<paroneayea>well I *think* what I'm doing is working. Let's see.
<paroneayea>Writing to 'stdio:./guixsd-usb-install-0.11.0.x86_64-linux.iso' completed successfully.
<paroneayea>but will it boot? :)
<bavier>ACTION crosses fingers
<paroneayea>oh well
<paroneayea>I guess I need to provide the boot info somehow.
<civodul>paroneayea: sounds cool so far!
<civodul>did you use 'xorrisofs'?
<paroneayea>civodul: I did, though I think it won't boot so far
<paroneayea>here's what I've done:
<paroneayea> - snatched the guixsd boot usb image
<paroneayea> - unxz'ed it
<paroneayea> - checked out where the partition offset was in parted
<paroneayea> - mounted a loopback filesystem with that offset specified
<paroneayea> - ran xorrisofs like so:
<paroneayea>$ sudo xorrisofs -v -R -o ./guixsd-usb-install-0.11.0.x86_64-linux.iso /mnt/tmp/
<paroneayea>but I'm realizing I missed a step, because it needs boot info.
<paroneayea>-b iso_rr_path
<paroneayea>I think I need that flag
<paroneayea>though admittedly I don't know how to extract it.
<civodul>right, and the doc is horrid
<paroneayea>do I just dd out the part from the usb image that's everything *before* the first partition offset?
<paroneayea>civodul: yeah the xorriso docs are very confusing.
<civodul>no idea, i guess it needs to somehow embed the MBR that GRUB created
<paroneayea>I'm guessing the MBR is everything before the first partition
<paroneayea>but that seems like a heck of a guess
<civodul>reasonable guess, but maybe it's not that simple :-)
<civodul>that's a case where we need help from The Internet
<paroneayea>yeah I'll do some more searching
<paroneayea>I think I'm making progress though.
<paroneayea>I'll send an email to... help-guix? guix-devel? the same thread I was on previously or a new one?
<paroneayea>with the info
<civodul>i'm happy you're looking into it
<rekado_>found the reason why nginx didn’t quite work the way I wanted it to. After reconfiguring and restarting nginx it would just continue to use the previous nginx configuration.
<rekado_>I switched from “(plain-file …)” to “(local-file …)” and nginx just didn’t use the local file until after rebooting.
<rekado_>not sure if this is a bug or just a missing feature
<paroneayea> this article looks helpful
<ng0>what's up
<ng0>people working on making an iso?
<paroneayea>ng0: well, I seem to have fallen down that rabbit hole
<ng0>just follow the white rabbit
<ng0>I have recursive backups I'm fighting.. there's an backup in my backup in my backup in my backup ...
<paroneayea>where's the code that generates the bootable usb stick again? I know I've seen it
<ng0>gnu/system/gnu-system.scm or something
<paroneayea>ah that's it, thanks ng0
<civodul>along with gnu/system/vm.scm
<ng0>thanks for reminding me, I have to add that information to an issue for my project
<paroneayea>guix system disk-image --image-size=1G gnu/system/install.scm
<paroneayea>right, there we go
<paroneayea>this blogpost is pretty good
<paroneayea>I didn't expect this to be such a rabbit hole though!
<paroneayea>so it goes
<paroneayea>always expect a rabbit hole
<bavier>I've never seen a blog put a sidebar right over the scrollbar like that before
<paroneayea>bavier: it's very strange
<civodul>the HTML of that post is empty, it requires JS
<civodul>like Elm :-)
<paroneayea>civodul: eep ;)
<ng0>nice. gnome just locked up my gpu oO
<ng0>well, webkit
<rekado_>can git be used with lsh?
<civodul>probably not
<ng0>gitlab is a memory bloat
<ng0>4GB requirement