IRC channel logs


back to list of logs

<lechner>Hi, do we have a Perl team?
<redacted>If I have a configuration variable that takes a path to a file, is there a function that will add a local file to my filesystem to the store and return the path to the file in the store?
<redacted>Specifically for a service, so, if I have a foo-service-type that has a foo-path configuration slot in its foo-configuration object, can I set that to a file that guix adds from my file system?
<redacted>I thought that local-file might do that, but it seems not.
<redacted>like (service foo-service-type (foo-configuration (foo-path (local-file "foo.conf")))) or something
<lechner>redacted / what happened when you tried, please?
<lechner>i might try to quote in and out, #~#$(local-file ...) but others here will give you better advice
<redacted>lechner it complains that I've given it an invalid value: error: invalid value #<<local-file> [...]> for field 'repository-directory'
<redacted>'repostiory-directory' is the field I'm working with, which expects a string
<redacted>Same problem with quoting. A gexp is also an invalid value.
<wdkrnls>Dear Guix, what does it mean for a supplementary group to be undeclared? Why would Guix get angry about that?
<wdkrnls>I was trying to create a group for plocate.
<wdkrnls>I guess I don't really need it.
<apteryx>podiki: it's related in that if gcc:lib has no meaningful purpose (because out depends on lib anyway), then it can be simplified out
<apteryx>(and then the bug no longer exists)
<apteryx>is #$output in inherited phases rewritten to point to the right output[
<apteryx>it looks like it is, but I wonder what is and what is not rewritten then
<apteryx>this-package doesn't for example
<apteryx>jpoiret: we can make static libraries from shared one, if they were built with -fPIC
<apteryx>(that is, aggregate shared objects into a static archive)
<podiki>apteryx: ah, you are saying gcc still references gcc:lib so there is no real separation effectively
<apteryx>it's useless currently
<podiki>that would change gcc derivation then, so core-updates?
<apteryx>yes. but perhaps those who made "lib" in the first place would like to see if the out -> lib reference can be fixed instead
<apteryx>presumably it was made to reduce the size of gcc
<apteryx>(that's the only reason I know to make various outputs)
<podiki>that would be my guess, and if something could use gcc:lib instead of gcc:out
<podiki>or does that not decrease closure size?
<apteryx>but gcc:lib would probably depend to gcc:out
<podiki>right, that's what i was wondering
<podiki>hard to follow the git blame, looks like from back when gcc-final was in gnu/packages/base (before mid 2014)
<podiki>likely from the start then?
<apteryx>ah! maybe! we could look at earlier versions to see if it's a regression
<apteryx>I mean gcc 5 instead of gcc 11 say
<apteryx>on current master
<apteryx>ACTION checks
<apteryx>wdkrnls: supplementary groups must already exists; it's just a means to list which groups your user should be part of, not meant to *create* those groups
<apteryx>groups are created via the 'groups' operating-system field; a list of 'user-group' objects
<apteryx>what does the bootstrap-guile driver does exactly in ?
<apteryx>it looks like it replaces a bunch of binaries that would be needed such as a shell awk, etc by being able to build scheme libraries like gash
<apteryx>and tar
<apteryx>so the aim is to have a minimal set of bootstrappable seeds, of which the biggest one would not play a directy part (no reference kept to) in compiling packages (it'd just be running the guix machinery to let other packages do so)
<apteryx>that's why they call it the 'driver'
<ulfvonbelow>I think it's also because it's what runs the builders
<apteryx>that mean that Guix still runs on Guile 2? at least a subset of it
<ulfvonbelow>aye, it can make some of the build-side code like (guix build syscalls) a bit more difficult
<apteryx>can I use subsitute* to substitute strings in binary files?
<apteryx>it's line oriented, so it'd probably be very inefficient, but other that that, it should work?
<ulfvonbelow>is there a way to get 'guix archive' to read its list of paths to export from stdin or a file or something? I have a list of around 5000ish different sources I want to export to an archive, but I worry that the command line will be too long
<ulfvonbelow>apteryx: I know that substitute* has been known to choke on certain unexpected characters in the past, so I wouldn't count on it
<ulfvonbelow>at least, I recall personally several instances of it raising an exception while operating on what looked to me like a normal text file, but with different line endings or something
<apteryx>I've tried it manually, seemed to work, though I haven't verified the result yet
<apteryx>we also have 'replace-store-references' from (guix build graft)
<apteryx>I'm trying both and will compare the result
<apteryx>is 'this-package-native-input' also broken in inherited packages? (operates on parents native-inputs?)
<apteryx>*on parent's
<gibbs>hi, I am having trouble sending a patch to My MTA reported 'all hosts for '' have been failing for a long time'. Anything I could do?
<apoorv569>Something is wrong with the home-pipewire-service-type, sometimes it works sometimes it doesn't
<apoorv569>if I do `pgrep -a pipewire` I get this,
<apoorv569>sometimes there are multiple of the same sometimes not
<apoorv569>this time it was multiple..
<apoorv569>and I can't play any video or audio..
<apoorv569>this also changes (by change I mean either more instances appear in pgrep or the pipewire service dies) when I connect HDMI cable and use arandr to use multiple monitors for example..
<apoorv569>if I `pkill -9 pipewire` and `pkill -9 wireplumber` I get this,
<futurile>gibbs: send to - that will create a bug - then you can send to afterwards?
<jpoiret>apteryx: wdym you can make static libraries out of shared ones? I don't believe that would let you do static linking, since most of the required information was lost with the first linking step
<francesco3>hi, i'd like to add a configuration flag to a package using meson-build-system
<francesco3>is there a modify-arguments similar to modify-inputs?
<jpoiret>yes, it's (substitute-keyword-arguments ...)
<efraim>does the meson-build-system have #:configure-flags?
<jpoiret>huh, we don't have it in the manual :(
<francesco3>thanks jpoiret, yes i was about to ask where i could have looked it up :P
<jpoiret>you can look at the docstring in the guix sources, or example uses (it's actually quite widespread)
<jpoiret>hence why I'm surprised we don't have any docs on it
<efraim>hmm, in order to build rust-1.73 on ppc64le I need to use clang to build rust-1.72
<efraim>there's an unsafe block that trips up rustc and causes problems if I remove the unsafe wrapper. if I tell it to ignore unused_usafe then I get a large backtrace, so it seems there's an actual bug somewhere there
<efraim>nope, error came back, I spoke too soon
<efraim>well those were the easy options, time to look through the backtrace and see if I can spot anything in the rust sources
<futurile>Damm I had 3133t speak number of unread emails in my inbox there for a few seconds!
<futurile>But now it's just ... more
<francesco3>the latest zathura doesn't ship synctex anymore, one has to add the library as input to enable synctex. Do you think we should have a package variant for it, or simply add texlive-bin to the inputs of zathura?
<civodul>ACTION merged master into core-updates
<efraim>how bad was it?
<francesco3>when i have a package variant, how do i express it as a specification?
<jpoiret>civodul: I don't understand how our cryptsetup-static builds at all. i'm upgrading it on c-u, and the static build just doesn't work at all anymore.
<snape>futurile: didn't know about those addresses
<snape>are you sure/
<jpoiret>one thing I don't understand is how we can possibly static link with dependencies for which we don't build the .a
<snape>gibbs, futurile: should be and
<snape>(wrong channel)
<francesco3>(no (problem))
<gibbs>futurile, snape: I already got a bug number a few weeks ago. Now I can't send my changes to
<peanuts>"[PATCH] gnu: Add r-gtsummary and dependencies"
<efraim>jpoiret: I assumed that the static library/binary "absorbed" the dynamic library in those cases
<jpoiret>you can't static link with .so's, no
<jpoiret>at least I'm not aware of such a case
<fnat>IIUC, `use-package-modules' (and respectively `use-service-modules') are only a shortcut; in particular, one could as well use the traditional `use-modules' form, if they're happy to manually search the location of said package or service?
<jpoiret>alright, I've got a building cryptsetup-static. Still don't understand how the current definition can possibly work 🙃
<rekado>ACTION reconfigures berlin to add an automated updater for the guix-bioc channel
<graywolf>Hello, if anyone has the time, there is up for a review...
<peanuts>"[PATCH 0/6] Add curl-full"
<mothacehe>graywolf: yeah I had a brief look already, not sure about the curl-full part. We often have a package and its minimal counterpart, but is not that common
<mothacehe>couldn't we have those options enabled in the main curl package on core-updates?
<graywolf>This was suggest here on the irc due to number of dependants for the curl package
<graywolf>Sure, that would work as well, I just follow instructions I got here ^_^
<graywolf>One advantage would be that curl-full could be update much more often (due to not having to rebuild the world)
<mothacehe>maybe we can find a middle ground where you add a comment indicating which options should be added to the curl package on the next c-u cycle?
<graywolf>Hm, I wonder how much bigger the curl-full closure is
<graywolf>lemme check
<graywolf>105.3 MiB vs 120.5 MiB; It that size increase acceptable?
<mothacehe>yes i think so
<graywolf>Ok. Is your long-term idea that the curl-full would be gone (and all the options would be enabled in curl) or there would still be two, but just with one (possibly) newer?
<mothacehe>Yes that it what I have in mind
<graywolf>Which of those two?
<mothacehe>that we try to have curl-full gone
<mothacehe>in the long term
<graywolf>Ah, I see, in that case it probably makes sense to do it on core-updates directly so we would avoid the whole deprecated package dance I guess?
<mothacehe>core-updates is frozen i think, so i might be better to go curl-full with a comment stating that we want to have that one merged into curl during the next c-u cycle
<mothacehe>*it might
<graywolf>It can just wait, no one is bothered by the absence of PSL it seems. I will close this bug report and resent it when next c-u cycle is open.
<graywolf>Thank you for the consultation :)
<mothacehe>yw :) you can keep the other patches of the patchset btw!
<apteryx>ulfvonbelow: substitute* to rewrite a binary worked at the REPL but not in a package definition
<apteryx>replace-store-references worked
<apteryx>It's not used in package definitions anywhere else
<apteryx>but references are still found in the binary after... hm
<apteryx>perhaps replace-store-references is written for the specific context of C/C++ produced binaries and assumes things
<apoorv569>is it possible to convert file-like to string?
<francesco3>apoorv569: a string representing the absolute path?
<apoorv569>francesco3: Hmm.. maybe I'm looking for wrong thing then.. I'm writing a home service in which I have a field for the home-FOO-configuration for the package which I take as an file like.. but then I do `(map specification->package (list "pkg1" "pkg2" ))
<apoorv569>I wanna add that field that package to this list as well
<apoorv569>file-like is not what I'm looking for then..
<apteryx>ulfvonbelow: sed worked... lol
<apoorv569>maybe just a string?
<francesco3>what does the file like represent?
<francesco3>maybe you want a package, apoorv569
<apoorv569>package of type tring?
<apoorv569>is of*
<francesco3>no then you have directly an object of type package
<francesco3>no need to have the string
<francesco3>so you can do: (cons your-package (map specification->package (list "pkg1" ...)))
<apoorv569>I see.. let me try this.
<apoorv569>OK, no errors.. building profile..
<graywolf>What does (properties `((hidden? . #t))) do and what would be reasons to set it on a package?
<rekado>graywolf: it hides the package from the user interface (e.g. guix search)
<apteryx>is anyone into D? I have dmd bootstrapped from GDC
<rekado>graywolf: we do that to hide the “gcc” package, for example, which is generally not what people should install (they should use “gcc-toolchain” instead)
<graywolf>Ah, thank you. Hm, any idea why curl-ssh is hidden?
<efraim>apteryx: nice. I wonder if it does better with other architectures than ldc does
<graywolf>Commit message is lack any details regarding a reason :)
<efraim>IIRC it was needed for julia but didn't want to confuse anyone from the CLI
<graywolf>I fail to see how giving people support for sftp in curl would be confusing, but thank you, it is good to know
<graywolf>the reason
<efraim>they're both called 'curl' from the CLI, so it'd be confusing for there to be two with the same name and no differentiator
<graywolf>ooooh I did not realize that; I now see the potential for the confusion
<graywolf>(would be solvable by naming it curl-with-ssh though...)
<weary-traveler>does emacs from the current emacs-team branch build? i ran into issues yesterday
<weary-traveler>lilyp: on a related note to above, i'm wondering if i should try your native-comp patchset against master instead. 1. is that advisable to try? 2. have you tested against something like "./pre-inst-env guix shell emacs emacs-org --with-input=emacs-minimal=emacs"
<graywolf>weary-traveler: On 60c97924e9519361494aaf0686e28eb831a42315 guix build --no-grafts --check emacs does build for me (although "may not be deterministic")
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<weary-traveler>graywolf: thank you for the reference point. is the "--no-grafts" necessary?
<graywolf>Sorry, no idea, still new here :) But without it nothing is built (even with --check), it just prints existing store path.
<weary-traveler>reading up on grafts, --no-grafts certainly seems like the "more robust at the cost of compute cycles" option
<jackhill>uh, I think I need help understanding this error:
<peanuts>"Issue 68212 Guix Quality Assurance"
<jackhill>sounds like I may have messed up indentation, but I don't recall doing anythng unusual.
<graywolf>jackhill: I do not fully understand the warnings, but they are just that, warnings.
<graywolf>The real issue I believe is the last line: No changes -- Patch already applied.
<graywolf>Indeen, on master the file gnu/packages/patches/openssh/openssh-gcc-13-ppc64le-fzero-call-used-regs.patch seems to exist.
<graywolf>Is it possible this was already landed?
<graywolf>In ef270f9d73203c1b19c6163ce4d4257a52bfb605, by... you?
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<weary-traveler>graywolf: so, --no-grafts certainly seems sufficient to make build work on emacs-team. unsure if it's necessary
<weary-traveler>oh there's no fsbot here
<lilyp>Even with grafts, it ought to build
<weary-traveler>ran into some errors yesterday when i tried building emacs-team with grafts. i was also tired, so there's some chance it was user-error
<lilyp>speaking of "ought to build", should I gently increase the priority of gnome-team?
<rekado>lilyp: go for it
<lilyp>let's retry the current evaluation first
<jackhill>graywolf: ha, goood catch. Well, I wasn't the committer, but I'll close the issue.
<graywolf>right, author, committer... :D
<weary-traveler>priority in cuirass?
<redacted>What's the Guix way of extending a service's activation gexp?
<redacted>I want to do some extra setup for cgit
<redacted>Actually, I wonder if that's even the right move. It looks like the activation-service-type runs the code at boot time, but maybe the directory should be created at build time?
<redacted>The /srv/git directory I mean
<redacted>I also want to chown it for the git user
<redacted>And run git init --bare
<graywolf>You cannot do that at build time. At build time you have access to just the output directory in /gnu/store (and the inputs and such).
<graywolf>So it needs to go into shepherd, how, I do not know
<lilyp>You'd typically have an escape hatch in the service for that. If not, you need to write your own service extending it or patch it in-source.
<redacted>lilyp: thanks!
<lilyp>If it's not something unusual, you might even submit that patch to Guix proper
<jaft>Hey, Guix; is anyone here running the MPD service, any?
<apteryx>jaft: I am, with limited success
<jaft>Welp; there's very little I want of it (just a local setup) so you might be able to help me. What makes your success limited?
<lechner>Hi, why can QA not apply these 37 patches, please? ("sha1 information is lacking or useless")
<peanuts>"Issue 67963 Guix Quality Assurance"
<lechner>the patches rebase without incident onto master
<rekado>jaft: I’m running it successfully on a headless machine with ALSA only.
<rekado>(though I’d like to switch to pipewire eventually)
<dthompson>pipewire is very appealing but I haven't tried it yet
<dthompson>right now I have a laptop for pulseaudio stuff and another for jack stuff lol
<jaft>rekado: Mmm; unfortunately, my problem is stemming directly from not being headless. I'm running it as my user but, otherwise, the standard out-of-the-box setup and, even with a pulse output, I have this weird split between the rest of my system and MPD.
<jaft>On boot, – if I play a song via MPD first – no other program has audio working. If I start any other application which uses audio first, MPD can't seem to use the audio and I hear nothing from it.
<jaft>I'm at a loss as to what might even be causing it so was hoping someone else had it working and could give insight as to their setup.
<ieure>jaft, Don't have MPD running under Guix, but I am running it on a Debian box. It sounds like your MPD is using ALSA directly, which prevents anything else from accessing the audio device. I admit it's been a good while since I had to care much about this, but my recollection is that only one program at a time can use ALSA to output audio, which is why there's a proliferation of userspace mixer/muxer things (jack, pulseaudio,
<apteryx>ACTION tries 'mumi send' again to send a small series
<ieure>The situation is extra complicated because many of the mix/mux type things also support outputting through another mixer/muxer, so you can do things like have jack output to pulseaudio, except it's really pipewire. wheeeee
<jaft>iseure: See, those were the only cases I could search for that came up that matched what I was seeing; but I'm not using Alsa (leastwise, I don't think…)! The Guix manual says PulseAudio is the default output and I didn't modify that part, any.
<jaft>ieure: welp; got that username wrong. Sorry about that; haven't slept any, yet.
<jaft>I even checked the generated config. to make sure and its =audio_output= section has ~type "pulse"~.
<ieure>jaft, Ah! You're running this as a system service, though, yeah? It runs as your user, but it's not a home service / part of your post-login setup?
<apteryx>jaft: if that helps, I have the same situation on my end
<apteryx>if I want to use mpd, I must it it first
<apteryx>otherwise you have to pkill pulse and pray it'll work
<apteryx>not exactly great
<apteryx>what would solve that would be running it in your user session, via a guix home service
<apteryx>I'm not sure one has made the service for it yet
<jaft>ieure: Yep; I'd first looked for a home service but didn't see any so went with the system one.
<apteryx>I think that'd be the least convoluted solution
<apteryx>(port the mpd-service-type to a mpd-home-service-type or similar)
<apteryx>you may want to ask in #mpd;
<apteryx>last I did I think the use case of running mpd as your user but outside your user session was not a supported use case
<jaft>apteryx: People have hacked together ones; if you search Reddit about it, you can find a few examples. I've just hacked together self-made solutions for my current config. that I'm trying to avoid adding any more (for up-keeps sake, if no other reason).
<apteryx>it's either for headless systems where mpd is the sole audio user, or running inside a user session, not outside of it
<apteryx>I've tried things too, but they didn't work
<jaft>Makes sense; maybe I'll relook at a home service, then. If I feel confident enough about it, maybe send a patch.
<ieure>jaft, What I think is happening is that when MPD spawns from the service and tries to connect to PulseAudio. And that either spawns one running as root, which prevents your user session's pulseaudio from talking to ALSA; or it spawns one as your user, but it can't set up the socket path.
<ieure>If you're using the machine interactively, I agree that porting it to be a home service (and maybe sending in a patch) is the right path forward.
<apteryx>jaft: if you get to it, I'll be happy to review (and perhaps it'll finally tip my config toward guix home :-))
<ieure>I'm less certain about the solution for a headless box. Mine is using a systemd linger service, which means MPD spawns dynamically as my user when I first connect to it. But I also have a RasPi dedicated to running MPD, so it talks to ALSA directly and I don't even have pulseaudio installed.
<apteryx>our mpd-service-type is fine for headless solutions
<apteryx>and it kind of works if you run it as your user with the right permissions on the music folder
<apteryx>as long as it plays some music first
<apteryx>before any other sound application
<apteryx>civodul: how frozen is core-updates at this time?
<ieure>Not the ringingest endorsement.
<rekado>I’ve set up dmix to allow other applications to output to also even as mpd is playing
<lilyp>I think we should touch up the mpd-service-type so that it can function as a home service.
<lilyp>I'm currently rolling custom shepherd code because it's easier than dealing with whatever you just wrote in the IRC
<rekado>but let’s please not remove it as a system service. It would be annoying if I had to get a user session on that headless server before I could use it as a media center.
<lilyp>Oh, sure, I meant it more like make it so that the existing service serves both purposes.
<lilyp>I don't want to take away your headless pulse/alsa-only MPDs :)
<rekado>(no pulse, just alsa)
<lilyp>speaking of which, wasn't this already a reasn for bruno's MPD patches?
<podiki>speaking of sound stuff, if i wanted to move to pipewire i see we have a home service
<podiki>do i need to make sure anything is present or removed from the system configuration for that to work properly? (haven't tried yet)
<podiki>I have a pulseaudio service in my config for a setting, does that stay or should be removed?
<dthompson>podiki: also curious how we can use pipewire. I know nothing about it
<dthompson>(and don't feel like figuring it out anytime soon)
<sarg>for pipewire it's only this line in your home.scm: `(service home-pipewire-service-type)`
<rekado>…that’s all?
<rekado>shouldn’t we also install alsa plugins to redirect clients to pipewire? And can this not be done system-wide without a home service?
<sarg>it's done by the service, it installs ~/.config/alsa/asoundrc which does the redirection
<rekado>why a home service, though?
<rekado>we’ve got an alsa-service-type for the whole system
<sarg>no idea, but I prefer running things under my user
<dthompson>yeah I'd expect a system service for this
<dthompson>I don't have to use guix home to use pulseaudio
<lfam>Do we have a current "standard" for archiving of non-versioned support data for packages? For example, map data that is required by a mapping program, but provided by a third party?
<lfam>Like, or similar?
<rekado>we’ve used in several instance
<lfam_>It's fun, this site has versioned URLs for the old releases, but not the current release
<PotentialUser-54>Hi. Until now I installed it on Qemu- KVM. Everything worked.  When installing for hd :  “substitute: updating substitutes from ''... 0.0%. guix substitute: warning: connection failed:     ”                 What can be done to fix this           sory, using ubuntu touch web
<rekado>PotentialUser-54: do you have internet access on your machine? Is this wireless? If so, your network card may not have blob-free drivers, and so you’d need to either use wired internet, tethered wifi, or use the vanilla Linux kernel.
<PotentialUser-54>Other packages are being downloaded
<futurile>PotentialUser-54: what about guix build --source qemu - or whatever the package is
<PotentialUser-54>All packages are loaded except: substitute: updating substitutes from '
<futurile>PotentialUser-54: what does guix weather qemu (or whatever package this is show you) - maybe it's not built for your architecture at the revision of guix you pulled
<futurile>I'm on boring x86_64-linux and qemu is available as a substitute from and according to guix weather
<peanuts>" Build farm"
<PotentialUser-54>I'm currently installing to my hard drive. About qemu KVM he said that everything was installed there and worked . System 32 bit, downloaded i686
<futurile>PotentialUser-54: so running "guix weather qemu" says something like: -> 100.% substitutes available (3 out of 3) ?
<lfam_>What do we think about the directory structure of a package's share/ folder?
<PotentialUser-54>“: so running "guix weather qemu" says something like: -> 100.% substitutes available (3 out of 3) ?” no Only writes: substitute: updating substitutes from ''... 0.0%. Now I'm trying another system, also 32 bit. If the same happens, I’ll write in the chat
<lfam_>Should it go like 'share/foo/blah.txt', or should it always be 'share/foo-1.2/blah.txt'
<lfam_>Like, when do we version that directory, and when don't we?
<futurile>PotentialUser-54: what if you try: guix package --substitute-urls= --install qemu
<peanuts>" Build farm"
<lfam_>PotentialUser-54: Are you sure that you're online?
<futurile>PotentialUser-54: definitely a weird one :-(
<futurile>have to go - late here - night all
<apteryx>hm, 'mumi send-email *.patch' failed to detected the debbugs reply
<apteryx>to detect*
<apteryx>oh, it really hasn't arrived yet