IRC channel logs
2024-11-11.log
back to list of logs
<stites>hi all! I'm writing my first guix package and I'm wondering how to define a source that uses the current directory as the origin. <ekaitz>stites: (source (local-file ...)) <stites>and... when I finally package this thing and fetch with git or by url -- how would make the fetcher choose a subdirectory of the repo? <Kolev>i wish i could get audio working on chromebook <ekaitz>stites: that's a different question, i think you need to source the repo and then chdir to the subdirectory you need <stites>ekaitz: thanks, yea! ...and I think that means that I would want to use `snippets` and write a gexp to change the working directory? <stites>I'm mostly just wrapping my mind around how to read the documentation <stites>ekaitz: so local-file just seems to be for a single file, not a directory. Did I get that wrong? <apteryx>lilyp: I'm almost ready sending my gnome-team branch <apteryx>been fixing things to be able to build 'fontmanager' <divya>I have an old Nvidia GT 610 and have nouveau drivers, and I think I've got it working because: <divya>$ lspci -nnk | grep -iA2 vga gives the right model and everything <divya>The problem is when I open something with mpv, I get: libEGL warning: MESA-LOADER: failed to retrieve device information <divya>Is this a warning worth worrying about or just something that can be ignored and I can consider that my graphics is using hardware acceleration? <divya>I'm not on wayland btw, good ol' X11 with stumpwm <stites>So I've now defined two packages and I'm trying to depend one on the other via cmake. Would anyone be able to help tell me how to serialize a package into it's path? Right now I've got something like: (apply invoke "cmake" `(,@(string-concatenate "-DPICO_SDK_PATH=" pico-sdk))) <apteryx>lilyp: I think we should move straight to GNOME latest (47) unless we have strong reason to stick to already outdated 46 <apteryx>I suspect the effort going from 46 to 47 is very low <apteryx>is there a way to mark a package as 'not to update' ? <apteryx>'guix refresh' gets it wrong, and the package is archived anyway <apteryx>updating gstreamer (again) to latest 1.24.9 <lilyp>apteryx: you can use =VERSION to force a particular version <apteryx>yes; I still intend to fix --target-version to accept a partially specified version <apteryx>--target-version=46 meaning it could be 46.1 or 46.0.8 <apteryx>divya: hardware acceleration for 3D or video playback? <apteryx>both nvidia and amd GPUs require proprietary blobs to get video playback... <apteryx>older GPUs can do OpenGL fine without blobs. <apteryx>it seems manufacturers have been pushing more and more complexity into the binary blob part, seemingly encouraged by the linux non-free firmware loop-hole. <apteryx>I have this in my ~/.bash_profile: export INFOPATH="$HOME/src/guix/doc:$INFOPATH:" <apteryx>lilyp: I've tested and applied your webkit updates <efraim>building 3 webbrowsers and all these other libraries make me want to see if I can upgrade the CPU in my motherboard :/ <efraim>well, I'm a happy user of `shepherd-run --exec "mbsync -a" --transient` <efraim>ACTION shamelessly self-promotes shepherd-run <futurile>efraim: do you have a 'nominal' time-line for when you want to merge rust-team next? <futurile>efraim: found some patches in issues that I could rebase etc, or there's other things I can work heh <efraim>futurile: I try to keep it in a buildable state, so it should be ready as soon as it's the rust-team's turn. looks like qt, lisp and meson are ahead of it <jakef>hi Steve, have you had a few responses on the survey? <futurile>jakef: about 15 when I looked last night <jakef>pretty good! considering it hasn't really been pushed out yet <futurile>jakef: a few people who didn't 'complete' it all the way through; might be people testing it, or maybe indicative that's it's a *bit long* (which it is but so many interesting questions!) <futurile>I'll email the mailing lists today, and hopefully the blog post will go up <efraim>it's only on the extra check-x86 phase, so I don't know if its something we should skip or if a newer version would fix it <nutcase>for me it affects guix system vm, which, I guess, is a quite popular use case? <janneke>yeah, same here for my devel-hurd -vm <efraim>it needs u-boot-tools for x86 systems? <Rutherther>efraim: is there a reason why guix keeps just one version of rust that can be used for building? seems to me that large chunks of the derivation can still be reused across versions, so it doesn't seem to me like it would be necessary to remove the old ones. Or am I missing something? <janneke>ACTION just rebased on master, what happened?? <janneke>yeah it's a new dependency that just came in from the rebase <efraim>Rutherther: it's easiest to just support the most recent version possible <efraim>plus the intermediate objects can't be re-used cross rust versions <efraim>I could be convinced to keep a slightly older version for ppc64le, since I'm having trouble building one of the intermediate versions there <efraim>does anyone remember the syntax for using b4 to grab patches? <janneke>efraim: ah, it comes in via genimage <efraim>looks like ppc64le fails building rust-1.73. rust-1.72 might be too old to use <apteryx>has youtube-dl been superseded by something else (a fork?) <jaft_r>apteryx: yt-dlp (technically, I think youtube-dl hasn't been discontinued, last I checked, but a lot of people've moved on to yt-dlp so, well…); also already packaged, too, so switching's easy. <apteryx>jaft_r: their website is down, last release I can find is from 2021 <apteryx>looks dead to me, unless you can point me to a live repo <janneke>wow, it looks like the mesa-related updates also break grub's console output in qemu <Deltafire>oh, has the mesa-updates branch been merged? <Deltafire>janneke: thanks, will try that after this update finished :) <nckx>futurile: …seems to've been pushed already? <futurile>nckx: someone must have done it over night - thanks for looking at it! <nckx>It appears that a wild cbaines appeared. As did the rendered blog post (it wasn't up when I sent my previous message). <nckx>Are VPSes public cloud? I've never used AWS. <bdju>anyone know how I can troubleshoot the broken thumbnails problem in pcmanfm-qt that started a few months ago? the only interesting thing I see launching it from a terminal is `4:25:25.688|qt.qpa.plugin|W|Could not find the Qt platform plugin "wayland" in ""` which may or may not be relevant <cbaines>nckx, yep, providing it's open to the public. <attila_lendvai>bdju, the guix issue is probably due to not finding the right dir where the plugin is expected to reside. but i'm cluless about qt stuff... <futurile>janneke: there's lots of GNU/Linux in there I promise - I just got bored writing it the same way 20 times - and I used the other distros official names <futurile>so far 24 people have completed it; but 10 didn't go all the way through so didn't hit 'Submit' - ugh that's a worry! <nckx>Does that count folks currently filling it out? <futurile>because it's anonymous I think you can't go "back in" to it - but I guess if the page is still open in your browser it will show me a partially completed one <bdju>so is there any easy way to check the version of a currently installed package? like a pacman -Qs type thing? think I might've asked this before but don't recall the answer <nckx>futurile: There's ‘resume later’ in the ⋯ menu. No idea what it does. <futurile>nckx: oh interesting - I assumed it wouldn't work <futurile>bdju: you want to know if a packge would be updated? guix package --dry-run --install <package> <bdju>I just found guix package --list-installed <bdju>no qtwayland has two versions and I wanted to know which I had. I am fully updated at the moment <bdju>I wonder if everything will break if I try to install the other version or if I can have both <bdju>ah dang it does downgrade the one I have <bdju>why do we have both available then <bdju>thumbnails still broken but having the older qtwayland does remove that one plugin message from before 🤔 <bdju>so something between pcmanfm-qt and qtwayland 6 isn't working right but that's unrelated to the thumbnail problem <janneke>ACTION tries not to be a spoil sport <attila_lendvai>the questions about hw support are hard to answer, because with nonguix i'm ok, but without it i would be f*ked... <bdju>typo on the first page of the survey >so that you're answers count <futurile>attila_lendvai: well it's just factually asking you what you do; and you can always add that as a comment in the question at the end which asks you for other thoughts :-) <futurile>attila_lendvai: with or without f*ked in it heh <nckx>I wish I'd noticed the hidden assumption that ‘if you use nonfree drivers, you use nonguix’ earlier. <futurile>bdju: thank-you, fixed it - and add a similar reminder on the last page <bdju>I thought nonguix was a taboo topic so I'm surprised to see it in the survey which was posted as an official blog post <futurile>nckx: damm that's an actual mistake and I can't fix it now - it was supposed to have 'other' switched on <nckx>bdju: It's hard to read the survey as promoting Nonguix IMO. <futurile>bdju: no it's not taboo, we're not promoting it by asking if people use it <nckx>It's never been a taboo word. <nckx>If someone claims that you can tell them they're wrong. It's OK. <nckx>I've had to do so a few times, ironically more often in unofficial channels. <futurile>32 submissions; 17 full responses - let's see if my emoji star 🌟 reminders are enough heh heh <attila_lendvai>damn! i forgot to lament about the lack of a wiki in the survey... :) <bdju>I don't think it's promoting it either but I did think it wasn't intended to be discussed in official channels and that you had to basically hear about it through the grapevine <futurile>attila_lendvai: tell another Guix person about the survey, get them to fill it out and have them mention the Wiki thing? ;-)) <nutcase>I also forgot to mention establishing a practice to have something like a README.Guix (similar to README.Debian) where Guix specifics could be documented. Such a file probably gets immediately updated, when a contributor updates a package. A well maintained wiki is also a good idea, maybe an even better one. <bdju>so what sort of incantation of guix shell do I need to test a sort of vanilla/clean pcmanfm-qt to see if it's my config breaking the thumbnails or something else <bdju>do I have to list dependencies with it? <bdju>if I do `guix shell --container pcmanfm-qt -- pcmanfm-qt` it can't connect to the display and can't load the Qt platform plugin <bdju>so I usually launch nheko with `LC_TIME=en_SE.utf8` at the start to get better time/date stamps (setting this systemwide breaks stuff but just doing it for nheko worked well) but now recently it's showing 12 hour time again <bdju>another Qt program. are all the Qt things broken? <futurile>bdju: you don't want to use container, otherwise you will have to make sure you pass all the right env variables <futurile>bdju: so just plain guix shell pcmanfm-qt, <attila_lendvai>futurile, i don't really know anyone personally who uses guix. every guix user i know is from the usual guix channels... this could have been an interesting question. e.g. how many people do you know in-person who uses guix? <bdju>futurile: well if I do `guix shell pcmanfm-qt -- pcmanfm-qt` I get one broken in the same way as my installed version, and it's using my same theme and fonts and such. so I would like one that is less aware of other stuff on my system I think. <Rutherther>bdju: easiest will probably be to start it under another user <bdju>oh I see now I do have icons/thumbnails but for some reason there are huge areas of blank space and a big horizontal scrollbar. same between my installed version and the guix shell version. may need to reconfigure theme stuff <bdju>qt5ct says it's not configured correctly because I have QT_QPA_PLATFORMTHEME set to lxqt instead of qt5ct or qt6ct. lxappearance segfaults when I try to run it. is there any guix documentation on how this qt theming stuff is supposed to be set up? I'm using Sway <bdju>I think lxqt-config-appearance is what I wanted. and it appears changing my font to something besides terminus makes the icons appear where they belong again. that's a shame as I really like terminus <nutcase>bdju: Some time ago I ran lxappearance with "GDK_BACKEND=x11 lxappearance" to avoid a segfault. Does that help? <bdju>yes, that does seem to allow it to launch. thanks. though I had forgotten lxappearance was for gtk stuff, so it's not what I was looking for in the end anyway. <bdju>is there any locale I can use that has 24 hour time and year-month-day date? I'm trying to set locale stuff granularly with lxqt-config-locale but I can't find any options for time that look how I want. <bdju>I thought en_SE or en_DK were how I wanted, but seems not <nckx>bdju: ‘LC_ALL=en_DK date’ on Guix System seems to work. I don't use lxqt. <marmar>nix run nixpkgs#package works though <bdju>I'm not using lxqt itself but qt is hell and I'm just trying anything and everything and nothing works <bdju>I just use sway but I want my qt stuff to behave <bdju>date ignores LC_ALL when specified like that <bdju>I read something about using +"%c" but not sure that's working right either <Rutherther>marmar: you need to switch to home-manager to have the home-manager program executable in your path. Anyway this is probably better suited for #nixos irc, as that is completely unrelated question to guix <bdju>and I am indeed on Guix System <marmar>Rutherther: but I don't think I can switch if it's not in path in the first place. Probably would go there <Rutherther>marmar: you can, and it even tells you how to do it. Add package output having home manager, and then execute it with nix run . -- switch <apteryx>seems like a convenient option to forget about it indefinitely <apteryx>ACTION was replying about an old msg from nckx about the survey 'resume later' option <marmar>Rutherther: okay I don't have reading comprehension apparently. Sorry! <nckx>bdju: <date ignores LC_ALL when specified like that> uh <Rutherther>marmar: though note the guide is quite old and defaultPackage output is depreated, should be "packages.<system>.default" instead <nckx>apteryx: Yeah, we should collect e-mail addresses so we can send hourly emoji-laden ‘did you forget our surwey uwu’ reminders. <nckx>I have no idea what that means. <bdju>yeah. something is broken on my system probably. like usual. not sure how to figure this out <nckx>But it seems likely that every Qt test is tainted because of that. <bdju>is it possible I'm lacking some locales on my system so setting them doesn't do the right thing? <nckx>I have (locale-definitions (utf8-locales "en_IE" "en_US" "de_DE" "eo" "fr_FR" "nl_BE" "zh_CN")) [where utf8-locales is just a silly macro that maps utf-locale over each string] in my system configuration. You'll note the absence of en_DK, so I ass-u-me'd that time locales were somehow special/exempt/always included/something else. <nckx>Also make sure that your system & user profiles aren't using mismatched glibc versions (e.g., you don't get the ‘GUIX_LOCPATH’ warning). Unfortunately glibc locales aren't backwards compatible. <nckx>This is all annoyingly generic advice though. <bdju>wait where are you defining that? I set LC_ALL in my ~/.profile but otherwise not sure where this stuff is set. oh yeah and I have a locale line in config.scm right under operating-system. both are set to en_US.utf8 <bdju>I really just want LC_TIME to be a different thing I think <nckx>It defines the available locales for space-saving purposes. <nckx>If you're not doing that, I don't think it's your problem. <nckx>But again, since I don't declare en_DK and it still works at least for time purposes, this might turn out to be irrelevant. <bdju>I am indeed not doing that. hm. <nckx>ACTION wonders what would happen if you specified (locale "en_DK.utf8"), reconfigured, and logged back in. Just as a sanity test. <Deltafire>cool, blender is working again following latest updates :) <nckx>apteryx: In Qt, but even ‘LC_ALL=en_DK date’ doesn't return the expected YYYYMMDDTHH:MM:SS output. <apteryx>hm. so the problem is not qt specific? <ekaitz>divya: dude sorry for confusing explanation haha <divya>ekaitz: No worries, it was my ignorance regarding title and body. I usually use only title, so I thought it was the body lol <ekaitz>divya: run git help commit and go to discussion <divya>ekaitz: Indeed, I checked it and then sent it. In magit's commit buffer, I wrote the title and then RET once for a blank line and then the required body. <ekaitz>divya: also we need to think a little bit about the version number <divya>ekaitz: I was worried about it too, but the source uses these large numbers :/ <ekaitz>looks like there are other packages with a weird numbering scheme like this one <ekaitz>divya: did you test the package? <divya>wait, the patch doesn't build? <ekaitz>you have two big issues: licens: vs license: <ekaitz>and also gnu-gettext-minimal vs gettext-minimal <divya>I thought that would be the symbol name <ekaitz>divya: how do you test this? do you want me to help you test it? <ekaitz>did you try to 'make' and './pre-inst-env guix build ...' ? <divya>ekaitz: Yeah, I do guix package --install-from-file=audio.scm and then also guix build --rounds=2 <divya>But I think there are some typos, let me fix <ekaitz>divya: do what I wrote there instead, adding the package to the guix code <divya>ekaitz: I am not sure what exactly to do...do "make" where? <divya>I haven't tried to see if guix builds <ekaitz>inside there you do guix shell, then ./boostrap and then ./configure and make -j <ekaitz>guix manual explains how to build guix from source very well <ekaitz>divya: also, careful with the tabs vs spaces in the indentation <divya>Okay looks like I'll need more time with this patch. <divya>I'll be here, but would have to go for dinner. Would ping you if I get a successful build. <ekaitz>don't get me wrong, it's very near from being ready <efraim>I'm at over 10.3 GB of ram used compiling zig-0.10.0-610 on aarch64 <ekaitz>efraim: that was known i think efraim <ekaitz>i think they even have an issue for it in zig <efraim>I'm about to OOM on my RPi5, it's at 10.8 now <efraim>next build I'll try single threaded. uptime suggests it's using 3 cores <divya>ekaitz: How long does it usually take to build guix? I'm on an old i3. <efraim>how much ram? and 1 core or more? <efraim>so it should be faster than my pinebook pro. from a fresh checkout that one I want to estimate at 45 minutes but I don't actually remember <divya>Okay, that gives me a ballpark. Thanks. <divya>Didn't know zig is so meaty about RAM, is it the same in x86? <olafes>How would I download patches from a url and put them into `patches` field of `origin` of some package? <efraim>yeah, we have a note that it can take 10 GB of RAM for linking <divya>[ 24%] LOAD gnu/packages/audio.scm Looks like it built it fine, let's see if the whole build works out. <ekaitz>divya: once it finishes do ./pre-inst-env guix lint <clarkf>is there a trick to getting 'make check' working? I'm getting tons of errors <futurile>clarkf: are you doing it in a guix shell container? it needs a lot of coreutils stuff, grep etc <clarkf>I am. `guix shell -CPW` per the manual <clarkf>So I should run it in just a plain `guix shell`? <podiki>wigust: [hoping i got the right nick] I think I saw on a github issue for sunshine that you had it running on guix? do you have a package definition? <futurile>clarkf: I would come out of the container part of that for running make check, just use a plain ``guix shell --development guix `` <clarkf>Would that not be covered by just using the local manifest.scm? i.e. just 'guix shell' (no further args)? <clarkf>either way, it fails due to missing guile despite being present? <futurile>clarkf: OK, does this work: cd <where you have guix source>; guix shell --development guix --pure --manifest=manifest.scm ; make check <zeropoint>hello guix, does shepherd/guix have any functionality or patterns to be able to run something (or start another service) AFTER a one-shot service completes? <Rutherther>zeropoint: as far as I know requirements of services should work exactly like that if the requirement is a one shot service, shouldn't they? <zeropoint>i.e. I want to fork+exec and not block shepherd <zeropoint>but I want to be able to trigger something after the one-shot completes successfully <Rutherther>zeropoint: from shepherd manual: One-shot services are useful to trigger an action before other services are started, such as a cleanup or an initialization action. <divya>ekaitz: lint didn't show anything, so hopefully I'll just do build and then send it again. <futurile>clarkf: mmm odd - if you do it with the container switch (guix shell --container --development guix --manifest.scm coreutils), then echo $PATH, and check if you get `guile` in that profile; ls /gnu/store/xxx/bin/ <divya>Also now I have two commits though, one that I sent you and another that fixed the typos. I hope it's alright? ekaitz <futurile>clarkf: sorry that's --manifest=manifest.scm right - <futurile>clarkf: the --development guix should automatically be adding guile into the profile that you're creating with guix shell <zeropoint>Rutherther: right, but if I denote a one-shot service as providing something, the dependent service will start immediately after the one-shot service starts (instead of when it completes) <daviwil>futurile: Did you put together the Guix Survey? If so, nice work! If not, nice work to whomever made it! <divya>Indeed, it was him. I just filled it earlier today, really good work. <futurile>daviwil: yup - heh I'm about to email you asking you to talk about it on your social and stream heh heh <daviwil>oh yeah... I should add it to the newsletter I'm about to send out <daviwil>How long are you accepting submissions? <daviwil>OK, so there's still time, I'll give it a plug <futurile>daviwil: I think the <number> link is incremented for each person <daviwil>Well, at least I linked to the blog site <daviwil>Actually, because my mail provider has rejected the list mail, I have another chance to fix it ;) <futurile>nckx just fixed the link on the blog for me - I didn't notice until just now <permcu>Hi folks, if I do a guix system reconfigure, several times updating channel & computing guix derivation happens. Is this to be expected now? Or is there something strange in my new guix install? <clarkf>futurile: sorry, had to step away, but, yes, guile is on $PATH. In the error, the pre-inst wrapper is doing something funny with ~/.guix-profile <permcu>Also guix system reconfigure with sudo does not work since after a final updating channels & computing guix derivation cycle I get the error that the guix repo in cache is not owned by the current user. It is indeed owned by my user & not root. So that's strange as well. <olafes>Is there a way to use origin/file-like-object as input to a package? The docs say it's possible but it's unclear how to refer to these inputs in build phases <Rutherther>olafes: should be a plain assoc-ref from build-inputs. Not sure about the name though, worst case you could use named inputs <Kolev>futurile, I took the survey! <Kolev>One huge issue I have with Guix System is that it asks for the LUKS password twice, once without even a password prompt. <Kolev>So a user not in the know won't know that they have to type their LUKS password into the gray void. <permcu>kolev: Have a look at extra-initrd in the guix manual. There you find a receipt for single LUKS-PW. <permcu>Fortunatly it's not an issue any more. Just some configuring. <Kolev>I think it should be default. <permcu>Probably. But the rather manual process of installing guix makes such defaults difficult. <olafes>Rutherther: I got it working, thanks for help <Rutherther>olafes: what was the name of the input / did you go with named inputs? <Kolev>permcu, I use the installer. <divya>ekaitz: Sent it, I believe this is the final one. Did all the stuff, passed everything fine :) <ulfvonbelow>the survey at guix.limesurvey.net has as an option under "Which parts of Guix have you used on top of another Linux distribution?" the option "Dotfiles and home environment management (guix home)", but under "Which parts of Guix have you used on top of Guix System? " it has the option "Dotfiles and home environment manager (guix shell)" <permcu>kolev: Never tried the installer myself. <Kolev>permcu, I don't know how to manually install with encryption, so I don't do manual install. <Kolev>ulfvonbelow, I noticed that too... <permcu>kolev: Definitely the one key solution should be default in the installer. Hopefully someone's in the mood to change this someday. <Rutherther>Kolev: I don't think the approach suggested, with extra-initrd, can be default. It needs a specific setup from your side, namely to put your key to the initrd. Normally guix doesn't have to know about the key at all, but in this case it has to. Also I personally think it's a wrong approach, and it should be handled differently, by putting kernel and initrd to unencrypted partition, so you don't need to unencrypt anything. That also avoids the long... <Rutherther>... waits since grub is not able to do decryption quickly. <permcu>My guix issue keeps getting stranger after issuing the sudo guix reconfigure some files in ~/.cache/guix/checkouts are root owned and a subsequent guix pull fails. How is this happening. Should only root itself do reconfigure now? I always used sudo for reconfigure. Please tell me it works for you and it's my xtra special new setup instead. <ieure>permcu, Sounds like you're `guix pull'ing as root. <permcu>ieure: Yes it feels like it. But the pull happens several times during system reconfigure. At least it prints similar albeit shorter messages. <Rutherther>permcu: if you execute sudo guix system reconfigure, even if it builds guix derivation (which would mean you have to be using guix-for-channels somewhere), it should be building it purely under root. The environment is not kept when you use sudo, so cache directory should be root's <Rutherther>permcu: have you tried removing the folder in cache, and rerunning? <efraim>I downloaded more RAM and I made it past the RAM bottleneck on aarch64 zig-0.10.0-610 <ekaitz>efraim: downloaded more ram haha <ieure>permcu, system reconfigure will need to download stuff, but that all ends up in /gnu/store, it shouldn't touch anything in your user's $HOME. <ekaitz>divya: try to ./pre-inst-env guix style your-package and you'll see how some things changed <permcu>Hmm. Rutherer: I do not use guix-for-channels. ieure: It pulls the channels. Pretty strange. Thanks for your reassurance that this is not normal. I will further investigate tomorrow. Its getting nighty. <ieure>permcu, Suggest chown'ing the files, then doing `sudo guix system reconfigure' and checking their permissions. Maybe you accidentally ran `sudo guix pull' and are seeing stale stuff from that? <nckx>ACTION pings futurile for ulfvonbelow's message above. <ekaitz>divya: i'm going to explain better with the email <futurile>sneek: later tell ulfvonbelow thanks for the report about the issue with the Guix survey missing option. No idea how that happened. I'm not sure if I can fix it with the survey being 'live', but I'll try and do so. <divya>ekaitz: Okay, there was a conflict of commits, so I had to checkout the repository again. Will have to build the whole thing again. <ekaitz>divya: i'm bothering you with changes but the goal is to encourage you and make you learn what kind of details we need to make right <divya>Indeed, I appreciate. I would be better off next time, and it is good to uniformly follow the code that everyone else is following. <divya>ekaitz: If I don't build, I won't see the package when doing ./pre-inst-env guix style [package] right? <divya>Well without 'make' it doesn't seem to find it, so the only way to verify is build :) <nckx>futurile: Oh, I assumed it was just a typo (shell → home), not an intentional deviation. <nckx>But I guess it's true that changing it now might contaminate the results if someone only read 'shell' (although the results are arguably contaminated already). <divya>This is getting worse, no build is successfully working. <divya>Nothing, it's not the package. It's ending with some Error 2 <ekaitz>and start over with the compilation from the bootstrap to the make <divya>Also tell me, after I do guix style, how do I add the changes? In a different commit? <divya>Also another question, what exactly are the .go binaries? G-Object something? <divya>ekaitz: but if i do guix style and the file changes how can I add it to the same commit? <divya>Sorry if this is a trivial question. <ekaitz>guile is compiled first, those are run later in the interpreter's virtual machine <Ironsmith>i always thought they were related to golang... <ekaitz>Ironsmith: no relation with go lang <divya>Ironsmith: It was my first thought too, but then I remember there's G-Objects. <divya>ekaitz: Can --ammend take the new changes and put it in the same commit? <ekaitz>divya: sure, you have to git add them first <divya>I was trying to do that with magit but for some reason I was getting it wrong, let me see if I can do it with just CLI instead. <ekaitz>i don't use magit so I can't tell you how to do that <aurtzy>if the commit you're trying to modify was the very last one you made, "c a" in the status buffer should work <janneke>ACTION finally finds how to convince libtool to actually produce a static guile <attila_lendvai>janneke, BTW, wasn't %guile-static-stripped a good template for compiling a static guile?