Re: Planning for the next release

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello!
>
> Leo Famulari  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  (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

Re: Planning for the next release

[Ludovic Courtès]

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

[Ludovic Courtès]

Hi!

Marius Bakke  skribis:

> Ludovic Courtès  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: 0x2f00 from 0x8100 (relocation 
>> range: 0x8000-0xbfff)
>> [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: inval

Re: Planning for the next release

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  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: .
>>>
>>> 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

[Ricardo Wurmus]

Ludovic Courtès  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: .
>>
>> 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

[Ricardo Wurmus]

Ludovic Courtès  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]

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


signature.asc
Description: PGP signature

Re: Planning for the next release

[Marius Bakke]

Ludovic Courtès  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: 0x2f00 from 0x8100 (relocation 
> range: 0x8000-0xbfff)
> [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] [DEVICE [COMMAND [PARAMETERS]]...]
> ERROR: In procedure scm-error:
> ERROR: f

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: 0x2f00 from 0x8100 (relocation 
range: 0x8000-0xbfff)
[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] [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=0x
--8<---cut here---end--->8---

Any ideas what could be wrong?

Thanks in advance,  :-)
Ludo’.

Re: Planning for the next release

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> An update on the release that never comes.  ;-)
>>
>> The main remaining item is merging UEFI support in ‘version-0.13.0’:
>> .

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

> Hello Guix!
>
> An update on the release that never comes.  ;-)
>
> The main remaining item is merging UEFI support in ‘version-0.13.0’:
> .
>
> 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: .

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]

Hello Guix!

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

The main remaining item is merging UEFI support in ‘version-0.13.0’:
.

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

Help welcome on all these fronts!

Ludo’.

Re: Planning for the next release

[Leo Famulari]

On Wed, May 17, 2017 at 02:38:13PM +0200, Ludovic Courtès wrote:
> Hi Leo,
> 
> Leo Famulari  skribis:
> 
> > From 1c9ad17ea0b64b29117e49526ff07d2e7e7c6c13 Mon Sep 17 00:00:00 2001
> > From: Leo Famulari 
> > 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.


signature.asc
Description: PGP signature

Re: Planning for the next release

[Ludovic Courtès]

Hi Leo,

Leo Famulari  skribis:

> From 1c9ad17ea0b64b29117e49526ff07d2e7e7c6c13 Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> 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

[Ludovic Courtès]

Hello!

Leo Famulari  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

[Leo Famulari]

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.


signature.asc
Description: PGP signature

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]

On Mon, May 15, 2017 at 02:44:51PM +0200, Ludovic Courtès wrote:
> Leo Famulari  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
From 1c9ad17ea0b64b29117e49526ff07d2e7e7c6c13 Mon Sep 17 00:00:00 2001
From: Leo Famulari 
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 
 # Copyright © 2016, 2017 Mark H Weaver 
 # Copyright © 2017 Mathieu Othacehe 
+# Copyright © 2017 Leo Famulari 
 #
 # 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 I

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

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

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


signature.asc
Description: PGP signature

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

[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

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

[Leo Famulari]

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.


signature.asc
Description: PGP signature

Re: Planning for the next release

[Leo Famulari]

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


signature.asc
Description: PGP signature

Re: Planning for the next release

[Leo Famulari]

On Sat, May 13, 2017 at 03:59:24PM +0200, Ludovic Courtès wrote:
> Leo Famulari  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
From 6ae03aa362b3542590e12c0ab2b65af127bdb00d Mon Sep 17 00:00:00 2001
From: Leo Famulari 
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

From 30effa15369a1707755d134e37e63e2df135422e Mon Sep 17 00:00:00 2001
From: Leo Famulari 
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" ; 
\

Re: Planning for the next release

[Vincent Legoll]

On Sat, May 13, 2017 at 3:59 PM, Ludovic Courtès  wrote:

> Leo Famulari  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

[Ludovic Courtès]

Hello!

Leo Famulari  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  (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: Fwd: Re: Planning for the next release

[Ricardo Wurmus]

Manolis Ragkousis  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

[ng0]

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

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> Ludovic Courtès  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]

Forgot to cc the list
-- Forwarded message --
From: "Manolis Ragkousis" 
Date: May 12, 2017 21:17
Subject: Re: Planning for the next release
To: "Ricardo Wurmus" 
Cc:

Hey Ricardo,

On May 12, 2017 08:45, "Ricardo Wurmus"  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

Re: Planning for the next release

[Leo Famulari]

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


signature.asc
Description: PGP signature

Re: Planning for the next release

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  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

[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.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Planning for the next release

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello Guix!
>
> l...@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 ; 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

[Ludovic Courtès]

Hello Guix!

l...@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 ; 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]

Leo Famulari  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

[Leo Famulari]

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!


signature.asc
Description: PGP signature

Re: Planning for the next release

[Ludovic Courtès]

Hello Guix!

l...@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 ; 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

[Ludovic Courtès]

Leo Famulari  skribis:

> On Mon, Apr 03, 2017 at 10:26:54AM +0200, Ludovic Courtès wrote:
>> Leo Famulari  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:
>
> 

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

Ludo’.

Re: Planning for the next release

[Ricardo Wurmus]

ng0  writes:

> Leo Famulari transcribed 2.2K bytes:
>> On Fri, Mar 31, 2017 at 04:33:24PM +, 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

[Leo Famulari]

On Mon, Apr 03, 2017 at 10:26:54AM +0200, Ludovic Courtès wrote:
> Leo Famulari  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:




signature.asc
Description: PGP signature

Re: Planning for the next release

[Ludovic Courtès]

Hi!

Leo Famulari  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

[Ludovic Courtès]

Marius Bakke  skribis:

> Ludovic Courtès  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’.

Re: Planning for the next release

[Leo Famulari]

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.


signature.asc
Description: PGP signature

Re: Planning for the next release

[Marius Bakke]

Ludovic Courtès  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 :-)


signature.asc
Description: PGP signature

Re: Planning for the next release

[ng0]

Leo Famulari transcribed 2.2K bytes:
> On Fri, Mar 31, 2017 at 04:33:24PM +, 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

[Leo Famulari]

On Fri, Mar 31, 2017 at 04:33:24PM +, 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.


signature.asc
Description: PGP signature

Re: Planning for the next release

[ng0]

Ludovic Courtès transcribed 0.6K bytes:
> ng0  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

[Ludovic Courtès]

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