Planning for the next release

Planning for the next release

[Ludovic Courtès]

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

Hello Guix!

It’s time to plan for the next release!  Here’s what we maintainers
think should be done for the next release, which would hopefully happen
within less than a month:

   1. ‘core-updates’ merged.  We’re almost there!

   2. ‘wip-installer’ retested, and probably merged.

      I think the prerequisite for it would be to do some more testing.
      Last time people reported glitches here and there but John has
      done quite a bit of work since then.  John: what about doing
      another round of tests?

      In the installation image, we should probably make the installer
      optional and mark it as “beta” or something like that.  That will
      leave us time to iron out remaining issues, and will avoid having
      people expect a rock-solid Debian-style installer.

      As far as review is concerned, we can probably do a quick and
      lightweight review process since that’s quite a big chunk of code
      and we don’t want the branch to block indefinitely.  So we can do
      that quick process, and then incrementally improve it if needed.
      I think it’s a reasonable approach given that the installer is
      mostly an independent component.

      John, everyone: thoughts?

   3. UEFI support documented and possibly improved.

      We can certainly document the UEFI setup and add the /boot/efi
      partition in some of the ‘operating-system’ examples.

      The more difficult part is the installation: do we need to make a
      second, UEFI-specific, installation image?  When I installed
      GuixSD on UEFI, I booted our installation image as “legacy”, but
      then GRUB would default to a legacy install, not a UEFI install:

        https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html

      I’m not sure exactly what needs to be done.  Thoughts?

   4. Fix low-hanging fruits at <https://bugs.gnu.org/guix>; your help
      welcome!

Please share your thoughts!

Ludo’.

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

Re: Planning for the next release

[ng0]

Ludovic Courtès transcribed 3.0K bytes:
> Hello Guix!
> 
> It’s time to plan for the next release!  Here’s what we maintainers
> think should be done for the next release, which would hopefully happen
> within less than a month:
> 
>    1. ‘core-updates’ merged.  We’re almost there!
> 
>    2. ‘wip-installer’ retested, and probably merged.
> 
>       I think the prerequisite for it would be to do some more testing.
>       Last time people reported glitches here and there but John has
>       done quite a bit of work since then.  John: what about doing
>       another round of tests?
> 
>       In the installation image, we should probably make the installer
>       optional and mark it as “beta” or something like that.  That will
>       leave us time to iron out remaining issues, and will avoid having
>       people expect a rock-solid Debian-style installer.
> 
>       As far as review is concerned, we can probably do a quick and
>       lightweight review process since that’s quite a big chunk of code
>       and we don’t want the branch to block indefinitely.  So we can do
>       that quick process, and then incrementally improve it if needed.
>       I think it’s a reasonable approach given that the installer is
>       mostly an independent component.
> 
>       John, everyone: thoughts?
> 
>    3. UEFI support documented and possibly improved.
> 
>       We can certainly document the UEFI setup and add the /boot/efi
>       partition in some of the ‘operating-system’ examples.
> 
>       The more difficult part is the installation: do we need to make a
>       second, UEFI-specific, installation image?  When I installed
>       GuixSD on UEFI, I booted our installation image as “legacy”, but
>       then GRUB would default to a legacy install, not a UEFI install:
> 
>         https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
> 
>       I’m not sure exactly what needs to be done.  Thoughts?
> 
>    4. Fix low-hanging fruits at <https://bugs.gnu.org/guix>; your help
>       welcome!
> 
> Please share your thoughts!
> 
> Ludo’.

Questions about UEFI are getting more frequent, so I'd say this is good
to document it properly.

On my side, people will and have asked for the intermediate time how/if
the http_proxy of Guix works. If someone has been using it with an
SOCKS5 proxy successfully, I'd would like to have this added to
documentation as well. My own experiment ended up with a shot in the
foot where I had to roll back because Guix was now unable to do anything
at all.

Maybe as a 'food for thought': More filesystems.. I have an work in
progress patch for XFS, but it's not completely clear how filesystems
are supposed to be built. All static? All dynamic? Both?

Re: Planning for the next release

[Ludovic Courtès]

ng0 <contact.ng0@cryptolab.net> skribis:

> On my side, people will and have asked for the intermediate time how/if
> the http_proxy of Guix works. If someone has been using it with an
> SOCKS5 proxy successfully, I'd would like to have this added to
> documentation as well. My own experiment ended up with a shot in the
> foot where I had to roll back because Guix was now unable to do anything
> at all.

The guix-service in GuixSD now allows you to specify an HTTP proxy quite
easily, for substitutes and downloads (commit 93d32da9f8).  I haven’t
tried it but it Should Work Fine.

Ludo’.

Re: Planning for the next release

[ng0]

Ludovic Courtès transcribed 0.6K bytes:
> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> > On my side, people will and have asked for the intermediate time how/if
> > the http_proxy of Guix works. If someone has been using it with an
> > SOCKS5 proxy successfully, I'd would like to have this added to
> > documentation as well. My own experiment ended up with a shot in the
> > foot where I had to roll back because Guix was now unable to do anything
> > at all.
> 
> The guix-service in GuixSD now allows you to specify an HTTP proxy quite
> easily, for substitutes and downloads (commit 93d32da9f8).  I haven’t
> tried it but it Should Work Fine.
> 
> Ludo’.
> 

That's the commit after which I've tried to make it work, reconfigured
the system with it and failed.
If I remember correctly, I simply added this to the config of guix, as
suggested in the config.
For what I really did and if you require an error output, I can provide
this to you within the next 2 weeks.

Re: Planning for the next release

[Leo Famulari]

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

On Fri, Mar 31, 2017 at 04:33:24PM +0000, ng0 wrote:
> Ludovic Courtès transcribed 0.6K bytes:
> > > On my side, people will and have asked for the intermediate time how/if
> > > the http_proxy of Guix works. If someone has been using it with an
> > > SOCKS5 proxy successfully, I'd would like to have this added to
> > > documentation as well. My own experiment ended up with a shot in the
> > > foot where I had to roll back because Guix was now unable to do anything
> > > at all.
> > 
> > The guix-service in GuixSD now allows you to specify an HTTP proxy quite
> > easily, for substitutes and downloads (commit 93d32da9f8).  I haven’t
> > tried it but it Should Work Fine.
> 
> That's the commit after which I've tried to make it work, reconfigured
> the system with it and failed.
> If I remember correctly, I simply added this to the config of guix, as
> suggested in the config.
> For what I really did and if you require an error output, I can provide
> this to you within the next 2 weeks.

Since that's my commit, I'm happy to debug / test it, but I don't have
an HTTP proxy or know how to set one up.

If you can share the proxy server with me, or explain how to create one,
I'll test it.

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

Re: Planning for the next release

[ng0]

Leo Famulari transcribed 2.2K bytes:
> On Fri, Mar 31, 2017 at 04:33:24PM +0000, ng0 wrote:
> > Ludovic Courtès transcribed 0.6K bytes:
> > > > On my side, people will and have asked for the intermediate time how/if
> > > > the http_proxy of Guix works. If someone has been using it with an
> > > > SOCKS5 proxy successfully, I'd would like to have this added to
> > > > documentation as well. My own experiment ended up with a shot in the
> > > > foot where I had to roll back because Guix was now unable to do anything
> > > > at all.
> > > 
> > > The guix-service in GuixSD now allows you to specify an HTTP proxy quite
> > > easily, for substitutes and downloads (commit 93d32da9f8).  I haven’t
> > > tried it but it Should Work Fine.
> > 
> > That's the commit after which I've tried to make it work, reconfigured
> > the system with it and failed.
> > If I remember correctly, I simply added this to the config of guix, as
> > suggested in the config.
> > For what I really did and if you require an error output, I can provide
> > this to you within the next 2 weeks.
> 
> Since that's my commit, I'm happy to debug / test it, but I don't have
> an HTTP proxy or know how to set one up.
> 
> If you can share the proxy server with me, or explain how to create one,
> I'll test it.

To put it simple, my use case is tor. I thought it would be enough to
point to the host:port like I do for socks5 settings of applications.

                   (tor-service
                    (plain-file "torrc"
"SocksPort 127.0.0.1:9050\n"))

could be a config (not my config).

Step one is to test it with tor, afterwards comes testing with gnunet
socks.

If you can not use tor, I can't help to provide a different example.
The machine where the old configs are is down at the moment, but I've
added it to config of guix similar to how you extend the list of
substitute machines in the config.

Re: Planning for the next release

[Ricardo Wurmus]

ng0 <contact.ng0@cryptolab.net> writes:

> Leo Famulari transcribed 2.2K bytes:
>> On Fri, Mar 31, 2017 at 04:33:24PM +0000, ng0 wrote:
>> > Ludovic Courtès transcribed 0.6K bytes:
>> > > > On my side, people will and have asked for the intermediate time how/if
>> > > > the http_proxy of Guix works. If someone has been using it with an
>> > > > SOCKS5 proxy successfully, I'd would like to have this added to
>> > > > documentation as well. My own experiment ended up with a shot in the
>> > > > foot where I had to roll back because Guix was now unable to do anything
>> > > > at all.
>> > > 
>> > > The guix-service in GuixSD now allows you to specify an HTTP proxy quite
>> > > easily, for substitutes and downloads (commit 93d32da9f8).  I haven’t
>> > > tried it but it Should Work Fine.
[…]
> To put it simple, my use case is tor. I thought it would be enough to
> point to the host:port like I do for socks5 settings of applications.

The commit augments the environment in which guix-daemon is running such
that “http_proxy” is set.  AFAIK “http_proxy” only works with HTTP
proxies, not with SOCKS proxies.  You would have to set up an HTTP proxy
that forwards to Tor’s SOCKS proxy, e.g. with privoxy.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Planning for the next release

[Ludovic Courtès]

Hello Guix!

An update on the release that never comes.  ;-)

The main remaining item is merging UEFI support in ‘version-0.13.0’:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26815#173>.

The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved.

Not a release blocker, but a kind of general blocker: we have a ‘guix
offload’ bug for which we need more testers and hackers to get better
debugging info: <https://bugs.gnu.org/26976>.

Help welcome on all these fronts!

Ludo’.

Re: Planning for the next release

[Ricardo Wurmus]

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

> Hello Guix!
>
> An update on the release that never comes.  ;-)
>
> The main remaining item is merging UEFI support in ‘version-0.13.0’:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26815#173>.
>
> The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved.

I’ll try to take care of this tonight.

> Not a release blocker, but a kind of general blocker: we have a ‘guix
> offload’ bug for which we need more testers and hackers to get better
> debugging info: <https://bugs.gnu.org/26976>.

I’ll try to give this a try either tonight or tomorrow.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Planning for the next release

[Ludovic Courtès]

Hi!

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello Guix!
>>
>> An update on the release that never comes.  ;-)
>>
>> The main remaining item is merging UEFI support in ‘version-0.13.0’:
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26815#173>.

Marius already fixed this one.

>> The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved.
>
> I’ll try to take care of this tonight.
>
>> Not a release blocker, but a kind of general blocker: we have a ‘guix
>> offload’ bug for which we need more testers and hackers to get better
>> debugging info: <https://bugs.gnu.org/26976>.
>
> I’ll try to give this a try either tonight or tomorrow.

Great!

Regardless of what happens with #26976, I can run “make release” and
upload the tarballs tomorrow, and presumably send out the announcement
on Monday.

How does that sound?

Thanks,
Ludo’.

Re: Planning for the next release

[Ricardo Wurmus]

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

>>> Not a release blocker, but a kind of general blocker: we have a ‘guix
>>> offload’ bug for which we need more testers and hackers to get better
>>> debugging info: <https://bugs.gnu.org/26976>.
>>
>> I’ll try to give this a try either tonight or tomorrow.
>
> Great!
>
> Regardless of what happens with #26976, I can run “make release” and
> upload the tarballs tomorrow, and presumably send out the announcement
> on Monday.
>
> How does that sound?

That sounds good!

Should this bug be mentioned somewhere (in the release tarball) as a
known issue with 0.13.0?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Planning for the next release

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>>> Not a release blocker, but a kind of general blocker: we have a ‘guix
>>>> offload’ bug for which we need more testers and hackers to get better
>>>> debugging info: <https://bugs.gnu.org/26976>.
>>>
>>> I’ll try to give this a try either tonight or tomorrow.
>>
>> Great!
>>
>> Regardless of what happens with #26976, I can run “make release” and
>> upload the tarballs tomorrow, and presumably send out the announcement
>> on Monday.
>>
>> How does that sound?
>
> That sounds good!
>
> Should this bug be mentioned somewhere (in the release tarball) as a
> known issue with 0.13.0?

I don’t know, maybe not.

Ludo’.

Re: Planning for the next release

[Ludovic Courtès]

Hi again!

I build the installation image with from commit
96afb480f8165a315a69b1dd3a031e053044d3b2:

  ./pre-inst-env guix system disk-image --image-size=1.2G gnu/system/install.scm -K

and then ran QEMU on that image:

  qemu-system-x86_64 -enable-kvm -serial stdio \
    -net nic,model=virtio -net user /tmp/t.qcow

but that failed with:

--8<---------------cut here---------------start------------->8---
[    0.664746] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[    0.665664] List of all partitions:
[    0.666117] 0100           65536 ram0 
[    0.666118]  (driver?)
[    0.666865] 0101           65536 ram1 
[    0.666865]  (driver?)
[    0.667602] 0102           65536 ram2 
[    0.667602]  (driver?)
[    0.668354] 0103           65536 ram3 
[    0.668355]  (driver?)
[    0.669062] 0104           65536 ram4 
[    0.669063]  (driver?)
[    0.669931] 0105           65536 ram5 
[    0.669932]  (driver?)
[    0.670675] 0106           65536 ram6 
[    0.670675]  (driver?)
[    0.671383] 0107           65536 ram7 
[    0.671384]  (driver?)
[    0.673712] 0108           65536 ram8 
[    0.673716]  (driver?)
[    0.675340] 0109           65536 ram9 
[    0.675341]  (driver?)
[    0.676810] 010a           65536 ram10 
[    0.676812]  (driver?)
[    0.677862] 010b           65536 ram11 
[    0.677863]  (driver?)
[    0.678739] 010c           65536 ram12 
[    0.678740]  (driver?)
[    0.679441] 010d           65536 ram13 
[    0.679441]  (driver?)
[    0.680144] 010e           65536 ram14 
[    0.680145]  (driver?)
[    0.680902] 010f           65536 ram15 
[    0.680903]  (driver?)
[    0.681675] 0800         1258291 sda 
[    0.681676]  driver: sd
[    0.682435]   0801         1207091 sda1 897ff0a1-01
[    0.682436] 
[    0.683158]   0802           40960 sda2 897ff0a1-02
[    0.683159] 
[    0.683872] 0b00         1048575 sr0 
[    0.683873]  driver: sr
[    0.684558] No filesystem could mount root, tried: 
[    0.684559]  ext3
[    0.685052]  ext2
[    0.685253]  ext4
[    0.685449]  vfat
[    0.685645] 
[    0.686013] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
[    0.686831] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-gnu #1
[    0.687689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
[    0.690057] Call Trace:
[    0.690475]  dump_stack+0x63/0x90
[    0.690970]  panic+0xe4/0x22d
[    0.691426]  mount_block_root+0x27c/0x2bf
[    0.692042]  mount_root+0x65/0x68
[    0.692424]  prepare_namespace+0x16a/0x1a2
[    0.692872]  kernel_init_freeable+0x1f3/0x21c
[    0.693348]  ? rest_init+0x80/0x80
[    0.693720]  kernel_init+0xe/0x100
[    0.694069]  ret_from_fork+0x2c/0x40
[    0.694548] Kernel Offset: 0x2f000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    0.695494] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
--8<---------------cut here---------------end--------------->8---

Likewise, “make check-system TESTS=basic” fails like this:

--8<---------------cut here---------------start------------->8---
environment variable `PATH' set to `/gnu/store/445x4k15v3mlym7n0i1irqyiih0hxr1f-qemu-minimal-2.9.0/bin:/gnu/store/ddpg6rlr5f3xv8fjh8812ll9g584x51z-parted-3.2/sbin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/bin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/sbin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/bin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/sbin:/gnu/store/82kq5zzq9d7rsq0d9rjppp3528p4cg72-dosfstools-4.1/sbin:/gnu/store/z763jk8lkragpz2qr2wbrz946lgalx2h-sed-4.4/bin:/gnu/store/87sj03j9kwzhl9zr76gs2i8ill86ki95-grep-3.0/bin:/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin:/gnu/store/gdgrzf1y15scqwk1yzm51dc40g29vad9-findutils-4.6.0/bin:/gnu/store/55r4yg5iw9zh2j3zvzc6272k5xn4yxg4-gawk-4.1.4/bin'
creating partition table with 2 partitions...
parted: invalid option -- '1'
parted: invalid option -- '9'
parted: invalid option -- '9'
parted: invalid option -- '2'
parted: invalid option -- '2'
parted: invalid option -- '9'
parted: invalid option -- '4'
parted: invalid option -- '4'
parted: invalid option -- 'B'
parted: invalid option -- '1'
parted: invalid option -- '9'
parted: invalid option -- '9'
parted: invalid option -- '2'
parted: invalid option -- '2'
parted: invalid option -- '4'
parted: invalid option -- '3'
parted: invalid option -- '2'
parted: invalid option -- 'B'
Usage: parted [-hlmsv] [-a<align>] [DEVICE [COMMAND [PARAMETERS]]...]
ERROR: In procedure scm-error:
ERROR: failed to create partition table

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
[    1.032767] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
--8<---------------cut here---------------end--------------->8---

Any ideas what could be wrong?

Thanks in advance,  :-)
Ludo’.

Re: Planning for the next release

[Marius Bakke]

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

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

> Hi again!
>
> I build the installation image with from commit
> 96afb480f8165a315a69b1dd3a031e053044d3b2:
>
>   ./pre-inst-env guix system disk-image --image-size=1.2G gnu/system/install.scm -K
>
> and then ran QEMU on that image:
>
>   qemu-system-x86_64 -enable-kvm -serial stdio \
>     -net nic,model=virtio -net user /tmp/t.qcow
>
> but that failed with:
>
> --8<---------------cut here---------------start------------->8---
> [    0.664746] RAMDISK: Couldn't find valid RAM disk image starting at 0.
> [    0.665664] List of all partitions:
> [    0.666117] 0100           65536 ram0 
> [    0.666118]  (driver?)
> [    0.666865] 0101           65536 ram1 
> [    0.666865]  (driver?)
> [    0.667602] 0102           65536 ram2 
> [    0.667602]  (driver?)
> [    0.668354] 0103           65536 ram3 
> [    0.668355]  (driver?)
> [    0.669062] 0104           65536 ram4 
> [    0.669063]  (driver?)
> [    0.669931] 0105           65536 ram5 
> [    0.669932]  (driver?)
> [    0.670675] 0106           65536 ram6 
> [    0.670675]  (driver?)
> [    0.671383] 0107           65536 ram7 
> [    0.671384]  (driver?)
> [    0.673712] 0108           65536 ram8 
> [    0.673716]  (driver?)
> [    0.675340] 0109           65536 ram9 
> [    0.675341]  (driver?)
> [    0.676810] 010a           65536 ram10 
> [    0.676812]  (driver?)
> [    0.677862] 010b           65536 ram11 
> [    0.677863]  (driver?)
> [    0.678739] 010c           65536 ram12 
> [    0.678740]  (driver?)
> [    0.679441] 010d           65536 ram13 
> [    0.679441]  (driver?)
> [    0.680144] 010e           65536 ram14 
> [    0.680145]  (driver?)
> [    0.680902] 010f           65536 ram15 
> [    0.680903]  (driver?)
> [    0.681675] 0800         1258291 sda 
> [    0.681676]  driver: sd
> [    0.682435]   0801         1207091 sda1 897ff0a1-01
> [    0.682436] 
> [    0.683158]   0802           40960 sda2 897ff0a1-02
> [    0.683159] 
> [    0.683872] 0b00         1048575 sr0 
> [    0.683873]  driver: sr
> [    0.684558] No filesystem could mount root, tried: 
> [    0.684559]  ext3
> [    0.685052]  ext2
> [    0.685253]  ext4
> [    0.685449]  vfat
> [    0.685645] 
> [    0.686013] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
> [    0.686831] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-gnu #1
> [    0.687689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
> [    0.690057] Call Trace:
> [    0.690475]  dump_stack+0x63/0x90
> [    0.690970]  panic+0xe4/0x22d
> [    0.691426]  mount_block_root+0x27c/0x2bf
> [    0.692042]  mount_root+0x65/0x68
> [    0.692424]  prepare_namespace+0x16a/0x1a2
> [    0.692872]  kernel_init_freeable+0x1f3/0x21c
> [    0.693348]  ? rest_init+0x80/0x80
> [    0.693720]  kernel_init+0xe/0x100
> [    0.694069]  ret_from_fork+0x2c/0x40
> [    0.694548] Kernel Offset: 0x2f000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [    0.695494] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
> --8<---------------cut here---------------end--------------->8---

It looks like the initrd is becoming obese. Adding "-m 168M" makes it
boot (qemu defaults to 128MiB). Not sure what to do about it.

> Likewise, “make check-system TESTS=basic” fails like this:
>
> --8<---------------cut here---------------start------------->8---
> environment variable `PATH' set to `/gnu/store/445x4k15v3mlym7n0i1irqyiih0hxr1f-qemu-minimal-2.9.0/bin:/gnu/store/ddpg6rlr5f3xv8fjh8812ll9g584x51z-parted-3.2/sbin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/bin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/sbin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/bin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/sbin:/gnu/store/82kq5zzq9d7rsq0d9rjppp3528p4cg72-dosfstools-4.1/sbin:/gnu/store/z763jk8lkragpz2qr2wbrz946lgalx2h-sed-4.4/bin:/gnu/store/87sj03j9kwzhl9zr76gs2i8ill86ki95-grep-3.0/bin:/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin:/gnu/store/gdgrzf1y15scqwk1yzm51dc40g29vad9-findutils-4.6.0/bin:/gnu/store/55r4yg5iw9zh2j3zvzc6272k5xn4yxg4-gawk-4.1.4/bin'
> creating partition table with 2 partitions...
> parted: invalid option -- '1'
> parted: invalid option -- '9'
> parted: invalid option -- '9'
> parted: invalid option -- '2'
> parted: invalid option -- '2'
> parted: invalid option -- '9'
> parted: invalid option -- '4'
> parted: invalid option -- '4'
> parted: invalid option -- 'B'
> parted: invalid option -- '1'
> parted: invalid option -- '9'
> parted: invalid option -- '9'
> parted: invalid option -- '2'
> parted: invalid option -- '2'
> parted: invalid option -- '4'
> parted: invalid option -- '3'
> parted: invalid option -- '2'
> parted: invalid option -- 'B'
> Usage: parted [-hlmsv] [-a<align>] [DEVICE [COMMAND [PARAMETERS]]...]
> ERROR: In procedure scm-error:
> ERROR: failed to create partition table
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> [    1.032767] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> --8<---------------cut here---------------end--------------->8---

OMG. I've ran the other system tests, but somehow missed "basic". Oops!

Anyway, the problem is that the parted script gets a negative size for
TESTS=basic:

creating partition table with 2 partitions...                                         
DEBUG: (mkpart primary ext2 1048576B -19922944B set 1 boot on mkpart primary ext2 -19922432B 22020608B set 2 esp on)

The attached commit fixes it; although there are other default sizes in
(gnu system vm) that may need adjustment after
ecf5d5376979fadd971559367bf553df89fcc62b.

Currently running *all* system tests, but it's going to take a while!


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-vm-Increase-default-disk-sizes-to-account-for-ESP-pa.patch --]
[-- Type: text/x-patch, Size: 1260 bytes --]

From 4b012ae4a9be9b6fe566dc003197c740e5e35a86 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Sat, 20 May 2017 21:28:20 +0200
Subject: [PATCH] vm: Increase default disk sizes to account for ESP partition.

Fixes a test regression introduced by ecf5d5376979fadd971559367bf553df89fcc62b.

* gnu/system/vm.scm (system-qemu-image/shared-store-script): 30MiB -> 70MiB.
---
 gnu/system/vm.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index d282ba557..ad5e6b75b 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -499,7 +499,7 @@ with '-virtfs' options for the host file systems listed in SHARED-FS."
                                                 (mappings '())
                                                 full-boot?
                                                 (disk-image-size
-                                                 (* (if full-boot? 500 30)
+                                                 (* (if full-boot? 500 70)
                                                     (expt 2 20))))
   "Return a derivation that builds a script to run a virtual machine image of
 OS that shares its store with the host.
-- 
2.13.0


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

Re: Planning for the next release

[Marius Bakke]

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

Marius Bakke <mbakke@fastmail.com> writes:

> Anyway, the problem is that the parted script gets a negative size for
> TESTS=basic:
>
> creating partition table with 2 partitions...                                         
> DEBUG: (mkpart primary ext2 1048576B -19922944B set 1 boot on mkpart primary ext2 -19922432B 22020608B set 2 esp on)
>
> The attached commit fixes it; although there are other default sizes in
> (gnu system vm) that may need adjustment after
> ecf5d5376979fadd971559367bf553df89fcc62b.
>
> Currently running *all* system tests, but it's going to take a while!

All passed except nss-mdns, but it doesn't seem related. Is the below
patch good enough, or should we preemptively increase the other default
disk values in (gnu system vm) as well?

> From 4b012ae4a9be9b6fe566dc003197c740e5e35a86 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Sat, 20 May 2017 21:28:20 +0200
> Subject: [PATCH] vm: Increase default disk sizes to account for ESP partition.
>
> Fixes a test regression introduced by ecf5d5376979fadd971559367bf553df89fcc62b.
>
> * gnu/system/vm.scm (system-qemu-image/shared-store-script): 30MiB -> 70MiB.
> ---
>  gnu/system/vm.scm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
> index d282ba557..ad5e6b75b 100644
> --- a/gnu/system/vm.scm
> +++ b/gnu/system/vm.scm
> @@ -499,7 +499,7 @@ with '-virtfs' options for the host file systems listed in SHARED-FS."
>                                                  (mappings '())
>                                                  full-boot?
>                                                  (disk-image-size
> -                                                 (* (if full-boot? 500 30)
> +                                                 (* (if full-boot? 500 70)
>                                                      (expt 2 20))))
>    "Return a derivation that builds a script to run a virtual machine image of
>  OS that shares its store with the host.

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

Re: Planning for the next release

[Ludovic Courtès]

Hi!

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi again!
>>
>> I build the installation image with from commit
>> 96afb480f8165a315a69b1dd3a031e053044d3b2:
>>
>>   ./pre-inst-env guix system disk-image --image-size=1.2G gnu/system/install.scm -K
>>
>> and then ran QEMU on that image:
>>
>>   qemu-system-x86_64 -enable-kvm -serial stdio \
>>     -net nic,model=virtio -net user /tmp/t.qcow
>>
>> but that failed with:
>>
>> --8<---------------cut here---------------start------------->8---
>> [    0.664746] RAMDISK: Couldn't find valid RAM disk image starting at 0.
>> [    0.665664] List of all partitions:
>> [    0.666117] 0100           65536 ram0 
>> [    0.666118]  (driver?)
>> [    0.666865] 0101           65536 ram1 
>> [    0.666865]  (driver?)
>> [    0.667602] 0102           65536 ram2 
>> [    0.667602]  (driver?)
>> [    0.668354] 0103           65536 ram3 
>> [    0.668355]  (driver?)
>> [    0.669062] 0104           65536 ram4 
>> [    0.669063]  (driver?)
>> [    0.669931] 0105           65536 ram5 
>> [    0.669932]  (driver?)
>> [    0.670675] 0106           65536 ram6 
>> [    0.670675]  (driver?)
>> [    0.671383] 0107           65536 ram7 
>> [    0.671384]  (driver?)
>> [    0.673712] 0108           65536 ram8 
>> [    0.673716]  (driver?)
>> [    0.675340] 0109           65536 ram9 
>> [    0.675341]  (driver?)
>> [    0.676810] 010a           65536 ram10 
>> [    0.676812]  (driver?)
>> [    0.677862] 010b           65536 ram11 
>> [    0.677863]  (driver?)
>> [    0.678739] 010c           65536 ram12 
>> [    0.678740]  (driver?)
>> [    0.679441] 010d           65536 ram13 
>> [    0.679441]  (driver?)
>> [    0.680144] 010e           65536 ram14 
>> [    0.680145]  (driver?)
>> [    0.680902] 010f           65536 ram15 
>> [    0.680903]  (driver?)
>> [    0.681675] 0800         1258291 sda 
>> [    0.681676]  driver: sd
>> [    0.682435]   0801         1207091 sda1 897ff0a1-01
>> [    0.682436] 
>> [    0.683158]   0802           40960 sda2 897ff0a1-02
>> [    0.683159] 
>> [    0.683872] 0b00         1048575 sr0 
>> [    0.683873]  driver: sr
>> [    0.684558] No filesystem could mount root, tried: 
>> [    0.684559]  ext3
>> [    0.685052]  ext2
>> [    0.685253]  ext4
>> [    0.685449]  vfat
>> [    0.685645] 
>> [    0.686013] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
>> [    0.686831] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-gnu #1
>> [    0.687689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
>> [    0.690057] Call Trace:
>> [    0.690475]  dump_stack+0x63/0x90
>> [    0.690970]  panic+0xe4/0x22d
>> [    0.691426]  mount_block_root+0x27c/0x2bf
>> [    0.692042]  mount_root+0x65/0x68
>> [    0.692424]  prepare_namespace+0x16a/0x1a2
>> [    0.692872]  kernel_init_freeable+0x1f3/0x21c
>> [    0.693348]  ? rest_init+0x80/0x80
>> [    0.693720]  kernel_init+0xe/0x100
>> [    0.694069]  ret_from_fork+0x2c/0x40
>> [    0.694548] Kernel Offset: 0x2f000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
>> [    0.695494] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
>> --8<---------------cut here---------------end--------------->8---
>
> It looks like the initrd is becoming obese. Adding "-m 168M" makes it
> boot (qemu defaults to 128MiB). Not sure what to do about it.

Oh, that didn’t come to mind.  I’m pretty sure this is because we’re
pulling dynamically-linked stuff that bring in glibc and co.  I’ll take
a look tomorrow if nobody beats me.

>> Likewise, “make check-system TESTS=basic” fails like this:
>>
>> --8<---------------cut here---------------start------------->8---
>> environment variable `PATH' set to `/gnu/store/445x4k15v3mlym7n0i1irqyiih0hxr1f-qemu-minimal-2.9.0/bin:/gnu/store/ddpg6rlr5f3xv8fjh8812ll9g584x51z-parted-3.2/sbin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/bin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/sbin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/bin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/sbin:/gnu/store/82kq5zzq9d7rsq0d9rjppp3528p4cg72-dosfstools-4.1/sbin:/gnu/store/z763jk8lkragpz2qr2wbrz946lgalx2h-sed-4.4/bin:/gnu/store/87sj03j9kwzhl9zr76gs2i8ill86ki95-grep-3.0/bin:/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin:/gnu/store/gdgrzf1y15scqwk1yzm51dc40g29vad9-findutils-4.6.0/bin:/gnu/store/55r4yg5iw9zh2j3zvzc6272k5xn4yxg4-gawk-4.1.4/bin'
>> creating partition table with 2 partitions...
>> parted: invalid option -- '1'
>> parted: invalid option -- '9'
>> parted: invalid option -- '9'
>> parted: invalid option -- '2'
>> parted: invalid option -- '2'
>> parted: invalid option -- '9'
>> parted: invalid option -- '4'
>> parted: invalid option -- '4'
>> parted: invalid option -- 'B'
>> parted: invalid option -- '1'
>> parted: invalid option -- '9'
>> parted: invalid option -- '9'
>> parted: invalid option -- '2'
>> parted: invalid option -- '2'
>> parted: invalid option -- '4'
>> parted: invalid option -- '3'
>> parted: invalid option -- '2'
>> parted: invalid option -- 'B'
>> Usage: parted [-hlmsv] [-a<align>] [DEVICE [COMMAND [PARAMETERS]]...]
>> ERROR: In procedure scm-error:
>> ERROR: failed to create partition table
>>
>> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>> [    1.032767] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>> --8<---------------cut here---------------end--------------->8---
>
> OMG. I've ran the other system tests, but somehow missed "basic". Oops!
>
> Anyway, the problem is that the parted script gets a negative size for
> TESTS=basic:
>
> creating partition table with 2 partitions...                                         
> DEBUG: (mkpart primary ext2 1048576B -19922944B set 1 boot on mkpart primary ext2 -19922432B 22020608B set 2 esp on)
>
> The attached commit fixes it; although there are other default sizes in
> (gnu system vm) that may need adjustment after
> ecf5d5376979fadd971559367bf553df89fcc62b.
>
> Currently running *all* system tests, but it's going to take a while!

Great, thanks for taking the time.  (And yes, the nss-mdns has always
been unreliable…)

> From 4b012ae4a9be9b6fe566dc003197c740e5e35a86 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Sat, 20 May 2017 21:28:20 +0200
> Subject: [PATCH] vm: Increase default disk sizes to account for ESP partition.
> 
> Fixes a test regression introduced by ecf5d5376979fadd971559367bf553df89fcc62b.
> 
> * gnu/system/vm.scm (system-qemu-image/shared-store-script): 30MiB -> 70MiB.

LGTM, thank you!

Ludo’.

Re: Planning for the next release

[Ludovic Courtès]

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

>> It looks like the initrd is becoming obese. Adding "-m 168M" makes it
>> boot (qemu defaults to 128MiB). Not sure what to do about it.
>
> Oh, that didn’t come to mind.  I’m pretty sure this is because we’re
> pulling dynamically-linked stuff that bring in glibc and co.  I’ll take
> a look tomorrow if nobody beats me.

That was unionfs-fuse.  Fixed in
9f8d6eb24a5f193683076e16ffb68da18a537140!

Ludo’.

Re: Planning for the next release

[Ricardo Wurmus]

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

> Hello Guix!
>
> An update on the release that never comes.  ;-)
[…]

> The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved.

I just pushed commit 402f241da, which fills that section a bit.  Thank
you for the many bug fixes that I’ve combed through just now!

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Planning for the next release

[Marius Bakke]

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

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

>    3. UEFI support documented and possibly improved.
>
>       We can certainly document the UEFI setup and add the /boot/efi
>       partition in some of the ‘operating-system’ examples.
>
>       The more difficult part is the installation: do we need to make a
>       second, UEFI-specific, installation image?  When I installed
>       GuixSD on UEFI, I booted our installation image as “legacy”, but
>       then GRUB would default to a legacy install, not a UEFI install:
>
>         https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
>
>       I’m not sure exactly what needs to be done.  Thoughts?

I plan to work on this over the next few days. The most common way is to
create a "hybrid" disk image that supports both UEFI and BIOS boot. IIRC
Debian achieves this by using Isolinux to create the EFI payload and
chainload to Grub. More information next week :-)

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

Re: Planning for the next release

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>    3. UEFI support documented and possibly improved.
>>
>>       We can certainly document the UEFI setup and add the /boot/efi
>>       partition in some of the ‘operating-system’ examples.
>>
>>       The more difficult part is the installation: do we need to make a
>>       second, UEFI-specific, installation image?  When I installed
>>       GuixSD on UEFI, I booted our installation image as “legacy”, but
>>       then GRUB would default to a legacy install, not a UEFI install:
>>
>>         https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
>>
>>       I’m not sure exactly what needs to be done.  Thoughts?
>
> I plan to work on this over the next few days. The most common way is to
> create a "hybrid" disk image that supports both UEFI and BIOS boot. IIRC
> Debian achieves this by using Isolinux to create the EFI payload and
> chainload to Grub. More information next week :-)

Awesome, thanks for volunteering!

Ludo’.

UEFI support in boot image

[Marius Bakke]

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

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

> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>>    3. UEFI support documented and possibly improved.
>>>
>>>       We can certainly document the UEFI setup and add the /boot/efi
>>>       partition in some of the ‘operating-system’ examples.
>>>
>>>       The more difficult part is the installation: do we need to make a
>>>       second, UEFI-specific, installation image?  When I installed
>>>       GuixSD on UEFI, I booted our installation image as “legacy”, but
>>>       then GRUB would default to a legacy install, not a UEFI install:
>>>
>>>         https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
>>>
>>>       I’m not sure exactly what needs to be done.  Thoughts?
>>
>> I plan to work on this over the next few days. The most common way is to
>> create a "hybrid" disk image that supports both UEFI and BIOS boot. IIRC
>> Debian achieves this by using Isolinux to create the EFI payload and
>> chainload to Grub. More information next week :-)
>
> Awesome, thanks for volunteering!

Apologies for the late follow-up, but I finally found some time to work
on this.

I've attached a few patches as a humble beginning, but currently the
"format-partition" code in (gnu build vm) needs to learn some
filesystem-specific parameters. So, I don't think it will be ready for
the upcoming release.

I have also done some reading and don't think we can use isolinux as it
requires an image in ISO 9660 format. Nor does the syslinux utilities
actually support chainloading grub from UEFI as I had hoped.

So I think we'll have to offer UEFI as a standalone image, at least to
begin with. Unfortunately I also believe it needs to be generated from a
UEFI system, but this grub limitation can hopefully be lifted.

Anyway, here is the current status (advice on the FIXME appreciated):


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: uefi-boot.patch --]
[-- Type: text/x-patch, Size: 7643 bytes --]

From 25b01f9a219338580b6f7a7449bba8ff90c2176c Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Tue, 11 Apr 2017 10:47:38 +0200
Subject: [PATCH 1/4] vm: Add support for arbitrary partition flags.

* gnu/build/vm.scm (<partition>): Change BOOTABLE? to FLAGS.
(initialize-partition-table): Pass each flag to parted.
(initialize-hard-disk): Search for root partition by "boot" flag.
* gnu/system/vm.scm (qemu-image): Adjust partitions accordingly.
---
 gnu/build/vm.scm  | 22 ++++++++++++++++------
 gnu/system/vm.scm |  2 +-
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/gnu/build/vm.scm b/gnu/build/vm.scm
index 1eb9a4c45..f6a028868 100644
--- a/gnu/build/vm.scm
+++ b/gnu/build/vm.scm
@@ -41,7 +41,7 @@
             partition-size
             partition-file-system
             partition-label
-            partition-bootable?
+            partition-flags
             partition-initializer
 
             root-partition-initializer
@@ -141,7 +141,7 @@ the #:references-graphs parameter of 'derivation'."
   (size        partition-size)
   (file-system partition-file-system (default "ext4"))
   (label       partition-label (default #f))
-  (bootable?   partition-bootable? (default #f))
+  (flags       partition-flags (default '()))
   (initializer partition-initializer (default (const #t))))
 
 (define (fold2 proc seed1 seed2 lst)              ;TODO: factorize
@@ -168,9 +168,10 @@ actual /dev name based on DEVICE."
     (cons* "mkpart" "primary" "ext2"
            (format #f "~aB" offset)
            (format #f "~aB" (+ offset (partition-size part)))
-           (if (partition-bootable? part)
-               `("set" ,(number->string index) "boot" "on")
-               '())))
+           (apply append (map (lambda (flag)
+                                (cons* "set" (number->string index) flag
+                                       "on" '()))
+                              (partition-flags part)))))
 
   (define (options partitions offset)
     (let loop ((partitions partitions)
@@ -300,8 +301,17 @@ in PARTITIONS, and using BOOTCFG as its bootloader configuration file.
 
 Each partition is initialized by calling its 'initializer' procedure,
 passing it a directory name where it is mounted."
+
+  (define (find-root-partition partitions)
+    "Return the first partition found with the boot flag set."
+    ;; FIXME: This probably does not work. What's the best way to do this?
+    (find (match-lambda
+            (($ <partition> _ _ _ _ flags)
+             (member "boot" flags)))
+          partitions))
+
   (let* ((partitions (initialize-partition-table device partitions))
-         (root       (find partition-bootable? partitions))
+         (root       (find-root-partition partitions))
          (target     "/fs"))
     (unless root
       (error "no bootable partition specified" partitions))
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 374d8b663..e8a8463d5 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -229,7 +229,7 @@ the image."
                                                 (* 10 (expt 2 20))))
                                      (label #$file-system-label)
                                      (file-system #$file-system-type)
-                                     (bootable? #t)
+                                     (flags '("boot"))
                                      (initializer initialize)))))
              (initialize-hard-disk "/dev/vda"
                                    #:partitions partitions
-- 
2.12.2


From 9db90ea41a94ecbe42bba88de1c2e3ac607d5ea4 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Tue, 11 Apr 2017 10:55:22 +0200
Subject: [PATCH 2/4] vm: Unconditionally add a small ESP partition.

* gnu/system/vm.scm (qemu-image): Append 20MB FAT32 partition.
---
 gnu/system/vm.scm | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index e8a8463d5..867802342 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -226,11 +226,18 @@ the image."
                                #:system-directory #$os-derivation))
                   (partitions (list (partition
                                      (size #$(- disk-image-size
-                                                (* 10 (expt 2 20))))
+                                                (* 30 (expt 2 20))))
                                      (label #$file-system-label)
                                      (file-system #$file-system-type)
                                      (flags '("boot"))
-                                     (initializer initialize)))))
+                                     (initializer initialize))
+                                    (partition
+                                     ;; Append a small FAT32 partition for
+                                     ;; use with UEFI bootloaders.
+                                     (size (* 20 (expt 2 20)))
+                                     (label "gnu-esp")
+                                     (file-system "vfat")
+                                     (flags '("esp"))))))
              (initialize-hard-disk "/dev/vda"
                                    #:partitions partitions
                                    #:grub.cfg #$grub-configuration)
-- 
2.12.2


From 4306bae25d6110ec52b8bbe3ad8b55f2c4c18fca Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Mon, 17 Apr 2017 22:21:28 +0200
Subject: [PATCH 3/4] gnu: dosfstools: Enable compatibility symlinks.

* gnu/packages/disk.scm (dosfstools)[arguments]<#:configure-flags>: New
parameter.
---
 gnu/packages/disk.scm | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/disk.scm b/gnu/packages/disk.scm
index 93895278d..c31107fcf 100644
--- a/gnu/packages/disk.scm
+++ b/gnu/packages/disk.scm
@@ -196,7 +196,10 @@ to recover data more efficiently by only reading the necessary blocks.")
          "0wy13i3i4x2bw1hf5m4fd0myh61f9bcrs035fdlf6gyc1jksrcp6"))))
     (build-system gnu-build-system)
     (arguments
-     `(#:make-flags (list (string-append "PREFIX=" %output)
+     `(;; The "--enable-compat-symlinks" flag is needed so that "mkfs.vfat"
+       ;; is created. The guix build code expects this to exist.
+       #:configure-flags '("--enable-compat-symlinks")
+       #:make-flags (list (string-append "PREFIX=" %output)
                           "CC=gcc")))
     (native-inputs
      `(("xxd" ,vim))) ; for tests
-- 
2.12.2


From d3e733739edebfd42efd70e7cc6335f3862f1ed5 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Mon, 17 Apr 2017 22:25:43 +0200
Subject: [PATCH 4/4] gnu: vm: Add FAT32 utilities in base image.

* gnu/system/vm.scm (qemu-image): Add DOSFSTOOLS to the closure.
---
 gnu/system/vm.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 867802342..0f4e3ef7d 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -201,7 +201,7 @@ the image."
                       (guix build utils))
 
          (let ((inputs
-                '#$(append (list qemu parted grub e2fsprogs)
+                '#$(append (list qemu parted grub e2fsprogs dosfstools)
                            (map canonical-package
                                 (list sed grep coreutils findutils gawk))
                            (if register-closures? (list guix) '())))
-- 
2.12.2


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

Re: UEFI support in boot image

[Ludovic Courtès]

Hi Marius!

Marius Bakke <mbakke@fastmail.com> skribis:

> I've attached a few patches as a humble beginning, but currently the
> "format-partition" code in (gnu build vm) needs to learn some
> filesystem-specific parameters. So, I don't think it will be ready for
> the upcoming release.
>
> I have also done some reading and don't think we can use isolinux as it
> requires an image in ISO 9660 format. Nor does the syslinux utilities
> actually support chainloading grub from UEFI as I had hoped.

OK.

> So I think we'll have to offer UEFI as a standalone image, at least to
> begin with. Unfortunately I also believe it needs to be generated from a
> UEFI system, but this grub limitation can hopefully be lifted.

Providing a separate standalone image is reasonable IMO.

Anyway, I’m happy to see this patch set!

> From 25b01f9a219338580b6f7a7449bba8ff90c2176c Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Tue, 11 Apr 2017 10:47:38 +0200
> Subject: [PATCH 1/4] vm: Add support for arbitrary partition flags.
>
> * gnu/build/vm.scm (<partition>): Change BOOTABLE? to FLAGS.
> (initialize-partition-table): Pass each flag to parted.
> (initialize-hard-disk): Search for root partition by "boot" flag.
> * gnu/system/vm.scm (qemu-image): Adjust partitions accordingly.

[...]

> @@ -141,7 +141,7 @@ the #:references-graphs parameter of 'derivation'."
>    (size        partition-size)
>    (file-system partition-file-system (default "ext4"))
>    (label       partition-label (default #f))
> -  (bootable?   partition-bootable? (default #f))
> +  (flags       partition-flags (default '()))
>    (initializer partition-initializer (default (const #t))))

So ‘flags’ must be a list of strings, and each string is something
Parted recognizes, right?

It would be slightly nicer to make it a list of symbols.

> +  (define (find-root-partition partitions)
> +    "Return the first partition found with the boot flag set."
> +    ;; FIXME: This probably does not work. What's the best way to do this?
> +    (find (match-lambda
> +            (($ <partition> _ _ _ _ flags)
> +             (member "boot" flags)))
> +          partitions))

Why wouldn’t it work?  LGTM.

BTW, in this case, I’d recommend using ‘partition-flags’ instead of
‘match’ with the 4 wildcards; probably safer.  :-)

That said, it’s probably best to keep

  (define (partition-bootable? partition)
    (member "boot" (partition-flags partition)))

>    (let* ((partitions (initialize-partition-table device partitions))
> -         (root       (find partition-bootable? partitions))
> +         (root       (find-root-partition partitions))

… and keep this line unchanged (‘find-foo’ procedures are an
anti-pattern in a way.)

> From 9db90ea41a94ecbe42bba88de1c2e3ac607d5ea4 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Tue, 11 Apr 2017 10:55:22 +0200
> Subject: [PATCH 2/4] vm: Unconditionally add a small ESP partition.
>
> * gnu/system/vm.scm (qemu-image): Append 20MB FAT32 partition.

[...]

>                    (partitions (list (partition
>                                       (size #$(- disk-image-size
> -                                                (* 10 (expt 2 20))))
> +                                                (* 30 (expt 2 20))))
>                                       (label #$file-system-label)
>                                       (file-system #$file-system-type)
>                                       (flags '("boot"))
> -                                     (initializer initialize)))))
> +                                     (initializer initialize))
> +                                    (partition
> +                                     ;; Append a small FAT32 partition for
> +                                     ;; use with UEFI bootloaders.
> +                                     (size (* 20 (expt 2 20)))
> +                                     (label "gnu-esp")
> +                                     (file-system "vfat")
> +                                     (flags '("esp"))))))

Should we do it conditionally, only when targeting UEFI?

(BTW, what’s “esp”?)

> From 4306bae25d6110ec52b8bbe3ad8b55f2c4c18fca Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Mon, 17 Apr 2017 22:21:28 +0200
> Subject: [PATCH 3/4] gnu: dosfstools: Enable compatibility symlinks.
>
> * gnu/packages/disk.scm (dosfstools)[arguments]<#:configure-flags>: New
> parameter.

LGTM.

> From d3e733739edebfd42efd70e7cc6335f3862f1ed5 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Mon, 17 Apr 2017 22:25:43 +0200
> Subject: [PATCH 4/4] gnu: vm: Add FAT32 utilities in base image.
>
> * gnu/system/vm.scm (qemu-image): Add DOSFSTOOLS to the closure.

OK.

Thank you for working on it!

Ludo’.

Re: UEFI support in boot image

[Marius Bakke]

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

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

>> @@ -141,7 +141,7 @@ the #:references-graphs parameter of 'derivation'."
>>    (size        partition-size)
>>    (file-system partition-file-system (default "ext4"))
>>    (label       partition-label (default #f))
>> -  (bootable?   partition-bootable? (default #f))
>> +  (flags       partition-flags (default '()))
>>    (initializer partition-initializer (default (const #t))))
>
> So ‘flags’ must be a list of strings, and each string is something
> Parted recognizes, right?

Correct.

> It would be slightly nicer to make it a list of symbols.

Good idea.

>> +  (define (find-root-partition partitions)
>> +    "Return the first partition found with the boot flag set."
>> +    ;; FIXME: This probably does not work. What's the best way to do this?
>> +    (find (match-lambda
>> +            (($ <partition> _ _ _ _ flags)
>> +             (member "boot" flags)))
>> +          partitions))
>
> Why wouldn’t it work?  LGTM.
>
> BTW, in this case, I’d recommend using ‘partition-flags’ instead of
> ‘match’ with the 4 wildcards; probably safer.  :-)
>
> That said, it’s probably best to keep
>
>   (define (partition-bootable? partition)
>     (member "boot" (partition-flags partition)))
>
>>    (let* ((partitions (initialize-partition-table device partitions))
>> -         (root       (find partition-bootable? partitions))
>> +         (root       (find-root-partition partitions))
>
> … and keep this line unchanged (‘find-foo’ procedures are an
> anti-pattern in a way.)

That's much better indeed. Thanks!

>> From 9db90ea41a94ecbe42bba88de1c2e3ac607d5ea4 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke <mbakke@fastmail.com>
>> Date: Tue, 11 Apr 2017 10:55:22 +0200
>> Subject: [PATCH 2/4] vm: Unconditionally add a small ESP partition.
>>
>> * gnu/system/vm.scm (qemu-image): Append 20MB FAT32 partition.
>
> [...]
>
>>                    (partitions (list (partition
>>                                       (size #$(- disk-image-size
>> -                                                (* 10 (expt 2 20))))
>> +                                                (* 30 (expt 2 20))))
>>                                       (label #$file-system-label)
>>                                       (file-system #$file-system-type)
>>                                       (flags '("boot"))
>> -                                     (initializer initialize)))))
>> +                                     (initializer initialize))
>> +                                    (partition
>> +                                     ;; Append a small FAT32 partition for
>> +                                     ;; use with UEFI bootloaders.
>> +                                     (size (* 20 (expt 2 20)))
>> +                                     (label "gnu-esp")
>> +                                     (file-system "vfat")
>> +                                     (flags '("esp"))))))
>
> Should we do it conditionally, only when targeting UEFI?

Probably, but I'm not sure which condition (maybe 'uefi-disk-image'?).
Will revisit this once it works :)

> (BTW, what’s “esp”?)

ESP is short for 'EFI System Partition' (I'll mention this in the code
somewhere). UEFI firmwares scans each connected I/O device looking for
this partition, which must be flagged as such and FAT-formatted.

Thanks for the feedback! I'll keep hammering at this and should
hopefully have something usable within a few weeks. Currently, need to
figure out why the qemu builder can't find the ISO8859-1 kernel module.

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

Re: UEFI support in boot image

[Ludovic Courtès]

Hello Marius,

Marius Bakke <mbakke@fastmail.com> skribis:

> Thanks for the feedback! I'll keep hammering at this and should
> hopefully have something usable within a few weeks. Currently, need to
> figure out why the qemu builder can't find the ISO8859-1 kernel module.

Any news from the front?  :-)

Ludo’.

Re: UEFI support in boot image

[Marius Bakke]

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

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

> Hello Marius,
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Thanks for the feedback! I'll keep hammering at this and should
>> hopefully have something usable within a few weeks. Currently, need to
>> figure out why the qemu builder can't find the ISO8859-1 kernel module.
>
> Any news from the front?  :-)

I'm sorry, I haven't been able to work on this at all. Will pick it up again
now though, if we're lucky I might have something usable tomorrow.

How imminent is the release?

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

Re: UEFI support in boot image

[Marius Bakke]

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

Marius Bakke <mbakke@fastmail.com> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello Marius,
>>
>> Marius Bakke <mbakke@fastmail.com> skribis:
>>
>>> Thanks for the feedback! I'll keep hammering at this and should
>>> hopefully have something usable within a few weeks. Currently, need to
>>> figure out why the qemu builder can't find the ISO8859-1 kernel module.
>>
>> Any news from the front?  :-)
>
> I'm sorry, I haven't been able to work on this at all. Will pick it up again
> now though, if we're lucky I might have something usable tomorrow.

See https://bugs.gnu.org/26815 :-)


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

Re: Planning for the next release

[Leo Famulari]

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

On Thu, Mar 30, 2017 at 02:37:47PM +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> It’s time to plan for the next release!  Here’s what we maintainers
> think should be done for the next release, which would hopefully happen
> within less than a month:
> 
> Please share your thoughts!

I just pushed a tzdata update to a new staging branch. Let's build and
merge this branch before the next release.

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

Re: Planning for the next release

[Ludovic Courtès]

Hi!

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Mar 30, 2017 at 02:37:47PM +0200, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> It’s time to plan for the next release!  Here’s what we maintainers
>> think should be done for the next release, which would hopefully happen
>> within less than a month:
>> 
>> Please share your thoughts!
>
> I just pushed a tzdata update to a new staging branch. Let's build and
> merge this branch before the next release.

We can do that, but should it be a blocker?  Anyway, let’s try and we’ll
see.

BTW:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix refresh -l -e '(@@ (gnu packages base) tzdata)'
Building the following 239 packages would ensure 442 dependent packages are rebuilt
--8<---------------cut here---------------end--------------->8---

I was expecting to see fewer packages depending on this one since
3ffaec136fab017e6cc094287da207cf30f05974.  Perhaps in the ‘staging’
branch we should migrate a few more packages to ‘tzdata-2017a’?

Thanks,
Ludo’.

Re: Planning for the next release

[Leo Famulari]

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

On Mon, Apr 03, 2017 at 10:26:54AM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > I just pushed a tzdata update to a new staging branch. Let's build and
> > merge this branch before the next release.
> 
> We can do that, but should it be a blocker?  Anyway, let’s try and we’ll
> see.
> 
> BTW:
> 
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix refresh -l -e '(@@ (gnu packages base) tzdata)'
> Building the following 239 packages would ensure 442 dependent packages are rebuilt
> --8<---------------cut here---------------end--------------->8---

It used to be about ~1400 :)

> I was expecting to see fewer packages depending on this one since
> 3ffaec136fab017e6cc094287da207cf30f05974.  Perhaps in the ‘staging’
> branch we should migrate a few more packages to ‘tzdata-2017a’?

The bulk of it comes through libical, so I'm not sure we can get it
under 300 rebuilds without removing tzdata from libical.

Having said that, I'm not sure if libical even needs a run-time
reference to tzdata. At least, we didn't notice that it was missing for
~1 year:

<https://bugs.gnu.org/26039>

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

Re: Planning for the next release

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Mon, Apr 03, 2017 at 10:26:54AM +0200, Ludovic Courtès wrote:
>> Leo Famulari <leo@famulari.name> skribis:
>> > I just pushed a tzdata update to a new staging branch. Let's build and
>> > merge this branch before the next release.
>> 
>> We can do that, but should it be a blocker?  Anyway, let’s try and we’ll
>> see.
>> 
>> BTW:
>> 
>> --8<---------------cut here---------------start------------->8---
>> $ ./pre-inst-env guix refresh -l -e '(@@ (gnu packages base) tzdata)'
>> Building the following 239 packages would ensure 442 dependent packages are rebuilt
>> --8<---------------cut here---------------end--------------->8---
>
> It used to be about ~1400 :)

Right, definitely an improvement!

>> I was expecting to see fewer packages depending on this one since
>> 3ffaec136fab017e6cc094287da207cf30f05974.  Perhaps in the ‘staging’
>> branch we should migrate a few more packages to ‘tzdata-2017a’?
>
> The bulk of it comes through libical, so I'm not sure we can get it
> under 300 rebuilds without removing tzdata from libical.
>
> Having said that, I'm not sure if libical even needs a run-time
> reference to tzdata. At least, we didn't notice that it was missing for
> ~1 year:
>
> <https://bugs.gnu.org/26039>

Heh, indeed.  I guess we can address it at a later stage, whenever is
convenient.

Ludo’.

Re: Planning for the next release

[Ludovic Courtès]

Hello Guix!

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

>    1. ‘core-updates’ merged.  We’re almost there!
>
>    2. ‘wip-installer’ retested, and probably merged.
>
>       I think the prerequisite for it would be to do some more testing.
>       Last time people reported glitches here and there but John has
>       done quite a bit of work since then.  John: what about doing
>       another round of tests?
>
>       In the installation image, we should probably make the installer
>       optional and mark it as “beta” or something like that.  That will
>       leave us time to iron out remaining issues, and will avoid having
>       people expect a rock-solid Debian-style installer.
>
>       As far as review is concerned, we can probably do a quick and
>       lightweight review process since that’s quite a big chunk of code
>       and we don’t want the branch to block indefinitely.  So we can do
>       that quick process, and then incrementally improve it if needed.
>       I think it’s a reasonable approach given that the installer is
>       mostly an independent component.
>
>       John, everyone: thoughts?
>
>    3. UEFI support documented and possibly improved.
>
>       We can certainly document the UEFI setup and add the /boot/efi
>       partition in some of the ‘operating-system’ examples.
>
>       The more difficult part is the installation: do we need to make a
>       second, UEFI-specific, installation image?  When I installed
>       GuixSD on UEFI, I booted our installation image as “legacy”, but
>       then GRUB would default to a legacy install, not a UEFI install:
>
>         https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
>
>       I’m not sure exactly what needs to be done.  Thoughts?
>
>    4. Fix low-hanging fruits at <https://bugs.gnu.org/guix>; your help
>       welcome!

I’m going to be mostly away for a week, but it would be nice if we could
release after that, wouldn’t it?

I think we’ll have to postpone work on the installer though since that
would leave too little time now.

WDYT?

Thanks,
Ludo’.

Re: Planning for the next release

[Leo Famulari]

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

On Sat, Apr 22, 2017 at 12:27:11AM +0200, Ludovic Courtès wrote:
> I’m going to be mostly away for a week, but it would be nice if we could
> release after that, wouldn’t it?
> 
> I think we’ll have to postpone work on the installer though since that
> would leave too little time now.
> 
> WDYT?

Sounds good to me!

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

Re: Planning for the next release

[Ricardo Wurmus]

Leo Famulari <leo@famulari.name> writes:

> On Sat, Apr 22, 2017 at 12:27:11AM +0200, Ludovic Courtès wrote:
>> I’m going to be mostly away for a week, but it would be nice if we could
>> release after that, wouldn’t it?
>> 
>> I think we’ll have to postpone work on the installer though since that
>> would leave too little time now.
>> 
>> WDYT?
>
> Sounds good to me!

I also agree.  Looking forward to a new release!

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Planning for the next release

[Ludovic Courtès]

Hello Guix!

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

> It’s time to plan for the next release!  Here’s what we maintainers
> think should be done for the next release, which would hopefully happen
> within less than a month:
>
>    1. ‘core-updates’ merged.  We’re almost there!
>
>    2. ‘wip-installer’ retested, and probably merged.
>
>       I think the prerequisite for it would be to do some more testing.
>       Last time people reported glitches here and there but John has
>       done quite a bit of work since then.  John: what about doing
>       another round of tests?
>
>       In the installation image, we should probably make the installer
>       optional and mark it as “beta” or something like that.  That will
>       leave us time to iron out remaining issues, and will avoid having
>       people expect a rock-solid Debian-style installer.
>
>       As far as review is concerned, we can probably do a quick and
>       lightweight review process since that’s quite a big chunk of code
>       and we don’t want the branch to block indefinitely.  So we can do
>       that quick process, and then incrementally improve it if needed.
>       I think it’s a reasonable approach given that the installer is
>       mostly an independent component.
>
>       John, everyone: thoughts?
>
>    3. UEFI support documented and possibly improved.
>
>       We can certainly document the UEFI setup and add the /boot/efi
>       partition in some of the ‘operating-system’ examples.
>
>       The more difficult part is the installation: do we need to make a
>       second, UEFI-specific, installation image?  When I installed
>       GuixSD on UEFI, I booted our installation image as “legacy”, but
>       then GRUB would default to a legacy install, not a UEFI install:
>
>         https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
>
>       I’m not sure exactly what needs to be done.  Thoughts?
>
>    4. Fix low-hanging fruits at <https://bugs.gnu.org/guix>; your help
>       welcome!
>
> Please share your thoughts!

With UEFI (almost) ready, Guile 2.2 in the house, and “make release”,
should we aim for next week (like Wed. 17th)?  Can we focus on polishing
the remaining bits and testing?

If the schedule turns out to be too tight, we could move to the week
after.

Thoughts?

Ludo’.

Re: Planning for the next release

[Ricardo Wurmus]

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

> Hello Guix!
>
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> It’s time to plan for the next release!  Here’s what we maintainers
>> think should be done for the next release, which would hopefully happen
>> within less than a month:
>>
>>    1. ‘core-updates’ merged.  We’re almost there!
>>
>>    2. ‘wip-installer’ retested, and probably merged.
>>
>>       I think the prerequisite for it would be to do some more testing.
>>       Last time people reported glitches here and there but John has
>>       done quite a bit of work since then.  John: what about doing
>>       another round of tests?
>>
>>       In the installation image, we should probably make the installer
>>       optional and mark it as “beta” or something like that.  That will
>>       leave us time to iron out remaining issues, and will avoid having
>>       people expect a rock-solid Debian-style installer.
>>
>>       As far as review is concerned, we can probably do a quick and
>>       lightweight review process since that’s quite a big chunk of code
>>       and we don’t want the branch to block indefinitely.  So we can do
>>       that quick process, and then incrementally improve it if needed.
>>       I think it’s a reasonable approach given that the installer is
>>       mostly an independent component.
>>
>>       John, everyone: thoughts?
>>
>>    3. UEFI support documented and possibly improved.
>>
>>       We can certainly document the UEFI setup and add the /boot/efi
>>       partition in some of the ‘operating-system’ examples.
>>
>>       The more difficult part is the installation: do we need to make a
>>       second, UEFI-specific, installation image?  When I installed
>>       GuixSD on UEFI, I booted our installation image as “legacy”, but
>>       then GRUB would default to a legacy install, not a UEFI install:
>>
>>         https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
>>
>>       I’m not sure exactly what needs to be done.  Thoughts?
>>
>>    4. Fix low-hanging fruits at <https://bugs.gnu.org/guix>; your help
>>       welcome!
>>
>> Please share your thoughts!
>
> With UEFI (almost) ready, Guile 2.2 in the house, and “make release”,
> should we aim for next week (like Wed. 17th)?  Can we focus on polishing
> the remaining bits and testing?
>
> If the schedule turns out to be too tight, we could move to the week
> after.

I’d like to merge wip-installer, but not start it by default.  It would
be a shame to see the branch bit-rot.

We also need to fix the glibc on hurd (the patch for i686 should not be
applied there), but I haven’t been able to reproduce the failure on
hydra.  https://hydra.gnu.org/build/2036383/nixlog/1/raw

What do you think?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Planning for the next release

[Hartmut Goebel]

Am 12.05.2017 um 07:45 schrieb Ricardo Wurmus:
> > With UEFI (almost) ready, Guile 2.2 in the house, and “make release”,
> > should we aim for next week (like Wed. 17th)?  Can we focus on polishing
> > the remaining bits and testing?
> >
> > If the schedule turns out to be too tight, we could move to the week
> > after.

KDE has a severe security error regarding KAuth and dbus [1]. I suggest
updating he frameworks to 5.34, which is scheduled for tomorrow [2].
Alternatively we could try to integrate the patches mentioned at [1].

[1] https://www.kde.org/info/security/advisory-20170510-1.txt
[2] https://www.kde-neon.de/kde-release-termine/?event_id1=27

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Planning for the next release

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

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

[...]

>> With UEFI (almost) ready, Guile 2.2 in the house, and “make release”,
>> should we aim for next week (like Wed. 17th)?  Can we focus on polishing
>> the remaining bits and testing?
>>
>> If the schedule turns out to be too tight, we could move to the week
>> after.
>
> I’d like to merge wip-installer, but not start it by default.  It would
> be a shame to see the branch bit-rot.

I agree we shouldn’t let it bitrot.  Earlier I suggested postponing it
though, because we wouldn’t have time to test it (nobody is currently
working on it AFAIK):

  https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00491.html

WDYT?

> We also need to fix the glibc on hurd (the patch for i686 should not be
> applied there), but I haven’t been able to reproduce the failure on
> hydra.  https://hydra.gnu.org/build/2036383/nixlog/1/raw

Cross-compilation to GNU/Hurd from x86_64-linux-gnu works:

  $ guix build sed --target=i586-pc-gnu
  /gnu/store/rd2jngvxbyk5a1yy2ysd0d3wwkbw0pmc-sed-4.4

It would be better to fix cross builds from i686 as well.  I can take a
look but I wouldn’t consider it a blocker.

Thoughts?

Thanks,
Ludo’.

Re: Planning for the next release

[Ricardo Wurmus]

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

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> With UEFI (almost) ready, Guile 2.2 in the house, and “make release”,
>>> should we aim for next week (like Wed. 17th)?  Can we focus on polishing
>>> the remaining bits and testing?
>>>
>>> If the schedule turns out to be too tight, we could move to the week
>>> after.
>>
>> I’d like to merge wip-installer, but not start it by default.  It would
>> be a shame to see the branch bit-rot.
>
> I agree we shouldn’t let it bitrot.  Earlier I suggested postponing it
> though, because we wouldn’t have time to test it (nobody is currently
> working on it AFAIK):
>
>   https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00491.html
>
> WDYT?

Okay, let’s merge it some time after the release to be sure that it
doesn’t break anything.

>> We also need to fix the glibc on hurd (the patch for i686 should not be
>> applied there), but I haven’t been able to reproduce the failure on
>> hydra.  https://hydra.gnu.org/build/2036383/nixlog/1/raw
>
> Cross-compilation to GNU/Hurd from x86_64-linux-gnu works:
>
>   $ guix build sed --target=i586-pc-gnu
>   /gnu/store/rd2jngvxbyk5a1yy2ysd0d3wwkbw0pmc-sed-4.4
>
> It would be better to fix cross builds from i686 as well.  I can take a
> look but I wouldn’t consider it a blocker.

You don’t need to spend time on this.  I didn’t know that it’s a cross
build *from* i686 that’s failing.  Earlier I didn’t find the right
incantation to reproduce that failing build, but now I should be able to
figure it out and fix it.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Fwd: Re: Planning for the next release

[Manolis Ragkousis]

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

Forgot to cc the list
---------- Forwarded message ----------
From: "Manolis Ragkousis" <manolis837@gmail.com>
Date: May 12, 2017 21:17
Subject: Re: Planning for the next release
To: "Ricardo Wurmus" <rekado@elephly.net>
Cc:

Hey Ricardo,

On May 12, 2017 08:45, "Ricardo Wurmus" <rekado@elephly.net> wrote:


We also need to fix the glibc on hurd (the patch for i686 should not be
applied there), but I haven’t been able to reproduce the failure on
hydra.  https://hydra.gnu.org/build/2036383/nixlog/1/raw

What do you think?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net


I was not aware of this problem. Maybe I should keep a closer look to hydra
:P

I can't reproduce it on x86_64. Does it only appear on x86?

Manolis

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

Re: Fwd: Re: Planning for the next release

[Ricardo Wurmus]

Manolis Ragkousis <manolis837@gmail.com> writes:

> We also need to fix the glibc on hurd (the patch for i686 should not be
> applied there), but I haven’t been able to reproduce the failure on
> hydra.  https://hydra.gnu.org/build/2036383/nixlog/1/raw

Yes, I’m working on it.  I wasn’t able to reproduce this in my past
attempts, but I’ll try again.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Planning for the next release

[Leo Famulari]

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

On Thu, May 11, 2017 at 11:00:16AM +0200, Ludovic Courtès wrote:
> With UEFI (almost) ready, Guile 2.2 in the house, and “make release”,
> should we aim for next week (like Wed. 17th)?  Can we focus on polishing
> the remaining bits and testing?
> 
> If the schedule turns out to be too tight, we could move to the week
> after.
> 
> Thoughts?

If possible, I would appreciate if the release included a QEMU image
that we could offer to VPS hosters like serveraptor.com, as discussed in
this thread:

https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00772.html

This would also depend on <https://bugs.gnu.org/26875> (Non-graphical
GRUB menus) being merged.

If the maintainers want to try for this, I'm happy to help prepare a
system declaration and test it.

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

Re: Planning for the next release

[ng0]

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

On Fri, 12 May 2017, Leo Famulari wrote:

> On Thu, May 11, 2017 at 11:00:16AM +0200, Ludovic Courtès wrote:
>> With UEFI (almost) ready, Guile 2.2 in the house, and “make release”,
>> should we aim for next week (like Wed. 17th)?  Can we focus on polishing
>> the remaining bits and testing?
>>
>> If the schedule turns out to be too tight, we could move to the week
>> after.
>>
>> Thoughts?
>
> If possible, I would appreciate if the release included a QEMU image
> that we could offer to VPS hosters like serveraptor.com, as discussed in
> this thread:
>
> https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00772.html
>
> This would also depend on <https://bugs.gnu.org/26875> (Non-graphical
> GRUB menus) being merged.
>
> If the maintainers want to try for this, I'm happy to help prepare a
> system declaration and test it.
>

That would be great, a start for those who can easily make use of
not so specific images!

Re: Planning for the next release

[Ludovic Courtès]

Hello!

Leo Famulari <leo@famulari.name> skribis:

> If possible, I would appreciate if the release included a QEMU image
> that we could offer to VPS hosters like serveraptor.com, as discussed in
> this thread:
>
> https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00772.html
>
> This would also depend on <https://bugs.gnu.org/26875> (Non-graphical
> GRUB menus) being merged.
>
> If the maintainers want to try for this, I'm happy to help prepare a
> system declaration and test it.

Why not.  Ricardo?

The main “difficulty” would be to adjust the “Download” page on the web
site, the instructions in the manual, “make release”, and to come up
with a clear file name for the new image.

I would assume that x86_64 is sufficient for the VPS image?

Thanks for reminding us of this,
LUdo’.

Re: Planning for the next release

[Vincent Legoll]

On Sat, May 13, 2017 at 3:59 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> Leo Famulari <leo@famulari.name> skribis:
>
>> If possible, I would appreciate if the release included a QEMU image
>> that we could offer to VPS hosters like serveraptor.com, as discussed in
>> this thread:

+1

>> If the maintainers want to try for this, I'm happy to help prepare a
>> system declaration and test it.

I'll test the images too.

> The main “difficulty” would be to adjust the “Download” page on the web
> site, the instructions in the manual, “make release”, and to come up
> with a clear file name for the new image.

Maybe:
https://alpha.gnu.org/gnu/guix/guixsd-qemu-live-0.12.0.x86_64-linux.xz

> I would assume that x86_64 is sufficient for the VPS image?

As a first step, maybe we'll have more ARMs customers coming in the
future (EOMA68 for instance)

-- 
Vincent Legoll

Re: Planning for the next release

[Leo Famulari]

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

On Sat, May 13, 2017 at 03:59:24PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > If possible, I would appreciate if the release included a QEMU image
> > that we could offer to VPS hosters like serveraptor.com, as discussed in
> > this thread:
> >
> > If the maintainers want to try for this, I'm happy to help prepare a
> > system declaration and test it.

I'll work on the system declaration shortly. I think it should take some
parts from installation-os from (gnu system install), but the
file-systems can be simplified, and the packages reduced.

> The main “difficulty” would be to adjust the “Download” page on the web
> site, the instructions in the manual, “make release”, and to come up
> with a clear file name for the new image.

I think the name should be "guixsd-vm-image-VERSION", since this follows
the convention established with `guix system vm-image`.

I've attached some rough patches for guix.git and guix-artwork.git.

I'm confused about `make release`. The for-loop that builds the disk
images doesn't seem to set up offloading or actually build the images
for the different values of $SUPPORTED_SYSTEMS [0]. Am I missing this
somewhere?

For the web-site, I'm struggling to set up a development environment
where I can run (export-web-site) and test my changes.

[0]
https://git.savannah.gnu.org/cgit/guix.git/tree/Makefile.am?id=e0b2e93005188ab4d6c7413a27832ba2fb7388e8#n608

[-- Attachment #1.2: 0001-doc-Mention-the-pre-built-VM-image.patch --]
[-- Type: text/plain, Size: 2145 bytes --]

From 6ae03aa362b3542590e12c0ab2b65af127bdb00d Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Sat, 13 May 2017 20:44:36 -0400
Subject: [PATCH 1/2] doc: Mention the pre-built VM image.

* doc/guix.texi (Running GuixSD in a VM): Mention the pre-built VM image.
---
 doc/guix.texi | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 844f0d74f..7b8a4fea0 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -15649,17 +15649,21 @@ example graph.
 @subsection Running GuixSD in a Virtual Machine
 
 @cindex virtual machine
-One way to run GuixSD in a virtual machine (VM) is to build a GuixSD
-virtual machine image using @command{guix system vm-image}
-(@pxref{Invoking guix system}).  The returned image is in qcow2 format,
-which the @uref{http://qemu.org/, QEMU emulator} can efficiently use.
+To run GuixSD in a virtual machine (VM), one can either use the
+pre-built GuixSD VM image distributed at
+@indicateurl{ftp://alpha.gnu.org/guix/guixsd-vm-image-@value{VERSION}.@var{system}.tar.xz}
+, or build their own virtual machine image using @command{guix system
+vm-image} (@pxref{Invoking guix system}).  The returned image is in
+qcow2 format, which the @uref{http://qemu.org/, QEMU emulator} can
+efficiently use.
 
 @cindex QEMU
-To run the image in QEMU, copy it out of the store (@pxref{The Store})
-and give yourself permission to write to the copy.  When invoking QEMU,
-you must choose a system emulator that is suitable for your hardware
-platform.  Here is a minimal QEMU invocation that will boot the result
-of @command{guix system vm-image} on x86_64 hardware:
+If you built your image image, you must copy it out of the store
+(@pxref{The Store}) and give yourself permission to write to the copy
+before you can use it.  When invoking QEMU, you must choose a system
+emulator that is suitable for your hardware platform.  Here is a minimal
+QEMU invocation that will boot the result of @command{guix system
+vm-image} on x86_64 hardware:
 
 @example
 $ qemu-system-x86_64 \
-- 
2.13.0


[-- Attachment #1.3: 0002-maint-The-release-target-builds-a-VM-image.patch --]
[-- Type: text/plain, Size: 2198 bytes --]

From 30effa15369a1707755d134e37e63e2df135422e Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Sat, 13 May 2017 18:07:01 -0400
Subject: [PATCH 2/2] maint: The 'release' target builds a VM image.

* Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE,
GUIXSD_VM_IMAGE_SIZE): New variables.
(release): Add logic to build a VM image.
---
 Makefile.am | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 4b5a29a72..8663de3ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -571,12 +571,21 @@ BINARY_TARBALLS =							\
 # Systems supported by GuixSD.
 GUIXSD_SUPPORTED_SYSTEMS ?= x86_64-linux i686-linux
 
+# Systems for which we build GuixSD VMs.
+GUIXSD_VM_SYSTEMS ?= x86_64-linux
+
 # Prefix of the GuixSD installation image file name.
 GUIXSD_IMAGE_BASE = guixsd-usb-install-$(PACKAGE_VERSION)
 
+# Prefix of the GuixSD VM image file name.
+GUIXSD_VM_IMAGE_BASE = guixsd-vm-image-$(PACKAGE_VERSION)
+
 # Size of the installation image (for x86_64 typically).
 GUIXSD_INSTALLATION_IMAGE_SIZE ?= 950MiB
 
+# Size of the VM image (for x86_64 typically).
+GUIXSD_VM_IMAGE_SIZE ?= 2GiB
+
 # The release process works in several phases:
 #
 #   0. We assume the developer created a 'vX.Y' tag.
@@ -627,6 +636,19 @@ release: distcheck
 	  mv "$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz.tmp"			\
 	     "$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz" ;				\
 	done
+	for system in $(GUIXSD_VM_SYSTEMS) ; do						\
+	  image=`$(top_builddir)/pre-inst-env						\
+	    guix system vm-image							\
+	    --image-size=$(GUIXSD_VM_IMAGE_SIZE)					\
+	    gnu/system/install.scm` ;							\
+	  if [ ! -f "$$image" ] ; then							\
+	    echo "failed to produced GuixSD VM image for $$system" >&2 ;		\
+	    exit 1 ;									\
+	  fi ;										\
+	  xz < "$$image" > "$(releasedir)/$(GUIXSD_VM_IMAGE_BASE).$$system.xz.tmp" ;	\
+	  mv "$(releasedir)/$(GUIXSD_VM_IMAGE_BASE).$$system.xz.tmp"			\
+	     "$(releasedir)/$(GUIXSD_VM_IMAGE_BASE).$$system.xz" ;			\
+	done
 	@echo
 	@echo "Congratulations!  All the release files are now in $(releasedir)."
 	@echo
-- 
2.13.0


[-- Attachment #1.4: 0001-website-downloads-Mention-the-VM-image.patch --]
[-- Type: text/plain, Size: 2453 bytes --]

From 584a9dfb224de28dc40692d2957d2301952378c2 Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Sun, 14 May 2017 15:03:57 -0400
Subject: [PATCH] website: downloads: Mention the VM image.

* website/www/download.scm (%vm-image-description, %vm-image-manual,
%vm-image-image): New variables.
(guixsd-vm-image-files): New procedure.
(download-page): Use guixsd-vm-image-files.
---
 website/www/download.scm | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/website/www/download.scm b/website/www/download.scm
index 887c6db..98f03ee 100644
--- a/website/www/download.scm
+++ b/website/www/download.scm
@@ -62,6 +62,15 @@ dependencies.")
 (define %guix-src-image
   "src-package.png")
 
+(define %vm-image-description
+  "Virtual machine (QEMU) image of GuixSD.")
+
+(define %vm-image-manual
+  "manual/html_node/Running-GuixSD-in-a-VM.html")
+
+(define %vm-image-image
+  "GuixSD-package.png")
+
 (define (ftp-url file)
   (string-append "ftp://alpha.gnu.org/gnu/guix/" file))
 
@@ -75,6 +84,12 @@ dependencies.")
                                             "-linux.xz"))))
        archs))
 
+(define (guixsd-vm-image-files archs)
+  (map (lambda (arch)
+         (cons arch (https-url (string-append "guixsd-vm-image-"
+                                              (latest-guix-version) "." arch
+                                              "-linux.xz"))))))
+
 (define (guix-files archs)
   (map (lambda (arch)
          (cons arch (https-url (string-append "guix-binary-" (latest-guix-version)
@@ -150,7 +165,12 @@ Linux-based system.")
                             #:files (guix-source-files '("tarball"))
                             #:description %source-tarball-description
                             #:manual %source-tarball-manual
-                            #:image %guix-src-image))
+                            #:image %guix-src-image)
+             ,(download-box (string-append "GuixSD " (latest-guix-version))
+                            #:files (guixsd-vm-image-files '("x86_64"))
+                            #:description %vm-image-description
+                            #:manual %vm-image-manual
+                            #:image %guixsd-vm-image))
 
 		(p "Source code for the Guix System Distribution USB
 installation images as well as GNU Guix can be found on the GNU ftp server for "
-- 
2.13.0


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

Re: Planning for the next release

[Leo Famulari]

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

On Sun, May 14, 2017 at 03:14:07PM -0400, Leo Famulari wrote:
> Subject: [PATCH 1/2] doc: Mention the pre-built VM image.
> 
> * doc/guix.texi (Running GuixSD in a VM): Mention the pre-built VM image.

[...]

> +If you built your image image, you must copy it out of the store

s/image image/own image

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

Re: Planning for the next release

[Leo Famulari]

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

On Sun, May 14, 2017 at 03:14:07PM -0400, Leo Famulari wrote:
> Subject: [PATCH 2/2] maint: The 'release' target builds a VM image.
> 
> * Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE,
> GUIXSD_VM_IMAGE_SIZE): New variables.
> (release): Add logic to build a VM image.

After following the instructions in release.org and copying texinfo.tex
from a recent gnulib into build-aux, I ran the following command and
built a working VM image:

guix environment --pure guix --ad-hoc imagemagick git texlive texinfo -- make release

Those extra packages all seem to be required.

I disabled the disk-image builds to save time and disk space.

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

Re: Planning for the next release

[Ludovic Courtès]

Hi Leo!

(sirgazil: this is about providing a ready-to-use VM image of GuixSD for
download, in addition to the installation image.  See at the bottom.)

Leo Famulari <leo@famulari.name> skribis:

> I think the name should be "guixsd-vm-image-VERSION", since this follows
> the convention established with `guix system vm-image`.

Sounds good.

> I've attached some rough patches for guix.git and guix-artwork.git.
>
> I'm confused about `make release`. The for-loop that builds the disk
> images doesn't seem to set up offloading or actually build the images
> for the different values of $SUPPORTED_SYSTEMS [0]. Am I missing this
> somewhere?

As discussed on IRC, there was a typo fixed in
6344e959ea45c283a0c7a2091f0959f8e09a198d.  As for offloading, the target
assumes that the user has set it up correctly.

> For the web-site, I'm struggling to set up a development environment
> where I can run (export-web-site) and test my changes.

I’ll add a guix.scm there.

> From 6ae03aa362b3542590e12c0ab2b65af127bdb00d Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Sat, 13 May 2017 20:44:36 -0400
> Subject: [PATCH 1/2] doc: Mention the pre-built VM image.
>
> * doc/guix.texi (Running GuixSD in a VM): Mention the pre-built VM image.

OK.  I think this commit can be squashed with the next one.

What about explicitly mentioning VPS, as in:

- If you’d like to install GuixSD in a virtual machine (VM)
+ @cindex virtual private server (VPS)
+ @cindex VPS (virtual private server)
+ If you’d like to install GuixSD in a virtual machine (VM)
+ in a virtual machine (VM) or on a virtual private server (VPS)

?

> From 30effa15369a1707755d134e37e63e2df135422e Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Sat, 13 May 2017 18:07:01 -0400
> Subject: [PATCH 2/2] maint: The 'release' target builds a VM image.
>
> * Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE,
> GUIXSD_VM_IMAGE_SIZE): New variables.
> (release): Add logic to build a VM image.

[...]

> +	  image=`$(top_builddir)/pre-inst-env						\
> +	    guix system vm-image							\
> +	    --image-size=$(GUIXSD_VM_IMAGE_SIZE)					\
> +	    gnu/system/install.scm` ;							\

So you need --system=$$system as well.  :-)

Otherwise LGTM.

> From 584a9dfb224de28dc40692d2957d2301952378c2 Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Sun, 14 May 2017 15:03:57 -0400
> Subject: [PATCH] website: downloads: Mention the VM image.
>
> * website/www/download.scm (%vm-image-description, %vm-image-manual,
> %vm-image-image): New variables.
> (guixsd-vm-image-files): New procedure.
> (download-page): Use guixsd-vm-image-files.

[...]

> --- a/website/www/download.scm
> +++ b/website/www/download.scm
> @@ -62,6 +62,15 @@ dependencies.")
>  (define %guix-src-image
>    "src-package.png")
>  
> +(define %vm-image-description
> +  "Virtual machine (QEMU) image of GuixSD.")
> +
> +(define %vm-image-manual
> +  "manual/html_node/Running-GuixSD-in-a-VM.html")
> +
> +(define %vm-image-image
> +  "GuixSD-package.png")
> +
>  (define (ftp-url file)
>    (string-append "ftp://alpha.gnu.org/gnu/guix/" file))
>  
> @@ -75,6 +84,12 @@ dependencies.")
>                                              "-linux.xz"))))
>         archs))
>  
> +(define (guixsd-vm-image-files archs)
> +  (map (lambda (arch)
> +         (cons arch (https-url (string-append "guixsd-vm-image-"
> +                                              (latest-guix-version) "." arch
> +                                              "-linux.xz"))))))
> +
>  (define (guix-files archs)
>    (map (lambda (arch)
>           (cons arch (https-url (string-append "guix-binary-" (latest-guix-version)
> @@ -150,7 +165,12 @@ Linux-based system.")
>                              #:files (guix-source-files '("tarball"))
>                              #:description %source-tarball-description
>                              #:manual %source-tarball-manual
> -                            #:image %guix-src-image))
> +                            #:image %guix-src-image)
> +             ,(download-box (string-append "GuixSD " (latest-guix-version))
> +                            #:files (guixsd-vm-image-files '("x86_64"))
> +                            #:description %vm-image-description
> +                            #:manual %vm-image-manual
> +                            #:image %guixsd-vm-image))

sirgazil: do you think we should add a special icon or something for the
VM image?

Otherwise LGTM!

Thanks,
Ludo’.

Re: Planning for the next release

[sirgazil]

On 15/05/17 07:44, Ludovic Courtès wrote:
> Hi Leo!
>
> (sirgazil: this is about providing a ready-to-use VM image of GuixSD for
> download, in addition to the installation image.  See at the bottom.)

[...]

> sirgazil: do you think we should add a special icon or something for the
> VM image?

Yes. How about this:

https://bitbucket.org/sirgazil/dnd/downloads/qemu-img.tar.gz

You can drop both files in "website/static/base/img". The
"installer.svg" file is supposed to overwrite the existing one.

Re: Planning for the next release

[Leo Famulari]

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

On Tue, May 16, 2017 at 09:41:38AM -0500, sirgazil wrote:
> On 15/05/17 07:44, Ludovic Courtès wrote:
> > Hi Leo!
> >
> > (sirgazil: this is about providing a ready-to-use VM image of GuixSD for
> > download, in addition to the installation image.  See at the bottom.)
> 
> [...]
> 
> > sirgazil: do you think we should add a special icon or something for the
> > VM image?
> 
> Yes. How about this:
> 
> https://bitbucket.org/sirgazil/dnd/downloads/qemu-img.tar.gz
> 
> You can drop both files in "website/static/base/img". The
> "installer.svg" file is supposed to overwrite the existing one.

I like this image; I'll push it to guix-artwork soon unless somebody
objects.

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

Re: Planning for the next release

[Leo Famulari]

On Tue, May 16, 2017 at 09:41:38AM -0500, sirgazil wrote:
> On 15/05/17 07:44, Ludovic Courtès wrote:
> > Hi Leo!
> >
> > (sirgazil: this is about providing a ready-to-use VM image of GuixSD for
> > download, in addition to the installation image.  See at the bottom.)
> 
> [...]
> 
> > sirgazil: do you think we should add a special icon or something for the
> > VM image?
> 
> Yes. How about this:
> 
> https://bitbucket.org/sirgazil/dnd/downloads/qemu-img.tar.gz
> 
> You can drop both files in "website/static/base/img". The
> "installer.svg" file is supposed to overwrite the existing one.

Although, I am wondering why 'installer.svg' seems specific to the VM
image now. The VM image is not an installer.

Re: Planning for the next release

[sirgazil]

On 16/05/17 13:19, Leo Famulari wrote:
> On Tue, May 16, 2017 at 09:41:38AM -0500, sirgazil wrote:
>> On 15/05/17 07:44, Ludovic Courtès wrote:
>>> Hi Leo!
>>>
>>> (sirgazil: this is about providing a ready-to-use VM image of GuixSD for
>>> download, in addition to the installation image.  See at the bottom.)
>> [...]
>>
>>> sirgazil: do you think we should add a special icon or something for the
>>> VM image?
>> Yes. How about this:
>>
>> https://bitbucket.org/sirgazil/dnd/downloads/qemu-img.tar.gz
>>
>> You can drop both files in "website/static/base/img". The
>> "installer.svg" file is supposed to overwrite the existing one.
> Although, I am wondering why 'installer.svg' seems specific to the VM
> image now. The VM image is not an installer.
Hi Leo :)

I don't know if I understand correctly, but the "installed.svg" file
contains several download icons, but just one is on the "canvas" at a
time, so your file manager will display a preview with the last icon
that was left on the canvas, which should be the QEMU icon.

As for the name of the file, it may be confusing, so maybe it could be
renamed "download-icons.svg"?

-- 
https://sirgazil.bitbucket.io/

Re: Planning for the next release

[Leo Famulari]

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

On Tue, May 16, 2017 at 07:51:36PM -0500, sirgazil wrote:
> On 16/05/17 13:19, Leo Famulari wrote:
> > Although, I am wondering why 'installer.svg' seems specific to the VM
> > image now. The VM image is not an installer.
> Hi Leo :)
> 
> I don't know if I understand correctly, but the "installed.svg" file
> contains several download icons, but just one is on the "canvas" at a
> time, so your file manager will display a preview with the last icon
> that was left on the canvas, which should be the QEMU icon.

Oh, I see! I didn't realize it could contain multiple icons. Now, I
opened it with inkscape and see all the icons.

> As for the name of the file, it may be confusing, so maybe it could be
> renamed "download-icons.svg"?

Yeah, I think that's a good idea. I can do that locally before pushing.

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

Re: Planning for the next release

[Ludovic Courtès]

Hello!

Leo Famulari <leo@famulari.name> skribis:

> On Tue, May 16, 2017 at 07:51:36PM -0500, sirgazil wrote:
>> On 16/05/17 13:19, Leo Famulari wrote:
>> > Although, I am wondering why 'installer.svg' seems specific to the VM
>> > image now. The VM image is not an installer.
>> Hi Leo :)
>> 
>> I don't know if I understand correctly, but the "installed.svg" file
>> contains several download icons, but just one is on the "canvas" at a
>> time, so your file manager will display a preview with the last icon
>> that was left on the canvas, which should be the QEMU icon.
>
> Oh, I see! I didn't realize it could contain multiple icons. Now, I
> opened it with inkscape and see all the icons.
>
>> As for the name of the file, it may be confusing, so maybe it could be
>> renamed "download-icons.svg"?
>
> Yeah, I think that's a good idea. I can do that locally before pushing.

Awesome, please do.

Thank you sirgazil for the quick reply!

Ludo’.

Re: Planning for the next release

[Alex Kost]

If it's not too late for the release, I think it would be good to make
guile-json an optional dependency (currently it is required).  A simple
fix is here:

  http://debbugs.gnu.org/26860

Although Ricardo suggested another solution there.

-- 
Alex

Re: Planning for the next release

[Leo Famulari]

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

On Mon, May 15, 2017 at 02:44:51PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > Subject: [PATCH 1/2] doc: Mention the pre-built VM image.
> > * doc/guix.texi (Running GuixSD in a VM): Mention the pre-built VM image.
>
> > Subject: [PATCH 2/2] maint: The 'release' target builds a VM image.
> > * Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE,
> > GUIXSD_VM_IMAGE_SIZE): New variables.
> > (release): Add logic to build a VM image.

I took your suggestions and added 'gnu/system/examples/vm-image.tmpl' in
the updated version of the patch (attached).

In 'vm-image.tmpl', I put some VPS-specific suggestions related to
partitioning and filesystems in the MOTD. The crux of the issue is that
we don't know how large the virtual disk will be, so we need to resize
the partition and filesystem after we boot.

Hopefully in the future we can offer something more sophisticated, which
will do this sort of task automatically.

> > Subject: [PATCH] website: downloads: Mention the VM image.
> >
> > * website/www/download.scm (%vm-image-description, %vm-image-manual,
> > %vm-image-image): New variables.
> > (guixsd-vm-image-files): New procedure.
> > (download-page): Use guixsd-vm-image-files.

> sirgazil: do you think we should add a special icon or something for the
> VM image?

I had a followup question for sirgazil so I'll wait for a response:

https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00310.html

[-- Attachment #1.2: 0001-maint-The-release-target-builds-a-VM-image.patch --]
[-- Type: text/plain, Size: 7520 bytes --]

From 1c9ad17ea0b64b29117e49526ff07d2e7e7c6c13 Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Sat, 13 May 2017 20:44:36 -0400
Subject: [v2] maint: The 'release' target builds a VM image.

* Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE,
GUIXSD_VM_IMAGE_SIZE): New variables.
(release): Add logic to build a VM image.
* gnu/system/examples/vm-image.tmpl: New file.
* doc/guix.texi (Running GuixSD in a VM, Installing GuixSD in a VM): Mention the
pre-built VM image.
---
 Makefile.am                       | 24 ++++++++++++++++++
 doc/guix.texi                     | 29 +++++++++++++--------
 gnu/system/examples/vm-image.tmpl | 53 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 95 insertions(+), 11 deletions(-)
 create mode 100644 gnu/system/examples/vm-image.tmpl

diff --git a/Makefile.am b/Makefile.am
index 5bfc9ca88..0b12c6484 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@
 # Copyright © 2016 Mathieu Lirzin <mthl@gnu.org>
 # Copyright © 2016, 2017 Mark H Weaver <mhw@netris.org>
 # Copyright © 2017 Mathieu Othacehe <m.othacehe@gmail.com>
+# Copyright © 2017 Leo Famulari <leo@famulari.name>
 #
 # This file is part of GNU Guix.
 #
@@ -571,12 +572,21 @@ BINARY_TARBALLS =							\
 # Systems supported by GuixSD.
 GUIXSD_SUPPORTED_SYSTEMS ?= x86_64-linux i686-linux
 
+# Systems for which we build GuixSD VMs.
+GUIXSD_VM_SYSTEMS ?= x86_64-linux
+
 # Prefix of the GuixSD installation image file name.
 GUIXSD_IMAGE_BASE = guixsd-usb-install-$(PACKAGE_VERSION)
 
+# Prefix of the GuixSD VM image file name.
+GUIXSD_VM_IMAGE_BASE = guixsd-vm-image-$(PACKAGE_VERSION)
+
 # Size of the installation image (for x86_64 typically).
 GUIXSD_INSTALLATION_IMAGE_SIZE ?= 950MiB
 
+# Size of the VM image (for x86_64 typically).
+GUIXSD_VM_IMAGE_SIZE ?= 2GiB
+
 # The release process works in several phases:
 #
 #   0. We assume the developer created a 'vX.Y' tag.
@@ -631,6 +641,20 @@ release: dist
 	  mv "$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz.tmp"			\
 	     "$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz" ;				\
 	done
+	for system in $(GUIXSD_VM_SYSTEMS) ; do						\
+	  image=`$(top_builddir)/pre-inst-env						\
+	    guix system vm-image							\
+	    --system=$$system								\
+	    --image-size=$(GUIXSD_VM_IMAGE_SIZE)					\
+	    gnu/system/examples/vm-image.tmpl` ;					\
+	  if [ ! -f "$$image" ] ; then							\
+	    echo "failed to produced GuixSD VM image for $$system" >&2 ;		\
+	    exit 1 ;									\
+	  fi ;										\
+	  xz < "$$image" > "$(releasedir)/$(GUIXSD_VM_IMAGE_BASE).$$system.xz.tmp" ;	\
+	  mv "$(releasedir)/$(GUIXSD_VM_IMAGE_BASE).$$system.xz.tmp"			\
+	     "$(releasedir)/$(GUIXSD_VM_IMAGE_BASE).$$system.xz" ;			\
+	done
 	@echo
 	@echo "Congratulations!  All the release files are now in $(releasedir)."
 	@echo
diff --git a/doc/guix.texi b/doc/guix.texi
index b272fcec8..e6a9706b9 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -7628,8 +7628,11 @@ good.
 @subsection Installing GuixSD in a Virtual Machine
 
 @cindex virtual machine, GuixSD installation
-If you'd like to install GuixSD in a virtual machine (VM) rather than on
-your beloved machine, this section is for you.
+@cindex virtual private server (VPS)
+@cindex VPS (virtual private server)
+If you'd like to install GuixSD in a virtual machine (VM) or on a
+virtual private server (VPS) rather than on your beloved machine, this
+section is for you.
 
 To boot a @uref{http://qemu.org/,QEMU} VM for installing GuixSD in a
 disk image, follow these steps:
@@ -15687,17 +15690,21 @@ example graph.
 @subsection Running GuixSD in a Virtual Machine
 
 @cindex virtual machine
-One way to run GuixSD in a virtual machine (VM) is to build a GuixSD
-virtual machine image using @command{guix system vm-image}
-(@pxref{Invoking guix system}).  The returned image is in qcow2 format,
-which the @uref{http://qemu.org/, QEMU emulator} can efficiently use.
+To run GuixSD in a virtual machine (VM), one can either use the
+pre-built GuixSD VM image distributed at
+@indicateurl{ftp://alpha.gnu.org/guix/guixsd-vm-image-@value{VERSION}.@var{system}.tar.xz}
+, or build their own virtual machine image using @command{guix system
+vm-image} (@pxref{Invoking guix system}).  The returned image is in
+qcow2 format, which the @uref{http://qemu.org/, QEMU emulator} can
+efficiently use.
 
 @cindex QEMU
-To run the image in QEMU, copy it out of the store (@pxref{The Store})
-and give yourself permission to write to the copy.  When invoking QEMU,
-you must choose a system emulator that is suitable for your hardware
-platform.  Here is a minimal QEMU invocation that will boot the result
-of @command{guix system vm-image} on x86_64 hardware:
+If you built your own image, you must copy it out of the store
+(@pxref{The Store}) and give yourself permission to write to the copy
+before you can use it.  When invoking QEMU, you must choose a system
+emulator that is suitable for your hardware platform.  Here is a minimal
+QEMU invocation that will boot the result of @command{guix system
+vm-image} on x86_64 hardware:
 
 @example
 $ qemu-system-x86_64 \
diff --git a/gnu/system/examples/vm-image.tmpl b/gnu/system/examples/vm-image.tmpl
new file mode 100644
index 000000000..57ac71c53
--- /dev/null
+++ b/gnu/system/examples/vm-image.tmpl
@@ -0,0 +1,53 @@
+;;; This is an operating system configuration template for a "bare-bones" setup,
+;;; suitable for booting in a virtualized environment, including virtual private
+;;; servers (VPS).
+
+(use-modules (gnu))
+(use-package-modules bootloaders disk nvi)
+
+(define vm-image-motd (plain-file "motd" "
+This is the GNU system.  Welcome!
+
+This instance of GuixSD is a bare-bones template for virtualized environments.
+
+You will probably want to do these things first if you booted in a virtual
+private server (VPS):
+
+* Set a password for 'root'.
+* Set up networking.
+* Expand the root partition to fill the space available by 0) deleting and
+recreating the partition with fdisk, 1) reloading the partition table with
+partprobe, and then 2) resizing the filesystem with resize2fs.\n"))
+
+(operating-system
+  (host-name "gnu")
+  (timezone "Etc/UTC")
+  (locale "en_US.utf8")
+
+  ;; Assuming /dev/sdX is the target hard disk, and "my-root" is
+  ;; the label of the target root file system.
+  (bootloader (grub-configuration (device "/dev/sda")
+                                  (terminal-outputs '(console))))
+  (file-systems (cons (file-system
+                        (device "my-root")
+                        (title 'label)
+                        (mount-point "/")
+                        (type "ext4"))
+                      %base-file-systems))
+
+  ;; This is where user accounts are specified.  The "root"
+  ;; account is implicit, and is initially created with the
+  ;; empty password.
+  (users %base-user-accounts)
+
+  ;; Globally-installed packages.
+  (packages (cons* nvi fdisk
+                   grub   ; mostly so xrefs to its manual work
+                   parted ; partprobe
+                   %base-packages))
+
+  (services (modify-services %base-services
+              (login-service-type config =>
+                                  (login-configuration
+                                    (inherit config)
+                                    (motd vm-image-motd))))))
-- 
2.13.0


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

Re: Planning for the next release

[Ludovic Courtès]

Hi Leo,

Leo Famulari <leo@famulari.name> skribis:

> From 1c9ad17ea0b64b29117e49526ff07d2e7e7c6c13 Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Sat, 13 May 2017 20:44:36 -0400
> Subject: [v2] maint: The 'release' target builds a VM image.
>
> * Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE,
> GUIXSD_VM_IMAGE_SIZE): New variables.
> (release): Add logic to build a VM image.
> * gnu/system/examples/vm-image.tmpl: New file.
> * doc/guix.texi (Running GuixSD in a VM, Installing GuixSD in a VM): Mention the
> pre-built VM image.

Could you add vm-image.tmpl to the ‘EXAMPLES’ variable in Makefile.am?

OK with this change, thank you!

Ludo’.

Re: Planning for the next release

[Leo Famulari]

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

On Wed, May 17, 2017 at 02:38:13PM +0200, Ludovic Courtès wrote:
> Hi Leo,
> 
> Leo Famulari <leo@famulari.name> skribis:
> 
> > From 1c9ad17ea0b64b29117e49526ff07d2e7e7c6c13 Mon Sep 17 00:00:00 2001
> > From: Leo Famulari <leo@famulari.name>
> > Date: Sat, 13 May 2017 20:44:36 -0400
> > Subject: [v2] maint: The 'release' target builds a VM image.
> >
> > * Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE,
> > GUIXSD_VM_IMAGE_SIZE): New variables.
> > (release): Add logic to build a VM image.
> > * gnu/system/examples/vm-image.tmpl: New file.
> > * doc/guix.texi (Running GuixSD in a VM, Installing GuixSD in a VM): Mention the
> > pre-built VM image.
> 
> Could you add vm-image.tmpl to the ‘EXAMPLES’ variable in Makefile.am?

Done!

> OK with this change, thank you!

Pushed as 4b236c88eaa690a045bc57b9c4d2acf44ae91f17!

I still haven't pushed my changes to guix-artwork.git, because I still
haven't built / test them.

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

Building the web site

[Ludovic Courtès]

Hello,

Leo Famulari <leo@famulari.name> skribis:

> I still haven't pushed my changes to guix-artwork.git, because I still
> haven't built / test them.

For the record I just pushed a ‘guix.scm’ file in guix-artwork/website,
such that you can simply run:

  guix build -f guix.scm

and have the thing built in an appropriate environment.

  https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/commit/?id=85940cd58ecaa7916da6abbda6b0de955a1005eb

HTH!

Ludo’.

Re: Planning for the next release

[Ricardo Wurmus]

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

> Hello!
>
> Leo Famulari <leo@famulari.name> skribis:
>
>> If possible, I would appreciate if the release included a QEMU image
>> that we could offer to VPS hosters like serveraptor.com, as discussed in
>> this thread:
>>
>> https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00772.html
>>
>> This would also depend on <https://bugs.gnu.org/26875> (Non-graphical
>> GRUB menus) being merged.
>>
>> If the maintainers want to try for this, I'm happy to help prepare a
>> system declaration and test it.
>
> Why not.  Ricardo?

I’m sorry, this email fell through the cracks.  Yes, offering a release
image for VPS hosters would be a very good idea.

I see that work on this issue has already progressed; just wanted to say
that it’s great that you’re moving this forward!

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net