#40650 guix test suite failures building Debian package

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

Received: (at 40650) by debbugs.gnu.org; 17 Apr 2020 08:50:41 +0000
From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 17 04:50:41 2020
Received: from localhost ([127.0.0.1]:39925 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1jPMht-0007o6-C4
	for submit@debbugs.gnu.org; Fri, 17 Apr 2020 04:50:41 -0400
Received: from eggs.gnu.org ([209.51.188.92]:38332)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@gnu.org>) id 1jPMhr-0007nq-Uu
 for 40650@debbugs.gnu.org; Fri, 17 Apr 2020 04:50:40 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:48094)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <ludo@gnu.org>)
 id 1jPMhm-0008HF-F3; Fri, 17 Apr 2020 04:50:34 -0400
Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=43796 helo=ribbon)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <ludo@gnu.org>)
 id 1jPMhl-0003bG-Q0; Fri, 17 Apr 2020 04:50:34 -0400
From: Ludovic Courtès <ludo@gnu.org>
To: Vagrant Cascadian <vagrant@debian.org>
Subject: Re: bug#40650: guix test suite failures building Debian package
References: <87pnc8wgnq.fsf@yucca> <87d087kem6.fsf@gnu.org>
 <87o8rr1h02.fsf@ponder>
X-URL: http://www.fdn.fr/~lcourtes/
X-Revolutionary-Date: 29 Germinal an 228 de la Révolution
X-PGP-Key-ID: 0x090B11993D9AEBB5
X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
Date: Fri, 17 Apr 2020 10:50:31 +0200
In-Reply-To: <87o8rr1h02.fsf@ponder> (Vagrant Cascadian's message of "Thu, 16
 Apr 2020 10:23:57 -0700")
Message-ID: <87mu7abinc.fsf@gnu.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -1.5 (-)
X-Debbugs-Envelope-To: 40650
Cc: 40650@debbugs.gnu.org
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: -2.5 (--)

Hi Vagrant,

Vagrant Cascadian <vagrant@debian.org> skribis:

> On 2020-04-16, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant@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’.

Send a report that this bug log contains spam.