<marusich>Huh...and it downloads the xcb-util-keysyms-0.4.0.tar.bz2, anyway?
<roelj>It tries to.. but the mirror links seem down
<marusich>Does the version of xcb-util-keysyms (shown by guix package --show=xcb-util-keysyms) match the version of your tarball? I don't know if that matters, but if they're not the same maybe that's why?
<marusich>Also, maybe try putting --with-source=... before the -i option? I don't think the order would matter, but maybe.
<roelj>marusich: efraim: I did 'guix gc -d `ls -d -1 /hpc/cog_bioinf/guix/store/* | grep keysyms`'
<roelj>marusich: efraim: Then I used --with-source=file:///...
<roelj>So it could be that the gc action actually removed the derivation that wanted to download it.
<marusich>The manual, as well as the test tests/guix-package.sh, suggest that "file://" is not required as a prefix when specifying a local file.
<roelj>So the problem is likely that when you start a build derivation, cancel it, and then restart it with the --with-source argument, the argument gets ignored because the derivation already exists?
<rekado>scipy fails because we ran out of space: guix build: error: build failed: cannot link `/gnu/store/.links/1m17f17gs7wgvwcq9l6j410v4sawnxw1nr03zgrzizg90jcp6fw0' to `/gnu/store/qwqpbfx4carmdq29ikwslq7m72qbiy09-python2-scipy-0.16.0-doc/share/doc/python-scipy-0.16.0/html/scipy.special.hyp2f1.html': No space left on device
<marusich>efraim, rekado, I was curious, so I checked. FYI the "file://" is not necessary because the code goes like this: transform-package-source (in guix/scripts/biuld.scm) -> package-with-source (in guix/scripts/biuld.scm) -> download-to-store (in guix/download.scm), where we special-case a normal path (without "file://") and invoke add-to-store directly using that path. But "file://" works too. So the manual and the test are correct.
<marusich>If anything, I suppose we should mention that you can specify a URI like "file:///foo/bar"
<jmd>Why does installing a package require building graphviz?
<marusich>I think it's hard to say why so many things were being built. But if you were changing the package definitions via git pull, it's possible that something changed deep in the dependency graph which triggered a rebuild of lots of things.
<jmd>In that case, somebody must have pushed to master what belonged in core-updates.
<civodul>obviously the question is who/what you want to protect from
<roelj>civodul: So multiple mirrors would work.. I proposed a plan for a build host at our HPC facility.
<htgoebel>civodul: I didn't take this to serious. But even if it a joke: Wehret den Anfängen (German proverb, according to leo to be translated with "nip things in the bud"). You never know when jokes start to become serious.
<davexunit>"I'm afraid it's a holy war (dare I say jihad?) and it will be hard to escape."
<davexunit>"There's little point in gathering metrics if they're disabled by default."
<davexunit>people always use this justification for opt-out tracking.
<OrangeShark>paroneayea: says that sponsors want hard data on usage numbers
<OrangeShark>"Anyone who's tried to raise money for Django knows this first-hand: potential sponsors always ask for data. When they hear that we have no hard metrics, their offers decrease (or vanish)."
<ng0> "Anyone who's tried to raise money for Django knows this first-hand: potential sponsors always ask for data. When they hear that we have no hard metrics, their offers decrease (or vanish)." I would want solid data for these claims
<paroneayea>davexunit: unfortunately I doubt jk-m would be sympathetic to our concerns... I think he gets annoyed with idealists
<paroneayea>he's also one of the most vocally anti-copyleft people around
<reirob>So far I managed to make guixsd work on a libreboot thinkpad x60s :-)
<reirob>It was compiling the whole night. Then I discovered that there is no VI editor so I added vi to the system config and started to do reconfigure and now it is again recompiling everything for 8 hours
<reirob>There is probably an easier way to do this.
<bavier>reirob: it shouldn't have to rebuild *everything*
<bavier>it should just build/substitute VI, then rebuild the os derivation
<bavier>but I need to figure out still how to get its database update to work
<dvc>civodul: why is the root file system read from the --root command line and not from the mounts list in linux-boot.scm? I'd like to mount a btrfs subvolume, so should I support a --root-flags or should I use the spec list?
<lfam>See all your team mates pretty faces on one screen as Sneek takes your photo at a regular interval (which you control). Yes, we all pick our noses, there's no shame."
<lfam>Great, now even when I'm alone I have to think about how I lookj
<jmd>What happens if you tell sneek to tell sneek something?
<dvc>sneek: later tell civodul why is the root file system read from the --root command line and not from the mounts list in linux-boot.scm? I'd like to mount a btrfs subvolume, so should I support a --root-flags or should I use the spec list?
<lfam>IMO core-updates is the place to make breaking changes and wait to see the result. So I would just do the simple update. We can fix the problems if they arise later, when we try building the branch.
<lfam>OTOH, if you know about specific issues, and you are willing to manage the extra complexity of multiple flex versions, I don't see the harm in doing that now
<ng0>does someone wnat to take on putting some finishing touches (substitute stuff) to an package for arm (the tor arm, not arm architecture)? I did something and realized later I have no intention to finish it
<sneek>civodul, dvc says: why is the root file system read from the --root command line and not from the mounts list in linux-boot.scm? I'd like to mount a btrfs subvolume, so should I support a --root-flags or should I use the spec list?
<buenouanq>wait, I just did a pull, but that doesn't on it"s own update anything installed does it?
<civodul>dvc: the reason is mostly that i thought it can be useful to change the root fs from the GRUB command line, and it's what's usually done