bug#52089: [core-updates-frozen] geeqie fails to launch

[Jack Hill]

On Wed, 24 Nov 2021, Maxim Cournoyer wrote:


Hello,

The failure looks like this:

--8<---cut here---start->8---
$ geeqie

(geeqie:6216): Gdk-ERROR **: 23:30:16.057: The program 'geeqie' received an X 
Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
 (Details: serial 180 error_code 2 request_code 152 (GLX) minor_code 24)
 (Note to programmers: normally, X errors are reported asynchronously;
  that is, you will receive the error a while after causing it.
  To debug your program, run it with the GDK_SYNCHRONIZE environment
  variable to change this behavior. You can then get a meaningful
  backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap

$ GDK_SYNCHRONIZE= geeqie

(geeqie:6217): Clutter-CRITICAL **: 23:30:26.345: Unable to initialize Clutter: 
Unable to initialize the Clutter backend: no available drivers found.
Can't initialize clutter-gtk.
Start Geeqie with the option "geeqie --disable-clutter"
--8<---cut here---end--->8---

The suggested workaround (geeqie --disable-clutter) works.

Thanks,

Maxim


Interesting. I don't think I'm going to be of any help, but I just testing 
running geeqie from a guix shell with core-updates-frozen commit 
d0f6e8ae7944666469ec1a226df502063d4d0670 under a sway wayland session and 
it launches fine as a native wayland client.


It doesn't display any images though, but maybe that's a different bug. It 
worked the same with and without --disable-clutter.


Best,
Jack

bug#52069: [patch] add gst-plugins-base-gl (with opengl support)

[Maxim Cournoyer]

Hello,

"Dr. Arne Babenhauserheide"  writes:

> Hi,
>
> The attached patch adds a derivative package of gst-plugins-base that
> includes gl support and has mesa as input.
>
> I needed that for an application.
>
> Best wishes,
> Arne
>
> From a1435b89c6ff01c1644bea671628678eebf3dfc2 Mon Sep 17 00:00:00 2001
> From: Arne Babenhauserheide 
> Date: Wed, 24 Nov 2021 01:58:32 +0100
> Subject: [PATCH] gnu: gst-plugins-base-gl: add package version that includes
>  opengl.
>
> * gnu/packages/gstreamerr.scm (gst-plugins-base-gl): -Dgl=enabled, input: mesa
> ---
>  gnu/packages/gstreamer.scm | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
> index bb991789da..324af10ee0 100644
> --- a/gnu/packages/gstreamer.scm
> +++ b/gnu/packages/gstreamer.scm
> @@ -581,6 +581,17 @@ (define-public gst-plugins-base
>  for the GStreamer multimedia library.")
>  (license license:lgpl2.0+)))
>  
> +(define-public gst-plugins-base-gl
> +  (package (inherit gst-plugins-base)
> +(name "gst-plugins-base-gl")
> +(inputs
> + `(("mesa" ,mesa) ;; required for libgstgl
> +   ,@(package-inputs gst-plugins-base)))
> +(arguments
> + `(,@(package-arguments gst-plugins-base)
> +   #:tests? #f ;; check fails with gl

Disabling tests shouldn't be done lightly; considerable efforts have
probably gone in enabling them in the first place and they are one of
our best allies in assessing the negative impacts of an upgrade.  Could
you please investigate what is at cause?  Perhaps it's a matter of
adding an argument to the Xvfb invocation?

Thank you!

Maxim

bug#52090: swaylock unaligned fastbin chunk detected

[Jack Hill]

Hi Guix,

swaylock sometimes crashes on core-updates-frozen 
d0f6e8ae7944666469ec1a226df502063d4d0670 with:


$ swaylock -e -c 195521 -F
malloc_consolidate(): unaligned fastbin chunk detected
Aborted

I think that this could be upstream issue #162 [0] since I see 
malloc_consolidate() in that stacktrace, and the host where I'm seeing 
this problem has some monitors that take a while to wake up from sleep.


[0] https://github.com/swaywm/swaylock/issues/162

Best,
Jack

bug#52089: [core-updates-frozen] geeqie fails to launch

[Maxim Cournoyer]

Hello,

The failure looks like this:

--8<---cut here---start->8---
$ geeqie

(geeqie:6216): Gdk-ERROR **: 23:30:16.057: The program 'geeqie' received an X 
Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 180 error_code 2 request_code 152 (GLX) minor_code 24)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap

$ GDK_SYNCHRONIZE= geeqie

(geeqie:6217): Clutter-CRITICAL **: 23:30:26.345: Unable to initialize Clutter: 
Unable to initialize the Clutter backend: no available drivers found.
Can't initialize clutter-gtk.
Start Geeqie with the option "geeqie --disable-clutter"
--8<---cut here---end--->8---

The suggested workaround (geeqie --disable-clutter) works.

Thanks,

Maxim

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

[Maxim Cournoyer]

Hello,

I've found a workaround: restarting elogind via SSH resolved the issue.

I guess itt may be a race between elogind and dbus-system (elogind gets
started before dbus-system is fully up, and the communication with the
session bus is somehow crippled from there?).

I'll experiment with the elogind service a bit, adding a dumb sleep to
its start slot to see if it prevents the race.

Thank you,

Maxim

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

[Maxim Cournoyer]

Hello Josselin,

Josselin Poiret  writes:

> Hello Maxim,
>
> Maxim Cournoyer  writes:
>
>> --8<---cut here---start->8---
>> Nov 23 01:09:14 localhost dbus-daemon[383]: [system] Activating
>> service name='org.freedesktop.login1' requested by ':1.17' (uid=0
>> pid=370
>> comm="/gnu/store/ximad0zvg12r4x0x80mvym8hzg0n33jl-shadow") (using 
>> servicehelper)
>> Nov 23 01:09:14 localhost elogind[1189]: elogind is already running as PID 
>> 390
>> Nov 23 01:09:20 localhost shepherd[1]: Respawning term-tty1. 
>> Nov 23 01:09:20 localhost shepherd[1]: Service host-name has been started. 
>> Nov 23 01:09:20 localhost shepherd[1]: Service term-tty1 has been started.
>> Nov 23 01:09:39 localhost dbus-daemon[383]: [system] Failed to
>> activate service 'org.freedesktop.login1': timed out
>> (service_start_timeout=25000ms)
>> --8<---cut here---end--->8---
>>
>> I don't remember if I saw the slim login screen; but in any case I
>> couldn't successfully login even via a ptty.
>>
>> It may have to do with polkit.
>>
>> To be investigated.
>>
>> This happened on a system *not* using gdm (it uses slim) and with
>> ratpoison as the WM, on commit f42bc604547d9ee8e35fcd66d5db7786954cfac3
>> of the core-updates-frozen branch.
>>
>> To be investigated.
>
> I cannot reproduce in a fresh VM on commit
> d5de4e163ccef80f78bc5fe330f568d8fe3a23ab, and can login just fine, with
>
>   (services (cons* (service slim-service-type (slim-configuration))
>(modify-services %desktop-services
>  (delete gdm-service-type
>
> Is this still affecting you?

Yes!  It didn't occur in a 'guix system vm my-config.scm', but the exact
same config deployed on my machine fails at login.

Some symptoms:

1. Slim login screen comes up, but after entering credentials Xorg
resets (back to login screen)

2. going to a TTY and attempting to login there, it'd fail with a "Login
failed after 60 s timeout" or similar error.

3. I can login via SSH (thanks goodness!)

4. There are no errors (EE) in /var/log/Xorg.0.log

5. here's the tail of my /var/log/messages:

--8<---cut here---start->8---
Nov 24 21:23:54 localhost ntpd[346]: Soliciting pool server 216.197.156.83
Nov 24 21:23:55 localhost ntpd[346]: Soliciting pool server 206.108.0.133
Nov 24 21:23:56 localhost wpa_supplicant[343]: wlp4s0: CTRL-EVENT-BEACON-LOSS 
Nov 24 21:23:56 localhost ntpd[346]: Soliciting pool server 98.143.85.249
Nov 24 21:23:57 localhost ntpd[346]: Soliciting pool server 192.95.27.155
Nov 24 21:23:58 localhost dbus-daemon[341]: [system] Activating service 
name='org.freedesktop.login1' requested by ':1.16' (uid=0 pid=324 
comm="/gnu/store/ximad0zvg12r4x0x80mvym8hzg0n33jl-shadow") (using servicehelper)
Nov 24 21:23:58 localhost elogind[1114]: elogind is already running as PID 355
Nov 24 21:24:11 localhost wpa_supplicant[343]: wlp4s0: CTRL-EVENT-BEACON-LOSS 
Nov 24 21:24:21 localhost last message repeated 5 times
Nov 24 21:24:23 localhost dbus-daemon[341]: [system] Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Nov 24 21:24:23 localhost shepherd[1]: Respawning term-tty2. 
Nov 24 21:24:23 localhost shepherd[1]: Service host-name has been started. 
Nov 24 21:24:23 localhost shepherd[1]: Service term-tty2 has been started. 
Nov 24 21:24:23 localhost wpa_supplicant[343]: wlp4s0: CTRL-EVENT-BEACON-LOSS 
Nov 24 21:24:27 localhost last message repeated 3 times
Nov 24 21:26:04 localhost dbus-daemon[341]: [system] Activating service 
name='org.freedesktop.login1' requested by ':1.17' (uid=0 pid=429 
comm="/gnu/store/nvvmksc9pvahqmypaz3h8mqya82vnga8-slim-1") (using servicehelper)
Nov 24 21:26:04 localhost elogind[1127]: elogind is already running as PID 355
Nov 24 21:26:29 localhost dbus-daemon[341]: [system] Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Nov 24 21:26:29 localhost shepherd[1]: Respawning xorg-server. 
Nov 24 21:26:29 localhost shepherd[1]: Service host-name has been started. 
Nov 24 21:26:29 localhost shepherd[1]: Service xorg-server has been started. 
Nov 24 21:27:23 localhost ntpd[346]: Soliciting pool server 209.115.181.108
Nov 24 21:27:24 localhost ntpd[346]: Soliciting pool server 138.197.153.200
Nov 24 21:27:25 localhost ntpd[346]: Soliciting pool server 162.159.200.123
Nov 24 21:27:26 localhost ntpd[346]: Soliciting pool server 162.159.200.1
Nov 24 21:29:09 localhost ntpd[346]: kernel reports TIME_ERROR: 0x41: Clock 
Unsynchronized
Nov 24 21:29:42 localhost ntpd[346]: Soliciting pool server 199.182.221.110
Nov 24 21:35:23 localhost wpa_supplicant[343]: wlp4s0: CTRL-EVENT-SIGNAL-CHANGE 
above=0 signal=-87 noise=-95 txrate=27
Nov 24 21:35:32 localhost wpa_supplicant[343]: wlp4s0: CTRL-EVENT-SIGNAL-CHANGE 
above=1 signal=-67 noise=-95 txrate=27
Nov 24 21:42:50 localhost dbus-daemon[341]: [system] Activating service 
name='o

bug#30123: claws-mail plugins not updated

[Julien Lepiller]

The problem seems to be solved now. Thanks for reminding me of my old bugs :). 
Closing.

Le 24 novembre 2021 18:32:20 GMT-05:00, zimoun  a 
écrit :
>Hi Julien,
>
>On Mon, 15 Jan 2018 at 14:52, julien lepiller  wrote:
>
>> claws-mail has a plugin system to add functionnality. For instance, to add 
>> PGP
>> support, one has to load 3 plugins from the claws-mail package. By default,
>> claws-mail looks in its store directory to propose available plugins.
>>
>> When upgrading claws-mail, the configuration doesn't change. Plugins are 
>> still
>> looked for in the old store location, so old plugins are still used. This is
>> bad for security and compatibility. Another issue is when running guix gc
>> afterwards: the old plugins are deleted and claws-mail issues an error 
>> message
>> on startup because it cannot find them anymore.
>
>Reading the recent activity about claws-mail, is it still an issue?
>
>Cheers,
>simon

bug#30401: gitolite some important hooks not working

[zimoun]

Hi,

On Fri, 09 Feb 2018 at 12:52, n...@crash.cx wrote:
> A paste that lost its formatting but speaks for itself:

[...]

> Installing the module + perl into the profile didn't help either.
> There's a service NixOS provides which we could replicate, but
> for now I have a crash recovery to make and would like to get
> gitolite up and running. Ideas, input, even small hacks welcome.
>
> guix package -l:
> Generation 1Feb 09 2018 13:28:26
>   perl-data-dumper-concise  2.023   out
>   /gnu/store/fckd34g3njmjc8yl4vk3hkqj5cbv9mvj-perl-data-dumper-concise-2.023
>
> Generation 2Feb 09 2018 13:32:57(current)
>  + perl 5.26.0  out
>  /gnu/store/9g4fpfz86vjkx83v5696vm5dzg2sc9qj-perl-5.26.0
>
>
>  env:
>  
> DICPATH=/home/git/.guix-profile/share/hunspell:/run/current-system/profile/share/hunspell
>  LANG=en_US.UTF-8
>  GTK_DATA_PREFIX=/run/current-system/profile
>  GST_PLUGIN_PATH=/home/git/.guix-profile/lib/gstreamer-1.0
>  GIT_SSL_CAINFO=/run/current-system/profile/etc/ssl/certs/ca-certificates.crt
>  LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
>  
> GUILE_LOAD_COMPILED_PATH=/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2
>  USER=git
>  TZDIR=/gnu/store/bzj472nmnnj5hcfd5yvfiqip1wzw84p9-tzdata-2017b/share/zoneinfo
>  GUIX_LOCPATH=/run/current-system/locale
>  PWD=/home/git
>  HOME=/home/git
>  XDG_DATA_DIRS=/home/git/.guix-profile/share:/run/current-system/profile/share
>  SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
>  GIT_EXEC_PATH=/run/current-system/profile/libexec/git-core
>  SHELL=/gnu/store/ars9lm9jk9hgdifg0gqvf1jrvz5mdg1j-bash-4.4.12/bin/bash
>  TERM=st-256color
>  PERL5LIB=/home/git/.guix-profile/lib/perl5/site_perl
>  SHLVL=1
>  
> MANPATH=/run/current-system/profile/share/man:/home/git/.guix-profile/share/man:/run/current-system/profile/share/man
>  SSL_CERT_DIR=/etc/ssl/certs
>  BASH_LOADABLES_PATH=/run/current-system/profile/lib/bash
>  LOGNAME=git
>  GUILE_LOAD_PATH=/run/current-system/profile/share/guile/site/2.2
>  
> XDG_CONFIG_DIRS=/home/git/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
>  DBUS_FATAL_WARNINGS=0
>  
> PATH=/home/git/.guix-profile/bin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin
>  
> INFOPATH=/run/current-system/profile/share/info:/home/git/.guix-profile/share/info:/run/current-system/profile/share/info
>  
> XCURSOR_PATH=/home/git/.icons:/home/git/.guix-profile/share/icons:/run/current-system/profile/share/icons
>  _=/run/current-system/profile/bin/env

Reading the all thread, it appears to me that it lacks info for
investigating.  Therefore, I am closing.

If I miss something, feel free to reopen.


Cheers,
simon

bug#30840: the panel crash

[zimoun]

Hi,

Thanks for the report and sorry for the absence of answer.

On Sat, 17 Mar 2018 at 15:10, Catonano  wrote:
> Maybe related to the previous bug I filed (dbus unavailability ?)
>
> When attempting to add a keyboard layout, the panel crashes
>
> Here the footage
> https://youtu.be/anHeACHu8OQ

Is it still an issue?  If not, let close this old bug. :-)


Cheers,
simon

bug#30839: Gnome produces lots of errors and warnings

[zimoun]

Hi,

On Sat, 17 Mar 2018 at 14:18, Catonano  wrote:

> I used a Qemu based guest in order to show the copious amount of
> errors and warnings that Gnome produces on GuixSD

Thanks for the report.  Is it still an issue?  Especially with GNOME of
core-updates-frozen?

After the merge to master, please report again the issue about GNOME.
Or let close the bug.


Cheers,
simon

bug#30896: Guix pull problems on armhf

[zimoun]

Hi,

On Wed, 21 Mar 2018 at 20:59, Jelle Licht  wrote:
> I have been running the binary Guix installation on top of Armbian on my
> Rockchip RK3288 (armhf) based computing platform.
>
> Up till about ~8 days ago, guix pull worked as intended. Recently,
> running guix pull leads to the following error message
> `./guix/build/pull.scm:44:20: ./guix/build/pull.scm:44:20: Throw to key
> `match-error' with args `("match" "no matching pattern"' [1]
>
>
> I already checked that re{moving,naming} `$HOME/.config/guix/latest'
> does not change anything. Neither does running `./pre-inst-env guix
> pull' from a git checkout.
>
> [1]: For the full log, see: https://paste.debian.net/1015219/
>
> --
> Jelle Licht

The bug had been tagged moreinfo on 12 Oct 2021 (6 weeks, 1 day).
Therefore, I assume it is not an issue anymore so I am closing.

Cheers,
simon

bug#30229: Python modules installed by pip in virtualenv can't find shared objects.

[zimoun]

Hi,

On Tue, 23 Jan 2018 at 13:00, Ricardo Wurmus  wrote:

>> When a python module needs to load a dynamic shared object, it looks in the
>> path provided by *LD_LIBRARY_PATH*(1), but guix doesn't modify this 
>> environment
>> variable to export the needed path for python.
>
> We cannot set this environment variable by default lest we break other
> packages that may be installed.  LD_LIBRARY_PATH is dangerous as it
> tells the runtime linker to prefer libraries in the specified
> directories.
>
> For Guix packages we use different means to embed store paths in
> binaries, which are looked up at runtime.  For binaries that’s achieved
> with RUNPATH; for others we patch the sources to ensure that libraries
> are not looked up merely by name but by absolute path.
>
> In your particular case (installing packages without Guix) I think the
> best way is to manually set LD_LIBRARY_PATH on demand, or to set
> LD_PRELOAD to the specific libraries that are required.
>
> In general, though, I recommend using Guix for package management and
> development instead of virtualenv and pip.

Regarding the improvements of ’guix import pypi’ since 2018, and because
tweaking LD_LIBRARY_PATH is dangerous, I do not see what could be the
next action to solve this.

Therefore, I propose to close it.  WDYT?


Cheers,
simon

bug#30161: gnucobol: depends on non-optional runtime depedencies

[zimoun]

Hi,

On Sun, 18 Feb 2018 at 10:25, Efraim Flashner  wrote:
> On Thu, Jan 18, 2018 at 12:43:39PM +, ng0 wrote:

>> For a simple hello world (as per their own Manual) GNU Cobol depends on:
>>
>> * ncurse
>> * bdb
>> * gmp
>> --
>
> Cobol is already built with these three as inputs so I'm not really sure
> what the bug report is. Are you saying that programs built with GNU
> Cobol also need to link with these libraries?

It appears to me the question is still pending since 2018, I am closing.

Feel free to reopen if I miss something.

Cheers,
simon

bug#30123: claws-mail plugins not updated

[zimoun]

Hi Julien,

On Mon, 15 Jan 2018 at 14:52, julien lepiller  wrote:

> claws-mail has a plugin system to add functionnality. For instance, to add PGP
> support, one has to load 3 plugins from the claws-mail package. By default,
> claws-mail looks in its store directory to propose available plugins.
>
> When upgrading claws-mail, the configuration doesn't change. Plugins are still
> looked for in the old store location, so old plugins are still used. This is
> bad for security and compatibility. Another issue is when running guix gc
> afterwards: the old plugins are deleted and claws-mail issues an error message
> on startup because it cannot find them anymore.

Reading the recent activity about claws-mail, is it still an issue?

Cheers,
simon

bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> This is what I get for the last one:
>
> sqlite> select * from validpaths where path = 
> '/gnu/store/q6qa5s2z2l20q25qpxyfv1wni5wwhk24-flightgear-2018.3.5';
> 48732920|/gnu/store/q6qa5s2z2l20q25qpxyfv1wni5wwhk24-flightgear-2018.3.5|sha256:86426115e1f49835a24612ae89a180e87ac835332b4e83d19ecbd43211336cd2|1623360391|/gnu/store/722yyaa1qvkaakn6p7ywwr4dnm5wmddz-flightgear-2018.3.5.drv|-1610199336
>
>
> The registration date is:
>
> scheme@(guile-user)> ,use(srfi srfi-19)
> scheme@(guile-user)> (date->string (time-utc->date (make-time time-utc 0 
> 1623360391)) "~1" )
> $164 = "2021-06-10"
>
>> I think there were safeguards put in place to avoid bad data making it's
>> way in to the store database?
>
> I thought so too (commit 13a7d2a538b00aa0a8cf9b999f1a4ff3e5959af9)!
> So we must be using another code path.

At last I found the culprit (me! :-)).  This is fixed by commit
f9b1bb916c284bea00dd5549a43e0894b219d650.

The reason ci.guix would experience it and not bayfront is because the
Cuirass worker mechanism relies on substitutes to retrieve files from a
worker, and this is how it would end up storing a negative size.

We’ll have to upgrade the ‘guix’ package and deploy it on berlin.  I
don’t think it’s easily feasible to fix existing entries in the store
database and (more importantly) narinfos so I’d just leave them around;
the bogus nar size propagates but it’s harmless and doesn’t prevent
substitution.

Thoughts?

Ludo’.

bug#46212: bug#51983: guix build: error: integer expected from stream

[Ludovic Courtès]

Hi,

Tobias Geerinckx-Rice  skribis:

> Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：
>> substitute: updating substitutes from
>> 'https://ci.guix.gnu.org'... 100.0%
>> guix build: error: integer expected from stream:
>> 18446744071924943736
>
> And it is indeed specific to querying ci.guix.

This reminds me of:

  https://issues.guix.gnu.org/46212

and indeed:

--8<---cut here---start->8---
$ guix build flightgear -n --no-grafts
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bayfront.guix.gnu.org'... 100.0%
guix build: error: integer expected from stream
$ guix describe
Generacio 195   Nov 22 2021 00:37:58(nuna)
  guix 24aa7b3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 24aa7b3c21309b63cc6e8e18d6417d2cddccf6c6
--8<---cut here---end--->8---

The ‘NarSize’ field is still broken on ci.guix:

--8<---cut here---start->8---
$ wget -qO - https://ci.guix.gnu.org/ashmi6vr9d0k03z9q6ncbb2wf36p9nyk.narinfo 
|grep Size
FileSize: 1876560180
FileSize: 1715771086
FileSize: 1753645085
NarSize: 18446744072093825552
$ wget -qO - 
https://bordeaux.guix.gnu.org/ashmi6vr9d0k03z9q6ncbb2wf36p9nyk.narinfo |grep 
Size
FileSize: 1715771086
NarSize: 2679241232
--8<---cut here---end--->8---

and again the database on berlin has a negative size:

--8<---cut here---start->8---
$ sudo sqlite3 /var/guix/db/db.sqlite
SQLite version 3.32.3 2020-06-18 14:00:33
Enter ".help" for usage hints.
sqlite> select * from validpaths where path = 
'/gnu/store/ashmi6vr9d0k03z9q6ncbb2wf36p9nyk-flightgear-2020.3.11';
56551239|/gnu/store/ashmi6vr9d0k03z9q6ncbb2wf36p9nyk-flightgear-2020.3.11|sha256:1c68105efd8ee4677085a2cecaa5859f1f5f213d52e213ef4949384717dc493a|1636968959|/gnu/store/xvyar43mcfw0r7jfm1x0a2i9rhnsdh87-flightgear-2020.3.11.drv|-1615726064
--8<---cut here---end--->8---

[Time passes…]

OK, this one is now fixed by commit
1eb40a6dc4917f5a2e915f8b31b750dba3d378c6m, which means you now get:

--8<---cut here---start->8---
$ guix build flightgear --no-grafts  -n
1,715.8 MB would be downloaded:
   /gnu/store/ashmi6vr9d0k03z9q6ncbb2wf36p9nyk-flightgear-2020.3.11
guix build: warning: at least 18,446,744,072,093.8 MB needed but only 4,753.4 
MB available in /gnu/store
--8<---cut here---end--->8---

Fun, no?  :-)

Also, after substitution, the size in the store database would be the
wrong one, so ‘guix size’ would keep telling you it’s this big.  Not
great but harmless as the nar size is used for UI purposes only.

Ludo’.

bug#52073: remove Google support from GVFS?

[Liliana Marie Prikler]

Am Mittwoch, den 24.11.2021, 12:33 -0500 schrieb Leo Famulari:
> On Wed, Nov 24, 2021 at 06:00:15AM +0100, raingloom wrote:
> > I'd love to say it's because I want the package to be more in line
> > with libre software guidelines, but honestly I just don't want
> > WebKitGTK as a transitive input. A few weeks ago I had to remove
> > GVFS from my system because WebKitGTK was failing to build.
> 
> Can you explain the connection between libre software guidelines
> (FSDG), GVFS, and WebKitGTK?
> 
> If the problem was simply that the WebKitGTK package was broken for a
> few days, I'm sorry, that was my mistake.
Note that WebkitGTK is still broken on i686 (bug#51863).  I could take
some time out of my weekend to fix the issues I raised w.r.t. that
patch or we could apply it as-is (though note that hasty as-is
applications have not worked out too well for us in the recent past). 
I'm not sure whether raingloom is on i686 or x86_64, just wanted to
point that out.

Cheers

bug#51983: guix build: error: integer expected from stream

[Maxim Cournoyer]

Hello Tobias!

Tobias Geerinckx-Rice  writes:

> Guix,
>
> I saw this reported by jlicht on #guix but I'm pretty sure that 
> it's been reported a few times.
>
> Here's the error, with channel:
>
> (channel
>   (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git";)
>   (branch "core-updates-frozen")
>   (introduction
> (make-channel-introduction
>  "9edb3f66fd807b096b48283debdcddccfea34bad"
>  (openpgp-fingerprint
>   "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
>
> And patch:
>
> From: Tobias Geerinckx-Rice 
> Date: Fri, 19 Nov 2021 17:37:44 +0100
> Subject: [PATCH] daemon: Print the line whence we expect an 
> integer.
>
> * nix/libstore/local-store.cc 
>   (LocalStore::getLineFromSubstituter):
> Include the malformed substituter stream line in the error 
> message.
>
> ---
>  nix/libstore/local-store.cc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/nix/libstore/local-store.cc 
> b/nix/libstore/local-store.cc
> index 675d1ba66f..83b6681122 100644
> --- a/nix/libstore/local-store.cc
> +++ b/nix/libstore/local-store.cc
> @@ -839,7 +839,8 @@ template T 
> LocalStore::getIntLineFromSubstituter(Agent & run)
>  {
>  string s = getLineFromSubstituter(run);
>  T res;
> -if (!string2Int(s, res)) throw Error("integer expected from 
>  stream");
> +if (!string2Int(s, res))
> +throw Error(format("integer expected from stream: %1%") % 
> s);
>  return res;
>  }

I just stumbled on this.

LGTM!

Maxim

bug#33696: Works now: Webview crashes on query.wikidata.org

[Jack Hill]

I'm going to close this bug since it was reported as working over a year 
ago, and I can also not reproduce the problem on the current 
core-updates-frozen development branch.


That said, webkit is definitely not free of all crashes or rendering bugs, 
so if this issue recurs or if you notice another one, please open a new 
ticket.


Best,
Jack

bug#52081: [core-updates-frozen] Wine fails to build; failing i686 tests

[John Kehayias via Bug reports for GNU Guix]

Hi everyone,

I was hoping the polkit/duktape patch would resolve issues with i686 builds 
that prevent Wine from building (on x86-64 where it needs the i686 version). 
While it has gotten further, it is failing due to test failures on i686 for its 
dependencies. I've successfully built Wine for i686 with:

guix build wine -s i686-linux --without-tests=plotutils 
--without-tests=glib-networking --without-tests=lib2geom 
--without-tests=gtk+@3.24.30

I don't know if I'll have the chance today to try to disable or fix the failing 
tests on i686 for these packages, which would also likely help the i686 
coverage (lots of packages depend on these). If someone is more familiar with 
these packages and tests, that would be most helpful.

Here are the most recent failure logs on Cuirass for the packages:

plotutils (2 tests): https://ci.guix.gnu.org/build/1685012/log/raw

glib-networking (1 test): https://ci.guix.gnu.org/build/1759508/log/raw

lib2geom (1 test): https://ci.guix.gnu.org/build/1690360/log/raw

gtk+@3.24.30 (2 tests): https://ci.guix.gnu.org/build/1331231/log/raw

Hope this is helpful! If I do make any progress on patches for these tests, 
I'll add it to this thread.

John

bug#52073: remove Google support from GVFS?

[Leo Famulari]

On Wed, Nov 24, 2021 at 06:00:15AM +0100, raingloom wrote:
> I'd love to say it's because I want the package to be more in line with
> libre software guidelines, but honestly I just don't want WebKitGTK as
> a transitive input. A few weeks ago I had to remove GVFS from my system
> because WebKitGTK was failing to build.

Can you explain the connection between libre software guidelines (FSDG),
GVFS, and WebKitGTK?

If the problem was simply that the WebKitGTK package was broken for a
few days, I'm sorry, that was my mistake.

> Then again if I had to connect to Google Drive or Picasa or whatever
> I'd rather do it through libre software, so maybe it should stay.

GNU's position is that services are not "free" or "nonfree" in the way
that software is. So, it shouldn't be a problem that Guix packages can
use 3rd party services.

https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.en.html

bug#52080: Non-standard terminology in NEWS (Minetest mods instead of Minetest extensions)

[Maxime Devos]

Recently, while looking at commits on git.savannah.gnu.org,
I noticed the following line was added to NEWS:

* Changes in 1.4.0 [...]
[...]
*** New ‘guix import minetest’ command, to import Minetest extensions

However, Minetesters call these mods, and almost never extensions.
See, e.g., the Minetest wiki: https://wiki.minetest.net/Mods,
the Minetest forum: https://forum.minetest.net/viewforum.php?f=46,
ContentDB:
https://content.minetest.net/packages/loosewheel/lwcolorable/ (search
for ‘Type’).

That said, I did find one web page were ‘extension’ is used instead of
‘mod’, at https://wiki.minetest.net/MinetestEDU. Also, ContentDB also
supports ‘texture packs’ and ‘games’, but those aren't supported by the
importer yet.

I suggest replacing ‘extensions’ by ‘mods’.

Greetings,
Maxime
-- 
not hacking on guix for a while, only occassionally looking at IRC logs
and bug reports.  E-mails are unsigned until backup is located.

bug#52076: [core-updates-frozen] eigen-for-tensorflow fails to build

[Guillaume Le Vaillant]

On the core-updates-frozen branch at d5de4e163ccef80f78bc5fe330f568d8fe3a23ab,
compilation of eigen-for-tensorflow fails with the following error:

--8<---cut here---start->8---
[ 56%] Building CXX object 
test/CMakeFiles/stddeque_overload_4.dir/stddeque_overload.cpp.o
cd /tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/build/test 
&& /gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/bin/c++  
-I/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/build/test 
-I/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test 
-I/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source 
-I/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/build 
-pedantic -Wall -Wextra -Wundef -Wcast-align -Wchar-subscripts 
-Wnon-virtual-dtor -Wunused-local-typedefs -Wpointer-arith -Wwrite-strings 
-Wformat-security -Wlogical-op -Wdouble-promotion -Wshadow -Wno-psabi 
-Wno-variadic-macros -Wno-long-long -fno-check-new -fno-common 
-fstrict-aliasing -ansi -O3 -DNDEBUG  -DEIGEN_TEST_MAX_SIZE=320 
-DEIGEN_TEST_FUNC=stddeque_overload  -DEIGEN_TEST_PART_4=1 -MD -MT 
test/CMakeFiles/stddeque_overload_4.dir/stddeque_overload.cpp.o -MF 
CMakeFiles/stddeque_overload_4.dir/stddeque_overload.cpp.o.d -o 
CMakeFiles/stddeque_overload_4.dir/stddeque_overload.cpp.o -c 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp
In file included from 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/Eigen/StdDeque:23,
 from 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp:13:
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/Eigen/src/StlSupport/StdDeque.h:
 In instantiation of ‘void std::deque 
>::resize(std::deque >::size_type, const 
value_type&) [with T = Eigen::Transform; std::deque >::size_type = long unsigned int; std::deque >::value_type = Eigen::Transform]’:
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp:81:11:
   required from ‘void check_stddeque_transform(const TransformType&) [with 
TransformType = Eigen::Transform]’
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp:152:3:
   required from here
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/Eigen/src/StlSupport/StdDeque.h:106:41:
 error: ‘std::_Deque_base, 
Eigen::aligned_allocator_indirection > 
>::_Deque_impl std::_Deque_base, 
Eigen::aligned_allocator_indirection > 
>::_M_impl’ is protected within this context
  106 |   deque_base::_M_erase_at_end(this->_M_impl._M_start + new_size);
  |   ~~^~~
In file included from 
/gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/include/c++/deque:67,
 from 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/main.h:42,
 from 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp:11:
/gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/include/c++/bits/stl_deque.h:589:19:
 note: declared protected here
  589 |   _Deque_impl _M_impl;
  |   ^~~
--8<---cut here---end--->8---

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

[Josselin Poiret via Bug reports for GNU Guix]

Hello Maxim,

Maxim Cournoyer  writes:

> --8<---cut here---start->8---
> Nov 23 01:09:14 localhost dbus-daemon[383]: [system] Activating service 
> name='org.freedesktop.login1' requested by ':1.17' (uid=0 pid=370
> comm="/gnu/store/ximad0zvg12r4x0x80mvym8hzg0n33jl-shadow") (using 
> servicehelper)
> Nov 23 01:09:14 localhost elogind[1189]: elogind is already running as PID 390
> Nov 23 01:09:20 localhost shepherd[1]: Respawning term-tty1. 
> Nov 23 01:09:20 localhost shepherd[1]: Service host-name has been started. 
> Nov 23 01:09:20 localhost shepherd[1]: Service term-tty1 has been started.
> Nov 23 01:09:39 localhost dbus-daemon[383]: [system] Failed to activate 
> service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
> --8<---cut here---end--->8---
>
> I don't remember if I saw the slim login screen; but in any case I
> couldn't successfully login even via a ptty.
>
> It may have to do with polkit.
>
> To be investigated.
>
> This happened on a system *not* using gdm (it uses slim) and with
> ratpoison as the WM, on commit f42bc604547d9ee8e35fcd66d5db7786954cfac3
> of the core-updates-frozen branch.
>
> To be investigated.

I cannot reproduce in a fresh VM on commit
d5de4e163ccef80f78bc5fe330f568d8fe3a23ab, and can login just fine, with

  (services (cons* (service slim-service-type (slim-configuration))
   (modify-services %desktop-services
 (delete gdm-service-type

Is this still affecting you?

Best,
Josselin Poiret