<apteryx>oh, thank you, adwaita-icon-theme: "PNG versions of the SVG symbolic icons are generated in 16x16, 24x24, 32x32, 48x48, 64x64 and 96x96 sizes if the gtk-encode-symbolic-svg tool is found in $(PREFIX)\bin, and the SVG GDK-Pixbuf loader is properly installed, which is obtained by building GDK-Pixbuf and libRSVG. The PNG versions of the symbolic icons are necessary if your app is a GTK-3.x app and you
<apteryx>are not intending to ship the SVG GDK-Pixbuf loader nor the libRSVG DLL (which are both required otherwise)."
<apteryx>basically, to generate the PNG versions you need librsvg. If you don't intend to ship librsvg, you need the PNGs.
<mala>so, how can I better understand why certain dependencies are being pulled down? I often get very strange packages being installed even as a result of a single, relatively innocuous-seeming install -- like, I'll end downloading subversion or the cups printing system for a command-line program. I'm curious as to what the closure is that requires these
<jackhill>mala: there's `guix graph --path package1 package2` to see how package1 came to depend on package2
<jackhill>depending on what you're doing you may have to download non-dependency stuf too sometimes such as the dependencies needed to build a profile containing your desired packages, but I don't if subversion or cups are ever needed because of that
<cjtenny>huh, when downloading substitutes only for bluez, why does guix download all the native-inputs for bluez instead of just the inputs?
<cjtenny>I suppose that's a much broader question than just bluez, probably something in the manual I missed. e.g. maybe even if you're not building anything, you still download all the build inputs for reproducibility?
<simendsjo_>Hi, I'm having a problem with using guix on a foreign distro. When running `guix pull` as a regular user, I get "Updating channel 'guix' from ..", and then `guix pull: error: Git error: malformed URL ''`. Running guix pull as root is working, but then my user won't see these. After running, I get an empty /var/guix/profiles/per-user/simendsjo, but
<simendsjo_>~/.config/guix/current links to a non-existing current-guix file. Running `guix install hello` will install properly and give me a profile, but no current-guix. Setting verbosity and debug flags doesn't give any additional information. Any idea what might be wrong?
<abrenon>but it doesn't work here, there must be another layer involved than just the keyboard layout
<rekado_>cjtenny: Guix only downloads what it needs. In some cases a package will embed references to stuff that’s really not needed at all at runtime. Guix can’t know the difference. It will always get all the things that are referenced.
<NicholasvonKlitz>Is there a known way to get flatpak and nix packages to properly locate .desktop files? I currently always need to run the from the shell `flatpak run ...` which isn't the best experience.
<abrenon>help ! someone is asserting that notebooks are a tool for reproducibility, that pinning the versions in requirements.txt is enough to ensure reproducible execution of code
<NinjaTrappeur>0/ In the context of https://lists.gnu.org/archive/html/help-guix/2021-11/msg00118.html, ekaitz and I are trying to understand how gcc manage to find its libraries from within a guix shell. We came to the conclusion that unlike Nix, Guix is not wrapping GCC but directly ld (via make-ld-wrapper) to resolve the dependencies available in the shell. First of all, are we correct? Is this what's really
<NinjaTrappeur>And of course, could you point us to a direction to perform the same "magic" for lua-jit?
<NinjaTrappeur>civodul: running git-blame on "make-ld-wrapper" is screaming your name :)
<rekado_>mothacehe: the log at /var/log/cuirass-remote-worker.log on my new aarch64 build node is empty. Is there something I can do to test the connection to ci.guix.gnu.org?
<rekado_>maybe some port needs to be opened on my router…?
<mothacehe>rekado_: what's the build node ip on the 10.0.0.0/24 subnet?
<rekado_>abrenon: version numbers are just a tiny fraction of what one would care about for reproducibility, so it is important to also include deployment in that story. There’s a jupyter kernel for Guix to help with that.
<rekado_>oh, /24? I gave it the wireguard IP 10.0.0.8/32.
<civodul>mjw: congrats on the Valgrind release! :-)
<KE0VVT>I'm still really impressed by the graphical installer and the ease of setting up GNOME with disk encryption.
<mjw>civodul, grin. Thanks. funny thing is, it was released last month, we just kind of forgot to announce it... :}
<apteryx>mothaceh`: the keepalives allow refreshing the IPs but that only works while the connection is alive; if the connection is severed and the ip changes (which often happens at the same time for dynamic IPs), then wireguard doesn't recover as it keeps attempting to use the previous IP (it doesn't reattempt to resolve the host name).
<apteryx>also, does upstream know about the lack of reproducibility?
<apteryx>if not, we should file an issue with them
<apteryx>LLVM at this point should produce reproducible binaries (it does for Rust)
<tricon>Say I need my webserver, which is a service, to have access to a Lua command. Is sub-packaging the web server with a dep on Lua still the best practice? Or should there be a way to define environments for services?
<KE0VVT>Waiting on the computer to add user and keyboard layout.
<rekado_>tricon: shepherd services can be given environment variables, so you could augment the PATH with that of a profile containing lua
<tricon>rekado_: Ah, that is a good idea. I had not thought of that. Thank ya!
<rekado_>(or you could give it specifically the lua package’s bin directory via a gexp)
<nckx>zimoun: --system isn't really cross-compilation, if that helps, it's an emulated native build (…OK that might not help, but it is quite different :). You can't ‘build --system=aarch64-linux’ something on x86 unless you set up QEMU. You can always --target=, which performs a traditional cross-compilation.
<zimoun>apteryx, nckx thanks. Once I read it, it is clear. But each time, I ask. :-)
<KE0VVT>shepherd: Service tor could not be started.
<zimoun>apteryx: about julia-* packages, it is long because… guess what… their test suite. ;-) Most are run sequencial. Here the attempt to improve the situation. :-)
<jbv1[m]>in the future what do you think about having a "parametrized" julia package that compiles a system image with the packages in the profile ? and what form should that take in guix in your opinion ?
<zimoun>jbv1[m]: yeah, we already discussed that, right? And I do not know. This “system image” is not clear for me. :-) Maybe it is a good idea
<jbv1[m]>not with me ;) the system image is a so file that has functions that have already been compiled
<jbv1[m]>since julia is JIT compiled, without a system image just starting the REPL would take ages
<jbv1[m]>so what is done when you build julia is it runs some common functions and records the compilations I think this is called "recording precompile statements" or something like that
<jbv1[m]>and what we could do is when we run the test suite of a package, we can also record the precompile statements then and use them to create a more complete system image
<lilyp>jbv1[m]: with "system image" you mean something like emacs portable dump?
<zimoun>jbv1[m], lilyp: the issue with julia sysimages is the composition. It is not clear for me. Well, bytecompile Julia is quite fast, the long part is test suite. Therefore, we could build and check the packages by CI; as we do now. Then, installing julia-* packages would create on the fly this sysimages. As jbv1[m] said «I'll think about it when I have some free time» :-)
<zimoun>apteryx I am killing my carbon budget, I am trying to upgrade Julia ;-)
<nckx>Sometime my Shepherd loses track of tor, so the service ‘fails to start’ whilst ‘pgrep tor’ still returns a thing. So I either let it run or kill it (follewed by ‘herd enable tor && herd start tor’) if I need to upgrade it
<cjtenny>rekado_: I thought the point of native-inputs was that they're only needed for building, allowing you to e.g. cross-compile substitutes. Does this mean that guix will always fetch all native-inputs even when substitutes are available?
<KE0VVT>Hm. I have Sway installed, but it does not show up in GDM.
<cjtenny>nckx: is there a way to force a reference when defining a package that does e.g. (load-foreign-library some-string) ?
<cjtenny>i'll put the bluez<-->cups curiosity aside for another day :P
<nckx>cjtenny: You'd patch it to load-foreign-library the absolute path, or, if that's not supported (never actually used that), use a wrapper that will set BLAH_LOAD_PATH so it can only load that exact library.
<nckx>Then you get the reference as a side effect.
<cjtenny>nckx: wrapper like (search-paths '(search-path-specfiication...))?
<nckx>You can create a reference simply by writing /gnu/store/foo to a text file in <out> but that's often pointless. Yes, Guix will make sure to download /gnu/store/foo when installing your package. What use does that have if your package doesn't hard-code /gnu/store/foo anywhere else?
<nckx>And if it does, that will incidentally create a reference anyway.
<cjtenny>ah, must have missed that section of the manual
<nckx>wrap-program does not seem explicitly documented. It doesn't do anything magical to ‘create a reference’ though. You have to first understand that references are just occurrences of a string, then most else falls into place.
<cjtenny>right, in this case what I'd want is (wrap-program "guile" '("GUILE_EXTENSIONS_PATH" ....), or something.
<singpolyma>Ideally one loads directly. wrap-program is a hack when you don't want to fix the ecosystem to allow that first and they already support an environment variable
<cjtenny>maybe when rekado_ is back they can comment their opinions on proper use of GUILE_EXTENSIONS_PATH for guix-packaged libraries as well
<Franciman>hi guix, if I want to load my patched driver, how do I tell guix about this?
<KE0VVT>Noisytoot: shepherd: Service tor could not be started.
<apteryx>lilyp: does 'guix-emacs-autoload-packages' works for you to discover a newly installed package? It used to, but perhaps with the subdirectiory entries it doesn't work the same anymore?
<apteryx>GNUtoo: 'guix pack' always create a profile in the pack
<fiesh>is there a preferred way to get certain function keys to control the display brightness? I guess I can hack together something with either xbindkeys or acpid, but of course I'd prefer to learn to correct Guix way if there is one
<podiki[m]>for the new swap syntax, if I had needed-for-boot on a btrfs subvol for swap, should that be replaced by the new swap definition dependencies?
<podiki[m]>same thing different place? or different functionality?
<lilyp>apteryx: it does exactly what it should, which is keeping old emacs as-is, but making newly spawned emacs use new packages
<lilyp>isn't this double-wrapping issue known already?
<lilyp>it's pretty common with glib-or-gtk-build-system for example
<unmatched-paren>i'm trying to package something in rust that depends on rust-anyhow, but even though i have (gnu packages crates-io) imported for some reason it tells me that it's an undefined variable?
<rekado_>I’m using ’guix deploy’ to build the aarch64 systems, and it fails (after building a lot) with this error: while setting up the build environment: a `x86_64-linux' is required to build `/gnu/store/awniiw0r5qji4njhycpv4h3saa7dap6v-activate-service.scm.drv', but I am a `aarch64-linux'