bug#37164: Generated installation image does not include grub.

[Gábor Boskovits]

Hello,

Jesse Gibbons  ezt írta (időpont: 2019. aug. 27.,
K, 4:48):

> On Mon, 2019-08-26 at 22:44 +0200, Gábor Boskovits wrote:
> > Hello,
> >
> > Jesse Gibbons  ezt írta (időpont: 2019. aug.
> > 23., P, 19:41):
> > > 1. generate the install image
> > >  guix system disk-image --file-system-type=iso9600 --verbosity=3 --
> > > root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
> > > system install) installation-os)'
> > >
> >
> > Just a wild guess, does it work with the verbosity option removed?
> > I had issues with that in the past.
> I tried generating an install image with --verbosity and another
> without --verbosity. There was no difference because guix does not
> expect the --verbosity option to make a difference.
>
> I deleted the link and ran the garbage collector, then tried building
> the image without --verbosity, but file does not detect grub. I think
> it isn't a problem with 'file' because a virtual machine setup with
> virt-manager does not think the ISO is bootable.
>

Is it possible that you are hit by this issue?
https://issues.guix.gnu.org/issue/36865
Could you try again after guix pull?

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

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

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> Mark H Weaver  skribis:
>
>> Ludovic Courtès  wrote:
>>> 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'.
>
> Fine with me!  Could you take care of tagging and merging?

I tagged 'wip-binaries' and merged it into master, but there's an
undesirable side effect.  After the merge, "git describe" from 'master'
now returns "bootstrap-20190815-222-g32e18e9b94".

Mark

bug#36942: Reconfigure broke GRUB

[ison]

On Mon, Aug 26, 2019 at 12:20:04PM +0200, Ludovic Courtès wrote:
> 
> Closing, because this is apparently the same as
> , which fortunately was fixed a
> while back!
> 
> Thanks,
> Ludo’.

For the record I attempted another install just now and it was
successful. I'm not sure exactly what caused the initial breakage or
what fixed it, but I'm glad it's working now.

Thanks again for the help.

bug#37164: Generated installation image does not include grub.

[Jesse Gibbons]

On Mon, 2019-08-26 at 22:44 +0200, Gábor Boskovits wrote:
> Hello,
> 
> Jesse Gibbons  ezt írta (időpont: 2019. aug.
> 23., P, 19:41):
> > 1. generate the install image
> >  guix system disk-image --file-system-type=iso9600 --verbosity=3 --
> > root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
> > system install) installation-os)'
> > 
> 
> Just a wild guess, does it work with the verbosity option removed?
> I had issues with that in the past.
I tried generating an install image with --verbosity and another
without --verbosity. There was no difference because guix does not
expect the --verbosity option to make a difference.

I deleted the link and ran the garbage collector, then tried building
the image without --verbosity, but file does not detect grub. I think
it isn't a problem with 'file' because a virtual machine setup with
virt-manager does not think the ISO is bootable.

bug#37164: Generated installation image does not include grub.

[Gábor Boskovits]

Hello,

Jesse Gibbons  ezt írta (időpont: 2019. aug. 23.,
P, 19:41):

> 1. generate the install image
>  guix system disk-image --file-system-type=iso9600 --verbosity=3 --
> root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
> system install) installation-os)'
>
>
Just a wild guess, does it work with the verbosity option removed?
I had issues with that in the past.

2. examine the resulting iso
> readlink installation-os-x86_64.iso | xargs file
>
> output: /gnu/store/3xp541s4zrxass6h6rcwfz7bc33wv84p-disk-image: DOS/MBR
> boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-
> CHS (0xe3,198,58), startsector 2048, 3657239 sectors; partition 2 :
> ID=0xef, start-CHS (0xe3,198,59), end-CHS (0xe8,224,16), startsector
> 3659287, 81921 sectors
>
> 3. Compare this output with what file says about the official
> installation iso:
> wget https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1.x86_64-linu
> x.iso.xz
> unxz guix-system-install-1.0.1.x86_64-linux.iso.xz
> readlink guix-system-install-1.0.1.x86_64-linux.iso
>
> output:guix-system-install-1.0.1.x86_64-linux.iso: DOS/MBR boot sector;
> GRand Unified Bootloader, stage1 version 0x79, boot drive 0xbb, stage2
> address 0x8e70, 1st sector stage2 0xb8db31c3, stage2 segment 0x201;
> partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3f6,38,4),
> startsector 1, 2694403 sectors, extended partition table (last)
>
> It appears file discovered the GRand Unified Bootloader in the official
> iso but not in the generated iso.
>
> When I try to use the generated iso in virt-manager, it claims there
> are no bootable drives. I think this is because the generated iso has
> no GRUB.
>
> The manual says to specify the file gnu/system/install.scm instead of
> the value (@ (gnu system install) installation-os)) but ultimately they
> give guix the same value, so I think that wouldn't make a difference.
>
> removing --system=x86_64 does not trigger a full rebuild, so it looks
> like guix does not expect to build anything different.
>
> Guix describe outputs:
>
> Generation 47   Aug 23 2019 09:22:24(current)
>   guix d78bc23
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: d78bc23411b1351ff9495a511c22b27d17f9226f
>
> GUIX_PACKAGE_PATH="/home/jesse/Documents/broken-guix/Broken-Guix-
> Packages"
>
> Thanks
> -Jesse
>
>
>
>
Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#36855: guix system switch-generation doesn't

[Mark H Weaver]

Hi,

Ludovic Courtès  writes:

> Jakob, now that we generate scripts for the effectful bits of system
> reconfiguration (one of these bits being service upgrades), couldn’t we
> take it one step further and store those scripts in the “system”
> derivation so we can run them eventually, notably upon
> ‘switch-generation’?

As a bonus, this approach might solve another issue I've observed: on my
Guix system, where I build everything locally, several derivations are
built *during* activation.  Based on the terminal output, I get the
impression that the system is compiling things while the system in an
intermediate state, when some of the activation steps have been done,
but not all of them.

As I recall, the derivations built during activation are limited to
compiled modules for Guile, but it still sometimes takes on the order of
a minute or two on my laptop to complete the "activating system" steps.
This seems suboptimal.

The next time I update my system, I'll try to remember to keep a
transcript of this, so that I can be more specific.

  Best,
   Mark

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

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> Mark H Weaver  skribis:
>
>> 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':
>>
>> 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.
>>
>> These commits are the only difference between 'core-updates' and
>> 'core-updates-next'.
>
> OK.  The Bash change means we’re rebuilding from scratch on
> architectures, not just x86.  So I’ll probably ungraft my Ghostscript
> fix (466ff55c72959ba1499ce3ec69f534b3038eb30b) while we’re at it.

Hmm, good point.  Perhaps we should postpone the Bash fix until the next
core-updates cycle.  The problem was quite severe in bash-4.4, which
builds incorrectly on linux-5.0 or later, but the issue in bash-5.0 is
far less likely to cause problems in practice: it will build differently
on linux-2.3 or earlier.

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'.
>
> Fine with me!  Could you take care of tagging and merging?

Sure, will do.

Thanks,
  Mark

bug#36931: [swh-devel] bug#36931: guile-bash repository no longer exists?

[Nicolas Dandrimont]

* Ludovic Courtès  [2019-08-23 18:30:17 +0200]:

> Hello SWH!
> 
> We noticed¹ that the ‘fetch_url’ of this Vault entry returns 404:
> 
>   
> https://archive.softwareheritage.org/api/1/vault/directory/ad8976564375ee55f645387bbcdf4b66e6582fbf/
> 
> Is that supposed to happen?  I don’t remember hitting a ‘fetch_url’ that
> would be 404 before.
> 
> For the record, it corresponds to this revision:
> 
>   
> https://archive.softwareheritage.org/api/1/revision/1eabc563ca5692b3e08d84f1f0e6fd2283284469/
> 
> Thanks in advance,
> Ludo’.
> 
> ¹ Originally reported at .

Hi!

We've recently moved the Software Heritage Vault to different infrastructure.
In doing so, the existing bundles were scrapped; however, the old cache entries
in the database hadn't been invalidated.

I've now made sure that pre-migration cache entries have been invalidated. I've
also scheduled cooking of objects that had been accessed recently, including
the one you've referenced, and they should now be available for download (or
at least trickling in).

Thanks for the report!
-- 
Nicolas Dandrimont

if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
printf("Don't Panic!\n");
exit(42);
}
(Arnold Robbins in the LJ of February '95, describing RCS)


signature.asc
Description: PGP signature

bug#36551: [META] Run Guix System on Purism Librem 5

[Jonathan Brielmaier]

libhandy is already in master since commit 213315d485:
https://issues.guix.gnu.org/issue/36926

bug#36961: Can't use microphone in ungoogled-chromium

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello,
>
> Mathieu Lirzin  skribis:
>
>> Brian Leung  writes:
>>
>>> When a microphone is plugged in, ungoogled-chromium fails to detect it.
>>
>> I have the same issue here.
>
> I initially had the same problem (specifically with Jitsi on
> https://riot.im) but switching the input to the right microphone in
> ‘pavucontrol’ fixed it.
>
> So perhaps it’s just that, for some reason, Chromium picks the wrong
> PulseAudio input by default?
>
> Thanks,
> Ludo’.

FWIW I just did a VoIP call using ungoogled-chromium last Friday.  I had
to *both* open pavucontrol and select the right input device and enable
it (it was muted) also click on the microphone button (I don't remember
where) and select the particular device.  Once I did that, worked like a
charm.

bug#36961: Can't use microphone in ungoogled-chromium

[Ludovic Courtès]

Hello,

Mathieu Lirzin  skribis:

> Brian Leung  writes:
>
>> When a microphone is plugged in, ungoogled-chromium fails to detect it.
>
> I have the same issue here.

I initially had the same problem (specifically with Jitsi on
https://riot.im) but switching the input to the right microphone in
‘pavucontrol’ fixed it.

So perhaps it’s just that, for some reason, Chromium picks the wrong
PulseAudio input by default?

Thanks,
Ludo’.

bug#37162: ‘guix pack -f docker’ creates an image without /etc/passwd

[Ricardo Wurmus]

Ludovic Courtès  writes:

>> What use case(s) exactly depend on the presence of the
>> /etc/{passwd,group,shadow} files?
>
> Generally, absent these files, getpw(3) and co. won’t give useful
> results, and some applications will behave poorly (e.g., the PS1 prompt
> in Bash can’t show the user name; ‘id’ fails).
>
> Most of the time it’s just a minor inconvenience.

I think it’s fine to add these files to avoid this source of
inconvenience.

Perhaps it would be good to recommend in the manual the use of “guix
system” for those who need more control over the contents of these
files.

And maybe we can make some really simple template system configuration
available to “guix system” without requiring users to fully specify the
operating system configuration.  I’m thinking of something like this
where %simple-os is made available by default:

(operating-system
  (inherit %simple-os)
  (packages (list "a" "b" "c")))

--
Ricardo

bug#36931: guile-bash repository no longer exists?

[Björn Höfling]

On Fri, 23 Aug 2019 18:32:38 +0200
Ludovic Courtès  wrote:

> Ouch.  I’ve improved error reporting handling here, but I think the
> fundamental issue is that SWH is failing to deliver this thing, even
> though it does have it:

Thanks for looking into this. Let's see what SWH has to say.

After all, I think we should leave this pack in Guix. At least it is a
good SWH-test-package :-)

Björn


pgpee44Jxw5kL.pgp
Description: OpenPGP digital signature

bug#36942: Reconfigure broke GRUB

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> On Tue, 06 Aug 2019 15:48:43 -0400
> zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) wrote:
>
>> Danny Milosavljevic  writes:
>> 
>> > Hi,
>> >
>> > I've examined /var/guix/gcroots without #36947 and I get:
>> >
>> > lrwxrwxrwx 1 root root   18 24. Jul 11:32 profiles -> /var/guix/profiles
>> > lrwxrwxrwx 1 root root   19 24. Jul 11:32 current-system -> 
>> > /run/current-system
>> > lrwxrwxrwx 1 root root   18 24. Jul 11:32 booted-system -> 
>> > /run/booted-system
>> > lrwxrwxrwx 1 root root   26 29. Jul 22:26 bootcfg -> 
>> > //var/guix/gcroots/bootcfg
>> >
>> > So I guess I'm one "guix gc" away from also destroying my
>> > installation.  
>> 
>> Was this fixed after applying #36947?
>
> Yes.

Closing, because this is apparently the same as
, which fortunately was fixed a
while back!

Thanks,
Ludo’.

bug#36942: Reconfigure broke GRUB

[Ludovic Courtès]

Hello ison,

ison  skribis:

> At least it's giving an error this time:
> error: '/gnu/store/drz35fc...-grub-efi-2.02/sbin/grub-install 
> --boot-directory /mnt/boot --bootloader-id=Guix --efi-directory /boot/efi' 
> exited with status 1: output follows:
>   /gnu/store/drz35fc...-grub-efi-2.02/sbin/grub-install: error: 
> /gnu/store/drz35fc...-grub-efi-2.02/lib/grub/i386-pc/modinfo.sh doesn't 
> exist. Please specify --target or --directory.
>
> My bootloader is section is still:
>   (bootloader (bootloader-configuration
>(bootloader grub-efi-bootloader)
>(target "/boot/efi")))

The message above is telling that it’s trying to do a “BIOS” (as opposed
to EFI) install of GRUB, but you specified ‘grub-efi’, hence the
failure.

Is your system really EFI?

Anyway, this issue is different from the original one, so perhaps we
should discuss it on help-guix?

Thanks,
Ludo’.

bug#36870:

[Ludovic Courtès]

Hi,

Bengt Richter  skribis:

> On +2019-08-06 02:54:03 -0400, Mark H Weaver wrote:
>> Hi Bengt,
>> 
>> I'm sorry that I didn't have time to fully read your messages, but if I
>> understand correctly from my quick skimming, the 'date' command from
>> Guix is failing to access the zoneinfo.  I think I see your problem.
>> 
>> Bengt Richter  writes:
>> > $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n:g'
>> > openat(AT_FDCWD,
>> >  
>> > "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
>> >  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> 
>> The file name above suggests that your TZDIR variable is not set
>> correctly to allow Guix-built binaries to find the zoneinfo files.
>> 
>> On Guix systems, /etc/environment includes an entry that sets TZDIR to
>> the equivalent of "$(guix build tzdata)/share/zoneinfo".
>> 
>> When using Guix on top of another distro, an alternative choice might be
>> to set TZDIR to "/usr/share/zoneinfo".  I'm not sure which setting is
>> preferable on non-Guix systems.
>> 
>> Can you try setting TZDIR and see if that solves the problem for you?
>> 
>>  Regards,
>>Mark
>
> Thanks, that works using either /usr/... or /gnu/...

Good, closing!

> but I am thinking everything guix should be accessed via
> some profile if it's configurable?
>
> There is already a suggestion to source like this:
>
> GUIX_PROFILE="$HOME/.guix-profile"
> . "$GUIX_PROFILE/etc/profile"
>
> I think it would be nice if that were the only ~/.bash_profile
> mod a foreign-system user would have to make to tie into the
> guix packages such user installs with guix install.
>
> So what about having that GUIX_PROFILE profile -- at its end --
> source ~/.guixrc if it exists, and then when some installation wants
> to suggest some environment settings, just automatically
> append commented-out code to ~/.guixrc.

I agree that it’d be nice to somehow tell users about ‘TZDIR’, but I’m
reluctant to introducing yet another profile file.

I’m not sure what would be the best approach!

Thanks,
Ludo’.

bug#36855: guix system switch-generation doesn't

[Ludovic Courtès]

Hey Chris & Jakob,

Chris Marusich  skribis:

> zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes:
>
>> 'switch-to-system-generation' doesn't call out to
>> 'upgrade-shepherd-services'. I'm not sure if this was an intentional
>> decision or not
>
> It is intentional, but only because there is currently no way to call
> upgrade-shepherd-services when switching system generations.

[...]

> FYI, last I checked (about 3 years ago), in NixOS they took a slightly
> different approach: instead of storing state describing the previous
> system generation and relying on the current system's logic to correctly
> parse it and use it to revert the system to a prior configuration, they
> just dump everything into a self-contained script that knows how to
> update the entire system to one specific configuration.  That approach
> is nice in some ways because switching generations is dead simple - you
> just run the switching script belonging to the generation you want to
> switch to - but it also has downsides.

Jakob, now that we generate scripts for the effectful bits of system
reconfiguration (one of these bits being service upgrades), couldn’t we
take it one step further and store those scripts in the “system”
derivation so we can run them eventually, notably upon
‘switch-generation’?

> For example, if the target generation is old enough compared to the
> current system, then the target generation's old switching script might
> not understand how to deal with the current system correctly.  Instead,
> if you only store the bare minimum of state required to take the right
> actions, and you implement the meat of the logic in the current Guix
> installation, you are more likely to be able to switch generations even
> to very old ones where the world was very different, since the current
> Guix can be taught how to deal gracefully with the old world.  But it
> seems more complicated.  It's all about trade-offs.

Indeed.  The important thing to me is that from the GRUB menu you can
really switch to any generation.  I’ve actually never used
‘switch-generations’ on my laptop, but technically, I feel like storing
the “switch-to-system” script would be the easiest way.

Thanks,
Ludo’.

bug#36782: Website manual language links

[Julien Lepiller]

Hi,

instead of applying a patch to texinfo, shouldn't we simply rename guix.fr -> 
guix-fr or something?

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

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> 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':
>
> 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.
>
> These commits are the only difference between 'core-updates' and
> 'core-updates-next'.

OK.  The Bash change means we’re rebuilding from scratch on
architectures, not just x86.  So I’ll probably ungraft my Ghostscript
fix (466ff55c72959ba1499ce3ec69f534b3038eb30b) while we’re at it.

> 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.

I find that ‘guix weather -c’ gives a rather good overview of the
situation, though it’s not equivalent to comparing with another
evaluation.

> 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?

That sounds good to me.  I think we should start real soon, then.
Marius?

>> 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'.

Fine with me!  Could you take care of tagging and merging?

Thanks,
Ludo’.

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

[Ludovic Courtès]

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

> 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'.

Alrighty, done!

Ludo’.

bug#36865: Guix gc breaks grub

[Ludovic Courtès]

Hi Jakob,

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

> Ludovic Courtès  writes:
>
>> Jakob, does that ring a bell?
>
> Yes, this was fixed by #36880.

Looking more closely, it seems to be
.

Anyway, closing.  Thanks for your feedback!

Ludo’.

bug#37162: ‘guix pack -f docker’ creates an image without /etc/passwd

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Ricardo Wurmus  writes:
>
>> Hi Maxim,
>>
>>> Ludovic Courtès  writes:
>>>
 ‘guix pack -f docker’ currently creates an image without
 /etc/{passwd,group,shadow}.

 It’s OK most of the time, but again it looks like a gratuitous annoyance
 for those cases where having them around matters (that’s also the reason
 why guix-daemon creates them.)
>>>
>>> Would that include the files required for PAM authentication to work
>>> correctly? I remember struggling with this use case: using the Docker
>>> image with CQFD wrapper, which must be able to create a user and
>>> sudo'ing (or 'su') to it in the docker container.
>>
>> I wonder if at this point it wouldn’t be better to build a whole system
>> container.  Isn’t that outside the scope of “guix pack” and rather a
>> task for “guix system”?

I think so.

> Probably! But then one has to wonder if adding some base files to `guix
> pack' is not one of those slippery slopes where users come back
> expecting more stuff to be there?
>
> What use case(s) exactly depend on the presence of the
> /etc/{passwd,group,shadow} files?

Generally, absent these files, getpw(3) and co. won’t give useful
results, and some applications will behave poorly (e.g., the PS1 prompt
in Bash can’t show the user name; ‘id’ fails).

Most of the time it’s just a minor inconvenience.

Ludo’.