unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* Release v1.2 timetable
@ 2020-09-29 12:16 zimoun
  2020-09-29 15:07 ` Danny Milosavljevic
                   ` (2 more replies)
  0 siblings, 3 replies; 51+ messages in thread
From: zimoun @ 2020-09-29 12:16 UTC (permalink / raw)
  To: Guix Devel

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>


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-09-29 12:16 Release v1.2 timetable zimoun
@ 2020-09-29 15:07 ` Danny Milosavljevic
  2020-10-07 14:51   ` zimoun
  2020-10-05 10:18 ` pelzflorian (Florian Pelz)
  2020-10-19 15:17 ` Update on the timeline for the release v1.2 zimoun
  2 siblings, 1 reply; 51+ messages in thread
From: Danny Milosavljevic @ 2020-09-29 15:07 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-09-29 12:16 Release v1.2 timetable zimoun
  2020-09-29 15:07 ` Danny Milosavljevic
@ 2020-10-05 10:18 ` pelzflorian (Florian Pelz)
  2020-10-05 11:16   ` Julien Lepiller
  2020-10-19 15:17 ` Update on the timeline for the release v1.2 zimoun
  2 siblings, 1 reply; 51+ messages in thread
From: pelzflorian (Florian Pelz) @ 2020-10-05 10:18 UTC (permalink / raw)
  To: Julien Lepiller; +Cc: Guix Devel

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-05 10:18 ` pelzflorian (Florian Pelz)
@ 2020-10-05 11:16   ` Julien Lepiller
  2020-10-05 12:38     ` Miguel Ángel Arruga Vivas
  2020-10-05 13:48     ` Ludovic Courtès
  0 siblings, 2 replies; 51+ messages in thread
From: Julien Lepiller @ 2020-10-05 11:16 UTC (permalink / raw)
  To: pelzflorian (Florian Pelz); +Cc: Guix Devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-05 11:16   ` Julien Lepiller
@ 2020-10-05 12:38     ` Miguel Ángel Arruga Vivas
  2020-10-05 13:50       ` Julien Lepiller
  2020-10-05 13:48     ` Ludovic Courtès
  1 sibling, 1 reply; 51+ messages in thread
From: Miguel Ángel Arruga Vivas @ 2020-10-05 12:38 UTC (permalink / raw)
  To: guix-devel

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-05 11:16   ` Julien Lepiller
  2020-10-05 12:38     ` Miguel Ángel Arruga Vivas
@ 2020-10-05 13:48     ` Ludovic Courtès
  2020-10-05 21:17       ` zimoun
  1 sibling, 1 reply; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-05 13:48 UTC (permalink / raw)
  To: Julien Lepiller; +Cc: Guix Devel

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-05 12:38     ` Miguel Ángel Arruga Vivas
@ 2020-10-05 13:50       ` Julien Lepiller
  0 siblings, 0 replies; 51+ messages in thread
From: Julien Lepiller @ 2020-10-05 13:50 UTC (permalink / raw)
  To: Miguel Ángel Arruga Vivas, guix-devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-05 13:48     ` Ludovic Courtès
@ 2020-10-05 21:17       ` zimoun
  2020-10-06  6:57         ` Mathieu Othacehe
  2020-10-06  6:59         ` Efraim Flashner
  0 siblings, 2 replies; 51+ messages in thread
From: zimoun @ 2020-10-05 21:17 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-05 21:17       ` zimoun
@ 2020-10-06  6:57         ` Mathieu Othacehe
  2020-10-07 14:36           ` zimoun
  2020-10-06  6:59         ` Efraim Flashner
  1 sibling, 1 reply; 51+ messages in thread
From: Mathieu Othacehe @ 2020-10-06  6:57 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel


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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-05 21:17       ` zimoun
  2020-10-06  6:57         ` Mathieu Othacehe
@ 2020-10-06  6:59         ` Efraim Flashner
  2020-10-06  7:05           ` Mathieu Othacehe
  1 sibling, 1 reply; 51+ messages in thread
From: Efraim Flashner @ 2020-10-06  6:59 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-06  6:59         ` Efraim Flashner
@ 2020-10-06  7:05           ` Mathieu Othacehe
  2020-10-06  7:26             ` Efraim Flashner
  0 siblings, 1 reply; 51+ messages in thread
From: Mathieu Othacehe @ 2020-10-06  7:05 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: Guix Devel


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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-06  7:05           ` Mathieu Othacehe
@ 2020-10-06  7:26             ` Efraim Flashner
  2020-10-06  7:57               ` Mathieu Othacehe
  0 siblings, 1 reply; 51+ messages in thread
From: Efraim Flashner @ 2020-10-06  7:26 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: Guix Devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-06  7:26             ` Efraim Flashner
@ 2020-10-06  7:57               ` Mathieu Othacehe
  2020-10-07 14:39                 ` zimoun
                                   ` (2 more replies)
  0 siblings, 3 replies; 51+ messages in thread
From: Mathieu Othacehe @ 2020-10-06  7:57 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: Guix Devel


> 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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-06  6:57         ` Mathieu Othacehe
@ 2020-10-07 14:36           ` zimoun
  2020-10-21  9:14             ` Ludovic Courtès
  0 siblings, 1 reply; 51+ messages in thread
From: zimoun @ 2020-10-07 14:36 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: Guix Devel

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-06  7:57               ` Mathieu Othacehe
@ 2020-10-07 14:39                 ` zimoun
  2020-10-09 18:25                 ` Andreas Enge
  2020-10-12 11:47                 ` Shipping more installer images? Ludovic Courtès
  2 siblings, 0 replies; 51+ messages in thread
From: zimoun @ 2020-10-07 14:39 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: Guix Devel

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-09-29 15:07 ` Danny Milosavljevic
@ 2020-10-07 14:51   ` zimoun
  2020-10-07 15:39     ` Danny Milosavljevic
  2020-10-07 16:31     ` Release v1.2 timetable Danny Milosavljevic
  0 siblings, 2 replies; 51+ messages in thread
From: zimoun @ 2020-10-07 14:51 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: Guix Devel

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-07 14:51   ` zimoun
@ 2020-10-07 15:39     ` Danny Milosavljevic
  2020-10-07 15:56       ` Weird things found while fixing basic Guix packages Danny Milosavljevic
                         ` (2 more replies)
  2020-10-07 16:31     ` Release v1.2 timetable Danny Milosavljevic
  1 sibling, 3 replies; 51+ messages in thread
From: Danny Milosavljevic @ 2020-10-07 15:39 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Weird things found while fixing basic Guix packages
  2020-10-07 15:39     ` Danny Milosavljevic
@ 2020-10-07 15:56       ` Danny Milosavljevic
  2020-10-12 11:53         ` Ludovic Courtès
  2020-10-07 16:29       ` Release v1.2 timetable Danny Milosavljevic
  2020-10-12 11:52       ` 32-bit builds on 64-bit hardware/VMs Ludovic Courtès
  2 siblings, 1 reply; 51+ messages in thread
From: Danny Milosavljevic @ 2020-10-07 15:56 UTC (permalink / raw)
  Cc: Guix Devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-07 15:39     ` Danny Milosavljevic
  2020-10-07 15:56       ` Weird things found while fixing basic Guix packages Danny Milosavljevic
@ 2020-10-07 16:29       ` Danny Milosavljevic
  2020-10-12 11:52       ` 32-bit builds on 64-bit hardware/VMs Ludovic Courtès
  2 siblings, 0 replies; 51+ messages in thread
From: Danny Milosavljevic @ 2020-10-07 16:29 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-07 14:51   ` zimoun
  2020-10-07 15:39     ` Danny Milosavljevic
@ 2020-10-07 16:31     ` Danny Milosavljevic
  1 sibling, 0 replies; 51+ messages in thread
From: Danny Milosavljevic @ 2020-10-07 16:31 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-06  7:57               ` Mathieu Othacehe
  2020-10-07 14:39                 ` zimoun
@ 2020-10-09 18:25                 ` Andreas Enge
  2020-10-09 18:37                   ` Danny Milosavljevic
  2020-10-12 11:47                 ` Shipping more installer images? Ludovic Courtès
  2 siblings, 1 reply; 51+ messages in thread
From: Andreas Enge @ 2020-10-09 18:25 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: Guix Devel

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



^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-09 18:25                 ` Andreas Enge
@ 2020-10-09 18:37                   ` Danny Milosavljevic
  0 siblings, 0 replies; 51+ messages in thread
From: Danny Milosavljevic @ 2020-10-09 18:37 UTC (permalink / raw)
  To: Andreas Enge; +Cc: Guix Devel, Mathieu Othacehe

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Shipping more installer images?
  2020-10-06  7:57               ` Mathieu Othacehe
  2020-10-07 14:39                 ` zimoun
  2020-10-09 18:25                 ` Andreas Enge
@ 2020-10-12 11:47                 ` Ludovic Courtès
  2020-10-12 13:48                   ` Danny Milosavljevic
  2020-10-13 15:07                   ` Efraim Flashner
  2 siblings, 2 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-12 11:47 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: Guix Devel

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* 32-bit builds on 64-bit hardware/VMs
  2020-10-07 15:39     ` Danny Milosavljevic
  2020-10-07 15:56       ` Weird things found while fixing basic Guix packages Danny Milosavljevic
  2020-10-07 16:29       ` Release v1.2 timetable Danny Milosavljevic
@ 2020-10-12 11:52       ` Ludovic Courtès
  2020-10-12 12:06         ` Andreas Enge
  2 siblings, 1 reply; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-12 11:52 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: Guix Devel

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Weird things found while fixing basic Guix packages
  2020-10-07 15:56       ` Weird things found while fixing basic Guix packages Danny Milosavljevic
@ 2020-10-12 11:53         ` Ludovic Courtès
  0 siblings, 0 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-12 11:53 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: Guix Devel

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: 32-bit builds on 64-bit hardware/VMs
  2020-10-12 11:52       ` 32-bit builds on 64-bit hardware/VMs Ludovic Courtès
@ 2020-10-12 12:06         ` Andreas Enge
  2020-10-13 13:54           ` Ludovic Courtès
  0 siblings, 1 reply; 51+ messages in thread
From: Andreas Enge @ 2020-10-12 12:06 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel

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



^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Shipping more installer images?
  2020-10-12 11:47                 ` Shipping more installer images? Ludovic Courtès
@ 2020-10-12 13:48                   ` Danny Milosavljevic
  2020-10-13 13:51                     ` Ludovic Courtès
  2020-10-13 15:07                   ` Efraim Flashner
  1 sibling, 1 reply; 51+ messages in thread
From: Danny Milosavljevic @ 2020-10-12 13:48 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel, Mathieu Othacehe

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Shipping more installer images?
  2020-10-12 13:48                   ` Danny Milosavljevic
@ 2020-10-13 13:51                     ` Ludovic Courtès
  2020-10-13 14:19                       ` Mathieu Othacehe
  2020-10-13 16:29                       ` Danny Milosavljevic
  0 siblings, 2 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-13 13:51 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: Guix Devel, Mathieu Othacehe

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: 32-bit builds on 64-bit hardware/VMs
  2020-10-12 12:06         ` Andreas Enge
@ 2020-10-13 13:54           ` Ludovic Courtès
  0 siblings, 0 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-13 13:54 UTC (permalink / raw)
  To: Andreas Enge; +Cc: Guix Devel

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Shipping more installer images?
  2020-10-13 13:51                     ` Ludovic Courtès
@ 2020-10-13 14:19                       ` Mathieu Othacehe
  2020-10-13 21:23                         ` Ludovic Courtès
  2020-10-13 16:29                       ` Danny Milosavljevic
  1 sibling, 1 reply; 51+ messages in thread
From: Mathieu Othacehe @ 2020-10-13 14:19 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel


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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Shipping more installer images?
  2020-10-12 11:47                 ` Shipping more installer images? Ludovic Courtès
  2020-10-12 13:48                   ` Danny Milosavljevic
@ 2020-10-13 15:07                   ` Efraim Flashner
  2020-10-13 21:25                     ` Ludovic Courtès
  1 sibling, 1 reply; 51+ messages in thread
From: Efraim Flashner @ 2020-10-13 15:07 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel, Mathieu Othacehe

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Shipping more installer images?
  2020-10-13 13:51                     ` Ludovic Courtès
  2020-10-13 14:19                       ` Mathieu Othacehe
@ 2020-10-13 16:29                       ` Danny Milosavljevic
  1 sibling, 0 replies; 51+ messages in thread
From: Danny Milosavljevic @ 2020-10-13 16:29 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel, Mathieu Othacehe

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Shipping more installer images?
  2020-10-13 14:19                       ` Mathieu Othacehe
@ 2020-10-13 21:23                         ` Ludovic Courtès
  0 siblings, 0 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-13 21:23 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: Guix Devel

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Shipping more installer images?
  2020-10-13 15:07                   ` Efraim Flashner
@ 2020-10-13 21:25                     ` Ludovic Courtès
  0 siblings, 0 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-13 21:25 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: Guix Devel, Mathieu Othacehe

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Update on the timeline for the release v1.2.
  2020-09-29 12:16 Release v1.2 timetable zimoun
  2020-09-29 15:07 ` Danny Milosavljevic
  2020-10-05 10:18 ` pelzflorian (Florian Pelz)
@ 2020-10-19 15:17 ` zimoun
  2020-10-19 18:26   ` Miguel Ángel Arruga Vivas
  2020-10-21 12:44   ` Ludovic Courtès
  2 siblings, 2 replies; 51+ messages in thread
From: zimoun @ 2020-10-19 15:17 UTC (permalink / raw)
  To: Guix Devel, Marius Bakke, Mathieu Othacehe

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>


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-19 15:17 ` Update on the timeline for the release v1.2 zimoun
@ 2020-10-19 18:26   ` Miguel Ángel Arruga Vivas
  2020-10-19 19:27     ` pelzflorian (Florian Pelz)
  2020-10-21 12:44   ` Ludovic Courtès
  1 sibling, 1 reply; 51+ messages in thread
From: Miguel Ángel Arruga Vivas @ 2020-10-19 18:26 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel, Mathieu Othacehe

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-19 18:26   ` Miguel Ángel Arruga Vivas
@ 2020-10-19 19:27     ` pelzflorian (Florian Pelz)
  2020-10-19 21:57       ` Julien Lepiller
  0 siblings, 1 reply; 51+ messages in thread
From: pelzflorian (Florian Pelz) @ 2020-10-19 19:27 UTC (permalink / raw)
  To: Miguel Ángel Arruga Vivas; +Cc: Guix Devel, Mathieu Othacehe

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-19 19:27     ` pelzflorian (Florian Pelz)
@ 2020-10-19 21:57       ` Julien Lepiller
  0 siblings, 0 replies; 51+ messages in thread
From: Julien Lepiller @ 2020-10-19 21:57 UTC (permalink / raw)
  To: guix-devel, pelzflorian (Florian Pelz), Miguel Ángel Arruga Vivas
  Cc: Guix Devel, Mathieu Othacehe



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.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-07 14:36           ` zimoun
@ 2020-10-21  9:14             ` Ludovic Courtès
  2020-10-22  7:55               ` Mathieu Othacehe
  2020-10-23  8:39               ` zimoun
  0 siblings, 2 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-21  9:14 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel, Mathieu Othacehe

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-19 15:17 ` Update on the timeline for the release v1.2 zimoun
  2020-10-19 18:26   ` Miguel Ángel Arruga Vivas
@ 2020-10-21 12:44   ` Ludovic Courtès
  2020-10-21 14:14     ` zimoun
  1 sibling, 1 reply; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-21 12:44 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel, Mathieu Othacehe

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-21 12:44   ` Ludovic Courtès
@ 2020-10-21 14:14     ` zimoun
  2020-10-21 15:57       ` Ludovic Courtès
  0 siblings, 1 reply; 51+ messages in thread
From: zimoun @ 2020-10-21 14:14 UTC (permalink / raw)
  To: Ludovic Courtès, Jakub Kądziołka, Efraim Flashner,
	Marius Bakke
  Cc: Guix Devel

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-21 14:14     ` zimoun
@ 2020-10-21 15:57       ` Ludovic Courtès
  2020-10-21 18:03         ` Julien Lepiller
  0 siblings, 1 reply; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-21 15:57 UTC (permalink / raw)
  To: zimoun; +Cc: Jakub Kądziołka, Guix Devel

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-21 15:57       ` Ludovic Courtès
@ 2020-10-21 18:03         ` Julien Lepiller
  2020-10-21 21:27           ` Marius Bakke
  2020-10-21 22:16           ` Ludovic Courtès
  0 siblings, 2 replies; 51+ messages in thread
From: Julien Lepiller @ 2020-10-21 18:03 UTC (permalink / raw)
  To: guix-devel, Ludovic Courtès, zimoun
  Cc: Jakub Kądziołka, Guix Devel



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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-21 18:03         ` Julien Lepiller
@ 2020-10-21 21:27           ` Marius Bakke
  2020-10-21 22:16           ` Ludovic Courtès
  1 sibling, 0 replies; 51+ messages in thread
From: Marius Bakke @ 2020-10-21 21:27 UTC (permalink / raw)
  To: Julien Lepiller, guix-devel, Ludovic Courtès, zimoun
  Cc: Jakub Kądziołka, Guix Devel

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

^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-21 18:03         ` Julien Lepiller
  2020-10-21 21:27           ` Marius Bakke
@ 2020-10-21 22:16           ` Ludovic Courtès
  2020-10-21 22:23             ` zimoun
  2020-10-21 22:36             ` zimoun
  1 sibling, 2 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-21 22:16 UTC (permalink / raw)
  To: Julien Lepiller; +Cc: guix-devel, Jakub Kądziołka

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-21 22:16           ` Ludovic Courtès
@ 2020-10-21 22:23             ` zimoun
  2020-10-21 22:36             ` zimoun
  1 sibling, 0 replies; 51+ messages in thread
From: zimoun @ 2020-10-21 22:23 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel, Jakub Kądziołka

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-21 22:16           ` Ludovic Courtès
  2020-10-21 22:23             ` zimoun
@ 2020-10-21 22:36             ` zimoun
  2020-10-26 22:44               ` Ludovic Courtès
  1 sibling, 1 reply; 51+ messages in thread
From: zimoun @ 2020-10-21 22:36 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel, Jakub Kądziołka

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-21  9:14             ` Ludovic Courtès
@ 2020-10-22  7:55               ` Mathieu Othacehe
  2020-10-23  8:39               ` zimoun
  1 sibling, 0 replies; 51+ messages in thread
From: Mathieu Othacehe @ 2020-10-22  7:55 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel


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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-21  9:14             ` Ludovic Courtès
  2020-10-22  7:55               ` Mathieu Othacehe
@ 2020-10-23  8:39               ` zimoun
  2020-10-26 22:52                 ` Ludovic Courtès
  1 sibling, 1 reply; 51+ messages in thread
From: zimoun @ 2020-10-23  8:39 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel, Mathieu Othacehe

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


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Update on the timeline for the release v1.2.
  2020-10-21 22:36             ` zimoun
@ 2020-10-26 22:44               ` Ludovic Courtès
  0 siblings, 0 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-26 22:44 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel, Jakub Kądziołka

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’.


^ permalink raw reply	[flat|nested] 51+ messages in thread

* Re: Release v1.2 timetable
  2020-10-23  8:39               ` zimoun
@ 2020-10-26 22:52                 ` Ludovic Courtès
  0 siblings, 0 replies; 51+ messages in thread
From: Ludovic Courtès @ 2020-10-26 22:52 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel, Mathieu Othacehe

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!


^ permalink raw reply	[flat|nested] 51+ messages in thread

end of thread, other threads:[~2020-10-26 22:53 UTC | newest]

Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-29 12:16 Release v1.2 timetable zimoun
2020-09-29 15:07 ` Danny Milosavljevic
2020-10-07 14:51   ` zimoun
2020-10-07 15:39     ` Danny Milosavljevic
2020-10-07 15:56       ` Weird things found while fixing basic Guix packages Danny Milosavljevic
2020-10-12 11:53         ` Ludovic Courtès
2020-10-07 16:29       ` Release v1.2 timetable Danny Milosavljevic
2020-10-12 11:52       ` 32-bit builds on 64-bit hardware/VMs Ludovic Courtès
2020-10-12 12:06         ` Andreas Enge
2020-10-13 13:54           ` Ludovic Courtès
2020-10-07 16:31     ` Release v1.2 timetable Danny Milosavljevic
2020-10-05 10:18 ` pelzflorian (Florian Pelz)
2020-10-05 11:16   ` Julien Lepiller
2020-10-05 12:38     ` Miguel Ángel Arruga Vivas
2020-10-05 13:50       ` Julien Lepiller
2020-10-05 13:48     ` Ludovic Courtès
2020-10-05 21:17       ` zimoun
2020-10-06  6:57         ` Mathieu Othacehe
2020-10-07 14:36           ` zimoun
2020-10-21  9:14             ` Ludovic Courtès
2020-10-22  7:55               ` Mathieu Othacehe
2020-10-23  8:39               ` zimoun
2020-10-26 22:52                 ` Ludovic Courtès
2020-10-06  6:59         ` Efraim Flashner
2020-10-06  7:05           ` Mathieu Othacehe
2020-10-06  7:26             ` Efraim Flashner
2020-10-06  7:57               ` Mathieu Othacehe
2020-10-07 14:39                 ` zimoun
2020-10-09 18:25                 ` Andreas Enge
2020-10-09 18:37                   ` Danny Milosavljevic
2020-10-12 11:47                 ` Shipping more installer images? Ludovic Courtès
2020-10-12 13:48                   ` Danny Milosavljevic
2020-10-13 13:51                     ` Ludovic Courtès
2020-10-13 14:19                       ` Mathieu Othacehe
2020-10-13 21:23                         ` Ludovic Courtès
2020-10-13 16:29                       ` Danny Milosavljevic
2020-10-13 15:07                   ` Efraim Flashner
2020-10-13 21:25                     ` Ludovic Courtès
2020-10-19 15:17 ` Update on the timeline for the release v1.2 zimoun
2020-10-19 18:26   ` Miguel Ángel Arruga Vivas
2020-10-19 19:27     ` pelzflorian (Florian Pelz)
2020-10-19 21:57       ` Julien Lepiller
2020-10-21 12:44   ` Ludovic Courtès
2020-10-21 14:14     ` zimoun
2020-10-21 15:57       ` Ludovic Courtès
2020-10-21 18:03         ` Julien Lepiller
2020-10-21 21:27           ` Marius Bakke
2020-10-21 22:16           ` Ludovic Courtès
2020-10-21 22:23             ` zimoun
2020-10-21 22:36             ` zimoun
2020-10-26 22:44               ` Ludovic Courtès

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git