<lfam>cehteh: I don't know if they care which make is used. I'm building it with Guix's gnu-build-system.
<lfam>It would be good if the website's package list had an anchor link for each package name
<lfam>Are there any standard practices for creating a version-number for sources fetched from a git repo with no tags / releases? I see some packages in gnu/packages that use (string-append "0.0-" commit) and some that just use the commit.
<mark_weaver>I suppose if it is expected that the project will some day have versioned releases, maybe putting a "0." or "0.0." in front would be reasonable
<lfam>mark_weaver: That's good to know. What about making "git package -u" access the git DAG's logical history?
<lfam>Using timestamps is fine for now, but it would be nice to eventually make the guix tools use the canonical history from the source.
<mark_weaver>lfam: the git repo is not normally available, and cloning all the git repos and searching their history for commit ids would be prohibitively expensive.
<mark_weaver>multiply that process by the number of packages in the profile, which for me is about 150.
<mark_weaver>also, a human should be able to look at two version numbers and see which one is newer, IMO.
<lfam>mark_weaver: The manual says that using (git-fetch) clones the repo and checks out the commit specified in the package definition. Does the daemon not cache these repos like it does with source tarballs? As for the expense, I don't know one way or the other.
<lfam>fps: I meant that the .git directory with all of the repo metadata does not get stored
<Digit>"patching the XMonad source may be the only way" (from a nixos log). is there a fundamental difficulty in getting xmonad reconfigured past guix/nix package imutableness that means i need to create a guix package every time i want to change my xmonad configuration? ...or some simpler issue that will mean some day reconfiguring xmonad will be as simple as issuing "xmonad --recompile" ?
<civodul>Digit: i don't know the answer, but i think issues with xmonad configuration were discussed on the ML a few weeks ago
<Digit>yeah, just starting to read some of those from around october time. :)
<efraim>python2-zope-security failed to build on hydra, I have the fix locally, just waiting for my current builds to finish before I can test it
<taylan>civodul: working on the auto-compile solution at the moment. problem: how do I induce the auto-compilation without 'load'ing the files? (when I do that it means we still have the same problem of evaluating the top-level of many files twice.)
<lfam>efraim: It looks like the dependently built zope-testrunner can't find its own dependencies. It seems like another python-3 to python-2 translation error. Is that what you found?
<Digit>ACTION almost tried a kludge partial-remedy of ~/.guix-profile/lib$ ln -s ghc-7.10.2 ghc-7.8.4 before deciding that's silly, wont work, makes a mess, n instead he should just wait for better minds to tackle the xmonad issue
<fps>hmm, it would be nice if one could make "sudo guix pull; guix pull" an atomic operation
<fps>right now i have to maintain three guix'es to keep everything up to date
<fps>root's to reconfigure my system, my user's to get packages and my git clone to hack on things
<rekado>I want to test whether python2-matplotlib really needs numpy as a propagated input --- but I have to wait for texlive to be downloaded before I can test this.
<rekado>is anyone sitting on unfinished work to break up texlive into many little packages?
<cehteh>ACTION wonders if that really makes sense, yes its huge, but once you have it all it should just work and rarely gets updates
<cehteh>the only think i could imagine would be some texlife-lite for very small netbooks or so with just basic functionality, everyone else nowadays has prolly a few GB at spare to install the full thing
<rekado>we need to download it often, whenever an input changes.
<rekado>I've had to download it for about a dozen times on my machines since I started using it.
<davexunit>it's not as if we aren't aware of these things
<cehteh>at least the downloading .. imagine 1) round robin DNS to a few frontend squid proxy servers (hosted by the community) 2) this squids are configured in a hierarchy with a 2nd level of cachinng servers
<davexunit>fps: read more docs, the functionality is all basically the same
<davexunit>and the user can control the degree of isolation
<lfam>davexunit: Why do you think I was able to build the letsencrypt dependency graph but hydra could not? Is it because I already had all the zopes in my store from when I was building them individually during testing? Especially because there was a time when I used straight package-with-python2 for all of them, with any python-2 specific dependencies in the "main" python-3 recipe? (That was a stroke of laziness)
<davexunit>I don't know the details of why it happened here
<lfam>But this seems different. For these python packages aren't we basically just unpacking them? Is there any real compilation happening?
<lfam>And based on some other packages like python-pyopenssl, we could have guessed this would happen. Although the whole situation may be a bug, in this particular case it seems like a bug that it succeeded on our machines at all
<davexunit>lfam: we aren't just unpacking them, there's a whole build system for python projects
<lfam>Okay, I don't really know the details of how python software is compiled.
<davexunit>there's more to build systems than compilation
<lfam>I ask these things because after Efraim's report, I tried and failed to build python2-zope-security locally. But I could still build letsencrypt. It seems like the memoization is breaking down.
<lfam>That's true about the build system. I guess I am just able to imagine a million sources of non-determinism in C compilation but not in Python builds, because I have more experience with the former.
<davexunit>if it's true that letsencrypt builds but python2-zope-security doesn't, it means that the python2-zope-security used in the letsencrypt dependency graph is different than the one bound to the variable python2-zope-security
<lfam>Why do you say that? I could not build the dependency based on the current recipe, but I had a cached output of that recipe that the system was willing to use. So I never actually built based on that recipe.
<lfam>That is in response to your previous message
<davexunit>lfam: if it was changed, then it would be rebuilt.
<davexunit>guix isn't just going to use a previous build unless the hash of the derivation is the same
<lfam>That's what I thought. So I guess I did somehow successfully build that recipe, but it doesn't work in isolation.
<davexunit>what do you mean "doesn't work in isolation"?
<lfam>I mean that if I `guix gc`, and then `guix build letsencrypt`, joy! If I `guix build python2-zope-security`, it fails. I shouldn't say things like "in isolation" without being more explicit. I just meant that it fails on its own but not when part of a larger dependency graph.
<lfam>And that `guix gc` should work because I never put letsencrypt in a profile with this machine's store.
<davexunit>introducing something that users couldn't reasonably do themselves doesn't make me feel very comfortable
<fps>one question though: hydra builds packages one by one, too, right?
<lfam>I think this problem doesn't crop up that often. At a certain point we have to learn about the software we want to package. There is a whole class of software that doesn't really have a clear provenance and we have to hunt for the source. For example, libuuid is provided by util-linux. But if you google it, the linux.die.net manpage points you to e2fsprogs
<fps>so for every built package you can remember the list of files produces
<davexunit>fps: introducing reliance upon hydra is not something that I want
<lfam>Or, try fakeroot. AFAICT, the "canonical" source for fakeroot is a Debian developer uploading it him- or herself
<lfam>I want to print a list of package descriptions of everything that depends on util-linux. I know how to use recutils but I don't know how to make `guix package` print the dependencies. Anyone have a method for this?
<lfam>I think the output of guix graph is really not that good for this. It's only useful for piping into `dot`
<fps>true.. maybe a different output format for guix graph is needed
<efraim>gah. to update python-keystoneclient from 1.8.1 to 2.0.0 I have to add python-reno, which requires updating python-testtools, which requires packaging python-traceback2, and I've stopped there for now
<lfam>If you just want to clear the line and rewrite, you don't need curses. You can use ANSI shell escapes. In bourne shell it's 'printf "\\r\\033[K"'. Of course I have no idea how to do that in Scheme.
<lfam>That just erases the line so you can rewrite it.
<lfam>Which I think is preferable if there are no issues. A successful pass through the linter should leave no output except for a zero return status.