Release!

Release!

[Ludovic Courtès]

Hello Guix!

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

> I think it’s time to think about what we want to work on next, ideally
> before the next release, and ideally said release should be in a couple
> of months rather than in 5 months.

Oops, that was 5 months ago…  :-)

> Here are some important items I can think of:
>
>   • Merge the ncurses installer (the ‘wip-installer’) branch.
>
>   • We’re supposed to freeze ‘core-updates’ in a couple of days and we
>     have defined a couple of important goals:
>     <https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00120.html>.
>     I have a vague feeling that the ‘wip-build-systems-gexp’ merge is
>     not for this time yet…
>
>   • ‘guix offload’ terrible bug: <https://bugs.gnu.org/26976>.
>
>   • Guile 2.2 compiler terrible issue:
>     <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.
>
>   • Adjust the release process so we don’t find ourselves without
>     substitutes for the ‘guix’ package, as reported at
>     <https://bugs.gnu.org/27032>.
>
>   • Prepare to migrate to the new build farm: the hardware of
>     bayfront.guixsd.org has been fixed (it was unreliable until we
>     changed its CPUs), so now we need to fix a couple of issues in
>     Cuirass and generally improve it so we can, via its HTTP interface,
>     add new jobsets and so on.  Of course we’ll have to work
>     on that incrementally.
>
>   • Finalize the new bootloader API and support for new bootloaders:
>     <https://bugs.gnu.org/26339>.
>
>   • Merge the potluck!  <https://bugs.gnu.org/26645>

Good news is that we made progress on some of these issues, but not all;
we also made progress on other things which are really cool, such as the
ISO installer.

Regardless, I think we should be planning for a release within a couple
of weeks.  An important question to me is ‘wip-installer’: what do we
do, Danny?  John?

I would have loved to have a fix to at least mitigate Guile’s compiler
resource consumption issue.  I made some progress at
<https://bugs.gnu.org/28590> notably, but it’s not over yet.

In the meantime, it would be great if people could run an installation
from an ISO image and report bugs and glitches:

  https://www.gnu.org/software/guix/manual/html_node/Building-the-Installation-Image.html

Thoughts?

Ludo’.

Re: Release!

[Christopher Baines]

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

On Wed, 04 Oct 2017 17:12:36 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> In the meantime, it would be great if people could run an installation
> from an ISO image and report bugs and glitches:
> 
>   https://www.gnu.org/software/guix/manual/html_node/Building-the-Installation-Image.html
> 
> Thoughts?

Unfortunately, building the ISO image has broken since I was
successfully using it [1].

One other issue I was thinking of recently was the size of the image. I
checked an ISO of the installation system I generated a while ago, and
it's 1.1GB in size. A actual CD can only hold 0.7GB of data. This might
be something that just needs documenting, saying that this is for a
DVD, and not a CD, or, it the size could be reduced so that it fits on
a CD.

When I build the installation system, and run guix size, it says 1031.0
MiB, so I guess looking at the breakdown there and trying to reduce it
would be a way to start, if this is a worthwhile objective.

I don't have any use for a physical CD installation image, so if anyone
is interested in having this, now is the time to say so?


1: guix system disk-image --file-system-type=iso9660
gnu/system/install.scm

error: changing mode of
`/tmp/root//gnu/store/jjna4ivyidxfq40mq78g97yzg0wfzcqy-shadow-4.5/bin/su'
to 100555: Operation not permitted ERROR: In procedure scm-error:
ERROR: failed to register store items "/xchg/system"

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

Re: Release!

[Ludovic Courtès]

Heya!

Christopher Baines <mail@cbaines.net> skribis:

> Unfortunately, building the ISO image has broken since I was
> successfully using it [1].

Oops, weird.  Let’s investigate.

> One other issue I was thinking of recently was the size of the image. I
> checked an ISO of the installation system I generated a while ago, and
> it's 1.1GB in size. A actual CD can only hold 0.7GB of data. This might
> be something that just needs documenting, saying that this is for a
> DVD, and not a CD, or, it the size could be reduced so that it fits on
> a CD.
>
> When I build the installation system, and run guix size, it says 1031.0
> MiB, so I guess looking at the breakdown there and trying to reduce it
> would be a way to start, if this is a worthwhile objective.

We can do both.  :-)

I think reducing the size of package closures in general is
worthwhile—there’s room for progress.

Yet, we probably won’t make it fit in 650 MiB this easily, so we should
document this.

Thanks for your feedback,
Ludo’.

> 1: guix system disk-image --file-system-type=iso9660
> gnu/system/install.scm
>
> error: changing mode of
> `/tmp/root//gnu/store/jjna4ivyidxfq40mq78g97yzg0wfzcqy-shadow-4.5/bin/su'
> to 100555: Operation not permitted ERROR: In procedure scm-error:
> ERROR: failed to register store items "/xchg/system"

Re: Release!

[Ricardo Wurmus]

Hi Ludo,

>> Here are some important items I can think of:
[…]
>>   • Guile 2.2 compiler terrible issue:
>>     <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.

One way to side-step this issue for the upcoming release is to use one
Guile process per file when running “guix pull”.  This will make it run
a lot slower, but that would be better than the current situation.

Maybe we could make parallel compilation within the same Guile process
an option, so that it won’t be needlessly slow on machines within the
RAM goldilocks zone.

I’ve reverted f07041f7d25badb7d74b8fad6ee446a12af04f63 locally on my
i686 netbook with 1GB RAM and tested it with “guix pull
--url=/path/to/guix”.  This seems to work — it’s still running… :)

One annoyance is that after compiling one file it prints this message:

   Some deprecated features have been used.  Set the environment
   variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
   program to get more information.  Set it to "no" to suppress
   this message.

I suppose we should suppress this for “guix pull”.

Do you want to make this behaviour optional, e.g. through a command line
switch like “--sloth”?  Or should this be the default until the problem
in Guile/libgc is fixed?

>>   • Prepare to migrate to the new build farm: the hardware of
>>     bayfront.guixsd.org has been fixed (it was unreliable until we
>>     changed its CPUs), so now we need to fix a couple of issues in
>>     Cuirass and generally improve it so we can, via its HTTP interface,
>>     add new jobsets and so on.  Of course we’ll have to work
>>     on that incrementally.

I guess we’ll be using berlin.guixsd.org instead of bayfront, no?  I’m
currently installing additional servers (we’re now at 13 build servers,
I’ll get this up to 18 this week).

>>   • Merge the potluck!  <https://bugs.gnu.org/26645>

About that… We now have a JSON importer, so maybe it’s worth using the
even simpler JSON package format instead of the simplified S-expression
format that Andy proposed.  What do you think?  Should we discuss this
at <https://bugs.gnu.org/26645>?

Who would like to help us squash some bugs before the release?  Let’s
try to fix at least 5 more bugs!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Release!

[David Pirotte]

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

Hi Recardo,
Hi Ludo,

> >>   • Merge the potluck!  <https://bugs.gnu.org/26645>  

> About that… We now have a JSON importer, so maybe it’s worth using the
> even simpler JSON package format instead of the simplified S-expression
> format that Andy proposed.  What do you think?  Should we discuss this
> at <https://bugs.gnu.org/26645>?

FWIW, I much prefer s-exp, and the generated file is a scheme file right? I very
much doubt guix and potluck package developers can't easily read (and write :))
s-exp, so why would we 'abandon' s-exp, what would we win here? These files will
never be processed by anything else but guix and/or potluck, and the 'package
developers' do all know scheme perfectly well...

my 2c :)
Thanks for the fantastic work, both Guix and potluck!

David

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

Re: Release!

[Hartmut Goebel]

Am 07.10.2017 um 01:31 schrieb David Pirotte:
> so why would we 'abandon' s-exp, what would we win here?

It might be interesting to *create* these files using tools written in
other programming languages. And modules for creating *JSON* are
available for most programming languages.

(OTOH TOML[]1] could be a better format than JSON – it's much like
.ini-files, but more formal specification. A scheme implementation is
available [2].)

[1] https://en.wikipedia.org/wiki/TOML
[2] 0f52bab3e3cfeb261110f9217c39eb03e78d026a

-- 
Regards
Hartmut Goebel

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

Re: Release!

[David Pirotte]

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

Hello Hartmut,

> > so why would we 'abandon' s-exp, what would we win here?  

> It might be interesting to *create* these files using tools written in
> other programming languages. And modules for creating *JSON* are
> available for most programming languages.

But that would be another tool, another package manager, not potluck... written by
we don't know who, neither when ... and that would be a totally separate effort,
that would not contribute to potluck ... which needs help (I wish I had the time...)

Potluck package definitions are generated, adjusted 'by hand' - mostly to update
the description, sometimes the copyright - then that is used to generated a Guix
package, which is a Guile scheme module: It makes no sense to me that the
potluck package representation would be anything but s-expr:

	actually, most guilers do the exact opposite :) -  when an app or a lib
	either produces or needs xml, html, json ... the first thing they do is to
	transform these into s-expr, so these become (a lot more) readable and
	hackable ...

> (OTOH TOML[]1] could be a better format than JSON – it's much like
> .ini-files, but more formal specification...

Absolutely terrible :):) I hope we never do that, at least not for the 'official'
and maintained potluck package representation.

Again, my 2c.
David


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

Re: Release!

[Ricardo Wurmus]

Hi David,

>> >>   • Merge the potluck!  <https://bugs.gnu.org/26645>
>
>> About that… We now have a JSON importer, so maybe it’s worth using the
>> even simpler JSON package format instead of the simplified S-expression
>> format that Andy proposed.  What do you think?  Should we discuss this
>> at <https://bugs.gnu.org/26645>?
>
> FWIW, I much prefer s-exp, and the generated file is a scheme file right? I very
> much doubt guix and potluck package developers can't easily read (and write :))
> s-exp, so why would we 'abandon' s-exp, what would we win here? These files will
> never be processed by anything else but guix and/or potluck, and the 'package
> developers' do all know scheme perfectly well...

I’m not saying that JSON is “better” than s-exps.

Part of the potluck effort as I understood it is to simplify packaging.
The potluck package definition is strictly simpler than Guix package
definitions in that there’s less boilerplate and inputs are really just
strings.  Taking that aspect of simplifying packaging even farther we
can reduce the syntax even more.

The target audience here has little overlap with Guix developers.  Guix
won’t adopt JSON as a packaging format; that’s not what this is about.
The goal I had in mind when I worked on the JSON importer was to make
packaging even simpler for people who don’t really care all that much
about packaging — if they did they would probably want to learn about
how to contribute to Guix, and thus would want to learn the S-expr
syntax we use in Guix.

There are users of Guix who benefit from its features as a personal
package manager.  Users can already add their own packages via
GUIX_PACKAGE_PATH.  We support those who don’t feel comfortable writing
Scheme by offering a JSON importer; with just a minor change to “guix
build” we can even build JSON packages directly, without making people
convert them to Scheme modules first.

I think that this feature can be useful within the context of the
potluck.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Release!

[Hartmut Goebel]

Am 07.10.2017 um 23:30 schrieb Ricardo Wurmus:
> The target audience here has little overlap with Guix developers.  […]
> The goal I had in mind when I worked on the JSON importer was to make
> packaging even simpler for people who don’t really care all that much
> about packaging – […]

+1

-- 
Regards
Hartmut Goebel

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

Re: Release!

[Christopher Baines]

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

On Fri, 06 Oct 2017 15:01:42 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> Heya!
> 
> Christopher Baines <mail@cbaines.net> skribis:
> 
> > Unfortunately, building the ISO image has broken since I was
> > successfully using it [1].  
> 
> Oops, weird.  Let’s investigate.

I'm very glad that now I've removed the setuid binaries from the store,
the building of the ISO image, and the associated iso-image-installer
system test are now working for me :)

Thanks for investigating and fixing this Ludo :D

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

Re: Release!

[Ludovic Courtès]

Heya,

Ricardo Wurmus <rekado@elephly.net> skribis:

>>> Here are some important items I can think of:
> […]
>>>   • Guile 2.2 compiler terrible issue:
>>>     <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.

I should mention that I spent entire days on this, and some of the
conclusions are described here:

  https://lists.gnu.org/archive/html/guile-devel/2017-09/msg00031.html
  https://bugs.gnu.org/28590

I invite the Guilers among us to join the fun.  :-)  A bug that serious
is a problem for Guile.

From a Guix perspective, we have to find alternate solutions to improve
scalability anyway:

  https://bugs.gnu.org/27284

>>>   • Prepare to migrate to the new build farm: the hardware of
>>>     bayfront.guixsd.org has been fixed (it was unreliable until we
>>>     changed its CPUs), so now we need to fix a couple of issues in
>>>     Cuirass and generally improve it so we can, via its HTTP interface,
>>>     add new jobsets and so on.  Of course we’ll have to work
>>>     on that incrementally.
>
> I guess we’ll be using berlin.guixsd.org instead of bayfront, no?

Yes.

> I’m currently installing additional servers (we’re now at 13 build
> servers, I’ll get this up to 18 this week).

Woohoo, thank you!

>>>   • Merge the potluck!  <https://bugs.gnu.org/26645>
>
> About that… We now have a JSON importer, so maybe it’s worth using the
> even simpler JSON package format instead of the simplified S-expression
> format that Andy proposed.  What do you think?  Should we discuss this
> at <https://bugs.gnu.org/26645>?

Yeah I think we need to reopen the discussion.  We discussed it at the
GHM but this should take place here on guix-devel I guess.

> Who would like to help us squash some bugs before the release?  Let’s
> try to fix at least 5 more bugs!

Yes, let’s squash bugs!

There are many ways people can help, and one of them is triage: close
bugs that are already fixed, determine whether old bugs are still
relevant and close those that are obsolete, retitle bugs to better
reflect what the problem is, ping people asking for more information.
After that, there are more-or-less “easy” packaging bugs in the list
that can be a good starting point.

Thanks,
Ludo’.

Re: Release!

[Ludovic Courtès]

Christopher Baines <mail@cbaines.net> skribis:

> On Fri, 06 Oct 2017 15:01:42 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> Heya!
>> 
>> Christopher Baines <mail@cbaines.net> skribis:
>> 
>> > Unfortunately, building the ISO image has broken since I was
>> > successfully using it [1].  
>> 
>> Oops, weird.  Let’s investigate.
>
> I'm very glad that now I've removed the setuid binaries from the store,
> the building of the ISO image, and the associated iso-image-installer
> system test are now working for me :)

Awesome, thanks for checking!

I really didn’t expect such a bug to crop up…

Ludo’.

Re: Release!

[Ludovic Courtès]

Hello Guix,

I think we can start preparing the release for good now!

The situation of ‘guix pull’ is mitigated by the split of python.scm and
other big files into several pieces.  This is of course not ideal, but
it’s an improvement over 0.13.0 anyway.

I think the main tasks to prepare the release are (1) testing the GuixSD
ISO, and (2) updating ‘NEWS’.

Let’s get that done!

Ludo’.

Re: Release!

[Ludovic Courtès]

Hello!

Time flies, but I think we’re about ready for the release.  I’d like to
aim for next Tuesday (Dec. 5th) and fix small hickups and annoyances by
then, particularly regarding GuixSD installation.

Ricardo Wurmus <rekado@elephly.net> skribis:

>>> Here are some important items I can think of:
> […]
>>>   • Guile 2.2 compiler terrible issue:
>>>     <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.

There’s more going on on the Guile side, but for now the recent split of
the big package files has helped reduce peak memory consumption
noticeably.

> One annoyance is that after compiling one file it prints this message:
>
>    Some deprecated features have been used.  Set the environment
>    variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
>    program to get more information.  Set it to "no" to suppress
>    this message.

This was also showing up a lot in ‘guix system init’ et al, when
compiling modules.  I think a912c723f76d9762072ce27204a9227a64bcb625
removes most of these.

>>>   • Prepare to migrate to the new build farm: the hardware of
>>>     bayfront.guixsd.org has been fixed (it was unreliable until we
>>>     changed its CPUs), so now we need to fix a couple of issues in
>>>     Cuirass and generally improve it so we can, via its HTTP interface,
>>>     add new jobsets and so on.  Of course we’ll have to work
>>>     on that incrementally.
>
> I guess we’ll be using berlin.guixsd.org instead of bayfront, no?

Yes.  Questions:

  1. Do we pre-register berlin’s key on GuixSD?

  2. Do we add berlin.guixsd.org to the list of substitute servers on
     GuixSD?  On Guix?  The drawback is that ‘guix’ sometimes talks to
     both servers when retrieve substitute lists, which can be slightly
     slower/annoying, but otherwise I think it’s a win.

Thoughts?

The main GuixSD annoying messages that I think we should address by
Tuesday are:

  1. “Error in finalization thread: Bad file descriptor” coming from the
     Shepherd;

  2. “udevd[304]: RUN{builtin}: 'uaccess' unknown /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”

Both are harmless but they may give users a false sense that something’s
broken.

Ludo’.

Re: Release!

[Maxim Cournoyer]

Hi!

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

[...]

>>
>> I guess we’ll be using berlin.guixsd.org instead of bayfront, no?
>
> Yes.  Questions:
>
>   1. Do we pre-register berlin’s key on GuixSD?

Isn't this already the case?

[...]

>
> The main GuixSD annoying messages that I think we should address by
> Tuesday are:

[...]

>
>   2. “udevd[304]: RUN{builtin}: 'uaccess' unknown /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
>

I had researched about that error a bit and it seems that it caused by
eudev lacking support for 'uaccess'[0]; so not something to fix in Guix
proper.

[0]  https://github.com/gentoo/eudev/issues/145

Maxim

Re: Release!

[Leo Famulari]

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

On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
>   1. Do we pre-register berlin’s key on GuixSD?

I vote yes.

>   2. Do we add berlin.guixsd.org to the list of substitute servers on
>      GuixSD?  On Guix?  The drawback is that ‘guix’ sometimes talks to
>      both servers when retrieve substitute lists, which can be slightly
>      slower/annoying, but otherwise I think it’s a win.

I think it's worth the extra source of substitutes. Since adding
berlin.guixsd.org to my list of substitute URLs, it seems like I need to
build less often.

In my experience, it's annoying to query multiple servers when my
network connection is slow or unreliable. But, it's also annoying in
that situation to need to download source files from a variety of
upstream sites.

> The main GuixSD annoying messages that I think we should address by
> Tuesday are:
> 
>   1. “Error in finalization thread: Bad file descriptor” coming from the
>      Shepherd;

I'm not sure how to start debugging this :/ If I get some advice, I
could try to fix it on Sunday and Monday.

>   2. “udevd[304]: RUN{builtin}: 'uaccess' unknown /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”

I haven't seen this one before.

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

Re: Release!

[Ricardo Wurmus]

Leo Famulari <leo@famulari.name> writes:

> On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
>>   1. Do we pre-register berlin’s key on GuixSD?
>
> I vote yes.
>
>>   2. Do we add berlin.guixsd.org to the list of substitute servers on
>>      GuixSD?  On Guix?  The drawback is that ‘guix’ sometimes talks to
>>      both servers when retrieve substitute lists, which can be slightly
>>      slower/annoying, but otherwise I think it’s a win.
>
> I think it's worth the extra source of substitutes. Since adding
> berlin.guixsd.org to my list of substitute URLs, it seems like I need to
> build less often.
>
> In my experience, it's annoying to query multiple servers when my
> network connection is slow or unreliable. But, it's also annoying in
> that situation to need to download source files from a variety of
> upstream sites.

I’d like to add berlin.guix.org to the list of default substitute
servers, but before I can allow this with a good conscience I need to
increase space on the head node.  We were very busy, so the new head
node and storage aren’t ready yet, and the old node that’s currently
coordinating builds on berlin.guix.org has very limited storage.

I’ll try to get the new storage ready on Monday.

>>   2. “udevd[304]: RUN{builtin}: 'uaccess' unknown /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
>
> I haven't seen this one before.

I have seen it, but only when checking the output of dmesg.  I guess we
could just remove that rule.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Release!

[Ludovic Courtès]

Hello!

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
>>   1. Do we pre-register berlin’s key on GuixSD?
>
> I vote yes.
>
>>   2. Do we add berlin.guixsd.org to the list of substitute servers on
>>      GuixSD?  On Guix?  The drawback is that ‘guix’ sometimes talks to
>>      both servers when retrieve substitute lists, which can be slightly
>>      slower/annoying, but otherwise I think it’s a win.
>
> I think it's worth the extra source of substitutes. Since adding
> berlin.guixsd.org to my list of substitute URLs, it seems like I need to
> build less often.
>
> In my experience, it's annoying to query multiple servers when my
> network connection is slow or unreliable. But, it's also annoying in
> that situation to need to download source files from a variety of
> upstream sites.

Sounds reasonable.  Let’s wait for a green light from Ricardo.

>> The main GuixSD annoying messages that I think we should address by
>> Tuesday are:
>> 
>>   1. “Error in finalization thread: Bad file descriptor” coming from the
>>      Shepherd;
>
> I'm not sure how to start debugging this :/ If I get some advice, I
> could try to fix it on Sunday and Monday.

I investigated and fixed it yesterday:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4bd70904c7f555a953808a9a4f892f462ffd352f

The thing is that there’s a separate finalization thread in Guile, which
takes care of finalizing dead objects.  For file ports, finalization
means closing the underlying file descriptor.  As it turns out,
‘close-port’ in Guile 2.0 would ignore EBADF errors, whereas
‘close-port’ in 2.2 reports them, hence the error.

The fix is to take extra care to close ports and not just the underlying
file descriptors.

>>   2. “udevd[304]: RUN{builtin}: 'uaccess' unknown /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
>
> I haven't seen this one before.

I compared the source of eudev and systemd, and indeed, like Maxim
wrote, the issue is that eudev does not support a “uaccess” built-in
tag.  So I pushed a fix that simply comments out that line:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f8446df663fecb5aa34e5c6dfa477544d3271d1e

There’s still room for improvement, but the console output is less messy
now.  :-)

Thanks,
Ludo’.

Re: Release!

[Ludovic Courtès]

Hello!

Ricardo Wurmus <rekado@elephly.net> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
>>>   1. Do we pre-register berlin’s key on GuixSD?
>>
>> I vote yes.
>>
>>>   2. Do we add berlin.guixsd.org to the list of substitute servers on
>>>      GuixSD?  On Guix?  The drawback is that ‘guix’ sometimes talks to
>>>      both servers when retrieve substitute lists, which can be slightly
>>>      slower/annoying, but otherwise I think it’s a win.
>>
>> I think it's worth the extra source of substitutes. Since adding
>> berlin.guixsd.org to my list of substitute URLs, it seems like I need to
>> build less often.
>>
>> In my experience, it's annoying to query multiple servers when my
>> network connection is slow or unreliable. But, it's also annoying in
>> that situation to need to download source files from a variety of
>> upstream sites.
>
> I’d like to add berlin.guix.org to the list of default substitute
> servers, but before I can allow this with a good conscience I need to
> increase space on the head node.  We were very busy, so the new head
> node and storage aren’t ready yet, and the old node that’s currently
> coordinating builds on berlin.guix.org has very limited storage.
>
> I’ll try to get the new storage ready on Monday.

Awesome.  Let us know how it goes and what we should do!

Thanks,
Ludo’.

Re: Release!

[Maxim Cournoyer]

Hi!

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

[...] (Great fix! :)

>>>   2. “udevd[304]: RUN{builtin}: 'uaccess' unknown /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
>>
>> I haven't seen this one before.
>
> I compared the source of eudev and systemd, and indeed, like Maxim
> wrote, the issue is that eudev does not support a “uaccess” built-in
> tag.  So I pushed a fix that simply comments out that line:
>
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f8446df663fecb5aa34e5c6dfa477544d3271d1e

Nitpick: Maybe we could reference to the issue so that a maintainer can
decide to remove that alteration after the "uaccess" issue gets properly
fixed (implemented).

> There’s still room for improvement, but the console output is less messy
> now.  :-)

Thank you for it!

Maxim

Release v1.4?

[zimoun]

Hi,

It is time for a release!  We were almost there on January… time
flies. ;-)

Many things are pending and I feel we need a small impulsion for a
general motivation. :-)

Well, it seems conditioned by the status of the build farms.  Is all
fine in this area?


Schedule a release is the occasion to tackle some not-so-fun tasks as
merging the ’staging’ branch [1], many upgrades as Haskell [2] or Julia,
etc.

Even, it could also be the occasion to complete the purge of Python 2. :-)

Vagrant proposed [3] to fix low-hanging fruit issues in synopsis and
description.  It is an occasion for a meetup [4].

For instance, a release date on July could be neat.  WDYT?


Please comment bug#53214 [5] or answer to this message for listing the
blocking points; as discussed in this thread [6].


1: <https://yhetil.org/guix/878rrn5vy3.fsf@inria.fr>
2: <https://yhetil.org/guix/Yl/9/Ly/WevaVxlj@noor.fritz.box>
3: <https://yhetil.org/guix/877dbxznto.fsf@ponder>
4: <https://yhetil.org/guix/87pmmkt6k2.fsf@contorta>
5: <http://issues.guix.gnu.org/issue/53214>
6: <https://yhetil.org/guix/86ilvnh7kt.fsf@gmail.com>


Cheers,
simon

Re: Release v1.4?

[Ludovic Courtès]

Hello!

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

> Schedule a release is the occasion to tackle some not-so-fun tasks as
> merging the ’staging’ branch [1], many upgrades as Haskell [2] or Julia,
> etc.

Thanks for the heads-up!  I think merging ‘staging’ should be
top-priority.  People are welcome to upgrade/reconfigure from it with:

  guix time-machine --branch=staging -- …

Remaining things to check:

  - [ ] system tests
  - [ ] status on non-x86_64 architectures

Ludo’.

Re: Release v1.4?

[zimoun]

Hi,

On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès <ludo@gnu.org> wrote:

>   guix time-machine --branch=staging -- …
>
> Remaining things to check:
>
>   - [ ] system tests
>   - [ ] status on non-x86_64 architectures

I agree.  To me, it is part of the same effort.  From my point of view,
we missed the window for releasing at the previous core-updates merge.
I would like to avoid to miss it. :-)

Somehow, we all have various constraints on our agenda so if we do not
set some deadlines in advance, it is hard to free some slots compared to
the continuous other “urgent” tasks from elsewhere.

My email is a call (July is a proposal) for synchronizing our agenda and
agree on some deadlines and make them happen.


Cheers,
simon

Re: Release v1.4?

[vidak]

On 2022-06-06 01:57, zimoun wrote:
> Hi,
> 
> On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès <ludo@gnu.org> wrote:
> 
>>   guix time-machine --branch=staging -- …
>>
>> Remaining things to check:
>>
>>   - [ ] system tests
>>   - [ ] status on non-x86_64 architectures
> 
> I agree.  To me, it is part of the same effort.  From my point of view,
> we missed the window for releasing at the previous core-updates merge.
> I would like to avoid to miss it. :-)
> 
> Somehow, we all have various constraints on our agenda so if we do not
> set some deadlines in advance, it is hard to free some slots compared to
> the continuous other “urgent” tasks from elsewhere.
> 
> My email is a call (July is a proposal) for synchronizing our agenda and
> agree on some deadlines and make them happen.
> 
> 
> Cheers,
> simon

can i help with the system tests?

how do i do those?

~vidak

Re: Release v1.4?

[Maxim Cournoyer]

Hello,

vidak@riseup.net writes:

> On 2022-06-06 01:57, zimoun wrote:
>> Hi,
>> 
>> On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès <ludo@gnu.org> wrote:
>> 
>>>   guix time-machine --branch=staging -- …
>>>
>>> Remaining things to check:
>>>
>>>   - [ ] system tests
>>>   - [ ] status on non-x86_64 architectures
>> 
>> I agree.  To me, it is part of the same effort.  From my point of view,
>> we missed the window for releasing at the previous core-updates merge.
>> I would like to avoid to miss it. :-)
>> 
>> Somehow, we all have various constraints on our agenda so if we do not
>> set some deadlines in advance, it is hard to free some slots compared to
>> the continuous other “urgent” tasks from elsewhere.
>> 
>> My email is a call (July is a proposal) for synchronizing our agenda and
>> agree on some deadlines and make them happen.
>> 
>> 
>> Cheers,
>> simon
>
> can i help with the system tests?
>
> how do i do those?

You can run them locally with 'make check-system' (beware: some are
expensive).

Thanks!

Maxim

Merging ‘staging’?

[Ludovic Courtès]

Hi,

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

> Thanks for the heads-up!  I think merging ‘staging’ should be
> top-priority.  People are welcome to upgrade/reconfigure from it with:
>
>   guix time-machine --branch=staging -- …
>
> Remaining things to check:
>
>   - [ ] system tests

I set up a jobset and we’re doing okay compared to ‘master’:

  https://ci.guix.gnu.org/jobset/staging-tests

The main regression is the timescaledb test, because timescaledb fails
its tests on that branch (help welcome!).

Then there’s what looks like a transient failure of the installation
test, which is more worrisome but not a regression I believe:

--8<---------------cut here---------------start------------->8---
Jun  5 17:44:46 localhost installer[252]: command ("guix" "system" "init" "--fallback" "--no-grafts" "--no-substitutes" "/mnt/etc/config.scm" "/mnt") succeeded 

conversation expecting pattern ((quote installation-complete))
Jun  5 17:44:46 localhost shepherd[1]: Service guix-daemon has been stopped. 

Jun  5 17:44:46 localhost shepherd[1]: Service guix-daemon has been started. 

Jun  5 17:44:46 localhost installer[252]: crashing due to uncaught exception: system-error ("umount" "~S: ~A" ("/remove" "Device or resource busy") (16)) 

Jun  5 17:44:47 localhost installer[252]: running form #<newt-form 21d9960> ("Unexpected problem") with 1 clients 

Jun  5 17:44:47 localhost installer[252]: form #<newt-form 21d9960> ("Unexpected problem"): client 20 replied #t 

/gnu/store/87wf3r1v18an9cj8d2jkh0240g07dqd6-shepherd-marionette.scm:1:1718: ERROR:
  1. &pattern-not-matched:
      pattern: ((quote installation-complete))
      sexp: (contents-dialog (title "Unexpected problem") (text "The installer has encountered an unexpected problem. The backtrace is displayed below. You may choose to exit or create a dump archive.") (content "In ./gnu/installer/steps.scm:\n   144:13 19 (run ((substitutes . #f) (network (select-technology . #<<technology> name: \"Wired\" type: \"ethernet\" powered?: #t connected?: #t>) (power-technology . #<unspecified>) (# . #<<???>) ???) ???) ???)\n   144:13 18 (run ((user #<<user> name: \"root\" real-name: \"\" group: \"users\" password: <secret> home-directory: \"/root\"> #<<user> name: \"alice\" real-name: \"Alice\" group: \"users\" password: <s???> ???) ???) ???)\n   144:13 17 (run ((services #<<system-service> name: \"GNOME\" type: desktop recommended?: #f snippet: ((service gnome-desktop-service-type)) packages: ()> #<<system-service> name: \"Xfce\" ty???> ???) ???) ???)\n   142:23 16 (run ((partition #<<user-partition> name: #f type: normal file-name: \"/dev/vda1\" disk-file-name: \"/dev/vda\" crypt-label: #f crypt-password: #f fs-type: ext4 bootable?: #t esp?:???> ???) ???) ???)\nIn ./gnu/installer/newt/final.scm:\n   128:11 15 (run-final-page ((partition #<<user-partition> name: #f type: normal file-name: \"/dev/vda1\" disk-file-name: \"/dev/vda\" crypt-label: #f crypt-password: #f fs-type: ext4 bootable???> ???) ???) ???)\n   101:21 14 (run-install-shell \"en_HK.utf8\" #:users _)\nIn ./gnu/installer/final.scm:\n    191:5 13 (install-system \"en_HK.utf8\" #:users _)\n   113:13 12 (call-with-mnt-container #<procedure 7f6f6b992080 at ./gnu/installer/final.scm:192:7 ()>)\nIn gnu/build/linux-container.scm:\n   265:16 11 (run-container _ _ (mnt) _ #<procedure 7f6f6b992080 at ./gnu/installer/final.scm:192:7 ()> #:guest-uid _ #:guest-gid _)\nIn ./gnu/installer/final.scm:\n   222:13 10 (_)\nIn gnu/build/install.scm:\n    270:5  9 (unmount-cow-store \"/mnt\" \"/tmp/guix-inst\")\nIn guix/build/syscalls.scm:\n    588:8  8 (_ _ _ #:update-mtab? _)\nIn ice-9/boot-9.scm:\n  1685:16  7 (raise-exception _ #:continuable? _)\n  1780:13  6 (_ #<&compound-exception components: (#<&external-error> #<&origin origin: \"umount\"> #<&message message: \"~S: ~A\"> #<&irritants irritants: (\"/remove\" \"Device or resource busy\")> #<&ex???>)\nIn ice-9/eval.scm:\n    619:8  5 (_ #(#(#(#<directory (guile-user) 7f6f74584c80>) system-error (\"umount\" \"~S: ~A\" (\"/remove\" \"Device or resource busy\") (16))) #<variable 7f6f60988c40 value: #<unspecified>> #<varia???> ???))\n   626:19  4 (_ #(#(#(#<directory (guile-user) 7f6f74584c80>) system-error (\"umount\" \"~S: ~A\" (\"/remove\" \"Device or resource busy\") (16))) #<variable 7f6f60988c40 value: #<unspecified>> #<varia???> ???))\nIn ./gnu/installer/dump.scm:\n     54:4  3 (prepare-dump system-error (\"umount\" \"~S: ~A\" (\"/remove\" \"Device or resource busy\") (16)) #:result _)\nIn ice-9/ports.scm:\n   433:17  2 (call-with-output-file _ _ #:binary _ #:encoding _)\nIn ./gnu/installer/dump.scm:\n    56:27  1 (_ #<output: installer-backtrace 7>)\nIn unknown file:\n           0 (make-stack #t)\n./gnu/installer/dump.scm:58:36: In procedure umount: \"/remove\": Device or resource busy\n"))
Jun  5 17:44:47 localhost installer[196]: unmounting "/mnt/" 

Backtrace:
           2 (primitive-load "/gnu/store/58r38d916naqslddflkwf8xavyv?")
In ice-9/eval.scm:
   191:35  1 (_ #f)
    619:8  0 (_ #(#<directory (guile-user) 7fffeffcfc80> #<variabl?>))

ice-9/eval.scm:619:8: Throw to key `marionette-eval-failure' with args `((quote (complete-installation installer-socket)))'.
builder for `/gnu/store/zmg87adhblg5c7jv0c06wsb7rancxxq0-installation.drv' failed with exit code 1
@ build-failed /gnu/store/zmg87adhblg5c7jv0c06wsb7rancxxq0-installation.drv - 1 builder for `/gnu/store/zmg87adhblg5c7jv0c06wsb7rancxxq0-installation.drv' failed with exit code 1
cannot build derivation `/gnu/store/2lr3d1yapxf8azx7mzxkmgxc4zgl9sky-gui-installed-desktop-os-encrypted.drv': 1 dependencies couldn't be built
--8<---------------cut here---------------end--------------->8---

(From <https://ci.guix.gnu.org/build/958038/details>.)

>   - [ ] status on non-x86_64 architectures

‘guix weather -s i686-linux’ says 89% (which is underestimated, because
it wrongfully checks for all the packages, including unsupported
packages), which sounds good.

We have to check for AArch64 & co.  Any takers?

Overall it seems to me we should be able to merge ‘staging’ within a
couple of days.  Thoughts?

Ludo’.

Re: Merging ‘staging’?

[Efraim Flashner]

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

On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Ludovic Courtès <ludo@gnu.org> skribis:
> 
> ‘guix weather -s i686-linux’ says 89% (which is underestimated, because
> it wrongfully checks for all the packages, including unsupported
> packages), which sounds good.
> 
> We have to check for AArch64 & co.  Any takers?
> 
> Overall it seems to me we should be able to merge ‘staging’ within a
> couple of days.  Thoughts?

Currently ci.guix.gnu.org isn't building any of the aarch64 packages,
and it looks like it hasn't since about May 26th. Once those start
building again I expect we'll see it's doing well. Minus perhaps the
rust stuff since I'm not sure the offload build machines can handle
that.

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

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

Re: Merging ‘staging’?

[Ludovic Courtès]

Hey Efraim,

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

> On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote:
>> Hi,
>> 
>> Ludovic Courtès <ludo@gnu.org> skribis:
>> 
>> ‘guix weather -s i686-linux’ says 89% (which is underestimated, because
>> it wrongfully checks for all the packages, including unsupported
>> packages), which sounds good.
>> 
>> We have to check for AArch64 & co.  Any takers?
>> 
>> Overall it seems to me we should be able to merge ‘staging’ within a
>> couple of days.  Thoughts?
>
> Currently ci.guix.gnu.org isn't building any of the aarch64 packages,
> and it looks like it hasn't since about May 26th. Once those start
> building again I expect we'll see it's doing well. Minus perhaps the
> rust stuff since I'm not sure the offload build machines can handle
> that.

Hmm the situation is bad indeed:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env  guix weather -s aarch64-linux -c200
computing 18,932 package derivations for aarch64-linux...
looking for 19,704 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  17.1% substitutes available (3,360 out of 19,704)
  at least 22,303.1 MiB of nars (compressed)
  24,029.2 MiB on disk (uncompressed)
  0.006 seconds per request (114.2 seconds in total)
  172.5 requests per second

  5.3% (870 out of 16,344) of the missing items are queued
  at least 1,000 queued builds
      aarch64-linux: 840 (84.0%)
      x86_64-linux: 84 (8.4%)
      powerpc64le-linux: 72 (7.2%)
      armhf-linux: 4 (.4%)
  build rate: 143.62 builds per hour
      i686-linux: 99.96 builds per hour
      x86_64-linux: 31.51 builds per hour
      aarch64-linux: 25.66 builds per hour
      powerpc64le-linux: 3.14 builds per hour
729 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', among which:
  14236	libxft@2.3.3	/gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3 
  10066	icu4c@69.1	/gnu/store/n9nx5rmnhdf3hdswhvns31diayq9vfq2-icu4c-69.1 
  7723	jbig2dec@0.19	/gnu/store/lrpczm2m0agx0x5rp6kmn8c46mc85l35-jbig2dec-0.19 
  6552	libxt@1.2.1	/gnu/store/rqqkla9kqjq3182gdqynkq2jb4jf2bl5-libxt-1.2.1-doc /gnu/store/82pzzkny0gwdfkfa5zvnyy4vbzxqnwyy-libxt-1.2.1 
  4555	openblas@0.3.20	/gnu/store/wc8cbkcvgqkdf65fj7drb82plkf8igyw-openblas-0.3.20 
  4231	libxfixes@6.0.0	/gnu/store/h70i9gyvif5kzpw7a8bdaxhw7sqiv7wz-libxfixes-6.0.0 
  3788	libxrandr@1.5.2	/gnu/store/9gqkb75sr60lxic9a3nx543a6wxz0866-libxrandr-1.5.2 
  3320	libxkbfile@1.1.0	/gnu/store/kk0xk8j8ffgxvfs5kz1vxp2ipz28xwh4-libxkbfile-1.1.0 
  3297	xcb-util@0.4.0	/gnu/store/n2x5kvy5zxbnh28ak7rbvw6brp97z1c9-xcb-util-0.4.0 
  3279	xcb-util-wm@0.4.1	/gnu/store/hhasmz0l5f10f9nfg0nx378c7bcgf9v0-xcb-util-wm-0.4.1 
  3263	libxres@1.2.1	/gnu/store/5mpjhsyq2bbri006g7lh6h82239s8fb8-libxres-1.2.1 
  1383	xprop@1.2.5	/gnu/store/61x7vscvrz8zqda73dlq5x35anhz8f8k-xprop-1.2.5 
  1381	xdg-user-dirs@0.17	/gnu/store/gab0ycim14xflaxzp8arg8hfapx73z3l-xdg-user-dirs-0.17 
  1368	docbook2x@0.8.8	/gnu/store/cclsrji5p14aj8bg3kmhkj5532k7l5m4-docbook2x-0.8.8 
  1286	perl-net-ssleay@1.92	/gnu/store/cn77pic9249j7h002a9701v0xzpi28yk-perl-net-ssleay-1.92 
  1179	emacs-minimal@28.1	/gnu/store/c768r60pj3f2af2ysbjqdnlxwpgwmmpp-emacs-minimal-28.1 
  1121	go-std@1.17.9	/gnu/store/fqdkzg6nlzhj93ysjqxrmqsz8srq2l9r-go-std-1.17.9 
  1021	ruby-activemodel@6.1.3	/gnu/store/12gm34s68siqdfagc16ldjdp03klc5xw-ruby-activemodel-6.1.3 
  1005	ruby-shoulda-matchers@2.8.0	/gnu/store/zcbdlp0qqb3axsmfvd8rdmn70kwdiw11-ruby-shoulda-matchers-2.8.0 
  1001	ruby-webmock@2.3.2	/gnu/store/jfrng4404avghlkyxw2y5hqpdn8v3mih-ruby-webmock-2.3.2 
   976	ruby-sawyer@0.8.2	/gnu/store/w0aaby4lvdcz0dr5006mx2ik6l1v2s5l-ruby-sawyer-0.8.2 
   634	jikes@1.22	/gnu/store/nwkrhbzbd8s9dysgik58af93b2kjm4w3-jikes-1.22 
   622	nss-certs@3.71	/gnu/store/01k1v00g7vc7n90y5yr9bacrnr3ml46p-nss-certs-3.71 
   576	texlive-latex-cmap@59745	/gnu/store/zdws0y31a1hhgxb80qc2lx4smmp9pmgc-texlive-latex-cmap-59745 
   558	libxft@2.3.3	/gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3 
   491	xmodmap@1.0.10	/gnu/store/rm8ww2flazqypwiagizbbsslv0g86h67-xmodmap-1.0.10 
   489	ucd@14.0.0	/gnu/store/f3hkrqnsj9dadliaixrlh17z4c9bsjfl-ucd-14.0.0 
   400	jbig2dec@0.19	/gnu/store/lrpczm2m0agx0x5rp6kmn8c46mc85l35-jbig2dec-0.19 
   317	icu4c@69.1	/gnu/store/n9nx5rmnhdf3hdswhvns31diayq9vfq2-icu4c-69.1 
   309	libxt@1.2.1	/gnu/store/rqqkla9kqjq3182gdqynkq2jb4jf2bl5-libxt-1.2.1-doc /gnu/store/82pzzkny0gwdfkfa5zvnyy4vbzxqnwyy-libxt-1.2.1 
   290	libxfixes@6.0.0	/gnu/store/h70i9gyvif5kzpw7a8bdaxhw7sqiv7wz-libxfixes-6.0.0 
   272	libunwind-julia@1.3.1	/gnu/store/i8c1hpdxdjb86vn4bqjiml5gad6mnrw5-libunwind-julia-1.3.1 
   268	ocaml@4.14.0	/gnu/store/zvz0xlwm7mvipr7c8q15fw7r6r25nn4s-ocaml-4.14.0 
   256	mailutils@3.15	/gnu/store/6c5sd4z84p8mbck8b5vn4vd6s05mkbrc-mailutils-3.15 
   246	libxrandr@1.5.2	/gnu/store/9gqkb75sr60lxic9a3nx543a6wxz0866-libxrandr-1.5.2 
   241	libxkbfile@1.1.0	/gnu/store/kk0xk8j8ffgxvfs5kz1vxp2ipz28xwh4-libxkbfile-1.1.0 
   238	xcb-util@0.4.0	/gnu/store/n2x5kvy5zxbnh28ak7rbvw6brp97z1c9-xcb-util-0.4.0 
   237	xcb-util-wm@0.4.1	/gnu/store/hhasmz0l5f10f9nfg0nx378c7bcgf9v0-xcb-util-wm-0.4.1 
   237	libxres@1.2.1	/gnu/store/5mpjhsyq2bbri006g7lh6h82239s8fb8-libxres-1.2.1 
   233	openblas@0.3.20	/gnu/store/wc8cbkcvgqkdf65fj7drb82plkf8igyw-openblas-0.3.20 
   226	xdg-user-dirs@0.17	/gnu/store/gab0ycim14xflaxzp8arg8hfapx73z3l-xdg-user-dirs-0.17 
   223	xprop@1.2.5	/gnu/store/61x7vscvrz8zqda73dlq5x35anhz8f8k-xprop-1.2.5 
   223	docbook2x@0.8.8	/gnu/store/cclsrji5p14aj8bg3kmhkj5532k7l5m4-docbook2x-0.8.8 
--8<---------------cut here---------------end--------------->8---

There are currently three Overdrive machines processing the AArch64
build backlog:

  https://ci.guix.gnu.org/workers

I propose to let them do more work overnight and merge tomorrow
afternoon CEST.  How does that sound?

Thanks,
Ludo’.

Re: Merging ‘staging’?

[pelzflorian (Florian Pelz)]

On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote:
> We have to check for AArch64 & co.  Any takers?
> 
> Overall it seems to me we should be able to merge ‘staging’ within a
> couple of days.  Thoughts?
> 
> Ludo’.
> 

I mostly succeeded in updating my rock64 aarch64 machine

guix time-machine --branch=staging -- package -m ~/keep/guixsd/rock64-manifest.scm

but building llvm@11 fails (needed for mesa, I think).  The log ends with:

[...]
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 97%] Built target verify-uselistorder
make  -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make tools/yaml2obj/CMakeFiles/yaml2obj.dir/depend
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/tools/yaml2obj /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj/CMakeFiles/yaml2obj.dir/DependInfo.cmake --color=
Consolidate compiler generated dependencies of target yaml2obj
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make  -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make tools/yaml2obj/CMakeFiles/yaml2obj.dir/build
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 98%] Linking CXX executable ../../bin/yaml2obj
cd /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_link_script CMakeFiles/yaml2obj.dir/link.txt --verbose=1
/gnu/store/dbcbcaxq20kbkhh2mr8k98qfnymq22kp-gcc-10.3.0/bin/c++  -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -O3 -DNDEBUG  -Wl,-allow-shlib-undefined  -Wl,-O3 -Wl,--gc-sections CMakeFiles/yaml2obj.dir/yaml2obj.cpp.o -o ../../bin/yaml2obj  -Wl,-rpath,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib:::::::::::::::: ../../lib/libLLVMObjectYAML.so.11 -lpthread ../../lib/libLLVMSupport.so.11 -Wl,-rpath-link,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib 
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 98%] Built target yaml2obj
make  -f examples/Bye/CMakeFiles/Bye.dir/build.make examples/Bye/CMakeFiles/Bye.dir/depend
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/examples/Bye /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye /tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye/CMakeFiles/Bye.dir/DependInfo.cmake --color=
Consolidate compiler generated dependencies of target Bye
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make  -f examples/Bye/CMakeFiles/Bye.dir/build.make examples/Bye/CMakeFiles/Bye.dir/build
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make[2]: Nothing to be done for 'examples/Bye/CMakeFiles/Bye.dir/build'.
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 98%] Built target Bye
make  -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make unittests/Passes/CMakeFiles/TestPlugin.dir/depend
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/unittests/Passes /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes/CMakeFiles/TestPlugin.dir/DependInfo.cmake --color=
Consolidate compiler generated dependencies of target TestPlugin
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make  -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make unittests/Passes/CMakeFiles/TestPlugin.dir/build
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make[2]: Nothing to be done for 'unittests/Passes/CMakeFiles/TestPlugin.dir/build'.
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
[ 98%] Built target TestPlugin
make  -f unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/build.make unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/depend
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/unittests/Support/DynamicLibrary /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Support/DynamicLibrary /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/DependInfo.cmake --color=
Consolidate compiler generated dependencies of target SecondLib
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make  -f unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/build.make unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/build
make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make[2]: *** No rule to make target 'unittests/Support/DynamicLibrary/%p/Inputs/macho-universal.x86_64.i386', needed by 'unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/PipSqueak.cpp.o'.  Stop.
make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:115594: unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/all] Error 2
make[1]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
make: *** [Makefile:159: all] Error 2
error: in phase 'install': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("install") exit-status: 2 term-signal: #f stop-signal: #f> 
phase `install' failed after 317.1 seconds
command "make" "install" failed with status 2


(The build of llvm@11 also needed a few retries because gcc randomly
fails sometimes (once with a segfault).  That is not a Guix bug
though, I think, but peculiarities of the rock64.)

Regards,
Florian

Re: Merging ‘staging’?

[Efraim Flashner]

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

On Thu, Jun 09, 2022 at 07:19:30PM +0200, pelzflorian (Florian Pelz) wrote:
> On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote:
> > We have to check for AArch64 & co.  Any takers?
> > 
> > Overall it seems to me we should be able to merge ‘staging’ within a
> > couple of days.  Thoughts?
> > 
> > Ludo’.
> > 
> 
> I mostly succeeded in updating my rock64 aarch64 machine
> 
> guix time-machine --branch=staging -- package -m ~/keep/guixsd/rock64-manifest.scm
> 
> but building llvm@11 fails (needed for mesa, I think).  The log ends with:
> 
> [...]
> make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> [ 97%] Built target verify-uselistorder
> make  -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make tools/yaml2obj/CMakeFiles/yaml2obj.dir/depend
> make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/tools/yaml2obj /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj/CMakeFiles/yaml2obj.dir/DependInfo.cmake --color=
> Consolidate compiler generated dependencies of target yaml2obj
> make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> make  -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make tools/yaml2obj/CMakeFiles/yaml2obj.dir/build
> make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> [ 98%] Linking CXX executable ../../bin/yaml2obj
> cd /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_link_script CMakeFiles/yaml2obj.dir/link.txt --verbose=1
> /gnu/store/dbcbcaxq20kbkhh2mr8k98qfnymq22kp-gcc-10.3.0/bin/c++  -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -O3 -DNDEBUG  -Wl,-allow-shlib-undefined  -Wl,-O3 -Wl,--gc-sections CMakeFiles/yaml2obj.dir/yaml2obj.cpp.o -o ../../bin/yaml2obj  -Wl,-rpath,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib:::::::::::::::: ../../lib/libLLVMObjectYAML.so.11 -lpthread ../../lib/libLLVMSupport.so.11 -Wl,-rpath-link,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib 
> make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> [ 98%] Built target yaml2obj
> make  -f examples/Bye/CMakeFiles/Bye.dir/build.make examples/Bye/CMakeFiles/Bye.dir/depend
> make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/examples/Bye /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye /tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye/CMakeFiles/Bye.dir/DependInfo.cmake --color=
> Consolidate compiler generated dependencies of target Bye
> make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> make  -f examples/Bye/CMakeFiles/Bye.dir/build.make examples/Bye/CMakeFiles/Bye.dir/build
> make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> make[2]: Nothing to be done for 'examples/Bye/CMakeFiles/Bye.dir/build'.
> make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> [ 98%] Built target Bye
> make  -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make unittests/Passes/CMakeFiles/TestPlugin.dir/depend
> make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/unittests/Passes /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes/CMakeFiles/TestPlugin.dir/DependInfo.cmake --color=
> Consolidate compiler generated dependencies of target TestPlugin
> make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> make  -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make unittests/Passes/CMakeFiles/TestPlugin.dir/build
> make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> make[2]: Nothing to be done for 'unittests/Passes/CMakeFiles/TestPlugin.dir/build'.
> make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> [ 98%] Built target TestPlugin
> make  -f unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/build.make unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/depend
> make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/unittests/Support/DynamicLibrary /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Support/DynamicLibrary /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/DependInfo.cmake --color=
> Consolidate compiler generated dependencies of target SecondLib
> make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> make  -f unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/build.make unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/build
> make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> make[2]: *** No rule to make target 'unittests/Support/DynamicLibrary/%p/Inputs/macho-universal.x86_64.i386', needed by 'unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/PipSqueak.cpp.o'.  Stop.
> make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> make[1]: *** [CMakeFiles/Makefile2:115594: unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/all] Error 2
> make[1]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build'
> make: *** [Makefile:159: all] Error 2
> error: in phase 'install': uncaught exception:
> %exception #<&invoke-error program: "make" arguments: ("install") exit-status: 2 term-signal: #f stop-signal: #f> 
> phase `install' failed after 317.1 seconds
> command "make" "install" failed with status 2
> 
> 
> (The build of llvm@11 also needed a few retries because gcc randomly
> fails sometimes (once with a segfault).  That is not a Guix bug
> though, I think, but peculiarities of the rock64.)
> 
> Regards,
> Florian

I know I've built llvm@11 and mesa on aarch64 hardware for staging.
Also, you're missing the actual error message there, We only have
Error 2. I was able to build my pine64's OS config on staging although I
haven't tried deploying it.

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

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

Re: Merging ‘staging’?

[pelzflorian (Florian Pelz)]

On Thu, Jun 09, 2022 at 08:41:21PM +0300, Efraim Flashner wrote:
> I know I've built llvm@11 and mesa on aarch64 hardware for staging.

Oh I see I'm missing the last merge; I'm still at commit b422687cbd.

I will try again with staging at 091eb323ba27.  But it will take a
long time; feel free to proceed regardless.

Regards,
Florian

Re: Merging ‘staging’?

[pelzflorian (Florian Pelz)]

On Thu, Jun 09, 2022 at 09:02:14PM +0200, pelzflorian (Florian Pelz) wrote:
> I will try again with staging at 091eb323ba27.

llvm@11 was built successfully.  Sorry for the noise.

Regards,
Florian

Re: Merging ‘staging’?

[Efraim Flashner]

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

On Wed, Jun 08, 2022 at 11:24:22PM +0200, Ludovic Courtès wrote:
> Hey Efraim,
> 
> Efraim Flashner <efraim@flashner.co.il> skribis:
> 
> > On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote:
> >> Hi,
> >> 
> >> Ludovic Courtès <ludo@gnu.org> skribis:
> >> 
> >> ‘guix weather -s i686-linux’ says 89% (which is underestimated, because
> >> it wrongfully checks for all the packages, including unsupported
> >> packages), which sounds good.
> >> 
> >> We have to check for AArch64 & co.  Any takers?
> >> 
> >> Overall it seems to me we should be able to merge ‘staging’ within a
> >> couple of days.  Thoughts?
> >
> > Currently ci.guix.gnu.org isn't building any of the aarch64 packages,
> > and it looks like it hasn't since about May 26th. Once those start
> > building again I expect we'll see it's doing well. Minus perhaps the
> > rust stuff since I'm not sure the offload build machines can handle
> > that.
> 
> Hmm the situation is bad indeed:
> 
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env  guix weather -s aarch64-linux -c200
> computing 18,932 package derivations for aarch64-linux...
> looking for 19,704 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org
>   17.1% substitutes available (3,360 out of 19,704)
>   at least 22,303.1 MiB of nars (compressed)
>   24,029.2 MiB on disk (uncompressed)
>   0.006 seconds per request (114.2 seconds in total)
>   172.5 requests per second
> 
>   5.3% (870 out of 16,344) of the missing items are queued
>   at least 1,000 queued builds
>       aarch64-linux: 840 (84.0%)
>       x86_64-linux: 84 (8.4%)
>       powerpc64le-linux: 72 (7.2%)
>       armhf-linux: 4 (.4%)
>   build rate: 143.62 builds per hour
>       i686-linux: 99.96 builds per hour
>       x86_64-linux: 31.51 builds per hour
>       aarch64-linux: 25.66 builds per hour
>       powerpc64le-linux: 3.14 builds per hour
> 729 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', among which:
>   14236	libxft@2.3.3	/gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3 
>   10066	icu4c@69.1	/gnu/store/n9nx5rmnhdf3hdswhvns31diayq9vfq2-icu4c-69.1 
>   7723	jbig2dec@0.19	/gnu/store/lrpczm2m0agx0x5rp6kmn8c46mc85l35-jbig2dec-0.19 
>   6552	libxt@1.2.1	/gnu/store/rqqkla9kqjq3182gdqynkq2jb4jf2bl5-libxt-1.2.1-doc /gnu/store/82pzzkny0gwdfkfa5zvnyy4vbzxqnwyy-libxt-1.2.1 
>   4555	openblas@0.3.20	/gnu/store/wc8cbkcvgqkdf65fj7drb82plkf8igyw-openblas-0.3.20 
>   4231	libxfixes@6.0.0	/gnu/store/h70i9gyvif5kzpw7a8bdaxhw7sqiv7wz-libxfixes-6.0.0 
>   3788	libxrandr@1.5.2	/gnu/store/9gqkb75sr60lxic9a3nx543a6wxz0866-libxrandr-1.5.2 
>   3320	libxkbfile@1.1.0	/gnu/store/kk0xk8j8ffgxvfs5kz1vxp2ipz28xwh4-libxkbfile-1.1.0 
>   3297	xcb-util@0.4.0	/gnu/store/n2x5kvy5zxbnh28ak7rbvw6brp97z1c9-xcb-util-0.4.0 
>   3279	xcb-util-wm@0.4.1	/gnu/store/hhasmz0l5f10f9nfg0nx378c7bcgf9v0-xcb-util-wm-0.4.1 
>   3263	libxres@1.2.1	/gnu/store/5mpjhsyq2bbri006g7lh6h82239s8fb8-libxres-1.2.1 
>   1383	xprop@1.2.5	/gnu/store/61x7vscvrz8zqda73dlq5x35anhz8f8k-xprop-1.2.5 
>   1381	xdg-user-dirs@0.17	/gnu/store/gab0ycim14xflaxzp8arg8hfapx73z3l-xdg-user-dirs-0.17 
>   1368	docbook2x@0.8.8	/gnu/store/cclsrji5p14aj8bg3kmhkj5532k7l5m4-docbook2x-0.8.8 
>   1286	perl-net-ssleay@1.92	/gnu/store/cn77pic9249j7h002a9701v0xzpi28yk-perl-net-ssleay-1.92 
>   1179	emacs-minimal@28.1	/gnu/store/c768r60pj3f2af2ysbjqdnlxwpgwmmpp-emacs-minimal-28.1 
>   1121	go-std@1.17.9	/gnu/store/fqdkzg6nlzhj93ysjqxrmqsz8srq2l9r-go-std-1.17.9 
>   1021	ruby-activemodel@6.1.3	/gnu/store/12gm34s68siqdfagc16ldjdp03klc5xw-ruby-activemodel-6.1.3 
>   1005	ruby-shoulda-matchers@2.8.0	/gnu/store/zcbdlp0qqb3axsmfvd8rdmn70kwdiw11-ruby-shoulda-matchers-2.8.0 
>   1001	ruby-webmock@2.3.2	/gnu/store/jfrng4404avghlkyxw2y5hqpdn8v3mih-ruby-webmock-2.3.2 
>    976	ruby-sawyer@0.8.2	/gnu/store/w0aaby4lvdcz0dr5006mx2ik6l1v2s5l-ruby-sawyer-0.8.2 
>    634	jikes@1.22	/gnu/store/nwkrhbzbd8s9dysgik58af93b2kjm4w3-jikes-1.22 
>    622	nss-certs@3.71	/gnu/store/01k1v00g7vc7n90y5yr9bacrnr3ml46p-nss-certs-3.71 
>    576	texlive-latex-cmap@59745	/gnu/store/zdws0y31a1hhgxb80qc2lx4smmp9pmgc-texlive-latex-cmap-59745 
>    558	libxft@2.3.3	/gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3 
>    491	xmodmap@1.0.10	/gnu/store/rm8ww2flazqypwiagizbbsslv0g86h67-xmodmap-1.0.10 
>    489	ucd@14.0.0	/gnu/store/f3hkrqnsj9dadliaixrlh17z4c9bsjfl-ucd-14.0.0 
>    400	jbig2dec@0.19	/gnu/store/lrpczm2m0agx0x5rp6kmn8c46mc85l35-jbig2dec-0.19 
>    317	icu4c@69.1	/gnu/store/n9nx5rmnhdf3hdswhvns31diayq9vfq2-icu4c-69.1 
>    309	libxt@1.2.1	/gnu/store/rqqkla9kqjq3182gdqynkq2jb4jf2bl5-libxt-1.2.1-doc /gnu/store/82pzzkny0gwdfkfa5zvnyy4vbzxqnwyy-libxt-1.2.1 
>    290	libxfixes@6.0.0	/gnu/store/h70i9gyvif5kzpw7a8bdaxhw7sqiv7wz-libxfixes-6.0.0 
>    272	libunwind-julia@1.3.1	/gnu/store/i8c1hpdxdjb86vn4bqjiml5gad6mnrw5-libunwind-julia-1.3.1 
>    268	ocaml@4.14.0	/gnu/store/zvz0xlwm7mvipr7c8q15fw7r6r25nn4s-ocaml-4.14.0 
>    256	mailutils@3.15	/gnu/store/6c5sd4z84p8mbck8b5vn4vd6s05mkbrc-mailutils-3.15 
>    246	libxrandr@1.5.2	/gnu/store/9gqkb75sr60lxic9a3nx543a6wxz0866-libxrandr-1.5.2 
>    241	libxkbfile@1.1.0	/gnu/store/kk0xk8j8ffgxvfs5kz1vxp2ipz28xwh4-libxkbfile-1.1.0 
>    238	xcb-util@0.4.0	/gnu/store/n2x5kvy5zxbnh28ak7rbvw6brp97z1c9-xcb-util-0.4.0 
>    237	xcb-util-wm@0.4.1	/gnu/store/hhasmz0l5f10f9nfg0nx378c7bcgf9v0-xcb-util-wm-0.4.1 
>    237	libxres@1.2.1	/gnu/store/5mpjhsyq2bbri006g7lh6h82239s8fb8-libxres-1.2.1 
>    233	openblas@0.3.20	/gnu/store/wc8cbkcvgqkdf65fj7drb82plkf8igyw-openblas-0.3.20 
>    226	xdg-user-dirs@0.17	/gnu/store/gab0ycim14xflaxzp8arg8hfapx73z3l-xdg-user-dirs-0.17 
>    223	xprop@1.2.5	/gnu/store/61x7vscvrz8zqda73dlq5x35anhz8f8k-xprop-1.2.5 
>    223	docbook2x@0.8.8	/gnu/store/cclsrji5p14aj8bg3kmhkj5532k7l5m4-docbook2x-0.8.8 
> --8<---------------cut here---------------end--------------->8---
> 
> There are currently three Overdrive machines processing the AArch64
> build backlog:
> 
>   https://ci.guix.gnu.org/workers
> 
> I propose to let them do more work overnight and merge tomorrow
> afternoon CEST.  How does that sound?
> 

My main concern is that so few of the missing items are queued to be
built. I've restarted some of them manually, but we're going to need to
tell cuirass to rebuild those packages.

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

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

Re: Release v1.4?

[Josselin Poiret]

Hello everyone,

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

> Thanks for the heads-up!  I think merging ‘staging’ should be
> top-priority.  People are welcome to upgrade/reconfigure from it with:

I'm currently running on staging with no bugs to report (x86_64-linux)!

Should we also make use of the point release to remove some deprecated
things/switch some defaults?  I'm thinking of:
* removing the swap-devices deprecation warning and compatibility code;
* removing the bootloader-configuration-target warning and compatibility
code;
* switching gdm-configuration-wayland? to #t, so that the OOB experience
with Wayland sessions is better.

All of those have roughly been in Guix for ~6 months, so it would seem
fair to me to move on.  There may be many other deprecations that we
could remove, but those are the ones I'm aware of, feel free to add your
own :)

I have patches for the 3 above, if we agree to move on with this (with a
NEWS entry for the third).

WDYT?
-- 
Josselin Poiret

Re: Merging ‘staging’?

[pelzflorian (Florian Pelz)]

On Thu, Jun 09, 2022 at 09:02:14PM +0200, pelzflorian (Florian Pelz) wrote:
> I will try again with staging at 091eb323ba27.  But it will take a
> long time; feel free to proceed regardless.

All my manifest built and runs on rock64 aarch64.  Thank you all!

Regards,
Florian

Re: Merging ‘staging’?

[Ludovic Courtès]

Hi,

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

> My main concern is that so few of the missing items are queued to be
> built.

I wonder if that info is accurate.

For instance, https://ci.guix.gnu.org/build/716980/details shows the
derivation for /gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3.
It is queued, just not being processed (yet).

> I've restarted some of them manually, but we're going to need to tell
> cuirass to rebuild those packages.

It went from 17.1% to 17.3% in two days, even though the AArch64
machines have been busy all along it seems.  Maybe they’ve been
processing the backlog that had accumulated on ‘master’ rather than the
things we care about.

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env  guix weather -s aarch64-linux -c200
computing 18,932 package derivations for aarch64-linux...
looking for 19,704 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  17.3% substitutes available (3,410 out of 19,704)
  at least 22,359.4 MiB of nars (compressed)
  24,158.2 MiB on disk (uncompressed)
  0.008 seconds per request (127.0 seconds in total)
  128.7 requests per second

  0.0% (0 out of 16,294) of the missing items are queued
  at least 1,000 queued builds
      powerpc64le-linux: 987 (98.7%)
      aarch64-linux: 12 (1.2%)
      x86_64-linux: 1 (.1%)
  build rate: 40.03 builds per hour
      x86_64-linux: 16.83 builds per hour
      aarch64-linux: 11.23 builds per hour
      i686-linux: 9.03 builds per hour
      powerpc64le-linux: 3.04 builds per hour
1496 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', among which:
  14236	libxft@2.3.3	/gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3 
  12379	nghttp2@1.44.0	/gnu/store/4cs553aj8x1xbavfzfdh4gn5idf5ij81-nghttp2-1.44.0-lib /gnu/store/4phvjrp12n8bfpncyp89414q2pa4d46q-nghttp2-1.44.0 
  10066	icu4c@69.1	/gnu/store/n9nx5rmnhdf3hdswhvns31diayq9vfq2-icu4c-69.1 
  7723	jbig2dec@0.19	/gnu/store/lrpczm2m0agx0x5rp6kmn8c46mc85l35-jbig2dec-0.19 
  6989	ninja@1.10.2	/gnu/store/jdq3xrcj0am4j698xr81hwgj8skcn7xq-ninja-1.10.2 
  6927	python-libxml2@2.9.12	/gnu/store/swgvpb6pb6nf84a08m8flmy7fjhxwvni-python-libxml2-2.9.12 
  6924	mallard-ducktype@1.0.2	/gnu/store/662lari1slhz56q8333sdczq1av9f799-mallard-ducktype-1.0.2 
  6552	libxt@1.2.1	/gnu/store/rqqkla9kqjq3182gdqynkq2jb4jf2bl5-libxt-1.2.1-doc /gnu/store/82pzzkny0gwdfkfa5zvnyy4vbzxqnwyy-libxt-1.2.1 
  6503	python-fonttools@4.28.5	/gnu/store/vp3g1ddrv067gay8zk1xd7c0kcgq1cv5-python-fonttools-4.28.5 
  5120	python-wheel@0.37.0	/gnu/store/0rmkfrmrjsvf2hvl9px7h3g91zypmycz-python-wheel-0.37.0 
  5113	python-flit-core-bootstrap@3.5.1	/gnu/store/pcwmq56r3wb8wdv8blj8ajfsmvcj6wm1-python-flit-core-bootstrap-3.5.1 
  4555	openblas@0.3.20	/gnu/store/wc8cbkcvgqkdf65fj7drb82plkf8igyw-openblas-0.3.20 
  4231	libxfixes@6.0.0	/gnu/store/h70i9gyvif5kzpw7a8bdaxhw7sqiv7wz-libxfixes-6.0.0 
  4041	python-markupsafe@2.0.1	/gnu/store/1k63s700a1sy3pvcms0kax7csqsjzxdr-python-markupsafe-2.0.1 
  3788	libxrandr@1.5.2	/gnu/store/9gqkb75sr60lxic9a3nx543a6wxz0866-libxrandr-1.5.2 
  3563	eudev@3.2.11	/gnu/store/nvdlxv30l6f06nclls7j6zi4s8cm1jnc-eudev-3.2.11 /gnu/store/5ja9bj947iir15ypmqzrwxk04w6vhiyz-eudev-3.2.11-static 
  3360	libpsl@0.21.1	/gnu/store/5jyxcfsgk0hsj6rzfsz84wnap6bn57ka-libpsl-0.21.1 
  3329	libevent@2.1.12	/gnu/store/28iivyxgqvnp2alx2fyqqx18md7pwja8-libevent-2.1.12-bin /gnu/store/cvvsdqkcb8z78bh7rhzirv2n4sb4svgg-libevent-2.1.12 
  3320	libxkbfile@1.1.0	/gnu/store/kk0xk8j8ffgxvfs5kz1vxp2ipz28xwh4-libxkbfile-1.1.0 
  3297	xcb-util@0.4.0	/gnu/store/n2x5kvy5zxbnh28ak7rbvw6brp97z1c9-xcb-util-0.4.0 
  3279	xcb-util-wm@0.4.1	/gnu/store/hhasmz0l5f10f9nfg0nx378c7bcgf9v0-xcb-util-wm-0.4.1 
  3263	libxres@1.2.1	/gnu/store/5mpjhsyq2bbri006g7lh6h82239s8fb8-libxres-1.2.1 
  3215	python-flit-core@3.5.1	/gnu/store/zldar3i40q3l40fypm8n6fh3kpddxhzq-python-flit-core-3.5.1 
  3213	python-pytz@2022.1	/gnu/store/byyn7jzs85r2n11hdbk98dk2ikb74z9n-python-pytz-2022.1 
  3205	python-pycparser@2.21	/gnu/store/4a5l67ama5msmd2qi8w7mvlq64b04znb-python-pycparser-2.21-doc /gnu/store/98g8chr9pcxyz0czp9fq2w3q8rm2sn14-python-pycparser-2.21 
  3201	python-idna@3.3	/gnu/store/fj5sc68s4g0rh5gycnzvx2nkmviphfyb-python-idna-3.3 
  3170	python-pretend@1.0.9	/gnu/store/ksyw3ffmmhizh25ql0jp7yfv5llg55km-python-pretend-1.0.9 
  3132	python-semantic-version@2.8.5	/gnu/store/0g95jbn19fwr52f5l5j1ibv7h9g7dsyl-python-semantic-version-2.8.5 
  3127	python-asn1crypto@1.4.0	/gnu/store/12xs95mcz9v9swwyinsagfdn0qa74rgw-python-asn1crypto-1.4.0 
  3126	python-cryptography-vectors@3.4.8	/gnu/store/5ww2a12dzyq8fbazwkqhn26wv5ahk1xj-python-cryptography-vectors-3.4.8 
  2754	python-pyyaml@6.0	/gnu/store/pxxnkbrljhizypjpfdl27djjzsyflnic-python-pyyaml-6.0 
  2542	python-dnspython@2.1.0	/gnu/store/m66znr3nwqb7w132yiw9iznzqif2z84r-python-dnspython-2.1.0 
  2539	python-pyasn1@0.4.8	/gnu/store/y8xmfzmigvkhx5qz30r1hviyrbl351gf-python-pyasn1-0.4.8 
  2499	talloc@2.3.3	/gnu/store/3a4kjg0gza37nww955wmn2fvr47vhcg2-talloc-2.3.3 
  2485	tdb@1.4.5	/gnu/store/mih377grfg6a0p29d9g073h2asgz2qhb-tdb-1.4.5 
  2474	sane-backends-minimal@1.0.32	/gnu/store/irsdxn937lk7kwzbzynv5jfsg23dg00w-sane-backends-minimal-1.0.32 
  2466	iso-codes@4.5.0	/gnu/store/wh8wjbcl3ra9rgqm8k03bvv44592d21q-iso-codes-4.5.0 
  2404	python-pygments@2.12.0	/gnu/store/daikb3nxqvqf26xaz0g07r9mpk3qppf9-python-pygments-2.12.0 
  2387	python-execnet@1.9.0	/gnu/store/d8bch78szsdzhwcf1xv2s33czqjngylp-python-execnet-1.9.0 
  2381	python-pytest-forked@1.3.0	/gnu/store/2sd0qgv2ahmfhrjqkffc95ha2vkg0v7l-python-pytest-forked-1.3.0 
  2356	python-docutils@0.17.1	/gnu/store/6lmz781dvgv32vri4yz3zabb7xb2ba9c-python-docutils-0.17.1 
  2145	python-pbr-minimal@5.5.1	/gnu/store/ylicyzxc1xi7jld73lnfay4vkkkzj3v2-python-pbr-minimal-5.5.1 
  2045	python-parameterized@0.7.4	/gnu/store/4avvz5qb327l5nv6vs8s9fvi3w0hnpg3-python-parameterized-0.7.4 
  2044	python-pyserial@3.5	/gnu/store/42s9wkvmb1mxwk2bcshhhhinkqa1fk62-python-pyserial-3.5 
  2036	python-scour@0.38.2	/gnu/store/vdbf89hbs3md00iaiz181d2lnxv6n0ph-python-scour-0.38.2 

[…]
--8<---------------cut here---------------end--------------->8---

Anyway, I think we must address that, but I also think we can’t afford
to delay the merge any longer or the updates will be stale.

Thus I propose to merge today, for real this time.

Objections?

Thanks,
Ludo’.

Re: Merging ‘staging’?

[Tom Fitzhenry]

Ludovic Courtès <ludo@gnu.org> writes:
> It went from 17.1% to 17.3% in two days, even though the AArch64
> machines have been busy all along it seems.  Maybe they’ve been
> processing the backlog that had accumulated on ‘master’ rather than the
> things we care about.

Per https://issues.guix.gnu.org/55848, it looks like
grunewald/kreuzberg/pankow are busy processing jobs, but each time
failing after 15 minutes with the same network-level error.

> Objections?

SGTM!

Re: Merging ‘staging’?

[Efraim Flashner]

On June 11, 2022 9:53:14 AM UTC, "Ludovic Courtès" <ludo@gnu.org> wrote:
>Hi,
>
>Efraim Flashner <efraim@flashner.co.il> skribis:
>
>> My main concern is that so few of the missing items are queued to be
>> built.
>
>I wonder if that info is accurate.
>
>For instance, https://ci.guix.gnu.org/build/716980/details shows the
>derivation for /gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3.
>It is queued, just not being processed (yet).
>
>> I've restarted some of them manually, but we're going to need to tell
>> cuirass to rebuild those packages.
>
>It went from 17.1% to 17.3% in two days, even though the AArch64
>machines have been busy all along it seems.  Maybe they’ve been
>processing the backlog that had accumulated on ‘master’ rather than the
>things we care about.
>
>--8<---------------cut here---------------start------------->8---
>$ ./pre-inst-env  guix weather -s aarch64-linux -c200
>computing 18,932 package derivations for aarch64-linux...
>looking for 19,704 store items on https://ci.guix.gnu.org...
>https://ci.guix.gnu.org
>  17.3% substitutes available (3,410 out of 19,704)
>  at least 22,359.4 MiB of nars (compressed)
>  24,158.2 MiB on disk (uncompressed)
>  0.008 seconds per request (127.0 seconds in total)
>  128.7 requests per second
>
>  0.0% (0 out of 16,294) of the missing items are queued
>  at least 1,000 queued builds
>      powerpc64le-linux: 987 (98.7%)
>      aarch64-linux: 12 (1.2%)
>      x86_64-linux: 1 (.1%)
>  build rate: 40.03 builds per hour
>      x86_64-linux: 16.83 builds per hour
>      aarch64-linux: 11.23 builds per hour
>      i686-linux: 9.03 builds per hour
>      powerpc64le-linux: 3.04 builds per hour
>1496 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', among which:
>  14236	libxft@2.3.3	/gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3 
>  12379	nghttp2@1.44.0	/gnu/store/4cs553aj8x1xbavfzfdh4gn5idf5ij81-nghttp2-1.44.0-lib /gnu/store/4phvjrp12n8bfpncyp89414q2pa4d46q-nghttp2-1.44.0 
>  10066	icu4c@69.1	/gnu/store/n9nx5rmnhdf3hdswhvns31diayq9vfq2-icu4c-69.1 
>  7723	jbig2dec@0.19	/gnu/store/lrpczm2m0agx0x5rp6kmn8c46mc85l35-jbig2dec-0.19 
>  6989	ninja@1.10.2	/gnu/store/jdq3xrcj0am4j698xr81hwgj8skcn7xq-ninja-1.10.2 
>  6927	python-libxml2@2.9.12	/gnu/store/swgvpb6pb6nf84a08m8flmy7fjhxwvni-python-libxml2-2.9.12 
>  6924	mallard-ducktype@1.0.2	/gnu/store/662lari1slhz56q8333sdczq1av9f799-mallard-ducktype-1.0.2 
>  6552	libxt@1.2.1	/gnu/store/rqqkla9kqjq3182gdqynkq2jb4jf2bl5-libxt-1.2.1-doc /gnu/store/82pzzkny0gwdfkfa5zvnyy4vbzxqnwyy-libxt-1.2.1 
>  6503	python-fonttools@4.28.5	/gnu/store/vp3g1ddrv067gay8zk1xd7c0kcgq1cv5-python-fonttools-4.28.5 
>  5120	python-wheel@0.37.0	/gnu/store/0rmkfrmrjsvf2hvl9px7h3g91zypmycz-python-wheel-0.37.0 
>  5113	python-flit-core-bootstrap@3.5.1	/gnu/store/pcwmq56r3wb8wdv8blj8ajfsmvcj6wm1-python-flit-core-bootstrap-3.5.1 
>  4555	openblas@0.3.20	/gnu/store/wc8cbkcvgqkdf65fj7drb82plkf8igyw-openblas-0.3.20 
>  4231	libxfixes@6.0.0	/gnu/store/h70i9gyvif5kzpw7a8bdaxhw7sqiv7wz-libxfixes-6.0.0 
>  4041	python-markupsafe@2.0.1	/gnu/store/1k63s700a1sy3pvcms0kax7csqsjzxdr-python-markupsafe-2.0.1 
>  3788	libxrandr@1.5.2	/gnu/store/9gqkb75sr60lxic9a3nx543a6wxz0866-libxrandr-1.5.2 
>  3563	eudev@3.2.11	/gnu/store/nvdlxv30l6f06nclls7j6zi4s8cm1jnc-eudev-3.2.11 /gnu/store/5ja9bj947iir15ypmqzrwxk04w6vhiyz-eudev-3.2.11-static 
>  3360	libpsl@0.21.1	/gnu/store/5jyxcfsgk0hsj6rzfsz84wnap6bn57ka-libpsl-0.21.1 
>  3329	libevent@2.1.12	/gnu/store/28iivyxgqvnp2alx2fyqqx18md7pwja8-libevent-2.1.12-bin /gnu/store/cvvsdqkcb8z78bh7rhzirv2n4sb4svgg-libevent-2.1.12 
>  3320	libxkbfile@1.1.0	/gnu/store/kk0xk8j8ffgxvfs5kz1vxp2ipz28xwh4-libxkbfile-1.1.0 
>  3297	xcb-util@0.4.0	/gnu/store/n2x5kvy5zxbnh28ak7rbvw6brp97z1c9-xcb-util-0.4.0 
>  3279	xcb-util-wm@0.4.1	/gnu/store/hhasmz0l5f10f9nfg0nx378c7bcgf9v0-xcb-util-wm-0.4.1 
>  3263	libxres@1.2.1	/gnu/store/5mpjhsyq2bbri006g7lh6h82239s8fb8-libxres-1.2.1 
>  3215	python-flit-core@3.5.1	/gnu/store/zldar3i40q3l40fypm8n6fh3kpddxhzq-python-flit-core-3.5.1 
>  3213	python-pytz@2022.1	/gnu/store/byyn7jzs85r2n11hdbk98dk2ikb74z9n-python-pytz-2022.1 
>  3205	python-pycparser@2.21	/gnu/store/4a5l67ama5msmd2qi8w7mvlq64b04znb-python-pycparser-2.21-doc /gnu/store/98g8chr9pcxyz0czp9fq2w3q8rm2sn14-python-pycparser-2.21 
>  3201	python-idna@3.3	/gnu/store/fj5sc68s4g0rh5gycnzvx2nkmviphfyb-python-idna-3.3 
>  3170	python-pretend@1.0.9	/gnu/store/ksyw3ffmmhizh25ql0jp7yfv5llg55km-python-pretend-1.0.9 
>  3132	python-semantic-version@2.8.5	/gnu/store/0g95jbn19fwr52f5l5j1ibv7h9g7dsyl-python-semantic-version-2.8.5 
>  3127	python-asn1crypto@1.4.0	/gnu/store/12xs95mcz9v9swwyinsagfdn0qa74rgw-python-asn1crypto-1.4.0 
>  3126	python-cryptography-vectors@3.4.8	/gnu/store/5ww2a12dzyq8fbazwkqhn26wv5ahk1xj-python-cryptography-vectors-3.4.8 
>  2754	python-pyyaml@6.0	/gnu/store/pxxnkbrljhizypjpfdl27djjzsyflnic-python-pyyaml-6.0 
>  2542	python-dnspython@2.1.0	/gnu/store/m66znr3nwqb7w132yiw9iznzqif2z84r-python-dnspython-2.1.0 
>  2539	python-pyasn1@0.4.8	/gnu/store/y8xmfzmigvkhx5qz30r1hviyrbl351gf-python-pyasn1-0.4.8 
>  2499	talloc@2.3.3	/gnu/store/3a4kjg0gza37nww955wmn2fvr47vhcg2-talloc-2.3.3 
>  2485	tdb@1.4.5	/gnu/store/mih377grfg6a0p29d9g073h2asgz2qhb-tdb-1.4.5 
>  2474	sane-backends-minimal@1.0.32	/gnu/store/irsdxn937lk7kwzbzynv5jfsg23dg00w-sane-backends-minimal-1.0.32 
>  2466	iso-codes@4.5.0	/gnu/store/wh8wjbcl3ra9rgqm8k03bvv44592d21q-iso-codes-4.5.0 
>  2404	python-pygments@2.12.0	/gnu/store/daikb3nxqvqf26xaz0g07r9mpk3qppf9-python-pygments-2.12.0 
>  2387	python-execnet@1.9.0	/gnu/store/d8bch78szsdzhwcf1xv2s33czqjngylp-python-execnet-1.9.0 
>  2381	python-pytest-forked@1.3.0	/gnu/store/2sd0qgv2ahmfhrjqkffc95ha2vkg0v7l-python-pytest-forked-1.3.0 
>  2356	python-docutils@0.17.1	/gnu/store/6lmz781dvgv32vri4yz3zabb7xb2ba9c-python-docutils-0.17.1 
>  2145	python-pbr-minimal@5.5.1	/gnu/store/ylicyzxc1xi7jld73lnfay4vkkkzj3v2-python-pbr-minimal-5.5.1 
>  2045	python-parameterized@0.7.4	/gnu/store/4avvz5qb327l5nv6vs8s9fvi3w0hnpg3-python-parameterized-0.7.4 
>  2044	python-pyserial@3.5	/gnu/store/42s9wkvmb1mxwk2bcshhhhinkqa1fk62-python-pyserial-3.5 
>  2036	python-scour@0.38.2	/gnu/store/vdbf89hbs3md00iaiz181d2lnxv6n0ph-python-scour-0.38.2 
>
>[…]
>--8<---------------cut here---------------end--------------->8---
>
>Anyway, I think we must address that, but I also think we can’t afford
>to delay the merge any longer or the updates will be stale.
>
>Thus I propose to merge today, for real this time.
>
>Objections?
>
>Thanks,
>Ludo’.

Let's do it

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

Re: Merging ‘staging’?

[Thiago Jung Bauermann]

Hello,

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

> ‘guix weather -s i686-linux’ says 89% (which is underestimated, because
> it wrongfully checks for all the packages, including unsupported
> packages), which sounds good.
>
> We have to check for AArch64 & co.  Any takers?

Sorry for the delay. I've built some packages from the staging branch on
powerpc64le-linux (including Emacs, which brings in a lot of stuff) and
it seems good.

-- 
Thanks
Thiago

Re: Merging ‘staging’?

[Ludovic Courtès]

Hi,

Thiago Jung Bauermann <bauermann@kolabnow.com> skribis:

> Sorry for the delay. I've built some packages from the staging branch on
> powerpc64le-linux (including Emacs, which brings in a lot of stuff) and
> it seems good.

That’s good news, thanks for testing!

Ludo’.

Re: Merging ‘staging’?

[Ludovic Courtès]

Hi,

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

> Let's do it

Soooo… turns out commit e31ab8c24848a7691a838af8df61d3e7097cddbc on
‘master’ unwillingly triggered a rebuild of 2K packages.

It’s too late to revert (they’ve been built anyway), but I’ve merged
‘master’ in ‘staging’ so they can be built there.

Which means I’ll merge ‘staging’ in ‘master’ tomorrow morning if nothing
has collapsed by then.  :-)

Ludo’.

Re: Merging ‘staging’?

[Ludovic Courtès]

Hello Guix,

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

> Which means I’ll merge ‘staging’ in ‘master’ tomorrow morning if nothing
> has collapsed by then.  :-)

Merged, enjoy!  :-)

Thanks to everyone who helped on the way!

Next up: release and ‘core-updates’.

Ludo’.

Re: Merging ‘staging’?

[Thiago Jung Bauermann]

Hello,

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

> Hello Guix,
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Which means I’ll merge ‘staging’ in ‘master’ tomorrow morning if nothing
>> has collapsed by then.  :-)
>
> Merged, enjoy!  :-)

Nice!

> Thanks to everyone who helped on the way!

Thank you for merging the branch!

> Next up: release and ‘core-updates’.

Exciting times. :-)

-- 
Thanks
Thiago

Release ? (was: Merging ‘staging’?)

[zimoun]

Hi,

On Mon, 13 Jun 2022 at 09:03, Ludovic Courtès <ludo@gnu.org> wrote:

> Merged, enjoy!  :-)

Cool!


> Next up: release and ‘core-updates’.

Do you want to do a ’core-updates’ merge before the release?  I think a
release on July would be very welcome.  WDYT?


Cheers,
simon

Re: Release ? (was: Merging ‘staging’?)

[Efraim Flashner]

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

On Tue, Jun 14, 2022 at 12:32:13PM +0200, zimoun wrote:
> Hi,
> 
> On Mon, 13 Jun 2022 at 09:03, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> > Merged, enjoy!  :-)
> 
> Cool!
> 
> 
> > Next up: release and ‘core-updates’.
> 
> Do you want to do a ’core-updates’ merge before the release?  I think a
> release on July would be very welcome.  WDYT?

I think we do release and then core-updates, before we get bogged down
in fixing packages in core-updates.

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

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

Re: Release v1.4?

[Ludovic Courtès]

Hello!

Josselin Poiret <dev@jpoiret.xyz> skribis:

> Should we also make use of the point release to remove some deprecated
> things/switch some defaults?  I'm thinking of:
> * removing the swap-devices deprecation warning and compatibility code;
> * removing the bootloader-configuration-target warning and compatibility
> code;

I don’t think we can do that because there hasn’t been any new release
in the meantime, unfortunately.  Better wait for a few months after 1.4.

> * switching gdm-configuration-wayland? to #t, so that the OOB experience
> with Wayland sessions is better.

Perhaps I’m biased because I use Xorg, but I wonder how good a default
that is?  To put it differently, what fraction of the user base uses
Wayland?

Thanks,
Ludo’.

Re: Release ?

[Ludovic Courtès]

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

> I think we do release and then core-updates, before we get bogged down
> in fixing packages in core-updates.

Agreed!

Ludo’.

Re: Release v1.4?

[Gábor Boskovits]

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

Hello,

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2022. jún. 15., Sze
11:12):

> Hello!
>
> Josselin Poiret <dev@jpoiret.xyz> skribis:
>
> > Should we also make use of the point release to remove some deprecated
> > things/switch some defaults?  I'm thinking of:
> > * removing the swap-devices deprecation warning and compatibility code;
> > * removing the bootloader-configuration-target warning and compatibility
> > code;
>
> I don’t think we can do that because there hasn’t been any new release
> in the meantime, unfortunately.  Better wait for a few months after 1.4.
>
> > * switching gdm-configuration-wayland? to #t, so that the OOB experience
> > with Wayland sessions is better.
>
> Perhaps I’m biased because I use Xorg, but I wonder how good a default
> that is?  To put it differently, what fraction of the user base uses
> Wayland?
>

Do you think we can use download statistics to estimate this?
>

Regards,
g_bor

>
> Thanks,
> Ludo’.
>
>

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

Re: Release v1.4?

[Josselin Poiret]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:
>> * switching gdm-configuration-wayland? to #t, so that the OOB experience
>> with Wayland sessions is better.
>
> Perhaps I’m biased because I use Xorg, but I wonder how good a default
> that is?  To put it differently, what fraction of the user base uses
> Wayland?

I'm not sure, it does seem like a fraction of people use it on IRC but
then again it's more likely that Wayland users would talk about it, X
being the default.  If there are no outstanding bugs with Wayland Gnome
though, I think it'd be a better choice: no tearing in the default
configuration, and better designed.  GUI Toolkits seem to have adapted
pretty well, and we still have XWayland for the rest.  The most glaring
non-Wayland app would be Emacs, but emacs-next-pgtk is fully
Wayland-native.

For me the #1 reason though is onboarding experience: take a user of
another distro that uses their favorite Wayland compositor, and wants to
try out Guix.  They install it through the Guix installer, and don't
understand (yet) how to read the whole documentation and write their own
config file fully.  They add sway to their system packages, reconfigure,
but next reboot GDM doesn't show Sway in the available sessions; they then
decide it's not worth their time and go back to their old distro.  This
default change would make sure that it Just Works Out of The Box™ on
first install.

For the other deprecation changes, I agree, let's just wait a bit longer.

Best,
-- 
Josselin Poiret

Re: Release v1.4?

[Ludovic Courtès]

Hi,

Josselin Poiret <dev@jpoiret.xyz> skribis:

> I'm not sure, it does seem like a fraction of people use it on IRC but
> then again it's more likely that Wayland users would talk about it, X
> being the default.  If there are no outstanding bugs with Wayland Gnome
> though, I think it'd be a better choice: no tearing in the default
> configuration, and better designed.  GUI Toolkits seem to have adapted
> pretty well, and we still have XWayland for the rest.  The most glaring
> non-Wayland app would be Emacs, but emacs-next-pgtk is fully
> Wayland-native.

So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like a
recipe for a poor user experience, no?

(FWIW folks like me who use exwm, ratpoison, or one of these geeky
tiling window managers probably can’t switch.)

> For me the #1 reason though is onboarding experience: take a user of
> another distro that uses their favorite Wayland compositor, and wants to
> try out Guix.  They install it through the Guix installer, and don't
> understand (yet) how to read the whole documentation and write their own
> config file fully.  They add sway to their system packages, reconfigure,
> but next reboot GDM doesn't show Sway in the available sessions; they then
> decide it's not worth their time and go back to their old distro.  This
> default change would make sure that it Just Works Out of The Box™ on
> first install.

Yeah, understood.  (I think we should have a section in the manual
documenting, with actual examples, how to set up Wayland!)

Surely there’s a geek audience who expects Wayland, and another geek
audience who needs X for their tools; in between, there’s probably a lot
of people who’s fine either way.

I have no objection to defaulting to Wayland, but my gut feeling is that
we have enough on our plate for 1.4 already, so I’d rather delay that
post-release.

WDYT?

Ludo’.

Re: Release v1.4?

[Brian Cully via Development of GNU Guix and the GNU System distribution.]

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

> So plain ‘emacs’ package doesn’t work on Wayland?  That sounds 
> like a
> recipe for a poor user experience, no?

The mainline Emacs is not Wayland-native, but it (along with just 
about everything else) will run fine under XWayland. It's how I've 
been running it for some time now. The user experience is almost 
indistinguishable from either the ‘pgtk’ branch or the mainline, 
X-only branch.

> (FWIW folks like me who use exwm, ratpoison, or one of these 
> geeky
> tiling window managers probably can’t switch.)

This is correct, but I don't see why this should prevent Guix 
offering the option for Wayland-based compositors/window-managers 
out of the box as all it does is offer more options for users.

> I have no objection to defaulting to Wayland, but my gut feeling 
> is that
> we have enough on our plate for 1.4 already, so I’d rather delay 
> that
> post-release.

Unless I'm misunderstanding something, I don't believe that 
setting the ‘wayland’ flag to #t in gdm-configuration causes 
Wayland to be used for your desktop environment, it merely 
*allows* it to be selected from the greeter. When logging in you 
can select from Gnome under X, Gnome under Wayland, or other 
window managers you may have installed under either 
environment. Without that flag only the X11 window managers will 
be selectable.

-bjc

Re: Release v1.4?

[Josselin Poiret]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:
> So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like a
> recipe for a poor user experience, no?

It does, but only through XWayland which is not ideal, and doesn't look
as good as Emacs on native X or emacs-pgtk on Wayland (font rendering in
XWayland isn't as good as either of those).

> (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> tiling window managers probably can’t switch.)

Maybe someone would love to write ewwm? :p

> Yeah, understood.  (I think we should have a section in the manual
> documenting, with actual examples, how to set up Wayland!)
>
> Surely there’s a geek audience who expects Wayland, and another geek
> audience who needs X for their tools; in between, there’s probably a lot
> of people who’s fine either way.

What I was advocating was only to change GDM's default mode to Wayland,
not force everyone to use a Wayland compositor!  The reason is that GDM
running in X mode will not pick up Wayland sessions, whereas GDM running
in Wayland mode will happily list and launch both types.  Also, note
that X software can run on Wayland through XWayland, which is part of
the official xorg project and works quite well, minus some small
wrinkles such as the one noted above.

> I have no objection to defaulting to Wayland, but my gut feeling is that
> we have enough on our plate for 1.4 already, so I’d rather delay that
> post-release.
>
> WDYT?

Seems ok to me, since in any case most people trying out Guix in a VM
will `guix pull` before `guix reconfigure`'ing, as long as we do that at
some point it will work OOTB for them.  We can postpone all of this for
after the release.

Best,
-- 
Josselin Poiret

Further thoughts on Xorg "vs" Wayland etc -- was: Re: Release v1.4?

[bokr]

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

Hi brian, et al,

On +2022-06-17 11:37:18 -0400, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote:
> 
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> > So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like a
> > recipe for a poor user experience, no?
> 
> The mainline Emacs is not Wayland-native, but it (along with just about
> everything else) will run fine under XWayland. It's how I've been running it
> for some time now. The user experience is almost indistinguishable from
> either the ‘pgtk’ branch or the mainline, X-only branch.
>

Yes, and NB:  Xwayland does not shut out native wayland.

It may even share more nicely than that, depending on system.
On my old Puri.sm Librem13v4 PureOS/amber-variant-of-debian system...
-----------cut here---------------start------------->8---
# $ uname -rv
4.19.0-19-amd64 #1 SMP Debian 4.19.232-1 (2022-03-07)
-----------cut here---------------end--------------->8---
...I can switch back and forth between Xwayland that does
all the stuff that needs X or Xorg (gnome and browsers, and Audacity
and all that) and my hacky experiments with bypassing X and
talking to the compositor in C.

The compositor happily places my pixel buffers on the screen together with
firefox or texworks or whatever else is running, so there is not necessarily
a Wayland "vs" Xorg conflict. YMMV I would guess, but works for me :)

This seems to me like it demonstrates an opportunity to encourage developers
to get their feet wet with X-server-indepedent apps. (That doesn't mean
giving up all the graphics and font software that paints pixels into buffers --
it "just" factors out the buffer compositing)

My system also permits switching to a framebuffer ( /dev/fb0 ) tty3 based
environemt, while leaving the gnome gui stuff running.
Ctl-Alt-F3 gets me a console login prompt. Ctl-Alt-F2 switches me back,
whether I logged out of the console shell or not.

If you are a member of the video group, you can read and write the
frame buffer as a 1920x1080x4 byte mmap whose address you can get
with an ioctl. Other geometries are of course possble. 

I wrote some C to poke character cells from the kernel sun12x22 font.
Long time ago. I have been meaning to port my pixelpoking to wayland,
and have wip stuff, which I will share at some point :)

The reason I was in frame buffer mode today was the gnome side got
total locked, so I thought I could Ctl-Alt-F3 and kill off stuck bits.
Which I did -- killed the whole GUI side, in the end. An alernative
to rescue/maintenace mode, before going there, IOW.

But since I was there in console fb mode, I wanted to check that
my old font demo worked. It did :)

BUT: Fn Prt Sc had no hook like in gnome, so I wanted to save the
display. Guess what you can do?

To make a screenshot:
    xz -kzc /dev/fb0 > some_xzss_name.xz
To display such a screen-shot:
    xz -dc some_xzss_name.xz > /dev/fb0

This works fast, and the compression is better than the .png files from
gnome's screenshots. Of course this doess not coordinate with anything else
that may be painting the screen, so it will get mixed with updates in sometimes
curious ways, since the compositor avoids update screen areas it thinks haven't
changed. If you poke pixels there, they'll stay until the compositor gets someting
new for that area,

I'll try to attach one I made. It shows all the kernel sun12x22.c characters
with bounding boxes in red and hex index numbers at the array edges.

Maybe this dual fb0 and Xwayland capabilty could help someone?
You get it all "for free" with some systems, and it doesn't demand anything.

There is tricky stuff going on though. So no warranties
from me on any of this info :)


> > (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> > tiling window managers probably can’t switch.)
>

I don't know how much work, but I would guess they can be made
to work alongside wayland, if not using wayland to best advanage.

Best would be to wean emacs of X, IWT.

Otherwise they can probably play nicely on the same back end,
not sharing screen space maybe, but flipping between with some key hit.

A quick check on if you have drm-driven displays:

-----------cut here---------------start------------->8---
# $ head /sys/class/drm/*/status
==> /sys/class/drm/card0-DP-1/status <==
disconnected

==> /sys/class/drm/card0-eDP-1/status <==
connected

==> /sys/class/drm/card0-HDMI-A-1/status <==
disconnected
-----------cut here---------------end--------------->8---

BTW, if you want to hack native wayland, I recommend [0]
to start with. The examples mostly worked for me.

but so much is developing so fast that things
like using anonymous files and mmap-ing them to pass
to wayland as private buffers may show up only
while your're looking for something else on stackoverflow
or wikipedia or reddit or ... you may miss it.

[0] https://wayland-book.com/introduction.html

Sorry to interpose so much, the context for "this" (I think) was:

--8<---------------cut here---------------start------------->8---
> > (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> > tiling window managers probably can’t switch.)
--8<---------------cut here---------------end--------------->8---

Well, I think some may be able to switch, or coexist. But I've been wrong before :)

> This is correct, but I don't see why this should prevent Guix offering the
> option for Wayland-based compositors/window-managers out of the box as all
> it does is offer more options for users.
> 
> > I have no objection to defaulting to Wayland, but my gut feeling is that
> > we have enough on our plate for 1.4 already, so I’d rather delay that
> > post-release.
> 
> Unless I'm misunderstanding something, I don't believe that setting the
> ‘wayland’ flag to #t in gdm-configuration causes Wayland to be used for your
> desktop environment, it merely *allows* it to be selected from the greeter.
> When logging in you can select from Gnome under X, Gnome under Wayland, or
> other window managers you may have installed under either environment.
> Without that flag only the X11 window managers will be selectable.
>

I think you must be right, Brian, or we should
"Make it So," as the Captain said.

> -bjc
>
--
Regards,
Bengt Richter

[-- Attachment #2: xzss20220618_210042.xz --]
[-- Type: application/x-xz, Size: 15020 bytes --]

Re: Release v1.4?

[Philip McGrath]

On Fri, Jun 17, 2022, at 11:37 AM, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> So plain ‘emacs’ package doesn’t work on Wayland?  That sounds 
>> like a
>> recipe for a poor user experience, no?
>
> The mainline Emacs is not Wayland-native, but it (along with just 
> about everything else) will run fine under XWayland. It's how I've 
> been running it for some time now. The user experience is almost 
> indistinguishable from either the ‘pgtk’ branch or the mainline, 
> X-only branch.
>

I'm on a foreign distro, but FWIW I've been using plain Emacs 27 with the KDE Plasma Wayland session on HiDPI displays for over a year, and I have no complaints. In fact, I didn't even realize Emacs wasn't Wayland-native until this thread. I took a look just now at the 'emacs-next-pgtk' package in Guix: it does look a bit nicer in a side-by-side comparison, but it's subtle. Either way, mostly Emacs just looks like Emacs. So I don't think Emacs should be a blocker for enabling Wayland by default.

-Philip

Re: Release v1.4?

[Ludovic Courtès]

Hi,

Brian Cully <bjc@spork.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like
>> a
>> recipe for a poor user experience, no?
>
> The mainline Emacs is not Wayland-native, but it (along with just
> about everything else) will run fine under XWayland. It's how I've
> been running it for some time now. The user experience is almost
> indistinguishable from either the ‘pgtk’ branch or the mainline,
> X-only branch.
>
>> (FWIW folks like me who use exwm, ratpoison, or one of these geeky
>> tiling window managers probably can’t switch.)
>
> This is correct, but I don't see why this should prevent Guix offering
> the option for Wayland-based compositors/window-managers out of the
> box as all it does is offer more options for users.

Sure.

> Unless I'm misunderstanding something, I don't believe that setting
> the ‘wayland’ flag to #t in gdm-configuration causes Wayland to be
> used for your desktop environment, it merely *allows* it to be
> selected from the greeter. When logging in you can select from Gnome
> under X, Gnome under Wayland, or other window managers you may have
> installed under either environment. Without that flag only the X11
> window managers will be selectable.

OK, I wasn’t aware of that; if setting ‘wayland?’ to #t is this smooth
and basically indistinguishable for those who want to stick with X, then
I guess we should enable it.

I’m still unsure whether doing is before the release is reasonable,
given how much we have on our plate.

Thanks,
Ludo’.

Re: Release v1.4?

[Efraim Flashner]

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

On Wed, Jun 22, 2022 at 03:31:34PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Brian Cully <bjc@spork.org> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >> So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like
> >> a
> >> recipe for a poor user experience, no?
> >
> > The mainline Emacs is not Wayland-native, but it (along with just
> > about everything else) will run fine under XWayland. It's how I've
> > been running it for some time now. The user experience is almost
> > indistinguishable from either the ‘pgtk’ branch or the mainline,
> > X-only branch.
> >
> >> (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> >> tiling window managers probably can’t switch.)
> >
> > This is correct, but I don't see why this should prevent Guix offering
> > the option for Wayland-based compositors/window-managers out of the
> > box as all it does is offer more options for users.
> 
> Sure.
> 
> > Unless I'm misunderstanding something, I don't believe that setting
> > the ‘wayland’ flag to #t in gdm-configuration causes Wayland to be
> > used for your desktop environment, it merely *allows* it to be
> > selected from the greeter. When logging in you can select from Gnome
> > under X, Gnome under Wayland, or other window managers you may have
> > installed under either environment. Without that flag only the X11
> > window managers will be selectable.
> 
> OK, I wasn’t aware of that; if setting ‘wayland?’ to #t is this smooth
> and basically indistinguishable for those who want to stick with X, then
> I guess we should enable it.
> 
> I’m still unsure whether doing is before the release is reasonable,
> given how much we have on our plate.
> 
> Thanks,
> Ludo’.

I think the only real question is what shows up first by default in a
fresh install. I believe by default SDDM will show the window manager
that was last used by default.

My current OS config, when I spin it up in a VM, lists
enlightenment/wayland before enlightenment/X11. I didn't test with
gnome.

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

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

Re: Rock64 segfaults (was: Merging ‘staging’?)

[Timotej Lazar]

Hi,

sorry to hijack the thread – I found your post when debugging random
segfaults on the rock64, and just wanted to post a possible solution for
anyone having the same problem.

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> [2022-06-09 19:19:30+0200]:
> (The build of llvm@11 also needed a few retries because gcc randomly
> fails sometimes (once with a segfault).  That is not a Guix bug
> though, I think, but peculiarities of the rock64.)

This seems to be a hardware issue that can be fixed by downclocking the
memory¹. Mainline u-boot has two variants of the rk3328-sdram-lpddr3
.dtsi file, so I just did

    (define u-boot-rock64-rk3328/666
      (package
        (inherit u-boot-rock64-rk3328)
        (arguments
         (substitute-keyword-arguments (package-arguments u-boot-rock64-rk3328)
           ((#:phases phases)
            `(modify-phases ,phases
               (add-after 'unpack 'change-ddr-clock
                 (lambda _
                   (substitute* "arch/arm/dts/rk3328-rock64-u-boot.dtsi"
                     (("rk3328-sdram-lpddr3-1600.dtsi") "rk3328-sdram-lpddr3-666.dtsi"))))))))))

and used that for the bootloader:

    (bootloader
      (bootloader-configuration
        (bootloader
          (bootloader
            (inherit u-boot-rock64-rk3328-bootloader)
            (package u-boot-rock64-rk3328/666)))
        …

With this I was able to compile both gcc and llvm several times; before,
compilation would reliably crash within an hour unless it was done using
a single core. I assume performance with the lower memory rate is
considerably worse, but I haven’t done any measurements.

It’s very nice that I can include this in my OS configuration and then
pretty much forget about it. Big thanks to all guix for a system where
making such changes is so simple!

Regards,
Timotej

¹ https://forum.armbian.com/topic/15082-rock64-focal-fossa-memory-frequency/