<elb>Hello friends! I have been using Emacs through Guix on a foreign system (debian) for a long time now, and it works fine, but I had never installed an Emacs package through guix, so I hadn't noticed that the Guix site packages weren't installed. I can't tell why they're not, and they're not there in `emacs -Q`, either. I noticed because I installed emacs-guix, but don't have any guix- commands; I checked my
<elb>I'm under the impression that this should be automatic; am I wrong? If I am not wrong, any ideas why it's not happening, or how to find out?
<elb>(Background is that I'm wanting to move from using `guix package -i` ad-hoc on a number of machines to distributing a known-good manifest and installing that, and that's causing me to try to learn a bit more about Guix; I was prompted by listening to Foss & Crafts' Guix 10th anniversary podcast while mowing the lawn yesterday!)
<nckx>But one is a whole lot easier to promise than the other.
<podiki[m]>nckx: so I made a variable rocclr-src for the needed source origin, and it is only needed to set a configure-flag (path to this source); is it okay to just refer to it as #$rocclr-src not putting it in inputs
<podiki[m]>nckx: that is to say it works of course, but stylistically, if it should be in the inputs also
<vagrantc>ok, i've catalogued most of the reproducible builds issues for guix.
<vagrantc>i'm sure as soon as staging is merged, there will be fun surprises
<rekado>civodul: clearly, we’re playing on easy mode!
<civodul>rekado: that's for sure! none of us at to get up at 3AM to hot-swap hard-disks and whatnot
<avalenn>cidovul: As I see it, the core of the problem is reputation. Too much trust is put on what is brought by packaging systems (cargo, npm, pip, etc.) but there is no easy alternative of establishing trust.
<avalenn>The thing is that "historical" package managers (aka. Distributions, like Debian, Slackware or Guix) were more trustable (thanks to being a bit more centralized and with known processes) but also considered too slow to bring latest versions and to difficult to use by modern programmers.
<rekado>I want to let mumi handle (some?) incoming email directly. I wonder if we should move issues.* off to a separate server.
<avalenn>cidovul: I am struggling to express myself on the subject. Not yet to the point of "ce qui ce conçoit clairement s'énonce clairement". I must still think about it. Thanks for the food for thought anyway.
<avalenn>Would like to hear about what you think the "social issues" are, at some point. But probably another day.
<civodul>avalenn: traditional distros, Guix included, only include packages after review; pip, npm, cargo take everything
<maximed>civodul: Maybe: use the delabelified package-names->package-inputs for most importers, and use the old one for crate / cargo-build-system?
<maximed>the old one could be removed after antioxidant
<nckx>bovid-19: Patch looks good, but I can't build it now. Nit pix: there should be a comment after (delete 'configure), usually 'no configure script' say it all, and descriptions should contain only full sentences. Not usually worth a v3 but if you're looking for an excuse to bump... :-)
<nckx>Maybe prefix the synopsis with 'Terminal' if that's its only UI.
<elb[m]>Good morning all. I asked a long question (above) about Emacs init on Guix, and I was hoping to get some eyeballs on it. The short is that I have installed Emacs via Guix and been using it for a long time, but recently discovered that it is not loading guix site-local packages (even with -Q). I am under the impression (from manual section 2.6.5) that it should. What might I be doing wrong?
<maximed>elb: Can you test whether "guix shell --pure emacs emacs-guix -- emacs" works, where emacs-guix is the relevant Guix package?
<elb[m]>The `guix shell ... -Q` exhibits the same behavior I see in my "regular" emacs: guix-emacs does not show up in list-packages, and cannot be required. $EMACSLOADPATH lists a directory that contains that file.
<scisssssssors21>hi. does anyone know if it's practical at all to put guix on a thinkpad t420 machine? i tried to do `guix pull && guix system reconfigure` and it's taking ages to build kernel. do i have to wait a couple of days after guix pull for substitutes to be built on ci.guix.gnu.org?
<podiki[m]>PurpleSym: I got a new camera so that inspired me to dig into darktable again, hence the dive into opencl. but looks like mesa might be able to handle more opencl directly in the near future which will be great
<podiki[m]>scisssssssors21: take a look at the guix weather command to check for subs, or yes, wait a little after a pull if there was a lot for the build farm to build
<podiki[m]>scisssssssors21: or if guix tells you it will build rather than download a lot, just ctrl-c to quit, nothing will have changed by design (atomic/transactional updates yay)
<podiki[m]>PurpleSym: not sure if you saw the earlier discussion yesterday, but any thoughts on rocclr? it no longer has an "install" in the makefile, meant to be included in other packages, so I was just made it a plain origin (to use in the opencl-runtime)
<PurpleSym>podiki: Yeah, I tried to upgrade rocm earlier, but got distracted. I also made rocclr an origin, because I couldn’t think of a better solution.
<PurpleSym>Weird design decision by AMD, but they must have their reasons.
<scisssssssors21>the only thing i'm missing in guix is signal messenger. does anyone know if there is a way to install it? i do not mind using unofficial client as i see electron apps are absent from guix repositories
<PurpleSym>I’m slightly worried by old old GPU won’t be supported any more after the upgrade.
<scisssssssors21>i do not really like the idea of using flatpak/snap and etc. especially in guix which has an awesome package manager
<podiki[m]>maybe there are other client possibilities using signald in the backend
<scisssssssors21>i might try packaging signal then, i've written a couple of package definitions for myself
<podiki[m]>PurpleSym: I had the opposite where I needed the new version so it would work for me :)
<podiki[m]>PurpleSym: on a stylistic front with a bare origin for rocclr, I only needed in a configure-flag (pointing to source location) for rocm-opencl-runtime; should that be included in the inputs then? even though I refer to it directly with #$rocclr-src?
<Guest11>I'm somewhat puzzled. I was here last week because i was unable to `guix pull`. The problem was some variable still referenced in ~/.cache/guix/checkouts. Now i've run in the same (?) problem again. I'm now on a different machine (guix system, 2 additional channels). Last time i simply deleted the checkouts cache which made `guix pull` run
<Guest11>successfully again - this time that trick doesn't work. The package (that is not part of Guix source anymore) is now libpng-1.2.
<PotentialUser-75>unmatched-paren what is the recommended "$out" permission model ? rw for all ? is it a common case ?
<unmatched-paren>PotentialUser-75: $out is short for the "out" output, which is somewhere in /gnu/store :) you can get $out with (assoc-ref outputs "out"), if you have it listed in the phase lambda: (lambda* (#:key outputs #:allow-other-keys) ...)
<maximed>n/quitPotentialUser-75: everything in the store is read-only
<maximed>except for the store items of the package that is being built, that's read+write
<podiki[m]>katco: what card do you have? I went down the rabbit hole of trying to find what was supported or not, but it is really not documented
<podiki[m]>katco: I decided to just try: I'm on a 6700xt and the newer rocm works for me
<katco>podiki: sorry, i don't really have time to discuss right now, but 5700xt
<podiki[m]>katco: no worries; I'll let you know when the patch lands (about to send), but I feel like you will have a chance in it working since mine does. hopefully
<katco>fingers crossed that it just works for my card too :) but i don't know when i'll next have a free moment to try. things are kind of crazy for me right now.
<katco>tysm for the ping on this. very thoughtful! :)
<podiki[m]>welcome! once that patch is merged (unless you want to build llvm locally) you can give it a shot, at least with rocminfo or darktable-cltest to see that you get something opencl working
<podiki[m]>your blog post helped me get to the right direction, so thank you too :)
<podiki[m]>and let's hope Mesa gets full opencl in the near future, make everything much easier
***mark_ is now known as mjw
<PurpleSym>podiki: I’ll have a look tomorrow and see whether 5.0 still works on my GPU, thanks again.
<podiki[m]>PurpleSym: no problem! if it did remove support for your gpu, guess we'll start keeping older versions...
<char[m]>What does an `failed to produce output path' with an empty build log mean?
<podiki[m]>I think that there was nothing built/made in the output path
<kaelyn>char[m]: a bit more detail would be helpful to diagnose the specific problem, but I believe I've seen that error when nothing was installed to the package's output path (in my case, from a broken custom install phase)
<attila_lendvai>so, i have a HP printer on USB, and hplip-minimal installed. in gnome settings the printer is detected, but installing it fails. this is in the cups error log: [cups-driverd] Unable to open driver directory \"/gnu/store/rwrmqxklbdq85lwjgjl56r9zh54066ra-cups-server-bin/lib/cups/driver\": No such file or directory. what am i missing?
*the_tubular Thinks we are getting closer to a 1.4 release!
<jonsger[m]>attila_lendvai ah that experience about gnome-printer-settings I could have told you :P
*jonsger[m] already signed up for Paris meeting :)
<attila_lendvai>jonsger[m], you mean it has a solution, or that it has never worked? :)
<jonsger[m]>that gnome-printer-settings had some issues, I didn't fixed them...
<flugo>hello folks! I have some software that I'm trying to package which only be built if the `.git` folder is present (the build script uses it for some version checking shenanigans)
<flugo>but when packaging and using `git-fetch`, that `.git` folder isn't present so the build fails
<flugo>this sounds like a problem with a known solution :)
<flugo7>it could be an X/Y problem and I'm misunderstanding something, but I can build the thing myself in a guix shell with the `.git` folder present, and that folder is absent from the checkout folder in the gnu store
***flugo7 is now known as flugo
<nckx>flugo: Instead, we tend to override such shenanigans to return the proper Guix package VERSION, for example with something like (substitute* "naughty-script" (("\"git --sniff-my-own-.*\"") (string-append "\"echo " #$version "\"")))