bug#47121: [Mumi] Why does Mumi display my name as "Mark HWeaver"?

[Mark H Weaver]

Hi Ricardo,

Why does Mumi discard the space between my middle initial and my
surname, e.g. in  ?

The default web interface for Debbugs doesn't do it.


Also, where should Mumi bugs be reported?

Thanks,
  Mark

bug#47121: [Mumi] Why does Mumi display my name as "Mark HWeaver"?

[Ricardo Wurmus]

Hi Mark,

thanks for your report!

> Why does Mumi discard the space between my middle initial and my
> surname, e.g. in  ?

I’m not sure.  Mumi chops up the Debbugs “log” file and then parses the
extracted emails with guile-email.  Since even the download links for
emails from you fail
(e.g. https://issues.guix.gnu.org/issue/issue/47115/raw/3) I guess that
guile-email had problems parsing the email.

I’m copying the Debbugs data to my laptop now, so I can try to reproduce
this locally and see what guile-email sees and outputs.

> Also, where should Mumi bugs be reported?

bug-guix with Cc to me is fine, I guess.  We have no separate mailing
list for it.

-- 
Ricardo

bug#47121: [Mumi] Why does Mumi display my name as "Mark HWeaver"?

[Ricardo Wurmus]

Hi Mark,

> Why does Mumi discard the space between my middle initial and my
> surname, e.g. in  ?
[…]
> The default web interface for Debbugs doesn't do it.
> 

This must be a regression in guile-email.  When I tried to reproduce
this with

guix environment -l guix.scm

from the mumi source directory I saw your name rendered correctly.
When I used

guix environment mumi

however, I was able to reproduce the problem.

The only difference between these environments is the version of
guile-email.  There is no problem when guile-email 0.2.2 is used; the
problem appears with guile-email 0.2.2-1.03e9cac aka
“guile-email-latest” in Guix.

@Arun, does this sound familiar to you?

-- 
Ricardo

bug#47107: libtiff/fixed uses wrong version number in 'doc' output

[Ludovic Courtès]

Hi Leo,

Leo Famulari  skribis:

> The grafted replacement of libtiff, libtiff/fixed, updates the package
> from version 4.1.0 to 4.2.0.
>
> However, the it does not adjust the #:configure-flags of the inherited
> package, which rely on the version number. 
>
> The result is directories named 'share/doc/libtiff-4.1.0' in the "doc"
> output of libtiff-4.2.0.

Instead of duplicating the ‘name’ and ‘arguments’ fields as done in
35b3ab8e5748d9911ae7a0189065d0c25392895b, one possibility is to change
the initial ‘libtiff’ like so:

diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index 4f249b7622..44d2cac0fe 100644
--- a/gnu/packages/image.scm
+++ b/gnu/packages/image.scm
@@ -599,7 +599,8 @@ extracting icontainer icon files.")
 `(#:configure-flags (list (string-append "--with-docdir="
  (assoc-ref %outputs "doc")
  "/share/doc/"
- ,name "-" ,version)
+ ,name "-"
+ ,(package-version this-package))
   "--disable-static")))
(inputs `(("zlib" ,zlib)
  ("libjpeg" ,libjpeg-turbo)))

WDTY?

Would it make sense to adopt this style also for
 and
?

(Changing to this style should not trigger any rebuild because it
expands to the exact same thing.)

Thanks,
Ludo’.

bug#47106: Bubblewrap hates Guix containers 😞

[Ludovic Courtès]

Hi!

Leo Prikler  skribis:

> both Epiphany and Eolie (post fixing #47097; will submit patch shortly)
> fail inside Guix containers with the suggested incantation.  After
> getting the environment to no longer complain about $DISPLAY by adding
> `--preserve="XAUTHORITY" --expose=$XAUTHORITY', it repeatedly outputs
> lines like
> bwrap: Can't find source path /sys/class: No such file or directory
> before closing the process altogether.

What is ‘bwrap’ looking for?  /sys is mounted inside ‘guix environment -C’,
but perhaps it needs something special?

I suggest running these things (or ‘bwrap’ directly) in ‘strace -f -o
log’ inside the container to see.

Thanks,
Ludo’.

bug#47106: Bubblewrap hates Guix containers 😞

[Leo Prikler]

Hi!
Am Samstag, den 13.03.2021, 11:48 +0100 schrieb Ludovic Courtès:
> Hi!
> 
> Leo Prikler  skribis:
> 
> > both Epiphany and Eolie (post fixing #47097; will submit patch
> > shortly)
> > fail inside Guix containers with the suggested incantation.  After
> > getting the environment to no longer complain about $DISPLAY by
> > adding
> > `--preserve="XAUTHORITY" --expose=$XAUTHORITY', it repeatedly
> > outputs
> > lines like
> > bwrap: Can't find source path /sys/class: No such file or directory
> > before closing the process altogether.
> 
> What is ‘bwrap’ looking for?  /sys is mounted inside ‘guix
> environment -C’,
> but perhaps it needs something special?
> 
> I suggest running these things (or ‘bwrap’ directly) in ‘strace -f -o
> log’ inside the container to see.
It seems to be 
> openat(AT_FDCWD, "/sys/class/dmi/id/chassis_type", O_RDONLY) = -1
> ENOENT (No such file or directory)
> openat(AT_FDCWD, "/sys/firmware/acpi/pm_profile", O_RDONLY) = -1
> ENOENT (No such file or directory)

I haven't repeated that for all warnings of similar kind, but if I add
`--expose=/sys/block --expose=/sys/class --expose=/sys/bus --
expose=/sys/dev --expose=/sys/devices` to the invocation, I instead get
a warning, that the WebKitWebProcess can't open $DISPLAY.  I'm not sure
how to resolve that one, given that I already had to sneak DISPLAY and
XAUTHORITY into the container, but it's a start.

Regards,
Leo

bug#47106: Bubblewrap hates Guix containers 😞

[Bengt Richter]

Hi,

On +2021-03-13 12:07:51 +0100, Leo Prikler wrote:
> Hi!
> Am Samstag, den 13.03.2021, 11:48 +0100 schrieb Ludovic Courtès:
> > Hi!
> > 
> > Leo Prikler  skribis:
> > 
> > > both Epiphany and Eolie (post fixing #47097; will submit patch
> > > shortly)
> > > fail inside Guix containers with the suggested incantation.  After
> > > getting the environment to no longer complain about $DISPLAY by
> > > adding
> > > `--preserve="XAUTHORITY" --expose=$XAUTHORITY', it repeatedly
> > > outputsn
> > > lines like
> > > bwrap: Can't find source path /sys/class: No such file or directory
> > > before closing the process altogether.
> > 
> > What is ‘bwrap’ looking for?  /sys is mounted inside ‘guix
> > environment -C’,
> > but perhaps it needs something special?
> > 
> > I suggest running these things (or ‘bwrap’ directly) in ‘strace -f -o
> > log’ inside the container to see.
> It seems to be 
> > openat(AT_FDCWD, "/sys/class/dmi/id/chassis_type", O_RDONLY) = -1
> > ENOENT (No such file or directory)
> > openat(AT_FDCWD, "/sys/firmware/acpi/pm_profile", O_RDONLY) = -1
> > ENOENT (No such file or directory)
> 
> I haven't repeated that for all warnings of similar kind, but if I add
> `--expose=/sys/block --expose=/sys/class --expose=/sys/bus --
> expose=/sys/dev --expose=/sys/devices` to the invocation, I instead get
> a warning, that the WebKitWebProcess can't open $DISPLAY.  I'm not sure
> how to resolve that one, given that I already had to sneak DISPLAY and
> XAUTHORITY into the container, but it's a start.
> 
> Regards,
> Leo
> 
Does $DISPLAY mean ":0" and does the Wayland server answer that with
its XWayland X-interface?

I am wonderering how that is resolved inside a container.

HTH with the detective work ;)

-- 
Regards,
Bengt Richter

bug#47123: Quagga source code is gone

[Ludovic Courtès]

The Quagga tarballs and Git repository on Savannah as linked from
 are all 404:

  https://savannah.nongnu.org/projects/quagga
  http://download.savannah.gnu.org/releases/quagga/
  https://git.savannah.gnu.org/cgit/quagga.git

I can’t find an alternate hosting site.

Ludo’.

bug#47106: Bubblewrap hates Guix containers 😞

[Leo Prikler]

Am Samstag, den 13.03.2021, 13:27 +0100 schrieb Bengt Richter:
> Hi,
> 
> On +2021-03-13 12:07:51 +0100, Leo Prikler wrote:
> > Hi!
> > Am Samstag, den 13.03.2021, 11:48 +0100 schrieb Ludovic Courtès:
> > > Hi!
> > > 
> > > Leo Prikler  skribis:
> > > 
> > > > both Epiphany and Eolie (post fixing #47097; will submit patch
> > > > shortly)
> > > > fail inside Guix containers with the suggested
> > > > incantation.  After
> > > > getting the environment to no longer complain about $DISPLAY by
> > > > adding
> > > > `--preserve="XAUTHORITY" --expose=$XAUTHORITY', it repeatedly
> > > > outputsn
> > > > lines like
> > > > bwrap: Can't find source path /sys/class: No such file or
> > > > directory
> > > > before closing the process altogether.
> > > 
> > > What is ‘bwrap’ looking for?  /sys is mounted inside ‘guix
> > > environment -C’,
> > > but perhaps it needs something special?
> > > 
> > > I suggest running these things (or ‘bwrap’ directly) in ‘strace
> > > -f -o
> > > log’ inside the container to see.
> > It seems to be 
> > > openat(AT_FDCWD, "/sys/class/dmi/id/chassis_type", O_RDONLY) = -1
> > > ENOENT (No such file or directory)
> > > openat(AT_FDCWD, "/sys/firmware/acpi/pm_profile", O_RDONLY) = -1
> > > ENOENT (No such file or directory)
> > 
> > I haven't repeated that for all warnings of similar kind, but if I
> > add
> > `--expose=/sys/block --expose=/sys/class --expose=/sys/bus --
> > expose=/sys/dev --expose=/sys/devices` to the invocation, I instead
> > get
> > a warning, that the WebKitWebProcess can't open $DISPLAY.  I'm not
> > sure
> > how to resolve that one, given that I already had to sneak DISPLAY
> > and
> > XAUTHORITY into the container, but it's a start.
> > 
> > Regards,
> > Leo
> > 
> Does $DISPLAY mean ":0" and does the Wayland server answer that with
> its XWayland X-interface?
In my setup $DISPLAY=:1, but obviously the exact value depends on other
circumstances (i.e. if there's already an open session belonging to
another user it'd be :2, :3, ...).  I'm not sure how X vs. Wayland
plays out here, but I'm still using Gnome on X, so that should
hopefully not be an issue here.

> I am wonderering how that is resolved inside a container.
Well, for X you'd usually preserve DISPLAY and XAUTHORITY and also
expose $XAUTHORITY or something along those lines.  Not sure how you
Wayland folk do that.

Regards,
Leo

bug#47123: Quagga source code is gone

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Ludovic Courtès 写道：

I can’t find an alternate hosting site.


Does that mean the project is dead?  Unmaintained network software 
is a great thing to have lying around.


Anyway, I've updated the quagga package to use this[0] one.

Kind regards,

T G-R

[0]: https://fossies.org/linux/misc/quagga-1.2.4.tar.gz/


signature.asc
Description: PGP signature

bug#47106: Bubblewrap hates Guix containers 😞

[Bengt Richter]

Hi again,

On +2021-03-13 15:43:15 +0100, Leo Prikler wrote:
> Am Samstag, den 13.03.2021, 13:27 +0100 schrieb Bengt Richter:
> > Hi,
> > 
> > On +2021-03-13 12:07:51 +0100, Leo Prikler wrote:
> > > Hi!
> > > Am Samstag, den 13.03.2021, 11:48 +0100 schrieb Ludovic Courtès:
> > > > Hi!
> > > > 
> > > > Leo Prikler  skribis:
> > > > 
> > > > > both Epiphany and Eolie (post fixing #47097; will submit patch
> > > > > shortly)
> > > > > fail inside Guix containers with the suggested
> > > > > incantation.  After
> > > > > getting the environment to no longer complain about $DISPLAY by
> > > > > adding
> > > > > `--preserve="XAUTHORITY" --expose=$XAUTHORITY', it repeatedly
> > > > > outputsn
> > > > > lines like
> > > > > bwrap: Can't find source path /sys/class: No such file or
> > > > > directory
> > > > > before closing the process altogether.
> > > > 
> > > > What is ‘bwrap’ looking for?  /sys is mounted inside ‘guix
> > > > environment -C’,
> > > > but perhaps it needs something special?
> > > > 
> > > > I suggest running these things (or ‘bwrap’ directly) in ‘strace
> > > > -f -o
> > > > log’ inside the container to see.
> > > It seems to be 
> > > > openat(AT_FDCWD, "/sys/class/dmi/id/chassis_type", O_RDONLY) = -1
> > > > ENOENT (No such file or directory)
> > > > openat(AT_FDCWD, "/sys/firmware/acpi/pm_profile", O_RDONLY) = -1
> > > > ENOENT (No such file or directory)
> > > 
> > > I haven't repeated that for all warnings of similar kind, but if I
> > > add
> > > `--expose=/sys/block --expose=/sys/class --expose=/sys/bus --
> > > expose=/sys/dev --expose=/sys/devices` to the invocation, I instead
> > > get
> > > a warning, that the WebKitWebProcess can't open $DISPLAY.  I'm not
> > > sure
> > > how to resolve that one, given that I already had to sneak DISPLAY
> > > and
> > > XAUTHORITY into the container, but it's a start.
> > > 
> > > Regards,
> > > Leo
> > > 
> > Does $DISPLAY mean ":0" and does the Wayland server answer that with
> > its XWayland X-interface?
> In my setup $DISPLAY=:1, but obviously the exact value depends on other
> circumstances (i.e. if there's already an open session belonging to
> another user it'd be :2, :3, ...).  I'm not sure how X vs. Wayland
> plays out here, but I'm still using Gnome on X, so that should
> hopefully not be an issue here.
> 
> > I am wonderering how that is resolved inside a container.
> Well, for X you'd usually preserve DISPLAY and XAUTHORITY and also
> expose $XAUTHORITY or something along those lines.  Not sure how you
> Wayland folk do that.
>

I am not a Wayland developer, if that's what you mean by "Wayland folk" :)
But I have been experimenting with writing my own text and graphics widget,
poking 32-bit pixels into buffers for display by the Wayland compositor,
so I've learned a little :) I am using the linux kernel's sun12x22 bitmap
font to do text at a low level.

Idk much about containers yet, but I imagine using lowlevel stuff to
make images for a trivial web server running in a container could be 
interesting.

> Regards,
> Leo
> 

I am curious what the commands below would show inside your container.
"pidparents" [1] is a little script I find handy, which would have to be
accessible in your container of course. Idk how you put local bash scripts
in your container. I assume it's possible :)

I did these commands in a debian gnome terminal window, where pidparents[1]
showed (timetagged later, since I just went back to do that) this context:
--8<---cut here---start->8---
[17:29 ~/bs]$ pidparents
pidparents  pts/1 5800 S+   /usr/bin/bash /home/bokr/bin/pidparents
bashpts/1 5711 Ss   /bin/bash
tilix   ? 2007 Sl   /usr/bin/tilix --gapplication-service
systemd ? 1308 Ss   /lib/systemd/systemd --user
systemd ?1 Ss   /sbin/init splash
--8<---cut here---end--->8---

 First I just look for processes with X11 or way in their names, 
 then I use pidparents to see how they are started.

[17:18 ~/bs]$ ps af|egrep -i 'x11|way'
 5741 pts/1S+ 0:00  \_ grep -E -i x11|way
 1329 tty2 Ssl+   0:00 /usr/lib/gdm3/gdm-wayland-session 
/usr/bin/gnome-session
 1433 tty2 Sl+0:13  |   \_ /usr/bin/Xwayland :0 -rootless 
-terminate -accessx -core -listen 4 -listen 5 -displayfd 6
 1468 tty2 Sl 0:00 /usr/lib/ibus/ibus-x11 --kill-daemon

[17:21 ~/bs]$ pidparents 1329
gdm-wayland-ses tty2  1329 Ssl+ /usr/lib/gdm3/gdm-wayland-session 
/usr/bin/gnome-session
gdm-session-wor ? 1304 Sl   gdm-session-worker [pam/gdm-password]
gdm3?  711 Ssl  /usr/sbin/gdm3
systemd ?1 Ss   /sbin/init splash

 this one might be the most interesting in your container
 can you SSH into it to do these things?
[17:22 ~/bs]$ pidparents 1433
Xwaylandtty2  1433 Sl+  /usr/bin/Xwayland :0 -rootless -terminate 
-accessx -core -listen 4 -listen 5 -displayfd 

bug#47106: Bubblewrap hates Guix containers 😞

[Leo Prikler]

Am Samstag, den 13.03.2021, 18:07 +0100 schrieb Bengt Richter:
> I am not a Wayland developer, if that's what you mean by "Wayland
> folk" :)
I meant it as "folk using Wayland in their display manager".

> I am curious what the commands below would show inside your
> container.
> "pidparents" [1] is a little script I find handy, which would have to
> be
> accessible in your container of course. Idk how you put local bash
> scripts
> in your container. I assume it's possible :)
Far from getting a script into my container, I can't even really get
into my container through means like `guix container exec`, so I simply
bloated it with screen and pstree.  The result:

--8<---cut here---start->8---
sh-+-dbus-daemon
   |-dbus-launch
   `-screen---screen-+-sh---.epiphany-real-+-WebKitNetworkPr---
11*[{WebKitNetworkPr}]
 | |-bwrap---bwrap---
WebKitWebProces
 | `-18*[{.epiphany-real}]
 `-sh---pstree
--8<---cut here---end--->8---

I think these processes are created and die too quickly for me to
reliably extract PIDs.

Regards,
Leo

bug#47115: Failure building grub-img.png when reconfiguring

[Jack Hill]

On Sat, 13 Mar 2021, Mark H Weaver wrote:


Thanks.  Given this, and the lack of similar reports from others, my
guess is that you hit a non-deterministic Guile bug, possibly the same
one as  (Non-deterministic failures while
building Guix with Guile 3.0.5).

If the problem happens reproducibly on that one VM only, that suggests
that the bug might have led to a corrupted store item, i.e. a store item
containing a .go file with bad code.  If so, running "guix gc" might be
sufficient to clear the corrupted items.


guix gc and the reconfigure again (now with 
373c7b5791acd8f377455be47260948b843dd5db) still results in the same error. 
Of course, if the miscompilation was in something that couldn't get 
collected… However, I have been able to reproduce it on that one VM across 
multiple Guix commits.


Best,
Jack

bug#47107: libtiff/fixed uses wrong version number in 'doc' output

[Leo Famulari]

On Sat, Mar 13, 2021 at 11:44:27AM +0100, Ludovic Courtès wrote:
> Instead of duplicating the ‘name’ and ‘arguments’ fields as done in
> 35b3ab8e5748d9911ae7a0189065d0c25392895b, one possibility is to change
> the initial ‘libtiff’ like so:
> 

> diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
> index 4f249b7622..44d2cac0fe 100644
> --- a/gnu/packages/image.scm
> +++ b/gnu/packages/image.scm
> @@ -599,7 +599,8 @@ extracting icontainer icon files.")
>  `(#:configure-flags (list (string-append "--with-docdir="
>   (assoc-ref %outputs "doc")
>   "/share/doc/"
> - ,name "-" ,version)
> + ,name "-"
> + ,(package-version this-package))
>"--disable-static")))

That is great, thanks. I will make the adjustments.

bug#47115: Failure building grub-img.png when reconfiguring

[Jack Hill]

In an effort to clear out more of the potentially problematic store items, 
I switched to an older generation of the system as well as guix pull and 
user profiles. I then ran guix gc. At this point, I was running guix from 
commit 373e5fc96724fd38bb1263e4af90932ea36f596b and the system profile was 
created with guix f3eecfd36cb537a1febc30eea1f6aa448203ba40.


I then pulled, bringing me up to guix 
8154beffd8c121e953a7c4cd75c3eebfcc073a9a. Reconfiguring results in the 
same error. Any thoughts on how to recover? Should I try building guix 
against an older guile version?


Best,
Jack

bug#47131: pioneers: beep dependency

[Christopher Howard]

The game "pioneers" calls the "beep" utility in order to signal a turn
change, and gives a (non-fatal) error message if beep is not installed.
I confirmed beep is available as a guix package.

christopher@nightshade ~$ guix describe
Generation 2Feb 25 2021 21:06:30(current)
  guix 6294299
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 62942992831249d6d1c047c0a11c41d2e4fc

-- 
Christopher Howard
phone: (907) 374-0257 (landline)
blog: https://librehacker.com
social: https://gnusocial.club/librehacker