IRC channel logs
2023-10-23.log
back to list of logs
<jaeme>What do I do with ".1" man source files in Guix <jaeme>For context I'm packaging a CLI tool called ani-cli <jaeme>I'm using the copy-build-system since it's just a shell script <zamfofex>Doesn’t it install it by itself? (During the “install” phase of its build.) <nckhexen>jaeme: (install-file "something.1" (string-append #$output "/share/man/man1")) or fancier as needed. <nckhexen>I don't know off-hand whether the c-b-s shares gnu-b-s's automatic gzip compression. <jaeme>nckhexen: thank you so much, it works now. <jaeme>The free operating system needs anime <vivien>lilyp, do you mean we should keep glib 2.76 and not update to 2.78? <lilyp>is this still about MisakaOS? <lilyp>vivien: if you have a reason to do 2.78, go for it, but I'd rather focus on getting GNOME 44 done atm <lilyp>and every day spent building webkit is a non-productive day <lilyp>plus we'd have to worry about gstreamer et al again too <alxsim>hmm I must have something messed up in my setup, trying to use guix shell --pure gives me a lot of errors starting with bash: dirname: command not found... <alxsim>I have guix installed on fedora and using fish, I've already spent the afternoon trying to fix my PATH <alxsim>any tips on trying to debug this? a guix shell does not give me any errors <chipb>alxsim: dirname is part of GNU coreutils, so I'm guessing you'll probably need to pull that into your shell too. <chipb>as coreutils is pretty pervasive, I'd hazard that you have shell startup files that are complaining about it. <chipb>though I'm a bit surprised if they get sourced when entering a guix shell. <alxsim>thanks, yeah it stops complaining when I do guix shell --pure coreutils python for example <RavenJoad>Agreed. There is something not quite right. Remember that a pure shell only contains *exactly* what you ask for (and some of those dependencies). So it is perfectly possible to get yourself into a situation where you lack coreutils in a pure shell. <alxsim>So I guess this is my fish shell that is messing up things <RavenJoad>On my guix system, guix shell --pure hello -- ls does not run ls. <RavenJoad>So what you were seeing is expected behavior, I believe. <alxsim>I am correct that in guix shell, it creates a new profile and this should appear first on the PATH to bypass other installed versions <alxsim>in my case, because I set some paths with fish, guix shell adds the new profile path, then loads fish which ends up messing the PATH I think. <alxsim>I end up with something like /home/alexis/.config/guix/current/bin /home/alexis/.guix-profile/bin /home/alexis/.nix-profile/bin /home <alxsim>/alexis/.cargo/bin /gnu/store/x5fkl1l1kvrmjf7hvjpizivf9lk5n107-profile/bin /home/alexis/.config/guix/cur <alxsim>(ah sorry for the extra-ones, meant to edit that) <alxsim>with the x5fkl1...profile supposed to be the shell if I understand that correctly <RavenJoad>"creates a new profile that appears first in PATH" Yes, that is how PATH is manipulated. <RavenJoad>Something is always adding those other ones to the front of PATH. <alxsim>I'll need to go look how this is handled in the guix installed fish (mine is installed from the distro) <apteryx>lilyp: I've found a way to resolve the duplicate include directive in your .git/config; see 75aba5a746 <apteryx>sneek later tell civodul thanks; I'm looking at the RPM thing. I'm thinking of merging bug#42146 to core-updates, if you don't have more comments/concerns to voice <bdju>our gajim package is a bit out of date <bdju>darn I can't upgrade to a newer commit because it doesn't fetch with git <bdju>though I wonder why it doesn't fetch with git for the package. it looks like things are available via the gitlab releases page <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, apteryx says: thanks; I'm looking at the RPM thing. I'm thinking of merging bug#42146 to core-updates, if you don't have more comments/concerns to voice <civodul>not sure where the “Change-Id” thing was discussed but i think we should be able to get things done without it <civodul>after all, every forge out there is able to close issues without requiring specific metadata in commit logs <cbaines>you can do without it, but then you'd either have to rely more on heuristics, or do things like stop amending patches before applying them <cbaines>and I think both of those things aren't desirable <cbaines>if we want automation, it's important that it's very reliable, and I don't think we want to give up the ability to change patches before applying them (because that would make the automation look unreliable) <isaneran>why does guix start downloading stuff when I run guix system delete-generations <isaneran>feels like a think that should be entirely offline <civodul>cbaines: i agree, but what do the others do? <civodul>i mean, nobody complains that sr.ht or GitLab are unreliable in that respect <cbaines>in many cases, the forge handles the merging, so it knows what "Merge request" or issue to close <cbaines>we could implement that, but it would cause issues for commit signing and tweaking patches before pushing <civodul>if Change-Id is necessary, so be it; i’m just surprised we’re the only ones who found it necessary <snape>however Cuirass eval seems ok <snape>probably because Cuirass didn't have to run ./configure <civodul>snape: yes, evaluations do not involve anything that’s not Scheme <simendsjo>I'm having problems running guix pull on a small VPS as it keeps running out of memory I guess. Been running guix there for several years, but now it runs into problems. Any tips on a way around this? <rekado>simendsjo: how much RAM do you have there? <rekado>2G should be just about enough for “guix pull” <rekado>anything lower might not work since compiler changes in Guile 3. <efraim>create a swapfile for now and add zram to your OS config is my suggestion <rekado>(the bigger Guix becomes the worse this gets. Guilers and Guixers alike are aware of this, but a real fix is not trivial.) <simendsjo>Only 1G; bumping to 2G goes from $5 to $12 per month :( Is there a way to offload this? <rekado>simendsjo: yes, we do build the “guix pull” derivations on ci.guix.gnu.org, so you should get substitutes for this <rekado>you may need to pull a slightly older commit if ci.guix.gnu.org hasn’t quite caught up with the latest commit <mekeor>... or use `channel-with-substitutes-available' <futurile>mekeor: what's that command -^ - is it part of guix pull? <mekeor>futurile: it's documented in manual section "7.5 Channels with Substitutes", aka (info "(guix) Channels with Substitutes") <mekeor>you can use it to wrap a channel in your user profiles channels.scm <simendsjo>Haven't heard about that before. (channel-with-substitutes-available %default-guix-channel (channel-url %default-guix-channel)) fails with a 404, but I'll read up. <futurile>damm - just found it - thank-you - wow I've been jumping through hoops to exactly that <mekeor>unfortunately, it's not possible to list multiple substitute-servers, afaik. i think bordeaux is better than ci.guix... <mekeor>simendsjo: tbh, i'm not 100% sure if this will help with your memory problem. good luck! <simendsjo>Maybe not. It's at "Computing Guix derivation". Worst case, I can bump the size when I need to do a guix pull, but that's quite tedious. <mekeor>simendsjo: just to make sure. did you read efraim's suggestion to use a swap-file? <rekado>unfortunately “Computing Guix derivation” cannot be substituted. <simendsjo>Yeah, using zram is probably a good solution. I don't have any memory or speed requirements for the server, only that it doesn't cost much. <hako>I'm using "guix deploy" for VPS <simendsjo>I've been reluctant to convert to guix deploy as I've been afraid I'll brake the server :) But it does look quite easy to use though. I notice the "The functionality described in this section is still under development" -- Anything in particular I need to think about or does it work as intended? <civodul>simendsjo: i think the “still under development” bit is not meaningful here, we should remove it <rekado>we’re using it for most of the build nodes behind ci.guix <civodul>it’s still “under development” in some way, but the basics are in place <rekado>all of Guix luckily is still under development <simendsjo>:) The build didn't work this time either, so I'll try moving to guix deploy. Makes more sense anyway. Thanks! <simendsjo>Looks like guix deploy is working fine though: guix deploy: sending 301 store items (1,351 MiB) to 'my-host-here'... Thanks again! <apteryx>sneek: later tell snape: thanks for the quick fix <civodul>apteryx: alright, i guess it’s just me failing to keep up <civodul>(i should review fewer patches to make room to join discussions :-)) <voroskoi>are the network-related tests expected to work, or i can just ignore them? <apteryx>civodul: one of things I like about Change-Ids is that it's forge-agnostic. We could go from one to another and keep our same scripts to close merged issues (assuming we have them written :-)) <futurile>voroskoi: network related tests won't work, you're supposed to alter the package so that they are not run I believe <gabber`>images gnu/system/images/rock64.scm and gnu/system/images/pine64.scm don't build due to gawk-mesboot not recognizing `aarch64-linux-gnu' host system triplet. is it possible these images are not built automatically in ci? <futurile>aaargh one rust crate wants jack-0.10 and then about 40 crates later I have jack0.08 ... and (I didn't know but sensibly) you can't have two versions of the same system library in the dependency tree! <futurile>thought I had climbed all the way to the top of the tree ... for my grand moment of everything compiles ... <kaboom> <singpolyma>Is there a way to specify the version of go that the go-build-system should use? <apteryx>sneek later tell singpolyma there's probably a #:go argument? <sneek>Welcome back singpolyma, you have 1 message! <sneek>singpolyma, apteryx says: there's probably a #:go argument? <mirai>apteryx: what's this Change-Id thing and where does it come from? <lilyp>it comes from the automatically added git config <lilyp>it helps automating some nonexisting scripts :) <apteryx>in the meantime, it also adds a unique identifier that can be used to map merged commits to their submission on the guix-patches@gnu.org tracker <apteryx>or even with mumi directly: mumi search Ia92fa958eae600fdd4e180bad494c85db8bb4dd6 <apteryx>ulfvonbelow: I've seen those yes, they are rare but it still happens, especially when using a large amount of substitute jobs in parallel <apteryx>I guess you may be using --max=jobs=N where N > 1 with your guix-daemon? <ulfvonbelow>although in my case I'm not passing --max-jobs, so presumably the default of 1 is being used <apteryx>I guess the risk is not zero but it seemed like I was hitting the issue most often when using a large --max-jobs <nate1>Does anyone here run xmonad? I've been trying to switch everything I have installed to guix-home, but xmonad fails to compile my config because it can't find the xmonad or xmonad-contrib library <phf>Hi #guix! `$ ./pre-inst-env guix build -K elixir-kv' gives: `error: #{.}#: unbound variable'. Is this a common error? How to fix it if possible? Thx! <phf>sneek: later tell civodul Great! <phf>A dot has found its way in a random place in the file which caused the compilation error above... <gabber>phf: i figure you recently pulled and recompiled the source tree you're running that command from? <phf>gabber: yes: I added the dot. <gabber>so you were able to resolve the issue? <phf>Yes, I've removed the dot, and I have other errors now ;-). But these, I know how to solve them. <phf>That's funny: if `./pre-inst-env guix build -K elixir-kv', then: `no code for module (guix utils)'. If I comment the line `#:use-module (guix utils)', then: `error: string-replace-substring: unbound variable, hint: Did you forget `(use-modules (guix utils))'?' <gabber>this is a new package definition you're crafting there, right? <gabber>i think you have an issue with your package definition, though it's hard to tell i can't glance over it <phf>This error seems to come from somewhere else. As far as I know, (guix utils) should not raise a `no code for module' error, but it does. <gabber>i usually try to comment out major blocks of (the newly added) code until the error disappears. it does make sense that guix tells you which modules to import when you don't import them but use the functions <elevenkb>Hey there people, I have a question about define-configurataion. <phf>gabber: well, it's exactly what I'm doing :-). <elevenkb>when you have a field with defaults like e.g. (port (integer #f) "The port") it seems that you can't leave out that field anyway because #f is not an integer. <gabber>phf: your elixir-kv definition is super minimal! i think except that you may lack the import of hexpm-uri - which is in (guix build-system rebar) - it looks goot to me? <elevenkb>2. If so, how can I specify a default that has a different type than explicitly specified value? <phf>hexpm-uri comes from (guix build-system mix) this time. <gabber>phf: i see, it's not *that* simple considering the new build system... have you tried importing the single modules in a $(guix repl)? <phf>hexpm-uri calls snake-case which is exported from (guix build mix-build-system) for some reason. <phf>gabber: not all of them, I'm doing that. <gabber>elevenkb: you are talking about record-type fields, right? <phf>snake-case calls string-replace-substring which relies on (guix utils) which causes the error. <elevenkb>i was speaking more directly about the TYPE-DECL field in a define-configuration clause (see the info page for define-configuration to see what I mean by that). <mirai>`exact-integer' would be better though <mirai>using (port exact-integer "The port") means that a port _must_ be specified <elevenkb>I know how to specify the clause mirai... the main thing was that I wanted an optional port. <elevenkb>I wanted it to become #f if not specified. <mirai>then you need to define-maybe exact-integer <mirai>and use it as maybe-exact-integer <nate1>Is there a good way to debug what service is doing what? With my home config, something is causing a syntax error in on-first-login, and I don't even know where to start on fixing that <gabber>you can test your home configuration before reconfiguring with $(guix home container home-config.scm) <gabber>but besides reading the docs (and eventually the sources) it's hard to tell what service does what exactly ;) <nate1>Thanks, that speeds things up significantly, but now I'm even more confused because I can remove everything and still get the syntax error <gabber>are you sure you are operating on the correct file? what is the exact error? would you mind sharing (through a pastebin) you configuration? <nate1>Yeah I'm sure it's the right file because in the container I can see my shell config disappear and whatnot. The exact error is "/home/nate/.guix-home/on-first-login:3:1272: sequence of zero expressions in form (begin)" <nate1>In that file sure enough I can see an empty begin which I'm pretty sure is a syntax error <gabber>have you configured your guix home before successfully? <nate1>Yeah it only started doing that today. I probably should have been more atomic with what I did, but today I pulled, added a few packaged and reconfigured and then it started happening. You can see in this paste though that I've removed basically everything and am still getting the error when I start the container https://p.twil.cx/ped.lsp <gabber>so it started with your very first generation? otherwise you'd be able to $(guix home switch generation 1) to go back to the first iteration <nate1>I can roll back to the generation before I started messing with it today and it works fine <gabber>is it possible your issues emerge from the (najer packages utils) import? <gabber>nate1: so the problem lies in the diff between the old generations and what you have now (: <nate1>Yeah and that seems like it has to come from the guix pull I did, since I can revert the changed lines to no effect <gabber>you can also go back in guix time with $(guix time-machine ..) -- hope that helps <futurile>are we supposed to send the initial patch email to guix-patches@gnu.org OR guix-patches@debbugs.gnu.org - the manual says one thing in the paragraph and something else in the command. <futurile>(the one with the cover letter when you're creating a series) <gabber>where did you find the reference to the latter? <gabber>i think the latter is only with an ISSUE_NUMBER (that you'll get after sending your cover letter) <jbnote>Hi there, I'm trying to use guix/etc/source-manifest.scm instead of a custom solution for whole-source downloading. Currently this manifest is invalid due to duplicate entries (first one: java-binding.zip from packages/batik.scm). Should I fix them one-by-one in packages or should I fix source-manifest.scm, for instance by enriching the name field in the manifest, in order to work around this? <jbnote>Actually, once asked, the answer seems pretty obvious: fix source-manifest.scm unless I'm ready to spend my life fixing the packages, right? <civodul>jbnote: what makes it “invalid” exactly? <jbnote>civodul: when running 'guix package -p .guix-sources -m ~/src/guix/etc/source-manifest.scm' <jbnote>civodul: it says guix package: error: profile contains conflicting entries for java-binding.zip <jbnote>guix package: error: first entry: java-binding.zip@0 /gnu/store/2m979xi8mwnks5f2x5s88nrq1j0cpkj6-java-binding.zip <jbnote>guix package: error: second entry: java-binding.zip@0 /gnu/store/7swwa7yh5h3xqjv1kb34an8gpfyl3kbd-java-binding.zip <jbnote>hint: You cannot have two different versions or variants of `java-binding.zip' in the same profile. <civodul>it’s good enough for “guix build -m etc/source-manifest.scm” though <jbnote>(admittedly i'm not on the tip of the git tree) <civodul>it never occurred to me that this could to to a profile <civodul>you could pass ‘--allow-collisions’ to work around it <jbnote>I'd like the profile install because i'd like to run GCs in my store and keep around the source. <civodul>note that this is *all* the source of all packages <civodul>perhaps that’s more than you’d like? <civodul>another option, if what you want is to avoid redownloading things you might need, is to run guix-daemon with “--gc-keep-outputs --gc-keep-derivations” <jbnote>civodul: i'm running offline guix cluster for aarch64, x86_64 and powerpc64le. I just realized that etc/source-manifest.scm existed. I was using a custom solution up to now, in order to do the mirror. <jbnote>indeed, it's completely air-gapped, so it's a good testbed. The documentation somewhere asks for feedback in such a use case. I will do it someday :) <jbnote>thanks a lot for Guix by the way. The 'product' is amazing and the community is awesome. Besides, i'm having a lot of fun learning guile. <futurile>anyone know how I can find the magic that is running `get_maintainer_script` - I'm not in the guix/ repo but it's still doing it somehow <civodul>in academia clusters are rarely air-gapped; there can be network restrictions, but it’s usually not too strict, just slightly annoying <ulfvonbelow>out of curiosity, would either of you happen to have any numbers for how much disk space the resulting profile from etc/source-manifest.scm takes? <jbnote>ulfvonbelow: my old source mirror is around 200GiB. This is on btrfs with compression. <civodul>“guix weather -m source-manifest.scm” should give figures