<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>I see; that's nice. I've noticed that in emacs when I do, say, "M-x guix-search-by-name" and look for "autoconf", I only see "out" as an Output <marusich>I thought the source was supposed to be in a special "src" output or something? <davexunit>source tarballs and things have their own entries in the store <marusich>So, if I want to obtain the source for autoconf, but I don't necessarily need the built stuff, how do I get that? <davexunit>from the CLI, you can run 'guix build -S foo' <marusich>I see also that it's in the manual, in the Invoking guix build section; I think I just hadn't read this part yet. <marusich>So, even if the URIs in package definitions become invalid, as long as I can connect to some trusted substitute server, I can get the source, examine it, and build it if I want to, right? <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. <mark_weaver>also, we usually have the opportunity to compare the two versions and see how they differ. <mark_weaver>because hydra usually has a cache of the old version, and then we can download the new one separately. <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 <davexunit>marusich: the package objects have the version included <marusich>How do we deal with them? They seem likely to become more common, the more packages are included <mark_weaver>in the case of shared libraries, they can be very problematic, because it's generally not possible to load different versions of the same shared library into a single process. <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>And that is because X will use different dependencies, yes? <davexunit>assuming the build is deterministic in the first place, yes. <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 <davexunit>and yes, sometimes we update a package and see other packages break. <davexunit>well, each package associates with a precise version of its dependencies <marusich>sure, but that closure today will not necessarily be the same as it is tomorrow, if dependencies change, right? <davexunit>if the *variables* in the guix source code change <davexunit>that's the part that I don't think is being understood <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>since a package describes the full dependency graph, having each package contain its own, completely isolated graph would be insane. <marusich>Well, a single package would need only to state what package versions it depended on, precisely <davexunit>what dependencies are used to build the dependency? <marusich>that would be defined in the dependency's package definition <marusich>well, you don't store the exact package version, right? As previously mentioned, autoconf 2.69 is defined to depend on "perl", not on "perl 1.2.3" <marusich>right, but the version of that package object specifies a version that may change over time <davexunit>if autoconf needed a different version, we could make a different package object for it. <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>I guess what I mean is that guix seems to have chosen not to reify that concept, and I was curious to know if it had been thought about, and if rejected, why <mark_weaver>fwiw, I always run guix out of a git checkout. it's the natural thing to do as a guix developer, and also allows me to make arbitrary local modifications to guix on a private branch. <marusich>I am still having trouble building the darn thing :( I haven't found a single checkout for which I can run make check successfully <mark_weaver>well, git already does precisely the job, so I'm not sure why we would reinvent the wheel there. <mark_weaver>marusich: forget about older versions. use the latest 'master' from git and tell me what fails. <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 21925@debbugs.gnu.org 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? <mark_weaver>marusich: you might try reverting the following 4 commits and see if it fixes the problem: <mark_weaver>you'll have to revert this one as well, because it depends on the others: git.savannah.gnu.org/cgit/guix.git/commit/?id=bd7e1ffae6c91680e3328974f94c3ead8d2f378d <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. <Digit>probably 12 years to the day since i was smitten with gnu n picking my first distro. n now i'm smitten with guix sd, and am just as elated and smitten. :) *note to self: remember this moment* <mark_weaver>he made the web sites for both Guix and Guile vastly more beautiful than they were. we are very lucky that he came along :) <mark_weaver>and of course he did a bunch of other artwork for GuixSD as well <marusich>oops, didn't mean to send that a second time <Digit>first guix command i issue in my fresh system just to install fish, seems to be doing a lot. is it trying to recompile my entire system? <rekado>Digit: is it downloading source tarballs? <Digit>i presume so. looks like a lot of gcc action scrolling by at the moment. <rekado>check the output at the very beginning. <rekado>guix will tell you what it will build. <rekado>by default it should download substitutes. <rekado>only if no substitutes are available (or if you have passed "--no-substitutes") it will build from sources. <rekado>sometimes network issues lead guix to think that no substitutes are available. <lfam>Digit: When installing, did you do the step where you `guix authorize ...`? <Digit>i think i just "guix package -i fish". <lfam>How did you install Guix? <lfam>With the binary install, the source install, or the full OS (GuixSD)? <lfam>Or did you install it through your system's package manager? <Digit>fresh guix sd install following the guide and a little advice from here in #guix <lfam>Ah. I haven't used GuixSD. I wonder if it comes with the Guix build farm authorized to serve subsitutes. <lfam>Is there anything in /etc/guix/acl? There should be a public key in there. That key would authorize the use of binary substitutes from hydra.gnu.org. Without substitutes you compile everything. <Digit>yup, looks like an rsa public key is there. <lfam>Digit: Did you check the beginning of the `guix package` output? That should summarize what it wants to do. <Digit>i let it run. it's done now. ... n i'm probably too sleepy to safely meddle with things i dont know... even though it's guix and i could rollback. :) <Digit>i'll pick up the fun later when i wake up. will check my situation regarding substitutes n such. thnx for the help, gni. :) ~first time going to sleep as a guix/guixsd user.~ :) <efraim>Digit: was it the 0.8.3 install or the 0.9.0 install? either way the recommendation is to run guix pull as the first thing after installing <efraim>also, the 0.8.3 substitutes got garbage collected off the server <Digit>efraim: 0.9.0 guix pull : ERROR: In procedure getaddrinfo: Name or service not known ... n stuff. ~ okies, rly gone now, cant keep eyes open. <rekado>the eigen test failures on non-x86_64 bother me. I was given hints that I'll try on the tests soon. <civodul>the main author is in the office next door so i can see with them <rekado>it's been like this for a while. I've been meaning to fix this for some time, but never got around to it. <rekado>I remember that we had a build failure on i686 for a long time (about when I packaged guitarix). <rekado>the other two platform failures appeared somewhat later. <civodul>yeah i remember seeing it before, but i thought it had been fixed somehow <rekado>one person on #eigen said: "non-x86* is barely tested, so there could be some issues" <rekado>some tests time out, so the suggestion is to reduce their size by modifying DART_TESTING_TIMEOUT and EIGEN_TEST_MAX_SIZE. ***pyfgcrl is now known as botbottle
<civodul>yes, mark_weaver & i are looking into it <civodul>should be back up, but quite overloaded <civodul>mark_weaver created a 'security-updates' branch which i hadn't noticed because lists.gnu.org is lagging behind <rekado>civodul, mark_weaver: thanks for working on it! <rekado>my "guix environment --ad-hoc" broke :( <rekado>when I do "./pre-inst-env guix environment --ad-hoc ruby -- ruby" it just sits there and I cannot even abort it. <davexunit>I've definitely made that mistake a few times :) <rekado>it's been a long time since I did ruby stuff. <davexunit>I once had an argument on HN with someone espousing how superior a Ruby REPL called "pry" is compared to all other REPLs. <davexunit>I asked about how one evaluates an arbitrary block of code in a file, like lisp programmers often do <davexunit>and the response was basically "why would you want to do that?" <davexunit>the way to do it is to run a metacommand that *opens the file* in an editor subprocess, and re-evaluates *the entire file* when you exit. <rekado>select expression, copy, switch to REPL, paste...? <davexunit>I could not make this person understand that the proposed workflow was lacking. <davexunit>it seems that for every language that isn't lisp, "live coding" means "watching files for changes and re-evaluating them" <davexunit>which is a really bad approximation of live coding! <davexunit>if you need to involve the file system, then you are doing it wrong! <civodul>still no news re the Free Software Fund grrr <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? <rekado>this should keep the current environment. <davexunit>if you want to use the root user's .bash_profile and such, you need to use a login shell <rekado>but you could always do "sudo su -" <davexunit>environment variables will not be magically set <rgrau>I usually want to just run a single command as root... but at least now I can run the commands. thanks :) <taylan>rekado: I recently learned of sudo -i, which more directly does what sudo su - does <rekado>"sudo su -" is a deeply engrained habit for me. <piyo>alias sudoi="sudo su -" ? <piyo>Did you see the discussion on HN about that fancy parens editor aid? And then emacs semi-alternative adjust-parens-mode. Press Tab and the parens on other lines move for you. <bavier>piyo: 'parinfer' was mentioned here a few days ago <piyo>parinfer is not for emacs, iirc, its for atom? <bavier>yes, but there are ports underway <piyo>Adjust-parens works like the first animated repl box. <piyo>Oh the highlight part does not work in a-p <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. <piyo>I use smartparens after a bout with paredit. <ReactorScram>This is gonna sound dumb but Guix doesn't run on windows at all does it? <civodul>ReactorScram: no it relies on the GNU C library <ReactorScram>Okay. I was looking for a way to make an automatic updater for my windows application and I didn't write to write an ad-hoc package manager ***classieur is now known as cpjjl
<claa>Hi, I’m trying to install guixSD. installation hangs on ftp://ftp.mozilla.org/sth. It seems that ftp.mozilla.org with protocol ftp is down. How can I change it to http? <civodul>claa: are you using the GuixSD 0.9.0 USB image? <claa>well, actually I used --no-substitutes <claa>(maybe thats the problem…) <claa>because of network issues <claa>it may not have refresh some stuff? <claa>oh I should have read the doc about substitutes :) <civodul>claa: yes, you should leave substitutes enabled <civodul>the hydra.gnu.org server is often slow, but when doing a full install, it's best to use it <Steap_>which feels a bit gentoo-like :) <Steap_>Or can I just use guix system init <some-config> and generate an iamge that can be run in kvm ? <civodul>Steap_: for a "real" install, you have to follow the steps above <civodul>to give it a try, you could simply use "guix system vm" <Steap_>yeah, I'm already running guix in a vm, not sure how well nested kvm work :D <civodul>Guix (not GuixSD) doesn't need a VM if you ask me <paroneayea>ACTION likes both VMs and containers in proper VM and container use, as caveat :) <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? <Digit>er, i mean myself. i cant speak for anyone else <efraim>what was that black magic about grafting updates? <amz3>I used to have guixsd with multiple monitors <bavier>keverets: I tried hooking up two monitors through a laptop docking station, and was having trouble getting both external monitors to be recognized <bavier>i.e. the one would display fine, but not the other <efraim>ok, i looked more closely at ludo's patches today and I see what happened, and assumably why we don't use it more often <bavier>keverets: yes, both monitors are visible in arandr <davexunit>nice use of n-par-for-each in the grafting code <davexunit>I wonder if this has made grafts perform fast enough to be useful <paroneayea>I guess if I'm writing guix code I don't need to wait on https stuff to land in guile master because guix has https support since that's where I tore it out of... of course :) <paroneayea>now working on trying to generate an image from a system definition that I can upload to openstack nova/compute <paroneayea>now I need to read the source to figure out where that image gets put <fps>re: "real installs": i guess one could make a raw image of a more "complete" system than the installer image <fps>erm, never mind.. grub :) <fps>would only work if you don't have existing partitions on the target disk that you want to keep ***exio4 is now known as hacker
***aeva`` is now known as aeva
<keverets>bavier: I have my siystem do: xrandr --output LVDS1 --off --output HDMI2 --mode 1920x1200 --output HDMI3 --mode 1920x1080 <keverets>while connected to the dock, which outputs on the two monitors connected (one via DVI, actually) <keverets>if you try to set the active screen via an xrandr command line, what does it say? <bavier>keverets: thanks, I'll give that a try <civodul>at work i have one external monitor and i use xrandr similarly, FWIW <efraim>also if you have tab completion for xrandr it helps a lot <bavier>I don't have my guixsd system plugged in at the moment, but will play around with it more later <keverets>I just script it and use srandrd to determine when to issue the command <efraim>I have a bunch of shell scripts that I leave around my home directory <civodul>mark_weaver: it seems the security-updates jobset was canceled? <taylan>TIL there's a "villains" wiki, listing all villains in media <taylan>it doesn't have John Irenicus. I immediately lose all respect for this wiki. <taylan>oh wait, it's written Jon not John <mark_weaver>civodul: I cancelled the jobs because I needed to add another patch for libsndfile, and I wanted to make the evaluation go fast and not waste time building outdated jobs. <mark_weaver>it's mostly restarted now. still waiting for some of the jobs to restart. <civodul>i was wondering if something had gone wrong <davexunit>civodul, mark_weaver: is libpng among the applications being updated? <davexunit>thanks, being lazy because I don't have the git repo in front of me right now <mark_weaver>the dovecot upgrade was also for security, btw, but I pushed that to master <paroneayea>so a while ago, you offered to "make a vm" image for joeyh so he could test out guix <Steap_>Talking about vms, I'm getting weird stack traces when running "guix pull" in kvm <Steap_>It keeps compiling stuff, though. <paroneayea>what's the mechanism by which you were doing this? <paroneayea>I'm trying to produce some nice vm images to test copying up <paroneayea>davexunit: hey, nice, something easy and built in :D <davexunit>unfortunately my image got corrupted when I uploaded to my server <paroneayea>davexunit: I was trying to write code to do this myself when I realized something probably existed and I was just missing it ;)