preparing the next release v0.15.0

preparing the next release v0.15.0

[Ricardo Wurmus]

Hi Guix,

all of us have been very busy fixing bugs, adding great new features,
adding packages, and managing core-updates/staging.  In fact, we’ve done
so much that people installing version 0.14.0 would really miss out on a
couple of important changes.  (For example, they wouldn’t even be able
to update to the latest version directly with “guix pull”.)

It’s about time we make another release.  Let’s make a plan!

Here are a bunch of things that we should look into:

* Outstanding patches.  There are many patches in the queue at
  guix-patches[1] that we should go through, comment on, and/or apply
  before the release.  Who would like to join a task force to do that
  together?  Let’s pick 5 patches each and review them so that we can
  either comment to ask for changes or to apply them.

  [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches

* breakage since the last core-updates merge.  Since the long overdue
  merge of the “core-updates” branch we have a few serious problems on
  i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
  lead an effort to investigate and fix these problems?  (Note: you
  obviously don’t need to fix them yourself, just keep track of these
  things and coordinate with others who investigate them.)

* collecting new features and big changes in NEWS.  The NEWS file
  already lists some of the changes that the next release would provide
  compared to 0.14.0, but we all know that there are more.  Who would
  like to take charge of the NEWS file?  This involves asking people for
  changes they would really like to be mentioned and coordinating with
  other volunteers to search through all commits since v0.14.0 to find
  noteworthy changes.

* Finding a date.  Some of the fixes that need to be included may have
  to end up on core-updates.  According to my calendar core-updates will
  be frozen on <2018-08-06 Mon> and be merged on <2018-08-20 Mon> at the
  latest.  That’s a little late, so if we can solve problems on the
  master branch with architecture-specific workarounds that don’t result
  in rebuilding the world (in addition to proper fixes on core-updates)
  that would be best.  What do you think: is July 27 (2018) realistic?

Did I miss anything?  Who wants to help?
Your comments are very welcome!

--
Ricardo

Re: preparing the next release v0.15.0

[Pjotr Prins]

Can we aim for a v1.0 release? At least for the package manager? I am
facing people that say Guix is not mature and therefore insecure and
therefore they can justifiably ignore my pleas for installation
without even looking.

I think any outstanding features can be projected on later realeases.

GuixSD can have its own release version.

Pj.

Re: preparing the next release v0.15.0

[Ricardo Wurmus]

Hi Pjotr,

> Can we aim for a v1.0 release? At least for the package manager? I am
> facing people that say Guix is not mature and therefore insecure and
> therefore they can justifiably ignore my pleas for installation
> without even looking.

I would like to leave 1.0 for the future.

Things that I’d like to see in 1.0 include a new manifest format that
records more information about the version of Guix, retiring of
GUIX_PACKAGE_PATH, and more.

--
Ricardo

Re: preparing the next release v0.15.0

[Pierre Neidhardt]

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


Ricardo Wurmus <rekado@elephly.net> writes:

> retiring of GUIX_PACKAGE_PATH, and more.

What alternative do you have in mind?

--
Pierre Neidhardt

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

Re: preparing the next release v0.15.0

[Ludovic Courtès]

Hi!

Ricardo Wurmus <rekado@elephly.net> skribis:

>> Can we aim for a v1.0 release? At least for the package manager? I am
>> facing people that say Guix is not mature and therefore insecure and
>> therefore they can justifiably ignore my pleas for installation
>> without even looking.
>
> I would like to leave 1.0 for the future.
>
> Things that I’d like to see in 1.0 include a new manifest format that
> records more information about the version of Guix, retiring of
> GUIX_PACKAGE_PATH, and more.

Ditto.  In terms of programming effort, we’re very close to what we’ve
been targeting for 1.0.

Ludo’.

Re: preparing the next release v0.15.0

[Clément Lassieur]

Hi Pjotr,

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> Can we aim for a v1.0 release? At least for the package manager? I am
> facing people that say Guix is not mature and therefore insecure and
> therefore they can justifiably ignore my pleas for installation
> without even looking.
>
> I think any outstanding features can be projected on later realeases.
>
> GuixSD can have its own release version.
>
> Pj.

I think we need https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602 to
be fixed.

Also, in the ROADMAP file, there is a "Features schedules for 1.0"
section.

Clément

Re: preparing the next release v0.15.0

[Ludovic Courtès]

Hello!

Clément Lassieur <clement@lassieur.org> skribis:

> I think we need https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602 to
> be fixed.

Done.   \o/

With Guile 2.2.4 now released, we can go ahead with 0.15.  Could people
build the ISO installation image and give it a try:

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

and then boot the resulting image (you can do that in QEMU if you
prefer), and follow the instructions.

Likewise, tests of the binary Guix tarball would be welcome.  You can
build it with:

  make guix-binary.x86_64-linux.tar.xz

For the record, some of the items Ricardo listed are not entirely
addressed either (quoting Ricardo’s previous message):

  * Outstanding patches.  There are many patches in the queue at
    guix-patches[1] that we should go through, comment on, and/or apply
    before the release.  Who would like to join a task force to do that
    together?  Let’s pick 5 patches each and review them so that we can
    either comment to ask for changes or to apply them.

    [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches

  * breakage since the last core-updates merge.  Since the long overdue
    merge of the “core-updates” branch we have a few serious problems on
    i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
    lead an effort to investigate and fix these problems?  (Note: you
    obviously don’t need to fix them yourself, just keep track of these
    things and coordinate with others who investigate them.)

  * collecting new features and big changes in NEWS.  The NEWS file
    already lists some of the changes that the next release would provide
    compared to 0.14.0, but we all know that there are more.  Who would
    like to take charge of the NEWS file?  This involves asking people for
    changes they would really like to be mentioned and coordinating with
    other volunteers to search through all commits since v0.14.0 to find
    noteworthy changes.

If we all focus on this, we could release by the end of the week or
beginning of next week.  Let’s do that!  :-)

Ludo’.

Re: preparing the next release v0.15.0

[Efraim Flashner]

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

On Mon, Jul 02, 2018 at 11:44:42AM +0200, Ludovic Courtès wrote:
> Hello!
> 
> Clément Lassieur <clement@lassieur.org> skribis:
> 
> > I think we need https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602 to
> > be fixed.
> 
> Done.   \o/
> 
> With Guile 2.2.4 now released, we can go ahead with 0.15.  Could people
> build the ISO installation image and give it a try:
> 
>   guix system disk-image --file-system-type=iso9660 gnu/system/install.scm

This fails (as expected) on aarch64-linux.

> 
> and then boot the resulting image (you can do that in QEMU if you
> prefer), and follow the instructions.
> 
> Likewise, tests of the binary Guix tarball would be welcome.  You can
> build it with:
> 
>   make guix-binary.x86_64-linux.tar.xz
> 

make guix-binary.aarch64-linux.tar.xz works as exptected



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

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

Re: preparing the next release v0.15.0

[Ludovic Courtès]

Hello!

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

> make guix-binary.aarch64-linux.tar.xz works as exptected

Great, thanks for checking!

BTW, did “we” fix access to the OverDrive by berlin.guixsd.org?

In other news, these installation tests pass for me, as of
a51cf16031c974ffa238e5dd9ced32f0d68c9227, on x86_64:

  make check-system TESTS="installed-os iso-image-installer encrypted-root-os"

I think I’ll create the ‘version-0.15’ branch real soon, so we can have
some stability in the next few days.

Ludo’.

Re: preparing the next release v0.15.0

[Ricardo Wurmus]

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

> BTW, did “we” fix access to the OverDrive by berlin.guixsd.org?

I opened a ticket to have the firewall rules adjusted but the network
security person who usually does these things is currently out sick.
Looks like it’s going to take a little longer, unfortunately.

(I didn’t yet get around to reconfiguring some build nodes to use qemu
to build for other architectures, but it’s on my list.)

--
Ricardo

Re: preparing the next release v0.15.0

[Ludovic Courtès]

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

> In other news, these installation tests pass for me, as of
> a51cf16031c974ffa238e5dd9ced32f0d68c9227, on x86_64:

All of these pass at this commit:

PASS: /gnu/store/rdaib0mw3r81h1d87kv669z9wd49072s-installed-os
PASS: /gnu/store/9wzidlrcv38rspvai26k62h64ba1dclf-separate-home-os
PASS: /gnu/store/vjd7q1sxf383d0gn5hhhraqlh7qmjldz-btrfs-root-os
PASS: /gnu/store/2p4vfrfxxp57n74wz9288q8zv2sgmzfw-iso-image-installer
PASS: /gnu/store/7wv54d8abkl7l1mifwfwa0za0ypf5r9l-raid-root-os
PASS: /gnu/store/kj85ns1kymx9g2a12cr85h955bsh3ssx-encrypted-root-os

Ludo’.

Re: preparing the next release v0.15.0

[Nils Gillmann]

Ludovic Courtès transcribed 2.1K bytes:
> Hello!
> 
> Clément Lassieur <clement@lassieur.org> skribis:
> 
> > I think we need https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602 to
> > be fixed.
> 
> Done.   \o/
> 
> With Guile 2.2.4 now released, we can go ahead with 0.15.  Could people
> build the ISO installation image and give it a try:
> 
>   guix system disk-image --file-system-type=iso9660 gnu/system/install.scm
> 
> and then boot the resulting image (you can do that in QEMU if you
> prefer), and follow the instructions.
> 
> Likewise, tests of the binary Guix tarball would be welcome.  You can
> build it with:
> 
>   make guix-binary.x86_64-linux.tar.xz
> 
> For the record, some of the items Ricardo listed are not entirely
> addressed either (quoting Ricardo’s previous message):
> 
>   * Outstanding patches.  There are many patches in the queue at
>     guix-patches[1] that we should go through, comment on, and/or apply
>     before the release.  Who would like to join a task force to do that
>     together?  Let’s pick 5 patches each and review them so that we can
>     either comment to ask for changes or to apply them.
> 
>     [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches
> 
>   * breakage since the last core-updates merge.  Since the long overdue
>     merge of the “core-updates” branch we have a few serious problems on
>     i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
>     lead an effort to investigate and fix these problems?  (Note: you
>     obviously don’t need to fix them yourself, just keep track of these
>     things and coordinate with others who investigate them.)

mysql is borked, as well as rust, if nothing changes in the last commits.
rust does not really matter since we do not have many depending packages
for it.
Mysql is more grave.

Any takers on mysql?

>   * collecting new features and big changes in NEWS.  The NEWS file
>     already lists some of the changes that the next release would provide
>     compared to 0.14.0, but we all know that there are more.  Who would
>     like to take charge of the NEWS file?  This involves asking people for
>     changes they would really like to be mentioned and coordinating with
>     other volunteers to search through all commits since v0.14.0 to find
>     noteworthy changes.
> 
> If we all focus on this, we could release by the end of the week or
> beginning of next week.  Let’s do that!  :-)

I could contribute some time on the NEWS file tomorrow.

> Ludo’.
> 

Re: preparing the next release v0.15.0

[Ludovic Courtès]

Hello!

The plan looks good to me!

Ricardo Wurmus <rekado@elephly.net> skribis:

> * breakage since the last core-updates merge.  Since the long overdue
>   merge of the “core-updates” branch we have a few serious problems on
>   i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
>   lead an effort to investigate and fix these problems?  (Note: you
>   obviously don’t need to fix them yourself, just keep track of these
>   things and coordinate with others who investigate them.)
>
> * collecting new features and big changes in NEWS.  The NEWS file
>   already lists some of the changes that the next release would provide
>   compared to 0.14.0, but we all know that there are more.  Who would
>   like to take charge of the NEWS file?  This involves asking people for
>   changes they would really like to be mentioned and coordinating with
>   other volunteers to search through all commits since v0.14.0 to find
>   noteworthy changes.

Agreed with all this.  :-)

> * Finding a date.  Some of the fixes that need to be included may have
>   to end up on core-updates.  According to my calendar core-updates will
>   be frozen on <2018-08-06 Mon> and be merged on <2018-08-20 Mon> at the
>   latest.  That’s a little late, so if we can solve problems on the
>   master branch with architecture-specific workarounds that don’t result
>   in rebuilding the world (in addition to proper fixes on core-updates)
>   that would be best.  What do you think: is July 27 (2018) realistic?

I would prefer an earlier date even, perhaps around June 30.

WDYT?

Thanks,
Ludo’.

Re: preparing the next release v0.15.0

[Ricardo Wurmus]

Hi Ludo,

> The plan looks good to me!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> * breakage since the last core-updates merge.  Since the long overdue
>>   merge of the “core-updates” branch we have a few serious problems on
>>   i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
>>   lead an effort to investigate and fix these problems?  (Note: you
>>   obviously don’t need to fix them yourself, just keep track of these
>>   things and coordinate with others who investigate them.)
>>
>> * collecting new features and big changes in NEWS.  The NEWS file
>>   already lists some of the changes that the next release would provide
>>   compared to 0.14.0, but we all know that there are more.  Who would
>>   like to take charge of the NEWS file?  This involves asking people for
>>   changes they would really like to be mentioned and coordinating with
>>   other volunteers to search through all commits since v0.14.0 to find
>>   noteworthy changes.
>
> Agreed with all this.  :-)

Excellent!  Now we just need volunteers who would like to help with
these tasks :)

I’d like to reiterate that none of these tasks should be done by one
person alone, but we do need someone for each task to keep track of
progress or to report on hurdles.  So if anyone would like to help out,
please do respond here.

>> * Finding a date.  Some of the fixes that need to be included may have
>>   to end up on core-updates.  According to my calendar core-updates will
>>   be frozen on <2018-08-06 Mon> and be merged on <2018-08-20 Mon> at the
>>   latest.  That’s a little late, so if we can solve problems on the
>>   master branch with architecture-specific workarounds that don’t result
>>   in rebuilding the world (in addition to proper fixes on core-updates)
>>   that would be best.  What do you think: is July 27 (2018) realistic?
>
> I would prefer an earlier date even, perhaps around June 30.

June 30 sounds good to me.

--
Ricardo

Re: preparing the next release v0.15.0

[Ricardo Wurmus]

Hi Guix,

I wrote almost 6 days ago:

> Here are a bunch of things that we should look into:
>
> * Outstanding patches.  There are many patches in the queue at
>   guix-patches[1] that we should go through, comment on, and/or apply
>   before the release.  Who would like to join a task force to do that
>   together?  Let’s pick 5 patches each and review them so that we can
>   either comment to ask for changes or to apply them.
>
>   [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches
>
> * breakage since the last core-updates merge.  Since the long overdue
>   merge of the “core-updates” branch we have a few serious problems on
>   i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
>   lead an effort to investigate and fix these problems?  (Note: you
>   obviously don’t need to fix them yourself, just keep track of these
>   things and coordinate with others who investigate them.)
>
> * collecting new features and big changes in NEWS.  The NEWS file
>   already lists some of the changes that the next release would provide
>   compared to 0.14.0, but we all know that there are more.  Who would
>   like to take charge of the NEWS file?  This involves asking people for
>   changes they would really like to be mentioned and coordinating with
>   other volunteers to search through all commits since v0.14.0 to find
>   noteworthy changes.
>
[…]
> Did I miss anything?  Who wants to help?

We aim for a release on June 30, 2018.  Unfortunately, so far nobody has
come forward to help us coordinate one of these three tasks.

Any volunteers?

--
Ricardo

Re: preparing the next release v0.15.0

[Pierre Neidhardt]

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


I'd be happy to help unfortunately this month is hectic for me.
Had it been July or August I would have been more free.  Sorry :(

-- 
Pierre Neidhardt

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

Re: preparing the next release v0.15.0

[Kei Kebreau]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Guix,
>
> I wrote almost 6 days ago:
>
>> Here are a bunch of things that we should look into:
>>
>> * Outstanding patches.  There are many patches in the queue at
>>   guix-patches[1] that we should go through, comment on, and/or apply
>>   before the release.  Who would like to join a task force to do that
>>   together?  Let’s pick 5 patches each and review them so that we can
>>   either comment to ask for changes or to apply them.
>>
>>   [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches
>>
>> * breakage since the last core-updates merge.  Since the long overdue
>>   merge of the “core-updates” branch we have a few serious problems on
>>   i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
>>   lead an effort to investigate and fix these problems?  (Note: you
>>   obviously don’t need to fix them yourself, just keep track of these
>>   things and coordinate with others who investigate them.)
>>
>> * collecting new features and big changes in NEWS.  The NEWS file
>>   already lists some of the changes that the next release would provide
>>   compared to 0.14.0, but we all know that there are more.  Who would
>>   like to take charge of the NEWS file?  This involves asking people for
>>   changes they would really like to be mentioned and coordinating with
>>   other volunteers to search through all commits since v0.14.0 to find
>>   noteworthy changes.
>>
> […]
>> Did I miss anything?  Who wants to help?
>
> We aim for a release on June 30, 2018.  Unfortunately, so far nobody has
> come forward to help us coordinate one of these three tasks.
>
> Any volunteers?
>
> --
> Ricardo

I suppose I could give working on the NEWS file a shot. If I have my
schedule right, I can start work on it within the next 24 hours.

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

Re: preparing the next release v0.15.0

[Gábor Boskovits]

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

Ricardo Wurmus <rekado@elephly.net> ezt írta (időpont: 2018. jún. 19., K,
0:17):

> Hi Guix,
>
> I wrote almost 6 days ago:
>
> > Here are a bunch of things that we should look into:
> >
> > * Outstanding patches.  There are many patches in the queue at
> >   guix-patches[1] that we should go through, comment on, and/or apply
> >   before the release.  Who would like to join a task force to do that
> >   together?  Let’s pick 5 patches each and review them so that we can
> >   either comment to ask for changes or to apply them.
>

This week I'm on vacation. I can start helping with the patches the next
week.
Are there any to priority ones?



> >
> >   [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches
> >
> > * breakage since the last core-updates merge.  Since the long overdue
> >   merge of the “core-updates” branch we have a few serious problems on
> >   i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
> >   lead an effort to investigate and fix these problems?  (Note: you
> >   obviously don’t need to fix them yourself, just keep track of these
> >   things and coordinate with others who investigate them.)
> >
> > * collecting new features and big changes in NEWS.  The NEWS file
> >   already lists some of the changes that the next release would provide
> >   compared to 0.14.0, but we all know that there are more.  Who would
> >   like to take charge of the NEWS file?  This involves asking people for
> >   changes they would really like to be mentioned and coordinating with
> >   other volunteers to search through all commits since v0.14.0 to find
> >   noteworthy changes.
> >
> […]
> > Did I miss anything?  Who wants to help?
>
> We aim for a release on June 30, 2018.  Unfortunately, so far nobody has
> come forward to help us coordinate one of these three tasks.
>
> Any volunteers?
>
> --
> Ricardo
>
>
>

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

Re: preparing the next release v0.15.0

[Marius Bakke]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Guix,
>
> I wrote almost 6 days ago:
>
>> Here are a bunch of things that we should look into:
>>
>> * Outstanding patches.  There are many patches in the queue at
>>   guix-patches[1] that we should go through, comment on, and/or apply
>>   before the release.  Who would like to join a task force to do that
>>   together?  Let’s pick 5 patches each and review them so that we can
>>   either comment to ask for changes or to apply them.
>>
>>   [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches
>>
>> * breakage since the last core-updates merge.  Since the long overdue
>>   merge of the “core-updates” branch we have a few serious problems on
>>   i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
>>   lead an effort to investigate and fix these problems?  (Note: you
>>   obviously don’t need to fix them yourself, just keep track of these
>>   things and coordinate with others who investigate them.)
>>
>> * collecting new features and big changes in NEWS.  The NEWS file
>>   already lists some of the changes that the next release would provide
>>   compared to 0.14.0, but we all know that there are more.  Who would
>>   like to take charge of the NEWS file?  This involves asking people for
>>   changes they would really like to be mentioned and coordinating with
>>   other volunteers to search through all commits since v0.14.0 to find
>>   noteworthy changes.
>>
> […]
>> Did I miss anything?  Who wants to help?
>
> We aim for a release on June 30, 2018.  Unfortunately, so far nobody has
> come forward to help us coordinate one of these three tasks.

Hello!

Thanks for this writeup.  I live a somewhat nomadic lifestyle at the
moment, and recently my phone was stolen, so I'm only online very
sporadically.

There is one bug I'll try to fix before the release: when doing an EFI
install, the ESP must be mounted at "/boot/efi" on the live system,
instead of relative to the mounted system (e.g. "/mnt/boot/efi").  This
is a regression since 0.13.

On the NEWS side, here is what springs to mind:

* `guix weather` now reports CI statistics
* Guix will give hints for how to resolve common configuration errors
* RHEL6 systems are again supported
* Reproducibility improvements all around
* Lots of new supported AArch64 boards
* Packages can specify that some CVEs don't apply to them
* `guix pack --relocatable` :-)

Others?

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

Re: preparing the next release v0.15.0

[Julien Lepiller]

Le 2018-06-19 14:36, Marius Bakke a écrit :
> Ricardo Wurmus <rekado@elephly.net> writes:
> 
>> Hi Guix,
>> 
>> I wrote almost 6 days ago:
>> 
>>> Here are a bunch of things that we should look into:
>>> 
>>> * Outstanding patches.  There are many patches in the queue at
>>>   guix-patches[1] that we should go through, comment on, and/or apply
>>>   before the release.  Who would like to join a task force to do that
>>>   together?  Let’s pick 5 patches each and review them so that we can
>>>   either comment to ask for changes or to apply them.
>>> 
>>>   [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches
>>> 
>>> * breakage since the last core-updates merge.  Since the long overdue
>>>   merge of the “core-updates” branch we have a few serious problems 
>>> on
>>>   i686 (e.g. the gst-plugins-base package) and armhf.  Who would like 
>>> to
>>>   lead an effort to investigate and fix these problems?  (Note: you
>>>   obviously don’t need to fix them yourself, just keep track of these
>>>   things and coordinate with others who investigate them.)
>>> 
>>> * collecting new features and big changes in NEWS.  The NEWS file
>>>   already lists some of the changes that the next release would 
>>> provide
>>>   compared to 0.14.0, but we all know that there are more.  Who would
>>>   like to take charge of the NEWS file?  This involves asking people 
>>> for
>>>   changes they would really like to be mentioned and coordinating 
>>> with
>>>   other volunteers to search through all commits since v0.14.0 to 
>>> find
>>>   noteworthy changes.
>>> 
>> […]
>>> Did I miss anything?  Who wants to help?
>> 
>> We aim for a release on June 30, 2018.  Unfortunately, so far nobody 
>> has
>> come forward to help us coordinate one of these three tasks.
> 
> Hello!
> 
> Thanks for this writeup.  I live a somewhat nomadic lifestyle at the
> moment, and recently my phone was stolen, so I'm only online very
> sporadically.
> 
> There is one bug I'll try to fix before the release: when doing an EFI
> install, the ESP must be mounted at "/boot/efi" on the live system,
> instead of relative to the mounted system (e.g. "/mnt/boot/efi").  This
> is a regression since 0.13.
> 
> On the NEWS side, here is what springs to mind:
> 
> * `guix weather` now reports CI statistics
> * Guix will give hints for how to resolve common configuration errors
> * RHEL6 systems are again supported
> * Reproducibility improvements all around
> * Lots of new supported AArch64 boards
> * Packages can specify that some CVEs don't apply to them
> * `guix pack --relocatable` :-)
> 
> Others?

* guix manual can now be translated and is partially translated into 
French

:)

Re: preparing the next release v0.15.0

[swedebugia]

On June 19, 2018 2:48:49 PM GMT+02:00, Julien Lepiller <julien@lepiller.eu> wrote:
>Le 2018-06-19 14:36, Marius Bakke a écrit :
>> Ricardo Wurmus <rekado@elephly.net> writes:

... Snip... 

>> 
>> On the NEWS side, here is what springs to mind:
>> 
>> * `guix weather` now reports CI statistics
>> * Guix will give hints for how to resolve common configuration errors
>> * RHEL6 systems are again supported
>> * Reproducibility improvements all around
>> * Lots of new supported AArch64 boards
>> * Packages can specify that some CVEs don't apply to them
>> * `guix pack --relocatable` :-)
>> 
>> Others?
>
>* guix manual can now be translated and is partially translated into 
>French 

* new guix pull which builds guix in a profile with roll-back functionality, common build options and with the commit ID as the version string if guix pull has been run since installation. 

* now possible to compile guix with multiple cores? (see compile: Work around non-thread-safe module autoloading.)

* harmless collisions are no longer reported to the user

* translations for 12 languages! (with stats on completion?) 

* new Android NDK build-system. 

* (wish) 2 default build farms available! (Berlin and hydra) keys are included but the url to Berlin is not yet added to substitute-urls. 

-- 
Cheers Swedebugia

Re: preparing the next release v0.15.0

[Ricardo Wurmus]

Hi Julien and Marius,

>> On the NEWS side, here is what springs to mind:
>>
>> * `guix weather` now reports CI statistics
>> * Guix will give hints for how to resolve common configuration errors
>> * RHEL6 systems are again supported
>> * Reproducibility improvements all around
>> * Lots of new supported AArch64 boards
>> * Packages can specify that some CVEs don't apply to them
>> * `guix pack --relocatable` :-)
>>
>> Others?
>
> * guix manual can now be translated and is partially translated into
> French

These are all good points.  Please feel free to make these changes in
NEWS directly.

-- 
Ricardo

Re: preparing the next release v0.15.0

[Kei Kebreau]

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

Marius Bakke <mbakke@fastmail.com> writes:

> On the NEWS side, here is what springs to mind:
>
[...]
> * Packages can specify that some CVEs don't apply to them

Around when (or what commit) was this feature introduced?

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

Re: preparing the next release v0.15.0

[Nils Gillmann]

Is it worth mentioning that guix pull for some time now
is back to relatively decent 1GB RAM consumption? I
think I had it even succeed on 512MB RAM per handwritten
notes here, but I haven't had the possibility to test again
on low specs.

Re: preparing the next release v0.15.0

[Ludovic Courtès]

Hello Guix!

Thanks for all the ideas, I’ve updated NEWS accordingly.  I’m sure we’re
still missing a number things (so much has happened!) so more ideas are
still welcome.  :-)

Ludo’.

Re: preparing the next release v0.15.0

[Kei Kebreau]

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

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

> Hello Guix!
>
> Thanks for all the ideas, I’ve updated NEWS accordingly.  I’m sure we’re
> still missing a number things (so much has happened!) so more ideas are
> still welcome.  :-)
>
> Ludo’.

Hi Ludo,

Looking at your changes to the log file increases my confidence that I
was on the right track with updating it. You covered what I'd added and
more, but I do have a quick question: I take it that there exists a
script for determining the new packages and updates for each release?
Maybe I've missed it in the repository or in discussion.

Thanks,
Kei

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

Re: preparing the next release v0.15.0

[Ricardo Wurmus]

Hi Kei,

> but I do have a quick question: I take it that there exists a
> script for determining the new packages and updates for each release?
> Maybe I've missed it in the repository or in discussion.

It is done with “make update-NEWS”.  It depends on a checkout of the
maintenance repository
(git://git.savannah.gnu.org/guix/maintenance.git), which is where we
store the list of package/version pairs of each Guix release.

--
Ricardo

Re: preparing the next release v0.15.0

[Marius Bakke]

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

Kei Kebreau <kkebreau@posteo.net> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> On the NEWS side, here is what springs to mind:
>>
> [...]
>> * Packages can specify that some CVEs don't apply to them
>
> Around when (or what commit) was this feature introduced?

It was added in commit f4007b25476dfd97885f358d2dabbd463f6f6017, but
there has been little fuzz or discussions around it.

I've been meaning to fix false positives from `guix lint -c cve` for a
while, but did not get around to it yet.

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

Re: preparing the next release v0.15.0

[swedebugia]

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



On June 20, 2018 8:38:46 PM GMT+02:00, Kei Kebreau <kkebreau@posteo.net> wrote:
>Marius Bakke <mbakke@fastmail.com> writes:
>
>> On the NEWS side, here is what springs to mind:
>>
>[...]
>> * Packages can specify that some CVEs don't apply to them
>
>Around when (or what commit) was this feature introduced?

f4007b25476dfd97885f358d2dabbd463f6f6017
Nov 30th. By efraim. 
-- 
Cheers Swedebugia 

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

Re: preparing the next release v0.15.0

[Kei Kebreau]

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

swedebugia <swedebugia@riseup.net> writes:

> On June 20, 2018 8:38:46 PM GMT+02:00, Kei Kebreau <kkebreau@posteo.net> wrote:
>
>  Marius Bakke <mbakke@fastmail.com> writes:
>
>   On the NEWS side, here is what springs to mind:
>
> [...]
>
>   * Packages can specify that some CVEs don't apply to them
>
> Around when (or what commit) was this feature introduced?
>
> f4007b25476dfd97885f358d2dabbd463f6f6017
> Nov 30th. By efraim. 

I see, thank you both.

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