bug#56437: Reduce closure size of gsettings-desktop-schemas

[宋文武 via Bug reports for GNU Guix]

Maxime Devos  writes:

> On 07-07-2022 16:50, Pierre Neidhardt wrote:
>
>> Hi,
>>
>> Gsettings-desktop-schemas is required by WebKitGTK to load HTTPS pages.
>> But it also depends on gnome-backgrounds which weights some 40 MiB.
>>
>> For sure this does not help the closure size...
>>
>> I suggest we create a separate output, or maybe a
>> gsettings-desktop-schemas-minimal which does not include the reference
>> to the backgrounds.
>>
>> Thoughts?
>
> There are only two schemes that contain a reference, so maybe those
> can be put in a separate output:
> [...]
> As such, I'd prefer gong for a separate output. It would need to be
> checked that this doesn't cause problems from GNOME users though.

I think we can use some gsettings overrides in the gnome package, there
is no need for gsettings-desktop-schemas hardcode the background
setting itself.

bug#57048: tiled-1.8.1 fails to build

[宋文武 via Bug reports for GNU Guix]

Fixed in commit ee216d16ef5ea537eaf5508dcffa5d808ab62bb0, thank you for
the report!

bug#57049: cool-retro-term-1.2.0 build failure

[宋文武 via Bug reports for GNU Guix]

"bdju"  writes:

> build log: http://ix.io/46Yn
> guix version: just shows up as 0 for some reason...

cool-retro-term fixed in master now, thank you for the report!

I have version as 0 too...

bug#57067: Missing Xfce icons

[宋文武 via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> In current ‘master’ (ca. 6db3b34d7203639ef4286c237a6e536259f92352), in a
> VM created with:
>
>   guix system vm gnu/system/examples/vm-image.tmpl
>
> Xfce is lacking a few icons in window decorations and in the bar at the top:
>

Fixed in commit 02b69362cb5922e3e2579b120a12afcc6167a46e now.

GTK+3 (and 4) requires the Adwaita icon theme is always available.
Maybe we can make gtk+ depends and hardcode the path to
adwaita-icon-theme to avoid install it into the profile.

Thank you!

bug#57104: Python-symengine fails to build

[宋文武 via Bug reports for GNU Guix]

Andreas Enge  writes:

> Since it replaces a broken package by a more modern broken package, I still
> took the liberty to push, but it would be nice if someone with knowledge of
> python and/or symengine could have a look. Disabling the tests makes the
> compilation succeed, but it would be nice to find a better solution...
>

Fixed it by using 'nosetests' to run the tests.

Close now, thanks!

bug#57268: rottlog create a /.lastweek file

[宋文武 via Bug reports for GNU Guix]

Our rottlog has an empty STATDIR, it will create a /.lastweek file when
running.  Normally it should use /var/lib/rottlog/.lastweek.

bug#57480: Wrong Type To Apply on Reconfigure

[宋文武 via Bug reports for GNU Guix]

Julien Lepiller  writes:

> I don't know how to fix it, but here is what I think is the issue:
>
> in guix/scripts/system/reconfigure.scm:
>
> #:autoload   (guix describe) (current-channels)
> ...
> (define* (check-forward-update ...
>(current-channels ...))
>   (define new (current-channels)) ; this is supposed to be the
>  ; autoloaded procedure, but it's the keyword argument
>  ; which is a list
>   ... ; uses of current-channels, the keyword argument
>
> Le Mon, 29 Aug 2022 23:01:46 -0400,
> Christopher Rodriguez  a écrit :
>
>> Hello All,
>> 
>> A change made in b084398 is preventing both my system and home
>> configurations from building with a Wrong Type to Apply error. Did the
>> channel spec format change with the changes in that commit?

Hello, I revert the commit b084398 for now.

bug#58697: [bug] guix refresh nftables crashes

[宋文武 via Bug reports for GNU Guix]

Maxime Devos  writes:

> On 22-10-2022 03:55, kiasoc5 via Bug reports for GNU Guix wrote:
>> % guix refresh nftables
>> [...]
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> In procedure getaddrinfo: Servname not supported for ai_socktype
>> ```
>
> I can reproduce this locally and don't know the cause.
>

It happens when the origin have both 'mirror://' and 'http://' urls,
current the html updater check for any url match 'http' or 'https', but
when updating it will just pick the first url, so when the first is
'mirror://' this error will come.

This patch should fix it:

>From e9dfdc3a2031c25043cc8b6f4b08656d05024c16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Mon, 24 Oct 2022 16:35:18 +0800
Subject: [PATCH] gnu-maintenance: Don't try html updater on 'mirror://' urls.

This fixes .

* guix/gnu-maintenance.scm (latest-html-updatable-release): Use the first http
or https url for updating.
---
 guix/gnu-maintenance.scm | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/guix/gnu-maintenance.scm b/guix/gnu-maintenance.scm
index 10a6ec05f1..4cd501e492 100644
--- a/guix/gnu-maintenance.scm
+++ b/guix/gnu-maintenance.scm
@@ -806,10 +806,16 @@ (define http-url?
 (define (latest-html-updatable-release package)
   "Return the latest release of PACKAGE.  Do that by crawling the HTML page of
 the directory containing its source tarball."
+  (define (http-url? url)
+(match (string->uri url)
+  (#f #f)
+  (uri (let ((scheme (uri-scheme uri)))
+ (memq scheme '(http https))
   (let* ((uri   (string->uri
  (match (origin-uri (package-source package))
((? string? url) url)
-   ((url _ ...) url
+   ;; We need filter out possibly 'mirror://' urls.
+   ((? list? urls) (first (filter http-url? urls))
  (custom(assoc-ref (package-properties package)
'release-monitoring-url))
  (base  (or custom
-- 
2.37.3

bug#59876: Bug.

[宋文武 via Bug reports for GNU Guix]

Ping Pong  writes:

> Hello,

Hello!
>
> My shell asked me to send this your way:
> [...]
> ./guix/serialization.scm:80:6: In procedure read-int:
> ERROR:
>   1. &nar-error:
>   file: #f
>   port: #
> guix pull: error: You found a bug: the program 
> '/gnu/store/lzj46vv382in6axngwsjaaa2y96lss04-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "f57fbc2fb1b20823f433781d08047df5d7bc31df"; system: "x86_64-linux";
> host version: "1.3.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

Sorry for the failure and not helpful error message...  I believe this
usually was due to unstable internet connection, does try "guix pull"
again fixed it?

bug#59846: "Running Guix in a Virtual Machine" documentation unclear/incomplete/wrong

[宋文武 via Bug reports for GNU Guix]

Ian Eure  writes:

> I’m trying to explore Guix System by running it in a VM on my computer
> which runs Debian.  I’m interested in some of the Guix ideas, but not
> ready to do a bare-metal install.

Hello!
>
> I found the download page[1] and got a copy of the QEMU image, then
> clicked "Installation instructions"[2].  These instructions didn’t
> work, because they’re incomplete and/or unclear and/or wrong and/or
> not really installation instructions in the way one might assume.
> Since I don’t really know anything about Guix (which is why I’m
> reading the documentation and test driving it in a VM), I’m not sure
> which one-or-more of these it may be.

Sorry for the not very helpful documentation, I'd say write good
documentation is very hard...
>
> Specifically:
>
>> To enable SSH inside a VM you need to add an SSH server like
>> openssh-service-type to your VM (see openssh-service-type).
>
> The documentation doesn’t say *how* to do that.  The
> openssh-service-type link[3] takes me to a large page of code
> documentation for every possible networking service, instead of the
> openssh-service-type one specifically.  This documentation describes
> *what* the service type and its many configuration options is, but is
> silent on *how* to make use of it.

This openssh-service-type should be added into the system configuration
file, it's /run/current-system/configuration.scm in the pre-built qemu
image or the file passed to 'guix system vm-image' when built your own
image.  The configuration file is a scheme (guile) file, the detail is
in the section "10.1 Using the configuration System".

>
> It continues:
>
>> In addition you need to forward the SSH port, 22 by default, to the
>> host. You can do this with
>> $(guix system vm config.scm) -nic
>> user,model=virtio-net-pci,hostfwd=tcp::10022-:22
>
> I’m really not sure what this is supposed to be doing.  It can’t run
> on my Debian host, since there’s no guix command.  It errors inside
> the VM, since it can’t find a config.scm file; and I don’t see an
> obvious config.scm file anywhere inside the VM that it might be
> looking for.
>
> I *suspect* that this documentation is actually targeted at running a
> Guix System VM on an existing Guix host.  Which is a chicken-and-egg
> problem, if I’ve already installed Guix, I don’t need to follow
> instructions to install it.

Well this 10.16 target both running a pre-built qcow guix system image
and running a 'guix system vm' built one.  But it's not self contained,
as the service things lacking commands for the former as you reported,
and the later case assume you already have guix installed (not the guix
system though).

Hope it helps!

bug#61132: xfce 4.18 issues: gsettings, icons missing, and logout need long time

[宋文武 via Bug reports for GNU Guix]

> [...]
>
> Hello Feng Shu and Michael Rohleder, I have create a wip-xfce branch and
> applied all patches: They're all LGTM, and I will merge it after some
> tests later.  Thank you!
>

Pushed!

During my tests, I find some issues though:

1. in xfce4-appearance-settings, switch the theme to greybird-dark will
kill it, with output:
```
(xfce4-appearance-settings:13788): Gtk-WARNING **: 10:53:21.078: Could not load 
a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg.
This may indicate that pixbuf loaders or the mime database could not be found.

(xfce4-appearance-settings:13788): GLib-GIO-ERROR **: 10:53:23.264: Settings 
schema 'org.gnome.desktop.interface' does not contain a key named 'color-scheme'
```
I think this is due to our gsettings-desktop-schemas is old.

2. some icons are missing, and by default there is no pixbuf loader for
svg.  With a manually set GDK_PIXBUF_MODULE_FILE, I get better result
with elementary-xfce-icon-theme (the adwaita icon themes still missing
some icons).

3. logout via xfce4-session-logout will wait more about 30s for me,
sometimes it does logout immediately, no idea...

4. mousepad output:
Mousepad-Message: 11:00:34.614: Plugin directory 
'/gnu/store/0m4rqqn3gxwg6mafhccqjwwvqdz1a5sr-mousepad-0.5.10/lib/mousepad/plugins'
 not found
GLib-GIO-Message: 11:00:34.614: Using the 'memory' GSettings backend.  Your 
settings will not be saved or shared with other applications.

The default gsettings backend is dconf, I guess some applications like
mousepad need fix to enable dconf or use the keyfile backend for
gsettings...

I now open a bug for thoes issues.

bug#59579: installing zbar prevents gdm to start on Ubuntu 22.04 foreign distro

[宋文武 via Bug reports for GNU Guix]

Simon Tournier  writes:

> Hi,
>
> On Fri, 25 Nov 2022 at 18:45, Clément Lassieur  wrote:
>
>> It's very difficult to pin the issue down to a guix package being
>> installed.
>>
>> I imagine the bug would not happen if ~/.guix-profile/share was not in
>> XDG_DATA_DIRS.
>
> Yes, it is related to XDG_DATA_DIRS and it can be tedious to find which
> package brings the issue.
>
> I had a similar issue with the package ’python-ipython’ and recently
> with ’fontconfig’ – both cases running on the top of Debian.
>
> The issue can happen whatever the profile; it just depends which ones
> are sourced by your login shell.
>

Hello, I don't think XDG_DATA_DIRS should be the problems, but other
environment variables with "lib", since the xdg data should be
portable...

So:
--8<---cut here---start->8---
$ guix shell -C coreutils zbar --no-grafts  -- env
PS1=\u@\h \w [env]\$ 
TMPDIR=/tmp
TEMPDIR=/tmp
TMP=/tmp
TEMP=/tmp
LOGNAME=iyzsong
USER=iyzsong
HOME=/home/iyzsong
PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/bin:/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/sbin
XDG_DATA_DIRS=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/share
GUIX_GTK3_PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/gtk-3.0
QMAKEPATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/qt5
QT_PLUGIN_PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/qt5/plugins
XDG_CONFIG_DIRS=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/etc/xdg
XCURSOR_PATH=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/share/icons
GDK_PIXBUF_MODULE_FILE=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
GUIX_ENVIRONMENT=/gnu/store/yfnm6nh3a6c7hiqk1nq228wpph1x1z1w-profile
--8<---cut here---end--->8---

I think GUIX_GTK3_PATH, QT_PLUGIN_PATH, GDK_PIXBUF_MODULE_FILE should be
the problems.

bug#61195: termite failed to build, need switch to a maintained fork

[宋文武 via Bug reports for GNU Guix]

New fork: https://github.com/aperezdc/termite
Maybe also remove vte-ng.

bug#61343: modules from channels is not available to "guix repl"

[宋文武 via Bug reports for GNU Guix]

I have add the rde channel to my guix, and "guix pull".
--8<---cut here---start->8---
(cons*
 (channel
  (name 'rde)
  (url "https://git.sr.ht/~abcdw/rde";)
  (introduction
   (make-channel-introduction
"257cebd587b66e4d865b3537a9a88cccd7107c95"
(openpgp-fingerprint
 "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0"
 %default-channels)
--8<---cut here---end--->8---

But then, Run:
  echo '(use-modules (rde features))' | guix repl /dev/stdin
Will get error: no code for module (rde features)

Well, Run:
  echo '(use-modules (gnu packages) (rde features))' | guix repl /dev/stdin
Will pass!

bug#57677: GIMP retains reference to GCC

[宋文武 via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> [...]
> So the root cause is that GIMP’s build process captures the output of
> ‘gcc -v’, which leads to this unintended retention.

I sent a patch to fix reference from 'gcc -v', but gcc is still here via
exiv2->gcc:

rg -a /gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0 $(guix build exiv2)

--8<---cut here---start->8---
bin/iptcprint:^@^@^@std::auto_ptr<  >::element_type* 
std::auto_ptr<  >::operator->() const [with _T
p = Exiv2::Image; std::auto_ptr< >::element_type =
Exiv2::Image]^@^@^@^@^@^@^@^@/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/backward/auto_ptr.h^@^@%s:%d:
%s: Assertion '%s' failed.
[...]
--8<---cut here---end--->8---

bug#61469: Xfce window snapping broke with latest upgrade

[宋文武 via Bug reports for GNU Guix]

Nathan Dehnel  writes:

> Latest guix pull and reconfigure caused window snapping to stop
> working in XFCE. I have tried toggling it off and on a few times in
> the settings.
> Current generation: ccf742f120452acf587d16e40adea570d15169c4
> Previous generation: 658c09333da095edf6e1b3c5e351a7bfa3c87354
Hello, it does works for me here.

Note that only snapping up upon the default pannel will prevent it
moving future.  For other directions, if you drag too much, the window
will escape the snap and move to another workspace...

bug#61343: [PATCH] scripts: repl: Load (gnu packages) to set up %load-path.

[宋文武 via Bug reports for GNU Guix]

Josselin Poiret  writes:

> * guix/scripts/repl.scm: Add (gnu packages) to the used modules so that 
> channel
> Scheme files are available straight away.
> ---
> Hi both of you,
>
> I don't think there's a reason for that, other than no one realizing before.
> Here's a simple fix, freshly tested.
>
>  guix/scripts/repl.scm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/guix/scripts/repl.scm b/guix/scripts/repl.scm
> index 787c63d48e..407f5b2b38 100644
> --- a/guix/scripts/repl.scm
> +++ b/guix/scripts/repl.scm
> @@ -22,6 +22,7 @@ (define-module (guix scripts repl)
>#:use-module (guix ui)
>#:use-module (guix scripts)
>#:use-module (guix repl)
> +  #:use-module (gnu packages) ;; To extend %load-path with channels
It's not clear to me why load (gnu packages) will/should extend
%load-path, a suprise side effect!

bug#48214: inetutils-1.9.4 build fails

[宋文武 via Bug reports for GNU Guix]

Bone Baboon  writes:

> I have reopened bug#48214 because while inetutils-1.9.4 can be built on
> x86_64 with IPv6 disabled this command fails on x86_64 with IPv6
> disabled `guix build --no-substitutes --system=i686-linux` inetutils`.
> This command has the same failing test.  Attached is the failing i686
> build log.
>

Does this issue still exist?  Now we have inetutils-2.0 in master, and will
have 2.3 soon after core-updates merged...

bug#61469: Xfce window snapping broke with latest upgrade

[宋文武 via Bug reports for GNU Guix]

Nathan Dehnel  writes:

> Turns out the setting for this is called "tiling" in xfce, not
> "snapping". So I was able to re-enable it. This can probably be
> closed.

Cool!  Close now, thank you!

bug#63133: python-ipy FTBFS

[宋文武 via Bug reports for GNU Guix]

Felix Lechner  writes:

> Hi,
>
> With a recent checkout of Guix, python-ipy fails to build from source.

Hello, update to 1.01 fix it, pushed, thank you for the report!

bug#63118: Mumble failing to build

[宋文武 via Bug reports for GNU Guix]

"J. Sims"  writes:

> Hello,
>
> As of at least bb385f247292d3162b27afa7ac48a1bf404c8e37, Mumble is
> failing to build during compilation.

Hello, fixed with use openssl-1.1.  Thank you for the report!

bug#63099: Dovecot FTBFS

[宋文武 via Bug reports for GNU Guix]

Felix Lechner  writes:

> Hi,
>
> With a recent checkout of Guix, dovecot fails to build from source due
> to failing tests. Looks like an assertion related to OpenSSL. A
> partial log is below. Thanks!

Fixed with a patch from:
https://raw.githubusercontent.com/archlinux/svntogit-community/packages/dovecot/trunk/dovecot-2.3.14-opensslv3.patch

Thank you for the report!

bug#20255: 'search-paths' should respect both user and system profile.

[宋文武 via Bug reports for GNU Guix]

Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
search-paths from multiple profiles by `guix package --search-paths`, in
~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
update).  


Close now!

bug#20255: 'search-paths' should respect both user and system profile.

[宋文武 via Bug reports for GNU Guix]

Josselin Poiret  writes:

> Hi Maxim,
>
> Maxim Cournoyer  writes:
>
>> Just to make sure, remove what exactly?
>
> Remove the bit in /etc/profile that loads the user's profile, if it is
> indeed supposed to be loaded by the user's own ~/.zprofile or
> ~/.bash_profile.

Remove will break existed systems, so need a NEWS entry as Maxim
mentioned, and maybe some explainations and examples in the manual about
how to setup the environments as needed.

I could make a patch for it this weekend if no one beats me..


> At least, I don't know if there is a general agreement
> on what should be done in /etc/profile vs. the user's own config.

I think hopefully we can agree that /etc/profile only handle the system
profile, and user's own config can decide what it want.

Despite mitigation, it still work out of the box with skeletons, and
user can arrange priorities among profiles, or disable the system one.
Or configure it via home-shell-profile (TODO: need some changes).

bug#20255: 'search-paths' should respect both user and system profile.

[宋文武 via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

> Hi,
>
> 宋文武  writes:
>
>> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
>> search-paths from multiple profiles by `guix package --search-paths`, in
>> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
>> update).  
>>
>>
>> Close now!

Well, I reopen this since the changes is not totaly (duplicates in
/etc/profile, guix home changes) done, sorry...

>
> Cool, thanks for the update.  Perhaps a NEWS entry would be useful to
> keep Guix System existing users in the loop?  Until we have a better
> mechanism/approach to these stateful files that don't change past the
> original installation.

Now, I send more patches with NEWS entry.


Add guix-devel to CC for more reviews, TIA!

bug#64736: pipewire doesn't provide libspa-libcamera.so

[宋文武 via Bug reports for GNU Guix]

Alexandre Hannud Abdo  writes:

> Ni! File `usr/lib/spa-0.2/libcamera/libspa-libcamera.so` isn't found when 
> installing pipewire.
>
> This seems to affect screen sharing on wayland through wireplumber, or at 
> least my setup broke once the messages below started appearing:
>
> ```
>
> M 22:57:06.048626  wp-device
> ../source/lib/wp/device.c:619:wp_spa_device_new_from_spa_factory: SPA
> handle 'api.libcamera.enum.manager' could not be loaded; is it
> installed?
> M 22:57:06.048653   script/libcamera libcamera.lua:173:chunk: PipeWire's 
> libcamera SPA missing or broken. libcamera not supported.
>
> ```
>
> Cheers, ale

Hello, thank you for the report.  I'll looking into it during this
weekend.

bug#64736: pipewire doesn't provide libspa-libcamera.so

[宋文武 via Bug reports for GNU Guix]

Alexandre Hannud Abdo  writes:

> Uou, thank you. Let me know if and how I can help. Best, .~´
>

I had submit patches for it at https://issues.guix.gnu.org/64767.
It builds fine, but I haven't test the camera (no camera here), it
will be good if you can test it...

It can be fetched in a local guix checkout:
  git remote add qa https://git.guix-patches.cbaines.net/guix-patches
  git fetch qa issue-64767
  git checkout -f qa/issue-64767

And then do a build of guix, and update local packages...
If this seems too much, you can wait the patches get merged, no worry!

Thank you!

bug#64941: ModuleNotFoundError in ibus-anthy

[宋文武 via Bug reports for GNU Guix]

elaexuo...@wilsonb.com writes:

> Hey guix,
>
> Anthy has been giving me grief lately. It's not showing up in ibus-setup's 
> list
> of input methods.
>

Hello, thanks for the report, fix now in master!

bug#64987: Blind people unable to install Guix System

[宋文武 via Bug reports for GNU Guix]

Simen Endsjø  writes:

> It was brought to my attention that blind people runs into problems installing
> Guix System, while Debian and Arch have solved this better.
>
> The problem is outlined by the user k.g.roberts, ref
> :
>
>   The installer for Guix System 1.4.0 is basically the same as I remember 
> it from
>   a few years ago; boots almost immediately into an ncurses menu for 
> locale
>   selection and it takes another few screens to get to the option for a 
> shell. No
>   other assistive technologies built into the installer itself outside of 
> what’s
>   in the kernel, so a blind installation is doable over a remote 
> connection after
>   that point, but would likely be a hassle to get going without 
> additional help
>   from a sighted person.
>
> Dave Dude mention a solution, ref 
> :
>
>   They’d need to add a console screen reader, like Fenrir or ESpeakup to 
> the
>   installation image, then have something to type, on the boot command 
> line, to
>   start the reader. Debian has done this, on its installation images for 
> a long
>   time. Arch now does something like this, too. Thanks for looking into 
> this!
>
> I’m not the right person to do something like this, just thought I should 
> report
> it in case it’s easy to fix.

Hello, I CC this email to bug-guix to open an issue now.

Thank you for the report!

bug#61195: termite failed to build, need switch to a maintained fork

[宋文武 via Bug reports for GNU Guix]

> New fork: https://github.com/aperezdc/termite
> Maybe also remove vte-ng.

Done in commit 1b8c5480f64a57f46e39822136d279fa0b1270cd and
34b56974dfe720e5e30f04409ac216747d7e3f5c.

bug#61132: xfce 4.18 issues: gsettings, icons missing, and logout need long time

[宋文武 via Bug reports for GNU Guix]

> 宋文武  writes:
>
>> During my tests, I find some issues though:
>>
>> 1. in xfce4-appearance-settings, switch the theme to greybird-dark will
>> kill it, with output:
>>
>> ```
>> (xfce4-appearance-settings:13788): Gtk-WARNING **: 10:53:21.078:
>> Could not load a pixbuf from
>> /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg.
>> This may indicate that pixbuf loaders or the mime database could not be 
>> found.
>>
>> (xfce4-appearance-settings:13788): GLib-GIO-ERROR **: 10:53:23.264:
>> Settings schema 'org.gnome.desktop.interface' does not contain a key
>> named 'color-scheme'
>> ```
>>
>> I think this is due to our gsettings-desktop-schemas is old.
>>
>> 2. some icons are missing, and by default there is no pixbuf loader for
>> svg.  With a manually set GDK_PIXBUF_MODULE_FILE, I get better result
>> with elementary-xfce-icon-theme (the adwaita icon themes still missing
>> some icons).
>>
>> 3. logout via xfce4-session-logout will wait more about 30s for me,
>> sometimes it does logout immediately, no idea...
>>
>> 4. mousepad output:
>> Mousepad-Message: 11:00:34.614: Plugin directory
>> '/gnu/store/0m4rqqn3gxwg6mafhccqjwwvqdz1a5sr-mousepad-0.5.10/lib/mousepad/plugins'
>> not found
>> GLib-GIO-Message: 11:00:34.614: Using the 'memory' GSettings
>> backend.  Your settings will not be saved or shared with other
>> applications.
>>
>> The default gsettings backend is dconf, I guess some applications like
>> mousepad need fix to enable dconf or use the keyfile backend for
>> gsettings...
>>
>> I now open a bug for thoes issues.
>>
>
> 5. Thunar start slowly
>
> When I update to xfce 4.18, thunar start need 5 second, when I
>
> 1. backup my xfce4 config.
> 2. rm my old xfce4 config.
> 3. run xfce4 and quit.
> 4. restore old xfce4 config.
> 5. run xfce4 again.
>
> The problem dispear, I do not know why.

Except gsettings for mousepad, which i now set
`GSETTINGS_BACKEND=keyfile` myself, the issues seems all fixed now.
Closing..

bug#53543: bug#64798: [PATCH 000/209] update kde package and add plasme desktop

[宋文武 via Bug reports for GNU Guix]

Andreas Enge  writes:

> Am Tue, Aug 08, 2023 at 08:39:26PM +0800 schrieb 宋文武:
>> Thank you!  Fixed failures due to missing ktextaddons with:
>>   5ced446828 gnu: Add ktextaddons.
>>   8d1a785d59 gnu: Add missing ktextaddons to kde-pim packages.
>> Also fixed kalendar and kgpg:
>>   67f32a2fd2 gnu: kalendar: Add missing inputs.
>>   1a02365c4a gnu: kgpg: Skip flaky test.
>
> Thank you! Does this also fix this older bug report:
>https://issues.guix.gnu.org/53543
> or if not, could you check if there is a simple fix?

Yes, kmessagelib build fine now.

bug#18640: fontconfig's cache is not refreshed automatically

[宋文武 via Bug reports for GNU Guix]

Hello, I believe this issue had been fixed by:

commit 6f12880a76a6c91058718d15845f8b9d9b529a5a
Author: Sarah Morgensen 
Date:   Fri Jun 18 17:52:05 2021 -0700

gnu: fontconfig: Use (locally) deterministic caching

Make fontconfig use directory contents rather than modification time to
determine cache validity (by pretending that mtime is broken).

Closing.

bug#26877: building fonts: fontcache must be updated regulary

[宋文武 via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

> Hello,
>
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi,
>>
>> Mark H Weaver  skribis:
>>
>>> The usual Guix way to handle things like this is to arrange for the font
>>> cache to be part of the profile, and to create a profile hook that
>>> creates the cache from all of the built packages included within.
>>
>> The problem is that the cache should be mutable so that one can run
>> “fc-cache -f” after having dropped files in ~/.local/share/fonts, for
>> instance.
>>
>> That said, quite surprisingly, I think I never had to run ‘fc-cache’
>> except in the situation above.
>
> I've never had to do this in years, although I don't use "loose" fonts
> manually installed under ~/.local/share/fonts.
>
> Should we close the issue?  Our fontconfig package now honors fonts
> found under XDG_DATA_DIRS, and it seems to just work.


Hello, I think we can close this now, since this commit:

commit 6f12880a76a6c91058718d15845f8b9d9b529a5a
Author: Sarah Morgensen  mgsn.dev>
Date:   Fri Jun 18 17:52:05 2021 -0700

gnu: fontconfig: Use (locally) deterministic caching

Make fontconfig use directory contents rather than modification time to
determine cache validity (by pretending that mtime is broken).

There is no need to run 'fc-cache' manually, and applications just need
close/restart to use newly install fonts (also manual run here doesn't
remove the need of restart).

bug#25865: xinit does not allow non-root startx

[宋文武 via Bug reports for GNU Guix]

Alex Vestgaard  writes:

> Hi,
>
> xinit suffers from an upstream bug, which does not allow non-root X to be run 
> without a display manager via startx or xinitrc. Several
> people have reported this on #guix.
>
> Currently if one runs startx as non-root, X reports:
> (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)
>
> This bug is further discussed in [1]. Redhat seems to have a patch [2], but 
> it is unclear to me whether this has been applied upstream.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/xinit/+bug/1562219
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1203780

Hello, for 'xinit', you can create a '~/.xserverrc` file with:

  tty=$(tty)
  tty=${tty#/dev/tty}
  X vt${tty}

then it will run a non-root X from current tty.  Also 'sx' works fine.

Closing now..

bug#65282: guix-1.3 on Ubuntu-22.04 is broken because of outdated datefudge.

[宋文武 via Bug reports for GNU Guix]

Dmitry Nikolaev  writes:

> The problem with guix-1.3 on Ubuntu-22.04 is not with datefudge. The
> problem is ci.guix.gnu.org connectivity from Russia.

Hello, you could try follow substitute mirrors if ci doesn't works:

ci mirror:   https://mirror.sjtu.edu.cn/guix/
bordeaux:https://bordeaux.guix.gnu.org
bordeaux mirror: https://bordeaux-singapore-mirror.cbaines.net
bordeaux mirror: https://bordeaux-us-east-mirror.cbaines.net

Hope this could be useful, thanks!

bug#64736: pipewire doesn't provide libspa-libcamera.so

[宋文武 via Bug reports for GNU Guix]

Alexandre Hannud Abdo  writes:

> Uou, thank you. Let me know if and how I can help. Best, .~´

Hello, it should be fixed now.  Since commit
7d8ce0701e82cf984906980e240bbf67f4988426.

Closing,  thanks.

bug#64981: GTK4 applications broken (missing libGLESv2)

[宋文武 via Bug reports for GNU Guix]

iyzs...@envs.net writes:

> * gnu/packages/gl.scm (libepoxy)[arguments]<#:phases>:
> Hardcode paths to libGLESv1_CM.so.1 and libGLESv2.so.2.

Hello, since we already hardcode paths for libGL, adding libGLES seems
reasonable.

Have test it though, because on my machine (kwin in wayland) it seems
GTK4 applications will use GL renderer instead of GLES.

bug#65390: naev build failure: validate-runpath failed

[宋文武 via Bug reports for GNU Guix]

Maxime Devos  writes:

> When doing "guix shell naev", things ended with:
>
> [...]
> starting phase `validate-runpath'
> validating RUNPATH of 1 binaries in
> "/gnu/store/nl8fl0agic9a5dw9i1m701p3yn6x6sw9-naev-0.10.4/bin"...
> /gnu/store/nl8fl0agic9a5dw9i1m701p3yn6x6sw9-naev-0.10.4/bin/naev:
> error: depends on 'libSDL2_image-2.0.so.0', which cannot be found in
> [...]

Hello, avoid the use of 'sdl-union' will fix it.  It was caused by meson
removing rpaths during install phase.  Not sure why it remove the one
for sdl2-image though..

bug#65390: bug#65395: [PATCH] gnu: naev: Fix build.

[宋文武 via Bug reports for GNU Guix]

iyzs...@envs.net writes:

> From: 宋文武 
>
> * gnu/packages/games.scm (naev)[inputs]: Don't use sdl-union.
> Remove sdl2-mixer.

Pushed now, closing.

bug#36944: Xfce Panel shortcuts after updates might not work

[宋文武 via Bug reports for GNU Guix]

zna...@disroot.org writes:

> Hello! Sometimes, when Icecat or Pcmanfm-qt update, I am not able to run them 
> from shortcuts I've add to
> panel as Items (right mouse click - Panel - Add new Item).
> This is because applications addresses were changed after update (because 
> guix adds hash to application
> folder).
> This makes me need to delete shortcut and add again.
> Xfce is not in account in this. Xfce does not use 
> /home/user/.giux-profile/bin folder for those shortcuts. Xfce
> uses /gnu/store/hashhashahsh-icecat-60.1/bin/icecat instead. And this is my 
> trouble.
>
> Do you think we can solve this?

No solution yet, but i confirm this issue does exists..

After add a launcher for chroium in xfce4-panel, i got:

$ cat panel/launcher-9/16929589731.desktop

--8<---cut here---start->8---
[Desktop Entry]
Version=1.0
Name=Chromium
GenericName=Web Browser
Comment=Access the Internet
Exec=/gnu/store/0bm0k38601acm56pv5jkl6wgvm0rj5xc-ungoogled-chromium-112.0.5615.165-1/bin/chromium
 %U
StartupNotify=true
Terminal=false
Icon=chromium
Type=Application
Categories=Network;WebBrowser;
MimeType=application/pdf;application/rdf+xml;application/rss+xml;application/xhtml+xml;application/xhtml_xml;application/xml;image/gif;image/jpeg;image/png;image/webp;text/html;text/xml;x-scheme-handler/http;x-scheme-handler/https;
Actions=new-window;new-private-window;
X-XFCE-Source=file:///home/iyzsong/.guix-home/profile/share/applications/chromium.desktop

[Desktop Action new-window]
Name=New Window
Exec=/gnu/store/0bm0k38601acm56pv5jkl6wgvm0rj5xc-ungoogled-chromium-112.0.5615.165-1/bin/chromium

[Desktop Action new-private-window]
Name=New Incognito Window
Exec=/gnu/store/0bm0k38601acm56pv5jkl6wgvm0rj5xc-ungoogled-chromium-112.0.5615.165-1/bin/chromium
 --incognito
--8<---cut here---end--->8---

So it hardcode store paths in 'Exec'.

bug#48549: Can't change keyboard layout in Xfce

[宋文武 via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

> Hello,
>
> In a VM image such as the one we offer for download here:
> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2
> or manually built with
>
> $ guix system image --image-size=20G -t qcow2 
> gnu/system/examples/vm-image.tmpl
>
> it is not possible to switch the keyboard layout (it sticks to the
> default English US one) via the provided GUI (xfce4-keyboard-settings).


Hello, i find that select the layout won't make it active, but you have
to move it to the top row.  Closing now, as it does works..


Thanks.

bug#40880: [XFCE]: No webbrowser installed by default

[宋文武 via Bug reports for GNU Guix]

Michael Rohleder  writes:

> Hi Jonathan,
>
> Jonathan Brielmaier  writes:
>> If you install XFCE and you want to start the webbrowser via the bottom
>> line or the Applications menu, you get a dialog "Choose Preferred
>> Application" instead of a launching web browser.
>>
>> That's because no web browser is installed with XFCE.
>
> I think its because you havent choosen a preferred browser, so I think
> xfce behavior is correct here.
>
> If the user wants a webbrowser he needs to install one, I dont think
> there is anything xfce could do here.


Hello, Xfce project doesn't have a web browser (i think it did had
midori years ago, but it seems abandoned), so I think it's reasonable to
leave the choice to users.

Closing, thanks.

bug#65506: Anki: Preferences Dialog Broken

[宋文武 via Bug reports for GNU Guix]

Christopher Howard  writes:

> Hello, The Anki program works well except that if I select Tools >> 
> Preferences menu, I do not get a preferences menu, and instead I get this 
> error:
>
> ```
> Error 
> An error occurred. Please use Tools > Check Database to see if that fixes the 
> problem. 
> If problems persist, please report the problem on our support site. Please 
> copy and paste the information below into your report.
> Anki 2.1.16 (4bc33e2f) Python 3.10.7 Qt 5.15.8 PyQt 5.15.9
> Platform: Linux
> Flags: frz=False ao=False sv=2
>
> Caught exception:
> Traceback (most recent call last):
>   File 
> "/gnu/store/c6hiswiwspb70q7lfy61fwdyr3i1j6jz-anki-2.1.16/share/anki/aqt/main.py",
>  line 881, in onPrefs
> aqt.dialogs.open("Preferences", self)
>   File 
> "/gnu/store/c6hiswiwspb70q7lfy61fwdyr3i1j6jz-anki-2.1.16/share/anki/aqt/__init__.py",
>  line 82, in open
> instance = creator(*args)
>   File 
> "/gnu/store/c6hiswiwspb70q7lfy61fwdyr3i1j6jz-anki-2.1.16/share/anki/aqt/preferences.py",
>  line 25, in __init__
> self.setupCollection()
>   File 
> "/gnu/store/c6hiswiwspb70q7lfy61fwdyr3i1j6jz-anki-2.1.16/share/anki/aqt/preferences.py",
>  line 80, in setupCollection
> f.lrnCutoff.setValue(qc['collapseTime']/60.0)
> TypeError: setValue(self, val: int): argument 1 has unexpected type 'float'
> ```

Hello, thank you for the report!  It seems QSpinBox really want 'int'
instead of 'float' now.  I have sent a patch to fix this.

bug#48549: Can't change keyboard layout in Xfce

[宋文武 via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

> Hello,
>
> 宋文武  writes:
>
>> Maxim Cournoyer  writes:
>>
>>> Hello,
>>>
>>> In a VM image such as the one we offer for download here:
>>> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2
>>> or manually built with
>>>
>>> $ guix system image --image-size=20G -t qcow2 
>>> gnu/system/examples/vm-image.tmpl
>>>
>>> it is not possible to switch the keyboard layout (it sticks to the
>>> default English US one) via the provided GUI (xfce4-keyboard-settings).
>>
>>
>> Hello, i find that select the layout won't make it active, but you have
>> to move it to the top row.  Closing now, as it does works..
>
> And is this is how it is intended to behave (the same on other GNU/Linux
> distributions, say?).
>
> Thanks for trying it out!

Yes, it also behave the same on ArchLinux, the "Keyboard Layouts" panel
plugin is more easier to use..

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[宋文武 via Bug reports for GNU Guix]

Maxime Devos  writes:

> For example, naev used to work just fine, yet apparently it doesn't
> anymore: https://issues.guix.gnu.org/65390.
>
> Given that Guix has ci.guix.gnu.org, I would expect such new problems
> to be detected and resolved early, and it was detected by
> ci.guix.gnu.org, yet going by issues.guix.gnu.org it was never even
> investigated.

Yes, honestly I only look for build failures from bug reports, not from
CI if i'm not doing a "request for merge" from another branch.

>
> (Yes, there is a delay, but that doesn't matter at all, as there's
> this dashboard .)

I found the dashboard inconvenient to use, it show failures for both
builds and dependencies in the same red color, and can't be searched.
What I usually do is:

1. download the job status json with:
  wget -O jobs.json 
'https://ci.guix.gnu.org/api/jobs?evaluation=692229&system=x86_64-linux'

2. use jq to show package names with build failures:
  cat jobs.json  | jq '. | map(select(.status == 1)) | .[].name' -r

3. select interested one to investigate (if doing merge, diff the failures from
working branch with master).


>
> Do people really need to report 33% of all jobs
> (https://ci.guix.gnu.org/eval/668365/dashboard) before those failures
> are taken seriously, instead of the ‘there don't seem to be that much
> more build failures from the core-updates/... merge, let's solve them
> later (i.e., never)’ that seems to be  status quo?

Maybe we can automatically report the failures as bugs, say every 7
days, and remove a package if it still fail to build in 90 days?

As for now, x86_64 master (eval 668365) has 696 build failures, 604
dependencies failures, 30 unknown (canceld?) failures, total 1330
failures according to the jobs.json data.

Should we open a bug report for each of those 696 build failures?
aarch64-linux-gnu.gcc
abjad-ext-ipython
adms
aegis
anubis
aoflagger
apache-commons-parent-pom
apricots
arachne-pnr
arcan-sdl
arcan
archivebox
arm-linux-gnueabihf.gcc
arpack-ng-openmpi
asignify
asmjit
avro-cpp
azimuth
balsa
barectf
beignet
blacksmith
boinc-server
bonnie++
boost-signals2
btar
burp
cc65
cedille
chaiscript
chezmoi
clang
combinatorial-blas
commoncpp
confusion-mdl
coq-ide
coturn
cpplint
cssc
ctl
cube
darkice
dbus-cxx
ddcci-driver-linux
debops
deluge
dolphin-emu
dosbox-staging
dovecot-trees
d-tools
duc
dvdstyler
dxvk
ecl-april
ecl-binding-arrows
ecl-canonicalized-initargs
ecl-cl-form-types
ecl-cl-gserver
ecl-closure-template
ecl-cl-prevalence
ecl-cmd
ecl-coalton
ecl-coleslaw
ecl-conium
ecl-hdf5-cffi
ecl-lispbuilder-sdl
ecl-mito
ecl-nodgui
ecl-prometheus
ecl-radiance-contribs
ecl-schemeish
ecl-supertrace
ecl-trivial-octet-streams
ecl-trucler
ecl-typo
ecl-yxorp
edi
efilinux
elemental
elpa-openmpi
elpa
emacs-next-pgtk
emacspeak
emacsy
emilua
emulation-station
enblend-enfuse
eog-plugins
epic5
epour
eternalterminal
evdi
fanc
fasthenry
fenics
fiano-fmap
flowee
freedink-engine
freeorion
frotz-dumb-terminal
fulcrum
ganeti
gash-utils
gcc-objc++
gcc-objc
gcc-stripped-tarball
gcc-toolchain
gcc
gcc
ghc-ncurses
ghc-next
ghmm
gimagereader
gitile
gitless
glibc
glibc
glusterfs
gmime
gnash
gnaural
gnome-dictionary
gnucap
go-github-com-charmbracelet-glamour
gourmet
goxel
guile2.0-commonmark
guile2.0-gcrypt
guile2.0-redis
guile2.2-fibers
guile2.2-ics
guile2.2-pfds
guile2.2-xapian
guile-emacs
guile-gnunet
guile-goblins
guile-irc
guile-sparql
guile-static-stripped
guix-minimal
gx-saturator-lv2
gx-slow-gear-lv2
gx-vbass-preamp-lv2
h5check
harminv
hash-extender
hdf5-parallel-openmpi
hdf-eos2
hdf-eos5
hdf-java
hikari
hosts
ht
hydrus-network
hyperledger-iroha
hypre-openmpi.skylake-avx512
i3lock-blur
i586-pc-gnu.gcc-stripped-tarball
i586-pc-gnu.gcc
i586-pc-gnu.gcc
i586-pc-gnu.glibc
i686-linux-gnu.gcc-stripped-tarball
i686-linux-gnu.gcc
i686-linux-gnu.gcc
i686-w64-mingw32.coreutils
i686-w64-mingw32.diffutils
i686-w64-mingw32.findutils
i686-w64-mingw32.gawk
i686-w64-mingw32.gcc
i686-w64-mingw32.gcc
i686-w64-mingw32.gcc
i686-w64-mingw32.gdb-minimal
i686-w64-mingw32.gettext
i686-w64-mingw32.glibc
i686-w64-mingw32.grep
i686-w64-mingw32.guile
i686-w64-mingw32.guix
i686-w64-mingw32.gzip
i686-w64-mingw32.patch
i686-w64-mingw32.sed
i686-w64-mingw32.xz
insight-toolkit
insight-toolkit.haswell
insight-toolkit.ivybridge
insight-toolkit.skylake
insight-toolkit.skylake-avx512
insight-toolkit.westmere
irram
itk-snap
java-asm-tree
java-commons-compress
java-eclipse-jetty-util-ajax
java-eclipse-lsp4j-common
java-fasterxml-jackson-databind
java-geronimo-xbean-asm-util
java-geronimo-xbean-bundleutils
java-janino
java-jgit
java-jsch-agentproxy-jsch
java-objenesis
java-sonatype-aether-api
java-sonatype-spice-parent-pom
java-surefire-logger-api
java-xom
java-xsdlib
js-context-menu
jucipp
julia-calculus
julia-deepdiffs
julia-genericschur
julia-infinity
julia-wcs
kalendar
kbd-neo
khmer
launchmon
leptonica
libfreenect-examples
libiax2
libnfsidmap
libpsyc
libsigrokdecode
libstdc++
libtcod
libtmcg
libtorrent-rasterbar
libvi

bug#64340: libsigrokdecode: check phase fails

[宋文武 via Bug reports for GNU Guix]

Christopher Howard  writes:

> I am trying to install pulseview, but libsigrokdecode fails to build,
> dying at the check phase. It appears to be a dependency-related issue
> - test programs cannot build do to undefined functions.
>
> ```
> ld: ./.libs/libsigrokdecode.so: undefined reference to `PyList_Insert'
> ld: ./.libs/libsigrokdecode.so: undefined reference to `PyModule_AddObject'
> ld: ./.libs/libsigrokdecode.so: undefined reference to `PySys_GetObject'
> <<>>
> ld: ./.libs/libsigrokdecode.so: undefined reference to 
> `PyUnicode_AsUTF8String'
> ld: ./.libs/libsigrokdecode.so: undefined reference to `Py_IsInitialized'
> ld: ./.libs/libsigrokdecode.so: undefined reference to `PyDict_New'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:751: tests/main] Error 1
> make: *** [Makefile:1353: check-am] Error 2
>
> Test suite failed, dumping logs.
> error: in phase 'check': uncaught exception:
> %exception #<&invoke-error program: "make" arguments: ("check" "-j"
> "4") exit-status: 2 term-signal: #f stop-signal: #f>
> phase `check' failed after 0.5 seconds
> command "make" "check" "-j" "4" failed with status 2
> ```
>
> Full build log is attached.
>
> I see an open bug at , but I'm not sure if 
> this is the same issue or not.
>

Thanks for the report, and I had fixed it by apply update for
libsigrokdecode from 63971.

Closing!

bug#65391: [Cuirass] feature requests for dashboard

[宋文武 via Bug reports for GNU Guix]

Hello, I think the current CI dashboard (eg: 
https://ci.guix.gnu.org/eval/693369/dashboard)
is a little inconvenient to use, and I'd like it have:

1. different colors for build failures (status=1) and dependencies
failures (status=2), and other type failures.  Maybe yellow for
dependencies failures, and grey for other.

2. more search options in addition to job name, eg:
status:failed
status:failed-dependency
status:canceled
team:python
   also a help like in mumi https://issues.guix.gnu.org/help#search for
   those options.

3. for a failed build, show a link to its bug report on
   issues.guix.gnu.org if one existed.
   eg, for: https://ci.guix.gnu.org/build/1170869/details
   add a Issue row with link to https://issues.guix.gnu.org/65392
   so we can know this build failure is known.




Maxim Cournoyer  writes:

>> I found the dashboard inconvenient to use, it show failures for both
>> builds and dependencies in the same red color, and can't be searched.
>> What I usually do is:
>>
>> 1. download the job status json with:
>>   wget -O jobs.json 
>> 'https://ci.guix.gnu.org/api/jobs?evaluation=692229&system=x86_64-linux'
>>
>> 2. use jq to show package names with build failures:
>>   cat jobs.json  | jq '. | map(select(.status == 1)) | .[].name' -r
>>
>> 3. select interested one to investigate (if doing merge, diff the failures 
>> from
>> working branch with master).
>
> Maybe we should open Cuirass feature requests on our bug tracker to
> remember what would be valuable to implement.

Okay, I'll open one here.

bug#65506: [bug#65533] [PATCH] gnu: anki: Fix preferences error.

[宋文武 via Bug reports for GNU Guix]

>
> * gnu/packages/education.scm (anki)[source]: Add snippet.
> ---
>  gnu/packages/education.scm | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/gnu/packages/education.scm b/gnu/packages/education.scm
> index bb307cf7ab..21c8a60c0b 100644
> --- a/gnu/packages/education.scm
> +++ b/gnu/packages/education.scm
> @@ -737,6 +737,13 @@ (define-public anki
> version "-source.tgz"))
> (sha256
>  (base32 "1gfr51rnllkyzli73p4r51h5ypzfa3m7lic3m3rzpywmqwrxs07k"))
> +   (modules '((guix build utils)))
> +   ;; #65506 Fix preferences error.
> +   (snippet '(substitute* "aqt/preferences.py"
> +   (("qc\\['collapseTime']/60\\.0" x)
> +(format #f "int(~a)" x))
> +   (("qc\\['timeLim']/60\\.0" x)
> +(format #f "int(~a)" x
> (patches (search-patches "anki-mpv-args.patch"
>  (build-system gnu-build-system)
>  (arguments
>
> base-commit: 1c916c167b7eb1f2f8af2cf621aa1512b00b1033


Pushed now, closing.

bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)

[宋文武 via Bug reports for GNU Guix]

Maxime Devos  writes:

>> Maybe we can automatically report the failures as bugs, say every 7
>> days, and remove a package if it still fail to build in 90 days?
>
> The first part looks reasonable to me (though I would decrease 7 days
> to daily or even hourly, as I don't see a point in the delay), but how
> does the second part (removing packages) make sense at all?
>

Oh, to be more clear I didn't mean automatically remove a package, but
notify guix-devel to consider removing one if its "fail to build" issue
had existed for a long time and no one care.

> [...]
>
> Instead, what about:
>
>> Maybe we can automatically report the failures as bugs, say every
>> hour, and revert the commit(s) causing the new build failures if they
>> haven't been fixed in a week.

Yes, automatically report bugs would be helpful.  And I'll leave the
reverting rights to committers, which usually need some research and
maybe risky.


> [...]
> Expanding upon this a bit more:
>
>* Expecting that people fix build failures of X when updating X seems
>  reasonable to me, and I think this is not in dispute.
>
>* Expecting that people using X fix build failures of X or risk the
>  package X being deleted when someone else changed a dependency Y of
>  X seems unreasonable to me.   More generally, I am categorically
>  opposed to:
>
>  ‘If you change something and it breaks something else, you should
>  leave fixing the something else to someone (unless you want to
>  fix it yourself).’
>
>  (I can think of some situations where this is a good thing, but not
>  in general and in particular not in this Guix situation.)
>
>  I mean, I don't know about you, but for me it fails the categorical
>  imperative and the so-called Golden Rule.

I agree.  Well sometimes if breaks are overlooked by me, then it's very
welcome for other to give me a hand.


Thanks.

bug#65594: [feature] [qa] Notify users by email of problems

[宋文武 via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

> Hi,
>
> This is a feature request for QA: I think it'd be nice if it sent
> notifications by email when a submitted patch or series has any kind of
> issues, such as lint warnings, newly introduced breakage, etc.
>
> That'd be less clicking around to navigate to the information (currently
> one has to go to the issues.guix.gnu.org page and click on the badge, or
> search on the QA site), and would help new users discover it exists.

Yes, it could reply to issue...@debbugs.gnu.org, CC the submitter, and
include results.  Also I think a start run / rerun (by reroll patches)
notify is useful too.

bug#54447: cuirass: missing derivation error

[宋文武 via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

> I wonder if these could be related to the DDoS protection discovered on
> the Berlin network.  I'll keep looking for other, potentially different
> occurrences.


Hello, this one for ddd: https://ci.guix.gnu.org/build/1372655/log/raw

  cannot build missing derivation 
?/gnu/store/anzz2p18b7r9x45y350avnk8br2yihi2-ddd-3.4.0.drv?

Restart it on CI still got the same error.

bug#63151: [PATCH] gnu: sound-juicer: Update to 3.40.0.

[宋文武 via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

> Hi,
>
> iyzs...@envs.net writes:
>
>> From: 宋文武 
>>
>> * gnu/packages/gnome.scm (sound-juicer): Update to 3.40.0.
>> [arguments]: Adjust 'disable-gtk-update-icon-cache'.
>> Add 'wrap-program' for GST_PLUGIN_SYSTEM_PATH.
>
> Installed, thank you!
>
> Related: it doesn't find my CD drive, although I have two DVD drives
> in there.  Is there something missing at the udev level in Guix System
> for that to work?

Without CD drivers I haven't test it, I guess the current user need
permissions for '/dev/sr*'.


Thank you handle the commits (also dbus-cxx ones)!

bug#63686: sound-juicer-3.38-0: fails configure phase

[宋文武 via Bug reports for GNU Guix]

Christopher Howard  writes:

> Package "sound-juicer" fails configure phase. Build log
> attached. Built with command:

Hello, it had been fixed with commit
4d4bf9ab1f9c3ce850bef9c6934a941c0337dd3b,

Closing, thanks!

bug#64465: plasma-workspace 5.25.5 build segfaults in check-after-install phase

[宋文武 via Bug reports for GNU Guix]

Athena Martin  writes:

> I did a 'guix system build' of my Plasma configuration ahead of actually
> installing it and got the following build failure:
>
> [...]
> The following tests FAILED:
>   4 - screenpooltest (SEGFAULT)
> [...]
> guix system: error: build of 
> `/gnu/store/ims94hwcfi3wjsxqz89vr8xhr2shxm3d-plasma-workspace-5.25.5.dr
> v' failed

Hello, we have plasma-workspace 5.27.7 build fine on CI now, closing.

If the issue still exist, please reopen it, thanks!

bug#36345: Font and other Issues/Bugs in Guix System

[宋文武 via Bug reports for GNU Guix]

Freddy Reimer  writes:

> Hello,
>
> I have been trying out guix in a VM, and would like to report a few
> bugs I've run into.
> [...]
> [...]
> The first of these issues, and one I managed to get by on my own, was
> my terminal freaking out when I first installed one. 
> [...]
> The second issue is that icecat doesn't display numbers.


Hello I believed those issues was fixed in fontconfig (use dejavu as
default font and fix cache update).

Closing, thanks.

bug#67329: Plan9port breaks Emacs Dired

[宋文武 via Bug reports for GNU Guix]

Navajeeth  writes:

> There’s a bug with the ‘plan9port’ (p9p) package on Guix—installing it on the 
> Guix System breaks Dired inside Emacs.
> When I try to open a Dired buffer with p9p installed, I get the following 
> error:
>
>  (error "Listing directory failed but ‘access-file’ worked")
>error("Listing directory failed but `access-file' worked")
>insert-directory("/home/guix/" "--dired -lFaGh1v --group-directories-first 
> --time-..." nil t)
>dired-insert-directory("/home/guix/" "-lFaGh1v --group-directories-first 
> --time-style=lo..." nil nil t)
>dired-readin-insert()
>#()
>combine-change-calls-1(1 17349 # F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_47>)
>dired-readin()
>dired-revert(nil nil)
>revert-buffer()
>dired-internal-noselect("~/" nil)
>dired-noselect("~/" nil)
>dired("~/" nil)
>funcall-interactively(dired "~/" nil)
>command-execute(dired)
>
> p9p distributes its own version of ‘ls’, so maybe that’s interfering?
>
> The output of ‘ls’, on the command-line, with p9p installed is:
>
>~% ls --version
>usage: ls [-dlmnpqrstuFQ] [file ...]
>~% ls --help
>usage: ls [-dlmnpqrstuFQ] [file ...]
>~% ls -v
>usage: ls [-dlmnpqrstuFQ] [file ...]
>~% ls
>usage: ls [-dlmnpqrstuFQ] [file ...]

Hello, I beileve this had been fixed with commit 2538a773c, which put
p9p into $out/plan9, only '9' is available via PATH.

User can append $GUIX_PROFILE/plan9/bin into $PATH if wanted.


Close now, thanks!

bug#69648: [bug#69622] [PATCH] gnu: plasma-desktop: fix build.

[宋文武 via Bug reports for GNU Guix]

Zheng Junjie  writes:

> * gnu/packages/kde-plasma.scm (plasma-desktop): fix build.
> [inputs]: Replace qtwayland with qtwayland-5.

Pushed as commit e51c26ef2d, thank you!

Also fixes #69648, close both.

bug#69667: build of sway-1.9-checkout.drv failed

[宋文武 via Bug reports for GNU Guix]

chris  writes:

> guix home reconfigure fails at sway-1.9. The bottom of the drv file shows 
> this,
> ```
> `source is at 'sway-1.9-checkout'
> [...]
> ERROR: In procedure delete-file:
> In procedure delete-file: No such file or directory

Hello, sway build fine for me (and CI), this seems like a disk or
filesystem issue on your side.

bug#57677: GIMP retains reference to GCC

[宋文武 via Bug reports for GNU Guix]

Fixed in commit b099e5e98033, forgot to close.

bug#70100: [bug#70176] [PATCH] * gnu/packages/kde-frameworks.scm (kdelibs4support): [arguments]<#:phases>: In check-post-install phase, exclude kmimetypetest.

[宋文武 via Bug reports for GNU Guix]

Hello, I fixed it by patch the test data in 9acc056725.

Thank you!

bug#70529: Several packages have dbus service files with broken file paths

[宋文武 via Bug reports for GNU Guix]

Nathan Dehnel  writes:

> I was investigating powerdevil and snapper being broken and I
> discovered packages with incorrect file paths in the Exec line of
> their dbus services
>
> $ ls -d /gnu/store/**/share/dbus-1/services/** | grep -v
> profile/share/dbus-1 | while read line; do grep Exec $line 2>
> /dev/null | grep -v /gnu/store && echo $line >>/dev/stderr; done
> Exec=libexec/fontinst
> /gnu/store/6hz6j922gs1861h49id3ddjsg02cwkl1-plasma-workspace-5.27.7/share/dbus-1/services/org.kde.fontinst.service
> Exec=libexec/fontinst
> /gnu/store/nv8ccgy6jzfjkik5c5vy6id7dplnbb1y-plasma-workspace-5.27.7/share/dbus-1/services/org.kde.fontinst.service
> [...]

Hello, thank you the report, I have send a patch to fix this (tested
fine with ktexteditor and plasma-disks).

bug#40885: [bug#70508] [PATCH] services: Add gvfs-service-type.

[宋文武 via Bug reports for GNU Guix]

宋文武  writes:

>>From Patch1:
>> * gnu/packages/xfce.scm (thunar)[build-system]: Switch to 
>> glib-or-gtk-build-system.
>>
>
>>From Patch2:
>> * gnu/services/desktop.scm (gvfs-service-type): New variable.
>> (gvfs-configuration, make-gvfs-configuration, gvfs-configuration?,
>> gvfs-package): New procedures.
>> (): New record.
>> * doc/guix.texi (Desktop Services): Document it.

Pushed to master as commits 1fbbdef3c9..3bd8d238ab, 'gvfs-service-type'
is not enabled by default due to its closure size (webkitgtk, samba, etc.)

bug#41927: gio mount unusable on many setups, likely caused by missing dependencies

[宋文武 via Bug reports for GNU Guix]

raingloom  writes:

> [...]
>
> Could someone who knows what the hell GVFS is doing help with this? I'd
> really like to avoid installing the entirety of Gnome just to mount some
> folders.

Hello, this issue had been fixed by commit 3bd8d238ab, which introduces
'gvfs-service-type'.  Close now, thanks!

bug#36561: gvfs and/or sftp bugs and pain points

[宋文武 via Bug reports for GNU Guix]

Hello, this issue had been fixed with commit 3bd8d238aba7, which
introduces a 'gvfs-service-type', add it to the system and reboot to
test.  Close now, thanks!

bug#71458: wireplumber service fails to start in home-pipewire-service-type

[宋文武 via Bug reports for GNU Guix]

Antero Mejr  writes:

> Immediately after logging into an account with
> home-pipewire-service-type in the home environment, about 5 error
> messages appear about the wireplumber service failing and restarting.
> Eventually herd gives up trying to start wireplumber.
>
> Trying to start it manually using `herd start wireplumber` results in
> the message:
> herd: error: failed to start service wireplumber
>
> The other pipewire-related services appear to have started successfully.
>
> home-dbus-service-type is in the home environment also.


Have a look at ~/.local/state/log/shepherd.log, it should have some logs
from wireplumber, which may help debuging.

bug#71458: wireplumber service fails to start in home-pipewire-service-type

[宋文武 via Bug reports for GNU Guix]

Antero Mejr  writes:

> 宋文武  writes:
>
>> Antero Mejr  writes:
>>
>> Have a look at ~/.local/state/log/shepherd.log, it should have some logs
>> from wireplumber, which may help debuging.
>
> It was a problem with older versions of Wireplumber, this
> yet-to-be-merged patch resolves the issue:
>
> https://issues.guix.gnu.org/71463

Merged now, close, thank you!

bug#70456: core-updates failed package: time

[宋文武 via Bug reports for GNU Guix]

time-1.9 fail its test on core-updates:
https://ci.guix.gnu.org/build/4587082/log/raw

time(1) failed to detect 5MB allcoation.
  mem-baseline(kb): 768
  mem-5MB(kb):  5720
  delta(kb):4952
FAIL tests/time-max-rss.sh (exit status: 1)

delta is 4952, but it expect 5000-6000.

No idea what's the reason, maybe skip it?

bug#70456: core-updates failed package: libfaketime for i686-linux

[宋文武 via Bug reports for GNU Guix]

宋文武  writes:

libfaketime (dependency of nss, poppler, cairo) failed for i686-linux

https://ci.guix.gnu.org/build/4555668/log/raw


out=1717606732 (secs since Epoch) expected=1 - bad
out=1717606732 (secs since Epoch) expected=2 - bad
out=1717606732 (secs since Epoch) expected=4 - bad


that mean FAKETIME=1 date doesn't report 1, but 1717606732.
I think that due to libfaketime doesn't work with _TIME_BITS=64 on 32bit
systems.  Maybe this issue
https://github.com/wolfcw/libfaketime/issues/418.

I have no idea how to fix this, help need!

bug#72284: kdeconnect-app fails to start

[宋文武 via Bug reports for GNU Guix]

Hello, since the update to 24.05.2, 'kdeconnect-app' fails with:

QQmlApplicationEngine failed to load component
qrc:/qt/qml/org/kde/kdeconnect/app/Main.qml:49:13: Type QQC2.ToolBar unavailable
qrc:/qt/qml/org/kde/desktop/ToolBar.qml: Type GlobalSonnetSettings unavailable
qrc:/qt/qml/org/kde/desktop/private/GlobalSonnetSettings.qml:10:1: module 
"org.kde.sonnet" is not installed

bug#72284: kdeconnect-app fails to start

[宋文武 via Bug reports for GNU Guix]

Zheng Junjie  writes:

> 宋文武 via Bug reports for GNU Guix  writes:
>
>> Hello, since the update to 24.05.2, 'kdeconnect-app' fails with:
>>
>> QQmlApplicationEngine failed to load component
>> qrc:/qt/qml/org/kde/kdeconnect/app/Main.qml:49:13: Type QQC2.ToolBar 
>> unavailable
>> qrc:/qt/qml/org/kde/desktop/ToolBar.qml: Type GlobalSonnetSettings 
>> unavailable
>> qrc:/qt/qml/org/kde/desktop/private/GlobalSonnetSettings.qml:10:1: module 
>> "org.kde.sonnet" is not installed
>
> i think this patch can fix it.
>
> From b430840809bfb936ac8c17f7a40da77d7549449c Mon Sep 17 00:00:00 2001
> Message-ID: 
> 
> From: Zheng Junjie 
> Date: Thu, 25 Jul 2024 12:50:52 +0800
> Subject: [PATCH] gnu: kdeconnect: Add sonnet dependency.
>
> * gnu/packages/kde.scm (kdeconnect)[inputs]: Add sonnet.
>
> Change-Id: I494bdf393d433f6f3dffe8dbe1774f53776fbc63
> ---
>  gnu/packages/kde.scm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
> index 44b3b10606..59f3b1052b 100644
> --- a/gnu/packages/kde.scm
> +++ b/gnu/packages/kde.scm
> @@ -1361,6 +1361,7 @@ (define-public kdeconnect
> qtdeclarative
> qtmultimedia
> qtwayland
> +   sonnet
> wayland
> modemmanager-qt
> libxkbcommon))

Pushed to master, thanks.

bug#72346: dbus session daemon fail to start kdeconnectd

[宋文武 via Bug reports for GNU Guix]

Hello, kdeconnect-app fail to start 'kdeconnectd' automatically.

It reports:
2024-07-29 11:06:12 dbus-daemon[293]: [session uid=1000 pid=293 pidfd=4] 
Activated service 'org.kde.kdeconnect' failed: Failed to execute program 
org.kde.kdeconnect: No such file or directory

And we have org.kde.kdeconnect.service:
[D-BUS Service]
Name=org.kde.kdeconnect
Exec=kdeconnectd

Maybe the 'Exec=' must have an absolute path?

bug#72346: dbus session daemon fail to start kdeconnectd

[宋文武 via Bug reports for GNU Guix]

Zheng Junjie  writes:

> [...]
> Subject: [PATCH] gnu: kdeconnect: Fix dbus autostart.
>
> * gnu/packages/kde.scm (kdeconnect)[phases]: Add fix-dbus-autostart phase.
>
> Change-Id: I27ac61e41f15f9ff2de658fbd04633820f5e0966
> ---
>  gnu/packages/kde.scm | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
> index 59f3b1052b..0e51e3e230 100644
> --- a/gnu/packages/kde.scm
> +++ b/gnu/packages/kde.scm
> @@ -1326,6 +1326,12 @@ (define-public kdeconnect
> "-DKDE_INSTALL_LIBEXECDIR=libexec"
> ;; So kdeconnect.so isn't installed to lib/plugins
> "-DPLUGIN_INSTALL_DIR=lib/qt6/plugins")
> +   #:phases #~(modify-phases %standard-phases
> +(add-after 'unpack 'fix-dbus-autostart
> +  (lambda _
> +(substitute* 
> "daemon/org.kde.kdeconnect.service.in"
> +  (("kdeconnectd")
> +   (string-append #$output 
> "/bin/kdeconnectd"))
> #:tests? #f)) ; tests fail hard in our build environment
>  (native-inputs
>   (list extra-cmake-modules
>
> base-commit: fdc6274de5b1d617fcabb3f3af9d2c0dd2a6520d
> prerequisite-patch-id: 9429d31c7fc951f1c90d8df0d4c1d5655f38287f
> prerequisite-patch-id: 8aba1f6e2d202562de36cf70cb0cb0a4eaa76de7

Pushed to master, thank you!