<honkitybonk>Maybe an upgrade later will resolve it or something. Thanks for the help anyways! I learned a bit about generations and such in guix doing this stuff.
***catonano_ is now known as catonano
<peanutbutterandc>Can anybody please explain to me the exact differences between `~/.guix-profile` and `~/.config/guix/current`? It seems to be the case that the latter is pointing to the current profile and the former is just stuck at what it was.
<mange>Basically: ~/.guix-profile is the packages that you have installed as a user. ~/.config/guix/current is the latest update of the Guix distribution itself. So running "guix pull" will update ~/.config/guix/current, but "guix package -u" will update the packages in ~/.guix-profile.
<peanutbutterandc>Another troubling thing is that running `guix package --manifest=empty_manifest.scm` to initialize a profile for users creates `~/.guix-profile` and not `~/.config/guix/current`. The latter seems to be created only by `guix pull`.
<mange>They shouldn't point to or refer to each other, as far as I know. :/
<peanutbutterandc>I was wondering if it'd be nice if we had only one thing... Perhaps we could have ~/.guix-profile pointing out the current profile. That would only require one addition to our PATH variable. Is there any reason why that isn't the case?
<mange>It's nice to be able to roll back my user packages without also rolling back Guix itself. If the version of Guix were tied to the profile version then it would be easy to make all sorts of mistakes (like installing out-of-date and vulnerable packages).
<peanutbutterandc>Oh! So that is why the provision is made! To roll back user packages without rolling back Guix itself! Neat! That makes a lot of sense!
<mange>It also lets you do the opposite: to roll back Guix (in case of a bug, or whatever) without having to roll back everything.
<mange>~/.config/guix/current is a profile, just like ~/.guix-profile, so you have all the same tools to manipulate it.
<peanutbutterandc>I see. Thank you. Another question: So my PATH should be '~/.config/guix/current:~/.guix-profile:and/other/usual/stuffs'?
<mange>You need /bin on each of those, but otherwise yes.
<peanutbutterandc>mange, I see. Neat. Thank you. That makes a lot of sense. Guix continues to impress me more and more. Turns out even the things that make me go "I think the devs missed this (trivial) part somehow" is a careful design decision that makes a lot of sense. Super cool!
<mange>Yeah, it's really confusing at the start, but for most things there's a good reason behind it.
<mange>Also, I usually source ~/.config/guix/current/etc/profile and ~/.guix-profile/etc/profile rather than explicitly setting PATH.
<peanutbutterandc>Strange, my ~/.guix-profile/etc/profile does not have a ready-to-eval PATH variable (just comments) while my ~/.config/guix/current/etc/profile does...
<peanutbutterandc>Anyways, is there a particular name for ~/.config/guix/current? Just as ~/.guix-profile is called $GUIX_PROFILE (of the user) in general? I would like to update my /etc/profile (with descriptive names)
<jfred>Oh interesting, I missed the distinction between ~/.config/guix/current and ~/.guix-profile before but it makes sense
<jfred>helpful as someone trying to use guix on a foreign distro
<roptat>right, so guile doesn't put any restriction, but guix does?
<truby>"Linking [name of your program] statically or dynamically with other modules is making a combined work based on [name of your program]. Thus, the terms and conditions of the GNU General Public License cover the whole combination" - https://www.gnu.org/licenses/gpl-faq.en.html
<truby>so I would assume that the same applies in this case but I'm no expert :-)
<leoprikler>without having to manually install guile-xyz as well
<vixus>Hi all, I'm running guix system init on a custom system configuration of mine. I've ended up having to add a #:use-module line for a bunch of stuff (mapped-devices, file-systems) etc. which I didn't see imported in the example desktop.scm -- what's going on?
<leoprikler>why do you have the keyword notation? did you define your OS in a Guile module?
<nckx>That doesn't sound right to me, but I can't explain the behaviour you're seeing either.
<leoprikler>Building against libA and then grafting libB is not the same as directly building against libB
<roptat>I know, but I would expect guix to be able to compute the output path of the graft before building the ungrafted version, something like hash(ungrafted + 'graft' + grafted-lib) or something
<roptat>it would be enough to identify the grafted knot uniquely
<nckx>roptat: Yah, that's (roughly) what I've always assumed. Let's face it, the only person who can do this in their head is probably civodul 🙂
<reepca>client-side guix doesn't get to choose precisely how the output paths are generated. For derivation output paths, it's based on the derivation contents minus the output paths themselves (makes sense). guix build --dry-run knot will produce the grafting derivation without ever building any derivations. So the contents of the grafting derivation cannot depend on the output of the original derivation, and thus neither can the output path
<leoprikler>perhaps Guix thinks it has to build both, even though one of them is a graft?
<leoprikler>(similar to multiple outputs if one of them gets deleted)
<reepca>ah, I think I've got it. See Section 11 "Security Updates" of the manual. Note where it says "From there on, any package depending directly or indirectly on Bash—as reported by ‘guix gc --requisites’ ...". "guix gc" lists references, but references are a property of the /output/ of a derivation. That is, while you could get a (very) conservative estimate of the references of an output just from looking (recursively) at the derivation
<reepca>and its inputs, the exact references of the output can't be known until it is built.
<reepca>basically, it needs to know whether it references things-being-replaced before it can know whether it needs to apply grafts. But to know the references, it has to have the output.
<reepca>to see this in action, compare "guix build --dry-run -d knot" to "guix build -d knot". --dry-run will refuse to build, so the references aren't known and it returns the original derivation. Without --dry-run, it will build the original, check its references, and return the grafting derivation (without building it).
<reepca>one reason this behavior isn't seen very much is that it actually first asks substitute servers for reference information for the prospective graftee before falling back to building. So as soon as substitutes become available for knot, it'll mysteriously go back to acting "normal".
<nckx>MaliRemorker: I don't remember, but badness 😛 It's not how Guix is intended to be used. guix is already in .config/guix/current, if you install a (by definition: older) one in .guix-profile, bad things can happen.
<leoprikler>nckx: in other words don't do `guix install guix`?
<MaliRemorker>okay, so ... i would need to fix my infopath to point to `.../current`
<nckx>leoprikler: Indeed. Or any other equivalent to ‘guix package -i guix’.
<apteryx>MaliRemorker: there's a section in Guix doc covering how to update your Guix (and guix-daemon). It was added recently.
<truby>MaliRemorker: you almost definitely want gcc-toolchain rather than gcc so gcc is hidden
<nckx>MaliRemorker: Installing ‘gcc’ used to work, but it didn't result in the working toolchain people expected, so it was hidden in favour of the full ‘gcc-toolchain’ package.
<dongcarl>janneke: Not sure if you're online but, could you tell me how you come up with patches like 308eb5c11a885768f81fb6136fd4d30b4639fe04? I was stuck on this for so long and couldn't find any answers from googling... I'd love to learn!
<apteryx>MaliRemorker: the info node is called 'Upgrading Guix', part of chapter 2.
<peanutbutterandc>leoprikler, That makes sense but `which guix` before and after `guix pull` point to different guix in `/gnu/store`
<peanutbutterandc>leoprikler, As far as I have understood, `guix pull` updates/upgrades the package manager itself (using the latest commit in the main git repo) while `guix pull -u` upgrades/updates the packages. Am I wrong?
<peanutbutterandc>nckx, `guix pull` seems to be making the changes... yes `guix package pu` I mean. Beg your pardon
<nckx>peanutbutterandc: In that case, yes, but only for your user, not all.
<MaliRemorker>it needs to be followed by the restart of the daemon service
<nckx>Too many people stumbling over each other to talk, nckx out 🙂
<MaliRemorker>Well, I was looking through the docs and it seems like it's important for peanutbutterandc (and mine) case to not forget to update guix daemon as root, (obviously) not as an ordinary user. though, i don't know, maybe peanutbutterandc was already aware of that
<truby>can I specify that a package needs some source code from somewhere else as an input? As in, I need to download an extra source archive and then use a configure option to point to it
<roptat>MaliRemorker, when you install guix with itself and use that, the next time you run "guix upgrade", it uses the package definitions from the installed guix, including a definition for guix which is necessarily older that the installed guix. So, every time you "upgrade" your packages, you actually downgrade them
<janneke>dongcarl: yes, i can imagine. i could not believe that duckduckgo did not know about this problem.
<dongcarl>janneke: Haha yeah, I guess I'd just like to learn about the thought process of how you come up with a fix like this
<janneke>dongcarl: i spent a lot of time searching, and then i gave up and went checking how debian does it; checking packages versions and reading patches.
<dongcarl>janneke: I did that too! Which package did you end up reading?
<janneke>dongcarl: i found that debian has no gcc-7 + mingw combination, but looked at gcc-6 and gcc-8 and neither those, nor their mingw-64 package had patches that really inspired me...i think i tried one or two.
<MaliRemorker>roptat, funny how one can be able to write a relatively complex guix package and yet be blissfully unaware of the issues you mention
<roptat>that's the reason why we have guix pull ;)
<janneke>dongcarl: finally, i ran the build using --no-build-hook --keep-failed, ran `make' manually in /tmp/guix-build-*/.../... and went trying things ... duckduckgo did have old posts that talked about memalign and _aligned_malloc.
<dongcarl>janneke: did you end up finding the solution on DuckDuckGo?
<dongcarl>Also, I understand `--keep-failed`, but what does `--no-build-hook` do?
<peanutbutterandc>Sorry everyone for the delay but here is a paste: https://pastebin.com/u9U0YTZi that shows the differences before and after `guix pull`. I really think `guix pull` upgrades the package manager itself. cc: leoprikler nckx MaliRemorker
<truby>huh.. you can just put a (origin ...) object as an input to a package and it grabs and unpacks it. Well, that does what I want :-)
<janneke>dongcarl: i was hoping/expecting to be able to do it without adding this #define. i was expecting a similar #define to be present in a mingw or gcc header and i was hoping to switch it on by setting some HAVE_MINGW or so, but i could not find anything. i have been stuck on this also quite a while.
<janneke>dongcarl: next time when we are stuck, let's just chat sooner :-)
<Linschn>I'll take my week end and come back to it on monday
<Linschn>Thank you roptat and truby and brendyyn for your help
<truby>if something has the licence LGPLv2+ and I compile in some code with license Apache2.0, does that mean the only valid license for the resulting combination (and therefore this package) is LGPLv3+? Licenses make my head hurt :(
<shrdlu68>Hello, I have `(skeletons (cons (list ".terminfo/x/xterm-kitty" (local-file "xterm-kitty")) (default-skeletons)))` in my config.scm, but it's failing to build. What am I doing wrong?
<roptat>I think guix was able to find xterm-kitty just fine
<roptat>but the skeletons don't create subdirectories as needed
<roptat>maybe create a file-like object for .terminfo?
***freedom is now known as gnufr33d0m
<truby>ok the source dependency thing I tried didn't do what I thought it would :-) anyone got any pointers?
<reepca>truby: it does grab it, but it doesn't unpack it - gnu-build-system has an "unpack" phase specifically for that.
<truby>ah right. Basically I'm trying to write a package for racket's chez scheme backend, which requies a patched version of the chez-scheme source code from their github that you pass the path to with --enable-scheme=... and I can't really work out how to do it :-)
<reepca>ah, yeah, tricky part there is that the source output path isn't easily known until the builder is being run. Including it in #:configure-flags would require lowering the origin to a derivation in the store just to evaluate the package definition (well, technically certain low-level procedures for constructing derivations could get you "what the output path would be" without actually serializing the derivation and interning it in the
<reepca>I'd propose wrapping the built-in configure phase with your own which invokes it with #:configure-flags (string-append "--enable-scheme=" (assoc-ref inputs "patched-chez-source"))
<truby>so, that's what I have right now :-) but patched-chez-source is a tarball not a folder
<truby>so --enable-scheme=.. points to the right place if I just do that naively (which might not be what you're talking about) but like I said it just points to the tarball, and that's the part I can't work out how to resolve :P
<reepca>looking at guix/build/gnu-build-system.scm, I believe the appropriate incantation would be (invoke "tar" "xvf" (assoc-ref inputs "patched-chez-source"))
<truby>but am I right in thinking that I won't then know what the path is to pass in to -enable-scheme?
<reepca>annoying thing about that is that it doesn't tell you what the extracted file name is
<truby>I guess the hacky way of doing it is to git-fetch instead of url-fetch, since that'll just be a folder right?
<reepca>it's kind of amusing, actually, the way we work around this in the unpack phase is to just assume it's the first subdirectory
<Tirifto>Question: What would be an appropriate place to submit a reply to the joint statement on the GNU project? Would that be the mailing list ‘gnu-system-discuss’? Or should I reply to the announcement that was posted on ‘guix-devel’? I have some thoughts I'd like to share that perhaps someone might like to read.
***jonsger1 is now known as jonsger
<shrdlu68>roptat: I am supposed to `(mkdir (string-append #$output ".terminfo/x/"))` in the gexp I pass to compute-file, right?