Re: core-updates-frozen branch merged

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> In case you hadn't taken notice, the core-update-frozen branch was
>> finally merged into master.  So please reconfigure your remotes to avoid
>> uploading any further work there :-).
>
> I’m late to the party, but that’s because I’ve been contemplating my
> updated Guixes for a week.  Thumbs up everyone and Maxim in particular
> for getting it past the finish line!

Thank you!  I wasn't alone :-) We have motivated and skilled hackers
going as far as swapping hard drives in their laptop to reproduce hard
to debug problems like in [0], which is amazing!  Thanks to all who are
debugging and fixing things, it helps tremendously (in many ways,
including keeping in good spirits!)

> That makes me wonder: do we even have a list of all the big changes that
> made it into this branch?  Would be nice to come up with a summary.

I have a couple of changes on top of my head; I intend to lay them down
in NEWS as soon as the version-1.4.0 branch I've been refining with more
integrated bits and last minute updates is ready for one last
(hopefully) big rebuild.  For sure I'll have to survey the git log as
I'm sure I've lost track of many great things that went in also.

Thanks,

Maxim

[0]  https://issues.guix.gnu.org/52051

Re: core-updates-frozen branch merged

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).

I’m late to the party, but that’s because I’ve been contemplating my
updated Guixes for a week.  Thumbs up everyone and Maxim in particular
for getting it past the finish line!

That makes me wonder: do we even have a list of all the big changes that
made it into this branch?  Would be nice to come up with a summary.

Ludo’.

Re: [core-updates-frozen] Tryton broken

[Hartmut Goebel]

Am 14.12.21 um 09:15 schrieb zimoun:

Now, core-updates-frozen is merged, they can go to master. :-)


I pushed the fixes to master yesterday. Shall I cherry-pick them to the 
release-1.4 branch or will somebody else take care of that?


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: core-updates-frozen branch merged

[Thiago Jung Bauermann]

Hello!

Em segunda-feira, 13 de dezembro de 2021, às 22:34:34 -03, Maxim Cournoyer 
escreveu:
> Hello Guix!
> 
> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.

Hooray! Thank you very much to everyone who made this happen! I really 
appreciate the effort. The master branch is working great for me.

-- 
Thanks,
Thiago

Re: [core-updates-frozen] Attempt julia@1.6.4 (upgrade)

[Maxim Cournoyer]

Hey Simon!

zimoun  writes:

> Hi Maxim,
>
> On Mon, 13 Dec 2021 at 22:20, Maxim Cournoyer  
> wrote:
>
>> It'll have to be resolved on core-updates :-).
>
> Well, Julia update can happen in master, IMHO.  Even, depending on the
> release date, it appears to me doable for the next release. ;-)

Oh wow!  You sound confident, I like it!  :-).

When you have polished patches ready, we could have them built on the
version-1.4.0 branch.

Cheers,

Maxim

Re: core-updates-frozen branch merged

[Maxim Cournoyer]

Hi!

zimoun  writes:

> Hi Josselin,
>
> On Tue, 14 Dec 2021 at 14:24, Josselin Poiret  wrote:
>
>> What exactly would those "release-specific enhancements" be?
>
> Basically,
>
> - Fix important bugs and/or blocking ones (I do not know if there are
> many today).  And previous release, a "release" bug had been opened to
> collect them.
> - Make sure that all work as expected: test installers etc.
> - String freeze for documentation updates.  Let the time for translators.
> - Update changelog / NEWS
> - Write blog post

Yes, this, and I was also thinking the occasional change that'd cause
too many rebuilds for master, such as fixing up sitecustomize.py [0]
that basically triggers a world rebuild if we want to ship it in the
next release.  We could batch others as well; I know that bumping our
xorg package to the recently released 1.7.3 would be nice to fix the
spurious warnings.  [1]

[0]  https://issues.guix.gnu.org/52269
[1]  https://lists.x.org/archives/xorg-announce/2021-December/003120.html

Thanks all for the great collaboration that went into readying
core-updates-frozen for the merge! :-)

Maxim

Re: core-updates-frozen branch merged

[Katherine Cox-Buday]

Congratulations, everyone!

I love Guix, and I really appreciate all the work that everyone puts into it. 
I'm updating now :)

Sincerely,
-- 
Katherine

Re: core-updates-frozen branch merged

[zimoun]

Hi Josselin,

On Tue, 14 Dec 2021 at 14:24, Josselin Poiret  wrote:

> What exactly would those "release-specific enhancements" be?

Basically,

- Fix important bugs and/or blocking ones (I do not know if there are
many today).  And previous release, a "release" bug had been opened to
collect them.
- Make sure that all work as expected: test installers etc.
- String freeze for documentation updates.  Let the time for translators.
- Update changelog / NEWS
- Write blog post

Cheers,
simon

Re: core-updates-frozen branch merged

[Josselin Poiret]

Maxim Cournoyer  writes:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).

Great work and thanks for coordinating it!  Thanks also to everyone who
contributed :)

> A tentative release preparation branch 'version-1.4.0' was then created
> from master, where release-specific enhancements can go.  Things broken
> on master as it stands should be fixed there, and we can cherry pick
> these fixes into the release branch.

What exactly would those "release-specific enhancements" be?

Best,
Josselin Poiret

Re: [core-updates-frozen] Tryton broken

[zimoun]

Hi Hartmut,

Sorry for the delay.

On Fri, 03 Dec 2021 at 14:41, Hartmut Goebel  
wrote:

> 
>
> They can be added on master, too, since they are not dealing with 
> 'sanitiy-check
>
> Question: After approval, shall I push them to core-updates-frozen and 
> or to master?

Now, core-updates-frozen is merged, they can go to master. :-)

However, because ’format-patch’ had been used without the ’--base’
option, and because the Git tree changed, I cannot apply and test your
patches.

Could you rebase them?  I have not tried them but they LGTM so maybe you
can push them modulo typo in patch 3/3.

Thanks for the fix.

Cheers,
simon

Re: core-updates-frozen branch merged

[Mathieu Othacehe]

Hey,

> That's it!  Enjoy the latest additions and improvements, and report any
> issues you encounter!

That's great news! Thanks to all the people that have been involved and
special thanks to you Maxim for your commitment.

Mathieu

Re: [core-updates-frozen] Attempt julia@1.6.4 (upgrade)

[zimoun]

Hi Maxim,

On Mon, 13 Dec 2021 at 22:20, Maxim Cournoyer  wrote:

> It'll have to be resolved on core-updates :-).

Well, Julia update can happen in master, IMHO.  Even, depending on the
release date, it appears to me doable for the next release. ;-)

Cheers,
simon

Re: core-updates-frozen branch merged

[zimoun]

Hi,

On Mon, 13 Dec 2021 at 20:34, Maxim Cournoyer  wrote:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).
>
> A tentative release preparation branch 'version-1.4.0' was then created
> from master, where release-specific enhancements can go.  Things broken
> on master as it stands should be fixed there, and we can cherry pick
> these fixes into the release branch.

Double yeah! \o/

Thanks for all involved to make it happen.

About the release, what is the draft schedule?

Cheers,
simon

Re: core-updates-frozen branch merged

[Timothy Sample]

Hi Maxim,

Maxim Cournoyer  writes:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).
>
> [...]
>
> That's it!  Enjoy the latest additions and improvements, and report any
> issues you encounter!
>
> Thank you,

Thank you Maxim!  I really appreciate the extra work you put in to get
this finished.  It was not an easy process, but your energy really kept
things moving.  I’ve been a happy c-u-f user for a while now, and the
updates are really terrific!

Here’s hoping the next one will be a little easier.  :)


-- Tim

Re: [core-updates-frozen] Attempt julia@1.6.4 (upgrade)

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi,
>
> First, I am not convinced that upgrade Julia from 1.6.3 to 1.6.4 is
> something to do now; especially when the branch is “frozen”.  Using
> patches #52117 [1], all failures are fixed for 1.6.3.
>
> 1: https://issues.guix.gnu.org/52117
>
>
> Here a rough attempt which replaces the source of 1.6.3 by 1.6.4 and
> many tests are deeply broken (broken precompile is not a good sign, at
> all ;-)).  Well, it seems expected regarding the complexity of the Julia
> stack. :-)
>
> Therefore, the upgrade requires various other upgrades elsewhere and
> probably some fixes with couple of patches.  As it had been for previous
> Julia upgrades. :-)
>
> Then, using this upgraded julia@1.6.4, there is a high probability that
> many julia-* packages would be broken too and thus they would require
> fixes.
>
> IMHO, if we want a working Julia in the delay for the merge, the best
> seems to just apply patch#52117 and let this Julia upgrade for another
> round.  For what my opinion is here. :-)

Seems I had not answered here; thanks for attempting my suggestion!  It
seems you were right that Julia (even for a patch version bump) is
picky.

It'll have to be resolved on core-updates :-).

Thanks,

Maxim

Re: [core-updates-frozen] Haskell for i686-linux: report

[Timothy Sample]

Hi,

zimoun  writes:

> After some Cuirass monitoring and restarted some unexpected failures,
> the situation for ghc-* on i686-linux is the same as the one from
> current master.

I took a few minutes to triage these.  Most of them are fixable.

> Two packages are broken in core-updates-frozen and not in master:
>
>  1. ghc-ncurses
> https://ci.guix.gnu.org/build/1858160/details

Looks like this is due to an ncurses API update:

https://lists.gnu.org/archive/html/bug-ncurses/2020-08/msg00017.html

AFAICS, both scroll and ghc-ncurses are abandoned.  In the case of
scroll, you could say that it’s “finished” I guess, since it’s a game.
I bet it would work fine if we drop the “KEY_EVENT” line in
“lib/UI/NCurses/Enums.chs”.  Otherwise, we could consider dropping these
two packages.

>  2. ghc-lukko
> https://ci.guix.gnu.org/build/1858215/details

Upstream bug: https://github.com/haskellari/lukko/issues/15

The consensus so far is disable OFD locking on 32-bit platforms using
the “-ofd-locking” configure flag.

> These test suite failures require some investigations.  Many other ghc-*
> packages too:
>
>  - ghc-sha

This one is an out of memory error.  Not sure what to do.

>  - ghc-validty

Upstream bug: https://github.com/NorfairKing/validity/issues/84

There’s a patch there to fix the tests for 32-bit machines.

>  - ghc-bloomfilter

Upstream bug: https://github.com/bos/bloomfilter/issues/7

The tests are bounds checking using an overflowed literal: 0x.
Other distros get rid of the check, but the literal could be fixed, too,
as explained in the bug report.

>  - ghc-tar

Upstream bug: https://github.com/haskell/tar/issues/21 (from rekado!)

There’s no patch from upstream.  It looks like a simple word size
mistake in the tests like ghc-validity or ghc-bloomfilter.

>  - ghc-llvm-hs

Not sure about this one.

>  - ghc-lucid

This one I’ve seen before!  Upstream has trouble with nondeterministic
ordering of output HTML attributes.  I guess running the tests on a
32-bit machine exposes some more of these problems.  Patching the tests
to allow different orders would fix it.

[---]

It would be good to fix these, but it would be better to update our
whole Haskell stack.  That’ll have to be something to attempt once c-u-f
is merged.


-- Tim

Re: [core-updates-frozen] Tryton broken

[Hartmut Goebel]

Hi,
I just sent in patches fixing this issue, see 



They can be added on master, too, since they are not dealing with 
'sanitiy-check


Question: After approval, shall I push them to core-updates-frozen and 
or to master?



--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [core-updates-frozen] Tryton broken

[Hartmut Goebel]

Hi,

TL;DR: I'll take care of this within the next few days.

Am 01.12.21 um 17:44 schrieb zimoun:

Many thanks for providing this info and the links.



The issue with 'trythond-*' is the new phase `sanity-check' for
python-build-system.


The way trytond modules are intended (by the maintainers) to be 
installed is *very* special.  Thus I'm not astound to find sanity checks 
for end-points failing - end points are simply not supported by trytond 
for trytond modules as one would expect in Python.



Any chance that someone give a look before the merge?  Otherwise,
these broken packages could land to master; which would be sad.


trytond itself and tryton seem okay. So I suggest to remove the phase 
sanity-check to all failing packages due to this check. Hopefully only a 
few trytond- module are effected - those containing scripts.


I'll take care of this within the next few days.

--
Regards
Hartmut Goebel

| Hartmut Goebel  |h.goe...@crazy-compilers.com|
|www.crazy-compilers.com  | compilers which you thought are impossible |

Re: ‘core-updates-frozen’: julia status update

[zimoun]

Hi,

On Thu, 25 Nov 2021 at 03:13, zimoun  wrote:

> I am currently rebuilding all the julia-* packages.  It is high probable
> some are now broken.  But it appears to me not a blocker for the
> merge.

All is fixed in patch#52117 [1].  After this hacking session,

 1. The package julia uses parallelism to build, i.e., it requires much
much less time to build; something like 5x speedup on Berlin.

 2. The julia-build-system runs the tests with some degree of
parallelism.  The speedup depends on each ’test/runtests.jl’ script
provided by the package julia-* itself.

The strong issues to tackle are:

 a) bug#22304: build julia package with reproducible
 b) bug#47354: build julia-* packages reproducible


1: 
2: 
3: 


Cheers,
simon

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Ricardo Wurmus]

Ludovic Courtès  writes:


Hi,

Ricardo Wurmus  skribis:


on the core-updates-frozen branch we have a minor problem:
python-numpy has been upgraded to 1.21, but python-numba can 
only 
be built with 1.20[1].  I added python-numpy-1.20 and made

python-numba use it.


How big of an effort would it be to modify numba so that it 
works with

1.21?  With luck, that effort has already been made upstream?


I spoke too soon: 
https://github.com/numba/numba/issues/7175#issuecomment-975470113


 “Numba 0.55 release candidates will be out within the next week 
 or so (hopefully!), these will have NumPy 1.21.x series 
 support.”


So soon after the merge we will be able to switch back to numpy 
1.21 as the default.


--
Ricardo

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Ricardo Wurmus]

Hi,

Ludovic Courtès  writes:


Ricardo Wurmus  skribis:


on the core-updates-frozen branch we have a minor problem:
python-numpy has been upgraded to 1.21, but python-numba can 
only 
be built with 1.20[1].  I added python-numpy-1.20 and made

python-numba use it.


How big of an effort would it be to modify numba so that it 
works with

1.21?  With luck, that effort has already been made upstream?


It hasn’t.  Upstream doesn’t seem to know exactly how to 
accomplish this.  There’s a breaking change in numpy (something 
relating to typing of ufuncs) and it leads to incorrect type 
errors in numba AFAIU.  This is not something I’d feel comfortable 
just hacking around.


--
Ricardo

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> on the core-updates-frozen branch we have a minor problem:
> python-numpy has been upgraded to 1.21, but python-numba can only 
> be built with 1.20[1].  I added python-numpy-1.20 and made
> python-numba use it.

How big of an effort would it be to modify numba so that it works with
1.21?  With luck, that effort has already been made upstream?

Ludo’.

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[zimoun]

Hi Ricardo,

On Sat, 20 Nov 2021 at 10:42, Ricardo Wurmus  wrote:

> on the core-updates-frozen branch we have a minor problem: 
> python-numpy has been upgraded to 1.21, but python-numba can only 
> be built with 1.20[1].  I added python-numpy-1.20 and made 
> python-numba use it.

I think the upgrade of Numpy had been a mistake.  All the Python
scientific stack has to be upgraded in one go.  From my understanding,
it is the same issue as Haskell and LTS, for instance.  As Lars said,
try to have several versions would probably lead to a mess with weird
behaviours difficult to debug; from my understanding.

The best is to downgrades python-numpy to 1.20 (potentially 1.20.3
released on May 2021, that’s not that old :-)) and wait python-numba
works with Numpy 1.21.  IMHO.


Cheers,
simon

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Ricardo Wurmus]

Lars-Dominik Braun  writes:


Hello Ricardo,

So… since numpy 1.20 is the exception here, could we perhaps … 
rename it?  And then have python-numba import that renamed 
module 
“totally-not-numpy” instead of “numpy”?  Could we thus avoid 
this 
conflict?  If renaming is an option — how would it be done?  Is 
it 
enough to rename the “numpy” directory with “numpy-1.20”, the 
“numpy.py” file with “numpy-1.20.py”, and then update all 
“import” 
statements both by numpy itself and by python-numba?
I feel this is a dangerous idea. Python is dynamically typed and 
if we
– somehow – end up with objects from both, numpy 1.20 and numpy 
1.21
in the same program, which can still happen when renaming, 
things may
go wrong very badly. [1] says versions 1.* are ABI compatible, 
but the
API changes between releases, which is probably why numba cannot 
be used

with a newer numpy.

Can we rewrite the entire graph to use numpy 1.20 whenever a 
package

imports numba?


After a quick discussion on IRC we decided to make 1.20 the 
default and keep 1.21 as python-numpy-next.  Let’s hope we can 
switch to 1.21 for good soon.


--
Ricardo

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Lars-Dominik Braun]

Hello Ricardo,

> So… since numpy 1.20 is the exception here, could we perhaps … 
> rename it?  And then have python-numba import that renamed module 
> “totally-not-numpy” instead of “numpy”?  Could we thus avoid this 
> conflict?  If renaming is an option — how would it be done?  Is it 
> enough to rename the “numpy” directory with “numpy-1.20”, the 
> “numpy.py” file with “numpy-1.20.py”, and then update all “import” 
> statements both by numpy itself and by python-numba?
I feel this is a dangerous idea. Python is dynamically typed and if we
– somehow – end up with objects from both, numpy 1.20 and numpy 1.21
in the same program, which can still happen when renaming, things may
go wrong very badly. [1] says versions 1.* are ABI compatible, but the
API changes between releases, which is probably why numba cannot be used
with a newer numpy.

Can we rewrite the entire graph to use numpy 1.20 whenever a package
imports numba?

Cheers,
Lars

[1] https://numpy.org/devdocs/user/depending_on_numpy.html

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey Ricardo,

> It should be fine now.  I didn’t run the test myself, but I ran most of the
> commands and found a few more hardcoded tool file names that referenced /sbin
> or /usr/bin. 

Yes, I confirm it passes! I also fixed the childhurd test. Only 9 tests
to go :).

Thanks,

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[Ricardo Wurmus]

Hi Mathieu,

I fixed the build.  Also had to upgrade 389-ds-base to get 
around a linker

error.


Thanks for your support here! The ldap test is now run, but 
sadly there

are some failures: https://ci.guix.gnu.org/build/928047/log/raw.


Thanks for checking!

It should be fine now.  I didn’t run the test myself, but I ran 
most of the commands and found a few more hardcoded tool file 
names that referenced /sbin or /usr/bin. 


--
Ricardo

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hello Ricardo,

> I fixed the build.  Also had to upgrade 389-ds-base to get around a linker
> error.

Thanks for your support here! The ldap test is now run, but sadly there
are some failures: https://ci.guix.gnu.org/build/928047/log/raw.

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey,

> For example, this evaluation from Sep 17 has thousands of scheduled 
> evaluations:
>
> https://ci.guix.gnu.org/eval/19271?status=pending

Mmmh, not nice. Any chance you could share the cuirass-remote-worker
logs on the guixp9 machine?

Thanks,

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[Ricardo Wurmus]

Mathieu Othacehe  writes:


* ldap (https://ci.guix.gnu.org/build/901179/details)
 => 389-ds-base build appears to be broken.


I fixed the build.  Also had to upgrade 389-ds-base to get around 
a linker error.


--
Ricardo

Re: core-updates-frozen: Planning for the last world rebuild

[Thiago Jung Bauermann]

Hello Mathieu,

Em quinta-feira, 30 de setembro de 2021, às 06:03:52 -03, Mathieu Othacehe 
escreveu:
> Hey Thiago,
> 
> > I was waiting for this world rebuild to happen to see the results in
> > Cuirass now that powerpc64le-linux builds are only done on guixp9, but
> > in hindsight it would have been better if I requested that those
> > builds were restarted instead. Restarting this build should remove the
> > main roadblock though:
> > 
> > https://ci.guix.gnu.org/build/703194/details
> 
> Now restarted!

Thank you! Unfortunately that build is now affected by an issue that I only 
noticed yesterday: powerpc64le-linux builds for core-updates-frozen get 
permanently stuck in the ‘Scheduled’ state, even though guixp9 is 
completely idle (as it is right now).

For example, this evaluation from Sep 17 has thousands of scheduled 
evaluations:

https://ci.guix.gnu.org/eval/19271?status=pending

This is also happening with at least one other platform as well. This 
evaluation from Sep 25 has a lot of scheduled evaluations for i586-gnu (as 
well as powerpc64le-linux):

https://ci.guix.gnu.org/eval/23187?status=pending

> > When that build is restarted and succeeds, does Cuirass also restart
> > the
> > builds that failed because they depended on it, or do we need to
> > explicitly restart those as well?
> 
> Yes, on successful build completion Cuirass looks if some builds that
> were marked as "failed-dependency" (failing because some of the
> dependencies are also failing) can be resumed.

That is awesome!

> That being said, Cuirass is not performing nicely these days because of:
> this issue https://issues.guix.gnu.org/48468.

Ah, ok. Thank you for the heads up.

-- 
Thanks,
Thiago

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey Thiago,

> I was waiting for this world rebuild to happen to see the results in 
> Cuirass now that powerpc64le-linux builds are only done on guixp9, but in 
> hindsight it would have been better if I requested that those builds were 
> restarted instead. Restarting this build should remove the main roadblock 
> though:
>
> https://ci.guix.gnu.org/build/703194/details

Now restarted!

>
> When that build is restarted and succeeds, does Cuirass also restart the 
> builds that failed because they depended on it, or do we need to explicitly 
> restart those as well?

Yes, on successful build completion Cuirass looks if some builds that
were marked as "failed-dependency" (failing because some of the
dependencies are also failing) can be resumed.

That being said, Cuirass is not performing nicely these days because of:
this issue https://issues.guix.gnu.org/48468.

Thanks,

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[Efraim Flashner]

On Tue, Sep 28, 2021 at 01:57:45PM +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> Wouldn’t it be nice to get ‘core-updates-frozen’ merged?  :-)
> 
> What about merging the patches blocked by
> ?  We could even have them on a
> separate branch, have Cuirass build it, and merge it 24–36h later, at
> which point substitute coverage should be reasonably good.
> 
> I haven’t followed the new ports, POWER9 and RISC-V.  If there’s
> anything needed in this area, like localized toolchain changes, please
> send a heads-up!
> 
> As I say every time someone proposes a new port, the main issue is not
> the port itself but maintaining it longer-term.  And here it’s not even
> clear to me what the status of POWER9 is on ‘core-updates-frozen’, so
> it’d be great to get feedback on this, ensure Cuirass builds it, and so
> on.

I'm still building away on riscv64-linux. I have some minor changes,
namely renaming target-riscv? to target-riscv64? As far as cuirass
support I have it officially unsupported in %hydra-supported-systems (or
whatever that variable is called). I've tried to keep the patches so
that they can be applied without interfering with the other
architectures. At this point as far as I know it's waiting for another
pair of eyes or so to say it looks OK to merge.

-- 
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: core-updates-frozen: Planning for the last world rebuild

[Thiago Jung Bauermann]

Hello Ludo,

Em terça-feira, 28 de setembro de 2021, às 08:57:45 -03, Ludovic Courtès 
escreveu:
> Hello Guix!
> 
> Wouldn’t it be nice to get ‘core-updates-frozen’ merged?  :-)
> 
> What about merging the patches blocked by
> ?  We could even have them on a
> separate branch, have Cuirass build it, and merge it 24–36h later, at
> which point substitute coverage should be reasonably good.
> 
> I haven’t followed the new ports, POWER9 and RISC-V.  If there’s
> anything needed in this area, like localized toolchain changes, please
> send a heads-up!

There are two things I’m aware of for POWER9:

• diffutils test fix: https://issues.guix.gnu.org/50239
• gcc-5 build with GCC 10 fix: https://issues.guix.gnu.org/49896

In the case of diffutils, IMHO ideally we would apply the v2 patch there for 
the world rebuild, but as Ludo suggested it’s also possible to make the 
change only for powerpc64le-linux and avoid affecting other platforms.

In the case of gcc-5, it’s the same situation actually. But in addition to 
that, `guix refresh --list-dependent` says that modifying gcc-5 would only 
cause 32 dependent packages to be rebuilt so it’s not necessary to address 
it for the world rebuild.

> As I say every time someone proposes a new port, the main issue is not
> the port itself but maintaining it longer-term.  And here it’s not even
> clear to me what the status of POWER9 is on ‘core-updates-frozen’, so
> it’d be great to get feedback on this, ensure Cuirass builds it, and so
> on.

Yeah, the status of POWER9 on ‘core-updates-frozen’ is obfuscated by some 
build failures early in the dependency chain that were caused by QEMU bugs.
My impression is that the same is also true for aarch64-linux. For 
instance, QEMU can’t run libsigsegv’s testsuite (among other things), and 
that blocks a ton of stuff. Ditto for util-linux’s testsuite.

I was waiting for this world rebuild to happen to see the results in 
Cuirass now that powerpc64le-linux builds are only done on guixp9, but in 
hindsight it would have been better if I requested that those builds were 
restarted instead. Restarting this build should remove the main roadblock 
though:

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

When that build is restarted and succeeds, does Cuirass also restart the 
builds that failed because they depended on it, or do we need to explicitly 
restart those as well?

What I can say is that IMHO POWER9 support isn’t too bad at least for the 
base packages given that I can build e.g., emacs (assuming that the patch 
for issue 50521 fixing a problem in gtk+-2 is applied), which depends on 
many base packages including X11 and GTK+.

-- 
Thanks,
Thiago

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey!

> have more system tests passing. Currently 16 out of 87 are
> broken. Except for the nfs-root-fs that has always been broken, the
> other tests probably cover user configurations out there.

Made some progress here but there are still a bit more work needed:

* childhurd (https://ci.guix.gnu.org/build/901219/details)
 => gnumach build appears to be broken.

* dovecot (https://ci.guix.gnu.org/build/901189/details)
 => dovecot build appears to be broken.

* patchwork (https://ci.guix.gnu.org/build/901227/details)
 => python-django-pipeline build (dependency of patchwork) appears to be
  broken.

* ganeti-kvm (https://ci.guix.gnu.org/build/901158/details)
 => ganeti build appears to be broken.

* ganeti-lxc (https://ci.guix.gnu.org/build/901157/details)
 => same reason.

* getmail (https://ci.guix.gnu.org/build/901187/details)
 => dovecot build appears to be broken.

* gui-installed-desktop-os-encrypted
  (https://ci.guix.gnu.org/build/923078/details)
 => emacs-exwm build is broken presumably because of
  https://issues.guix.gnu.org/50066.

* jami-provisioning (https://ci.guix.gnu.org/build/901214/details) and
 jami (https://ci.guix.gnu.org/build/901213/details)
 => sobjectizer build appears to be broken.

* ldap (https://ci.guix.gnu.org/build/901179/details)
 => 389-ds-base build appears to be broken.

The overall status can be seen here:
https://ci.guix.gnu.org/eval/24933/dashboard. Let's get those tests fixed
so that we can start this branch on good grounds!

Thanks,

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[John Kehayias]

Hi Ludo’ and Guixers,

Thanks for the good progress on core-updates-frozen (where I'm currently 
writing from and have nearly everything working as before). Seems like we have 
a few different bug numbers and threads for the world rebuild. Sorry for 
repeating from #50860, which I will paste below.

In summary, I also noticed an older bug for Flatpak with p11-kit, as well as 
p11-kit being out of date. Locally I've tested it builds with the patch and 
version update and fixes the bug. The configuration change is the same as nix 
does for p11-kit for the same reason, for what that is worth.

Less critical is Mesa continuing to put out updates, both on 21.1 and now 
moving to 21.2 (considered stable I believe). I thought we might sneak that in 
if we're doing lots of rebuilding.

Thanks! Original message with more details below:

Is there anything else with huge rebuilds to push together? I don't want to 
keep finding and adding things, but two possibilities come to mind that I've 
just noticed:

1a. p11-kit #49957 https://issues.guix.gnu.org/49957

I've just hit this bug on core-updates-frozen as well, though was originally 
reported on master. As I noted there, I tried to test with just grafts but 
didn't fix it for me (I'm guessing grafting won't work with that configure flag 
change). The patch matches how nix configures p11-kit as well, due to this bug.

1b. p11-kit is also now out of date. The changelog doesn't look substantial or 
serious, but given the nature of p11-kit I wonder if we want to update it now 
too. https://github.com/p11-glue/p11-kit/releases/tag/0.24.0

2. (minor) Mesa has had a few more bugfix and major releases since my initial 
patch for core-updates-frozen. Now at 21.1.8 for the 21.1 branch (we have 
21.1.6 currently), but 21.2 has also had stable releases, with 21.2.2. I 
previously built 21.2.1 and sent a patch for it, and could test 21.2.2 if we 
want to do that too.

I'm aware this could continue forever, and #2 is likely lower priority. #1, 
though, should we consider p11-kit a critical update (version, at least) since 
we're still fixing core-updates-frozen?

John

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey!

> Wouldn’t it be nice to get ‘core-updates-frozen’ merged?  :-)

That would be great :) Before merging to master, it would be nice to
have more system tests passing. Currently 16 out of 87 are
broken. Except for the nfs-root-fs that has always been broken, the
other tests probably cover user configurations out there.

I'm currently working on the installation tests.

Thanks,

Mathieu

Re: [core-updates-frozen] Blockers for working system

[Liliana Marie Prikler]

Hi Jonathan,

Am Samstag, den 11.09.2021, 00:16 +0200 schrieb Jonathan Brielmaier:
> /gnu/store/2p3lw0dy8b3b34xfn2xlwg9ngrw493v7-gnome-maps-3.38.5.drv
>Fails in testsuite with:
> JS ERROR: Error: Expected 1,001 m (string) but was 1001 m (string)
> I have no clue why, maybe something is "wrangled" with LC_ALL or LANG
> variables. Or it has to do with our mozjs-78 (used by gjs), where I
> assume comes the `toLocaleString` function from...
There is a phase called "fix-broken-tests" in gnome-maps which patches
exactly those strings to add a comma.  gnome-maps expects the new
behaviour (exactly the one you're observing), but building against an
old mozjs probably borked those tests at the time.  The obvious fix is
to drop that phase as it's no longer needed.

Happy hacking!

Re: [core-updates-frozen] Blockers for working system

[Guillaume Le Vaillant]

Jonathan Brielmaier  skribis:

> Hi Guix folks,
>
> here are the blockers which prevent me from using core-updates-frozen on
> my personal machine. So those 14 derivations failed for me this morning:
>
> [...]
>
> /gnu/store/7mz3ci5gydg606wmh2y6yl7q53mp5x68-materialdecoration-1.1.0-9.6a5de23.drv
>   Unbound variable: %build-inputs -> needs to be replaced by the gexp
> way of naming it...

Hi,

I fixed materialdecoration-1.1.0 in 856591e2b50cb5f186f01b252be239ae7553eeef.


signature.asc
Description: PGP signature

Re: [core-updates-frozen] Bug in binutils 2.37

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> Leo Famulari  skribis:
>
>> On Mon, Sep 06, 2021 at 03:39:52PM +, Guillaume Le Vaillant wrote:
>>> There's a bug in binutils 1.37, which we are using on the
>>> core-updates-frozen branch.
>>
>> 2.37, right? :)
>>
>
> Indeed. :)
>
>
>>> It's a file descriptor leak that can lead to 'malformed archive' errors
>>> when linking libraries. We get this problem at least when building
>>> qtwekbit and qtwebengine. A workaround allows us to compile qtwebkit
>>> (see [1]), but it doesn't work for qtwebengine.
>>> 
>>> The bug was discussed at [2] and upstream has a patch to fix it at [3].
>>> However, adding this patch to our binutils rebuilds the world.
>>> I'm currently trying to build things with the patched binutils.
>>> If everything works, should I push this fix on core-updates-frozen, or
>>> does someone have an idea that would lead to less rebuilds?
>>
>> There are a few options:
>>
>> 1) Apply the patch in the normal way and rebuild the world. If the
>> changes in the patch are limited to fixing this bug, then we can be
>> confident that changing binutils will not break other packages, which is
>> the main goal behind "freezing" the core-updates branch. Do you think
>> that expectation is reasonable? Otherwise, the branch is frozen except
>> for bug fixes; we'd like to avoid rebuilding the world but it's not a
>> problem if we have to.
>> 2) Create a binutils-fixed package and only use it for qtwebkit and
>> qtwebengine
>> 3) Try to work around the bug in the qtwebkit and qtwebengine packages
>>
>> 2 and 3 are not great because maybe the bug affects other packages in
>> some situations. Do you know if it manifests deterministically?
>
> The problem happens when linking a library with a lot of members (I
> don't know exactly how many), which is the case at least for qtwebkit
> and qtwebengine. Users creating such libraries in their projects will
> also have the problem.
>
> Increasing the maximum number of open file descriptors seems not be
> a very robust workaround. Setting it at 4096 for qtwebkit works,
> but I tried 4096, 8192 and 16384 for qtwebengine and it didn't work.
>
> I have built many packages with the patched binutils and I didn't get
> any new failure so far. I'm not yet at qtwebkit and qtwebengine though
> (compiling the 20 versions of rust took a while).
> So when I get there, and if the patch really solves the issue, pushing
> it looks like the best solution.
>
> Do you know if there are other world-rebuilding pending fixes that could
> go in at the same time?

I confirm that the patch fixed the compilation issues for qtwebkit and
qtwebengine, and it didn't cause new build failures, so I pushed it as
de8e2a699c0219f5ea86f6bbfff4d5ee35104738.


signature.asc
Description: PGP signature

Re: [core-updates-frozen] Bug in binutils 2.37

[Guillaume Le Vaillant]

Leo Famulari  skribis:

> On Mon, Sep 06, 2021 at 03:39:52PM +, Guillaume Le Vaillant wrote:
>> There's a bug in binutils 1.37, which we are using on the
>> core-updates-frozen branch.
>
> 2.37, right? :)
>

Indeed. :)


>> It's a file descriptor leak that can lead to 'malformed archive' errors
>> when linking libraries. We get this problem at least when building
>> qtwekbit and qtwebengine. A workaround allows us to compile qtwebkit
>> (see [1]), but it doesn't work for qtwebengine.
>> 
>> The bug was discussed at [2] and upstream has a patch to fix it at [3].
>> However, adding this patch to our binutils rebuilds the world.
>> I'm currently trying to build things with the patched binutils.
>> If everything works, should I push this fix on core-updates-frozen, or
>> does someone have an idea that would lead to less rebuilds?
>
> There are a few options:
>
> 1) Apply the patch in the normal way and rebuild the world. If the
> changes in the patch are limited to fixing this bug, then we can be
> confident that changing binutils will not break other packages, which is
> the main goal behind "freezing" the core-updates branch. Do you think
> that expectation is reasonable? Otherwise, the branch is frozen except
> for bug fixes; we'd like to avoid rebuilding the world but it's not a
> problem if we have to.
> 2) Create a binutils-fixed package and only use it for qtwebkit and
> qtwebengine
> 3) Try to work around the bug in the qtwebkit and qtwebengine packages
>
> 2 and 3 are not great because maybe the bug affects other packages in
> some situations. Do you know if it manifests deterministically?

The problem happens when linking a library with a lot of members (I
don't know exactly how many), which is the case at least for qtwebkit
and qtwebengine. Users creating such libraries in their projects will
also have the problem.

Increasing the maximum number of open file descriptors seems not be
a very robust workaround. Setting it at 4096 for qtwebkit works,
but I tried 4096, 8192 and 16384 for qtwebengine and it didn't work.

I have built many packages with the patched binutils and I didn't get
any new failure so far. I'm not yet at qtwebkit and qtwebengine though
(compiling the 20 versions of rust took a while).
So when I get there, and if the patch really solves the issue, pushing
it looks like the best solution.

Do you know if there are other world-rebuilding pending fixes that could
go in at the same time?


signature.asc
Description: PGP signature

Re: [core-updates-frozen] Bug in binutils 1.37

[Leo Famulari]

On Mon, Sep 06, 2021 at 03:39:52PM +, Guillaume Le Vaillant wrote:
> There's a bug in binutils 1.37, which we are using on the
> core-updates-frozen branch.

2.37, right? :)

> It's a file descriptor leak that can lead to 'malformed archive' errors
> when linking libraries. We get this problem at least when building
> qtwekbit and qtwebengine. A workaround allows us to compile qtwebkit
> (see [1]), but it doesn't work for qtwebengine.
> 
> The bug was discussed at [2] and upstream has a patch to fix it at [3].
> However, adding this patch to our binutils rebuilds the world.
> I'm currently trying to build things with the patched binutils.
> If everything works, should I push this fix on core-updates-frozen, or
> does someone have an idea that would lead to less rebuilds?

There are a few options:

1) Apply the patch in the normal way and rebuild the world. If the
changes in the patch are limited to fixing this bug, then we can be
confident that changing binutils will not break other packages, which is
the main goal behind "freezing" the core-updates branch. Do you think
that expectation is reasonable? Otherwise, the branch is frozen except
for bug fixes; we'd like to avoid rebuilding the world but it's not a
problem if we have to.
2) Create a binutils-fixed package and only use it for qtwebkit and
qtwebengine
3) Try to work around the bug in the qtwebkit and qtwebengine packages

2 and 3 are not great because maybe the bug affects other packages in
some situations. Do you know if it manifests deterministically?

Re: [core-updates-frozen] python2-google-api-client and sanity-check

[zimoun]

Hi Lars,

On Tue, 31 Aug 2021 at 18:41, Lars-Dominik Braun  wrote:

> pushed as bac072e09bb80c172672e13782e1ed25ce04d6d5. Please don’t
> hesitate to ping me if there’s any other issuse with the sanity check
> phase.

Thanks.  I will do. :-)  I am going to check if all the 'python2-'
packages on core-updates-frozen build or not.

Cheers,
simon

Re: [core-updates-frozen] python2-google-api-client and sanity-check

[Lars-Dominik Braun]

Hi,

> From my point of view, yes you can push because it is a fix.
pushed as bac072e09bb80c172672e13782e1ed25ce04d6d5. Please don’t
hesitate to ping me if there’s any other issuse with the sanity check
phase.

Cheers,
Lars

Re: [core-updates-frozen] python2-google-api-client and sanity-check

[zimoun]

Hi,

On Tue, 31 Aug 2021 at 14:39, Lars-Dominik Braun
 wrote:

> See attached patch for a fix.

LGTM.


> Can I simply push that to core-updates-frozen or is there anything else I 
> should do?

>From my point of view, yes you can push because it is a fix.

Cheers,
simon

Re: [core-updates-frozen] python2-google-api-client and sanity-check

[Lars-Dominik Braun]

Hi zimoun,

> Because this ’sanity-check’ is new, IIUC, my question is: is it
> expected?  And is it worth to fix such Python 2 packages or simply
> remove them because ’sanity-check.py’ uses Python 3 only features?
setup.py of this package is broken, because the package list contains a slash.
See attached patch for a fix.

Can I simply push that to core-updates-frozen or is there anything else I 
should do?

Lars

-- 
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate

www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz Institute for Psychology
Universitätsring 15
D-54296 Trier - Germany
Tel.: +49–651–201-4964
diff --git a/gnu/packages/python-web.scm b/gnu/packages/python-web.scm
index 91b68cf5f4..4763abce8b 100644
--- a/gnu/packages/python-web.scm
+++ b/gnu/packages/python-web.scm
@@ -4338,7 +4338,15 @@ Google search engine.  Its module is called 
@code{googlesearch}.")
  "1wpbbbxfpy9mwxdy3kn352cb590ladv574j1aa2l4grjdqw3ln05"
 (build-system python-build-system)
 (arguments
- '(#:tests? #f)) ; tests require internet access
+ `(#:tests? #f ; tests require internet access
+   #:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'fix-setup-py
+   (lambda _
+ (substitute* "setup.py"
+   (("googleapiclient/discovery_cache")
+"googleapiclient.discovery_cache"))
+ #t)
 (native-inputs
  `(("python-httplib2" ,python-httplib2)
("python-six" ,python-six)


signature.asc
Description: PGP signature

Re: Core updates frozen.

[Leo Famulari]

On Fri, Aug 20, 2021 at 11:49:01AM +0200, zimoun wrote:
> Is it possible to “guix weather” a specific branch?  If it makes
> sense. :-)

I'm preparing some weather reports now. Basically, I use this command:

$ while read branch; do while read system; do guix weather 
--substitute-urls=https://ci.guix.gnu.org -c 10 -s ${system}-linux 2>&1 | tee 
~/tmp/reports/${branch}-${system}-linux; done < systems; done < branches

... along with two files, 'branches' and 'systems' which contain this,
respectively:

core-updates-frozen

armhf
aarch64
i686
x86_64

Re: Core updates frozen.

[Efraim Flashner]

On August 20, 2021 9:49:01 AM UTC, zimoun  wrote:
>Hi,
>
>On Wed, 18 Aug 2021 at 13:33, Efraim Flashner  wrote:
>
>> I assumed we're in the 'find your packages and fix them' phase. Some I
>> have on my TODO list are sddm, glibc-2.31 and ruby-asciidoctor.
>
>Cool!
>
>Is it possible to “guix weather” a specific branch?  If it makes
>sense. :-)
>
>Cheers,
>simon

From my git worktree of core-updates-frozen I'll run ./pre-inst-env guix 
weather with some flags and that works for me.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Core updates frozen.

[zimoun]

Hi,

On Wed, 18 Aug 2021 at 13:33, Efraim Flashner  wrote:

> I assumed we're in the 'find your packages and fix them' phase. Some I
> have on my TODO list are sddm, glibc-2.31 and ruby-asciidoctor.

Cool!

Is it possible to “guix weather” a specific branch?  If it makes
sense. :-)

Cheers,
simon

Re: Core updates frozen.

[Efraim Flashner]

On Tue, Aug 17, 2021 at 02:40:26PM +0200, zimoun wrote:
> Hi,
> 
> On Wed, 28 Jul 2021 at 13:50, Mathieu Othacehe  wrote:
> 
> > A new core-updates-frozen branch is available here:
> > https://git.savannah.gnu.org/cgit/guix.git/log/?h=core-updates-frozen.
> 
> Cool!
> 
> > Your help is welcome :).
> 
> What is the schedule for the merge?
> 
> (I am back from holidays. :-))
> 
> Cheers,
> simon
> 

I assumed we're in the 'find your packages and fix them' phase. Some I
have on my TODO list are sddm, glibc-2.31 and ruby-asciidoctor.

-- 
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: Core updates frozen.

[zimoun]

Hi,

On Wed, 28 Jul 2021 at 13:50, Mathieu Othacehe  wrote:

> A new core-updates-frozen branch is available here:
> https://git.savannah.gnu.org/cgit/guix.git/log/?h=core-updates-frozen.

Cool!

> Your help is welcome :).

What is the schedule for the merge?

(I am back from holidays. :-))

Cheers,
simon

Re: core-updates-frozen on powerpc64le-linux

[Thiago Jung Bauermann]

Hello!

Em quarta-feira, 11 de agosto de 2021, às 07:18:27 -03, Ludovic Courtès 
escreveu:
> Thiago Jung Bauermann  skribis:
> > Em quarta-feira, 4 de agosto de 2021, às 17:48:59 -03, Ludovic Courtès
> > escreveu:
> >> Thiago Jung Bauermann  skribis:
> >> Note that currently ci.guix only does emulated powerpc64le-linux
> >> because
> >> the only POWER9 machine we currently have access to (lent by OSUOSL)
> >> is
> >> not running ‘cuirass-remote-worker’.



> >> It’s a foreign distro (Debian) so
> >> setting up these things can be a bit tedious.  If you or anyone would
> >> like to help with this, we can discuss it!
> > 
> > I’d be glad to help set that up and maintain the OSUOSL machine!
> 
> Excellent!  I think Mathieu, Tobias, and guix-sysad...@gnu.org should be
> able to get you started.  Could you send us an account name and SSH
> public key?

Thanks! I sent it in private.

> >> (bordeaux.guix does have a POWER9 build machine behind, but it’s not
> >> building ‘core-updates-frozen’ currently.)
> > 
> > Nice! I’d be glad to help with that machine as well if there’s anything
> > to do on that front.
> 
> I think it’s running fine, using the Guix Build Coordinator instead of
> Cuirass, set up by Christopher Baines (this POWER9 machine is Chris’s,
> currently).

That’s great. Thanks Chris!

> >> > So next step for me is to look into the build failures above. I’ll
> >> > semi-randomly start with ‘gmp-boot’ and see what I can find out.
> >> 
> >> Neat, thank you!
> > 
> > You’re welcome. Patches on issues 49880, 49881 and 49882. :-)
> 
> Alrighty, I’ll take a look!

Thank you!

-- 
Thanks,
Thiago

Re: core-updates-frozen on powerpc64le-linux

[Ludovic Courtès]

Hi!

Thiago Jung Bauermann  skribis:

> Em quarta-feira, 4 de agosto de 2021, às 17:48:59 -03, Ludovic Courtès 
> escreveu:
>> Thiago Jung Bauermann  skribis:

[...]

>> Note that currently ci.guix only does emulated powerpc64le-linux because
>> the only POWER9 machine we currently have access to (lent by OSUOSL) is
>> not running ‘cuirass-remote-worker’.
>
> Ah, I didn’t realise that. I started out my investigations of powerpc64le-
> linux CI failures using emulation on my laptop (both with qemu-user and 
> qemu-system), and found it to be a bit unreliable. I saw some failures in 
> packages’ testsuite results which don’t happen on real hardware. There was 
> one in the glib package in particular which happened on the master branch 
> and prevented a `guix pull` command from succeeding. This is what prompted 
> me to request the Minicloud VM instance.
>
>> It’s a foreign distro (Debian) so
>> setting up these things can be a bit tedious.  If you or anyone would
>> like to help with this, we can discuss it!
>
> I’d be glad to help set that up and maintain the OSUOSL machine!

Excellent!  I think Mathieu, Tobias, and guix-sysad...@gnu.org should be
able to get you started.  Could you send us an account name and SSH
public key?

>> (bordeaux.guix does have a POWER9 build machine behind, but it’s not
>> building ‘core-updates-frozen’ currently.)
>
> Nice! I’d be glad to help with that machine as well if there’s anything to 
> do on that front.

I think it’s running fine, using the Guix Build Coordinator instead of
Cuirass, set up by Christopher Baines (this POWER9 machine is Chris’s,
currently).

>> > So next step for me is to look into the build failures above. I’ll
>> > semi-randomly start with ‘gmp-boot’ and see what I can find out.
>> 
>> Neat, thank you!
>
> You’re welcome. Patches on issues 49880, 49881 and 49882. :-)

Alrighty, I’ll take a look!

Thanks,
Ludo’.

Re: core-updates-frozen on powerpc64le-linux

[Thiago Jung Bauermann]

Hi Ludo’!

Em quarta-feira, 4 de agosto de 2021, às 17:48:59 -03, Ludovic Courtès 
escreveu:
> Thiago Jung Bauermann  skribis:
> > Em quarta-feira, 28 de julho de 2021, às 08:50:16 -03, Mathieu Othacehe
> 
> > escreveu:
> [...]
> 
> >> Cuirass has started evaluating this branch here:
> >> https://ci.guix.gnu.org/jobset/core-updates-frozen. According to the
> >> related dashboard, there's still a bit of work required to stabilize
> >> this branch: https://ci.guix.gnu.org/eval/68124/dashboard.
> > 
> > There are no results for powerpc64le-linux. Does anyone know why?
> 
> It was turned off in the config at
> .  I’ve
> added it now (though maybe it won’t actually build until someone has
> pushed.)

Thanks for the explanation. And thanks for re-adding it!

> Note that currently ci.guix only does emulated powerpc64le-linux because
> the only POWER9 machine we currently have access to (lent by OSUOSL) is
> not running ‘cuirass-remote-worker’.

Ah, I didn’t realise that. I started out my investigations of powerpc64le-
linux CI failures using emulation on my laptop (both with qemu-user and 
qemu-system), and found it to be a bit unreliable. I saw some failures in 
packages’ testsuite results which don’t happen on real hardware. There was 
one in the glib package in particular which happened on the master branch 
and prevented a `guix pull` command from succeeding. This is what prompted 
me to request the Minicloud VM instance.

> It’s a foreign distro (Debian) so
> setting up these things can be a bit tedious.  If you or anyone would
> like to help with this, we can discuss it!

I’d be glad to help set that up and maintain the OSUOSL machine!

> (bordeaux.guix does have a POWER9 build machine behind, but it’s not
> building ‘core-updates-frozen’ currently.)

Nice! I’d be glad to help with that machine as well if there’s anything to 
do on that front.

> > The last Cuirass evaluation of core-updates with powerpc64le-linux
> > results is https://ci.guix.gnu.org/eval/67285 so I tried to run the
> > failed builds on my VM to see what the current state is. My
> > core-updates-frozen branch was at commit f8458a228224
> > (”build-system/python: Handle missing metadata on Python 2.”) when I
> > did these builds.
> > 
> > At first, I didn’t try the “*tarball*” builds because I didn’t want to
> > focus on the bootstrap binaries. Apart from those, I was glad to see
> > that all failed powerpc64le-linux builds from that evaluation built
> > fine on my VM, except for the ones below:
> > 
> > • gcc-toolchain@4.8
> > • gcc-toolchain@5.5
> > • gmp@4.3.2 aka `(@@ (gnu packages commencement) gmp-boot)`
> > • mpfr@2.4.2 aka `(@@ (gnu packages commencement) mpfr-boot)`
> > • mpc@1.0.3 aka `(@@ (gnu packages commencement) mpc-boot)`
> > 
> > I later tried building ‘bootstrap-tarballs’, but it failed during the
> > build of the static gawk binary.
> > 
> > I also did a `guix pull --branch=core-updates-frozen`, which built a
> > ton of stuff and completed successfully. At the time,
> > core-updates-frozen was at commit 5e4cdb5b3b1d (”gnu: python-django:
> > Fix test failure.”)
> 
> Woow, that’s fairly intense testing!

:-)

I was glad to see that powerpc64le-linux was in better shape than I had 
thought.

> Does the Coreutils test failure at 
> happen on real hardware?

Thanks for point it out. I just tested and it doesn’t! I’ll close that 
issue.

> > So next step for me is to look into the build failures above. I’ll
> > semi-randomly start with ‘gmp-boot’ and see what I can find out.
> 
> Neat, thank you!

You’re welcome. Patches on issues 49880, 49881 and 49882. :-)

-- 
Thanks,
Thiago

Re: core-updates-frozen on powerpc64le-linux

[Ludovic Courtès]

Hi!

Thiago Jung Bauermann  skribis:

> Em quarta-feira, 28 de julho de 2021, às 08:50:16 -03, Mathieu Othacehe 
> escreveu:

[...]

>> This means that the core-updates branch remains open, while the
>> core-updates-frozen branch will only accept bug fixes.
>> 
>> This branch contains exciting new features, such as:
>> 
>> * Switch to GCC 10.
>> * Update to TexLive 2021.
>> * Simplified package inputs[1].
>> * Build system Gexp support[2].
>> * Meson cross-compilation support[3].
>> 
>> between lots of other things.
>
> Really nice refresh indeed.

Woohoo!

>> Cuirass has started evaluating this branch here:
>> https://ci.guix.gnu.org/jobset/core-updates-frozen. According to the
>> related dashboard, there's still a bit of work required to stabilize
>> this branch: https://ci.guix.gnu.org/eval/68124/dashboard.
>
> There are no results for powerpc64le-linux. Does anyone know why?

It was turned off in the config at
.  I’ve
added it now (though maybe it won’t actually build until someone has
pushed.)

Note that currently ci.guix only does emulated powerpc64le-linux because
the only POWER9 machine we currently have access to (lent by OSUOSL) is
not running ‘cuirass-remote-worker’.  It’s a foreign distro (Debian) so
setting up these things can be a bit tedious.  If you or anyone would
like to help with this, we can discuss it!

(bordeaux.guix does have a POWER9 build machine behind, but it’s not
building ‘core-updates-frozen’ currently.)

> A few days ago I requested access to a VM on the Unicamp/IBM Minicloud, and 
> had it granted a couple of hours later so now now I have a POWER VM to play 
> with. :-)  I was a bit surprised to see it’s actually a POWER8 system 
> rather than POWER9, but I don’t think it matters for Guix development and 
> tests.
>
> I’m using a guest with 8 vCPUs and Debian testing installed. Guix is 
> working fine on it, installed from Debian’s experimental ‘guix’ package 
> (thanks vagrant!) and then updated from v1.3 to master with `guix pull`. 
> The Minicloud allows use for 30 days, and can extend it to 30 more days. 
> Hopefuly, that should be enough to help get core-updates in shape on 
> powerpc64le-linux.
>
> The last Cuirass evaluation of core-updates with powerpc64le-linux results 
> is https://ci.guix.gnu.org/eval/67285 so I tried to run the failed builds 
> on my VM to see what the current state is. My core-updates-frozen branch 
> was at commit f8458a228224 (”build-system/python: Handle missing metadata 
> on Python 2.”) when I did these builds.
>
> At first, I didn’t try the “*tarball*” builds because I didn’t want to 
> focus on the bootstrap binaries. Apart from those, I was glad to see that 
> all failed powerpc64le-linux builds from that evaluation built fine on my 
> VM, except for the ones below:
>
> • gcc-toolchain@4.8
> • gcc-toolchain@5.5
> • gmp@4.3.2 aka `(@@ (gnu packages commencement) gmp-boot)`
> • mpfr@2.4.2 aka `(@@ (gnu packages commencement) mpfr-boot)`
> • mpc@1.0.3 aka `(@@ (gnu packages commencement) mpc-boot)`
>
> I later tried building ‘bootstrap-tarballs’, but it failed during the build 
> of the static gawk binary.
>
> I also did a `guix pull --branch=core-updates-frozen`, which built a ton of 
> stuff and completed successfully. At the time, core-updates-frozen was at 
> commit 5e4cdb5b3b1d (”gnu: python-django: Fix test failure.”)

Woow, that’s fairly intense testing!

Does the Coreutils test failure at 
happen on real hardware?

> So next step for me is to look into the build failures above. I’ll semi-
> randomly start with ‘gmp-boot’ and see what I can find out.

Neat, thank you!

Ludo’.

Re: core-updates frozen!

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> The Core-updates bootstrap (code named "Scheme-only bootstrap") removes
>>
>>   Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.
>>
>> and replaces them with Gash and Gash-Utils!
>
> That’s worth a second blog post!  :-)

Yes, let's do that when core-updates is merged into master!  "someone"
is still struggling a bit with the documentation anyway.  ;-)

janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: core-updates frozen!

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> For the record...it's even better: The GCC, binutils and glibc
> removal mentioned above is already in master; so our next release will
> bootstrap from ~135MB like blog post mentions!
>
> The Core-updates bootstrap (code named "Scheme-only bootstrap") removes
>
>   Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.
>
> and replaces them with Gash and Gash-Utils!

That’s worth a second blog post!  :-)

Ludo’.

Re: core-updates frozen!

[Marius Bakke]

Jan Nieuwenhuizen  writes:

>> For those unaware, this means that the set of trusted binaries at the
>> root of the package graph from which everything else derives is only 60
>> MiB (on i686 and x86_64).  The set no longer includes GCC, binutils, or
>> glibc!
>
>> For more information, see jannekes blog post:
>>
>> https://www.joyofsource.com/guix-reduces-bootstrap-seed-by-50.html
>
> For the record...it's even better: The GCC, binutils and glibc
> removal mentioned above is already in master; so our next release will
> bootstrap from ~135MB like blog post mentions!
>
> The Core-updates bootstrap (code named "Scheme-only bootstrap") removes
>
>   Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.
>
> and replaces them with Gash and Gash-Utils!

Oh my, that's just incredible, I did not think we were there already!

Thanks for the update.  :-)


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Jan Nieuwenhuizen]

Marius Bakke writes:

> Jan Nieuwenhuizen  writes:
>
>> Marius Bakke writes:
>>
>>> The branch currently represents 676 commits by 26 people.  Some
>>> highlights from this round:
>>>
>>> * Guix runs natively on GNU/Hurd.
>>> * Guix System can be cross-compiled for foreign architectures.
>>> * The distribution is built with Guile 3.0.
>>> * GNOME 3.34 (on a separate branch, will get merged shortly).
>>
>> These are exciting changes!  Let's also not forget:
>>
>>  * for x86 and x86_64: another reduction of the bootstrap binary seed by
>> roughly %0%, to ~60MB!
>
> I knew I was forgetting something important!  Thanks for the reminder.

:-)

> For those unaware, this means that the set of trusted binaries at the
> root of the package graph from which everything else derives is only 60
> MiB (on i686 and x86_64).  The set no longer includes GCC, binutils, or
> glibc!

> For more information, see jannekes blog post:
>
> https://www.joyofsource.com/guix-reduces-bootstrap-seed-by-50.html

For the record...it's even better: The GCC, binutils and glibc
removal mentioned above is already in master; so our next release will
bootstrap from ~135MB like blog post mentions!

The Core-updates bootstrap (code named "Scheme-only bootstrap") removes

  Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.

and replaces them with Gash and Gash-Utils!

janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: core-updates frozen!

[Jan Nieuwenhuizen]

Pierre Neidhardt writes:

> Jan Nieuwenhuizen  writes:
>
>> These are exciting changes!  Let's also not forget:
>>
>>  * for x86 and x86_64: another reduction of the bootstrap binary seed by
>> roughly %0%, to ~60MB!
>
> %0%? :p

Hah -- should have been yeah, 50%!

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: core-updates frozen!

[Marius Bakke]

Jan Nieuwenhuizen  writes:

> Marius Bakke writes:
>
>> The branch currently represents 676 commits by 26 people.  Some
>> highlights from this round:
>>
>> * Guix runs natively on GNU/Hurd.
>> * Guix System can be cross-compiled for foreign architectures.
>> * The distribution is built with Guile 3.0.
>> * GNOME 3.34 (on a separate branch, will get merged shortly).
>
> These are exciting changes!  Let's also not forget:
>
>  * for x86 and x86_64: another reduction of the bootstrap binary seed by
> roughly %0%, to ~60MB!

I knew I was forgetting something important!  Thanks for the reminder.

For those unaware, this means that the set of trusted binaries at the
root of the package graph from which everything else derives is only 60
MiB (on i686 and x86_64).  The set no longer includes GCC, binutils, or
glibc!

For more information, see jannekes blog post:

https://www.joyofsource.com/guix-reduces-bootstrap-seed-by-50.html


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Jan Nieuwenhuizen]

Marius Bakke writes:

> The branch currently represents 676 commits by 26 people.  Some
> highlights from this round:
>
> * Guix runs natively on GNU/Hurd.
> * Guix System can be cross-compiled for foreign architectures.
> * The distribution is built with Guile 3.0.
> * GNOME 3.34 (on a separate branch, will get merged shortly).

These are exciting changes!  Let's also not forget:

 * for x86 and x86_64: another reduction of the bootstrap binary seed by
roughly %0%, to ~60MB!

> Thanks to everyone who contributed to this branch.  Let the rebuilds
> begin!

\o/

Thanks,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: core-updates frozen!

[Christopher Baines]

I've sent a few patches to fix a couple of build issues on the
core-updates branch [1][2].

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36641
2: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36643


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Marius Bakke]

Ludovic Courtès  writes:

> Hello!
>
> Marius Bakke  skribis:
>
>> The 'core-updates' branch is ready for testing!  This is a very early
>> stage, so many substitutes are missing.  Consider yourself warned ;-)
>
> Yay!
>
>> ** GNU/Hurd no longer uses a special glibc variant.
>
> That’s the case since the previous ‘core-updates’ merge.  :-)

Whoops!

There is another important change that I forgot to list as well: glibc
no longer provides Sun/ONC RPC support, so many packages need to migrate
to 'libtirpc' and/or 'rpcsvc-proto'.


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Ludovic Courtès]

Hello!

Marius Bakke  skribis:

> The 'core-updates' branch is ready for testing!  This is a very early
> stage, so many substitutes are missing.  Consider yourself warned ;-)

Yay!

> ** GNU/Hurd no longer uses a special glibc variant.

That’s the case since the previous ‘core-updates’ merge.  :-)

At any rate, thanks for the news items, it’s great to rediscover what’s
actually been done months ago!

Ludo’.

Re: core-updates frozen!

[Leo Famulari]

On Fri, Mar 03, 2017 at 07:33:52PM +0100, Marius Bakke wrote:
> Note that 1.19.3 will be released shortly since 1.19.2 had a release bug
> that requires running `autoreconf`. See:
> 
> https://lists.x.org/archives/xorg-announce/2017-March/002780.html

Ooookay :)

> > I've been reconfiguring my GuixSD system on core-updates, so I've fixed
> > and then suffered breakage in a few non-core packages so far :)
> 
> Wow, nice :)

Note that I haven't succeeded yet. But I did reach the build of GRUB,
which failed to build.

> > At some arbitrary point we have to stop changing the branch and just
> > build it. Newer important updates will have to be grafted.
> 
> Agreed. Let's do a full evaluation once Hydra settles down and then
> *really* freeze it ;)

Okay, but Hydra may never settle down!


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Marius Bakke]

Leo Famulari  writes:

> On Fri, Mar 03, 2017 at 01:02:04AM +0100, Marius Bakke wrote:
>> Leo Famulari  writes:
>> > Once these changes are pushed, I'll start a new evaluation:
>> >
>> > http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
>> >
>> > Please, no more rebuild the world changes except to fix breakage in the
>> > core packages.
>> 
>> xorg-server@1.19.2 was *just* released[0] and contains some important
>> bug fixes (notably CVE-2017-2624).
>> 
>> [0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html
>
> It looks like a relatively small set of changes.
>
>> AFAICT it has not been built yet on Hydra since it's not part of the
>> "core" package set. Is it okay to push?
>
> xorg-server is not a core package, so I guess it's fine. I'll do the
> update when pushing the libgd changes from the thread linked above.

Note that 1.19.3 will be released shortly since 1.19.2 had a release bug
that requires running `autoreconf`. See:

https://lists.x.org/archives/xorg-announce/2017-March/002780.html

> I've been reconfiguring my GuixSD system on core-updates, so I've fixed
> and then suffered breakage in a few non-core packages so far :)

Wow, nice :)

> At some arbitrary point we have to stop changing the branch and just
> build it. Newer important updates will have to be grafted.

Agreed. Let's do a full evaluation once Hydra settles down and then
*really* freeze it ;)

>> Unfortunately I have not been able to backport the fix to 1.18.4.
>
> Okay, hopefully we can figure it out or copy from another distro.


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Leo Famulari]

On Fri, Mar 03, 2017 at 01:02:04AM +0100, Marius Bakke wrote:
> Leo Famulari  writes:
> > Once these changes are pushed, I'll start a new evaluation:
> >
> > http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
> >
> > Please, no more rebuild the world changes except to fix breakage in the
> > core packages.
> 
> xorg-server@1.19.2 was *just* released[0] and contains some important
> bug fixes (notably CVE-2017-2624).
> 
> [0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html

It looks like a relatively small set of changes.

> AFAICT it has not been built yet on Hydra since it's not part of the
> "core" package set. Is it okay to push?

xorg-server is not a core package, so I guess it's fine. I'll do the
update when pushing the libgd changes from the thread linked above.

I've been reconfiguring my GuixSD system on core-updates, so I've fixed
and then suffered breakage in a few non-core packages so far :)

At some arbitrary point we have to stop changing the branch and just
build it. Newer important updates will have to be grafted.

> Unfortunately I have not been able to backport the fix to 1.18.4.

Okay, hopefully we can figure it out or copy from another distro.


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Marius Bakke]

Leo Famulari  writes:

> On Mon, Feb 27, 2017 at 03:30:59PM -0500, Leo Famulari wrote:
>> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
>> > So, here’s a plan:
>> > 
>> >   • Once Efraim has pushed some of the aarch64 patches, do another
>> > evaluation of the “core” package set for that branch, and check for
>> > anything wrong.  From there on, forbid full-rebuild changes.
>> 
>> Let's freeze core-updates and try to build it. No more rebuild the world
>> changes except to fix breakage.
>
> Once these changes are pushed, I'll start a new evaluation:
>
> http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
>
> Please, no more rebuild the world changes except to fix breakage in the
> core packages.

xorg-server@1.19.2 was *just* released[0] and contains some important
bug fixes (notably CVE-2017-2624).

[0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html

AFAICT it has not been built yet on Hydra since it's not part of the
"core" package set. Is it okay to push?

Unfortunately I have not been able to backport the fix to 1.18.4.


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Leo Famulari]

On Mon, Feb 27, 2017 at 03:30:59PM -0500, Leo Famulari wrote:
> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
> > So, here’s a plan:
> > 
> >   • Once Efraim has pushed some of the aarch64 patches, do another
> > evaluation of the “core” package set for that branch, and check for
> > anything wrong.  From there on, forbid full-rebuild changes.
> 
> Let's freeze core-updates and try to build it. No more rebuild the world
> changes except to fix breakage.

Once these changes are pushed, I'll start a new evaluation:

http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html

Please, no more rebuild the world changes except to fix breakage in the
core packages.


signature.asc
Description: PGP signature

Re: core-updates frozen

[Ludovic Courtès]

It’s merged now!

There are still broken packages.  Please check
 and help fix them.  Each person
fixing something will get a proportion of my gratitude proportional to
the amount of fixing.  :-)

Ludo’.

Re: core-updates frozen

[Ludovic Courtès]

Beware, gawk 4.1.1 was bootstrapped with an unreleased libtool:

--8<---cut here---start->8---
~/src/gawk-4.1.1/extension$ ./libtool --version
libtool (GNU libtool) 2.4.2.418
Written by Gordon Matzigkeit , 1996

Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--8<---cut here---end--->8---

Ludo’.

Re: core-updates frozen

[Ludovic Courtès]

Hi, Mark,

Thanks for testing!

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>> Unfortunately, the MIPS box for Hydra is currently off-line, so I don’t
>> have any feedback.  It would be great if you could start building the
>> branch.
>
> I tried building 'hello' with v0.6-389-g1319cfe and got as far as gawk,
> which failed its test suite with the following log tail:
>
>  Done with tests that can vary based on character set or locale 
> support 
>  Starting shared library tests 
> make[2]: Entering directory '/tmp/nix-build-gawk-4.1.1.drv-0/gawk-4.1.1/test'
> fnmatch
> ./fnmatch.ok _fnmatch differ: char 1, line 1
> Makefile:3631: recipe for target 'fnmatch' failed
> make[2]: [fnmatch] Error 1 (ignored)

‘configure’ says:

--8<---cut here---start->8---
checking whether the gcc linker 
(/gnu/store/ipphmvaf5f4r34wz4jnwhn4pif7x1x5p-ld-wrapper-boot3-0/bin/ld -m elf) 
supports shared libraries... ld: unrecognised emulation mode: elf
Supported emulations: elf32ltsmipn32 elf32btsmipn32 elf32ltsmip elf32btsmip 
elf64ltsmip elf64btsmip
no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... unsupported
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
--8<---cut here---end--->8---

And on x86_64:

--8<---cut here---start->8---
checking whether the gcc linker 
(/gnu/store/w0y0axy55gqpk52vf07vrz92g8ib7ssx-ld-wrapper-boot3-0/bin/ld) 
supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
--8<---cut here---end--->8---

This check comes from libtool.m4.  It has specific cases for other
platforms, but not mips*-*gnu:

--8<---cut here---start->8---
# Some flags need to be propagated to the compiler or linker for good
# libtool support.
case $host in
[...]
x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
  # Find out which ABI we are using.
  echo 'int i;' > conftest.$ac_ext
  if AC_TRY_EVAL(ac_compile); then
case `/usr/bin/file conftest.o` in
  *32-bit*)
case $host in
  x86_64-*kfreebsd*-gnu)
LD="${LD-ld} -m elf_i386_fbsd"
;;
  x86_64-*linux*)
LD="${LD-ld} -m elf_i386"
;;
  ppc64-*linux*|powerpc64-*linux*)
LD="${LD-ld} -m elf32ppclinux"
;;
[...]
--8<---cut here---end--->8---

However I don’t see exactly where ‘-m elf’ comes from.

Are you doing a chroot build?  (In which case /usr/bin/file is
unavailable.)

Thanks,
Ludo’.

Re: core-updates frozen

[Mark H Weaver]

Mark H Weaver  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>> Unfortunately, the MIPS box for Hydra is currently off-line, so I don’t
>> have any feedback.  It would be great if you could start building the
>> branch.
>
> I tried building 'hello' with v0.6-389-g1319cfe and got as far as gawk,
> which failed its test suite with the following log tail:
>
>  Done with tests that can vary based on character set or locale 
> support 
>  Starting shared library tests 
> make[2]: Entering directory '/tmp/nix-build-gawk-4.1.1.drv-0/gawk-4.1.1/test'
> fnmatch
> ./fnmatch.ok _fnmatch differ: char 1, line 1
> Makefile:3631: recipe for target 'fnmatch' failed

gawk-4.1.1/test/_fnmatch contains the following:

--8<---cut here---start->8---
gawk: fnmatch.awk:1: error: can't open shared library `fnmatch' for reading (No 
such file or directory)
EXIT CODE: 1
--8<---cut here---end--->8---

 Mark

Re: core-updates frozen

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:
> Unfortunately, the MIPS box for Hydra is currently off-line, so I don’t
> have any feedback.  It would be great if you could start building the
> branch.

I tried building 'hello' with v0.6-389-g1319cfe and got as far as gawk,
which failed its test suite with the following log tail:

--8<---cut here---start->8---
 Done with tests that can vary based on character set or locale support 

 Starting shared library tests 
make[2]: Entering directory '/tmp/nix-build-gawk-4.1.1.drv-0/gawk-4.1.1/test'
fnmatch
./fnmatch.ok _fnmatch differ: char 1, line 1
Makefile:3631: recipe for target 'fnmatch' failed
make[2]: [fnmatch] Error 1 (ignored)
filefuncs
cmp: EOF on ./filefuncs.ok
Makefile:3636: recipe for target 'filefuncs' failed
make[2]: [filefuncs] Error 1 (ignored)
fork
cmp: EOF on ./fork.ok
Makefile:3641: recipe for target 'fork' failed
make[2]: [fork] Error 1 (ignored)
fork2
cmp: EOF on ./fork2.ok
Makefile:3646: recipe for target 'fork2' failed
make[2]: [fork2] Error 1 (ignored)
fts
gawk: ./fts.awk:1: error: can't open shared library `filefuncs' for reading (No 
such file or directory)
Makefile:2260: recipe for target 'fts' failed
make[2]: *** [fts] Error 1
make[2]: Leaving directory '/tmp/nix-build-gawk-4.1.1.drv-0/gawk-4.1.1/test'
Makefile:1531: recipe for target 'shlib-tests' failed
make[1]: *** [shlib-tests] Error 2
make[1]: Leaving directory '/tmp/nix-build-gawk-4.1.1.drv-0/gawk-4.1.1/test'
Makefile:728: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1
phase `check' failed after 56 seconds
--8<---cut here---end--->8---

Before gawk, I had built the following packages successfully:

fz4qjnddm8rc185i05jgfgvqlf4jp926-binutils-bootstrap-0
h0yw348cfbi777i6ca4427cb95ynkyc0-bootstrap-binaries-0
gxg6gvy08bz1wqq0hpi4sr99jzwq4m8x-glibc-bootstrap-0
4cq3q3920ki8czfbf7w4j4vxilskpnlv-gcc-bootstrap-0
mn7ixlvjznyyj2p7q731cz8di3fvpq66-make-boot0-4.0
srsqzfwq1zr3v2p61agsl9g86815q5pr-diffutils-3.3
v1qkwj2kv34icnc6kfvncm7rrmpm17v8-findutils-4.4.2
k9ncfqi2nx51myq420xr2w4jckz2ix09-binutils-cross-boot0-2.24
dbzhplprcifl57nzp5q4f4m511ki69rz-perl-5.16.1
jpdckj0dnqvsy03jlgzgzi3ipdr1f83l-xz-5.0.4
fiygysg0idz3p1wl3biqjz1cprvxg85z-gcc-cross-boot0-4.8.3
njkqxak7ng82hfgrr9yc6xd2dyqpw356-linux-libre-headers-3.3.8
62qkdznlcqjsapigvnn2rk3qn2zj2gbi-texinfo-5.2
8k1gbgg68il9b1xfw68b53qpb33c299n-glibc-intermediate-2.19
iwa2grw36bi43n47y3srlhvdk433p0m1-gcc-cross-boot0-wrapped-4.8.3
rz4xcx56lblwcri5xv6lwip8jgm3r8gy-bash-light-4.3
9rc18pjlqspxsd49x8yxwzr5sl70a8lp-glibc-2.19
n30yqpr16dsr3aj5khzp5zdfshlpgdp0-gcc-cross-boot0-wrapped-4.8.3
xdkwl4725d420whbna0xn0w07ak2fbnp-binutils-2.24
j4mv4kl3n3hi9lmfvr6z6r7nwd2ak1gk-libstdc++-4.8.3
k7rpmysjhx9wss2f8aiwiw50fxf95dcf-ld-wrapper-boot3-0
00xv2sv1c2j0jskdcapmfikq52i1rj7p-gcc-4.8.3
5bx6icjkjqf0bpqmrasmqxaq5snjr40s-ncurses-5.9
czl4raqvl5qicc35nvwp9pp4prnb72by-readline-6.3
3810lg6laq6872n4qllx4017sl8yqdh7-bash-4.3
0hyf81bnvg30plhm9151qk32mg6bw4xc-libffi-3.0.13
1n97dyj83j5irkzq7ryalxaf41iky2qs-libunistring-0.9.3
xf7hd6jc0qp4kzdww9ilra9vibqkaij5-ncurses-5.9
y766cvr33x84lj1g75lycjk8bvqc60i5-pkg-config-0.27.1
blwzmcm9ipay86d33frgql8v2pzwf2cr-perl-5.16.1
bpn3zcv13ff9i2kqqrk8gghbl05kasw6-m4-1.4.17
wp860q1zz7hs8pr33aihvh5h3jwcspn8-libatomic-ops-7.4.0
d3q5jn7pq1fgnc9kalg4zbjy8pzcraxn-readline-6.3
1lhwaaxzmzbmxqpbgyw5k455j2qvllcx-libtool-2.4.2
ww76m9jj7rwj87q61x0wbvzvkdwlyv2v-gmp-6.0.0a
9jfjn09znwqg55k3slhh71xrw88ajjhc-libgc-7.4.0
34jmy1zg9hh9d4y98axjfkm7z2g7w87v-guile-2.0.11
clg2i1y3b214rxgmc66rqcchv2cclzg8-ld-wrapper-0
9sckxribqafbqrxmhmwpl6cyb6a5anxs-grep-2.20
hrl4m7qaa78i7v08h30ca6xai7znfh6c-pkg-config-0.27.1
hajwplc124zsz1s71ccyx9gpzn0wpqpx-perl-5.16.1
0zxbppdgayqk4lk13r12x3cl1g085ffx-m4-1.4.17
cy156ib9p3bjgjszs98dcc6clzfahwlw-expat-2.1.0
jasm5dcih8yak3dg7vvd72807mc6nfx6-make-4.0
nwpdfff3w38x8qyngdrrwxwdq4mi3jll-gmp-6.0.0a
496ym1di159jnmys8hdlx9birrsrpgzd-gettext-0.19.1
5snwh1sy6fvadj8l9yzg83dw0mcdhcqb-attr-2.4.46
pgnjipm9jhxmsxw4hfqnlxpy7bsbsds1-acl-2.2.51
vhaj6v10pyz86ibirr3m3jpdlnxbmqyc-coreutils-8.22
2kjyyrhxfaakdiwa2pjss3qif270f1a2-patch-2.7.1
6rdsnh7vi2v8g144qspjjffkbfysma3f-tar-1.27.1
7vz2lpp1qs75isxcc71lmnc7gz2hfzh8-xz-5.0.4
9d1310r39rdpm7fmkwwr4bjvc1va3zgm-sed-4.2.2
cbxx9c6k5qh0wi8gls4iqj8blg7l47ma-diffutils-3.3
fw6vrrlfnrivigwm5ha5vnbwn31ncml7-gzip-1.6
km612rhw16839dznhy3jalygbx137j7j-findutils-4.4.2
pn5mvyjlcy6nvbh8mzhhl5jn5mysa7w7-bzip2-1.0.6
fxvv04h1aznm55k4ndblwbf7hvjrj6b2-libsigsegv-2.10

I've attached the entire (compressed) gawk build log.

  Mark




1g7l1ydixnaha4gzzdzb6b1jya91b14h-gawk-4.1.1.drv.bz2
Description: Failed gawk build log

Re: core-updates frozen

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> I'm sorry I haven't had time to look into this, but in April I tried to
>> build GCC 4.9.0 on my YeeLoong and it failed.
>
> That doesn’t look Guix-specific, no?

No, it doesn't.

>> Unless it has been fixed since then, this might mean that our MIPS
>> port will be non-functional in the next release.
>
> No, because we use 4.8.3 in the build environment.

Ah, good.

> Unfortunately, the MIPS box for Hydra is currently off-line, so I don’t
> have any feedback.  It would be great if you could start building the
> branch.

Okay, I'll start a build and let you know.

 Thanks,
   Mark

Re: core-updates frozen

[Ludovic Courtès]

Hello!

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> l...@gnu.org (Ludovic Courtès) skribis:
>>
>>> As discussed before, we’ll merge the branch before June 13th.
>>
>> The branch is now frozen.  Hydra is building it all now, and unless
>> something goes wrong, I’ll merge it once it’s done building it.
>
> I'm sorry I haven't had time to look into this, but in April I tried to
> build GCC 4.9.0 on my YeeLoong and it failed.

That doesn’t look Guix-specific, no?

> Unless it has been fixed since then, this might mean that our MIPS
> port will be non-functional in the next release.

No, because we use 4.8.3 in the build environment.

Unfortunately, the MIPS box for Hydra is currently off-line, so I don’t
have any feedback.  It would be great if you could start building the
branch.

Thanks,
Ludo’.

Re: core-updates frozen

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> As discussed before, we’ll merge the branch before June 13th.
>
> The branch is now frozen.  Hydra is building it all now, and unless
> something goes wrong, I’ll merge it once it’s done building it.

I'm sorry I haven't had time to look into this, but in April I tried to
build GCC 4.9.0 on my YeeLoong and it failed.  Unless it has been fixed
since then, this might mean that our MIPS port will be non-functional in
the next release.

See below for the tail of my build log.

 Mark


--8<---cut here---start->8---
make[3]: Entering directory '/tmp/nix-build-gcc-4.9.0.drv-0/build/gcc'
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/gnu/store/l5884ix8rl5pf71aniiyz77q5z8s1awk-bash-4.3/bin/bash 
../../gcc-4.9.0/gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT="((MASK_SPLIT_ADDRESSES)|MASK_EXPLICIT_RELOCS)|MASK_RELAX_PIC_CALLS"
 \
HEADERS="options.h insn-constants.h config/dbxelf.h config/elfos.h 
config/gnu-user.h config/linux.h config/linux-android.h config/glibc-stdint.h 
config/vxworks-dummy.h config/mips/mips.h config/mips/gnu-user.h 
config/mips/gnu-user64.h config/mips/linux64.h config/mips/linux-common.h 
config/initfini-array.h defaults.h" DEFINES="TARGET_ENDIAN_DEFAULT=0  
LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 DEFAULT_LIBC=LIBC_GLIBC 
ANDROID_DEFAULT=0 MIPS_ABI_DEFAULT=ABI_N32" \
/gnu/store/l5884ix8rl5pf71aniiyz77q5z8s1awk-bash-4.3/bin/bash 
../../gcc-4.9.0/gcc/mkconfig.sh tm.h
TARGET_CPU_DEFAULT="" \
HEADERS="config/mips/mips-protos.h config/linux-protos.h tm-preds.h" DEFINES="" 
\
/gnu/store/l5884ix8rl5pf71aniiyz77q5z8s1awk-bash-4.3/bin/bash 
../../gcc-4.9.0/gcc/mkconfig.sh tm_p.h
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/gnu/store/l5884ix8rl5pf71aniiyz77q5z8s1awk-bash-4.3/bin/bash 
../../gcc-4.9.0/gcc/mkconfig.sh bconfig.h
g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables 
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -I. 
-Ibuild -I../../gcc-4.9.0/gcc -I../../gcc-4.9.0/gcc/build 
-I../../gcc-4.9.0/gcc/../include  -I../../gcc-4.9.0/gcc/../libcpp/include  \
-o build/genmddeps.o ../../gcc-4.9.0/gcc/genmddeps.c
g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables 
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -I. 
-Ibuild -I../../gcc-4.9.0/gcc -I../../gcc-4.9.0/gcc/build 
-I../../gcc-4.9.0/gcc/../include  -I../../gcc-4.9.0/gcc/../libcpp/include  \
-o build/read-md.o ../../gcc-4.9.0/gcc/read-md.c
g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables 
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -I. 
-Ibuild -I../../gcc-4.9.0/gcc -I../../gcc-4.9.0/gcc/build 
-I../../gcc-4.9.0/gcc/../include  -I../../gcc-4.9.0/gcc/../libcpp/include  \
-o build/errors.o ../../gcc-4.9.0/gcc/errors.c
g++   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE 
-static-libstdc++ -static-libgcc 
-Wl,-rpath=/gnu/store/awpcc2na8w1i2ydh416x8p5bqds5lh4a-glibc-2.19/lib 
-Wl,-dynamic-linker 
-Wl,/gnu/store/awpcc2na8w1i2ydh416x8p5bqds5lh4a-glibc-2.19/lib/ld.so.1 -o 
build/genmddeps \
build/genmddeps.o build/read-md.o build/errors.o 
../build-mips64el-unknown-linux-gnu/libiberty/libiberty.a
build/genmddeps ../../gcc-4.9.0/gcc/config/mips/mips.md > tmp-mddeps
/gnu/store/l5884ix8rl5pf71aniiyz77q5z8s1awk-bash-4.3/bin/bash 
../../gcc-4.9.0/gcc/../move-if-change tmp-mddeps mddeps.mk
echo timestamp > s-mddeps
g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables 
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -I. 
-Ibuild -I../../gcc-4.9.0/gcc -I../../gcc-4.9.0/gcc/build 
-I../../gcc-4.9.0/gcc/../include  -I../../gcc-4.9.0/gcc/../libcpp/include  \
-o build/genmodes.o ../../gcc-4.9.0/gcc/genmodes.c
g++   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -DGENERAT

Re: core-updates frozen

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> As discussed before, we’ll merge the branch before June 13th.
>
> The branch is now frozen.  Hydra is building it all now, and unless
> something goes wrong, I’ll merge it once it’s done building it.

I just fixed a mistake, which triggers a rebuild: commit 953c9fc changed
ncurses so that it builds a separate libtinfo library, which I thought
was a common and good thing.  Here’s what’s at stake, per ncurses’
INSTALL:

--with-termlib[=XXX]
When building the ncurses library, organize this as two parts:  the
curses library (libncurses) and the low-level terminfo library
(libtinfo).  This is done to accommodate applications that use only
the latter.  The terminfo library is about half the size of the total.

If an option value is given, that overrides the name of the terminfo
library.  For instance, if the wide-character version is built, the
terminfo library would be named libtinfow.  But the libtinfow interface
is upward compatible from libtinfo, so it would be possible to overlay
libtinfo.so with a "wide" version of libtinfow.so by renaming it with
this option.

But it turns out that most packages don’t expect it this way, and in
fact recent distros don’t seem to do it; furthermore, we don’t have any
package that expects libtinfo separately at this point.  Hence the
revert in 7190ae7 (see the log for details.)

Ludo’.