IRC channel logs


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
<jaeme>But it also has "ani-cli.1"
<zamfofex>Doesn’t it install it by itself? (During the “install” phase of its build.)
<jaeme>I don't think it does
<jaeme>I can't find it
<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
<lechner>apteryx / thanks!
<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.
<chipb>* a --pure one, that is.
<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>but it seems weird
<alxsim>RavenJoad: ah right
<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>good to know
<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>this would be the fish config
<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
<jackhill>sneek later tell lilyp epiphany also needs to webktigtk-for-gtk3 change:
<jackhill>sneek: botsnack
<lilyp>jackhill: thanks
<sneek>lilyp, you have 1 message!
<sneek>lilyp, jackhill says: epiphany also needs to webktigtk-for-gtk3 change:
<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
<futurile>Morning Guix
<civodul>Hello Guix!
<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>(honest question)
<civodul>i mean, nobody complains that 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>ah yes
<civodul>if Change-Id is necessary, so be it; i’m just surprised we’re the only ones who found it necessary
<snape>seems build is broken with
<snape>apteryx ^
<snape>(missing "fi")
<snape>however Cuirass eval seems ok
<snape>not sure why
<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, so you should get substitutes for this
<rekado>you may need to pull a slightly older commit if 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
<futurile>'to do exactly that'
<mekeor>i don't know why but i put everything explicitely in my channels.scm:
<simendsjo>Ah, needed another URL. Here's a direct link to the documentation. Thanks a lot! This *really* helps!
<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
<civodul>right :-)
<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
<sneek>Got it.
<apteryx>civodul: re Change-Id; I've tried gathering some feedback in
<apteryx>it was discussed at some lengths already in
<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
<voroskoi>futurile: ok, thanks
<apteryx>and-map is not documented?
<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>there's probably a #:go argument?
<apteryx>sneek later tell singpolyma there's probably a #:go argument?
<sneek>Will do.
<singpolyma>apteryx: thanks, seems to be working
<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 tracker
<apteryx>for example, to find the commit responsible for adding this change-id on the tracker, you could search with its Change-Id:
<apteryx>or even with mumi directly: mumi search Ia92fa958eae600fdd4e180bad494c85db8bb4dd6
<ulfvonbelow>anyone else get errors of this sort sometimes when trying to download substitutes? It's from a self-hosted substitute server fwiw
<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>there is an issue opened for it
<ulfvonbelow>thanks, good to know
<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!
<sneek>phf, you have 1 message!
<sneek>phf, civodul says: Guix appears to be on
<phf>sneek: later tell civodul Great!
<phf>sneek: help
<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.
<gabber>good to read!
<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.
<gabber>elevenkb: ask away
<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.
<elevenkb>1. Is that intended behaviour?
<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)?
<elevenkb>The answers seem to be:
<elevenkb>1. Yes.
<elevenkb>2. Use define-maybe
<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>gabber: likely?
<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>(port integer "The port")
<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
<gabber>that paste does not seem to load without javascript enabled. would you mind using or a similar service?
<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 OR - 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>the former
<gabber>where did you find the reference to the latter?
<gabber>sorry, didn't read right
<futurile> <-- Multiple Patches section, 'git send-email outgoing...' command example
<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: 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?
<civodul>it’s used for
<jbnote>civodul: when running 'guix package -p .guix-sources -m ~/src/guix/etc/source-manifest.scm'
<civodul>oh i see
<jbnote>civodul: it says guix package: error: profile contains conflicting entries for
<jbnote>guix package: error: first entry: /gnu/store/
<jbnote>guix package: error: second entry: /gnu/store/
<jbnote>hint: You cannot have two different versions or variants of `' 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.
<jbnote>civodul: allright, thanks.
<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.
<civodul>oh ok
<civodul>that’s an interesting use case!
<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 :)
<civodul>yup, you should :-)
<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
<civodul>jbnote: heh, good!
<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
<civodul>(you’ll have to be patient tho)