bug#36517: 'guix deploy' does not restart services

[Ludovic Courtès]

Hi Jakob,

zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> Ludovic Courtès  writes:
>
>> Oh, I see. To me that’s completely orthogonal to ‘guix deploy’ though,
>> in that ‘guix system reconfigure’ and ‘guix deploy’ should use the
>> same code for that.
>>
>> Thanks,
>> Ludo’.
>
> Yeah, I believe it would be safe to close this once the code for 'guix
> deploy' and 'guix system reconfigure' is unified. I opened this under
> the impression that the two would remain separate and individual changes
> would need to occur for both.

Unless I’m mistaken, this bug can be closed now, right?

Thanks,
Ludo’.

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hello,

Marius Bakke  skribis:

> Mark H Weaver  writes:

[...]

>> I think what needs to be done is the following:
>>
>> (1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries'
>> should be reverted, to downgrade mescc-tools to the 0.5.2 release.
>>
>> (2) The 'wip-binaries' tarballs should be uploaded to a new subdirectory
>> of , along
>> with digital signatures, of course.  I'm talking about these in
>> particular:
>>
>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  
>> guile-static-stripped-2.2.4-i686-linux.tar.xz
>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  
>> linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  
>> mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  
>> mes-minimal-stripped-0.19-i686-linux.tar.xz
>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  
>> static-binaries-0-i686-linux.tar.xz
>>
>> (3) The following bootstrap packages in 'core-updates' bootstrap.scm
>> should be updated to use the new binaries above:
>>
>>  (a) %bootstrap-linux-libre-headers
>>  (b) %bootstrap-mescc-tools
>>  (c) %bootstrap-mes
>>
>> (4) Berlin should start rebuilding 'core-updates'.
>>
>> If desired, steps (3) and (4) could come before (2) if someone
>> temporarily uploads the new binaries somewhere else, and adjusts
>> '%bootstrap-base-urls' accordingly.  The key is for the hashes and file
>> names to match what we've agreed on here, as I listed in (2) above.
>>
>> What do you think?
>
> Thank you for the excellent summary.  I can look into adjusting the bash
> fix for 5.0, and updating the bootstrap binary URLs and hashes.  I will
> do this in a 'core-updates-next' branch.  I would also like to merge
> wip-binaries into it as a final step, unless someone has objections.

I don’t think we explicitly discussed it, but my assumption is that
we’re delaying merging of ‘core-updates’ into ‘master’ until
‘core-updates-next’ becomes ‘core-updates’.  Is this what you had in
mind?  (I’m asking because ‘core-updates’ was almost entirely built
IIRC.)

Also, what’s the next step for ‘wip-binaries’?

Thanks,
Ludo’.

bug#22138: Search paths of dependencies are not honored

[Ludovic Courtès]

Ludovic Courtès  skribis:

> The attached procedure computes the search paths of a package based on
> its run-time dependencies.  ‘profile-derivation’ could use this to
> compute its ‘etc/profile’ file and its ‘manifest’ file.

One difficulty with this approach is that search paths are currently a
“host-side” feature: there’s a ‘search-paths’ field in ,
which is populated before the profile is actually built.

What I suggest above would mean turning search paths into a “build-side”
feature, which has some implications.

Needs more thought…

Ludo’.

bug#36865: Guix gc breaks grub

[Ludovic Courtès]

Hello,

"Xavier Montillet"  skribis:

> All I can say for sure is that the bug was in the guix pull'ed version at 
> some point in the week leading to July 31 (and most likely on July 30), and 
> that the bug is no longer in the version of July 31 evening.

Could you run ‘guix pull -l 1m’ (for this specific ‘guix’ command) to
see exactly what the commits were for these two generations?

Thanks in advance,
Ludo’.

bug#36865: Guix gc breaks grub

[Xavier Montillet]

Hi,

Jul 26 2019 23:55:23   d23a00b599be56694065bd274184b9289fb8b85c
Jul 29 2019 11:32:04   ab20b3ed9152c7c95d0d2c6b2d65e29983ab57ce
Jul 29 2019 23:52:32   18c4b0a27705773e423fb17310394204b7295d4a
Jul 30 2019 before 22:03  nckx saves me (last messages of 
http://logs.guix.gnu.org/guix/2019-07-30.log)
Jul 30 2019 22:03  I send the bug report (first message of 
http://logs.guix.gnu.org/guix/2019-07-31.log)
Jul 31 2019 9:21  Ricardo responds to my bug report telling me to guix 
reconfigure
Jul 31 2019 09:30:31   bab94ffa0e27e39c02d5ce3add5605b676b76bee
Jul 31 2019 21:05  I send the email saying that Grub is no longer marked as 
dead after guix pulling
Jul 31 2019 13:31:40   716908411b4d393ec82d5b7e40c9817e81c8fa95
 Aug 01 2019 09:12:52   e7dfbae8a5abc9f088452ca35371d38eb343

So I would say that the bug was in18c4b0a27705773e423fb17310394204b7295d4a and 
was fixed before (or in) bab94ffa0e27e39c02d5ce3add5605b676b76bee.

Xavier

On Sat, Aug 24, 2019, at 2:04 PM, Ludovic Courtès wrote:
> Hello,
> 
> "Xavier Montillet"  skribis:
> 
> > All I can say for sure is that the bug was in the guix pull'ed version at 
> > some point in the week leading to July 31 (and most likely on July 30), and 
> > that the bug is no longer in the version of July 31 evening.
> 
> Could you run ‘guix pull -l 1m’ (for this specific ‘guix’ command) to
> see exactly what the commits were for these two generations?
> 
> Thanks in advance,
> Ludo’.
>

bug#36865: Guix gc breaks grub

[Jakob L. Kreuze]

Hi Ludovic,

Apologies for not participating in this thread until just now.

Ludovic Courtès  writes:

> Jakob, does that ring a bell?

Yes, this was fixed by #36880.

Regards,
Jakob


signature.asc
Description: PGP signature

bug#36517: 'guix deploy' does not restart services

[Jakob L. Kreuze]

Hi Ludovic,

Ludovic Courtès  writes:

> Unless I’m mistaken, this bug can be closed now, right?

Yep! This can be closed now, since we're running the unified code and we
have another ticket for tracking this in 'guix system reconfigure'.

Regards,
Jakob


signature.asc
Description: PGP signature

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  wrote:
> I don’t think we explicitly discussed it, but my assumption is that
> we’re delaying merging of ‘core-updates’ into ‘master’ until
> ‘core-updates-next’ becomes ‘core-updates’.  Is this what you had in
> mind?  (I’m asking because ‘core-updates’ was almost entirely built
> IIRC.)

My preference would be to merge 'core-updates-next' into 'core-updates',
or equivalently, to apply the following 3 commits to 'core-updates':

--8<---cut here---start->8---
commit d4bc93abe59e8ffcb8304050c05e727fe0230651
Author: Mark H Weaver 
Date:   Thu Aug 15 15:39:30 2019 -0400

  gnu: bootstrap: Update to the 20190815 bootstrap binaries.
  
  * gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update the
  download URL.
  (%bootstrap-mescc-tools, %bootstrap-mes): Update the download URL and hash.

commit 82eaac49ac983f28768d6623d802f41cbd7f779b
Author: Mark H Weaver 
Date:   Thu Aug 15 16:44:36 2019 -0400

  gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems.
  
  * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file.
  * gnu/local.mk (dist_patch_DATA): Add it.
  * gnu/packages/bash.scm (bash)[source]: Add the patch.

commit 47fcdfac44c5bf236299679781133468be6f0207
Author: Ludovic Courtès 
Date:   Thu Aug 22 11:47:27 2019 +0200

  gnu: bootstrap: Add ftp.gnu.org to '%bootstrap-base-urls'.
  
  * gnu/packages/bootstrap.scm (%bootstrap-base-urls): Add
  ftp.gnu.org/gnu/guix/bootstrap.
--8<---cut here---end--->8---

These commits are the only difference between 'core-updates' and
'core-updates-next'.

I'm confident that this will make no difference to the set of packages
that build successfully, modulo non-determistic build failures.  The
only additional time it should require is the time needed for Berlin to
rebuild the branch.

Otherwise, 'core-updates-next' seems to be in good shape, and possibly
almost ready to merge into 'master'.  I admit that this assessment is
based solely on the fact that I'm currently using it on my own machine,
and it works well.  Without Hydra's interface for comparing evaluations,
I'm mostly blind to the status of the branch beyond of the set of
packages I use myself.

In my opinion, 'core-updates' in its current form should never be merged
into 'master', because it's built upon non-deterministic bootstrap
tarballs that cannot be independently verified.

What do you think?

> Also, what’s the next step for ‘wip-binaries’?

Good question!  First, I think we should tag it with a name that
indicates that it was used to build the 20190815 bootstrap binaries.

Optionally, I would advocate merging 'wip-binaries' into 'master'.

What do you think?

  Thanks,
Mark