[PATCH 00/45] Fix builds and skip failing tests for the Hurd.

> Janneke Nieuwenhuizen (43):

> * gnu/packages/emacs.scm (emacs)[inputs]: Change glibc to (libc-for-

> target).

> ---

>  gnu/packages/emacs.scm | 4 ++--

>  1 file changed, 2 insertions(+), 2 deletions(-)

>

> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm

> index 437564f6f0..d3689c2474 100644

> --- a/gnu/packages/emacs.scm

> +++ b/gnu/packages/emacs.scm

> @@ -12,7 +12,7 @@

>  ;;; Copyright © 2017, 2019, 2020 Maxim Cournoyer

> <maxim.cournoyer@gmail.com>

>  ;;; Copyright © 2017 Alex Vong <alexvong1995@gmail.com>

>  ;;; Copyright © 2017, 2018 Ricardo Wurmus <rekado@elephly.net>

> -;;; Copyright © 2017 Jan Nieuwenhuizen <janneke@gnu.org>

> +;;; Copyright © 2017, 2023 Janneke Nieuwenhuizen <janneke@gnu.org>

>  ;;; Copyright © 2018, 2023 Efraim Flashner <efraim@flashner.co.il>

>  ;;; Copyright © 2018 Mathieu Othacehe <m.othacehe@gmail.com>

>  ;;; Copyright © 2018, 2019, 2021 Tobias Geerinckx-Rice

> <me@tobias.gr>

> @@ -310,7 +310,7 @@ (define-public emacs

>  

>             ;; For native compilation

>             binutils

> -           glibc

> +           (libc-for-target)

>             libgccjit

>  

>             ;; Required for "core" functionality, such as dired and

> compression.

> * gnu/packages/glib.scm (glib)[arguments]: When building for the

> Hurd,

> set #:tests? to #false.

> ---

>  gnu/packages/glib.scm | 3 ++-

>  1 file changed, 2 insertions(+), 1 deletion(-)

>

> diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm

> index e988e8dc87..bcbc1f22b1 100644

> --- a/gnu/packages/glib.scm

> +++ b/gnu/packages/glib.scm

> @@ -14,7 +14,7 @@

>  ;;; Copyright © 2019, 2020, 2021 Marius Bakke <marius@gnu.org>

>  ;;; Copyright © 2020 Nicolò Balzarotti <nicolo@nixo.xyz>

>  ;;; Copyright © 2020 Florian Pelz <pelzflorian@pelzflorian.de>

> -;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>

> +;;; Copyright © 2020, 2023 Janneke Nieuwenhuizen <janneke@gnu.org>

>  ;;; Copyright © 2020 Arthur Margerit <ruhtra.mar@gmail.com>

>  ;;; Copyright © 2021 Maxime Devos <maximedevos@telenet.be>

>  ;;; Copyright © 2022 Petr Hodina <phodina@protonmail.com>

> @@ -241,6 +241,7 @@ (define glib

>                 "debug"))

>      (arguments

>       (list

> +      #:tests? (not (target-hurd?))

>        #:disallowed-references

>        (cons tzdata-for-tests

>              ;; Verify glib-mkenums, gtester, ... use the cross-

> compiled

> Gobject-introspection and libdrm does not build for the Hurd. 

> Poppler depends

> on nss, which does not build for the Hurd.

>

> * gnu/packages/gtk.scm (cairo)[native-inputs]: When building for the

> Hurd, do

> not include gobject-introspection.

> [inputs]: Likewise, do not include libdrm, poppler.

> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

> Nieuwenhuizen:

>> * gnu/packages/glib.scm (glib)[arguments]: When building for the

>> Hurd,

>> set #:tests? to #false.

>> +      #:tests? (not (target-hurd?))

>> compiled

> Instead of disabling tests altogether, can we just disable those that

> fail on the Hurd?

> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

> Nieuwenhuizen:

>> Gobject-introspection and libdrm does not build for the Hurd. 

>> Poppler depends

>> on nss, which does not build for the Hurd.

>>

>> * gnu/packages/gtk.scm (cairo)[native-inputs]: When building for the

>> Hurd, do

>> not include gobject-introspection.

>> [inputs]: Likewise, do not include libdrm, poppler.

> Could we provide a minimal gobject-introspection that builds for the

> hurd?

> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

> Nieuwenhuizen:

>> * gnu/packages/emacs.scm (emacs)[inputs]: Change glibc to (libc-for-

>> target).

>> @@ -310,7 +310,7 @@ (define-public emacs

>>  

>>             ;; For native compilation

>>             binutils

>> -           glibc

>> +           (libc-for-target)

>>             libgccjit

>>  

>>             ;; Required for "core" functionality, such as dired and

>> compression.

> LGTM

> * gnu/packages/tls.scm (openssl-3.0)[arguments]: When building on the Hurd,

> add "hurd-x86" to #:configure-flags.

> + ((#:configure-flags flags #~'())

> + (if (target-hurd? (%current-system))

> + #~(append

> + #$flags

> + '("hurd-x86"))

> * gnu/packages/multiprecision.scm (mpfr)[arguments]: When building natively on

> the Hurd, add 'skip-tests' phase to skip "tsprintf".

> + #:phases (if (system-hurd?)

> + (substitute*

> + "tests/tsprintf.c"

> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

>

>> * gnu/packages/tls.scm (openssl-3.0)[arguments]: When building on the Hurd,

>> add "hurd-x86" to #:configure-flags.

>

> [...]

>

>> + ((#:configure-flags flags #~'())

>> + (if (target-hurd? (%current-system))

>

> Should it be (target-hurd?) with no arguments, so it also affects

> cross-compilation?

> If not, maybe add “;native builds” or similar as a

> margin comment to make it clear that it’s on purpose.

>

>> + #~(append

>> + #$flags

>> + '("hurd-x86"))

>

> On a single line please. :-)

> * gnu/packages/gtk.scm (pango)[native-inputs]: Do not include

> gobject-introspection when building for the Hurd.

> ---

> gnu/packages/gtk.scm | 14 ++++++++------

> 1 file changed, 8 insertions(+), 6 deletions(-)

>

> diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm

> index 853696c7f5..15dea2852b 100644

> --- a/gnu/packages/gtk.scm

> +++ b/gnu/packages/gtk.scm

> @@ -401,12 +401,14 @@ (define-public pango

> (list bash-minimal

> zlib))

> (native-inputs

> - (list `(,glib "bin") ;glib-mkenums, etc.

> - gobject-introspection ;g-ir-compiler, etc.

> - help2man

> - perl

> - pkg-config

> - python-wrapper))

> + `((,glib "bin") ;glib-mkenums, etc.

> + ,@(if (target-hurd?)

> + '()

> + (list gobject-introspection)) ;g-ir-compiler, etc.

> + ,help2man

> + ,perl

> + ,pkg-config

> + ,python-wrapper))

> Liliana Marie Prikler writes:

>

>> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

>> Nieuwenhuizen:

>>> * gnu/packages/glib.scm (glib)[arguments]: When building for the

>>> Hurd,

>>> set #:tests? to #false.

>

> [..]

>>> +      #:tests? (not (target-hurd?))

>

>>> compiled

>

>> Instead of disabling tests altogether, can we just disable those that

>> fail on the Hurd?

>

> We probably can, and I have tried to do so in most cases. However,

> identifying those tests can be quite time consuming. I'm not sure how

> many tests failed here, and note that some tests will hang or crash the

> Hurd, so if we decide to do this, I would appreciate some help :-)

>

> Ludo on the other hand, argued against having more than ~20 (IIRC) test

> exceptions and using #:tests? #f instead.

>

> My idea was to get guix to build natively, and guix pull to work. Once

> we get those to work, we can possibly look forward to more contributors

> to this.

> Liliana Marie Prikler writes:

>

>> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

>> Nieuwenhuizen:

>>> Gobject-introspection and libdrm does not build for the Hurd. 

>>> Poppler depends

>>> on nss, which does not build for the Hurd.

>>>

>>> * gnu/packages/gtk.scm (cairo)[native-inputs]: When building for the

>>> Hurd, do

>>> not include gobject-introspection.

>>> [inputs]: Likewise, do not include libdrm, poppler.

>

>> Could we provide a minimal gobject-introspection that builds for the

>> hurd?

>

> That would be nice. Note that Debian doesn't support

> gobject-introspection on the Hurd, unless I'm mistaken.

> * gnu/packages/base.scm (coreutils)[arguments]: When building natively on the

> Hurd, remove "test/df/unreadable.sh" and "test-perror2" from #:make-flags's

> XFAIL_TESTS as they now pass. Move failing script tests from XFAIL_TESTS to

> 'remove-tests' phase. In phase 'remove-tests' rewrite substitute* to skip

> tests instead of removing them. Add hanging and failing tests.

> + '((substitute*

> + ;; These tests hang

> + '("tests/cp/sparse-to-pipe.sh"

> + "tests/split/fail.sh"

> + ;; These tests error

> + "tests/dd/nocache.sh"

> + ;; These tests fail

> + "tests/cp/sparse.sh"

> + "tests/cp/special-f.sh"

> + "tests/dd/bytes.sh"

> + "tests/dd/stats.sh"

> + "tests/ls/dangle.sh"

> + "tests/ls/follow-slink.sh"

> + "tests/ls/hyperlink.sh"

> + "tests/ls/infloop.sh"

> + "tests/ls/inode.sh"

> + "tests/ls/selinux-segfault.sh"

> + "tests/misc/env-S.pl"

> + "tests/misc/factor-parallel.sh"

> + "tests/misc/ls-misc.pl"

> + "tests/misc/nice.sh"

> + "tests/misc/pwd-long.sh"

> + "tests/misc/shred-passes.sh"

> + "tests/misc/stat-slash.sh"

> + "tests/rm/fail-eperm.xpl"

> + "tests/split/filter.sh")

> + (("^#!.*" all)

> + (string-append all "exit 77;\n")))

> * gnu/packages/gtk.scm (harfbuzz)[native-inputs]: Do not include

> gobject-introspection when building for the Hurd.

> ---

> gnu/packages/gtk.scm | 12 +++++++-----

> 1 file changed, 7 insertions(+), 5 deletions(-)

>

> diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm

> index eb69a88221..853696c7f5 100644

> --- a/gnu/packages/gtk.scm

> +++ b/gnu/packages/gtk.scm

> @@ -276,11 +276,13 @@ (define-public harfbuzz

> ;; There are all in the Requires or Requires.private field of '.pc'.

> (list glib graphite2 icu4c))

> (native-inputs

> - (list `(,glib "bin") ;for glib-mkenums

> - gobject-introspection

> - pkg-config

> - python-wrapper

> - which))

> + `((,glib "bin") ;for glib-mkenums

> + ,@(if (target-hurd?)

> + '()

> + (list gobject-introspection))

> + ,pkg-config

> + ,python-wrapper

> + ,which))

> Thanks for your efforts on this.

> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>

>> * gnu/packages/gtk.scm (pango)[native-inputs]: Do not include

>> gobject-introspection when building for the Hurd.

>> ---

>> gnu/packages/gtk.scm | 14 ++++++++------

>> 1 file changed, 8 insertions(+), 6 deletions(-)

>>

>> diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm

>> index 853696c7f5..15dea2852b 100644

>> --- a/gnu/packages/gtk.scm

>> +++ b/gnu/packages/gtk.scm

>> @@ -401,12 +401,14 @@ (define-public pango

>> (list bash-minimal

>> zlib))

>> (native-inputs

>> - (list `(,glib "bin") ;glib-mkenums, etc.

>> - gobject-introspection ;g-ir-compiler, etc.

>> - help2man

>> - perl

>> - pkg-config

>> - python-wrapper))

>> + `((,glib "bin") ;glib-mkenums, etc.

>> + ,@(if (target-hurd?)

>> + '()

>> + (list gobject-introspection)) ;g-ir-compiler, etc.

>> + ,help2man

>> + ,perl

>> + ,pkg-config

>> + ,python-wrapper))

>

> Stylistically, I think it'd be better to use append (and 'if') here than

> quasiquotes (to avoid having to unquote all inputs).

> Otherwise it LGTM.

> * gnu/packages/guile.scm (guile-3.0)[arguments]: When building on the Hurd,

> add stage 'disable-popen.test-open-pipe' to avoid running the

> open-input-pipe test (hangs) and open-output-pipe test (fails.

> + #~((add-after 'unpack 'disable-popen.test-no-duplicate

> + ;; This test hangs on the Hurd.

> + (lambda _

> + (substitute* "test-suite/tests/popen.test"

> + (("\\(pass-if \"no duplicate\".*" all)

> + (string-append all " (when (string-ci= \"GNU\" (vector-ref (uname) 0)) (throw 'unresolved))

> +"))))))

> Great work!

> A general comment: these changes to test suites were made based on

> feedback from non-chrooted builds, whose outcome is influenced by system

> state such as running translators. Until we have chroot builds, I think

> we should be cautious and not invest too much time.

> For example, I wonder how reliable this long list is. Some of these

> tests may fiddle with /proc, /etc/fstab, and other things not under

> control, which means some might suddenly pass for some reason. So I

> wonder if we should just #:tests? #f in this case.

>

> Thoughts?

>

> (With other, higher-level test suites with a couple of failures, it’s

> probably still a good idea to skip individual tests instead of the whole

> test suite.)

> Great work!

> A general comment: these changes to test suites were made based on

> feedback from non-chrooted builds, whose outcome is influenced by system

> state such as running translators. Until we have chroot builds, I think

> we should be cautious and not invest too much time.

> For example, I wonder how reliable this long list is. Some of these

> tests may fiddle with /proc, /etc/fstab, and other things not under

> control, which means some might suddenly pass for some reason. So I

> wonder if we should just #:tests? #f in this case.

>

> Thoughts?

>

> (With other, higher-level test suites with a couple of failures, it’s

> probably still a good idea to skip individual tests instead of the whole

> test suite.)

> * gnu/packages/base.scm (grep)[arguments]: When building natively on the Hurd,

> remove Rename phase 'skip-triple-backref-test' to 'skip-tests'. Remove

> "tests/triple-backref" as it now passes. Add the hanging

> "tests/hash-collision-perf" test, and the failing "tests/file" test.

> + '((add-before 'check 'skip-test

> (lambda _

> - ;; This test is marked as malfunctioning on glibc systems

> - ;; due to

> - ;; <https://sourceware.org/bugzilla/show_bug.cgi?id=11053>

> - ;; and it triggers a segfault with glibc 2.33 on GNU/Hurd.

> - ;; Skip it.

> - (substitute* "tests/triple-backref"

> - (("^warn_" all)

> - (string-append "exit 77\n" all))))))

> - '()))

> - #:make-flags ,(if (target-hurd?)

> - ''("XFAIL_TESTS=test-perror2 equiv-classes") ;XXX

> - ''())))

> + (substitute*

> + ;; This test hangs

> + '("tests/hash-collision-perf"

> + ;; This test fails

> + "tests/file")

> + (("^#!.*" all)

> + (string-append all "exit 77;\n"))))))

> Also, most probably problematic tests in the guile test suite were fixed on

> guile master. As I understand, Josselin is working on this, so way may want

> to skip the patch for guile (or apply it anyway and revert it later).

>

> Because many patches are almost trivial and similar, you may want to give some

> specific comments to the non-trivial patches and possibly some general

> comments for the trivial ones instead of a LGTM on every individual patch?

> Okay, I can change it to

>

> (cons `(,glib "bin") ;glib-mkenums, etc.

> (append (if (target-hurd?)

> '()

> (list gobject-introspection)) ;g-ir-compiler, etc.

> (list help2man

> perl

> pkg-config

> python-wrapper)))

> (+Cc: Josselin.)

>

> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

>

>> * gnu/packages/guile.scm (guile-3.0)[arguments]: When building on the Hurd,

>> add stage 'disable-popen.test-open-pipe' to avoid running the

>> open-input-pipe test (hangs) and open-output-pipe test (fails.

>

> [...]

>

>> + #~((add-after 'unpack 'disable-popen.test-no-duplicate

>> + ;; This test hangs on the Hurd.

>> + (lambda _

>> + (substitute* "test-suite/tests/popen.test"

>> + (("\\(pass-if \"no duplicate\".*" all)

>> + (string-append all " (when (string-ci= \"GNU\" (vector-ref (uname) 0)) (throw 'unresolved))

>> +"))))))

>

> Maybe write:

>

> (string-append all

> (object->string '(when …)))

> Out of curiosity, is there a bug report for this one?

> IIRC, the test suite of Guile 3.0.9 + ‘guile-hurd-posix-spawn.patch’

> used to pass on glibc 2.35.

> As discussed on IRC, skipping this test is not great in that it’ll

> likely come to haunt us. However, like you write, we can do that for

> now in the interest of making progress :-) and remove it with a proper

> fix once we have it.

>

> So… LGTM!

> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>

> [...]

>

>> Okay, I can change it to

>>

>> (cons `(,glib "bin") ;glib-mkenums, etc.

>> (append (if (target-hurd?)

>> '()

>> (list gobject-introspection)) ;g-ir-compiler, etc.

>> (list help2man

>> perl

>> pkg-config

>> python-wrapper)))

>

> You can avoid 'cons' by moving `(,glib "bin") to the front of the

> trailing list (the one starting with help2man ...), I think.

> (+Cc: Josselin.)

>

> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

>

>> * gnu/packages/guile.scm (guile-3.0)[arguments]: When building on the Hurd,

>> add stage 'disable-popen.test-open-pipe' to avoid running the

>> open-input-pipe test (hangs) and open-output-pipe test (fails.

>

> [...]

>

>> + #~((add-after 'unpack 'disable-popen.test-no-duplicate

>> + ;; This test hangs on the Hurd.

>> + (lambda _

>> + (substitute* "test-suite/tests/popen.test"

>> + (("\\(pass-if \"no duplicate\".*" all)

>> + (string-append all " (when (string-ci= \"GNU\" (vector-ref (uname) 0)) (throw 'unresolved))

>> +"))))))

>

> Maybe write:

>

> (string-append all

> (object->string '(when …)))

> Out of curiosity, is there a bug report for this one?

> IIRC, the test suite of Guile 3.0.9 + ‘guile-hurd-posix-spawn.patch’

> used to pass on glibc 2.35.

> As discussed on IRC, skipping this test is not great in that it’ll

> likely come to haunt us. However, like you write, we can do that for

> now in the interest of making progress :-) and remove it with a proper

> fix once we have it.

>

> So… LGTM!

> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>

>> Liliana Marie Prikler writes:

>>

>>> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

>>> Nieuwenhuizen:

>>>> Gobject-introspection and libdrm does not build for the Hurd. 

>>>> Poppler depends

>>>> on nss, which does not build for the Hurd.

>>>>

>>>> * gnu/packages/gtk.scm (cairo)[native-inputs]: When building for the

>>>> Hurd, do

>>>> not include gobject-introspection.

>>>> [inputs]: Likewise, do not include libdrm, poppler.

>>

>>> Could we provide a minimal gobject-introspection that builds for the

>>> hurd?

>>

>> That would be nice. Note that Debian doesn't support

>> gobject-introspection on the Hurd, unless I'm mistaken.

>

> I wonder what prevents gobject-introspection from running on the Hurd?

> Maxim Cournoyer writes:

>

> Hello,

>

>> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>>

>> [...]

>>

>>> Okay, I can change it to

>>>

>>> (cons `(,glib "bin") ;glib-mkenums, etc.

>>> (append (if (target-hurd?)

>>> '()

>>> (list gobject-introspection)) ;g-ir-compiler, etc.

>>> (list help2man

>>> perl

>>> pkg-config

>>> python-wrapper)))

>>

>> You can avoid 'cons' by moving `(,glib "bin") to the front of the

>> trailing list (the one starting with help2man ...), I think.

>

> Eh..I think that I don't understand; you mean moving `(,glib ,bin) after

> gobject-introspection like this?

>

> (append (if (target-hurd?)

> '()

> (list gobject-introspection)) ;g-ir-compiler, etc.

> (list

> `(,glib "bin") ;glib-mkenums, etc.

> help2man

> perl

> pkg-config

> python-wrapper)))

>

> That will trigger a rebuild that I would like to avoid.

> We could avoid cons by doing

>

> (append (list `(,glib "bin")) ;glib-mkenums, etc.

> (if (target-hurd?)

> '()

> (list gobject-introspection)) ;g-ir-compiler, etc.

> (list

> help2man

> perl

> pkg-config

> python-wrapper))

>

> perhaps the best option?

> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>

>> Maxim Cournoyer writes:

>>

>> Hello,

>>

>>> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>>>

>>> [...]

>> That will trigger a rebuild that I would like to avoid.

>

> Ah, apologies, I had not thought about this causing rebuilds.

>> We could avoid cons by doing

>>

>> (append (list `(,glib "bin")) ;glib-mkenums, etc.

>> (if (target-hurd?)

>> '()

>> (list gobject-introspection)) ;g-ir-compiler, etc.

>> (list

>> help2man

>> perl

>> pkg-config

>> python-wrapper))

>>

>> perhaps the best option?

>

> Either ways are fine, sorry for the noise :-).

> Maxim Cournoyer writes:

>

> Hi!

>

>> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>>

>>> Liliana Marie Prikler writes:

>>>

>>>> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

>>>> Nieuwenhuizen:

>>>>> Gobject-introspection and libdrm does not build for the Hurd. 

>>>>> Poppler depends

>>>>> on nss, which does not build for the Hurd.

>>>>>

>>>>> * gnu/packages/gtk.scm (cairo)[native-inputs]: When building for the

>>>>> Hurd, do

>>>>> not include gobject-introspection.

>>>>> [inputs]: Likewise, do not include libdrm, poppler.

>>>

>>>> Could we provide a minimal gobject-introspection that builds for the

>>>> hurd?

>>>

>>> That would be nice. Note that Debian doesn't support

>>> gobject-introspection on the Hurd, unless I'm mistaken.

>>

>> I wonder what prevents gobject-introspection from running on the Hurd?

>

> Find build log attached.

> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>

>> Liliana Marie Prikler writes:

>>

>>> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

>>> Nieuwenhuizen:

>>>> * gnu/packages/glib.scm (glib)[arguments]: When building for the

>>>> Hurd,

>>>> set #:tests? to #false.

>>

>> [..]

>>>> +      #:tests? (not (target-hurd?))

>>

>>>> compiled

>>

>>> Instead of disabling tests altogether, can we just disable those that

>>> fail on the Hurd?

>>

>> We probably can, and I have tried to do so in most cases. However,

>> identifying those tests can be quite time consuming. I'm not sure how

>> many tests failed here, and note that some tests will hang or crash the

>> Hurd, so if we decide to do this, I would appreciate some help :-)

>>

>> Ludo on the other hand, argued against having more than ~20 (IIRC) test

>> exceptions and using #:tests? #f instead.

>>

>> My idea was to get guix to build natively, and guix pull to work. Once

>> we get those to work, we can possibly look forward to more contributors

>> to this.

>

> I agree with Liliana that it's nicer to disable just these tests that

> fail, but in light of what you wrote, your approach seems reasonable.

> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

>

>> Also, most probably problematic tests in the guile test suite were fixed on

>> guile master. As I understand, Josselin is working on this, so way may want

>> to skip the patch for guile (or apply it anyway and revert it later).

>>

>> Because many patches are almost trivial and similar, you may want to give some

>> specific comments to the non-trivial patches and possibly some general

>> comments for the trivial ones instead of a LGTM on every individual patch?

>

> So modulo the few comments I sent, I think this looks good.

> There’s a couple of things to check (which I haven’t do):

>

> • Make sure x86_64-linux derivations (for instance) are unchanged.

> That is, ‘./pre-inst-env guix build libreoffice -d’ should produce

> the same thing before and after this patch series, on x86_64-linux.

> (Pro tip: replace ‘-d’ with ‘-n’; if there are substitutes, it means

> it hasn’t changed. :-))

> • Make sure ‘guix build sed --target=i586-pc-gnu’ still works.

> Probably the derivation should be unchanged, but maybe it’s OK if it

> changes (sometimes avoiding a cross-rebuild would require extra

> boilerplate that we’d rather not have).

> • And well, ‘guix build sed -s i586-gnu’ should work as well, but

> that’s the whole point of this series!

> Thanks a lot for all the work!

> Maxim Cournoyer writes:

>

> Hello!

>

>> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>>

>>> Liliana Marie Prikler writes:

>>>

>>>> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

>>>> Nieuwenhuizen:

>>>>> * gnu/packages/glib.scm (glib)[arguments]: When building for the

>>>>> Hurd,

>>>>> set #:tests? to #false.

>>>

>>> [..]

>>>>> +      #:tests? (not (target-hurd?))

>>>

>>>>> compiled

>>>

>>>> Instead of disabling tests altogether, can we just disable those that

>>>> fail on the Hurd?

>>>

>>> We probably can, and I have tried to do so in most cases. However,

>>> identifying those tests can be quite time consuming. I'm not sure how

>>> many tests failed here, and note that some tests will hang or crash the

>>> Hurd, so if we decide to do this, I would appreciate some help :-)

>>>

>>> Ludo on the other hand, argued against having more than ~20 (IIRC) test

>>> exceptions and using #:tests? #f instead.

>>>

>>> My idea was to get guix to build natively, and guix pull to work. Once

>>> we get those to work, we can possibly look forward to more contributors

>>> to this.

>>

>> I agree with Liliana that it's nicer to disable just these tests that

>> fail, but in light of what you wrote, your approach seems reasonable.

>

> Yes, I agree that if we want to make Hurd better and enabble us to

> create a bug report it sure helps if we have more information.

>

> Yesterday I decided to have another look into this. I have identified

> 20 tests that TIMEOUT after 600s, and 37 FAIL and instead of setting

> #:tests? to #false, I have added them to the `disable-failing-tests'

> phase when building on the Hurd. See attached patch.

> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>

>> Maxim Cournoyer writes:

>>

>> Hello!

>>

>>> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>>>

>>>> Liliana Marie Prikler writes:

>>>>

>>>>> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

>>>>> Nieuwenhuizen:

>>>>>> * gnu/packages/glib.scm (glib)[arguments]: When building for the

>>>>>> Hurd,

>>>>>> set #:tests? to #false.

>>>>

>>>> [..]

>>>>>> +      #:tests? (not (target-hurd?))

>>>>

>>>>>> compiled

>>>>

>>>>> Instead of disabling tests altogether, can we just disable those that

>>>>> fail on the Hurd?

>>>>

>>>> We probably can, and I have tried to do so in most cases. However,

>>>> identifying those tests can be quite time consuming. I'm not sure how

>>>> many tests failed here, and note that some tests will hang or crash the

>>>> Hurd, so if we decide to do this, I would appreciate some help :-)

>>>>

>>>> Ludo on the other hand, argued against having more than ~20 (IIRC) test

>>>> exceptions and using #:tests? #f instead.

>>>>

>>>> My idea was to get guix to build natively, and guix pull to work. Once

>>>> we get those to work, we can possibly look forward to more contributors

>>>> to this.

>>>

>>> I agree with Liliana that it's nicer to disable just these tests that

>>> fail, but in light of what you wrote, your approach seems reasonable.

>>

>> Yes, I agree that if we want to make Hurd better and enabble us to

>> create a bug report it sure helps if we have more information.

>>

>> Yesterday I decided to have another look into this. I have identified

>> 20 tests that TIMEOUT after 600s, and 37 FAIL and instead of setting

>> #:tests? to #false, I have added them to the `disable-failing-tests'

>> phase when building on the Hurd. See attached patch.

>

> Well done pushing the investigation!

> Are you sure these failures are Hurd-only?

> When I see timeouts related to dbus tests, I often think the problem

> may be attributed to #30948, because dbus often waits for processes to

> die completely but are left as zombies in the build container due to

> incorrect signal handling from the Guile PID 1 there. But since the

> glib package currently builds for x86_64 at least,

> LGTM.

> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>

>> Maxim Cournoyer writes:

>>

>> Hi!

>>

>>> Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>>>

>>>> Liliana Marie Prikler writes:

>>>>

>>>>> Am Dienstag, dem 18.07.2023 um 16:40 +0200 schrieb Janneke

>>>>> Nieuwenhuizen:

>>>>>> Gobject-introspection and libdrm does not build for the Hurd. 

>>>>>> Poppler depends

>>>>>> on nss, which does not build for the Hurd.

>>>>>>

>>>>>> * gnu/packages/gtk.scm (cairo)[native-inputs]: When building for the

>>>>>> Hurd, do

>>>>>> not include gobject-introspection.

>>>>>> [inputs]: Likewise, do not include libdrm, poppler.

>>>>

>>>>> Could we provide a minimal gobject-introspection that builds for the

>>>>> hurd?

>>>>

>>>> That would be nice. Note that Debian doesn't support

>>>> gobject-introspection on the Hurd, unless I'm mistaken.

>>> I wonder what prevents gobject-introspection from running on the Hurd?

>>

>> Find build log attached.

>

> Interesting. Debian carries no Hurd patch for it [0], and upstream

> doesn't seem to know about this issue [1].

> [0] http://deb.debian.org/debian/pool/main/g/gobject-introspection/gobject-introspection_1.76.1-1.debian.tar.xz

> [1] https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/?sort=created_date&state=opened&search=getauxval&first_page_size=20