I've rebased wip-ppc64le onto core-updates

I've rebased wip-ppc64le onto core-updates

[Chris Marusich]

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

Hi Léo and others,

I just wanted to let you know that I've rebased the wip-ppc64le branch
onto core-updates.  The wip-ppc64le branch head used to be
147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's
df5d633db7acf6389ca9d444b8f5784a0da5ac5d.

I wanted to inform you so you don't get caught off-guard the next time
you update your local copy.

I've squished some commits together where it made sense to do so.  I've
omitted some commits which were cherry-picked before, but which are
already in the core-updates branch.  And I have explicitly NOT merged
master into wip-ppc64le at this time.

I have also taken the liberty of cherry-picking Tobias' commit
65fb3a3eb9a759e3dba18e78113e80d7e5b353f4 from master, which adds Léo to
.guix-authorizations.  This should allow him to add commits on
wip-ppc64le without worrying about causing problems for "guix pull"
later.

-- 
Chris

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

Re: I've rebased wip-ppc64le onto core-updates

[Léo Le Bouter]

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

On Sat, 2021-02-27 at 22:53 -0800, Chris Marusich wrote:
> Hi Léo and others,
> 
> I just wanted to let you know that I've rebased the wip-ppc64le
> branch
> onto core-updates.  The wip-ppc64le branch head used to be
> 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's
> df5d633db7acf6389ca9d444b8f5784a0da5ac5d.
> 
> I wanted to inform you so you don't get caught off-guard the next
> time
> you update your local copy.
> 
> I've squished some commits together where it made sense to do
> so.  I've
> omitted some commits which were cherry-picked before, but which are
> already in the core-updates branch.  And I have explicitly NOT merged
> master into wip-ppc64le at this time.
> 
> I have also taken the liberty of cherry-picking Tobias' commit
> 65fb3a3eb9a759e3dba18e78113e80d7e5b353f4 from master, which adds Léo
> to
> .guix-authorizations.  This should allow him to add commits on
> wip-ppc64le without worrying about causing problems for "guix pull"
> later.
> 

Thanks a bunch!!

Léo

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

Re: I've rebased wip-ppc64le onto core-updates

[Tobias Platen]

On Sun, 28 Feb 2021 21:42:44 +0100
Léo Le Bouter <lle-bout@zaclys.net> wrote:

> On Sat, 2021-02-27 at 22:53 -0800, Chris Marusich wrote:
> > Hi Léo and others,
> > 
> > I just wanted to let you know that I've rebased the wip-ppc64le
> > branch
> > onto core-updates.  The wip-ppc64le branch head used to be
> > 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's
> > df5d633db7acf6389ca9d444b8f5784a0da5ac5d.
> > 
> > I wanted to inform you so you don't get caught off-guard the next
> > time
> > you update your local copy.
> > 
> > I've squished some commits together where it made sense to do
> > so.  I've
> > omitted some commits which were cherry-picked before, but which are
> > already in the core-updates branch.  And I have explicitly NOT merged
> > master into wip-ppc64le at this time.
> > 
> > I have also taken the liberty of cherry-picking Tobias' commit
> > 65fb3a3eb9a759e3dba18e78113e80d7e5b353f4 from master, which adds Léo
> > to
> > .guix-authorizations.  This should allow him to add commits on
> > wip-ppc64le without worrying about causing problems for "guix pull"
> > later.
> > 
> 
> Thanks a bunch!!
> 
> Léo

In my recent talk about the guix port to POWER9, 
I also mentioned the libre-soc project.
Unlike POWER9 and maybe POWER8, libre-soc and microwatt do not implement VSX.
The libre-soc project instead has SVP64, and also plans to extend the POWER ISA
to support GPU like instructions. Since I work mostly on the libre-soc I will have
less time to contribute to the GUIx project.

The relevant bug report to GUIX is
https://bugs.libre-soc.org/show_bug.cgi?id=602

-- 
Tobias Platen <guix@platen-software.de>

Re: I've rebased wip-ppc64le onto core-updates

[jbranso]

March 1, 2021 2:14 PM, "Tobias Platen" <guix@platen-software.de> wrote:


> In my recent talk about the guix port to POWER9,
> I also mentioned the libre-soc project.
> Unlike POWER9 and maybe POWER8, libre-soc and microwatt do not implement VSX.
> The libre-soc project instead has SVP64, and also plans to extend the POWER ISA
> to support GPU like instructions. Since I work mostly on the libre-soc I will have
> less time to contribute to the GUIx project.
> 
> The relevant bug report to GUIX is
> https://bugs.libre-soc.org/show_bug.cgi?id=602

This looks like an annoying bug.  I'll copy the relevant bit from the bug report below:

    any OpenPOWER Compliant systems that choose not to implement the Optional SIMD 
    as per the Linux Compliancy Subset in v3.0C such as Microwatt, A2O, A2I and LibreSOC 
    are accidentally and unintentionally completely excluded from being able to run major
    modern distros, and with ABI changes taking estimated 3 to 5 years to propagate, there 
    are very few options. 

You won't be able to run GNU/Linux on the libreSOC?  That sounds annoying.

> 
> --
> Tobias Platen <guix@platen-software.de>

Re: I've rebased wip-ppc64le onto core-updates

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> I just wanted to let you know that I've rebased the wip-ppc64le branch
> onto core-updates.  The wip-ppc64le branch head used to be
> 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's
> df5d633db7acf6389ca9d444b8f5784a0da5ac5d.
>
> I wanted to inform you so you don't get caught off-guard the next time
> you update your local copy.
>
> I've squished some commits together where it made sense to do so.  I've
> omitted some commits which were cherry-picked before, but which are
> already in the core-updates branch.  And I have explicitly NOT merged
> master into wip-ppc64le at this time.

Noted.

> I have also taken the liberty of cherry-picking Tobias' commit
> 65fb3a3eb9a759e3dba18e78113e80d7e5b353f4 from master, which adds Léo to
> .guix-authorizations.  This should allow him to add commits on
> wip-ppc64le without worrying about causing problems for "guix pull"
> later.

Good idea.

We’ll have to think about merging.  At things stand, it seems that the
bits that could go to ‘master’ (those that don’t trigger a world
rebuild) are already there, right?

For the rest, we could aim for rebasing on core-updates and merging
there.

WDYT?

Thanks,
Ludo’.

Re: I've rebased wip-ppc64le onto core-updates

[Efraim Flashner]

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

On Wed, Mar 10, 2021 at 11:17:02AM +0100, Ludovic Courtès wrote:
> Hi Chris,
> 
> Chris Marusich <cmmarusich@gmail.com> skribis:
> 
> > I just wanted to let you know that I've rebased the wip-ppc64le branch
> > onto core-updates.  The wip-ppc64le branch head used to be
> > 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's
> > df5d633db7acf6389ca9d444b8f5784a0da5ac5d.
> >
> > I wanted to inform you so you don't get caught off-guard the next time
> > you update your local copy.
> >
> > I've squished some commits together where it made sense to do so.  I've
> > omitted some commits which were cherry-picked before, but which are
> > already in the core-updates branch.  And I have explicitly NOT merged
> > master into wip-ppc64le at this time.
> 
> Noted.
> 
> > I have also taken the liberty of cherry-picking Tobias' commit
> > 65fb3a3eb9a759e3dba18e78113e80d7e5b353f4 from master, which adds Léo to
> > .guix-authorizations.  This should allow him to add commits on
> > wip-ppc64le without worrying about causing problems for "guix pull"
> > later.
> 
> Good idea.
> 
> We’ll have to think about merging.  At things stand, it seems that the
> bits that could go to ‘master’ (those that don’t trigger a world
> rebuild) are already there, right?
> 
> For the rest, we could aim for rebasing on core-updates and merging
> there.
> 
> WDYT?

As noted in another thread this would involve updating gcc to gcc-8.
There are some other patches which could go straight into master (I'm
looking at libelf specifically, probably others), but glibc and
gcc/libstdc++ I'm not sure how to do those ones.

Actually, looking at the branch there's also findutils-boot0, but that
can be changed to only be for target-powerpc for now and changed in
core-updates. I have a similar one I had to do for binutils on
powerpc-linux that I managed to make not affect other architectures.

-- 
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: I've rebased wip-ppc64le onto core-updates

[Chris Marusich]

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

Hi,

I've rebased wip-ppc64le again just now onto the latest core-updates.
There were no conflicts.

Because I committed 5d2863dfe4613d5091e61800fcd5a48922c8ce4e and
001fc29b43fd0beb365d536774fae96624309413 directly to core-updates before
rebasing, I removed some similar commits from wip-ppc64le that are no
longer needed.  The rest is the same as before.

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

> We’ll have to think about merging.  At things stand, it seems that the
> bits that could go to ‘master’ (those that don’t trigger a world
> rebuild) are already there, right?
>
> For the rest, we could aim for rebasing on core-updates and merging
> there.

Essentially, yes.  The current plan is to periodically rebase
wip-ppc64le onto core-updates while working out the last few
powerpc64le-linux issues, then merge wip-ppc64le into core-updates, and
then merge core-updates into master.

I've taken care to only include in wip-ppc64le those commits that are
relevant to the porting effort.  Although there are some minor commits
on wip-ppc64le that could be cherry-picked onto master, I'm not sure
it's necessary or particularly helpful to go out of our way to do that
right now.  I would prefer to just finish the wip-ppc64le branch, merge
it into core-updates, and then merge core-updates into master.

Efraim Flashner <efraim@flashner.co.il> writes:

> As noted in another thread this would involve updating gcc to gcc-8.
> There are some other patches which could go straight into master (I'm
> looking at libelf specifically, probably others), but glibc and
> gcc/libstdc++ I'm not sure how to do those ones.
>
> Actually, looking at the branch there's also findutils-boot0, but that
> can be changed to only be for target-powerpc for now and changed in
> core-updates. I have a similar one I had to do for binutils on
> powerpc-linux that I managed to make not affect other architectures.

The libelf fix (b13ba3e gnu: libelf: Fix compilation for
powerpc64le-linux) could go to master, but it's a no-op for all systems
other than powerpc64le-linux.  Since nobody is using the
powerpc64le-linux port yet, there is no need for that change to go to
master at this time.

The findutils-boot0 fix (f4cbd18 gnu: commencement: Fix findutils-boot0
on some systems) fixes findutils-boot0 not only for powerpc64le-linux,
but for any system that does not use glibc-mesboot (i.e., any system
other than x86_64-linux or i686-linux).  We could limit the change to
just fix it for powerpc64le-linux, but I think the other systems will
need the fix, too.

In short, I think it will be simplest to just merge wip-ppc64le into
core-updates and then merge core-updates into master.

-- 
Chris

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

Re: I've rebased wip-ppc64le onto core-updates

[Léo Le Bouter]

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

Just wanted to say, Chris, thank you so much for following up steadily
on this powerpc64le-linux work. I have been testing your changes on and
off but without getting to actually solving issues as I have been busy
with other things unrelated with GNU Guix and also GNU Guix CVE
patching now.

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

Re: I've rebased wip-ppc64le onto core-updates

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> In short, I think it will be simplest to just merge wip-ppc64le into
> core-updates and then merge core-updates into master.

Maybe you could “formally” ask for a review of the branch when you think
it’s ready (perhaps even git-send-emailing the patches to guix-patches,
for convenience), and then we can merge in ‘core-updates’ (if/when that
matches other branch scheduling choices).

Thanks!

Ludo’.

Re: I've rebased wip-ppc64le onto core-updates, Re: Release on April 18th?

[Chris Marusich]

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

Hi Ludo,

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

> Maybe you could “formally” ask for a review of the branch when you think
> it’s ready (perhaps even git-send-emailing the patches to guix-patches,
> for convenience), and then we can merge in ‘core-updates’ (if/when that
> matches other branch scheduling choices).

That's a good idea.  I'll do that for wip-ppc64le-for-master shortly.

I'll do it for wip-ppc64le later, after incorporating the changes from
wip-ppc64le-for-master, and after resolving the issues with the GCC 8
upgrade.

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

> It works on my laptop.  :-) If you’re confident, please push—thanks for
> the fix!

Done in commit 341dfe7eda4972af0a027357015ea595314438b0!

> (Next time please report the issue to bug-guix where it’s more likely to
> be seen and dealt with.  :-))

Good call.  It's easy to miss an email in a big thread like this.  Thank
you for noticing it and replying.  In the future, I'll send bugs/patches
to bug-guix/guix-patches to increase their visibility.

-- 
Chris

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

Release on April 18th?

[zimoun]

Hi,

I would like to propose to release on April 18th (anniversary of the
"Initial commit.").  It could be 1.2.1 or 1.3.  Well, from my
understanding, if core-updates is merged it makes sense to have 1.3
otherwise 1.2.1 seems reasonable.  WDYT?

I have kept an eye on the Bug Tracker and I am not seeing any blocker
but I could have missed something, especially on the core-updates
side.

Is it doable to have core-updates merged in the next weeks?  Or not at all.

About translators?  WDYT about this deadline?


Let me know what do you think.

All the best,
simon

Re: Release on April 18th?

[Julien Lepiller]

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

On the translation side of things, we now have an almost rolling-release model, so deadline is fine. We need to figure out a date for a string freeze if we want to have good coverage for the release. Maybe a week before ?

For the date, I'd like to make sure we have some time to clean the aftermaths of the core-updates merge, so maybe two or three weeks after it would be good. If we do not merge core-updates yet, then we can release earlier than that.

Le 2 mars 2021 09:51:33 GMT-05:00, zimoun <zimon.toutoune@gmail.com> a écrit :
>Hi,
>
>I would like to propose to release on April 18th (anniversary of the
>"Initial commit.").  It could be 1.2.1 or 1.3.  Well, from my
>understanding, if core-updates is merged it makes sense to have 1.3
>otherwise 1.2.1 seems reasonable.  WDYT?
>
>I have kept an eye on the Bug Tracker and I am not seeing any blocker
>but I could have missed something, especially on the core-updates
>side.
>
>Is it doable to have core-updates merged in the next weeks?  Or not at
>all.
>
>About translators?  WDYT about this deadline?
>
>
>Let me know what do you think.
>
>All the best,
>simon

[-- Attachment #2: Type: text/html, Size: 1424 bytes --]

Re: Release on April 18th?

[Leo Famulari]

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

On Tue, Mar 02, 2021 at 03:51:33PM +0100, zimoun wrote:
> I would like to propose to release on April 18th (anniversary of the
> "Initial commit.").  It could be 1.2.1 or 1.3.  Well, from my
> understanding, if core-updates is merged it makes sense to have 1.3
> otherwise 1.2.1 seems reasonable.  WDYT?
> 
> I have kept an eye on the Bug Tracker and I am not seeing any blocker
> but I could have missed something, especially on the core-updates
> side.
> 
> Is it doable to have core-updates merged in the next weeks?  Or not at all.

I think that timeline is too short for core-updates, although it depends
on how many people choose to monitor the building and fix problems.

Regarding the bug tracker, I don't think we've begun identifying
core-updates bugs yet.

Besides the "nuts and bolts" of building packages, we also need to make
some decisions about architectural support before releasing. Do we
suspend the armhf port? 

I do think it's possible to release on April 18th, but not with
core-updates. We could do "ungrafting" and a handful of staging-esque
updates, like tzdata.

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

Re: Release on April 18th?

[Andreas Enge]

Hello,

Am Tue, Mar 02, 2021 at 03:03:50PM -0500 schrieb Leo Famulari:
> I think that timeline is too short for core-updates, although it depends
> on how many people choose to monitor the building and fix problems.
> Regarding the bug tracker, I don't think we've begun identifying
> core-updates bugs yet.

it would be nice if core-updates could be part of the release. I have
been waiting for gmp, mpfr and mpc to appear in master. In particular
mpfr-4.1.0 has been released in July 2020, and I have updated it in
core-updates in the same month. Even with a release in April, that makes
9 months! Otherwise, we would end very far off the 6 months suggested in
doc/contributing.texi.

If I read the git history correctly, we have merged core-updates for the
last time in May 2020. Shocking numbers. Hopefully the recent progress
in continuous integration will help us reach our goal of more frequent
merging again.

Andreas

Re: Release on April 18th?

[Leo Famulari]

On Fri, Mar 05, 2021 at 03:31:22PM +0100, Andreas Enge wrote:
> it would be nice if core-updates could be part of the release. I have
> been waiting for gmp, mpfr and mpc to appear in master. In particular
> mpfr-4.1.0 has been released in July 2020, and I have updated it in
> core-updates in the same month. Even with a release in April, that makes
> 9 months! Otherwise, we would end very far off the 6 months suggested in
> doc/contributing.texi.
> 
> If I read the git history correctly, we have merged core-updates for the
> last time in May 2020. Shocking numbers. Hopefully the recent progress
> in continuous integration will help us reach our goal of more frequent
> merging again.

I agree, it's a long time without core-updates. Guix could complete
core-updates in time for April 18, at least for x86_64, if many people
work on it.

Simon, is there a reason you chose April 18 for the release? Or could we
choose a later date?

Re: Release on April 18th?

[zimoun]

Hi,

On Fri, 05 Mar 2021 at 14:27, Leo Famulari <leo@famulari.name> wrote:
> On Fri, Mar 05, 2021 at 03:31:22PM +0100, Andreas Enge wrote:

>> it would be nice if core-updates could be part of the release. I have
>> been waiting for gmp, mpfr and mpc to appear in master. In particular
>> mpfr-4.1.0 has been released in July 2020, and I have updated it in
>> core-updates in the same month. Even with a release in April, that makes
>> 9 months! Otherwise, we would end very far off the 6 months suggested in
>> doc/contributing.texi.
>> 
>> If I read the git history correctly, we have merged core-updates for the
>> last time in May 2020. Shocking numbers. Hopefully the recent progress
>> in continuous integration will help us reach our goal of more frequent
>> merging again.
>
> I agree, it's a long time without core-updates. Guix could complete
> core-updates in time for April 18, at least for x86_64, if many people
> work on it.

On #guix, I proposed [1] without an answer (yet :-)):

        what is the current blocking for merging core-updates? I mean
        the last merge seems from May 2020. If all the branch is not in
        a state to be mergeable, maybe we could simply merge a part of
        it. WDYT?

1: <http://logs.guix.gnu.org/guix/2021-03-05.log#194536>


> Simon, is there a reason you chose April 18 for the release? Or could we
> choose a later date?

Because a) it is ~6 months later than previous one and I think releasing
twice a year is the process we should adopt, b) it is an anniversary
(first commit) and by chance the other anniversary (first public
announce on Nov. 23rd) is spaced by ~6 month.

However, I think it is a bad idea to postpone and wait for core-updates
merge.  We should fix deadlines for releasing everything ~6 months and
simply make it happen.  IMHO.

In my views, since Guix is a rolling release, adding tags is more about
public announcement than “features“, i.e., attract users and communicate
about the new stuff.  Therefore, merging core-updates before a release
could be cool because it increases the list of new stuff but this merge
is not mandatory.  Once the user is in, ’guix pull’ provides what is in
core-updates whenever the merge is.  And what is in core-updates will be
advertised at the next release (~6 months later).

(Releasing every ~3 months should be even better but we do not have the
task force to make it.)


That’s said, when could core-update be merged to master?  What could be
the deadline?  From my point of view, delaying a couple (meaning 2 or 3
here ;-)) of weeks from April 18th sounds fine with me.

Even, from my understanding, we should minor release ASAP, e.g., on
April 18th or even before if possible.  And we could also plan to
release (major or minor) after the core-updates merge (say in June).
Then on Nov. 23rd, I think it could be nice to have another release.
Well, since Guix is rolling-release, releasing should be smooth.


BTW, I sympathize with the frustration about core-updates not merged
since last May.  On the other hand, I did nothing to help in the merging
process. :-(  Maybe, we could organize a hackathon or synchronize a
core-updates week: freeze the branch and address issues.  WDYT?

Cheers,
simon

Re: Release on April 18th?

[Leo Famulari]

On Fri, Mar 05, 2021 at 09:20:10PM +0100, zimoun wrote:
> On #guix, I proposed [1] without an answer (yet :-)):
> 
>         what is the current blocking for merging core-updates? I mean
>         the last merge seems from May 2020. If all the branch is not in
>         a state to be mergeable, maybe we could simply merge a part of
>         it. WDYT?
> 
> 1: <http://logs.guix.gnu.org/guix/2021-03-05.log#194536>

Anything is possible, but I think that determining which parts are ready
to merge will be just as much work as completing the entire branch.
Unless people have been maintaining private branches with specific
updates cherry-picked and can vouch that they are working well.

> On Fri, 05 Mar 2021 at 14:27, Leo Famulari <leo@famulari.name> wrote:
> > Simon, is there a reason you chose April 18 for the release? Or could we
> > choose a later date?
> 
> Because a) it is ~6 months later than previous one and I think releasing
> twice a year is the process we should adopt, b) it is an anniversary
> (first commit) and by chance the other anniversary (first public
> announce on Nov. 23rd) is spaced by ~6 month.

Agreed.

> However, I think it is a bad idea to postpone and wait for core-updates
> merge.  We should fix deadlines for releasing everything ~6 months and
> simply make it happen.  IMHO.

Agreed. But I don't think we can force core-updates, or we will regret
it when problems slip through. It's better to release on schedule
without core-updates.

> That’s said, when could core-update be merged to master?  What could be
> the deadline?  From my point of view, delaying a couple (meaning 2 or 3
> here ;-)) of weeks from April 18th sounds fine with me.
> 
> Even, from my understanding, we should minor release ASAP, e.g., on
> April 18th or even before if possible.  And we could also plan to
> release (major or minor) after the core-updates merge (say in June).
> Then on Nov. 23rd, I think it could be nice to have another release.
> Well, since Guix is rolling-release, releasing should be smooth.
> 
> BTW, I sympathize with the frustration about core-updates not merged
> since last May.  On the other hand, I did nothing to help in the merging
> process. :-(  Maybe, we could organize a hackathon or synchronize a
> core-updates week: freeze the branch and address issues.  WDYT?

So, based on the status of ci.guix.gnu.org, I feel that we could not have
begun working on core-updates before January 2021. And then, in January,
staging was in progress.

Now, ci.guix.gnu.org is working well, and we can work more quickly and
confidently. However, my experience in the past tells me that 6 weeks is
not quite long enough to complete the branch and validate it for a
release. But, it really depends on how many people can help.

Re: Release on April 18th?

[zimoun]

Hi Leo,

On Fri, 05 Mar 2021 at 15:58, Leo Famulari <leo@famulari.name> wrote:

> Now, ci.guix.gnu.org is working well, and we can work more quickly and
> confidently. However, my experience in the past tells me that 6 weeks is
> not quite long enough to complete the branch and validate it for a
> release. But, it really depends on how many people can help.

As you did with ungrafting and staging, maybe it is worth to have
someone keeping an eye on it and punctually reporting.  For example,
personally I almost never pull core-updates (or staging) but when a
report pops up on guix-devel, I pay attention and give a look.

Cheers,
simon

Re: Release on April 18th?

[Tobias Geerinckx-Rice]

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

Leo Famulari 写道：
> Agreed. But I don't think we can force core-updates, or we will 
> regret
> it when problems slip through. It's better to release on 
> schedule
> without core-updates.

I'll rebase my system on core-updates and report back (it can't be 
worse than master, where IceCat crashes about twice a day), but I 
think I agree with Leo on this.  I wish it were different but it's 
not.

Kind regards,

T G-R

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

Re: Release on April 18th?

[Ludovic Courtès]

Hi!

zimoun <zimon.toutoune@gmail.com> skribis:

> I would like to propose to release on April 18th (anniversary of the
> "Initial commit.").  It could be 1.2.1 or 1.3.  Well, from my
> understanding, if core-updates is merged it makes sense to have 1.3
> otherwise 1.2.1 seems reasonable.  WDYT?

I’m all for 1.2.1 ASAP, notably because of important bug fixes:

  https://issues.guix.gnu.org/46330
  https://issues.guix.gnu.org/44559

We’ve also accumulated a whole bunch of new features.

Thoughts?

Thanks,
Ludo’.

Re: Release on April 18th?

[Leo Famulari]

On Wed, Mar 03, 2021 at 03:16:29PM +0100, Ludovic Courtès wrote:
> I’m all for 1.2.1 ASAP, notably because of important bug fixes:
> 
>   https://issues.guix.gnu.org/46330
>   https://issues.guix.gnu.org/44559
> 
> We’ve also accumulated a whole bunch of new features.
> 
> Thoughts?

More TODOs that I think are possible in this timeframe:

* Fix #46871 (problems with init scripts and guix-install.sh).

* Update tzdata

* Ungraft

Re: Release on April 18th?

[zimoun]

Hi Leo,

On Wed, 03 Mar 2021 at 13:51, Leo Famulari <leo@famulari.name> wrote:

> * Fix #46871 (problems with init scripts and guix-install.sh).

I think it is (almost) done, see <http://issues.guix.gnu.org/issue/46871#1>.


> * Update tzdata

“guix refresh tzdata -l” provides couple of dependants.  Is it
reasonable to update it for the next release?


> * Ungraft

I am not following closely, sorry if I miss something.  The ’ungrafting’
branch had been merged to ’staging’ right?  And what is the state of
’staging’?

From my point of view, the whole “ungrafting” process is unclear on two
sides: 1. how to effectively ungraft a package?  i.e., what are the
typical steps? and 2. what is the list of packages to ungraft?

About the #1, there are some commits, for example
a210c0d13752c38a850746fd97948121046a0e58, which could help to understand
how to do.  But grepping in the Git log with ’graft’ returns only a
couple of examples.

About the #2, because the feedback loop with ci.guix is slow and because
most of the (unnecessary) grafted packages look like more annoyance than
really unusuable packages, and for me, because it is not clear where I
have to look: master, staging, core-updates or ungrafting, then all in
all laziness applies. :-) Personally, I am saying to myself: let
investigate tomorrow, and then other stuff happens this very tomorrow,
so I never investigate at the end.

Well, I propose to first collect a list about packages that “we” would
like «ungrafted» for the next release.  This makes a concrete criteria
to decide if it releasable or not yet; as “we” do for blocking bugs.
WDYT?


Cheers,
simon

Re: Release on April 18th?

[Leo Famulari]

On Thu, Mar 04, 2021 at 10:41:34AM +0100, zimoun wrote:
> On Wed, 03 Mar 2021 at 13:51, Leo Famulari <leo@famulari.name> wrote:
> > * Update tzdata
> 
> “guix refresh tzdata -l” provides couple of dependants.  Is it
> reasonable to update it for the next release?

For me, I see 1765 dependents (a "couple" is 2). We have the capacity to
rebuild them in this timeframe.

> > * Ungraft
> 
> I am not following closely, sorry if I miss something.  The ’ungrafting’
> branch had been merged to ’staging’ right?  And what is the state of
> ’staging’?

The staging branch has been completed, along with the previous
ungrafting. But now there are new grafts and, in my opinion, we don't
have time to do another staging round before April 18.

I think it's important to release without any grafts because they do not
always work as expected. For example:

https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00292.html

> From my point of view, the whole “ungrafting” process is unclear on two
> sides: 1. how to effectively ungraft a package?  i.e., what are the
> typical steps? and 2. what is the list of packages to ungraft?

1) Move the changes of the replacement packages into the packages that
were being replaced. For example, we should move the patch
'python-2.7-CVE-2021-3177.patch' from the origin of python-2.7/fixed to
the origin of python-2.7.

2) Grep on the master branch in gnu/packages for '(replacement'. That
will show you every graft.

Does that make sense?

Re: Release on April 18th?

[zimoun]

Hi Leo,

On Thu, 04 Mar 2021 at 14:07, Leo Famulari <leo@famulari.name> wrote:
> On Thu, Mar 04, 2021 at 10:41:34AM +0100, zimoun wrote:
>> On Wed, 03 Mar 2021 at 13:51, Leo Famulari <leo@famulari.name> wrote:
>> > * Update tzdata
>> 
>> “guix refresh tzdata -l” provides couple of dependants.  Is it
>> reasonable to update it for the next release?
>
> For me, I see 1765 dependents (a "couple" is 2). We have the capacity to
> rebuild them in this timeframe.

I should have had emphasized «couple». ;-)
Ah, I miss something because I thought this kind of upgrade was a
candidate for core-updates or staging.
Anyway. :-)

Added to the TODO. :-)


> The staging branch has been completed, along with the previous
> ungrafting. But now there are new grafts and, in my opinion, we don't
> have time to do another staging round before April 18.

Ungrafting as an instance of «Sisyphus stone». ;-)


>> From my point of view, the whole “ungrafting” process is unclear on two
>> sides: 1. how to effectively ungraft a package?  i.e., what are the
>> typical steps? and 2. what is the list of packages to ungraft?
>
> 1) Move the changes of the replacement packages into the packages that
> were being replaced. For example, we should move the patch
> 'python-2.7-CVE-2021-3177.patch' from the origin of python-2.7/fixed to
> the origin of python-2.7.
>
> 2) Grep on the master branch in gnu/packages for '(replacement'. That
> will show you every graft.

Thanks for the explanations.  I will try to contribute to the effort in
the next days.

Does it exist a way to list the grafts?  I mean there is “guix build
--no-grafts” but I do not know how to get what grafts which will be
applied beforehand.


Cheers,
simon

Re: Release on April 18th?

[Leo Famulari]

On Thu, Mar 04, 2021 at 11:18:19PM +0100, zimoun wrote:
> I should have had emphasized «couple». ;-)
> Ah, I miss something because I thought this kind of upgrade was a
> candidate for core-updates or staging.
> Anyway. :-)

It is usually is, but we can be confident that it won't break anything,
based on past experience updating tzdata.

> Thanks for the explanations.  I will try to contribute to the effort in
> the next days.

We should have a branch where we do these changes.

> Does it exist a way to list the grafts?  I mean there is “guix build
> --no-grafts” but I do not know how to get what grafts which will be
> applied beforehand.

Not that I know of. I always use `git grep`.

Re: Release on April 18th?

[Leo Famulari]

On Wed, Mar 03, 2021 at 01:51:51PM -0500, Leo Famulari wrote:
> * Update tzdata
> 
> * Ungraft

I've pushed commits that accomplish these tasks to a 'wip-next-release'
branch:

https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-next-release

For now, the branch is a "work in progress" (WIP) and thus can be
rebased, pending your feedback and consensus on a concrete plan for the
release.

Re: Release on April 18th?

[zimoun]

Hi Leo,

On Fri, 05 Mar 2021 at 15:19, Leo Famulari <leo@famulari.name> wrote:
> On Wed, Mar 03, 2021 at 01:51:51PM -0500, Leo Famulari wrote:
>> * Update tzdata
>> 
>> * Ungraft
>
> I've pushed commits that accomplish these tasks to a 'wip-next-release'
> branch:

Cool!

> https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-next-release
>
> For now, the branch is a "work in progress" (WIP) and thus can be
> rebased, pending your feedback and consensus on a concrete plan for the
> release.

Does this branch is built by CI?


Cheers,
simon

Re: Release on April 18th?

[Leo Famulari]

On Sat, Mar 06, 2021 at 12:58:52AM +0100, zimoun wrote:
> Hi Leo,
> 
> On Fri, 05 Mar 2021 at 15:19, Leo Famulari <leo@famulari.name> wrote:
> > On Wed, Mar 03, 2021 at 01:51:51PM -0500, Leo Famulari wrote:
> >> * Update tzdata
> >> 
> >> * Ungraft
> >
> > I've pushed commits that accomplish these tasks to a 'wip-next-release'
> > branch:
> 
> Cool!
> 
> > https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-next-release
> >
> > For now, the branch is a "work in progress" (WIP) and thus can be
> > rebased, pending your feedback and consensus on a concrete plan for the
> > release.
> 
> Does this branch is built by CI?

No, not yet. Is it something we want to do?

I feel like I am monopolizing this discussion a bit. Does anyone else
have anything they want to see in the next release? Any ideas about how
to get there?

Re: Release on April 18th?

[Leo Famulari]

On Wed, Mar 03, 2021 at 01:51:51PM -0500, Leo Famulari wrote:
> More TODOs that I think are possible in this timeframe:
> 
> * Fix #46871 (problems with init scripts and guix-install.sh).
> 
> * Update tzdata
> 
> * Ungraft

I remembered that we also have a few packages that we aim to remove
sooner or later:

OpenSSL 1.0 <https://bugs.gnu.org/46602>

Qt 4 <https://bugs.gnu.org/45704>

Not to mention Python 2
<https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00696.html>

Of these, I think we could remove Qt 4 for the next release. It's only
used by a few packages. OpenSSL 1.0 and Python 2 could be removed in a
subsequent release, perhaps.

Re: Release on April 18th?

[Leo Famulari]

On Sat, Mar 06, 2021 at 02:06:44PM -0500, Leo Famulari wrote:
> I remembered that we also have a few packages that we aim to remove
> sooner or later:
> 
> Qt 4 <https://bugs.gnu.org/45704>

I pushed a commit to wip-next-release that removes Qt 4 and all its
users.

Unfortunately, a package was added recently that depends on Qt 4
(telegram-desktop). Hopefully its dependency graph can be updated to use
Qt 5.

Re: Release on April 18th?

[Raghav Gururajan]

[-- Attachment #1.1: Type: text/plain, Size: 330 bytes --]

Hi Leo!

> Unfortunately, a package was added recently that depends on Qt 4
> (telegram-desktop). Hopefully its dependency graph can be updated to use
> Qt 5.

IIRC, telegram-desktop uses Qt5.

Was it any of its dependencies? If so how can I narrow-it down using 
`guix graph`? I'll try to update it.

Regards,
RG.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Release on April 18th?

[Raghav Gururajan]

[-- Attachment #1.1.1: Type: text/plain, Size: 428 bytes --]

Hi Leo!

>> Unfortunately, a package was added recently that depends on Qt 4
>> (telegram-desktop). Hopefully its dependency graph can be updated to use
>> Qt 5.
> 
> IIRC, telegram-desktop uses Qt5.
> 
> Was it any of its dependencies? If so how can I narrow-it down using 
> `guix graph`? I'll try to update it.

Just saw your message in IRC. For nimf, can you merge attached patches 
to master?

Regards,
RG.

[-- Attachment #1.1.2: 0001-gnu-nimf-Use-separate-outputs-for-gtk-and-qt-modules.patch --]
[-- Type: text/x-patch, Size: 2213 bytes --]

From c544f794b41d5120d1749cc864a5175abddab052 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan <rg@raghavgururajan.name>
Date: Sat, 6 Mar 2021 23:50:37 -0500
Subject: [PATCH 1/2] gnu: nimf: Use separate outputs for gtk and qt modules.

* gnu/packages/language.scm (nimf) [outputs]: Add gtk and qt.
[arguments]<#:phases>['patch-paths]: Modify.
---
 gnu/packages/language.scm | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/language.scm b/gnu/packages/language.scm
index 651b2305c9..db7b9d7f33 100644
--- a/gnu/packages/language.scm
+++ b/gnu/packages/language.scm
@@ -85,7 +85,7 @@
        (sha256
         (base32 "01qi7flmaqrn2fk03sa42r0caks9d8lsv88s0bgxahhxwk1x76gc"))))
     (build-system glib-or-gtk-build-system)
-    (outputs '("out" "doc"))
+    (outputs '("out" "gtk" "qt" "doc"))
     (arguments
      `(#:imported-modules
        (,@%glib-or-gtk-build-system-modules
@@ -134,18 +134,18 @@
                                "/bin:$GTK2_LIBDIR/libgtk2.0-0")))
              (substitute* "modules/clients/gtk/Makefile.am"
                (("\\$\\(GTK3_LIBDIR\\)")
-                (string-append (assoc-ref outputs "out")
+                (string-append (assoc-ref outputs "gtk")
                                "/lib"))
                (("\\$\\(GTK2_LIBDIR\\)")
-                (string-append (assoc-ref outputs "out")
+                (string-append (assoc-ref outputs "gtk")
                                "/lib")))
              (substitute* "modules/clients/qt4/Makefile.am"
                (("\\$\\(QT4_LIB_DIR\\)")
-                (string-append (assoc-ref outputs "out")
+                (string-append (assoc-ref outputs "qt")
                                "/lib")))
              (substitute* "modules/clients/qt5/Makefile.am"
                (("\\$\\(QT5_IM_MODULE_DIR\\)")
-                (string-append (assoc-ref outputs "out")
+                (string-append (assoc-ref outputs "qt")
                                "/lib/qt5/plugins/inputmethods")))
              (substitute* '("bin/nimf-settings/Makefile.am"
                             "data/apparmor-abstractions/Makefile.am"
-- 
2.30.1


[-- Attachment #1.1.3: 0002-gnu-nimf-Disable-qt4-support.patch --]
[-- Type: text/x-patch, Size: 2027 bytes --]

From 93fda7fa66b7c6697a428ab628872fc86b9b09e1 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan <rg@raghavgururajan.name>
Date: Sun, 7 Mar 2021 00:30:36 -0500
Subject: [PATCH 2/2] gnu: nimf: Disable qt4 support.

* gnu/packages/language.scm (nimf) [arguments]: Add new phase 'disable-qt4
and modify phase 'patch-paths.
[inputs]: Remove qt4.
---
 gnu/packages/language.scm | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/language.scm b/gnu/packages/language.scm
index db7b9d7f33..be1c5d4191 100644
--- a/gnu/packages/language.scm
+++ b/gnu/packages/language.scm
@@ -105,7 +105,15 @@
                        "/share/gtk-doc/html"))
        #:phases
        (modify-phases %standard-phases
-         (add-after 'unpack 'patch-flags
+         (add-after 'unpack 'disable-qt4
+           (lambda _
+             (substitute* '("configure.ac" "modules/clients/Makefile.am")
+               (("\\[QtGui\\]")
+                "[Qt5Gui]")
+               ((" qt4")
+                ""))
+             #t))
+         (add-after 'disable-qt4 'patch-flags
            (lambda* (#:key inputs #:allow-other-keys)
              (substitute* "configure.ac"
                (("-Werror")
@@ -139,10 +147,6 @@
                (("\\$\\(GTK2_LIBDIR\\)")
                 (string-append (assoc-ref outputs "gtk")
                                "/lib")))
-             (substitute* "modules/clients/qt4/Makefile.am"
-               (("\\$\\(QT4_LIB_DIR\\)")
-                (string-append (assoc-ref outputs "qt")
-                               "/lib")))
              (substitute* "modules/clients/qt5/Makefile.am"
                (("\\$\\(QT5_IM_MODULE_DIR\\)")
                 (string-append (assoc-ref outputs "qt")
@@ -182,7 +186,6 @@
        ("hangul" ,libhangul)
        ("m17n-db" ,m17n-db)
        ("m17n-lib" ,m17n-lib)
-       ("qt-4" ,qt-4)
        ("qtbase" ,qtbase)
        ("rime" ,librime)
        ("rsvg" ,librsvg)
-- 
2.30.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Release on April 18th?

[Leo Famulari]

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

On Sun, Mar 07, 2021 at 12:39:04AM -0500, Raghav Gururajan wrote:
> Hi Leo!
> 
> > > Unfortunately, a package was added recently that depends on Qt 4
> > > (telegram-desktop). Hopefully its dependency graph can be updated to use
> > > Qt 5.
> > 
> > IIRC, telegram-desktop uses Qt5.
> > 
> > Was it any of its dependencies? If so how can I narrow-it down using
> > `guix graph`? I'll try to update it.

I'm sorry I was unclear!

> Just saw your message in IRC. For nimf, can you merge attached patches to
> master?

Yes, will do ASAP! Thank you very much for your quick reply.

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

Re: Release on April 18th?

[Raghav Gururajan]

[-- Attachment #1.1: Type: text/plain, Size: 155 bytes --]

Hi Leo!

> I'm sorry I was unclear!

No worries!

> Yes, will do ASAP! Thank you very much for your quick reply.

My pleasure!

Regards,
RG.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Release on April 18th?

[Leo Famulari]

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

On Sun, Mar 07, 2021 at 12:39:04AM -0500, Raghav Gururajan wrote:
> Hi Leo!
> 
> > > Unfortunately, a package was added recently that depends on Qt 4
> > > (telegram-desktop). Hopefully its dependency graph can be updated to use
> > > Qt 5.
> > 
> > IIRC, telegram-desktop uses Qt5.
> > 
> > Was it any of its dependencies? If so how can I narrow-it down using
> > `guix graph`? I'll try to update it.
> 
> Just saw your message in IRC. For nimf, can you merge attached patches to
> master?

And, pushed to master as 76c32fcab4e476181fffba2710166b6ac060290c

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

Re: Release on April 18th?

[zimoun]

Hi,

On Sat, 06 Mar 2021 at 14:06, Leo Famulari <leo@famulari.name> wrote:

> OpenSSL 1.0 <https://bugs.gnu.org/46602>

I commented:

        Therefore, a good start seems to try to build all the 16
        packages depending on openssl <at> 1.0 with openssl <at> 1.1.
        And mark them with a comment if they fail.  But I guess that
        openssl <at> 1.0 is a strong requirement for these 16 packages.

and tried for a couple of these 16 and they failed to build.  And since:

--8<---------------cut here---------------start------------->8---
$ guix refresh -l openssl@1.0
Building the following 2277 packages would ensure 2400 dependent
packages are rebuilt
--8<---------------cut here---------------end--------------->8---

which is worse than on Feb. 25th, 2021 («1930 packages would ensure 2048
dependent»), I guess we are not taking the good path to remove it soon.
Sadly.


> Qt 4 <https://bugs.gnu.org/45704>

I have never looked into this.  If you think it is possible to remove
it, let’s dot it. :-)


> Not to mention Python 2
> <https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00696.html>

The follow-up of this message from 2019 is:

<https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00376.html>

and Maxim provided the “process” (if that can be named a “process” :-))
as a reply here:

<https://lists.gnu.org/archive/html/guix-devel/2021-01/msg00391.html>


BTW, the package Python 3 python-enum34 is broken since maybe ever

<https://data.guix.gnu.org/repository/1/branch/master/package/python-enum34/output-history>

and only used for the Python 2 variant python2-enum34, which cannot be
removed yet (198 packages would ensure 386 dependent packages).


Cheers,
simon

Re: Release on April 18th?

[Leo Famulari]

On Wed, Mar 03, 2021 at 03:16:29PM +0100, Ludovic Courtès wrote:
> zimoun <zimon.toutoune@gmail.com> skribis:
> 
> > I would like to propose to release on April 18th (anniversary of the
> > "Initial commit.").  It could be 1.2.1 or 1.3.  Well, from my
> > understanding, if core-updates is merged it makes sense to have 1.3
> > otherwise 1.2.1 seems reasonable.  WDYT?
> 
> I’m all for 1.2.1 ASAP, notably because of important bug fixes:
> 
>   https://issues.guix.gnu.org/46330
>   https://issues.guix.gnu.org/44559
> 
> We’ve also accumulated a whole bunch of new features.
> 
> Thoughts?

We should also make sure to fix or avoid #46829, (Fresh install of 1.2.0
can't guix pull):

https://bugs.gnu.org/46829

Re: Release on April 18th?

[Chris Marusich]

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

Hi,

zimoun <zimon.toutoune@gmail.com> writes:

> Is it doable to have core-updates merged in the next weeks?  Or not at
> all.

Do we plan to upgrade GCC?  This is required for the powerpc64le-linux
port; see below for details.

The wip-ppc64le branch, which ports Guix to an architecture that can be
run on freedom-friendly POWER9 systems like the Talos II and Blackbird
from Raptor Computing Systems, is "almost" done, and I would really like
to try to get it into the next release if possible.

However, there is still some work to do, and I wouldn't necessarily want
to block the release just for sake of the powerpc64le-linux port.

In fact, the wip-ppc64le branch was "fully functional" for a little
while.  By "fully functional," I mean that "make check" succeeded, "make
guix-binary.powerpc64le-linux.tar.xz" succeeded, the resulting binary
could be installed on a fresh Debian ppc64le system, the binary could
successfully build and run GNU Hello, and the binary could successfully
run "guix pull", and the newly installed "guix pull" could do the same.

However, that was using glibc 2.31.  On core-updates, glibc has been
updated to 2.32, which unfortunately breaks wip-ppc64le.  To fix it, we
must upgrade GCC from 7 to 8 (or greater), and that is what we have done
on the wip-ppc64le branch (upgrade GCC to 8).  Currently, we are working
through build failures that occurred as a result, but I'm optimistic that
we can resolve those in the coming weeks.

The real question, I think, is when do we plan to upgrade GCC on
core-updates?  It's still on GCC 7.5.0.  The powerpc64le-linux port will
require GCC 8 or greater, since core-updates is now using glibc 2.32.

-- 
Chris

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

Re: Release on April 18th?

[Vincent Legoll]

Hello Chris,

I'm all for that, what can I do to help ?

I don't have a Talos, though...

So only cross- or emulated- stuff...

Willing to help, but needs directions.

-- 
Vincent Legoll

Re: Release on April 18th? (ppc64le support specifically)

[Efraim Flashner]

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

On Tue, Mar 09, 2021 at 10:32:18PM +0100, Vincent Legoll wrote:
> Hello Chris,
> 
> I'm all for that, what can I do to help ?
> 
> I don't have a Talos, though...
> 
> So only cross- or emulated- stuff...
> 
> Willing to help, but needs directions.
> 

The two ways forward that I can see is to figure out how to merge
wip-ppc64le into master without it affecting any of the other
architectures. This would generally be through some fancy ifs and whens
to only affect powerpc64le and would get the architecture supported
earlier.

For example, some of the patches touch gcc and libstdc++. If 'guix build
gcc-toolchain -d' and 'guix build gcc-toolchain -d
--system=powerpc64le-linux' are unchanged then you've successfully
combined the two.

The other option is to try to build and fix packages for other
architectures (notably x86_64 as a start) using the wip-ppc64le branch,
with the assumption that for the most part the same packages would be
broken by an update of gcc to gcc-8.

The first option has the potential to get powerpc64le merged before the
release, the second is going to be necessary in any event.

-- 
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: Release on April 18th?

[Chris Marusich]

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

Vincent Legoll <vincent.legoll@gmail.com> writes:

> I'm all for that, what can I do to help ?

Thank you for offering to help!

> I don't have a Talos, though...
>
> So only cross- or emulated- stuff...
>
> Willing to help, but needs directions.

I can probably also set you up with a temporary multi-core VM for
testing, too.  I'll see if I can set something like that up for you in
the next few days.

In addition to the ways you can help as Efraim mentioned elsewhere, on
my Debian ppc64le system, where I have manually built the wip-ppc64le
branch, I have observed a valgrind build failure when attempting to
build guix (e.g., when running "make
guix-binary.powerpc64le-linux.tar.xz").  I haven't had time to
investigate it more deeply, so that's one thing you could look into.

However, I have also noticed that after rebasing wip-ppc64le today onto
core-updates, there is a new test failure when "make check" runs.  The
tests/syscalls.scm test fails; it did not fail before the rebase, so
something on core-updates must have changed that broke it...  You could
investigate this, too, if you had a machine.

Basically, if you have a machine, you can fetch wip-ppc64le and try to
build it (./bootstrap && ./configure --localstatedir=/var && make -j &&
make check), and report/investigate the errors.  Feel free to send bugs
to bug-guix@gnu.org mentioning the commit and the reproduction steps, so
we can talk in a new bug report about any details.  That would be the
quite helpful, I think!

And yes, as Efraim mentioned, even without hardware, you could try
building your favorite packages on x86_64-linux (or whatever system you
are currently using) on the wip-ppc64le branch and report when there are
problems.  We don't want to break anything for the other system types,
but you never know what will happen.  This sort of testing might uncover
problems on core-updates, too, since wip-ppc64le is currently based off
of core-updates.

Anyway, I'll email you privately about VM access later.

-- 
Chris

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

Re: Release on April 18th?

[Vincent Legoll]

Hello,

I rebuilt guix on core-updates with gcc-8 succesfully
I'll now try the same above wip-ppc64le.

-- 
Vincent Legoll

Re: Release on April 18th?

[Chris Marusich]

[-- Attachment #1.1: Type: text/plain, Size: 1802 bytes --]

Hi,

Vincent Legoll <vincent.legoll@gmail.com> writes:

> I rebuilt guix on core-updates with gcc-8 succesfully
> I'll now try the same above wip-ppc64le.

Awesome!  Thank you for doing this.  I'm sure there will be some bumps,
and the sooner we can fix them, the easier it will be to integrate
later.

I'm still working on getting you access to ppc64le hardware or a VM.

Andreas Enge <andreas@enge.fr> writes:

> Am Fri, Mar 12, 2021 at 12:33:18AM -0800 schrieb Chris Marusich:
>> The proc man page has this to say about column 7:
>>   (7) optional fields: zero or more fields of the form "tag[:value]"
>
> And it goes on like this:
> (8)  separator: the end of the optional fields is marked
>                    by a single hyphen.
>
> So it looks like it is enough to search for a hyphen surrounded by spaces.
> The hyphen is apparently there also when there is no optional field (7),
> as can be seen from your examples and also my own system, where both occur
> in parallel:
> 34 26 253:0 /gnu/store /gnu/store ro,noatime - ext4 /dev/mapper/cryptroot rw
> 51 26 253:0 /var/lib/docker /var/lib/docker rw,relatime shared:1 - ext4 /dev/mapper/cryptroot rw
>
> Alternatively, one can also count from the back to get the fields labelled
> (9) to (11) (which may be (8) to (10) in case there are no optional fields).
> (I was momentarily confused by "(12) super option*s*"; but these are
> apparently separated by commas and not whitespace.)

That's true.  How about the following patch?  It fixes the issue for me
on my systems, and I manually tried out the new match pattern with some
lines from Leo's output, and it seems to behave correctly.  If nobody
has concerns, I'd like to apply it to master directly, since the tests
are already failing there on some systems, like mine.  Here's the patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: [PATCH] syscalls: mount: Fix a matching bug. --]
[-- Type: text/x-patch, Size: 1966 bytes --]

From 5417f68ee5892f6a587895105854cadf29eb7297 Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Thu, 11 Mar 2021 23:19:30 -0800
Subject: [PATCH] syscalls: mount: Fix a matching bug.

On some systems, the columns in /proc/self/mountinfo look like this:

23 28 0:21 / /proc rw,nosuid,nodev,noexec,relatime shared:11 - proc proc rw

Before this change, the mount procedure was written with the assumption that
the type and source could always be found in columns 8 and 9, respectively.
However, the proc(5) man page explains that there can be zero or more optional
fields starting at column 7 (e.g., "shared:11" above), so this assumption is
false in some situations.

* guix/build/syscalls.scm (mount): Update the match pattern to use ellipsis to
match zero or more optional fields followed by a single hyphen.  Remove the
trailing ellipsis, since multiple ellipses are not allowed in the same level.
The proc(5) man page indicates that there are no additional columns, so it is
probably OK to match an exact number of columns at the end like this.
---
 guix/build/syscalls.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
index 552343a481d..726c8e86d06 100644
--- a/guix/build/syscalls.scm
+++ b/guix/build/syscalls.scm
@@ -621,8 +621,9 @@ current process."
           (if (eof-object? line)
               (reverse result)
               (match (string-tokenize line)
+                ;; See the proc(5) man page for a description of the columns.
                 ((id parent-id major:minor root mount-point
-                     options _ type source _ ...)
+                     options _ ... "-" type source _)
                  (let ((devno (string->device-number major:minor)))
                    (loop (cons (%mount (octal-decode source)
                                        (octal-decode mount-point)
-- 
2.26.2


[-- Attachment #1.3: Type: text/plain, Size: 1067 bytes --]


Efraim Flashner <efraim@flashner.co.il> writes:

>> Something about the way in which we are searching for the patch is off,
>> but I don't have time just now to investigate.  Efraim, if you can
>> figure it out, that'd be nice, but I'll look into it more tomorrow.
>> It's probably something simple and related to commit 2712703.
>
> Leo told me about it yesterday and I pushed a second commit that fixed
> it. We needed to make sure the patch file was included as an input,
> that's why it got #f instead of a string. In any case, commit
> 710cfc330a7ed06934a193583b159fbdf07bf2fe takes care of it; it's the
> combination of 2712703 and the squash commit.
>
> I'm now running make guix-binary.powerpc64le-linux.tar.xz and so far
> it's made it past the initial building stages, we're on to building the
> grafts now.

Thank you.  This fixed the patch-related problem for me, too.  I'm
currently running "make guix-binary.powerpc64le-linux.tar.xz", also, on
my Debian ppc64le machine.  We'll see how far it gets - fingers crossed!

-- 
Chris

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

Re: Release on April 18th?

[Chris Marusich]

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

Chris Marusich <cmmarusich@gmail.com> writes:

> Subject: [PATCH] syscalls: mount: Fix a matching bug.

In the patch message, "mount" should be "mounts".  Sorry for the typo!

-- 
Chris

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

Re: Release on April 18th?

[Vincent Legoll]

Hello Chris,

On Fri, Mar 12, 2021 at 7:42 PM Chris Marusich <cmmarusich@gmail.com> wrote:
> Vincent Legoll <vincent.legoll@gmail.com> writes:
> > I rebuilt guix on core-updates with gcc-8 succesfully
> > I'll now try the same above wip-ppc64le.
>
> Awesome!  Thank you for doing this.  I'm sure there will be some bumps,
> and the sooner we can fix them, the easier it will be to integrate
> later.

I did not `make check` on core-updates + gcc 8, will retry that later.

On wip-ppc64le, guix built OK, but am meeting `make check` failures:

============================================================================
Testsuite summary for GNU Guix 1.0.1.31332-e8b83e
============================================================================
# TOTAL: 1171
# PASS:  1153
# SKIP:  7
# XFAIL: 2
# FAIL:  9
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to bug-guix@gnu.org
============================================================================

I'm looking at those log files now...

> I'm still working on getting you access to ppc64le hardware or a VM.

I already send my public key to Tobias, so that is WIP.

Tchuss

-- 
Vincent Legoll

Re: Release on April 18th?

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> From 5417f68ee5892f6a587895105854cadf29eb7297 Mon Sep 17 00:00:00 2001
> From: Chris Marusich <cmmarusich@gmail.com>
> Date: Thu, 11 Mar 2021 23:19:30 -0800
> Subject: [PATCH] syscalls: mount: Fix a matching bug.
>
> On some systems, the columns in /proc/self/mountinfo look like this:
>
> 23 28 0:21 / /proc rw,nosuid,nodev,noexec,relatime shared:11 - proc proc rw
>
> Before this change, the mount procedure was written with the assumption that
> the type and source could always be found in columns 8 and 9, respectively.
> However, the proc(5) man page explains that there can be zero or more optional
> fields starting at column 7 (e.g., "shared:11" above), so this assumption is
> false in some situations.
>
> * guix/build/syscalls.scm (mount): Update the match pattern to use ellipsis to
> match zero or more optional fields followed by a single hyphen.  Remove the
> trailing ellipsis, since multiple ellipses are not allowed in the same level.
> The proc(5) man page indicates that there are no additional columns, so it is
> probably OK to match an exact number of columns at the end like this.
> ---
>  guix/build/syscalls.scm | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
> index 552343a481d..726c8e86d06 100644
> --- a/guix/build/syscalls.scm
> +++ b/guix/build/syscalls.scm
> @@ -621,8 +621,9 @@ current process."
>            (if (eof-object? line)
>                (reverse result)
>                (match (string-tokenize line)
> +                ;; See the proc(5) man page for a description of the columns.
>                  ((id parent-id major:minor root mount-point
> -                     options _ type source _ ...)
> +                     options _ ... "-" type source _)
>                   (let ((devno (string->device-number major:minor)))
>                     (loop (cons (%mount (octal-decode source)
>                                         (octal-decode mount-point)

It works on my laptop.  :-) If you’re confident, please push—thanks for
the fix!

(Next time please report the issue to bug-guix where it’s more likely to
be seen and dealt with.  :-))

Ludo’.

Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

[Chris Marusich]

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

Hi,

I have good news!

Chris Marusich <cmmarusich@gmail.com> writes:

> Subject: [PATCH] syscalls: mount: Fix a matching bug.

If there are no concerns about this patch, I will commit it to master
(with the "mount" typo fixed so it reads "mounts") in the next few days.

> Efraim Flashner <efraim@flashner.co.il> writes:
>
>> I'm now running make guix-binary.powerpc64le-linux.tar.xz and so far
>> it's made it past the initial building stages, we're on to building the
>> grafts now.
>
> Thank you.  This fixed the patch-related problem for me, too.  I'm
> currently running "make guix-binary.powerpc64le-linux.tar.xz", also, on
> my Debian ppc64le machine.  We'll see how far it gets - fingers crossed!

I'm happy to report that I was able to do all of the following things
successfully on the wip-ppc64le-for-master branch after (1) applying the
syscalls patch mentioned above, (2) running "make update-guix-package",
and (3) locally committing the updated guix package:

- On a bare metal Debian ppc64le machine, I ran "make
  guix-binary.powerpc64le-linux.tar.xz" successfully.

- I installed the resulting guix binary in a fresh Debian ppc64le VM
  successfully.

- In the VM, using the newly installed guix binary, I successfully ran
  "guix pull" to update Guix to the commit I made in (3) above.

- In the VM, using the newly pulled guix, I built GNU Hello and verified
  that it ran successfully.

This demonstrates that wip-ppc64le-for-master is working.  Therefore, we
should merge it to master and officially include powerpc64le-linux
support in the next Guix release!  Thank you, Efraim, for taking the
initiative to adapt some of the commits from wip-ppc64le so they could
be applied to master without rebuilding the world on other systems.

I've verified that the wip-ppc64le-for-master branch does not rebuild
the world.  I did this by verifying that the derivations for the "hello"
and "gcc-toolchain" packages were the same at the branch point as they
are at the tip of the branch (e.g.: ./pre-inst-env guix build -d hello).

As I see it, the next tasks for powerpc64le-linux in this release are:

- Do a final rebase of wip-ppc64le-for-master, then merge it to master.

- When the release happens, make a guix-binary.powerpc64le-linux.tar.xz
  available wherever binary releases are normally published.

- Start building powerpc64le-linux substitutes in the build farm,
  ideally on POWER9 hardware.

How shall we build the binary tarball for the release?  Of course,
anybody with a copy of the (source) release tarball can build their own
guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz"
themselves.  However, for convenience, it would be nice to provide a
pre-built binary if possible.  Shall I build this myself when the time
comes, or would people prefer to do it a different way?

-- 
Chris

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

Re: Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

[Efraim Flashner]

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

On Mon, Mar 15, 2021 at 09:03:04PM -0700, Chris Marusich wrote:
> 
> How shall we build the binary tarball for the release?  Of course,
> anybody with a copy of the (source) release tarball can build their own
> guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz"
> themselves.  However, for convenience, it would be nice to provide a
> pre-built binary if possible.  Shall I build this myself when the time
> comes, or would people prefer to do it a different way?
> 

When aarch64 support was very new I gave ludo access to my board and he
offloaded the build to it.


-- 
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: Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

[Léo Le Bouter]

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

On Tue, 2021-03-16 at 09:08 +0200, Efraim Flashner wrote:
> On Mon, Mar 15, 2021 at 09:03:04PM -0700, Chris Marusich wrote:
> > How shall we build the binary tarball for the release?  Of course,
> > anybody with a copy of the (source) release tarball can build their
> > own
> > guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz"
> > themselves.  However, for convenience, it would be nice to provide
> > a
> > pre-built binary if possible.  Shall I build this myself when the
> > time
> > comes, or would people prefer to do it a different way?
> > 
> 
> When aarch64 support was very new I gave ludo access to my board and
> he
> offloaded the build to it.
> 
> 

We have one ppc64le VM from OSUOSL which would qualify as "GNU Guix
owned" that nckx, myself, Efraim and Vincent Legoll have access to, so
we should definitely use that. We will be working into having that VM
added into Cuirass CI as soon as possible after merge into master too.

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

Re: Let's include powerpc64le-linux in the next release

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> How shall we build the binary tarball for the release?  Of course,
> anybody with a copy of the (source) release tarball can build their own
> guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz"
> themselves.  However, for convenience, it would be nice to provide a
> pre-built binary if possible.  Shall I build this myself when the time
> comes, or would people prefer to do it a different way?

Like Efraim wrote, the person who makes the release (I’m afraid it’ll be
me) needs to be able to offload to a “trustworthy” machine for that
platform.

If we can do that, we should adjust the ‘release’ target in
‘Makefile.am’ to do that.

However, since we won’t be providing substitutes, we should label it as
“technology preview” in the manual (info "(guix) GNU Distribution").

How does that sound?

Ludo’.

Re: Let's include powerpc64le-linux in the next release

[Léo Le Bouter]

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

On Tue, 2021-03-23 at 14:42 +0100, Ludovic Courtès wrote:
> Like Efraim wrote, the person who makes the release (I’m afraid it’ll
> be
> me) needs to be able to offload to a “trustworthy” machine for that
> platform.
> 
> If we can do that, we should adjust the ‘release’ target in
> ‘Makefile.am’ to do that.
> 
> However, since we won’t be providing substitutes, we should label it
> as
> “technology preview” in the manual (info "(guix) GNU Distribution").
> 
> How does that sound?
> 
> Ludo’.

Sounds good!

Ludo, what is your SSH public key so I can give you access to the
powerpc64le-linux machine nckx has gotten from OSUOSL?

Thank you!

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

Re: Let's include powerpc64le-linux in the next release

[Tobias Geerinckx-Rice]

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

Ludo',

Ludovic Courtès 写道：
> Like Efraim wrote, the person who makes the release (I’m afraid 
> it’ll be
> me) needs to be able to offload to a “trustworthy” machine for 
> that
> platform.

Define trustworthy?  The project has access to an 8-core POWER9 VM 
from OSUOSL, currently running Debian, to which efraim, lle-bout, 
vincele, and me have root access.

Kind regards,

T G-R

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

Re: Let's include powerpc64le-linux in the next release

[Ludovic Courtès]

Hi Tobias,

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

> Ludovic Courtès 写道：
>> Like Efraim wrote, the person who makes the release (I’m afraid
>> it’ll be
>> me) needs to be able to offload to a “trustworthy” machine for that
>> platform.
>
> Define trustworthy?

I put quotes because it’s informally defined, at best, and it’s not all
or nothing.

To me one criterion would be that only known project contributors are
admins, physical access to the machine is limited to them and/or a
well-identified group of people, and that no build results flow from the
outside into this machine.

I realize we’re not there yet, but it’s OK: we’re just getting started
with this architecture.  Plus, I’m really grateful to OSUOSL for giving
us access to this machine!

Ludo’.

Re: Let's include powerpc64le-linux in the next release

[Vincent Legoll]

Hello,

On Tue, Mar 30, 2021 at 10:24 AM Ludovic Courtès <ludo@gnu.org> wrote:
> Plus, I’m really grateful to OSUOSL for giving
> us access to this machine!

Yes, it's really nice to have access to those, and in the future, if
we want to really support the ppc64le with substitutes, we may
ask for a CI-class VM which should have better performance.

I've also asked for details of the openstack setup, and the virtual
disks provided to the VMs are networked ceph storage which is
quite slow, they are investigating the problem. I also asked if they
can try to provide hypervisor-local scratch storage (way faster but
not durable, and would make the VM non migratable) to the VMs and
they may be able to do so in the future.

Tchuss

--
Vincent Legoll

Re: Let's include powerpc64le-linux in the next release, Re: Let's include powerpc64le-linux in the next release

[Chris Marusich]

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

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Ludovic Courtès 写道：
>> Like Efraim wrote, the person who makes the release (I’m afraid
>> it’ll be
>> me) needs to be able to offload to a “trustworthy” machine for that
>> platform.
>
> Define trustworthy?  The project has access to an 8-core POWER9 VM
> from OSUOSL, currently running Debian, to which efraim, lle-bout, 
> vincele, and me have root access.

That would probably work.  My understanding is that because we cannot
install Guix from an existing release binary, somebody will need to
manually build Guix on that machine first, for offloading to work.

I can help with this.

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

> If we can do that, we should adjust the ‘release’ target in
> ‘Makefile.am’ to do that.
>
> However, since we won’t be providing substitutes, we should label it as
> “technology preview” in the manual (info "(guix) GNU Distribution").

OK!  I was planning to add some commits to update the docs, anyway.  I
can do those two tasks.

Additionally, I plan to finally merge wip-ppc64le-for-master to master
later today.  I'll send a note when that's done.

-- 
Chris

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

Re: Release on April 18th?

[zimoun]

Hi Chris,

On Tue, 09 Mar 2021 at 10:17, Chris Marusich <cmmarusich@gmail.com> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
>
>> Is it doable to have core-updates merged in the next weeks?  Or not at
>> all.
>
> Do we plan to upgrade GCC?  This is required for the powerpc64le-linux
> port; see below for details.

You mean replace gcc-7 by gcc-8 or greater, right?  It implies a
core-updates merge, right?


> The wip-ppc64le branch, which ports Guix to an architecture that can be
> run on freedom-friendly POWER9 systems like the Talos II and Blackbird
> from Raptor Computing Systems, is "almost" done, and I would really like
> to try to get it into the next release if possible.

Could be cool!

> However, there is still some work to do, and I wouldn't necessarily want
> to block the release just for sake of the powerpc64le-linux port.
>
> In fact, the wip-ppc64le branch was "fully functional" for a little
> while.  By "fully functional," I mean that "make check" succeeded, "make
> guix-binary.powerpc64le-linux.tar.xz" succeeded, the resulting binary
> could be installed on a fresh Debian ppc64le system, the binary could
> successfully build and run GNU Hello, and the binary could successfully
> run "guix pull", and the newly installed "guix pull" could do the same.
>
> However, that was using glibc 2.31.  On core-updates, glibc has been
> updated to 2.32, which unfortunately breaks wip-ppc64le.  To fix it, we
> must upgrade GCC from 7 to 8 (or greater), and that is what we have done
> on the wip-ppc64le branch (upgrade GCC to 8).  Currently, we are working
> through build failures that occurred as a result, but I'm optimistic that
> we can resolve those in the coming weeks.

Thanks for the explanations.


> The real question, I think, is when do we plan to upgrade GCC on
> core-updates?  It's still on GCC 7.5.0.  The powerpc64le-linux port will
> require GCC 8 or greater, since core-updates is now using glibc 2.32.

Does it make sense to merge wip-ppc64le and core-updates?


Cheers,
simon

Re: Release on April 18th?

[Efraim Flashner]

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

On Wed, Mar 10, 2021 at 02:27:47PM +0100, zimoun wrote:
> Hi Chris,
> 
> On Tue, 09 Mar 2021 at 10:17, Chris Marusich <cmmarusich@gmail.com> wrote:
> > zimoun <zimon.toutoune@gmail.com> writes:
> >
> >> Is it doable to have core-updates merged in the next weeks?  Or not at
> >> all.
> >
> > Do we plan to upgrade GCC?  This is required for the powerpc64le-linux
> > port; see below for details.
> 
> You mean replace gcc-7 by gcc-8 or greater, right?  It implies a
> core-updates merge, right?
> 
> 
> > The wip-ppc64le branch, which ports Guix to an architecture that can be
> > run on freedom-friendly POWER9 systems like the Talos II and Blackbird
> > from Raptor Computing Systems, is "almost" done, and I would really like
> > to try to get it into the next release if possible.
> 
> Could be cool!
> 
> > However, there is still some work to do, and I wouldn't necessarily want
> > to block the release just for sake of the powerpc64le-linux port.
> >
> > In fact, the wip-ppc64le branch was "fully functional" for a little
> > while.  By "fully functional," I mean that "make check" succeeded, "make
> > guix-binary.powerpc64le-linux.tar.xz" succeeded, the resulting binary
> > could be installed on a fresh Debian ppc64le system, the binary could
> > successfully build and run GNU Hello, and the binary could successfully
> > run "guix pull", and the newly installed "guix pull" could do the same.
> >
> > However, that was using glibc 2.31.  On core-updates, glibc has been
> > updated to 2.32, which unfortunately breaks wip-ppc64le.  To fix it, we
> > must upgrade GCC from 7 to 8 (or greater), and that is what we have done
> > on the wip-ppc64le branch (upgrade GCC to 8).  Currently, we are working
> > through build failures that occurred as a result, but I'm optimistic that
> > we can resolve those in the coming weeks.
> 
> Thanks for the explanations.
> 
> 
> > The real question, I think, is when do we plan to upgrade GCC on
> > core-updates?  It's still on GCC 7.5.0.  The powerpc64le-linux port will
> > require GCC 8 or greater, since core-updates is now using glibc 2.32.
> 
> Does it make sense to merge wip-ppc64le and core-updates?
> 

I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master,
which cherry-picked (I think) all of the powerpc64le commits and
adjusted them to work against master WITHOUT affecting other
architectures.

I don't know why I thought it was an easy win, but if it looks good to
everyone I don't see why we couldn't merge powerpc64le into master by
the end of the week.

-- 
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: Release on April 18th?

[zimoun]

Hi Efraim,

On Wed, 10 Mar 2021 at 17:30, Efraim Flashner <efraim@flashner.co.il> wrote:
 
>> Does it make sense to merge wip-ppc64le and core-updates?
>> 
> I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master,
> which cherry-picked (I think) all of the powerpc64le commits and
> adjusted them to work against master WITHOUT affecting other
> architectures.
>
> I don't know why I thought it was an easy win, but if it looks good to
> everyone I don't see why we couldn't merge powerpc64le into master by
> the end of the week.

So you confirm that cherry-picking from core-updates (as I suggested
here [1]) is a bad idea, i.e., not an Easy Win™.  Anyway.

IIUC, the remaining part is the GCC upgrade, right?


1: <<http://logs.guix.gnu.org/guix/2021-03-05.log#194536>

Re: Release on April 18th?

[Efraim Flashner]

On March 10, 2021 3:59:07 PM UTC, zimoun <zimon.toutoune@gmail.com> wrote:
>Hi Efraim,
>
>On Wed, 10 Mar 2021 at 17:30, Efraim Flashner <efraim@flashner.co.il>
>wrote:
> 
>>> Does it make sense to merge wip-ppc64le and core-updates?
>>> 
>> I wanted an Easy Win™ and I've pushed a branch
>wip-ppc64le-for-master,
>> which cherry-picked (I think) all of the powerpc64le commits and
>> adjusted them to work against master WITHOUT affecting other
>> architectures.
>>
>> I don't know why I thought it was an easy win, but if it looks good
>to
>> everyone I don't see why we couldn't merge powerpc64le into master by
>> the end of the week.
>
>So you confirm that cherry-picking from core-updates (as I suggested
>here [1]) is a bad idea, i.e., not an Easy Win™.  Anyway.
>
>IIUC, the remaining part is the GCC upgrade, right?
>
>
>1: <<http://logs.guix.gnu.org/guix/2021-03-05.log#194536>

My understanding was that the gcc upgrade was necessary for powerpc64le with the next version of glibc. I think what we need now is people with powerpc64le hardware to test the branch.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Release on April 18th?

[Chris Marusich]

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

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:

> I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master,
> which cherry-picked (I think) all of the powerpc64le commits and
> adjusted them to work against master WITHOUT affecting other
> architectures.

It looks like you modified "gnu: glibc: Fix ldd path on powerpc" and
"gnu: gcc-4.7: On powerpc64le, fix /lib64 references" to avoid changing
the package definitions on other architectures.  That might work out;
I'll try testing it on my hardware and report back.  Believe me, I'd be
happy to have powerpc64le-linux working on any branch.

However, the moment master and core-updates are integrated with one
another, glibc will be upgraded upgraded from 2.31 to 2.32, and it will
be necessary to upgrade GCC, also.  I don't think there's any way around
that.  If possible, I'd really prefer not to hide that big of a change
behind an "if powerpc64le-linux" statement, since I don't like the idea
of having to deal with unique failures on powerpc64le-linux that might
stem from using a different GCC version than the rest of Guix.  It is
good to be consistent with other architectures, when we can be.  Then we
can share the same problems and help fix them together.

-- 
Chris

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

Re: Release on April 18th?

[Efraim Flashner]

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

On Thu, Mar 11, 2021 at 12:58:50AM -0800, Chris Marusich wrote:
> Hi Efraim,
> 
> Efraim Flashner <efraim@flashner.co.il> writes:
> 
> > I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master,
> > which cherry-picked (I think) all of the powerpc64le commits and
> > adjusted them to work against master WITHOUT affecting other
> > architectures.
> 
> It looks like you modified "gnu: glibc: Fix ldd path on powerpc" and
> "gnu: gcc-4.7: On powerpc64le, fix /lib64 references" to avoid changing
> the package definitions on other architectures.  That might work out;
> I'll try testing it on my hardware and report back.  Believe me, I'd be
> happy to have powerpc64le-linux working on any branch.
> 
> However, the moment master and core-updates are integrated with one
> another, glibc will be upgraded upgraded from 2.31 to 2.32, and it will
> be necessary to upgrade GCC, also.  I don't think there's any way around
> that.  If possible, I'd really prefer not to hide that big of a change
> behind an "if powerpc64le-linux" statement, since I don't like the idea
> of having to deal with unique failures on powerpc64le-linux that might
> stem from using a different GCC version than the rest of Guix.  It is
> good to be consistent with other architectures, when we can be.  Then we
> can share the same problems and help fix them together.
> 

My plan was absolutely to merge master into core-updates after and then
integrate all the changes into their affected packages. I'd also make
sure to bump gcc to 8 (assuming we don't go straight to 9).


-- 
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: Release on April 18th?

[Chris Marusich]

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

Hi Efraim and Ludo,

Efraim Flashner <efraim@flashner.co.il> writes:

> My plan was absolutely to merge master into core-updates after and then
> integrate all the changes into their affected packages. I'd also make
> sure to bump gcc to 8 (assuming we don't go straight to 9).

Sounds good.  If we can get powerpc64le-linux working on master, I'd be
very happy.  We can simultaneously try that while still working on
wip-ppc64le (based on core-updates).

I tried out the wip-ppc64le-for-master branch.  I can build it manually
on my Debian ppc64le system, but "make check" fails.  There are two test
failures.

The first test failure is tests/syscalls.scm.  It seems that Ludo's
recently added mount procedure (7e9d9f2 syscalls: Add 'mounts' and the
<mount> record type.) does not work on my system.  In fact, it does not
work on my Debian ppc64le system, nor does it work on my x86_64 Fedora
system.  In both cases, the code makes the incorrect assumption that the
type and source are located in columns 8 and 9, like so:

--8<---------------cut here---------------start------------->8---
(define (mounts)
  "Return the list of mounts (<mount> records) visible in the namespace of the
current process."
  (define (string->device-number str)
    (match (string-split str #\:)
      (((= string->number major) (= string->number minor))
       (+ (* major 256) minor))))

  (call-with-input-file "/proc/self/mountinfo"
    (lambda (port)
      (let loop ((result '()))
        (let ((line (read-line port)))
          (if (eof-object? line)
              (reverse result)
              (match (string-tokenize line)
                ((id parent-id major:minor root mount-point
                     options _ _ type source _ ...)
                 (let ((devno (string->device-number major:minor)))
                   (loop (cons (%mount (octal-decode source)
                                       (octal-decode mount-point)
                                       devno type options)
                               result)))))))))))
--8<---------------cut here---------------end--------------->8---

However, on my systems, the correct columns are 9 and 10.  Here's the
first few lines of output from Fedora:

--8<---------------cut here---------------start------------->8---
$ cat /proc/self/mountinfo 
22 97 0:21 / /sys rw,nosuid,nodev,noexec,relatime shared:2 - sysfs sysfs rw
23 97 0:5 / /proc rw,nosuid,nodev,noexec,relatime shared:24 - proc proc rw
24 97 0:6 / /dev rw,nosuid shared:20 - devtmpfs devtmpfs rw,size=3923828k,nr_inodes=980957,mode=755
...
--8<---------------cut here---------------end--------------->8---

And here it is from Debian:

--8<---------------cut here---------------start------------->8---
22 28 0:20 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw
23 28 0:21 / /proc rw,nosuid,nodev,noexec,relatime shared:11 - proc proc rw
24 28 0:5 / /dev rw,nosuid,noexec,relatime shared:2 - devtmpfs udev rw,size=15625664k,nr_inodes=244151,mode=755
...
--8<---------------cut here---------------end--------------->8---

On these systems, the 7th column is an optional field, like "shared:7".
The proc man page has this to say about column 7:

  (7) optional fields: zero or more fields of the form "tag[:value]"

So presumably there can be even more than just one optional field.  In
any case, Leo Le Bouter kindly checked his own x86_64 system, where he
observed different output:

--8<---------------cut here---------------start------------->8---
$ cat /proc/self/mountinfo 
23 27 0:21 / /proc rw,relatime - proc none rw
24 27 0:5 / /dev rw,relatime - devtmpfs none rw,size=7972408k,nr_inodes=1993102,mode=755
25 27 0:22 / /sys rw,relatime - sysfs none rw
--8<---------------cut here---------------end--------------->8---

As you can see, in this case there is no optional column, so the mount
procedure works fine on Leo's system.  But it fails on mine.

Ludo, do you have an opinion on how to fix this?  It seems like we can't
assume the number of columns will always be the same, so I guess we'll
have to somehow ignore the optional columns more intelligently, if we
want to keep using string-tokenize to do this.

The second test failure is tests/pack.scm.  There are two contributing
factors to this test failure.

The first contributing factor was commit 8f52ea2 on
wip-ppc64le-for-master.  It fixes an issue that is not present on
master, and for that reason it actually causes a problem if it's
included.  I have removed it from the branch in Savannah; please update
your local copy.

The second contributing factor is this bug:

https://issues.guix.gnu.org/47018

However, we can work around it by simply not running guix-daemon when
running the test.  When guix builds guix, it'll be done in the build
environment, so these problematic tests will probably be skipped.

Finally, I tried running make guix-binary.powerpc64le-linux.tar.xz just
to see how far it would get, anyway.  I was quickly greeted with this
failure when building glibc-intermediate:

--8<---------------cut here---------------start------------->8---
glibc-2.31/wctype/wctrans_l.c
glibc-2.31/wctype/wctype.c
glibc-2.31/wctype/wctype.h
glibc-2.31/wctype/wctype_l.c
phase `unpack' succeeded after 2.4 seconds
starting phase `apply-patch'
Backtrace:
In ice-9/boot-9.scm:
 160: 14 [catch #t #<catch-closure 7ffff0382200> ...]
In unknown file:
   ?: 13 [apply-smob/1 #<catch-closure 7ffff0382200>]
In ice-9/boot-9.scm:
  66: 12 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 11 [eval # #]
In ice-9/boot-9.scm:
2412: 10 [save-module-excursion #<procedure 7ffff03a4800 at ice-9/boot-9.scm:4084:3 ()>]
4089: 9 [#<procedure 7ffff03a4800 at ice-9/boot-9.scm:4084:3 ()>]
1734: 8 [%start-stack load-stack ...]
1739: 7 [#<procedure 7ffff03ba930 ()>]
In unknown file:
   ?: 6 [primitive-load "/gnu/store/kvwc9b9ga1sl4l6fyi3z182570rbsk2i-glibc-intermediate-2.31-guile-builder"]
In ice-9/eval.scm:
 387: 5 [eval # ()]
In ice-9/boot-9.scm:
 160: 4 [catch srfi-34 ...]
In srfi/srfi-1.scm:
 827: 3 [every1 #<procedure 7fffef522f20 at guix/build/gnu-build-system.scm:843:11 (expr)> ...]
In guix/build/gnu-build-system.scm:
 847: 2 [#<procedure 7fffef522f20 at guix/build/gnu-build-system.scm:843:11 (expr)> #]
In guix/build/utils.scm:
 652: 1 [invoke "patch" "--force" "-p1" "-i" #f]
In unknown file:
   ?: 0 [system* "patch" "--force" "-p1" "-i" #f]

ERROR: In procedure system*:
ERROR: Wrong type (expecting string): #f
--8<---------------cut here---------------end--------------->8---

Something about the way in which we are searching for the patch is off,
but I don't have time just now to investigate.  Efraim, if you can
figure it out, that'd be nice, but I'll look into it more tomorrow.
It's probably something simple and related to commit 2712703.

-- 
Chris

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

Re: Release on April 18th?

[Andreas Enge]

Hello,

Am Fri, Mar 12, 2021 at 12:33:18AM -0800 schrieb Chris Marusich:
> The proc man page has this to say about column 7:
>   (7) optional fields: zero or more fields of the form "tag[:value]"

And it goes on like this:
(8)  separator: the end of the optional fields is marked
                   by a single hyphen.

So it looks like it is enough to search for a hyphen surrounded by spaces.
The hyphen is apparently there also when there is no optional field (7),
as can be seen from your examples and also my own system, where both occur
in parallel:
34 26 253:0 /gnu/store /gnu/store ro,noatime - ext4 /dev/mapper/cryptroot rw
51 26 253:0 /var/lib/docker /var/lib/docker rw,relatime shared:1 - ext4 /dev/mapper/cryptroot rw

Alternatively, one can also count from the back to get the fields labelled
(9) to (11) (which may be (8) to (10) in case there are no optional fields).
(I was momentarily confused by "(12) super option*s*"; but these are
apparently separated by commas and not whitespace.)

Andreas

Re: Release on April 18th?

[Efraim Flashner]

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

On Fri, Mar 12, 2021 at 12:33:18AM -0800, Chris Marusich wrote:
> Hi Efraim and Ludo,
> 
> Efraim Flashner <efraim@flashner.co.il> writes:
> 
> > My plan was absolutely to merge master into core-updates after and then
> > integrate all the changes into their affected packages. I'd also make
> > sure to bump gcc to 8 (assuming we don't go straight to 9).
> 
> Sounds good.  If we can get powerpc64le-linux working on master, I'd be
> very happy.  We can simultaneously try that while still working on
> wip-ppc64le (based on core-updates).
> 
> I tried out the wip-ppc64le-for-master branch.  I can build it manually
> on my Debian ppc64le system, but "make check" fails.  There are two test
> failures.
> 
> The first test failure is tests/syscalls.scm.  It seems that Ludo's
> recently added mount procedure (7e9d9f2 syscalls: Add 'mounts' and the
> <mount> record type.) does not work on my system.  In fact, it does not
> work on my Debian ppc64le system, nor does it work on my x86_64 Fedora
> system.  In both cases, the code makes the incorrect assumption that the
> type and source are located in columns 8 and 9, like so:
> 
> --8<---------------cut here---------------start------------->8---
> (define (mounts)
>   "Return the list of mounts (<mount> records) visible in the namespace of the
> current process."
>   (define (string->device-number str)
>     (match (string-split str #\:)
>       (((= string->number major) (= string->number minor))
>        (+ (* major 256) minor))))
> 
>   (call-with-input-file "/proc/self/mountinfo"
>     (lambda (port)
>       (let loop ((result '()))
>         (let ((line (read-line port)))
>           (if (eof-object? line)
>               (reverse result)
>               (match (string-tokenize line)
>                 ((id parent-id major:minor root mount-point
>                      options _ _ type source _ ...)
>                  (let ((devno (string->device-number major:minor)))
>                    (loop (cons (%mount (octal-decode source)
>                                        (octal-decode mount-point)
>                                        devno type options)
>                                result)))))))))))
> --8<---------------cut here---------------end--------------->8---
> 
> However, on my systems, the correct columns are 9 and 10.  Here's the
> first few lines of output from Fedora:
> 
> --8<---------------cut here---------------start------------->8---
> $ cat /proc/self/mountinfo 
> 22 97 0:21 / /sys rw,nosuid,nodev,noexec,relatime shared:2 - sysfs sysfs rw
> 23 97 0:5 / /proc rw,nosuid,nodev,noexec,relatime shared:24 - proc proc rw
> 24 97 0:6 / /dev rw,nosuid shared:20 - devtmpfs devtmpfs rw,size=3923828k,nr_inodes=980957,mode=755
> ...
> --8<---------------cut here---------------end--------------->8---
> 
> And here it is from Debian:
> 
> --8<---------------cut here---------------start------------->8---
> 22 28 0:20 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw
> 23 28 0:21 / /proc rw,nosuid,nodev,noexec,relatime shared:11 - proc proc rw
> 24 28 0:5 / /dev rw,nosuid,noexec,relatime shared:2 - devtmpfs udev rw,size=15625664k,nr_inodes=244151,mode=755
> ...
> --8<---------------cut here---------------end--------------->8---
> 
> On these systems, the 7th column is an optional field, like "shared:7".
> The proc man page has this to say about column 7:
> 
>   (7) optional fields: zero or more fields of the form "tag[:value]"
> 
> So presumably there can be even more than just one optional field.  In
> any case, Leo Le Bouter kindly checked his own x86_64 system, where he
> observed different output:
> 
> --8<---------------cut here---------------start------------->8---
> $ cat /proc/self/mountinfo 
> 23 27 0:21 / /proc rw,relatime - proc none rw
> 24 27 0:5 / /dev rw,relatime - devtmpfs none rw,size=7972408k,nr_inodes=1993102,mode=755
> 25 27 0:22 / /sys rw,relatime - sysfs none rw
> --8<---------------cut here---------------end--------------->8---
> 
> As you can see, in this case there is no optional column, so the mount
> procedure works fine on Leo's system.  But it fails on mine.
> 
> Ludo, do you have an opinion on how to fix this?  It seems like we can't
> assume the number of columns will always be the same, so I guess we'll
> have to somehow ignore the optional columns more intelligently, if we
> want to keep using string-tokenize to do this.
> 
> The second test failure is tests/pack.scm.  There are two contributing
> factors to this test failure.
> 
> The first contributing factor was commit 8f52ea2 on
> wip-ppc64le-for-master.  It fixes an issue that is not present on
> master, and for that reason it actually causes a problem if it's
> included.  I have removed it from the branch in Savannah; please update
> your local copy.

Ooops, I guess it was like the findutils-boot0 patch, necessary for
core-updates but not needed for master.

> The second contributing factor is this bug:
> 
> https://issues.guix.gnu.org/47018
> 
> However, we can work around it by simply not running guix-daemon when
> running the test.  When guix builds guix, it'll be done in the build
> environment, so these problematic tests will probably be skipped.
> 
> Finally, I tried running make guix-binary.powerpc64le-linux.tar.xz just
> to see how far it would get, anyway.  I was quickly greeted with this
> failure when building glibc-intermediate:
> 
> --8<---------------cut here---------------start------------->8---
> glibc-2.31/wctype/wctrans_l.c
> glibc-2.31/wctype/wctype.c
> glibc-2.31/wctype/wctype.h
> glibc-2.31/wctype/wctype_l.c
> phase `unpack' succeeded after 2.4 seconds
> starting phase `apply-patch'
> Backtrace:
> In ice-9/boot-9.scm:
>  160: 14 [catch #t #<catch-closure 7ffff0382200> ...]
> In unknown file:
>    ?: 13 [apply-smob/1 #<catch-closure 7ffff0382200>]
> In ice-9/boot-9.scm:
>   66: 12 [call-with-prompt prompt0 ...]
> In ice-9/eval.scm:
>  432: 11 [eval # #]
> In ice-9/boot-9.scm:
> 2412: 10 [save-module-excursion #<procedure 7ffff03a4800 at ice-9/boot-9.scm:4084:3 ()>]
> 4089: 9 [#<procedure 7ffff03a4800 at ice-9/boot-9.scm:4084:3 ()>]
> 1734: 8 [%start-stack load-stack ...]
> 1739: 7 [#<procedure 7ffff03ba930 ()>]
> In unknown file:
>    ?: 6 [primitive-load "/gnu/store/kvwc9b9ga1sl4l6fyi3z182570rbsk2i-glibc-intermediate-2.31-guile-builder"]
> In ice-9/eval.scm:
>  387: 5 [eval # ()]
> In ice-9/boot-9.scm:
>  160: 4 [catch srfi-34 ...]
> In srfi/srfi-1.scm:
>  827: 3 [every1 #<procedure 7fffef522f20 at guix/build/gnu-build-system.scm:843:11 (expr)> ...]
> In guix/build/gnu-build-system.scm:
>  847: 2 [#<procedure 7fffef522f20 at guix/build/gnu-build-system.scm:843:11 (expr)> #]
> In guix/build/utils.scm:
>  652: 1 [invoke "patch" "--force" "-p1" "-i" #f]
> In unknown file:
>    ?: 0 [system* "patch" "--force" "-p1" "-i" #f]
> 
> ERROR: In procedure system*:
> ERROR: Wrong type (expecting string): #f
> --8<---------------cut here---------------end--------------->8---
> 
> Something about the way in which we are searching for the patch is off,
> but I don't have time just now to investigate.  Efraim, if you can
> figure it out, that'd be nice, but I'll look into it more tomorrow.
> It's probably something simple and related to commit 2712703.
> 

Leo told me about it yesterday and I pushed a second commit that fixed
it. We needed to make sure the patch file was included as an input,
that's why it got #f instead of a string. In any case, commit
710cfc330a7ed06934a193583b159fbdf07bf2fe takes care of it; it's the
combination of 2712703 and the squash commit.

I'm now running make guix-binary.powerpc64le-linux.tar.xz and so far
it's made it past the initial building stages, we're on to building the
grafts now.


-- 
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 --]