IRC channel logs
2024-01-17.log
back to list of logs
<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. <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>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>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 <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) <apteryx>ah! maybe! we could look at earlier versions to see if it's a regression <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>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>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?) <gibbs>hi, I am having trouble sending a patch to debbugs.gnu.org. My MTA reported 'all hosts for 'debbugs.gnu.org' 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>sometimes there are multiple of the same sometimes not <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.. <futurile>gibbs: send to patches@guix.gnu.org - that will create a bug - then you can send to nnn@debbugs.guix.gnu.org 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! <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 <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 <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 guix-patches@gnu.org and nnn@debbugs.gnu.org <gibbs>futurile, snape: I already got a bug number a few weeks ago. Now I can't send my changes to 67229@debbugs.gnu.org. <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 <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>105.3 MiB vs 120.5 MiB; It that size increase acceptable? <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? <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 <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. <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>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.. <francesco3>no then you have directly an object of type package <francesco3>so you can do: (cons your-package (map specification->package (list "pkg1" ...))) <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 <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") <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>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>In ef270f9d73203c1b19c6163ce4d4257a52bfb605, by... you? <weary-traveler>graywolf: so, --no-grafts certainly seems sufficient to make build work on emacs-team. unsure if it's necessary <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? <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. <redacted>What's the Guix way of extending a service's activation gexp? <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>I also want to chown it for the git user <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. <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? <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>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>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>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>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 :) <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>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>weâve got an alsa-service-type for the whole system <sarg>no idea, but I prefer running things under my user <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, archive.org or similar? <rekado>weâve used archive.org 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 'https://ci.guix.gnu.org'... 0.0%. guix substitute: warning: ci.guix.gnu.org: 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. <futurile>PotentialUser-54: what about guix build --source qemu - or whatever the package is <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 <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 <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: https://ci.guix.gnu.org -> 100.% substitutes available (3 out of 3) ?â no Only writes: substitute: updating substitutes from 'https://ci.guix.gnu.org'... 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? <lfam_>PotentialUser-54: Are you sure that you're online? <futurile>PotentialUser-54: definitely a weird one :-( <apteryx>hm, 'mumi send-email *.patch' failed to detected the debbugs reply