<djeis>So like, I have a library called libdedisp. It needs to use this GPU, the only way to use the GPU is by way of a userspace library. It dlopens that userspace library, without care about library version numbers, because it wants whatever version is associated with the currently loaded GPU kernel module.
<lechner>wouldn't the version matching resposibilty reside in the user-space module (which you call the library)
<euandreh>Can I do a "guix pull" only for a single channel?
<euandreh>Say I have channels "xyz" and "guix" in my channels.scm file
<euandreh>How could I update only the "xyz" channel?
<euandreh>If I duplicate the "xyz" channel into a dedicated file, guix pull complains of the file not having a channel called "guix"
<lechner>Hi, how can an inherited package definition refer to the outputs, please?
<euandreh>lechner: in the same way the original package definition refers to outputs
<nckx>euandreh: If you specified a channel without ‘guix’, the resulting new guix command wouldn't contain guix — which is impossible and therefore forbidden. There doesn't seem to be an easy way of doing what you want, a --do-not-upgrade equivalent for channels. You could hard-code the (commit "…") for the guix channel in your channels.scm.
<nckx>If you really want the --do-not-upgrade behaviour, keeping whatever commit is current without writing it down in a file, here's a terrible way to do so:
<euandreh>nckx: ACK, hard-coding the guix channel makes sense, I didn't consider that. I was hoping for a more ergonomic "guix pull -c xyz", that kept all channels as is without needing to do something else
<vagrantc>lechner: it doesn't just pick modules from the store, it picks them from the operating profile, environment, etc.
<nckx>Whichever store directory is either embedded into the Guile binary you're using (or transitively in one of its libraries), or is present in a variable like GUILE_LOAD_PATH, or is linked to a global location like /run/current-system/profile/lib.
<vagrantc>nckx: soon we'll have to add /usr/bin/sh :P
<oriansj>well there is the disagreement over if one should (service special-files-service-type `(("/bin/sh" ,(file-append (canonical-package bash) "/bin/sh")))) or (service special-files-service-type `(("/bin/sh" ,(file-append (canonical-package dash) "/bin/sh"))))
<vagrantc>yeah, the full-source bootstrap for guix is kind of the most amazing feat i've heard of in years
<lechner>so how do i build with a particular Guile module, please?
<oriansj>now we just need someone crazy and retired; with a lifetime of programming hacks to make smaller binaries, we could get M0 to fit in an MBR.
<vagrantc>lechner: package the guile module, list it in inputs for whatever else you're building?
<nckx>I have this particular cognitive dissonance about the Guix/bootstrappable bootstrap where it's both ‘this can't actually be as amazing and fundamental as I think, because that's herculean and literally everyone would be raving about it on-line’ and ‘…nope, that really is what it does, wow, why no CNN’.
<lechner>but it's suppoed to go into 3.0, except -wm does not find it
<nckx>I'll let you know when it finishes. But the file you pasted to <https://paste.debian.net/1242048> results in /gnu/store/spd4qvagh2fy4mjjizbv2q55scci4s78-guile-xcb-1.3-1.dd9a6ac. The others aren't relevant to it.
<nckx>Not because of the name. You could call xcb ‘guile-beefcake’, plug it into wm, and it would work. You could call it ‘guile-xcb’, *not* plug it into wm, and wm will never be able to see it. The name doesn't matter.
<lechner>replacing all the occurrences in the parent definition is cumbersome. is there another way?
<nckx>lechner: You'll have to manually patch it with something like (add-after 'unpack 'patch-shebang (lambda* (#:key inputs #:allow-other-keys) (substitute* "guile-wm" (("/usr/bin/guile3") (search-input-file inputs "bin/guile")))))
<nckx>Why? Because the default patch-shebangs phase that magically runs for you can only replace shebangs that are in $PATH, and there is no package with a ‘guile3’ binary anywhere in Guix (guile@3 is still just ‘guile’).
<yarl>Before my patch this runs childEntry that does sets up the environment then exec.
<yarl>After my patch this runs reaperEntry that forks (via startProcess, I would rather use plain and simple fork, I would rather a daemon in C (a guile daemon is planned?), not C++, that's just me.) Parent is the reaper (pid 1), child sets up the environment then exec.
<yarl>So when you hit childEntry (reaperEntry), you are already in the pid namespace, due to clone().
<cbaines>nalaginrut, the package definition specifies guile-2.2 as a propagated-input, changing that to a guile 3 package looks to be the main change
<nalaginrut>so it has to be released from the upstream, right?
<tricon>nalaginrut: i am presently utilizing guile-dbi in a project. iirc, it doesn't build with a meager change from guile-2.2 to guile. i think it needs further repackaging. haven't had time to update it and submit a patch.
<tricon>nalaginrut: you could copy the package definition and modify accordingly.
<tricon>fwiw, i ended up just making a profile for guile-dbi to run against guile-2.2 and its deps.
<nalaginrut>is it possible to make a local file and overload the guile-xyz.scm ?
<civodul>cbaines: my authorized key in maintenance.git is an RSA one; could you check whether those are rejected?
<cbaines>civodul, I think the key I'm using is an RSA one
<nalaginrut>tricon: I just copied (define-public guile3-dbi ...), but it seems not work
<nckx>pashencija[m]: For context, both ‘bugs’ and ‘patches’ end up in exactly the same place (both at debbugs.gnu.org and issues.guix.gnu.org) and share the same # namespace. The only miniscule difference is that sending something to -patches marks it as having a patch attached.
<peterpolidoro>hi, I am trying to trying to write a guix package for a pypi package and it is unable to find the tests. I tried replacing check with (invoke "python" "-m" "unittest" "discover") but it is still unable to find the tests. when I run "python -m unittest discover" in a python virtual environment rather than in guix then it finds and runs the tests as
<nckx>pashencija[m]: OK. You probably wouldn't be the first to type guix-bug after typing guix-patches. There's nothing I can do for you for now. You're not being moderated, so if it ever arrives, it will be instantly approved.
<nckx>peterpolidoro: And you're sure you're using the exact same sources (i.e., not guix building from PyPI and manually testing with a GitHub checkout, say)?
<peterpolidoro>oh you are right I am doing that. I am building from pypi and testing with the github checkout. Maybe the tests are not being included in the pypi download?
<pashencija[m]>OK. So either the message arrives or someone else submits a bug about GCC or I try it again tomorrow
<nckx>peterpolidoro: It happens unfortunately frequently (and I feel like increasingly) that they are not ☹
<nckx>pashencija[m]: Sounds good. Sorry, I wish there was something more I could do.
<nckx>We don't have access to the gnu.org mail servers proper.
<nckx>peterpolidoro: Look at the output of ‘guix build --source <your package or -f scm>’, it's exactly what Guix will use.
<nckx>If the tests are missing, you'll have to use git-fetch from the development repository.
<peterpolidoro>oh I think you are right, thank you! I will change it from a pypi pull to a git-fetch and see if that fixes it
<attila_lendvai>is this only me? i'm seeing: ntfs-3g: Could not load plugin /gnu/store/r1avamwgm5v39f4n717ip4cdn3rfvfjr-ntfs-3g-2021.8.22/lib/ntfs-3g/ntfs-plugin-8000001b.so (the file is not there). my toplevel issue is that ntfs partition is mounted read-only.
<nckx>Thanks to Erik, whoever they are here (if at all).
<jackhill>maybe it's time for me to dive back into understanding build systems. The last time I looked, it all looked like fog to me, but I bet if I do it again, I'll be able to make out some feature :) Thanks unmatched-paren nckx and #guix!
<nckx>Which keys are ‘valid’ at all is fully defined by the build system, pushing them into <package> record fields is very unnatural, although I completely understand why you suggested it.
<florhizome[m]>I would really like to have make composing build systems more convenient for example. Instead of having it in arguments, it would make sense to me to move it into build–system
<florhizome[m]>so you could either use a standard build system or use a procedure to compose one from existing ones…
<nckx>Yeah, multi-build-system packages — while possible and cool — are a big step up in difficulty for new users. It would be nice to streamline that.
<jpoiret>just sent my own patch for open-bidirectional-pipe, hope it can help
<vagrantc>hrm. when adding new packages to guix ... i always want to do something crazy like ... alphabetically insert it ... only to realize there's no such habit in general and it seems things always get appended to the end?
<nckx>civodul: I mean, I'll gladly write up a short message, I'm just not very optimistic that guix-announce@ or so will reach a meaningful number of users. It'll probably reach more ‘Linux blogs’ than users :) Unless you have a better idea.
<nckx>vagrantc: No, that's great. Appending to the end is discouraged.
<unmatched-paren>".DS_Store is a file that stores custom attributes of its containing folder, such as folder view options, icon positions, and other visual information" <- yep, sounds pointless to me. typical smack.
<pashencija[m]>lilyp: Wait, how else should I hide my potatoes from special services and shadow government?
<cocomeat4[m]>unmatched-paren: aka stuff that should be in a system config dir and not in the dir itself
<nckx>lilyp: Literally, or at least an accidental ‘feature’.