<kirisime>Do patches applied to package source need to apply perfectly? gnome-desktop-thumbnail-script.c is some three lines off around the point where I'd hope to change bwrap's arguments and I'm wondering if I could reuse the patch I have for nautilus.
<nckx>kirisime: No. What you're referring to is called ‘fuzz’ and it's allowed. As long as ‘patch -Np1 -i …’ accepts it, Guix should.
<nckx>3 lines changed is a bit much though, try it & see.
*nckx should've added --dry-run to that ‘patch’ example.
<mjw>mbakke, Thanks for the reply. But we are slightly out of phase. I'll need some sleep first. So will reply and update patch tomorrow.
<mbakke>mjw: hmm, good question, does not look like guix refresh supports outputs currently
<mjw>mbakke, also is there a magic (guile I assume) incantation to find all packages that have libelf as input?
<nckx>We tend to use grafts sparingy, mainly for security updates and other ‘very important fixes’.
<mbakke>mjw: unfortunately you would have to traverse the package graph yourself with 'fold-packages' :/
<mjw>mbakke, to answer your other question, I think guix should do what every other distro does. libelf is dead upstream for some years. Just use elfutils:libelf. They are API compatible (but not ABI).
<mjw>(of course I am slightly biased as upstream elfutils maintainer)
<NieDzejkob>I'm looking at fixing #38884 and some other issues around guix system switch-generation (and roll-back), and I think I need to have the operating-system object. Does configuration.scm in, say, /var/guix/profiles/system-42-link/ always exist, and is there a reason not to evaluate it during switch-generation?
<nckx>NieDzejkob: You can't assume that /etc/system.scm (or whatever) is a single file. That's only true for the most basic (dare I say ‘beginner’?) systems. It can depend on custom modules and files that aren't trivial to ‘enclose’ safely.
<nckx>Or that it even makes sense to evaluate it at a later date.
<kirisime>I now have a patched gnome-desktop package and would like to use it for all the packages that depend on gnome-desktop. Does guix have such a mechanism yet?
<nckx>kirisime: Yet? The current mechanism is input rewriting (in the manual), but it's been around for ages. If you mean something else: no. Not built-in.
<nckx>I guess it's somewhat similar to pkgOverrides in Nix, if that even still exists.
<nckx>NieDzejkob: Which information is currently missing to do what you'd like to do? And (if I read you correctly) why would you prefer to disable or avoid provenance tracking?
<NieDzejkob>no, by provenance tracking I mean that I wouldn't want my code to break when someone disables provenance tracking
<NieDzejkob>the information missing is the bootloader configuration, for one, see guix/scripts/system.scm:383
<roptat>now on to changing that default icecat configuration
<nckx>My view is that /etc/whatever.scm should only run once. Anything else is both too complex and too brittle. If the problem is that some of its output is thrown away when it later turns out to be needed (bootloader is a great example), that's what should be fixed. Serialise that somewhere.
<nckx>NieDzejkob: Oh, I would have said ‘Let's get a Fix Rollback Working Group going at FOSDEM 😉 Good night!’ instead of just ‘Good night’. That's all.
<nckx>raghav-gururajan: Please try to add comments saying which files/directories are covered by which licence, or in which circumstances which licence applies, or… However, try to keep them short. Plenty of examples in ‘grep -A5 '(license' gnu/packages/*scm’ I'm sure.
<nckx>madage: I must admit the carl build system is actually not that bad (\o/) but packaging this from source will still require packaging a SuperH toolchain first, like the htc firmware required an Extensa toolchain. Doable, just be aware that you'll be writing more than one package for this silly firmware file.
<roptat>if that firmware is free software, it should be in linux-libre, no?
<nckx>madage: You mean ath9k-htc-firmware? That is actually a good example: the meat is in creating the toolchain packages you see passed as native inputs (extensa for ath9k-htc-firmware, superh for carl).
<alextee[m]>Oh no, i just reinstalled guix and it still goes to grub rescue!
<nckx>alextee[m]: The game you are playing, if you choose to accept it, is setting $prefix to a value that makes ‘insmod normal’ start a fully-functional GRUB. If you choose not to play, I guess you can fiddle with your EFI set-up or reinstall GRUB or something.
<nckx>madage: Because the firmware does not run on your CPU.
<madage>so you are telling me that there is a cpu on the dongle?
<nckx>That's why building a little firmware file is such a huge undertaking, why the README says this will take a while (and 1.2 GiB of disc space), and why I first assumed you just wanted the binary blob for home use 😉
<NieDzejkob>[11:39] <000000NieDzejkob> sneek: later tell PotentialUser-52: though keep in mind that reconfiguring that adds or removes elogind will break sudo and login until reboot making rebooting a challenge. Keep a root shell open or remember how to use sysrq+reisub
<NieDzejkob>ahh, fuck, and I just wanted to save some typing
<NieDzejkob>sneek: later tell PotentialUser-52: though keep in mind that reconfiguring that adds or removes elogind will break sudo and login until reboot making rebooting a challenge. Keep a root shell open or remember how to use sysrq+reisub
<sneek>Welcome back PotentialUser-39, you have 2 messages.
<sneek>PotentialUser-39, NieDzejkob says: you need elogind too
<sneek>PotentialUser-39, NieDzejkob says: though keep in mind that reconfiguring that adds or removes elogind will break sudo and login until reboot making rebooting a challenge. Keep a root shell open or remember how to use sysrq+reisub
<zimoun>Naive question: I have a file containing an old R version (say 3.4.3 coming from say `git show cbe1314a7e:gnu/packages/statistics.scm > /tmp/stuff/old-stats.scm` + module tweaks), then `guix build -L /tmp/stuff email@example.com works. However, I would like to build the package firstname.lastname@example.org with email@example.com and `guix build -L . --firstname.lastname@example.org r-rcpp` does not work as expected because email@example.com is fetched
<zimoun>leoprikler: yes, I can write code that write code. But it seems better to be able to re-write any (implicit) inputs. For example, if I want to compile a R package with a specific R version compiled with a specific GCC verision.
<zimoun>Maybe it is related to "parametrized package" that Pierre is talking about. :-)
<leoprikler>no one is stopping you from adding explicit-gcc, explicit-clang, explicit-make, etc.
<leoprikler>you could add it in your own files, but you could also contribute it
<leoprikler>the thing about implicit inputs is, that they're implicit, as the name implies
<leoprikler>hence you don't know at the transformation level whether a given package actually needs that input or not
<leoprikler>consider e.g. you're building two packages, one with python and one with r
<leoprikler>you want to overwrite both the python and r version used respectively, but neither program should have the dependencies of the other as input
<leoprikler>with explicit inputs, you can do that, with implicit ones you can't
<zimoun>leoprikler: maybe I miss something... For example, "guix graph" shows all the inputs so the information is there. And do you mean with your example: build all python packages with gcc@7 and all R ones with gcc@8? And some packages depend on gcc so which version chooses? Do I understand you correctly?
<civodul>zimoun: you can try "guix graph -t bag" to view more details
<leoprikler>well yours would truly be impossible, even if you changed the order of operations
<zimoun>I understand it is consuming but I am not (yet?) convinced that it is not practical. I need to fail by myself. ;-)
<zimoun>NieDzejkob: it is a bit more complicated. Because the commit containing the R version 3.4.3 is older than the introduction of inferior, so "guix time-machine" cannot work. And even it would work, the r-rcpp version that I want is introduced to a new commit. Well, the inferior cannot help here, IMHO. And the solution is what leoprikler explained: re-write by hand by exposing the implict inputs that I want to re-write.
<leoprikler>rather than "re-write by hand" I'd suggest to say "re-write by scheme", as adding some input to a bunch of packages can still be automated to a certain extent
<zimoun>leoprikler: yes! sorry, that what I would mean. :-)
<jonsger>civodul: so guix is not yet ready to be built and used with Guile 3.0?
<zimoun>leoprikler, civodul: if parameters of the "build-system" is exposed, then does it help? For example, changing the version of the "compiler".
<leoprikler>After having seen the hell that is Gentoo, I'm certainly not a big supporter of parameters.
<roptat>zimoun: if you look at the python build system, it exposes #:python, which allows package-with-python2
<zimoun>and if I want to rebuild say the package ocmal-cudf with another compiler version, I need to write my own package using inherit and package-with-explicit-ocaml, right? And if it is a python package, it is package-with-explicit-python. But could we imagine something built-in and working for any build systems?
<leoprikler>looking at package-with-explicit-inputs vs. explicit-python, the difference appears to be in how they are introduced
<leoprikler>explicit-python, explicit-ocaml, explicit-r, etc. all would have to add keyword arguments on the fly.
<leoprikler>in order to deal with their respective build systems
<leoprikler>tbh. it would be preferrable, if all build systems respected #:implicit-inputs? #f
<zimoun>civodul, roptat, leoprikler: thank you the discussion. You helped me to clarify my mind. :-)
***ng0_ is now known as ng0
<nckx>There is no difference: en_US.utf8 and en_US.UTF-8 refer to the exact same codeset, but ‘utf8’ is the normalised one. Because codeset names aren't standardised and everybody uses slightly different ways to write the same thing (‘utf-8’, ‘UTF-8’, ‘UTF8’, …) and expect that to somehow work, glibc internally uses the lowercase alphanum-only version (‘.utf8’) which is always unambiguous. In Guix we tend to prefer the normalised .utf8 form but othe
<nckx>erikg: <en_US.utf8 doesn't seem to exist, so it's not surprising that setlocale won't switch to it> So now you know it is.
<nckx>erikg: The previous message was also meant for you.
<kirisime`>When I launch evince from the shell or by clicking a file in nautilus, some icons are missing. When I launch it from the application menu, all icons are present.
<lxsameer>hey folks, what's the easiest way to install a package from e schm file and debug the issues i might have ?
<kirisime`>lxsameer: guix install and guix build take the -f option for evaluating a file and operating on the package it returns, and other tools take the -e option for evaluating expressions where you can give a '(load "file.scm")' for the same effect.
<bricewge>Looks like I had a filesystem corruption and my store is in a kinda bad state with a lot of "error parsing derivation".
<kirisime`>lxsameer: Now you can do `guix build -Kf file.scm' to build the file and preserve the build directory in case it fails, and `guix environment --ad-hoc -e '(load "file.scm")'' to quickly place the resulting package in an environment to test it in.
<lxsameer>kirisime`: ok, i'm still a bit confused around some of the concepts
<bricewge>Out of luck? Like completely reinstalling Guix?
<nckx>bricewge: I don't know. I've kept backups of my entire store after my first brush with corruption like that (empty .drv files, I'm guessing?), now I treat it as valuable data, not something that can be easily regenerated.
<civodul>jonsger: also, do you have a way to reproduce the bug?
<str1ngs>sneek: later tell peanutbutterandc . as far as I can see tuxguitar is missing some plugins. probably minimum tuxguitar-alsa. these need to be added to the build. will try to figure out more when I have time.
<sameerynho>hey folks, I have this scheme file http://dpaste.com/2GHRAS4 and i'm trying to install `graalvm-mx` tool like this `guix build graalvm-mx -Kf gnu/packages/graalvm.scm` but I get this error with no traceback
*kmicu generally finds binary statements moved into fuzzy logic funny e.g. ‘Hi hon, I’m totally not pregnant tho I’m barely in the first week of my pregnancy’ or ‘our phone is fully open hardware, only n components require blobs’ 🤷
<nckx>jonsger: I mean, how would you run a non-default logind if dockerd silently pulls it in?
<jonsger>ah, got it. The other service dependencies are part of %base-services or so
<zig>re open hardware, is there anyone working with risc-v?
<kmicu>I do not plan to put Guix on My RISC-V with 128KB Flash, 32KB SRAM
<nckx>sammich: I'm not saying the Scheme interface is needlessly baroque (although I don't know either way), just that's it's not designed with interactive command-line/REPL one-liners mind & the command-line UI obviously is.
<kmicu>BTW could you limit your git commit messages to 10‑char‑long lines? Asking for a friend.
<dongcarl>I have a SiFive Unleashed, haven't set it up yet tho
<dongcarl>I'm guessing it's possible to get Guix running on it? Haven't tried bootstrapping to other archs yet
<sameerynho>hey folks, i'm trying to debug my package definition to why it doesn't work and to be honest i'm just looking for a traceback, how can i run the guix package command and ask for traceback on failures ?
<nixo>sameerynho: when you run guix build you see the build log. At the end of the build, it shows the path of the log file
<nixo>Also, if you want to inspect the state of the build folder, you can pass to guix build the "-K" flag (for keep). In the last lines you'll see something like: "note: keeping build directory /tmp/..."
<nixo>if you go there there's a file you can source to have the build environment variables
<sameerynho>nixo: ok that's the problem my build log is just a one liner