<leoprikler>I thought you were talking about guix system init, but you're talking about the boot process <honkitybonk>changing to a previous generation might work but it's not entirely ideal <leoprikler>what changed between your previous generation and the current one? <leoprikler>Did you make changes to /etc/config.scm or did you just update a bunch of things? <leoprikler>that shouldn't be too harmful -- try booting the previous generation <leoprikler>alternatively, you can also boot the current generation without "quiet" <leoprikler>now you just need to figure out how to get it to boot after reconfigure :) <leoprikler>btw. try checking /var/log/messages for interesting messages <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>"guix pull --roll-back" will do it. <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 ***jje_ is now known as jje
<MaliRemorker>i was kind of shocked about the RMS spill-over to guix lists, so thought to come by and see if everyone's alright <truby>my email has quarantined the guix-devel mailing list :-( I guess I'll wait a couple of days and see if it's safe to unquarantine then <MaliRemorker>say i include a bunch of guix modules into my program via (use-modules (guix whatever whatever)) <roptat>I would say no, because it works like dynamic linking, but I'm not sure <MaliRemorker>unless ... somehow guile compiler packs it all into one blob bytecode? <roptat>I think you need to have the libraries at run-time <roptat>so it's really like dynamic linking <truby>you need to be GPL licensed to dynamically link to a GPL licensed library though no? <truby>I thought that was the point of the LGPL <truby>(as in the LGPL relaxes that restriction) <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 :-) <truby>while we're on the subject of copyright, am I right in thinking guix doesn't require copyright assignment? <MaliRemorker>;;; GNU Guix --- Functional package management for GNU;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2019 Ludovic Courtès <ludo@gnu.org>;;; Copyright © 2013 Andreas Enge <andreas@enge.fr>;;; Copyright © 2014 Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com>;;; Copyright © 2014, 2015, 2016, 2017, 2018, 2019 Mark H Weaver <mhw@netris.org> <truby>yeah, I saw that so I assumed it doesn't need assignment <leoprikler>is there a way of "deeply" composing directories in ~/.guix-profile? <leoprikler>specifically, what I would want is the following: <leoprikler>guile-abc depends on guile-xyz and both have a /share/info <leoprikler>if I install guile-abc, I only get the /share/info of the former, but not the latter <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? <vixus>True. Ok, I'll give that a shot <ng0>truby: no, guix does not require copyright assignment *kmicu ʕノ•ᴥ•ʔノ ︵ ♥❤❣💞 to civodul, rekado and guix folks <bgardner>Good morning guix, I have an application that links against libgcc_s.so.1 and can't find it. 'ldd file' gives a bunch of good values and then 'libgcc_s.so.1 => not found'. Any advice? <bgardner>No, this is the D compiler - the ldmd2 version baked into guix is a tiny bit too old for the project so I was trying to get the reference version built <MaliRemorker>... /gnu/store/ypiv8dj4lkvsnm82s639h18l87frrh5g-gcc-6.5.0-lib/lib/libgcc_s.so <roptat>try to add gcc-toolchain:lib in our environment maybe <MaliRemorker>for anything gcc base a hack would be -L/gnu/store/.../...-gcc-...-lib/lib <roptat>in general, it's best to create a guix package, though <bgardner>roptat: You may be right, but not sure if it's worth the overhead yet. I'll keep it in mind. <nckx>bgardner: RPATH? I also recommend writing (or tweaking) a Guix package; it can be its own short file. <MaliRemorker>I encountered a lot of similar issues when trying to use the trivial build system <MaliRemorker>gcc in guix is not well aware of where it's bits and pieces are <roptat>mh... that's weird: I did "guix system reconfigure" which had to build knot, then I ran "guix gc" and now a new "guix system reconfigure" needs to build knot again... <nckx>And knot is such a breeze to build. <vixus>any idea why guix system disk-image takes such a long time (none of the packages it depends on have really changed)? <vixus>the image.iso.drv is what takes a long time <leoprikler>perhaps because of the size of your iso/hard drive speed? <roptat>mh... could it be related to grafts? I see the store still contains the knot I built previously (that my current system depends on) <nckx>I'm not a disk-image user (only ‘vm’), but isn't the disk-image also created by spawning a VM and writing everything from inside that virtuaguix? Elegant, but would add some slowness. <roptat>yet, I am building a knot from the exact same guix <leoprikler>your previous knot remains in the store until it is no longer referenced and you run guix gc <roptat>I know that, but why does guix want to build a different knot now, when I didn't guix pull in the meantime (it's the same terminal, just 10 minutes difference) <nckx>Oh, knot needs an upgrade. Sorry roptat, I hope you like building Knot. <vixus>leoprikler: could it be because of --file-system-type=iso9660 <reepca>it's possible that knot, correctly or incorrectly, isn't referenced by your built system. The reference may be obfuscated (bug!) or it's just not needed at run-time. <nckx>I've run many GCs on systems running Knot before without breaking the service. <roptat>it's in a service, and guix gc -R /run/current-system references it <leoprikler>vixus: not sure what's the problem, but that option is needed if you want an ISO <roptat>but "guix build knot" wants to build /gnu/store/cqqi9jknkg7j5ka65ir31fi0n520av6r-knot-2.8.2, whereas my system references /gnu/store/52727p46z9hgihjw2rvl3mb8s6cl0ihk-knot-2.8.2 <bgardner>Blech, I'm just chasing my tail here. I'll go see about a one-off package for this. <roptat>so there's nothing wrong with gc: it's working as expected, but it's weird that I need to build something completely different now <leoprikler>perhaps the service references an old knot, though? <roptat>no, I didn't change the file nor guix, I didn't expect any rebuild <roptat>that's why I'm blaming grafts, there're always making guix do unexpected things :p <leoprikler>but the grafts wouldn't change if guix wasn't updated <leoprikler>if you do `guix build knot` twice, you should get the same knot <roptat>no difference at all, just a gc in between <roptat>with the system retaining a reference to a knot version, that I expected to be the same than what I'm trying to build <leoprikler>maybe you unknowingly used two different versions of guix? <roptat>I think, the system has a reference to the grafted knot, which doesn't have a reference to the ungrafted one, so gc collected the ungrafted knot, which I'm now building again for some reason <roptat>I used guix from the same terminal, with only 10 minutes in between the two invocations <leoprikler>perhaps you're right about it rebuilding the ungrafted one <roptat>so, I think the question is: if I already have the grafted version, why does guix rebuild the ungrafted one? <roptat>especially when the output of "guix build knot" after building the ungrafted variant is the path to the grafted variant (which wasn't built, since it already existed) <leoprikler>because Guix can't know, that the ungrafted version will develop into the grafted one without building it <vixus>leoprikler: ha maybe it was because I was on battery :p <roptat>ah right, I don't know how guix computes the output path for a graft... <leoprikler>vixus: perhaps, if your machine tries to save energy <roptat>if it needs the ungrafted version content for that, then I guess the behavior makes sense <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 <reepca>that is to say, I'm puzzled as well. <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". ***bsima1 is now known as bsima
<reepca>(I should add that this means my earlier claim that 'guix build --dry-run' would produce the grafting derivation is false. Oops) <peanutbutterandc>Question: Does `guix pull` also not update guix-daemon? If so, where can I find the updated daemon? <nckx>peanutbutterandc: ‘guix pull’ doesn't update packages, only the packages available. <nckx>On Guix System, guix system reconfigure updates the daemon. <nckx>On other systems, I'm not really sure. It depends from where guix-daemon.service (or whatever) gets its daemon. <nckx>MaliRemorker: One should never install guix with guix 🙂 Badness happens. <nckx>(No ‘guix package -i guix’ etc.) <MaliRemorker>nckx: this was the only way to get the guix info documentation working on my system <peanutbutterandc>Strange, when I run `guix describe` after `guix pull` it shows me that guix is currently built from the latest commit in the master branch... <leoprikler>`guix describe` tells you where your ~/.config/guix/current points to <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. <MaliRemorker>apteryx: i wouldn't have been able to read guix documentation if i didn't do `guix install guix` :-P <peanutbutterandc>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version <MaliRemorker>anyway, curious about badness ... i wonder when will it hit me <apteryx>MaliRemorker: oh, that's not recommended (to install Guix itself in your profile). <nckx>I wonder what the reasoning was (if any) not to hide the guix package like we do gcc. Because it would break ‘guix environment guix’? <leoprikler>peanutbutterandc: `guix describe` describes guix after it was pulled <MaliRemorker>nckx ooooh, so it's also not recommended to install gcc ? :) <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, I am on a 'foreign distro', BTW. If there's a difference between GuixSD and foreign distros <nckx>peanutbutterandc: What does ‘which guix’ (better: ‘command -v guix’) actually return? <nckx>peanutbutterandc: There is, especially in this area. <peanutbutterandc>nckx, I will give the results once `guix pull` is complete. Please wait. <nckx>peanutbutterandc: Store paths are immutable, so the only way to ‘update’ /gnu/store/20215021foo is to create a new /gnu/store/27637bar and point a link/PATH/whatever to it. <MaliRemorker>wait ... in the docs ... for a foregin distro: `guix pull` needs to be executed as root <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? <nckx>peanutbutterandc: Do you mean package -u? <apteryx>MaliRemorker: on foreign distro, the guix-daemon is installed in the profile of the 'root' users. <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 ***somethinglittle is now known as nothingmuch
*MaliRemorker goes into idle mode too <dongcarl>Hi all, are there auxiliary files that I need to change if I change `doc/guix.texi`? *janneke goes looking for a commit <nckx>dongcarl: Not normally, no. <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 <roptat>that's the badness that can happen ;) <roptat>so don't do that and point INFOPATH to your .current directory <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 *dongcarl is thankful for knowledge <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 :-) <dongcarl>janneke: so in conclusion... `_aligned_malloc` is mingw's version of `memalign`? <janneke>dongcarl: that's what the internets seem to suggest, but i was unable to find some nice documentation about it -- really weird, but i guess that's microsoft for ya *janneke goes afk for a bit <Linschn>I'm trying to define new package directly in gnu/packages but guix does not want to see my .scm file <Linschn>./pre-inst-env guix build qgisguix build: error: qgis: unknown package <roptat>if that's a new file, have you added it to gnu/local.mk? <Linschn>Nope I didn't, the doc does not tell us to do so <Linschn>So I add it to gnu/local.mk and run make ? <roptat>not sure if it changes anything, but it doesn't hurt <roptat>also, it may be that you have a syntax error in your file, or maybe you didn't name your package "qgis" <roptat>(in the name field of the package) <Linschn>I tried the same package in antother folder and used the -L option to guix build and I get a useful error, <brendyyn>i dont think you need to do the local.mk thing since pre-inst-env defines GUILE_LOAD_PATH <Linschn>Does this mean I have to run make everytime I change my package ? <roptat>Linschn, sorry now I see that I was wrong to suggest adding the file to local.mk, it's not useful <roptat>running make is not useful either <roptat>you probably have a syntax error somewhere and guix refuses to load the file <roptat>it should tell you something like ;;; ... is older than compiled file <roptat>that means guix is able to build you .scm file by itself just fine, and there should be an error message there too <Linschn>I'll try with a copy of the hello package <roptat>I don't see anything wrong in the file... maybe a missing import? <Linschn>I created a package hella which is the same as hello and it works <Linschn>I have a bunch of ;;; note: source file /root/guix/gnu/packages/file-systems.scm messages <Linschn>The fact that guix lint requires the packages to be found is not helpful <Linschn>I can't try to see if there is an error in the package <roptat>there should be an error message when guix compiles the .scm file <Linschn>Guix does not even find the scm file :'( <truby>I put your code in a qgis.scm file in my load path and it builds fine, so it's not an error with the code <Linschn>OK so I copied hella.scm into qgis.scm, I s/hella/qgis/g and then it finds the file <truby>(well, there's a build error in the actual build, but not in the .scm file) <Linschn>OK so I'm going crazy it's working now <truby>(I think the package needs cmake-build-system instead of gnu-build-system but one thing at a time) <Linschn>I've been on this for the last 2 hours and I don't know why my package was unseen <Linschn>So maybe the make was necessary after all ? <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>then I don't know, what is skeletons? :) <shrdlu68>roptat: `A list target file name/file-like object tuples (see file-like objects). These are the skeleton files that will be added to the home directory of newly-created user accounts.` <roptat>do you have an error message or a log? <roptat>are you sure (default-skeletons) is a function? <shrdlu68>roptat: Yeah, there's `(define (default-skeletons)...` in the source. <reepca>shrdlu68: is xterm-kitty in the same directory as your config.scm? <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 <reepca>worst-case scenario, you could just tar xvf the source yourself and see what the resulting name is. It should be deterministic. <reepca>But really, we should figure out a way to get the name from tar <truby>yeah, I know what the name of the folder in the tar is <truby>but where does the tar get unpacked to? <truby>so it would be in .. relative to where racket is getting built? <truby>and therefore (string-append "--enable-scheme=../ChezScheme-racket-v" version) should work? I'll have to try that :-) <reepca>if this is happening after the unpack phase, then '.' is inside the racket build directory (something like /tmp/guix-build-racket.drv-0/racket-source). <truby>it seems like that's an even worse way of solving it than to just git-fetch though <reepca>if you want an almost comically hacky solution, you could create an empty directory, cd into it, run tar xvf, then use scandir to get the name of the resulting file <reepca>then move it outside of the empty directory ***ng0_ is now known as ng0
<truby>I think I'll just do the git-fetch because then I can specify the name of the output folder <shrdlu68>roptat: I've scanned the docs, I can't tell how to create a file-like object that creates parent directories as needed. <roptat>You would create #$output/.terminfo/… <shrdlu68>Where are functions such as mkdir, symlink, etc documented? <reepca>shrdlu68: guile reference manual <shrdlu68>I can't figure it out, and I'm getting an empty log file after build. <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? <pkill9>shrdlu68: you'll need a `/` after #$output <pkill9>and maybe remove the `/` after "x" <leungbk>but after some time I error out with: <leungbk>making '/gnu/store/74qnv9mg4jgdnqxzyzdjyyjnjrb3vg4c-system' the current system... <leungbk>setting up setuid programs in '/run/setuid-programs'... <leungbk>populating /etc from /gnu/store/aiy5h6bkp02w7cwx27i45bmc5vgh114f-etc... <leungbk>guix system: error: rename-file: Is a directory <leungbk>Would somebody be willing to help me troubleshoot this? <shrdlu68>pkill9: Thanks. I'm getting `In procedure copy-file: Is a directory \n /gnu/store/d40a8cvvgwsyqxjc0zfhac9y24bqfqzg-xterm-kitty' -> `/gnu/store/km80w8hhg9n5v539nfb8va18h0wfzdl6-xterm-kitty` <nckx>fanta1: We welcome members of all faiths! <nckx>Tirifto: Speaking only for myself: *if* you want to involve a Guix list, I'd rather it be help- than -devel. <kmicu>Hi fanta1: I use vi in Emacs. I welcome you! ( ^_^)／ <lfam>Hi maintainer apteryx :) <lfam>I was so happy to read that email <lfam>Yes I've been busy offline <lfam>The core-updates merge means I must write patches :) ***ChanServ sets mode: +o lfam
***ChanServ sets mode: +o nckx
<ng0>urgh... someone wants to do triage on the bugtracker if you haven't closed the bugs already. jean opened bugs on the 9th of october for all those nice emails <nckx>ng0: I thought I closed & archived all of them. <ng0>37677 37674 37676 37675 37658 <ng0>you might want to double check as I typed this from the mail window. <nckx>Sure, will do. 2-3 of them look familiar, but I didn't close 5.