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>
[-- 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 --]
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 #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 --]
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
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’.
[-- 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 --]
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
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
[-- 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 --]
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
[-- 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 --]
> 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
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
> > 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
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
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
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
[-- 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 --]
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’.
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’.
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’.
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
[-- 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 --]
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’.
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’.
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
[-- 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 --]
[-- 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 --]
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’.
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’.
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>
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
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
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.
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’.
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’.
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
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’.
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’.
[-- 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 --]
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’.
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
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
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
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
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’.
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!
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
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
[-- 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 --]
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
[-- 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 --]
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
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’.
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
[-- 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 --]
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