Re: staging branch merged to master

[Andreas Enge]

Am Fri, Apr 14, 2023 at 03:29:01PM -0400 schrieb Maxim Cournoyer:
> The staging branch has been merged to master.

Thanks and congratulations!

> Should we remove the branch from Cuirass and Guix, knowing that teams
> is the way going forward?

Definitely! I will go ahead and do so. If we want a staging branch at
any time in the future, it had better be spin off from master anyway.

By the way, I started cleaning up a few cuirass specs (for deleted
branches, for instance), but I suspect more could go.

Andreas

Re: staging branch merged to master

[John Kehayias]

Hello Maxim,

On Fri, Apr 14, 2023 at 03:29 PM, Maxim Cournoyer wrote:

> Hello,
>
> The staging branch has been merged to master.
>

Nice, thanks!

> Should we remove the branch from Cuirass and Guix, knowing that teams
> is the way going forward?

I also agree with this change, yes to branches going forward.

John

Re: staging branch merged to master

[Leo Famulari]

On Fri, Apr 14, 2023 at 03:29:01PM -0400, Maxim Cournoyer wrote:
> The staging branch has been merged to master.

Thanks! 

> Should we remove the branch from Cuirass and Guix, knowing that teams
> is the way going forward?

I am in favor!

staging branch merged to master

[Maxim Cournoyer]

Hello,

The staging branch has been merged to master.

Should we remove the branch from Cuirass and Guix, knowing that teams
is the way going forward?

-- 
Thanks,
Maxim

Re: ‘staging’ branch is open!

[Christopher Baines]

Ludovic Courtès  writes:

> Hopefully we’ll get a clearer picture in the coming days…

There is starting to be some information in the QA data service instance:

  
https://data.qa.guix.gnu.org/compare-by-datetime/package-derivations?base_branch=master_datetime=_branch=staging_datetime==x86_64-linux=none_change=broken_name=_results=_results=on

That page should show things that build on master, but fail to build on
staging.

There are some false positives though, like python-protobuf that was
recently fixed on master and should be working on staging once master is
merged in.

There's probably some false negatives as well, since the build
information is coming from bordeaux.guix.gnu.org, and it's not yet
attempted to build everything for staging yet.

Chris


signature.asc
Description: PGP signature

Re: python-cryptography and rust [was: Re: ‘staging’ branch is open!]

[Ludovic Courtès]

Hello,

Efraim Flashner  skribis:

> On Sun, May 15, 2022 at 11:22:05PM +0200, Ludovic Courtès wrote:

[...]

>> Yes, so what do you mean?  Should we keep the old 3.3.1 for use on
>> non-x86_64 platforms?  Would that even work?
>
> I'll add 3.4.8 for non-x86_64 platforms and see if I can do something
> about the rust inputs for python-cryptography, to shorten the graph a
> bit and note which crates are "locked" in their current versions.

OK.

>> Besides, since mrustc was updated on ‘staging’, does that new version
>> better support platforms other than x86_64?
>
> I hear we should be able to do aarch64 with our new version of mrustc
> but I haven't tried building it yet on my machines.

On i686 as well maybe?

> I'd leave it as a happy bonus for now and leave aarch64 with the C
> counterparts for this round, rather than relying on the rust bootstrap
> chain, considering how much RAM it can use.

Yup, makes sense.  We can try that eventually on a branch.

Ludo’.

Re: ‘staging’ branch is open!

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sun, 15 May 2022 at 22:55, Ludovic Courtès  wrote:
>
>> I propose freezing tomorrow evening, Monday 16th ca. 8PM CEST.
>> How does that sound?
>
> LGTM.  The branch is now frozen and receive only fixes, right?

An update: ci.guix wasn’t building much lately due to a bug that was
finally fixed a few days ago:

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

However, to quote Forest Gump, “shit happens”, and indeed it happened to
us: we lost SSH access to berlin.guix.gnu.org about the time we were
going to reconfigure it so it has that bug fix.

So, while working on it, the schedule itself is frozen.  :-)

Hopefully we’ll get a clearer picture in the coming days…

Ludo’.

Re: ‘staging’ branch is open!

[zimoun]

Hi,

On Sun, 15 May 2022 at 22:55, Ludovic Courtès  wrote:

> I propose freezing tomorrow evening, Monday 16th ca. 8PM CEST.
> How does that sound?

LGTM.  The branch is now frozen and receive only fixes, right?

Note the «Aborted» status on .


Cheers,
simon

Re: python-cryptography and rust [was: Re: ‘staging’ branch is open!]

[Efraim Flashner]

On Sun, May 15, 2022 at 11:22:05PM +0200, Ludovic Courtès wrote:
> Hi Efraim,
> 
> (+Cc: Marius.)
> 
> Efraim Flashner  skribis:
> 
> > python-cryptography now depends on rust. We're going to need 3.4.8 from
> > the 3.4 series for the other architectures. Currently
> > python-cryptography@36.0.1 is gating about 3000 packages.
> 
> Yes, so what do you mean?  Should we keep the old 3.3.1 for use on
> non-x86_64 platforms?  Would that even work?

I'll add 3.4.8 for non-x86_64 platforms and see if I can do something
about the rust inputs for python-cryptography, to shorten the graph a
bit and note which crates are "locked" in their current versions.

> Besides, since mrustc was updated on ‘staging’, does that new version
> better support platforms other than x86_64?

I hear we should be able to do aarch64 with our new version of mrustc
but I haven't tried building it yet on my machines. I'd leave it as a
happy bonus for now and leave aarch64 with the C counterparts for this
round, rather than relying on the rust bootstrap chain, considering how
much RAM it can use.

> Thanks for the heads-up,
> Ludo’.
> 

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


signature.asc
Description: PGP signature

Re: python-cryptography and rust [was: Re: ‘staging’ branch is open!]

[Ludovic Courtès]

Hi Efraim,

(+Cc: Marius.)

Efraim Flashner  skribis:

> python-cryptography now depends on rust. We're going to need 3.4.8 from
> the 3.4 series for the other architectures. Currently
> python-cryptography@36.0.1 is gating about 3000 packages.

Yes, so what do you mean?  Should we keep the old 3.3.1 for use on
non-x86_64 platforms?  Would that even work?

Besides, since mrustc was updated on ‘staging’, does that new version
better support platforms other than x86_64?

Thanks for the heads-up,
Ludo’.

Re: ‘staging’ branch is open!

[Ludovic Courtès]

Hi Guix!

Ludovic Courtès  skribis:

> zimoun  skribis:
>
>> The schedule could be:
>>
>>  + freeze the ’staging’ branch on the Sun May, 8th
>>  + fix until it is ready, targeting the Sun, May 22th
>>  + prepare a release for June
>
> So now I look ridiculous for being derailed myself…  But yes, something
> like this offset by one (or two?) week would be awesome.

I propose freezing tomorrow evening, Monday 16th ca. 8PM CEST.
How does that sound?

>From there we can start testing and fixing things.

The branch has updates for a few important packages and partial
ungrafting (util-linux and openssl grafts remain).

Thanks,
Ludo’.

python-cryptography and rust [was: Re: ‘staging’ branch is open!]

[Efraim Flashner]

python-cryptography now depends on rust. We're going to need 3.4.8 from
the 3.4 series for the other architectures. Currently
python-cryptography@36.0.1 is gating about 3000 packages.

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


signature.asc
Description: PGP signature

Re: ‘staging’ branch is open!

[zimoun]

Hi,

On Sun, 08 May 2022 at 00:04, Ludovic Courtès  wrote:
> zimoun  skribis:
>
>> The schedule could be:
>>
>>  + freeze the ’staging’ branch on the Sun May, 8th
>>  + fix until it is ready, targeting the Sun, May 22th
>>  + prepare a release for June
>
> So now I look ridiculous for being derailed myself…  But yes, something
> like this offset by one (or two?) week would be awesome.
>
> Who’s in?  :-)

Considering the current constraints on my schedule, now it is becoming
hard nor impossible to free enough time in the next two weeks.

I am in, but after the 22th. :-)


Cheers,
simon

Re: ‘staging’ branch is open!

[Ludovic Courtès]

Hi!

zimoun  skribis:

> The schedule could be:
>
>  + freeze the ’staging’ branch on the Sun May, 8th
>  + fix until it is ready, targeting the Sun, May 22th
>  + prepare a release for June

So now I look ridiculous for being derailed myself…  But yes, something
like this offset by one (or two?) week would be awesome.

Who’s in?  :-)

Thanks,
Ludo’.

Re: ‘staging’ branch is open!

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hi!
>
> The ‘staging’ branch is open!  Which means that changes with “between
> 300 and 1,800 rebuilds” (info "(guix) Submitting Patches") can go there;
> now’s the time to (re)send package updates in that ballpark.

Just to be clear, it was never closed :-).

> Incidentally, I was considering ungrafting things on that branch, even
> those that go beyond the 1,800 dependents limit, since this is almost
> always a safe change and ci.guix now has the capacity and stability
> needed for that.
>
> What do people think?
>
> I think we should aim for a freeze in one or two weeks, merging in three
> weeks, and resume work on the new release to be done sometime after the
> merge.
>
> Thoughts?

Seems like a fine plan.  Note that although we have the storage capacity
on paper, we still need to complete the Berlin config to make use of it
before we can afford to stress it with as many world rebuilds attempts
as we'd like.

Thanks,

Maxim

Re: ‘staging’ branch is open!

[zimoun]

Hi,

On Sat, 30 Apr 2022 at 01:08, Ludovic Courtès  wrote:

> Incidentally, I was considering ungrafting things on that branch, even
> those that go beyond the 1,800 dependents limit, since this is almost
> always a safe change and ci.guix now has the capacity and stability
> needed for that.

Cool!  I am in for ungrafting things. :-)


> I think we should aim for a freeze in one or two weeks, merging in three
> weeks, and resume work on the new release to be done sometime after the
> merge.

The schedule could be:

 + freeze the ’staging’ branch on the Sun May, 8th
 + fix until it is ready, targeting the Sun, May 22th
 + prepare a release for June

WDYT?


Cheers,
simon

‘staging’ branch is open!

[Ludovic Courtès]

Hi!

The ‘staging’ branch is open!  Which means that changes with “between
300 and 1,800 rebuilds” (info "(guix) Submitting Patches") can go there;
now’s the time to (re)send package updates in that ballpark.

Incidentally, I was considering ungrafting things on that branch, even
those that go beyond the 1,800 dependents limit, since this is almost
always a safe change and ci.guix now has the capacity and stability
needed for that.

What do people think?

I think we should aim for a freeze in one or two weeks, merging in three
weeks, and resume work on the new release to be done sometime after the
merge.

Thoughts?

Ludo’.

Re: Status of Qt build system patches on 'staging' branch.

[Zhu Zihao]

Leo Prikler writes:

> It appears that back in the day they were reverted with
> 918a099e7422fe8ad3464dc5a1b4f60843297742 before a staging merge on
> February 1st.  If nothing else happened on staging since, someone will
> need to revert the revert or apply the patches themselves once more.

These patches were pushed to 'staging-next' branch because 'staging'
branch was forzen at that time. So maybe this is a mistake that we
forget to pick them back to the 'staging'? Should I open a issue to
cherrypick that patches?

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: Status of Qt build system patches on 'staging' branch.

[Leo Prikler]

Am Samstag, den 19.06.2021, 13:59 +0800 schrieb Zhu Zihao:
> Hello Guix!
> 
> In January I'm following up a series of patches(
> https://issues.guix.gnu.org/45784) that fixes Qt build
> system to honor user's environment variable. It has been six months
> now,
> but these patches are still in 'staging' branch.
> 
> Tho these patches will trigger rebuild of almost all qt applications,
> but I think six month is so long, and these patches can also help fix
> some icon issues of qt application. Can someone tell me the status of
> it?
If these patches are still in staging, then they will end up in master
with the next staging merge.
It appears that back in the day they were reverted with
918a099e7422fe8ad3464dc5a1b4f60843297742 before a staging merge on
February 1st.  If nothing else happened on staging since, someone will
need to revert the revert or apply the patches themselves once more.

Regards,
Leo

Status of Qt build system patches on 'staging' branch.

[Zhu Zihao]

Hello Guix!

In January I'm following up a series of 
patches(https://issues.guix.gnu.org/45784) that fixes Qt build
system to honor user's environment variable. It has been six months now,
but these patches are still in 'staging' branch.

Tho these patches will trigger rebuild of almost all qt applications,
but I think six month is so long, and these patches can also help fix
some icon issues of qt application. Can someone tell me the status of
it?

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability]

[Mathieu Othacehe]

Hey,

> The network team asks me to test it now.  Could you please give it a
> try?

I ran a few tests, it seems to work perfectly! It's really impressive
how Wireguard is easy to set up. I think it deserves a complete Guix
service :).

--8<---cut here---start->8---
mathieu@berlin ~$ sudo wg
interface: wg0
  public key: wOIfhHqQ+JQmskRS2qSvNRgZGh33UxFDi8uuSXOltF0=
  private key: (hidden)
  listening port: 51820

peer: hzpKg9X1yqu1axN6iJp0mWf6BZGo8m1wteKwtTmDGF4=
  endpoint: 91.166.111.102:45266
  allowed ips: 10.0.0.2/32
  latest handshake: 26 seconds ago
  transfer: 3.27 KiB received, 3.21 KiB sent
--8<---cut here---end--->8---

Anyway, thanks for your support,

Mathieu

Re: Staging branch [substitute availability]

[Ricardo Wurmus]

Mathieu Othacehe  writes:

>> Yes, this should be okay.  Does this mean that we can get rid of all the
>> other ports that we previously requested?
>
> Yes, the SSH tunnels and the associated open ports shouldn't be useful
> anymore, as we'll be able to route all the build nodes traffic through
> the VPN.

Excellent!

>> If you’re sure that it should be UDP port 51820 for incoming connections
>> (and outgoing as well?) then I’ll submit the request.
>
> Yes, UDP 51820 for incoming and outgoing connections would be fine.

The network team asks me to test it now.  Could you please give it a
try?

-- 
Ricardo

Re: Staging branch [substitute availability]

[Mathieu Othacehe]

Hello,

> Yes, this should be okay.  Does this mean that we can get rid of all the
> other ports that we previously requested?

Yes, the SSH tunnels and the associated open ports shouldn't be useful
anymore, as we'll be able to route all the build nodes traffic through
the VPN.

> If you’re sure that it should be UDP port 51820 for incoming connections
> (and outgoing as well?) then I’ll submit the request.

Yes, UDP 51820 for incoming and outgoing connections would be fine.

> Sorry again for the delay!  Feel free to ping me directly in the future.

No worries, thanks for your reply!

Mathieu

Re: Staging branch [substitute availability]

[Ricardo Wurmus]

Hi Mathieu,

sorry for missing this message (and all the others).
Leo pointed me to this message on IRC.  (Thanks!)

> The easier way to proceed could be to create a VPN for the remote build
> machines that are not on berlin local network. Wireguard could be a good
> candidate. That would mean that only one UDP port has to be opened on
> berlin.
>
> Ricardo, do you think that the sysadmins would agree to open traffic on
> UDP port 51820 for instance?

Yes, this should be okay.  Does this mean that we can get rid of all the
other ports that we previously requested?

If you’re sure that it should be UDP port 51820 for incoming connections
(and outgoing as well?) then I’ll submit the request.

Sorry again for the delay!  Feel free to ping me directly in the future.

-- 
Ricardo

Re: Staging branch

[Ludovic Courtès]

Leo Famulari  skribis:

> The staging branch has been merged to master in commit
> 75b775e81b5a81a59656eeba8811b42f45d503da
>
> Hooray!
>
> Thanks to everyone that helped out with bug reports, fixes, CI
> assistance, etc.

Yay!  And thank *you* for coordinating this effort and working to get
the branch in mergeable stage!

> There is some discussion about changes to the branch workflow:
>
> https://lists.gnu.org/archive/html/guix-devel/2021-02/msg4.html
>
> And we should all discuss it "live" next Monday, February 8, during the
> Guix Days videoconference. Please follow the Guix blog for more details
> on how to join that meeting.

That’s a good idea.

Ludo’.

Re: Staging branch

[Leo Famulari]

The staging branch has been merged to master in commit
75b775e81b5a81a59656eeba8811b42f45d503da

Hooray!

Thanks to everyone that helped out with bug reports, fixes, CI
assistance, etc.

There is some discussion about changes to the branch workflow:

https://lists.gnu.org/archive/html/guix-devel/2021-02/msg4.html

And we should all discuss it "live" next Monday, February 8, during the
Guix Days videoconference. Please follow the Guix blog for more details
on how to join that meeting.


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability]

[Mathieu Othacehe]

Hello,

> What would it take to connect at least one OverDrive?  How can the
> admins among us help?

I have reconfigured the overdrive1 so that it runs a Cuirass remote
worker. Now several ports on berlin and the overdrive1 need to be opened
for the remote building mechanism.

The easier way to proceed could be to create a VPN for the remote build
machines that are not on berlin local network. Wireguard could be a good
candidate. That would mean that only one UDP port has to be opened on
berlin.

Ricardo, do you think that the sysadmins would agree to open traffic on
UDP port 51820 for instance?

> Fun.  Not sure what the correct solution would be; perhaps make one
> /api/queue request per system type?

Yes, that would already be better.

Thanks,

Mathieu

Re: Staging branch [substitute availability]

[Efraim Flashner]

On Tue, Jan 26, 2021 at 06:51:13PM -0500, Leo Famulari wrote:
> On Fri, Jan 22, 2021 at 03:46:45PM -0500, Leo Famulari wrote:
> > --
> > master branch
> > aarch64: 72% 
> > x86_64: 94% 
> > i686: 86%
> > armhf: 46%
> > 
> > staging branch
> > aarch64: 48% 
> > x86_64: 79% 
> > i686: 70%
> > armhf: 30%
> > --
> 
> Updates since the recent merge of master into staging:
> 
> ------
> master branch
> aarch64: 72%
> x86_64: 94%
> i686: 86%
> armhf: 46%
> 
> staging branch
> aarch64: 51%
> x86_64: 73%
> i686: 69%
> armhf: 27%
> --
> 
> So, minor improvements to aarch64, but x86_64 is actually worse!
> Mathieu, I'm curious, are we using the overdrives again? Or still
> emulating aarch64?
> 
> `guix weather` said to me that there are *no* queued builds for x86_64
> on staging, but ci.guix.gnu.org web interface shows that there are
> queued builds.
> 
> kwayland is definitely broken on x86_64, so wayland users are invited to
> fix it:
> 

This is probably me, I was able to enable and run the kwayland tests on
my machine but I think this test only fails when the machine is under
load.

> --
> The following tests FAILED: 
>  26 - kwayland-testPlasmaWindowModel (Failed) 
> Errors while running CTest 
> make: *** [Makefile:112: test] Error 8
> --
> 
> I've attached the full reports.
> 
> My plan is to wait for feedback for a few days and, if I don't hear
> otherwise, then merge the staging branch into master and push.

Sounds good!

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


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability]

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

> I have not connected the overdrives yet, so the aarch64 builds are still
> 100% emulated. Regarding x86_64, I guess it's because it took ~1.5 days
> for the CI to catch up, as you can see here:
> https://ci.guix.gnu.org/metrics.

What would it take to connect at least one OverDrive?  How can the
admins among us help?

Before, when Danny reported issues with emulated builds, we stopped all
emulated builds for AArch64/ARMv7 to avoid further breakage.  So I guess
we should try to get back to that situation.

> "guix time-machine --branch=staging -- weather" now reports 82.7%
> coverage for x86_64.

Nice that it quickly gets better!

>> `guix weather` said to me that there are *no* queued builds for x86_64
>> on staging, but ci.guix.gnu.org web interface shows that there are
>> queued builds.
>
> That's because %query-limit is 1000 in (guix ci). It means that "guix
> weather" will ask at most for the last 1000 queued builds. If they are
> all aarch64 builds, then it will erroneously report that there are no
> x86_64 queued builds.

Fun.  Not sure what the correct solution would be; perhaps make one
/api/queue request per system type?

Thanks!

Ludo’.

Re: Staging branch [substitute availability]

[Mathieu Othacehe]

Hey Leo,

> So, minor improvements to aarch64, but x86_64 is actually worse!
> Mathieu, I'm curious, are we using the overdrives again? Or still
> emulating aarch64?

I have not connected the overdrives yet, so the aarch64 builds are still
100% emulated. Regarding x86_64, I guess it's because it took ~1.5 days
for the CI to catch up, as you can see here:
https://ci.guix.gnu.org/metrics.

"guix time-machine --branch=staging -- weather" now reports 82.7%
coverage for x86_64.

> `guix weather` said to me that there are *no* queued builds for x86_64
> on staging, but ci.guix.gnu.org web interface shows that there are
> queued builds.

That's because %query-limit is 1000 in (guix ci). It means that "guix
weather" will ask at most for the last 1000 queued builds. If they are
all aarch64 builds, then it will erroneously report that there are no
x86_64 queued builds.

Thanks,

Mathieu

Re: Staging branch [kwayland test failure]

[Leo Famulari]

On Wed, Jan 27, 2021 at 02:44:42PM -0500, Leo Famulari wrote:
> On Wed, Jan 27, 2021 at 11:26:52AM +0100, Guillaume Le Vaillant wrote:
> > It looks like the kwayland test failure on x86-64 doesn't happen all the 
> > time.
> > I just built it successfully on master and on staging by trying again
> > when the build failed.
> 
> Thanks, that is useful info! I'll try building it some more, on a single
> core, and maybe we'll just disable this test.

It turns out, this package is broken (or flaky, at least) on the master
branch too. We should fix it, but it won't block the merge of staging.


signature.asc
Description: PGP signature

Re: Staging branch [kwayland test failure]

[Leo Famulari]

On Wed, Jan 27, 2021 at 11:26:52AM +0100, Guillaume Le Vaillant wrote:
> It looks like the kwayland test failure on x86-64 doesn't happen all the time.
> I just built it successfully on master and on staging by trying again
> when the build failed.

Thanks, that is useful info! I'll try building it some more, on a single
core, and maybe we'll just disable this test.

Re: Staging branch [kwayland test failure]

[Guillaume Le Vaillant]

It looks like the kwayland test failure on x86-64 doesn't happen all the time.
I just built it successfully on master and on staging by trying again
when the build failed.


signature.asc
Description: PGP signature

Re: Staging branch [kwayland test failure]

[Leo Famulari]

On Tue, Jan 26, 2021 at 06:51:13PM -0500, Leo Famulari wrote:
> kwayland is definitely broken on x86_64, so wayland users are invited to
> fix it:
> 
> --
> The following tests FAILED: 
>  26 - kwayland-testPlasmaWindowModel (Failed) 
> Errors while running CTest 
> make: *** [Makefile:112: test] Error 8
> --

Slightly more specific info, from
"build/Testing/Temporary/LastTest.log":

--
FAIL!  : PlasmaWindowModelTest::testVirtualDesktops() 
'!dataChangedSpy.wait(100)' returned FALSE. ()
   Loc: 
[/tmp/guix-build-kwayland-5.70.0.drv-0/kwayland-5.70.0/autotests/client/test_plasma_window_model.cpp(588)]
--

Any ideas?


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability]

[Leo Famulari]

On Fri, Jan 22, 2021 at 03:46:45PM -0500, Leo Famulari wrote:
> --
> master branch
> aarch64: 72% 
> x86_64: 94% 
> i686: 86%
> armhf: 46%
> 
> staging branch
> aarch64: 48% 
> x86_64: 79% 
> i686: 70%
> armhf: 30%
> --

Updates since the recent merge of master into staging:

--
master branch
aarch64: 72%
x86_64: 94%
i686: 86%
armhf: 46%

staging branch
aarch64: 51%
x86_64: 73%
i686: 69%
armhf: 27%
--

So, minor improvements to aarch64, but x86_64 is actually worse!
Mathieu, I'm curious, are we using the overdrives again? Or still
emulating aarch64?

`guix weather` said to me that there are *no* queued builds for x86_64
on staging, but ci.guix.gnu.org web interface shows that there are
queued builds.

kwayland is definitely broken on x86_64, so wayland users are invited to
fix it:

--
The following tests FAILED: 
 26 - kwayland-testPlasmaWindowModel (Failed) 
Errors while running CTest 
make: *** [Makefile:112: test] Error 8
--

I've attached the full reports.

My plan is to wait for feedback for a few days and, if I don't hear
otherwise, then merge the staging branch into master and push.
computing 13,328 package derivations for aarch64-linux...
http://ci.guix.gnu.org
  72.4% substitutes available (10,073 out of 13,907)
  at least 53,877.7 MiB of nars (compressed)
  80,315.8 MiB on disk (uncompressed)
  0.002 seconds per request (32.6 seconds in total)
  427.1 requests per second

  0.0% (1 out of 3,834) of the missing items are queued
  at least 1,000 queued builds
  i686-linux: 94 (9.4%)
  aarch64-linux: 865 (86.5%)
  i586-gnu: 1 (.1%)
  x86_64-linux: 40 (4.0%)
  build rate: 181.65 builds per hour
  x86_64-linux: 56.68 builds per hour
  i686-linux: 65.97 builds per hour
  aarch64-linux: 59.25 builds per hour
1321 packages are missing from 'http://ci.guix.gnu.org' for 'aarch64-linux', 
among which:
  2024  rust@1.21.0 
/gnu/store/vwyns4ahdcfzn8nkzrm9airwblxh2805-rust-1.21.0-cargo 
/gnu/store/zdzyw3xf1cyqly0jsvhddw0l9vkl9d4p-rust-1.21.0-doc 
/gnu/store/hdv7kzpvnn2hr79rghnl0mchwcz8dg57-rust-1.21.0 
   835  clisp@2.49-92   
/gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 
   811  r-yaml@2.2.1
/gnu/store/d06vsnv4rbkz389g7wrh0xbr3mb37rbk-r-yaml-2.2.1 
   809  r-highr@0.8 /gnu/store/gjwsyw35p4c6cd7gqrnl4xjpgys6pic7-r-highr-0.8 
   782  ghc@7.10.2  
/gnu/store/20dvxrmwp5p9b5pvb45152wh4sg7abb0-ghc-7.10.2-doc 
/gnu/store/2kz68x4abq6qz1zqkscqc41lcqhp14xi-ghc-7.10.2 
   397  elogind@243.7   
/gnu/store/6lsrwi88632ybrj14059brb1xcycfq8f-elogind-243.7 
   246  r-r-cache@0.14.0
/gnu/store/2g3c41lnvir5rr5ppn3svf2acqzs2290-r-r-cache-0.14.0 
   245  php@7.4.14  /gnu/store/3ik44x007z9wfyi4gnx99hfhdfi5wazx-php-7.4.14 
   178  elogind@243.7   
/gnu/store/6lsrwi88632ybrj14059brb1xcycfq8f-elogind-243.7 
   170  libpipeline@1.5.3   
/gnu/store/6qi0yj1i61py5mhg02vll8b6gbjilngl-libpipeline-1.5.3 
   170  qgpgme@1.15.1   
/gnu/store/pdg9g412blki37gk9bhyh3fqhf1qr59m-qgpgme-1.15.1 
   165  kwayland@5.70.0 
/gnu/store/4cl7xivd43b8jpkbnc3ndmhibgk04skd-kwayland-5.70.0 
   151  qgpgme@1.15.1   
/gnu/store/pdg9g412blki37gk9bhyh3fqhf1qr59m-qgpgme-1.15.1 
   149  java-testng@6.14.3  
/gnu/store/hwdl2805anag91xkysnq8l2c34kyvj4m-java-testng-6.14.3 
   137  java-commons-lang@2.6   
/gnu/store/cbiazsqhim38pvcxj8mxh27r3bgxjqq1-java-commons-lang-2.6-doc 
/gnu/store/mdx7giwafnprs31ncymzmppn9y3n6ybz-java-commons-lang-2.6 
   124  java-ops4j-base-monitors@1.5.0  
/gnu/store/45g5x60b0n1bcrvvm8a3dfg1d3lg8zpr-java-ops4j-base-monitors-1.5.0 
   122  java-powermock-core@1.7.3   
/gnu/store/m4qjvfxa4gc336h0qzckdmrwzl3jw76a-java-powermock-core-1.7.3 
   121  java-ops4j-base-util-property@1.5.0 
/gnu/store/qxn68hgg1a89c4qqarm4j16i8z22mhyp-java-ops4j-base-util-property-1.5.0 
   121  java-javax-mail@1.5.6   
/gnu/store/pvvqmz350vq6r71abm6fpyyw1g0297js-java-javax-mail-1.5.6 
   120  java-ops4j-base-spi@1.5.0   
/gnu/store/6ddhzanvy5xcclsajqsv5lqhcpfdfaam-java-ops4j-base-spi-1.5.0 
89  r-lazyeval@0.2.2
/gnu/store/wvwfx0qj0asssqa9rsjjzfs5j8bq46ds-r-lazyeval-0.2.2 
81  qtwebkit@5.212.0-alpha4 
/gnu/store/zdk4pbmfmnr0w85h7sky0cwq25yv34a3-qtwebkit-5.212.0-alpha4 
81  hwloc@2.2.0 
/gnu/store/4pbmc87q6n8zw8bw9wnlnhb1892dngd6-hwloc-2.2.0-debug 
/gnu/store/y26brf1zcccipqf2q990fhc6mnqjihm0-hwloc-2.2.0-doc 
/gnu/store/9vil275z0z0p6vy6q7a4ydwak83wk2cr-hwloc-2.2.0-lib 
/gnu/store/y905fmz3paa1jidinq54dbyag00iy3zr-hwloc-2.2.0 
80  emacs-ansi@0.4.1-1.a41d5cc  
/gnu/store/z3p7rwyn4rhn8h8mvxw38wp7shc04wyg-emacs-ansi-0.4.1-1.a41d5cc 
79  emacs-commander@0.7.0   
/gnu/store/y3gi03ihd3l799qvb5r6zn51fqqlc43s-emacs-commander-0.7.0 
77  r-nnet@7.3-14   
/gnu/store/3caabkmnjjkd8wcp14ysqgwx2amijpa3-r-nnet-7.3-14 
75  r-sourcetools@0.1.7 
/gnu/store/5hiia42k7xvxz4ndxlab44dl4spv4m8j-r-sourcetools-0.1.7 
73  r-jpeg@0.1-8.1  
/gnu/store/bpyqgcnzby7dmy9cf2lllb3kqa74skq5-r-jpeg-0.1-

Re: Staging branch [substitute availability]

[Ekaitz Zarraga]

Hi,

> Freetype issue is fixed in version 9, but that
> has other problems, such as making it impossible to unbundle the dozens
> of libraries that we are currently unbundling [...] it is possible to
> backport the VTK commits that fix Freetype compatibility, but it will be
> a lot of work and a huge patch (it was a major cleanup IIRC)." I'm
> CC-ing Ekaitz Zarraga, who has been working on FreeCAD. I'm not sure
> what we can do about this problem in the short term. Marius, can you
> give more info about the bundling problem?


Sorry for the delay in the answer.
I have no clue about what we can do. All the work I did with Freecad was
related with other inputs and I didn't need to touch freetype.

I don't know how I can help. If you have any specific question I'll do
my best to try to answer it.


Regards,
Ekaitz

Re: Staging branch [problem with node-10.22]

[Leo Famulari]

On Sat, Jan 23, 2021 at 04:29:54PM -0500, Mark H Weaver wrote:
> Presumably the problem is that you're using a certain 3rd-party channel
> that relies upon the 'node-10.22' variable, which was removed in the
> following commit on the 'ungrafting' branch (later merged into
> 'staging'):
> 
> https://git.sv.gnu.org/cgit/guix.git/commit/?h=staging=18f10c0b12dd369507fd2821dcf748fc9b13053a

This hypothesis was confirmed on the #guix IRC channel.

Re: Staging branch [problem with node-10.22]

[Mark H Weaver]

Jonathan Brielmaier  writes:

> I tried to update my desktop system to staging but it already fails in
> `guix pull`:
>
> $ cat
> /var/log/guix/drvs/d2/rd3sv1i0wy6bwibp4chjymz6b4dggl-guix-package-cache.drv.bz2
> | bzip2 -d
> (repl-version 0 1 1)
> Generating package cache for
> '/gnu/store/pn96j52ajgdkbsjv1i1m3jwj2iir91y6-profile'...
> (exception unbound-variable (value #f) (value "Unbound variable: ~S")
> (value (node-10.22)) (value #f))

Presumably the problem is that you're using a certain 3rd-party channel
that relies upon the 'node-10.22' variable, which was removed in the
following commit on the 'ungrafting' branch (later merged into
'staging'):

https://git.sv.gnu.org/cgit/guix.git/commit/?h=staging=18f10c0b12dd369507fd2821dcf748fc9b13053a

  Mark

Re: Staging branch [problem with node-10.22]

[Leo Famulari]

On Sat, Jan 23, 2021 at 12:58:29PM +0100, Jonathan Brielmaier wrote:
> I tried to update my desktop system to staging but it already fails in
> `guix pull`:
> 
> $ cat
> /var/log/guix/drvs/d2/rd3sv1i0wy6bwibp4chjymz6b4dggl-guix-package-cache.drv.bz2
> | bzip2 -d
> (repl-version 0 1 1)
> Generating package cache for
> '/gnu/store/pn96j52ajgdkbsjv1i1m3jwj2iir91y6-profile'...
> (exception unbound-variable (value #f) (value "Unbound variable: ~S")
> (value (node-10.22)) (value #f))
> 
> I don't really understand the error. I don't have node in my profile or
> my system config...

Also, if you are using any 3rd-party channels or GUIX_PACKAGE_PATH,
could you try again without them?

Re: Staging branch [problem with node-10.22]

[Leo Famulari]

On Sat, Jan 23, 2021 at 12:58:29PM +0100, Jonathan Brielmaier wrote:
> I tried to update my desktop system to staging but it already fails in
> `guix pull`:
> 
> $ cat
> /var/log/guix/drvs/d2/rd3sv1i0wy6bwibp4chjymz6b4dggl-guix-package-cache.drv.bz2
> | bzip2 -d
> (repl-version 0 1 1)
> Generating package cache for
> '/gnu/store/pn96j52ajgdkbsjv1i1m3jwj2iir91y6-profile'...
> (exception unbound-variable (value #f) (value "Unbound variable: ~S")
> (value (node-10.22)) (value #f))

--
$ ./pre-inst-env guix refresh -l node@10.22
Building the following 19 packages would ensure 27 dependent packages are 
rebuilt: cwltool@3.0.20201121085451 
ungoogled-chromium-wayland@87.0.4280.88-0.b78cb92 emacs-nodejs-repl@0.2.2 
gnome@3.34.2 vinagre@3.22.0 virt-viewer@7.0 virt-manager@2.2.1 
icedove-wayland@78.6.0 icedove@78.6.0 geierlein@0.9.13 node-semver@7.2.1 
node-env-variable@0.0.4 node-stack-trace@0.0.10-1.4fd379e 
node-statsd-parser@0.0.4 node-color-name@1.1.3 node-util-deprecate@1.0.2 
node-mersenne@0.0.4 ruby-autoprefixer-rails@9.4.7 vlang@0.1.29
--

Are you using any of those packages?

Re: Staging branch [problem with node-10.22]

[Jonathan Brielmaier]

On 22.01.21 21:46, Leo Famulari wrote:

On Wed, Jan 13, 2021 at 05:30:53PM -0500, Leo Famulari wrote:

Using `guix weather`, we can check substitute availability for the
staging branch:

--
master branch
aarch64: 66%
x86_64: 93%
i686: 85%
armhf: 51%

staging branch
aarch64: 44%
x86_64: 80%
i686: 60%
armhf: 30%
--


I tried to update my desktop system to staging but it already fails in
`guix pull`:

$ cat
/var/log/guix/drvs/d2/rd3sv1i0wy6bwibp4chjymz6b4dggl-guix-package-cache.drv.bz2
| bzip2 -d
(repl-version 0 1 1)
Generating package cache for
'/gnu/store/pn96j52ajgdkbsjv1i1m3jwj2iir91y6-profile'...
(exception unbound-variable (value #f) (value "Unbound variable: ~S")
(value (node-10.22)) (value #f))

I don't really understand the error. I don't have node in my profile or
my system config...

Re: Staging branch [substitute availability]

[Leo Famulari]

On Wed, Jan 13, 2021 at 05:30:53PM -0500, Leo Famulari wrote:
> Using `guix weather`, we can check substitute availability for the
> staging branch:
> 
> --
> master branch
> aarch64: 66% 
> x86_64: 93% 
> i686: 85%
> armhf: 51%
> 
> staging branch
> aarch64: 44% 
> x86_64: 80% 
> i686: 60%
> armhf: 30%
> --

Updates since 9 days ago:

--
master branch
aarch64: 72% 
x86_64: 94% 
i686: 86%
armhf: 46%

staging branch
aarch64: 48% 
x86_64: 79% 
i686: 70%
armhf: 30%
--

Some improvement can be seen. There are still a huge number of failures
on CI that can't be reproduced locally, especially for aarch64.

Since working around the failure of mesa on i686, that platform shows
major improvement.

The big failures on x86_64 are all rather niche — Java and OCaml mostly.

armhf continues to decline because we are no longer building substitutes
for it.

There are some failures I think are important, though.

For example, the vtk package is broken due to incompatibility with new
Freetype, which breaks FreeCAD. On #guix, Marius said "I looked into VTK
before the holidays; the Freetype issue is fixed in version 9, but that
has other problems, such as making it impossible to unbundle the dozens
of libraries that we are currently unbundling [...] it is possible to
backport the VTK commits that fix Freetype compatibility, but it will be
a lot of work and a huge patch (it was a major cleanup IIRC)." I'm
CC-ing Ekaitz Zarraga, who has been working on FreeCAD. I'm not sure
what we can do about this problem in the short term. Marius, can you
give more info about the bundling problem?

Full weather report attached, including failures of packages with at
least 10 dependents.

Can you identify any outstanding issues? Or are we ready to merge the
branch into master? Although the numbers are lower for staging, the high
rate of spurious failures and the successful system reconfigurations
reported by Guix users makes me think that the situation is fine.
computing 13,273 package derivations for aarch64-linux...
http://ci.guix.gnu.org
  71.7% substitutes available (9,935 out of 13,852)
  at least 53,537.1 MiB of nars (compressed)
  79,971.0 MiB on disk (uncompressed)
  0.002 seconds per request (26.9 seconds in total)
  515.1 requests per second

  0.0% (0 out of 3,917) of the missing items are queued
  10 queued builds
  i586-gnu: 8 (80.0%)
  armhf-linux: 1 (10.0%)
  aarch64-linux: 1 (10.0%)
  build rate: 91.55 builds per hour
  x86_64-linux: 36.71 builds per hour
  aarch64-linux: 8.70 builds per hour
  i686-linux: 46.15 builds per hour
1279 packages are missing from 'http://ci.guix.gnu.org' for 'aarch64-linux', 
among which:
  1989  rust@1.21.0 
/gnu/store/vwyns4ahdcfzn8nkzrm9airwblxh2805-rust-1.21.0-cargo 
/gnu/store/zdzyw3xf1cyqly0jsvhddw0l9vkl9d4p-rust-1.21.0-doc 
/gnu/store/hdv7kzpvnn2hr79rghnl0mchwcz8dg57-rust-1.21.0 
   811  r-yaml@2.2.1
/gnu/store/d06vsnv4rbkz389g7wrh0xbr3mb37rbk-r-yaml-2.2.1 
   809  r-highr@0.8 /gnu/store/gjwsyw35p4c6cd7gqrnl4xjpgys6pic7-r-highr-0.8 
   807  clisp@2.49-92   
/gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 
   782  ghc@7.10.2  
/gnu/store/20dvxrmwp5p9b5pvb45152wh4sg7abb0-ghc-7.10.2-doc 
/gnu/store/2kz68x4abq6qz1zqkscqc41lcqhp14xi-ghc-7.10.2 
   397  elogind@243.7   
/gnu/store/6lsrwi88632ybrj14059brb1xcycfq8f-elogind-243.7 
   246  r-r-cache@0.14.0
/gnu/store/2g3c41lnvir5rr5ppn3svf2acqzs2290-r-r-cache-0.14.0 
   245  php@7.4.14  /gnu/store/3ik44x007z9wfyi4gnx99hfhdfi5wazx-php-7.4.14 
   205  git@2.30.0  
/gnu/store/9ryjn5x9as9s6phzbjikvigjif1bdsbv-git-2.30.0-credential-netrc 
/gnu/store/magms2ibjvsn1l6kb1lps207vha7vyg8-git-2.30.0-gui 
/gnu/store/dq03y0xjlji1k8qh1l1nzx3lf4ykngb6-git-2.30.0 
/gnu/store/y3fghhd8nca08j8zlwvqsvzr9m0nv14r-git-2.30.0-send-email 
/gnu/store/xn8nnx6b11ks8n4s5x9x6w9y08j92scf-git-2.30.0-subtree 
/gnu/store/g3yg5ixwwlr9sgkv143prln4czq5xcj7-git-2.30.0-svn 
   178  elogind@243.7   
/gnu/store/6lsrwi88632ybrj14059brb1xcycfq8f-elogind-243.7 
   170  libpipeline@1.5.3   
/gnu/store/6qi0yj1i61py5mhg02vll8b6gbjilngl-libpipeline-1.5.3 
   170  qgpgme@1.15.1   
/gnu/store/pdg9g412blki37gk9bhyh3fqhf1qr59m-qgpgme-1.15.1 
   165  kwayland@5.70.0 
/gnu/store/4cl7xivd43b8jpkbnc3ndmhibgk04skd-kwayland-5.70.0 
   151  qgpgme@1.15.1   
/gnu/store/pdg9g412blki37gk9bhyh3fqhf1qr59m-qgpgme-1.15.1 
   149  java-testng@6.14.3  
/gnu/store/hwdl2805anag91xkysnq8l2c34kyvj4m-java-testng-6.14.3 
   137  java-commons-lang@2.6   
/gnu/store/cbiazsqhim38pvcxj8mxh27r3bgxjqq1-java-commons-lang-2.6-doc 
/gnu/store/mdx7giwafnprs31ncymzmppn9y3n6ybz-java-commons-lang-2.6 
   124  java-ops4j-base-monitors@1.5.0  
/gnu/store/45g5x60b0n1bcrvvm8a3dfg1d3lg8zpr-java-ops4j-base-monitors-1.5.0 
   123  python-distlib@0.3.1
/gnu/store/gwrq1fk4rxf9p41i7681xf8vdjhlznda-python-distlib-0.3.1 
   122  java-powermock-core@1.7.3   
/gnu/store/m4qjvfxa4gc336h0qzckdmrwz

Re: Staging branch [substitute availability i686-linux]

[Leo Famulari]

On Wed, Jan 13, 2021 at 07:22:35PM -0500, Leo Famulari wrote:
> I've reported this upstream:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091

Upstream cannot reproduce the test failure.

I disabled the test in commit 8b55544212a90b0276df49596a3d373e5c2e8f5c
and now mesa has built for i686-linux.

Re: Staging branch [substitute availability armhf-linux]

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

Sorry, I forgot to attach that config.(use-modules (gnu bootloader)
 (gnu bootloader u-boot)
 (gnu services base)
 (gnu system)
 (gnu system image)
 (gnu system file-systems)
 (guix channels)
 (guix inferior)
 (srfi srfi-1))

(define wip-pinebook
  (list (channel (name 'guix)
 (url "https://git.savannah.gnu.org/git/guix.git;)
 (branch "wip-pinebook-pro")
 (introduction
   (make-channel-introduction
 "47a5442aa7dad8b1904483954e91640c3cac5e90"
 (openpgp-fingerprint
   "658073613BFCC5C7E2E45D45DC518FC87F9716AA"))
(define inferior-pinebook (inferior-for-channels wip-pinebook))

(operating-system
  (host-name "test")
  (timezone "US/Eastern")
  (locale "en_US.utf8")
  (bootloader (bootloader-configuration
(bootloader u-boot-pinebook-pro-rk3399-bootloader)
(target "/dev/vda")))
  (kernel (first (lookup-inferior-packages inferior-pinebook
   "linux-libre-pinebook-pro")))
  (kernel-arguments (cons* "video=HDMI-A-1:1920x1080@60"
   "video=eDP-1:1920x1080@60"
   "vga=current"
   %default-kernel-arguments))
  (initrd-modules '())
  (file-systems (cons (file-system
(device (file-system-label root-label))
(mount-point "/")
(type "ext4"))
  %base-file-systems))
  (users (cons (user-account
 (name "test")
 (group "users")
 (supplementary-groups '("wheel"))
 (password (crypt "test" "$5$ca")))
   %base-user-accounts))
  (services (cons* (service agetty-service-type
(agetty-configuration
  (extra-options '("-L"))
  (baud-rate "150")
  (term "vt100")
  (tty "ttyS2")))
   %base-services)))

Re: Staging branch [substitute availability armhf-linux]

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

Hi,

> > LCD output, nothing answering on serial console (@1.5Mbps
> > (uboot speed) or 115.2Kbps (kernel speed, I think)).

Both kernel and u-boot use 150 baud.

> Strange, seems that Caliph did manage to get a serial console. Caliph,
> any insight here?

A configuration close to the pinebook-pro-barebones-os configuration worked for
me software-wise (albiet, without LCD output), but there's a few hardware
tweaks that need to be done to get it working. On the mainboard there's two
switches: an eMMC disable switch and a serial output switch. The serial output
switch needs to be set properly to get serial out through the headphone jack.
Nominally you should also disable the internal eMMC if there's anything on it
in order to use Guix's u-boot, but I wasn't able to get the switch to work so I
just removed the eMMC flash. From the log posted earlier, it does look like
that's the case, so it's booting from the factory-default 2017 u-boot with
blobs.

I just realized that the configuration I used had one (significant) change:
agetty needs to be started on /dev/ttyS2, not /dev/ttyS0. I have just submitted
a patch to fix this (https://issues.guix.gnu.org/45997).

To get the LCD up, I used an inferior with linux-libre-pinebook-pro from the
wip-pinebook-pro branch, and included some kernel arguments from janneke that
Mathieu told me about, though I'm unsure how necessary they are with the kernel
patches. I have also heard that disabling CONFIG_ROCKCHIP_CDN_DP on mainline
would work too, but I haven't tested it.

I'll attach a config that should work to bring up serial and the LCD.

Hope this helps.

Re: Staging branch [substitute availability aarch64-linux]

[Leo Famulari]

On Mon, Jan 18, 2021 at 12:19:59PM +0200, Efraim Flashner wrote:
> Just finished building llvm, took 14.5 hours and RAM+swap went over
> 3.5GB at certain points that I checked.

Wow! Thank you very much for checking.

Re: Staging branch [substitute availability aarch64-linux]

[Efraim Flashner]

Just finished building llvm, took 14.5 hours and RAM+swap went over
3.5GB at certain points that I checked.

On Sun, Jan 17, 2021 at 09:50:27PM +0200, Efraim Flashner wrote:
> On Wed, Jan 13, 2021 at 06:38:39PM -0500, Leo Famulari wrote:
> > For aarch64-linux, the biggest problems are LLVM and Rust, but there are
> > other major problems such as nss-certs.
> > 
> > Are LLVM and Rust expected to work on this platform within Guix? What
> > about GHC?
> 
> llvm should work, I'll start a build now on my pine64 and see how it
> goes. GHC has only ever been supported on x86_64 and i686, those are the
> blessed bootstrap downloads we have currently.
> 
> For most of the others on the list I believe I have built them
> successfully on my pine64, going down to weather -c 100 or 75. Clisp
> definitely built.
> 
> > --
> > 3509 packages are missing from 'https://ci.guix.gnu.org' for 
> > 'aarch64-linux', among which:
> >   2193  llvm@11.0.0 
> > /gnu/store/b9mk756wjyrrf51aw2sbjk2cmi6v1xvl-llvm-11.0.0-opt-viewer 
> > /gnu/store/kn6lssvq2akf7pq36krdxc3w8fir7cwv-llvm-11.0.0 
> >   1988  rust@1.21.0 
> > /gnu/store/7r6n32fz9cyyr5yv0505nw6c8w93g2mv-rust-1.21.0-cargo 
> > /gnu/store/04dy3g0dmzhz5djakgd44lm8xnw871l0-rust-1.21.0-doc 
> > /gnu/store/lf6kyhsdn2l0namvzhn2hm7rmv7zm6h2-rust-1.21.0 
> >792  clisp@2.49-92   
> > /gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 
> >781  ghc@7.10.2  
> > /gnu/store/gi463h584b8r7krdbp3dzb7hx3nv83fy-ghc-7.10.2-doc 
> > /gnu/store/y32p7z1569qzmc4z3yx592l3w7x2zcai-ghc-7.10.2 
> >682  python-cryptography-vectors@3.3.1   
> > /gnu/store/4n2kcsvxlh0n3rvpjgrfvs8pi5nh5b6i-python-cryptography-vectors-3.3.1
> >  
> >576  nss-certs@3.59  
> > /gnu/store/n43chb4cpgn5cwj73d4bywq6vvahiqxa-nss-certs-3.59 
> >337  go@1.4-bootstrap-20171003   
> > /gnu/store/cxm5py5p7wwgskjlfn6009mwql906884-go-1.4-bootstrap-20171003-doc 
> > /gnu/store/h5bbkxnad8lxvp2kqpmfz26wbv5w9i6h-go-1.4-bootstrap-20171003 
> > /gnu/store/qwr2kwxmmj6zyibgl586qx0gl7vq6hl2-go-1.4-bootstrap-20171003-tests 
> >244  php@7.4.14  
> > /gnu/store/2pzqq029qg9k2ybp0zbkzc9syfj5s1qy-php-7.4.14 
> >186  openbox@3.6.1   
> > /gnu/store/ydsy5zxg6hlp19v4cxyl7m7agkrqxxpa-openbox-3.6.1 
> >181  kcoreaddons@5.70.0  
> > /gnu/store/jgvqvcyrq02b6bsn7fhbdpsrqmpxczv6-kcoreaddons-5.70.0 
> > 
> 
> -- 
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted



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


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability aarch64-linux]

[Efraim Flashner]

On Wed, Jan 13, 2021 at 06:38:39PM -0500, Leo Famulari wrote:
> For aarch64-linux, the biggest problems are LLVM and Rust, but there are
> other major problems such as nss-certs.
> 
> Are LLVM and Rust expected to work on this platform within Guix? What
> about GHC?

llvm should work, I'll start a build now on my pine64 and see how it
goes. GHC has only ever been supported on x86_64 and i686, those are the
blessed bootstrap downloads we have currently.

For most of the others on the list I believe I have built them
successfully on my pine64, going down to weather -c 100 or 75. Clisp
definitely built.

> --
> 3509 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', 
> among which:
>   2193llvm@11.0.0 
> /gnu/store/b9mk756wjyrrf51aw2sbjk2cmi6v1xvl-llvm-11.0.0-opt-viewer 
> /gnu/store/kn6lssvq2akf7pq36krdxc3w8fir7cwv-llvm-11.0.0 
>   1988rust@1.21.0 
> /gnu/store/7r6n32fz9cyyr5yv0505nw6c8w93g2mv-rust-1.21.0-cargo 
> /gnu/store/04dy3g0dmzhz5djakgd44lm8xnw871l0-rust-1.21.0-doc 
> /gnu/store/lf6kyhsdn2l0namvzhn2hm7rmv7zm6h2-rust-1.21.0 
>792clisp@2.49-92   
> /gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 
>781ghc@7.10.2  
> /gnu/store/gi463h584b8r7krdbp3dzb7hx3nv83fy-ghc-7.10.2-doc 
> /gnu/store/y32p7z1569qzmc4z3yx592l3w7x2zcai-ghc-7.10.2 
>682python-cryptography-vectors@3.3.1   
> /gnu/store/4n2kcsvxlh0n3rvpjgrfvs8pi5nh5b6i-python-cryptography-vectors-3.3.1 
>576nss-certs@3.59  
> /gnu/store/n43chb4cpgn5cwj73d4bywq6vvahiqxa-nss-certs-3.59 
>337go@1.4-bootstrap-20171003   
> /gnu/store/cxm5py5p7wwgskjlfn6009mwql906884-go-1.4-bootstrap-20171003-doc 
> /gnu/store/h5bbkxnad8lxvp2kqpmfz26wbv5w9i6h-go-1.4-bootstrap-20171003 
> /gnu/store/qwr2kwxmmj6zyibgl586qx0gl7vq6hl2-go-1.4-bootstrap-20171003-tests 
>244php@7.4.14  
> /gnu/store/2pzqq029qg9k2ybp0zbkzc9syfj5s1qy-php-7.4.14 
>186openbox@3.6.1   
> /gnu/store/ydsy5zxg6hlp19v4cxyl7m7agkrqxxpa-openbox-3.6.1 
>181kcoreaddons@5.70.0  
> /gnu/store/jgvqvcyrq02b6bsn7fhbdpsrqmpxczv6-kcoreaddons-5.70.0 
> 

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


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability armhf-linux]

[Vincent Legoll]

On Sun, Jan 17, 2021 at 12:01 PM Mathieu Othacehe  wrote:
> you should be able to download this image.

Yep, I DL'ed and got the same result as with my own images, so my
building is not be the problem.

> Yes looks like the search pagination and ordering is broken, those are
> definitely bugs that you can report.

Done : https://issues.guix.gnu.org/45936

-- 
Vincent Legoll

Re: Staging branch [substitute availability armhf-linux]

[Mathieu Othacehe]

> That's slightly different than what I have been doing, but
> the resulting image has the same problem than mine, no
> LCD output, nothing answering on serial console (@1.5Mbps
> (uboot speed) or 115.2Kbps (kernel speed, I think)).

Strange, seems that Caliph did manage to get a serial console. Caliph,
any insight here?

> Does cuirass only remove the link after a while after the image has
> been gc'ed ?

Yes turns out it was a regression due to PostgreSQL switch, this is now
solved and you should be able to download this image.

Mathieu

Re: Staging branch [substitute availability armhf-linux]

[Vincent Legoll]

On Sun, Jan 17, 2021 at 11:17 AM Mathieu Othacehe  wrote:
> --8<---cut here---start->8---
> guix build -f pinebook.scm
> --8<---cut here---end--->8---
>
> should achieve the same result locally.

That's slightly different than what I have been doing, but
the resulting image has the same problem than mine, no
LCD output, nothing answering on serial console (@1.5Mbps
(uboot speed) or 115.2Kbps (kernel speed, I think)).

> > That's where I searched, but did not find one with
> > the "Build outputs" link like the one you cited.
> >
> > Why is 190783 different from the 6 other ones returned
> > by this search query ?
>
> Because I just enabled build outputs production for Pinebook Pro images.

Does cuirass only remove the link after a while after the image has
been gc'ed ?

> > BTW, I think there is a problem in the way Cuirass web UI sorts
> > its results (apparently by oldest to newest, on the completion
> > time column) it looks like it is doing a string comparison, where
> > "32 minutes ago" is older than "37 hours ago". The "<< < > >>"
> > buttons also act strangely. Do you see such things ?
> > Should I report them as bugs ?
>
> Yes looks like the search pagination and ordering is broken, those are
> definitely bugs that you can report.

I'll do it later today

Thanks

-- 
Vincent Legoll

Re: Staging branch [substitute availability armhf-linux]

[Mathieu Othacehe]

Hello,

> trying to DL (in browser or with wget) the build output, by using
> the "https://ci.guix.gnu.org/download/190783; link, I get:
> error "Could not find the request build product."

Oh, it's already been garbage collected on Berlin, sorry about that
:(. I'll see what I can do. In the meantime, running the attached file
this way:

--8<---cut here---start->8---
guix build -f pinebook.scm
--8<---cut here---end--->8---

should achieve the same result locally.

> That's where I searched, but did not find one with
> the "Build outputs" link like the one you cited.
>
> Why is 190783 different from the 6 other ones returned
> by this search query ?

Because I just enabled build outputs production for Pinebook Pro images.

> BTW, I think there is a problem in the way Cuirass web UI sorts
> its results (apparently by oldest to newest, on the completion
> time column) it looks like it is doing a string comparison, where
> "32 minutes ago" is older than "37 hours ago". The "<< < > >>"
> buttons also act strangely. Do you see such things ?
> Should I report them as bugs ?

Yes looks like the search pagination and ordering is broken, those are
definitely bugs that you can report.

Mathieu


pinebook.scm
Description: Binary data

Re: Staging branch [substitute availability armhf-linux]

[Vincent Legoll]

Hello,

Thanks

On Sun, Jan 17, 2021 at 10:35 AM Mathieu Othacehe  wrote:
> You can download the latest Pinebook Pro image here:
>
> https://ci.guix.gnu.org/build/190783/details

trying to DL (in browser or with wget) the build output, by using
the "https://ci.guix.gnu.org/download/190783; link, I get:
error "Could not find the request build product."

> to search for the latest images:
>
> https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+status%3Asuccess+pinebook-pro

That's where I searched, but did not find one with
the "Build outputs" link like the one you cited.

Why is 190783 different from the 6 other ones returned
by this search query ?

BTW, I think there is a problem in the way Cuirass web UI sorts
its results (apparently by oldest to newest, on the completion
time column) it looks like it is doing a string comparison, where
"32 minutes ago" is older than "37 hours ago". The "<< < > >>"
buttons also act strangely. Do you see such things ?
Should I report them as bugs ?

Tchuss

-- 
Vincent Legoll

Re: Staging branch [substitute availability armhf-linux]

[Mathieu Othacehe]

Hello Vincent,

You can download the latest Pinebook Pro image here:

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

to search for the latest images:

https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+status%3Asuccess+pinebook-pro

Thanks,

Mathieu

Re: Staging branch [substitute availability armhf-linux]

[Vincent Legoll]

Hello,

> > I even attempted building the pinebook pro image without success.
>
> Hm... it's a shame we are building this and it doesn't work.

I only tried my locally built one, is there a substitute that I can try ?
That would tell if the problem is on my side or not.

> Do you also use some armhf (32-bit) hardware?

I would like. I tried and failed (I tried to build an image for an
orangepi+2e)

I have other non-x86 HW that I would like to have guixsd on.

I don't ask for susbstitutes, I can build them locally if needed and
doable.

-- 
Vincent Legoll

Re: Staging branch [substitute availability armhf-linux]

[Leo Famulari]

On Fri, Jan 15, 2021 at 09:27:36AM +0100, Vincent Legoll wrote:
> On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari  wrote:
> > Specifically about armhf, if anybody wants to use it with Guix, I hope
> > they will speak up.
> 
> I am interested, I have tried, and failed to get anything (apart from guix
> on foreign armbian). But I am more interested in guixsd though.

Okay, thanks for letting us know.

> I even attempted building the pinebook pro image without success.

Hm... it's a shame we are building this and it doesn't work.

Do you also use some armhf (32-bit) hardware?

Re: Staging branch [substitute availability]

[Christopher Baines]

Mathieu Othacehe  writes:

> Now, how to move on?
>
> First, I still need to connect the four overdrives machine to the new
> Cuirass remote building mechanism, and I would need some help for that
> (asked on guix-sysadmins). But, I'm not sure it will much improve the
> situation.
>
> Longer term, we need to figure out a better solution. It's now
> obvious that we do not have the computation power to build all our
> branches for 5 different architectures, relying heavily on emulation for
> armhf and aarch64. Anyone knows how Nix deals with that?

Providing that the more important builds/architectures are prioritised,
I don't think it's an all or nothing situation. For build farms
providing substitutes, it's more about the time taken to catch up with
changes.

When I've tried emulation, I've found there are too many errors that
only occur when emulating.


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability armhf-linux]

[Vincent Legoll]

Hello,

On Fri, Jan 15, 2021 at 10:54 AM Mathieu Othacehe  wrote:
> It seems that Caliph Nomble succeeded to build a Pinebook Pro image and
> booted it, without graphics, after a few fixes:
> https://issues.guix.gnu.org/45584.
>
> You may want to try again :).

DONE, it's a bit better, this time initrd, kernel & dtb loaded properly.

But serial output stopped after "Starting kernel ..." which is probably
because of mismatched serial port speed, but I tried to relaunch screen
with 57600, 115200 and still go no output. [complete uboot log attached]

LCD screen stays black which is probably normal.

The image was built like the following:

# ./pre-inst-env guix describe
Git checkout:
  repository: /home/vince/dev/repo/guix
  branch: master
  commit: c03875b0361f114634caeb54935fe37a9b7b05af
# echo "(use-modules (gnu system images pinebook-pro))
pinebook-pro-barebones-os" > /tmp/os.scm
# ./pre-inst-env guix system disk-image -t pinebook-pro-raw /tmp/os.scm
[...]
/gnu/store/5fj3aha8jsyji9mpqzf2krakl08r9zlw-disk-image

Next I'll try the hints from:
https://issues.guix.gnu.org/45584

> >> There is almost no armhf hardware that is suitable
> >> for a build-from-source distro in terms of performance, thermal design
> >> and suitable storage (SD cards will not last for unless you pay a huge
> >> amount for the absolute highest quality). Binary distros like Trisquel
> >> are a much better option for armhf.
> >
> > The cross buildability *should* be kind of a solution for this.
>
> Yes we could always decide to stop supporting native ARMv7 substitutes
> and only focus on the cross-building to provide ready to use image for
> this architecture.

Isn't there a way to reconcile the 2 ? At least theoretically cross- or native-
compilation should give identical output, though I dunno how far that
is from reality (probably not good, or we would be doing just that)

> >> All that is not a reason to not support armhf, but if nobody is using
> >> it, then we should officially deprecate it, and not leave it in this
> >> in-between state.
> >
> > I'm not using it because I can't make it work.
>
> Don't hesitate to report the issues you encountered!

I've done it a few times already, for armhf, arm64, powerpc64, mipsel.

And I'll (re-)try anything if I'm hinted as what to try next.

The main problem from my PoV is the scatteredness of the infos.

Tchuss

-- 
Vincent Legoll
DDR Version 1.20 20190314
In
channel 0
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 400MHz 0,1
channel 0
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
CS = 1
MR0=0x18
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 800MHz 1,0
Channel 0: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
256B stride
ch 0 ddrconfig = 0x101, ddrsize = 0x2020
ch 1 ddrconfig = 0x101, ddrsize = 0x2020
pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD
OUT
Boot1: 2019-03-14, version: 1.19
CPUId = 0x0
ChipType = 0x10, 251
SdmmcInit=2 0
BootCapSize=10
UserCapSize=119276MB
FwPartOffset=2000 , 10
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=30528MB
FwPartOffset=2000 , 0
StorageInit ok = 191888
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt...
GPT 0x3380ec0 signature is wrong
recovery gpt fail!
LoadTrust Addr:0x4000
LoadTrust Addr:0x4400
LoadTrust Addr:0x4800
LoadTrust Addr:0x4c00
LoadTrust Addr:0x5000
LoadTrust Addr:0x5400
LoadTrust Addr:0x5800
LoadTrust Addr:0x5c00
Addr:0x4000 No find trust.img!
LoadTrustBL error:-3
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt...
GPT 0x3380ec0 signature is wrong
recovery gpt fail!

Re: Staging branch [substitute availability armhf-linux]

[Mathieu Othacehe]

Hello Vincent,

> I even attempted building the pinebook pro image without success.

It seems that Caliph Nomble succeeded to build a Pinebook Pro image and
booted it, without graphics, after a few fixes:
https://issues.guix.gnu.org/45584.

You may want to try again :).

>> There is almost no armhf hardware that is suitable
>> for a build-from-source distro in terms of performance, thermal design
>> and suitable storage (SD cards will not last for unless you pay a huge
>> amount for the absolute highest quality). Binary distros like Trisquel
>> are a much better option for armhf.
>
> The cross buildability *should* be kind of a solution for this.

Yes we could always decide to stop supporting native ARMv7 substitutes
and only focus on the cross-building to provide ready to use image for
this architecture.

>> All that is not a reason to not support armhf, but if nobody is using
>> it, then we should officially deprecate it, and not leave it in this
>> in-between state.
>
> I'm not using it because I can't make it work.

Don't hesitate to report the issues you encountered!

Thanks,

Mathieu

Re: Staging branch [substitute availability armhf-linux]

[Mathieu Othacehe]

Hey Ludo,

> You seem to imply that the issue is the number of architectures, rather
> than the small number of ARMv7 build machines (now that we disabled
> 32-bit builds on AArch64).  Do I get it right?

Yes my point is that building three specifications on three
architectures, including an emulated one, is already hard for the build
farm, so adding more specifications/architectures seems complex.

Even if we fix the problem raised by Danny, enabling again ARMv7
transparent emulation, without any additional hardware wouldn't fit.

> That was a problem with Cuirass doing ‘build-derivations’ RPCs for
> derivations spanning multiple architectures (the RPC would complete once
> the slowest architecture is done), but maybe that’s no longer the case
> with the new remote builds feature you’ve been working on?

Yes, that's solved by the remote building feature. The workers are
declaring the architectures they support. When they request work, the
remote server picks randomly an architecture and select the most
priority build available. This way the queuing happens at the database
level and not in the guix-daemon itself.

Thanks,

Mathieu

Re: Staging branch [substitute availability armhf-linux]

[Vincent Legoll]

Hello,

On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari  wrote:
> Specifically about armhf, if anybody wants to use it with Guix, I hope
> they will speak up.

I am interested, I have tried, and failed to get anything (apart from guix
on foreign armbian). But I am more interested in guixsd though.

I even attempted building the pinebook pro image without success.

> I think we should monitor the volume of substitute requests per platform
> and see how big the demand for armhf Guix really is.

With the current situation, I'm not sure this would really be representative
of the armhf or arm64 demand.

> Although there is a huge amount of armhf hardware deployed, Guix seems a
> very poor fit for it.

In its current state.

> There is almost no armhf hardware that is suitable
> for a build-from-source distro in terms of performance, thermal design
> and suitable storage (SD cards will not last for unless you pay a huge
> amount for the absolute highest quality). Binary distros like Trisquel
> are a much better option for armhf.

The cross buildability *should* be kind of a solution for this.

> All that is not a reason to not support armhf, but if nobody is using
> it, then we should officially deprecate it, and not leave it in this
> in-between state.

I'm not using it because I can't make it work.

-- 
Vincent Legoll

Re: Staging branch [substitute availability i686-linux]

[Leo Famulari]

On Thu, Jan 14, 2021 at 11:37:39PM +0100, Ricardo Wurmus wrote:
> 
> Leo Famulari  writes:
> 
> > For i686-linux:
> >
> > Should we even be attempting to build Rust on this platform? Has it ever
> > worked? What about the ant-bootstrap?
> […]
> >580  ant-bootstrap@1.8.4 
> > /gnu/store/rb0r3r4vf3gd63bqinpkha9450yzvjm6-ant-bootstrap-1.8.4
> 
> This should work on i686 IIRC.

Indeed, it appears to have been built. Sorry for the noise.

Re: Staging branch [substitute availability armhf-linux]

[Leo Famulari]

On Thu, Jan 14, 2021 at 09:44:17AM +0100, Mathieu Othacehe wrote:
> Your weather summary is a great idea, thanks! As I said in my previous
> email, the armhf substitutes are not built right now on the CI. It's
> really sad but we have to make an impossible choice between:

Specifically about armhf, if anybody wants to use it with Guix, I hope
they will speak up. I would have expected to hear from users that they
were not getting any substitutes.

I think we should monitor the volume of substitute requests per platform
and see how big the demand for armhf Guix really is.

Although there is a huge amount of armhf hardware deployed, Guix seems a
very poor fit for it. There is almost no armhf hardware that is suitable
for a build-from-source distro in terms of performance, thermal design
and suitable storage (SD cards will not last for unless you pay a huge
amount for the absolute highest quality). Binary distros like Trisquel
are a much better option for armhf.

All that is not a reason to not support armhf, but if nobody is using
it, then we should officially deprecate it, and not leave it in this
in-between state.

Re: Staging branch [substitute availability i686-linux]

[Ricardo Wurmus]

Leo Famulari  writes:

> For i686-linux:
>
> Should we even be attempting to build Rust on this platform? Has it ever
> worked? What about the ant-bootstrap?
[…]
>580  ant-bootstrap@1.8.4 
> /gnu/store/rb0r3r4vf3gd63bqinpkha9450yzvjm6-ant-bootstrap-1.8.4

This should work on i686 IIRC.

-- 
Ricardo

Re: Staging branch [substitute availability]

[Ludovic Courtès]

Mathieu Othacehe  skribis:

> Since the introduction of the "wip-offload" branch on Cuirass, the
> situation has much improved. The workers are constantly building. For
> now we are building three specifications:
>
> * guix-modular-master
> * guix-master
> * staging

Yay!

> for x86_64, i686 and aarch64. If you look at the "Pending builds" chart
> here[1], you will see that the CI is barely catching up. That's because
> the "aarch64" emulated builds are incredibly slow, and monopolizing all
> the build resources.
>
> I deliberately chose to put armhf aside until I have a clearer view of
> the situation.
>
> Now, how to move on?
>
> First, I still need to connect the four overdrives machine to the new
> Cuirass remote building mechanism, and I would need some help for that
> (asked on guix-sysadmins). But, I'm not sure it will much improve the
> situation.

Oh sorry, I still haven’t caught up from vacation but I’ll take a look
if nobody beats me at it.

> Longer term, we need to figure out a better solution. It's now
> obvious that we do not have the computation power to build all our
> branches for 5 different architectures, relying heavily on emulation for
> armhf and aarch64. Anyone knows how Nix deals with that?

I’m not sure, but I know they rent storage and processing power from a
big transnational company, and that may well include AArch64.

Note that we disabled emulated builds and ARMv7 builds on AArch64 (!)
when Danny discovered the _FILE_OFFSET_BITS issue, which makes things
much worse.

With the x86_64 machines we have in Berlin, using emulated builds, even
if they’re slow, could potentially help noticeably.

At this point the biggest issue is ARMv7 because we have too little
actual hardware.

> I guess that other major distributions provide only cross-compiled
> packages for those architectures, but I don't think it's an option for
> us, Ludo?

Cross-compiled derivations are different derivations, so no, it’s not an
option.

If people know what hardware to get, and if we can find people to host
it, we have enough funds to buy it.  On IRC yesterday Leo mentioned a
good-looking AArch64 board:

  https://shop.solid-run.com/product/SRLX216S00D00GE064H07CH/

For ARMv7, there are probably several known-good options like those by
Olimex, BeagleBoard (I think?) and the likes.

For any such candidate, we need to (1) check it can be used with free
software only, (2) check things like provided storage space, whether a
case is available, etc., and (3) plan for purchase and hosting.
Volunteers needed!

Thanks,
Ludo’.

Re: Staging branch [substitute availability armhf-linux]

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> Your weather summary is a great idea, thanks! As I said in my previous
> email, the armhf substitutes are not built right now on the CI. It's
> really sad but we have to make an impossible choice between:
>
> * Trying to build everything on all architecture and have the CI that is
>   awfully lagging behind.
>
> * Restrict the number of architecture we want to provide substitutes
>   for.

You seem to imply that the issue is the number of architectures, rather
than the small number of ARMv7 build machines (now that we disabled
32-bit builds on AArch64).  Do I get it right?

That was a problem with Cuirass doing ‘build-derivations’ RPCs for
derivations spanning multiple architectures (the RPC would complete once
the slowest architecture is done), but maybe that’s no longer the case
with the new remote builds feature you’ve been working on?

Ludo’.

Re: Staging branch [substitute availability]

[Tobias Geerinckx-Rice]

Mathieu,

Mathieu Othacehe 写道：
As I said, the new remote building Cuirass mechanism is not yet 
deployed

on those machines and I would need someone with login access to
reconfigure those machines for me.


I reconfigured dmitri and have now also restarted guix-daemon.

Is there anything more I need to do?  Remotely rebooting has 
proven risky in the past.


The situation is worse for x86_64: 96% idleness based on 
/proc/uptime.  Am I

misinterpreting?


On what machine?


All build nodes (141.*).

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability]

[Mathieu Othacehe]

Hello Jonathan,

> I can not speak for Nix, but openSUSE has around 10 more or less powerful ARM 
> servers for native building. See https://build.opensuse.org/monitor

Thanks for sharing, I like very much the design of this page, I might
take some ideas from it to improve https://ci.guix.gnu.org/workers.

> Some weeks ago i did some research on ARM servers. TL;DR There are some
> options, even fast ones, but its not easy to found shops who sell them and
> have them in stock...

True, you even proposed to contact Linaro to see if they were willing to
provide us some aarch64 VM. I think it would be great :).

Thanks,

Mathieu

Re: Staging branch [substitute availability armhf-linux]

[zimoun]

Hi Mathieu,

I have not read carefully all the emails on the topic, so I am
probably out-of-scope.

On Thu, 14 Jan 2021 at 09:44, Mathieu Othacehe  wrote:

> * Trying to build everything on all architecture and have the CI that is
>   awfully lagging behind.
>
> * Restrict the number of architecture we want to provide substitutes
>   for.

Maybe we could use Bayfront and the recent Fosshost donation
differently and so use them to cross-compile, removing the x86 builds
on them.

Cheers,
simon

Re: Staging branch [substitute availability]

[Mathieu Othacehe]

Hello Tobias,

> I don't think it's obvious and I don't think it's true.

Well obvious was a poor choice of word. But I've been spending several
weeks/months monitoring Berlin and I think I'm starting to have a good
overview of the situation.

This new page[1] shows what the build machines are doing. There are two
workers per machine, and they are always busy as far as I can tell.

If you have a look to the "Pending builds" chart here[2], you will see
that it took 4 days to absorb the ~7000 builds that were added the 9/10th
of January.

Building chromium for aarch64 takes more than 24 hours and will take one
whole worker down for instance. Now think about Linux, webkitgtk and
imagine that we also want to build the core-updates branch and the armhf
architecture, I don't see how it could fit without lagging weeks behind.

> Only because we don't use the non-emulated hardware.  Our (currently 3, one
> crashed) Overdrives 1000 sit idle for ~90% of the time.

As I said, the new remote building Cuirass mechanism is not yet deployed
on those machines and I would need someone with login access to
reconfigure those machines for me.

> The situation is worse for x86_64: 96% idleness based on /proc/uptime.  Am I
> misinterpreting?

On what machine? If it's on the Berlin main node, it's by design. We
don't want the main machine to build things as it interferes too much
with the other stuff happening on that machine such as gc'ing a huge store,
hosting Cuirass and other services.

Thanks,

Mathieu

[1]: https://ci.guix.gnu.org/workers
[2]: https://ci.guix.gnu.org/metrics

Re: Staging branch [substitute availability]

[Tobias Geerinckx-Rice]

Mathieu!

Mathieu Othacehe 写道：

Longer term, we need to figure out a better solution. It's now
obvious that we do not have the computation power to build all 
our

branches for 5 different architectures


I don't think it's obvious and I don't think it's true.


relying heavily on emulation for armhf and aarch64.


Only because we don't use the non-emulated hardware.  Our 
(currently 3, one crashed) Overdrives 1000 sit idle for ~90% of 
the time.


The situation is worse for x86_64: 96% idleness based on 
/proc/uptime.  Am I misinterpreting?


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Staging branch [substitute availability]

[Jonathan Brielmaier]

Am Thu, 14 Jan 2021 09:39:41 +0100, Mathieu Othacehe schrieb:
> First, I still need to connect the four overdrives machine to the new
> Cuirass remote building mechanism, and I would need some help for that
> (asked on guix-sysadmins). But, I'm not sure it will much improve the
> situation.
>
> Longer term, we need to figure out a better solution. It's now
> obvious that we do not have the computation power to build all our
> branches for 5 different architectures, relying heavily on emulation for
> armhf and aarch64. Anyone knows how Nix deals with that?

I can not speak for Nix, but openSUSE has around 10 more or less powerful ARM 
servers for native building. See https://build.opensuse.org/monitor

Some weeks ago i did some research on ARM servers. TL;DR There are some 
options, even fast ones, but its not easy to found shops who sell them and have 
them in stock...

--
Sent from Ubuntu Touch

Re: Staging branch [substitute availability armhf-linux]

[Mathieu Othacehe]

> The armhf-linux platform is in the worst shape, both on the master and
> staging branches. It's a shame because it's also the least powerful,
> with almost no hardware thermally capable of sustained CPU usage, so
> users will have the worst experience building packages for it.
>
> Does anyone want to work on it? Should we just "fix it on the master
> branch?"

Your weather summary is a great idea, thanks! As I said in my previous
email, the armhf substitutes are not built right now on the CI. It's
really sad but we have to make an impossible choice between:

* Trying to build everything on all architecture and have the CI that is
  awfully lagging behind.

* Restrict the number of architecture we want to provide substitutes
  for.

Thanks,

Mathieu

Re: Staging branch [substitute availability]

[Mathieu Othacehe]

Hello Leo,

> --
> master branch
> aarch64: 66% 
> x86_64: 93% 
> i686: 85%
> armhf: 51%
>
> staging branch
> aarch64: 44% 
> x86_64: 80% 
> i686: 60%
> armhf: 30%
> --

Thanks for the figures. I can comment on some stuff. Until recently it
was hard to monitor the build farm status because there were a lot of
contention at the main guix-daemon level.

Since the introduction of the "wip-offload" branch on Cuirass, the
situation has much improved. The workers are constantly building. For
now we are building three specifications:

* guix-modular-master
* guix-master
* staging

for x86_64, i686 and aarch64. If you look at the "Pending builds" chart
here[1], you will see that the CI is barely catching up. That's because
the "aarch64" emulated builds are incredibly slow, and monopolizing all
the build resources.

I deliberately chose to put armhf aside until I have a clearer view of
the situation.

Now, how to move on?

First, I still need to connect the four overdrives machine to the new
Cuirass remote building mechanism, and I would need some help for that
(asked on guix-sysadmins). But, I'm not sure it will much improve the
situation.

Longer term, we need to figure out a better solution. It's now
obvious that we do not have the computation power to build all our
branches for 5 different architectures, relying heavily on emulation for
armhf and aarch64. Anyone knows how Nix deals with that?

I guess that other major distributions provide only cross-compiled
packages for those architectures, but I don't think it's an option for
us, Ludo?

Thanks,

Mathieu

[1]: https://ci.guix.gnu.org/metrics

Re: Staging branch [substitute availability aarch64-linux]

[John Soo]

 I’ve been working on ghc and making some progress. I’d love to have more 
support for rust but I’m not sure what the issue is.

Re: Staging branch [substitute availability i686-linux]

[Leo Famulari]

On Wed, Jan 13, 2021 at 06:33:04PM -0500, Leo Famulari wrote:
> The mesa test suite failure is reproducible, and it looks like this:
> 
> --
> 23:07:53 /tmp/guix-build-mesa-20.2.4.drv-0/build/src/util/u_debug_stack_test
> --- stdout ---
> Running main() from ../mesa-20.2.4/src/gtest/src/gtest_main.cc
> [==] Running 2 tests from 1 test suite.
> [--] Global test environment set-up.
> [--] 2 tests from u_debug_stack_test
> [ RUN  ] u_debug_stack_test.basics
> [   OK ] u_debug_stack_test.basics (0 ms)
> [ RUN  ] u_debug_stack_test.capture_not_overwritten
> ../mesa-20.2.4/src/util/u_debug_stack_test.cpp:108: Failure
> Expected: (bt1) != (bt2), actual: 
> "/tmp/guix-build-mesa-20.2.4.drv-0/build/src/util/u_debug_stack_test() 
> [0x8072555]
> " vs "/tmp/guix-build-mesa-20.2.4.drv-0/build/src/util/u_debug_stack_test() 
> [0x8072555]
> "
> [  FAILED  ] u_debug_stack_test.capture_not_overwritten (0 ms)

I've reported this upstream:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091

Re: Staging branch [substitute availability aarch64-linux]

[Leo Famulari]

For aarch64-linux, the biggest problems are LLVM and Rust, but there are
other major problems such as nss-certs.

Are LLVM and Rust expected to work on this platform within Guix? What
about GHC?

--
3509 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', 
among which:
  2193  llvm@11.0.0 
/gnu/store/b9mk756wjyrrf51aw2sbjk2cmi6v1xvl-llvm-11.0.0-opt-viewer 
/gnu/store/kn6lssvq2akf7pq36krdxc3w8fir7cwv-llvm-11.0.0 
  1988  rust@1.21.0 
/gnu/store/7r6n32fz9cyyr5yv0505nw6c8w93g2mv-rust-1.21.0-cargo 
/gnu/store/04dy3g0dmzhz5djakgd44lm8xnw871l0-rust-1.21.0-doc 
/gnu/store/lf6kyhsdn2l0namvzhn2hm7rmv7zm6h2-rust-1.21.0 
   792  clisp@2.49-92   
/gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 
   781  ghc@7.10.2  
/gnu/store/gi463h584b8r7krdbp3dzb7hx3nv83fy-ghc-7.10.2-doc 
/gnu/store/y32p7z1569qzmc4z3yx592l3w7x2zcai-ghc-7.10.2 
   682  python-cryptography-vectors@3.3.1   
/gnu/store/4n2kcsvxlh0n3rvpjgrfvs8pi5nh5b6i-python-cryptography-vectors-3.3.1 
   576  nss-certs@3.59  
/gnu/store/n43chb4cpgn5cwj73d4bywq6vvahiqxa-nss-certs-3.59 
   337  go@1.4-bootstrap-20171003   
/gnu/store/cxm5py5p7wwgskjlfn6009mwql906884-go-1.4-bootstrap-20171003-doc 
/gnu/store/h5bbkxnad8lxvp2kqpmfz26wbv5w9i6h-go-1.4-bootstrap-20171003 
/gnu/store/qwr2kwxmmj6zyibgl586qx0gl7vq6hl2-go-1.4-bootstrap-20171003-tests 
   244  php@7.4.14  /gnu/store/2pzqq029qg9k2ybp0zbkzc9syfj5s1qy-php-7.4.14 
   186  openbox@3.6.1   
/gnu/store/ydsy5zxg6hlp19v4cxyl7m7agkrqxxpa-openbox-3.6.1 
   181  kcoreaddons@5.70.0  
/gnu/store/jgvqvcyrq02b6bsn7fhbdpsrqmpxczv6-kcoreaddons-5.70.0 
   180  ki18n@5.70.0
/gnu/store/m5rk1z8kv9blrwfy045zwh4sh8mbflyk-ki18n-5.70.0 
   179  kconfig@5.70.0  
/gnu/store/i5fim2lrykyvnvqszmi40n4lf1bh2rfq-kconfig-5.70.0 
   178  openbox@3.6.1   
/gnu/store/ydsy5zxg6hlp19v4cxyl7m7agkrqxxpa-openbox-3.6.1 
   178  ki18n@5.70.0
/gnu/store/m5rk1z8kv9blrwfy045zwh4sh8mbflyk-ki18n-5.70.0 
   178  karchive@5.70.0 
/gnu/store/39ln3kibfqnl0p8i9465dmvg1kzdqn6j-karchive-5.70.0 
   176  kcoreaddons@5.70.0  
/gnu/store/jgvqvcyrq02b6bsn7fhbdpsrqmpxczv6-kcoreaddons-5.70.0 
   176  kwidgetsaddons@5.70.0   
/gnu/store/pvljcxdlnhl6311494jxfp27b1z2l16f-kwidgetsaddons-5.70.0 
   175  kcodecs@5.70.0  
/gnu/store/r47szv81m0nf6l4acs12yhzj79i1zrbn-kcodecs-5.70.0 
   174  karchive@5.70.0 
/gnu/store/39ln3kibfqnl0p8i9465dmvg1kzdqn6j-karchive-5.70.0 
   174  kdbusaddons@5.70.0  
/gnu/store/00av6cmj7sfz19if37kivhvrfn4bcm34-kdbusaddons-5.70.0 
   174  kguiaddons@5.70.0   
/gnu/store/xya6mpz330680v72rvs9i85374872r66-kguiaddons-5.70.0 
   173  kitemviews@5.70.0   
/gnu/store/djndnnrl9ih1a0i5d6bxmw5ccl609jiy-kitemviews-5.70.0 
   171  sonnet@5.70.0   
/gnu/store/z70fsxk28qcdlzd91zynykprdpdywkqx-sonnet-5.70.0 
   170  kconfig@5.70.0  
/gnu/store/i5fim2lrykyvnvqszmi40n4lf1bh2rfq-kconfig-5.70.0 
   170  libpipeline@1.5.3   
/gnu/store/6qi0yj1i61py5mhg02vll8b6gbjilngl-libpipeline-1.5.3 
   170  phonon@4.11.1   
/gnu/store/0ilawnnli4l3xxnlc0930yyqfjrbd2z7-phonon-4.11.1 
   170  attica@5.70.0   
/gnu/store/axdap0dmkxdibxz45qvxm91qyqjg4hjw-attica-5.70.0 
   169  qgpgme@1.15.0   
/gnu/store/zrrs3hpqcif5rbw98qkl686lb910wsj2-qgpgme-1.15.0 
   168  solid@5.70.0
/gnu/store/n37dfll0wmnlzjimx1vwnm2a0d05wkvf-solid-5.70.0 
   166  kwidgetsaddons@5.70.0   
/gnu/store/pvljcxdlnhl6311494jxfp27b1z2l16f-kwidgetsaddons-5.70.0 
   166  kcodecs@5.70.0  
/gnu/store/r47szv81m0nf6l4acs12yhzj79i1zrbn-kcodecs-5.70.0 
   164  kwayland@5.70.0 
/gnu/store/9q7cf9cqdxi733sh44bz9zmqis718xak-kwayland-5.70.0 
   162  kguiaddons@5.70.0   
/gnu/store/xya6mpz330680v72rvs9i85374872r66-kguiaddons-5.70.0 
   160  kitemviews@5.70.0   
/gnu/store/djndnnrl9ih1a0i5d6bxmw5ccl609jiy-kitemviews-5.70.0 
   154  phonon@4.11.1   
/gnu/store/0ilawnnli4l3xxnlc0930yyqfjrbd2z7-phonon-4.11.1 
   153  sonnet@5.70.0   
/gnu/store/z70fsxk28qcdlzd91zynykprdpdywkqx-sonnet-5.70.0 
   153  r-survival@3.2-7
/gnu/store/ddcrdwp4fvqnnpak2n795lxa8v43swli-r-survival-3.2-7 
   152  solid@5.70.0
/gnu/store/n37dfll0wmnlzjimx1vwnm2a0d05wkvf-solid-5.70.0 
   152  attica@5.70.0   
/gnu/store/axdap0dmkxdibxz45qvxm91qyqjg4hjw-attica-5.70.0 
   150  qgpgme@1.15.0   
/gnu/store/zrrs3hpqcif5rbw98qkl686lb910wsj2-qgpgme-1.15.0 
   150  modem-manager@1.12.10   
/gnu/store/7qpsk5dc3dzpf7zylhw8gdzi7k1whj2j-modem-manager-1.12.10 
   127  python-sphinx-rtd-theme@0.2.4   
/gnu/store/lxpil9q4mamlz9m1xndy6f9ai31lxh6s-python-sphinx-rtd-theme-0.2.4 
   123  libwpe@1.6.0
/gnu/store/g2n55ynaq6155hrcqbcb99r6fmmw1f16-libwpe-1.6.0 
   112  python2-pytz@2020.4 
/gnu/store/0fdd13lnfdkr9ryd092qzy2b295izf8q-python2-pytz-2020.4 
   105  python-xcffib@0.6.0 
/gnu/store/w60lrz19jm405qxclk2jj136a8zgk6s3-python-xcffib-0.6.0 
96  python-tornado@5.1.1
/gnu/store/45s91xh8widqr96q1zwlp3naj6a37x84-python-tornado-5.1.1 
85  ruby-mysql2@0.5.2   
/gnu/store/4qzyr50njifdxdllgx8a3pzm78x9wpc0-ruby-mysql2-0.5.2 
85  python-numpydoc@0.8.0   

Re: Staging branch [substitute availability armhf-linux]

[Leo Famulari]

The armhf-linux platform is in the worst shape, both on the master and
staging branches. It's a shame because it's also the least powerful,
with almost no hardware thermally capable of sustained CPU usage, so
users will have the worst experience building packages for it.

Does anyone want to work on it? Should we just "fix it on the master
branch?"

--
3301 packages are missing from 'https://ci.guix.gnu.org' for 'armhf-linux', 
among which:
  2695  gdk-pixbuf@2.40.0   
/gnu/store/xjdgypav5vcl4pyc388cs6gr5hv73fvp-gdk-pixbuf-2.40.0 
  2277  imagemagick@6.9.11-48   
/gnu/store/gjb5j8yf7aynicmfsxwqnwzhjp2sp6i8-imagemagick-6.9.11-48-doc 
/gnu/store/vnpms2y3g9wrkl550zk0gh5vx9rb5hym-imagemagick-6.9.11-48 
  2239  elfutils@0.182  
/gnu/store/kbdmbs8h83kqya6wqjisjm6snbnjxpff-elfutils-0.182-bin 
/gnu/store/iy8q5i7fa9c347r34lllrvbqzh6lwrfr-elfutils-0.182 
  2194  libdrm@2.4.103  
/gnu/store/i6ydsdg2ha6k40s5vrqh5c5wqkkhx0i8-libdrm-2.4.103 
  2188  glslang@10-11.0.0   
/gnu/store/xvw9jbfqrjv5pc8d1ckni72y6mwll2ay-glslang-10-11.0.0 
  1990  rust@1.19.0 
/gnu/store/jgbkdpxrf18q3yms4a1apzkawsqhzqkr-rust-1.19.0-cargo 
/gnu/store/2zmswj21202j7xfli9aizz6a9k6pkfvd-rust-1.19.0 
  1861  xkbcomp-intermediate@1.4.4  
/gnu/store/c61lfs091rv4pa405rxcqzxn9hzvdlyn-xkbcomp-intermediate-1.4.4 
  1665  tzdata@2020f
/gnu/store/ix7dkzsc2g2028xxqirwmjlprdiarhsa-tzdata-2020f 
  1331  libcap@2.45 /gnu/store/rcx340qk9dcs7lck86xba8fmbwn132vm-libcap-2.45 
  1093  postgresql@13.1 
/gnu/store/bcgry8jrhs9d5z532yhacf2zzzviyzqi-postgresql-13.1 
   964  mariadb@10.5.8  
/gnu/store/3fa29zjsb48279g3qifa5fjlihx6wzvy-mariadb-10.5.8-dev 
/gnu/store/hxg1mynghbs1frnnwx2vb84ywj912a8j-mariadb-10.5.8-lib 
/gnu/store/67zkwlflvmj2mia67ifx07rzb3m2vyfn-mariadb-10.5.8 
   872  xprop@1.2.5 /gnu/store/2yj1m9xpil630qcry3psw6pg5nc7j8gh-xprop-1.2.5 
   855  libinput-minimal@1.16.4 
/gnu/store/zyr2hl2bsqxw63kr67p6nycdpmyng1f9-libinput-minimal-1.16.4 
   830  vulkan-headers@1.2.164  
/gnu/store/41gwjqma4whf6dvfif9d02fmmfa80bdr-vulkan-headers-1.2.164 
   788  sbcl@2.1.0  
/gnu/store/3dvfa85ycrpxbj208yfwikl0n33lavwi-sbcl-2.1.0-doc 
/gnu/store/1b7qwyv732n28gahwpjagv3xjjlpm2ik-sbcl-2.1.0 
   784  patchelf@0.11   
/gnu/store/ww555zg4njj4acr12qhbl8xjq9dzdg7f-patchelf-0.11 
   749  python-pytz@2020.4  
/gnu/store/lx2iqg2cpyi2ds1qqszav3vrf68hli5i-python-pytz-2020.4 
   739  python-cffi@1.14.4  
/gnu/store/x27rkkrp2dw3j0v0n3izd513kzxha6qp-python-cffi-1.14.4 
   714  python-iso8601@0.1.13   
/gnu/store/68b8mqbgsvdaqnrp3414sxqwymlpn29y-python-iso8601-0.1.13 
   682  python-cryptography-vectors@3.3.1   
/gnu/store/v3jjq6dmsf9l62pbfmz3502wc0fdixbh-python-cryptography-vectors-3.3.1 
   667  python-certifi@2020.12.5
/gnu/store/rbw7ni2f13s2fgxw825ygd5lpa1j2nw4-python-certifi-2020.12.5 
   619  gstreamer@1.18.2
/gnu/store/355qdcpy3dnv4yjpgrdxbgwk1hi03fw3-gstreamer-1.18.2 
   582  classpath@0.93  
/gnu/store/5hy2cdkjscq5546ym6jkf048dyick7cd-classpath-0.93 
   576  nss-certs@3.59  
/gnu/store/p131lkj2mhiq5dbl4snlkaachvlivbjy-nss-certs-3.59 
   511  python-pygments@2.7.3   
/gnu/store/4mzgxp6bsx4zk7xylr7hm5l8d7bby1x6-python-pygments-2.7.3 
   401  shadow@4.8.1
/gnu/store/lxnfvrkijw9awbrw47vx4nmra2dmpa16-shadow-4.8.1 
   245  git@2.30.0  
/gnu/store/xvpmhk29ykscfdpfyjhpyrhahi6rck19-git-2.30.0-credential-netrc 
/gnu/store/fnyrbmzxhcgbpl300irpycr8fy85dqrs-git-2.30.0-gui 
/gnu/store/klswflk1cqn723i0hyzxg3vv2wicrb5k-git-2.30.0 
/gnu/store/06f3b2igianyqwic7jp2c216lb98w6jb-git-2.30.0-send-email 
/gnu/store/7i9clx90q28b966aypr8g3yhrvqd1b3z-git-2.30.0-subtree 
/gnu/store/zlc18bbhbgc7lzjk5xqw5p54a0jrr8l3-git-2.30.0-svn 
   234  gsasl@1.10.0
/gnu/store/gs1mgdfxd7il90ij78zl9jdfrg2j7dcq-gsasl-1.10.0 
   227  gdk-pixbuf@2.40.0   
/gnu/store/xjdgypav5vcl4pyc388cs6gr5hv73fvp-gdk-pixbuf-2.40.0 
   222  libdrm@2.4.103  
/gnu/store/i6ydsdg2ha6k40s5vrqh5c5wqkkhx0i8-libdrm-2.4.103 
   221  elfutils@0.182  
/gnu/store/kbdmbs8h83kqya6wqjisjm6snbnjxpff-elfutils-0.182-bin 
/gnu/store/iy8q5i7fa9c347r34lllrvbqzh6lwrfr-elfutils-0.182 
   218  imagemagick@6.9.11-48   
/gnu/store/gjb5j8yf7aynicmfsxwqnwzhjp2sp6i8-imagemagick-6.9.11-48-doc 
/gnu/store/vnpms2y3g9wrkl550zk0gh5vx9rb5hym-imagemagick-6.9.11-48 
   217  xkbcomp-intermediate@1.4.4  
/gnu/store/c61lfs091rv4pa405rxcqzxn9hzvdlyn-xkbcomp-intermediate-1.4.4 
   216  libcap@2.45 /gnu/store/rcx340qk9dcs7lck86xba8fmbwn132vm-libcap-2.45 
   216  tzdata@2020f
/gnu/store/ix7dkzsc2g2028xxqirwmjlprdiarhsa-tzdata-2020f 
   214  xprop@1.2.5 /gnu/store/2yj1m9xpil630qcry3psw6pg5nc7j8gh-xprop-1.2.5 
   213  postgresql@13.1 
/gnu/store/bcgry8jrhs9d5z532yhacf2zzzviyzqi-postgresql-13.1 
   213  mariadb@10.5.8  
/gnu/store/3fa29zjsb48279g3qifa5fjlihx6wzvy-mariadb-10.5.8-dev 
/gnu/store/hxg1mynghbs1frnnwx2vb84ywj912a8j-mariadb-10.5.8-lib 
/gnu/store/67zkwlflvmj2mia67ifx07rzb3m2vyfn-mariadb-10.5.8 
   213  libinput-minimal@1.16.4 

Re: Staging branch [substitute availability i686-linux]

[Leo Famulari]

For i686-linux:

Should we even be attempting to build Rust on this platform? Has it ever
worked? What about the ant-bootstrap?

The mesa test suite failure is reproducible, and the error messages are
found below.

--
2286 packages are missing from 'https://ci.guix.gnu.org' for 'i686-linux', 
among which:
  2179  mesa@20.2.4 
/gnu/store/y2pqvr7297q7pkj82qrgwvsvfg2mvbam-mesa-20.2.4-bin 
/gnu/store/isx9ra95v8gw3fqgrvz62cwrlzl5s5y7-mesa-20.2.4
  1990  rust@1.19.0 
/gnu/store/cazsr6swdp457h6j2df9slmsrv45bqvq-rust-1.19.0-cargo 
/gnu/store/p9sj678d8sk9wqp86gqq1ghl5w1alrk4-rust-1.19.0
   580  ant-bootstrap@1.8.4 
/gnu/store/rb0r3r4vf3gd63bqinpkha9450yzvjm6-ant-bootstrap-1.8.4
   220  mesa@20.2.4 
/gnu/store/y2pqvr7297q7pkj82qrgwvsvfg2mvbam-mesa-20.2.4-bin 
/gnu/store/isx9ra95v8gw3fqgrvz62cwrlzl5s5y7-mesa-20.2.4
   149  protobuf@3.14.0 
/gnu/store/6d54h23b86hs9y8y6528962sbg8qd43n-protobuf-3.14.0 
/gnu/store/hfarq203gg3hh2q179zabidh0rlcjbp5-protobuf-3.14.0-static
69  ucx@1.6.1   /gnu/store/rw5qfppz6pjzvxlir7ad67znww6nrc8d-ucx-1.6.1
68  psm2@11.2.86/gnu/store/8cqcmlww41srcihcl30fqllzs0xajw4n-psm2-11.2.86
46  htslib@1.9  /gnu/store/m58c8bc9b4v8ij0w5vd6q2da27rvmx3z-htslib-1.9
44  htslib@1.11 /gnu/store/a9g55dfay50aiwxiwxaw001b9fkcdn1f-htslib-1.11
42  go-gopkg-in-yaml-v2@2.2.2   
/gnu/store/7ynxpa5r5j17np17g9d74dkbbjrvi6fb-go-gopkg-in-yaml-v2-2.2.2
40  ruby-ruby-prof@1.4.1
/gnu/store/5j9v7afqi0qhkna8izza5hppg1q7q79d-ruby-ruby-prof-1.4.1
31  python-gevent@20.9.0
/gnu/store/2nl53qjhm429pdj3vf2czlkfq7fg83ir-python-gevent-20.9.0
30  python2-numpydoc@0.8.0  
/gnu/store/f9i0psw9kwljfkfprwja53lmn3h7qd5q-python2-numpydoc-0.8.0
28  python2-pympler@0.8 
/gnu/store/a6gvqx4876mddscz0a1109fp1qr11lvd-python2-pympler-0.8
28  libgeotiff@1.5.1
/gnu/store/2mk87lgadgclnkzh3fq44qwnrrzd3sg9-libgeotiff-1.5.1
23  python-networkx@2.5 
/gnu/store/dq3gld1h74w7a6z5fll2byf19rflr4rs-python-networkx-2.5
21  rakudo@2019.03.1
/gnu/store/l2w4b9bbkg4dwmvyz3c8la8h2i18kl3v-rakudo-2019.03.1
20  python2-twisted@19.7.0  
/gnu/store/nzv3qhggqawwpzmj65p2hcg8iqi1j22f-python2-twisted-19.7.0
19  ocaml-migrate-parsetree@1.7.3   
/gnu/store/7mkcrkqxs27vxsxvnx0ddd9m8p7ml21s-ocaml-migrate-parsetree-1.7.3
16  python2-zope-testrunner@5.2 
/gnu/store/ya3l6fa2cnlsr3kxsxlh1zqxvvq9k4xs-python2-zope-testrunner-5.2
15  r-assertive-base@0.0-7  
/gnu/store/z5akvxvl6g3gnlbf7q3jp43gjfxq9vrc-r-assertive-base-0.0-7
14  python-arrow@0.17.0 
/gnu/store/3b6fmmsx3bywk4js088kq06vmsg8y1v8-python-arrow-0.17.0
13  mono@4.4.1.0/gnu/store/k84fvwkv58440cmi52yzycl3v56klxmx-mono-4.4.1.0
12  r-webshot@0.5.2 
/gnu/store/fqszb150xjm8y516ms8n3my9dy5p1sri-r-webshot-0.5.2
12  r-flowcore@2.2.0
/gnu/store/z1sscs431wg86lgg2iarg7xhqvdysbk7-r-flowcore-2.2.0
12  r-registry@0.5-1
/gnu/store/s4yc8ah2hfw7ir0wyw8iza9m6m07dxsr-r-registry-0.5-1
12  guile@1.8.8 /gnu/store/j6mnhk6iiy77m1ial0ffgjz2zwdc6m4z-guile-1.8.8
11  scalapack@2.0.2 
/gnu/store/ayrbfdfcq33r1xmxln6jvkw7x6jis9xn-scalapack-2.0.2
11  hdf5-parallel-openmpi@1.10.7
/gnu/store/a8x6s1d6wh1ga35vjd7z49jh6zr28hmq-hdf5-parallel-openmpi-1.10.7-fortran
 /gnu/store/a58wsdqhs1gq5sa9cvnwr14i0ydq4xcp-hdf5-parallel-openmpi-1.10.7
11  clang@11.0.0
/gnu/store/lq4jhyjd1027i5nf6kafp3xjxb6fnilb-clang-11.0.0-extra 
/gnu/store/04hvxidk3rpy8x977nkq9vpa27svny40-clang-11.0.0
11  r-corrplot@0.84 
/gnu/store/26izpmf2m5pdf7sq7b30yfw1zagl30wb-r-corrplot-0.84
11  cmake@3.19.2
/gnu/store/v78kmw21l0dnzqrwb3bdfcjhhvqjhbic-cmake-3.19.2-doc 
/gnu/store/3ll779l3viph275svivhc59krla4byxs-cmake-3.19.2
11  r-sandwich@3.0-0
/gnu/store/qjqjvz4l92dg96fan9z5lv0ssdi30k64-r-sandwich-3.0-0
11  ghc-ieee754@0.8.0   
/gnu/store/4lyzys7v1chzy5a64697pazwhdss55gb-ghc-ieee754-0.8.0 
/gnu/store/3hnmkxbp5gxxjp0vjw4vp0vqf2spy626-ghc-ieee754-0.8.0-static
10  dune-common@2.7.0   
/gnu/store/pfdcjaicifq42b3siwycmry7i969cvrv-dune-common-2.7.0
10  dune-common-openmpi@2.7.0   
/gnu/store/6wy9w4crxz2bqvj3c10g5b18n8zj656d-dune-common-openmpi-2.7.0
10  ghc-half@0.3
/gnu/store/q17zfd341rd4yzcvq2fd63g2dr5pd1yd-ghc-half-0.3 
/gnu/store/z9qi2sgnbx1s5fzx49809587gd30kdb5-ghc-half-0.3-static
10  r-hdrcde@3.3/gnu/store/m69lkzmxkicpbc6rg1r220bh393izw5v-r-hdrcde-3.3
10  abseil-cpp@20200225.2   
/gnu/store/fbx5lzmhjaywqdwx7pxky4nkfpsdjc08-abseil-cpp-20200225.2
10  ghc-bytes@0.15.5
/gnu/store/w8bpqvzjkzcxiccfscmdm6pv869m5n38-ghc-bytes-0.15.5 
/gnu/store/m8f9afzgbz6jkz0fpl63vhpl8g7k8asd-ghc-bytes-0.15.5-static
10  r-future-apply@1.6.0
/gnu/store/m103jmmcsijgsh5778hs8s6la62ahlka-r-future-apply-1.6.0
10  r-rsvd@1.0.3/gnu/store/q53slf7d22p12hka5064awn99y36flka-r-rsvd-1.0.3
10  ghc-hashtables@1.2.3.4  
/gnu/store/qh86n6f6akzyb5a6x5qj9fig9wb641hq-ghc-hashtables-1.2.3.4 

Re: Staging branch [substitute availability x86_64-linux]

[Leo Famulari]

Here is the "missing package" report printed by `guix weather
--coverage=10` for x86_64-linux.

The Java packages at the top of this list are private packages, but 
substitutes are available for them. Maybe they should be public, but 
hidden?

Overall, I think the staging branch is ready for x86_64-linux.

--
2402 packages are missing from 'https://ci.guix.gnu.org' for 'x86_64-linux', 
among which:
   370  java-org-ow2-parent-pom@1.3 
/gnu/store/k7f85jn0g4r3pic9rcjxphm77w94pwqi-java-org-ow2-parent-pom-1.3 
   162  java-slf4j-parent@1.7.25
/gnu/store/h446mfbngdjxc1fv6xcpl9h9g78csplg-java-slf4j-parent-1.7.25 
   158  java-guava-parent-pom@20.0  
/gnu/store/lz2sahbgyrfwbjfq9ks2z8qww62wll30-java-guava-parent-pom-20.0 
   154  java-google-parent-pom@5
/gnu/store/ca2xl55bxgzhyn3iw49nvc9smixxcz5z-java-google-parent-pom-5 
   119  java-snappy@1.1.7.5 
/gnu/store/cq9x7m3nqdfw3kyxnzxjbkiy3ab8g75d-java-snappy-1.1.7.5 
   108  java-geronimo-genesis@2.1   
/gnu/store/wx7bffn53f6xfqiqvsqkb5b3zj5k8djk-java-geronimo-genesis-2.1 
74  java-plexus-containers-parent-pom@1.7.1 
/gnu/store/vqzh225cvjzcjvbzaa6706d6f4j4hb07-java-plexus-containers-parent-pom-1.7.1
 
52  plexus-components-parent-pom@4.0
/gnu/store/siv9s9rx3n1ccjw4iw98xn6i8y5v27qm-plexus-components-parent-pom-4.0 
52  java-sisu-inject-parent-pom@0.3.4   
/gnu/store/mbda0iypwjin24r1b4qi5zlangdzpymy-java-sisu-inject-parent-pom-0.3.4 
49  java-sisu-plexus-parent-pom@0.3.4   
/gnu/store/pkqj1h4dd67snn9fsizkni066kg6b5ix-java-sisu-plexus-parent-pom-0.3.4 
45  java-stringtemplate@4.0.6   
/gnu/store/1rwvj03224ismgr30y2jq3lcg44kvks9-java-stringtemplate-4.0.6 
44  maven-pom@3.6.1 
/gnu/store/knlfsdw04aji3nsnd517mrzvgx7a4qfq-maven-pom-3.6.1 
41  ocaml4.07-dose3@5.0.1   
/gnu/store/pj35fddjlfg2dfhdanc7jdi28dpssfm9-ocaml4.07-dose3-5.0.1 
40  maven-resolver-parent-pom@1.3.1 
/gnu/store/3fb7x8iq7s4qr8iw5jaqfxb38jwj14yi-maven-resolver-parent-pom-1.3.1 
39  cl-unicode@0.1.6
/gnu/store/6pbghy445vqb2ryv4z4gcxq10s8cs22a-cl-unicode-0.1.6 
37  python2-cairocffi@1.2.0 
/gnu/store/rkw14pvzg9jhk2d0l1idyh4c6hi9kaqg-python2-cairocffi-1.2.0-doc 
/gnu/store/7nqd9v2mvrdlx0swvwab33g43kpbi6ns-python2-cairocffi-1.2.0 
35  java-jaxen-bootstrap@1.1.6  
/gnu/store/jigmr6xzqf2gsvaa4nlqydpqr705apg9-java-jaxen-bootstrap-1.1.6 
34  java-commons-collections@3.2.2  
/gnu/store/ak09a9rz5k73jhai1g7dmzh0skkmkd5f-java-commons-collections-3.2.2 
34  java-tunnelvisionlabs-antlr4-runtime@4.7.4  
/gnu/store/ax4x9z2z2wv4db4isam6mzhnnhzjv1by-java-tunnelvisionlabs-antlr4-runtime-4.7.4
 
32  maven-plugin-tools-parent-pom@3.5   
/gnu/store/3q1j8z1z0gfs1fxridcb2l6590dnjmd2-maven-plugin-tools-parent-pom-3.5 
31  java-xstream@1.4.15 
/gnu/store/nz1s1svrszjpd0vkcrdmxay30w2v96as-java-xstream-1.4.15 
30  python2-numpydoc@0.8.0  
/gnu/store/9jmb5hz8zhqcfn5fl3ys77m1q4ah2rr6-python2-numpydoc-0.8.0 
25  maven-pom@3.0   
/gnu/store/mk65i8z6z4gvl789il9nv0ghr84adm0x-maven-pom-3.0 
20  r-affy@1.68.0   
/gnu/store/xrzs85ix0h3mld053j3j3l2ggznp01q8-r-affy-1.68.0 
17  cl-symbol-munger@0.0.1-1.97598d4
/gnu/store/cbfrlizlj2lx2z3j4xj9zvrcgbljhk5w-cl-symbol-munger-0.0.1-1.97598d4 
16  maven-wagon-provider-api@3.3.4  
/gnu/store/78nv8hicg8wywq04767z1nbp88czpg6i-maven-wagon-provider-api-3.3.4 
15  python-stevedore@3.2.2  
/gnu/store/ypifs3qxw0l5gw8w7l165zpcihi3k669-python-stevedore-3.2.2 
15  r-uuid@0.1-4
/gnu/store/s5nxr3jhfp7cdfl1dclc79c8djgwa12d-r-uuid-0.1-4 
14  stumpwm@20.11   
/gnu/store/9f98ids4s8hg306chy36d3bhk7zmyg9a-stumpwm-20.11-lib 
/gnu/store/pjfirqc9zxzmk2kap1kph07xib1s1749-stumpwm-20.11 
14  cl-syntax@0.0.3 
/gnu/store/m7miy4bz0slcib33hi6v1cw2wh3wrd5g-cl-syntax-0.0.3 
14  python-arrow@0.17.0 
/gnu/store/q9j7snxqyirpq94dqpjl3y9hvjzljynq-python-arrow-0.17.0 
13  osinfo-db-tools@1.8.0   
/gnu/store/w05va2s51vx70c0akgs73wnc09j2bxws-osinfo-db-tools-1.8.0 
12  python-trytond-currency@5.6.0   
/gnu/store/8d19alw9wavp94xfka4pvr9gb3bvzahj-python-trytond-currency-5.6.0 
12  java-eclipse-jetty-http-test-classes@9.2.22 
/gnu/store/3xj4swsbyrnlh8f5awy36qx3i51ah8fl-java-eclipse-jetty-http-test-classes-9.2.22
 
12  sdl-union@1.2.15
/gnu/store/hkl87qvqvhqvja954hk4b4i9s3a2l69v-sdl-union-1.2.15 
11  python-openstackdocstheme@1.18.1
/gnu/store/wshcx7j6ld0gmsd6iikib50b1b423420-python-openstackdocstheme-1.18.1 
11  doctest@2.4.4   
/gnu/store/84rh11m92a2vmpap4rdppb5l6n6x521h-doctest-2.4.4
10  r-dorng@1.8.2   
/gnu/store/i5za4zyldlnqb9vy5aby4s7ff2bm3qj0-r-dorng-1.8.2
10  r-insight@0.11.1
/gnu/store/z2xazlvfq2qpj7wcr3p5is3s4y86q5ps-r-insight-0.11.1
10  libxaw3d@1.6.3  
/gnu/store/93yq8qgvjsp6zcxipzvi40g2fvx9vsq7-libxaw3d-1.6.3
10  r-scrime@1.3.5  
/gnu/store/kj6gjbdpariqcp6iclkxypm8i4jb53li-r-scrime-1.3.5
10  r-beanplot@1.2  
/gnu/store/w3r5vl74m9xklhbsa243gnhnkryicb2s-r-beanplot-1.2
--

Re: Staging branch [substitute availability]

[Leo Famulari]

Using `guix weather`, we can check substitute availability for the
staging branch:

--
master branch
aarch64: 66% 
x86_64: 93% 
i686: 85%
armhf: 51%

staging branch
aarch64: 44% 
x86_64: 80% 
i686: 60%
armhf: 30%
--

So, substitute availability is definitely lower on the staging branch.

It's not clear if this is the result of "real problems" with the
packages or problems with the build farm.

Re: Staging branch [i686]

[Leo Famulari]

mesa has failed to build for i686-linux on the staging branch, but there
is no build log for this failure:

--
builder for `/gnu/store/isx9ra95v8gw3fqgrvz62cwrlzl5s5y7-mesa-20.2.4' failed 
previously (cached)
build of /gnu/store/26f51p9y1glpal0ik84qsyy5z7nqhc6w-mesa-20.2.4.drv failed
Could not find build log for 
'/gnu/store/26f51p9y1glpal0ik84qsyy5z7nqhc6w-mesa-20.2.4.drv'.
--

Is it safe to run clear cached failures on berlin? Using a command like
`guix gc --clear-failures
/gnu/store/isx9ra95v8gw3fqgrvz62cwrlzl5s5y7-mesa-20.2.4`?


signature.asc
Description: PGP signature

Re: Staging branch [aarch64 failures]

[Leo Famulari]

On Wed, Jan 06, 2021 at 11:38:17AM +0100, Stefan wrote:
> Hi Leo!
> 
> > "while setting up the build environment: executing 
> > `/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No 
> > such 
> > file or directory"
> > 
> > Does anybody have advice?
> 
> I have the same problem. See  for a 
> workaround.

Thanks for pointing this out. It does seem to be a similar issue.

Re: Staging branch [aarch64 failures]

[Stefan]

Hi Leo!

> "while setting up the build environment: executing 
> `/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such 
> file or directory"
> 
> Does anybody have advice?


I have the same problem. See  for a 
workaround.


Bye

Stefan

Re: Staging branch [aarch64 failures]

[Leo Famulari]

On Tue, Jan 05, 2021 at 02:01:35PM +0200, Efraim Flashner wrote:
> qtbase built for me using qemu-binfmt emulation. Send it through again?

I had Cuirass retry the build, and it failed immediately:

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

The log file reads:

"while setting up the build environment: executing 
`/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such 
file or directory"

Does anybody have advice?

Re: Staging branch [aarch64 failures]

[Efraim Flashner]

On Tue, Jan 05, 2021 at 02:01:35PM +0200, Efraim Flashner wrote:
> On Mon, Jan 04, 2021 at 08:37:44PM -0500, Leo Famulari wrote:
> > The branch is building again!
> > 
> > http://ci.guix.gnu.org/eval/10974
> > 
> > Qtbase is failing on aarch64:
> > 
> > https://ci.guix.gnu.org/build/166439/details
> > 
> > There errors like this:
> > 
> > --
> > g++ -c -pipe -O2 -w -fPIC  -I. 
> > -I/gnu/store/48i8mxxb1v4x632dff3i1dbdhsazm8bw-mariadb-10.5.8-dev/include/mysql
> >  
> > -I/gnu/store/48i8mxxb1v4x632dff3i1dbdhsazm8bw-mariadb-10.5.8-dev/include/mysql/mysql
> >  
> > -I/tmp/guix-build-qtbase-5.15.2.drv-0/qtbase-everywhere-src-5.15.2/mkspecs/linux-g++
> >  -o main.o main.cpp
> > g++ -Wl,-O1 -o mysql main.o   
> > -L/gnu/store/c9id1jf4r3cfys6289p92wpdhk1ryns0-mariadb-10.5.8-lib/lib/
> > ld: main.o: in function `main':
> > main.cpp:(.text.startup+0x8): undefined reference to 
> > `mysql_get_client_version'
> > collect2: error: ld returned 1 exit status
> > make: *** [Makefile:69: mysql] Error 1
> > --
> 
> qtbase built for me using qemu-binfmt emulation. Send it through again?
> 

Also built for me just fine on my pine64.


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


signature.asc
Description: PGP signature

Re: Staging branch [aarch64 failures]

[Efraim Flashner]

On Mon, Jan 04, 2021 at 08:37:44PM -0500, Leo Famulari wrote:
> The branch is building again!
> 
> http://ci.guix.gnu.org/eval/10974
> 
> Qtbase is failing on aarch64:
> 
> https://ci.guix.gnu.org/build/166439/details
> 
> There errors like this:
> 
> --
> g++ -c -pipe -O2 -w -fPIC  -I. 
> -I/gnu/store/48i8mxxb1v4x632dff3i1dbdhsazm8bw-mariadb-10.5.8-dev/include/mysql
>  
> -I/gnu/store/48i8mxxb1v4x632dff3i1dbdhsazm8bw-mariadb-10.5.8-dev/include/mysql/mysql
>  
> -I/tmp/guix-build-qtbase-5.15.2.drv-0/qtbase-everywhere-src-5.15.2/mkspecs/linux-g++
>  -o main.o main.cpp
> g++ -Wl,-O1 -o mysql main.o   
> -L/gnu/store/c9id1jf4r3cfys6289p92wpdhk1ryns0-mariadb-10.5.8-lib/lib/
> ld: main.o: in function `main':
> main.cpp:(.text.startup+0x8): undefined reference to 
> `mysql_get_client_version'
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:69: mysql] Error 1
> --

qtbase built for me using qemu-binfmt emulation. Send it through again?


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


signature.asc
Description: PGP signature

Re: Staging branch [aarch64 failures]

[Leo Famulari]

The branch is building again!

http://ci.guix.gnu.org/eval/10974

Qtbase is failing on aarch64:

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

There errors like this:

--
g++ -c -pipe -O2 -w -fPIC  -I. 
-I/gnu/store/48i8mxxb1v4x632dff3i1dbdhsazm8bw-mariadb-10.5.8-dev/include/mysql 
-I/gnu/store/48i8mxxb1v4x632dff3i1dbdhsazm8bw-mariadb-10.5.8-dev/include/mysql/mysql
 
-I/tmp/guix-build-qtbase-5.15.2.drv-0/qtbase-everywhere-src-5.15.2/mkspecs/linux-g++
 -o main.o main.cpp
g++ -Wl,-O1 -o mysql main.o   
-L/gnu/store/c9id1jf4r3cfys6289p92wpdhk1ryns0-mariadb-10.5.8-lib/lib/
ld: main.o: in function `main':
main.cpp:(.text.startup+0x8): undefined reference to `mysql_get_client_version'
collect2: error: ld returned 1 exit status
make: *** [Makefile:69: mysql] Error 1
--


signature.asc
Description: PGP signature

Re: Staging branch

[Leo Famulari]

On Sat, Jan 02, 2021 at 08:38:27PM -0800, John Soo wrote:
> For what it is worth I have rebased on staging and reconfiguring my
> system on it built successfully.  Also my manifest built successfully.

Thank you very much for testing it. I'd glad to hear that everything is
working for you.

Re: Staging branch

[John Soo]

Hi Guix,

Leo Famulari  writes:

> It is supposed to be running, but something has broken. This does happen
> from time to time...

Ah well...

For what it is worth I have rebased on staging and reconfiguring my
system on it built successfully.  Also my manifest built successfully.

I don't have many effected packages though [1].

Thanks again,

John

[1] My packages:

(define-public languages
  '("agda"
"agda-ial"
"cedille"
"coq"
"idris"
"ocaml"
"purescript"))

(define-public utilities
  '("aspell"
"aspell-dict-en"
"bpftrace"
"cups"
"direnv"
"docker-cli"
"dog"
"emacs-no-x"
"exa"
"fd"
"fish"
"fish-foreign-env"
"fzy"
"gdb"
"global"
"groff"
"make"
"pijul"
"pinentry"
"recutils"
"ripgrep"
"rlwrap"
"shellcheck"
"skim"
"time"
"tlsdate"
"tokei"
"tmux"
"unzip"))

(define-public browsers
  '("icecat"
"lynx"
"ungoogled-chromium"))

(define-public desktop-tools
  '("alacritty"
"alsa-utils"
"clipmenu"
"compton"
"dbus"
"dunst"
"garcon"
"libnotify"
"libreoffice"
"mpv"
"my-dmenu"
"pulseaudio"
"scrot"))

(define-public fonts
  '("mkfontdir"
"mkfontscale"
"font-dejavu"
"font-iosevka"
"font-iosevka-term-slab"))

(define-public haskell-tools
  '("ghc"
"hlint"
"hoogle"))

(define-public ocaml-tools
  '("opam"))

(define-public rust-tools
  '("rust"
"rust:cargo"
"rust:rls"
"rust:rustfmt"))

(define-public guile-tools
  '("guile"
"guile-colorized"
"guile-readline"
"guile-syntax-highlight"))

(define-public pdf-tools
  '("texlive"
"zathura"
"zathura-pdf-mupdf"))

(define-public xorg-tools
  '("gcc-toolchain"
"ghc-dbus"
"ghc-xmonad-contrib"
"setxkbmap"
"xcape"
"xdg-utils"
"xdotool"
"xev"
"xfontsel"
"xinit"
"xinput"
"xlockmore"
"xmessage"
"xmobar"
"xmonad"
"xrandr"
"xsel"
"xsetroot"
"xwallpaper"))

(define-public emacs-packages
  '("emacs-anzu"
"emacs-avy"
"emacs-cmake-mode"
"emacs-company"
"emacs-company-coq"
"emacs-company-math"
"emacs-counsel-projectile"
"emacs-csv-mode"
"emacs-cql-mode"
"emacs-dash"
"emacs-debbugs"
"emacs-dhall-mode"
"emacs-direnv"
"emacs-dired-git-info"
"emacs-diredfl"
"emacs-docker"
"emacs-dockerfile-mode"
"emacs-ediprolog"
"emacs-eglot"
"emacs-elfeed"
"emacs-elf-mode"
"emacs-elm-mode"
"emacs-emmet-mode"
"emacs-evil"
"emacs-evil-anzu"
"emacs-evil-commentary"
"emacs-evil-escape"
"emacs-evil-leader"
"emacs-evil-magit"
"emacs-evil-org"
"emacs-evil-surround"
"emacs-evil-tmux-navigator"
"emacs-f"
"emacs-fill-column-indicator"
"emacs-fish-completion"
"emacs-fish-mode"
"emacs-flycheck"
"emacs-flycheck-elm"
"emacs-flycheck-rust"
"emacs-forge"
"emacs-geiser"
"emacs-goto-chg"
"emacs-graphql-mode"
"emacs-graphviz-dot-mode"
"emacs-guix"
"emacs-haskell-mode"
"emacs-haskell-snippets"
"emacs-ibuffer-projectile"
"emacs-idris-mode"
"emacs-imenu-list"
"emacs-ivy"
"emacs-let-alist"
"emacs-magit"
"emacs-markdown-mode"
"emacs-merlin"
"emacs-multi-term"
"emacs-nix-mode"
"emacs-nodejs-repl"
"emacs-ob-restclient"
"emacs-origami-el"
"emacs-prescient"
"emacs-projectile"
"emacs-psc-ide"
"emacs-recutils"
"emacs-reformatter"
"emacs-restclient"
"emacs-rust-mode"
"emacs-s"
"emacs-slime"
"emacs-slime-company"
"emacs-sml-mode"
"emacs-solarized-theme"
"emacs-systemd-mode"
"emacs-terraform-mode"
"emacs-tuareg"
"emacs-vimrc-mode"
"emacs-web-mode"
"emacs-wgrep"
"emacs-which-key"
"emacs-xclip"
"emacs-xterm-color"
"emacs-yaml-mode"
"emacs-yasnippet"
"proof-general"))

Re: Staging branch

[Leo Famulari]

On Sat, Jan 02, 2021 at 08:59:03AM -0800, John Soo wrote:
> Is staging not running in ci?It looks like the last time it ran was just 
> before the rustfmt output of rust (commit 48926b5).Did changing rust@1.46 
> somehow keep ci from running on staging?

It is supposed to be running, but something has broken. This does happen
from time to time...

Re: Staging branch

[John Soo]

 Hi there, 

 
Is staging not running in ci?It looks like the last time it ran was just 
before the rustfmt output of rust (commit 48926b5).Did changing rust@1.46 
somehow keep ci from running on staging?
 

 
Maybe I am missing something.
 

 
Any clues?
 

 
John
 

Re: Staging branch

[Efraim Flashner]

On Wed, Dec 30, 2020 at 03:24:02PM -0500, Leo Famulari wrote:
> On Wed, Dec 30, 2020 at 10:57:39AM +0200, Efraim Flashner wrote:
> > In the interest of getting staging merged soon-ish I think it's best to
> > leave the kde-frameworks at 5.70 for now. A quick 'guix refresh -u -t
> > kde' had a couple of patches which didn't apply anymore and isn't
> > something I want to just run through.
> > 
> > I would like to do it soon-ish though. We are starting to hit packages
> > which want a version of extra-cmake-modules newer than 5.70.
> 
> Okay.
> 
> I saw you did some work on the branch — thanks!
> 
> Have you identified any other outstanding problems?

Python-arrow is blocking a couple of packages. Also offlate is blocked
by python-pygithub. qemu built for me on the 2nd or 3rd try. I don't
have a specific use case for either, but I know they build find on
master.

I haven't tried reconfiguring on staging yet but everything else seems to
build just fine.

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


signature.asc
Description: PGP signature

Re: Staging branch

[Leo Famulari]

On Wed, Dec 30, 2020 at 10:57:39AM +0200, Efraim Flashner wrote:
> In the interest of getting staging merged soon-ish I think it's best to
> leave the kde-frameworks at 5.70 for now. A quick 'guix refresh -u -t
> kde' had a couple of patches which didn't apply anymore and isn't
> something I want to just run through.
> 
> I would like to do it soon-ish though. We are starting to hit packages
> which want a version of extra-cmake-modules newer than 5.70.

Okay.

I saw you did some work on the branch — thanks!

Have you identified any other outstanding problems?

Re: Staging branch

[Efraim Flashner]

On Tue, Dec 29, 2020 at 02:05:12PM -0500, Leo Famulari wrote:
> On Tue, Dec 29, 2020 at 04:00:16PM +0200, Efraim Flashner wrote:
> > These are mostly blocked by purpose and grantleetheme. I'll see if those
> > suddenly start building correctly if I upgrade the whole KDE stack.
> 
> Thanks, Efraim!
> 
> Let me know if I can help with that.

In the interest of getting staging merged soon-ish I think it's best to
leave the kde-frameworks at 5.70 for now. A quick 'guix refresh -u -t
kde' had a couple of patches which didn't apply anymore and isn't
something I want to just run through.

I would like to do it soon-ish though. We are starting to hit packages
which want a version of extra-cmake-modules newer than 5.70.

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


signature.asc
Description: PGP signature

Re: Staging branch

[Leo Famulari]

On Tue, Dec 29, 2020 at 04:00:16PM +0200, Efraim Flashner wrote:
> These are mostly blocked by purpose and grantleetheme. I'll see if those
> suddenly start building correctly if I upgrade the whole KDE stack.

Thanks, Efraim!

Let me know if I can help with that.

Re: Staging branch

[Efraim Flashner]

On Tue, Dec 29, 2020 at 10:39:09AM +0200, Efraim Flashner wrote:
> On Wed, Dec 23, 2020 at 05:46:25PM -0500, Leo Famulari wrote:
> > On Wed, Dec 23, 2020 at 12:27:22AM -0500, Leo Famulari wrote:
> > 
> > I tried using the newer version of this package (5.71) but it fails due
> > to incompatibilities with the rest of the KDE frameworks.
> > 
> > Any ideas?
> > 
> 
> The problem persists even when upgrading extra-cmake-modules and
> kwidgetsaddons to 5.77.0.
> 
> I'm trying out disabling the test, I'll see what builds and what doesn't
> if we just skip that test.
> 

I skipped the test and fixed a couple of other packages which weren't
building. The final list that failed to build for me was:

The following derivations would be built:
   /gnu/store/ddphzjax6lissg2hy82svsjm1gz52073-elisa-0.4.2.drv
   /gnu/store/ka3qs4fl6dqcn5p28j5m3ab5kfgj9d59-kmail-20.04.1.drv
   /gnu/store/4n34vjwj6mawhkkybpswsx762vz550gg-libksieve-20.04.1.drv
   /gnu/store/nmy4rr3fyxwgdirzb1rg5qrfnri0ypvx-kpimcommon-20.04.1.drv
   /gnu/store/xxqbqaizi6vf9skn9wwjy36vp2r110bx-purpose-5.70.0.drv
   /gnu/store/989ymvm67znqrybcxah48j4zr0475jbk-kmailcommon-20.04.1.drv
   /gnu/store/r1s11n050lx10fqg7knqqg61n11967f8-kmessagelib-20.04.1.drv
   /gnu/store/2qlmvbyg3pfprd8f81n8l9anjll9j1k6-grantleetheme-20.04.1.drv
   /gnu/store/l4fqdwsgfbfgmxh94w95fyll6v8i36im-libgravatar-20.04.1.drv
   /gnu/store/ngsm8ws3mlvag8pxq4xdl76hmzdv8v52-kdepim-apps-libs-20.04.1.drv
   /gnu/store/ic0jiln1jjzj3k7v1y05hl57f6fc8n8m-kaddressbook-20.04.1.drv
   /gnu/store/blvzp1d47x905anqxac4kfsx9p95cknj-korganizer-20.04.1.drv
   /gnu/store/j7pq7mb4b1dbfs2qzpaybmchm7xjcffv-keventviews-20.04.1.drv
   /gnu/store/jr5ka4lhq0gji1bqmmpik68nqy593q8q-kcalendarsupport-20.04.1.drv
   /gnu/store/ncgvh9vyasly3ygv31whqk5jzbv5984w-kincidenceeditor-20.04.1.drv
   /gnu/store/z7m20l2c70d11bxsqmzb5l1ymfldqkyv-knotes-20.04.1.drv
   /gnu/store/5p77xgq9q9yg6jpm1qpns7iq01mmfvch-kdepim-runtime-20.04.1.drv
   /gnu/store/ds7z6lphxbz7y2d1ksc11fq8792d7za5-choqok-1.7.0.drv
   /gnu/store/2wlmmxygf0yqi0d7s0vhkl0d2wkm0qsh-okular-20.12.0.drv
   /gnu/store/2x7j1wnln6h6xwni29wpkjdyg5mfjkjb-kdenlive-20.08.3.drv
   /gnu/store/2r7zqwlyjxvrv7ff55vd87qvklkc1r75-kamoso-20.04.1.drv

These are mostly blocked by purpose and grantleetheme. I'll see if those
suddenly start building correctly if I upgrade the whole KDE stack.


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


signature.asc
Description: PGP signature

Re: Staging branch

[Efraim Flashner]

On Wed, Dec 23, 2020 at 05:46:25PM -0500, Leo Famulari wrote:
> On Wed, Dec 23, 2020 at 12:27:22AM -0500, Leo Famulari wrote:
> > ... and reply with any problems.
> 
> The package kwidgetsaddons fails its test suite like this:
> 
> --
> * Start testing of KColumnResizerTest *
> Config: Using QtTest library 5.15.2, Qt 5.15.2 (x86_64-little_endian-lp64 
> shared (dynamic) release build; by GCC 7.5.0), unknown unknown
> PASS   : KColumnResizerTest::initTestCase()
> QWARN  : KColumnResizerTest::test(forms) This plugin does not support 
> propagateSizeHints()
> PASS   : KColumnResizerTest::test(forms)
> QWARN  : KColumnResizerTest::test(grids) This plugin does not support 
> propagateSizeHints()
> PASS   : KColumnResizerTest::test(grids)
> QWARN  : KColumnResizerTest::test(grid-and-form) This plugin does not support 
> propagateSizeHints()
> FAIL!  : KColumnResizerTest::test(grid-and-form) Compared values are not the 
> same
>Actual   (widget1->x()): 145
>Expected (widget2x): 161
>Loc: 
> [/tmp/guix-build-kwidgetsaddons-5.70.0.drv-0/kwidgetsaddons-5.70.0/autotests/kcolumnresizertest.cpp(83)]
> PASS   : KColumnResizerTest::cleanupTestCase()
> Totals: 4 passed, 1 failed, 0 skipped, 0 blacklisted, 18ms
> * Finished testing of KColumnResizerTest *
> 
> 
> 95% tests passed, 1 tests failed out of 19
> 
> Total Test time (real) =   8.27 sec
> 
> The following tests FAILED:
>19 - kwidgetsaddons-kcolumnresizertest (Failed)
> Errors while running CTest
> make: *** [Makefile:110: test] Error 8
> 
> Test suite failed, dumping logs.
> --
> 
> I tried using the newer version of this package (5.71) but it fails due
> to incompatibilities with the rest of the KDE frameworks.
> 
> Any ideas?
> 

The problem persists even when upgrading extra-cmake-modules and
kwidgetsaddons to 5.77.0.

I'm trying out disabling the test, I'll see what builds and what doesn't
if we just skip that test.

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


signature.asc
Description: PGP signature

Re: Staging branch

[Efraim Flashner]

On Wed, Dec 23, 2020 at 05:46:25PM -0500, Leo Famulari wrote:
> On Wed, Dec 23, 2020 at 12:27:22AM -0500, Leo Famulari wrote:
> > ... and reply with any problems.
> 
> The package kwidgetsaddons fails its test suite like this:
> 
> --
> * Start testing of KColumnResizerTest *
> Config: Using QtTest library 5.15.2, Qt 5.15.2 (x86_64-little_endian-lp64 
> shared (dynamic) release build; by GCC 7.5.0), unknown unknown
> PASS   : KColumnResizerTest::initTestCase()
> QWARN  : KColumnResizerTest::test(forms) This plugin does not support 
> propagateSizeHints()
> PASS   : KColumnResizerTest::test(forms)
> QWARN  : KColumnResizerTest::test(grids) This plugin does not support 
> propagateSizeHints()
> PASS   : KColumnResizerTest::test(grids)
> QWARN  : KColumnResizerTest::test(grid-and-form) This plugin does not support 
> propagateSizeHints()
> FAIL!  : KColumnResizerTest::test(grid-and-form) Compared values are not the 
> same
>Actual   (widget1->x()): 145
>Expected (widget2x): 161
>Loc: 
> [/tmp/guix-build-kwidgetsaddons-5.70.0.drv-0/kwidgetsaddons-5.70.0/autotests/kcolumnresizertest.cpp(83)]
> PASS   : KColumnResizerTest::cleanupTestCase()
> Totals: 4 passed, 1 failed, 0 skipped, 0 blacklisted, 18ms
> * Finished testing of KColumnResizerTest *
> 
> 
> 95% tests passed, 1 tests failed out of 19
> 
> Total Test time (real) =   8.27 sec
> 
> The following tests FAILED:
>19 - kwidgetsaddons-kcolumnresizertest (Failed)
> Errors while running CTest
> make: *** [Makefile:110: test] Error 8
> 
> Test suite failed, dumping logs.
> --
> 
> I tried using the newer version of this package (5.71) but it fails due
> to incompatibilities with the rest of the KDE frameworks.
> 
> Any ideas?
> 

I got the same error while trying to build my profile.

I also got a transient test-suite error while building tuir, but it
passed after the 5th try.

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


signature.asc
Description: PGP signature

Re: Staging branch

[Leo Famulari]

On Wed, Dec 23, 2020 at 12:27:22AM -0500, Leo Famulari wrote:
> ... and reply with any problems.

The package kwidgetsaddons fails its test suite like this:

--
* Start testing of KColumnResizerTest *
Config: Using QtTest library 5.15.2, Qt 5.15.2 (x86_64-little_endian-lp64 
shared (dynamic) release build; by GCC 7.5.0), unknown unknown
PASS   : KColumnResizerTest::initTestCase()
QWARN  : KColumnResizerTest::test(forms) This plugin does not support 
propagateSizeHints()
PASS   : KColumnResizerTest::test(forms)
QWARN  : KColumnResizerTest::test(grids) This plugin does not support 
propagateSizeHints()
PASS   : KColumnResizerTest::test(grids)
QWARN  : KColumnResizerTest::test(grid-and-form) This plugin does not support 
propagateSizeHints()
FAIL!  : KColumnResizerTest::test(grid-and-form) Compared values are not the 
same
   Actual   (widget1->x()): 145
   Expected (widget2x): 161
   Loc: 
[/tmp/guix-build-kwidgetsaddons-5.70.0.drv-0/kwidgetsaddons-5.70.0/autotests/kcolumnresizertest.cpp(83)]
PASS   : KColumnResizerTest::cleanupTestCase()
Totals: 4 passed, 1 failed, 0 skipped, 0 blacklisted, 18ms
* Finished testing of KColumnResizerTest *


95% tests passed, 1 tests failed out of 19

Total Test time (real) =   8.27 sec

The following tests FAILED:
 19 - kwidgetsaddons-kcolumnresizertest (Failed)
Errors while running CTest
make: *** [Makefile:110: test] Error 8

Test suite failed, dumping logs.
--

I tried using the newer version of this package (5.71) but it fails due
to incompatibilities with the rest of the KDE frameworks.

Any ideas?