<valignatev>Hey #guix! I just got a permission error during the reset-gzip-timestamp stage. I've seen that many packages have added a snippet before this stage to their package definitions in order to make gzips writable. I don't quite understand the purpose of this stage and why all those packages are doing its own thing to adhere to it? Why is there permissi
<valignatev>on errors at all? I thought that guix daemon builds the packages in a sandbox where it has all the permissions
<rekado>valignatev: this happens with git-fetch as the resulting files are all read-only
<valignatev>My guess is that this stage has something to do with resetting tarball's state to the point it was before we started building it, but I'm not sure if I get it right
<valignatev>I don't think I understand what git-fetch has to do with it since it happens on a later point of the build
<alextee[m]>i usually embed some libraries in my code if many distros don't have them, and im thinking to just use this instead, but i think packagers will hate it
<wdkrnls>Hi Guix, I'm trying to figure out how to control the backlight on my laptop. Instructions on the internet suggest this is a rather involved process which entails making a symlink from my /sys/devices/pci0000:00/... to /sys/class/brightness, adding a section to my Xorg configuration, and possibly modifying my GRUB CMD_LINE.
<wdkrnls>I was curious if anyone had run through this process and might have figured out the configuration under guix.
<grillon>Sorry to ask that but the best way to keep environement variables as PATH after installing or updating (I have just installed a fresh system)
<valignatev>Hello-hello! I'm continuing to make a package definition that installs a package from master from the latest commit every time. I did it by replacing package (source (origin ...)) to (source (git-checkout (url ""))). But I still want to apply patches from the original package definition. I can obtain a list of patches with (origin-patches), but how
<snape>valignatev: actually you need to use git-fetch
<valignatev>snape: Can I use git-fetch to not fetch specific commit, but the latest one every time? I picked up git-checkout because it can accept #f as a commit argument and just checkout latest thing. If git-fetch can do this as well then I should be all set
<snape>I see... I didn't know about git-checkout actually
<snape>I initially thought you were talking about git-fetch
<valignatev>But what about applying some patches from the base package that I inherit?
<snape>my understanding (now) is that there are two compilers: one for <origin> (in guix/packages.scm) and one for <git-checkout> (in guix/git.scm). The former handles a 'patches' field, but the latter doesn't handle patches at all
<snape>valignatev: so what you could do is define a new compiler
<snape>that would work like the one in git.scm, and that would apply patches as well
<valignatev>I'm a total scheme noob. Like really, I started to learn it only about two days ago. It's magic how I can already read and write some stuff, but I don't think I can pull off a new compiler (or extend git-checkout)
<valignatev>Maybe I could try to extend git-checkout to be honest
*snape just succeeded building a package from an authenticated ssh git repository
<nixo_>In order to be notified for updates in packages I want to maintain, I wrote this script https://paste.debian.net/1120089/ that I run inside mcron. However, It seems to be using an outdated store.. any pointer on why that's happening?
***lurch_ is now known as optima
<nixo_>Ok found out, sorry for the noise. Btw, the script is simple but maybe can be useful to somebody
<raghav-gururajan>Folks! After gnome 3.32 update, fonts in gtk applications became weired. Mainly terminal. How do I reset/refresh the font cache?
<valignatev>civodul: Yes, I have this in my systemd unit. It has Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 in it. This directory exists and has en_US locales
<valignatev>I don't have this warning when I log in under root directly, only when I'm under my non-privileged account
<roptat>valignatev, do you have glibc-locales installed in your user profile?
<roptat>it could also be that the guix you're running uses a version of the glibc that doesn't match the version of glibc-utf8-locales
<roptat>since you don't have a warning as root, the daemon is running the same glibc as the one in root's glibc-locales, which is good, so maybe your glibc-utf8-locales is older than the glibc used by guix? have you tried updating it?
<valignatev>Running with GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale as a user fixes the warning
<valignatev>Does it mean that the daemon fails to obtain environment from systemd unit somehow?
<dftxbs3e>hulten, POWER9 is well supported across the Free Software eco-system, currently GNU Guix is a maturing distro and doesnt support POWER9, along with few other contributors, I am trying to get it to work. Also, the GNU Guix team is interested in purchasing OpenPOWER hardware for their CI build farm, they currently wait for an OpenPOWER VM to experiment on
<dftxbs3e>I use my OpenPOWER machine since a year now as a main workstation, I run Fedora.
<dftxbs3e>Why Fedora? Because Red Hat provides official support hand-in-hand with IBM, so Fedora is where all the software support comes first, and it works great!
<puoxond>Does anyone here use AUCTeX (emacs-auctex) installed with Guix? And if so, what happens if you do `M-: (require 'url)'?
<sylvain>Je cherche le dossier /usr/local/bin vous savez ou il est situe sur guix ? C'est pour mettre a jour youtube-dl
<dftxbs3e>hulten, for now, no. POWER9 is server grade. RISC-V is mainly mobile/microcontroller grade now.
<dftxbs3e>I bet on POWER9 because it has already it's High Performance Computing market, and it fits my workstation use case. With RISC-V, I would have to wait for some time until I can do the same thing.
<dftxbs3e>GNU Guix itself is functional, just GNU Hello wont build
<leoprikler>Given your rather unique situation it's a bit hard to tell, but it might work for GNU hello if you can get it to run.
<leoprikler>Oh, that can happen on standard Cuirass too, just not likely for GNU Hello.
<civodul>dftxbs3e: the patch should even be on master, no? it's pretty old
<dftxbs3e>civodul, I would expect that. So it's a similar issue, but somewhere else..
<leoprikler>But if the build itself fails, you should receive a failed status and be able to inspect the build log from Cuirass.
<dftxbs3e>civodul, I'm improving my CI so it's faster, then I can work comfortably on this.
<civodul>yeah, sorry that i don't have more specific advice!
<dftxbs3e>civodul, it's been so long I've wanted to get GNU Guix on powerpc64le-linux-gnu running.. I feel like you guys would've done this already since forever, it's just you don't have the hardware like me, and I'm inexperienced with both Scheme and GNU Guix!
<civodul>a simple workaround is to have Guile in the global profile
<snape>What I'd like to have is a 'proc' that takes as input (from Cuirass) a package + a revision, and gives (to Cuirass) as output a derivation of that package whose source is changed to that revision
<snape>but it's currently not possible because if I set sha256 to #f, the download doesn't happen, and if I can't guess the sha256 in advance
<snape>(I would have to download the source twice, which isn't good)
<civodul>not sure i understand the use case: you'd like Cuirass to test not-yet-packaged releases?
<snape>ok, well, git-checkout is specific to git, so I guess I have to rewrite it for other kind of sources
<civodul>yeah, it's also not ideal because Cuirass would be unaware of it
<civodul>you'd really need a Cuirass input if you want it to be able to trigger builds, keep track of commits, etc.
<civodul>but since you can have several inputs per job in Cuirass, that should already be workable, no?
<snape>yes, but in my case, the input (one git repository) differs from the source (the git repository pulls other repositories, like submodules). And I have a Guix package for that, so all I need is change the source uri
<snape>no, because there are other things to pull that aren't in that input
<civodul>that is, Hydra is responsible for fetching stuff, and then you insert it in your job
<snape>civodul: my Cuirass input is a git repositories that track the state of other git repositories. That first git repository is enough to know there is a change, but I'd need to download other git repositories to build the source
<rekado>I’d like to add a form to mumi to let visitors respond to bug reports and perhaps even submit a new one. No authentication, no captcha, just hidden input field and timing checks as abuse prevention.
<snape>my point is that Hydra/Cuirass should not be responsible for fetching. It should be Guix origin's job