GNU Guix 1.3.0 released

GNU Guix 1.3.0 released

[Maxim Cournoyer]

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

We are pleased to announce the release of GNU Guix 1.3.0!

This release corresponds to 8,300 commits over almost 6 months by 212
people.  Support for the POWER9 platform is now offered as technological
preview.  This release adds new features, refines the user experience
and improves performance.  It also includes many new packages and
services along bug fixes--see below for a list of changes.

Read more about today’s announcement at:

  https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released

• About

  GNU Guix is a transactional package manager and an advanced
  distribution of the GNU system that respects user freedom.  Guix can
  be used on top of any system running the Hurd or the Linux kernel, or
  it can be used as a standalone operating system distribution for i686,
  x86_64, ARMv7, AArch64 and POWER9 machines.

  In addition to standard package management features, Guix supports
  transactional upgrades and roll-backs, unprivileged package
  management, per-user profiles, and garbage collection.  When used as a
  standalone GNU/Linux distribution, Guix offers a declarative,
  stateless approach to operating system configuration management.  Guix
  is highly customizable and hackable through Guile programming
  interfaces and extensions to the Scheme language.

  https://guix.gnu.org

• Download

  Here are the compressed sources and a GPG detached signature[*]:
    https://ftp.gnu.org/gnu/guix/guix-1.3.0.tar.gz   (39MB)
    https://ftp.gnu.org/gnu/guix/guix-1.3.0.tar.gz.sig

  Here are the bootable USB installation images and their signatures[*]:
    https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.i686-linux.iso   (610MB)
    https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.i686-linux.iso.sig
    https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.x86_64-linux.iso   (612MB)
    https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.x86_64-linux.iso.sig

  Here is the QCOW2 virtual machine (VM) image and its signature[*]:
    https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2 (972MB)
    https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2.sig

  Here are the binary tarballs and their signatures[*]:
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.aarch64-linux.tar.xz   (83MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.aarch64-linux.tar.xz.sig
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.armhf-linux.tar.xz   (83MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.armhf-linux.tar.xz.sig
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.i686-linux.tar.xz   (88MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.i686-linux.tar.xz.sig
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.powerpc64le-linux.tar.xz   (85MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.powerpc64le-linux.tar.xz.sig
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz   (87MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz.sig

  Use a mirror for higher download bandwidth:
    https://www.gnu.org/order/ftp.html

  Here are the MD5 and SHA1 checksums:

  406fc1948b8147fa8047a661e3544d4c  guix-1.3.0.tar.gz
  b4820b4c9fc85e2980201bf2e9e9eeb9  guix-binary-1.3.0.aarch64-linux.tar.xz
  5b5e76c48a886866fa2c4267b25107e4  guix-binary-1.3.0.armhf-linux.tar.xz
  79fba3f8f6b1a4c71ba8a1ec394e6e56  guix-binary-1.3.0.i686-linux.tar.xz
  d5f638e498a73d7b238981aef1258a42  guix-binary-1.3.0.powerpc64le-linux.tar.xz
  99ea26fb47b2a8a1ed04a60b30d4fd8c  guix-binary-1.3.0.x86_64-linux.tar.xz
  7565231d32dedcd417fae4985b4ca486  guix-system-vm-image-1.3.0.x86_64-linux.qcow2
  7d0c42c7b53507b4fccabe865dbd78fa  guix-system-install-1.3.0.i686-linux.iso
  d1aa177eafb9becf2fdcd86f9e1f9790  guix-system-install-1.3.0.x86_64-linux.iso
  6c4536c0995d5c487d281cddc63ddda9df2eb749  guix-1.3.0.tar.gz
  414916ebfb8504e9b608d62c22c9f21c9ee6f243  guix-binary-1.3.0.aarch64-linux.tar.xz
  5753f12bdc400e5b848c5c8042f79da7efd390ad  guix-binary-1.3.0.armhf-linux.tar.xz
  ad8ab3957d00add7d0133084dee3d3f00d671246  guix-binary-1.3.0.i686-linux.tar.xz
  fd20ff962ceae612d5c1f19ccb8d9a8068372173  guix-binary-1.3.0.powerpc64le-linux.tar.xz
  c2a805775a6490b2546c30faf967a2db87d8806b  guix-binary-1.3.0.x86_64-linux.tar.xz
  1fbda19d14d8291d13a4bb1ed8a50516fac220c4  guix-system-vm-image-1.3.0.x86_64-linux.qcow2
  87f94f0d656fbca8bafdeabef52d69f52bffb898  guix-system-install-1.3.0.i686-linux.iso
  56cfb1d413344479590bc788ffb99d35dd526d90  guix-system-install-1.3.0.x86_64-linux.iso

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

    gpg --verify guix-1.3.0.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

    gpg --keyserver keys.gnupg.net --recv-keys 27D586A4F8900854329FF09F1260E46482E63562

  and rerun the 'gpg --verify' command.

• Changes in 1.3.0 (since 1.2.0)

  ** Package management

  *** POWER9 (powerpc64le-linux) is now supported as a technology preview
  *** New ‘--export-manifest’ and ‘--export-channels’ options of ‘guix package’
  *** New ‘--profile’ option for ‘guix environment’
  *** New ‘--discover’ option of ‘guix-daemon’, for local substitute discovery
  *** New ‘--advertise’ option of ‘guix publish’
  *** New ‘--with-patch’ and ‘--with-latest’ package transformation options
  *** ‘guix system image’ supersedes the ‘disk-image’ and ‘vm-image’ sub-commands
  *** ‘--verbosity=1’ no longer displays download URLs
  *** ‘guix publish -C’ now supports zstd compression via Guile-zstd
  *** ‘guix-daemon’ now supports zstd substitutes, which decompress faster
  *** New ‘guix import go’ command, to import Go packages
  *** ‘guix import opam’ now supports Coq packages and has a ‘--repo’ option
  *** ‘guix import crate’ now honors semantic versioning (“semver”)
  *** ‘guix import nix’ has been removed
  *** New updaters (see ‘guix refresh’): ‘sourceforge’ and ‘generic-html’
  *** Substitute installation has been optimized
  *** ‘guix’ commands suggest alternative sub-commands or options upon typos
  *** Offloading no longer requires ‘guile’ to be in $PATH on build machines
  *** ‘GUIX_EXTENSIONS_PATH’ is honored when looking for extensions such as GWL
  *** New ‘--format’ option for ‘guix processes’
  *** ‘guix upgrade’ can now be passed several regexps

  ** Distribution

  *** The Guix System demonstration VM now supports the SPICE protocol
  *** The installation script can now run in a fully automated manner
  *** ‘qemu-binfmt-service-type’ now relies on statically-linked QEMU
  *** ‘sysctl-service-type’ enables Linux protected hardlinks/symlinks by default
  *** ‘%base-services’ now includes a default ‘sysctl-service-type’ instance
  *** Linux Logical Volumne Manager (LVM) now supported, via ‘lvm-device-mapping’
  *** ‘guix system init’ has been optimized
  *** ‘guix system’ warns when users/groups appear more than once
  *** ‘guix system image -t rock64-raw’ produces images for Rock64 devices
  *** ‘herd discover guix-daemon on’ turns on substitute server discovery
  *** Default initrd now supports bcachefs
  *** CUPS service includes ‘brlaser’ extension by default
  *** “lp” group is no longer included in ‘%base-groups’
  *** New ‘--graph-backend’ option for ‘guix system {extension,shepherd}-graph’
  *** New services

  agate, cuirass-remote-worker, ipfs, keepalived, laminar, radicale, syncthing,
  transmission-daemon, wireguard, xorg-server

  *** 2009 new packages

  *** 3100 package updates

  Noteworthy updates:
  emacs 27.2, gcc-toolchain 10.3.0, ghc 8.8.3, glibc 2.31, gnome 3.34.5,
  gnupg 2.2.27, go 1.14.15, guile 3.0.5, icecat 78.10.0-guix0-preview1,
  icedtea 3.7.0, inkscape 1.0.2, julia 1.5.3, libreoffice 6.4.7.2,
  linux-libre 5.11.15, ocaml 4.11.1, octave 6.2.0, openjdk 14.0,
  python 3.8.2, racket 8.0, rust 1.51.0, r 4.0.4, sbcl 2.1.3, xfce 4.16.0,
  xorg-server 1.20.10

  ** Programming interfaces

  *** New ‘channel-with-substitutes-available’ procedure in (guix channels)
  *** New modules (guix substitutes), (guix narinfo), and (guix avahi)
  *** <image> records can be passed to ‘guix system image’
  *** New (guix ipfs) module to interact with an IPFS gateway

  ** Noteworthy bug fixes

  *** Risk of local privilege escalation via guix-daemon fixed
      (<https://issues.guix.gnu.org/47229>, CVE-2021-27851)
  *** Setuid programs on Guix System are no longer setgid root
      (<https://issues.guix.gnu.org/46395>)
  *** Risk of local privilege escalation during reconfigure fixed
      (<https://issues.guix.gnu.org/47584>)
  *** Grafting recognizes UTF-16 and UTF-32 store references
      (<https://issues.guix.gnu.org/33848>)
  *** (guix git) honors HTTP/HTTPS proxy settings for Git submodules
      (<https://issues.guix.gnu.org/44593>)
  *** Fix ‘guix substitute’ crash when interleaving lzip and gzip
      (<https://issues.guix.gnu.org/46967>)
  *** Fix GnuTLS memory corruption when used from Guile
      (<https://issues.guix.gnu.org/46330>)
  *** Update GnuTLS to 3.6.15, addressing a time-dependent test failure
      (<https://issues.guix.gnu.org/44559>)
  *** Booted system is fully protected from garbage collection
      (<https://issues.guix.gnu.org/46767>)
  *** Add MSDOS disk label support on UEFI systems
      (<https://issues.guix.gnu.org/47889>)
  *** Installer’s kmscon no longer uses up 100% CPU
      (<https://issues.guix.gnu.org/39341>)
  *** Git checkouts can be updated to the remote’s default HEAD
      (<https://issues.guix.gnu.org/45187>)
  *** ‘guix pull’ correctly displays early builds and downloads
      (<https://issues.guix.gnu.org/41930>)
  *** Fix OpenRC init scripts for ‘guix-daemon’
      (<https://issues.guix.gnu.org/46871>)
  *** Activate system when switching generations
      (<https://issues.guix.gnu.org/38884>)
  *** ‘guix environment -C’ preserves original mount flags
      (<https://issues.guix.gnu.org/46292>)
  *** Remove duplicates in profile transactions
      (<https://issues.guix.gnu.org/23874>)
  *** Fix sound problems with ALSA plugins on foreign distros
      (<https://issues.guix.gnu.org/40832>)

  ** Native language support

  *** Updated translations of the manual

  The manual is fully translated into French and German, 90% translated into
  Spanish, and has preliminary translations into Chinese, Brazilian Portuguese,
  and Russian.

  *** Update translations of the cookbook

  The cookbook is fully translated in French and German and has a preliminary
  translation into Korean.

  *** Updated translations of messages

  This version of Guix is fully translated in French, German, and Slovak; it has
  good translation into Brazilian Portuguese and Spanish, and preliminary
  translations in a dozen other languages.

  *** Translations now hosted on Fedora’s Weblate instance

  Translations are now handled at
  <https://translate.fedoraproject.org/projects/guix/guix/> (thanks, Fedora!).
  You can join to help improve translations in your native language of messages,
  documentation, package descriptions, and the web site.

Please report bugs to bug-guix@gnu.org
Join guix-devel@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release!

Maxim, on behalf of the Guix team.

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

Re: GNU Guix 1.3.0 released

[Paul Jewell]

On 12/05/2021 07:40, Maxim Cournoyer wrote:
> We are pleased to announce the release of GNU Guix 1.3.0!
>
>
> Maxim, on behalf of the Guix team.

Congratulations, and many thanks to everyone involved in making this happen!

Best regards,
Paul

Re: GNU Guix 1.3.0 released

[宋文武]

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

> We are pleased to announce the release of GNU Guix 1.3.0!
>
> This release corresponds to 8,300 commits over almost 6 months by 212
> people.  Support for the POWER9 platform is now offered as technological
> preview.  This release adds new features, refines the user experience
> and improves performance.  It also includes many new packages and
> services along bug fixes--see below for a list of changes.
>
> Read more about today’s announcement at:
>
>   https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released
>

Cheers!  Thank you, to everyone who make it possible!

Re: GNU Guix 1.3.0 released

[maxxcan--- via]

Thank you everyone. This project is the most.

El mié, 12 de may de 2021 a las 19:43, 宋文武 <iyzsong@outlook.com> 
escribió:
> Maxim Cournoyer <maxim.cournoyer@gmail.com 
> <mailto:maxim.cournoyer@gmail.com>> writes:
> 
>>  We are pleased to announce the release of GNU Guix 1.3.0!
>> 
>>  This release corresponds to 8,300 commits over almost 6 months by 
>> 212
>>  people.  Support for the POWER9 platform is now offered as 
>> technological
>>  preview.  This release adds new features, refines the user 
>> experience
>>  and improves performance.  It also includes many new packages and
>>  services along bug fixes--see below for a list of changes.
>> 
>>  Read more about today’s announcement at:
>> 
>>    <https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released>
>> 
> 
> Cheers!  Thank you, to everyone who make it possible!
> 

Re: GNU Guix 1.3.0 released

[Mathieu Othacehe]

Hey,

>> This release corresponds to 8,300 commits over almost 6 months by 212
>> people.  Support for the POWER9 platform is now offered as technological
>> preview.  This release adds new features, refines the user experience
>> and improves performance.  It also includes many new packages and
>> services along bug fixes--see below for a list of changes.

Congrats! It's amazing to see how much has been achieved in six
months. Special thanks to Ludo and Maxim for your dedication and hard
work that made this release possible :).

Mathieu

Re: GNU Guix 1.3.0 released

[Ludovic Courtès]

Hi!

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

> We are pleased to announce the release of GNU Guix 1.3.0!

Yay, congrats everyone!

Kudos Maxim for taking responsibility for the whole process!  Now you
know what can be improved :-) and I’m interested in helping make the
process smoother.

There’s no rush, but we can already start thinking about who’s turn is
next.  It’s great if it’s you, Maxim, but if another experienced hacker
is interested, please make yourself known!

Note also that we were “only” 3 weeks late thanks to the hard work of
zimoun and Leo early on keeping track of everything that needed to be
addressed.  If someone wants to propose a date for the next release and
take responsibility as “release keeper”, we’ll all welcome that!

Ludo’.

GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)

[Maxim Cournoyer]

Hello,

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

> Hi!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> We are pleased to announce the release of GNU Guix 1.3.0!
>
> Yay, congrats everyone!
>
> Kudos Maxim for taking responsibility for the whole process!  Now you
> know what can be improved :-) and I’m interested in helping make the
> process smoother.

Thanks :-).  It was nice to have the backing of the bug fixing squad and
your generous contributions in the release material write-up.  Thanks to
Julien Lepiller for their help and availability w.r.t. the translations.

> There’s no rush, but we can already start thinking about who’s turn is
> next.  It’s great if it’s you, Maxim, but if another experienced hacker
> is interested, please make yourself known!

I wouldn't mind to do it again; twice in a row seems like it may be a
bit fresh in my mind and enable me to do more refinements to the build
system.  I'd also be happy to mentor someone else to try their hand at
it.  I feel like rotation improves our processes, especially w.r.t. to
its documentation.

> Note also that we were “only” 3 weeks late thanks to the hard work of
> zimoun and Leo early on keeping track of everything that needed to be
> addressed.  If someone wants to propose a date for the next release and
> take responsibility as “release keeper”, we’ll all welcome that!

Yes, thank you Simon and Leo for the help with the release!  I felt less
lonely :-).  I've learned that producing a release can easily take 2-3
weeks even in good conditions (e.g., not many blockers to fix).  I'd
suggest anyone (myself included :-)) trying to meet the schedule to
seriously start trying to put out RCs a month before the planned release
date.

Perhaps we can aim for the next release mid-September (core-updates).
I'm not too sure of the status of core-updates right now, but last time
I worked on it was in a rather good state.

Thanks,

Maxim

Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)

[Vagrant Cascadian]

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

On 2021-05-16, Maxim Cournoyer wrote:
> Yes, thank you Simon and Leo for the help with the release!  I felt less
> lonely :-).  I've learned that producing a release can easily take 2-3
> weeks even in good conditions (e.g., not many blockers to fix).  I'd
> suggest anyone (myself included :-)) trying to meet the schedule to
> seriously start trying to put out RCs a month before the planned release
> date.

It would be nice to get a Release Candidate (or Pre Release?) out with
some time before the string freeze; it's easiest for me to do the
spelling/grammar/typo checks and fixes after the first RC tarball (as it
is basically just part of my packaging for Debian workflow), but was a
little disappointing to not be able to get such trivial fixes into the
release.

Alternately or additionally, setting up a "make dist" job on
ci.guix.gnu.org and publishing the resulting tarball somewhere would
allow me to check at arbitrary points during the release cycle and catch
things earlier.


live well, 
  vagrant

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

Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)

[Julien Lepiller]

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

I agree string freeze was way too long for this release. We entered string freeze one week before the planned release date, it got pushed by almost one month.

For next release, I think it would be better to enter string freeze along with rc1 or a bit later, but always at least give one week before release (so a late string freeze could delay release by a few days).

Le 16 mai 2021 12:02:38 GMT-04:00, Vagrant Cascadian <vagrant@debian.org> a écrit :
>On 2021-05-16, Maxim Cournoyer wrote:
>> Yes, thank you Simon and Leo for the help with the release!  I felt
>less
>> lonely :-).  I've learned that producing a release can easily take
>2-3
>> weeks even in good conditions (e.g., not many blockers to fix).  I'd
>> suggest anyone (myself included :-)) trying to meet the schedule to
>> seriously start trying to put out RCs a month before the planned
>release
>> date.
>
>It would be nice to get a Release Candidate (or Pre Release?) out with
>some time before the string freeze; it's easiest for me to do the
>spelling/grammar/typo checks and fixes after the first RC tarball (as
>it
>is basically just part of my packaging for Debian workflow), but was a
>little disappointing to not be able to get such trivial fixes into the
>release.
>
>Alternately or additionally, setting up a "make dist" job on
>ci.guix.gnu.org and publishing the resulting tarball somewhere would
>allow me to check at arbitrary points during the release cycle and
>catch
>things earlier.
>
>
>live well, 
>  vagrant

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

Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)

[zimoun]

Hi Maxim,

>> Note also that we were “only” 3 weeks late thanks to the hard work of
>> zimoun and Leo early on keeping track of everything that needed to be
>> addressed.  If someone wants to propose a date for the next release and
>> take responsibility as “release keeper”, we’ll all welcome that!
>
> Yes, thank you Simon and Leo for the help with the release!  I felt less
> lonely :-).  I've learned that producing a release can easily take 2-3
> weeks even in good conditions (e.g., not many blockers to fix).  I'd
> suggest anyone (myself included :-)) trying to meet the schedule to
> seriously start trying to put out RCs a month before the planned release
> date.

Thank you!  And thanks to all the people involved. :-)

For what it is worth, the anniversary dates seems good targets as
release dates:

 - April, 18th (init commit) 
 - November, 23rd (first announce)

Do you plan to keep a Release Bug open with all the blocking bugs?  Does
it help?  If yes, does it make sense to start now to add some or only ~2
months before the target?

> Perhaps we can aim for the next release mid-September (core-updates).
> I'm not too sure of the status of core-updates right now, but last time
> I worked on it was in a rather good state.

I remember a plot sent to guix-maintaainers about the number of grafts,
the core-updates merges and the release dates.  I am not sure it is
really interesting and it is worth to resend it, or maybe dumping the
Cuirass database to investigate a bit more.  Well, my point is the
core-updates merges and the release dates should be synchronized; say
target the core-updates for end of September, then the release for
November.  To me, this synchronisation makes senses because it
constraints the ~6months core-updates cycle and in the same time, the 2
releases per year.


Cheers,
simon

Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)

[Leo Famulari]

On Mon, May 17, 2021 at 02:55:39PM +0200, zimoun wrote:
> I remember a plot sent to guix-maintaainers about the number of grafts,
> the core-updates merges and the release dates.  I am not sure it is
> really interesting and it is worth to resend it, or maybe dumping the
> Cuirass database to investigate a bit more.  Well, my point is the
> core-updates merges and the release dates should be synchronized; say
> target the core-updates for end of September, then the release for
> November.  To me, this synchronisation makes senses because it
> constraints the ~6months core-updates cycle and in the same time, the 2
> releases per year.

I like this idea.

Re: GNU Guix 1.4.0 in September?

[Maxim Cournoyer]

Hi,

Leo Famulari <leo@famulari.name> writes:

> On Mon, May 17, 2021 at 02:55:39PM +0200, zimoun wrote:
>> I remember a plot sent to guix-maintaainers about the number of grafts,
>> the core-updates merges and the release dates.  I am not sure it is
>> really interesting and it is worth to resend it, or maybe dumping the
>> Cuirass database to investigate a bit more.  Well, my point is the
>> core-updates merges and the release dates should be synchronized; say
>> target the core-updates for end of September, then the release for
>> November.  To me, this synchronisation makes senses because it
>> constraints the ~6months core-updates cycle and in the same time, the 2
>> releases per year.
>
> I like this idea.

Me too, it makes sense.

Maxim

Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)

[Bengt Richter]

Hi all,

On +2021-05-17 10:43:36 -0400, Leo Famulari wrote:
> On Mon, May 17, 2021 at 02:55:39PM +0200, zimoun wrote:
> > I remember a plot sent to guix-maintaainers about the number of grafts,
> > the core-updates merges and the release dates.  I am not sure it is
> > really interesting and it is worth to resend it, or maybe dumping the
> > Cuirass database to investigate a bit more.  Well, my point is the
> > core-updates merges and the release dates should be synchronized; say
> > target the core-updates for end of September, then the release for
> > November.  To me, this synchronisation makes senses because it
> > constraints the ~6months core-updates cycle and in the same time, the 2
> > releases per year.
> 
> I like this idea.
> 

This sounds like planning activity.

Gnome has an app called planner ;-)

Would it make sense to discuss a way to put these rc- and other related goals
on a gantt chart?

Maybe even automate import from mailing list emails marked with e.g. [release-planning] in the subject
and one delimited markup region like
--8<---------------cut here---------------start------------->8---
planner-importable xml here
--8<---------------cut here---------------end--------------->8---

Discussion without triggering automated import would just leave
"[release-plannng]" out of the Subject: line, or have e.g. [release-discussion]
in the Subject: line.

Anyway, I thought a nice gantt chart .svg or .png or .pdf might be nice :)

Thoughts?

-- 
Regards,
Bengt Richter

Re: GNU Guix 1.4.0 in September?

[Maxim Cournoyer]

Hi Bengt,

Bengt Richter <bokr@bokr.com> writes:

[...]

> This sounds like planning activity.
>
> Gnome has an app called planner ;-)
>
> Would it make sense to discuss a way to put these rc- and other related goals
> on a gantt chart?
>
> Maybe even automate import from mailing list emails marked with e.g. [release-planning] in the subject
> and one delimited markup region like
>
> planner-importable xml here
>
> Discussion without triggering automated import would just leave
> "[release-plannng]" out of the Subject: line, or have e.g. [release-discussion]
> in the Subject: line.
>
> Anyway, I thought a nice gantt chart .svg or .png or .pdf might be nice :)
>
> Thoughts?

I won't stop you from implementing it, but to be honest, it seems
slightly over-engineered to me :-).  Tracking the tasks via blocking
issues in Debbugs worked well for the last iteration.

Thanks,

Maxim

Re: GNU Guix 1.4.0 in September?

[Ludovic Courtès]

Hi,

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

> Perhaps we can aim for the next release mid-September (core-updates).
> I'm not too sure of the status of core-updates right now, but last time
> I worked on it was in a rather good state.

Sounds like a plan!

We should start working on getting ‘core-updates’ merged real soon.  I’d
say it should be merged within a month or so, because it’s already been
a lot of time.

Ludo’.

Re: GNU Guix 1.4.0 in September?

[Maxim Cournoyer]

Hi Simon,

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

> Hi Maxim,
>
>>> Note also that we were “only” 3 weeks late thanks to the hard work of
>>> zimoun and Leo early on keeping track of everything that needed to be
>>> addressed.  If someone wants to propose a date for the next release and
>>> take responsibility as “release keeper”, we’ll all welcome that!
>>
>> Yes, thank you Simon and Leo for the help with the release!  I felt less
>> lonely :-).  I've learned that producing a release can easily take 2-3
>> weeks even in good conditions (e.g., not many blockers to fix).  I'd
>> suggest anyone (myself included :-)) trying to meet the schedule to
>> seriously start trying to put out RCs a month before the planned release
>> date.
>
> Thank you!  And thanks to all the people involved. :-)
>
> For what it is worth, the anniversary dates seems good targets as
> release dates:
>
>  - April, 18th (init commit) 
>  - November, 23rd (first announce)

Sounds good, if perhaps a bit too far?

> Do you plan to keep a Release Bug open with all the blocking bugs?  Does
> it help?  If yes, does it make sense to start now to add some or only ~2
> months before the target?

I think we can flag them as 'important' to start, and as the release
approach, we can add them as blocking if they haven't yet been fixed.
No strong feelings either way though.

>> Perhaps we can aim for the next release mid-September (core-updates).
>> I'm not too sure of the status of core-updates right now, but last time
>> I worked on it was in a rather good state.
>
> I remember a plot sent to guix-maintaainers about the number of grafts,
> the core-updates merges and the release dates.  I am not sure it is
> really interesting and it is worth to resend it, or maybe dumping the
> Cuirass database to investigate a bit more.

Perhaps I failed to see a trend or something, but I don't remember
coming out with a clearer insight about what we should change or adjust
from looking at those graphs.  Had I missed something?

> Well, my point is the core-updates merges and the release dates should
> be synchronized; say target the core-updates for end of September,
> then the release for November.  To me, this synchronisation makes
> senses because it constraints the ~6months core-updates cycle and in
> the same time, the 2 releases per year.

Makes sense, let's aim to do that!

Thanks,

Maxim

Re: GNU Guix 1.4.0 in September?

[Chris Marusich]

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

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

> Perhaps we can aim for the next release mid-September (core-updates).
> I'm not too sure of the status of core-updates right now, but last time
> I worked on it was in a rather good state.

I intend to try to get POWER9 working on core-updates before the next
release.  Hopefully the recent upgrade to GCC 10 will make it easier.

Anyone who wants to help with powerpc64le-linux is, of course, more than
welcome to coordinate and lend a hand!  I will be tagging bug reports
specific to powerpc64le-linux with the "powerpc64le-linux" usertag, for
the user "guix-devel@gnu.org".  You can see the open bugs tagged thusly
here:

https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix-devel@gnu.org

For details on usertags, start here:

https://lwn.net/Articles/150658/

-- 
Chris

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

Debbugs user tags

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> Anyone who wants to help with powerpc64le-linux is, of course, more than
> welcome to coordinate and lend a hand!  I will be tagging bug reports
> specific to powerpc64le-linux with the "powerpc64le-linux" usertag, for
> the user "guix-devel@gnu.org".  You can see the open bugs tagged thusly
> here:
>
> https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix-devel@gnu.org
>
> For details on usertags, start here:
>
> https://lwn.net/Articles/150658/

Should we add some text (and conventions?) to “Tracking Bugs and
Patches” in the manual about usertags?  Sounds like it could be useful.

Thanks,
Ludo’.

Re: Debbugs user tags

[Chris Marusich]

[-- Attachment #1.1: Type: text/plain, Size: 722 bytes --]

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

>> Anyone who wants to help with powerpc64le-linux is, of course, more than
>> welcome to coordinate and lend a hand!  I will be tagging bug reports
>> specific to powerpc64le-linux with the "powerpc64le-linux" usertag, for
>> the user "guix-devel@gnu.org".  You can see the open bugs tagged thusly
>> here:
>>
>> https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix-devel@gnu.org
>>
>> For details on usertags, start here:
>>
>> https://lwn.net/Articles/150658/
>
> Should we add some text (and conventions?) to “Tracking Bugs and
> Patches” in the manual about usertags?  Sounds like it could be useful.

How's this?

-- 
Chris

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-Document-the-use-of-Debbugs-usertags.patch --]
[-- Type: text/x-patch, Size: 4598 bytes --]

From f640132745b26b19bd163bc67482e8aea041881b Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Tue, 22 Jun 2021 19:44:18 -0700
Subject: [PATCH] Document the use of Debbugs usertags.

* doc/contributing.texi (Contributing): Update the short description of the
"Tracking Bugs and Patches" chapter in the menu.
(Tracking Bugs and Patches): Split this section into three new subsections,
titled "Debbugs", "Debbugs User Interfaces", and "Debbugs Usertags".  Of
these, only the "Debbugs Usertags" is actually new.
---
 doc/contributing.texi | 61 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 60 insertions(+), 1 deletion(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index e612ea7b23..6a287fe6a4 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -26,7 +26,7 @@ choice.
 * Packaging Guidelines::        Growing the distribution.
 * Coding Style::                Hygiene of the contributor.
 * Submitting Patches::          Share your work.
-* Tracking Bugs and Patches::   Using Debbugs.
+* Tracking Bugs and Patches::   Keeping it all organized.
 * Commit Access::               Pushing to the official repository.
 * Updating the Guix Package::   Updating the Guix package definition.
 * Translating Guix::            Make Guix speak your native language.
@@ -1223,6 +1223,18 @@ for more information.  You can install @command{git send-email} with
 @node Tracking Bugs and Patches
 @section Tracking Bugs and Patches
 
+This section describes how the Guix project tracks its bug reports and
+patch submissions.
+
+@menu
+* Debbugs:: The official bug and patch tracker.
+* Debbugs User Interfaces:: Ways to interact with Debbugs.
+* Debbugs Usertags:: Tag reports with custom labels.
+@end menu
+
+@node Debbugs
+@subsection Debbugs
+
 @cindex bug reports, tracking
 @cindex patch submissions, tracking
 @cindex issue tracking
@@ -1234,6 +1246,9 @@ email to @email{bug-guix@@gnu.org}, while patch submissions are filed
 against the @code{guix-patches} package by sending email to
 @email{guix-patches@@gnu.org} (@pxref{Submitting Patches}).
 
+@node Debbugs User Interfaces
+@subsection Debbugs User Interfaces
+
 A web interface (actually @emph{two} web interfaces!) are available to
 browse issues:
 
@@ -1271,6 +1286,50 @@ For example, to list all open issues on @code{guix-patches}, hit:
 @xref{Top,,, debbugs-ug, Debbugs User Guide}, for more information on
 this nifty tool!
 
+@node Debbugs Usertags
+@subsection Debbugs Usertags
+
+@cindex usertags, for debbugs
+@cindex Debbugs usertags
+Debbugs provides a feature called ``usertags'' that allows any user to
+tag any bug with an arbitrary label.  Bugs can be searched by usertag,
+so this is a handy way to organize bugs.@footnote{The list of usertags
+is public information, and anyone can modify any user's list of
+usertags, so keep that in mind if you choose to use this feature.}
+
+For example, to view all the bug reports (or patches, in the case of
+guix-patches) tagged with the usertag @code{powerpc64le-linux} for the
+user @code{guix-devel@@gnu.org}, open a URL like the following in a web
+browser:
+@url{https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix-devel@@gnu.org}
+
+For more information on how to use usertags, please refer to the
+documentation for Debbugs or the documentation for whatever tool you use
+to interact with Debbugs.
+
+In Guix, we are experimenting with usertags to keep track of
+architecture-specific issues.  To facilitate collaboration, all our
+usertags are associated with the single user @code{guix-devel@@gnu.org}.
+The following usertags currently exist for that user:
+
+@table @code
+
+@item powerpc64le-linux
+The purpose of this usertag is to make it easy to find the issues that
+matter most for the @code{powerpc64le-linux} system type.  Please assign
+this usertag to issues or patches that affect @code{powerpc64le-linux}
+but not other system types.  In addition, you may use it to identify
+issues that for some reason are particularly important for the
+@code{powerpc64le-linux} system type, even if the issue affects other
+system types, too.
+
+@end table
+
+If you're a committer and you want to add a usertag, just start using it
+with the @code{guix-devel@@gnu.org} user.  If the usertag proves useful
+to you, consider updating this section of the manual so that others will
+know what your usertag means.
+
 @node Commit Access
 @section Commit Access
 
-- 
2.30.2


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

Re: Debbugs user tags

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> From f640132745b26b19bd163bc67482e8aea041881b Mon Sep 17 00:00:00 2001
> From: Chris Marusich <cmmarusich@gmail.com>
> Date: Tue, 22 Jun 2021 19:44:18 -0700
> Subject: [PATCH] Document the use of Debbugs usertags.
>
> * doc/contributing.texi (Contributing): Update the short description of the
> "Tracking Bugs and Patches" chapter in the menu.
> (Tracking Bugs and Patches): Split this section into three new subsections,
> titled "Debbugs", "Debbugs User Interfaces", and "Debbugs Usertags".  Of
> these, only the "Debbugs Usertags" is actually new.

Wonderful!

> +++ b/doc/contributing.texi
> @@ -26,7 +26,7 @@ choice.
>  * Packaging Guidelines::        Growing the distribution.
>  * Coding Style::                Hygiene of the contributor.
>  * Submitting Patches::          Share your work.
> -* Tracking Bugs and Patches::   Using Debbugs.
> +* Tracking Bugs and Patches::   Keeping it all organized.

You probably have to adjust it in a second place (yeah…).

> +@menu
> +* Debbugs:: The official bug and patch tracker.
> +* Debbugs User Interfaces:: Ways to interact with Debbugs.
> +* Debbugs Usertags:: Tag reports with custom labels.
> +@end menu

‘M-x texinfo-make-menu’ or similar should indent it for you.  :-)

> +@node Debbugs
> +@subsection Debbugs

Maybe rename to “The Issue Tracker”, so as to not require knowledge of
what Debbugs is when skimming through the table of contents?

> +Debbugs provides a feature called ``usertags'' that allows any user to

@dfn{usertags}

> +In Guix, we are experimenting with usertags to keep track of
> +architecture-specific issues.  To facilitate collaboration, all our
> +usertags are associated with the single user @code{guix-devel@@gnu.org}.
> +The following usertags currently exist for that user:
> +
> +@table @code
> +
> +@item powerpc64le-linux
> +The purpose of this usertag is to make it easy to find the issues that
> +matter most for the @code{powerpc64le-linux} system type.  Please assign
> +this usertag to issues or patches that affect @code{powerpc64le-linux}
> +but not other system types.  In addition, you may use it to identify
> +issues that for some reason are particularly important for the
> +@code{powerpc64le-linux} system type, even if the issue affects other
> +system types, too.

Maybe we can already add ‘reproducibility’.

Otherwise LGTM, thank you!

Ludo’.

Re: Debbugs user tags

[Chris Marusich]

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

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

>> * doc/contributing.texi (Contributing): Update the short description of the
>> "Tracking Bugs and Patches" chapter in the menu.
>> (Tracking Bugs and Patches): Split this section into three new subsections,
>> titled "Debbugs", "Debbugs User Interfaces", and "Debbugs Usertags".  Of
>> these, only the "Debbugs Usertags" is actually new.
>
> Wonderful!

I'm glad you like it!  :-)

>> +++ b/doc/contributing.texi
>> @@ -26,7 +26,7 @@ choice.
>>  * Packaging Guidelines::        Growing the distribution.
>>  * Coding Style::                Hygiene of the contributor.
>>  * Submitting Patches::          Share your work.
>> -* Tracking Bugs and Patches::   Using Debbugs.
>> +* Tracking Bugs and Patches::   Keeping it all organized.
>
> You probably have to adjust it in a second place (yeah…).

Other references to "Tracking Bugs and Patches" do exist, but they don't
mention "Using Debbugs," so I don't think they need to be updated.

>> +@menu
>> +* Debbugs:: The official bug and patch tracker.
>> +* Debbugs User Interfaces:: Ways to interact with Debbugs.
>> +* Debbugs Usertags:: Tag reports with custom labels.
>> +@end menu
>
> ‘M-x texinfo-make-menu’ or similar should indent it for you.  :-)

You learn something new every day!

>> +@node Debbugs
>> +@subsection Debbugs
>
> Maybe rename to “The Issue Tracker”, so as to not require knowledge of
> what Debbugs is when skimming through the table of contents?

Sounds good.  I just changed the first subsection, so now it looks like
this:

--8<---------------cut here---------------start------------->8---
@menu
* The Issue Tracker::           The official bug and patch tracker.
* Debbugs User Interfaces::     Ways to interact with Debbugs.
* Debbugs Usertags::            Tag reports with custom labels.
@end menu
--8<---------------cut here---------------end--------------->8---

This seems fine, since the first subsection introduces Debbugs.

>> +Debbugs provides a feature called ``usertags'' that allows any user to
>
> @dfn{usertags}

OK.

>> +In Guix, we are experimenting with usertags to keep track of
>> +architecture-specific issues.  To facilitate collaboration, all our
>> +usertags are associated with the single user @code{guix-devel@@gnu.org}.
>> +The following usertags currently exist for that user:
>> +
>> +@table @code
>> +
>> +@item powerpc64le-linux
>> +The purpose of this usertag is to make it easy to find the issues that
>> +matter most for the @code{powerpc64le-linux} system type.  Please assign
>> +this usertag to issues or patches that affect @code{powerpc64le-linux}
>> +but not other system types.  In addition, you may use it to identify
>> +issues that for some reason are particularly important for the
>> +@code{powerpc64le-linux} system type, even if the issue affects other
>> +system types, too.
>
> Maybe we can already add ‘reproducibility’.
>
> Otherwise LGTM, thank you!
>
> Ludo’.

I added this text:

--8<---------------cut here---------------start------------->8---
@item reproducibility
For issues related to reproducibility.  For example, it would be
appropriate to assign this usertag to a bug report for a package that
fails to build reproducibly.
--8<---------------cut here---------------end--------------->8---

I've gone ahead and committed these changes in
3c86372e36cecaed1ad55675ce32a14b972406bf.  I verified that the Texinfo
manual could be built, and that when viewing it in Info, it looks as
expected.

Please let me know if you'd like any further changes; I'd be happy to
make them.

-- 
Chris

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

Re: GNU Guix 1.4.0 in September?

[Maxim Cournoyer]

Hello Chris,

Chris Marusich <cmmarusich@gmail.com> writes:

[...]

> I intend to try to get POWER9 working on core-updates before the next
> release.  Hopefully the recent upgrade to GCC 10 will make it easier.

Neat!

> Anyone who wants to help with powerpc64le-linux is, of course, more than
> welcome to coordinate and lend a hand!  I will be tagging bug reports
> specific to powerpc64le-linux with the "powerpc64le-linux" usertag, for
> the user "guix-devel@gnu.org".  You can see the open bugs tagged thusly
> here:

I'm rather late to the party, but may I suggest simply using 'guix' as
the user?  It was made possible to do so as the result of me bothering
the very nice GNU people maintaining emacs-debbugs / GNU debbugs
instance (there used to be a limitation for 5 letters+ projects so that
'emacs' would be usable as a user).

C-h f debbugs-gnu-usertags also has the docstring "List all user tags
for USERS, which is \(\"emacs\"\) by default." and later the input text
"Package name(s) or email address: ", which suggest 'guix' should be
valid.

Thanks for this nice initiatives of yours!

Maxim

Debbugs Usertags - which user to use? (Was: Re: GNU Guix 1.4.0 in September?)

[Chris Marusich]

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

Hi Maxim,

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

> Hello Chris,
>
> Chris Marusich <cmmarusich@gmail.com> writes:
>
> [...]
>
>> I intend to try to get POWER9 working on core-updates before the next
>> release.  Hopefully the recent upgrade to GCC 10 will make it easier.
>
> Neat!
>
>> Anyone who wants to help with powerpc64le-linux is, of course, more than
>> welcome to coordinate and lend a hand!  I will be tagging bug reports
>> specific to powerpc64le-linux with the "powerpc64le-linux" usertag, for
>> the user "guix-devel@gnu.org".  You can see the open bugs tagged thusly
>> here:
>
> I'm rather late to the party, but may I suggest simply using 'guix' as
> the user?  It was made possible to do so as the result of me bothering
> the very nice GNU people maintaining emacs-debbugs / GNU debbugs
> instance (there used to be a limitation for 5 letters+ projects so that
> 'emacs' would be usable as a user).
>
> C-h f debbugs-gnu-usertags also has the docstring "List all user tags
> for USERS, which is \(\"emacs\"\) by default." and later the input text
> "Package name(s) or email address: ", which suggest 'guix' should be
> valid.
>
> Thanks for this nice initiatives of yours!
>
> Maxim

Yes, my understanding is that the user "guix" would also work.

I think it would be fine to use the user "guix" instead of
"guix-devel@gnu.org".  Perhaps it would have the added benefit of
eliminating any possible risk of accidentally spamming the email list,
although so far that hasn't happened.

To give others time to voice their opinion, I'll plan to update the
manual to suggest using the "guix" user about 2 weeks from now.  At that
time, I'll also re-tag the handful of issues currently tagged with the
powerpc64le-linux usertag associated with the guix-devel@gnu.org user.

-- 
Chris

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

Re: Debbugs Usertags - which user to use?

[Maxim Cournoyer]

Hello,

Chris Marusich <cmmarusich@gmail.com> writes:

[...]

> Yes, my understanding is that the user "guix" would also work.
>
> I think it would be fine to use the user "guix" instead of
> "guix-devel@gnu.org".  Perhaps it would have the added benefit of
> eliminating any possible risk of accidentally spamming the email list,
> although so far that hasn't happened.
>
> To give others time to voice their opinion, I'll plan to update the
> manual to suggest using the "guix" user about 2 weeks from now.  At that
> time, I'll also re-tag the handful of issues currently tagged with the
> powerpc64le-linux usertag associated with the guix-devel@gnu.org user.

Sounds good to me!

Thank you,

Maxim

Re: Debbugs Usertags - which user to use?

[Chris Marusich]

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

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

> Hello,
>
> Chris Marusich <cmmarusich@gmail.com> writes:
>
> [...]
>
>> Yes, my understanding is that the user "guix" would also work.
>>
>> I think it would be fine to use the user "guix" instead of
>> "guix-devel@gnu.org".  Perhaps it would have the added benefit of
>> eliminating any possible risk of accidentally spamming the email list,
>> although so far that hasn't happened.
>>
>> To give others time to voice their opinion, I'll plan to update the
>> manual to suggest using the "guix" user about 2 weeks from now.  At that
>> time, I'll also re-tag the handful of issues currently tagged with the
>> powerpc64le-linux usertag associated with the guix-devel@gnu.org user.
>
> Sounds good to me!
>
> Thank you,
>
> Maxim

Done in 586136d12745eeddccd05d80dbd21959595b45d1.

-- 
Chris

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

Re: Debbugs Usertags - which user to use?

[Maxim Cournoyer]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hello,
>>
>> Chris Marusich <cmmarusich@gmail.com> writes:
>>
>> [...]
>>
>>> Yes, my understanding is that the user "guix" would also work.
>>>
>>> I think it would be fine to use the user "guix" instead of
>>> "guix-devel@gnu.org".  Perhaps it would have the added benefit of
>>> eliminating any possible risk of accidentally spamming the email list,
>>> although so far that hasn't happened.
>>>
>>> To give others time to voice their opinion, I'll plan to update the
>>> manual to suggest using the "guix" user about 2 weeks from now.  At that
>>> time, I'll also re-tag the handful of issues currently tagged with the
>>> powerpc64le-linux usertag associated with the guix-devel@gnu.org user.
>>
>> Sounds good to me!
>>
>> Thank you,
>>
>> Maxim
>
> Done in 586136d12745eeddccd05d80dbd21959595b45d1.

Thank you!

Maxim