<roptat>also, I noticed two package have a source that doesn't exist anymore (thankfully saved on berlin). Should I update the package to change the source (without updating the package)?
*M6piz7wk[m] realized that bandali works in GNU so it's likely that his super power spreads across multiple rooms, but he decided not to use it lightly in case the power needs refreshing after it's been used to keep it for hard times
<mbakke>roptat: changing the source is good, if the file name does not change then it does not need to be rebuilt
<GNUtoo>hi, is there a way to know why a dependency is pulled in when doing guix system reconfigure ?
<GNUtoo>I've zfs that is being pulled in and I don't see why (grepping in guix source code doesn't show why either)
<M6piz7wk[m]><samplet> "For the record, Disarchive..." <- why though? Is it trying to optimize the compression of xz?
<samplet>GNUtoo: For a package, you can use ‘guix graph --path’, but I’m not sure about a system. What do you mean by “being pulled in”? Is it getting downloaded or does it show up in ‘guix gc -R’ or ...?
<samplet>M6piz7wk[m]: We have the uncompressed data, and we want to get the original, compressed data as distributed by the package author. Disarchive tries to store what it needs to recreate the compressed data without storing the whole package.
<GNUtoo>Ah I've found how by reading the mailing list
<GNUtoo>Basically gnome depends on the ZFS kernel module
<GNUtoo>And beside all the huge issue that module brings, it doesn't even compile on i686
<jackhill>but it is a tricky question with Guix since we try to blur the line for who is and isn't a developer, but if you hope to get your package included in guix, then -devel@ seems very appropriate.
<fcw>jackhill: Yeah, I noticed some packaging questions in help-guix.
<avp>Thanks, I can write Texinfo indeed, just didn't realise that the description can parse it.
<vivien>Is the 'autoreconf phase necessary? I thought the gnu-build-system could figure it out
<avp>Not sure about that, I shamelessly copied this part from some other Guile-related package.
<vivien>The guilesitedir substitution feels like kind of repetitive. Maybe you could use a for-each loop? (for-each (lambda (file) (substitute* file ...)) '("Makefile.in" "modules/gitlab/Makefile.in" ...)
<roptat>avp, vivien even (susbtitute* '("Makefile.in" "modules/gitlab/Makefile.in" ...) ...) or maybe (substitute* (find-files "." "Makefile.in") ...)
<jpoiret>sneek, later tell samplet: Just saw your gnome-shell patch, great! maybe we need to move away from gnome-shell/gdm as a default as its elogind integration is not great... I'll be looking into the greetd patches
<jlicht>rekado: would rebranding numpy 1.21 as python-numpy-next be workable solution? I doubt that there is much utility in offering a slightly more recent numpy by default over all the potential pain that you mentioned in your mail :/
<jlicht>* and then packaging numpy 1.20 as the 'default', naturally
<jlicht>Then we have defaults that work, and an easy escape hatch for folks who know what they are doing
<rekado>jlicht: I would like that, but on the other hand numba has had plenty of time to address this.
<nckx>remimimimi: You'd invoke the xset command in your session initialisation script/settings, which is where it gets hairy, because those tend to differ between desktop environments. For example, in my case I would have put it in ~/.config/i3/config or .xsession which were run when I logged into X, but it really depends.
<nckx>Regardless, it's a user setting that is not directly (or at least easily) configurable in your Guix system .scm.
<nckx>Maybe someone will prove me wrong and I won't even mind.
<nckx>(It's fine but sure, this is ‘expected’ to be a transparent back-end: you're ‘expected’ to run ‘mount -t foo’, although that will simply invoke ‘mount.foo’ anyway. Invoking it manually will always work.)
<KE0VVT>rekado: So, the ".cil" file in "/gnu/" did not work.
<florhizome[m]>Basically the functionality comes from the davfs Daemon you say
<rekado>KE0VVT: no surprise there. Look at when it was written.
<drakonis>florhizome[m]: i think guix as a project has to communicate that it won't bow down to the bad design choices from being a gnu distro
<rekado>the SELinux base policy of Fedora keeps changing. So you can’t use an application policy that was written several major versions back.
<drakonis>maybe make it a gnu project but not a gnu distro
<rekado>florhizome[m]: *is* it a package manager first?
<florhizome[m]>And that it’s not dependent on the os. Guix/nix are very different then Debian or arch.
<rekado>it does a whole bunch of things that are far removed from what the term “package manager” traditionally describes.
<florhizome[m]>rekado: Since you can use it on other operating systems, I would say yes.
<florhizome[m]>Imho guix os is guix as package Manager plus shepherd weaved together
<drakonis>being a gnu distro tacks on restrictions that guix does not need
<drakonis>nckx: maybe the problem here is that nix users have issues with including new repos
<drakonis>and the repo that provides the packages in question is a poorly kept secret
<KE0VVT>I have not tried adding the Devil's repo, but I'm sure it would not be hard.
<nckx>No need to allude. You can talk about vim freely here.
<nckx>But no, it's not. I don't know if it's official policy but Guix has never been about adding artificial hurdles to using/extending your system however you want to. Some GNU distributions have this reputation (I have no idea if it's deserved) and it rubs off on us.
<rekado>nckx: why does it take up to 10s to connect?
<kaelyn>Is there a way to change the subject line of an already-mailed patch? I sent out https://issues.guix.gnu.org/51957 for the core-updates-frozen sprint on Thursday, but forgot to adjust the subject to say it was for c-u-f before emailing it.
<kaelyn>(It fixes the build of xfce-weather-plugin on c-u-f by explicitly using libsoup2)
<nckx>kaelyn: Send ‘retitle NUMBER The new subject line’ as the body to control at debbugs dot gnu dot org.
<podiki[m]>in c-u-f news I rebuilt all my packages last night (the CI was GC-ing, and I was going to bed), all successful! except an emacs outside package I need to investigate (I think an xwidges/webkit thing)
<podiki[m]>drakonis: yeah, I was catching up there. Lots of nix folks (nice), debate over cpu microcode in typical HN tangential fashion
<sneek>samplet, jpoiret says: Just saw your gnome-shell patch, great! maybe we need to move away from gnome-shell/gdm as a default as its elogind integration is not great... I'll be looking into the greetd patches
<samplet>jpoiret: My guess is that many of the folks who currently use Guix would just as soon use something lighter than GDM to login to their Sway/i3/EXWM/hacked-together-in-Guile-this-morning desktop environments. :)
<podiki[m]>maybe we could change the comment in our webkitgtk-with-libsoup2 to note that it isn't jsut for gnome-online-accounts but a handful of packages
<jgart>How do rust releases get made in guix? For example, if I want to upgrade the rust version to the 2021 edition
<podiki[m]>samplet: I agree with this, I sorta started a whole thing the other day with being confused over how mutter was pulled in by gdm (I don't use gnome)
<samplet>jgart: I’m not an authority on Rust+Guix, but you could probably add a new Rust on the master branch. If you wanted to use that Rust to compile, say, librsvg, it would have to go to core-updates.
<nckx>Nailed it, although it's somewhat recursive: if you use the new Rust to compile not the older librsvg (2.40) with a zillion dependents, but only the new one (2.50) with 4, that could go on master as well.
<podiki[m]>yeah, could make the package available on main I think (rust-1.56 or whatever?)
<KE0VVT>I tried to say Guix and Nix both have their advantages, and that Guix has the advantage of using a real programming language for its package definitions, rather than mixing Perl and shell and awk with Nix language.
<jpoiret>KE0VVT: tbh i think the advantage of guix is that it truly lets you do whatever you want with it. If you want to code guix home, you can do so pretty easily. If you want to do containers by itself, you can, etc...
<jpoiret>also i saw the "guix is pretending not to be a fork of nix", they really haven't looked at guix beyond the homepage
<nckx>It is well-established canon fact that civo dul forked the Nix(pkgs) repos on GitHub, then rewrote each Perl and Nix file in Guile, line by line. It took years.
<KE0VVT>And I can't wrap my head around the Nix language, personally. It's not a real language.
<nckx>podiki[m]: We are less good at pretending to know a thing about something we know absolutely nothing about than some people, that is for sure.
<podiki[m]>hahaha well put and the source of many disagreements in the world
<nckx>KE0VVT: It was a fun training excercise in being forced to think a certain way, but it kind of ends there without the wide-open vista that a real language like Scheme (or Haskell, whatever) leaves you with.
<M6piz7wk[m]>What is the magnitude of the outer angle of an Isosceles triangle at any of its vertices
<nckx>I'm rewriting https://guix.gnu.org/en/contact/irc/. I'm surprised it links to a list with proprietary IRC clients. Although Free software is ridiculously dominant, which is nice :), I still think this is problematic.
<nckx>That's a separate issue with separate issue eyes.
<fiesh>after installing python-pynvim, I feel that `python3 -c 'import neovim'` should be working. it not working makes nvim's ":checkhealth" fail. am I misunderstanding something or is this a bug of the python-pynvim package?
<civodul>apteryx: hi! is it not a problem to mix gnome-shell 41 when the rest of the stack is at version 40?
<vivien>I noticed that at boot, I get: "/gnu/store/xxx-openresolv-3.12.0/sbin/resolvconf: line 824: mkdir: command not found
<vivien>Failed to create needed directory /var/run/resolvconf
<nckx>Wow, that is one very long sbin shell script.
<nckx>Could you file a bug, vivien? (A patch is fine too if you insist!)
<vivien>nckx, I’m planning to do that, but I didn’t want to lose the info in case my systems crashes to the ground ^^
<nckx>Straw poll to see if this is worth preparing a patch too: you're a journalist looking to hype up Guix 1.4 (we can dream!) but your puff piece is still missing a sick official Guix logo. You visit https://guix.gnu.org. Which drop-down item do you click?
<vivien>That’s so cute, openresolv has a bunch of tests to detect the init system and it even has an entry for guix :)
<vagrantc>while i know it clutters things up, i really appreciate being able to easily find both the stable manual and the latest manual on the website ... similar for downloads
<fiesh>is (service kernel-module-loader-service-type '("librem_ec_acpi")) supposed to suffice for loading this module (supposing the corresponding package librem-ec-acpi-linux-module is also listed for packages), or do I need to do something in addition since it's not working for me?
<nckx>vagrantc: It occasionally confuses users, so a way to make that even more clear would be good, but I agree it's good.
<roptat>arg, I'm trying to update coq, and it's now split into coq-core, coq-stdlib and coq. coq-core contains binaries and the core library. stdlib contains the standard library (coq files) and coq is a stub that is only here for opam, to depend on stdlib and core
<vivien>Noisytoot, Too bad that’s not the one indexed by duckduckgo (or bing)
<nckx>It's apparently copyrightable, which is nice.
<fiesh>(which would bring me to the next question: how to set values in /sys via guix's system configuration?)
<roptat>coq-stdlib and coq install stuff to lib/ocaml/site-lib/coq, but programs from coq-core need to find that directory, via $COQLIB, which is defined with (separator #f). It's set in the build environment, but to the wrong store path
<roptat>*** Error: coqdep: cannot find plugins directory for coqlib: /gnu/store/0rghkn3sw51y9n4q73yaygkp93nav82c-coq-8.14.0/lib/ocaml/site-lib/coq/