bug#64775: /run should be cleaned on boot
On Mon, 07 Aug 2023 04:06:37 +0800, Vagrant Cascadian wrote: > > [1 ] > On 2023-08-06, Hilton Chain wrote: > > On Sat, 22 Jul 2023 04:24:17 +0800, > > Saku Laesvuori via Bug reports for GNU Guix wrote: > >> > >> [1 ] > >> > > I vote for TMPFS, since that would also reduce flash wear. > >> > > Honestly I don't get why it's not already using TMPFS. > >> > > >> > One argument could be how much ram it takes: > >> > > >> > $ du -sc /run/* > >> > 12 /run/blkid > >> > 0 /run/booted-system > >> > 0 /run/current-system > >> > 1312/run/setuid-programs > >> > 524 /run/udev > >> > 1848total > >> > > >> > That is with no explicit setuid programs configured, on a machine with a > >> > fairly minimal configuration. > >> > > >> > Not a *huge* amount of ram, but not nothing, either... > >> > >> I'd say it's effectively nothing for almost all devices capable of > >> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick > >> test one terminal window with only zsh running in it took almost 10 > >> times as much ram. > >> [2 signature.asc ] > >> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 > >> using RSA > > > > I'm currently using tmpfs for /tmp, /run and /var/run on my Guix > > Systems. > > > > If you are interested, this is my base file systems: > > --8<---cut here---start->8--- > > (cons* (file-system > > (device "none") > > (mount-point "/tmp") > > (type "tmpfs") > > (check? #f)) > > > >(file-system > > (device "none") > > (mount-point "/run") > > (type "tmpfs") > > (needed-for-boot? #t) > > (check? #f)) > > > >(file-system > > (device "none") > > (mount-point "/var/run") > > (type "tmpfs") > > (needed-for-boot? #t) > > (check? #f)) > > You probably want to restrict permissions on /run and /var/run, as the > defaults for tmpfs are world-writeable, allowing any user or process to > create files or directories in potentially harmful ways... > > For /tmp, these defaults are appropriate, however tricky a > world-writeable directory is... I have set the mode and size limit on them. Thank you so much! Otherwise I won't notice that... > Although I rarely have enough spare ram on a system to have /tmp be > tmpfs for Guix System because builds happen there by default, and > occasionally I need a lot more space than available ram in some cases. I have enough RAM for builds I currently do on my laptop and it's the builder for other systems, so tmpfs is fine for me. Thanks
bug#64775: /run should be cleaned on boot
On 2023-08-06, Hilton Chain wrote: > On Sat, 22 Jul 2023 04:24:17 +0800, > Saku Laesvuori via Bug reports for GNU Guix wrote: >> >> [1 ] >> > > I vote for TMPFS, since that would also reduce flash wear. >> > > Honestly I don't get why it's not already using TMPFS. >> > >> > One argument could be how much ram it takes: >> > >> > $ du -sc /run/* >> > 12 /run/blkid >> > 0 /run/booted-system >> > 0 /run/current-system >> > 1312/run/setuid-programs >> > 524 /run/udev >> > 1848total >> > >> > That is with no explicit setuid programs configured, on a machine with a >> > fairly minimal configuration. >> > >> > Not a *huge* amount of ram, but not nothing, either... >> >> I'd say it's effectively nothing for almost all devices capable of >> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick >> test one terminal window with only zsh running in it took almost 10 >> times as much ram. >> [2 signature.asc ] >> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using >> RSA > > I'm currently using tmpfs for /tmp, /run and /var/run on my Guix > Systems. > > If you are interested, this is my base file systems: > --8<---cut here---start->8--- > (cons* (file-system > (device "none") > (mount-point "/tmp") > (type "tmpfs") > (check? #f)) > >(file-system > (device "none") > (mount-point "/run") > (type "tmpfs") > (needed-for-boot? #t) > (check? #f)) > >(file-system > (device "none") > (mount-point "/var/run") > (type "tmpfs") > (needed-for-boot? #t) > (check? #f)) You probably want to restrict permissions on /run and /var/run, as the defaults for tmpfs are world-writeable, allowing any user or process to create files or directories in potentially harmful ways... For /tmp, these defaults are appropriate, however tricky a world-writeable directory is... Although I rarely have enough spare ram on a system to have /tmp be tmpfs for Guix System because builds happen there by default, and occasionally I need a lot more space than available ram in some cases. live well, vagrant signature.asc Description: PGP signature
bug#64981: GTK4 applications broken (missing libGLESv2)
Csepp writes: >> Am Dienstag, dem 01.08.2023 um 00:06 +0200 schrieb Csepp: >>> for example: >>> $ transmission-gtk >>> Couldn't open libGLESv2.so.2: libGLESv2.so.2 >>> >>> I get the same error with Tuba. It likely affects other >>> applications. >> I assume you are not using the gnome-desktop-service, are you? > > Yup, I'm using Sway without a display manager. Gnome was a memory hog. Oddly, GTK 4 apps work fine for me on Sway. -- (
bug#64775: /run should be cleaned on boot
Hi all, On Sat, 22 Jul 2023 04:24:17 +0800, Saku Laesvuori via Bug reports for GNU Guix wrote: > > [1 ] > > > I vote for TMPFS, since that would also reduce flash wear. > > > Honestly I don't get why it's not already using TMPFS. > > > > One argument could be how much ram it takes: > > > > $ du -sc /run/* > > 12 /run/blkid > > 0 /run/booted-system > > 0 /run/current-system > > 1312/run/setuid-programs > > 524 /run/udev > > 1848total > > > > That is with no explicit setuid programs configured, on a machine with a > > fairly minimal configuration. > > > > Not a *huge* amount of ram, but not nothing, either... > > I'd say it's effectively nothing for almost all devices capable of > running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick > test one terminal window with only zsh running in it took almost 10 > times as much ram. > [2 signature.asc ] > No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using > RSA I'm currently using tmpfs for /tmp, /run and /var/run on my Guix Systems. If you are interested, this is my base file systems: --8<---cut here---start->8--- (cons* (file-system (device "none") (mount-point "/tmp") (type "tmpfs") (check? #f)) (file-system (device "none") (mount-point "/run") (type "tmpfs") (needed-for-boot? #t) (check? #f)) (file-system (device "none") (mount-point "/var/run") (type "tmpfs") (needed-for-boot? #t) (check? #f)) (delete %debug-file-system %base-file-systems)) --8<---cut here---end--->8--- Thanks
bug#64981: GTK4 applications broken (missing libGLESv2)
Liliana Marie Prikler writes: > tags 64981 moreinfo > thanks > > Am Dienstag, dem 01.08.2023 um 00:06 +0200 schrieb Csepp: >> for example: >> $ transmission-gtk >> Couldn't open libGLESv2.so.2: libGLESv2.so.2 >> >> I get the same error with Tuba. It likely affects other >> applications. > I assume you are not using the gnome-desktop-service, are you? Yup, I'm using Sway without a display manager. Gnome was a memory hog. > Neither transmission-gtk nor GTK4 appears to actually link against > libGLES, so there's probably something arcane going on already. Have > you tried the usual debugging tools (GDB, strace)? > > Cheers Not yet, but I did now: ``` $ strace -e %file transmission-gtk |& grep libGL :( openat(AT_FDCWD, "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLX.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLX.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/libGL.so.1", O_RDONLY|O_CLOEXEC) = 29 openat(AT_FDCWD, "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLESv2.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLESv2.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: No such file or directory ``` So it's not looking for it in Mesa, which is odd, isn't that where it's supposed to be? According to guix locate libGLESv2.so.2, it should be in one of the Mesa packages. Thanks for helping me look into this! Gonna look a bit more into what's going on...
bug#65111: GnuCash cannot get online quotes
Hi, GnuCash 5.3, as packaged in Guix, cannot access quote sources. When adding a new security, it displays "Warning: Finance::Quote not installed properly." and the "Get Online Quotes" checkbox is greyed out. I am on an up-to-date Guix System and the rest of GnuCash seems to be working fine. It seems the package perl-finance-quote was not automatically installed with gnucash, so I installed it. I then tried to follow the steps in the upstream doc: https://www.gnucash.org/docs/v4/C/gnucash-help/finance-quote-install.html But it did not change the result. The flatpak version of GnuCash from flathub.org (also 5.3) appears to be working (on the same Guix System). Best regards, Altadil
bug#64999: Acknowledgement (emacs-next: emacs-29.1 fails to native-compile libraries, giving a runtime error that ctri.o and other files can't be found)
Hi Adam, Adam Porter writes: > OTOH, if anyone knows why the transformation option failed in that way, > it might be helpful to solve it if possible, so users could use the > option to install future releases without having to modify the package > definition. (AFAIK, I was able to do that for various Emacs 28 versions > without this problem, so I wonder if something's changed.) It's probably because emacs is missing the emacs-native-comp-driver-options.patch patch of emacs-next. Package transformations can't and won't replace the manual work of packaging new versions, so I think it is unreasonable to expect emacs 28's package definition to work with emacs 29. Best, -- Josselin Poiret signature.asc Description: PGP signature
