<rndd>guix package --search-paths -p "$HOME/.guix-profile" also didn't help
<vagrantc>honestly, convincing people to switch to guix has some potentially undesireable consequences ... people are a bit change resistant, so if you convince them to use it, and something goes wrong ... they might forever blame guix
<rndd>soooo, my PATH "/home/user/.guix-profile/bin:/home/user/.guix-profile/bin:/home/user/.guix-profile/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
<vagrantc>as opposed to demonstrating the benefits of it, honestly describing the challenges, and letting people decide for themselves to experiment with it ... and decide for themselves
<viivien>What compelled me to use guix was how easy it is to self-host services. I was on debian before, and I must say that after half a dozen of "Oh exim/apache/dovecot/wesnoth/minetest/prosody services look cool,let’s set them up!" followed with some "well, that’s not very useful / the config is a pain" a few months later, I could not tell reliably which services were running, which were meant to be running and which were meant to
<apteryx_>mbakke: Hi! I think it was just refreshing the patch so that it'd apply to a newer version of NSS, from the top of my head
<apteryx_>mbakke: in any case, I don't have strong feelings about getting rid of that patch, if you manage to do without it (its purpose seem to have a .pc pkg-config file installed)
<sss1_>is it possible to have "guix pull" state shared for all users ?
<ecbrown>sss1_: the best i've thought of is one's own git repo for guix, where users pull from that. git admins can put new things in master, and everyone can pull to that. (vs. e.g. follow guix git, which keeps going and going)
<ecbrown>i can't think of a way around preventing e.g. guix ... --commit=
<abcdw>Do someone succesfully switched to pipewire on Guix System?
<abcdw>civodul: How are you doing? Have you had a chance to play with Guix Home?
<solene>I'm trying to play with "guix publish" but I don't have much results... on a new computer I've done guix pull --substitute-urls=http://192.168.1.150:8080 , I see some GET to the publish server but the new computer doesn't seem to enjoy the packages and download sources from the internet to compile it itself
<solene>this is not what I expected to be honest ^^'
<roptat>solene, did you authorize the key from that substitute server'
<abcdw>pineapples: Yep, seems working, at least pactl shows it. But I got this and few similar warnings: [E][000005067.483206][bluez5-dbus.c:2582 get_managed_objects_reply()] GetManagedObjects() failed: org.freedesktop.DBus.Error.ServiceUnknown
<yoctocell>civodul: If you already has things in ~/.config or ~/.bashrc it will create a backup directory ~/guix-home-legacy or something like that
<pineapples>abcdw: As for setting it up properly, you need to either uncomment a line that contains the `"-c pipewire-pulse.conf" }' string in the `$(guix build pipewire)/etc/pipewire/pipewire.conf' configuration file and have PipeWire read it somehow (I couldn't get this to work even if I placed the configuration file in my `/etc' directory) or to have guix home/shepherd start it like this: pipewire -c
<pineapples>pipewire-pulse.conf, which should automatically launch the `pipewire-pulse' binary
<yoctocell>or would be just say create a default guix home bash config if we see a ~/.bashrc file?
<abcdw>yoctocell: I got the patches, I'll try to handle them in next few days. Thank you!)
<yoctocell>abcdw: you are welcome! The run-on-change service would be nice to finish soon
<abcdw>civodul: We partially covered gradual migration to Guix Home topic during previous meetup, we already have an approach to do so by including already existing config files as a part of home service configuration (not a tool, just an approach for user). I can elaborate on that later, probably have to write it in the manual.
<civodul>abcdw: nice! yes, a section in the manual would be a good start
<vldn>guix install desktop-file-utils; guix install: error: opening file `/gnu/store/99px2khsxccbczbb2dzgjvjg3xsrfh8l-desktop-file-utils-0.26.tar.xz.drv': No such file or directory
<apteryx_>civodul: restarting guix-daemon on that offload machine updated it from /gnu/store/rsya5hkyq3fixl2r36lq2g892jadq1fc-guix-1.2.0-21.4dff6ec/bin/guix-daemon to /gnu/store/hgk21jf5plhijh7vdvyz81imsgn4887f-guix-1.3.0-1.771b866/bin/guix-daemon, for the record, and I could still trigger the crash :-(
<cbaines>I need to work out what the next steps are now
<apteryx_>civodul: yeah, still getting 'guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet.'; should I open an issue with it? I'll note the offload and head node guix-daemon versions, something else?
<nckx>ix: Was there… a reason you copy-pasted someone's join/part message last night?
<mbakke>raghavgururajan: what was the reason for enabling OpenSSL support in glib-networking (commit a1dd57ce83de42b115392816606e810d13864e41)? AFAIK it is discouraged, and Guix prefers GnuTLS when possible.
<civodul>apteryx_: yes, please open an issue; try to reproduce locally with offloading out of the picture
<mitzman>the uncultured questions that keep on giving -> if gcc-mesboot1 depends on glibc-mesboot0 (which has "disable-shared" flag), then why does gcc-mesboot1 try to use the dynamic linker? now it fails because it can't find ld-linux. does it build the .so even with disable-shared conf flag?
<bone-baboon>I am trying to use inetutils from core-updates because inetutils 1.9.4 fails to build for me. I have cloned the Guix repository. I have applied a patch to /gnu/packages/admin.scm so it has the definition for inetutils 2.0 from core-updates. When I run `sudo ./pre-inst-env guix system --no-substitutes reconfigure config.scm` or `./pre-inst-env guix build inetutils` it tries to build inetutils 1.9.4 instead of inetutils 2.0. Further I
<bone-baboon>want inetutils to be used as a dependency for all the other packages I build instead of inetutils 1.9.4. What do I need to do to get this working?
<roptat>jra, after the (begin, I think you can do (use-modules (guix build utils))
<rovanion>Any ideas as to why my guix environment created through direnv with the line `use guix --ad-hoc texlive --root=.direnv/guix-gc-root` gets garbage collected even though `guix gc --list-roots` lists it?
<roptat>the content of the builder is the whole file that's executed on the build side, it doesn't have access to the context of that file, so it doesn't import (guix build utils) by itself
<roptat>I think your profile contains the grafted texlive, so gc removes the ungrafted texlive, but then when you need to enter the profile again, guix needs the ungrafted texlive to know what it wants to graft, and notice it already has the graft
<jra>roptat: I got a different error "no code for module (guix build utils)"
<roptat>so it looks like gc collected your profile when it didn't really?
<roptat>jra, ah it needs to be available on the build side, give me a sec, I don't remember how you do that :p
<roptat>jra, I think you need to add another argument, that would be #:modules '((guix build utils))
<lfam>Bah, Guile 3.0.7 is failing to build on the ungrafting branch
<jra>roptat: I got a wrong ype argument: quote ... paste.debian.net/1200313
<roptat>oh you're right, there's no quote needed there, sorry
*lfam wishes that --clear-failures could handle multiple outputs gracefully
<roptat>ah nevermind, I read your error message too quickly, it had nothing to do with #:modules, if just shows it's running the content correctly, so go back to when there was to quote
<roptat>the issue is that "mpicc" is not found, and that's because there's no $PATH on the build side
<rovanion>roptat: Me not understanding again: Does the substitute not contain a fix number of hashes no matter the Guix version? If more information than just the hashes is used to then filter the hashes, perhaps that can be brought too?
<lfam>When you add a replacement field to a package definition, you have "grafted it". Then Guix knows that it should rewrite any "references" to the store items generated by that package definition with the store items generated by the replacement
<roptat>so... let's make a $PATH ourselves, in the let, you can define something like (path (string-join (map (lambda (pkg) (string-append (assoc-ref %build-inputs pkg) "/bin")) '("mpich" "gcc")) ":")) and right after the let, add (setenv "PATH" path)
<roptat>whenever you add something to the inputs, you'll have to add it to the list that defines path
<roptat>what we're doing here is, for each input specified in the list, look for it, append /bin (that's the map), and join each element of that list together with ":". That creates the content of the PATH variable, which we set later
<jra>roptat: looks like progress, new error: "gcc: error trying to exec 'as':execvp: No such file or directory". https://paste.debian.net/1200325 It looks like `as` is in the same place as `gcc`. Maybe execvp doesn't see PATH?
<lfam>I want to add a section "how to graft" to the cookbook but it's hard for me to approach with a beginner's mind
<raghavgururajan>mbakke: IIRC, it generates two libs and any software that uses glib-net can choose either of them. I thought if a project specifically looks for glib-net-openssl.so then it might be useful.
<lfam>There's another thing like that later in the text that needs to be adjusted
<raghavgururajan>mbakke: Hmm. I also didn't know that GnuTLS was preferred over OpenSSL. The latter seemed ubiquitous. Shall I make a commit to disable OpenSSL support? Revert will also disable libproxy support.
<lfam>I think it's a matter of taste within Guix. We like to use GNU software, although GnuTLS is not part of GNU anymore. OpenSSL is definitely better from a technical perspective
<lfam>There are some license compatibility issues with OpenSSL that should go away whenever OpenSSL 3 comes out
<bauermann>hello! I'm doing `guix pull --branch=core-updates` and in the process, Guix is building ‘texlive-amscls’. is there a way to make it not do that? I just want it to update the package definitions (and guix itself, of course).
<bauermann>I don't know why it is building that package. I've been trying to build it with `guix build` but I don't remember actually ever trying to install it...
<nckx2>Which exact issue, BlackMug[m]? Guix doesn't have the concept of conflicts or recommendations at all, so everything is 'fixed'. Package A either refers to package B or it doesn't.
<bauermann>also, in any case just to be sure I did a `guix package -d` and also `guix package -d -r .config/guix/current` to get rid of older generations of my profiles, followed by `guix gc`. so guix shouldn't have any reason to go and built ‘texlive-amscls’. I'm very confused about why it's doing that...
<nckx2>If Guix upstream has packaged A to require B, and you don't like that, you could create a custom A variant with (say) --disable-b if A supports that. But there's no 'Installing A will ask you whether you want B, and if so will treat B as a heisendep of A' nonsense like in Debian and I'm grateful for it.
<BlackMug[m]>issue if x distro base itself on debian then one want to remove a package which already coming by default with x distro the package wont be only removed but it will take other packages as well <- This scenario is mitigated by guixsd design or still face the same issue?
<lfam>bauermann: Presumable, texlive-amscls is a dependency of Guix itself, or it's required to build a profile. Building a profile is something that happens for `guix pull`
<nckx2>Removing a Guix package can't remove other packages. Guix doesn't work like that.
<rekado_>BlackMug[m]: nothing will ever be removed as long as it’s needed.
<nckx2>And there's no way to express 'package A is allergic to package B' so installing something won't ever remove something else either.
<rekado_>BlackMug[m]: Guix knows what needs to remain in /gnu/store because it has a record of all references.
<lfam>bauermann: If you only want access to the package definitions on core-updates, I recommend using the 'pre-inst-env' mechanism, as explained in the manual sections Building From Git and Running Guix Before It Is Installed
<nckx2>You're sometimes forced to update packages together because of propagation, but that's it.
<lfam>However, my understanding is that core-updates is currently unusable bauermann, so the only reason to try using it is to fix bugs and get it into shape :)
<bauermann>yes, that's the reason why I'm trying to use it :-)
<BlackMug[m]>nckx2: thats brilliant, just to make sure again it doesnt matter/effect if the package from guix level (userspace) or from the system level (root)? both will react as a independent and nothing going to effected if any package removed right?
<dstolfa>nckx2: i thought you actually hit a shark with your car...
<rekado_>bauermann: texlive-latex-amscls is part of texlive-base
<bauermann>lfam, I wondered whether it related to a profile. that's why I did the `guix package -d` thing. but for some reason it wasn't enough. The only package I have in my profile is ‘glibc-locales’ so I'm confused. I'll use ‘./pre-inst-env’ then. thanks for the tip
<nckx2>dstolfa: It's not out of character let's put it that way.
<lfam>bauermann: There is software used to create new profiles
<dstolfa>on another note... i find it extremely difficult to update the system when i have local changes i depend on
<bauermann>rekado_, ah, and guix depends on texlive-base?
<lfam>Texlive may be part of that group of software, bauermann
<lfam>yoctocell: I would build it with --keep-failed and poke around. I'm not sure if it's crashing on the last copy action that it prints, or something that hasn't been printed yet. But I would take a look at that final copy action and see if it could possible succeed
<lfam>BlackMug[m]: We are working on improving the availability of binary substitutes and fixing problems that break substitution, so that will help people using old computers with substitutes
<lfam>There's nothing we can do for people who don't use substitutes but want to use old computers
<lfam>If it were me, I'd skim gnu/packages/golang.scm to see if any other package seems to be working around this kind of thing
<lfam>I wish I knew how to make the backtrace print full filenames, instead of truncating them
<dstolfa>would it make sense (at some point in the future), let users opt it to binary only packages? perhaps the simple way to do it is to have a "release" branch which gets automerged into from the master branch once a binary package has successfully built or something along those lines?
<dstolfa>in case someone really doesn't want to build anything?
<yoctocell>Hm, I see that `go-github-com-alcortesm-tgz' has a `make-git-checkout-writable' phase, I will try that
<lfam>It sounds tricky dstolfa. The "release" branch would end up with a different order from the master branch
<lfam>I think we are on the cusp of a sea change, at least for x86
<dstolfa>fair, it was just a thought :). maybe at some point in the future it would make sense to poke at in a way that respects the ordering, but then i guess the question becomes: "what if the package *doesn't* build on the build farm?"
<lfam>It could be that the "release" branch is simply a delayed feed of the master branch
<lfam>I don't see how commit messages are relevant here
<dstolfa>well, if a commit message always mentions the thing that is changed, you could read the commit message and say: "right, package X is failing a build", and then when it sees "package X" being touched again with a passing build, it could fast-forward the branch to that commit
<dstolfa>but that seems incredibly fragile and susceptible to typos
<dstolfa>the idea is similar to Signed-off-by, but for say, packages
<lfam>The CI doesn't use commit messages at all when keeping track of failures
<lfam>I think I understand. You are talking about "fixing" a broken package
<lfam>You push to some kind of queue, the CI builds everything based on your change and, if it works, then your commit is applied to the real branch
<dstolfa>that means the CI is ahead of the actual repository and wouldn't need a delayed branch then, right?
<lfam>It could be a bit annoying, since commits might land on the master branch in a different order than what the contributor intended. But, that intended order would not ever be "canonical" (no pun intended), so it wouldn't really matter much
<lfam>I'd say it would be based on "pushes" rather than "individual commits"
<solene>I visited it but I don't really see what it provides except the arches
<jab>He lists the key, but not in a key file format...he lists it as the guile function (public-key ... ) How can I copy that guile code (aka where is the guile procedure (public-key) defined)....or how do I turn that public key into a file?