bug#46967: Connection reuse for substitutes breaks with gzip

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> I decided to take a heavy-handed solution to that problem, which is to
>> augment Guile-zlib with an interface for gzip compression/decompression
>> not restricted to file ports (‘call-with-gzip-output-port’ & co. are
>> restricted to file ports):
>>
>>   
>> https://notabug.org/guile-zlib/guile-zlib/commit/b899ac2fecf91475da1eba7e7b24708ea8b5fb73
>>
>> That way, we can change ‘decompressed-port’ in (guix utils) to perform
>> in-process decompression for ‘gzip’, like it does for zstd and lzip.
>
> Done in a04aef2430645357d7796969d4b6453478ff8a3f!
>
> I’ll update the ‘guix’ package so people on Guix System can get the fix,
> and then we can close this bug.

Done in 8154beffd8c121e953a7c4cd75c3eebfcc073a9a, closing!

Ludo’.

bug#46803: User manual does not explain Profiles (nor GUIX_PROFILE)

[Ludovic Courtès]

Hello,

zimoun  skribis:

> Effectively, profiles is not explicitly defined but implicitly, for
> instance:
>
> 
>
> Otherwise, the most explicit definition is in the Cookbook:
>
> Guix provides a very useful feature that may be quite foreign to
> newcomers: profiles. They are a way to group package
> installations together and all users on the same system are free
> to use as many profiles as they want.
>
> 

[...]

> 
>
> And from this old time, I remember that examples really helps, for
> instance.
>
> .
>
> Therefore, the section «Getting Started» could be a bit extended with a
> paragraph about Profiles and one or two examples.  WDYT?
>
> 

Thanks for the pointers!  How about these changes to “Getting Started”
and “Invoking guix package”?

Ludo’.

diff --git a/doc/guix.texi b/doc/guix.texi
index 4cf241c56a..00bd087628 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2751,7 +2751,10 @@ you can go ahead and install it (run this command as a regular user,
 guix install emacs
 @end example
 
-You've installed your first package, congrats!  In the process, you've
+You've installed your first package, congrats!  The package is now
+visible in your default @dfn{profile}, @file{$HOME/.guix-profile}---a
+profile is a directory containing installed packages.
+In the process, you've
 probably noticed that Guix downloaded pre-built binaries; or, if you
 explicitly chose to @emph{not} use pre-built binaries, then probably
 Guix is still building software (@pxref{Substitutes}, for more info).
@@ -3061,7 +3064,10 @@ retaining precise @dfn{provenance tracking} of the software.
 @cindex package removal
 The @command{guix package} command is the tool that allows users to
 install, upgrade, and remove packages, as well as rolling back to
-previous configurations.  It operates only on the user's own profile,
+previous configurations.  These operations work on a user
+@dfn{profile}---a directory of installed packages.  Each user has a
+default profile in @file{$HOME/.guix-profile}.
+The command operates only on the user's own profile,
 and works with normal user privileges (@pxref{Features}).  Its syntax
 is:
 

bug#47106: Bubblewrap hates Guix containers 😞

[Bengt Richter]

Hi again^2,

On +2021-03-13 19:01:29 +0100, Leo Prikler wrote:
> 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
> 

Maybe
pstree -at
would show a little more?
Also,
ls -lr /sys/class/drm
if that's accessible -- I'm wondering if the version of screen
in the container is built with libdrm and is bypassing X or ??

Do you have a makefile or a guix something.scm defining
what's built/packed into your container? 

Sorry if my curiosity is making work for you, but I'd like to
try containers down the road -- tho right now I'm taking a break
from events IRL, so I may disappear for a while...

-- 
Regards,
Bengt Richter

bug#47106: Bubblewrap hates Guix containers 😞

[Leo Prikler]

Hi again³

Am Sonntag, den 14.03.2021, 18:45 +0100 schrieb Bengt Richter:
> Hi again^2,
> 
> Maybe
> pstree -at
> would show a little more?
sh
  |-dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7
--sess
  |-dbus-launch --autolaunch=fa7a4d52637958ddd37547bb5d8bd9d2--binary-
synt
  `-screen
  `-screen
  |-sh
  |   `-.epiphany-real
  |   |-WebKitNetworkPr 3 21
  |   |   |-{BMScavenger}
  |   |   |-{ReceiveQueue}
  |   |   |-{StorageTask}
  |   |   |-{Storage}
  |   |   |-{WebStorage}
  |   |   |-{background}
  |   |   |-{dconf worker}
  |   |   |-{erialBackground}
  |   |   |-{gdbus}
  |   |   `-{gmain}
  |   |-bwrap --args 37 --
/gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
  |   |   `-bwrap --args 37 --
/gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
  |   |   `-WebKitWebProces 1277 28
  |   |-{.epiphany-real}
  |   |-{BMScavenger}
  |   |-{HashSaltStorage}
  |   |-{IconDatabase}
  |   |-{PressureMonitor}
  |   |-2*[{ReceiveQueue}]
  |   |-{dconf worker}
  |   |-{e Compile Queue}
  |   |-{ebsiteDataStore}
  |   |-{gdbus}
  |   |-{gmain}
  |   |-{re Remove Queue}
  |   `-{tore Read Queue}
  `-sh
  `-pstree -at
> Also,
> ls -lr /sys/class/drm
total 0
-r--r--r-- 1 65534 overflow 4096 Mar 14 17:59 version
lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 ttm ->
../../devices/virtual/drm/ttm
lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 renderD128 ->
../../devices/pci:00/:00:02.0/:01:00.0/drm/renderD128
lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 card0-VGA-1 ->
../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-VGA-
1
lrwxrwxrwx 1 65534 overflow0 Mar 14 17:59 card0-HDMI-A-1 ->
../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-
HDMI-A-1
lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 card0-DVI-D-1 ->
../../devices/pci:00/:00:02.0/:01:00.0/drm/card0/card0-DVI-
D-1
lrwxrwxrwx 1 65534 overflow0 Mar 14 17:58 card0 ->
../../devices/pci:00/:00:02.0/:01:00.0/drm/card0
> if that's accessible -- I'm wondering if the version of screen
> in the container is built with libdrm and is bypassing X or ??
I doubt it is being built differently than screen normally is.

> Do you have a makefile or a guix something.scm defining
> what's built/packed into your container? 
Nah, it's a rather ad-hoc definition grown from what should be an Eolie
container from the cookbook (also refer to #47097).

guix environment --preserve='^DISPLAY$' --preserve=XAUTHORITY \
 --preserve=TERM \
 --expose=$XAUTHORITY \
 --expose=/etc/machine-id \
 --expose=/etc/ssl/certs/ \
 --expose=/sys/block --expose=/sys/class --expose=/sys/bus \
 --expose=/sys/dev --expose=/sys/devices \
 --ad-hoc epiphany nss-certs dbus procps coreutils psmisc screen

Given that I expose most of /sys explicitly, you should take the above
with a grain of salt.

> Sorry if my curiosity is making work for you, but I'd like to
> try containers down the road -- tho right now I'm taking a break
> from events IRL, so I may disappear for a while...
I'm not personally impacted by this bug or anything, it's much rather a
follow-up to my attempted fix of #47097.  I think there might be some
flaw in trying to run a sandbox inside a sandbox (like bubblewrap
inside `guix container`), that doesn't actually improve security in any
meaningful way.

Regards,
Leo

bug#47106: Bubblewrap hates Guix containers 😞

[Ludovic Courtès]

Hi Leo,

Leo Prikler  skribis:

> Nah, it's a rather ad-hoc definition grown from what should be an Eolie
> container from the cookbook (also refer to #47097).
>
> guix environment --preserve='^DISPLAY$' --preserve=XAUTHORITY \
>  --preserve=TERM \
>  --expose=$XAUTHORITY \
>  --expose=/etc/machine-id \
>  --expose=/etc/ssl/certs/ \
>  --expose=/sys/block --expose=/sys/class --expose=/sys/bus \
>  --expose=/sys/dev --expose=/sys/devices \
>  --ad-hoc epiphany nss-certs dbus procps coreutils psmisc screen

I’m not sure I follow; does it work when you do this?

/sys is already mounted inside ‘guix environment -C’ containers so I
don’t see what difference it would make.

But wait, the example above lacks ‘-C’; a mistake?

Thanks,
Ludo’.

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")))
> (inputs `(("zlib" ,zlib)
>   ("libjpeg" ,libjpeg-turbo)))

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

Done as b082ea9406f19f0d0c296227510256b87fe11e3c

Thanks for the suggestion!

bug#47106: Bubblewrap hates Guix containers 😞

[Leo Prikler]

Am Sonntag, den 14.03.2021, 21:32 +0100 schrieb Ludovic Courtès:
> Hi Leo,
> 
> Leo Prikler  skribis:
> 
> > Nah, it's a rather ad-hoc definition grown from what should be an
> > Eolie
> > container from the cookbook (also refer to #47097).
> > 
> > guix environment --preserve='^DISPLAY$' --preserve=XAUTHORITY \
> >  --preserve=TERM \
> >  --expose=$XAUTHORITY \
> >  --expose=/etc/machine-id \
> >  --expose=/etc/ssl/certs/ \
> >  --expose=/sys/block --expose=/sys/class --expose=/sys/bus \
> >  --expose=/sys/dev --expose=/sys/devices \
> >  --ad-hoc epiphany nss-certs dbus procps coreutils psmisc
> > screen
> 
> I’m not sure I follow; does it work when you do this?
It does work insofar as I don't get any warnings about resources
missing from /sys, but the bubblewrapped WebKit processes don't have
access to $DISPLAY even though epiphany itself has.  While they don't
crash the browser itself and just infinitely respawn, that's still far
from usable.

> /sys is already mounted inside ‘guix environment -C’ containers so I
> don’t see what difference it would make.
I think I've been told this several times, but I don't believe it.  Not
adding all these expose=/sys lines triggers the "warnings" in the
original post.  (Okay, perhaps one of /sys/dev and /sys/devices is
superfluous, I would need to check.)

> But wait, the example above lacks ‘-C’; a mistake?
Indeed, -CN should also be given, but I hastily edited the command line
inside the email to make it appear more beautiful than it actually is,
thereby deleting it.  I'm sorry.  The preserves and exposes should be
the same list as I'm actually using however.

Regards,
Leo

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

[Arun Isaac]

Hi,

> @Arun, does this sound familiar to you?

Thanks for the bug report! It was indeed a regression in guile-email. I
have fixed it, and added a test. See
https://git.systemreboot.net/guile-email/commit/?id=ca0520a33c9042a68691d85c6849f88412ca8357

Cheers!


signature.asc
Description: PGP signature

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

[Jack Hill]

Still on the same VM, I've been able to reproduce the problem while 
building a different derivation: 
/gnu/store/07xw2pp63xin4c4y8ndrcdn3n8z1vmx2-grub-image.png.drv from Guix 
commit d4e29f3628ad0c7576d7cab659d7fcc19d21999a. I can still build the new 
derivation on my desktop.


Hrm, it's a pretty spooky problem.

Best,
Jack

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

[Jack Hill]

Trying to document some more information in the hopes that others can 
reproduce this bug.


On the host that fails:

$ guix describe
Generation 7Mar 14 2021 16:14:58(current)
  guix d4e29f3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: d4e29f3628ad0c7576d7cab659d7fcc19d21999a

jackhill@kalessin ~$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel Xeon E3-12xx v2 (Ivy Bridge, IBRS)
stepping: 9
microcode   : 0x1
cpu MHz : 2599.990
cache size  : 16384 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm 
constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq 
vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes 
xsave avx f16c rdrand hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust smep erms 
xsaveopt arat md_clear
vmx flags	: vnmi preemption_timer posted_intr invvpid ept_x_only 
ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid 
unrestricted_guest vapic_reg vid
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass 
l1tf mds swapgs itlb_multihit srbds

bogomips: 5199.98
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel Xeon E3-12xx v2 (Ivy Bridge, IBRS)
stepping: 9
microcode   : 0x1
cpu MHz : 2599.990
cache size  : 16384 KB
physical id : 1
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm 
constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq 
vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes 
xsave avx f16c rdrand hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust smep erms 
xsaveopt arat md_clear
vmx flags	: vnmi preemption_timer posted_intr invvpid ept_x_only 
ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid 
unrestricted_guest vapic_reg vid
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass 
l1tf mds swapgs itlb_multihit srbds

bogomips: 5199.98
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

jackhill@kalessin ~$ cat /config.scm
;; This is an operating system configuration for a VM image.
;; Modify it as you see fit and instantiate the changes by running:
;;
;;   guix system reconfigure /etc/config.scm
;;

(use-modules (gnu) (guix))
(use-service-modules networking ssh)
(use-package-modules bootloaders certs linux
 package-management)

(define vm-image-motd (plain-file "motd" "
\x1b[1;37mThis is the GNU system.  Welcome!\x1b[0m

This instance of Guix is a template for virtualized environments.
You can reconfigure the whole system by adjusting /etc/config.scm
and running:

  guix system reconfigure /etc/config.scm

Run '\x1b[1;37minfo guix\x1b[0m' to browse documentation.

\x1b[1;33mConsider setting a password for the 'root' and 'guest' \
accounts.\x1b[0m
"))

(operating-system
 (host-name "kalessin")
 (timezone "America/New_York")
 (locale "en_US.utf8")
 (initrd-modules (cons "virtio_scsi" %base-initrd-modules))

 ;; Label for the GRUB boot menu.
 (label (string-append "GNU Guix " (package-version guix)))

 (firmware '())

 ;; Below we assume /dev/vda is the VM's hard disk.
 ;; Adjust as needed.
 (bootloader (bootloader-configuration
  (bootloader grub-bootloader)
  (target "/dev/vda")
  (terminal-outputs '(console
 (file-systems (cons (file-system
  (mount-point "/")
  (device (file-system-label "kalessin-btrfs"))
  (type "btrfs")
  (options "compress=zstd"))
 %base-file-systems))

 (users (cons* (user-account
(name "jackhill")
(comment "Jack Hill")
(group "users")
(supplementary-groups '("wheel" "netdev")))
   %base-user-accounts))

 ;; Our /etc/sudoers file.  Since 'guest' initially has an empty password,
 ;; allow for password-less sudo.
 (sudoers-file (plain-file "sudoers" "\
root ALL=(ALL) ALL
%wheel ALL=NOPASSWD: ALL\n"))

 (package

bug#47141: Zabbix packages vulnerable to CVE-2021-27927

[Mark H Weaver]

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten.

  Mark

 Start of forwarded message 
Subject: Zabbix packages vulnerable to CVE-2021-27927
From: Léo Le Bouter 
To: guix-de...@gnu.org
Date: Wed, 03 Mar 2021 21:08:54 +0100

Would be nice to update, it's a CSRF so not very high severity but
still.

See https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-27927


signature.asc
Description: This is a digitally signed message part
 End of forwarded message 

bug#47144: security patching of 'patch' package

[Mark H Weaver]

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten.

   Mark

 Start of forwarded message 
Subject: security patching of 'patch' package
From: Léo Le Bouter 
To: guix-de...@gnu.org
Date: Wed, 10 Mar 2021 04:14:35 +0100

Hello!

I could find that the 'patch' package was vulnerable to numerous CVEs
that other distros like Debian have patched. Here's the list reported
by 'guix lint -c cve patch':

patch@2.7.6: probably vulnerable to CVE-2019-13636, CVE-2019-13638,
CVE-2019-20633, CVE-2018-1000156, CVE-2018-20969, CVE-2018-6951, CVE-
2018-6952

Can I use latest commit from master to build 'patch' then graft
original package?

i.e. https://git.savannah.gnu.org/git/patch.git

There's not that many commits since last release, but lots of time: 
https://git.savannah.gnu.org/cgit/patch.git/log/

Thank you,
Léo


signature.asc
Description: This is a digitally signed message part
 End of forwarded message 

bug#47142: squid package vulnerable to CVE-2021-28116

[Mark H Weaver]

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten.

  Mark

 Start of forwarded message 
Subject: squid package vulnerable to CVE-2021-28116
From: Léo Le Bouter 
To: guix-de...@gnu.org
Date: Wed, 10 Mar 2021 01:22:51 +0100

CVE-2021-28116  09.03.21 23:15
Squid through 4.14 and 5.x through 5.0.5, in some configurations,
allows information disclosure because of an out-of-bounds read in WCCP
protocol data. This can be leveraged as part of a chain for remote code
execution as nobody.

Upstream did not release a patch yet. CVE entry to be monitored for a
fix.

https://www.zerodayinitiative.com/advisories/ZDI-21-157/ - says it is a
low impact issue.


signature.asc
Description: This is a digitally signed message part
 End of forwarded message 

bug#47143: pjproject package is vulnerable to CVE-2021-21375 and CVE-2020-15260

[Mark H Weaver]

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten.

  Mark

 Start of forwarded message 
Subject: pjproject package is vulnerable to CVE-2021-21375 and CVE-2020-15260
From: Léo Le Bouter 
To: guix-de...@gnu.org
Date: Thu, 11 Mar 2021 03:30:42 +0100

CVE-2021-21375  00:15
PJSIP is a free and open source multimedia communication library
written in C language implementing standard based protocols such as
SIP, SDP, RTP, STUN, TURN, and ICE. In PJSIP version 2.10 and earlier,
after an initial INVITE has been sent, when two 183 responses are
received, with the first one causing negotiation failure, a crash will
occur. This results in a denial of service.

CVE-2020-15260  00:15
PJSIP is a free and open source multimedia communication library
written in C language implementing standard based protocols such as
SIP, SDP, RTP, STUN, TURN, and ICE. In version 2.10 and earlier, PJSIP
transport can be reused if they have the same IP address + port +
protocol. However, this is insufficient for secure transport since it
lacks remote hostname authentication. Suppose we have created a TLS
connection to `sip.foo.com`, which has an IP address `100.1.1.1`. If we
want to create a TLS connection to another hostname, say `sip.bar.com`,
which has the same IP address, then it will reuse that existing
connection, even though `100.1.1.1` does not have certificate to
authenticate as `sip.bar.com`. The vulnerability allows for an insecure
interaction without user awareness. It affects users who need access to
connections to different destinations that translate to the same
address, and allows man-in-the-middle attack if attacker can route a
connection to another destination such as in the case of DNS spoofing.

Upstream has not made a release yet, I advise we wait for a release on
their end then upgrade. To be monitored.


signature.asc
Description: This is a digitally signed message part
 End of forwarded message 

bug#47140: libupnp package vulnerable to CVE-2021-28302

[Mark H Weaver]

I'm forwarding this to bug-guix@gnu.org so that it won't be forgotten.

   Mark

 Start of forwarded message 
Subject: libupnp package vulnerable to CVE-2021-28302
From: Léo Le Bouter 
To: guix-de...@gnu.org
Date: Sat, 13 Mar 2021 02:12:45 +0100

CVE-2021-28302  12.03.21 16:15
A stack overflow in pupnp 1.16.1 can cause the denial of service
through the Parser_parseDocument() function. ixmlNode_free() will
release a child node recursively, which will consume stack space and
lead to a crash.

Upstream did not provide a patch yet, see <
https://github.com/pupnp/pupnp/issues/249>.

I suggest we wait for the patch to be made and then update, to be
monitored.


signature.asc
Description: This is a digitally signed message part
 End of forwarded message 

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

[Jack Hill]

Okay, I've started looking at the builder a little more:

jackhill@alperton ~$ cat /gnu/store/larqpc2wjhnc6jmj4885k8lynd19fl4m-grub-image.png-builder 
(if (string-suffix? ".svg" "/gnu/store/83qplqmavzphd30hm1maxwlh166ylpwr-guix-artwork-2f2fe74-checkout/grub/GuixSD-fully-black-4-3.svg") (begin (use-modules (gnu build svg)) (svg->png "/gnu/store/83qplqmavzphd30hm1maxwlh166ylpwr-guix-artwork-2f2fe74-checkout/grub/GuixSD-fully-black-4-3.svg" ((@ (guile) getenv) "out") #:width 1024 #:height 768)) (copy-file "/gnu/store/83qplqmavzphd30hm1maxwlh166ylpwr-guix-artwork-2f2fe74-checkout/grub/GuixSD-fully-black-4-3.svg" ((@ (guile) getenv) "out")))


The problem appears to be in the svg->png procedure or at least in the 
svg.scm file. On the "bad" system:


jackhill@kalessin ~$ guix environment --ad-hoc guile guile-rsvg guile-readline
jackhill@kalessin ~ [env]$ guile
GNU Guile 3.0.5
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use (gnu build svg)
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /run/current-system/profile/share/guile/site/3.0/gnu/build/svg.scm
;;; WARNING: compilation of 
/run/current-system/profile/share/guile/site/3.0/gnu/build/svg.scm failed:
;;; failed to create path for auto-compiled file 
"/run/current-system/profile/share/guile/site/3.0/gnu/build/svg.scm"
scheme@(guile-user)> (svg->png 
"/gnu/store/83qplqmavzphd30hm1maxwlh166ylpwr-guix-artwork-2f2fe74-checkout/grub/GuixSD-fully-black-4-3.svg"
 "/tmp/test.png")
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Wrong type (expecting finalized smob): #

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

On the good system

ckhill@alperton ~$ guix environment --ad-hoc guile guile-rsvg guile-readline
jackhill@alperton ~ [env]$ guile
GNU Guile 3.0.5
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use (gnu build svg)
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /run/current-system/profile/share/guile/site/3.0/gnu/build/svg.scm
;;; compiled 
/home/jackhill/.cache/guile/ccache/3.0-LE-8-4.4/gnu/store/0j6w61vjjvp4zqzrqvyhqm6254ppzh8y-guix-1.2.0-16.c8887a5/share/guile/site/3.0/gnu/build/svg.scm.go
scheme@(guile-user)> (svg->png 
"/gnu/store/83qplqmavzphd30hm1maxwlh166ylpwr-guix-artwork-2f2fe74-checkout/grub/GuixSD-fully-black-4-3.svg"
 "/tmp/test.png")

and a png file is produced. Particularly relivant seems the 
auto-compilation failure.


To be continued…

Best,
Jack

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

[Mark H Weaver]

Hi Jack,

Jack Hill  writes:

> 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?

Rolling back to an earlier system generation and running "guix gc" again
was a good idea, but you might have missed one or two crucial steps in
between:

(1) You must *delete* the "older" system generations and user profiles
e.g. by running "guix system delete-generations" and "guix package
--delete-generations", or else "guix gc" won't clear them from your
store.  It is not enough to merely switch to an older system
generation and profiles.

(2) You'll also need to actually reboot into the older system
generation, because /run/booted-system will continue to protect
(from GC) the system that you last booted into, even after you
switch systems.

Did you do those things before running "guix gc"?

I'm sorry that you've hit this nasty bug.

 Regards,
   Mark

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

[Leo Famulari]

On Fri, Mar 12, 2021 at 07:24:16PM -0500, Mark H Weaver wrote:
> Is anyone else seeing this?  FWIW, I tested reconfiguring my Guix system
> with the grafts I recently pushed, and grub-img.png built successfully
> for me.  I'm using the resulting system now.

I wasn't able to reproduce this on either a Core 2 Duo or a newer AMD
EPYC machine.

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

[Jack Hill]

On Sun, 14 Mar 2021, Mark H Weaver wrote:


(1) You must *delete* the "older" system generations and user profiles
   e.g. by running "guix system delete-generations" and "guix package
   --delete-generations", or else "guix gc" won't clear them from your
   store.  It is not enough to merely switch to an older system
   generation and profiles.

(2) You'll also need to actually reboot into the older system
   generation, because /run/booted-system will continue to protect
   (from GC) the system that you last booted into, even after you
   switch systems.

Did you do those things before running "guix gc"?


Oops, I left out those details. Yes, I did both those things.


I'm sorry that you've hit this nasty bug.


Thanks. For me, being the only one that can reproduce or experience a 
problem can be a frustrating and lonely experience, so really appreciate 
the time you and Leo have spent looking at it.


Best,
Jack

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

[Mark H Weaver]

Hi Jack,

Jack Hill  writes:

> On Sun, 14 Mar 2021, Mark H Weaver wrote:
>
>> (1) You must *delete* the "older" system generations and user profiles
>>e.g. by running "guix system delete-generations" and "guix package
>>--delete-generations", or else "guix gc" won't clear them from your
>>store.  It is not enough to merely switch to an older system
>>generation and profiles.
>>
>> (2) You'll also need to actually reboot into the older system
>>generation, because /run/booted-system will continue to protect
>>(from GC) the system that you last booted into, even after you
>>switch systems.
>>
>> Did you do those things before running "guix gc"?
>
> Oops, I left out those details. Yes, I did both those things.

It occurs to me that we missed something: the profiles in
~/.config/guix/current that are managed by "guix pull".  It might be
that code within Guix itself was miscompiled (e.g. gnu/build/svg.scm),
or else that a profile in ~/.config/guix/current is still holding a
reference to something else that was miscompiled, (e.g. guile-cairo).

I suggest "guix pull --commit=453e101fc3f7dac9aabcd6122cf05fb7925103c7",
and then "guix package -p ~/.config/guix/current --delete-generations"
to delete any generations of Guix at commits that came after the Cairo
graft (use "guix pull --list-generations" to list them).  Do this for
all user accounts (including root) that have a ~/.config/guix/current
directory.  Then, try "guix gc" again.

 Thanks,
   Mark

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

Hello all,

Unfortunately, it seems that the SJTU server is somewhat unreliable, I 
sometimes get random failures in various parts talking to the substitute 
server, complaining of strange responses from the server:

```
Backtrace:
In guix/ui.scm:
  2164:12 19 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
652:2 18 (guix-substitute . _)
In unknown file:
  17 (with-continuation-barrier #)
In ice-9/boot-9.scm:
  1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
  15 (apply-smob/0 #)
In ice-9/boot-9.scm:
  1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
  1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15 12 (with-exception-handler # …)
In guix/scripts/substitute.scm:
   701:17 11 (_)
410:7 10 (process-substitution _ "/gnu/store/yfzsz94qy92c7m9w0j…" …)
In ice-9/boot-9.scm:
  1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
419:9  8 (_)
In ice-9/boot-9.scm:
  1731:15  7 (with-exception-handler # …)
  1669:16  6 (raise-exception _ #:continuable? _)
  1667:16  5 (raise-exception _ #:continuable? _)
  1669:16  4 (raise-exception _ #:continuable? _)
  1764:13  3 (_ #<&compound-exception components: (#<&error> #<&irri…>)
  1669:16  2 (raise-exception _ #:continuable? _)
  1667:16  1 (raise-exception _ #:continuable? _)
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
Backtrace:
In ice-9/boot-9.scm:
  1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   3 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2  2 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  1 (_ #(#(#)))
In guix/ui.scm:
  2164:12  0 (run-guix-command _ . _)

guix/ui.scm:2164:12: In procedure run-guix-command:
Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
substitution of /gnu/store/yfzsz94qy92c7m9w0jbll7slc2pcap45-guix-packages-base 
failed
guix pull: error: corrupt input while restoring archive from #
```

I configured `guix-daemon` to have two substitute URLs: SJTUG, and the official 
Cuirass in Berlin.  My expectation is that if the SJTUG server fails, it should 
fall back on using the Cuirass server.

So my problems are two-fold:

* Apparently the SJTUG mirror sometimes acts in ways that aren't quite how Guix 
expects it.  Either SJTUG or Guix has to be fixed so they talk in compatible 
manners.
* Multiple Substitute URLs are not useful for the mirroring configuration where 
one server is temporarily unable to properly serve; further servers are not 
checked.

I'm still not satisfied with this solution overall.  Yes it's fast but it's 
imperfect.

I recently had to rebuild an OS (because I was dumb; the Guix language for 
shepherd services can easily lead you deadlocking shepherd itself) and had 
supreme difficulty reinstalling, because the Berlin server was too slow (would 
have taken ~10hours downloading everything) while the SJTUG server was 
unreliable and would consistently break the automated install.  I had to `guix 
system build --fallback` separately and *then* `guix system init` manually.

Thanks
raid5atemyhomework

bug#47147: Guix substituter gives up too easily, causing higher-level commands to fail catastrophically

[raid5atemyhomework via Bug reports for GNU Guix]

Split off from 46942

I recently had to rebuild a Guix OS. I ran a modified installer that used two 
substitute URLs: the SJTUG mirror, and the official Cuirass server in Berlin, 
listed in that order.

Unfortunately, it seems the SJTUG mirror has some reliability problems, during 
install the guided installation repeatedly failed during downloading of a 
`e2fsck` archive; I was unable to save the error since this occurred during an 
install when I had no easy way to copy-paste error messages.

But that's tangential to *this* particular report.  My expectation when I give 
multiple substitute URLs is that if one substitute server is failing, it should 
automatically try other substitute servers.  So even if it gets *any* kind of 
error on the first listed server, the substituter should make an effort to talk 
to some other server listed in the `substitute-urls`, not give up immediately.

My expectation is this:

* For each substitute server:
  * If package exists in server:
* Try downloading
  * If downloading completed with signature OK, exit function with success.
  * else continue
* If we reach here, build locally if `--fallback` is specified.

But it looks like:

* For each substitute server:
  * If package exists in server:
* Try downloading
  * If downloading completed with signature OK, exit function with success.
  * else error out of the function
* If we reach here, build locally if `--fallback` is specified.

The simple fact of the matter is that Internet connectivity ***IS NOT 
RELIABLE***, so failure to download MUST NOT mean that the substituter should 
assume the worst and should just fail catastrophically and abort, which then 
leads to higher-level constructions *also* aborting, sometimes throwing several 
minutes' worth of processing and downloading down the drain just because some 
package was not downloaded from a particular substitute server.

So what I would really like is:

* The substituter should really make at least a token effort to *resume* a 
partial download that failed midway through.  Even just have it try a resume 
*once* would be good.
* The substituter should really fall back to the next item in the list of 
substitute URLs if the first one is not behaving properly, instead of deciding 
that the first substitute URL is the canonical version and further substitute 
URLs are to be ignored.

Is there any reason why the above is not feasible for Guix?

Thanks
raid5atemyhomework

bug#47149: guix system init seems to ignore --fallback

[raid5atemyhomework via Bug reports for GNU Guix]

Split off from 46942

Recently I had to rebuild my Guix OS (ummm it was practice for installing Guix, 
not at all being too overconfident with `guix system --delete-generations` and 
screwing up a shepherd start service so that shepherd got into an infinite loop 
in an edge case...).  Because the official Guix Cuirass in Berlin is 
ridiculously slow, I used a modified installer with the SJTUG mirror as the 
first substitute URL and the Guix Cuirass server as second substitute URL.

However, during guided install the SJTUG server gave strange errors to the 
substituter (which I was unable to capture since it was an install environment 
and I had no good way to copy-paste from it - I am running Guix on the metal, 
not in a VM).

Now of course any failure in the first substitute URL should cause the 
substituter to fall back to the second substitute URL and so on, but that's 
47147

*This* bug report is about `guix system init --fallback`.

The same errors happened when I fell back to manual installation and used `guix 
system init`.  So I tried passing in `--fallback` to make Guix build the 
package (some `e2fsck` package, do not remember details) instead of trying to 
download it from SJTUG (since it couldn't download it, it would fail 
catastrophically).

In order to continue, I had to use `guix system build --fallback`, which seemed 
to work in that it completed, and a a subsequent `guix system init` succeeded.

So it looks to me that `guix system init` does not propagate `--fallback`.

Thanks
raid5atemyhomework

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

[Jack Hill]

On Sun, 14 Mar 2021, Mark H Weaver wrote:


It occurs to me that we missed something: the profiles in
~/.config/guix/current that are managed by "guix pull".  It might be
that code within Guix itself was miscompiled (e.g. gnu/build/svg.scm),
or else that a profile in ~/.config/guix/current is still holding a
reference to something else that was miscompiled, (e.g. guile-cairo).

I suggest "guix pull --commit=453e101fc3f7dac9aabcd6122cf05fb7925103c7",
and then "guix package -p ~/.config/guix/current --delete-generations"
to delete any generations of Guix at commits that came after the Cairo
graft (use "guix pull --list-generations" to list them).  Do this for
all user accounts (including root) that have a ~/.config/guix/current
directory.  Then, try "guix gc" again.


Thanks Mark. I've done the dance to gc as much as possible again. This 
time, I also checked in /var/guix/gcroots to make sure I hadn't missed 
anything. In fact I had missed some extra manual roots that I had created, 
and I cleaned those up as well before running guix gc.


After running guix gc, I rebooted, ran guix pull, followed by a 
reconfigure. The first reconfigure failed because of the substitute 
networking problem, but when I ran it again, it failed in the same way 
building the grub png. After it failed, I ran it again to capture the 
following output:


jackhill@kalessin ~$ guix describe
Generation 9Mar 14 2021 23:24:43(current)
  guix d059485
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: d059485257bbe5b4f4d903b357ec99a3af2d4f39
jackhill@kalessin ~$ sudo -E guix system -v3 reconfigure /config.scm
The following derivations will be built:
   /gnu/store/xqdm3fslr3n0jyxh6i3nsn237lygjfwf-system.drv
   /gnu/store/2p1s41kwh9w7w8cijg3r4zplc9f9i6fw-activate.scm.drv
   /gnu/store/jgagsl2m5x5vi63s3hdwg6lb58m8qiz1-activate-service.scm.drv
   /gnu/store/dsv31bkl2vwqhqgrqvz59wir009ix3kb-etc.drv
   /gnu/store/9f2rvmk0xii50smi8dwn0q9556y7qc94-rottlog.drv
   /gnu/store/ky3yw75v55g06ggi4i0xk155i7knn10f-sudoers.drv
   /gnu/store/b2h0nkrd03zff082lg7y149aw3j9yfxg-profile.drv
   /gnu/store/hlr9ypdb841sz2w949mxi5kqhvv2dd22-boot.drv
   /gnu/store/y8s53y9irwbsy1pc07vbczbp7jwsrsw4-shepherd.conf.drv
   
/gnu/store/6zk7p1iljyayb5hyafgbzik06cq0f00j-shepherd-ssh-daemon-ssh-sshd.go.drv
   
/gnu/store/p89f6qy78yarsjrmq8mkrjihnk4hpm25-shepherd-ssh-daemon-ssh-sshd.scm.drv
   /gnu/store/kscdry7kq4izr7nyzs6gq3kg0hqcjffx-shepherd-guix-daemon.go.drv
   /gnu/store/aa4wgjx3625m5k71i5rzb0ywx9z6a0i3-shepherd-guix-daemon.scm.drv
   /gnu/store/qy2sl92bqnzahvpzb6imgspp6llpz0cj-shepherd-mcron.go.drv
   /gnu/store/xdxd5gfvzk4g0m2idbfcrp3d32gm0vz6-shepherd-mcron.scm.drv
   /gnu/store/q8ampzxsdkibl15jhlvq30gic5qgm0wi-mcron-job.drv
   /gnu/store/qj9nqyhci6zhkfprpwch90ry5hkhwvbx-mcron-job.drv
   /gnu/store/6gx45db5mwraihq1qv8c9vmxhdskjk1a-grub.cfg.drv
   /gnu/store/07xw2pp63xin4c4y8ndrcdn3n8z1vmx2-grub-image.png.drv
The following grafts will be made:
   /gnu/store/fwwwnlzhckvi4wmw89m9az9y9wb9v6q9-rottlog-0.72.2.drv
   /gnu/store/26z2lhnqhzr5b88axv7b38fgqjl3w2h8-usbutils-013.drv
The following profile hooks will be built:
   /gnu/store/5c19y82k9pw297w0b5gn8j6p7g7c6h60-ca-certificate-bundle.drv
   /gnu/store/j5plp2k4bkjilqx1yw9mkavy37ipp29h-fonts-dir.drv
   /gnu/store/lcilg958v3adfl8jljkjwpwihbzsyr6c-info-dir.drv
   /gnu/store/z5m7ra9zd3vhqbp5hg4695s2jgsggr6q-manual-database.drv
building /gnu/store/07xw2pp63xin4c4y8ndrcdn3n8z1vmx2-grub-image.png.drv...
Backtrace:
   2 (primitive-load "/gnu/store/larqpc2wjhnc6jmj4885k8lynd1?")
In gnu/build/svg.scm:
 53:6  1 (svg->png _ "/gnu/store/vmldvxllh07k641wmbnlz3migga29r?" ?)
In unknown file:
   0 (rsvg-handle-render-cairo # #)

ERROR: In procedure rsvg-handle-render-cairo:
Wrong type (expecting finalized smob): #
builder for `/gnu/store/07xw2pp63xin4c4y8ndrcdn3n8z1vmx2-grub-image.png.drv' 
failed with exit code 1
build of /gnu/store/07xw2pp63xin4c4y8ndrcdn3n8z1vmx2-grub-image.png.drv failed
View build log at 
'/var/log/guix/drvs/07/xw2pp63xin4c4y8ndrcdn3n8z1vmx2-grub-image.png.drv.bz2'.
cannot build derivation 
`/gnu/store/6gx45db5mwraihq1qv8c9vmxhdskjk1a-grub.cfg.drv': 1 dependencies 
couldn't be built
guix system: error: build of 
`/gnu/store/6gx45db5mwraihq1qv8c9vmxhdskjk1a-grub.cfg.drv' failed

Do you think it is worth creating another VM to see if it's a problem with 
the VM configuration?


Best,
Jack

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

[Jack Hill]

On Sun, 14 Mar 2021, Jack Hill wrote:


After running guix gc, I rebooted, ran guix pull


Er, I wrote it backwords here, but I ran them in the correct order: delete 
roots, reboot, gc, pull, …

bug#47089: error: make-session: unbound variable

[Mark H Weaver]

Hi Jean,

Jean Louis  writes:

> Running guix package manager on Hyperbola GNU/Linux-libre:
>
> [root@protected ~]# guix pull --no-substitutes -K
> accepted connection from pid 876, user root
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   5a06b83
> building /gnu/store/0l5krmnzmkyawbh7y7xa808sq7sp30vv-config.scm.drv...
> building /gnu/store/klcxrfvivkjri4whdpyhsnjywr9ki8br-git.scm.drv...
> building /gnu/store/6kfhwxxjkrknf9wgv2mawyrrzlbbzli2-hash.scm.drv...
> building /gnu/store/1imdq47vyanhn2mw4814xz10d4ahyd25-module-import.drv...
> building 
> /gnu/store/2zb0ys1iiz7djfgyj234ykzfqcjg27lf-module-import-compiled.drv...
> building 
> /gnu/store/dmr42vhl0wsjm413i79dxx5nv6wqvcb8-compute-guix-derivation.drv...
> Computing Guix derivation for 'x86_64-linux'... |@ build-started 
> /gnu/store/51h0bidlh2w1qhkmy1mc3jdg31jla4b1-module-import-compiled.drv - 
> x86_64-linux 
> /var/log/guix/drvs/51//h0bidlh2w1qhkmy1mc3jdg31jla4b1-module-import-compiled.drv.bz2
>  2051
> -@ build-succeeded 
> /gnu/store/51h0bidlh2w1qhkmy1mc3jdg31jla4b1-module-import-compiled.drv -
> @ build-started 
> /gnu/store/rx4xa4pzl258yg3hgxrv8xaasrcc6fkg-Python-3.8.2.tar.xz.drv - 
> x86_64-linux 
> /var/log/guix/drvs/rx//4xa4pzl258yg3hgxrv8xaasrcc6fkg-Python-3.8.2.tar.xz.drv.bz2
>  2083
> |@ build-log 2083 22
>
> Starting download of @ build-log 2083 132
> /gnu/store/pkzdxf9fhdfx473lphqgydd4q3nk4rql-Python-3.8.2.tar.xz
> From https://www.python.org/ftp/python/3.8.2/Python-3.8.2.tar.xz...
> /@ build-log 2083 51
> error: make-session: unbound variable

'make-session' should be provided by the Guile-bindings included in
GnuTLS.  It might be that the GnuTLS provided by Hyperbola wasn't
compiled with Guile support, or provides Guile support but for a
different version of Guile than the one you're using to run Guix.

What method did you use to install Guix?

It looks like you compiled Guix from source using Hyperbola's native
toolchain, libraries, and Guile.  If so, you might have better results
using Guix's binary installer method, which installs a Guix binary that
avoids using components from your native OS, in favor of components that
were built by Guix and are known to work correctly with it.

Regards,
  Mark

bug#47064: DrRacket internal error uncompressing

[Jack Hill]

I wrote to the racket-users [0] list to see if they have advice on what 
could be causing this problem.


[0] https://www.mail-archive.com/racket-users@googlegroups.com/msg46066.html

Best,
Jack