<Sleep_Walker>is there some hook, script or service to run shell scripts on boot? <mbuf>is there a wishlist or TODO for guix? <mbuf>never mind, I see a ROADMAP and TODO file <mbuf>1. where can I search for a list of available packages in guix? 2. where is the CI build server where one can see the log of the packages built? ***sveta is now known as svetlana
<rekado>I cannot build libsigsegv on i686 because of test failures. <rekado>and it seems hydra isn't responding. <mbuf>rekado, yes hydra.gnu.org is not responding *civodul was thinking the same thing <Sleep_Walker>civodul: I just spent some time to find #:initialize? lsh-service <Sleep_Walker>I agree with default value, but I'd use `#:initialize? #t' in system configuration example ***sveta is now known as svetlana
<oitofelix>Ludovic Courtès: oitofelix: just saw the announcement, congrats; you should try "guix import gnu ccd2cue" and submit a patch :-) <oitofelix>Ludovic Courtès: Thank you! Hopefully, I'll soon take the time to do just that. :-) <taylanub>oitofelix: does your IRC client somehow turn nicks into real names? :P <oitofelix>taylanub: Ouch... Yeah. I suppose ludo didn't get notified. :-P <civodul>Sleep_Walker: double-check the license text at the URL for x11 or expat in (guix licenses) <rekado>odd. I get *lots* of collision warnings as if I had two versions installed at the same time. <rekado>warning: collision encountered: /gnu/store/nm6348jxns67hlizfihgqmq0hkcl6flm-fontconfig-2.11.92/etc/fonts/conf.d/30-metric-aliases.conf /gnu/store/q97xk7wc4ssfffp0ry5z6s42blyyif7d-fontconfig-2.10.93/etc/fonts/conf.d/30-metric-aliases.conf <rekado>the problem disappeared after guix gc, but I still don't know how this could have happened. <Sleep_Walker>chm, they don't want me to have underscore in username @ fencepost... I feel like Bobby Tables <davexunit>hydra.gnu.org is down. I'm sure you've all noticed now. <sneek>davexunit, you have 1 message. <sneek>davexunit, nalaginrut says: yeah, I saw Carmack said so last night. Years ago I saw he tweet "Scheme has the challenge of getting your program to work." ;-P <davexunit>it's due to the VM's host, a server at MIT, going down <taylanub>davexunit: hidy, are you on linkedin? (there's dozens of David Thompsons) <davexunit>taylanub: but yeah, I have a very common name. <davexunit>I don't use linkedin because I'm opposed to their business practices <davexunit>Sleep_Walker: they're essentially spammers, for one. <davexunit>they recently closed their public API to build a higher wall around their garden <davexunit>a few years ago they had a major security breach and password leak <davexunit>that happened just before I was going to sign up, feeling it was necessary for my professional career. <davexunit>and it's never been a problem that I'm not on linkedin. <davexunit>I didn't even mention the obvious software freedom issues :) <Sleep_Walker>another topic - it would be nice to have possibility to search for file in package without installing it <davexunit>when you say 'install', do you mean 'add it to the store' or 'add to profile'? <davexunit>how could you possibly search for a file that isn't on disk? <davexunit>I don't like the idea of spamming a build farm with `find` calls <Sleep_Walker>davexunit: I'd rather build filelist.txt when the build is end <davexunit>well you could easily create a derivation that takes as input another derivation and computes a file with all of the file names in it <davexunit>seems messy to make a file list to be part of the package derivation <davexunit>I dunno, I guess I'm unconvinced of the usefulness and practicality of such a tool <davexunit>looks like apt-file downloads a list of *all* the files <davexunit>so the first difference is that in guix, the whole distro is buildable on your local machine <Sleep_Walker>davexunit: you don't want to build whole distro to find a file, do you <davexunit>but we'd have to get the nar archive for *each* package <Sleep_Walker>the most obscure solution I remember was Knoppix HTTP fuse :D <Sleep_Walker>implementation of random access fuse filesystem access on big files available through HTTP :D <davexunit>note that all of these ideas require reliance on a server <davexunit>our solution, should we have one, would work locally, too. <Sleep_Walker>with this information you could download list files using some name convention <davexunit>you *never* have to trust a build farm with guix <Sleep_Walker>the worst case you'll get from that is that you won't find your file <davexunit>any solution must work without using a server for substitutes <Sleep_Walker>if you take data from build farm you trust, it's still better than when you have nothing <Sleep_Walker>the only other solution I can think of is to store list of files as part of package description which make sense but is not practical at all <davexunit>looks like we've got some hardware failure on the server that runs hydra. <civodul>rekado: could it be that one of the fontconfigs is propagated in your profile from another package? <mark_weaver>rekado: for various reasons, including propagated-inputs, I find it best to upgrade all packages in a profile together <mark_weaver>otherwise you can end up with multiple versions of the same library in your profile <mark_weaver>suppose, for example, that two libraries A and B each depend on a third library C. <mark_weaver>now suppose that you upgrade library A but leave the old version of library B. <mark_weaver>and suppose that the newer library A is linked against a newer version of library C than library B was. <mark_weaver>so suppose you have A-2.0 that's linked against C-2.0, and B-1.0 that's linked against C-1.0 <mark_weaver>and now you try to build a program that uses both A and B. <mark_weaver>I think this would try to link in both C-1.0 and C-2.0, and I don't see how that can work. <mark_weaver>because of these difficulties, I usually upgrade everything in one atomic operation. <{0}grant>Hm, this new Guix install is trying to build everything from source. I think it timesout, when/after it does "substitute-binary: updating list of subsiutes from 'http://hydra.gnu.org'...". *{0}grant does a cost/benf analysis to see if it's worth building the base-system from source ... or just waiting a bit. :^P <mark_weaver>hydra will probably be back up long before you'd be finished building everything from source *{0}grant buys 60 more GB or RAM and 10 i7s. :^) <civodul>though-provoking and well written as usual <Sleep_Walker>I'd say that there even are openhardware options, but I never liked the quality and robustness <Sleep_Walker>it would be nice if some HW manufacturers create good case for open hardware in good quality <mark_weaver>Sleep_Walker: the Libreboot X60 and X200 are both quite good <mark_weaver>Sleep_Walker: what's wrong with the X60? too old for you? <fchmmr>If "portable" is more your thing, though, X200 is the most practical choice in libreboot at present. <mark_weaver>Sleep_Walker: well, if you don't mind Intel having back doors to your machine, then the X230 sounds great <fchmmr>Sleep_Walker, X230 has a ME, it's a backdoor. It's removed on the X200. <civodul>mark_weaver: i think that's because rms wrote the HTML by hand, ready for gnu.org, with relative links *civodul is somewhat concerned about hydra.gnu.org and the other VMs <jxself>I understand that there was a hardware failurre. <mark_weaver>civodul: yeah, sounds like a good guess. I wrote to both RMS and Wired about it <davexunit>working on the issue. not sure if the problem has been identified yet or not. <zacts>mark_weaver: hopefully they will fix it soon <davexunit>I told the folks at the FSF office, who may be able to get in touch with the editor faster. <rekado>re conflicts: I think this issue appeared after I installed xfce into an existing profile containing audio software. <mark_weaver>davexunit: sounds good. getting this fixed ASAP would be helpful. <davexunit>today is the day for all sorts of broken stuff, it seems. <mark_weaver>it's painful to think of the thousands of visitors who might have clicked on those links. <mark_weaver>(well, if you're needed elsewhere, best not waste time telling us the details :) <davexunit>and also trying to get stuff done for libreplanet <davexunit>small staff, a lot of work, a lot of onlookers. do the math. :) <zacts>hm.. I wonder if it would be difficult to port guix to the beaglebone black <jxself>Plus the new person they've not added yet... <zacts>mark_weaver: well I've got a bbb, just got it at my front door like 20 min ago <zacts>I would be more than interested to test guix out on it <mark_weaver>the main issue now is that we don't have any build slaves for our build farm, so no pre-compiled binaries for it (and it wouldn't be powerful enough to build the system itself) and a lot of packages may have become broken in the meantime because of the lack of continuous integration. <zacts>hm.. can I help with this in any way? <mark_weaver>but I've ported guix to armhf anyway, which includes the BBB <zacts>even if just testing builds? <zacts>I'm also getting a build server too. <zacts>and I could build within a beagle-qemu image <zacts>like jenkins or something perhaps <zacts>mark_weaver: can I contribute hardware? <davexunit>mark_weaver: do you of any powerful arm boards out there? I did a brief search and didn't come up with anything <zacts>davexunit: slackware arm does something for this <zacts>I can't remember how they do it <zacts>maybe I should contact those guys to see how they are able to sanely, or insanely, keep an arm build farm going <mark_weaver>okay, the main thing is that we need something that can be run without blobs <zacts>mark_weaver: yeah, well is it ok if bbb just has disfunctional hardware that we don't use, if it requires blobs? <zacts>I mean the bbb I think allows for networking / many things, other than the graphics card, to run without blobs <zacts>so I'm thinking it might work, but certain things like the graphics card we just won't support <mark_weaver>The BBB would be fine, if it had more RAM and a SATA interface <zacts>mark_weaver: what are the min RAM requirements you need? <zacts>let me check, but I think newer bbb acutally have 4GB <zacts>yeah, let me see if this would in any way be possible <zacts>I'll have to look more into it <zacts>but I'll do this and get back with you <zacts>I wouldn't mind contributing some hardware for this <zacts>and also I wouldn't mind contributing a hydra test farm, if needed. or any other testing I could do <mark_weaver>zacts: a suitable hardware donation would be most welcome! <zacts>cool, well I'll keep you updated with what I find <mark_weaver>zacts: but regarding the BBB, the other major problem is the lack of a fast disk interface. <zacts>mark_weaver: um.. bbb supports SD cards <zacts>or you can use the native flash <zacts>well you can also install onto the native bbb <mark_weaver>build slaves need a lot of disk, and it should be fast disk <zacts>but you won't have much storage that way, enough for all of the packages <zacts>hm.. I'll see about connecting another disk <zacts>although, that's not necessarily the fastest <mark_weaver>a decent build slave needs at least a couple hundred gigs of fast disk, preferably SATA <davexunit>I sure hope we can get the patchelf issue sorted out soon. I'm very excited to try out guix on my novena. <mark_weaver>I think the best approach for now is to incrementally remove uses of 'patchelf' from key packages. <mark_weaver>I can still successfully build full 'emacs' on armhf. <mark_weaver>but some of the other graphics stuff is problematic at the moment. <davexunit>I hope to help out in some capacity with arm issues in the future. <Sleep_Walker>mini netbook SHARP Netwalker, Sony Xperia Tablet Z, HTC Desire Z phone <mark_weaver>well, adding older versions of linux-libre to guix is not difficult <mark_weaver>though I don't know whether those machines can run blob free <zacts>mark_weaver: apparently the way other people are doing it <zacts>they are just cross compiling packages on x86 <zacts>you can't add SATA or more G of ram to the bbb <zacts>although, other arm boards have SATA <zacts>if you really want to do a native build <zacts>and apparently the packages built on those boards will work on the bbb <Sleep_Walker>it's built from custom kernel tree with really dirty hacks and very little work in vanilla <civodul>davexunit: ok, thanks for the update <mark_weaver>Sleep_Walker: custom kernels are also something we'll need anyway. For example, all of my non-Intel machines need patched kernels. <mark_weaver>however, in recent years I've made sure to buy only machines that can run blob-free. <Sleep_Walker>but SHARP is crippled by design (broken CPU without NEON) <Sleep_Walker>I haven't found much time on HTC and there was no decent phone related software <mark_weaver>at present, our armhf port doesn't require NEON, but I've been wondering if maybe we should change that. it's becoming common for optimized software (e.g. video codecs) to use NEON. <Sleep_Walker>and Sony Tablet - I'm working on that when I have enough time (which is not much often) <Sleep_Walker>wife is sick so I can provide just tiny hacks to some project (like Guix :) <mark_weaver>Sleep_Walker: I'm sorry to hear that :-( yes, definitely take care of your loved ones first. <Sleep_Walker>ad kernel - I can build custom kernel for Guix, but there is one exact spot I'd love to make configurable <zacts>so perhaps I'll look at more powerful boards for guix <zacts>and then if we can find one that will meet our requirements, I'll see if I can contribute <mark_weaver>our kernel package is not very flexible right now. we need a better way to provide alternative kernels with different version numbers, custom patches, and custom configs. <Sleep_Walker>gnu/system/linux-initrd.scm:228 - there is hardcoded linux-libre variable <mark_weaver>some of those hardcoded config variables are really needed for guix-daemon to work. *mark_weaver goes afk for a bit... <Sleep_Walker>I can set my own variable, but only with code change (which is not nice) <mark_weaver>of course the number of people working on free software is huge <mark_weaver>but the folks at the FSF work on the not-so-fun things that are important but wouldn't otherwise get done by volunteers. my hats off to them! <davexunit>"the researchers have sought to thwart the company’s attempts to provide mobile security to hundreds of millions of Apple customers across the globe." <davexunit>providing security through proprietary software? lol <davexunit>civodul: so the takeaway is that we can't even trust software made by people we trust? <civodul>davexunit: the interesting thing is that they modified Xcode <civodul>this is pretty much the "trusting trust" attack: everyone who compiles with that gets a trojaned binary <civodul>though i guess that's not enough because the OS supposedly makes run-time checks or restricts accesses to resources <davexunit>I wish I knew more about this stuff. people seem to discredit the "trusting trust" paper. <civodul>unless the OS itself is built with the broken Xcode <davexunit>people say things like ""Reflections on Trusting Trust" gets posted on HN regularly, and it's an interesting exercise, but you are far more likely to have an exploit hiding in plain sight in a compiler compiled from source once than you are to have one that only appears after multiple iterated compilations." <davexunit>and ""Trusting Trust" is over three decades old, and there have been numerous response to it in the interim, with lots of study." <civodul>the only response i know of is the one by David Wheeler <civodul>now, the attack itself is surely difficult to do in practice <civodul>but not impossible for these agencies <nully>still working on the physical host hydra is on. Good news: its not hardware <nully>bad news: its the network, worst news: its not our network <nully>shoud hvae it sortedin the next hour or so i wouldhope <nully>i amgoing ot upgrade some prartsof this machine while i a m on site and everything is already down hard <civodul>nully: ok, thanks for the update, and good luck! <nully>civodul: hopefully this is not fallout of some sort of attack <nully>and just a random network tech inthe middle of the night going `which cable? meh this one will be fine *yoink' <nully>it disabled ourmonitoring systems <nully>which i will have ot refine now x.x i didnt get a notice about this <taylanub>I'm trying to package s2tc, an optional mesa dependency, but it seems to require OpenGL headers to be built, meaning it's a circular dependency :\\ I think normally it's solved through the fact that mesa loads it dynamically, not requiring it be there at build-time, but how to solve that for guix? <civodul>taylanub: typically we would (1) build mesa without s2tc, (2) build s2tc with mesa from (1), and (3) build mesa with st2c <civodul>though that can only work if users of (3) don't end up with two copies of libmesa.so in memory <taylanub>so a mesa-without-s2tc package inheriting from mesa, used only to build s2tc and not meant for installation by users? <taylanub>and with the second line you mean I should check whether mesa is also a run-time dependency of s2tc, which would be a problem, right? it should only use the headers. <civodul>yes, it may be that (3) dlopens (2), which has (1) in its RUNPATH and marked as NEEDED <civodul>but hmm, maybe ld.so would not even try to load (1) <mark_weaver>civodul: to implement david wheeler's approach, we need to develop a way to produce Guix bootstrap tarballs by diverse means. <mark_weaver>it would also be good if we minimized our use of precompiled *anything*, using only true source code. <mark_weaver>e.g. always run 'autoreconf' ourselves, rather than using the stuff that upstream produced. *mark_weaver goes afk for a while <rekado>I'm trying to port a little offlineimap hook script to use the Guix python, but I'm failing. <rekado>Does this error mean anything to anyone here? <rekado>--> ImportError: could not import gobject (error was: '/gnu/store/vd8ij01bq08icp87bz5gs2v4bq53bls6-glibc-2.21/lib/librt.so.1: symbol __shm_directory, version GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference') <rekado>never mind. I just fixed it after realising that I screwed up my PYTHONPATH... <rekado>I should not be using ~ in the environment variable; using $HOME instead. <rekado>BTW: I find myself adding the following snippets to many non-trivial Python applications: <rekado>import site,sys\\nfor path in [path for path in sys.path if 'site-packages' in path]: site.addsitedir(path) <rekado>This hack goes through every path in PYTHONPATH and adds each directory as a "site". <rekado>This causes the *.pth file to be interpreted, resulting in more required paths to be added to the PYTHONPATH. <rekado>I found that I need this for my offlineimap script which uses python2-gnomekeyring (packaged, but not yet submitted to the ML); I also need it for Solfege which uses pygtk. <rekado>Both pygtk and python2-gnomekeyring have in common that their code is in a subdir of the site-packages directory, requiring a pth file. <rekado>I suspect that Gimp with Python scripting enabled will also require this hack as it depends on pygtk. <rekado>Currently, I'm patching the first Python file I encounter, but I feel that we may need a more general wrapper mechanism around Python rather than hacking up each application using pygtk or similar. <Sleep_Walker>hackers, how is it possible, that you don't have packaged cscope yet? <{0}grant>If so, I'm not shocked it's not packaged. <{0}grant>I haven't messed with indexing much generally though. <{0}grant>Sleep_Walker: Well, I'm still in the student/trivialities stage -- so I'm probably biased on that front then. :^) <rekado>wat? I only changed one new package and guix wants to recompile all the things. <rekado>I must have done something stupid. <Sleep_Walker>something is _very_ wrong with curl version we provide - it doesn't support HTTP :D <rekado>I already compiled everything earlier today. <{0}grant>rekado_: mark_weaver told me so, when I was unable to grab subsitutes earlier. <Sleep_Walker>it would be nice if the solver would be optionally more verbose <{0}grant>Oh, that's not it. I thought you "no it's not". :^P <rekado>I already have all the stuff on my machine. *{0}grant should probably nap. <rekado>after my change it wants to rebuild guile-bootstrap and everything. <rekado>oh, I think it's my earlier run of "guix gc" that got rid of all the beautiful build tools :-/ <rekado>guess I should just install them to my profile. <taylanub>can I query *why* a store object has another as a requisite? running ldd on all s2tc-installed ELF files, I don't see any of them link to anything in the mesa package, yet the mesa package becames a requisite of s2tc as per 'guix gc -R' <rekado>propagated inputs from an input of s2tc maybe? <taylanub>nope, mesa is the only input to s2tc ("mesa-without-s2tc" to be precise, which I just added) <taylanub>find /gnu/store/...-s2tc-1.0/ -type f -exec grep <hash_of_mesa_package> {} + # no output <taylanub>false alarm, I used a wildcard in the 'guix gc -R' call that included the 'mesa-without-s2tc' package itself :-) <mark_weaver>rekado: I've also wanted a way to run 'guix gc' without removing anything I would need to build things locally. <mark_weaver>I realize that what I want is to compute the set of derivations that would need to be built in order to build every package in guix (or maybe some subset that I specify), and then protect all of those from GC. <civodul>mark_weaver: i think "guix-daemon --gc-keep-outputs --gc-keep-derivations" does what you want <mark_weaver>you suggested that long ago, and I found it didn't do what I wanted. <mark_weaver>it saved things I didn't care about, and dumped things I did care about <mark_weaver>what I want actually requires information that the daemon does not have <mark_weaver>because it depends on the set of packages in my current guix tree <mark_weaver>basically, if I started from an empty store, and then asked guix to build every package there is <mark_weaver>then I want to protect every derivation and every store item that would be built <mark_weaver>and then periodically I want to update that list of protected items, based on my current tree. <mark_weaver>and of course, at any given time, I won't have all of those items in the store. <mark_weaver>so when items are added to the store later, they should also become protected if they would be in that list. <mark_weaver>basically, these are the things that are needed to have a usable 'guix gc' for someone who choses to build everything locally. <bavier`>"collect everything except what can be derived from the current package source" <bavier`>aha, license is in the readme. Just a bit frightened when all the usual places say "unknown" *civodul crosses fingers and mentally supports nully & co. :-)