GNU bug report logs - #40650
guix test suite failures building Debian package

Previous Next

To reply to this bug, email your comments to 40650 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: bug-guix <at> gnu.org
Subject: guix test suite failures building Debian package
Date: Wed, 15 Apr 2020 15:03:21 -0700

[Message part 1 (text/plain, inline)]

I almost always get some test suite failures when building the Debian
package of guix:

  https://salsa.debian.org/vagrant/guix

Any of the test suites that require networking will need to be disabled
for Debian packages.

One thing that occurs to me is Debian systems have USER_NS_UNPRIVLEDGED
disabled by default (enableable at run-time with
/proc/sys/kernel/unprivileged_userns_clone).

Attached is the test-suite.log, as requested.

I also have copied the tests/*.log and full build log, if those are useful.


live well,
  vagrant

[test-suite.log (application/octet-stream, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: Re: bug#40650: guix test suite failures building Debian package
Date: Thu, 16 Apr 2020 10:40:33 +0200

Hi Vagrant,

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> Any of the test suites that require networking will need to be disabled
> for Debian packages.

That should be fine.

> One thing that occurs to me is Debian systems have USER_NS_UNPRIVLEDGED
> disabled by default (enableable at run-time with
> /proc/sys/kernel/unprivileged_userns_clone).

That should be fine too: tests that rely on unprivileged user namespaces
are skipped when that’s missing.

> Attached is the test-suite.log, as requested.

Excellent!

> test-name: wrap-program, one input, multiple calls
> location: /build/guix-jgTHmh/guix-1.1.0/tests/build-utils.scm:94
> source:
> + (test-equal
> +   "wrap-program, one input, multiple calls"
> +   "hello world\n"
> +   (call-with-temporary-directory
> +     (lambda (directory)
> +       (let ((bash (search-bootstrap-binary
> +                     "bash"
> +                     (%current-system)))
> +             (foo (string-append directory "/foo")))
> +         (call-with-output-file
> +           foo
> +           (lambda (p)
> +             (format
> +               p
> +               "#!~a~%echo \"${GUIX_FOO} ${GUIX_BAR}\"~%"
> +               bash)))
> +         (chmod foo 511)
> +         (with-environment-variable
> +           "PATH"
> +           (dirname bash)
> +           (wrap-program foo `("GUIX_FOO" prefix ("hello")))
> +           (wrap-program foo `("GUIX_BAR" prefix ("world")))
> +           (unsetenv "LOCPATH")
> +           (let* ((pipe (open-input-pipe foo))
> +                  (str (get-string-all pipe)))
> +             (with-directory-excursion
> +               directory
> +               (for-each delete-file '("foo" ".foo-real")))
> +             (and (zero? (close-pipe pipe)) str)))))))
> expected-value: "hello world\n"
> actual-value: #f
> actual-error:
> + (system-error
> +   "copy-file"
> +   "~A: ~S"
> +   ("Permission denied"
> +    "/build/guix-jgTHmh/guix-1.1.0/gnu/packages/bootstrap/i686-linux/bash")
> +   (13))
> result: FAIL

Here’s it’s ‘search-bootstrap-binary’ from (guix tests) that tries to
create the file above, having downloaded it earlier.

For the ‘guix’ package in Guix, what we do is that this and related
files are inputs to the package; that way, they are not downloaded at
all upon ‘make check’ since they’re already there.

All you need is to ensure that
gnu/packages/bootstrap/*-linux/{bash,mkdir,tar,xz} exist, are
executable, and are statically-linked.  You could provide Debian
binaries if that’s more appropriate.

> test-name: channel-instances->manifest
> location: /build/guix-jgTHmh/guix-1.1.0/tests/channels.scm:177

[...]

> +                Initialized empty Git repository in /tmp/guix-directory.kYfBE0/.git/
>
> *** Please tell me who you are.
>
> Run
>
>   git config --global user.email "you <at> example.com"
>   git config --global user.name "Your Name"
>
> to set your account's default identity.
> Omit --global to set the identity only in this repository.
>
> fatal: unable to auto-detect email address (got 'vagrant <at> yucca.(none)')

We may need to provide a dummy .gitconfig file or something here so we
can run these tests.  See also <https://issues.guix.gnu.org/issue/37679>.
(The same applies to several test failures.)

Thoughts?

> test-name: scandir*, properties
> location: /build/guix-jgTHmh/guix-1.1.0/tests/syscalls.scm:257
> source:
> + (test-assert
> +   "scandir*, properties"
> +   (let ((directory
> +           (dirname
> +             (search-path %load-path "guix/base32.scm"))))
> +     (every (lambda (entry name)
> +              (match entry
> +                     ((name2 . properties)
> +                      (and (string=? name2 name)
> +                           (let* ((full (string-append directory "/" name))
> +                                  (stat (lstat full))
> +                                  (inode (assoc-ref properties 'inode))
> +                                  (type (assoc-ref properties 'type)))
> +                             (and (= inode (stat:ino stat))
> +                                  (or (eq? type 'unknown)
> +                                      (eq? type (stat:type stat)))))))))
> +            (scandir* directory)
> +            (scandir directory (const #t) string<?))))
> actual-value: #f
> result: FAIL

Could you wrap the ‘scandir*’ and ‘scandir’ calls in ‘pk’, run:

  make check TESTS=tests/syscalls.scm

and send ‘test-suite.log’?

> ++ guix build guile-gcrypt --with-branch=guile-gcrypt=master -d
> accepted connection from pid 17231, user vagrant
> updating checkout of 'https://notabug.org/cwebber/guile-gcrypt.git'...
> guix build: error: cannot fetch branch 'master' from https://notabug.org/cwebber/guile-gcrypt.git: the SSL certificate is invalid: 0x08 - The certificate is not correctly signed by the trusted CA
> + latest_drv=
> FAIL tests/guix-build-branch.sh (exit status: 1)

This test relies on network access + HTTPS certificates.  It does check
for the former but not the latter.  Any suggestions on how to do that?

Thanks,
Ludo’.

Message #11 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: Re: bug#40650: guix test suite failures building Debian package
Date: Thu, 16 Apr 2020 10:23:57 -0700

[Message part 1 (text/plain, inline)]

Thanks for the quick response!

On 2020-04-16, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>
>> Any of the test suites that require networking will need to be disabled
>> for Debian packages.
>
> That should be fine.

Well, they need to be disabled even if networking is available...

We might be able to make some of them "autopackagetests" ... e.g. tests
that are run as part of Debian's CI infrastructure on the installed
packages (as opposed to tests run from within the source tree).


>> test-name: wrap-program, one input, multiple calls
>> location: /build/guix-jgTHmh/guix-1.1.0/tests/build-utils.scm:94
>> source:
>> + (test-equal
>> +   "wrap-program, one input, multiple calls"
>> +   "hello world\n"
>> +   (call-with-temporary-directory
>> +     (lambda (directory)
>> +       (let ((bash (search-bootstrap-binary
>> +                     "bash"
>> +                     (%current-system)))
>> +             (foo (string-append directory "/foo")))
>> +         (call-with-output-file
>> +           foo
>> +           (lambda (p)
>> +             (format
>> +               p
>> +               "#!~a~%echo \"${GUIX_FOO} ${GUIX_BAR}\"~%"
>> +               bash)))
>> +         (chmod foo 511)
>> +         (with-environment-variable
>> +           "PATH"
>> +           (dirname bash)
>> +           (wrap-program foo `("GUIX_FOO" prefix ("hello")))
>> +           (wrap-program foo `("GUIX_BAR" prefix ("world")))
>> +           (unsetenv "LOCPATH")
>> +           (let* ((pipe (open-input-pipe foo))
>> +                  (str (get-string-all pipe)))
>> +             (with-directory-excursion
>> +               directory
>> +               (for-each delete-file '("foo" ".foo-real")))
>> +             (and (zero? (close-pipe pipe)) str)))))))
>> expected-value: "hello world\n"
>> actual-value: #f
>> actual-error:
>> + (system-error
>> +   "copy-file"
>> +   "~A: ~S"
>> +   ("Permission denied"
>> +    "/build/guix-jgTHmh/guix-1.1.0/gnu/packages/bootstrap/i686-linux/bash")
>> +   (13))
>> result: FAIL
>
> Here’s it’s ‘search-bootstrap-binary’ from (guix tests) that tries to
> create the file above, having downloaded it earlier.
>
> For the ‘guix’ package in Guix, what we do is that this and related
> files are inputs to the package; that way, they are not downloaded at
> all upon ‘make check’ since they’re already there.
>
> All you need is to ensure that
> gnu/packages/bootstrap/*-linux/{bash,mkdir,tar,xz} exist, are
> executable, and are statically-linked.  You could provide Debian
> binaries if that’s more appropriate.

Regarding providing Debian binaries, I could Build-Depend (the debian
equivalent of "inputs") on bash-static and symlink to that, and maybe
use busybox-static and symlinks for mkdir and tar, but I don't think
there's a static implementation of xz in Debian.

Do they strictly need to be statically linked? These are just for test
suites, not actually used in the eventual packaged guix?

I notice it's also checking for i686-linux/bash above even though the
build was done on amd64/x86_64 ... and it would be non-trivial to enable
cross-architecture checks for all architectures across all of Debian's
architectures.


>> test-name: channel-instances->manifest
>> location: /build/guix-jgTHmh/guix-1.1.0/tests/channels.scm:177
>
> [...]
>
>> +                Initialized empty Git repository in /tmp/guix-directory.kYfBE0/.git/
>>
>> *** Please tell me who you are.
>>
>> Run
>>
>>   git config --global user.email "you <at> example.com"
>>   git config --global user.name "Your Name"
>>
>> to set your account's default identity.
>> Omit --global to set the identity only in this repository.
>>
>> fatal: unable to auto-detect email address (got 'vagrant <at> yucca.(none)')
>
> We may need to provide a dummy .gitconfig file or something here so we
> can run these tests.  See also <https://issues.guix.gnu.org/issue/37679>.
> (The same applies to several test failures.)
>
> Thoughts?

I could try a couple things ... basically re-implement the patch from
#37679 in Debian's packaging (e.g. HOME=/some/path and populate
$HOME/.gitconfig), or apply the patch and try it. :)


>> test-name: scandir*, properties
>> location: /build/guix-jgTHmh/guix-1.1.0/tests/syscalls.scm:257
>> source:
>> + (test-assert
>> +   "scandir*, properties"
>> +   (let ((directory
>> +           (dirname
>> +             (search-path %load-path "guix/base32.scm"))))
>> +     (every (lambda (entry name)
>> +              (match entry
>> +                     ((name2 . properties)
>> +                      (and (string=? name2 name)
>> +                           (let* ((full (string-append directory "/" name))
>> +                                  (stat (lstat full))
>> +                                  (inode (assoc-ref properties 'inode))
>> +                                  (type (assoc-ref properties 'type)))
>> +                             (and (= inode (stat:ino stat))
>> +                                  (or (eq? type 'unknown)
>> +                                      (eq? type (stat:type stat)))))))))
>> +            (scandir* directory)
>> +            (scandir directory (const #t) string<?))))
>> actual-value: #f
>> result: FAIL
>
> Could you wrap the ‘scandir*’ and ‘scandir’ calls in ‘pk’, run:

like this?
                (pk (scandir* directory))
                (pk (scandir directory (const #t) string<?)))))


>   make check TESTS=tests/syscalls.scm
>
> and send ‘test-suite.log’?

It's a bit expensive for me to do a build for just this test, but I can
patch it and it should still get included in the full test-suite.log,
yes?

I guess it might make sense to do a build from a chroot manually to
debug some of these test suite issues, but I usually just do a full
package build to make sure I didn't manually tweak something without
remembering what it was later...


>> ++ guix build guile-gcrypt --with-branch=guile-gcrypt=master -d
>> accepted connection from pid 17231, user vagrant
>> updating checkout of 'https://notabug.org/cwebber/guile-gcrypt.git'...
>> guix build: error: cannot fetch branch 'master' from https://notabug.org/cwebber/guile-gcrypt.git: the SSL certificate is invalid: 0x08 - The certificate is not correctly signed by the trusted CA
>> + latest_drv=
>> FAIL tests/guix-build-branch.sh (exit status: 1)
>
> This test relies on network access + HTTPS certificates.  It does check
> for the former but not the latter.  Any suggestions on how to do that?

This might be a candidate for "autopackagetests" described earlier.

Alternately/Additionally, ship or create a git repository from the
source tree, run git daemon on a random free port, and try it there.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: Re: bug#40650: guix test suite failures building Debian package
Date: Fri, 17 Apr 2020 10:50:31 +0200

Hi Vagrant,

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> On 2020-04-16, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>>
>>> Any of the test suites that require networking will need to be disabled
>>> for Debian packages.
>>
>> That should be fine.
>
> Well, they need to be disabled even if networking is available...

Would it be an option for you to run:

  unshare -Un make check

or similar?

If not we would need to identify all the places that check for
networking and replace them with a constant.  For tests/*.scm, you can
change ‘network-reachable?’ to return #f.  For tests/*.sh, you have to
grep/sed for ‘getaddrinfo’.

>> Here’s it’s ‘search-bootstrap-binary’ from (guix tests) that tries to
>> create the file above, having downloaded it earlier.
>>
>> For the ‘guix’ package in Guix, what we do is that this and related
>> files are inputs to the package; that way, they are not downloaded at
>> all upon ‘make check’ since they’re already there.
>>
>> All you need is to ensure that
>> gnu/packages/bootstrap/*-linux/{bash,mkdir,tar,xz} exist, are
>> executable, and are statically-linked.  You could provide Debian
>> binaries if that’s more appropriate.
>
> Regarding providing Debian binaries, I could Build-Depend (the debian
> equivalent of "inputs") on bash-static and symlink to that, and maybe
> use busybox-static and symlinks for mkdir and tar, but I don't think
> there's a static implementation of xz in Debian.
>
> Do they strictly need to be statically linked? These are just for test
> suites, not actually used in the eventual packaged guix?

Actually no, it would also work with dynamically-linked binaries since
we’re not doing chroot builds.

So you could copy (not symlink) binaries from Debian, even simply those
that happen to be in /bin.

> I notice it's also checking for i686-linux/bash above even though the
> build was done on amd64/x86_64 ... and it would be non-trivial to enable
> cross-architecture checks for all architectures across all of Debian's
> architectures.

It’s simply that we use i686 binaries on x86_64.

At any rate, you’ll restrict the package to the subset of architectures
that Guix supports, right?

>> We may need to provide a dummy .gitconfig file or something here so we
>> can run these tests.  See also <https://issues.guix.gnu.org/issue/37679>.
>> (The same applies to several test failures.)
>>
>> Thoughts?
>
> I could try a couple things ... basically re-implement the patch from
> #37679 in Debian's packaging (e.g. HOME=/some/path and populate
> $HOME/.gitconfig), or apply the patch and try it. :)

Yeah, let’s do something about it.  :-)

>>> test-name: scandir*, properties
>>> location: /build/guix-jgTHmh/guix-1.1.0/tests/syscalls.scm:257
>>> source:
>>> + (test-assert
>>> +   "scandir*, properties"
>>> +   (let ((directory
>>> +           (dirname
>>> +             (search-path %load-path "guix/base32.scm"))))
>>> +     (every (lambda (entry name)
>>> +              (match entry
>>> +                     ((name2 . properties)
>>> +                      (and (string=? name2 name)
>>> +                           (let* ((full (string-append directory "/" name))
>>> +                                  (stat (lstat full))
>>> +                                  (inode (assoc-ref properties 'inode))
>>> +                                  (type (assoc-ref properties 'type)))
>>> +                             (and (= inode (stat:ino stat))
>>> +                                  (or (eq? type 'unknown)
>>> +                                      (eq? type (stat:type stat)))))))))
>>> +            (scandir* directory)
>>> +            (scandir directory (const #t) string<?))))
>>> actual-value: #f
>>> result: FAIL
>>
>> Could you wrap the ‘scandir*’ and ‘scandir’ calls in ‘pk’, run:
>
> like this?
>                 (pk (scandir* directory))
>                 (pk (scandir directory (const #t) string<?)))))

Yes.

>>   make check TESTS=tests/syscalls.scm
>>
>> and send ‘test-suite.log’?
>
> It's a bit expensive for me to do a build for just this test, but I can
> patch it and it should still get included in the full test-suite.log,
> yes?

Yes.

> I guess it might make sense to do a build from a chroot manually to
> debug some of these test suite issues, but I usually just do a full
> package build to make sure I didn't manually tweak something without
> remembering what it was later...

Perhaps it’s reproducible in a “regular” Debian environment?

>>> ++ guix build guile-gcrypt --with-branch=guile-gcrypt=master -d
>>> accepted connection from pid 17231, user vagrant
>>> updating checkout of 'https://notabug.org/cwebber/guile-gcrypt.git'...
>>> guix build: error: cannot fetch branch 'master' from https://notabug.org/cwebber/guile-gcrypt.git: the SSL certificate is invalid: 0x08 - The certificate is not correctly signed by the trusted CA
>>> + latest_drv=
>>> FAIL tests/guix-build-branch.sh (exit status: 1)
>>
>> This test relies on network access + HTTPS certificates.  It does check
>> for the former but not the latter.  Any suggestions on how to do that?
>
> This might be a candidate for "autopackagetests" described earlier.
>
> Alternately/Additionally, ship or create a git repository from the
> source tree, run git daemon on a random free port, and try it there.

Uh, that would be better… I’d gladly accept patches.  :-)

Thanks for your feedback!  Hopefully we can easily address the remaining issues.

Ludo’.

Message #17 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: Re: bug#40650: guix test suite failures building Debian package
Date: Fri, 17 Apr 2020 15:13:41 -0700

[Message part 1 (text/plain, inline)]

With a few patches/workarounds applied, we got better results overall:

  # TOTAL: 1011
  # PASS:  954 (was 950)
  # SKIP:  51
  # XFAIL: 2
  # FAIL:  4 (was 8)

FAIL: tests/gexp
FAIL: tests/size
FAIL: tests/syscalls
FAIL: tests/guix-build-branch

This time tests/build-utils, tests/channels and
tests/git all passed!

Seems tests/gexp and tests/size are new failures? Maybe revealed by
fixing other issues.

Not sure how that math works out... went from 8 failures to 4, but I see
3 fixed and two added?

More details below and full test-suite.log attached for more meaningful
analysis.


On 2020-04-17, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>> On 2020-04-16, Ludovic Courtès wrote:
>>> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>>>> Any of the test suites that require networking will need to be disabled
>>>> for Debian packages.
>>>
>>> That should be fine.
>>
>> Well, they need to be disabled even if networking is available...
>
> Would it be an option for you to run:
>
>   unshare -Un make check
>
> or similar?

Not sure; will look into it.


> If not we would need to identify all the places that check for
> networking and replace them with a constant.  For tests/*.scm, you can
> change ‘network-reachable?’ to return #f.  For tests/*.sh, you have to
> grep/sed for ‘getaddrinfo’.

This certainly sounds more explicit... :)



>>> Here’s it’s ‘search-bootstrap-binary’ from (guix tests) that tries to
>>> create the file above, having downloaded it earlier.
>>>
>>> For the ‘guix’ package in Guix, what we do is that this and related
>>> files are inputs to the package; that way, they are not downloaded at
>>> all upon ‘make check’ since they’re already there.
>>>
>>> All you need is to ensure that
>>> gnu/packages/bootstrap/*-linux/{bash,mkdir,tar,xz} exist, are
>>> executable, and are statically-linked.  You could provide Debian
>>> binaries if that’s more appropriate.
>>
>> Regarding providing Debian binaries, I could Build-Depend (the debian
>> equivalent of "inputs") on bash-static and symlink to that, and maybe
>> use busybox-static and symlinks for mkdir and tar, but I don't think
>> there's a static implementation of xz in Debian.
>>
>> Do they strictly need to be statically linked? These are just for test
>> suites, not actually used in the eventual packaged guix?
>
> Actually no, it would also work with dynamically-linked binaries since
> we’re not doing chroot builds.
>
> So you could copy (not symlink) binaries from Debian, even simply those
> that happen to be in /bin.
>
>> I notice it's also checking for i686-linux/bash above even though the
>> build was done on amd64/x86_64 ... and it would be non-trivial to enable
>> cross-architecture checks for all architectures across all of Debian's
>> architectures.
>
> It’s simply that we use i686 binaries on x86_64.

So, copying the system /bin/bash, /bin/mkdir, /bin/tar and /usr/bin/xz
into gnu/packages/bootstrap/i686-linux/ seems to have passed the test.


> At any rate, you’ll restrict the package to the subset of architectures
> that Guix supports, right?

In Debian the norm is to assume it *might* build on any architecture,
and only restrict it if it's impossible for it to ever build for some
theoretical reason, or some other practical reason. That it doesn't yet
build on a particular architecture is generally fine.

So my intention was to let it try to build on any architecture...
Consider it outreach to the Debian porter community!


>>> We may need to provide a dummy .gitconfig file or something here so we
>>> can run these tests.  See also <https://issues.guix.gnu.org/issue/37679>.
>>> (The same applies to several test failures.)
>>>
>>> Thoughts?
>>
>> I could try a couple things ... basically re-implement the patch from
>> #37679 in Debian's packaging (e.g. HOME=/some/path and populate
>> $HOME/.gitconfig), or apply the patch and try it. :)
>
> Yeah, let’s do something about it.  :-)

I tried the patch in the mentioned bug, and it seems to have worked!


>>>> test-name: scandir*, properties
>>>> location: /build/guix-jgTHmh/guix-1.1.0/tests/syscalls.scm:257
>>>> source:
>>>> + (test-assert
>>>> +   "scandir*, properties"
>>>> +   (let ((directory
>>>> +           (dirname
>>>> +             (search-path %load-path "guix/base32.scm"))))
>>>> +     (every (lambda (entry name)
>>>> +              (match entry
>>>> +                     ((name2 . properties)
>>>> +                      (and (string=? name2 name)
>>>> +                           (let* ((full (string-append directory "/" name))
>>>> +                                  (stat (lstat full))
>>>> +                                  (inode (assoc-ref properties 'inode))
>>>> +                                  (type (assoc-ref properties 'type)))
>>>> +                             (and (= inode (stat:ino stat))
>>>> +                                  (or (eq? type 'unknown)
>>>> +                                      (eq? type (stat:type stat)))))))))
>>>> +            (scandir* directory)
>>>> +            (scandir directory (const #t) string<?))))
>>>> actual-value: #f
>>>> result: FAIL
>>>
>>> Could you wrap the ‘scandir*’ and ‘scandir’ calls in ‘pk’, run:
>>
>> like this?
>>                 (pk (scandir* directory))
>>                 (pk (scandir directory (const #t) string<?)))))
>
> Yes.

Patched and test-suite.log attached.


>>>> ++ guix build guile-gcrypt --with-branch=guile-gcrypt=master -d
>>>> accepted connection from pid 17231, user vagrant
>>>> updating checkout of 'https://notabug.org/cwebber/guile-gcrypt.git'...
>>>> guix build: error: cannot fetch branch 'master' from https://notabug.org/cwebber/guile-gcrypt.git: the SSL certificate is invalid: 0x08 - The certificate is not correctly signed by the trusted CA
>>>> + latest_drv=
>>>> FAIL tests/guix-build-branch.sh (exit status: 1)
>>>
>>> This test relies on network access + HTTPS certificates.  It does check
>>> for the former but not the latter.  Any suggestions on how to do that?
>>
>> This might be a candidate for "autopackagetests" described earlier.
>>
>> Alternately/Additionally, ship or create a git repository from the
>> source tree, run git daemon on a random free port, and try it there.
>
> Uh, that would be better… I’d gladly accept patches.  :-)

We'll see...


> Thanks for your feedback!  Hopefully we can easily address the
> remaining issues.

Yeah, it was nice to see fixes already on the second attempt!


live well,
  vagrant

[test-suite.log (application/octet-stream, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: ‘scandir*’ test failure
Date: Sat, 18 Apr 2020 21:53:48 +0200

Hey,

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> test-name: scandir*, properties
> location: /build/guix-YPdZIs/guix-1.1.0/tests/syscalls.scm:257
> source:
> + (test-assert
> +   "scandir*, properties"
> +   (let ((directory
> +           (dirname
> +             (search-path %load-path "guix/base32.scm"))))
> +     (every (lambda (entry name)
> +              (match entry
> +                     ((name2 . properties)
> +                      (and (string=? name2 name)
> +                           (let* ((full (string-append directory "/" name))
> +                                  (stat (lstat full))
> +                                  (inode (assoc-ref properties 'inode))
> +                                  (type (assoc-ref properties 'type)))
> +                             (and (= inode (stat:ino stat))
> +                                  (or (eq? type 'unknown)
> +                                      (eq? type (stat:type stat)))))))))
> +            (pk (scandir* directory))
> +            (pk (scandir directory (const #t) string<?)))))
>
> ;;; ((("." (type . directory) (inode . 656899)) (".." (type . directory) (inode . 655381)) ("base16.go" (type . regular) (inode . 673193)) ("base16.scm" (type . regular) (inode . 656947)) ("base32.go" (type . regular) (inode . 674231)) ("base32.scm" (type . regular) (inode . 656911)) ("base64.go" (type . regular) (inode . 675116)) ("base64.scm" (type . regular) (inode . 657151)) ("build" (type . directory) (inode . 657319)) ("build-system" (type . directory) (inode . 657157)) ("build-system.go" (type . regular) (inode . 673229)) ("build-system.scm" (type . regular) (inode . 656914)) ("bzr-download.go" (type . regular) (inode . 674252)) ("bzr-download.scm" (type . regular) (inode . 656932)) ("cache.go" (type . regular) (inode . 673222)) ("cache.scm" (type . regular) (inode . 657532)) ("channels.go" (type . regular) (inode . 675153)) ("channels.scm" (type . regular) (inode . 657499)) ("ci.go" (type . regular) (inode . 674235)) ("ci.scm" (type . regular) (inode . 657298)) ("colors.go" (type . regular) (inode . 673271)) ("colors.scm" (type . regular) (inode . 656965)) ("combinators.go" (type . regular) (inode . 675122)) ("combinators.scm" (type . regular) (inode . 656926)) ("config.go" (type . regular) (inode . 676566)) ("config.scm" (type . regular) (inode . 675006)) ("config.scm.in" (type . regular) (inode . 657505)) ("cpio.go" (type . regular) (inode . 675880)) ("cpio.scm" (type . regular) (inode . 656935)) ("cve.go" (type . regular) (inode . 675915)) ("cve.scm" (type . regular) (inode . 657295)) ("cvs-download.go" (type . regular) (inode . 674303)) ("cvs-download.scm" (type . regular) (inode . 657265)) ("deprecation.go" (type . regular) (inode . 674238)) ("deprecation.scm" (type . regular) (inode . 656962)) ("derivations.go" (type . regular) (inode . 675143)) ("derivations.scm" (type . regular) (inode . 657544)) ("describe.go" (type . regular) (inode . 675149)) ("describe.scm" (type . regular) (inode . 656908)) ("diagnostics.go" (type . regular) (inode . 675214)) ("diagnostics.scm" (type . regular) (inode . 656902)) ("discovery.go" (type . regular) (inode . 675897)) ("discovery.scm" (type . regular) (inode . 656971)) ("docker.go" (type . regular) (inode . 673196)) ("docker.scm" (type . regular) (inode . 656968)) ("download.go" (type . regular) (inode . 675127)) ("download.scm" (type . regular) (inode . 657310)) ("elf.go" (type . regular) (inode . 673265)) ("elf.scm" (type . regular) (inode . 657301)) ("ftp-client.go" (type . regular) (inode . 674297)) ("ftp-client.scm" (type . regular) (inode . 657538)) ("gexp.go" (type . regular) (inode . 673203)) ("gexp.scm" (type . regular) (inode . 656941)) ("git-download.go" (type . regular) (inode . 674255)) ("git-download.scm" (type . regular) (inode . 657316)) ("git.go" (type . regular) (inode . 673219)) ("git.scm" (type . regular) (inode . 656905)) ("glob.go" (type . regular) (inode . 673216)) ("glob.scm" (type . regular) (inode . 656929)) ("gnu-maintenance.go" (type . regular) (inode . 673210)) ("gnu-maintenance.scm" (type . regular) (inode . 657517)) ("gnupg.go" (type . regular) (inode . 675940)) ("gnupg.scm" (type . regular) (inode . 657292)) ("grafts.go" (type . regular) (inode . 674258)) ("grafts.scm" (type . regular) (inode . 657520)) ("graph.go" (type . regular) (inode . 675175)) ("graph.scm" (type . regular) (inode . 656917)) ("hg-download.go" (type . regular) (inode . 675900)) ("hg-download.scm" (type . regular) (inode . 657508)) ("http-client.go" (type . regular) (inode . 674300)) ("http-client.scm" (type . regular) (inode . 657526)) ("i18n.go" (type . regular) (inode . 675211)) ("i18n.scm" (type . regular) (inode . 657268)) ("import" (type . directory) (inode . 657574)) ("inferior.go" (type . regular) (inode . 675146)) ("inferior.scm" (type . regular) (inode . 657523)) ("json.go" (type . regular) (inode . 675883)) ("json.scm" (type . regular) (inode . 657145)) ("licenses.go" (type . regular) (inode . 673213)) ("licenses.scm" (type . regular) (inode . 657502)) ("lint.go" (type . regular) (inode . 675912)) ("lint.scm" (type . regular) (inode . 657277)) ("lzlib.go" (type . regular) (inode . 674267)) ("lzlib.scm" (type . regular) (inode . 656923)) ("man-db.scm" (type . regular) (inode . 657280)) ("memoization.go" (type . regular) (inode . 675889)) ("memoization.scm" (type . regular) (inode . 656956)) ("modules.go" (type . regular) (inode . 674249)) ("modules.scm" (type . regular) (inode . 657541)) ("monad-repl.go" (type . regular) (inode . 675903)) ("monad-repl.scm" (type . regular) (inode . 657529)) ("monads.go" (type . regular) (inode . 673200)) ("monads.scm" (type . regular) (inode . 657547)) ("nar.go" (type . regular) (inode . 675906)) ("nar.scm" (type . regular) (inode . 656977)) ("packages.go" (type . regular) (inode . 675997)) ("packages.scm" (type . regular) (inode . 657289)) ("pki.go" (type . regular) (inode . 674242)) ("pki.scm" (type . regular) (inode . 657571)) ("profiles.go" (type . regular) (inode . 675139)) ("profiles.scm" (type . regular) (inode . 657514)) ("profiling.go" (type . regular) (inode . 675943)) ("profiling.scm" (type . regular) (inode . 657274)) ("progress.go" (type . regular) (inode . 675886)) ("progress.scm" (type . regular) (inode . 657283)) ("records.go" (type . regular) (inode . 675119)) ("records.scm" (type . regular) (inode . 657313)) ("remote.scm" (type . regular) (inode . 657154)) ("repl.go" (type . regular) (inode . 674262)) ("repl.scm" (type . regular) (inode . 656938)) ("scripts" (type . directory) (inode . 656983)) ("scripts.go" (type . regular) (inode . 674383)) ("scripts.scm" (type . regular) (inode . 657271)) ("search-paths.go" (type . regular) (inode . 674352)) ("search-paths.scm" (type . regular) (inode . 656944)) ("self.go" (type . regular) (inode . 675167)) ("self.scm" (type . regular) (inode . 656920)) ("serialization.go" (type . regular) (inode . 673206)) ("serialization.scm" (type . regular) (inode . 657535)) ("sets.go" (type . regular) (inode . 674246)) ("sets.scm" (type . regular) (inode . 656953)) ("ssh.scm" (type . regular) (inode . 656980)) ("status.go" (type . regular) (inode . 674311)) ("status.scm" (type . regular) (inode . 657307)) ("store" (type . directory) (inode . 657553)) ("store.go" (type . regular) (inode . 673268)) ("store.scm" (type . regular) (inode . 657550)) ("svn-download.go" (type . regular) (inode . 675208)) ("svn-download.scm" (type . regular) (inode . 656974)) ("swh.go" (type . regular) (inode . 675130)) ("swh.scm" (type . regular) (inode . 657148)) ("tests" (type . directory) (inode . 657256)) ("tests.go" (type . regular) (inode . 676569)) ("tests.scm" (type . regular) (inode . 656950)) ("ui.go" (type . regular) (inode . 674307)) ("ui.scm" (type . regular) (inode . 657304)) ("upstream.go" (type . regular) (inode . 675171)) ("upstream.scm" (type . regular) (inode . 657286)) ("utils.go" (type . regular) (inode . 675892)) ("utils.scm" (type . regular) (inode . 657511)) ("workers.go" (type . regular) (inode . 673225)) ("workers.scm" (type . regular) (inode . 656959)) ("zlib.go" (type . regular) (inode . 675918)) ("zlib.scm" (type . regular) (inode . 657637))))
>
> ;;; (("." ".." "base16.go" "base16.scm" "base32.go" "base32.scm" "base64.go" "base64.scm" "build" "build-system" "build-system.go" "build-system.scm" "bzr-download.go" "bzr-download.scm" "cache.go" "cache.scm" "channels.go" "channels.scm" "ci.go" "ci.scm" "colors.go" "colors.scm" "combinators.go" "combinators.scm" "config.go" "config.scm" "config.scm.in" "cpio.go" "cpio.scm" "cve.go" "cve.scm" "cvs-download.go" "cvs-download.scm" "deprecation.go" "deprecation.scm" "derivations.go" "derivations.scm" "describe.go" "describe.scm" "diagnostics.go" "diagnostics.scm" "discovery.go" "discovery.scm" "docker.go" "docker.scm" "download.go" "download.scm" "elf.go" "elf.scm" "ftp-client.go" "ftp-client.scm" "gexp.go" "gexp.scm" "git-download.go" "git-download.scm" "git.go" "git.scm" "glob.go" "glob.scm" "gnu-maintenance.go" "gnu-maintenance.scm" "gnupg.go" "gnupg.scm" "grafts.go" "grafts.scm" "graph.go" "graph.scm" "hg-download.go" "hg-download.scm" "http-client.go" "http-client.scm" "i18n.go" "i18n.scm" "import" "inferior.go" "inferior.scm" "json.go" "json.scm" "licenses.go" "licenses.scm" "lint.go" "lint.scm" "lzlib.go" "lzlib.scm" "man-db.scm" "memoization.go" "memoization.scm" "modules.go" "modules.scm" "monad-repl.go" "monad-repl.scm" "monads.go" "monads.scm" "nar.go" "nar.scm" "packages.go" "packages.scm" "pki.go" "pki.scm" "profiles.go" "profiles.scm" "profiling.go" "profiling.scm" "progress.go" "progress.scm" "records.go" "records.scm" "remote.scm" "repl.go" "repl.scm" "scripts" "scripts.go" "scripts.scm" "search-paths.go" "search-paths.scm" "self.go" "self.scm" "serialization.go" "serialization.scm" "sets.go" "sets.scm" "ssh.scm" "status.go" "status.scm" "store" "store.go" "store.scm" "svn-download.go" "svn-download.scm" "swh.go" "swh.scm" "tests" "tests.go" "tests.scm" "ui.go" "ui.scm" "upstream.go" "upstream.scm" "utils.go" "utils.scm" "workers.go" "workers.scm" "zlib.go" "zlib.scm"))
> actual-value: #f
> result: FAIL

Looking at this test, the only way ‘every’ could return #f is (1) if
‘lstat’ returns a different inode number, or (2) if ‘lstat’ returns a
different file type than the one for ‘scandir*’.

Unfortunately it’s hard to tell more without debugging interactively on
the machine, adding ‘pk’ calls here and there to see.

Can you reproduce this test failure in a simpler environment when
interactive debugging is possible?

Thanks,
Ludo’.

Message #23 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: Re: bug#40650: guix test suite failures building Debian package
Date: Sat, 18 Apr 2020 22:00:37 +0200

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> test-name: gexp->derivation #:references-graphs
> location: /build/guix-YPdZIs/guix-1.1.0/tests/gexp.scm:944

[...]

> actual-value: #f
> result: FAIL

This failure is because of this assumption in the test:

         ;; Note: %BOOTSTRAP-GUILE depends on the bootstrap Bash.
         (lset= string=?
                (call-with-input-file g-guile read)
                (list (derivation->output-path guile-drv) bash))

This assumption does not hold if you use a ‘bash’ binary different from
the one Guix provides; I had overlooked this.

You can either solve this by pre-downloading Guix’ statically-linked
{bash,mkdir,xz,tar} as discussed earlier, or simply by skipping this
test by adding (test-skip 1) above it (it’s not unreasonable IMO).

Ludo’.

Message #26 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: Re: bug#40650: guix test suite failures building Debian package
Date: Sat, 18 Apr 2020 22:02:03 +0200

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> test-name: store-profile
> location: /build/guix-YPdZIs/guix-1.1.0/tests/size.scm:36
> source:

[...]

> +                           (bash (interned-file
> +                                   (search-bootstrap-binary
> +                                     "bash"
> +                                     (%current-system))
> +                                   "bash"
> +                                   #:recursive?

[...]

> actual-value: #f
> actual-error:
> + (match-error "match" "no matching pattern" #f)
> result: FAIL

Same story here: if you provide a ‘bash’ other than Guix’ bash, this
test is bound to fail.

Thanks,
Ludo’.

Message #29 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: Re: ‘scandir*’ test failure
Date: Sat, 18 Apr 2020 13:19:30 -0700

[Message part 1 (text/plain, inline)]

On 2020-04-18, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>
>> test-name: scandir*, properties
>> location: /build/guix-YPdZIs/guix-1.1.0/tests/syscalls.scm:257
>> source:
...
> Looking at this test, the only way ‘every’ could return #f is (1) if
> ‘lstat’ returns a different inode number, or (2) if ‘lstat’ returns a
> different file type than the one for ‘scandir*’.

My debian package builds are done using a overlay fs(with tmpfs on top,
and ext4 below), which might explain inode discrepancies... this sort of
thing is not uncommon in Debian package building environments.

If that's indeed triggering the issue, maybe it needs some sort of
workaround or a way to detect if it should skip the test?


> Unfortunately it’s hard to tell more without debugging interactively on
> the machine, adding ‘pk’ calls here and there to see.
>
> Can you reproduce this test failure in a simpler environment when
> interactive debugging is possible?

Yeah, I could build in a one-off chroot or virtual machine using a
"normal" filesystem.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: Re: ‘scandir*’ test failure
Date: Sun, 19 Apr 2020 13:01:11 +0200

Hello,

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> On 2020-04-18, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>>
>>> test-name: scandir*, properties
>>> location: /build/guix-YPdZIs/guix-1.1.0/tests/syscalls.scm:257
>>> source:
> ...
>> Looking at this test, the only way ‘every’ could return #f is (1) if
>> ‘lstat’ returns a different inode number, or (2) if ‘lstat’ returns a
>> different file type than the one for ‘scandir*’.
>
> My debian package builds are done using a overlay fs(with tmpfs on top,
> and ext4 below), which might explain inode discrepancies... this sort of
> thing is not uncommon in Debian package building environments.
>
> If that's indeed triggering the issue, maybe it needs some sort of
> workaround or a way to detect if it should skip the test?

Oh, I see.  We would need to see exactly what the discrepancy is (is it
the inode number? for all the entries?), and from there we can come up
with a way to adjust the test or skip it.

Thanks,
Ludo’.

Message #37 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Vagrant Cascadian <vagrant <at> debian.org>, 40650 <at> debbugs.gnu.org
Subject: Re: bug#40650: guix test suite failures building Debian package
Date: Fri, 21 Feb 2025 23:07:36 +0100

Hi,

For reference: https://issues.guix.gnu.org/issue/40650

On Sat, 18 Apr 2020 at 22:02, Ludovic Courtès <ludo <at> gnu.org> wrote:

>> test-name: store-profile
>> location: /build/guix-YPdZIs/guix-1.1.0/tests/size.scm:36
>> source:
>
> [...]
>
>> +                           (bash (interned-file
>> +                                   (search-bootstrap-binary
>> +                                     "bash"
>> +                                     (%current-system))
>> +                                   "bash"
>> +                                   #:recursive?
>
> [...]
>
>> actual-value: #f
>> actual-error:
>> + (match-error "match" "no matching pattern" #f)
>> result: FAIL
>
> Same story here: if you provide a ‘bash’ other than Guix’ bash, this
> test is bound to fail.

What’s the status of this old bug?  It’s marked as moreinfo since 1
year, 49 weeks, 3 days.

Closing?

Cheers,
simon

Message #40 received at 40650 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Simon Tournier <zimon.toutoune <at> gmail.com>, Ludovic Courtès <ludo <at> gnu.org>
Cc: 40650 <at> debbugs.gnu.org
Subject: Re: bug#40650: guix test suite failures building Debian package
Date: Fri, 21 Feb 2025 18:12:27 -0800

[Message part 1 (text/plain, inline)]

On 2025-02-21, Simon Tournier wrote:
> For reference: https://issues.guix.gnu.org/issue/40650
> On Sat, 18 Apr 2020 at 22:02, Ludovic Courtès <ludo <at> gnu.org> wrote:
>>> actual-value: #f
>>> actual-error:
>>> + (match-error "match" "no matching pattern" #f)
>>> result: FAIL
>>
>> Same story here: if you provide a ‘bash’ other than Guix’ bash, this
>> test is bound to fail.
>
> What’s the status of this old bug?  It’s marked as moreinfo since 1
> year, 49 weeks, 3 days.

Great timing to be asking this question, as I have just refreshed the
packaging for Debian from a recent git snapshot of guix!


There are tons of failures on the Debian packaging. I mostly got
exhausted and just patched many of them out. And every new release, I
patch out more. And when build dependencies change in Debian, I
sometimes have to patch out even more though nothing has changed in the
guix source in Debian...

There are probably a few categories of issues:

* Tests that require network access fail, as Debian requires builds to
  not access the network during the build.

  They are typically patched out with:

    (unless (network-reachable?) (test-skip 1))

  These are arguably upstreamable.

* Effectively every test that depends on bootstrap binaries of one form
  or another requires network access, so are usually disabled in a
  similar way.

  These probably do not make sense to upstream, as bootstrap binaries
  can generally be assumed to be present when needed on Guix System or
  even a foreign distro install via guix-install.sh (I think?). But it
  might be nice to figure out a programmatic way to disable them with a
  build flag or enviuronment variable or something, so I do not need to
  patch all relevent tests!

  Many of the tests/*.sh also effectively are in this category, either
  directly or indirectly depending on bootstrap binaries, and are
  patched to be treated as "skip if no network".

* Architecture-specific failures, such as the one I commented on today:

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

  Could probably sum up that bug as: the page size of the architecture
  affects the results in some cases (e.g. /tmp on tmpfs).

* Debian-specific patches (e.g use the system guix-daemon, guix-publish,
  use the system locale, etc.).

  Probably fine to leave patched in Debian, although if anything could
  be made simpler by upstreaming it, so much the better!

* Broken things with "make dist" produced tarballs (e.g. missing
  po/doc/po4a.cfg, missing patches, etc.) and related yak-shaving.

  This obviously ought to get fixed upstream, and more regularly
  monitored somehow so that things are caught and fixed earlier rather
  than waiting for a release...

* Inscrutible (to me) failures. I suspect some current ones are due to
  Debian using guile 3.0.10 rather than older guile in guix (3.0.9?) or
  other build dependency or runtime versions that are skewed. I suspect
  the guile packages that Guix depends on that use C bindings
  (e.g. guile-zlib, guile-gnutls, etc.) may need to be rebuilt more
  often in Debian(something Guix handles by design). These need to be
  looked into by someone who knows what they are doing (e.g. Halp!) or
  at least finds different things to be inscrutible than me. :)


Unfortunately, I have done a poor job of categorizing all the different
patches that disable tests ... so this is a case of putting off work
creating more work. :/

For 1.4.0 the current set of disabled patches:

  https://salsa.debian.org/debian/guix/-/tree/debian/latest/debian/patches

I also just started working on an updated version based on a recent git
snapshot:

  https://salsa.debian.org/debian/guix/-/tree/debian/experimental/debian/patches?ref_type=heads

If someone was able to help upstream some of these patches in a useful
way, that would be great!

> Closing?

Maybe not?

Pretty sure the original issues are at best worked around, and are still
problems, although reviewing and properly categorizing which patches are
which would be a great project to tackle... and maybe, maybe some of
them are no longer needed!

Well, that sure turned into a longer email.

Thanks for prodding!


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.