From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#40650: guix test suite failures building Debian package Date: Fri, 17 Apr 2020 10:50:31 +0200 Message-ID: <87mu7abinc.fsf@gnu.org> References: <87pnc8wgnq.fsf@yucca> <87d087kem6.fsf@gnu.org> <87o8rr1h02.fsf@ponder> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:53614) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPMiG-0001Xv-Jw for bug-guix@gnu.org; Fri, 17 Apr 2020 04:51:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jPMiE-0000Yv-7w for bug-guix@gnu.org; Fri, 17 Apr 2020 04:51:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:56612) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jPMiE-0000Yh-4A for bug-guix@gnu.org; Fri, 17 Apr 2020 04:51:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jPMiE-0007od-3k for bug-guix@gnu.org; Fri, 17 Apr 2020 04:51:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87o8rr1h02.fsf@ponder> (Vagrant Cascadian's message of "Thu, 16 Apr 2020 10:23:57 -0700") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Vagrant Cascadian Cc: 40650@debbugs.gnu.org Hi Vagrant, Vagrant Cascadian skribis: > On 2020-04-16, Ludovic Court=C3=A8s wrote: >> Vagrant Cascadian 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 =E2=80=98network-reachable?=E2=80=99 to return #f. For tests/*.sh, = you have to grep/sed for =E2=80=98getaddrinfo=E2=80=99. >> Here=E2=80=99s it=E2=80=99s =E2=80=98search-bootstrap-binary=E2=80=99 fr= om (guix tests) that tries to >> create the file above, having downloaded it earlier. >> >> For the =E2=80=98guix=E2=80=99 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 =E2=80=98make check=E2=80=99 since they=E2=80=99re already ther= e. >> >> 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=E2=80=99s 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=E2=80=99re 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=E2=80=99s simply that we use i686 binaries on x86_64. At any rate, you=E2=80=99ll restrict the package to the subset of architect= ures that Guix supports, right? >> We may need to provide a dummy .gitconfig file or something here so we >> can run these tests. See also . >> (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=3D/some/path and populate > $HOME/.gitconfig), or apply the patch and try it. :) Yeah, let=E2=80=99s 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=3D? name2 name) >>> + (let* ((full (string-append directory "/" n= ame)) >>> + (stat (lstat full)) >>> + (inode (assoc-ref properties 'inode)) >>> + (type (assoc-ref properties 'type))) >>> + (and (=3D 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 =E2=80=98scandir*=E2=80=99 and =E2=80=98scandir=E2=80= =99 calls in =E2=80=98pk=E2=80=99, run: > > like this? > (pk (scandir* directory)) > (pk (scandir directory (const #t) string> make check TESTS=3Dtests/syscalls.scm >> >> and send =E2=80=98test-suite.log=E2=80=99? > > 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=E2=80=99s reproducible in a =E2=80=9Cregular=E2=80=9D Debian env= ironment? >>> ++ guix build guile-gcrypt --with-branch=3Dguile-gcrypt=3Dmaster -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.or= g/cwebber/guile-gcrypt.git: the SSL certificate is invalid: 0x08 - The cert= ificate is not correctly signed by the trusted CA >>> + latest_drv=3D >>> 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=E2=80=A6 I=E2=80=99d gladly accept patches. :-) Thanks for your feedback! Hopefully we can easily address the remaining is= sues. Ludo=E2=80=99.