IRC channel 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

<efraim>:(

<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

<civodul>:-/

<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

<civodul>oh?

<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

<efraim>thanks

<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.

<civodul>rekado_: https://lists.gnu.org/archive/html/guix-devel/2016-11/msg01241.html

<rekado_>thanks

<rekado_>I'll take a look at ipython and sympy

<rekado_>FWIW: python-numpy fails :-/

<rekado_>during the install-doc phase

<civodul>ouch

<civodul>htgoebel: ↑

<rekado_>the error is "Can't locate TeXLive/TLUtils.pm in @INC"

<rekado_>TLUtils.pm 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 https://hydra.gnu.org/eval/109382?filter=numpy

<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

<civodul>*it

<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=https://hydra.gnu.org

<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

<roelj>ouch..

<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_>:(

<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

<htgoebel>:-)

<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 ;-))

<htgoebel>GTG

<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!

<davexunit>np

<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 tarballs.nixos.org 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> http://superuser.com/questions/1080245/xorriso-to-convert-raw-image-to-iso-fails-file-size-too-large 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>ok

<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>xorriso?

<paroneayea>ACTION lost

<daviid>sorry! i've had a baf experience with it

<paroneayea>oh ok

<daviid>baf/bad

<daviid>:)

<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 ...

<paroneayea>ok

<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>right

<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

<civodul>sure

<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> http://lukeluo.blogspot.com/2013/06/grub-how-to-2-make-boot-able-iso-with.html 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>:)

<ng0>just follow the white rabbit

<paroneayea>heh

<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