***llida is now known as svetlana``
<svetlana``>(and I'm not sure where it's saving the image file) <jxself>Yeah - 'server is unresponsive' :) <jxself>Hydra = Down, dead, gone, kicked the bucket, offline, disconnected.... um... what other words to use? :) <svetlana``>i have no idea what 'substitutes' it's looking for. substitute means 'something different from what we wanted originally' <jxself>It means you get a binary (downloaded from Hydra) instead of compiling it yourself. <svetlana``>ah, so if it's not giving errors then it means it succeeded building it itself? <jxself>The binary is 'substituted' for ths source, where you'd then compile it. <jxself>Does it keep on going and doing stuff? <svetlana``>it keeps spewing more of such warnings a little and doesn't say anything else <svetlana``>it says http://dpaste.com/1XH09SS#wrap - i could follow its instructions (enable it access to these dirs) except i wouldn't really like these packages /installed/ on this OS, as it already has them through another package manager <svetlana``>how can i make sure it uses that directory only to build things and it won't install them on this distro? <svetlana``><svetlana``> it says http://dpaste.com/1XH09SS#wrap - i could follow its instructions (enable it access to these dirs) except i wouldn't really like these packages /installed/ on this OS, as it already has them through another package manager <svetlana``><svetlana``> how can i make sure it uses that directory only to build things and it won't install them on this distro? <tadni>Hrm, if you are using the pre-inst-env, it shouldn't be trying to install to your host os. <svetlana``>ok, I've started then.. is there some means to revitalize hydra though? it looks useful -- compiling all the things by hand doesn't sound very exciting -- but the thing complains that it's unresponsive <tadni>svetlana`In regards to hydra, to my understanding the server has been maxed out and Ludo is waiting for the FSF to allocate more resources to them. He has a ticket put in to do this, but I'm not sure when this will actually be done ... so until this happens, expect hydra to be down/unresponsive ... which sadly means one has to build with substitutes. *tadni is currently building a disk image too now. :^) <svetlana``>it might make sense to sorta redistribute the processes (torrent download of installer, mirrors of the packages in each world region, etc) <tadni>svetlana``: There was recently a request from Ludo for someone to package hydra for use. That being said, I'm hoping the general process of implementing a mirror becomes relatively trivial. <tadni>I have an old/clunky box I can dedicate to be a mirror and would love to eventually. <tadni>Would make a horrible build farm, but it sounds like hydra can account for that and not use my box as such. <tadni>As just an always on mirror, yeah. it should be fine. <tadni>I'm hoping we eventually get a kind of archwiki like system for some stuff. <tadni>Like "how to deploy a mirror" or the like. I suppose most could be done via info though. <svetlana``>it's downloading stuff, didn't even start compiling *tadni has been compiling for about 10 minutes. <svetlana``>I'm considering stealing from you (downloading things on this wifi is a crap task) <DusXMT>I stumbled upon 2 packages which failed to build. One of them, gnunet-0.10.0, is not the newest version, and the newest version focused on bugfixing so perhaps I could try updating it by hand. <DusXMT>My guestion is, where should I put and how should I compile the package's .scm file? <DusXMT>just to be clear: the packages didn't actually fail to build, they build fine, but they fail their test suites (will report it on ML in detail if I don't resolve it) <DusXMT>waxysubs: No. I installed it from the 0.7 tarball, installed all the guix dependencies and installed it again, doing a `guix pull' at the end. <DusXMT>I guess I should try building it from git and using that instead <waxysubs>if you want to make local changes or contribute, building from git is the thing... <DusXMT>One more question: Do I need to remove the package definitions I fetched with `guix pull' earlier? <waxysubs>there was a post to the ML about upgrading gnunet, just before GHM, but it also failed some tests. <waxysubs>yeah, if you work from git, then you should remove that 'guix pull' directory, which is normally ~/.config/guix/latest <DusXMT>waxysubs: thanks a bunch, cheers <waxysubs>and also precede commands with ./pre-inst-env from the guix build directory, e.g. ./pre-inst-env package build -K gnunet <tadni>svetlana`I'm on x64, but mine failed to build too... so. <tadni>Once GNU distro hits beta tier, I'll probably host a whole bunch of download options for my "Emaculate" config file. <Svetlana>is it normal for it to spew out names of a lot of .c files on screen with no other info? <tadni>Svetlana: Yeah, it happens sometimes. <DusXMT>even the kernel does it. CC file.o <DusXMT>waxysubs: Yup, you were right, still fails <svetlana``>one would wonder how resuming the disk image build process after its fails due to crap wifi affects the result <DusXMT>svetlana``: The same command, it'll continue, afaik <svetlana``>"what were you doing this weekend?" "downloading free software" <DusXMT>apparently, the test suite's trying to access $(prefix)/share/gnunet/config.d, which should be at /gnu/store/yadayadayada-gnunet-0.10.1/../share/gnunet/config.d; while it should be searching for it in /gnu/store/yadayadayada-gnunet-0.10.1/share... <DusXMT>so bsically, there's an extra step backwards <DusXMT>It's a test suite problem, the test program implictly adds in a step backwards, which I think won't ever work (they probably didn't test it themselves) *DusXMT heads off to study Guix's documentation to figure out how to write patches for guix packages <svetlana``>stripping binaries in "/gnu/store/lwlpzapd30x5qcp03nl58lmhy0jxs8rp-gcc-cross-boot0-4.8.3/libexec" with "strip" and flags ("--strip-debug") <svetlana``>strip:/gnu/store/lwlpzapd30x5qcp03nl58lmhy0jxs8rp-gcc-cross-boot0-4.8.3/libexec/gcc/i686-guix-linux-gnu/4.8.3/liblto_plugin.la: File format not recognized <svetlana``>and some more dozens of messages about not recognised file format <svetlana``>it's a warning since it's not exiting? looks weird <DusXMT>svetlana``: it's a warning, and it's expected <DusXMT>they describe how to link with a given dynamic library <svetlana``>strip:/gnu/store/7lgqg1v32yjspmhrqzjwqagbg0vz2lpq-gcc-cross-boot0-4.8.3-lib/lib/gcc/i686-guix-linux-gnu/4.8.3/include/bmi2intrin.h: File format not recognized <DusXMT>and header files are text files as well <svetlana``>i know it's a header but like, not why it fails to recognise it <DusXMT>because strip works on binary files, it expects an ELF object but instead gets a text file <svetlana``>building of `/gnu/store/87mc6jkjb4cxy263mzwbw63gxwb66nkv-perl-5.16.1.tar.gz.drv' timed out after 3600 seconds of silence <svetlana``>not sure whether that's download phase or build phase, hmm <svetlana``>good luck with hydra eventually; I'd perhaps be interested in knowing how much space its mirror could need <DusXMT>was messing some more with the gnunet - was not able to get the test suite to work, this time test_gnunet_service_arm fails, and it doesn't seem to provide any details (the log files are empty, only mentioning that it failed) <DusXMT>strange, I ran make check-TESTS (as root, so that might be it) in src/arm, and all the tests passed... <paroneayea>I'm interested in guix but haven't had time to try it yet :) <tadni>paroneayea: Well, glad to see you're poking your head in here. :^) <jxself>Taking a break from MediaGoblin things? <paroneayea>I'm not installing guix right now, but I've taken a strong interest in how it describes its packages, and would love to test it out soon <paroneayea>right now I'm going through the debian packaging tutorial, making it easy to spin up virtual machines, and that *is* mediagoblin related, so I can work on improving deployability <paroneayea>but that's also had me curious how guix is handling packaging, hence me popping my head in here <jxself>Hopefully Guix packaging makes sense. <jxself>I started maintaining the kernel. <jxself>It was kinda easy, since I'm already doing that for my public APT repository. <jxself>And Guix needed a working kernel. <paroneayea>btw, does guix use nix right now? that's not clear to me <jxself>But I don't think you need Nix to install Guix though if that's what you were wondering. <paroneayea>jxself: there's another reason I might be interested :) <paroneayea>I might home-roll the deployment scripts for the "premium hosting" stuff for mediagoblin we're doing but use guile as a basis <paroneayea>so make a micro-deployment-framework, something along the lines of ansible/saltstack/etc but much simpler <paroneayea>but I'd want to see how something like guix works first :)