IRC channel logs

<mbuf>does guix have support to run Docker?

<mbuf>how about VirtualBox?

<mark_weaver>it's not packaged yet, but I wonder, is it free software? I see that in Debian it is in 'contrib', not 'main'.

<mark_weaver>do you know why that is?

<mark_weaver>we have qemu packaged

<mbuf>mark_weaver, there is a Free Software version

<mark_weaver>why is it not in debian main?

<mbuf>mark_weaver, I guess I need to learn packaging for guix, so I can contribute the packages that I need

<mbuf>mark_weaver, let me check

<mbuf>mark_weaver, https://packages.debian.org/wheezy/virtualbox

<mark_weaver>"It is in the "contrib" area of the Debian archive because it requires a non-free compiler (Open Watcom) to build the BIOS."

<mark_weaver>We cannot add VirtualBox to Guix for that reason. It would steer users to use non-free software which violates the requirements of the GNU FSDG <https://gnu.org/distros/free-system-distribution-guidelines.html>

<mark_weaver>mbuf: ^^

<mbuf>mark_weaver, thanks!

<mark_weaver>np!

<mbuf>mark_weaver, should docker be fine then?

<mark_weaver>I'm not aware of a problem there, but I know almost nothing about Docker.

<mbuf>mark_weaver, I see the package list here, http://www.gnu.org/software/guix/package-list.html, it will be good to have a list that states why certain packages cannot be included

<mbuf>mark_weaver, so people will know the problem with the software and what needs to be done to liberate them

<mbuf>mark_weaver, might also save you some time having to repeat the above reply if another person asks the same question

<mark_weaver>docker is included in trisquel, so that bodes well

<{-}grant>For hardware donations, should I make my 1tb drive the root partition I'm guessing?

<mark_weaver>{-}grant: I don't understand your questoin

<mark_weaver>*question

<mbuf>mark_weaver, https://docs.docker.com/installation/debian/

<mbuf>mark_weaver, okay

<mark_weaver>mbuf: I don't think we should be advertising non-free software in our package list

<mbuf>mark_weaver, sorry, I meant to maintain a list on why the software is non-free

<mbuf>mark_weaver, at least people will learn the reason why it is non-free, and if possible, can contact the authors for a Free Software license or alternative

<mbuf>mark_weaver, just a suggestion

<{-}grant>mark_weaver: I'll ask again, if I don't figure it out on a night of sleep. No need to bother, now that I think about it, when it's probably just an issue with sleep deprivation.

<mark_weaver>mbuf: so far I have spent almost no time fielding such questions, but it might be worth considering if it becomes more of a burden :)

<mbuf>mark_weaver, sure

<mbuf>mark_weaver, can you please point me to any documentation on packaging Free Software for guix?

<mark_weaver>such a list would not be specific to Guix though. such a list would be applicable to all FSDG-compliant distros. the fact that the FSF doesn't already maintain such a list makes me suspect that they consider it counterproductive.

<mark_weaver>mbuf: see our home page http://gnu.org/s/guix which links to our manual https://gnu.org/s/guix/manual/ and these slides of a tutorial: https://gnu.org/software/guix/guix-ghm-andreas-20130823.pdf which are slightly out of date but still mostly right.

<mark_weaver>also feel free to ask questions here on channel. most guix packagers started out with lots of help here.

<mbuf>mark_weaver, thanks!

<mark_weaver>np!

<abnegate>i'm having locale-related issues after installing weechat through guix

<abnegate>when i run weechat, i get these errors: http://okturing.com/src/2748/body

<abnegate>oops, make that LANG = "en_US.UTF-8"

<abnegate>anyway, i tried running "sudo dpkg-reconfigure locales" and selecting en_US.UTF-8 and setting that as the default

<abnegate>but it didn't help

<abnegate>i'm also getting the same error when i run urxvt, which i also compiled through guix

<abnegate>neither the original urxvt nor the original weechat that i got through debian's native package manager gave me these problems before i uninstalled them an reinstalled them through guix

<mark_weaver>you need to set the LOCPATH environment to point to your locales. on Debian I guess maybe that's /usr/share/locale ?

<abnegate>yeah

<abnegate>but "export LOCPATH=/usr/share/locale" doesn't help

<abnegate>also, for some reason both of these programs worked fine before i installed them through guix.. so i have a feeling it's guix-related

<abnegate>is it possible that they're looking somewhere in /gnu/store for locales?

<abnegate>btw, i tried installing "glibc-locales" through guix after i ran in to this issue, and it didn't help either

<mark_weaver>if you installed 'glibc-locales' in your profile, then export LOCPATH=$HOME/.guix-profile/share/locale

<mark_weaver>if LOCPATH is not yet, then Guix-compiled programs will look for locales in /run/current-system/locale which is only available on a GuixSD system.

<abnegate>hmm.. "export LOCPATH=$HOME/.guix-profile/share/locale" didn't help either

<mark_weaver>can you run the program in 'strace' to find out what's going on?

<abnegate>yep, i'll try that

<mark_weaver>fwiw, my LANG=en_US.utf8

<mark_weaver>I'm not sure if the .utf8 vs .UTF-8 might be causing a problem or not.

<mark_weaver>(but then, I'm also running on GuixSD)

<mark_weaver>(I'm presuming that you launched the program in question from the same shell where you set the environment variables)

<abnegate>i tried "en_US.utf8" too

<abnegate>didn't help

<abnegate>and i guess i was wrong about uninstalling the original urxvt that i got through debian's own package manager

<abnegate>it's still there, and i can run both the original urxvt and the guix urxvt, and only the guix one exhibits this problem

<mark_weaver>presumably the debian glibc is built to look for locales in /usr/share/locale if LOCPATH is not set. Guix does not look there.

<abnegate>and i think it's the guix perl that's the problem

<abnegate>when i run the guix perl from within the /gnu/store, i see the issue

<abnegate>both weechat and urxvt load perl, i think

<mark_weaver>this is a shot in the dark, but you know that environment variables are passed from parent to child processes, right? so if you export a variable in one shell that has no effect on other sibling shells.

<abnegate>right

<abnegate>when i was experimenting with setting environment variables, i always did it in the parent shell, before spawning child urxvt, weechat, or perl processes

<abnegate>so the env vars were inherited by the children

<mark_weaver>we have a lot of users who run Guix on top of Debian, including me (on my MIPS and ARM machines), and I haven't had this problem.

<abnegate>looks like perl's looking in $HOME/.guix-profile/share/locale

<abnegate>looks like it also looks in /gnu/store/wiqbxcvzj3r35hd55yxzz919b1dv1hnv-glibc-2.21/share/locale/locale.alias

<abnegate>which does not contain any en_US* locales

<mark_weaver>but it should have found them in $HOME/.guix-profile/share/locale, yes?

<mark_weaver>or /usr/share/locale if you set LOCPATH to that

<abnegate>here's the strace: http://okturing.com/src/2749/body

<mark_weaver>my locale.alias does not have any en_US locales either

<mark_weaver>abnegate: you ran "guix package -i glibc-locales" ? I think that /home/me/.guix-profile/share/locale/en_US.UTF-8/LC_IDENTIFICATION should exist

<mark_weaver>abnegate: does "guix package -I locales" show that you have installed it?

<abnegate>there's no en_US.UTF-8 (or any other en_US*) in $HOME/.guix-profile/share/locale

<abnegate>the only "en_*" is an "en_GB"

<mark_weaver>what is the output of "guix package -I locales" run from user 'me' ?

<abnegate>glibc-locales 2.21 out /gnu/store/cgwlkh0bz5swb4ahnnrdvcg951flvksg-glibc-locales-2.21

<mark_weaver>I am currently downloading the glibc-locales package to see for myself.

<mark_weaver>(I don't actually use that package, instead I use the GuixSD mechanism where I specify the locales I want, and it builds just those)

<abnegate>btw, if i "export LANG=en_GB" and re-run urxvt, i still get the same error (only now it references "en_GB" of course)

<mark_weaver>ah, they're in lib/locale

<mark_weaver>so set LOCPATH=$HOME/lib/locale

<mark_weaver>sorry

<mark_weaver>so set LOCPATH=$HOME/.guix-profile/lib/locale

<abnegate>yay!

<abnegate>thanks, that worked

<mark_weaver>:)

<abnegate>here's a tricker one...

<abnegate>i need to use a program called "qjackctl" (which is a nice gui over the jack daemon).. but it's not part of guix

<abnegate>and the version of jack that comes with debian's pretty old, so i used guix to install jack, and then compiled qjackctl while pointing it at guix's copy of jack

<abnegate>but when i "export LD_LIBRARY_PATH=$(pwd):$LD_LIBRARY_PATH" and then run qjackctl, i get this error:

<abnegate>"qjackctl: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument"

<abnegate>from reading around the internets a bit, i gather that this is a problem with having more than one glibc on the same system

<abnegate>have you run in to this issue?

<abnegate>and is there any way around it?

<mark_weaver>you definitely cannot link together guix libraries with non-guix libraries into the same process

<mark_weaver>and that also means that LD_LIBRARY_PATH better only include libraries from Guix

<mark_weaver>if you are running programs from Guix

<mark_weaver>on my systems where I run Guix on top of Debian, I set my environment variables such that I'm *only* using Guix programs and libraries.

<mark_weaver>so the host system is only used for booting, system daemons, and maybe the X server.

<mark_weaver>what does 'ldd qjackctl' output?

<mark_weaver>ideally, you shouldn't have to set LD_LIBRARY_PATH to run qjackctl

<mark_weaver>did you install 'gcc-toolchain', or did you install things like 'glibc', 'binutils', and 'gcc' separately?

<mark_weaver>the reason I ask is that we have a package called 'ld-wrapper' which arranges to embed rpaths into programs and libraries that are linked, so that they can find their shared libraries when run without relying on LD_LIBRARY_PATH

<mark_weaver>and 'gcc-toolchain' includes 'ld-wrapper' and takes care that it takes precedence over the 'ld' that's in 'binutils'.

<mark_weaver>you should consider just adding qjackctl as a guix package.

<abnegate>hmm.. i think i just lost my network connection

<abnegate>i was wondering why it got so quiet in here all of a sudden.. :)

<abnegate>mark_weaver: could you repeat your last response, please? i'm afraid i may have missed it

<mark_weaver> https://gnunet.org/bot/log/guix/2015-03-24#T612233

<abnegate>whoa

<abnegate>that's way more than i saw

<abnegate>i only saw the first line of that

<abnegate>thanks!

<mark_weaver>np!

<abnegate>reading through it now..

<abnegate>if i don't set LD_LIBRARY_PATH, "ldd qjackctl" reports: http://okturing.com/src/2750/body

<abnegate>i did not install gcc-toolchain

<abnegate>i installed binutils seperately

<mark_weaver>when building package X, you need to ensure that package X's build system does auto-configure a mixture of code from Debian and Guix. you need to ensure that only components from one system get used.

<abnegate>and when i tried to install gcc, i ran out of memory and swap

<abnegate>only have 4 gigs of memory

<mark_weaver>you should "guix -i gcc-toolchain -r gcc binutils glibc

<mark_weaver>"

<abnegate>i'm afraid to try installing gcc again

<mark_weaver>what are you afraid of? what happened last time?

<mark_weaver>if you make a mistake you can always "guix package --roll-back"

<abnegate>i ran out of memory and swap

<mark_weaver>and that operation is just moving a symlink, btw

<abnegate>my system came to its knees

<mark_weaver>how much memory do you have? how much swap?

<abnegate>i had to kill guix to recover

<abnegate> http://okturing.com/src/2750/body

<abnegate>oops, sorry wrong link

<abnegate> http://okturing.com/src/2751/body

<abnegate>hmm.. i guess the tabs did not show up properly.. 4 gigs ram, 2.5 gigs swap

<mark_weaver>that should be plenty. it's more than I have.

<abnegate>hmm

<abnegate>weird.. wonder what happened

<abnegate>i had to kill guix to recover

<mark_weaver>I see what's going wrong with the qjackctl

<abnegate>maybe i'll give it another go, then

<mark_weaver>it's because it was built for the Guix libraries, but doesn't know how to find those libraries. instead it's finding Debian's libraries, which are not compatible

<abnegate>yeah

<mark_weaver>ld-wrapper would have inserted the rpaths so that it could find its libraries

<mark_weaver>using gcc-toolchain uses the 'ld' from ld-wrapper

<abnegate>i tried setting LD_LIBRARY_PATH=$HOME/.guix-profile/lib:$LD_LIBRARY_PATH

<abnegate>but then i got that "error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument" error

<abnegate>i'll try installing gcc-toolchain

<abnegate>btw, regarding what you said about "you should consider just adding qjackctl as a guix package"

<abnegate>what i'd said when my network died, before i realized it was: "so i guess when i build qjackctl i have to make sure it only links in guix libraries" "and probably the easiest way of ensuring that is by just writing my own guix recipe for qjackctl"

<abnegate>so yeah, i figured that'd probably be the case

<abnegate>i think i might need some more simple examples of guix recipes

<mark_weaver>it is problematic to build software in an environment that contains a mixture of Debian and Guix software.

<mark_weaver>it is okay to use such a hybrid for non-development purposes

<mark_weaver>but if you want to compile something based on Guix libraries, then you must ensure that nothing from Debian is picked up

<abnegate>i see

<abnegate>so what's a good place to take a look at some more simple guix recipes?

<abnegate>how do i actually download a recipe to look at?

<mark_weaver> http://git.savannah.gnu.org/cgit/guix.git/

<abnegate>thanks

<mark_weaver>clone it, look in gnu/packages/*.scm

<mark_weaver>and build it

<abnegate>so to build from a local package definition, all i have to do is type "guix build foo.scm" ?

<mark_weaver>abnegate: https://gnu.org/software/guix/guix-ghm-andreas-20130823.pdf might also be worth a look

<mark_weaver>abnegate: the best way is to add it to gnu/packages/*.scm in your git repo, on your own private branch

<mark_weaver>but another way is to put the *.scm file in $GUIX_PACKAGE_PATH and then "guix build <package-name>"

<mark_weaver>where <package-name> is exported from the *.scm file

<mark_weaver>'define-public' implies export

<abnegate>ok, cool

<mark_weaver>the nice thing about the git repo approach is that you can also make arbitrary changes to any part of guix, and yet easily rebase your locale changes onto our upstream (or merge our upstream into your branch, if you prefer)

<abnegate>i think i'm going to have to read over that pdf and the guix docs again

<abnegate>and then read over your suggestions once more

<abnegate>to fully understand them

<abnegate>thank you

<mark_weaver>okay, happy hacking!

<abnegate>:)

<abnegate>in the meantime, i just installed the gcc-toolchain

<abnegate>and going to try just building qjackctl as is

<abnegate>hmm..

<abnegate>$ guix --help package

<abnegate>guix: unrecognized option '--help'

<abnegate>Try `guix --help' for more information.

<mark_weaver>abnegate: can you send a quick email to bug-guix@gnu.org about it? just those three lines would be sufficient

<abnegate>will do

<mark_weaver>thanks!

<abnegate>np

<abnegate>when i run "jackdbus" it complains "jackdbus: error while loading shared libraries: libjackserver.so.0: cannot open shared object file: No such file or directory"

<abnegate>but "libjackserver.so.0" is in ~/.guix-profile/lib

<abnegate>also "ldd ~/.guix-profile/lib/libjackserver.so.0" shows only libraries within /gnu/store and all of them are found

<mark_weaver>what does "ldd jackdbus" show?

<abnegate>hmm.. it does show that "libjackserver.so.0 => not found"

<mark_weaver>so there's a missing rpath

<abnegate>full ldd output here: http://okturing.com/src/2752/body

<abnegate>i don't need to add anything to my LD_LIBRARY_PATH, right?

<mark_weaver>you shouldn't have to, if the rpaths are set correctly

<mark_weaver>you could use LD_LIBRARY_PATH to paper over the problem for now though

<mark_weaver>I wonder why that rpath didn't get picked up

<mark_weaver>ld-wrapper should have taken care of that automatically

<abnegate>hmm

<mark_weaver>but sometimes the build system does something unusual that prevents that from working.

<abnegate>maybe i need to reinstall jack2

<abnegate>because i installed it before i installed gcc-toolchain

<mark_weaver>in some of our packages, we have to explicitly specify LDFLAGS=-Wl,-rpath=/gnu/store/.../lib to configure or make

<mark_weaver>abnegate: ah yes, that could be!

<mark_weaver>that would make sense

<abnegate>there's not "guix package --reinstall" is there?

<mark_weaver>what would that do?

<abnegate>uninstall and reinstall, but without messing with dependencies

<mark_weaver>both the packages and the profiles are read-only immutable store items

<mark_weaver>there's no mess to clean up

<mark_weaver>(assuming that you don't become root and modify things in /gnu/store, but if you do that everything will break badly anyway)

<abnegate>i see

<mark_weaver>your profile is also an immutable tree of symlinks in /gnu/store

<abnegate>btw, i'm getting tons of collisions when i install or uninstall anything

<mark_weaver>each generation of your profile is in a different directory

<mark_weaver>that's normal

<mark_weaver>obviously it would be good to avoid that, but there's a lot of important work to do on guix, and at the moment that's pretty far down our priority lists

<abnegate>well, i just removed and installed jack2, and jackdbus still gives me the same "libjackserver.so.0: cannot open shared object file: No such file or directory" error

<mark_weaver>but of course we are all volunteers, so if someone were to be motivated to fix it sooner rather than later, so much the better! patches welcome :)

<abnegate>yep, i hear you

<mark_weaver>abnegate: none of the packages in guix need to be fixed

<mark_weaver>the problem is in your jackdbus package

<abnegate>jackdbus is a program in the jack2 guix package

<mark_weaver>ah!!

<abnegate>sorry, should have made that clear

<mark_weaver> http://bugs.gnu.org/20039

<mark_weaver>sorry about that

<mark_weaver>so it would be easy to apply a suboptimal fix, namely to pass LDFLAGS=-Wl,-rpath=/gnu/store/.../lib to 'configure', but really we need to investigate what went wrong to make a *proper* fix.

<mark_weaver>a related question is: how is it that the package author didn't notice these problems?

<mark_weaver>maybe they did their testing in an environment with LD_LIBRARY_PATH=$HOME/.guix-profile/lib

<mark_weaver>so they wouldn't notice these problems.

<abnegate>i just tried setting my LD_LIBRARY_PATH to that, and it does seem to fix this issue

<mark_weaver>we should investigate the feasibility of adding a phase to gnu-build-system that checks for these problems

<mark_weaver>anyway, I must sleep now. good night!

<abnegate>thanks for your help!

<abnegate>and have a good night

<Sleep_Walker>are nar archives somehow signed?

<Sleep_Walker>can we distribute binary archives to mirrors and verify they are identical?

<Sleep_Walker>(good morning guix! :)

<Sleep_Walker>I'd like to ask our local university which already does mirroring for various linux distributions and major open source projects whether they could mirror it as well

<Sleep_Walker>they should have both space and capacity to host it

<Sleep_Walker>can that work on pure HTTP/FTP protocols?

<Sleep_Walker>is hydra ready for mirroring?

<rekado>I'm the author of jack2. libjackserver.so.0 is installed to .guix-profile/lib, but jackdbus does not contain the rpath to this library. At that time I must have had some environment variable set. I'll take a look at how to fix this.

<rekado>(personally I just use jack1)

<Sleep_Walker>no, Paul Davis is author of Jack

<civodul>Hello Guix!

<Sleep_Walker>morning

<Sleep_Walker>civodul: I wanted to ask you about mirroring of hydra

<Sleep_Walker>is it possible to rsync from hydra? are nar archives signed? can pure HTTP/FTP be used for providing nar archives?

<Sleep_Walker>I was thinking that one local university is mirroring some distributions and open source projects in general

<Sleep_Walker>I could ask them to set up mirror for Europe

<Sleep_Walker>they usually have both capacity of storage and decent connectivity

<civodul>Sleep_Walker: the thing is that Hydra is very dynamic by nature

<civodul>so mirroring is not really an option

<civodul>what you could do is run Hydra at your university though

<Sleep_Walker>not my university and that is something more than usual

<Sleep_Walker>but I can ask anyway

<Sleep_Walker>hydra is very dynamic, but it depends on speed of transfers...

<Sleep_Walker>or you think that mere mirroring would eat too big part of bandwidth?

<civodul>i mean you would have to be mirroring almost continuously for it to be useful

<civodul>that would be better than nothing anyway

<civodul>but i'm not sure how to set that up

<civodul>you cannot rsync because the files served by Hydra are generated dynamically

<civodul>you could periodically do something like: guix build $(guix package -A |cut -f1)

<civodul>with substitutes enabled

<civodul>so you would end up populating the store of your machine from hydra.gnu.org

<civodul>and then if you run 'guix publish' on that machine, it's effectively a mirror

<civodul>but yeah, that's an unusual setup, compared to a regular mirror

<Sleep_Walker>are there different paths for packages which are being built and which are built already?

<Sleep_Walker>and I still miss confirmation, that nar archives are signed

<Sleep_Walker>I'll send an email to the people and ask whether is something like that possible at all

<civodul>the archives are signed yes, see "Substitutes" in the manual

<civodul>so you would end up signing them with a different key

<civodul>alternately, you could ask them whether they'd like to donate a build machine :-)

<Sleep_Walker>what is hydra HW?

<Sleep_Walker>number of CPUs, ammount of RAM, disk space occupied?

<Sleep_Walker>I wanted to have a look on hydra but it seems that either account or key is not there

<Sleep_Walker>(I don't know much about the gnu.org servers yet)

<civodul>hydra.gnu.org is actually a VM with 4 G or RAM and 640 G of disk

<civodul>but we'd need more RAM and disk and CPU

<civodul>(for the front-end)

<Sleep_Walker>ok

<Sleep_Walker>mail sent, we'll see how cooperative they can be :)

<civodul>nice, thanks!

<Sleep_Walker>patching service code is tricky - I brought my dmd to crash and kernel to panic :(

<rekado_>is it normal for the ATLAS tuning process to take several hours...?

<rekado_>I'm building ATLAS on a virtual machine with lots of memory and 8 CPUs.

<bavier>rekado_: yes, atlas can take quite a while

<bavier>I would personally prefer to use something like openblas or blis instead.

<rekado_>in principle it should be possible to swap out blas libraries. I would like not to use ATLAS in this shared environment at all, because the tuning is rather pointless when the library will be used on cluster nodes and workstations alike.

<Sleep_Walker>wow - percent counter for communication with hydra

<Sleep_Walker>nice

<rekado_>mark_weaver: my apologies for not responding any sooner to your mail about the build failure for julia on hydra.

<rekado_>the problem is in fact that it uses a tuned openblas.

<sirgazil>Hi. An Inkscape installed with apt-get finds custom color palettes in /usr/share/Inkscape/palettes, what would be the right location for an Inkscape installed with Guix?

<davexunit>sirgazil: $your-profile/share/Inkscape/palettes

<davexunit>perhaps a search path is needed to make it work

<sirgazil>davexunit: Thanks, Inkscape already loads palettes from there, no need to set paths.

<sirgazil>But I had to add the palette as root, is that normal? I thought I had write access to my guix-profile (or I'm confused)...

<davexunit>sirgazil: well, you shouldn't touch the files in your profile

<davexunit>are they owned by root?

<bavier>the palattes directory in your profile is probably a symlink to /gnu/store

<davexunit>yeah

<bavier>which would be owned by root

<davexunit>so looks like sirgazil corrupted his store a bit

<bavier>I got patch-and-repack to work with zip archives

<bavier>unfortunately, my package's zip doesn't have a top-level directory

<bavier>and patch-and-repack currently insists on descending into the first directory it can find

<davexunit>ah, it's one of those "tarbombs"

<bavier>:P

<bavier>I was thinking we could do something more adaptive, in terms of directory switching

<sirgazil>davexunit: This is my profile: lrwxrwxrwx 1 anonimo anonimo 58 feb 27 13:36 .guix-profile -> /usr/local/var/guix/profiles/per-user/anonimo/guix-profile

<bavier>e.g. try applying the patches in the cwd, and only if that fails descending into directories

<davexunit>I think it would be better to detect a tarbomb and create a root directory for it, instead.

<davexunit>since the vast majority of source tarballs are made correctly

<bavier>davexunit: that would also be useful for later 'guix build -S'

<davexunit>yes

<rekado_>has anyone attempted to build openblas yet? On my virtual server it fails with "ar: sgemm_kernel.o: No such file or directory" :-/

<Sleep_Walker>I'm fighting a bit with my patch - http://sprunge.us/ThcO - it doesn't seem to be doing _anything_ (but seems to work outside of dmd)

<Sleep_Walker>can you see something wrong? (besides my style)

<rekado_>maybe the problem with openblas here and on hydra is that both machines are virtual machines.

<rekado_>I'll set a particular CPU type on my VM and try rebuilding openblas.

<rekado_>(ATLAS is still busy tuning itself... 6 hours and counting.)

<rekado_>when I add "DYNAMIC_ARCH=1" to the make-flags of openblas it actually builds even on the VM.

<rekado_>it actually builds modules for all CPU types that can then be switched at runtime with environment variables.

<rekado_>neat.

<bavier>rekado_: interesting, I didn't know openblas had that feature

<rekado_>I'll propose a patch to the ML.

<rekado_>in this case it would be substitutable.

<civodul>davexunit: http://media.libreplanet.org/ seems to only have the 2014 videos, or am i missing something?

<davexunit>civodul: we are working on getting the 2015 videos up

<davexunit>it will take some time for us to post-process and transcode and stuff

<davexunit>I'm currently trying and I suck at video processing :)

<civodul>ooh ok, np

<civodul>i thought the latest message about LP said they were ready

<davexunit>we made a blog saying to expect 1 to 2 weeks.

<civodul>i guess i didn't pay enough attention to the wording :-)

<davexunit>I somehow managed to transcode a keynote into a file that was bigger than the original...

<davexunit>ugh

<civodul>heh

<civodul>shouldn't Mediagoblin take care of everything? :-)

<davexunit>I'm not eager to upload a 3.6gb video right now.

<davexunit>and I need to do some trimming to get *just* the keynote part

<civodul>right

<davexunit>I did a rough cut just to get a smaller video file from the main master copy.

<davexunit>let's see if I can get it today :)

<remi`bd>hi! is there anyone currently working on “Supporting binary package distribution through GNUnet” ?

<davexunit>remi`bd: referrring to the GSoC project? no, I don't think so.

<davexunit>are you interested? :)

<remi`bd>yep

<davexunit>remi`bd: great!

<davexunit>remi`bd: are you familiar with the process for applying?

<remi`bd>yes... well, I’ve sent a draft application for the DHCP subject on the guix mailing-list

<davexunit>oh, that was you!

<davexunit>okay then ;)

<remi`bd>yes ^^

<davexunit>you know exactly what to do

<davexunit>great

<remi`bd>thanks for your help :D

<davexunit>np!

<Sleep_Walker>what is #~(...) in scheme?

<davexunit>Sleep_Walker: that is special read syntax for Guix's "g-expressions"

<davexunit>check out the manual for an explanation of them

<Sleep_Walker>ah

<Sleep_Walker>thanks

<Sleep_Walker>that may be the problem of my attempt

<davexunit>yw

<remi`bd>well, it’s probably a silly question, but how does guix handle different substitutes providing the same package?

<davexunit>remi`bd: I think some clarification is needed here, so let's work through it.

<davexunit>what do you mean by "different substitutes"?

<remi`bd>hum

<remi`bd>well, let’s say I want to install Emacs; hydra provides a pre-built Emacs, but what if another server also provide a pre-built Emacs?

<davexunit>ah, okay. now it makes sense.

<davexunit>currently, guix only supports a single substitute server.

<davexunit>when guix supports multiple, I imagine it will just search in the order that they are specified when the daemon is started. that's just a guess, though.

<remi`bd>well, maybe it would not be suitable if substitutions were provided through peer-to-peer

<davexunit>yeah

<davexunit>I guess the point is, it could choose any of the servers

<davexunit>and it would be just fine

<remi`bd>yes

<davexunit>perhaps in a p2p system you'd want to balance downloads out

<davexunit>amongst all of the peers

<Sleep_Walker>I need to add some more code before #~(make-forkexec-constructor ...), can that gexp be returned as last part of (begin ...) block?

<Sleep_Walker>(I need to do something before start of service

<Sleep_Walker>)

<les>It would be nice if guix supported weighted substitute servers if it supports multiple.

*les also wants a pony.

<remi`bd>:D

<davexunit>les: that could happen.

<les>Well sure, but I don't feel comfortable saying crap like that without also a patch that says 'here's how I did it feel free to merge'

<les>otherwise I just feel like I'm begging hah

<Sleep_Walker>sorry, right now is pony the easier task

<davexunit>first step, get guix to support multiple substitution servers at all

<Sleep_Walker>second step, get another server :b

<les>This weekend I actually tried to a get a small build farm setup but alas my VPSs apparently have critical glibc calls disabled

<davexunit>just run 'guix publish' on your machines :)

<davexunit>(once my patches are merged, which will be soon)

<sneek>So noted.

<davexunit>okay sneek

<davexunit>u r funny

<Sleep_Walker>how can I persuade geiser to load some guix module?

<davexunit>add the path to the guix scheme modules to guile's load path

<Sleep_Walker>I tried (use-modules ...), ,use

<Sleep_Walker>ah

<Sleep_Walker>:E

<Sleep_Walker>thanks

<davexunit>note, that you'll want to modify 2 load paths.

<davexunit>one for the source files, one for the compiled files.

<davexunit>the shell env vars are GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH

<les>davexunit: do you have an overview or just the patches for guix publish around? Interested in seeing what it is and how it applies

<davexunit>les: let me pull up the ol' mailing list archive...

<davexunit>les: here's the thread https://lists.gnu.org/archive/html/guix-devel/2015-03/msg00508.html

<les>davexunit: thats super rad thanks

<davexunit>yw

<Sleep_Walker>isn't both environment vars something which should be exported by default?

<Sleep_Walker>IOW is there any reason to not set it or set it differently?

<davexunit>Sleep_Walker: is this your development guix you're trying to use the modules of?

<davexunit>./pre-inst-env will setup the environment properly, in that case

<Sleep_Walker>no

<Sleep_Walker>I'm modifying the system directly

<davexunit>I'm not sure what you mean

<Sleep_Walker>I'm editing file /gnu/store/...-guix-.../share/guile/site/2.0/gnu/services/dbus.scm

<Sleep_Walker>in current profile it is the one which is part of system

<Sleep_Walker>and I booted some older system version

<Sleep_Walker>(pretty cool! :)

<davexunit>ohhhhh

<davexunit>neat

<davexunit>yay hackability!

<Sleep_Walker>I needed to deploy my changes somehow

<davexunit>oh wait, you're actually updating the file on disk? eek!

<Sleep_Walker>it's a bit faster than `guix system reconfigure'

<civodul>Sleep_Walker: you Should Not modify files in /gnu/store

<civodul>otherwise bad things will happen

<civodul>like you build a new config, and somehow some changes are not taken into account

<civodul>things like that

<civodul>the solution to your problem is to profile & optimize 'guix system reconfigure' :-)

<Sleep_Walker>civodul: ok

<Sleep_Walker>I'd like to try patch on dmd in less destructive way

<Sleep_Walker>and exec to new dmd instance would be also nice (and probably not that hard) feature

<Sleep_Walker>I'm still learning scheme though

<Sleep_Walker>civodul: and can you give me hint about http://sprunge.us/ThcO ? I'm fighting with that for hours and I can't even debug it

<Sleep_Walker>I tried methods I usually use - interpret the piece of code, add some debug printing

<Sleep_Walker>I tried even simple things like adding (when (file-exists? ...) (format #t ...))

<Sleep_Walker>when the file existed, it ended somehow leading to kernel panic thanks to dead init

<taylanub>mark_weaver: I couldn't find out much more than https://bugreports.qt.io/browse/QTBUG-45205 specifically I can't figure out how the presence of libxfixes/libxshmfence is even relevant. best I can think of is patching this in some hacky but straightforward way like adding an "#ifndef __glext_h_" around the two problematic typedefs.

<taylanub>*than what I describe in that bug report

<civodul>Sleep_Walker: ideally this is not how we'd address the stale PID file issue

<atheia`>,q

<civodul>:-)

<civodul>atheia live in a REPL :-)

<civodul>*lives

<atheia`>quite — don't know what went through my mind there :-)

<civodul>heheh

<atheia`>I'm kind of starting to live in gsd. It's bloody amazing!

<civodul>good to hear :-)

<atheia`>Switching to it full-time's definitely made the diff for me in terms of grokking it.

<Sleep_Walker>civodul: ideally it would be fixed already :b