<nckx>I got that scary-lookin' thing twice whilst I was somewhere in the process of testing & switching to c-u-f. It hasn't occured since I completed that, and I assumed it was some ABI mismatch $somewhere.
<jackhill>I seem to not understand something about how to use gexps. I'm trying to use one to wrap a program like so https://paste.debian.net/1224360/ but I've done something wrong and get the inscrutable (to me) error: unbound-variable #f "Unbound variable: ~S" (gexp) #f
<roptat>jackhill, I'm not sure this is the right place to start a gexp
<nckx>I don't like that webkitgtk upstream is strong-arming distroes into ignoring gstreamer upstream's own assessment of this junk.
<jackhill>It is nice taht we have the gst-plugins/selection proc. things like webrtc is in -bad so I see why they want it. I just, yeah, wish the web weren't so terrible and that wich plugins they want were better documented.
<nckx>Right, I don't mean leave webkitgtk broken, just give it the minimum it needs. Seems like that's exactly your plan. Great.
<jackhill>Speaking of gst-plugins/selection, its docstring says "… Optionally, if CONFIGURE-FLAGS are given …", but it's defined as "lambda* (pkg #:key plugins configure-flags)" so something must be passed as configure-flags. I gave the empty list above, but perhaps that could be improved 🤔
<jackhill>sure, fortunately it's only used by pitivi currently and that passes #:configure-flags
<nckx>This is triggering extreme déjà vu, and yet I don't think I dealt with gstreamer lately. Must have been something very similar. Probably not the last such subtle bug with only 1 user waiting to be exposed.
<apteryx>python2 packages are expensive to keep working... let's get rid of it soon
***lukedashjr is now known as luke-jr
<jackhill>nckx, apteryx: progress, I've determined that the minium plugin from gst-plugins-bad needed to solve my tab crashing problem is debuguitls. Next: clean up my proof of concept and start a conversation on guix-devel@. For now though, sleep!
<eyJhb>mothacehe: Graphical installer doesn't work on stable, but it works on the latest you linked, BUT in that one it can't build some drv. So I ended up with using the stable, and instead not using the graphical installer
***nckx is now known as nckxmas
<jpoiret>eyJhb: do you know which derivation it wasn't able to build?
<mothacehe>because the installer point to the N-1 guix package
<jpoiret>how? In `gnu/installer/final.scm` I only see a `run-command` invocation with a usual `guix system init ...`
<mothacehe>yes but that guix is current-guix from (gnu guix package-management)
<zamfofex>Hello, Guix! I have recently been reading about Mes and bootstrapping, and it felt really interesting to me! I spent some time thinking, and I came up with an approach for boostrapping Guix using a minimal set of binaries and an existing operating system installation. No code yet, but I wrote my idea in a GitHub Gist and I wanted to be able to know what y’all might think about it, and whether it seems sensible or not.
<janneke>zamfofex: the thing is, in the very next step we will still use guile+gash and guile+guix, but remove the mes binary seed; in the next steps as you lay them out, the mes binary is re-introduced but now as a replacement for guile
<phf-1>A GUIX_LOCPATH is actually defined there. ll $GUIX_LOCPATH gives 2.31 which is different from the 2.33 of the `phf' user.
<mothacehe>jpoiret: if you run qemu on the latest installation image, and run "guix build guix" you will see that it tries to build the 15 guix revision. That's because the guix package 16 is a snaphsot of guix that embeds the guix 15 revision. So when running guix init ..., you are using the 16th revision to install the 15th
<phf-1>But still, the locals seems to be accessible for the daemon
<phf-1>*But still, the locales seem to be accessible to the daemon.
<mothacehe>which means that when the guix package is broken it needs to be updated twice, which sucks
<jpoiret>oh! i get it. that's a quirk if i've ever seen one :)
<mothacehe>hehe yeah quite terrible. The installer tests use current-guix to work around that and install the checkouted guix
<attila_lendvai>[git] i can't seem to find the answer anywhere: how can i do the equivalent of this (which doesn't work): git send-email email@example.com 4a9e702a86..8f7ffdf36a, or any other way to specify a range of commits that are below the HEAD
<nckxmas>attila_lendvai: *If* it's the same as format-patch: -NUMBER NEWEST-COMMIT
<phf-1>rekado: "$ strace guix" shows that it cannot find locales for 2.33 of glibc: https://paste.debian.net/1224405/ (I've done a `$ sudo guix pull') in the hope to update the root version of guix. Then, locales should be updated to 2.33.
<nckxmas>the_tubular: The opposite of monospace. It's not directly related, of course, but *in practice* techy monospace fonts put more emphasis on unique glyph shapes like I and l than many proportional fonts used for prose where it's less important.
<civodul>rekado: i've restarted mumi, which was apparently stuck in an infinite loop or something, with things like this in the log: Throw to key `match-error' with args `("match" "no matching pattern" (HEAD "52051"))'.
<jpoiret>i'd suggest namespacing your modules too, ie having "$repo/modules/f1refly/picom.scm" and (f1refly picom) (or whatever you might want to call it), since channel modules are actually merged with the guix tree
<jpoiret>i see you're trying to use the latest available picom commit, for that use case i'd really suggest using `guix install --with-latest=picom picom` or equivalent
<jpoiret>actually, --with-latest won't work since there's no new tag, sorry. `--with-commit=picom=<commit-sha>` will though
<f1refly>okay, I'll do it like that. And I'll put the next package definitio in a proper namespace
<f1refly>the package built went well but unfortunatly xorg still lags like crazy with the newest version :)
<jpoiret>heh. One more reason to switch to Wayland
<civodul>should we copy LE certs over rsync (on the VPN), until there's a "proper" solution?
<civodul>alright, i restarted nginx on both machines, and everything seems to be fine
<yewscion>Hello all, could someone point me somewhere that (wrap-program) might be documented? I'm attempting to modify a package definition to ensure a python library can find $GUIX_PYTHONPATH, but unfortunately I am unfamiliar with how that works. I'm combing through the sources now to find a good example, but I was hoping asking here might point me in a
<roptat>some ocaml packages have not been switched to the new style yet, probably because the labels are not exactly the same as the package name. I'd like to change that. Should I make it one commit per package, or a single commit? there's no functional change, except for ocaml-4.07, and the changes unfortunately affect the derivation
<attila_lendvai>these shepherd tests print all kinds of stuff, including error messages. no clue what is expected.
<civodul>roptat: if there's no functional change, and once you've made sure nothing breaks, i think it's fine to make a single commit
<roptat>ok, I think I'll make ocaml-4.07 a separate commit, just because I changed a (assoc-ref inputs ...) with (search-input-file ...)
<roptat>the rest is just changing the style of inputs
<roptat>is there a way to change the input style when the input is an origin record that I use in a phase?
<attila_lendvai>daaaaamn! the shepherd tests are running shepherd from the PATH, not the actual checked out codebase... the last thing i would have expected
<jlicht>attila_lendvai: how are you running the tests? If you get this behaviour /w `make check`, that seems like a mistake
<attila_lendvai>jlicht, i was just running them. i'm installing the autotools now. only now have realized that there's only a Makefile.am. i'm not very familiar with the auto* stuff (nor fond of them).
<yewscion>Quick Question: If a file with a package definition is pulling in python.scm, which exports (customize-site guix-pythonpath-search-path), how can I use that export in the aforementioned package definition? I want to avoid propagating python unnecessarily, but I need $GUIX_PYTHONPATH to be set to include the local libraries.
<unmatched-paren>how can i do a ./pre-inst-env sort of thing in my channel's working environment? is it even possible without cloning the guix makefile?
<robin>hm, 'guix upgrade texlive' dies with an 'integer expected from stream' error from the daemon. this should be fun to debug (initially i thought it was some more general problem communicating with the substitute servers)
<jpoiret>lfam: about the xorg-server patch, I don't use Xorg at all, sorry
<attila_lendvai>is gettext an assumed dependency everywhere, or the shepherd package is missing it in native-inputs?
<attila_lendvai>i can't compile shepherd. i'd appreciate if someone could update the README. it requires at least `guix shell gettext guile -D shepherd` and `autoreconf --install`, or somesuch. i'm clueless about these tools.
<the_tubular>I'm not sure I understand your question, isn't that how guix works fundamentally?
<zamfofex>Hello, Guix! Quick question: Would it be sensible to use the bit‐by‐bit identity of built packages on the store to determine compatibility? So imagine a package at ‘/gnu/store/aaa-hello-2.10’ has a dependency on GCC 10, and its definition is then updated to depend on GCC 11.
<zamfofex>But if the new ‘/gnu/store/bbb-hello-2.10’ is bit‐by‐bit equal to the previous ‘aaa-’ one, then dependencies of the new ‘hello’ package would’t be rebuilt, and instead simply copied over from the previous store path (if they are already available in the store).
<zamfofex>I feel like this would alleviate the need to keep package definitions intact (specially those with a lot of dependents), as long as dependent don’t change because of that.
<zamfofex>the_tubular: I think AIM[m] wants to e.g. ‘git clone’ a repository and ‘sudo make install’ it like they would in other systems, without needing to package it.
<zamfofex>lfam: That’s pretty much exactly what I suggested. I think an elegant solution would have been to consider the hashes of the built outputs of a dependency (rather than the dependency definition itself), but I feel like that would be a far more drastic change.
<lfam>zamfofex: So, Nix actually implemented this recently. I guess it's a hybrid of the two paradigms now? I don't really know the details
<lfam>If you search our mailing list archives for the terminology, I think there is some recent-ish discussion
<zamfofex>Also, another (perhaps more computationally difficult) thing that would also be really neat would be to infer grafts instead of explicitly defining them. So that if the output of a package only change by dependency path (in the same position within the binaries/outputs), a graft can be applied automatically. Though in that case, I suppose it would be useful to allow for the build farm to communicate that with clients somehow.
<lfam>zamfofex: Something to consider is that, at the time the thesis was published (2006), an intensional model was not useful at all. It was unreasonable to count on bit-identical outputs of builds, even when nothing had changed at all
<lfam>So, it's only through the efforts of Nix, Guix, and the reproducible builds movement that the intensional model is a viable option
<lfam>I'm not sure I understand your suggestion about grafts
*fiesh just realized there's no podman, only docker, in guix :(
<fiesh>well that leaves me with my seemingly unsurmountable sysfs problem... I can't believe I'm the only one facing it
<zamfofex>lfam: I mean if two outputs only differ by the store path of a dependency in their binaries, then the dependency could be considered interchangeable, and thus the build farm could let clients know that a graft can be made.
<zamfofex>When I say “the dependency could be considered interchangeable”, I mean the two paths of the dependency.
<jackhill>fiesh: what's your systfs problem (sorry, I wasn't paying attention earlier)?
<lfam>fiesh: It's definitely not insurmountable. But nobody has a "ready to use" example for you. Once can define custom services that can do anything you like
<lfam>It's definitely unusual to change permissions of sysfs, but changing values is normal
<jackhill>fiesh: oh yeah, I would use that to, I've just been lazy about looking into it :) For a minute you had me worried that there was something broken. It's sad to be missing a feature but less worrysome
<lfam>In general, you'll get the best advice if you say exactly what you are trying to do, rather than beating around the bush
<fiesh>lfam: idk, that was the only non-awful solution I found to adjusting my laptop's backlight -- by using xbindkeys and having a script that alters /sys/class/backlight/intel_backlight/brightness
<ns12>I noticed that some packages have a "release-monitoring-url" property in the package's "properties" field. What is release-monitoring-url used for?
<fiesh>KE0VVT: I tried installing a new display into my X220 and screwed up the soldering, hardware just isn't for me, so I threw it away and got a new laptop ;)
<civodul>ns12: hi! this is used by the 'generic-html' updater, for "guix refresh"
<PotentialUser-34>Has anyone ever encountered qtile not creating a .desktop file for the display manager? For context, all I did is put (specifiation->package "qtile") in my config.scm, and I did the same with a couple of other wms and had no problems with them
<KarlJoad>lfam: Just checked with the linux-libre log, no IPMI modules are removed. Good to know. Maybe my computer will shut off this time.
<ns12>civodul: Thanks. When is that property needed? I noticed that only some packages have/need it.
<civodul>ns12: it's needed for packages that (1) rely on generic-html to determine their latest version, and (2) where the default choice of URL is incorrect