i686 core-updates failure.

i686 core-updates failure.

[Kaelyn]

Hi,

I've been working on getting wine to build on core-updates, with the most recent blocker being python-numpy failing two tests on i686 (one of which is apparently too big for 32-bit systems, based on the comment in the Gentoo ebuild of python-numpy where they skip the test). I just poked through the CI dashboard for the latest core-updates evaluation to see if it was hitting the same failure (it was), and discovered an odd chain of dependencies. Before going into the chain, I want to mention that wine has 6 failing dependencies[1], one of which is pulseaudio, two of which include pulseaudio as part of why they failed, and two include dependency failures that are on pulseaudio's dependency chain (the 6th failed dependency is due to qtbase which I didn't look into; none are direct failures).

On to the odd chain:
* The sole failed dependency of pulseaudio is bluez
* bluez's sole failed dependency is libical
* libical's sole failed dependency is gtk-doc (also a failed dependency of two other wine dependencies)
* gtk-doc's sole failed dependency is dblatex
* dblatex's sole failed dependency is inkscape(?!?!?)
* inkscape's sole failed dependency is python-numpy, which is failing two tests.

I call the dependency chain odd in that pulseaudio--which is near the heart of a lot of Linux software that supports audio--is failing because inkscape--a graphical vector editor--is a dependency of a tool designed to extract API documentation from source code.

For the dependency chain, I have no real thoughts, goals, or proposed changes other than surprise that pulseaudio fails to build because a GUI SVG editor failed to build.

For the actual failures in python-numpy[2]:
1. TestUfunc::test_identityless_reduction_huge_array in numpy/core/tests/test_ufunc.py: as I alluded to earlier, the Gentoo ebuild[3] disables this test with a comment that the test is "too large for 32-bit platforms".
2. TestKind::test_all in numpy/f2py/tests/test_kind.py: I'm not sure why this test is failing or what to do about it, since it seems to be seeing incorrect values for objects coming from Fortran code. Perhaps a type size mismatch for 32-bit platforms, but hard for me to say since I don't know Fortran and I haven't had luck finding other reports of that test failing.

Cheers,
Kaelyn


[1] https://ci.guix.gnu.org/build/843194/details
[2] https://ci.guix.gnu.org/build/712672/log/raw
[3] https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/numpy/numpy-1.24.0.ebuild#n142

Re: i686 core-updates failure.

[Josselin Poiret]

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

Hi Kaelyn,

Kaelyn <kaelyn.alexi@protonmail.com> writes:

> I call the dependency chain odd in that pulseaudio--which is near the heart of a lot of Linux software that supports audio--is failing because inkscape--a graphical vector editor--is a dependency of a tool designed to extract API documentation from source code.

I agree that this is quite a "heavy" dependency chain for pulseaudio,
but this is also the case for most programs which produce documentation.
In the end, they also don't retain references to inkscape, so once
they're built on CI, anyone using substitutes wouldn't need to download
all of that part of the dependency chain.

Best,
-- 
Josselin Poiret

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

Re: i686 core-updates failure.

[Andreas Enge]

Hello,

Am Wed, Apr 12, 2023 at 04:11:58PM +0000 schrieb Kaelyn:
> For the actual failures in python-numpy[2]:

you could always try whether an update solves the test failures; the package
has 2892 dependents, but anyway, the only option is fixing it and rebuilding
all the 2892 dependents also on x86_64, or renouncing at the 2892 dependents
on i686. I think the former would be preferable (and maybe even required for
merging).

Andreas

Re: i686 core-updates failure.

[Kaelyn]

Hi,

------- Original Message -------
On Wednesday, April 12th, 2023 at 9:31 PM, Andreas Enge <andreas@enge.fr> wrote:


> 
> 
> Hello,
> 
> Am Wed, Apr 12, 2023 at 04:11:58PM +0000 schrieb Kaelyn:
> 
> > For the actual failures in python-numpy[2]:
> 
> 
> you could always try whether an update solves the test failures; the package
> has 2892 dependents, but anyway, the only option is fixing it and rebuilding
> all the 2892 dependents also on x86_64, or renouncing at the 2892 dependents
> on i686. I think the former would be preferable (and maybe even required for
> merging).

I forgot to mention that I had also tried updating to the latest numpy (2.24.2), with the same tests failing. I agree the test failures in numpy need to be resolved in some way for merging core-updates, since the failure affects such a large number of common (desktop) applications on i686. My inclination is to disable both failing tests (at least for now), and possibly updating to the latest numpy since changing the package would trigger a rebuild anyway. I only hesitate about disabling TestKind.test_all since I don't know what role the Fortran bridging code plays in numpy and if the failure is a sign of a legitimate problem instead of a platform limitation (as the large array test failure seems to be).

Cheers,
Kaelyn

> 
> Andreas

Re: i686 core-updates failure.

[Andreas Enge]

Hello,

Am Thu, Apr 13, 2023 at 04:37:55AM +0000 schrieb Kaelyn:
> I forgot to mention that I had also tried updating to the latest numpy (2.24.2), with the same tests failing. I agree the test failures in numpy need to be resolved in some way for merging core-updates, since the failure affects such a large number of common (desktop) applications on i686. My inclination is to disable both failing tests (at least for now), and possibly updating to the latest numpy since changing the package would trigger a rebuild anyway. I only hesitate about disabling TestKind.test_all since I don't know what role the Fortran bridging code plays in numpy and if the failure is a sign of a legitimate problem instead of a platform limitation (as the large array test failure seems to be).

I agree with your analysis: I am not overly shocked that on a 32 bit
architecture creating an array of 2^31 elements fails, while on a
64 bit architecture the same test passes. Still, how about sending
a bug report? Can anything be seen from the Debian package? If it is
a consistent 32 bit failure, it had better be repaired upstream.

For the Fortran bindings, I am hesitant as well. I think it is bad style
to disable a test just because it fails ;-)  Maybe someone with experience
in numpy can speak up.

Andreas

Re: i686 core-updates failure.

[Andreas Enge]

Am Thu, Apr 13, 2023 at 06:25:47PM +0200 schrieb Andreas Enge:
> For the Fortran bindings, I am hesitant as well. I think it is bad style
> to disable a test just because it fails ;-)  Maybe someone with experience
> in numpy can speak up.

Well, given how many packages on i686 eventually depend on numpy,
I think disabling these two tests on i686 (maybe in a phase so that they
continue to run on other architectures, see the recent powerpc commit on
core-updates) is justifiable. At worst we end up with numpy with broken
fortran bindings on i686. It is likely that pulseaudio will continue
to work nevertheless.

Andreas

Re: i686 core-updates failure.

[Kaelyn]

------- Original Message -------
On Friday, April 14th, 2023 at 8:28 AM, Andreas Enge <andreas@enge.fr> wrote:


> 
> 
> Am Thu, Apr 13, 2023 at 06:25:47PM +0200 schrieb Andreas Enge:
> 
> > For the Fortran bindings, I am hesitant as well. I think it is bad style
> > to disable a test just because it fails ;-) Maybe someone with experience
> > in numpy can speak up.
> 
> 
> Well, given how many packages on i686 eventually depend on numpy,
> I think disabling these two tests on i686 (maybe in a phase so that they
> continue to run on other architectures, see the recent powerpc commit on
> core-updates) is justifiable. At worst we end up with numpy with broken
> fortran bindings on i686. It is likely that pulseaudio will continue
> to work nevertheless.

I just sent in https://issues.guix.gnu.org/62843 to disable the two tests for i686 and armhf (disabling TestKind.test_all for armhf might not be needed, but the Gentoo package definition suggests the huge array test will fail for armhf as well).

Cheers,
Kaelyn

> 
> Andreas

Re: python-pytest on core-updates (was: i686 core-updates failure.)

[Andreas Enge]

Am Fri, Apr 14, 2023 at 08:05:46PM +0000 schrieb Kaelyn:
> I just sent in https://issues.guix.gnu.org/62843 to disable the two tests for i686 and armhf (disabling TestKind.test_all for armhf might not be needed, but the Gentoo package definition suggests the huge array test will fail for armhf as well).

Thanks for taking care of this! Disabling the large array test on all 32 bit
architectures sounds reasonable, and I think that disabling the fortran test
on armhf is a reasonable approach also given that we have no CI for this
architecture.

The recent master/staging merge apparently broke python-pytest even on
x86_64, see message below, which should be sorted out first.

Andreas


=================================== FAILURES ===================================
___________________ test_raise_assertion_error_raising_repr ____________________

pytester = <Pytester PosixPath('/tmp/guix-build-python-pytest-7.1.3.drv-0/pytest-of-nixbld/pytest-0/test_raise_assertion_error_raising_repr0')>

    def test_raise_assertion_error_raising_repr(pytester: Pytester) -> None:
        pytester.makepyfile(
            """
            class RaisingRepr(object):
                def __repr__(self):
                    raise Exception()
            def test_raising_repr():
                raise AssertionError(RaisingRepr())
        """
        )
        result = pytester.runpytest()
        if sys.version_info >= (3, 11):
            # python 3.11 has native support for un-str-able exceptions
            result.stdout.fnmatch_lines(
                ["E       AssertionError: <exception str() failed>"]
            )
        else:
>           result.stdout.fnmatch_lines(
                ["E       AssertionError: <unprintable AssertionError object>"]
            )
E           Failed: nomatch: 'E       AssertionError: <unprintable AssertionError object>'
E               and: '============================= test session starts =============================='
E               and: 'platform linux -- Python 3.10.7, pytest-7.1.3, pluggy-1.0.0'
E               and: 'rootdir: /tmp/guix-build-python-pytest-7.1.3.drv-0/pytest-of-nixbld/pytest-0/test_raise_assertion_error_raising_repr0'
E               and: 'collected 1 item'
E               and: ''
E               and: 'test_raise_assertion_error_raising_repr.py F                             [100%]'
E               and: ''
E               and: '=================================== FAILURES ==================================='
E               and: '______________________________ test_raising_repr _______________________________'
E               and: ''
E               and: '    def test_raising_repr():'
E               and: '>       raise AssertionError(RaisingRepr())'
E               and: 'E       AssertionError: <exception str() failed>'
E               and: ''
E               and: 'test_raise_assertion_error_raising_repr.py:5: AssertionError'
E               and: '=========================== short test summary info ============================'
E               and: 'FAILED test_raise_assertion_error_raising_repr.py::test_raising_repr - Assert...'
E               and: '============================== 1 failed in 0.01s ==============================='
E           remains unmatched: 'E       AssertionError: <unprintable AssertionError object>'

/tmp/guix-build-python-pytest-7.1.3.drv-0/pytest-7.1.3/testing/test_assertion.py:1655: Failed
----------------------------- Captured stdout call -----------------------------
============================= test session starts ==============================
platform linux -- Python 3.10.7, pytest-7.1.3, pluggy-1.0.0
rootdir: /tmp/guix-build-python-pytest-7.1.3.drv-0/pytest-of-nixbld/pytest-0/test_raise_assertion_error_raising_repr0
collected 1 item

test_raise_assertion_error_raising_repr.py F                             [100%]

=================================== FAILURES ===================================
______________________________ test_raising_repr _______________________________

    def test_raising_repr():
>       raise AssertionError(RaisingRepr())
E       AssertionError: <exception str() failed>

test_raise_assertion_error_raising_repr.py:5: AssertionError
=========================== short test summary info ============================
FAILED test_raise_assertion_error_raising_repr.py::test_raising_repr - Assert...
============================== 1 failed in 0.01s ===============================
=========================== short test summary info ============================
FAILED testing/test_assertion.py::test_raise_assertion_error_raising_repr - F...
= 1 failed, 3040 passed, 92 skipped, 15 deselected, 9 xfailed in 290.90s (0:04:50) =
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "pytest" arguments: ("-vv" "-k" " not test_argcomplete and not test_code_highlight and not test_color_yes") exit-status: 1 term-signal: #f stop-signal: #f>
phase `check' failed after 292.0 seconds
command "pytest" "-vv" "-k" " not test_argcomplete and not test_code_highlight and not test_color_yes" failed with status 1
builder for `/gnu/store/rd9aiszfkb8k96magk1y59hya79c9ch4-python-pytest-7.1.3.drv' failed with exit code 1
@ build-failed /gnu/store/rd9aiszfkb8k96magk1y59hya79c9ch4-python-pytest-7.1.3.drv - 1 builder for `/gnu/store/rd9aiszfkb8k96magk1y59hya79c9ch4-python-pytest-7.1.3.drv' failed with exit code 1
derivation '/gnu/store/rd9aiszfkb8k96magk1y59hya79c9ch4-python-pytest-7.1.3.drv' offloaded to '141.80.167.159' failed: build of `/gnu/store/rd9aiszfkb8k96magk1y59hya79c9ch4-python-pytest-7.1.3.drv' failed
build of /gnu/store/rd9aiszfkb8k96magk1y59hya79c9ch4-python-pytest-7.1.3.drv failed
View build log at '/var/log/guix/drvs/rd/9aiszfkb8k96magk1y59hya79c9ch4-python-pytest-7.1.3.drv.gz'.

Re: python-pytest on core-updates

[Andreas Enge]

Am Sat, Apr 15, 2023 at 01:20:07PM +0200 schrieb Andreas Enge:
> The recent master/staging merge apparently broke python-pytest even on
> x86_64, see message below, which should be sorted out first.

I tried to update to the more recent versions 7.2.2 and 7.3.1, but the
recipe does not work out of the box. For instance 7.2.2 fails with
...checking requirements: ERROR: pytest==7.2.2 DistributionNotFound(Requirement.parse('exceptiongroup>=1.0.0rc8'), {'pytest'})

However, we do have python-exceptiongroup@1.1.1, which should be fine.

I will let someone knowledgeable with python sort it out!

Andreas

[PATCH core-updates] gnu: python-pytest: Fix failing test_raising_repr.

[Josselin Poiret]

* gnu/packages/patches/pytest-fix-unstrable-exception-test.patch: Add new
patch from upstream.
* gnu/packages/check.scm (python-pytest): Use it.
* gnu/local.mk (dist_patch_DATA): Register it.
---
Hey Andreas and Kaelyn,

This should also fix it without bumping python-pytest to a new version (since it
has so many dependents, don't want to introduce new breakage now).

Best,
Josselin

 gnu/local.mk                                  |  1 +
 gnu/packages/check.scm                        |  3 +-
 .../pytest-fix-unstrable-exception-test.patch | 34 +++++++++++++++++++
 3 files changed, 37 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/pytest-fix-unstrable-exception-test.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index e29e09b688..73756a8c49 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1730,6 +1730,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/pybugz-stty.patch			\
   %D%/packages/patches/pygpgme-disable-problematic-tests.patch  \
   %D%/packages/patches/pyqt-configure.patch			\
+  %D%/packages/patches/pytest-fix-unstrable-exception-test.patch	\
   %D%/packages/patches/python-2-deterministic-build-info.patch	\
   %D%/packages/patches/python-2.7-adjust-tests.patch		\
   %D%/packages/patches/python-2.7-expat-compat.patch		\
diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm
index f388eb82a7..d072edbf51 100644
--- a/gnu/packages/check.scm
+++ b/gnu/packages/check.scm
@@ -1253,7 +1253,8 @@ (define-public python-pytest
        (uri (pypi-uri "pytest" version))
        (sha256
         (base32
-         "0f8c31v5r2kgjixvy267n0nhc4xsy65g3n9lz1i1377z5pn5ydjg"))))
+         "0f8c31v5r2kgjixvy267n0nhc4xsy65g3n9lz1i1377z5pn5ydjg"))
+       (patches (search-patches "pytest-fix-unstrable-exception-test.patch"))))
     (build-system python-build-system)
     (arguments
      (list
diff --git a/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch b/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch
new file mode 100644
index 0000000000..4d77786b77
--- /dev/null
+++ b/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch
@@ -0,0 +1,34 @@
+From b55e264a675f7621b8351e227b93742f19e01c7d Mon Sep 17 00:00:00 2001
+From: Daniel Valenzuela <dsvalenzuela@uc.cl>
+Date: Wed, 9 Nov 2022 19:43:10 -0300
+Subject: [PATCH] Fix test_raising_repr test
+
+Closes #10473
+
+Python <3.11 versions depend on `exceptiongroup>=1.0.0rc8`, and they released version `1.0.1`
+6 days ago (2022/11/03) that as a side-effect changed the output of exceptions.
+---
+ testing/test_assertion.py | 10 +---------
+ 1 file changed, 1 insertion(+), 9 deletions(-)
+
+diff --git a/testing/test_assertion.py b/testing/test_assertion.py
+index d8844f2e41..7574592210 100644
+--- a/testing/test_assertion.py
++++ b/testing/test_assertion.py
+@@ -1664,15 +1664,7 @@ def test_raising_repr():
+     """
+     )
+     result = pytester.runpytest()
+-    if sys.version_info >= (3, 11):
+-        # python 3.11 has native support for un-str-able exceptions
+-        result.stdout.fnmatch_lines(
+-            ["E       AssertionError: <exception str() failed>"]
+-        )
+-    else:
+-        result.stdout.fnmatch_lines(
+-            ["E       AssertionError: <unprintable AssertionError object>"]
+-        )
++    result.stdout.fnmatch_lines(["E       AssertionError: <exception str() failed>"])
+ 
+ 
+ def test_issue_1944(pytester: Pytester) -> None:

base-commit: 7ccf9943029747d4ba97160214f895b365511278
-- 
2.39.2

Re: [PATCH core-updates] gnu: python-pytest: Fix failing test_raising_repr.

[Kaelyn]

------- Original Message -------
On Saturday, April 15th, 2023 at 2:08 PM, Josselin Poiret <dev@jpoiret.xyz> wrote:

> 
> * gnu/packages/patches/pytest-fix-unstrable-exception-test.patch: Add new
> patch from upstream.
> * gnu/packages/check.scm (python-pytest): Use it.
> * gnu/local.mk (dist_patch_DATA): Register it.
> ---
> Hey Andreas and Kaelyn,
> 
> This should also fix it without bumping python-pytest to a new version (since it
> has so many dependents, don't want to introduce new breakage now).
> 
> Best,
> Josselin
> 
> gnu/local.mk | 1 +
> gnu/packages/check.scm | 3 +-
> .../pytest-fix-unstrable-exception-test.patch | 34 +++++++++++++++++++
> 3 files changed, 37 insertions(+), 1 deletion(-)
> create mode 100644 gnu/packages/patches/pytest-fix-unstrable-exception-test.patch
> 
> diff --git a/gnu/local.mk b/gnu/local.mk
> index e29e09b688..73756a8c49 100644
> --- a/gnu/local.mk
> +++ b/gnu/local.mk
> @@ -1730,6 +1730,7 @@ dist_patch_DATA = \
> %D%/packages/patches/pybugz-stty.patch \
> %D%/packages/patches/pygpgme-disable-problematic-tests.patch \
> %D%/packages/patches/pyqt-configure.patch \
> + %D%/packages/patches/pytest-fix-unstrable-exception-test.patch \
> %D%/packages/patches/python-2-deterministic-build-info.patch \
> %D%/packages/patches/python-2.7-adjust-tests.patch \
> %D%/packages/patches/python-2.7-expat-compat.patch \
> diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm
> index f388eb82a7..d072edbf51 100644
> --- a/gnu/packages/check.scm
> +++ b/gnu/packages/check.scm
> @@ -1253,7 +1253,8 @@ (define-public python-pytest
> (uri (pypi-uri "pytest" version))
> (sha256
> (base32
> - "0f8c31v5r2kgjixvy267n0nhc4xsy65g3n9lz1i1377z5pn5ydjg"))))
> + "0f8c31v5r2kgjixvy267n0nhc4xsy65g3n9lz1i1377z5pn5ydjg"))
> + (patches (search-patches "pytest-fix-unstrable-exception-test.patch"))))
> (build-system python-build-system)
> (arguments
> (list
> diff --git a/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch b/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch
> new file mode 100644
> index 0000000000..4d77786b77
> --- /dev/null
> +++ b/gnu/packages/patches/pytest-fix-unstrable-exception-test.patch
> @@ -0,0 +1,34 @@
> +From b55e264a675f7621b8351e227b93742f19e01c7d Mon Sep 17 00:00:00 2001
> +From: Daniel Valenzuela dsvalenzuela@uc.cl
> 
> +Date: Wed, 9 Nov 2022 19:43:10 -0300
> +Subject: [PATCH] Fix test_raising_repr test
> +
> +Closes #10473
> +
> +Python <3.11 versions depend on `exceptiongroup>=1.0.0rc8`, and they released version `1.0.1`
> 
> +6 days ago (2022/11/03) that as a side-effect changed the output of exceptions.
> +---
> + testing/test_assertion.py | 10 +---------
> + 1 file changed, 1 insertion(+), 9 deletions(-)
> +
> +diff --git a/testing/test_assertion.py b/testing/test_assertion.py
> +index d8844f2e41..7574592210 100644
> +--- a/testing/test_assertion.py
> ++++ b/testing/test_assertion.py
> +@@ -1664,15 +1664,7 @@ def test_raising_repr():
> + """
> + )
> + result = pytester.runpytest()
> +- if sys.version_info >= (3, 11):
> 
> +- # python 3.11 has native support for un-str-able exceptions
> +- result.stdout.fnmatch_lines(
> +- ["E AssertionError: <exception str() failed>"]
> 
> +- )
> +- else:
> +- result.stdout.fnmatch_lines(
> +- ["E AssertionError: <unprintable AssertionError object>"]
> 
> +- )
> ++ result.stdout.fnmatch_lines(["E AssertionError: <exception str() failed>"])
> 
> +
> +
> + def test_issue_1944(pytester: Pytester) -> None:
> 
> 
> base-commit: 7ccf9943029747d4ba97160214f895b365511278
> --
> 2.39.2

Hi Josselin,

I just confirmed locally that the patch fixes the python-pytest test failure. Thank you for figuring out the failure!

Cheers,
Kaelyn

Re: [PATCH core-updates] gnu: python-pytest: Fix failing test_raising_repr.

[Andreas Enge]

Hello Josselin,

Am Sat, Apr 15, 2023 at 04:08:18PM +0200 schrieb Josselin Poiret:
> This should also fix it without bumping python-pytest to a new version (since it
> has so many dependents, don't want to introduce new breakage now).

in the meantime Maxim updated pytest to the latest version, but then numpy
fails on i686 *and* x86_64, because its three inputs
  /gnu/store/3wq4gfh21kfgda6gv6wnp015jhd8nnf2-python-pytest-xdist-2.5.0.drv
  /gnu/store/xc3b4yw9m69lgn9i82sy7l5cd6w4yvaj-python-execnet-1.9.0.drv
  /gnu/store/xp6lkn92py94mb2dxig25n1l36j87yp9-python-pytest-forked-1.6.0.drv
all fail...

I will try to revert the commit that updates pytest and apply yours instead
to see if this is the safer route.

Andreas

Re: [PATCH core-updates] gnu: python-pytest: Fix failing test_raising_repr.

[Andreas Enge]

Am Sat, Apr 15, 2023 at 09:59:00PM +0200 schrieb Andreas Enge:
> I will try to revert the commit that updates pytest and apply yours instead
> to see if this is the safer route.

It was, in this way I get a working python-numpy on x86_64 and i686.
I think we should be rather conservative now. The update to the latest
version of python-pytest can be done after the core-updates merge
on a feature branch.

Andreas

Re: python-pytest on core-updates (was: i686 core-updates failure.)

[Andreas Enge]

Am Sat, Apr 15, 2023 at 01:20:07PM +0200 schrieb Andreas Enge:
> The recent master/staging merge apparently broke python-pytest even on
> x86_64, see message below, which should be sorted out first.

With pytest repaired, your patch builds numpy successfully on both x86
architectures. Pushed, thanks again!

Andreas

Re: i686 core-updates failure.

[Simon Tournier]

Hi,

CC: teams for each ecosystem.


About i686 core-updates failures, well I do not know where to start :-)
when giving a look at:

https://ci.guix.gnu.org/eval/391720/dashboard?system=i686-linux


1. Java

Well, it seems broken because wget-1.21.3
<https://ci.guix.gnu.org/build/709528/log/raw>.

Any taker?


2. Python

Well, python-numpy-1.23.2 seems the first to tackle for improving the
situation. <https://ci.guix.gnu.org/build/712672/log/raw>

Any taker?



3. Haskell:

Well, Haskell is broken because ghc-8.10.7 is broken with:

--8<---------------cut here---------------start------------->8---
building of `/gnu/store/fk4nlvkdl0qgafybd8kbg2c9a4vq5fz4-ghc-8.10.7.drv' timed out after 3600 seconds of silence
@ build-failed /gnu/store/fk4nlvkdl0qgafybd8kbg2c9a4vq5fz4-ghc-8.10.7.drv - timeout
--8<---------------cut here---------------end--------------->8---

Note that Haskell is also broken on master for a similar error with
ghc-9.2.5 <https://ci.guix.gnu.org/build/478772/log/raw>.

Therefore, the question is: do we drop Haskell for i686?


4. R

Corollary of #3, pandoc is broken and so many R packages too.

Well, the situation seems similar with master for Haskell and R
packages.


Cheers,
simon

Re: i686 core-updates failure.

[jgart]

My thoughts on this are that unless someone has the time to maintain those broken packages we should just remove them and clean up shop a bit.

Is there a reason to keep around the broken packages?

A news entry about the removals would also be helpful if we decide to remove them in order for people to know and so future contributors can pick up the work if they are interested in maintaining them at a later date.

Anyways, one idea for what to do, WDYT

Re: i686 core-updates failure.

[Andreas Enge]

Am Thu, Apr 13, 2023 at 01:23:15PM +0000 schrieb jgart:
> My thoughts on this are that unless someone has the time to maintain those broken packages we should just remove them and clean up shop a bit.
> Is there a reason to keep around the broken packages?

Well, we can certainly remove a few hopeless, outdated, non-maintained
broken packages. But if we start to remove packages such as wget, and
Java, and Haskell, and much of R, and big chunks of Python, for i686,
this amounts to removing the architecture altogether. It is a decision
we may want to take at some point in time, but we should not do so casually.
And definitely not in this core-updates merge.

One argument for keeping i686 was that problems there were often indicative
of problems in "more exotic" architectures, whereas i686 is relatively easy
to build on x86_64 without specific (often slow) hardware. I am not sure
if this still holds for the 32 bit problems we have seen recently; so there
is a certain argument to make for removing the 32 bit architectures i686
and armhf (x86_64 will soon celebrate its 25th birthday, aarch64 is half
as old; I do not expect much hardware for the corresponding 32 bit
architectures to be around any more).

Andreas

Re: i686 core-updates failure.

[Csepp]

Andreas Enge <andreas@enge.fr> writes:

> Am Thu, Apr 13, 2023 at 01:23:15PM +0000 schrieb jgart:
>> My thoughts on this are that unless someone has the time to maintain
>> those broken packages we should just remove them and clean up shop a
>> bit.
>> Is there a reason to keep around the broken packages?
>
> Well, we can certainly remove a few hopeless, outdated, non-maintained
> broken packages. But if we start to remove packages such as wget, and
> Java, and Haskell, and much of R, and big chunks of Python, for i686,
> this amounts to removing the architecture altogether. It is a decision
> we may want to take at some point in time, but we should not do so casually.
> And definitely not in this core-updates merge.
>
> One argument for keeping i686 was that problems there were often indicative
> of problems in "more exotic" architectures, whereas i686 is relatively easy
> to build on x86_64 without specific (often slow) hardware. I am not sure
> if this still holds for the 32 bit problems we have seen recently; so there
> is a certain argument to make for removing the 32 bit architectures i686
> and armhf (x86_64 will soon celebrate its 25th birthday, aarch64 is half
> as old; I do not expect much hardware for the corresponding 32 bit
> architectures to be around any more).
>
> Andreas

That is a pretty terrible direction to take.  There are still plenty of
people who rely on old hardware who can't afford to buy new machines.
When discussing these issues, it is important to keep in mind that the
people who have enough spare time to contribute to this project and hang
out on the mailing lists come from a rather privileged background.  What
you think is reasonable to categorize as obsolete might be the only
machine a poor family could afford on the second hand market.
If Linux distros keep dropping support for old hardware, then they are
not liberatory, no matter how "free" their licenses are.

We are also in the middle of a massive climate crisis, so we should aim
to prolong the usefulness of existing hardware and not give in to this
planned obsolescence BS.

Re: i686 core-updates failure.

[Simon Tournier]

Hi,

On ven., 14 avril 2023 at 17:12, Csepp <raingloom@riseup.net> wrote:

> That is a pretty terrible direction to take.  There are still plenty of
> people who rely on old hardware who can't afford to buy new machines.
> When discussing these issues, it is important to keep in mind that the
> people who have enough spare time to contribute to this project and hang
> out on the mailing lists come from a rather privileged background.  What
> you think is reasonable to categorize as obsolete might be the only
> machine a poor family could afford on the second hand market.
> If Linux distros keep dropping support for old hardware, then they are
> not liberatory, no matter how "free" their licenses are.
>
> We are also in the middle of a massive climate crisis, so we should aim
> to prolong the usefulness of existing hardware and not give in to this
> planned obsolescence BS.

At some point we have to make choices or trade-off.  Because we have two
incompatible directions.  The maintenance is very hard: on one hand, the
rate of updates is very high and on the other hand the person-power for
doing the job is low.

Somehow, it’s not new.  Mark already pointed the issue with non-x86_64
architectures, for instance, quoting [1]:

        In my experience, Guix is already moving far too fast to be usable on
        less popular architectures.  I have some knowledge of this.  Years ago,
        I made a serious effort to make Guix usable on non-Intel systems.  When
        Guix was young, I initiated its first two ports to non-Intel
        architectures: mips64el-linux and armhf-linux, and I tried to actually
        use Guix on those systems in practice.  I found that my system was very
        frequently broken by upstream updates, and that we didn't have nearly
        enough developer energy to keep up with fixing those problems.

        I've come to believe that having Guix work well on non-Intel systems is,
        in practice, incompatible with the rate at which we update our packages.
        I'm not sure that even Debian would have enough energy to keep less
        popular architecures working well, given our practices.  I raised this
        issue on guix-devel a few times over the years, but it became clear that
        the desire in this community to keep packages aggressively updated far
        outweighs any interest in supporting non-Intel systems.

        Ultimately, I gave up.  In my opinion, Guix has never achieved usability
        as a desktop system on non-Intel systems.  Therefore, the Guix community
        is unable to attract many developers who want a distro that supports
        non-Intel systems well.  Our community has thus become dominated by
        Intel users, and there's unsufficient political will to adopt policies
        that would enable us to provide a usable system for non-Intel users.

        1: https://yhetil.org/guix/87v99qit39.fsf@netris.org
        Re: [opinion] CVE-patching is not sufficient for package security patching
        Tue, 16 Mar 2021 19:19:59 -0400
        id:87v99qit39.fsf@netris.org

My opinion, FWIW, is to move less fast, as explained in [2].  Otherwise
it appears to me impossible to have both very up-to-date packages and
running on various architectures.

2: https://yhetil.org/guix/86mtv29erk.fsf@gmail.com


Cheers,
simon

PS: “We are in the middle of a massive climate crisis” implies an end;
sadly it will not be the case: we are at the beginning of a massive
climate change.

Re: i686 core-updates failure.

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi everyone,

> At some point we have to make choices
>
>         Guix has never achieved usability as a desktop system on non-Intel
>         systems.
>
>         I've come to believe that having Guix work well on non-Intel systems is,
>         in practice, incompatible with the rate at which we update our packages.

There are many good reasons to drop a machine type but I'm not sure
that's one. In my book, a poorly working Guix system is still better
than having none at all.

Kind regards
Felix Lechner

P.S. Porting to exotic architectures can also expose interesting bugs
that make software more portable in the future.

Re: i686 core-updates failure.

[Simon Tournier]

Hi jgart,

On Thu, 13 Apr 2023 at 13:23, "jgart" <jgart@dismail.de> wrote:

> Is there a reason to keep around the broken packages?

Euh, maybe you have missed what the branch core-updates is. :-)

For packages with many dependents, it is not possible to update them
directly in master, because of two main reasons: 1) the build farm would
not be able to build in timely manner so many substitutes would be
lacking after each push and 2) it would be hard if not impossible to
know before the push the impact of one change over the complete list of
dependents.

Instead, we push these changes concerning some packages with many
dependents – considered as the “core” of Guix – to the branch
core-updates.  But because each change impacts large and intensive
rebuilds, this branch is not continuously built.

Therefore, the state of this branch core-updates is often poor; meaning
that many packages are potentially broken.

At some point, when enough changes are pushed into this core-updates
branch – well, it’s more when someone takes the lead for this branch –
we set the CI to re-build all the packages of the core-updates branch.

Then, we detect broken packages, often impacted by unrelated changes as
ungrafts and co., and we try to fix them all before merging this
core-updates branch into the master branch.

Thanks to the tireless Andreas’s lead over the past months, we are at
the point where the core-updates will be merged soon to master.

Considering the architecture x86_64, the state is almost good!
Yeah! \o/  Please give a look at « A Joyous Core-Updates Week-End 🎉 »
email which provides details about how to help and test.
<https://lists.gnu.org/archive/html/guix-devel/2023-04/msg00121.html>


Considering other architectures as i686, that’s not the case.  See [1].
The state of non-x86_64 architectures is weak compared to the usual
standards for merging.

All in all, no, it is possible to drop python-numpy for example [2]. :-)

Hope that makes sense.

1: https://ci.guix.gnu.org/eval/391720/dashboard?system=i686-linux
2: https://ci.guix.gnu.org/build/712672/details

Cheers,
simon

Re: i686 core-updates failure.

[Simon Tournier]

On Thu, 13 Apr 2023 at 17:31, Simon Tournier <zimon.toutoune@gmail.com> wrote:

> All in all, no, it is possible to drop python-numpy for example [2]. :-)

No, it is *not* possible!  (My fingers had not been enough fast. ;-))

Re: i686 core-updates failure.

[Ricardo Wurmus]

"jgart" <jgart@dismail.de> writes:

> My thoughts on this are that unless someone has the time to maintain those broken packages we should just remove them and clean up shop a bit.
>
> Is there a reason to keep around the broken packages?

Definitely not!

It’s been difficult enough to get them added in the first place.  Rather
than undoing years of past work just because it’s inconvenient to do
maintenance we should increase the number of people who feel responsible
to help with maintenance.

I know that I won’t continue contributing to Guix if packages are
removed with nonchalance.  We speak of removing Pandoc, Haskell, and
most of R.  That would be nothing short of reckless.

Yes, this is only i686 and it’s worth thinking about whether to continue
supporting this architecture when developers seemingly don’t care about
it any more.  But just removing foundational packages is akin to just
giving up.

-- 
Ricardo

Re: i686 core-updates failure.

[Greg Hogan]

On Thu, Apr 13, 2023 at 11:53 AM Ricardo Wurmus <rekado@elephly.net> wrote:
>
> Yes, this is only i686 and it’s worth thinking about whether to continue
> supporting this architecture when developers seemingly don’t care about
> it any more.  But just removing foundational packages is akin to just
> giving up.

We have package->supported-systems, although the package reference
does not define "supported system".

For test failures could we not disable tests conditional on the
architecture? Tests enabled/disabled could be presented to the user in
guix search/show.

Greg

Re: i686 core-updates failure.

[Simon Tournier]

Hi Ricardo, all,

I totally agree with your words.  A minor comment about the merge of
core-updates…

On Thu, 13 Apr 2023 at 17:47, Ricardo Wurmus <rekado@elephly.net> wrote:

> I know that I won’t continue contributing to Guix if packages are
> removed with nonchalance.  We speak of removing Pandoc, Haskell, and
> most of R.  That would be nothing short of reckless.

…well, the current bad shape of master for non-x86_64 should not be
blocking for the core-updates merge, IMHO.

For instance, Pandoc is already broken for i686 on master.  Julia too!

Aside, I agree the situation must be improved.  Therefore…


…Concerning Julia, it seems about the configuration of the build farm,

--8<---------------cut here---------------start------------->8---
Error During Test at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/test/testdefs.jl:21
  Got exception outside of a @test
  LoadError: OutOfMemoryError()
--8<---------------cut here---------------end--------------->8---

Is it possible that Berlin is missing memory?


…Concerning GHC@9.2, it is also about the build farm,

--8<---------------cut here---------------start------------->8---
building of `/gnu/store/in0gfsahn1z6ym232wg3cayzim51zng8-ghc-9.2.5.drv' timed out after 3600 seconds of silence
@ build-failed /gnu/store/in0gfsahn1z6ym232wg3cayzim51zng8-ghc-9.2.5.drv - timeout
--8<---------------cut here---------------end--------------->8---

Well, so maybe it is fixable by extending the timeout.


Once Julia fixed on core-updates for x86_64 (the patch is almost ready,
I am currently checking it will have the expected effect ;-)), then I
will give a look for Julia on i686; probably tomorrow.


About GHC, I am trying to build ghc-8.10.7 on core-updates for i686.  It
could be nice to fix it.  Well, I will be happy if someone™ beats me. ;-)


1: https://ci.guix.gnu.org/eval/394617/dashboard?system=i686-linux


Cheers,
simon

Re: i686 core-updates failure.

[Ricardo Wurmus]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> On Thu, 13 Apr 2023 at 17:47, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> I know that I won’t continue contributing to Guix if packages are
>> removed with nonchalance.  We speak of removing Pandoc, Haskell, and
>> most of R.  That would be nothing short of reckless.
>
> …well, the current bad shape of master for non-x86_64 should not be
> blocking for the core-updates merge, IMHO.

Agreed.

> Aside, I agree the situation must be improved.  Therefore…

FWIW I’m all tied up trying to fix packages on core-updates, rust on
aarch64, and repairing aarch64 build nodes in the data center, so I
won’t be able to commit any time to work on i686 at this point.

-- 
Ricardo

Re: i686 core-updates failure.

[Lars-Dominik Braun]

Hi Simon,

> About GHC, I am trying to build ghc-8.10.7 on core-updates for i686.  It
> could be nice to fix it.  Well, I will be happy if someone™ beats me. ;-)

GHC 8.10.7 on i686 built fine for me locally with all timeouts
disabled. 9.2.5 is not done yet, but is slowly processing through the test
suite as well for me. Can someone build both manually on the CI servers
maybe?

Lars

Re: i686 core-updates failure.

[Simon Tournier]

Hi Lars,

On Thu, 13 Apr 2023 at 22:02, Lars-Dominik Braun <lars@6xq.net> wrote:

> > About GHC, I am trying to build ghc-8.10.7 on core-updates for i686.  It
> > could be nice to fix it.  Well, I will be happy if someone™ beats me. ;-)
>
> GHC 8.10.7 on i686 built fine for me locally with all timeouts
> disabled. 9.2.5 is not done yet, but is slowly processing through the test
> suite as well for me. Can someone build both manually on the CI servers
> maybe?

Thanks for checking.  It also builds for me locally.  So I guess,

+    (properties
+     ;; 3 hours to avoid time-out in the check phase.
+     `((max-silent-time . 10800)))

would be helpful.  And it should be inherited by 9.2.5 so it should
also build on CI.  WDYT?


Cheers,
simon

Re: i686 core-updates failure.

[Andreas Enge]

Am Thu, Apr 13, 2023 at 10:15:14PM +0200 schrieb Simon Tournier:
> Thanks for checking.  It also builds for me locally.  So I guess,
> +    (properties
> +     ;; 3 hours to avoid time-out in the check phase.
> +     `((max-silent-time . 10800)))
> would be helpful.

I may misunderstand something, but while ghc takes a long time for its
tests, it is not silent - it regularly outputs test results. I do not
think it really is silent for one hour. So I am not sure this would help.
Maybe some transient build failure?

I have just restarted the builds in cuirass.

Andreas

Re: i686 core-updates failure.

[Simon Tournier]

On Thu, 13 Apr 2023 at 22:45, Andreas Enge <andreas@enge.fr> wrote:
> Am Thu, Apr 13, 2023 at 10:15:14PM +0200 schrieb Simon Tournier:
> > Thanks for checking.  It also builds for me locally.  So I guess,
> > +    (properties
> > +     ;; 3 hours to avoid time-out in the check phase.
> > +     `((max-silent-time . 10800)))
> > would be helpful.
>
> I may misunderstand something, but while ghc takes a long time for its
> tests, it is not silent - it regularly outputs test results. I do not
> think it really is silent for one hour. So I am not sure this would help.
> Maybe some transient build failure?

Well, maybe it is transient because an issue with Berlin but the
failure [1] is because it was silent for one hour:

--8<---------------cut here---------------start------------->8---
building of `/gnu/store/i6h8q8jgqxli3mkfyw7lpwzf7gq6mrxk-ghc-8.10.7.drv'
timed out after 3600 seconds of silence
@ build-failed /gnu/store/i6h8q8jgqxli3mkfyw7lpwzf7gq6mrxk-ghc-8.10.7.drv
- timeout
--8<---------------cut here---------------end--------------->8---


And I think the patch would avoid such transient error.  Note it
similar for ghc-9 for i686 on master [2]; it is maybe not as transient
as it seems. ;-)

1: https://ci.guix.gnu.org/build/718809/log/raw
2: https://ci.guix.gnu.org/build/478772/log/raw

> I have just restarted the builds in cuirass.

Good, let see. :-)

Cheers,
simon

Re: i686 core-updates failure.

[Andreas Enge]

Am Thu, Apr 13, 2023 at 10:57:38PM +0200 schrieb Simon Tournier:
> --8<---------------cut here---------------start------------->8---
> building of `/gnu/store/i6h8q8jgqxli3mkfyw7lpwzf7gq6mrxk-ghc-8.10.7.drv'
> timed out after 3600 seconds of silence
> @ build-failed /gnu/store/i6h8q8jgqxli3mkfyw7lpwzf7gq6mrxk-ghc-8.10.7.drv
> - timeout
> --8<---------------cut here---------------end--------------->8---

But the last output was
=====> galois_raytrace(normal) 4154 of 7358 [0, 0, 0]
after about 2 hours of builds. So each test takes only a few seconds and
then outputs something. So my guess would rather be that one hour of silence
indicates that a test is stuck, and likely to be stuck also after
three hours.

I have just started a manual build on berlin and will keep you updated.

Andreas

Re: i686 core-updates failure.

[Simon Tournier]

Hi Andreas,

On Fri, 14 Apr 2023 at 10:25, Andreas Enge <andreas@enge.fr> wrote:

> But the last output was
> =====> galois_raytrace(normal) 4154 of 7358 [0, 0, 0]
> after about 2 hours of builds. So each test takes only a few seconds and
> then outputs something. So my guess would rather be that one hour of silence
> indicates that a test is stuck, and likely to be stuck also after
> three hours.

Maybe, who knows. :-)

My point is: the failure is not transient.  Well, the build still does
not pass <https://ci.guix.gnu.org/build/804101/details>.


> I have just started a manual build on berlin and will keep you updated.

Fingers crossed. :-)

Cheers,
simon

Re: i686 core-updates failure.

[Andreas Enge]

Am Fri, Apr 14, 2023 at 10:25:25AM +0200 schrieb Andreas Enge:
> I have just started a manual build on berlin and will keep you updated.

This also did not work - timeout after 3600 seconds of silence,
the property is overwritten by the guix daemon, I think.
Anyway, as said before, I rather think this is a real problem with
the tests (maybe depending on some special situation on berlin if you
could build it on your machine) than a genuine silence.

Andreas

Re: i686 core-updates failure.

[Lars-Dominik Braun]

Hi Andreas,

> This also did not work - timeout after 3600 seconds of silence,
> the property is overwritten by the guix daemon, I think.
> Anyway, as said before, I rather think this is a real problem with
> the tests (maybe depending on some special situation on berlin if you
> could build it on your machine) than a genuine silence.

do you have a log file indicating where exactly it failed?

Thanks,
Lars

ghc in core-updates on i686

[Andreas Enge]

Hello Lars,

Am Fri, Apr 14, 2023 at 08:40:32PM +0200 schrieb Lars-Dominik Braun:
> do you have a log file indicating where exactly it failed?

here is one:
   http://localhost:8081/build/804101/log/raw

There is consistently this timeout after printing the lines
=====> galois_raytrace(normal) 4154 of 7358 [0, 0, 0]
cd "programs/galois_raytrace/galois_raytrace.run" &&  "/tmp/guix-build-ghc-8.10.7.drv-0/ghc-8.10.7/inplace/bin/ghc-stage2" --make -o galois_raytrace Main -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output  -package parsec<
cd "programs/galois_raytrace/galois_raytrace.run" && ./galois_raytrace   <
building of `/gnu/store/fk4nlvkdl0qgafybd8kbg2c9a4vq5fz4-ghc-8.10.7.drv' timed out after 3600 seconds of silence
@ build-failed /gnu/store/fk4nlvkdl0qgafybd8kbg2c9a4vq5fz4-ghc-8.10.7.drv - timeout

Andreas

Re: i686 core-updates failure.

[Lars-Dominik Braun]

Hi Simon,

> Thanks for checking.  It also builds for me locally.  So I guess,
> 
> +    (properties
> +     ;; 3 hours to avoid time-out in the check phase.
> +     `((max-silent-time . 10800)))
> 
> would be helpful.  And it should be inherited by 9.2.5 so it should
> also build on CI.  WDYT?

last time I tried this I was told Cuirass does not respect this property,
so I’ll leave your patch untouched, hoping someone more knowledgable
will push it – if it works.

Lars

Re: i686 core-updates failure.

[Simon Tournier]

Hi Lars,

On ven., 14 avril 2023 at 12:49, Lars-Dominik Braun <lars@6xq.net> wrote:

> last time I tried this I was told Cuirass does not respect this property,
> so I’ll leave your patch untouched, hoping someone more knowledgable
> will push it – if it works.

Ah ok… I did not know.  Hum, I thought it had been used for camlboot for
instance.  Is this behaviour about ’max-silent-time’ changed recently?


Cheers,
simon

wget (was Re: i686 core-updates failure.)

[Simon Tournier]

Hi,

Fixing ’wget’ for i686 would help for Java and Julia.  Well, currently
’wget’ is broken on core-updates for i686,

    https://ci.guix.gnu.org/build/709528/details

And the 5 error seem similar (missing file?), i.e., read,

--8<---------------cut here---------------start------------->8---
FAIL: Test-hsts
===============

Setting --no-config (noconfig) to 1
Setting --hsts-file (hstsfile) to /tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
Setting --ca-certificate (cacertificate) to /tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem
DEBUG output created by Wget 1.21.3 on linux-gnu.

Reading HSTS entries from /tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
URI encoding = 'ANSI_X3.4-1968'
converted 'http://localhost:41133/hw' (ANSI_X3.4-1968) -> 'http://localhost:41133/hw' (UTF-8)
URL transformed to HTTPS due to an HSTS policy
Converted file name 'hw' (UTF-8) -> 'hw' (ANSI_X3.4-1968)
--2023-04-06 18:17:39--  https://localhost:41133/hw
Loaded CA certificate '/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem'
Certificates loaded: 1
Resolving localhost (localhost)... 127.0.0.1
Caching localhost => 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:41133... connected.
Created socket 3.
Releasing 0x080e1190 (new refcount 1).
The certificate has not yet been activated
Saving HSTS entries to /tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
1
Running Test Test-hsts.py
/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/src/wget --debug --no-config --hsts-file=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv --ca-certificate=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem http://localhost:41133/hw 
['/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/src/wget', '--debug', '--no-config', '--hsts-file=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv', '--ca-certificate=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem', 'http://localhost:41133/hw']
{'HOME': '/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/Test-hsts.py-test'}
Error: Expected file hw not found..
Traceback (most recent call last):
  File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/./Test-hsts.py", line 76, in <module>
    err = test.begin()
  File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/http_test.py", line 41, in begin
    self.do_test()
  File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/base_test.py", line 198, in do_test
    self.post_hook_call()
  File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/base_test.py", line 217, in post_hook_call
    self.hook_call(self.post_configs, 'Post Test Function')
  File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/base_test.py", line 207, in hook_call
    conf.find_conf(conf_name)(conf_arg)(self)
  File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/conf/expected_files.py", line 55, in __call__
    raise TestFailed('Expected file %s not found.' % file.name)
exc.test_failed.TestFailed: Expected file hw not found.
FAIL Test-hsts.py (exit status: 1)
--8<---------------cut here---------------end--------------->8---


Any idea?


Cheers,
simon

Re: wget (was Re: i686 core-updates failure.)

[Andreas Enge]

Am Thu, Apr 13, 2023 at 10:33:28PM +0200 schrieb Simon Tournier:
> Fixing ’wget’ for i686 would help for Java and Julia.  Well, currently
> ’wget’ is broken on core-updates for i686,
> And the 5 error seem similar (missing file?), i.e., read,
> Any idea?

I had a look, but no idea :(

Except for one: Would it make sense to try to depend on wget2 instead?

Andreas

Re: wget (was Re: i686 core-updates failure.)

[Simon Tournier]

On Thu, 13 Apr 2023 at 22:37, Andreas Enge <andreas@enge.fr> wrote:

> Except for one: Would it make sense to try to depend on wget2 instead?

I have no idea. )-:

Do you mean replace all the occurrences of 'wget' by 'wget2'?  Maybe
only the occurrences of 'wget' by 'wget2' for the current broken
packages on i686?

Well, it would be better to fix 'wget'. (-:

Cheers,
simon

Re: wget

[Andreas Enge]

Am Thu, Apr 13, 2023 at 10:43:31PM +0200 schrieb Simon Tournier:
> Do you mean replace all the occurrences of 'wget' by 'wget2'?  Maybe
> only the occurrences of 'wget' by 'wget2' for the current broken
> packages on i686?

Yes, assuming that wget2 is the future and wget a thing of the past.
But it is not very likely to work; the binary is also called "wget2",
so it is really a different project, and can only work if it is checked
for by the package to be built.

Andreas

Re: wget (was Re: i686 core-updates failure.)

[Maxim Cournoyer]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> Fixing ’wget’ for i686 would help for Java and Julia.  Well, currently
> ’wget’ is broken on core-updates for i686,
>
>     https://ci.guix.gnu.org/build/709528/details
>
> And the 5 error seem similar (missing file?), i.e., read,
>
> FAIL: Test-hsts
> ===============
>
> Setting --no-config (noconfig) to 1
> Setting --hsts-file (hstsfile) to /tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
> Setting --ca-certificate (cacertificate) to /tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem
> DEBUG output created by Wget 1.21.3 on linux-gnu.
>
> Reading HSTS entries from /tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
> URI encoding = 'ANSI_X3.4-1968'
> converted 'http://localhost:41133/hw' (ANSI_X3.4-1968) -> 'http://localhost:41133/hw' (UTF-8)
> URL transformed to HTTPS due to an HSTS policy
> Converted file name 'hw' (UTF-8) -> 'hw' (ANSI_X3.4-1968)
> --2023-04-06 18:17:39--  https://localhost:41133/hw
> Loaded CA certificate '/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem'
> Certificates loaded: 1
> Resolving localhost (localhost)... 127.0.0.1
> Caching localhost => 127.0.0.1
> Connecting to localhost (localhost)|127.0.0.1|:41133... connected.
> Created socket 3.
> Releasing 0x080e1190 (new refcount 1).
> The certificate has not yet been activated
> Saving HSTS entries to /tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv
> 1
> Running Test Test-hsts.py
> /tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/src/wget --debug --no-config --hsts-file=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv --ca-certificate=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem http://localhost:41133/hw 
> ['/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/src/wget', '--debug', '--no-config', '--hsts-file=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/.wget-hsts-testenv', '--ca-certificate=/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/certs/ca-cert.pem', 'http://localhost:41133/hw']
> {'HOME': '/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/Test-hsts.py-test'}
> Error: Expected file hw not found..
> Traceback (most recent call last):
>   File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/./Test-hsts.py", line 76, in <module>
>     err = test.begin()
>   File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/http_test.py", line 41, in begin
>     self.do_test()
>   File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/base_test.py", line 198, in do_test
>     self.post_hook_call()
>   File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/base_test.py", line 217, in post_hook_call
>     self.hook_call(self.post_configs, 'Post Test Function')
>   File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/test/base_test.py", line 207, in hook_call
>     conf.find_conf(conf_name)(conf_arg)(self)
>   File "/tmp/guix-build-wget-1.21.3.drv-0/wget-1.21.3/testenv/conf/expected_files.py", line 55, in __call__
>     raise TestFailed('Expected file %s not found.' % file.name)
> exc.test_failed.TestFailed: Expected file hw not found.
> FAIL Test-hsts.py (exit status: 1)
>
>
> Any idea?

None, but are there wget uptsream reports about the problem?

-- 
Thanks,
Maxim

Re: wget (was Re: i686 core-updates failure.)

[Andreas Enge]

Am Fri, Apr 14, 2023 at 08:51:18PM -0400 schrieb Maxim Cournoyer:
> None, but are there wget uptsream reports about the problem?

I do not see anything at
   https://gitlab.com/gnuwget/wget

Andreas

Re: wget (was Re: i686 core-updates failure.)

[Kaelyn]

Hi,

------- Original Message -------
On Saturday, April 15th, 2023 at 10:43 AM, Andreas Enge <andreas@enge.fr> wrote:

> 
> Am Fri, Apr 14, 2023 at 08:51:18PM -0400 schrieb Maxim Cournoyer:
> 
> > None, but are there wget uptsream reports about the problem?
> 
> 
> I do not see anything at
> https://gitlab.com/gnuwget/wget
> 
> Andreas

Doing a search of the error message, I just found https://savannah.gnu.org/bugs/?62110; the subject is about the HSTS tests being broken 32-bit big endian devices, but comment #3 mentions the tests failing on i686, with the same error we are seeing. It looks like https://gitlab.com/gnuwget/wget/-/merge_requests/31 was merged to fix the issue about a month after 1.21.3 was released (I haven't tested yet since the package definition downloads a release tarball instead of building from git).

Cheers,
Kaelyn

Re: wget (was Re: i686 core-updates failure.)

[Kaelyn]

------- Original Message -------
On Saturday, April 15th, 2023 at 4:37 PM, Kaelyn <kaelyn.alexi@protonmail.com> wrote:


> 
> 
> Hi,
> 
> ------- Original Message -------
> On Saturday, April 15th, 2023 at 10:43 AM, Andreas Enge andreas@enge.fr wrote:
> 
> > Am Fri, Apr 14, 2023 at 08:51:18PM -0400 schrieb Maxim Cournoyer:
> > 
> > > None, but are there wget uptsream reports about the problem?
> > 
> > I do not see anything at
> > https://gitlab.com/gnuwget/wget
> > 
> > Andreas
> 
> 
> Doing a search of the error message, I just found https://savannah.gnu.org/bugs/?62110; the subject is about the HSTS tests being broken 32-bit big endian devices, but comment #3 mentions the tests failing on i686, with the same error we are seeing. It looks like https://gitlab.com/gnuwget/wget/-/merge_requests/31 was merged to fix the issue about a month after 1.21.3 was released (I haven't tested yet since the package definition downloads a release tarball instead of building from git).

I tried to update the package definition to be able to build from git but it became a much bigger rabbit hole than I have the energy for at the moment. I also tried to cherry-pick the commit from the merge request without luck. At least until a new release of wget occurs (and is confirmed to build on i686), I feel like the most expedient solution may be to revert commit 9cd22702b8 which updated wget from 1.21.1 to 1.21.3. I tried building 1.21.2 for i686 and hit the same test failures, but have confirmed that 1.21.1 builds just fine for i686 on core-updates

Cheers,
Kaelyn

Re: wget on i686 in core-updates

[Andreas Enge]

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

Hello,

Am Sat, Apr 15, 2023 at 06:25:52PM +0000 schrieb Kaelyn:
> I tried to update the package definition to be able to build from git but it became a much bigger rabbit hole than I have the energy for at the moment. I also tried to cherry-pick the commit from the merge request without luck.

I just downloaded the commit, which is in uniform diff format and can serve
as a patch to be applied to the tarball. The result is attached, but it
does not work: The tests fail as before with the "file not found" messages.

But thanks for digging through the wget issues!

Andreas


[-- Attachment #2: 0001-gnu-wget-Add-patch-needed-for-i686.patch --]
[-- Type: text/plain, Size: 11436 bytes --]

From 0991a0daf74c0a3754618f99b7a7cb812debfa1a Mon Sep 17 00:00:00 2001
From: Andreas Enge <andreas@enge.fr>
Date: Sat, 15 Apr 2023 22:52:39 +0200
Subject: [PATCH] gnu: wget: Add patch needed for i686.

* gnu/packages/patches/wget-hsts-portability.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patch.
* gnu/packages/wget.scm (wget)[origin]: Apply patch.
---
 gnu/local.mk                                  |   1 +
 .../patches/wget-hsts-portability.patch       | 223 ++++++++++++++++++
 gnu/packages/wget.scm                         |   4 +-
 3 files changed, 227 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/wget-hsts-portability.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 73756a8c49..8dd0c45cea 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -2021,6 +2021,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/webrtc-audio-processing-big-endian.patch	\
   %D%/packages/patches/webrtc-for-telegram-desktop-fix-gcc12-cstdint.patch   \
   %D%/packages/patches/websocketpp-fix-for-cmake-3.15.patch	\
+  %D%/packages/patches/wget-hsts-portability.patch              \
   %D%/packages/patches/wmctrl-64-fix.patch			\
   %D%/packages/patches/wmfire-update-for-new-gdk-versions.patch	\
   %D%/packages/patches/wordnet-CVE-2008-2149.patch			\
diff --git a/gnu/packages/patches/wget-hsts-portability.patch b/gnu/packages/patches/wget-hsts-portability.patch
new file mode 100644
index 0000000000..62dabd7fae
--- /dev/null
+++ b/gnu/packages/patches/wget-hsts-portability.patch
@@ -0,0 +1,223 @@
+From 9a3479a23c15cd7234a54296ae50c48f29c427ec Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Tim=20R=C3=BChsen?= <tim.ruehsen@gmx.de>
+Date: Sun, 20 Mar 2022 12:18:20 +0100
+Subject: [PATCH] Fix HSTS portability by using int64_t instead of time_t.
+
+* src/hsts.c: Use int64_t instead of time_t.
+* src/http.c: Use int64_t for parsing Strict-Transport-Security.
+---
+ src/hsts.c | 41 ++++++++++++++++++++---------------------
+ src/hsts.h |  2 +-
+ src/http.c | 24 ++++++++++++------------
+ 3 files changed, 33 insertions(+), 34 deletions(-)
+
+diff --git a/src/hsts.c b/src/hsts.c
+index 0a014401..72c5e936 100644
+--- a/src/hsts.c
++++ b/src/hsts.c
+@@ -61,8 +61,8 @@ struct hsts_kh {
+ };
+ 
+ struct hsts_kh_info {
+-  time_t created;
+-  time_t max_age;
++  int64_t created;
++  int64_t max_age;
+   bool include_subdomains;
+ };
+ 
+@@ -166,7 +166,7 @@ end:
+ static bool
+ hsts_new_entry_internal (hsts_store_t store,
+                          const char *host, int port,
+-                         time_t created, time_t max_age,
++                         int64_t created, int64_t max_age,
+                          bool include_subdomains,
+                          bool check_validity,
+                          bool check_expired,
+@@ -216,21 +216,21 @@ bail:
+ static bool
+ hsts_add_entry (hsts_store_t store,
+                 const char *host, int port,
+-                time_t max_age, bool include_subdomains)
++                int64_t max_age, bool include_subdomains)
+ {
+-  time_t t = time (NULL);
++  int64_t t = (int64_t) time (NULL);
+ 
+   /* It might happen time() returned -1 */
+-  return (t == (time_t)(-1) ?
++  return (t == -1) ?
+       false :
+-      hsts_new_entry_internal (store, host, port, t, max_age, include_subdomains, false, true, false));
++      hsts_new_entry_internal (store, host, port, t, max_age, include_subdomains, false, true, false);
+ }
+ 
+ /* Creates a new entry, unless an identical one already exists. */
+ static bool
+ hsts_new_entry (hsts_store_t store,
+                 const char *host, int port,
+-                time_t created, time_t max_age,
++                int64_t created, int64_t max_age,
+                 bool include_subdomains)
+ {
+   return hsts_new_entry_internal (store, host, port, created, max_age, include_subdomains, true, true, true);
+@@ -245,7 +245,7 @@ hsts_remove_entry (hsts_store_t store, struct hsts_kh *kh)
+ static bool
+ hsts_store_merge (hsts_store_t store,
+                   const char *host, int port,
+-                  time_t created, time_t max_age,
++                  int64_t created, int64_t max_age,
+                   bool include_subdomains)
+ {
+   enum hsts_kh_match match_type = NO_MATCH;
+@@ -276,11 +276,11 @@ hsts_read_database (hsts_store_t store, FILE *fp, bool merge_with_existing_entri
+   size_t len = 0;
+   int items_read;
+   bool result = false;
+-  bool (*func)(hsts_store_t, const char *, int, time_t, time_t, bool);
++  bool (*func)(hsts_store_t, const char *, int, int64_t, int64_t, bool);
+ 
+   char host[256];
+   int port;
+-  time_t created, max_age;
++  int64_t created, max_age;
+   int include_subdomains;
+ 
+   func = (merge_with_existing_entries ? hsts_store_merge : hsts_new_entry);
+@@ -326,10 +326,9 @@ hsts_store_dump (hsts_store_t store, FILE *fp)
+       struct hsts_kh *kh = (struct hsts_kh *) it.key;
+       struct hsts_kh_info *khi = (struct hsts_kh_info *) it.value;
+ 
+-      if (fprintf (fp, "%s\t%d\t%d\t%lu\t%lu\n",
++      if (fprintf (fp, "%s\t%d\t%d\t%" PRId64 "\t%" PRId64 "\n",
+                    kh->host, kh->explicit_port, khi->include_subdomains,
+-                   (unsigned long) khi->created,
+-                   (unsigned long) khi->max_age) < 0)
++                   khi->created, khi->max_age) < 0)
+         {
+           logprintf (LOG_ALWAYS, "Could not write the HSTS database correctly.\n");
+           break;
+@@ -439,7 +438,7 @@ hsts_match (hsts_store_t store, struct url *u)
+ bool
+ hsts_store_entry (hsts_store_t store,
+                   enum url_scheme scheme, const char *host, int port,
+-                  time_t max_age, bool include_subdomains)
++                  int64_t max_age, bool include_subdomains)
+ {
+   bool result = false;
+   enum hsts_kh_match match = NO_MATCH;
+@@ -464,9 +463,9 @@ hsts_store_entry (hsts_store_t store,
+                * 'created' field too. The RFC also states that we have to
+                * update the entry each time we see HSTS header.
+                * See also Section 11.2. */
+-              time_t t = time (NULL);
++              int64_t t = (int64_t) time (NULL);
+ 
+-              if (t != (time_t)(-1) && t != entry->created)
++              if (t != -1 && t != entry->created)
+                 {
+                   entry->created = t;
+                   entry->max_age = max_age;
+@@ -792,7 +791,7 @@ test_hsts_read_database (void)
+   hsts_store_t table;
+   char *file = NULL;
+   FILE *fp = NULL;
+-  time_t created = time(NULL) - 10;
++  int64_t created = time(NULL) - 10;
+ 
+   if (opt.homedir)
+     {
+@@ -801,9 +800,9 @@ test_hsts_read_database (void)
+       if (fp)
+         {
+           fputs ("# dummy comment\n", fp);
+-          fprintf (fp, "foo.example.com\t0\t1\t%lu\t123\n",(unsigned long) created);
+-          fprintf (fp, "bar.example.com\t0\t0\t%lu\t456\n", (unsigned long) created);
+-          fprintf (fp, "test.example.com\t8080\t0\t%lu\t789\n", (unsigned long) created);
++          fprintf (fp, "foo.example.com\t0\t1\t%" PRId64 "\t123\n", created);
++          fprintf (fp, "bar.example.com\t0\t0\t%" PRId64 "\t456\n", created);
++          fprintf (fp, "test.example.com\t8080\t0\t%" PRId64 "\t789\n", created);
+           fclose (fp);
+ 
+           table = hsts_store_open (file);
+diff --git a/src/hsts.h b/src/hsts.h
+index 6ecd5060..be048944 100644
+--- a/src/hsts.h
++++ b/src/hsts.h
+@@ -46,7 +46,7 @@ bool hsts_store_has_changed (hsts_store_t);
+ 
+ bool hsts_store_entry (hsts_store_t,
+                        enum url_scheme, const char *, int,
+-                       time_t, bool);
++                       int64_t, bool);
+ bool hsts_match (hsts_store_t, struct url *);
+ 
+ #endif /* HAVE_HSTS */
+diff --git a/src/http.c b/src/http.c
+index f61c99a7..87b51b00 100644
+--- a/src/http.c
++++ b/src/http.c
+@@ -1300,7 +1300,7 @@ parse_content_disposition (const char *hdr, char **filename)
+ 
+ #ifdef HAVE_HSTS
+ static bool
+-parse_strict_transport_security (const char *header, time_t *max_age, bool *include_subdomains)
++parse_strict_transport_security (const char *header, int64_t *max_age, bool *include_subdomains)
+ {
+   param_token name, value;
+   const char *c_max_age = NULL;
+@@ -1330,7 +1330,7 @@ parse_strict_transport_security (const char *header, time_t *max_age, bool *incl
+            * Also, time_t is normally defined as a long, so this should not break.
+            */
+           if (max_age)
+-            *max_age = (time_t) strtol (c_max_age, NULL, 10);
++            *max_age = (int64_t) strtoll (c_max_age, NULL, 10);
+           if (include_subdomains)
+             *include_subdomains = is;
+ 
+@@ -3184,9 +3184,6 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
+ #else
+   extern hsts_store_t hsts_store;
+ #endif
+-  const char *hsts_params;
+-  time_t max_age;
+-  bool include_subdomains;
+ #endif
+ 
+   int sock = -1;
+@@ -3674,21 +3671,24 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
+ #ifdef HAVE_HSTS
+   if (opt.hsts && hsts_store)
+     {
+-      hsts_params = resp_header_strdup (resp, "Strict-Transport-Security");
++      int64_t max_age;
++      const char *hsts_params = resp_header_strdup (resp, "Strict-Transport-Security");
++      bool include_subdomains;
++
+       if (parse_strict_transport_security (hsts_params, &max_age, &include_subdomains))
+         {
+           /* process strict transport security */
+           if (hsts_store_entry (hsts_store, u->scheme, u->host, u->port, max_age, include_subdomains))
+-            DEBUGP(("Added new HSTS host: %s:%u (max-age: %lu, includeSubdomains: %s)\n",
++            DEBUGP(("Added new HSTS host: %s:%" PRIu32 " (max-age: %" PRId64 ", includeSubdomains: %s)\n",
+                    u->host,
+-                   (unsigned) u->port,
+-                   (unsigned long) max_age,
++                   (uint32_t) u->port,
++                   max_age,
+                    (include_subdomains ? "true" : "false")));
+           else
+-            DEBUGP(("Updated HSTS host: %s:%u (max-age: %lu, includeSubdomains: %s)\n",
++            DEBUGP(("Updated HSTS host: %s:%" PRIu32 " (max-age: %" PRId64 ", includeSubdomains: %s)\n",
+                    u->host,
+-                   (unsigned) u->port,
+-                   (unsigned long) max_age,
++                   (uint32_t) u->port,
++                   max_age,
+                    (include_subdomains ? "true" : "false")));
+         }
+       xfree (hsts_params);
+-- 
+GitLab
+
diff --git a/gnu/packages/wget.scm b/gnu/packages/wget.scm
index 083cf27212..6774fd477f 100644
--- a/gnu/packages/wget.scm
+++ b/gnu/packages/wget.scm
@@ -6,6 +6,7 @@
 ;;; Copyright © 2018–2021 Tobias Geerinckx-Rice <me@tobias.gr>
 ;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
 ;;; Copyright © 2021 Michael Rohleder <mike@rohleder.de>
+;;; Copyright © 2023 Andreas Enge <andreas@enge.fr>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -54,7 +55,8 @@ (define-public wget
                           version ".tar.lz"))
       (sha256
        (base32
-        "19afmyr1i3zwdwr8wkyz8q6z5764ik3dm87as194g78l8xggplnv"))))
+        "19afmyr1i3zwdwr8wkyz8q6z5764ik3dm87as194g78l8xggplnv"))
+      (patches (search-patches "wget-hsts-portability.patch"))))
     (build-system gnu-build-system)
     (inputs
      (list gnutls libidn2 libpsl))
-- 
2.39.2

Re: wget (was Re: i686 core-updates failure.)

[Andreas Enge]

Am Sat, Apr 15, 2023 at 06:25:52PM +0000 schrieb Kaelyn:
> I tried to update the package definition to be able to build from git but it became a much bigger rabbit hole than I have the energy for at the moment.

As an explanation, this may be because the git checkout contains gnulib
as a submodule. So just "git clone" is not enough.

Andreas

Re: wget (was Re: i686 core-updates failure.)

[Kaelyn]

------- Original Message -------
On Sunday, April 16th, 2023 at 5:06 PM, Andreas Enge <andreas@enge.fr> wrote:


> 
> 
> Am Sat, Apr 15, 2023 at 06:25:52PM +0000 schrieb Kaelyn:
> 
> > I tried to update the package definition to be able to build from git but it became a much bigger rabbit hole than I have the energy for at the moment.
> 
> 
> As an explanation, this may be because the git checkout contains gnulib
> as a submodule. So just "git clone" is not enough.

Indeed. I'd basically gotten as far as pointing the origin to the git repo and adding a bunch of needed inputs for the bootstrap phase. At that point the bootstrap script tried to run git, and git couldn't find a valid work tree. Looking at the script, it seemed that the flag "--no-git" would have to be passed in to prevent it from trying to run git and I wasn't sure how to pass the flag to the bootstrap script with the gnu-build-system (and suspected that once I cleared that hurdle I'd have more work to do for satisfying the gnulib dependency).

Cheers,
Kaelyn

> 
> Andreas

Core-updates after the staging merge

[Andreas Enge]

Hello all,

the merge of staging to master, and the subsequent merge of master to
core-updates did break a few things; but on the positive side, we are
halfway there with getting rid of the staging and core-updates branches ;-)
CI has almost caught up on x86_64; looking at the dashboard at
   https://ci.guix.gnu.org/eval/402403/dashboard
shows much more red than on master, so we will need to do some more work
before the merge. Since it is ordered alphabetically and our package names
often start by the language, red streaks often indicate problems with
a given programming language. There are things to work on for most of the
teams!

- rust: This one bootstrapped up to the latest version! There are a few
  red dots for individual packages.
- python: It is mostly green, but with lots of red, including at least
  one package that prevents icecat from building. I would call for careful
  updates and bug fixes to move on; leaf packages can be updated to the
  latest version, but for important intermediate packages please be
  careful.
- Go looks good.
- Java is red, but apparently still bootstrapping; everything hinges on
  icedtea@2.6, which is still scheduled for build:
     https://ci.guix.gnu.org/build/1007080/details
  So we need to wait, and potentially restart jobs that are marked as
  failed, but may actually build once their inputs are there.
- Everything common lisp related is red (cl-*, sbcl-*), but maybe there
  is a similar thing going; or maybe not, since clisp is built.
- R is red, but for the time being held up by texlive packages still being
  built.
- ghc is taking a long time...

A single package holds up a lot (gtk+ and so on): openldap. It fails after
about a minute of compiling like so:
  starting phase `provide-libldap_r'
  error: in phase 'provide-libldap_r': uncaught exception:
  unbound-variable #f "Unbound variable: ~S" (ungexp) #f
  phase `provide-libldap_r' failed after 0.0 seconds
This looks more like a typo than anything else.


On i686, we are still stuck by wget.


On aarch64, I think we are mainly stuck by lack of build power. I cancelled
a few build jobs on CI belonging to older git commits, but there is not much
we can do apart from bringing back build machines.

On powerpc, my cancelling of old jobs has apparently also cancelled newer
jobs that are actually the same; I am trying to restart them all, but am
not sure if I succeed. Apologies! As written yesterday, CI does not seem
to use all the build power at our disposal for this architecture.

Andreas

wget on i686 in core-updates

[Andreas Enge]

Am Sun, Apr 16, 2023 at 01:09:02PM +0200 schrieb Andreas Enge:
> On i686, we are still stuck by wget.

HEAD of git solves the problem, I will try to propose a solution later.

Andreas

Re: wget on i686 in core-updates

[Andreas Enge]

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

Am Sun, Apr 16, 2023 at 04:00:15PM +0200 schrieb Andreas Enge:
> HEAD of git solves the problem, I will try to propose a solution later.

Due to gnulib handled as a submodule, this turned out to be quite tricky
(for details, see the IRC logs with my discussion with jlicht).
The solution is to create a tarball after checking out the gnulib
submodule corresponding to the latest wget git commit and after running
./bootstrap.

As a stop-gap measure, I suggest to use a self-hosted tarball as in the
attached commit. I have good hope that we will soon see a 1.23.4 release,
see https://lists.gnu.org/archive/html/bug-wget/2023-04/msg00002.html .

What do you think?

Andreas


[-- Attachment #2: 0001-gnu-wget-Update-to-1.21.3.24.patch --]
[-- Type: text/plain, Size: 1392 bytes --]

From 424ee72ffbdf9a79eee4dd4aac43404167e66083 Mon Sep 17 00:00:00 2001
From: Andreas Enge <andreas@enge.fr>
Date: Sun, 16 Apr 2023 20:52:35 +0200
Subject: [PATCH] gnu: wget: Update to 1.21.3.24.

This update to a non-release version fixes a build failure on i686-linux.

* gnu/packages/wget.scm (wget): Update to 1.21.3.24.
[origin]: Use a self-hosted tarball created from the latest git commit.
---
 gnu/packages/wget.scm | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/wget.scm b/gnu/packages/wget.scm
index 083cf27212..17459344c0 100644
--- a/gnu/packages/wget.scm
+++ b/gnu/packages/wget.scm
@@ -46,15 +46,16 @@ (define-module (gnu packages wget)
 (define-public wget
   (package
     (name "wget")
-    (version "1.21.3")
+    (version "1.21.3.24")
     (source
      (origin
       (method url-fetch)
-      (uri (string-append "mirror://gnu/wget/wget-"
-                          version ".tar.lz"))
+      ;;(uri (string-append "mirror://gnu/wget/wget-"
+      ;;                    version ".tar.lz"))
+      (uri "https://www.multiprecision.org/wget-1.21.3.24-2b723.tar.lz")
       (sha256
        (base32
-        "19afmyr1i3zwdwr8wkyz8q6z5764ik3dm87as194g78l8xggplnv"))))
+        "17ip94mvax83h0gh4905jqc64g5qf3vgxr3bj9gn02pijjm5lzbp"))))
     (build-system gnu-build-system)
     (inputs
      (list gnutls libidn2 libpsl))
-- 
2.39.2

Re: wget on i686 in core-updates

[Andreas Enge]

Am Sun, Apr 16, 2023 at 08:57:48PM +0200 schrieb Andreas Enge:
> As a stop-gap measure, I suggest to use a self-hosted tarball as in the
> attached commit. I have good hope that we will soon see a 1.23.4 release,
> see https://lists.gnu.org/archive/html/bug-wget/2023-04/msg00002.html .

I just pushed the commit. There should be a new wget release this week:
    https://lists.gnu.org/archive/html/bug-wget/2023-04/msg00005.html
and then we can push the update. Having wget will enable us to see where
more work is needed on i686.

Andreas