Re: bug#70456: Request for merging "core-updates" branch

[Ludovic Courtès]

Hi Chris and all,

Christopher Baines  skribis:

> I think keeping the Git commit history clean and representative is
> really important, so to me at least this means core-updates can't be
> merged to master in it's current form, even if the changes overall from
> these 6351 commits are reasonable.
>
> I'm really not sure how to move forward though, I had a go at trying to
> rebuild the branch without introducing the thousands of duplicate
> commits and that produced a branch with 765 commits over master, which
> still seems a lot, but a big improvement over 6351:
>
>   https://git.cbaines.net/guix/log/?h=chris-core-updates-no-duplicates-attempt
>
> That was really hard going though, as there's plenty of merge conflicts
> along the way, and I'm pretty sure I solved some of them
> incorrectly. The resulting branch also differs from core-updates.

Woow, impressive.  How did you go about finding which commits were
duplicates/cherry-picked from master?  Which commit did you start from?

Given everything you’ve explained, it seems to me it’s worth trying to
start from a clean branch like this.

I checked it out (commit da77ea23daa0bfa4a73290dff99b22d6825ff80b) to
get an idea of where we are and got this:

--8<---cut here---start->8---
make[2]: *** No rule to make target 
'gnu/packages/patches/glib-networking-gnutls-binding.patch', needed by 'all-am'.
make[2]: *** No rule to make target 
'gnu/packages/patches/librecad-support-for-boost-1.76.patch', needed by 
'all-am'.
--8<---cut here---end--->8---

It stopped at:

--8<---cut here---start->8---
gnu/packages/sdl.scm:72:2: error: (package (name "sdl2") (version "2.30.1") 
(source (origin (method url-fetch) (uri (string-append 
"https://libsdl.org/release/SDL2-; version ".tar.gz")) (sha256 (base32 
"0fj7gxc7rlzzrafnx9nmf7ws3paxy583fmx7bcbavi6gr3xmy881" (arguments (list 
#:tests? #f #:configure-flags (gexp (append (quote ("--disable-wayland-shared" 
"--enable-video-kmsdrm" "--disable-kmsdrm-shared")) (quote 
("--disable-alsa-shared" "--disable-pulseaudio-shared" "--disable-x11-shared" 
"LDFLAGS=-lGL" #:make-flags (gexp (cons* (string-append 
"LDFLAGS=-Wl,-rpath," (ungexp (this-package-input "eudev")) "/lib" ",-rpath," 
(ungexp (this-package-input "vulkan-loader")) "/lib") (quote ("V=1")) 
(propagated-inputs (list libx11 libcap mesa)) (native-inputs (list pkg-config)) 
(inputs (list libxrandr glu alsa-lib pulseaudio dbus eudev glib ibus-minimal 
libxkbcommon libxcursor vulkan-loader wayland wayland-protocols)) (outputs 
(quote ("out" "debug"))) (synopsis "Cross platform game development library") 
(description "Simple DirectMedia Layer is a cross-platform development library 
designed to\nprovide low level access to audio, keyboard, mouse, joystick, and 
graphics\nhardware.") (home-page "https://libsdl.org/;) (license 
license:bsd-3)): missing field initializers (build-system)
--8<---cut here---end--->8---

I guess these are merge conflicts that weren’t correctly resolved.

This branch rewrites the entire ‘core-updates’ history.  What about
rewriting starting from the first series of “duplicate” commits?  That
should solve the immediate issue while keeping the “known good” history?

Thanks,
Ludo’.

Re: Merging core-updates? OFF TOPIC PRAISE

[Joshua Branson]

Christopher Baines  writes:

> Christopher Baines  writes:
>
>> Julien Lepiller  writes:
>>
>>> As discussed at Guix Days before Fosdem, we haven't merged core-updates
>>> in a very long time. I'd volunteer to lead this effort, but I don't
>>> know what steps I should follow. Do we have some documentation about
>>> that?
>>
>> I can try and help with this, at least in terms of helping get
>> bordeaux.guix.gnu.org substitute availability to a good level.
>>
>> I'd also like to get the kind of comparison that the qa-frontpage can do
>> for patches working for branches, but that'll probably take a bit of
>> work in the data service/qa-frontpage to get working smoothly.
>
> I've now addressed some performance issues with data.qa.guix.gnu.org,
> which means that the comparisons for core-updates (and branches like it)
> should now work, even if they're still a bit slow.
>
> This has enabled qa.guix.gnu.org to submit builds to the bordeaux build
> farm, they're still being slowly submitted but things have already
> started to happen for aarch64-linux at least.
>
> Once there's enough build data to work with, I'll see if I can start
> getting some information to show up on qa.guix.gnu.org.

Christopher thanks a million for your work on bordeaux and
qa.guix.gnu.org!  It's awesome that guix is moving towards having a QA
assurance that new patches won't break testsuitse!

Thanks again!

Joshua

Re: Merging core-updates?

[Christopher Baines]

Christopher Baines  writes:

> Julien Lepiller  writes:
>
>> As discussed at Guix Days before Fosdem, we haven't merged core-updates
>> in a very long time. I'd volunteer to lead this effort, but I don't
>> know what steps I should follow. Do we have some documentation about
>> that?
>
> I can try and help with this, at least in terms of helping get
> bordeaux.guix.gnu.org substitute availability to a good level.
>
> I'd also like to get the kind of comparison that the qa-frontpage can do
> for patches working for branches, but that'll probably take a bit of
> work in the data service/qa-frontpage to get working smoothly.

I've now addressed some performance issues with data.qa.guix.gnu.org,
which means that the comparisons for core-updates (and branches like it)
should now work, even if they're still a bit slow.

This has enabled qa.guix.gnu.org to submit builds to the bordeaux build
farm, they're still being slowly submitted but things have already
started to happen for aarch64-linux at least.

Once there's enough build data to work with, I'll see if I can start
getting some information to show up on qa.guix.gnu.org.


signature.asc
Description: PGP signature

Re: Merging core-updates?

[Ludovic Courtès]

Hi!

Leo Famulari  skribis:

> On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote:
>> As discussed at Guix Days before Fosdem, we haven't merged core-updates
>> in a very long time. I'd volunteer to lead this effort, but I don't
>> know what steps I should follow. Do we have some documentation about
>> that?
>
> The process could be considered "free form".
>
> Basically, you can try to reconfigure your system on core-updates. It
> will fail, many build failures will have to be fixed, and eventually it
> will work.

Before you get to that point, there are probably more basic tests to do,
as people pointed out.

Overall, “leading the effort” IMO will be largely about (1) monitoring
the status, and (2) sending weekly (?) status updates to bug the
relevant people, with the understanding that it’ll take a few weeks
before the dust settles down.

Ludo’.

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Hello,

Am Sun, Feb 19, 2023 at 11:24:44PM +0100 schrieb Andreas Enge:
> python-graphviz does not pass its tests any more in core-updates, and
> I can trace it back to your commit 3d388fe3d0475f2e991ae061cc1364529a97af42.
> Adding python-mock back to native-inputs fixes it.

I opted for this fix and could compile python-graphviz; this enables me to
test the build of icecat now.

Andreas

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Am Sun, Feb 19, 2023 at 12:30:42PM +0100 schrieb Andreas Enge:
> And another one: python-ecdsa

This just built. Strange, but I will not complain!

Andreas

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Am Sun, Feb 19, 2023 at 10:59:35PM + schrieb Kaelyn:
> It was mentioned recently that python-pycryptodome is / should be a drop-in 
> replacement for python-pycrypto (it is also says that in the package 
> description);

Apparently it is not, as Lars wrote. And in any case, it does require some
patching: I tried to compile python-potr with either of python-pycryptodome
and python-pycryptodomex, and it fails in the check phase, where it tries
to download pycrypto via pip.

> perhaps replace the python-pycrypto input with python-pycryptodome for 
> python-potr, with a snippet to change the pycrypto dependency to pycryptodome 
> in python-potr's setup.py?

Indeed this would be an alternative; but then here, I would still argue
that it is not a "drop-in replacement" for python-potr (in C, one could
imagine a separate project creating a library with the same soname).

> After taking a peek at the poezio and python-potr git repos, the main 
> alternative I can see to patching the dependency is to remove python-potr 
> from poezio's inputs since python-potr is listed as an optional dependency in 
> poezio's setup.py (for its OTR plugin).

But without python-potr, the tests fail... So it may be optional, but not
for the tests.

I took the liberty to update poezio while keeping the python-potr
dependency, as it does not worsen the situation, and could be argued to
improve it.

Andreas

Re: Ocaml (was: Merging core-updates?)

[Julien Lepiller]

We can probably get rid of most 4.07 variants but I would keep the bootstrap 
(in the hope we can bootstrap later versions from it). 4.09 is still used for 
unison, and I think Andreas uses it a lot :)

I'd say remove all leaf 4.07 packages that are libraries only.

Le 20 février 2023 11:35:16 GMT+01:00, Simon Tournier 
 a écrit :
>Hi Julien,
>
>On dim., 19 févr. 2023 at 10:15, Julien Lepiller  wrote:
>> ocaml-4.14 and ocaml-5 don't have this issue. I just pushed a fix for
>> ocaml-4.09. I'll also have to fix ocaml-4.07 since it fails to build as
>> early as camlboot. It'll take a while to test. Thanks for pointing me
>> to that patch!
>
>Do we still keep 4.07 and 4.09?  And all the package variants?
>
>Cheers,
>simon

Re: Merging core-updates?

[Christopher Baines]

Christopher Baines  writes:

> [[PGP Signed Part:Undecided]]
>
> Julien Lepiller  writes:
>
>> Le Sun, 12 Feb 2023 12:52:51 +0100,
>> Julien Lepiller  a écrit :
>>
>>> Le Sun, 12 Feb 2023 12:06:14 +0100,
>>> Andreas Enge  a écrit :
>>> 
>>> I just tried to build mpc on my machine, from core-updates. I get the
>>> same derivation as the one shown on the data service, and it built
>>> fine. Maybe there's something wrong with the machines behind bordeaux?
>>> I probably got substitutes from berlin, for gcc and friends (though I
>>> built gmp, mpfr and mpc).
>>
>> And I was able to rebuild (with --check) patch-mesboot. The error looks
>> a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
>> :)
>
> It could be something "wrong" with a build machine, although my
> suspicion for a while is that various things are broken/don't work on
> btrfs, which milano-guix-1 (the most important x86_64-linux) build
> machine uses.
>
> I've filed a few issues that probably relate to this:
>
> https://issues.guix.gnu.org/53415
> https://issues.guix.gnu.org/53416
> https://issues.guix.gnu.org/60202
>
> There are other build machines that don't use btrfs, so it should be
> possible to get these things built anyway.

Following up on this, there are some failed builds for patch-mesboot [1]
for the latest revision of core-updates [2].

1: 
https://data.qa.guix.gnu.org/gnu/store/3nidliz9rdxwvvl46i0afvwkfx4yly74-patch-mesboot-2.5.9.drv
2: 
https://data.qa.guix.gnu.org/revision/3b57f25f55c52c97428106de285d3cf2746554dc

I've tried this manually on milano-guix-1 (which uses btrfs) and I get
the same failure, so this seems to be specific to the
machine/configuration.

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Ocaml (was: Merging core-updates?)

[Simon Tournier]

Hi Julien,

On dim., 19 févr. 2023 at 10:15, Julien Lepiller  wrote:
> ocaml-4.14 and ocaml-5 don't have this issue. I just pushed a fix for
> ocaml-4.09. I'll also have to fix ocaml-4.07 since it fails to build as
> early as camlboot. It'll take a while to test. Thanks for pointing me
> to that patch!

Do we still keep 4.07 and 4.09?  And all the package variants?

Cheers,
simon

Re: Python (was: Merging core-updates?)

[Kaelyn]

--- Original Message ---
On Sunday, February 19th, 2023 at 10:08 PM, Andreas Enge  
wrote:


> 
> There is poezio, which has a new release (0.14), with a license change to
> gpl3+. I updated python-slixmpp, a dependency of poezio, but this is not
> enough: The newest poezio still depends on python-potr, which in turn depends
> on python-pycrypto.

It was mentioned recently that python-pycryptodome is / should be a drop-in 
replacement for python-pycrypto (it is also says that in the package 
description); perhaps replace the python-pycrypto input with 
python-pycryptodome for python-potr, with a snippet to change the pycrypto 
dependency to pycryptodome in python-potr's setup.py? After taking a peek at 
the poezio and python-potr git repos, the main alternative I can see to 
patching the dependency is to remove python-potr from poezio's inputs since 
python-potr is listed as an optional dependency in poezio's setup.py (for its 
OTR plugin).

Cheers,
Kaelyn

> 
> Andreas

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Hello Ricardo,

python-graphviz does not pass its tests any more in core-updates, and
I can trace it back to your commit 3d388fe3d0475f2e991ae061cc1364529a97af42.
Adding python-mock back to native-inputs fixes it.

Or maybe python-pytest-mock should have python-mock as propagated input?
It calls itself a "Thin-wrapper around the mock package for easier use
with py.test", but does not even have python-mock as any kind of input.

Thanks for your help,

Andreas

Re: Python (was: Merging core-updates?)

[Andreas Enge]

There is poezio, which has a new release (0.14), with a license change to
gpl3+. I updated python-slixmpp, a dependency of poezio, but this is not
enough: The newest poezio still depends on python-potr, which in turn depends
on python-pycrypto.

Andreas

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Am Sun, Feb 19, 2023 at 04:50:37PM +0100 schrieb Lars-Dominik Braun:
> The rest seems to be alive
> without any references to python-pycrypto. So these should be upgradable
> and then we can drop python-pycrypto.

I more or less got rid of one of them: python-ledgerblue.
I have updated it from 0.1.16 of 2016 (!) to 0.1.44 of last month.
The package builds, but the tests fail. I did not find an intermediate
commit that would not depend on python-pycrypto, but pass its tests.
(Well, I did not check each and every of them either.)

I pushed nevertheless, since the situation is not worse than before.
Maybe someone more knowledgeable could have a look and see whether the
tests can be fixed or should be disabled. Here is the error message:
running build_ext
usage: -c [-h] [--targetId TARGETID] [--rootPrivateKey ROOTPRIVATEKEY]
  [--apdu] [--deployLegacy]
-c: error: unrecognized arguments: test
error: in phase 'check': uncaught exception:
%exception #< program: "python" arguments: ("-c" "import 
setuptools, tokenize;__file__='setup.py';f=getattr(tokenize, 'open', 
open)(__file__);code=f.read().replace('\\r\\n', 
'\\n');f.close();exec(compile(code, __file__, 'exec'))" "test") exit-status: 2 
term-signal: #f stop-signal: #f>
phase `check' failed after 1.2 seconds
command "python" "-c" "import setuptools, 
tokenize;__file__='setup.py';f=getattr(tokenize, 'open', 
open)(__file__);code=f.read().replace('\\r\\n', 
'\\n');f.close();exec(compile(code, __file__, 'exec'))" "test" failed with 
status 2
builder for 
`/gnu/store/9kfks35xhr6abgkmpmy0la2m2nrwg6i1-python-ledgerblue-0.1.44.drv' 
failed with exit code 1
build of 
/gnu/store/9kfks35xhr6abgkmpmy0la2m2nrwg6i1-python-ledgerblue-0.1.44.drv failed

Andreas

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Am Sun, Feb 19, 2023 at 12:57:07PM +0100 schrieb Andreas Enge:
> > which seems to be the only change in attrdict3, see 
> > https://github.com/pirofti/AttrDict3/commit/f6678b627b469c9aeddca2a9e4ba4e1ee9e3ccbb
> Great, I will replace the package then.

Done. Interestingly enough, there was only one dependent: python-wxpython;
which has three dependents, of which python-matplotlib, and from there it
propagates everywhere...

Andreas

Re: Python (was: Merging core-updates?)

[Lars-Dominik Braun]

Hi,

> Except that we have to decide what to do about its dependents...
upgrade or drop if not possible. pycryptodome does not provide an entirely
compatible interface (see https://www.pycryptodome.org/src/vs_pycrypto),
so we cannot simply switch existing packages from pycrypto to pycryptdome
without manual testing and (possibly) patching.

eolie upstream looks dead, same with jrnl. The rest seems to be alive
without any references to python-pycrypto. So these should be upgradable
and then we can drop python-pycrypto.

Lars

Re: Python (was: Merging core-updates?)

[Attila Lendvai]

> but it is somehow in the same git repository as trezor-agent,
> and I do not totally understand how these are related. Taking
> back my rant and acknowledging my ignorance.

weirdly enough, upstream uses one git repo for multiple projects, and uses 
prefixed tag names for them.

FYI, there's this long-pending patchset to update the trezor-agent (something i 
can test myself):

https://issues.guix.gnu.org/58437#4

it's been pending so long, maybe it should be updated again.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Hurt people hurt people. That's how pain patterns gets passed on, generation 
after generation after generation. Break the chain today. Meet anger with 
sympathy, contempt with compassion, cruelty with kindness. Greet grimaces with 
smiles. Forgive and forget about finding fault. Love is the weapon of the 
future.”
— Yehuda Berg

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Hello Lars,

thanks for having a look!

Am Sun, Feb 19, 2023 at 12:47:46PM +0100 schrieb Lars-Dominik Braun:
> > command "python" "-m" "compileall" "--invalidation-mode=unchecked-hash" 
> > "/gnu/store/5i3yqwaqd8mayl2vr9lmrihxwv8203b1-python-pycrypto-2.6.1" failed 
> > with status 1
> this particular line looks different with Python 3.9, since the package
> is built with an automated Python 2 to Python 3 converter, which does
> not seems to work correctly on 3.10 (build_py_2to3 in setup.py). Not
> sure why though. Given the warning on their homepage it’s probably
> safe to drop the package.

Except that we have to decide what to do about its dependents...

> > from collections import Mapping
> > ImportError: cannot import name 'Mapping' from 'collections' 
> > (/gnu/store/blals34ar25fiifvm17m2b504waxzys0-python-3.10.7/lib/python3.10/collections/__init__.py)
> This is trivial to fix and should be
>   from collections.abc import Mapping
> which seems to be the only change in attrdict3, see 
> https://github.com/pirofti/AttrDict3/commit/f6678b627b469c9aeddca2a9e4ba4e1ee9e3ccbb

Great, I will replace the package then.

Andreas

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Am Sun, Feb 19, 2023 at 12:02:15PM +0100 schrieb Andreas Enge:
>Then we have:
>   Building the following 6 packages would ensure 9 dependent packages are 
> rebuilt: python-miio@0.5.11 ledger-agent@0.9.0 electrum@4.3.2 eolie@0.9.101 
> jrnl@1.9.7 poezio@0.13.2

Concerning poezio, it depends on python-potr (and is its only dependent),
which in turn depends on python-pycrypto.

Concerning python-potr, I am a bit at a loss. There is
   https://github.com/python-otr/pure-python-otr
with their latest release 1.0.2 in 2018 and a big bold comment
"This software is experimental and potentially insecure. Do not rely on it".

Pypi has this:
   https://pypi.org/project/python-otr/
which I suppose is a different project.

Would it make sense to remove python-potr and poezio?
I am not confident with crypto libraries that call themselves insecure...

Andreas

Re: Python (was: Merging core-updates?)

[Lars-Dominik Braun]

Hi Andreas,

> ***   File 
> "/gnu/store/5i3yqwaqd8mayl2vr9lmrihxwv8203b1-python-pycrypto-2.6.1/lib/python3.10/site-packages/Crypto/Util/number.py",
>  line 139
> value |= 2L ** (N-1)# Ensure high bit is set
>  ^
> SyntaxError: invalid decimal literal
> error: in phase 'install': uncaught exception:
> %exception #< program: "python" arguments: ("-m" "compileall" 
> "--invalidation-mode=unchecked-hash" 
> "/gnu/store/5i3yqwaqd8mayl2vr9lmrihxwv8203b1-python-pycrypto-2.6.1") 
> exit-status: 1 term-signal: #f stop-signal: #f>
> phase `install' failed after 0.5 seconds
> command "python" "-m" "compileall" "--invalidation-mode=unchecked-hash" 
> "/gnu/store/5i3yqwaqd8mayl2vr9lmrihxwv8203b1-python-pycrypto-2.6.1" failed 
> with status 1
this particular line looks different with Python 3.9, since the package
is built with an automated Python 2 to Python 3 converter, which does
not seems to work correctly on 3.10 (build_py_2to3 in setup.py). Not
sure why though. Given the warning on their homepage it’s probably
safe to drop the package.

> from collections import Mapping
> ImportError: cannot import name 'Mapping' from 'collections' 
> (/gnu/store/blals34ar25fiifvm17m2b504waxzys0-python-3.10.7/lib/python3.10/collections/__init__.py)
This is trivial to fix and should be

from collections.abc import Mapping

which seems to be the only change in attrdict3, see 
https://github.com/pirofti/AttrDict3/commit/f6678b627b469c9aeddca2a9e4ba4e1ee9e3ccbb

Cheers,
Lars

Re: Python (was: Merging core-updates?)

[Andreas Enge]

And another one: python-ecdsa

I tried to update it from 0.17.0 to 0.18.0, but it still fails its tests
with this message:
src/ecdsa/test_jacobi.py:393: TypeError
=== warnings summary ===
src/ecdsa/test_der.py::TestEncodeBitstring::test_implicit_unused_bits
src/ecdsa/test_der.py::TestEncodeBitstring::test_new_call_convention
src/ecdsa/test_der.py::TestRemoveBitstring::test_implicit_unexpected_unused
src/ecdsa/test_der.py::TestRemoveBitstring::test_new_call_convention
  
/gnu/store/blals34ar25fiifvm17m2b504waxzys0-python-3.10.7/lib/python3.10/unittest/case.py:549:
 PytestRemovedIn8Warning: Passing None has been deprecated.
  See 
https://docs.pytest.org/en/latest/how-to/capture-warnings.html#additional-use-cases-of-warnings-in-tests
 for alternatives in common use cases.
method()

Andreas

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Am Sun, Feb 19, 2023 at 12:15:59PM +0100 schrieb Andreas Enge:
> I am looking at these packages. One of them, ledger-agent, dates from 2017
> and has seen 25 releases in the meantime.

Well, maybe, maybe not. The version in Pypi has not changed,
but it is somehow in the same git repository as trezor-agent,
and I do not totally understand how these are related. Taking
back my rant and acknowledging my ignorance.

Andreas

Re: Python (was: Merging core-updates?)

[Andreas Enge]

Am Sun, Feb 19, 2023 at 12:02:15PM +0100 schrieb Andreas Enge:
> PPS: On the first issue, the homepage says:
>PyCrypto 2.x is unmaintained, obsolete, and contains security 
> vulnerabilities.
>   Building the following 6 packages would ensure 9 dependent packages are 
> rebuilt: python-miio@0.5.11 ledger-agent@0.9.0 electrum@4.3.2 eolie@0.9.101 
> jrnl@1.9.7 poezio@0.13.2

I am looking at these packages. One of them, ledger-agent, dates from 2017
and has seen 25 releases in the meantime. I can of course try to update it
(in main? core-updates?), but I am also wondering whether we have a
deprecation policy. This feels like a package nobody is interested in, and
it is demotivating to spend time fixing it... (Well, it is entirely possible
that flocks of users are still clinging on to a perfectly working old
version, but well!)

Andreas

Python (was: Merging core-updates?)

[Andreas Enge]

Hello,

I am having problems with at least two python packages in core-updates:

***   File 
"/gnu/store/5i3yqwaqd8mayl2vr9lmrihxwv8203b1-python-pycrypto-2.6.1/lib/python3.10/site-packages/Crypto/Util/number.py",
 line 139
value |= 2L ** (N-1)# Ensure high bit is set
 ^
SyntaxError: invalid decimal literal
error: in phase 'install': uncaught exception:
%exception #< program: "python" arguments: ("-m" "compileall" 
"--invalidation-mode=unchecked-hash" 
"/gnu/store/5i3yqwaqd8mayl2vr9lmrihxwv8203b1-python-pycrypto-2.6.1") 
exit-status: 1 term-signal: #f stop-signal: #f>
phase `install' failed after 0.5 seconds
command "python" "-m" "compileall" "--invalidation-mode=unchecked-hash" 
"/gnu/store/5i3yqwaqd8mayl2vr9lmrihxwv8203b1-python-pycrypto-2.6.1" failed with 
status 1


starting phase `sanity-check'
validating 'attrdict' 
/gnu/store/lvy1fmmf1dsr3fjw82zal2aaisf3d47k-python-attrdict-2.0.1/lib/python3.10/site-pac
kages
...checking requirements: OK
...trying to load module attrdict: ERROR:
Traceback (most recent call last):
  File "/gnu/store/35ix1m6m8a5s21j02ajhdyqxb2xkshfb-sanity-check.py", line 69, 
in 
importlib.import_module(name)
  File 
"/gnu/store/blals34ar25fiifvm17m2b504waxzys0-python-3.10.7/lib/python3.10/importlib/__init__.py",
 line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 1006, in _find_and_load_unlocked
  File "", line 688, in _load_unlocked
  File "", line 883, in exec_module
  File "", line 241, in _call_with_frames_removed
  File 
"/gnu/store/lvy1fmmf1dsr3fjw82zal2aaisf3d47k-python-attrdict-2.0.1/lib/python3.10/site-packages/attrdict/__init__.py",
 line 5, in 
from attrdict.mapping import AttrMap
  File 
"/gnu/store/lvy1fmmf1dsr3fjw82zal2aaisf3d47k-python-attrdict-2.0.1/lib/python3.10/site-packages/attrdict/mapping.py",
 line 4, in 
from collections import Mapping
ImportError: cannot import name 'Mapping' from 'collections' 
(/gnu/store/blals34ar25fiifvm17m2b504waxzys0-python-3.10.7/lib/python3.10/collections/__init__.py)
error: in phase 'sanity-check': uncaught exception:
%exception #< program: "python" arguments: 
("/gnu/store/35ix1m6m8a5s21j02ajhdyqxb2xkshfb-sanity-check.py" 
"/gnu/store/lvy1fmmf1dsr3fjw82zal2aaisf3d47k-python-attrdict-2.0.1/lib/python3.10/site-packages")
 exit-status: 1 term-signal: #f stop-signal: #f>
phase `sanity-check' failed after 0.2 seconds
command "python" "/gnu/store/35ix1m6m8a5s21j02ajhdyqxb2xkshfb-sanity-check.py" 
"/gnu/store/lvy1fmmf1dsr3fjw82zal2aaisf3d47k-python-attrdict-2.0.1/lib/python3.10/site-packages"
 failed with status 1
for python-attrdict.

Both are at their latest version from Pypi.

Have there been some incompatible changes in Python 3.10? Should we revert
the Python update or try to backport patches? (I have no idea about Python,
and probably need it only for calibre.)

Andreas


PS: On the second issue: The latest commit is this:
v2.0.1  2019/02/01 -- Haven't used or looked at this in years so updating 
tests to the current version of python and then marking it inactive.
This would rather make me thing we should drop it, but here we go:
Building the following 160 packages would ensure 366 dependent packages are 
rebuilt: kicad@6.0.10 ...

There is something called attrdict3:
https://pypi.org/project/attrdict3/
at the same version +0.0.1; maybe we should use this?


PPS: On the first issue, the homepage says:
   PyCrypto 2.x is unmaintained, obsolete, and contains security 
vulnerabilities.
   Please choose one of the following alternatives:
   Cryptography
 Recommended for new applications.
 Newer API with fewer gotchas.
 API docs
 GitHub
 PyPI
   PyCryptodome
 Recommended for existing software that depends on PyCrypto.
 Fork of PyCrypto. Most applications should run unmodified.
 API docs
 GitHub
 PyPI

   Then we have:
  Building the following 6 packages would ensure 9 dependent packages are 
rebuilt: python-miio@0.5.11 ledger-agent@0.9.0 electrum@4.3.2 eolie@0.9.101 
jrnl@1.9.7 poezio@0.13.2
   We already have python-pycryptodome and python-pycryptodomex.
   Maybe we should try rebuilding the 9 dependent packages with one of them?
   Do the specialists have a preference as to which one to use?
   Both have a similar number of dependents currently.

Re: Ocaml (was: Merging core-updates?)

[Julien Lepiller]

ocaml-4.14 and ocaml-5 don't have this issue. I just pushed a fix for
ocaml-4.09. I'll also have to fix ocaml-4.07 since it fails to build as
early as camlboot. It'll take a while to test. Thanks for pointing me
to that patch!

Le Sat, 18 Feb 2023 12:38:55 +0100,
Andreas Enge  a écrit :

> Am Sat, Feb 18, 2023 at 12:03:31PM +0100 schrieb Andreas Enge:
> > this looks exactly like the line that posed problems for openjdk.
> > Maybe there is a patch? Could someone familiar with ocaml have a
> > look?  
> 
> It looks like this:
>https://github.com/ocaml/ocaml/pull/10266
> 
> Andreas
> 

Re: Ocaml (was: Merging core-updates?)

[Andreas Enge]

Am Sat, Feb 18, 2023 at 12:03:31PM +0100 schrieb Andreas Enge:
> this looks exactly like the line that posed problems for openjdk.
> Maybe there is a patch? Could someone familiar with ocaml have a look?

It looks like this:
   https://github.com/ocaml/ocaml/pull/10266

Andreas

Re: Openjdk (was: Merging core-updates?)

[Andreas Enge]

Am Thu, Feb 16, 2023 at 12:38:23PM +0100 schrieb Julien Lepiller:
> Upstream ensures openjdk N+1 can be built by openjdk N, but not necessarily 
> with N-1. We can try :)

And fail :)

configure: Potential Boot JDK found at 
/gnu/store/lqfppbbxhq503hfy2xf3djivqv3s8df4-openjdk-17.0.5-jdk is incorrect JDK 
version (openjdk version "17.0.5" 2022-10-18 OpenJDK Runtime Environment (build 
17.0.5+0-adhoc..source) OpenJDK 64-Bit Server VM (build 17.0.5+0-adhoc..source, 
mixed mode, sharing)); ignoring
configure: (Your Boot JDK version must be one of: 18 19)
configure: Could not find a valid Boot JDK. OpenJDK distributions are available 
at http://jdk.java.net/.
configure: This might be fixed by explicitly setting --with-boot-jdk
configure: error: Cannot continue

So @19 does not bootstrap with @17. Neither does @17 with @15. Dommage!

Andreas

Ocaml (was: Merging core-updates?)

[Andreas Enge]

Hello,

Am Mon, Feb 13, 2023 at 09:35:32PM +0100 schrieb Andreas Enge:
> ocaml-4.0.9 fails with
> gcc -c -O2 -fno-strict-aliasing -fwrapv -Wall -fno-tree-vrp -g 
> -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE  
> -DOCAML_STDLIB_DIR='"/gnu/store/mzzak7bp6dpngq04hphlx58wzp62755m-ocaml-4.09.0/lib/ocaml"'
>   -DNATIVE_CODE -DTARGET_amd64 -DMODEL_default -DSYS_linux   -o 
> signals_nat_n.o signals_nat.c
> signals_nat.c:185:13: error: variably modified ‘sig_alt_stack’ at file scope
>   185 | static char sig_alt_stack[SIGSTKSZ];
>   | ^
> make[3]: *** [Makefile:343: signals_nat_n.o] Error 1

this looks exactly like the line that posed problems for openjdk.
Maybe there is a patch? Could someone familiar with ocaml have a look?

Andreas

Re: Openjdk (was: Merging core-updates?)

[Andreas Enge]

Am Fri, Feb 17, 2023 at 05:27:02PM + schrieb Kaelyn:
> I don't know much about openjdk or its development process, but I had one 
> possible thought about the pattern of patch application. Was it a patch that 
> was applied or backported to existing openjdk releases, and are @14 and @16 
> the latest releases of those series? At least to me as a naive outside 
> observer, the patch being needed for some of the older release branches but 
> not others sounds like a patch applied to multiple existing release branches, 
> with openjdk@14 and @16 being at older point releases from prior to the patch 
> being applied upstream.

Ah, right, this sounds like a good explanation, thanks, Kaelyn!

I think we should consider core-updates frozen for the moment, but someone
updating these intermediate openjdk versions in the future should pay
attention to it.

In the meantime, I have pushed a convoluted patch that adds and removes
the patch by dancing back and forth.

Andreas

Re: Openjdk (was: Merging core-updates?)

[Kaelyn]

Hi,

--- Original Message ---
On Friday, February 17th, 2023 at 4:28 PM, Andreas Enge  wrote:

> Am Fri, Feb 17, 2023 at 03:49:19PM +0100 schrieb Andreas Enge:
> 
> > Hm, I compiled up to openjdk@13, @14 fails with the message below.
> > This is strange. It looks as if the patch that has become obsolete,
> > because integrated into the source @13, is needed again @14!
> > And then @15, the patch is again already integrated into the source code.
> > Very weird!
> 
> 
> Things become totally crazy.
> So far I have compiled @13 without the patch, @14 with the patch,
> @15 without the patch, and @16 seems to need it again. Is this an
> odd/even thing? Are there spring and autumn versions of openjdk with
> different release teams?

Hi,

I don't know much about openjdk or its development process, but I had one 
possible thought about the pattern of patch application. Was it a patch that 
was applied or backported to existing openjdk releases, and are @14 and @16 the 
latest releases of those series? At least to me as a naive outside observer, 
the patch being needed for some of the older release branches but not others 
sounds like a patch applied to multiple existing release branches, with 
openjdk@14 and @16 being at older point releases from prior to the patch being 
applied upstream.

HTH! (And I apologize for the noise if not!)

Cheers,
Kaelyn
 
> Well, in @17, @18 and @19 the patch seems to be definitely integrated
> into the source code.
> 
> Andreas

Re: Architecture support [was: Re: Merging core-updates?]

[Christopher Baines]

Julien Lepiller  writes:

> Could we get berlin to evaluate a small set of core packages (mpc,
> hello, …)? Are the changes intended to fix the issue with bordeaux's
> machines? Is it configured to build core-updates?

There's some rudimentary support for building packages from branches in
the qa-frontpage, but that currently just submits builds for all
packages.

I'll keep an eye on the core-updates state on data.qa.guix.gnu.org and
submit some builds for core things manually when the derivations are
available.


signature.asc
Description: PGP signature

Re: Openjdk (was: Merging core-updates?)

[Andreas Enge]

Am Fri, Feb 17, 2023 at 03:49:19PM +0100 schrieb Andreas Enge:
> Hm, I compiled up to openjdk@13, @14 fails with the message below.
> This is strange. It looks as if the patch that has become obsolete,
> because integrated into the source @13, is needed again @14!
> And then @15, the patch is again already integrated into the source code.
> Very weird!

Things become totally crazy.
So far I have compiled @13 without the patch, @14 with the patch,
@15 without the patch, and @16 seems to need it again. Is this an
odd/even thing? Are there spring and autumn versions of openjdk with
different release teams?

Well, in @17, @18 and @19 the patch seems to be definitely integrated
into the source code.

Andreas

Re: Openjdk (was: Merging core-updates?)

[Andreas Enge]

> The following seems to work and create source for openjdk13 and later:
> (define-public openjdk13
>   (make-openjdk openjdk12 "13.0.13"
> "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"
>   (source (origin
> (inherit (package-source base))
> (patches '())

Hm, I compiled up to openjdk@13, @14 fails with the message below.
This is strange. It looks as if the patch that has become obsolete,
because integrated into the source @13, is needed again @14!
And then @15, the patch is again already integrated into the source code.
Very weird!

Giving it a try now.

Andreas


Creating CDS archive for jdk image
In file included from 
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/libstepBreakPopReturn.cpp:31:
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp:
 In function 'MethodName* getMethodName(jvmtiEnv*, jmethodID)':
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp:100:12:
 warning: 'char* strncpy(char*, const char*, size_t)' specified bound 256 
equals destination size [-Wstringop-truncation]
  100 | strncpy(mn->classSig, szSignature, sizeof(mn->classSig));
  | ~~~^
In file included from 
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/share/libIndyRedefineClass.cpp:31:
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp:
 In function 'MethodName* getMethodName(jvmtiEnv*, jmethodID)':
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp:100:12:
 warning: 'char* strncpy(char*, const char*, size_t)' specified bound 256 
equals destination size [-Wstringop-truncation]
  100 | strncpy(mn->classSig, szSignature, sizeof(mn->classSig));
  | ~~~^
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:
 In function 'set_signal_handler':
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:71:15:
 error: storage size of 'altstack' isn't constant
   71 |   static char altstack[SIGSTKSZ];
  |   ^~~~
make[3]: *** [JtregNativeHotspot.gmk:1532: 
/tmp/guix-build-openjdk-14.0.2.drv-0/source/build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o]
 Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [make/Main.gmk:550: build-test-hotspot-jtreg-native] Error 2

ERROR: Build failed for target 'all' in configuration 
'linux-x86_64-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target support_test_hotspot_jtreg_native_support_exeinvoke_exeinvoke.o:
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:
 In function 'set_signal_handler':
/tmp/guix-build-openjdk-14.0.2.drv-0/source/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:71:15:
 error: storage size of 'altstack' isn't constant
   71 |   static char altstack[SIGSTKSZ];
  |   ^~~~

* All command lines available in 
/tmp/guix-build-openjdk-14.0.2.drv-0/source/build/linux-x86_64-server-release/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See doc/building.html#troubleshooting for assistance.

make[1]: *** [/tmp/guix-build-openjdk-14.0.2.drv-0/source/make/Init.gmk:312: 
main] Error 2
make: *** [/tmp/guix-build-openjdk-14.0.2.drv-0/source/make/Init.gmk:186: all] 
Error 2
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("all" "JOBS=4") 
exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 1605.0 seconds
command "make" "all" "JOBS=4" failed with status 2
builder for `/gnu/store/3i4i2kh5zbw2l3rdp7gx41ykxgnbfr1x-openjdk-14.0.2.drv' 
failed with exit code 1
build of /gnu/store/3i4i2kh5zbw2l3rdp7gx41ykxgnbfr1x-openjdk-14.0.2.drv failed
View build log at 
'/var/log/guix/drvs/3i/4i2kh5zbw2l3rdp7gx41ykxgnbfr1x-openjdk-14.0.2.drv.gz'.

Re: Openjdk (was: Merging core-updates?)

[Andreas Enge]

Hello,

Am Thu, Feb 16, 2023 at 01:03:35PM +0200 schrieb Efraim Flashner:
> > Okay to push if I manage to build current openjdk with it?
> Yeah, that's probably fine.

after a day, I got past the point of mesa in core-updates on x86_64.
Which in itself is an encouraging milestone.

Andreas

Re: Merging core-updates?

[Josselin Poiret]

Hi everyone, 

I'd love to help with the core-updates merge, but I don't have a beefy
machine right now and would love to avoid building all the bootstrap
locally.  The evaluations on CI seem to keep failing, with no info
available [1].  Do we have more info about them/know what's making them
fail?

[1] https://ci.guix.gnu.org/jobset/core-updates

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: Merging core-updates?

[Andreas Enge]

Am Thu, Feb 16, 2023 at 12:41:08PM +0100 schrieb Maxime Devos:
> You didn't write the hash.  As the hash is unknown, it would be
> irreproducible for the Guix daemon to grant the build process access to the
> network, so the Guix daemon doesn't.
> You'll need to enter a hash (possibly a bogus one that the daemon can
> complain about later).

Interesting, thanks for the explanation!

Andreas

Re: Merging core-updates?

[Julien Lepiller]

I haven't tried the patch, but before it, I was already able to build mpc for 
x86_64 on a SSD with btrfs.

Le 16 février 2023 16:03:15 GMT+01:00, Janneke Nieuwenhuizen  
a écrit :
>Andreas Enge writes:
>
>> Am Wed, Feb 15, 2023 at 09:39:39AM +0100 schrieb Janneke Nieuwenhuizen:
>>> I have released 0.24.2 and updated mes-boot on core-updates as
>>> Let's hope this fixes these bugs.
>>
>> With your latest patch, I have successfully bootstrapped core-updates
>> on x86_64 up to hello and mpc. Thanks a lot!
>
>Great, thanks so much for checking!  Are you using any of tmpfs or btrfs
>on /tmp?
>
>Greetings,
>janneke
>

Re: Merging core-updates?

[Andreas Enge]

Am Thu, Feb 16, 2023 at 04:03:15PM +0100 schrieb Janneke Nieuwenhuizen:
> Great, thanks so much for checking!  Are you using any of tmpfs or btrfs
> on /tmp?

No, it is all on SSD, so we probably cannot conclude for the bugs,
unfortunately.

Andreas

Re: Merging core-updates?

[Janneke Nieuwenhuizen]

Andreas Enge writes:

> Am Wed, Feb 15, 2023 at 09:39:39AM +0100 schrieb Janneke Nieuwenhuizen:
>> I have released 0.24.2 and updated mes-boot on core-updates as
>> Let's hope this fixes these bugs.
>
> With your latest patch, I have successfully bootstrapped core-updates
> on x86_64 up to hello and mpc. Thanks a lot!

Great, thanks so much for checking!  Are you using any of tmpfs or btrfs
on /tmp?

Greetings,
janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: Merging core-updates?

[Andreas Enge]

Am Wed, Feb 15, 2023 at 09:39:39AM +0100 schrieb Janneke Nieuwenhuizen:
> I have released 0.24.2 and updated mes-boot on core-updates as
> Let's hope this fixes these bugs.

With your latest patch, I have successfully bootstrapped core-updates
on x86_64 up to hello and mpc. Thanks a lot!

Andreas

Re: Merging core-updates?

[Maxime Devos]

On 15-02-2023 19:51, Andreas Enge wrote:

I am trying to build openjdk13 without the patch as follows:
(define-public openjdk13
   (make-openjdk openjdk12 "13.0.13"
 "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"
(source (origin
  (method git-fetch)
  (uri (git-reference
 (url"https://github.com/openjdk/jdk13u/;)
 (commit "jdk-13.0.13-ga")))
  (file-name (git-file-name name version))
  (sha256 #f)
(with the hash to be determined later).

This fails with
Initialized empty Git repository 
in/gnu/store/dyxp7njz9k20mar2h2cp8f2g438vigm2-openjdk-13.0.13-checkout/.git/
fatal: unable to access 'https://github.com/openjdk/jdk13u/': Could not resolve 
host: github.com

Do you know why? I am at a total loss as to what is happening...


You didn't write the hash.  As the hash is unknown, it would be 
irreproducible for the Guix daemon to grant the build process access to 
the network, so the Guix daemon doesn't.


You'll need to enter a hash (possibly a bogus one that the daemon can 
complain about later).


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Openjdk (was: Merging core-updates?)

[Julien Lepiller]

Le 16 février 2023 12:03:35 GMT+01:00, Efraim Flashner  
a écrit :
>On Wed, Feb 15, 2023 at 08:19:08PM +0100, Andreas Enge wrote:
>
>> Is it necessary to keep all these version of openjdk and to bootstrap
>> version n with version n-1?
>
>Probably? I assume if you can cut some out that'd be ok. I'm pretty sure
>openjdk-11 and openjdk-17 are considered LTS by upstream so it would
>make sense to keep those specifically.

Upstream ensures openjdk N+1 can be built by openjdk N, but not necessarily 
with N-1. We can try :)

Re: Openjdk (was: Merging core-updates?)

[Efraim Flashner]

On Wed, Feb 15, 2023 at 08:19:08PM +0100, Andreas Enge wrote:
> Am Wed, Feb 15, 2023 at 07:51:56PM +0100 schrieb Andreas Enge:
> > Actually the patch has already been applied to openjdk13, if I am not
> > mistaken. So I do not understand how the source could be built in master
> > then, while the exact same code (?!) fails on core-updates...
> 
> Well, there is a somewhat hidden difference.
> core-updates introduces
> "openjdk-10-hotspot-pointer-comparison.patch"
> "openjdk-10-hotspot-stack-size.patch"
> to openjdk10.
> 
> openjdk11 is a package of its own without the patch.
> 
> openjdk12 uses the newly defined make-openjdk to start from openjdk11,
> overwriting the source together with openjdk-10-hotspot-stack-size.patch
> in core-updates, and without the patch in master. (And it uses an obscure
> tarball instead of a git checkout - why?)
> 
> openjdk13 has the same code in core-updates and master:
> (define-public openjdk13
>   (make-openjdk openjdk12 "13.0.13"
> "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"))
> So in core-updates it inherits the patch from openjdk12, in master
> it does not (I think). And then I suppose it passes the patch on to all
> its descendants.

It's definitely possible that the master->core-updates merge messed with
the package definitions and the inheritance and I didn't notice it.

> The following seems to work and create source for openjdk13 and later:
> (define-public openjdk13
>   (make-openjdk openjdk12 "13.0.13"
> "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"
>   (source (origin
> (inherit (package-source base))
> (patches '())
> 
> Okay to push if I manage to build current openjdk with it?

Yeah, that's probably fine.

> Is it necessary to keep all these version of openjdk and to bootstrap
> version n with version n-1?

Probably? I assume if you can cut some out that'd be ok. I'm pretty sure
openjdk-11 and openjdk-17 are considered LTS by upstream so it would
make sense to keep those specifically.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Openjdk (was: Merging core-updates?)

[Andreas Enge]

Am Wed, Feb 15, 2023 at 07:51:56PM +0100 schrieb Andreas Enge:
> Actually the patch has already been applied to openjdk13, if I am not
> mistaken. So I do not understand how the source could be built in master
> then, while the exact same code (?!) fails on core-updates...

Well, there is a somewhat hidden difference.
core-updates introduces
"openjdk-10-hotspot-pointer-comparison.patch"
"openjdk-10-hotspot-stack-size.patch"
to openjdk10.

openjdk11 is a package of its own without the patch.

openjdk12 uses the newly defined make-openjdk to start from openjdk11,
overwriting the source together with openjdk-10-hotspot-stack-size.patch
in core-updates, and without the patch in master. (And it uses an obscure
tarball instead of a git checkout - why?)

openjdk13 has the same code in core-updates and master:
(define-public openjdk13
  (make-openjdk openjdk12 "13.0.13"
"0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"))
So in core-updates it inherits the patch from openjdk12, in master
it does not (I think). And then I suppose it passes the patch on to all
its descendants.

The following seems to work and create source for openjdk13 and later:
(define-public openjdk13
  (make-openjdk openjdk12 "13.0.13"
"0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"
  (source (origin
(inherit (package-source base))
(patches '())

Okay to push if I manage to build current openjdk with it?

Is it necessary to keep all these version of openjdk and to bootstrap
version n with version n-1?

Andreas

Re: Merging core-updates?

[Andreas Enge]

Am Tue, Feb 14, 2023 at 07:27:10PM +0100 schrieb Andreas Enge:
> Am Mon, Feb 13, 2023 at 11:31:15PM +0200 schrieb Efraim Flashner:
> > Looks like you might be able to drop openjdk-10-hotspot-stack-size.patch
> > from openjdk-19.0.1.
> Maybe. What is strange is that we have the same openjdk package on master,
> apparently with the patch. I will give it a try nevertheless.

Actually the patch has already been applied to openjdk13, if I am not
mistaken. So I do not understand how the source could be built in master
then, while the exact same code (?!) fails on core-updates...

I am trying to build openjdk13 without the patch as follows:
(define-public openjdk13
  (make-openjdk openjdk12 "13.0.13"
"0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji"
   (source (origin
 (method git-fetch)
 (uri (git-reference
(url "https://github.com/openjdk/jdk13u/;)
(commit "jdk-13.0.13-ga")))
 (file-name (git-file-name name version))
 (sha256 #f)
(with the hash to be determined later).

This fails with
Initialized empty Git repository in 
/gnu/store/dyxp7njz9k20mar2h2cp8f2g438vigm2-openjdk-13.0.13-checkout/.git/
fatal: unable to access 'https://github.com/openjdk/jdk13u/': Could not resolve 
host: github.com

Do you know why? I am at a total loss as to what is happening...

Is there a way to keep the origin determined by make-openjdk and to just
empty its patches field?

Andreas

Re: Architecture support [was: Re: Merging core-updates?]

[Andreas Enge]

Am Tue, Feb 14, 2023 at 10:10:27PM +0200 schrieb Efraim Flashner:
> > I got to hello on my aarch64, which is very encouraging! I will have to
> > try again with your latest changes to core-updates, but am rather 
> > optimistic.
> 
> Also I made a typo in the tar fix, so I'll push a fix for that after I
> confirm that it actually skips the broken test.

With the typo fixed, I get to hello also on armhf (built on aarch64).
Great!

Andreas

Re: Merging core-updates?

[Janneke Nieuwenhuizen]

Andreas Enge writes:

Hello,

> Am Mon, Feb 13, 2023 at 12:34:56PM +0100 schrieb Janneke Nieuwenhuizen:
>> To use stat64 and friends on 32bit, I created the attached patch for GNU
>> Mes and hope to create a 0.24.2 release from
>> https://gitlab.com/janneke/mes/-/tree/wip-stat64
>
> Thanks a lot, Janneke!
>
>> Just hoping this is also a fix for
>> https://debbugs.gnu.org/41264
>> https://debbugs.gnu.org/49985
>> as I haven't been able to reproduce this bug.  IWBN if someone could
>> shed more light on that...
>
> The patch-mes package also builds on my laptop with an SSD, so I do not
> know how to reproduce it. If someone else does, that would be great.

Thanks a lot for testing!

I have released 0.24.2 and updated mes-boot on core-updates as
b928e38bd333e6186727fe5c5e94b85d157b79d6

Let's hope this fixes these bugs.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: Merging core-updates?

[Kaelyn]

--- Original Message ---
On Tuesday, February 14th, 2023 at 8:29 PM, Kaelyn 
 wrote:
> 
> --- Original Message ---
> On Tuesday, February 14th, 2023 at 2:50 PM, Efraim Flashner 
> efr...@flashner.co.il wrote:
> 
> [snip]
> 
> > I ended up going a different route and moving xz from the finalize
> > packages to an actual xz-final and replacing xz-bootstrap/xz-mesboot in
> > %boot6-inputs.
> > 
> > I also tracked down the issue in tar and adjusted the testsuite so it
> > shouldn't be a problem on 32-bit systems.
> 
> 
> I just tried building wine-minimal from core-updates at commit da7d615629, 
> and I think you may have be missing a "!" with the new flag for the tar test 
> suite (i.e. it needs to be "-k '!tricky time stamps'"). Based on the build 
> log, right now only the failing test is being run:
> 
> ## - ##
> ## Test results. ##
> ## - ##
> 
> ERROR: 1 test was run,
> 1 failed unexpectedly.
> 
> ##  ##
> ## Summary of the failures. ##
> ##  ##
> Failed tests:
> GNU tar 1.34 test suite test groups:
> 
> NUM: FILE-NAME:LINE TEST-GROUP-NAME
> KEYWORDS
> 
> 151: time01.at:20 time: tricky time stamps
> time time01

I wanted to give a quick update: once I fixed the test exclusion for tar, I was 
successful in building wine-minimal on core-updates (which is 32-bit package on 
x86_64 as well).

> Cheers,
> Kaelyn
> 
> > --
> > Efraim Flashner efr...@flashner.co.il אפרים פלשנר
> > 
> > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> > Confidentiality cannot be guaranteed on emails sent or received unencrypted

Re: Merging core-updates?

[Kaelyn]

--- Original Message ---
On Tuesday, February 14th, 2023 at 2:50 PM, Efraim Flashner 
 wrote:
> 
[snip] 
> 
> I ended up going a different route and moving xz from the finalize
> packages to an actual xz-final and replacing xz-bootstrap/xz-mesboot in
> %boot6-inputs.
> 
> I also tracked down the issue in tar and adjusted the testsuite so it
> shouldn't be a problem on 32-bit systems.

I just tried building wine-minimal from core-updates at commit da7d615629, and 
I think you may have be missing a "!" with the new flag for the tar test suite 
(i.e. it needs to be "-k '!tricky time stamps'"). Based on the build log, right 
now only the failing test is being run:

## - ##
## Test results. ##
## - ##

ERROR: 1 test was run,
1 failed unexpectedly.

##  ##
## Summary of the failures. ##
##  ##
Failed tests:
GNU tar 1.34 test suite test groups:

 NUM: FILE-NAME:LINE TEST-GROUP-NAME
  KEYWORDS

 151: time01.at:20   time: tricky time stamps
  time time01

Cheers,
Kaelyn

> 
> --
> Efraim Flashner efr...@flashner.co.il אפרים פלשנר
> 
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

Re: Architecture support [was: Re: Merging core-updates?]

[Efraim Flashner]

On Tue, Feb 14, 2023 at 05:30:32PM +0100, Andreas Enge wrote:
> Hello,
> 
> Am Mon, Feb 13, 2023 at 12:56:45PM +0200 schrieb Efraim Flashner:
> > Aarch64 and armhf are getting stuck at gcc-cross-boot0.
> 
> I got to hello on my aarch64, which is very encouraging! I will have to
> try again with your latest changes to core-updates, but am rather optimistic.

It might just be my machines then. My pinebook pro doesn't have a lot of
space available for building and my pine64 only has 2GB of ram.

Also I made a typo in the tar fix, so I'll push a fix for that after I
confirm that it actually skips the broken test.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Merging core-updates?

[Andreas Enge]

Am Mon, Feb 13, 2023 at 11:31:15PM +0200 schrieb Efraim Flashner:
> Looks like you might be able to drop openjdk-10-hotspot-stack-size.patch
> from openjdk-19.0.1.

Maybe. What is strange is that we have the same openjdk package on master,
apparently with the patch. I will give it a try nevertheless.

Andreas

Re: Architecture support [was: Re: Merging core-updates?]

[Julien Lepiller]

Could we get berlin to evaluate a small set of core packages (mpc, hello, …)? 
Are the changes intended to fix the issue with bordeaux's machines? Is it 
configured to build core-updates?

Le 14 février 2023 17:30:32 GMT+01:00, Andreas Enge  a écrit :
>Hello,
>
>Am Mon, Feb 13, 2023 at 12:56:45PM +0200 schrieb Efraim Flashner:
>> Aarch64 and armhf are getting stuck at gcc-cross-boot0.
>
>I got to hello on my aarch64, which is very encouraging! I will have to
>try again with your latest changes to core-updates, but am rather optimistic.
>
>Andreas
>
>

Re: Architecture support [was: Re: Merging core-updates?]

[Andreas Enge]

Hello,

Am Mon, Feb 13, 2023 at 12:56:45PM +0200 schrieb Efraim Flashner:
> Aarch64 and armhf are getting stuck at gcc-cross-boot0.

I got to hello on my aarch64, which is very encouraging! I will have to
try again with your latest changes to core-updates, but am rather optimistic.

Andreas

Re: Merging core-updates?

[Efraim Flashner]

On Mon, Feb 13, 2023 at 09:36:17PM +, Kaelyn wrote:
> --- Original Message ---
> On Monday, February 13th, 2023 at 8:04 PM, Efraim Flashner 
>  wrote:
> > 
> > 
> > On Sun, Feb 12, 2023 at 06:29:04PM +, Kaelyn wrote:
> > 
> > > Hi,
> > > 
> > > --- Original Message ---
> > > On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge andr...@enge.fr 
> > > wrote:
> > > 
> > > > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
> > > > 
> > > > > And I was able to rebuild (with --check) patch-mesboot. The error 
> > > > > looks
> > > > > a lot like https://issues.guix.gnu.org/49985. We should fix that 
> > > > > indeed
> > > > > :)
> > > > 
> > > > Ah indeed, that looks like deal breaking; maybe someone from MES can 
> > > > have
> > > > a look?
> > > > 
> > > > What is the magic incantation with double "@@" to build this package?
> > > > Ah, here we go, for reference to self:
> > > > guix build -e '(@@ (gnu packages commencement) patch-mesboot)'
> > > > 
> > > > Andreas
> > > 
> > > While not directly related to the patch-mesboot error, I want to mention 
> > > that there is also https://issues.guix.gnu.org/58719 blocking i686 builds 
> > > on core-updates (and x86_64 builds of certain packages like wine64, which 
> > > has i686 dependencies) since the update to glibc 2.35.
> > > 
> > > It may also need assistance from the MES folks to fix, since the error 
> > > message is about an undefined symbol in glibc-mesboot's libpthread.so.0:
> > > 
> > > make[2]: Entering directory 
> > > '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic'
> > > ../src/file -C -m magic
> > > /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup 
> > > error: 
> > > /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0:
> > >  undefined symbol: h_errno, version GLIBC_PRIVATE
> > > make[2]: *** [Makefile:863: magic.mgc] Error 127
> > > 
> > > Cheers,
> > > Kaelyn
> > 
> > 
> > I think I found where this is coming from. %boot3-inputs added
> > ld-wrapper-boot3 but didn't remove ld-wrapper-0, which pulled in
> > glibc-mesboot. I'm testing out removing ld-wrapper-0 from %boot3-inputs
> > to see if that's enough to make that final file build. Hopefully it'll
> > also fix the final tar for i686, which I found was also failing for me.
> 
> Interesting! Since my last email, I was able to fix the issue with file by 
> adding "--disable-xzlib" to the file package in gnu/packages/commencement.scm 
> (after discovering it when noticing "--disable-bzlib" was being passed to the 
> configure script), but hadn't sent in a patch yet because I hit a subsequent 
> test failure while building tar. I thought to disable xz support because I 
> traced the source of the glibc-mesboot libpthread.so in the error message to 
> xz-mesboot being detected by the configure script and linked in even though 
> file itself was being linked against a newer glibc and had no explicit 
> dependencies. (I think the error after upgrading to glibc 2.35 from 2.33 was 
> an abi compatibility between the newer glibc and the old pthread being pulled 
> in via xz-mesboot.)
> 
> Cheers,
> Kaelyn

I ended up going a different route and moving xz from the finalize
packages to an actual xz-final and replacing xz-bootstrap/xz-mesboot in
%boot6-inputs.

I also tracked down the issue in tar and adjusted the testsuite so it
shouldn't be a problem on 32-bit systems.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Merging core-updates?

[Kaelyn]

--- Original Message ---
On Monday, February 13th, 2023 at 8:04 PM, Efraim Flashner 
 wrote:
> 
> 
> On Sun, Feb 12, 2023 at 06:29:04PM +, Kaelyn wrote:
> 
> > Hi,
> > 
> > --- Original Message ---
> > On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge andr...@enge.fr 
> > wrote:
> > 
> > > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
> > > 
> > > > And I was able to rebuild (with --check) patch-mesboot. The error looks
> > > > a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
> > > > :)
> > > 
> > > Ah indeed, that looks like deal breaking; maybe someone from MES can have
> > > a look?
> > > 
> > > What is the magic incantation with double "@@" to build this package?
> > > Ah, here we go, for reference to self:
> > > guix build -e '(@@ (gnu packages commencement) patch-mesboot)'
> > > 
> > > Andreas
> > 
> > While not directly related to the patch-mesboot error, I want to mention 
> > that there is also https://issues.guix.gnu.org/58719 blocking i686 builds 
> > on core-updates (and x86_64 builds of certain packages like wine64, which 
> > has i686 dependencies) since the update to glibc 2.35.
> > 
> > It may also need assistance from the MES folks to fix, since the error 
> > message is about an undefined symbol in glibc-mesboot's libpthread.so.0:
> > 
> > make[2]: Entering directory 
> > '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic'
> > ../src/file -C -m magic
> > /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup 
> > error: 
> > /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0:
> >  undefined symbol: h_errno, version GLIBC_PRIVATE
> > make[2]: *** [Makefile:863: magic.mgc] Error 127
> > 
> > Cheers,
> > Kaelyn
> 
> 
> I think I found where this is coming from. %boot3-inputs added
> ld-wrapper-boot3 but didn't remove ld-wrapper-0, which pulled in
> glibc-mesboot. I'm testing out removing ld-wrapper-0 from %boot3-inputs
> to see if that's enough to make that final file build. Hopefully it'll
> also fix the final tar for i686, which I found was also failing for me.

Interesting! Since my last email, I was able to fix the issue with file by 
adding "--disable-xzlib" to the file package in gnu/packages/commencement.scm 
(after discovering it when noticing "--disable-bzlib" was being passed to the 
configure script), but hadn't sent in a patch yet because I hit a subsequent 
test failure while building tar. I thought to disable xz support because I 
traced the source of the glibc-mesboot libpthread.so in the error message to 
xz-mesboot being detected by the configure script and linked in even though 
file itself was being linked against a newer glibc and had no explicit 
dependencies. (I think the error after upgrading to glibc 2.35 from 2.33 was an 
abi compatibility between the newer glibc and the old pthread being pulled in 
via xz-mesboot.)

Cheers,
Kaelyn

> 
> --
> Efraim Flashner efr...@flashner.co.il אפרים פלשנר
> 
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

Re: Merging core-updates?

[Efraim Flashner]

On Mon, Feb 13, 2023 at 09:35:32PM +0100, Andreas Enge wrote:
> Hello all,
> 
> here are my first important failures when trying to go beyond hello and mpc
> (aka the easy C programs):
> 
> ocaml-4.0.9 fails with
> gcc -c -O2 -fno-strict-aliasing -fwrapv -Wall -fno-tree-vrp -g 
> -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE  
> -DOCAML_STDLIB_DIR='"/gnu/store/mzzak7bp6dpngq04hphlx58wzp62755m-ocaml-4.09.0/lib/ocaml"'
>   -DNATIVE_CODE -DTARGET_amd64 -DMODEL_default -DSYS_linux   -o 
> signals_nat_n.o signals_nat.c
> signals_nat.c:185:13: error: variably modified ‘sig_alt_stack’ at file scope
>   185 | static char sig_alt_stack[SIGSTKSZ];
>   | ^
> make[3]: *** [Makefile:343: signals_nat_n.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[3]: Leaving directory 
> '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0/runtime'
> make[2]: *** [Makefile:1004: makeruntimeopt] Error 2
> make[2]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
> make[1]: *** [Makefile:417: opt.opt] Error 2
> make[1]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
> make: *** [Makefile:468: world.opt] Error 2
> error: in phase 'build': uncaught exception:
> %exception #< program: "make" arguments: ("-j" "4" "world.opt") 
> exit-status: 2 term-signal: #f stop-signal: #f>
> phase `build' failed after 45.7 seconds
> command "make" "-j" "4" "world.opt" failed with status 2
> 
> openjdk-19.0.1-checkout fails:
> `File make/modules/java.desktop/lib/Awt2dLibraries.gmk is read-only; trying 
> to patch anyway
> patching file make/modules/java.desktop/lib/Awt2dLibraries.gmk
> Hunk #1 succeeded at 214 (offset -3 lines).
> File src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c is 
> read-only; trying to patch anyway
> patching file src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c
> Hunk #1 succeeded at 44 (offset 4 lines).
> Hunk #2 succeeded at 978 (offset 4 lines).
> File test/jdk/java/awt/JAWT/Makefile.unix is read-only; trying to patch anyway
> patching file test/jdk/java/awt/JAWT/Makefile.unix
> File test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c is read-only; 
> trying to patch anyway
> patching file test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c
> Hunk #1 FAILED at 67.
> 1 out of 1 hunk FAILED -- saving rejects to file 
> test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c.rej
> source is at 'openjdk-19.0.1-checkout'
> applying 
> '/gnu/store/g6sgv9nipmvsxbmimlgsmhdcdvcssmhf-openjdk-15-xcursor-no-dynamic.patch'...
> applying 
> '/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch'...
> Backtrace:
>5 (primitive-load "/gnu/store/kpgzrwyczkxymc54lnkld0nmrd0…")
> In ice-9/eval.scm:
> 619:8  4 (_ #(#(# "ope…") #))
> In ice-9/boot-9.scm:
> 142:2  3 (dynamic-wind # …)
> In ice-9/eval.scm:
> 619:8  2 (_ #(#(#)))
> In srfi/srfi-1.scm:
> 634:9  1 (for-each # _)
> In guix/build/utils.scm:
> 812:6  0 (invoke "/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-p…" …)
> 
> guix/build/utils.scm:812:6: In procedure invoke:
> ERROR:
>   1. :
>   program: 
> "/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-patch-2.7.6/bin/patch"
>   arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" 
> "/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch")
>   exit-status: 1
>   term-signal: #f
>   stop-signal: #f
> Just a permission error on files to be patched, or a problem with the patch 
> itself?
> 
> Andreas

Looks like you might be able to drop openjdk-10-hotspot-stack-size.patch
from openjdk-19.0.1.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Merging core-updates?

[Development of GNU Guix and the GNU System distribution.]

Hi

On Mon, Feb 13, 2023 at 12:22 PM Andreas Enge  wrote:
>
> It looks like we have reached the Debian trap

How about applying selectively those patches from core-updates that do
not break anything? It would split the difference.

Future changes waiting in Debbugs could join the remainder, which
needs more work. Later, the new branch could go through the same
procedure, i.e. any breakage would be caught.

The new process would be gradual and allow some commits to advance
into the project history (also known as the 'master' branch) within a
predicable time frame.

Thanks everyone for your hard work!

Kind regards
Felix Lechner

Re: Merging core-updates?

[Andreas Enge]

Hello all,

here are my first important failures when trying to go beyond hello and mpc
(aka the easy C programs):

ocaml-4.0.9 fails with
gcc -c -O2 -fno-strict-aliasing -fwrapv -Wall -fno-tree-vrp -g 
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE  
-DOCAML_STDLIB_DIR='"/gnu/store/mzzak7bp6dpngq04hphlx58wzp62755m-ocaml-4.09.0/lib/ocaml"'
  -DNATIVE_CODE -DTARGET_amd64 -DMODEL_default -DSYS_linux   -o signals_nat_n.o 
signals_nat.c
signals_nat.c:185:13: error: variably modified ‘sig_alt_stack’ at file scope
  185 | static char sig_alt_stack[SIGSTKSZ];
  | ^
make[3]: *** [Makefile:343: signals_nat_n.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory 
'/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0/runtime'
make[2]: *** [Makefile:1004: makeruntimeopt] Error 2
make[2]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
make[1]: *** [Makefile:417: opt.opt] Error 2
make[1]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
make: *** [Makefile:468: world.opt] Error 2
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("-j" "4" "world.opt") 
exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 45.7 seconds
command "make" "-j" "4" "world.opt" failed with status 2

openjdk-19.0.1-checkout fails:
`File make/modules/java.desktop/lib/Awt2dLibraries.gmk is read-only; trying to 
patch anyway
patching file make/modules/java.desktop/lib/Awt2dLibraries.gmk
Hunk #1 succeeded at 214 (offset -3 lines).
File src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c is read-only; 
trying to patch anyway
patching file src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c
Hunk #1 succeeded at 44 (offset 4 lines).
Hunk #2 succeeded at 978 (offset 4 lines).
File test/jdk/java/awt/JAWT/Makefile.unix is read-only; trying to patch anyway
patching file test/jdk/java/awt/JAWT/Makefile.unix
File test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c is read-only; 
trying to patch anyway
patching file test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c
Hunk #1 FAILED at 67.
1 out of 1 hunk FAILED -- saving rejects to file 
test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c.rej
source is at 'openjdk-19.0.1-checkout'
applying 
'/gnu/store/g6sgv9nipmvsxbmimlgsmhdcdvcssmhf-openjdk-15-xcursor-no-dynamic.patch'...
applying 
'/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch'...
Backtrace:
   5 (primitive-load "/gnu/store/kpgzrwyczkxymc54lnkld0nmrd0…")
In ice-9/eval.scm:
619:8  4 (_ #(#(# "ope…") #))
In ice-9/boot-9.scm:
142:2  3 (dynamic-wind # …)
In ice-9/eval.scm:
619:8  2 (_ #(#(#)))
In srfi/srfi-1.scm:
634:9  1 (for-each # _)
In guix/build/utils.scm:
812:6  0 (invoke "/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-p…" …)

guix/build/utils.scm:812:6: In procedure invoke:
ERROR:
  1. :
  program: 
"/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-patch-2.7.6/bin/patch"
  arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" 
"/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch")
  exit-status: 1
  term-signal: #f
  stop-signal: #f
Just a permission error on files to be patched, or a problem with the patch 
itself?

Andreas

Re: Merging core-updates?

[Andreas Enge]

Hello,

Am Sun, Feb 12, 2023 at 05:51:47PM +0200 schrieb Efraim Flashner:
> I think we normally have a 2 week last-chance window to get all sorts of
> last minute packages bumped and then we freeze it and try to build
> "everything".

I am a bit hesitant to let more breakages in :)  It looks like we have
reached the Debian trap: releases/core-update merges happen so infrequently
that people become desperate to get their favourite update in, which causes
build failures, which delay the release cycle, da capo ad infinitum.

Personally I would prefer to freeze now, then to let other big changes
(mesa for instance) happen in a feature branch; if all goes well, it could
be merged a week or two later, if it breaks things, it will anyway take
the time it needs to fix them.

Andreas

Re: Merging core-updates?

[Efraim Flashner]

On Sun, Feb 12, 2023 at 06:29:04PM +, Kaelyn wrote:
> Hi,
> 
> --- Original Message ---
> On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge  
> wrote:
> 
> >
> >
> > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
> >
> > > And I was able to rebuild (with --check) patch-mesboot. The error looks
> > > a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
> > > :)
> >
> >
> > Ah indeed, that looks like deal breaking; maybe someone from MES can have
> > a look?
> >
> > What is the magic incantation with double "@@" to build this package?
> > Ah, here we go, for reference to self:
> > guix build -e '(@@ (gnu packages commencement) patch-mesboot)'
> >
> > Andreas
> 
> While not directly related to the patch-mesboot error, I want to mention that 
> there is also https://issues.guix.gnu.org/58719 blocking i686 builds on 
> core-updates (and x86_64 builds of certain packages like wine64, which has 
> i686 dependencies) since the update to glibc 2.35.
> 
> It may also need assistance from the MES folks to fix, since the error 
> message is about an undefined symbol in glibc-mesboot's libpthread.so.0:
> 
> make[2]: Entering directory '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic'
> ../src/file -C -m magic
> /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup 
> error: 
> /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0:
>  undefined symbol: h_errno, version GLIBC_PRIVATE
> make[2]: *** [Makefile:863: magic.mgc] Error 127
> 
> Cheers,
> Kaelyn

I think I found where this is coming from. %boot3-inputs added
ld-wrapper-boot3 but didn't remove ld-wrapper-0, which pulled in
glibc-mesboot. I'm testing out removing ld-wrapper-0 from %boot3-inputs
to see if that's enough to make that final file build. Hopefully it'll
also fix the final tar for i686, which I found was also failing for me.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Merging core-updates?

[John Kehayias]

Hi Katherine et al,

On Mon, Feb 13, 2023 at 09:40 AM, Katherine Cox-Buday wrote:

> Efraim Flashner  writes:
>
>> On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote:
>>> Hi Guix!
>>>
>>> As discussed at Guix Days before Fosdem, we haven't merged core-updates
>>> in a very long time. I'd volunteer to lead this effort, but I don't
>>> know what steps I should follow. Do we have some documentation about
>>> that?
>>
>> I think we normally have a 2 week last-chance window to get all sorts of
>> last minute packages bumped and then we freeze it and try to build
>> "everything".
>
>
> On that note, could we possibly give Mesa one final bump? The latest
> version is 22.3.5, and the version in core-updates is 22.2.4.
>
> I also hope to be able to test, but my schedule tends to run away from
> me.

Yes, I would like to get Mesa up to date, we have the smaller LLVM closure now 
and the pending patches for some Vulkan paths/packages. I would like to help 
review/test/push those but I'm in the middle of a move so if anyone wants to 
beat me to it in the next week or so, please do :) But yes, those are all on my 
radar and certainly a preferred activity to more packing...

John

Re: Merging core-updates?

[Katherine Cox-Buday]

Efraim Flashner  writes:

> On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote:
>> Hi Guix!
>> 
>> As discussed at Guix Days before Fosdem, we haven't merged core-updates
>> in a very long time. I'd volunteer to lead this effort, but I don't
>> know what steps I should follow. Do we have some documentation about
>> that?
>
> I think we normally have a 2 week last-chance window to get all sorts of
> last minute packages bumped and then we freeze it and try to build
> "everything".


On that note, could we possibly give Mesa one final bump? The latest
version is 22.3.5, and the version in core-updates is 22.2.4.

I also hope to be able to test, but my schedule tends to run away from
me.

-- 
Katherine

Re: Merging core-updates?

[Andreas Enge]

Am Mon, Feb 13, 2023 at 12:34:56PM +0100 schrieb Janneke Nieuwenhuizen:
> To use stat64 and friends on 32bit, I created the attached patch for GNU
> Mes and hope to create a 0.24.2 release from
> https://gitlab.com/janneke/mes/-/tree/wip-stat64

Thanks a lot, Janneke!

> Just hoping this is also a fix for
> https://debbugs.gnu.org/41264
> https://debbugs.gnu.org/49985
> as I haven't been able to reproduce this bug.  IWBN if someone could
> shed more light on that...

The patch-mes package also builds on my laptop with an SSD, so I do not
know how to reproduce it. If someone else does, that would be great.

Andreas

Re: Merging core-updates?

[Janneke Nieuwenhuizen]

Andreas Enge writes:

> Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
>> And I was able to rebuild (with --check) patch-mesboot. The error looks
>> a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
>> :)
>
> Ah indeed, that looks like deal breaking; maybe someone from MES can have
> a look?
>
> What is the magic incantation with double "@@" to build this package?
> Ah, here we go, for reference to self:
>guix build -e '(@@ (gnu packages commencement) patch-mesboot)'

To use stat64 and friends on 32bit, I created the attached patch for GNU
Mes and hope to create a 0.24.2 release from

https://gitlab.com/janneke/mes/-/tree/wip-stat64

Also, I have update my core-updates branch with preliminary 0.24.2 mes
and mes-boot packages here

https://gitlab.com/janneke/guix/-/tree/core-updates

Just hoping this is also a fix for

https://debbugs.gnu.org/41264
https://debbugs.gnu.org/49985

as I haven't been able to reproduce this bug.  IWBN if someone could
shed more light on that...

Greetings,
Janneke

>From bc1fa57851d360abb161c54dce5339ad9d7af7aa Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen" 
Date: Sat, 29 Oct 2022 13:17:58 +0200
Subject: [PATCH] lib: stat: Use SYS_stat64 for 32bit platforms.

This fixes .

* include/linux/arm/syscall.h (SYS_stat64, SYS_lstat64,
SYS_fstat64)[__SIZEOF_LONG_LONG__ == 8]:
New defines.
(SYS_stat, SYS_lstat, SYS_fstat)[__SIZEOF_LONG_LONG__ == 8]: Redefine them.
* include/linux/x86/syscall.h (SYS_stat64, SYS_lstat64,
SYS_fstat64)[__SIZEOF_LONG_LONG__ == 8]:
New defines.
(SYS_stat, SYS_lstat, SYS_fstat)[__SIZEOF_LONG_LONG__ == 8]: Redefine them.
* include/sys/stat.h (struct stat): Move definition to...
* include/linux/arm/kernel-stat.h,
include/linux/m2/kernel-stat.h,
include/linux/x86/kernel-stat.h,
include/linux/x86_64/kernel-stat.h: These new files.
* include/gnu/x86/kernel-stat.h: New file.
* configure (main): Copy include///*.h to
include/.
* configure.sh: Likewise.
* .gitignore: Ignore them.  Add copyright header.
* build-aux/GNUmakefile.in (X86_ARCH_HEADERS, ARCH_HEADERS): New
variables.
(build): Use them.
(include/arch/%.h, arch-dir): New targets.
* build-aux/bootstrap.sh.in (AM_CPPFLAGS): Replace
include// with built ../include.
* build-aux/build.sh.in (AM_CPPFLAGS): Likewise.
* build-aux/install.sh.in: Also install built include.
* include/m2/types.h: New file.
* kaem.run: Use it.
* simple.sh: Copy kernel-stat.h, syscall.h for kernel/cpu to
include/arch.
---
 .gitignore |  19 
 build-aux/GNUmakefile.in   |  11 ++-
 build-aux/bootstrap.sh.in  |   4 +-
 build-aux/build.sh.in  |  11 ++-
 build-aux/install.sh.in|   3 +-
 configure  |   7 ++
 configure.sh   |   4 +
 include/gnu/x86/kernel-stat.h  |  25 ++
 include/linux/arm/kernel-stat.h|  79 +
 include/linux/arm/syscall.h|  19 
 include/linux/m2/kernel-stat.h |  47 ++
 include/linux/x86/kernel-stat.h|  79 +
 include/linux/x86/syscall.h|  20 -
 include/linux/x86_64/kernel-stat.h |  51 +++
 include/m2/types.h | 138 +
 include/sys/stat.h |  51 +--
 kaem.run   |   3 +
 lib/linux/_getcwd.c|   4 +-
 lib/linux/_open3.c |   2 +-
 lib/linux/_read.c  |   4 +-
 lib/linux/access.c |   4 +-
 lib/linux/brk.c|   4 +-
 lib/linux/chdir.c  |   4 +-
 lib/linux/chmod.c  |   4 +-
 lib/linux/clock_gettime.c  |   4 +-
 lib/linux/close.c  |   4 +-
 lib/linux/dup.c|   4 +-
 lib/linux/dup2.c   |   4 +-
 lib/linux/execve.c |   4 +-
 lib/linux/fcntl.c  |   4 +-
 lib/linux/fork.c   |   4 +-
 lib/linux/fstat.c  |   4 +-
 lib/linux/fsync.c  |   4 +-
 lib/linux/getdents.c   |   4 +-
 lib/linux/getegid.c|   4 +-
 lib/linux/geteuid.c|   4 +-
 lib/linux/getgid.c |   4 +-
 lib/linux/getpid.c |   4 +-
 lib/linux/getppid.c|   4 +-
 lib/linux/getrusage.c  |   4 +-
 lib/linux/gettimeofday.c   |   4 +-
 lib/linux/getuid.c |   4 +-
 lib/linux/ioctl.c  |   2 +-
 lib/linux/ioctl3.c |   2 +-
 lib/linux/kill.c   |   4 +-
 lib/linux/link.c   |   4 +-
 lib/linux/lseek.c  |   2 +-
 lib/linux/lstat.c  |   4 +-
 lib/linux/mkdir.c  |   4 +-
 lib/linux/mknod.c  |   4 +-
 lib/linux/nanosleep.c  |   4 +-
 lib/linux/pipe.c   |   4 +-
 lib/linux/read.c   

Architecture support [was: Re: Merging core-updates?]

[Efraim Flashner]

On Mon, Feb 13, 2023 at 10:43:17AM +0100, zimoun wrote:
> Hi,
> 
> Well, it could be helpful is Berlin or Bordeaux could build some
> manifest of core-updates (not necessary the whole core-updates).  And
> then, once the manifest builds, we could add some packages and repeat.
> 
> It would avoid that we all build the same things; worse, that each of us
> burn many CPU just for knowing it fails.
> 
> Chris, Mathieu?  What do you think?
> 

At least locally I try to build out to hello, and then to mesa.

Currently I believe only x86_64 is building to hello. I'm not against
downgrading file to an earlier version if it'll get i686 to get to
hello.

i686 is getting stuck at an unknown file.
Aarch64 and armhf are getting stuck at gcc-cross-boot0.
Riscv64 is getting stuck at gcc-final.
I haven't tested powerpc64le (or powerpc or mips64el).

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Merging core-updates?

[zimoun]

Hi,

On Sun, 12 Feb 2023 at 10:05, Julien Lepiller  wrote:

> As discussed at Guix Days before Fosdem, we haven't merged core-updates
> in a very long time. I'd volunteer to lead this effort, but I don't
> know what steps I should follow. Do we have some documentation about
> that?

Maybe a start could be to fix: 

Well, it could be helpful is Berlin or Bordeaux could build some
manifest of core-updates (not necessary the whole core-updates).  And
then, once the manifest builds, we could add some packages and repeat.

It would avoid that we all build the same things; worse, that each of us
burn many CPU just for knowing it fails.

Chris, Mathieu?  What do you think?


Cheers,
simon

Re: Merging core-updates?

[John Kehayias]

Hi guix-devel!

On Sun, Feb 12, 2023 at 03:49 PM, Josselin Poiret wrote:

> Hi everyone,
>
> Andreas Enge  writes:
>
>> I volunteer to follow your lead, but also have no clue what is actually
>> expected.
>
> I would also like to give a hand!
>

Count me in as well!

I only did some spot fixes the last round, but at least I have some familiarity 
with what happened. I don't have any particular expertise but I'm happy to help 
coordinate overall, test, and generally do some cat herding.

And now that I have commit access I hope I can really help move things through 
with review and pushing ready patches. Unfortunately had some other stuff come 
up for the last few months since I got access, but I should have more time 
starting in a week or so.

On that front, I think looking through relevant core-updates patches (the Mesa 
ones in particular, for me) is a good first step for review and I'll try 
building on my end to see how far I get.

>> [...]
>> Actually I am wondering whether the first step of killing these untamed
>> non-feature branches would not be to build and merge staging? It is based
>> on master, supposed to contain only medium sized changes, but which I
>> suspect end up being a world-rebuilding cluster of changes.
>
> You're right, for this to smoothly transition into the "feature branch
> workflow" (if that's actually what we want to do) I guess we also need
> to lay out a plan first, and prepare for the post-c.u-merge
> world. Getting rid of staging first could be an easier exercise,
> followed by c-u. I was planning on taking your notes of the Guix days
> and opening a discussion about how we could concretely transition to
> this new workflow, I can maybe do that this evening.
>

I need to catch up on the thread about feature branches and I'm looking forward 
to that as well. It has something that I have long wanted and will gladly help 
in that transition and doing what I can to make that go smoothly.

John

Re: Merging core-updates?

[Janneke Nieuwenhuizen]

Andreas Enge writes:

> Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
>> And I was able to rebuild (with --check) patch-mesboot. The error looks
>> a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
>> :)
>
> Ah indeed, that looks like deal breaking; maybe someone from MES can have
> a look?

I have backported

DRAFT lib: stat: Use SYS_stat64 for 32bit platforms.wip

to `wip'


https://git.savannah.gnu.org/cgit/mes.git/commit/?id=05d10877410b48d0a4f8960fd62190d70329eea7

that was slated to become Mes 0.25, after adding initial risc-v support
and some thorough testing.  If this works, maybe we should postpone
initial risc-v support to 0.26.

> What is the magic incantation with double "@@" to build this package?
> Ah, here we go, for reference to self:
>guix build -e '(@@ (gnu packages commencement) patch-mesboot)'

Thanks.  It would be nice, however, if there was a way for me to
reproduce this bug.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: Merging core-updates?

[Kaelyn]

Hi,

--- Original Message ---
On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge  wrote:

>
>
> Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
>
> > And I was able to rebuild (with --check) patch-mesboot. The error looks
> > a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
> > :)
>
>
> Ah indeed, that looks like deal breaking; maybe someone from MES can have
> a look?
>
> What is the magic incantation with double "@@" to build this package?
> Ah, here we go, for reference to self:
> guix build -e '(@@ (gnu packages commencement) patch-mesboot)'
>
> Andreas

While not directly related to the patch-mesboot error, I want to mention that 
there is also https://issues.guix.gnu.org/58719 blocking i686 builds on 
core-updates (and x86_64 builds of certain packages like wine64, which has i686 
dependencies) since the update to glibc 2.35.

It may also need assistance from the MES folks to fix, since the error message 
is about an undefined symbol in glibc-mesboot's libpthread.so.0:

make[2]: Entering directory '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic'
../src/file -C -m magic
/tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup error: 
/gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0:
 undefined symbol: h_errno, version GLIBC_PRIVATE
make[2]: *** [Makefile:863: magic.mgc] Error 127

Cheers,
Kaelyn


P.S. I also have https://issues.guix.gnu.org/59453 open for few months to fix 
the Vulkan layer paths in mesa on core-updates, which I'd really like to see 
land before a core-updates merge happens (it had originally been part of a mesa 
version update patch I sent in back in October, but which had been obsoleted by 
a newer patch release of mesa landing in core-updates; mesa in core-updates is 
also a few releases behind at this point, but that's a separate matter).

Re: Merging core-updates?

[Andreas Enge]

Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
> And I was able to rebuild (with --check) patch-mesboot. The error looks
> a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
> :)

Ah indeed, that looks like deal breaking; maybe someone from MES can have
a look?

What is the magic incantation with double "@@" to build this package?
Ah, here we go, for reference to self:
   guix build -e '(@@ (gnu packages commencement) patch-mesboot)'

Andreas

Re: Merging core-updates?

[Efraim Flashner]

On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote:
> Hi Guix!
> 
> As discussed at Guix Days before Fosdem, we haven't merged core-updates
> in a very long time. I'd volunteer to lead this effort, but I don't
> know what steps I should follow. Do we have some documentation about
> that?

I think we normally have a 2 week last-chance window to get all sorts of
last minute packages bumped and then we freeze it and try to build
"everything".

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Merging core-updates?

[Josselin Poiret]

Hi everyone,

Andreas Enge  writes:

> I volunteer to follow your lead, but also have no clue what is actually
> expected.

I would also like to give a hand!

> [...]
> Actually I am wondering whether the first step of killing these untamed
> non-feature branches would not be to build and merge staging? It is based
> on master, supposed to contain only medium sized changes, but which I
> suspect end up being a world-rebuilding cluster of changes.

You're right, for this to smoothly transition into the "feature branch
workflow" (if that's actually what we want to do) I guess we also need
to lay out a plan first, and prepare for the post-c.u-merge
world. Getting rid of staging first could be an easier exercise,
followed by c-u. I was planning on taking your notes of the Guix days
and opening a discussion about how we could concretely transition to
this new workflow, I can maybe do that this evening.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: Merging core-updates?

[Christopher Baines]

Julien Lepiller  writes:

> As discussed at Guix Days before Fosdem, we haven't merged core-updates
> in a very long time. I'd volunteer to lead this effort, but I don't
> know what steps I should follow. Do we have some documentation about
> that?

I can try and help with this, at least in terms of helping get
bordeaux.guix.gnu.org substitute availability to a good level.

I'd also like to get the kind of comparison that the qa-frontpage can do
for patches working for branches, but that'll probably take a bit of
work in the data service/qa-frontpage to get working smoothly.


signature.asc
Description: PGP signature

Re: Merging core-updates?

[Christopher Baines]

Julien Lepiller  writes:

> Le Sun, 12 Feb 2023 12:52:51 +0100,
> Julien Lepiller  a écrit :
>
>> Le Sun, 12 Feb 2023 12:06:14 +0100,
>> Andreas Enge  a écrit :
>> 
>> I just tried to build mpc on my machine, from core-updates. I get the
>> same derivation as the one shown on the data service, and it built
>> fine. Maybe there's something wrong with the machines behind bordeaux?
>> I probably got substitutes from berlin, for gcc and friends (though I
>> built gmp, mpfr and mpc).
>
> And I was able to rebuild (with --check) patch-mesboot. The error looks
> a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
> :)

It could be something "wrong" with a build machine, although my
suspicion for a while is that various things are broken/don't work on
btrfs, which milano-guix-1 (the most important x86_64-linux) build
machine uses.

I've filed a few issues that probably relate to this:

https://issues.guix.gnu.org/53415
https://issues.guix.gnu.org/53416
https://issues.guix.gnu.org/60202

There are other build machines that don't use btrfs, so it should be
possible to get these things built anyway.


signature.asc
Description: PGP signature

Re: Merging core-updates?

[Leo Famulari]

On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote:
> As discussed at Guix Days before Fosdem, we haven't merged core-updates
> in a very long time. I'd volunteer to lead this effort, but I don't
> know what steps I should follow. Do we have some documentation about
> that?

The process could be considered "free form".

Basically, you can try to reconfigure your system on core-updates. It
will fail, many build failures will have to be fixed, and eventually it
will work.

Then I would run the Guix test suite and the system tests, and also
try to make use of QA.

It's likely that different architectures will have some specific
problems to be fixed.

Re: Merging core-updates?

[Julien Lepiller]

Le Sun, 12 Feb 2023 12:52:51 +0100,
Julien Lepiller  a écrit :

> Le Sun, 12 Feb 2023 12:06:14 +0100,
> Andreas Enge  a écrit :
> 
> I just tried to build mpc on my machine, from core-updates. I get the
> same derivation as the one shown on the data service, and it built
> fine. Maybe there's something wrong with the machines behind bordeaux?
> I probably got substitutes from berlin, for gcc and friends (though I
> built gmp, mpfr and mpc).
> 

And I was able to rebuild (with --check) patch-mesboot. The error looks
a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
:)

Re: Merging core-updates?

[Julien Lepiller]

Le Sun, 12 Feb 2023 12:06:14 +0100,
Andreas Enge  a écrit :

> Hello,
> 
> Am Sun, Feb 12, 2023 at 10:05:40AM +0100 schrieb Julien Lepiller:
> > As discussed at Guix Days before Fosdem, we haven't merged
> > core-updates in a very long time. I'd volunteer to lead this
> > effort, but I don't know what steps I should follow. Do we have
> > some documentation about that?  
> 
> I volunteer to follow your lead, but also have no clue what is
> actually expected.
> 
> With Chris's help, I scheduled an evaluation on the build coordinator,
> which has not finished yet, so there is not yet anything to see at
>
> http://data.qa.guix.gnu.org/gnu/store/bjyfp7bhb9j25sw62nrkqjiivnzjxija-mpc-1.3.1.drv
> But if you click down the dependency tree, some of them have been
> built. And the first one already failed:
>
> http://data.qa.guix.gnu.org/gnu/store/0p0zs4gv8vg7rny25ki1szv4c7yk9zzb-patch-mesboot-2.5.9.drv
> With a strange error:
> starting phase `build'
> make: stat:Makefile: sterror: unknown error
> make: *** No targets specified and no makefile found.  Stop.
> error: in phase 'build': uncaught exception:
> srfi-34 # exit-status: 2 term-signal: #f stop-signal: #f] 1439cc0> phase
> `build' failed after 0.0 seconds command "make" failed with status 2
> Having failed three times in a row, this does not look like a
> transient error.
> 
> I also reconfigured bayfront to do more builds itself.
> 
> Actually I am wondering whether the first step of killing these
> untamed non-feature branches would not be to build and merge staging?
> It is based on master, supposed to contain only medium sized changes,
> but which I suspect end up being a world-rebuilding cluster of
> changes.
> 
> Andreas
> 

I just tried to build mpc on my machine, from core-updates. I get the
same derivation as the one shown on the data service, and it built
fine. Maybe there's something wrong with the machines behind bordeaux?
I probably got substitutes from berlin, for gcc and friends (though I
built gmp, mpfr and mpc).

Re: Merging core-updates?

[Andreas Enge]

Hello,

Am Sun, Feb 12, 2023 at 10:05:40AM +0100 schrieb Julien Lepiller:
> As discussed at Guix Days before Fosdem, we haven't merged core-updates
> in a very long time. I'd volunteer to lead this effort, but I don't
> know what steps I should follow. Do we have some documentation about
> that?

I volunteer to follow your lead, but also have no clue what is actually
expected.

With Chris's help, I scheduled an evaluation on the build coordinator,
which has not finished yet, so there is not yet anything to see at
   
http://data.qa.guix.gnu.org/gnu/store/bjyfp7bhb9j25sw62nrkqjiivnzjxija-mpc-1.3.1.drv
But if you click down the dependency tree, some of them have been built.
And the first one already failed:
   
http://data.qa.guix.gnu.org/gnu/store/0p0zs4gv8vg7rny25ki1szv4c7yk9zzb-patch-mesboot-2.5.9.drv
With a strange error:
starting phase `build'
make: stat:Makefile: sterror: unknown error
make: *** No targets specified and no makefile found.  Stop.
error: in phase 'build': uncaught exception:
srfi-34 # 
phase `build' failed after 0.0 seconds
command "make" failed with status 2
Having failed three times in a row, this does not look like a transient error.

I also reconfigured bayfront to do more builds itself.

Actually I am wondering whether the first step of killing these untamed
non-feature branches would not be to build and merge staging? It is based
on master, supposed to contain only medium sized changes, but which I
suspect end up being a world-rebuilding cluster of changes.

Andreas

Merging core-updates?

[Julien Lepiller]

Hi Guix!

As discussed at Guix Days before Fosdem, we haven't merged core-updates
in a very long time. I'd volunteer to lead this effort, but I don't
know what steps I should follow. Do we have some documentation about
that?

Re: Merging core-updates

[Ricardo Wurmus]

Hi Ludo,

> ‘core-updates’ is now merged!

Yay!

> Now the question is whether we can merge ‘wip-gnome-upgrades’ before the
> release, which I’d like to push out later this week, or whether it
> should wait a few more days.

Unfortunately, gnome-shell segfaults on wip-gnome-upgrades.  I’ve
decided to upgrade to the next version of GNOME (3.30 instead of 3.28)
and rather spend time on making that version work.

This will take some time (and cause quite a few rebuilds), so it should
not block the upcoming release.

--
Ricardo

Re: Merging core-updates

[Ludovic Courtès]

Hello Guix!

‘core-updates’ is now merged!

Thanks to everyone who contributed to the tedious testing and
stabilization process.  It certainly took us way too long but now we’re
happy to get all the new stuff: glibc 2.28, guile 2.2.4 by default, and
lots of things we worked on so long ago that we don’t even remember.
:-)

Now the question is whether we can merge ‘wip-gnome-upgrades’ before the
release, which I’d like to push out later this week, or whether it
should wait a few more days.

Ludo’.

Re: Merging core-updates

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> On Sat, 01 Dec 2018 19:20:26 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> On x86_64, LibreOffice, IceCat, etc. are available as substitutes; ‘guix
>> weather’ reports only 50% of coverage on berlin and 80% on
>> mirror.hydra.gnu.org (we’ll have to elucidate the bad number on berlin.)
>> I’m using ‘core-updates’ for both my system and my user profile.
>> 
>> Overall I’m in favor of merging.
>
> Me too.
>
> I've finally disabled the flaky Rust test in core-updates so it shouldn't
> nondeterministically break the build anymore.  Unfortunately that means
> it will cause some senseless rebuilds - among those icecat :(

Sounds good.  Thanks for taking care of this!

> So let's wait for those builds and then merge.

OK, hopefully that’ll be done by the end of the day.

This in turn means we could release 0.16.0 Wednesday or so (I’ll be at
the R-B Summit the next week anyway so it’d be good to get it done by
then!).

Ludo’.

Re: Merging core-updates

[Danny Milosavljevic]

Hi Ludo,

On Sat, 01 Dec 2018 19:20:26 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> On x86_64, LibreOffice, IceCat, etc. are available as substitutes; ‘guix
> weather’ reports only 50% of coverage on berlin and 80% on
> mirror.hydra.gnu.org (we’ll have to elucidate the bad number on berlin.)
> I’m using ‘core-updates’ for both my system and my user profile.
> 
> Overall I’m in favor of merging.

Me too.

I've finally disabled the flaky Rust test in core-updates so it shouldn't
nondeterministically break the build anymore.  Unfortunately that means
it will cause some senseless rebuilds - among those icecat :(

So let's wait for those builds and then merge.


pgpU8daKbEfAQ.pgp
Description: OpenPGP digital signature

Re: Merging core-updates

[Jan Nieuwenhuizen]

Ricardo Wurmus writes:

>> Overall I’m in favor of merging.
>
> I agree.
>
> I’ve been using core-updates on my laptop (both system and user profile)
> for about a week now without any problems.

Me too.

janneke

Re: Merging core-updates

[Ricardo Wurmus]

Hi,

> ‘core-updates’ seems to be in a rather good shape. […]
> On x86_64, LibreOffice, IceCat, etc. are available as substitutes; ‘guix
> weather’ reports only 50% of coverage on berlin and 80% on
> mirror.hydra.gnu.org (we’ll have to elucidate the bad number on berlin.)
> I’m using ‘core-updates’ for both my system and my user profile.
>
> Overall I’m in favor of merging.

I agree.

I’ve been using core-updates on my laptop (both system and user profile)
for about a week now without any problems.

--
Ricardo

Merging core-updates

[Ludovic Courtès]

Hello Guix!

‘core-updates’ seems to be in a rather good shape.  Unfortunately, the
web UI and APIs of hydra.gnu.org and berlin.guixsd.org make it difficult
to have a clear view of the situation.

“make assert-binaries-available” passes for all architectures, meaning
we have Emacs/X11 among other things available as substitutes.

The ‘bootstrap-tarballs’ package is available on all platforms including
aarch64.

On x86_64, LibreOffice, IceCat, etc. are available as substitutes; ‘guix
weather’ reports only 50% of coverage on berlin and 80% on
mirror.hydra.gnu.org (we’ll have to elucidate the bad number on berlin.)
I’m using ‘core-updates’ for both my system and my user profile.

Overall I’m in favor of merging.

What do people think?

Thanks,
Ludo’.