Release v1.2 timetable

Release v1.2 timetable

[zimoun]

Hi Guixers,

The last v1.1.0 had been released [1] a couple of months ago.  Since
then, a lot of commits with nice features.  And new features deserve new
release. :-)

What do you think if the freeze starts on this Friday Oct., 2nd and the
unfreeze as soon as possible?  (Ideally less than one week.)


To help the release process, please:

 a. test – especially the installer [2]
 b. fix bugs severity:important,serious [3,4] or report
 c. proofread the last manual [5]
 d. translate
 e. highlight an item to ease the list of important changes


The lesson of v1.0.1 [#,@] is: please help in testing the installer. :-)

Some of us will dedicate this Friday Oct., 2nd to test and address bugs.
Please join the collective effort on #guix and let coordinate there.

The idea is to tag the release candidate v1.2rc1 on this Fri, Oct., 2
evening (CET) and then release one week later on Fri, Oct., 9 (if
everything works well!).


How does it sound?


All the best,
simon

[1] <https://guix.gnu.org/en/blog/2020/gnu-guix-1.1.0-released/>
[2] <https://guix.gnu.org/manual/devel/en/guix.html#System-Installation>
[3] <http://issues.guix.gnu.org/search?query=severity%3Aserious+is%3Aopen>
[4] <http://issues.guix.gnu.org/search?query=severity%3Aimportant+is%3Aopen>
[5] <https://guix.gnu.org/manual/devel/en/guix.html>

[#] <https://guix.gnu.org/en/blog/2019/gnu-guix-1.0.1-released/>
[@] <https://issues.guix.gnu.org/issue/35541>

Re: Release v1.2 timetable

[Danny Milosavljevic]

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

Hi Zimoun,

On Tue, 29 Sep 2020 14:16:30 +0200
zimoun <zimon.toutoune@gmail.com> wrote:

>  b. fix bugs severity:important,serious [3,4] or report

Bug #43513 means that all armhf substitutes built for armhf on anything else
than armhf (especially those built on aarch64) are untrustworthy.

I'm working on fixing it (Patch #43591)--but it will entail a complete rebuild
of all packages at least on all 32 bit architectures.

If this bug is not fixed AND TESTED in time for the release, I would ask to
remove ARMHF and i686 from the list of supported systems for the time being,
and disable substitutes for armhf and i686--at least those built on a machine
that is not exactly the same (armhf and i686, respectively).

That bug is horrible.

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

Re: Release v1.2 timetable

[zimoun]

Dear Danny,

On Tue, 29 Sep 2020 at 17:08, Danny Milosavljevic
<dannym@scratchpost.org> wrote:

> >  b. fix bugs severity:important,serious [3,4] or report
>
> Bug #43513 means that all armhf substitutes built for armhf on anything else
> than armhf (especially those built on aarch64) are untrustworthy.
>
> I'm working on fixing it (Patch #43591)--but it will entail a complete rebuild
> of all packages at least on all 32 bit architectures.
>
> If this bug is not fixed AND TESTED in time for the release, I would ask to
> remove ARMHF and i686 from the list of supported systems for the time being,
> and disable substitutes for armhf and i686--at least those built on a machine
> that is not exactly the same (armhf and i686, respectively).
>
> That bug is horrible.

Ouch!  Thank you for working on that.


I have read Bug #43513 and Patch #43591 [1,2] and the table [3] is not
really encouraging. :-(

If I understand correctly, the plan is to disable some architectures
with this Patch #43829 [4], right?

BTW, is this Bug #43720 [5] blocking for the release too?

Well, what is the status and the plan about this armhf topic?


[1] <http://issues.guix.gnu.org/issue/43513>
[2] <http://issues.guix.gnu.org/issue/43591>
[3] <http://issues.guix.gnu.org/issue/43591#30>
[4] <http://issues.guix.gnu.org/43829>
[5] <https://issues.guix.gnu.org/43720>

All the best,
simon

Re: Release v1.2 timetable

[Danny Milosavljevic]

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

Hi,

On Wed, 7 Oct 2020 16:51:46 +0200
zimoun <zimon.toutoune@gmail.com> wrote:

> I have read Bug #43513 and Patch #43591 [1,2] and the table [3] is not
> really encouraging. :-(

This bug has serious repercussions for bootstrapping--and thus for the entire
GNU Guix distribution (not to mention those other distributions which do not
enable large file support).  If I were glibc I would be recalling their
last few releases and would be telling everyone not to use those releases.

> If I understand correctly, the plan is to disable some architectures
> with this Patch #43829 [4], right?

Yes, that is correct.

> BTW, is this Bug #43720 [5] blocking for the release too?
> 
> Well, what is the status and the plan about this armhf topic?

There's a branch wip-file-offset-64-sledgehammer (branched off core-updates)
where I'm trying to fix this bug for good.

I keep running into other problems (which have nothing to do with this bug) on
it--which is why I have to do other commits to fix those OTHER problems (to
core-updates).

Each one of those unrelated bugs delays me for a day each (first I have to
notice that one of the build servers stopped building everything on
wip-file-offset-64-sledgehammer, then I have to build core-updates to
see whether it has the problem too (also, chances are that the build of
core-updates on i686-linux-on-x86_64 and armhf-linux-on-aarch64 hangs because
the readdir problem causes an endless loop!), and then fix the problem on
core-updates, then rebase branch wip-file-offset-64-sledgehammer on that
core-updates, and finally restart the build of everything on all architectures
again).

(For example, I just fixed mesa--but it's not reproducible.  Was it not
reproducible before?  No one knows... WHY NOT?)

(Right now xorg-server has a problem with event (non-)ordering... again,
something that is definitely unrelated to file size.  So there I have to go
test that on core-updates again)

Not to mention that on the aarch64 build server I still don't have a working
home directory.  Otherwise I'd just do crontab -e and add the thing above
by myself.  But crontab -e probably doesn't work either...

This is so frustrating.

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

Weird things found while fixing basic Guix packages

[Danny Milosavljevic]

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

Hi,

because I don't have another place to put this, here are some weird things I
found while I was fixing basic Guix packages (for fixing bug #43513), which
have nothing specifically to do with bug #43513:

* curl[-minimal]: Needs (delete-file "tests/data/test1094") to fix a test failure:
  ;; "timeout: 5[LF]"(expected) vs "timeout: 6[LF]"(generated).
  What causes this?

* Why does cmake-bootstrap have curl-minimal as a dependency in the first place?

  It makes sense if bootstrap packages don't have extra dependencies that can
  be avoided.  And this one sounds really weird.  We want to have NETWORK
  CONNECTIVITY while bootstrapping??

  It turns out that that exist in order for ctest to automatically publish test
  results to a dashboard server.  It seems that that cannot be compiled out.
  Could upstream make it possible to remove curl?
  (If one specifies CMAKE_TESTS_CDASH_SERVER="NOTFOUND" then it won't publish.
  CMake_TEST_NO_NETWORK also exists)

* cmake and cmake-bootstrap could be updated to the newest release (3.18.3)
  with a tiny adaption to the snippet.  Do we want to?  It doesn't help us
  with the thing above, though.

* lz4 has "CC=gcc".  Shouldn't that be (string-append "CC=" (cc-for-target)) ?

* Long term, would it be possible to have some kind of check that the closure
  size of bootstrap packages can't exceed some amount?  This way, new
  weirdness like this cannot sneak in.  We need a LOT of checks of
  derivations anyway.  So many things come to mind.

* Grep and coreutils fail strerror_r and perror2 tests in gnulib-tests.
  test-perror2.c:84: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed
  test-strerror_r.c:170: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed

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

Re: Weird things found while fixing basic Guix packages

[Ludovic Courtès]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> because I don't have another place to put this,

Please open individual bugs for things that are undoubtedly bugs, and
individual threads on guix-devel for other things.  IME the more focused
the message or bug report, the higher the chances to get useful
feedback!

Ludo’.

Re: Release v1.2 timetable

[Danny Milosavljevic]

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

Hi zimoun,

On Wed, 7 Oct 2020 17:39:44 +0200
Danny Milosavljevic <dannym@scratchpost.org> wrote:

> > BTW, is this Bug #43720 [5] blocking for the release too?
> > 
> > Well, what is the status and the plan about this armhf topic?  

The short term plan is to only build 32 bit releases on 32 bit machines and
64 bit releases on 64 bit machines (I chose my words very carefully here.
I mean exactly that.  To be clear, do not build armhf on x86_64, do not
build armhf on aarch64, and best also do not build i686 on x86_64).

If there are already substitutes built that way, make sure to take those
offline.

This is not a fix but only a workaround--see table [1].  It IS perfectly
possible and easy for a 32 bit kernel to return a 64 bit value to userspace.
And then userspace can fail--or worse, not fail but still have an error.

Long term, I am fixing it in guix branch wip-file-offset-bits-64-sledgehammer
by enabling large file support.  That means that off_t will be 64 bits on all
architectures (including 32 bits).  Once off_t is the same size on all
architectures, an architecture-dependent off_t size mismatch can't happen,
now can it?

All the 32 bit distributions I know how enabled large file support decades
ago--so it should work fine by now.

[1] http://issues.guix.gnu.org/issue/43591#30

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

32-bit builds on 64-bit hardware/VMs

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Wed, 7 Oct 2020 16:51:46 +0200
> zimoun <zimon.toutoune@gmail.com> wrote:
>
>> I have read Bug #43513 and Patch #43591 [1,2] and the table [3] is not
>> really encouraging. :-(
>
> This bug has serious repercussions for bootstrapping--and thus for the entire
> GNU Guix distribution (not to mention those other distributions which do not
> enable large file support).  If I were glibc I would be recalling their
> last few releases and would be telling everyone not to use those releases.

I think we need less drama and more pragmatism.  :-)

Evidently, we’ve lived with those bugs for years just fine.

So I think we need to focus on the short-term plan for 1.2, which cannot
be a full rebuild.

As a start, could you comment out in ‘machines-for-berlin.scm’ the
machines that need to be removed in order to not run 32-bit builds in
potentially buggy environments?

(I’m sorry that I haven’t been able to contribute more to the discussion
around all the work you’ve done, but I’m really overwhelmed by
information and feel unable to determine the severity of the problem.)

Thanks,
Ludo’.

Re: 32-bit builds on 64-bit hardware/VMs

[Andreas Enge]

Hello,

On Mon, Oct 12, 2020 at 01:52:18PM +0200, Ludovic Courtès wrote:
> As a start, could you comment out in ‘machines-for-berlin.scm’ the
> machines that need to be removed in order to not run 32-bit builds in
> potentially buggy environments?

already done by Danny in commit 81b5eab1a85196725895502637e2540a1535ce8b
of the maintenance repository. However, that leaves only two machines
for armhf. If we had an image for the Novena board, I could set up one
or two more :)  In any case, it will not be enough to keep up with the
architecture.

Andreas

Re: 32-bit builds on 64-bit hardware/VMs

[Ludovic Courtès]

Hi,

Andreas Enge <andreas@enge.fr> skribis:

> On Mon, Oct 12, 2020 at 01:52:18PM +0200, Ludovic Courtès wrote:
>> As a start, could you comment out in ‘machines-for-berlin.scm’ the
>> machines that need to be removed in order to not run 32-bit builds in
>> potentially buggy environments?
>
> already done by Danny in commit 81b5eab1a85196725895502637e2540a1535ce8b
> of the maintenance repository.

Great.

> However, that leaves only two machines for armhf. If we had an image
> for the Novena board, I could set up one or two more :) In any case,
> it will not be enough to keep up with the architecture.

Indeed, at this stage we’re almost giving up on ARMv7 substitutes.  :-/

If you feel like fiddling with the Novenas, I’m sure you could ‘guix
system init /’ them.  You need to be very careful about the bootloader
choice and all, but that should be feasible.

Thanks,
Ludo’.

Re: Release v1.2 timetable

[Danny Milosavljevic]

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

Hi,

On Wed, 7 Oct 2020 16:51:46 +0200
zimoun <zimon.toutoune@gmail.com> wrote:

> BTW, is this Bug #43720 [5] blocking for the release too?

I'd say yes.  If homedirs are not created, one can't use the shiny new Guix
system, now can one?

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

Re: Release v1.2 timetable

[pelzflorian (Florian Pelz)]

On Tue, Sep 29, 2020 at 02:16:30PM +0200, zimoun wrote:
> To help the release process, please:
> […]
>  d. translate

Julien, shall I just push my translation without going through the TP?

Regards,
Florian

Re: Release v1.2 timetable

[Julien Lepiller]

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

I'll try sendinq them a tarball for 1.2. They won't accept new pot files, but maybe they'll update existing ones. You can push directly whatever is not on the TP.

Le 5 octobre 2020 06:18:36 GMT-04:00, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> a écrit :
>On Tue, Sep 29, 2020 at 02:16:30PM +0200, zimoun wrote:
>> To help the release process, please:
>> […]
>>  d. translate
>
>Julien, shall I just push my translation without going through the TP?
>
>Regards,
>Florian

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

Re: Release v1.2 timetable

[Miguel Ángel Arruga Vivas]

Hi Julien,

Julien Lepiller <julien@lepiller.eu> writes:
> I'll try sendinq them a tarball for 1.2. They won't accept new pot
> files, but maybe they'll update existing ones.

Maybe I'm loosing something between all the mail received through this
list or on the IRC where I almost never connect to, but why wouldn't
translationproject.org accept a new release of guix, guix-packages and
guix-manual?  AFAIU it's calling make dist and sending them the tarball,
plus or minus the associated pot files, am I wrong?

On my side I'm working on the translations too, so I hope I have them
ready for the release.  I'll try the proofread to the whole manual too
if I have time enough. :-)

Happy hacking!
Miguel

Re: Release v1.2 timetable

[Julien Lepiller]

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

To be clear, translate guix, guix-packages and guix-manual using the TP. Guix-cookbook and guix-website will not be available, so you can translate them directly.

Le 5 octobre 2020 08:38:32 GMT-04:00, "Miguel Ángel Arruga Vivas" <rosen644835@gmail.com> a écrit :
>Hi Julien,
>
>Julien Lepiller <julien@lepiller.eu> writes:
>> I'll try sendinq them a tarball for 1.2. They won't accept new pot
>> files, but maybe they'll update existing ones.
>
>Maybe I'm loosing something between all the mail received through this
>list or on the IRC where I almost never connect to, but why wouldn't
>translationproject.org accept a new release of guix, guix-packages and
>guix-manual?  AFAIU it's calling make dist and sending them the
>tarball,
>plus or minus the associated pot files, am I wrong?
>
>On my side I'm working on the translations too, so I hope I have them
>ready for the release.  I'll try the proofread to the whole manual too
>if I have time enough. :-)
>
>Happy hacking!
>Miguel

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

Re: Release v1.2 timetable

[Ludovic Courtès]

Hi,

Julien Lepiller <julien@lepiller.eu> skribis:

> I'll try sendinq them a tarball for 1.2.

Would be nice!  There’s quite a lot of new material to translate now, so
better leave people time to work on it.

> They won't accept new pot files, but maybe they'll update existing
> ones.

Sure.  The website POT files were rejected because we said we’d move
them away from the TP anyway, but the other POT files are still welcome
AIUI.

Thanks,
Ludo’.

Re: Release v1.2 timetable

[zimoun]

Hi,

On Mon, 5 Oct 2020 at 15:49, Ludovic Courtès <ludo@gnu.org> wrote:

> Would be nice!  There’s quite a lot of new material to translate now, so
> better leave people time to work on it.

Do we fix a "deadline"?  I mean a (movable) date as objective for
releasing?  Initially, I thought about Oct. 29th?  WDYT?

Danny told about i686 and arm&co from #43513 and #43591.
Marius sent in #41863 a comment about GDM.
Ludo did some progress on #39260.
I hope I could send a new version about guix-install.sh #43769
tomorrow, I mean it should be fixed before the end of this week.

<https://lists.gnu.org/archive/html/guix-devel/2020-09/msg00302.html>
<http://issues.guix.gnu.org/issue/41863>
<http://issues.guix.gnu.org/issue/43769>
<https://issues.guix.gnu.org/39260>

Something is missing?

What is the status of the installer?

All the best,
simon

Re: Release v1.2 timetable

[Mathieu Othacehe]

Hey zimoun,

> What is the status of the installer?

I don't think there are known issues at the moment. I have started
testing it on my laptop, by booting on a flash drive and installing on
another one, while being quite anxious for my main hard drive :p.

Maybe it would be nice to start a 1.2 branch so that we can all test the
same software and limit the risks of regression.

Thanks,

Mathieu

-- 
https://othacehe.org

Re: Release v1.2 timetable

[zimoun]

Hi Matthieu,

On Tue, 6 Oct 2020 at 08:57, Mathieu Othacehe <othacehe@gnu.org> wrote:

> > What is the status of the installer?
>
> I don't think there are known issues at the moment. I have started
> testing it on my laptop, by booting on a flash drive and installing on
> another one, while being quite anxious for my main hard drive :p.

Thank you for the tests.


> Maybe it would be nice to start a 1.2 branch so that we can all test the
> same software and limit the risks of regression.

Yes, it could be nice but I think it is still missing an update about
2 bug reports:

<https://issues.guix.gnu.org/39260>
<http://issues.guix.gnu.org/issue/43769>

For the latter, I have not had yet the time these days (sometimes
boring daily jobs happen ;-)) to send the quick update.

WDYT?

Cheers,
simon

Re: Release v1.2 timetable

[Ludovic Courtès]

Hello!

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

> <https://issues.guix.gnu.org/39260>

For that we need a Guile-Git release, which could be made anytime now.
Mathieu, do you want to take care of it?  If not, I can do it.

> <http://issues.guix.gnu.org/issue/43769>

Done!  :-)

Thanks,
Ludo’.

Re: Release v1.2 timetable

[Mathieu Othacehe]

Hey Ludo,

> For that we need a Guile-Git release, which could be made anytime now.
> Mathieu, do you want to take care of it?  If not, I can do it.

Done with fbac2572f6ab6bf709302b0a270e1e66a942ba07.

Thanks,

Mathieu

Re: Release v1.2 timetable

[zimoun]

Hi,

On Wed, 21 Oct 2020 at 11:14, Ludovic Courtès <ludo@gnu.org> wrote:

> > <https://issues.guix.gnu.org/39260>
>
> For that we need a Guile-Git release, which could be made anytime now.
> Mathieu, do you want to take care of it?  If not, I can do it.

Now, the initial list is done, right?
Commit 298f9d29d6c26e408a90d08d147d926aa6f81ab3 fixes #39260.
And Mathieu released.

Well, #39260 points the libgit2 bug
<https://github.com/libgit2/libgit2/issues/5650> which is not a
stopper.  Does #39260 remain open because of this?


All the best,
simon

Re: Release v1.2 timetable

[Ludovic Courtès]

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

> On Wed, 21 Oct 2020 at 11:14, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> > <https://issues.guix.gnu.org/39260>
>>
>> For that we need a Guile-Git release, which could be made anytime now.
>> Mathieu, do you want to take care of it?  If not, I can do it.
>
> Now, the initial list is done, right?
> Commit 298f9d29d6c26e408a90d08d147d926aa6f81ab3 fixes #39260.
> And Mathieu released.
>
> Well, #39260 points the libgit2 bug
> <https://github.com/libgit2/libgit2/issues/5650> which is not a
> stopper.  Does #39260 remain open because of this?

I had forgotten to close it, we’re done!

Re: Release v1.2 timetable

[Efraim Flashner]

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

On Mon, Oct 05, 2020 at 11:17:29PM +0200, zimoun wrote:
> Hi,
> 
> On Mon, 5 Oct 2020 at 15:49, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> > Would be nice!  There’s quite a lot of new material to translate now, so
> > better leave people time to work on it.
> 
> Do we fix a "deadline"?  I mean a (movable) date as objective for
> releasing?  Initially, I thought about Oct. 29th?  WDYT?
> 
> Danny told about i686 and arm&co from #43513 and #43591.
> Marius sent in #41863 a comment about GDM.
> Ludo did some progress on #39260.
> I hope I could send a new version about guix-install.sh #43769
> tomorrow, I mean it should be fixed before the end of this week.
> 
> <https://lists.gnu.org/archive/html/guix-devel/2020-09/msg00302.html>
> <http://issues.guix.gnu.org/issue/41863>
> <http://issues.guix.gnu.org/issue/43769>
> <https://issues.guix.gnu.org/39260>
> 
> Something is missing?
> 
> What is the status of the installer?
> 

What's the plan for an installer for the armhf/aarch64 boards? Do we
want to produce installer images for them or just ensure they work? I
ran into some issues when I was trying to create an installer for the
beaglebone black.

-- 
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.2 timetable

[Mathieu Othacehe]

Hello Efraim,

> What's the plan for an installer for the armhf/aarch64 boards? Do we
> want to produce installer images for them or just ensure they work? I
> ran into some issues when I was trying to create an installer for the
> beaglebone black.

I think that creating installer for those boards is a bit premature,
given how hard it is to test the installer on real hardware. However, we
could consider shipping bare-bones disk-images for the boards supported
by the image-type option.

WDYT?

Mathieu

Re: Release v1.2 timetable

[Efraim Flashner]

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

On Tue, Oct 06, 2020 at 09:05:53AM +0200, Mathieu Othacehe wrote:
> 
> Hello Efraim,
> 
> > What's the plan for an installer for the armhf/aarch64 boards? Do we
> > want to produce installer images for them or just ensure they work? I
> > ran into some issues when I was trying to create an installer for the
> > beaglebone black.
> 
> I think that creating installer for those boards is a bit premature,
> given how hard it is to test the installer on real hardware. However, we
> could consider shipping bare-bones disk-images for the boards supported
> by the image-type option.
> 
> WDYT?
> 

I'm actually not really sure how one would use the installer on one of
the boards. I think the bare-bones disk-images would be best; just
download it and flash it onto the board or an SD card and edit
/etc/config.scm to add your user and services. Or to boot up into the
installer and overwrite itself.

-- 
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.2 timetable

[Mathieu Othacehe]

> I'm actually not really sure how one would use the installer on one of
> the boards. I think the bare-bones disk-images would be best; just
> download it and flash it onto the board or an SD card and edit
> /etc/config.scm to add your user and services. Or to boot up into the
> installer and overwrite itself.

The CI is already building substitutes for two images
(hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
maybe release 1.2 version of those images.

Mathieu

Re: Release v1.2 timetable

[zimoun]

> > I'm actually not really sure how one would use the installer on one of
> > the boards. I think the bare-bones disk-images would be best; just
> > download it and flash it onto the board or an SD card and edit
> > /etc/config.scm to add your user and services. Or to boot up into the
> > installer and overwrite itself.
>
> The CI is already building substitutes for two images
> (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
> maybe release 1.2 version of those images.

Which means update these 2 webpages?

Possible to do now:

<http://guix.gnu.org/en/download/latest/>

and then:

<http://guix.gnu.org/en/download/>


WDYT?

All the best,
simon

Re: Release v1.2 timetable

[Andreas Enge]

On Tue, Oct 06, 2020 at 09:57:20AM +0200, Mathieu Othacehe wrote:
> The CI is already building substitutes for two images
> (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
> maybe release 1.2 version of those images.

Nice! For completely selfish reasons, I would like to also see an
image for the novena board.

Andreas

Re: Release v1.2 timetable

[Danny Milosavljevic]

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

On Fri, 9 Oct 2020 20:25:57 +0200
Andreas Enge <andreas@enge.fr> wrote:

> On Tue, Oct 06, 2020 at 09:57:20AM +0200, Mathieu Othacehe wrote:
> > The CI is already building substitutes for two images
> > (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
> > maybe release 1.2 version of those images.  
> 
> Nice! For completely selfish reasons, I would like to also see an
> image for the novena board.

+1

I have a Novena board now (for GNU Mes for ARM work)--but no Guix
for it yet.

In other news, I've disabled building 32 bit packages on 64 bit machines
in guix-maintenance now.

A Novena image must NOT use any 32 bit substitutes that had already been
built *on 64 bit machines* to make that Novena image--otherwise we would
be playing with fire.

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

Shipping more installer images?

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> I'm actually not really sure how one would use the installer on one of
>> the boards. I think the bare-bones disk-images would be best; just
>> download it and flash it onto the board or an SD card and edit
>> /etc/config.scm to add your user and services. Or to boot up into the
>> installer and overwrite itself.
>
> The CI is already building substitutes for two images
> (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
> maybe release 1.2 version of those images.

Keep in mind that images use space at ftp.gnu.org and also take time to
build (having CI up-to-date helps with that, but it doesn’t not
eliminate build times due to the ‘update-guix-package’ dance that takes
place during “make release”.)

Likewise, if we ship more images, we should update the “System
Installation” section accordingly and be clear about what users can
expect.

I guess all I’m saying is that we should not make such decisions lightly
and be sure to examine all the consequences.

Thanks,
Ludo’.

Re: Shipping more installer images?

[Danny Milosavljevic]

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

Hi Ludo,

On Mon, 12 Oct 2020 13:47:25 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> Mathieu Othacehe <othacehe@gnu.org> skribis:
> 
> Keep in mind that images use space at ftp.gnu.org and also take time to
> build (having CI up-to-date helps with that, but it doesn’t not
> eliminate build times due to the ‘update-guix-package’ dance that takes
> place during “make release”.)
> 
> Likewise, if we ship more images, we should update the “System
> Installation” section accordingly and be clear about what users can
> expect.
> 
> I guess all I’m saying is that we should not make such decisions lightly
> and be sure to examine all the consequences.

I agree.

IMO there are only very few RYF-worthy ARM devices--and we should support
at least those, if we support any ARM devices at all.  That includes
providing images for those few (at least A20-EOMA68, A?0*Olinuxino*, and
Novena).

(Now that we use genimage in order to create guix images anyway, long term
we can also provide an importer and import essentially all ARM devices
from buildroot--but that can come later)

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

Re: Shipping more installer images?

[Ludovic Courtès]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Mon, 12 Oct 2020 13:47:25 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Mathieu Othacehe <othacehe@gnu.org> skribis:
>> 
>> Keep in mind that images use space at ftp.gnu.org and also take time to
>> build (having CI up-to-date helps with that, but it doesn’t not
>> eliminate build times due to the ‘update-guix-package’ dance that takes
>> place during “make release”.)
>> 
>> Likewise, if we ship more images, we should update the “System
>> Installation” section accordingly and be clear about what users can
>> expect.
>> 
>> I guess all I’m saying is that we should not make such decisions lightly
>> and be sure to examine all the consequences.
>
> I agree.
>
> IMO there are only very few RYF-worthy ARM devices--and we should support
> at least those, if we support any ARM devices at all.  That includes
> providing images for those few (at least A20-EOMA68, A?0*Olinuxino*, and
> Novena).

So that’s 3 more 1 GiB installer images, right?  If we target Oct. 29th,
how are we going to test them in the meantime?  How long will it take to
build them, even assuming we build on an OverDrive?

I don’t want to spoil the party, I think it’d be great to better support
those devices, but it seems to me that there’s still quite a lot to be
done before we can offer that with reasonable confidence.

Thanks,
Ludo’.

Re: Shipping more installer images?

[Mathieu Othacehe]

Hey Ludo,

> So that’s 3 more 1 GiB installer images, right?  If we target Oct. 29th,
> how are we going to test them in the meantime?  How long will it take to
> build them, even assuming we build on an OverDrive?

I plan to provide compressed disk images for those boards so it's more
around 400MB. Anyway, compression patches are not available yet and I
don't even own one of those boards.

So, while we can provide latest images for those boards, having them in
a stable image will wait 1.3 I guess.

Thanks,

Mathieu

Re: Shipping more installer images?

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> So that’s 3 more 1 GiB installer images, right?  If we target Oct. 29th,
>> how are we going to test them in the meantime?  How long will it take to
>> build them, even assuming we build on an OverDrive?
>
> I plan to provide compressed disk images for those boards so it's more
> around 400MB. Anyway, compression patches are not available yet and I
> don't even own one of those boards.
>
> So, while we can provide latest images for those boards, having them in
> a stable image will wait 1.3 I guess.

OK, sounds like a more reasonable plan to me!  :-)

Ludo’.

Re: Shipping more installer images?

[Danny Milosavljevic]

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

Hi Ludo,

On Tue, 13 Oct 2020 15:51:19 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> > IMO there are only very few RYF-worthy ARM devices--and we should support
> > at least those, if we support any ARM devices at all.  That includes
> > providing images for those few (at least A20-EOMA68, A?0*Olinuxino*, and
> > Novena).  
> 
> So that’s 3 more 1 GiB installer images, right?  If we target Oct. 29th,
> how are we going to test them in the meantime?  How long will it take to
> build them, even assuming we build on an OverDrive?

Sure, I didn't mean "provide them in this release".

I meant: eventually.

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

Re: Shipping more installer images?

[Efraim Flashner]

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

On Mon, Oct 12, 2020 at 01:47:25PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Mathieu Othacehe <othacehe@gnu.org> skribis:
> 
> >> I'm actually not really sure how one would use the installer on one of
> >> the boards. I think the bare-bones disk-images would be best; just
> >> download it and flash it onto the board or an SD card and edit
> >> /etc/config.scm to add your user and services. Or to boot up into the
> >> installer and overwrite itself.
> >
> > The CI is already building substitutes for two images
> > (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
> > maybe release 1.2 version of those images.
> 
> Keep in mind that images use space at ftp.gnu.org and also take time to
> build (having CI up-to-date helps with that, but it doesn’t not
> eliminate build times due to the ‘update-guix-package’ dance that takes
> place during “make release”.)

We could also list out the commands for building the image and have
"community images" built and tested by people who actually have the
boards.

> Likewise, if we ship more images, we should update the “System
> Installation” section accordingly and be clear about what users can
> expect.

My slightly more featureful pine64plus image I built for myself came out
to 1.5 GiB and 291 MiB with bzip2. I don't know how much space the other
images or x86* images are.

We could also build and test them on a different schedule and upload
them at a later date as they're shown to be working.

> I guess all I’m saying is that we should not make such decisions lightly
> and be sure to examine all the consequences.
> 
> Thanks,
> Ludo’.

-- 
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: Shipping more installer images?

[Ludovic Courtès]

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

> On Mon, Oct 12, 2020 at 01:47:25PM +0200, Ludovic Courtès wrote:
>> Hi,
>> 
>> Mathieu Othacehe <othacehe@gnu.org> skribis:
>> 
>> >> I'm actually not really sure how one would use the installer on one of
>> >> the boards. I think the bare-bones disk-images would be best; just
>> >> download it and flash it onto the board or an SD card and edit
>> >> /etc/config.scm to add your user and services. Or to boot up into the
>> >> installer and overwrite itself.
>> >
>> > The CI is already building substitutes for two images
>> > (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
>> > maybe release 1.2 version of those images.
>> 
>> Keep in mind that images use space at ftp.gnu.org and also take time to
>> build (having CI up-to-date helps with that, but it doesn’t not
>> eliminate build times due to the ‘update-guix-package’ dance that takes
>> place during “make release”.)
>
> We could also list out the commands for building the image and have
> "community images" built and tested by people who actually have the
> boards.

Yeah, though “community images” could rhyme with
“we’re-not-sure-what’s-inside images”.  :-)

>> Likewise, if we ship more images, we should update the “System
>> Installation” section accordingly and be clear about what users can
>> expect.
>
> My slightly more featureful pine64plus image I built for myself came out
> to 1.5 GiB and 291 MiB with bzip2. I don't know how much space the other
> images or x86* images are.

Cool.

> We could also build and test them on a different schedule and upload
> them at a later date as they're shown to be working.

Hmm, tricky, security-wise.

Anyway, let’s work on that for 1.3!

Ludo’.

Update on the timeline for the release v1.2.

[zimoun]

Dear,

The date Nov. 6th seems a more reasonable target as a release date.

From what I am reading,

 - the tests of the installer are work ongoing
 - important packages updates are also ongoing (Julia, OCaml, ...)
 - fixes
 - manual typos and various improvement
 - staging is freezed

Contributors, please run "guix pull", update the packages you are
using and report unexpected behaviour.

Committers, the project keeps moving forward because you not only push
your own awesome changes, but also offer some of your time reviewing
and pushing other people’s changes. As a committer, you’re welcome to
use your expertise and commit rights to help other contributors.
[quoting the manual ;-)]


However, I am sorry, I have not been able to read what is happening on
the translation side --- aside French one ;-).  How is the shape?

The bug #43591 [0] hitting --system or --target (I am still confused
which one. :-)) is in progress.  And these architectures will not be
released, right?


The proposed coming timeline is:

 - freeze starting the Oct. 26th
 - last round for testing all over the week
 - unfreeze the Oct. 29th and then create the branch
 - minor bug fixes and all the papeword around (NEWS, blog, etc.)
 - release Nov. 6th.

Does this timeline sound good,

@Mathieu: to generate the various images?
@Marius: to merge staging?
@Translators: about the string-freeze,  almost 2 weeks?


All the best,
simon

0: <http://issues.guix.gnu.org/issue/43591#31>

> [2] <https://guix.gnu.org/manual/devel/en/guix.html#System-Installation>
> [3] <http://issues.guix.gnu.org/search?query=severity%3Aserious+is%3Aopen>
> [4] <http://issues.guix.gnu.org/search?query=severity%3Aimportant+is%3Aopen>
> [5] <https://guix.gnu.org/manual/devel/en/guix.html>

Re: Update on the timeline for the release v1.2.

[Miguel Ángel Arruga Vivas]

Hi Simon,

Wow, we're almost there! :-)

Just some comments inline.

zimoun <zimon.toutoune@gmail.com> writes:
> However, I am sorry, I have not been able to read what is happening on
> the translation side --- aside French one ;-).  How is the shape?

Spanish translation for manual and program messages are almost ready for
current master.

> The bug #43591 [0] hitting --system or --target (I am still confused
> which one. :-)) is in progress.  And these architectures will not be
> released, right?

IIUC it hits builds for a 32-bit targets (armhf) when the machine is
running a 64-bit kernel (x86_64, aarch64 too?, as the current system),
but aren't these disabled in the farm and this mitigates the issue?

> The proposed coming timeline is:
>
>  - freeze starting the Oct. 26th
>  - last round for testing all over the week
>  - unfreeze the Oct. 29th and then create the branch
>  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
>  - release Nov. 6th.
>
> Does this timeline sound good,
>
> @Mathieu: to generate the various images?
> @Marius: to merge staging?
> @Translators: about the string-freeze,  almost 2 weeks?

From my side everything is A-OK, 2 weeks is more than enough to
translate the delta with pre1 and to make the final fine-tune; more than
that shouldn't be expected for the freeze period.  I hope I can do some
extra work too... :)

Happy hacking!
Miguel

Re: Update on the timeline for the release v1.2.

[pelzflorian (Florian Pelz)]

Thank you zimoun for managing all this!  About the string freeze:

On Mon, Oct 19, 2020 at 08:26:31PM +0200, Miguel Ángel Arruga Vivas wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
> > The proposed coming timeline is:
> >
> >  - freeze starting the Oct. 26th
> >  - last round for testing all over the week
> >  - unfreeze the Oct. 29th and then create the branch
> >  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
> >  - release Nov. 6th.
> >
> > Does this timeline sound good,
> >
> > @Mathieu: to generate the various images?
> > @Marius: to merge staging?
> > @Translators: about the string-freeze,  almost 2 weeks?
> 
> From my side everything is A-OK, 2 weeks is more than enough to
> translate the delta with pre1 and to make the final fine-tune; more than
> that shouldn't be expected for the freeze period.  I hope I can do some
> extra work too... :)
> 
> Happy hacking!
> Miguel
> 

From my side such a long string freeze is not needed, but perhaps a
long freeze is useful for other languages’ translators.  I don’t know.
I regularly sync my translation with a POT file from git master:

cd ~/src/guix
git pull
make doc-pot-update
msgmerge --previous --no-wrap --lang=de old-translations.po ~/src/guix/po/doc/guix-manual.pot > new-translations.po

Regards,
Florian

Re: Update on the timeline for the release v1.2.

[Julien Lepiller]

Le 19 octobre 2020 15:27:01 GMT-04:00, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> a écrit :
>Thank you zimoun for managing all this!  About the string freeze:
>
>On Mon, Oct 19, 2020 at 08:26:31PM +0200, Miguel Ángel Arruga Vivas
>wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>> > The proposed coming timeline is:
>> >
>> >  - freeze starting the Oct. 26th
>> >  - last round for testing all over the week
>> >  - unfreeze the Oct. 29th and then create the branch
>> >  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
>> >  - release Nov. 6th.
>> >
>> > Does this timeline sound good,
>> >
>> > @Mathieu: to generate the various images?
>> > @Marius: to merge staging?
>> > @Translators: about the string-freeze,  almost 2 weeks?
>> 
>> From my side everything is A-OK, 2 weeks is more than enough to
>> translate the delta with pre1 and to make the final fine-tune; more
>than
>> that shouldn't be expected for the freeze period.  I hope I can do
>some
>> extra work too... :)
>> 
>> Happy hacking!
>> Miguel
>> 
>
>From my side such a long string freeze is not needed, but perhaps a
>long freeze is useful for other languages’ translators.  I don’t know.
>I regularly sync my translation with a POT file from git master:
>
>cd ~/src/guix
>git pull
>make doc-pot-update
>msgmerge --previous --no-wrap --lang=de old-translations.po
>~/src/guix/po/doc/guix-manual.pot > new-translations.po
>
>Regards,
>Florian

There are quite a bit of changes to the manual already. What we can do is reduce the string freeze to a few days before the release (say november 1st), but provide an intermediate -pre2 version to reduce the workload during the string freeze.

Re: Update on the timeline for the release v1.2.

[Ludovic Courtès]

Hi!

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

> The date Nov. 6th seems a more reasonable target as a release date.

Works for me!

> From what I am reading,
>
>  - the tests of the installer are work ongoing
>  - important packages updates are also ongoing (Julia, OCaml, ...)
>  - fixes
>  - manual typos and various improvement
>  - staging is freezed

Do we want to merge ‘staging’ before the release, though?

> Committers, the project keeps moving forward because you not only push
> your own awesome changes, but also offer some of your time reviewing
> and pushing other people’s changes. As a committer, you’re welcome to
> use your expertise and commit rights to help other contributors.
> [quoting the manual ;-)]

+1!  We’ve accumulated a serious backlog on guix-patches.

> The bug #43591 [0] hitting --system or --target (I am still confused
> which one. :-)) is in progress.  And these architectures will not be
> released, right?

I don’t think anything can be done for this release; I believe
resolution of #43591 will have to wait until after the release
(core-updates).

> The proposed coming timeline is:
>
>  - freeze starting the Oct. 26th
>  - last round for testing all over the week
>  - unfreeze the Oct. 29th and then create the branch
>  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
>  - release Nov. 6th.

Overall LGTM, but could you clarify what you mean by “freeze” on
Oct. 26–29?  No “important” changes to ‘master’, including to the
manual, is that correct?

Thanks,
Ludo’.

Re: Update on the timeline for the release v1.2.

[zimoun]

Dear,

On Wed, 21 Oct 2020 at 14:44, Ludovic Courtès <ludo@gnu.org> wrote:

> >  - staging is freezed
>
> Do we want to merge ‘staging’ before the release, though?

From my point of view, it would be really nice.  Marius or any
"merger" (Jakub, Efraim, Brett), is it reasonable?  WDYT?


> > The proposed coming timeline is:
> >
> >  - freeze starting the Oct. 26th
> >  - last round for testing all over the week
> >  - unfreeze the Oct. 29th and then create the branch
> >  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
> >  - release Nov. 6th.
>
> Overall LGTM, but could you clarify what you mean by “freeze” on
> Oct. 26–29?  No “important” changes to ‘master’, including to the
> manual, is that correct?

Yes, no "important" changes to 'master' which means:
 - no package or service updates
 - no manual entry
 - only serious fixes under guix/ or installer(s)

From my point of view, it is easier to freeze 'master' since everybody
can "guix pull" and check that everything is fine.
Otherwise, instead of the freeze, let create the branch and so "guix
pull --branch=version-1.2.0".  It is up to you.


Cheers,
simon

Re: Update on the timeline for the release v1.2.

[Ludovic Courtès]

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

>> > The proposed coming timeline is:
>> >
>> >  - freeze starting the Oct. 26th
>> >  - last round for testing all over the week
>> >  - unfreeze the Oct. 29th and then create the branch
>> >  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
>> >  - release Nov. 6th.
>>
>> Overall LGTM, but could you clarify what you mean by “freeze” on
>> Oct. 26–29?  No “important” changes to ‘master’, including to the
>> manual, is that correct?
>
> Yes, no "important" changes to 'master' which means:
>  - no package or service updates

I would phrase it as no _important_ package or service updates.
Updating non-critical leaf packages or services is probably fine.

>  - no manual entry
>  - only serious fixes under guix/ or installer(s)
>
> From my point of view, it is easier to freeze 'master' since everybody
> can "guix pull" and check that everything is fine.
> Otherwise, instead of the freeze, let create the branch and so "guix
> pull --branch=version-1.2.0".  It is up to you.

Yeah we could also branch on the 26th and cherry-pick harmless changes
from ‘master’, so people can still have fun on ‘master’.

Mathieu, Marius, Maxim, Tobias: thoughts?

Ludo’.

Re: Update on the timeline for the release v1.2.

[Julien Lepiller]

Le 21 octobre 2020 11:57:48 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>zimoun <zimon.toutoune@gmail.com> skribis:
>
>>> > The proposed coming timeline is:
>>> >
>>> >  - freeze starting the Oct. 26th
>>> >  - last round for testing all over the week
>>> >  - unfreeze the Oct. 29th and then create the branch
>>> >  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
>>> >  - release Nov. 6th.
>>>
>>> Overall LGTM, but could you clarify what you mean by “freeze” on
>>> Oct. 26–29?  No “important” changes to ‘master’, including to the
>>> manual, is that correct?
>>
>> Yes, no "important" changes to 'master' which means:
>>  - no package or service updates
>
>I would phrase it as no _important_ package or service updates.
>Updating non-critical leaf packages or services is probably fine.
>
>>  - no manual entry
>>  - only serious fixes under guix/ or installer(s)
>>
>> From my point of view, it is easier to freeze 'master' since
>everybody
>> can "guix pull" and check that everything is fine.
>> Otherwise, instead of the freeze, let create the branch and so "guix
>> pull --branch=version-1.2.0".  It is up to you.
>
>Yeah we could also branch on the 26th and cherry-pick harmless changes
>from ‘master’, so people can still have fun on ‘master’.
>
>Mathieu, Marius, Maxim, Tobias: thoughts?

Wouldn't that mess up with guix's authentication mechanism? If we branch v1.2 early, our release will have no forward path to master, so all our users will get an error when running guix pull.

>
>Ludo’.

Re: Update on the timeline for the release v1.2.

[Marius Bakke]

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

Julien Lepiller <julien@lepiller.eu> writes:

> Le 21 octobre 2020 11:57:48 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>>zimoun <zimon.toutoune@gmail.com> skribis:
>>
>>>> > The proposed coming timeline is:
>>>> >
>>>> >  - freeze starting the Oct. 26th
>>>> >  - last round for testing all over the week
>>>> >  - unfreeze the Oct. 29th and then create the branch
>>>> >  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
>>>> >  - release Nov. 6th.
>>>>
>>>> Overall LGTM, but could you clarify what you mean by “freeze” on
>>>> Oct. 26–29?  No “important” changes to ‘master’, including to the
>>>> manual, is that correct?
>>>
>>> Yes, no "important" changes to 'master' which means:
>>>  - no package or service updates
>>
>>I would phrase it as no _important_ package or service updates.
>>Updating non-critical leaf packages or services is probably fine.

Agree.  Re: staging, I don't think there is anything release-critical in
it (and it may even introduce bugs, hard to tell because #44121).

>>>  - no manual entry
>>>  - only serious fixes under guix/ or installer(s)
>>>
>>> From my point of view, it is easier to freeze 'master' since
>>everybody
>>> can "guix pull" and check that everything is fine.
>>> Otherwise, instead of the freeze, let create the branch and so "guix
>>> pull --branch=version-1.2.0".  It is up to you.
>>
>>Yeah we could also branch on the 26th and cherry-pick harmless changes
>>from ‘master’, so people can still have fun on ‘master’.

Sounds good to me.

> Wouldn't that mess up with guix's authentication mechanism? If we branch v1.2 early, our release will have no forward path to master, so all our users will get an error when running guix pull.

I think the authentication mechanism starts at a fixed point for new
users/installs (i.e. no previous 'guix pull').

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

Re: Update on the timeline for the release v1.2.

[Ludovic Courtès]

Julien Lepiller <julien@lepiller.eu> skribis:

> Le 21 octobre 2020 11:57:48 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :

[...]

>>Yeah we could also branch on the 26th and cherry-pick harmless changes
>>from ‘master’, so people can still have fun on ‘master’.
>>
>>Mathieu, Marius, Maxim, Tobias: thoughts?
>
> Wouldn't that mess up with guix's authentication mechanism? If we branch v1.2 early, our release will have no forward path to master, so all our users will get an error when running guix pull.

No, that’s fine as long as there’s a path from the source commit to the
target commit.

It’s the same as running ‘guix pull --branch=staging’ today for
instance.

Ludo’.

Re: Update on the timeline for the release v1.2.

[zimoun]

On Thu, 22 Oct 2020 at 00:16, Ludovic Courtès <ludo@gnu.org> wrote:

> It’s the same as running ‘guix pull --branch=staging’ today for
> instance.

Maybe I am doing wrong:

--8<---------------cut here---------------start------------->8---
$ guix describe
Generation 94   Oct 20 2020 18:28:42    (current)
  guix fd0ef0e
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: fd0ef0e128e4ab3c44b59980e6cb056b71441e15

$ guix pull --branch=staging
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: aborting update of channel 'guix' to commit
353bdae32f72b720c7ddd706576ccc40e2b43f95, which is not a descendant of
fd0ef0e128e4ab3c44b59980e6cb056b71441e15
hint: This could indicate that the channel has been tampered with and
is trying to force a roll-back, preventing you from getting the
latest updates.  If you think this is not the case, explicitly allow
non-forward updates.
--8<---------------cut here---------------end--------------->8---

All the best,
simon

Re: Update on the timeline for the release v1.2.

[zimoun]

On Thu, 22 Oct 2020 at 00:16, Ludovic Courtès <ludo@gnu.org> wrote:

> > Wouldn't that mess up with guix's authentication mechanism? If we branch v1.2 early, our release will have no forward path to master, so all our users will get an error when running guix pull.
>
> No, that’s fine as long as there’s a path from the source commit to the
> target commit.
>
> It’s the same as running ‘guix pull --branch=staging’ today for
> instance.

From 58af4c9, I did "guix pull --branch=staging" and then "guix pull
-l" says the last is 353bdae, so far so good.  And from there I run
"guix pull" and paf!

--8<---------------cut here---------------start------------->8---
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: aborting update of channel 'guix' to commit
3ddc47bc07439ab526013031f8e052e4c8c7cd92, which is not a descendant of
353bdae32f72b720c7ddd706576ccc40e2b43f95
hint: This could indicate that the channel has been tampered with and is trying
to force a roll-back, preventing you from getting the latest updates.  If
you think this is not the case, explicitly allow non-forward updates.
--8<---------------cut here---------------end--------------->8---

Well, I do not have all the details about the commit closure
implementation in mind but I remember discussing such cases. :-)
I should do something wrong.


Cheers,
simon

Re: Update on the timeline for the release v1.2.

[Ludovic Courtès]

Hi,

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

> From 58af4c9, I did "guix pull --branch=staging" and then "guix pull
> -l" says the last is 353bdae, so far so good.  And from there I run
> "guix pull" and paf!
>
> Updating channel 'guix' from Git repository at
> 'https://git.savannah.gnu.org/git/guix.git'...
> guix pull: error: aborting update of channel 'guix' to commit
> 3ddc47bc07439ab526013031f8e052e4c8c7cd92, which is not a descendant of
> 353bdae32f72b720c7ddd706576ccc40e2b43f95
> hint: This could indicate that the channel has been tampered with and is trying
> to force a roll-back, preventing you from getting the latest updates.  If
> you think this is not the case, explicitly allow non-forward updates.

That’s expected: once you’re on ‘staging’, pulling back to ‘master’ is
essentially a “downgrade”, hence the error above.

I tell you, it’s working as advertised!

Ludo’.

Re: Update on the timeline for the release v1.2.

[Maxim Cournoyer]

Hello everyone,

Sorry for being late in the discussion.

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

> zimoun <zimon.toutoune@gmail.com> skribis:
>
>>> > The proposed coming timeline is:
>>> >
>>> >  - freeze starting the Oct. 26th
>>> >  - last round for testing all over the week
>>> >  - unfreeze the Oct. 29th and then create the branch
>>> >  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
>>> >  - release Nov. 6th.
>>>
>>> Overall LGTM, but could you clarify what you mean by “freeze” on
>>> Oct. 26–29?  No “important” changes to ‘master’, including to the
>>> manual, is that correct?
>>
>> Yes, no "important" changes to 'master' which means:
>>  - no package or service updates
>
> I would phrase it as no _important_ package or service updates.
> Updating non-critical leaf packages or services is probably fine.

That's kind of already what master is for, so to me "important" doesn't
help that much in discerning what is OK to what is not :-).

>>  - no manual entry
>>  - only serious fixes under guix/ or installer(s)
>>
>> From my point of view, it is easier to freeze 'master' since everybody
>> can "guix pull" and check that everything is fine.
>> Otherwise, instead of the freeze, let create the branch and so "guix
>> pull --branch=version-1.2.0".  It is up to you.

> Yeah we could also branch on the 26th and cherry-pick harmless changes
> from ‘master’, so people can still have fun on ‘master’.
>
> Mathieu, Marius, Maxim, Tobias: thoughts?

This sounds like a better idea to me.  If something needs freezing, it's
technically much easier/safer to branch.  I don't think it's reasonable
to expect all of our ~60 committers to have seen this email and know
they shouldn't push any important updates to master between now and the
6th of November (if I followed correctly).

Thank you!

Maxim

Branching for v1.2?

[Ludovic Courtès]

Hi!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

[...]

>>> From my point of view, it is easier to freeze 'master' since everybody
>>> can "guix pull" and check that everything is fine.
>>> Otherwise, instead of the freeze, let create the branch and so "guix
>>> pull --branch=version-1.2.0".  It is up to you.
>
>> Yeah we could also branch on the 26th and cherry-pick harmless changes
>> from ‘master’, so people can still have fun on ‘master’.
>>
>> Mathieu, Marius, Maxim, Tobias: thoughts?
>
> This sounds like a better idea to me.  If something needs freezing, it's
> technically much easier/safer to branch.  I don't think it's reasonable
> to expect all of our ~60 committers to have seen this email and know
> they shouldn't push any important updates to master between now and the
> 6th of November (if I followed correctly).

Having pushed the (guix transformations) patch¹, which also updates the
manual and thus requires yet some more translation work, I think I don’t
have any serious changes to make and I’d be happy to branch now.  WDYT?

There are a couple of pending issues, notably regarding locales in GRUB,
but nothing big hopefully, and nothing that changes the manual and
strings I believe.

Thoughts?

Tuesday 6th is approaching very fast and probably we’re be a bit behind
schedule, we’ll see.

Ludo’.

¹ https://issues.guix.gnu.org/44321

Re: Branching for v1.2?

[Miguel Ángel Arruga Vivas]

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

Hi!

Ludovic Courtès <ludo@gnu.org> writes:
[...]
> There are a couple of pending issues, notably regarding locales in GRUB,
> but nothing big hopefully, and nothing that changes the manual and
> strings I believe.

I've already pushed the changes for grub.  The only missing bit I've
noticed today during some tests is that some strings in
gnu/installer/parted.scm:user-partition-description still need some i18n
work: format and G_.

> Thoughts?
>
> Tuesday 6th is approaching very fast and probably we’re be a bit behind
> schedule, we’ll see.

I'm unable to provide a patch for that until tomorrow evening/night WET,
but that's pushing more delay onto translations... :(

Does anybody else want to pick up this task on the meantime?  We also
could generate twice the tarball for translations with that update, or
declare it a known bug, as it doesn't break the system.

Best regards,
Miguel

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

Re: Branching for v1.2?

[Ludovic Courtès]

Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
> [...]
>> There are a couple of pending issues, notably regarding locales in GRUB,
>> but nothing big hopefully, and nothing that changes the manual and
>> strings I believe.
>
> I've already pushed the changes for grub.  The only missing bit I've
> noticed today during some tests is that some strings in
> gnu/installer/parted.scm:user-partition-description still need some i18n
> work: format and G_.

Done in commit 8f71305e8f87bf15d158fb2726c4a46cdf36eaf5.

Ludo’.

Re: Branching for v1.2?

[zimoun]

Hi,

On Sat, 31 Oct 2020 at 23:28, Ludovic Courtès <ludo@gnu.org> wrote:

> Having pushed the (guix transformations) patch¹, which also updates the
> manual and thus requires yet some more translation work, I think I don’t
> have any serious changes to make and I’d be happy to branch now.  WDYT?

I think it would be good to branch.


> There are a couple of pending issues, notably regarding locales in GRUB,
> but nothing big hopefully, and nothing that changes the manual and
> strings I believe.

Does it break the system?
Miguel seems to say no.

Does it downgrade the first impression that the user has?


> Tuesday 6th is approaching very fast and probably we’re be a bit behind
> schedule, we’ll see.

I think this Fri. Nov. 6th will be hard; but it is still doable if we
branch really soon.  Tomorrow?


All the best,
simon

Re: Branching for v1.2?

[Miguel Ángel Arruga Vivas]

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

Hi simon,

zimoun <zimon.toutoune@gmail.com> writes:
> Hi,
>
> On Sat, 31 Oct 2020 at 23:28, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Having pushed the (guix transformations) patch¹, which also updates the
>> manual and thus requires yet some more translation work, I think I don’t
>> have any serious changes to make and I’d be happy to branch now.  WDYT?
>
> I think it would be good to branch.
>
>
>> There are a couple of pending issues, notably regarding locales in GRUB,
>> but nothing big hopefully, and nothing that changes the manual and
>> strings I believe.
>
> Does it break the system?
> Miguel seems to say no.

Only Ludo knows about which exact issues was thinking, I can speak only
for myself. :-)

Messages displayed by GRUB should be localized as declared on the
operating-system with current master; menu items aren't translated yet
because I have to work more on that implementation and I couldn't reach
this release with something good, sorry. :-(

> Does it downgrade the first impression that the user has?

As far as my testing goes, all the bits that could lead to that are
already solved on master too.

>> Tuesday 6th is approaching very fast and probably we’re be a bit behind
>> schedule, we’ll see.
>
> I think this Fri. Nov. 6th will be hard; but it is still doable if we
> branch really soon.  Tomorrow?

With my translator hat on: a new tarball for TP has to be generated
before or after creating the branch (1.2.0-pre3).  If done tomorrow, I
think the translations could need a bit later than Friday to catch up;
Florian and Julien, what do you think?

Happy hacking!
Miguel

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

Re: Branching for v1.2?

[Julien Lepiller]

Le 2 novembre 2020 08:20:34 GMT-05:00, "Miguel Ángel Arruga Vivas" <rosen644835@gmail.com> a écrit :
>Hi simon,
>
>zimoun <zimon.toutoune@gmail.com> writes:
>> Hi,
>>
>> On Sat, 31 Oct 2020 at 23:28, Ludovic Courtès <ludo@gnu.org> wrote:
>>
>>> Having pushed the (guix transformations) patch¹, which also updates
>the
>>> manual and thus requires yet some more translation work, I think I
>don’t
>>> have any serious changes to make and I’d be happy to branch now. 
>WDYT?
>>
>> I think it would be good to branch.
>>
>>
>>> There are a couple of pending issues, notably regarding locales in
>GRUB,
>>> but nothing big hopefully, and nothing that changes the manual and
>>> strings I believe.
>>
>> Does it break the system?
>> Miguel seems to say no.
>
>Only Ludo knows about which exact issues was thinking, I can speak only
>for myself. :-)
>
>Messages displayed by GRUB should be localized as declared on the
>operating-system with current master; menu items aren't translated yet
>because I have to work more on that implementation and I couldn't reach
>this release with something good, sorry. :-(
>
>> Does it downgrade the first impression that the user has?
>
>As far as my testing goes, all the bits that could lead to that are
>already solved on master too.
>
>>> Tuesday 6th is approaching very fast and probably we’re be a bit
>behind
>>> schedule, we’ll see.
>>
>> I think this Fri. Nov. 6th will be hard; but it is still doable if we
>> branch really soon.  Tomorrow?
>
>With my translator hat on: a new tarball for TP has to be generated
>before or after creating the branch (1.2.0-pre3).  If done tomorrow, I
>think the translations could need a bit later than Friday to catch up;
>Florian and Julien, what do you think?

I think I can manage the deadline on the 6th if there aren't too many changes, and we generate the tarball today or tomorrow. If we generate it later, we'll need to postpone the deadline to after the weekend I think.

>
>Happy hacking!
>Miguel

Re: Branching for v1.2?

[pelzflorian (Florian Pelz)]

On Mon, Nov 02, 2020 at 10:00:38AM -0500, Julien Lepiller wrote:
> Le 2 novembre 2020 08:20:34 GMT-05:00, "Miguel Ángel Arruga Vivas" <rosen644835@gmail.com> a écrit :
> >With my translator hat on: a new tarball for TP has to be generated
> >before or after creating the branch (1.2.0-pre3).  If done tomorrow, I
> >think the translations could need a bit later than Friday to catch up;
> >Florian and Julien, what do you think?
> 
> I think I can manage the deadline on the 6th if there aren't too
> many changes, and we generate the tarball today or tomorrow. […]

That would be OK for me.

Regards,
Florian

Re: Branching for v1.2?

[Tobias Geerinckx-Rice]

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

Florian,

Thanks for your work on the German translation!  Could you 
incorporate this fix[0] back into the TP version?

Kind regards,

T G-R

[0]: 
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=1aced9aa0c32849939d1facfaa0f3e5f1a6c11e0

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

Re: Branching for v1.2?

[pelzflorian (Florian Pelz)]

On Tue, Nov 03, 2020 at 01:51:18PM +0100, Tobias Geerinckx-Rice wrote:
> Thanks for your work on the German translation!  Could you incorporate this
> fix[0] back into the TP version? […]
> [0]: http://git.savannah.gnu.org/cgit/guix.git/commit/?id=1aced9aa0c32849939d1facfaa0f3e5f1a6c11e0

> wenn [-@sasmp{/tftp/1.2.3.4}-]{+@samp{/tftp/1.2.3.4}+} existiert,

Done.  Thank you for fixing it!

Regards,
Florian