Freezing ‘core-updates’ soon?

Freezing ‘core-updates’ soon?

[Ludovic Courtès]

Hello Guix!

What about finally merging that ‘core-updates’ branch?  :-)

The main things to decide on are:

  • Upgrading to GCC 10?  I know Marius has spent time looking at it and
    fixing build failures caused by the upgrade.  Can we do it?

  • Reduced binary seeds—anything new?  My understanding is that the
    reduced binary seed bootstrap now works on ARM, but that we were
    waiting on a Mes release to merge those bits.  Janneke, Danny?

  • Simplified package inputs—I’ll keep working on that, and most of the
    work can be done without a world rebuild, so it’s not a blocker IMO.

Anything else?  Any patches pending review?

It would be great to freeze within a week (that is, stop world-rebuild
changes) with the goal of merging within a six weeks (end of July).

Thoughts?

Ludo’.

Re: Freezing ‘core-updates’ soon?

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> What about finally merging that ‘core-updates’ branch?  :-)
>
> The main things to decide on are:
>
>   • Upgrading to GCC 10?  I know Marius has spent time looking at it and
>     fixing build failures caused by the upgrade.  Can we do it?
>
>   • Reduced binary seeds—anything new?  My understanding is that the
>     reduced binary seed bootstrap now works on ARM, but that we were
>     waiting on a Mes release to merge those bits.  Janneke, Danny?

Sadly, we are not there yet.  The gcc/glibc build is still not done.

The full source bootstrap is "almost ready" and is waiting for a GNU Mes
release.  It was wating for an M2-Planet release but that happened last
week!  I'm not sure about a time frame here though.  A week, hmm?

>   • Simplified package inputs—I’ll keep working on that, and most of the
>     work can be done without a world rebuild, so it’s not a blocker IMO.

I haven't really caught-up here and am still wondering here about things
like

   ("foo-for-build" ,foo)
   ("patch-bar" ,(search-patch ...))

but that's prolly addressed.  I'll look into this.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Freezing ‘core-updates’ soon?

[Maxime Devos]

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

Ludovic Courtès schreef op di 15-06-2021 om 10:52 [+0200]:
> Hello Guix!
> 
> What about finally merging that ‘core-updates’ branch?  :-)
> 
> The main things to decide on are: [...]
>
> Anything else?  Any patches pending review?

* Fixing cross-compilation

I sent a patch series fixing some cross-compilation build failures
I discovered when trying to cross-compile glib
(<https://issues.guix.gnu.org/49025>, also implements cross-compilation
for meson-build-system). These could in principle be done on 'master' using
,@(if (%current-target-system) ...) though.

However, most of the causes of the cross-build failures is %build-inputs
not being defined anymore on core-updates when cross-compiling, but
apparently %build-inputs is still defined on master, so I just targetted
core-updates.

I would prefer to not have to add to the next release notes that
cross-compiling isn't supported anymore, so I'd like to have the
cross-compilation fixes on core-updates before the freeze.

* Fixing failed evaluations of core-updates (https://ci.guix.gnu.org/jobset/core-updates)

See https://issues.guix.gnu.org/49025#29 for a corresponding patch.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Freezing ‘core-updates’ soon?

[Efraim Flashner]

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

On Tue, Jun 15, 2021 at 10:52:51AM +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> What about finally merging that ‘core-updates’ branch?  :-)
> 
> The main things to decide on are:
> 
>   • Upgrading to GCC 10?  I know Marius has spent time looking at it and
>     fixing build failures caused by the upgrade.  Can we do it?

gcc was updated to 10 on the 1st

> Anything else?  Any patches pending review?
> 
> It would be great to freeze within a week (that is, stop world-rebuild
> changes) with the goal of merging within a six weeks (end of July).
> 
> Thoughts?
> 
> Ludo’.
> 

ant-bootstrap FTBFS, and I haven't been able to compile rust on aarch64.
`guix build xz --system=i686-linux' fails to use the correct i686
inputs.

-- 
Efraim Flashner   <efraim@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

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

Re: Freezing ‘core-updates’ soon?

[zimoun]

Hi Ludo,

On Tue, 15 Jun 2021 at 10:52, Ludovic Courtès <ludo@gnu.org> wrote:

> What about finally merging that ‘core-updates’ branch?  :-)

Cool! :-)

> Anything else?  Any patches pending review?

The Julia v1.6 update introduce a tweak to master: utf8proc-2.6.1 [1]
and pcre2-10.36 [2] to avoid a world rebuild.  AFAIK, their update in
core-updates branch is not done.  At least, I have never sent the patch.

The package Julia v1.6 depends on these 2 packages.  The question
becomes if the Julia v1.6 is merged before and after the freeze?

Could you give an input about the location of patches?  See [3].  Thanks
in advance.

1: <http://issues.guix.gnu.org/issue/48325#13>
2: <http://issues.guix.gnu.org/issue/48325#17>
3: <http://issues.guix.gnu.org/issue/48325#25>

Cheers,
simon

PS: On a side note, I will be offline until the end of the next week.

Re: Freezing ‘core-updates’ soon?

[Chris Marusich]

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

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guix!
>
> What about finally merging that ‘core-updates’ branch?  :-)
>
> The main things to decide on are:
>
>   • Upgrading to GCC 10?  I know Marius has spent time looking at it and
>     fixing build failures caused by the upgrade.  Can we do it?
>
>   • Reduced binary seeds—anything new?  My understanding is that the
>     reduced binary seed bootstrap now works on ARM, but that we were
>     waiting on a Mes release to merge those bits.  Janneke, Danny?
>
>   • Simplified package inputs—I’ll keep working on that, and most of the
>     work can be done without a world rebuild, so it’s not a blocker IMO.
>
> Anything else?  Any patches pending review?
>
> It would be great to freeze within a week (that is, stop world-rebuild
> changes) with the goal of merging within a six weeks (end of July).
>
> Thoughts?
>
> Ludo’.

I'm taking some time to test out powerpc64le-linux on core-updates.  At
the very least, I'd like to be able to "guix pull" on core-updates and
use the pulled guix to build some basic stuff.  Last time I tested this
was when we were using gcc-8, so I expect some things are different now.

I would also like to go go back and remove some of the conditionals that
we added in order to support powerpc64le-linux on master.  Then we could
delete the wip-ppc64le branch for good.

-- 
Chris

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

Re: Freezing ‘core-updates’ soon?

[Ludovic Courtès]

Hello!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Ludovic Courtès writes:

[...]

>>   • Reduced binary seeds—anything new?  My understanding is that the
>>     reduced binary seed bootstrap now works on ARM, but that we were
>>     waiting on a Mes release to merge those bits.  Janneke, Danny?
>
> Sadly, we are not there yet.  The gcc/glibc build is still not done.
>
> The full source bootstrap is "almost ready" and is waiting for a GNU Mes
> release.  It was wating for an M2-Planet release but that happened last
> week!  I'm not sure about a time frame here though.  A week, hmm?

Alright.  Well no rush, that can also happen on the next cycle, and we
can also work to make it shorter.  :-)

>>   • Simplified package inputs—I’ll keep working on that, and most of the
>>     work can be done without a world rebuild, so it’s not a blocker IMO.
>
> I haven't really caught-up here and am still wondering here about things
> like
>
>    ("foo-for-build" ,foo)
>    ("patch-bar" ,(search-patch ...))
>
> but that's prolly addressed.  I'll look into this.

Good points.  We’d have to look at specific examples.

In the first case, perhaps it’s enough to add ‘foo’ in ‘native-inputs’.

In both cases, you can always use gexps, like:

  (arguments
    (list #:configure-flags
          #~(list (string-append "FOO_FOR_BUILD=" #$foo))))

… though the ‘foo’ here won’t show up in the inputs fields, which is not
great because then ‘guix graph’ and related tools won’t “see” this
reference, and you can’t easily override it via inheritance.

A better approach is to still add ‘foo’ to ‘native-inputs’ but to write
something like:

  (arguments
    (list #:configure-flags
          #~(list (string-append "FOO_FOR_BUILD="
                                 #$(lookup-package-input
                                    (package-inputs this-package)
                                    "foo")))))

In the second example you give, you could have build-side code that
does, say:

  (lambda* (inputs #:allow-other-keys)
    (invoke "patch" "-p1" "-i"
            (find (cut string-suffix? ".patch") inputs)))

At any rate, I agree we need to find good idioms for these corner cases.

Thoughts?

Thanks,
Ludo’.