bug#28840: openrct2 cannot find data-path

[Rutger Helling]

Hi Ludo and Jelle, 

I've attached a patch that fixed the issue for me by changing some
references from /usr/share to /gnu/store/-openrct2-0.1.1/share.
I can now run openrct2 without the additional parameter. 

On 2017-10-20 22:21, l...@gnu.org wrote:

> Hello,
> 
> Jelle Licht  skribis:
> 
>> No, I am talking about resources such as shaders and
>> language packs, which seem to be included in openrct2 itself.
>> IOW, even *with* the data files from the proprietary rct2, our current
>> openrct2
>> does not run without the command line flags I added to my first posting :-).
> 
> Oh, I see.  Rutger, does that ring a bell?
> 
> https://bugs.gnu.org/28840
> 
> Thanks,
> Ludo'.From 4c2af88af74f3efe319f23e9716f9ca41f70e618 Mon Sep 17 00:00:00 2001
From: Rutger Helling 
Date: Sat, 21 Oct 2017 10:33:30 +0200
Subject: [PATCH] gnu: openrct2: Fix a few paths.

* gnu/packages/games.scm (openrct2): Fix a few paths.
---
 gnu/packages/games.scm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 6709f0292..657c23c4e 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -2647,6 +2647,12 @@ Transport Tycoon Deluxe.")
  `(#:tests? #f ;; no tests available
#:phases
 (modify-phases %standard-phases
+  (add-after 'unpack 'fix-usr-share-paths
+(lambda* (#:key make-flags outputs #:allow-other-keys)
+  ;; Fix some references to /usr/share.
+  (substitute* "src/openrct2/platform/linux.c"
+(("/usr/share")
+(string-append (assoc-ref %outputs "out") "/share")
   (add-after 'build 'fix-cmake-install-file
 (lambda _
   ;; The build system tries to download a file and compare hashes.
-- 
2.14.2

bug#29363: Single test failure building Guix

[Rutger Helling]

Hi Ludo, 

it is indeed reproducible. No matter how many times it always keeps
failing on this one test. 

I've had this problem for a long time, which is a little bit annoying
since it means I have to wait until a substitute is available every
time. 

On 2017-11-20 16:55, l...@gnu.org wrote:

> Hi Rutger,
> 
> Rutger Helling  skribis:
> 
>> test-name: dead path can be explicitly collected
>> location: 
>> /tmp/guix-build-guix-0.13.0-10.0b4c385.drv-0/source/tests/store.scm:178
>> source:
>> + (test-assert
>> +   "dead path can be explicitly collected"
>> +   (let ((p (add-text-to-store
>> +  %store
>> +  "random-text"
>> +  (random-text)
>> +  '(
>> + (let-values
>> +   (((paths freed) (delete-paths %store (list p
>> +   (and (equal? paths (list p))
>> +(> freed 0)
>> +(not (file-exists? p))
>> actual-value: #f
>> result: FAIL
> 
> I didn't experience this on my laptop.  Is it reproducible if you run
> "guix build guix" a second time?
> 
> Thanks,
> Ludo'.

bug#29363: Single test failure building Guix

[Rutger Helling]

Hi Marius, 

your patch did the trick, thanks! 

I'm indeed on Btrfs (with LUKS), no SSD though. 

On 2017-11-21 01:31, Marius Bakke wrote:

> Hi Rutger,
> 
> Rutger Helling  writes:
> 
>> when building Guix with 'guix build guix' I keep running into a single 
>> test failure. I've attached the test-suite.log.
> 
> Is this a Btrfs system by any chance, possibly on an SSD?
> 
>> test-name: dead path can be explicitly collected
>> location: 
>> /tmp/guix-build-guix-0.13.0-10.0b4c385.drv-0/source/tests/store.scm:178
>> source:
>> + (test-assert
>> +   "dead path can be explicitly collected"
>> +   (let ((p (add-text-to-store
>> +  %store
>> +  "random-text"
>> +  (random-text)
>> +  '(
>> + (let-values
>> +   (((paths freed) (delete-paths %store (list p
>> +   (and (equal? paths (list p))
>> +(> freed 0)
>> +(not (file-exists? p))
>> actual-value: #f
>> result: FAIL
> 
> I can reproduce this error on two different systems that have
> Btrfs+LUKS+SSD, and the problem is that freed == 0.
> 
> I suspect it's related to Btrfs' "lazy" reporting of disk space, but
> haven't dug very far.
> 
> Until we figure out what's going on, I suggest applying the patch
> below.  Can you confirm that it works on your system?
> 
> Ludo, WDYT?

bug#29363: Single test failure building Guix

[Rutger Helling]

Commenting out that line still made the test fail for me. 

On 2017-11-21 08:47, l...@gnu.org wrote:

> Hello,
> 
> Marius Bakke  skribis:
> 
> Rutger Helling  writes:
> 
> when building Guix with 'guix build guix' I keep running into a single 
> test failure. I've attached the test-suite.log. 
> Is this a Btrfs system by any chance, possibly on an SSD?
> 
> test-name: dead path can be explicitly collected
> location: 
> /tmp/guix-build-guix-0.13.0-10.0b4c385.drv-0/source/tests/store.scm:178
> source:
> + (test-assert
> +   "dead path can be explicitly collected"
> +   (let ((p (add-text-to-store
> +  %store
> +  "random-text"
> +  (random-text)
> +  '(
> + (let-values
> +   (((paths freed) (delete-paths %store (list p
> +   (and (equal? paths (list p))
> +(> freed 0)
> +(not (file-exists? p))
> actual-value: #f
> result: FAIL 
> I can reproduce this error on two different systems that have
> Btrfs+LUKS+SSD, and the problem is that freed == 0.

If you comment out (> freed 0), does the test pass?

> I suspect it's related to Btrfs' "lazy" reporting of disk space, but
> haven't dug very far.
> 
> Until we figure out what's going on, I suggest applying the patch
> below.  Can you confirm that it works on your system?
> 
> From bdc7b5310111e21801529ea57e290f6eb72ac6ed Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Tue, 21 Nov 2017 00:27:08 +0100
> Subject: [PATCH] gnu: guix: Disable test that fails on Btrfs.
> 
> Works around <https://bugs.gnu.org/29363>.
> Reported by Rutger Helling .
> 
> * gnu/packages/package-management.scm (guix)[arguments]: Rename
> 'disable-container-tests' phase to 'disable-failing-tests' and add 
> substitution
> to disable "dead path can be explicitly collected" test.

Alternately, we could comment out (> freed 0) if that's enough, with a
comment explaining why, and do "make update-guix-package".  That way
we'd avoid the extra build phase.

WDYT?

Thanks for finding out the root cause!

Ludo'.

bug#29363: Single test failure building Guix

[Rutger Helling]

I think commenting out (> freed 0) does work after all. When I ran 'guix
environment --pure guix' and 'make check TESTS=tests/store.scm' against
my git checkout the test passed. 

On 2017-11-21 13:53, l...@gnu.org wrote:

> Rutger Helling  skribis:
> 
>> Commenting out that line still made the test fail for me.
> 
> Could you figure out which of the conditions in the 'and' is failing?
> 
>> +   (and (equal? paths (list p))
>> +(> freed 0)
>> +(not (file-exists? p))
> 
> TIA,
> Ludo'.

bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.

[Rutger Helling]

Hey Guix,

I was surprised to learn that Ceph creates Btrfs subvolumes during its 
tests.
This is problematic because on Btrfs regular users can create 
subvolumes, but they cannot delete them.

This means I had to manually delete the following subvolumes as root:

ID 1744 gen 819598 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd0/current
ID 1745 gen 819598 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd0/snap_1
ID 1746 gen 819564 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd0/test_subvol
ID 1747 gen 819564 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd0/sync_snap_test
ID 1748 gen 819564 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd0/async_snap_test
ID 1749 gen 819598 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd1/current
ID 1750 gen 819598 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd1/snap_1
ID 1751 gen 819564 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd1/test_subvol
ID 1752 gen 819564 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd1/sync_snap_test
ID 1753 gen 819564 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd1/async_snap_test
ID 1754 gen 819598 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd2/current
ID 1755 gen 819598 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd2/snap_1
ID 1756 gen 819564 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd2/test_subvol
ID 1757 gen 819564 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd2/sync_snap_test
ID 1758 gen 819564 top level 257 path 
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd2/async_snap_test

bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.

[Rutger Helling]

Hi Ludo,

I'll try building again later (could be a while, Ceph takes a really 
long time to build), but I highly doubt that that's the case.
Btrfs subvolumes cannot be deleted with tools such as rm/rmdir, even as 
root. You have to run 'btrfs subvolume delete /subvolume' as root.
Although a regular user may create subvolumes, they cannot delete it 
(unless the USER_SUBVOL_RM_ALLOWED mount option is on).
Since the building is done as a guixbuilder user, I don't see how that 
would work.
And even if it did, if a build failed for example you'd still be left 
with a bunch of subvolumes in /tmp that can only be deleted as root.


On 2017-12-12 13:52, l...@gnu.org wrote:


Hi Rutger,

Rutger Helling  skribis:


I was surprised to learn that Ceph creates Btrfs subvolumes during its
tests.
This is problematic because on Btrfs regular users can create
subvolumes, but they cannot delete them.
This means I had to manually delete the following subvolumes as root:

ID 1744 gen 819598 top level 257 path
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd0/current
ID 1745 gen 819598 top level 257 path
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd0/snap_1


Does that mean that wiping out /tmp/guix-build-ceph-*, as happens when
build finishes, isn't enough to get rid of those volumes?

Ludo'.

bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.

[Rutger Helling]

Actually, I just tested it with the following:

$ cd /tmp
$ sudo -s -u guixbuilder01
bash-4.4$ guix environment -C --ad-hoc btrfs-progs
guixbuilder01@guixsd /tmp [env]#  btrfs subvol create test-snapshot
Create subvolume './test-snapshot'
guixbuilder01@guixsd /tmp [env]#  btrfs subvol del test-snapshot
Delete subvolume (no-commit): '/tmp/test-snapshot'
ERROR: cannot delete '/tmp/test-snapshot': Operation not permitted
guixbuilder01@guixsd /tmp [env]# exit
exit
bash-4.4$ guix environment -C --ad-hoc coreutils
guixbuilder01@guixsd /tmp [env]#  rm -rfv test-snapshot/
rm: cannot remove 'test-snapshot/': Operation not permitted
guixbuilder01@guixsd /tmp [env]#  rmdir  -v test-snapshot/
rmdir: removing directory, 'test-snapshot/'
rmdir: failed to remove 'test-snapshot/': Operation not permitted
guixbuilder01@guixsd /tmp [env]#

On 2017-12-12 14:10, Rutger Helling wrote:


Hi Ludo,

I'll try building again later (could be a while, Ceph takes a really 
long time to build), but I highly doubt that that's the case.
Btrfs subvolumes cannot be deleted with tools such as rm/rmdir, even as 
root. You have to run 'btrfs subvolume delete /subvolume' as root.
Although a regular user may create subvolumes, they cannot delete it 
(unless the USER_SUBVOL_RM_ALLOWED mount option is on).
Since the building is done as a guixbuilder user, I don't see how that 
would work.
And even if it did, if a build failed for example you'd still be left 
with a bunch of subvolumes in /tmp that can only be deleted as root.


On 2017-12-12 13:52, l...@gnu.org wrote:

Hi Rutger,

Rutger Helling  skribis:

I was surprised to learn that Ceph creates Btrfs subvolumes during its
tests.
This is problematic because on Btrfs regular users can create
subvolumes, but they cannot delete them.
This means I had to manually delete the following subvolumes as root:

ID 1744 gen 819598 top level 257 path
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd0/current
ID 1745 gen 819598 top level 257 path
tmp/guix-build-ceph-12.0.2.drv-0/td/t-7201/dev/osd0/snap_1
Does that mean that wiping out /tmp/guix-build-ceph-*, as happens when
build finishes, isn't enough to get rid of those volumes?

Ludo'.

bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.

[Rutger Helling]

Hey everyone,

Thanks for all the replies.

@Marius: It's a dependency for multipath-tools.

@Ludo: Like Tobias mentioned it does indeed systematically leave behind 
subvolumes that can only be manually deleted as root.

Thankfully this is the only package in which I've noticed this behavior.

I've disabled the tests entirely myself. This allowed me to build 
multipath-tools without any problems.
Maybe it's better to do that for now to make sure Btrfs users don't run 
into trouble and later disable the individual offending tests?


On 2017-12-12 21:19, l...@gnu.org wrote:


Tobias Geerinckx-Rice  skribis:

Ludovic Courtès wrote on 12/12/17 at 17:03: So does guix-daemon 
systematically leave /tmp/guix-build-ceph* behind it?

Almost certainly. I can confirm several hundred previously unknown
subvolumes filling up my btrfs substitute server. Time to clean up.


Ouch.  I find this Btrfs behavior highly questionable.

Let's make sure our packages don't leak Btrfs subvolumes then!

Ludo'.

bug#29675: databases should be created with chattr +C

[Rutger Helling]

This should also be done with virtual machine images.

bug#29689: Commit 1d008d9f8c44dfdb808235d451b72f255e72f103 gives derivation errors.

[Rutger Helling]

Commit 1d008d9f8c44dfdb808235d451b72f255e72f103 results in errors of the 
following type in guix environment/package/system etc.


guix system: error: build failed: derivation 
`/gnu/store/cmw2cl4fg1q5q5pdp7cbs6fd7yyg9phz-guile-2.0.14.drv' has 
incorrect output 
`/gnu/store/06y7gah4s74w66v0ba8pfd0azhkdkxhw-guile-2.0.14', should be 
`/gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14'


Reverting the commit makes things work again.

bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.

[Rutger Helling]

This bug has been open for quite a while now.
If there are no objections in the next few days, I'd like to disable the
tests entirely for now with a FIXME on finding and disabling only the
offending tests.

On Tue, 12 Dec 2017 21:19:07 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> Tobias Geerinckx-Rice  skribis:
> 
> > Ludovic Courtès wrote on 12/12/17 at 17:03:  
> >> So does guix-daemon systematically leave /tmp/guix-build-ceph*
> >> behind it?  
> >
> > Almost certainly. I can confirm several hundred previously unknown
> > subvolumes filling up my btrfs substitute server. Time to clean
> > up.  
> 
> Ouch.  I find this Btrfs behavior highly questionable.
> 
> Let’s make sure our packages don’t leak Btrfs subvolumes then!
> 
> Ludo’.



pgp146___G1g2.pgp
Description: OpenPGP digital signature

bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.

[Rutger Helling]

Thanks for all the replies. I've disabled the tests.


pgpVB5CVyirGf.pgp
Description: OpenPGP digital signature

bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.

[Rutger Helling]

I left it open because I was under the impression that some people were
still working on a fix for the tests. But since there doesn't seem to be
a short-term solution it's probably better to close it. There's a TODO
comment now anyway.

On Mon, 08 Jan 2018 15:29:35 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> Rutger Helling  skribis:
> 
> > Thanks for all the replies. I've disabled the tests.  
> 
> Thank you.  Remember to close the bug by emailing
> number-d...@debbugs.gnu.org as I did here.  :-)
> 
> Ludo’.



pgpubyAlmwwxw.pgp
Description: OpenPGP digital signature

bug#31109: Retroarch: source tarball has wrong hash

[Rutger Helling]

Hi Ludo, 

The tarball changed. I ran a diff and couldn't find anything malicious
in the changes so I updated the checksum just now. 

On 2018-04-09 10:44, l...@gnu.org wrote:

> Hello,
> 
> I get:
> 
> --8<---cut here---start->8---
> $ guix build 
> /gnu/store/csv3ibcqacvk1l6np1f6ch5f62gz1yw0-retroarch-1.7.1.tar.gz.drv
> The following derivation will be built:
> /gnu/store/csv3ibcqacvk1l6np1f6ch5f62gz1yw0-retroarch-1.7.1.tar.gz.drv
> @ build-started 
> /gnu/store/csv3ibcqacvk1l6np1f6ch5f62gz1yw0-retroarch-1.7.1.tar.gz.drv - 
> i686-linux 
> /var/log/guix/drvs/cs//v3ibcqacvk1l6np1f6ch5f62gz1yw0-retroarch-1.7.1.tar.gz.drv.gz
> 
> Starting download of 
> /gnu/store/pddz1nyw4rni60mqha4dp02rk4c9gv36-retroarch-1.7.1.tar.gz
> From https://github.com/libretro/RetroArch/archive/v1.7.1.tar.gz...
> following redirection to 
> `https://codeload.github.com/libretro/RetroArch/tar.gz/v1.7.1'...
> v1.7.1.tar.gz  19.6MiB   9.6MiB/s 00:02 [##] 
> 100.0%
> sha256 hash mismatch for output path 
> `/gnu/store/pddz1nyw4rni60mqha4dp02rk4c9gv36-retroarch-1.7.1.tar.gz'
> expected: 0fdribjfc5zz9brzhqcxw6m76kvyg13l67aiigszv4wsjd5j3gpz
> actual:   1wykv0w0kdlh7lh0k1ig0lpk5vh4c7r19jlfa9103jmjlryrq679
> @ build-failed 
> /gnu/store/csv3ibcqacvk1l6np1f6ch5f62gz1yw0-retroarch-1.7.1.tar.gz.drv - 1 
> sha256 hash mismatch for output path 
> `/gnu/store/pddz1nyw4rni60mqha4dp02rk4c9gv36-retroarch-1.7.1.tar.gz'
> expected: 0fdribjfc5zz9brzhqcxw6m76kvyg13l67aiigszv4wsjd5j3gpz
> actual:   1wykv0w0kdlh7lh0k1ig0lpk5vh4c7r19jlfa9103jmjlryrq679
> --8<---cut here---end--->8---
> 
> Looking at
> , it
> seems that this package never built on Hydra.
> 
> Rutger, could you take a look and determine if it's just a mistake or if
> the GitHub-generated tarball changed?
> 
> TIA!
> 
> Ludo'.

bug#31113: mcron ERROR: In procedure mktime:

[Rutger Helling]

I had this problem too. 

Reverting commit cfbf6de18cc70d2e385feb5f61f9363f18e78ddf (gnu: mcron:
Update to 1.1 and deprecate "mcron2".) fixed it for me.


pgpXebwLkqBJM.pgp
Description: OpenPGP digital signature

bug#31669: 'guix system' enhancements

[Rutger Helling]

Hi Guix,

This isn't really a bug, but I noticed that 'guix system' right now cannot use 
certain common build
options like 'with-input'. I don't know how hard it would be to add
that, because I think it could be pretty useful for something like the
following for example:

guix system reconfigure --with-input=openssl=libressl system.scm

WDYT?


pgppak9DEm8dF.pgp
Description: OpenPGP digital signature

bug#31669: 'guix system' enhancements

[Rutger Helling]

Hi Ludo,

That might cause confusion like you said, so I'm not sure if that would
be an improvement.

I guess I was wondering whether there was an easy way to do something
like build your entire system with a newer Mesa, or use LibreSSL 
instead of OpenSSL as mentioned. Of course you could change your own
git checkout, but that's not as elegant as '--with-input/--with-graft'
etc.

Another option would be to make your own transformed packages and add
those as services instead of the regular versions. Unfortunately a lot
of services right now don't have that option (OpenSSH for example).
Plus you're pretty liable to make a mistake that way.

On Fri, 01 Jun 2018 14:58:03 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Hello,
> 
> Rutger Helling  skribis:
> 
> > This isn't really a bug, but I noticed that 'guix system' right now
> > cannot use certain common build options like 'with-input'. I don't
> > know how hard it would be to add that, because I think it could be
> > pretty useful for something like the following for example:
> >
> > guix system reconfigure --with-input=openssl=libressl system.scm  
> 
> Note that ‘--with-input’ & co. are *package* transformation options,
> so the question is which packages we’d apply them to.
> 
> We could take those options as applying to all the packages in the
> global profile, but it may not be exactly what people would expect
> because it would not apply to packages used by Shepherd services.
> 
> WDYT?
> 
> Ludo’.



pgprwKpILQ6pY.pgp
Description: OpenPGP digital signature

bug#31669: 'guix system' enhancements

[Rutger Helling]

That's neat! I'll play around with it later, thanks for the tip.

On Fri, 01 Jun 2018 22:35:26 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Hello,
> 
> Rutger Helling  skribis:
> 
> > That might cause confusion like you said, so I'm not sure if that
> > would be an improvement.
> >
> > I guess I was wondering whether there was an easy way to do
> > something like build your entire system with a newer Mesa, or use
> > LibreSSL instead of OpenSSL as mentioned. Of course you could
> > change your own git checkout, but that's not as elegant as
> > '--with-input/--with-graft' etc.  
> 
> Another option would be to operate at the derivation level rather than
> at the package level.  There’s a currently unused procedure called
> ‘map-derivation’ which is similar to what ‘--with-input’ does, except
> that it’s at the derivation level.  Example:
> 
> --8<---cut here---start->8---
> scheme@(guile-user)> ,use(guix)
> scheme@(guile-user)> ,use(gnu)
> scheme@(guile-user)> (getcwd)
> $2 = "/home/ludo/src/guix/guix"
> scheme@(guile-user)> (define os (load
> "../gnu/system/examples/bare-bones.tmpl"))
> scheme@(guile-user)> ,run-in-store (operating-system-derivation os)
> $4 =
> # => /gnu/store/4igvd1ynxjv3hk8qpf0l9bpb2v157hjf-system 4c209b0>
> scheme@(guile-user)> ,use(gnu packages tls)
> scheme@(guile-user)> ,run-in-store (package->derivation openssl) $5 =
> # => /gnu/store/yvy6pj9b3rpb3wr98x0sjlxv5g9p5x5l-openssl-1.0.2o-doc 
> /gnu/store/ggrpw6gh2rnqjwyjf99z8cdw5digc4hb-openssl-1.0.2o 
> /gnu/store/9cdb2xydmm012v81l78jliird4f7dy25-openssl-1.0.2o-static
> 5594370> scheme@(guile-user)> ,run-in-store (package->derivation
> 5594370> libressl) substitute: updating list of substitutes from
> 5594370> 'https://berlin.guixsd.org'... 100.0% $6 =
> 5594370> # /gnu/store/2wds8bdyl25iqx63p2vv7fy05rbmq4s5-libressl-2.7.3.drv
> 5594370> => /gnu/store/d9askfqx719bv3610kd6s3jqjh5rnfsh-libressl-2.7.3
> 5594370> 538b1e0> scheme@(guile-user)> (define s (open-connection))
> 5594370> 538b1e0> scheme@(guile-user)> (map-derivation s $4
> 5594370> 538b1e0> `((,$5 . ,$6)))
> $7 =
> # => /gnu/store/x5gyjvmq663jhd1pc1pc5w46hpcghvwd-system 618bf00>
> --8<---cut here---end--->8---
> 
> It’s a bit of a sledgehammer and ‘map-derivation’ may be buggy on the
> edges, but worth exploring.  :-)
> 
> HTH,
> Ludo’.



pgpXUjyzyZd4D.pgp
Description: OpenPGP digital signature

bug#31711: qutebrowser is broken

[Rutger Helling]

Hi Guix,

qutebrowser fails to start with the recent python-pyqt upgrade,
possibly due to the removed qtwebkit input.

The following error occurs:
---

Fatal error: QtWebEngine is required to run qutebrowser but could not
be imported! Maybe it's not installed?

The error encountered was:
No module named 'PyQt5.QtWebEngineWidgets'

Please search for the python3 version of QtWebEngine in your
distributions packages, or install it via pip.

Please search for the python3 version of QtWebEngine in your
distributions packages, or install it via pip.


pgpipamF7NiMx.pgp
Description: OpenPGP digital signature

bug#31841: ./pre-inst-env guix system no longer works without ~/.config/guix

[Rutger Helling]

I'm having the same problem. I think being able to run Guix entirely
from a git checkout is one of the best things about it and it's pretty
essential that we keep that possibility for people who want it.


pgptMVmZX8dv0.pgp
Description: OpenPGP digital signature

bug#31982: shaderc fails its test suite on all hydra-supported systems

[Rutger Helling]

Hi Mark,

unfortunately I don't really have the time to look at it in-depth now.
I've disabled the tests for now so I'm not blocking you. I'll take
another look at the tests after you've fixed 'meson-build-system.

On Tue, 26 Jun 2018 14:41:59 -0400
Mark H Weaver  wrote:

> Hi Rutger,
> 
> In commit 7f540654873a2761746bdc43be4727cad99b92c0, you updated
> 'sharerc' to upstream commit be8e087 and enabled tests.
> 
> It turns out that it fails its test suite on all systems supported by
> Hydra, but the failure is effectively being ignored, because of
> .
> 
> I'd like to fix 'meson-build-system' to always return #t from phases
> and to report errors using exceptions, which would effectively work
> around the aforementioned bug, but then that would cause 'shaderc' to
> start failing in earnest.
> 
> See  for more details.
> 
> Would you be willing to take a look and fix 'sharerc' so that it won't
> start failing when I fix 'meson-build-system'?
> 
>  Regards,
>Mark
> 
> 



pgp_I8ZjQ7b2c.pgp
Description: OpenPGP digital signature

bug#33325: xpra doesn't work out-of-the-box (implicit dependencies)

[Rutger Helling]

Hello Ludo,

Does the :100 server show up when you do 'xpra list' after the command?

If so, can you try the following commands to see if it works:
$ guix environment --ad-hoc xpra --pure -- xpra attach :100
And then on a different terminal:
$ DISPLAY=:100 gui-program

On Fri, 09 Nov 2018 15:12:25 +0100
ludovic.cour...@inria.fr (Ludovic Courtès) wrote:

> Hello Rutger and all,
> 
> Our Xpra package seems to not be usable directly without installing
> additional items:
> 
> --8<---cut here---start->8---
> $ guix environment --ad-hoc xpra --pure -- xpra start :100
> Warning: Xorg binary not found, assuming the wrapper is needed!
> Entering daemon mode; any further errors will be reported to:
>   /run/user/1000/xpra/:100.log
> $ cat /run/user/1000/xpra/:100.log
> 2018-11-09 14:37:42,986 Error: cannot enable SSH socket upgrades:
> 2018-11-09 14:37:42,986  No module named paramiko
> 2018-11-09 14:37:42,987 cannot access python uinput module:
> 2018-11-09 14:37:42,987  No module named uinput
> 2018-11-09 14:37:42,995 Error adding xauth entry for :100
> 2018-11-09 14:37:42,995  using command "xauth
> -f /home/ludo/.Xauthority add :100 MIT-MAGIC-COOKIE-1
> 7c2c66d9295545cfb1c27b1109b4b54e": [mi] Extension "Composite" is not
> recognized 2018-11-09 14:37:42,995  [Errno 2] No such file or
> directory [mi] Only the following extensions can be run-time enabled:
> [mi]Generic Event Extension [mi]MIT-SHM
> [mi]XTEST
> [mi]XINERAMA
> [mi]XFIXES
> [mi]RENDER
> [mi]RANDR
> [mi]COMPOSITE
> [mi]DAMAGE
> [mi]MIT-SCREEN-SAVER
> [mi]DOUBLE-BUFFER
> [mi]RECORD
> [mi]DPMS
> [mi]X-Resource
> [mi]XVideo
> [mi]XVideo-MotionCompensation
> [mi]GLX
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> --8<---cut here---end--->8---
> 
> On a foreign distro I see we’re also lacking a reference to
> ‘dbus-launch’:
> 
> --8<---cut here---start->8---
> [courtes@devel13 ~]$ guix environment --ad-hoc xpra --pure -- xpra
> start :100 Warning: Xorg binary not found, assuming the wrapper is
> needed! Entering daemon mode; any further errors will be reported to:
>   /run/user/10218/xpra/:100.log
> [courtes@devel13 ~]$ cat /run/user/10218/xpra/:100.log
> 2018-11-09 15:10:06,064 Error: cannot enable SSH socket upgrades:
> 2018-11-09 15:10:06,064  No module named paramiko
> 2018-11-09 15:10:06,066 cannot access python uinput module:
> 2018-11-09 15:10:06,066  No module named uinput
> 2018-11-09 15:10:06,079 Error adding xauth entry for :100
> 2018-11-09 15:10:06,080  using command "xauth
> -f /home/courtes/.Xauthority add :100 MIT-MAGIC-COOKIE-1
> 9519cb23f6a348eda7f068d9317a664c": 2018-11-09 15:10:06,080  [Errno 2]
> No such file or directory [mi] Extension "Composite" is not
> recognized [mi] Only the following extensions can be run-time
> enabled: [mi]Generic Event Extension [mi]MIT-SHM
> [mi]XTEST
> [mi]XINERAMA
> [mi]XFIXES
> [mi]RENDER
> [mi]RANDR
> [mi]COMPOSITE
> [mi]DAMAGE
> [mi]MIT-SCREEN-SAVER
> [mi]DOUBLE-BUFFER
> [mi]RECORD
> [mi]DPMS
> [mi]X-Resource
> [mi]XVideo
> [mi]XVideo-MotionCompensation
> [mi]GLX
> 2018-11-09 15:10:06,472 Warning: some of the sockets are in an
> unknown state: 2018-11-09
> 15:10:06,473  /home/courtes/.xpra/devel13-100 2018-11-09
> 15:10:06,473  please wait as we allow the socket probing to timeout
> 2018-11-09 15:10:12,502 created unix domain
> socket: /home/courtes/.xpra/devel13-100 
> /gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh:
> dbus-launch: command not found dbus-launch failed to start using
> command 'dbus-launch --close-stderr':
> 
>  exit code is 127
> 
> --8<---cut here---end--->8---
> 
> Thoughts?
> 
> Thanks in advance,
> Ludo’.



pgpgzKkPfSU89.pgp
Description: OpenPGP digital signature

bug#33325: xpra doesn't work out-of-the-box (implicit dependencies)

[Rutger Helling]

Hi Ludo,

apologies for the delayed reaction, I've been quite busy. Oddly enough
the commands seem to work fine on GuixSD. Can you maybe tell me what
distro you're using?

I don't have access to a foreign distro at the moment, but I'll try to
look into it next weekend.

Do you have the 'xauth' command? If not, could you install that and see
if it makes a difference?

On Sun, 25 Nov 2018 17:15:22 +0100
ludovic.cour...@inria.fr (Ludovic Courtès) wrote:

> Hello,
> 
> ludovic.cour...@inria.fr (Ludovic Courtès) skribis:
> 
> > $ guix environment --ad-hoc xpra --pure
> > [env]$ xpra start :100
> > Warning: Xorg binary not found, assuming the wrapper is needed!
> > ludo@ribbon ~/src/guix [env]$ Entering daemon mode; any further
> > errors will be reported to: /run/user/1000/xpra/:100.log
> >
> > [env]$ xpra list
> > Warning: Xorg binary not found, assuming the wrapper is needed!
> > No xpra sessions found  
> 
> FWIW I get the same problem with the recent xpra 2.4.2 update.
> 
> > I believe the problem should be reproducible in a ‘--pure’
> > environment. Perhaps the missing Python modules mentioned in the
> > log are the root cause?  
> 
> Thoughts?
> 
> Thanks in advance,
> Ludo’.



pgpmUSejA8poS.pgp
Description: OpenPGP digital signature

bug#33325: xpra doesn't work out-of-the-box (implicit dependencies)

[Rutger Helling]

So it should actually work in the container if you run the command xpra
upgrade, like so:

container$ xpra start :100 # wait a few seconds for it to start
container$ xpra upgrade :100
container$ xpra list

Just starting it in a container isn't terribly useful though since that
way you can't attach to it. If you run
guix environment --ad-hoc xpra -C --share=/tmp/.X11-unix
--share=/home/$USER/.xpra

and then start the server with the above commands you should be
able to attach to it outside of the container, like:
$ xpra attach :100
$ DISPLAY=:100 gui-program # on a different terminal

Does this work for you too?

I'm not sure why the 'xpra upgrade' command seems to be required in a
container. I have no idea how to fix that.

On Mon, 26 Nov 2018 10:00:37 +0100
ludovic.cour...@inria.fr (Ludovic Courtès) wrote:

> Hi Rutger,
> 
> Rutger Helling  skribis:
> 
> > apologies for the delayed reaction, I've been quite busy. Oddly
> > enough the commands seem to work fine on GuixSD. Can you maybe tell
> > me what distro you're using?  
> 
> I’m using GuixSD.  :-)
> 
> If we use ‘-C’ instead of ‘--pure’, we should both get the same
> result:
> 
> --8<---cut here---start->8---
> $ guix environment --ad-hoc xpra -C 
> [env]# xpra start :100
> Warning: Xorg binary not found, assuming the wrapper is needed!
> 
> Warning: running as root
> [env]# Entering daemon mode; any further errors will be reported to:
>   /tmp/:100.log
> 
> [env]# xpra list
> Warning: Xorg binary not found, assuming the wrapper is needed!
> 
> Warning: running as root
> Found the following xpra sessions:
> /home/ludo/.xpra:
> UNKNOWN session at :100
> Re-probing unknown sessions in: /home/ludo/.xpra
> 
> UNKNOWN session at :100 (cleaned up)
> [env]# 
> [env]# xpra list
> Warning: Xorg binary not found, assuming the wrapper is needed!
> 
> Warning: running as root
> No xpra sessions found
> --8<---cut here---end--->8---
> 
> Same for you?
> 
> Thanks for your feedback,
> Ludo’.



pgpkDZDK7fH8f.pgp
Description: OpenPGP digital signature

bug#33750: Virt-manager missing USB/PCI host device options

[Rutger Helling]

In virt-manager when clicking "Add hardware" on a VM the USB/PCI Host
Device boxes are greyed out with the message "Connection does not
support host device enumeration". It seems we're missing some
dependencies.


pgpB0Yvs2FE9b.pgp
Description: OpenPGP digital signature

bug#33750: Virt-manager missing USB/PCI host device options

[Rutger Helling]

Hi Chris,

Thanks for the tips, but I already knew how to work around it. The
point was more that it shouldn't be greyed out. I tried adding
libpciaccess to libvirt, unfortunately that alone didn't do the trick.

On Sat, 15 Dec 2018 20:46:39 -0800
Chris Marusich  wrote:

> Rutger Helling  writes:
> 
> > In virt-manager when clicking "Add hardware" on a VM the USB/PCI
> > Host Device boxes are greyed out with the message "Connection does
> > not support host device enumeration". It seems we're missing some
> > dependencies.  
> 
> I don't have the solution, but I might have a work-around or two.
> 
> FYI, even though I also observe the problem you describe, it's
> actually still possible to assign a PCI device to a VM by using
> virsh's "attach-device" command.  See "man virsh" for details.  This
> requires you to craft an XML file describing the device you wish to
> attach to your VM [1].
> 
> In addition, if your goal is just to pass a USB device through to the
> guest, you might try running virt-manager as root.  This has worked
> for me in the past.
> 
> Of course, we should continue to investigate the actual problem.  I
> only mention these work-arounds in the hopes that it helps you out.
> 
> Footnotes: 
> [1]  https://libvirt.org/formatdomain.html
> 



pgp1s3brtEGt9.pgp
Description: OpenPGP digital signature

bug#33750: Virt-manager missing USB/PCI host device options

[Rutger Helling]

Closing, fixed in d15211c9b5b46b96c5b658329624942b6ff5c917.

On Sat, 15 Dec 2018 20:46:39 -0800
Chris Marusich  wrote:

> Rutger Helling  writes:
> 
> > In virt-manager when clicking "Add hardware" on a VM the USB/PCI
> > Host Device boxes are greyed out with the message "Connection does
> > not support host device enumeration". It seems we're missing some
> > dependencies.  
> 
> I don't have the solution, but I might have a work-around or two.
> 
> FYI, even though I also observe the problem you describe, it's
> actually still possible to assign a PCI device to a VM by using
> virsh's "attach-device" command.  See "man virsh" for details.  This
> requires you to craft an XML file describing the device you wish to
> attach to your VM [1].
> 
> In addition, if your goal is just to pass a USB device through to the
> guest, you might try running virt-manager as root.  This has worked
> for me in the past.
> 
> Of course, we should continue to investigate the actual problem.  I
> only mention these work-arounds in the hopes that it helps you out.
> 
> Footnotes: 
> [1]  https://libvirt.org/formatdomain.html
> 



pgpVGg3A9Drao.pgp
Description: OpenPGP digital signature

bug#33962: guix pull fails on latest master

[Rutger Helling]

Sorry, that was sloppiness on my part. I built the package on my own
Guix that already had staging merged where apparently the
meson-build-system was already added to the modules.

I was about to revert but I just noticed it's already been fixed. I'll
double check if it builds on a clean master next time.

On Fri, 4 Jan 2019 01:24:22 +1100
Brendan Tildesley  wrote:

> 95bf2fb637ba4abb27efe94e0b671c1e93204e4f , which adds wl-clipboard
> fails to build because it references meson-build-system without
> importing the required module. I'm guessing adding  #:use-module
> (guix build-system meson)   ; would fix it.
> 
> I'm curious to know how this error was made.
> 



pgpZH5No26IUe.pgp
Description: OpenPGP digital signature

bug#38336: ‘wine64-staging’ is very expensive to build

[Rutger Helling]

Hi Ludo, 


Sorry for the late reply. I'm not really active anymore in Guix
development for various reasons. 


Wine needs a whole 32-bit dependency chain to be able to run both 32-bit
and 64-bit code, since a Wine that can only run 64-bit code is
considered useless. That is why the package is unfortunately so large. I
don't think there's anything that can be done about that. 


A couple of binaries are also copied, not just JSON files. That is where
the 32-bit dependencies come from. 


On 2019-11-23 00:12, Ludovic Courtès wrote:


Hello,

I noticed that 'wine64-staging' is our most expensive package to build.
Initially I was surprised because it only has a couple of nodes more in
its  object than 'wine-staging':

--8<---cut here---start->8---
ludo@ribbon ~/src/guix$ guix graph wine-staging |grep 'label = ' |wc -l
509
ludo@ribbon ~/src/guix$ guix graph wine64-staging |grep 'label = ' |wc -l
511
--8<---cut here---end--->8---

However, that single additional node leads to the duplication of the
whole derivation graph on x86_64-linux:

--8<---cut here---start->8---
ludo@ribbon ~/src/guix$ guix graph -t derivation wine-staging |grep 'label = ' 
|wc -l
2738
ludo@ribbon ~/src/guix$ guix graph -t derivation wine64-staging |grep 'label = 
' |wc -l
4598
--8<---cut here---end--->8---

This is because 'wine-staging' has a hard-coded '#:system "i686-linux"',
whereas 'wine64-staging' is (unsurprisingly :-)) built on x86_64-linux.

(The same problem happens with 'wine' vs. 'wine64'.)

Likewise, 'guix size wine64' shows that every dependency appears twice
(one 32-bit, one 64-bit), and thus the total size is twice that of
'wine'.

Rutger, is there something that can be done to avoid this?  Apparently
only JSON files are copied from 'wine-staging' into 'wine64-staging',
but maybe they refer to 32-bit shared libraries or something?

Thanks,
Ludo'.