Re: Avoiding rebuilds (e.g. of mariadb, the entire Rust chain, etc.)?
On Sun, Dec 26, 2021 at 11:41:30PM -0600, Matthew Brooks wrote:
> Is there any way to avoid rebuilding stuff like mariadb, the entire Rust
> chain, etc. unless one of those packages *actually* changes? It seems like
> every few days every single package needs to rebuild for some reason,
> including many packages that spend unbelievably long times running tests that
> will never actually be of use to me, so I'm usually only able to update every
> couple of weeks since so much constantly needs to be rebuilt and everything
> takes so long.
In Guix, packages are considered to have changed when any part of their
dependency graph changes. So, no, there is not a way to avoid rebuilding
a package when one of its transitive dependencies has changed.
We have guidelines about how to make changes to the distro that are
based on how many rebuilds they cause. See item 8:
https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches
Both MariaDB and Rust have several thousand packages that depend on
them, so we change these packages seldomly, and use the build farm to
rebuild everything in advance so that users don't have to.
If users choose to avoid substitutes, that's fine too, but there's no
way to avoid doing the work.
Recently, we deployed the results of a "core-updates" project, which
updated core packages, and caused every single package to be rebuilt.
So, that's why you are having to rebuild more than usual.
> It seems to have gotten worse over time as well, as more and more base
> packages pull in extremely computation-hungry dependency chains. At this very
> moment, for example, I'm waiting for Rust & co. to compile simply to delete
> old system generations from the bootloader.
Yes, Rust continues to grow in importance and has become a relatively
low-level dependency of the distro on the x86_64 platform. We are
continually finding ways to shorten the "bootstrap chain" of Rust, but
it's still fairly long.
> I've got substitutes turned off (primarily because I like the idea of every
> package being "home built" as it were), but I can't imagine that even the
> official substitiute servers would be able to keep up with the constant
> rebuilds my system seems to want unless I've got something horribly
> misconfigured somewhere.
The build farm has ~2800 powerful CPU cores for the x86_64 architecture,
so it can keep up. Other architectures are less well-resourced. And of
course very few users have access to those kinds of resources.
>(extra-options '("--gc-keep-derivations=yes" "--gc-keep-outputs=yes"
> "--no-substitutes"))
I would have suggested adding those first two options. Beyond that,
maybe others can suggest something that will help.
Re: nmtui - user authorisation
On Mon, Dec 27, 2021 at 10:07:17PM +, Paul Jewell wrote: > Solved this - nmtui needs to be run as root; my script which invoked the > program didn't consider that. Changing it to run as sudo gives me an > opportunity to enter my password, and then successfully setup the wifi > interface details. Another option is to add nmtui to the list of programs that are setuid. That way, any user on your system could configure wifi, which may be more ergonomic. https://guix.gnu.org/manual/devel/en/html_node/Setuid-Programs.html
Re: nmtui - user authorisation
Solved this - nmtui needs to be run as root; my script which invoked the program didn't consider that. Changing it to run as sudo gives me an opportunity to enter my password, and then successfully setup the wifi interface details. -- Paul On 27/12/2021 07:33, Paul Jewell wrote: Good morning, I am using dwm with network-manager for wifi setup, but the nmtui app doesn't allow me to make changes with a user level account. How can I configure it to allow a user level account to make changes to the wifi setup? Thanks all! Paul
Re: Foreign distro Unity desktop broken after guix update
On Mon, 27 Dec 2021 19:37:07 + Fredrik Salomonsson wrote: > printenv LD_LIBRARY_PATH Empty > env | grep /gnu/store Empty > Another reason why the runtime linker would pick up that library would > be if its path is added to the /etc/ld.so.conf configs. But I highly > doubt it's the issue. Via include, that makes for the following list: /usr/lib/x86_64-linux-gnu/libfakeroot /usr/local/lib /usr/local/lib/x86_64-linux-gnu /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu > If you want to go down the rabbit hole you can use the LD_DEBUG > environment variable to get some debug output. The libs option is > probably the most useful to you as that will print where it's looking > for stuff and why. Use: > > env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace Interesting, but I’m puzzled about how to use that with compiz/unity. > I hope that helps a bit. A good start. Thank you! -- Thorsten Wilms
Re: Foreign distro Unity desktop broken after guix update
Hi, Thorsten Wilms writes: > Unity desktop stopped working after the first ’guix pull && guix > package -u’ in maybe 2 weeks. There has been no update on the Ubuntu > side between the last succesfull run and now, as far as I can tell. > Unity desktop causes a few redraws, then exits back to the session > greeter (lightdm). > > Now I would have assumed that there is no interaction between Unity and > guix, since the former is entirely on the dpkg side. But via journalctl, > I found a whole lot of: > ``` > Dec 27 15:44:51 charly compiz[2198]: ERROR 2021-12-27 15:44:51 > nux.gltexture.resource.manager GLTextureResourceManager.cpp: > 54 Invalid target, impossible to generate a new texture. > Impossible to generate a pixbuf: Unable to load image-loading > module: > /gnu/store/2dza2psfbrrbvsni8jjqzzqx3hmm8kw8-librsvg-2.50.7/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: > /lib/x86_64-linux-gnu/libpthread.so.0: version `GLIBC_PRIVATE' not found > (required by > /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/librt.so.1) > ``` > > It looks like compiz segfaults shortly after a bunch of those, followed > by unity7.service. > > Any ideas why dpkg-compiz tries to use guix-librsvg and what to do > about it, or what else is going on here? Could be that LD_LIBRARY_PATH is set and includs path(s) to libpixbufloader-svg.so in the guix store which is causing the streams to cross. Try: printenv LD_LIBRARY_PATH and see what it contains or: env | grep /gnu/store to see if any environment variable contains path to the store. Another reason why the runtime linker would pick up that library would be if its path is added to the /etc/ld.so.conf configs. But I highly doubt it's the issue. If you want to go down the rabbit hole you can use the LD_DEBUG environment variable to get some debug output. The libs option is probably the most useful to you as that will print where it's looking for stuff and why. Use: env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace The LD_DEBUG_OUTPUT is a must as it will print out a ton of text. This will save the output to /tmp/trace.. You can tell it to print out a help text by using: env LD_DEBUG=help cat I hope that helps a bit. -- s/Fred[re]+i[ck]+/Fredrik/g
Foreign distro Unity desktop broken after guix update
Hi! Unity desktop stopped working after the first ’guix pull && guix package -u’ in maybe 2 weeks. There has been no update on the Ubuntu side between the last succesfull run and now, as far as I can tell. Unity desktop causes a few redraws, then exits back to the session greeter (lightdm). Now I would have assumed that there is no interaction between Unity and guix, since the former is entirely on the dpkg side. But via journalctl, I found a whole lot of: ``` Dec 27 15:44:51 charly compiz[2198]: ERROR 2021-12-27 15:44:51 nux.gltexture.resource.manager GLTextureResourceManager.cpp: 54 Invalid target, impossible to generate a new texture. Impossible to generate a pixbuf: Unable to load image-loading module: /gnu/store/2dza2psfbrrbvsni8jjqzzqx3hmm8kw8-librsvg-2.50.7/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /lib/x86_64-linux-gnu/libpthread.so.0: version `GLIBC_PRIVATE' not found (required by /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/librt.so.1) ``` It looks like compiz segfaults shortly after a bunch of those, followed by unity7.service. Any ideas why dpkg-compiz tries to use guix-librsvg and what to do about it, or what else is going on here? -- Thorsten Wilms
Devuan replaced grub and runs before Guix
Hello, dear developers! Merry Christmas and Happy New year!I would like to ask questions I did not dug in the web, I hope there are short answers.I had Guix OS installed on /dev/sda and i had grub bootloader there configured to run guix and devuan from another sdd, my config:https://gitgud.io/youni/guix-configs/-/blob/master/config-wpa2-wlp5-wf-blacklist--my-desktop-services--isp.conf#L91Everything worked fine, i could boot to Guix or choose Devuan from the grub menu controlled by Guix.But i made Devuan 3 to Devuan 4 upgrades. And Devuan replaced grub and now i have no guix in the menu.I think i can add Guix to devuan grub menu, but I'm not sure I can find /vmlinuz and /initrd files in the Guix partitions.I have 3 questions:1. How to boot Guix manually from grub command line?2. How can I add Guix OS to devuan grub menu, which files i need to use for linux image and initrd, where to find them on Guix?3. Can I easy replace back grub by Guix making guix controls grub again?Thank you.
Re: gnupg 2.2.29 -> 2.2.30 breaks symmetric decryption (and gpg-agent?)
Leo Famulari [2021-12-26T23:45:23+0100]: > On Sun, Dec 26, 2021 at 02:31:01PM +0100, Sergiu Ivanov wrote: >> Hi, >> >> I have just upgraded my Guix home on a Guix System, which took gnupg >> from 2.2.29 to 2.2.30. When I run gpg -v --decrypt on a file with >> symmetric encryption, I get the following error: >> >> scolobb@quark ~/tmp$ gpg -v --decrypt world.gpg >> gpg: AES.CFB encrypted data >> gpg: no running gpg-agent - starting >> '/gnu/store/0snfzd41n430ddpq316j9v2z5fn2y62m-gnupg-2.2.30/bin/gpg-agent' >> gpg: waiting for the agent to come up ... (5s) >> gpg: connection to agent established >> gpg: pinentry launched (3287 gtk2 1.1.1 /dev/pts/0 eterm-color :0 >> 20620/1000/996 1000/998 1) >> gpg: problem with the agent: End of file >> gpg: encrypted with 1 passphrase >> gpg: decryption failed: No secret key > > [...] > >> Does anyone experience similar issues? > > Yes, you're describing bug #52483, "GnuPG 2.2.30 cannot do symmetric > encryption": > > https://issues.guix.gnu.org/52483 Oh! Thanks for the reference, I'll subscribe to bug-guix so that I'm up to date with bug reports. > I just pushed commit d03aa942def0037cb32ff1d0cc2ac5d13f1a63df, which > allows you to upgrade your gnupg package to 2.2.32, which fixes this > bug. > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d03aa942def0037cb32ff1d0cc2ac5d13f1a63df I confirm that symmetric decryption works in guix shell gnupg after a guix pull. Thanks a lot for the quick answer! - Sergiu
Re: Build of vte-ng-0.58.2.a fails (dependency of termite)
Efraim Flashner [2021-12-27T09:21:35+0100]: > [[PGP Signed Part:Undecided]] > On Sun, Dec 26, 2021 at 05:39:31PM +0100, Sergiu Ivanov wrote: >> Hello, >> >> Installing termite has been failing for me since last week, because of >> a build failure in vte-ng: >> >> >> building /gnu/store/mrv5jmw59zzgpzc4p2rl3n2fvmggcc5b-vte-ng-0.58.2.a.drv... >> 0% 'install' [ ]builder for >> `/gnu/store/mrv5jmw59zzgpzc4p2rl3n2fvmggcc5b-vte-ng-0.58.2.a.drv' >> failed with exit code 1 >> build of /gnu/store/mrv5jmw59zzgpzc4p2rl3n2fvmggcc5b-vte-ng-0.58.2.a.drv >> failed >> View build log at >> '/var/log/guix/drvs/mr/v5jmw59zzgpzc4p2rl3n2fvmggcc5b-vte-ng-0.58.2.a.drv.bz2'. >> cannot build derivation >> `/gnu/store/ci0dkbn02nbpjiq001rrpkw6wj5v9306-termite-15.drv': 1 dependencies >> couldn't be built >> cannot build derivation >> `/gnu/store/0zkmyg0fvq3hxvrxkw7wyj3f2wkh0mlq-profile.drv': 1 dependencies >> couldn't be built >> guix shell: error: build of >> `/gnu/store/0zkmyg0fvq3hxvrxkw7wyj3f2wkh0mlq-profile.drv' failed >> >> >> I attach the full build log of vte-ng. >> >> I don't use termite at the moment, so simply removing it from my home >> configuration solved the issue for me, but I thought it useful to let >> the community know anyway. > > According to upstream termite is deprecated in favor of alacritty. Oh, good to know, thank you! > I've fixed the build of vte-ng by disabling building the documentation. Great, thanks a lot! guix shell termite works now. I don't know whether Guix has such a mechanism, but telling the user that a package they are installing is deprecated may be a nice thing to have. - Sergiu
Re: Initialization of environment variables for guix on foreign distro
Hello Thiago, Le jeudi 23 décembre 2021 à 21:33 -0300, Thiago Jung Bauermann a écrit : > I had a similar issue recently on my Ubuntu laptop, when I switched > the > display manager from SDDM to GDM. From what I gather, the latter > launches the desktop session without using a shell so at no point the > shell initialization files are evaluated and thus the environment > isn’t set > up as usual. > > I use KDE Plasma, and it has a mechanism to evaluate shell scripts to > set the environment, so in my case to fix the problem what I had to > do > was: > > $ ln -s /etc/profile ~/.config/plasma-workspace/env/profile.sh > Thanks for sharing this. > I searched a bit, but unfortunately I couldn’t find an equivalent > solution for MATE. > I have a bit of difficulty finding documentation for Mate unfortunately. > I suppose one alternative would be to switch from GDM to SDDM. :-) If using GDM implies that the setup of Guix will not work, I suppose Guix should consider some improvement to make it work with GDM. I am not sure GDM is really the problem. On both computers, I am using lightdm, in my case, lightdm is surely not the problem (it could be a different configuration of lightdm, I could dig into lightdm documentation but it seems rather small). > bash automatically reads /etc/profile when invoked as a login shell. > There are more details here: > > > https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html > Yes and I can confirm it works. That said, a mechanism to always invoke bash as login shell could have side effects that I may find only much later. Or, after an upgrade, that mechanism may stop working, or create other problems, and I could have forgotten what I did manually. Perhaps the problem even comes because of something I did manually and can't remember. If anyone is using Guix with Debian 11 and Mate, I am interested to know whether that problem exists or not. David. publickey - david.lecompte@metani.info - 292b3e27.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Avoiding rebuilds (e.g. of mariadb, the entire Rust chain, etc.)?
Le dimanche 26 décembre 2021 à 23:41 -0600, Matthew Brooks a écrit : > Is there any way to avoid rebuilding stuff like mariadb, the entire > Rust chain, etc. unless one of those packages *actually* changes? It > seems like every few days every single package needs to rebuild for > some reason, including many packages that spend unbelievably long > times running tests that will never actually be of use to me, so I'm > usually only able to update every couple of weeks since so much > constantly needs to be rebuilt and everything takes so long. > I don't have a solution, just similar experience but with a different setup. I use Guix on Trisquel on my X200, I have substitues enabled, my installed packages are glibc-locales, fontconfig, font-adobe-source- han-sans, gajim, gajim-omemo, gajim-openpgp, nheko, syncthing, darktable, and ungoogled-chromium. Often, "guix pull" and "guix package update" take between 1h and 2h. This is not due to the download time. Apparently, even with substitues, some CPU-heavy work is needed. > It seems to have gotten worse over time as well, as more and more > base packages pull in extremely computation-hungry dependency chains. > At this very moment, for example, I'm waiting for Rust & co. to > compile simply to delete old system generations from the bootloader. > I started "guix package -u" about 40h ago, it has been on ungoogled- chromium-96.0.4664.110-1.drv for more than 30h now and it is not finished. For a long time, both cores of the CPU have been at 100% load. Now, it is much lower and I see a lot of disk activity but still working. During the whole time, I have almost not used the computer at all. I will have to travel in two hours and I need to switch my laptop off first. If the update is not finished, I will stop the process. I guess I will remove ungoogled chromium as well. publickey - david.lecompte@metani.info - 292b3e27.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Build of vte-ng-0.58.2.a fails (dependency of termite)
On Sun, Dec 26, 2021 at 05:39:31PM +0100, Sergiu Ivanov wrote: > Hello, > > Installing termite has been failing for me since last week, because of > a build failure in vte-ng: > > > building /gnu/store/mrv5jmw59zzgpzc4p2rl3n2fvmggcc5b-vte-ng-0.58.2.a.drv... > 0% 'install' [ > > ]builder for > `/gnu/store/mrv5jmw59zzgpzc4p2rl3n2fvmggcc5b-vte-ng-0.58.2.a.drv' failed with > exit code 1 > build of /gnu/store/mrv5jmw59zzgpzc4p2rl3n2fvmggcc5b-vte-ng-0.58.2.a.drv > failed > View build log at > '/var/log/guix/drvs/mr/v5jmw59zzgpzc4p2rl3n2fvmggcc5b-vte-ng-0.58.2.a.drv.bz2'. > cannot build derivation > `/gnu/store/ci0dkbn02nbpjiq001rrpkw6wj5v9306-termite-15.drv': 1 dependencies > couldn't be built > cannot build derivation > `/gnu/store/0zkmyg0fvq3hxvrxkw7wyj3f2wkh0mlq-profile.drv': 1 dependencies > couldn't be built > guix shell: error: build of > `/gnu/store/0zkmyg0fvq3hxvrxkw7wyj3f2wkh0mlq-profile.drv' failed > > > I attach the full build log of vte-ng. > > I don't use termite at the moment, so simply removing it from my home > configuration solved the issue for me, but I thought it useful to let > the community know anyway. According to upstream termite is deprecated in favor of alacritty. I've fixed the build of vte-ng by disabling building the documentation. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
