bug#71238: Installer image consistently fails to run system init due to TLS error

[CC'ing Chris as bordeaux expert] I'm affected by this issue as well. On both my desktop machines with Guix System installed for quite a while (so not in the installer). It also happens at different ISPs: * Telefonica O2 DSL, Germany * NetCom BW (ASN 47297) On one machine I removed the bordeaux

bug#69267: icedove.desktop has no StartupWMClass

I have submitted a patch at https://issues.guix.gnu.org/67849#11 ~Jonathan

bug#69267: icedove.desktop has no StartupWMClass

Fixed via https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b1b3724996952102ad2751fa5111c6e8680b2ed4 I think it works now, as in my GNOME session icedove behaves as intended. ~Jonathan

bug#68635: cifs-utils: smbinfo and smb2-quota do not run

`smbinfo` and `smb2-quota` of the cifs-utils package refuse to run properly: ``` $ smbinfo /usr/bin/env: 'python3': No such file or directory $ smb2-quota /usr/bin/env: 'python': No such file or directory ``` We need to patch out the `/usr/bin/env python` thing. ~Jonathan

bug#39117: GNOME Files: No file thumbnails

I'm running nautilus@42.2 and it shows thumbnails for at least JPEG and PNG images. This is on a rather recent Guix System installation: ``` $ LANG=en guix system describe Generation 10 Jan 07 2024 16:46:14(current) [...] channels: guix: repository URL: https://git.savannah.gnu.

bug#63775: git describe on current master says: v1.3.0-38775-g6192acf8b7

Hm, I'm hitting this bug while trying to work on the openSUSE package. They offer a way to build RPM packages from the most recent master commit, but it's get the wrong version (1.3.0 instead of 1.4.0) due to this `git describe` result. So in the end the package looks like `guix-1.3.0+git*.rpm` w

bug#68853: Guix Hurd - download error

In the meantime you could build the image yourself, while running the following command in a git checkout of Guix: ``` guix system image gnu/system/images/hurd.scm ``` It shouldn't take very long and e.g. even works on my rather slow Laptop :) ~Jonathan

bug#68939: sddm does not start after update to 0.20.0

Today I rebooted my workstation running Guix System and somehow sddm didn't started anymore. I quickly found a suspicious commit: 05fad99a431c6708ec18c7d0db67178bd8d36597 gnu: sddm: Update to 0.20.0. Then I pulled and reconfigured to this commit (Generation 14) and to one commit before (Generati

bug#68939: sddm does not start after update to 0.20.0

Hi tumashu, Am 05.02.24 um 23:45 schrieb tumashu: (display-server "wayland") remove this line, at the moment, sddm-service-type do not support this feature, for waston is not configure properly Thanks for that super fast response! Indeed this was the trick, sddm works now again without setti

bug#68961: ASLR seems to be partially broken

Hi, I found today an interesting blog post about broken ASLR (Address Space Layout Randomization) on Linux: https://zolutal.github.io/aslrnt/ Curious if this is also a problem on Guix System I did a quick test. ``` $ cat aslr.py from subprocess import check_output result = 0x0 for _ in range(0,

bug#68962: website: directly link the security mail address

Is there a reason why we don't link to the mail alias directly on the security page: https://guix.gnu.org/en/security/ Because the mailman archive doesn't make really sense for most of the users as it's only accessible with a password. What about this small patch? ``` diff --git a/website/apps/b

bug#70194: SDDM fails to start, black screen on 188d18fc47

I ran into this issue on my newly installed laptop (Guix System). Even after reconfiguring to 15a523ea213065c275e4852673cbb27c72c0ad87 (current master as of today), the screen stayed black and SDDM didn't start. My sddm configuration: ``` (service sddm-service-type (sddm-configuration (dis

bug#70960: [PATCH] gnu: Remove mozjs-91.

Hallo Andreas, Am 15.05.24 um 21:13 schrieb Andreas Enge: * gnu/packages/gnuzilla.scm (mozjs-91): Delete variable. I'm not sure we should remove it yet. 0ad (the only reverse-dependency of mozjs@78) at master branch uses mozjs@91. So the next release of it would require mozjs@91. See: https:

bug#73192: [PATCH] gnu: icedove-l10n: Fix build.

Hi André, Am 20.09.24 um 00:39 schrieb André Batista: Fixes * gnu/packages/gnuzilla.scm (make-l10n-package)[arguments]<#:phases>: On 'build phase unconditionally use 'system*' to invoke 'mach', as 'invoke' does not work for icedove any longer. Reported-by: b

bug#73192: icedove-l10n-115.14.0 build failure

bug#74770: [shepherd-website] Two "//" as link behind head image

Hi, there is a super tiny problem on the lovely and new shepherd website: 1. Go to https://www.gnu.org/software/shepherd/ 2. Click on to big Shepherd logo on the top of the website 3. You end up at https://www.gnu.org/software/shepherd// <- notice the additional "/" at the end of the url The pr

bug#76991: telegram-desktop package fails to build

@Arseniy: I think it's fine to point to another commit which causes the build failure and kind of "forces" this update of telegram/it's dependencies... ~Jonathan

bug#77112: mate-applets are not being installed correctly

Duplicate of https://issues.guix.gnu.org/77111 Closing

bug#76991: telegram-desktop package fails to build

I've built the patch for c++-gsl and telegram-desktop and pushed them. ~Jonathan