***Guest75728 is now known as sturm
<sneek>me, baconicsynergy says: a joke <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. <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 <efraim>keeping up with jasper is driving me crazy <rekado_>the URLs for HTTP-Message have changed <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 <efraim>i've started using it on spinning drives since its much faster than running guix gc and then redownloading <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_>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 <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>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 <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 <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_>the error is "Can't locate TeXLive/TLUtils.pm in @INC" <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 <htgoebel>This does not look like being related to the python build system. <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_>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 <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>or remove the cached narinfo manually in /var/guix/substitute/cache <civodul>many things are going wrong today, and we all seem very confused as to what is really going wrong :-) <rekado_>sure enough: after removing the cached narinfos it's downloading the substitute. <civodul>FWIW i've started a yasm build with -s i686-linux to see what happens <rekado_>now it's building pandas from source :) <civodul>i was about to reconfigure bayfront but i apparently messed up with networking <civodul>i should have stayed in bed this morning, i tell you <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 :-( <rekado_>oh, does this mean that all python packages that provide scripts will be broken? <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 <htgoebel>Hmm, maybe I'm wrong. Can somebody please check In python-build-system.scm, function "wrap", where PYTHONPATH is set. <civodul>htgoebel: please take the time to investigate this <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>and then you can tell people about it :-) <roelj>Is there a way to only download the source tarball for a package? <roelj>Like guix download --source octave <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 <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>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?... <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 <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>ACTION pulls "copying and pasting from stack overflow" meme-book down from shelf <rekado_>buenouanq: puredata is available as “pd”. <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 ...' <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>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 <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? <daviid>i really rerally reallly dislike thism kind of s/w, my 2c <daviid>paroneayea: i tried and almost lost the control of my comnputer ... terrible <daviid>sorry! i've had a baf experience with it <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>I guess I need to provide the boot info somehow. <paroneayea>civodul: I did, though I think it won't boot so far <paroneayea> - checked out where the partition offset was in parted <paroneayea> - mounted a loopback filesystem with that offset specified <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>though admittedly I don't know how to extract it. <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 <civodul>reasonable guess, but maybe it's not that simple :-) <civodul>that's a case where we need help from The Internet <paroneayea>I'll send an email to... help-guix? guix-devel? the same thread I was on previously or a new one? <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 <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 <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>I didn't expect this to be such a rabbit hole though! <bavier>I've never seen a blog put a sidebar right over the scrollbar like that before <civodul>the HTML of that post is empty, it requires JS <ng0>nice. gnome just locked up my gpu oO <ng0>gitlab is a memory bloat