<ggoes>when / how does guix load its emacs packages? i have emacs-geiser-racket installed for my nonroot guixsd user, but it doesn't seem to get loaded with emacs nor with M-x guix-emacs-autoload-packages
<Reinhilde>are errors encountered while executing 'guix system init' on a system other than Guix on-subject for #guix?
<Reinhilde>Do I need to un-authorize some or all substitution servers?
<Reinhilde>... I don't speak lisp... am I on the wrong system
<ggoes>hmm my user's .guix-profile isn't being added to $EMACSLOADPATH it seems; guess that's not automatic
<podiki[m]>it's fun having the whole system to mess with, barely touched packaging in other distros but find guix/scheme makes it very accessible
<lfam>The manual chapter Defining Package Variants is similar to Package Transformation Options but explains how to do it in a way that's easier to keep track of
<lfam>Agreed, I never was able to deal with packaging until Guix. I came from Debian and still use it as a base
<podiki[m]>yes, played with that a bit too and is very helpful
<podiki[m]>I've only maybe messed with a few basic pkgbuild changes on Arch, but never actually learned it. but put something in a Lisp and I'm all over it
<marusich>Making everything a monorepo makes it easier to discover everything.
<marusich>Also yeah, you can use the "package transformation options" or see how it's done internally to make your own modifications, but probably the easiest way to customize packages is to maintain a personal fork. Hopefully customizations can be upstreamed to Guix if they make sense.
<zamfofex>Is it possible to declare a modifiable variable within a package? The idea being that when modifying the package to create variants, you could modify that variable and have it affect all its uses.
<iskarian>another wonderfully general question: why do I only ever see phases used for patching rather than snippets?
<zamfofex>It feels unfortunate to me that there are multiple ways to do a similar thing: “patches”, “snippets” and “phases”. They are each slightly different from each other, and are more convenient for slightly different situations, but it’s unfortunate that there is no unfiied way to solve that kind of problem.
<lfam>Snippets are basically just for removing non-free bits from source code
<lfam>So that `guix build --source foo` gives the free variant of foo
<jackhill>zamfofex: in addition to what lfam said, both patches and snippets are for producing sources that is generally useful in many situations. It would be inapproprate to encode a refernece to a store path using those methods, but that's often nessisary and done during the build in a phase.
<jackhill>One could of couse apply patches during the build, but then guix build --source wouldn't "see" them.
<jackhill>I don't know if that helps, but maybe more insights will make it seem more ok for there to be the different methods.
<jackhill>also, phases aren't just for modifying the source, they're for arbitrary build steps, modifying the code is just one thing that could be done.
<jackhill>zamfofex: to your question of modifiable variable, I believe the answer is yes! I don't think I have the best grasp on it to explain clearly, but I think you'd just pass it as a keyword in arguments, and then look for it in appropriate phases of the package
<zamfofex>I see. That is all fair, I just feel like there is a lot of overlap, at least sometimes, and that can be a bit confusing.
<jackhill>zamfofex: you may want to search for what package-with-python2 does. Or the package with other common lisp procedures
<zamfofex>jackhill: About the arguments thing: I see! Thanks for the help, I’ll look into it.
<jackhill>zamfofex: cool, happy to (try to) help. Best of luck with your exploration
<Kitty[m]>Hmm, I notice the matrix client Element isn't on the default channel yet, couldn't find some others either ; anyone know of any which is?
<MysteriousSilver>Hello, I tried writing a package derivation after reading the cookbook. It was a fork of surf so I used the same scheme code as surf. Here's the full scheme file: http://ix.io/3svX Installing it fails and returns the following error: http://ix.io/3svL Any idea why?
<jackhill>Kitty[m]: yeah, Element is difficult to package because all the JS dependencies are for a difficult knot to untie. looks like quaternion, emacs-matrix-client, and nheko are available. I can't speak for any of them though. I get on matrix via xmpp and the matrix.org hosted bifrost bridge
<jackhill>MysteriousSilver: I guess it's not producing a sneedium file to install (maybe the fork is still using the surf name?). A good way to get debug this is to call guix build with the --keep-failed option. You'll end up with something in /tmp, and then you can cd there to see what files are there, and perhaps adjust the install phase accordingly
<jackhill>MysteriousSilver: yes, that sounds reasonable (or cd-ing before the cp, or doing it with a (with-directory-excursion …)), but it seems like that cp is being generated by the gtk-or-glib build system, so I don't know why it's getting it wrong
<zamfofex>Does anyone know whether it’s possible to try to build all packages using a different toolchain (e.g. a different C compiler or linker). (Probably in a server, I mean.)
<zamfofex>I’m mostly just curious, because I recently decided to package the “mold” linker for Guix, and it appears that coincidentally, someone did something similar, but with Nix to test mold against existing Nix packages and whatnot.
<irfus>re: updating mesa, does this channel have opinions on whether it is appropriate to build mesa with libglvnd support?
<irfus>libglvnd is already packaged in guix. And is completely free. And it seems like a good idea to have vendor neutral calls to video drivers in general. But this is practically useful, as of now, only to users with some nonfree graphics hardware.
<irfus>but switching comes with the cost of having to patch and rebuild every package that currently looks to mesa to provide libgl.so and friends
<irfus>I know there are at least a couple of mentions of this issue in this channel's archives, but there didn't seem to be a clear position...
<zamfofex>That’s interesting. I feel like it’s almost related to the question I asked. I think you want some way to have a different package e.g. “mesa-glvnd”, and be able to specify that you want to substitute the regular mesa by this new package in all dependencies, even if it means you’d have to build them yourself.
<zamfofex>Or, err... “dependents”, I mean, I suppose.
<Kitty[m]><jackhill "Kitty: yeah, Element is difficul"> wait, there is a matrix.org xmpp bridge?
<irfus>zamfofex: yeah, kind of. That is normally possible for a user to do with package transformations. Mesa has so many dependents, however, that it's not practical to expect users to actually be able to do that.
<zamfofex>Ah, I see. I suppose that’s not useful in your case, but it effectively answers my question. The ‘--with-input’ option is pretty much exactly what I wanted.
<zamfofex>irfus: Maybe it could be useful to be able to have downloadable substitutes for specific useful transformations.
<zamfofex>I think if that was possible, that’s solve your issue, no?
<leoprikler>guix gc --delete-generations only deletes your root user's generations IIUC
<leoprikler>not anyone else's generations and also not system generations
<rovanion>Yeah that seems right. If my brain fog clears up later today I'll see if I can construct some meaningful sentance for the manual along the lines of "Note: If you want to garbage collect system generations, look [[here]]."
<zamfofex>Hello once again! I was actually able to try out the mold linker through my package against some projects, though it seems it failed to build textinfo for binutils. The error is kinda strange, and I suspect it’s related to my system’s slightly outdated package listings (two weeks or so). I wonder if anyone here could have a quick idea to help me out, if it’s obvious enough.
<tissevert>just wanted that guix is saving my day, it lets me use ardour on my deeply broken devuan install where I can't install anything anymore
<dstolfa>tissevert: i guess the only way to fix it is to end up doing `guix system init` (:
<tissevert>on my todo list: I'll use guix system to generate VM image to get something useful and demonstrable to the other members of the family, maybe even something directly bootable on metal from a USB device ?
<tissevert>and I won't feel like I'm in a cybercafé all the time
<tissevert>(simply noticing btw that I had two profiles ~/.guix-profile and ~/.config/guix/current fighthing, and guix package -i ardour put it in the former while the latter was defined in my .bash_profile, but it's really probably just a setup error from my part when I installed it)
<dstolfa>am i correct to assume that emacs-next has --with-native-comp? it feels faster
<maximed>IIUC, cameras have a conventional layout for storage media (something with directories named ‘DCIM’)
<maximed>if you give it a (different) layout yourself, it is not unexpected that Shotwell won't recognise it
<maximed>though presumably Shotwell has some option for importing photos and videos from arbitrary directories, so you could use that?
<Noisytoot>maximed, They are all in DCIM, 2 cameras have used this SD card, one of them puts all photos/videos in DCIM/122MSDCF, and the other one puts photos/videos in directories named DCIM/<3 digit number>___<2 digit number>
<pushcx>It affects many phones, not just iphones. You can downgrade or wait a bit for the next version, which has a patch that's expected to fix it.
<podiki[m]>irfus: sorry for the duplicate messages, sneek was disappearing on me
<podiki[m]>irfus: yes, the libglvnd discussion...I'm not sure either, I was thinking we do Mesa to 21.1.x first without changes to build options, that should just work (at least the dependents I checked), and separate out the libglvnd question to another patch series
<lfam>More adventures with CONFIG_MODPROBE_PATH in Linux 5.13
<lfam>How is it supposed to work with LUKS encrypted disks?
<lfam>The paths /run/current-system or /sbin or whatever are not available before you unlock the device, but Linux needs to load some modules in order to do that
<thecatster_>I’m assuming allowing http instead of https connections should be a simple fix, or is it more elaborate?
<lfam>The problem with that is that Guix will consider it to be a different repository, and the code authentication machinery will not provide a "chain of trust" as you change from pulling over HTTPS to HTTP
<lfam>Instead, we can disable certificate verification when the --allow-insecure-transport option is passed
<lfam>This is still safe. HTTPS is not part of the code-signing security model
<lfam>We implemented this strict HTTPS certificate verification before we implemented code-signing, because it was easy and we didn't have anything better