<marusich>Does Guix store source code for all the packages it knows about, or does it only download source code from other places (e.g., GNU mirrors) when it needs to (e.g., for building)? Another way of phrasing this is: if all the URIs in the package definitions are invalid, can guix build anything at all?
<gustawho>marusich: Surely I may not be the right person to answer this, but... Yes, Guix download the sources when specified (--fallback, afaik) from hydra.gnu.org and then builds the packages locally.
<mark_weaver>marusich: guix stores the SHA256 hash of the source code of all packages.
<mark_weaver>if you have substitutes enabled, then the sources will be downloaded from hydra like everything else.
<marusich>Do you mean that sources will be downloaded from hydra, or that packages' build artifacts (i.e., the substitutes) will be downloaded from hydra?
<mark_weaver>all derivations that hydra has been asked to build will be cached on hydra and will be downloaded from hydra if substitutes are enabled and network access is available. sources, like object code, are derivations.
<mark_weaver>and hydra is asked to build everything that hits the master branch of the git repository.
<mark_weaver>(and sometimes other branches as well if we ask it to)
<mark_weaver>sources are not fundamentally different from object code, as far as guix is concerned. they are both cached on hydra and available as substitutes.
<marusich>I see. So, a derivation is both an abstraction for the source of a package and also for its built output. And Hydra caches both. Is Hydra's behavior special in this regard? Can my own guix-daemon also cache these derivations, including the source?
<marusich>Maybe "guix-daemon" wasn't the right word to use; what I am curious to know is: could I theoretically treat my friend's guix installation (if she has run guix publish or something like that) like I treat Hydra, and get both sources and built derivations from there instead of Hydra or other places like the GNU mirrors?
<marusich>What about the situation in which there is a single version that, for unfortunate reasons, has more than one sha256 hash value in different substitute servers?
<marusich>E.g., I downloaded foo-1.2.3 and computed its hash as H, and you on the next day downloaded it also, but it had a minor tweak that the developers didn't think needed a version bump, so you computed a different hash H', but it has the same version.
<marusich>Probably unlikely since we'd both have to be packaging it at nearly the same time
<mark_weaver>marusich: that has happened a few times, and we generally complain to the upstream about it, update our hash, and sometimes bump the version number on our end even though they didn't upstream.
<davexunit>marusich: source code derivations, known as fixed output derivations, must be deterministic, so you don't have to worry about the reproducibility issue in this particular case.
<marusich>Have we ever run into a situation where two different packages A and B require two different versions of some dependency C in order to build successfully? In other words, a situation in which A and B cannot both be built successfully from any single version of C?
<davexunit>I haven't personally, but it's possible that it's happened before.
<marusich>I ask because it seems there is no way to specify the dependency versions to use when building a package; the package definition seems to just use the latest one (but I might be wrong about this)
<davexunit>in most cases I can't see such a thing working
<mark_weaver>so in such cases we have sometimes hunted upstream for unreleased patches to make a given piece of software work with the newer version of some shared library.
<mark_weaver>this was a problem with nettle. for a while we had nettle-3.x and nettle-2.x, and some other libraries would only work with nettle-2.x. we ended up patching things to work with nettle-3
<davexunit>marusich: it's important to understand that a Guix package object describes the *precise* dependency tree for it, unlike other package managers that do the thing you describe by just listing a package name and a version string.
<marusich>If, when I ask to build some package X today, it builds sucessfully, will the output be identical to the output when I ask it to build that package X a year later, even after many of its dependencies may have been updated?
<marusich>So, I can break a build of pacakge X by updating one of its dependencies, and yesterday even though "guix package -i X" worked, "guix package -i X" won't work, even though it's for the same version of X. Right? Have you guys run into that problem much?
<davexunit>the version of a package is just one small piece of information that determines its output
<marusich>so guix does not make an attempt to associate with a particular version of a package all of the versions of its dependent packages that it should use to build
<marusich>I'd like to understand. For example, in the definition of the autoconf package, I see the variable "perl" listed as an input. The precise version of "perl" used to build autoconf is not pinned, right? It may change from day to day
<davexunit>if the package stored in the perl variable changes, then yes the autoconf build will change as a result
<marusich>So, you've made the choice that you will not pin autoconf version 2.69 to a particular version of perl, and you will let the build of "autoconf version 2.69" today use version X and perl, but tomorrow it might use version Y of perl, and that might cause a breakage. Yes?
<davexunit>if the guix source code changes, then the build could perhaps be different.
<davexunit>if autoconf needed a special perl, we could write a package that handled the special needs.
<marusich>I think that's what I mean. If somebody tomorrow updates the perl variable so that it is now building a more recent version of perl, then a request to build autoconf version 2.69 will use that new version, right?
<marusich>There are clearly benefits to doing it that way; you stay up to date as dependencies change. You don't have to micromanage all the packages to keep them up to date. And broken builds will be detected sooner and probably easier to fix.
<marusich>The downside is that what I built today may not be the same as what I built tomorrow
<marusich>I'm curious to know if this was a conscious choice made after considering those trade-offs, or if this is simply the way things happen to be right now
<davexunit>if you want to perform the exact same build, you need to use the same version of guix to do so.
<marusich>I have seen build systems that attempt to do basically that, and they are brittle.
<marusich>I agree with you; I think that it makes sense not to pin the dependencies to specific versions (in the way I have described - I understand that the package object you get on the day you decide to build happens to have a specific version associated with it) because it's untenable. I wanted to understand if the guix devs had considered the alternative, and it sounds like you have
<marusich>There are downsides, but it seems to me that they're probably not as bad as trying to pin everything down
<marusich>I wonder if we will be able to keep all the packages successfully building as more and more are added, though.
<marusich>Thank you for entertaining my questions.
<mark_weaver>marusich: I didn't read everything above, but I'd like to point out that if you build and run 'guix' from a git checkout of its source code, then you can precisely reproduce builds made at any point in the past by checking out an old version from git.
<mark_weaver>so, if you take care to record the git commit id when building software that you'll want to reproduce later, then you can always go back to it.
<marusich>That's true. In effect, the git commit acts like a version of the collection of the packages at that point in time.
<marusich>It builds, but those tests fail, and in fact running "guix package -i foo" fails sometimes with the same reason
<marusich>It's very strange. I'm not good enough at guile (yet!) to debug it deeply
<mark_weaver>hmm, interesting. can you email email@example.com and mention that you also have the same problem? and please mention that you are building from git source, and mention which distro and version you are doing this on.
<davexunit>marusich: is your distro Gentoo by any chance?
<Digit>"waiting for partition 'root' to appear..." is repeating upon my first rebooting into fresh installed guixsd. n it has put me in a guile prompt
<Digit>ctrl d out of it brought me to a kernel panic.
<Digit>looking in the edit of the grub, n it's very different to what i'm used to. i see no mention of root being sda6. was it supposed to figure that out, or is this something i'm supposed to manually do for it?
<Digit>sorted it now. just wondered if that was expected normal behaviour, or i had neglected to complete a part of the install correctly.
<Digit>also... G-oh-oh-oh-orgeous login screen. very encouraging. who's the artist? i tip my artist cap in your direction.
<Digit>also, *ahem* ~excuse this little outburst, but...~ FEEEEEEEEEEEEEEEEEEEEEEEEELLLS GOOOOOOOD! :) WHEEEEEEEEEE! YEAAAAHRGH! :) ... v happy fells from guixsd.
<civodul>it takes several weeks to get a reply to one message, and an unknown number of round trips to set it up
<rgrau>hi guix. When I install some package for root user, and I want to access it via sudo, it doesn't pick the .guix-profile path . how can I make sure that when sudoing it searches the root's guix paths?
<taylan>I think it's an interesting idea and might be worth trying out once it exists for Emacs, but I doubt it can improve substantially beyond paredit. I don't really feel any problems with indentation at all in paredit. hitting M-q is not that hard. :-)
<rekado>there's also lispy; the only thing that kept me from trying it out is that vi-like hotkeys are uncomfortable in dvorak.
<rekado>lispy is like paredit, but it doesn't require the modifier keys whenever point is at the beginning of an s-expression.
<Digit>ACTION likes bedrock, tho that may not work with guix sd yet.
<civodul>Digit: isn't Bedrock a standalone distro?
<Digit>into which you can put many other distros in. n this latest version to be released (expected end of the year) lets you hijack other distros to get that defining bedrock feature (any packages from any distro) anywhere* *(caveat for nixos/guixsd/gobo)
<Digit>my previous bedrock installs have typically had gentoo, debian, slack and arch in them. maybe eventually i'll have guix sd in there too, maybe even hijack my guix sd. but for now, they're separate things. :)
<Digit>with bedrock it's a cunning work around. with guixsd, i hope to be on a path of learning and empowerment such that i'd know how to package and debug and the rest. use is configuration is coding. :)
<marusich>mark_weaver, I tried reverting those 5 commits you suggested (to try and figure out https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21925 ), but when I do that, a similar problem occurs. Instead of getting an error message, the package command seems to just hang forever with "looking for the latest release of GNU gcc..."
<marusich>Oh, I see that Ludo provided a patch that might address the issue, also. I'll give that a shot!
***davi_ is now known as Guest39799
<bavier>anyone using guixsd with multiple monitors?