unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Vagrant Cascadian <vagrant@debian.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 40650@debbugs.gnu.org
Subject: bug#40650: guix test suite failures building Debian package
Date: Thu, 16 Apr 2020 10:23:57 -0700	[thread overview]
Message-ID: <87o8rr1h02.fsf@ponder> (raw)
In-Reply-To: <87d087kem6.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 6921 bytes --]

Thanks for the quick response!

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

  reply	other threads:[~2020-04-16 17:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 22:03 bug#40650: guix test suite failures building Debian package Vagrant Cascadian
2020-04-16  8:40 ` Ludovic Courtès
2020-04-16 17:23   ` Vagrant Cascadian [this message]
2020-04-17  8:50     ` Ludovic Courtès
2020-04-17 22:13       ` Vagrant Cascadian
2020-04-18 19:53         ` bug#40650: ‘scandir*’ test failure Ludovic Courtès
2020-04-18 20:19           ` Vagrant Cascadian
2020-04-19 11:01             ` Ludovic Courtès
2020-04-18 20:00         ` bug#40650: guix test suite failures building Debian package Ludovic Courtès
2020-04-18 20:02         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8rr1h02.fsf@ponder \
    --to=vagrant@debian.org \
    --cc=40650@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).