IRC channel logs


back to list of logs

***llida is now known as svetlana``
<jxself>"server is unresponsive"
<jxself>Seems to be the key part.
<jxself>Hydra often has problems.
<svetlana``>(and I'm not sure where it's saving the image file)
<svetlana``>should I ^C it and try again?
<svetlana``>1 more line, `substitute-binary: guix substitute-binary: warning: while fetching server is unresponsive`
<svetlana``>or i could try to use --no-substitutes
<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
<jxself>Try adding --no-substitutes?
<svetlana``>it means it'd compile things here, right?
<jxself>That is my understanding, yes.
<svetlana``>it says - 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``>hm, i guess i'll try it anyway
<svetlana``>tadni: here?
<tadni>svetlana``: Yes?
<svetlana``><svetlana``> it says - 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
<svetlana``> should probably reflect that (in light of a sysadmin dancing around while a computer is downloading stuff)
*tadni has been compiling for about 10 minutes.
<svetlana``>tadni: building it from latest git for 32bit?
<svetlana``>er, he quit
<svetlana``>tadni: building it from latest git for 32bit?
<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)
<waxysubs>have you built guix from git?
<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>Okay then, I'm on it
<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.
<Svetlana>mine craps out mid-download
<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: When compiling?
<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``>that is what I'm trying, yes
<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/ 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>.la files are text files
<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``>trying again
<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...
<Svetlana>going to sleep; it's still compiling
<tadni>paroneayea: Oh, howdy!
<paroneayea>heya tadni
<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>jxself: welllll yes/no.
<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>So you're a disembodied head?
<paroneayea>that would explain a lot, really :)
<jxself>Hopefully Guix packaging makes sense.
<paroneayea>jxself: are you a guix user presently?
<jxself>I started maintaining the kernel.
<paroneayea>oh great :)
<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
<paroneayea>whether it's a wrapper
<paroneayea>or if it reimplements the program
<jxself>Seems a little bit of both.
<jxself>I think that the stuff running came from there for example.
<jxself>But I don't think you need Nix to install Guix though if that's what you were wondering.
<paroneayea>gotcha, cool
<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 :)
<paroneayea>that might be too much NIH though
<paroneayea>we'll see :)
<paroneayea>yacc shaving
<paroneayea> ok, nix isn't required :)