IRC channel logs


back to list of logs

<Sleep_Walker>good morning Guix
<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
<Sleep_Walker>mbuf: 1. `guix package -s'
<Sleep_Walker>2. (but is quite sluggish)
<rekado>I cannot build libsigsegv on i686 because of test failures.
<rekado>and it seems hydra isn't responding.
<civodul>Hello Guix!
<mbuf>rekado, yes 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
<civodul>Sleep_Walker: yes, good idea
<atheia>morning all
<civodul>Sleep_Walker: done!
<civodul>hey, atheia
<Sleep_Walker>thanks, that was quick :)
<Sleep_Walker>and we saved tons of bug mails :b
<civodul>i can't even ssh into hydra, uh
***sveta is now known as svetlana
<Sleep_Walker>(guix licenses) doesn't contain MIT license...
<Sleep_Walker>how so?
<rekado>Sleep_Walker: expat. Or x11.
<Sleep_Walker>rekado: Are you sure about it?
<Sleep_Walker>maybe we could have alias for that then :)
<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
<oitofelix>civodul: ^ Sorry. :-P
<civodul>oitofelix: good ;-)
<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>how can this be?
<Sleep_Walker>it seems to be almost identical to Expat
<Sleep_Walker>only it is with link to :)
<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> 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
<davexunit>FSF sysadmins are working on it
<davexunit>apologies for downtime
<taylanub>davexunit: hidy, are you on linkedin? (there's dozens of David Thompsons)
<davexunit>taylanub: no
<davexunit>taylanub: but yeah, I have a very common name.
<davexunit>I don't use linkedin because I'm opposed to their business practices
<Sleep_Walker>davexunit: like?
<Sleep_Walker>taylanub: you're easy to find ;)
<davexunit>Sleep_Walker: they're essentially spammers, for one.
<davexunit>"so and so has invited you to linkedin"
<Sleep_Walker>well, I don't like this either
<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>once that happened I refused.
<davexunit>and it's never been a problem that I'm not on linkedin.
<Sleep_Walker>I still consider it as plus
<Sleep_Walker>for professional purposes
<Sleep_Walker>their emails are still easy to filter
<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'?
<Sleep_Walker>'add it to the store'
<davexunit>how could you possibly search for a file that isn't on disk?
<Sleep_Walker>like with apt-file
<davexunit>how does apt-file work?
<davexunit>I don't like the idea of spamming a build farm with `find` calls
<davexunit>if that's what would happen
<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
<Sleep_Walker>yes, it is possible, but is it nice solution as well?
<davexunit>seems messy to make a file list to be part of the package derivation
<Sleep_Walker>it doesn't need to be part of derivation
<Sleep_Walker>but it should be part of the build process
<davexunit>then it would be in a different derivation
<davexunit>I dunno, I guess I'm unconvinced of the usefulness and practicality of such a tool
<Sleep_Walker>I'm still not used to guile way of thinking
<davexunit>it's certainly possible to do.
<davexunit>looks like apt-file downloads a list of *all* the files
<davexunit>in the whole distro
<Sleep_Walker>with releases it is well possible
<Sleep_Walker>and keep in mind that the solution is old
<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>Sleep_Walker: *someone* has to
<Sleep_Walker>and hydra is doing that already
<Sleep_Walker>I mean, it can be part of metadata of nar archive
<Sleep_Walker>or separate file with the same hash
<davexunit>but we'd have to get the nar archive for *each* package
<davexunit>just to search for a single file
<davexunit>if the file list were in there
<Sleep_Walker>it depends on the mechanism...
<Sleep_Walker>I can do partial reads of big files too
<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>substitute-binary: updating list of substitutes from ''...
<Sleep_Walker>with this information you could download list files using some name convention
<Sleep_Walker>and then perform search locally
<davexunit>that still relies on the build farm
<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
<davexunit>substitution is an optimization
<Sleep_Walker>I don't agree
<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
<Sleep_Walker>local search is trivial
<davexunit>looks like we've got some hardware failure on the server that runs hydra.
<davexunit>will keep you posted.
<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
<davexunit>that's unfortunate
<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 ''...".
<mark_weaver>hydra is down right now
<{0}grant>Ah, okay.
*{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
<{0}grant>I'll probably just wait.
<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. :^)
<jxself>Nully killed it! :)
<davexunit>since some of us in here are interested in free hardware, here's a new article by RMS on the subject:
<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>davexunit: thanks for the link!
<mark_weaver>Sleep_Walker: the Libreboot X60 and X200 are both quite good
<mark_weaver>IMO anyway
<Sleep_Walker>X200 is
<mark_weaver>(or T60 / R400 if you prefer)
<Sleep_Walker>I used ThinkPad X60 for years
<mark_weaver>Sleep_Walker: what's wrong with the X60? too old for you?
<fchmmr>R400 is a really nice machine
<fchmmr>If "portable" is more your thing, though, X200 is the most practical choice in libreboot at present.
<Sleep_Walker>it's hard to get back from X230 :)
<mark_weaver>Sleep_Walker: well, if you don't mind Intel having back doors to your machine, then the X230 sounds great
*mark_weaver goes afk
<Sleep_Walker>It does not, of course
<fchmmr>Sleep_Walker, X230 has a ME, it's a backdoor. It's removed on the X200.
<Sleep_Walker>I know :/
<mark_weaver>davexunit: there's a broken link in that wired article. "Flash Player and Angry Birds" links to
<mark_weaver>davexunit: same problem with "the four essential freedoms" link. it goes to
<mark_weaver>actually all of the links to
<mark_weaver>that's a damn shame :-(
<mark_weaver>so many potential visits to, lost
<civodul>mark_weaver: i think that's because rms wrote the HTML by hand, ready for, with relative links
<civodul>but those links don't work here
*civodul is somewhat concerned about 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>civodul: nully is on site at MIT right now.
<davexunit>working on the issue. not sure if the problem has been identified yet or not.
<zacts>ah man
<zacts>mark_weaver: hopefully they will fix it soon
<davexunit>mark_weaver: thanks for noticing.
<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>yes indeed.
<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.
<davexunit>total chaos here.
<mark_weaver>davexunit: oh no :-(
<mark_weaver>davexunit: what else is broken?
<davexunit>some internal things
<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>a lot to do :)
<mark_weaver>davexunit: I'm glad the FSF has you on the team :)
<davexunit>thanks, I'm trying to hold things together!
<jxself>With duct tape and glue? :)
<davexunit>pretty much
<jxself>Oh, and gum too.
<davexunit>small staff, a lot of work, a lot of onlookers. do the math. :)
<Sleep_Walker>how small is staff?
<zacts>hm.. I wonder if it would be difficult to port guix to the beaglebone black
<jxself>They are:
<jxself>Plus the new person they've not added yet...
<mark_weaver>zacts: it's already done.
<zacts>oh really? :-)
<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
<davexunit>Sleep_Walker: the FSF has 13 employees
<zacts>like jenkins or something perhaps
<mark_weaver>we need a powerful ARM box to add to our build farm
<zacts>mark_weaver: can I contribute hardware?
<mark_weaver>one that doesn't require any non-free blobs
<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>let me look into 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
<mark_weaver>most distros don't care about that sort of thing
<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?
<mark_weaver>a build slave should probably have at least 2GB
<mark_weaver>preferably 4
<zacts>let me check, but I think newer bbb acutally have 4GB
<mark_weaver>I'm talking about RAM, not flash
<zacts>ah sorry
<zacts>yeah, let me see if this would in any way be possible
<zacts>hm.. mark_weaver
<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
<mark_weaver>SD cards are very slow
<zacts>ah I see
<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>you could use a usb disk
<mark_weaver>USB disks are also very slow.
<davexunit>SSD for /, big HDD for /gnu :)
<zacts>although, that's not necessarily the fastest
<zacts>ah yeah
<davexunit>>=7200rpm HDD, I would say
<davexunit>for a single disk setup
<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.
<davexunit>will I be the second user of guix on arm?
<mark_weaver>davexunit: maybe so! I could use help :)
<Sleep_Walker>my HW is too dependant on old kernel versions :'(
<mark_weaver>Sleep_Walker: what hardware?
<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>mark_weaver: well probably not
<Sleep_Walker>it's built from custom kernel tree with really dirty hacks and very little work in vanilla
<Sleep_Walker>and that applies to all 3 devices I mentioned :/
<civodul>davexunit: ok, thanks for the update
<mark_weaver>we need to do native compiles
<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.
<mark_weaver>(including BIOS)
<Sleep_Walker>all the devices I bought with chance to liberate them
<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
<Sleep_Walker>(maybe taking parts from Ubuntu phone can help now)
<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>np, that is not something I could change
<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)
<Sleep_Walker>hm, 13 people at FSF, I expected a bit larger staff :)
<Sleep_Walker>how much people is in FSFE?
<Sleep_Walker>looks like 9 full time employees
<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!
<civodul>"trusting trust" in practice:
<davexunit>civodul: oof
<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>and that can be undetectable
<davexunit>ah, I see.
<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>was about to say that :)
<civodul>to discredit it?
<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
<nully>kk that is all
<nully>bak 2 werk
<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 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>ok, will do
<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 would not even try to load (1)
<civodul>because they have the same SONAME
<civodul>well, you need to try :-)
<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>e.g. not requiring we start from Guix itself
<mark_weaver>I guess it wouldn't be too difficult
<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>but that's orthogonal
*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/ symbol __shm_directory, version GLIBC_PRIVATE not defined in file 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?
<Sleep_Walker>do you have some alternative I'm not aware of?
<{0}grant>Isn't that primarily used via Vi(m)?
<{0}grant>If so, I'm not shocked it's not packaged.
<Sleep_Walker>I use it with xscope.el
<Sleep_Walker>{0}grant: so what alternative do you use?
<{0}grant> ?
<{0}grant>I haven't messed with indexing much generally though.
<Sleep_Walker>I'll have a look
<{0}grant>But Global has been decent thusfar.
<Sleep_Walker>it's must for bigger projects
<{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.
<{0}grant>rekado_: Hydra is down.
<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>no. That's not it.
<rekado>I already compiled everything earlier today.
<{0}grant>rekado_: mark_weaver told me so, when I was unable to grab subsitutes earlier.
<rekado>it's not about substitutes.
<rekado>I know hydra is down.
<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>that's unexpected.
<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>and it's not a propagated one
<taylanub>find /gnu/store/...-s2tc-1.0/ -type f -exec grep <hash_of_mesa_package> {} + # no output
<taylanub>oh wait, I think I made a mistake
<taylanub>false alarm, I used a wildcard in the 'guix gc -R' call that included the 'mesa-without-s2tc' package itself :-)
<davexunit>mark_weaver: when we can run guixsd on novena, we should distribute an OS config with a basic software setup like
<mark_weaver>davexunit: absolutely, yes!
<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>civodul: no
<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
<civodul>maybe "guix-daemon --dwim"? ;-)
<mark_weaver>heh :)
<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
<civodul>what bavier did should help
<mark_weaver>basically, if I started from an empty store, and then asked guix to build every package there is
<civodul>i see
<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.
*mark_weaver goes afk
<bavier`>"collect everything except what can be derived from the current package source"
<bavier`>hmmm, unlicensed source...
<bavier`>aha, license is in the readme. Just a bit frightened when all the usual places say "unknown"
<civodul>good night/day!
*civodul crosses fingers and mentally supports nully & co. :-)