Re: ‘version-1.2.0’ branch created!

[zimoun]

Dear,

On Fri, 6 Nov 2020 at 13:52, zimoun  wrote:

> > Thoughts?  Patches?  Ideas?  :-)
>
> A lot of substitutes are still missing (for example R).  Is it possible
> to trigger the builds?

I think Ludo tried to trigger a rebuild of all the r-* packages, see
[1].  However, "guix weather -c 15" still lists packages:

 + java-snappy which builds fine locally and Berlin reports

 + sbcl-zpb-ttf which builds fine locally and on Bayfront and I am not
able to find information
 + sbcl-cl-paths idem.
 +  cl-ana.math-functions but I get a substitute; weird that weather
reports missing.
 +sbcl-cl-aa builds fine
 + java-slf4j-simple builds fine
 - python-pysam fails because of samtools.

where + means packages that should be rebuild on Berlin and - packages
that does not.


I think some IO issues lead to these missing substitutes and both Data
Services and ci.guix.gnu.org do not always report the correct status.
Well, or I am not sure to correctly understand.

However, it is not really an issue since the compilation is really
fast; I have not checked all the requirements though.

1: 

All the best,
simon

Re: ‘version-1.2.0’ branch created!

[Ludovic Courtès]

Hi Oleg,

Oleg Pykhalov  skribis:

> Ludovic Courtès  writes:
>
> […]
>
>> Changes to core Guix should be limited to bug fixes as well.
>>
>> Thoughts?  Patches?  Ideas?  :-)
>
> Could we have a shepherd with 5082354a included (service: Add
> #:supplementary-groups.)?  I could live with an overrided shepherd
> package [1] which contains 5082354a as a patch, but still. ;-)

I personally don’t feel like pushing a Shepherd release right now (I
have enough on my plate :-)), and note that, even when we’ve done that,
we won’t be able to rely on #:supplementary-groups right away because
users may still be running the older version.

All that said, I do agree that it’d be nice to have, mind you!

> [1]: (module-set! (resolve-module '(gnu packages admin)) 'shepherd 
> shepherd-patched)

This isn’t pretty.  We should arrange to make
‘shepherd-root-service-type’ customizable so one can choose which
Shepherd package to use.

Thanks,
Ludo’.

Re: ‘version-1.2.0’ branch created!

[Oleg Pykhalov]

Hi,

Ludovic Courtès  writes:

[…]

> Changes to core Guix should be limited to bug fixes as well.
>
> Thoughts?  Patches?  Ideas?  :-)

Could we have a shepherd with 5082354a included (service: Add
#:supplementary-groups.)?  I could live with an overrided shepherd
package [1] which contains 5082354a as a patch, but still. ;-)

Also, I remember people ask for this change be merged recently.


[1]: (module-set! (resolve-module '(gnu packages admin)) 'shepherd 
shepherd-patched)

Thanks,
Oleg.


signature.asc
Description: PGP signature

Re: ‘version-1.2.0’ branch created!

[Julien Lepiller]

Le 6 novembre 2020 07:51:30 GMT-05:00, zimoun  a 
écrit :
>Hi,
>
>On Fri, 06 Nov 2020 at 11:15, Ludovic Courtès  wrote:
>
>> We have a new branch now!
>
>Awesome!
>
>
>> This branch should take primarily important changes that fix the
>> installer or other key elements.  It should not change translatable
>> strings and should not change the manual either, unless a fix
>requires
>> it, because translations are being finalized.
>
>We are in string freeze.  Translators, is it fine for you?

We'll need some time to adjust the translation for the release. I've sent the 
new strings to the TP coordinator yesterday, but they're not on the TP yet.

>
>
>> It may be OK to merge “obvious” changes from ‘master’, such as the
>> addition or upgrade of leaf packages.  Changes that would lead to
>> rebuilds of key packages (everything the installer needs plus GNOME,
>> Emacs, IceCat, etc.) should be avoided I think.
>
>Agree.
>
>
>> Thoughts?  Patches?  Ideas?  :-)
>
>A lot of substitutes are still missing (for example R).  Is it possible
>to trigger the builds?
>
>
>All the best,
>simon

Re: ‘version-1.2.0’ branch created!

[zimoun]

Hi,

On Fri, 06 Nov 2020 at 11:15, Ludovic Courtès  wrote:

> We have a new branch now!

Awesome!


> This branch should take primarily important changes that fix the
> installer or other key elements.  It should not change translatable
> strings and should not change the manual either, unless a fix requires
> it, because translations are being finalized.

We are in string freeze.  Translators, is it fine for you?


> It may be OK to merge “obvious” changes from ‘master’, such as the
> addition or upgrade of leaf packages.  Changes that would lead to
> rebuilds of key packages (everything the installer needs plus GNOME,
> Emacs, IceCat, etc.) should be avoided I think.

Agree.


> Thoughts?  Patches?  Ideas?  :-)

A lot of substitutes are still missing (for example R).  Is it possible
to trigger the builds?


All the best,
simon

‘version-1.2.0’ branch created!

[Ludovic Courtès]

Hi Guix!

We have a new branch now!

This branch should take primarily important changes that fix the
installer or other key elements.  It should not change translatable
strings and should not change the manual either, unless a fix requires
it, because translations are being finalized.

It may be OK to merge “obvious” changes from ‘master’, such as the
addition or upgrade of leaf packages.  Changes that would lead to
rebuilds of key packages (everything the installer needs plus GNOME,
Emacs, IceCat, etc.) should be avoided I think.

Changes to core Guix should be limited to bug fixes as well.

Thoughts?  Patches?  Ideas?  :-)

Ludo’.