LVM support

LVM support

[Tomáš Čech]

Hi Guix,

as project for my Hackweek in SUSE I decided to spend my time on LVM
support in GuixSD - something I miss greatly. This also means that
I'll have much less time for that after this week :(

So far I spent time on reviving my GuixSD installation and preparing
staticly linked binaries for initrd. I have now lvm2 package with
extra output "static". 

What next?

Now the simplest way would be to simply call

vgchange --activate y

Matching configuration could be one configuration option:
(use-lvm?)


That would scan all block devices and look for LVM signature.

Pros:
- it's super simple!
Cons:
- if LVM with filesystem required at boot-time is not found, error
  is not detected or returned by LVM itself



Slightly bit more complicated way could be

vgchange --activate y <volume_group_name>

for every volume group defined in system configuration. Matching configuration could be
(logical-volume-groups '("system" "data"))

e.g. specify list of volume group names used by system.

Pros:
- still simple
- if group activation fails, I can detect it and report it to user

Cons:
- some block devices with LVM may not be available at boot-time (like
  iSCSI devices accessible through network only or Luks devices
  available after entering password)

That is my current approach.



I could also specify whether it should be made available at boot time or not
(logical-volume-groups '('("system" #t)
                         '("data"   #f)))

(sorry for my poor Scheme taste here :)

Pros:
- with this I could say that volume group "system" should be activated
  at boot time, but "data" should be activated later.

Cons:
- starting to be more complicated - I need both initrd stage LVM
  activation and root filesystem stage LVM activation (implemented as
  service? which dependencies it has?)


Or do it in different way. I'd rather not propose here any wild ideas
for configuration but if you can devise something better, please tell
me...



S_W

Re: LVM support

[Ludovic Courtès]

Tomáš Čech <sleep_walker@gnu.org> skribis:

> as project for my Hackweek in SUSE I decided to spend my time on LVM
> support in GuixSD - something I miss greatly. This also means that
> I'll have much less time for that after this week :(

Well this is nice already!

> So far I spent time on reviving my GuixSD installation and preparing
> staticly linked binaries for initrd. I have now lvm2 package with
> extra output "static". 

Don’t worry about static linking or anything: you can use any package,
including dynamically-linked, and it will be magically added to the
initrd if needed.

Then as a second step, since that’ll probably be very big, you can work
on statically-linked variants of the relevant packages (as done for
‘e2fsck/static’.)

> Now the simplest way would be to simply call
>
> vgchange --activate y
>
> Matching configuration could be one configuration option:
> (use-lvm?)
>
>
> That would scan all block devices and look for LVM signature.
>
> Pros:
> - it's super simple!
> Cons:
> - if LVM with filesystem required at boot-time is not found, error
>  is not detected or returned by LVM itself
>
>
>
> Slightly bit more complicated way could be
>
> vgchange --activate y <volume_group_name>
>
> for every volume group defined in system configuration. Matching configuration could be
> (logical-volume-groups '("system" "data"))
>
> e.g. specify list of volume group names used by system.
>
> Pros:
> - still simple
> - if group activation fails, I can detect it and report it to user
>
> Cons:
> - some block devices with LVM may not be available at boot-time (like
>  iSCSI devices accessible through network only or Luks devices
>  available after entering password)
>
> That is my current approach.
>
>
>
> I could also specify whether it should be made available at boot time or not
> (logical-volume-groups '('("system" #t)
>                         '("data"   #f)))
>
> (sorry for my poor Scheme taste here :)
>
> Pros:
> - with this I could say that volume group "system" should be activated
>  at boot time, but "data" should be activated later.
>
> Cons:
> - starting to be more complicated - I need both initrd stage LVM
>  activation and root filesystem stage LVM activation (implemented as
>  service? which dependencies it has?)

Sorry I’m not really familiar with LVM.

Technically, if LVM volumes are mapped devices, the best would be to
define a <mapped-device-kind> structure for them, as discussed on IRC
(like ‘luks-device-mapping’ in (gnu system).)

Then users would need to adjust their ‘mapped-devices’ accordingly (info
"(guix) Mapped Devices").

How does that sound?

Thanks,
Ludo’.

Re: LVM support

[Tomáš Čech]

On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@gnu.org> skribis:
>
>> as project for my Hackweek in SUSE I decided to spend my time on LVM
>> support in GuixSD - something I miss greatly. This also means that
>> I'll have much less time for that after this week :(
>
>Well this is nice already!
>
>> So far I spent time on reviving my GuixSD installation and preparing
>> staticly linked binaries for initrd. I have now lvm2 package with
>> extra output "static".
>
>Don’t worry about static linking or anything: you can use any package,
>including dynamically-linked, and it will be magically added to the
>initrd if needed.
>
>Then as a second step, since that’ll probably be very big, you can work
>on statically-linked variants of the relevant packages (as done for
>‘e2fsck/static’.)

I did this already :)

>
>> Now the simplest way would be to simply call
>>
>> vgchange --activate y
>>
>> Matching configuration could be one configuration option:
>> (use-lvm?)
>>
>>
>> That would scan all block devices and look for LVM signature.
>>
>> Pros:
>> - it's super simple!
>> Cons:
>> - if LVM with filesystem required at boot-time is not found, error
>>  is not detected or returned by LVM itself
>>
>>
>>
>> Slightly bit more complicated way could be
>>
>> vgchange --activate y <volume_group_name>
>>
>> for every volume group defined in system configuration. Matching configuration could be
>> (logical-volume-groups '("system" "data"))
>>
>> e.g. specify list of volume group names used by system.
>>
>> Pros:
>> - still simple
>> - if group activation fails, I can detect it and report it to user
>>
>> Cons:
>> - some block devices with LVM may not be available at boot-time (like
>>  iSCSI devices accessible through network only or Luks devices
>>  available after entering password)
>>
>> That is my current approach.
>>
>>
>>
>> I could also specify whether it should be made available at boot time or not
>> (logical-volume-groups '('("system" #t)
>>                         '("data"   #f)))
>>
>> (sorry for my poor Scheme taste here :)
>>
>> Pros:
>> - with this I could say that volume group "system" should be activated
>>  at boot time, but "data" should be activated later.
>>
>> Cons:
>> - starting to be more complicated - I need both initrd stage LVM
>>  activation and root filesystem stage LVM activation (implemented as
>>  service? which dependencies it has?)
>
>Sorry I’m not really familiar with LVM.

It's implemented using device mapper but instead of mapping one block
device to another you map one block device to whole group (like
playground where you can do anything).


>
>Technically, if LVM volumes are mapped devices, the best would be to
>define a <mapped-device-kind> structure for them, as discussed on IRC
>(like ‘luks-device-mapping’ in (gnu system).)

I didn't like the idea first because it felt confusing and
unatural. Words like `mapping' and `source' and `target' are
misleading. But from programming POV it seems to be the easisest
approach in the end.

(define-record-type* <mapped-device> mapped-device
  make-mapped-device
  mapped-device?
  (source    mapped-device-source)                ;string
  (target    mapped-device-target)                ;string
  (type      mapped-device-type))                 ;<mapped-device-kind>
	  
`source' will be ignored (I not only don't need it but I don't even
know how to pass it or what it should do). `target' will be used for
volume group name. mapped-device-kind structure is easily applicable.


On the other hand problem starts with need-for-boot?. Device mapped
device will be activated during the boot (which is desirable for LVM)
only if there is filesystem which uses such device and has
`need-for-boot?' set to #t.

I needed to tweak operating-system-boot-mapped-devices to not filter
mappings of the new type at all. Now it seems to generate initrd
capable of booting root filesystem from LVM :)

The thing is that this design is not nice. I always admired Scheme's
power in expressing things naturally. mapped-device interface is for
mapping 1 block device to 1 block device which will contain 1
filesystem.


Design I'm thinking about would follow file-system structure. For
device property (I'm not sure if this is proper word in Scheme for
item of record type) to define functions like `partition' (disk,
number), `mapped-device' (source, target, type), `logical-volume' (group,
volume) and whatever would be needed further. You could then express
your mount in more powerful way like:

(partition "sda" 1)

(mapped-device
  (partition "sda" 2)
  "encrypted_swap"
  luks-mapping-type)

(logical-volume
  "system_group"
  "root")


(mapped-device
  (logical-volume "some_group" "some_volume")
  "encrypted data"
  luks-mapping-type)

etc.


Of course, it would lead to more complicated code to handle such
configuration, but it would definitely feel more natural.

When other block device type (like iSCSI) would be required, just
another function (or whatever it is) would be implemented.

Please don't tell me 'this is not how Guix works' :)

Best regards,

S_W

Re: LVM support

[Ludovic Courtès]

Tomáš Čech <sleep_walker@gnu.org> skribis:

> On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote:

[...]

>>Sorry I’m not really familiar with LVM.
>
> It's implemented using device mapper but instead of mapping one block
> device to another you map one block device to whole group (like
> playground where you can do anything).

What do you mean by “whole group”?  A tree under /dev/mapper?

>>Technically, if LVM volumes are mapped devices, the best would be to
>>define a <mapped-device-kind> structure for them, as discussed on IRC
>>(like ‘luks-device-mapping’ in (gnu system).)
>
> I didn't like the idea first because it felt confusing and
> unatural. Words like `mapping' and `source' and `target' are
> misleading. But from programming POV it seems to be the easisest
> approach in the end.

I would think the terms are pretty descriptive, esp. when looking at the
corresponding section of the manual, but I’m biased.  ;-)

Now, my understanding of your message is not so much that the terms are
misleading, but rather that the abstraction is bogus (which appears to
be the case based on what you say.)

> On the other hand problem starts with need-for-boot?. Device mapped
> device will be activated during the boot (which is desirable for LVM)
> only if there is filesystem which uses such device and has
> `need-for-boot?' set to #t.

Right.  I was hesitant about this approach actually, see 9cb426b8.

> I needed to tweak operating-system-boot-mapped-devices to not filter
> mappings of the new type at all. Now it seems to generate initrd
> capable of booting root filesystem from LVM :)

Nice!  Could you post your working version of the patch, just to make
things more concrete?

> The thing is that this design is not nice. I always admired Scheme's
> power in expressing things naturally. mapped-device interface is for
> mapping 1 block device to 1 block device which will contain 1
> filesystem.

Understood.  This has nothing to do with Scheme, really.  :-)

> Design I'm thinking about would follow file-system structure. For
> device property (I'm not sure if this is proper word in Scheme for
> item of record type) to define functions like `partition' (disk,
> number), `mapped-device' (source, target, type), `logical-volume' (group,
> volume) and whatever would be needed further. You could then express
> your mount in more powerful way like:
>
> (partition "sda" 1)
>
> (mapped-device
>  (partition "sda" 2)
>  "encrypted_swap"
>  luks-mapping-type)
>
> (logical-volume
>  "system_group"
>  "root")
>
>
> (mapped-device
>  (logical-volume "some_group" "some_volume")
>  "encrypted data"
>  luks-mapping-type)
>
> etc.

I see.  Looks good!

Does the volume some_group/some_volume have an associated /dev node or
tree?  What does it look like?

Really a detail, but I think "/dev/sda2" or (partition "/dev/sda2") is
enough; no need to abstract it, IMO, since device node name is up to the
user.

> Of course, it would lead to more complicated code to handle such
> configuration, but it would definitely feel more natural.
>
> When other block device type (like iSCSI) would be required, just
> another function (or whatever it is) would be implemented.

Anything special about iSCSI?  I would expect iSCSI partitions/disks to
just have block devices as usual, no?

Thank you!

Ludo’.

Re: LVM support

[Tomáš Čech]

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

On Thu, Apr 16, 2015 at 02:47:52PM +0200, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@gnu.org> skribis:
>
>> On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote:
>
>[...]
>
>>>Sorry I’m not really familiar with LVM.
>>
>> It's implemented using device mapper but instead of mapping one block
>> device to another you map one block device to whole group (like
>> playground where you can do anything).
>
>What do you mean by “whole group”?  A tree under /dev/mapper?

From device node POV it generates
/dev/<volume_group_name>/<logical_volume_name> and it also creates
/dev/mapper/<volume_group_name>-<logical_volume_name> and
/dev/dm-<number>.

From block device perspective it adds another level of "partitioning"
to "physical volume" partitions. You gather block devices (can be
partitions, disks, anything), create volume group to join the space
into one entity and then create logical volumes without caring where
it really is. Logical volumes are useful for resizing, adding and
removing filesystems - it has always the same device node.


>
>>>Technically, if LVM volumes are mapped devices, the best would be to
>>>define a <mapped-device-kind> structure for them, as discussed on IRC
>>>(like ‘luks-device-mapping’ in (gnu system).)
>>
>> I didn't like the idea first because it felt confusing and
>> unatural. Words like `mapping' and `source' and `target' are
>> misleading. But from programming POV it seems to be the easisest
>> approach in the end.
>
>I would think the terms are pretty descriptive, esp. when looking at the
>corresponding section of the manual, but I’m biased.  ;-)

I meant in LVM context of course.

>Now, my understanding of your message is not so much that the terms are
>misleading, but rather that the abstraction is bogus (which appears to
>be the case based on what you say.)
>
>> On the other hand problem starts with need-for-boot?. Device mapped
>> device will be activated during the boot (which is desirable for LVM)
>> only if there is filesystem which uses such device and has
>> `need-for-boot?' set to #t.
>
>Right.  I was hesitant about this approach actually, see 9cb426b8.

Ah, OK, I didn't updated since I started to work on LVM.

>> I needed to tweak operating-system-boot-mapped-devices to not filter
>> mappings of the new type at all. Now it seems to generate initrd
>> capable of booting root filesystem from LVM :)
>
>Nice!  Could you post your working version of the patch, just to make
>things more concrete?

I attach patch to this mail.

>> The thing is that this design is not nice. I always admired Scheme's
>> power in expressing things naturally. mapped-device interface is for
>> mapping 1 block device to 1 block device which will contain 1
>> filesystem.
>
>Understood.  This has nothing to do with Scheme, really.  :-)
>
>> Design I'm thinking about would follow file-system structure. For
>> device property (I'm not sure if this is proper word in Scheme for
>> item of record type) to define functions like `partition' (disk,
>> number), `mapped-device' (source, target, type), `logical-volume' (group,
>> volume) and whatever would be needed further. You could then express
>> your mount in more powerful way like:
>>
>> (partition "sda" 1)
>>
>> (mapped-device
>>  (partition "sda" 2)
>>  "encrypted_swap"
>>  luks-mapping-type)
>>
>> (logical-volume
>>  "system_group"
>>  "root")
>>
>>
>> (mapped-device
>>  (logical-volume "some_group" "some_volume")
>>  "encrypted data"
>>  luks-mapping-type)
>>
>> etc.
>
>I see.  Looks good!
>
>Does the volume some_group/some_volume have an associated /dev node or
>tree?  What does it look like?

Yes, it does, I described above.

>Really a detail, but I think "/dev/sda2" or (partition "/dev/sda2") is
>enough; no need to abstract it, IMO, since device node name is up to the
>user.

Well, I faced situations where such freedom of expression would be
handy, but there were rare. sda says that it is the first found scsi
device in the system but it doesn't say anything about accessibility
of the device (`local-disk' should be introduced as well I think).

>> Of course, it would lead to more complicated code to handle such
>> configuration, but it would definitely feel more natural.
>>
>> When other block device type (like iSCSI) would be required, just
>> another function (or whatever it is) would be implemented.
>
>Anything special about iSCSI?  I would expect iSCSI partitions/disks to
>just have block devices as usual, no?

Yes, but when you have root filesystem on iSCSI, you need to perform
other actions to make that block device available as with device
mapping or LVM...

(You need to configure and establish connection to iSCSI target.)



Ad the progress - current state of the patch is that it should work
for filesystems mounted from initrd. And is ugly.

As I understand the problem, created device nodes are missing after
switch-root and it seems it tried to mount filesystems before starting
eudev. I'll have a look on that again after some sleep.

Thank you for your comments.

S_W


[-- Attachment #1.2: lvm.patch --]
[-- Type: text/plain, Size: 5818 bytes --]

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index caec80f..18d1f06 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -1638,6 +1638,33 @@ mapper.  Kernel components are part of Linux-libre.")
     ;; Command-line tools are GPLv2.
     (license (list gpl2 lgpl2.1))))
 
+(define-public lvm2/static
+  (package
+    (name "lvm2-static")
+    (version (package-version lvm2))
+    (build-system trivial-build-system)
+    (source #f)
+    (arguments
+     `(#:modules ((guix build utils))
+       #:builder
+       (begin
+         (use-modules (guix build utils))
+         (let ((source (string-append (assoc-ref %build-inputs "lvm2") "/sbin"))
+               (bin    (string-append (assoc-ref %outputs "out") "/sbin")))
+           (mkdir-p bin)
+           (for-each (lambda (file)
+                       (copy-file (string-append source "/" file)
+                                  (string-append bin "/" file)))
+                     '("lvm.static" "dmsetup.static"))))))
+
+     (native-inputs `(("lvm2" ,lvm2 "static")))
+     (synopsis "Statically-linked commands from lvm2")
+     (description
+      "This package provides statically-linked binaries dmsetup and lvm taken
+from lvm2 package.  It is meant to be used in initrds.")
+     (home-page (package-home-page lvm2))
+     (license (package-license lvm2))))
+
 (define-public wireless-tools
   (package
     (name "wireless-tools")
diff --git a/gnu/system.scm b/gnu/system.scm
index 6cf12df..7c1e67c 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -41,6 +41,7 @@
   #:use-module (gnu packages compression)
   #:use-module (gnu packages firmware)
   #:autoload   (gnu packages cryptsetup) (cryptsetup)
+  #:autoload   (gnu packages linux) (lvm2/static)
   #:use-module (gnu services)
   #:use-module (gnu services dmd)
   #:use-module (gnu services base)
@@ -86,7 +87,9 @@
             %base-packages
             %base-firmware
 
-            luks-device-mapping))
+            luks-device-mapping
+            lvm-mapping
+            lvm-mapping-used?))
 
 ;;; Commentary:
 ;;;
@@ -208,6 +211,27 @@ file."
    (open open-luks-device)
    (close close-luks-device)))
 
+(define (logical-volume-group-activate source target)
+  #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static")
+                         "vgchange" "--activate" "y" #$target)))
+
+(define (logical-volume-group-deactivate source target)
+  #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static")
+                    "vgchange" "--activate" "n" #$target)))
+
+(define (lvm-mapping-used? devices)
+  (not
+   (null? (filter
+           (lambda (md)
+             (eq? (mapped-device-type md)
+                  lvm-mapping))
+           devices))))
+
+(define lvm-mapping
+  (mapped-device-kind
+   (open  logical-volume-group-activate)
+   (close logical-volume-group-deactivate)))
+
 (define (other-file-system-services os)
   "Return file system services for the file systems of OS that are not marked
 as 'needed-for-boot'."
@@ -267,7 +291,10 @@ from the initrd."
         (file-systems (operating-system-file-systems os)))
    (filter (lambda (md)
              (let ((user (mapped-device-user md file-systems)))
-               (and user (file-system-needed-for-boot? user))))
+               (or
+                (and user (file-system-needed-for-boot? user))
+                (and (eq? (mapped-device-type md)
+                          lvm-mapping)))))
            devices)))
 
 (define (device-mapping-services os)
diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm
index 83685ad..fc8bbd3 100644
--- a/gnu/system/linux-initrd.scm
+++ b/gnu/system/linux-initrd.scm
@@ -25,6 +25,7 @@
                 #:select (%store-prefix))
   #:use-module ((guix derivations)
                 #:select (derivation->output-path))
+  #:use-module (gnu system)
   #:use-module (gnu packages cpio)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages linux)
@@ -212,6 +213,9 @@ loaded at boot time in the order in which they appear."
                   file-systems)
             (list e2fsck/static)
             '())
+      ,@(if (lvm-mapping-used? mapped-devices)
+            (list lvm2/static)
+            '())
       ,@(if volatile-root?
             (list unionfs-fuse/static)
             '())))
@@ -241,7 +245,19 @@ loaded at boot time in the order in which they appear."
 
          (boot-system #:mounts '#$(map file-system->spec file-systems)
                       #:pre-mount (lambda ()
-                                    (and #$@device-mapping-commands))
+                                    (and #$@device-mapping-commands
+                                         ;; If we activated any volume group, we
+                                         ;; need to ensure that device nodes are
+                                         ;; created.  Add code here to call it
+                                         ;; once for all activations.
+                                         #$(when (lvm-mapping-used? mapped-devices)
+                                             #~(zero?
+                                                (system* (string-append
+                                                          #$lvm2/static
+                                                          "/sbin/lvm.static")
+                                                         "vgscan"
+                                                         "--mknodes")))))
+
                       #:linux-modules '#$linux-modules
                       #:linux-module-directory '#$kodir
                       #:qemu-guest-networking? #$qemu-networking?

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: LVM support

[Ludovic Courtès]

Tomáš Čech <sleep_walker@gnu.org> skribis:

> On Thu, Apr 16, 2015 at 02:47:52PM +0200, Ludovic Courtès wrote:
>>Tomáš Čech <sleep_walker@gnu.org> skribis:
>>
>>> On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote:
>>
>>[...]
>>
>>>>Sorry I’m not really familiar with LVM.
>>>
>>> It's implemented using device mapper but instead of mapping one block
>>> device to another you map one block device to whole group (like
>>> playground where you can do anything).
>>
>>What do you mean by “whole group”?  A tree under /dev/mapper?
>
> From device node POV it generates
> /dev/<volume_group_name>/<logical_volume_name> and it also creates
> /dev/mapper/<volume_group_name>-<logical_volume_name> and
> /dev/dm-<number>.

OK.

> From block device perspective it adds another level of "partitioning"
> to "physical volume" partitions. You gather block devices (can be
> partitions, disks, anything), create volume group to join the space
> into one entity and then create logical volumes without caring where
> it really is. Logical volumes are useful for resizing, adding and
> removing filesystems - it has always the same device node.

Yes, that part I knew.  ;-)


[...]

> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -41,6 +41,7 @@
>    #:use-module (gnu packages compression)
>    #:use-module (gnu packages firmware)
>    #:autoload   (gnu packages cryptsetup) (cryptsetup)
> +  #:autoload   (gnu packages linux) (lvm2/static)
>    #:use-module (gnu services)
>    #:use-module (gnu services dmd)
>    #:use-module (gnu services base)
> @@ -86,7 +87,9 @@
>              %base-packages
>              %base-firmware
>  
> -            luks-device-mapping))
> +            luks-device-mapping
> +            lvm-mapping
> +            lvm-mapping-used?))
>  
>  ;;; Commentary:
>  ;;;
> @@ -208,6 +211,27 @@ file."
>     (open open-luks-device)
>     (close close-luks-device)))
>  
> +(define (logical-volume-group-activate source target)
> +  #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static")
> +                         "vgchange" "--activate" "y" #$target)))
> +
> +(define (logical-volume-group-deactivate source target)
> +  #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static")
> +                    "vgchange" "--activate" "n" #$target)))
> +
> +(define (lvm-mapping-used? devices)
> +  (not
> +   (null? (filter
> +           (lambda (md)
> +             (eq? (mapped-device-type md)
> +                  lvm-mapping))
> +           devices))))
> +
> +(define lvm-mapping
> +  (mapped-device-kind
> +   (open  logical-volume-group-activate)
> +   (close logical-volume-group-deactivate)))

This looks good to me!

So I would declare

  (mapped-device
    (source "/dev/sda")
    (target "volume_group_name-logical_volume_name")
    (kind lvm-device-mapping))

and that would give me
/dev/mapper/volume_group_name-logical_volume_name, right?

>  (define (other-file-system-services os)
>    "Return file system services for the file systems of OS that are not marked
>  as 'needed-for-boot'."
> @@ -267,7 +291,10 @@ from the initrd."
>          (file-systems (operating-system-file-systems os)))
>     (filter (lambda (md)
>               (let ((user (mapped-device-user md file-systems)))
> -               (and user (file-system-needed-for-boot? user))))
> +               (or
> +                (and user (file-system-needed-for-boot? user))
> +                (and (eq? (mapped-device-type md)
> +                          lvm-mapping)))))
>             devices)))

I don’t think it’s necessary: if a ‘file-system’ object has
"/dev/mapper/volume_group_name-logical_volume_name" has its ‘device’
field, then this device mapping will automatically be recognized as
needed-for-boot, won’t it?

> --- a/gnu/system/linux-initrd.scm
> +++ b/gnu/system/linux-initrd.scm
> @@ -25,6 +25,7 @@
>                  #:select (%store-prefix))
>    #:use-module ((guix derivations)
>                  #:select (derivation->output-path))
> +  #:use-module (gnu system)
>    #:use-module (gnu packages cpio)
>    #:use-module (gnu packages compression)
>    #:use-module (gnu packages linux)
> @@ -212,6 +213,9 @@ loaded at boot time in the order in which they appear."
>                    file-systems)
>              (list e2fsck/static)
>              '())
> +      ,@(if (lvm-mapping-used? mapped-devices)
> +            (list lvm2/static)
> +            '())
>        ,@(if volatile-root?
>              (list unionfs-fuse/static)
>              '())))
> @@ -241,7 +245,19 @@ loaded at boot time in the order in which they appear."
>  
>           (boot-system #:mounts '#$(map file-system->spec file-systems)
>                        #:pre-mount (lambda ()
> -                                    (and #$@device-mapping-commands))
> +                                    (and #$@device-mapping-commands
> +                                         ;; If we activated any volume group, we
> +                                         ;; need to ensure that device nodes are
> +                                         ;; created.  Add code here to call it
> +                                         ;; once for all activations.
> +                                         #$(when (lvm-mapping-used? mapped-devices)
> +                                             #~(zero?
> +                                                (system* (string-append
> +                                                          #$lvm2/static
> +                                                          "/sbin/lvm.static")
> +                                                         "vgscan"
> +                                                         "--mknodes")))))

So ‘lvm vgchange --activate y’ does not create /dev nodes?  Would it be
possible to change the command returned by
‘logical-volume-group-activate’ to somehow create the nodes?  That would
be ideal.

Thanks!

Ludo’.

Re: LVM support

[Tomáš Čech]

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

On Tue, Apr 21, 2015 at 05:52:33PM +0200, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@gnu.org> skribis:
>
>> On Thu, Apr 16, 2015 at 02:47:52PM +0200, Ludovic Courtès wrote:
>>>Tomáš Čech <sleep_walker@gnu.org> skribis:
>>>
>>>> On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote:
>>>
>>>[...]
>>>
>>>>>Sorry I’m not really familiar with LVM.
>>>>
>>>> It's implemented using device mapper but instead of mapping one block
>>>> device to another you map one block device to whole group (like
>>>> playground where you can do anything).
>>>
>>>What do you mean by “whole group”?  A tree under /dev/mapper?
>>
>> From device node POV it generates
>> /dev/<volume_group_name>/<logical_volume_name> and it also creates
>> /dev/mapper/<volume_group_name>-<logical_volume_name> and
>> /dev/dm-<number>.
>
>OK.
>
>> From block device perspective it adds another level of "partitioning"
>> to "physical volume" partitions. You gather block devices (can be
>> partitions, disks, anything), create volume group to join the space
>> into one entity and then create logical volumes without caring where
>> it really is. Logical volumes are useful for resizing, adding and
>> removing filesystems - it has always the same device node.
>
>Yes, that part I knew.  ;-)
>
>
>[...]
>
>> --- a/gnu/system.scm
>> +++ b/gnu/system.scm
>> @@ -41,6 +41,7 @@
>>    #:use-module (gnu packages compression)
>>    #:use-module (gnu packages firmware)
>>    #:autoload   (gnu packages cryptsetup) (cryptsetup)
>> +  #:autoload   (gnu packages linux) (lvm2/static)
>>    #:use-module (gnu services)
>>    #:use-module (gnu services dmd)
>>    #:use-module (gnu services base)
>> @@ -86,7 +87,9 @@
>>              %base-packages
>>              %base-firmware
>>
>> -            luks-device-mapping))
>> +            luks-device-mapping
>> +            lvm-mapping
>> +            lvm-mapping-used?))
>>
>>  ;;; Commentary:
>>  ;;;
>> @@ -208,6 +211,27 @@ file."
>>     (open open-luks-device)
>>     (close close-luks-device)))
>>
>> +(define (logical-volume-group-activate source target)
>> +  #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static")
>> +                         "vgchange" "--activate" "y" #$target)))
>> +
>> +(define (logical-volume-group-deactivate source target)
>> +  #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static")
>> +                    "vgchange" "--activate" "n" #$target)))
>> +
>> +(define (lvm-mapping-used? devices)
>> +  (not
>> +   (null? (filter
>> +           (lambda (md)
>> +             (eq? (mapped-device-type md)
>> +                  lvm-mapping))
>> +           devices))))
>> +
>> +(define lvm-mapping
>> +  (mapped-device-kind
>> +   (open  logical-volume-group-activate)
>> +   (close logical-volume-group-deactivate)))
>
>This looks good to me!
>
>So I would declare
>
>  (mapped-device
>    (source "/dev/sda")
>    (target "volume_group_name-logical_volume_name")
>    (kind lvm-device-mapping))
>
>and that would give me
>/dev/mapper/volume_group_name-logical_volume_name, right?

Volume group can be on multiple block devices. For now I rely on autodetect
abilities of LVM.

So you would declare:

(mapped-device
  (source "") ; irrelevant for LVM
  (target "volume_group_name")
  (type lvm-mapping))

and that would give you
/dev/mapper/volume_group_name-some_volume
/dev/mapper/volume_group_name-other_volume
...

and more conveniently
/dev/volume_group_name/some_volume
/dev/volume_group_name/other_volume
...

>
>>  (define (other-file-system-services os)
>>    "Return file system services for the file systems of OS that are not marked
>>  as 'needed-for-boot'."
>> @@ -267,7 +291,10 @@ from the initrd."
>>          (file-systems (operating-system-file-systems os)))
>>     (filter (lambda (md)
>>               (let ((user (mapped-device-user md file-systems)))
>> -               (and user (file-system-needed-for-boot? user))))
>> +               (or
>> +                (and user (file-system-needed-for-boot? user))
>> +                (and (eq? (mapped-device-type md)
>> +                          lvm-mapping)))))
>>             devices)))
>
>I don’t think it’s necessary: if a ‘file-system’ object has
>"/dev/mapper/volume_group_name-logical_volume_name" has its ‘device’
>field, then this device mapping will automatically be recognized as
>needed-for-boot, won’t it?

Yes, you're right, this chunk shouldn't be needed at all. Good catch!

>> --- a/gnu/system/linux-initrd.scm
>> +++ b/gnu/system/linux-initrd.scm
>> @@ -25,6 +25,7 @@
>>                  #:select (%store-prefix))
>>    #:use-module ((guix derivations)
>>                  #:select (derivation->output-path))
>> +  #:use-module (gnu system)
>>    #:use-module (gnu packages cpio)
>>    #:use-module (gnu packages compression)
>>    #:use-module (gnu packages linux)
>> @@ -212,6 +213,9 @@ loaded at boot time in the order in which they appear."
>>                    file-systems)
>>              (list e2fsck/static)
>>              '())
>> +      ,@(if (lvm-mapping-used? mapped-devices)
>> +            (list lvm2/static)
>> +            '())
>>        ,@(if volatile-root?
>>              (list unionfs-fuse/static)
>>              '())))
>> @@ -241,7 +245,19 @@ loaded at boot time in the order in which they appear."
>>
>>           (boot-system #:mounts '#$(map file-system->spec file-systems)
>>                        #:pre-mount (lambda ()
>> -                                    (and #$@device-mapping-commands))
>> +                                    (and #$@device-mapping-commands
>> +                                         ;; If we activated any volume group, we
>> +                                         ;; need to ensure that device nodes are
>> +                                         ;; created.  Add code here to call it
>> +                                         ;; once for all activations.
>> +                                         #$(when (lvm-mapping-used? mapped-devices)
>> +                                             #~(zero?
>> +                                                (system* (string-append
>> +                                                          #$lvm2/static
>> +                                                          "/sbin/lvm.static")
>> +                                                         "vgscan"
>> +                                                         "--mknodes")))))
>
>So ‘lvm vgchange --activate y’ does not create /dev nodes?

Right.

>Would it be possible to change the command returned by
>‘logical-volume-group-activate’ to somehow create the nodes?  That would
>be ideal.

There are two actions needed to be taken:
1] volume group activation
2] creation of nodes

This design choice does as many 1] as needed and 2] once in the end.

I could do always 1] and 2] for every volume group, but I didn't find it nice,
since previous 2] calls are useless only slowing down the process. Do you
really think I should change it?

Thanks for your review.

S_W

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: LVM support

[Ludovic Courtès]

Sorry for the delay.

Tomáš Čech <sleep_walker@gnu.org> skribis:

> On Tue, Apr 21, 2015 at 05:52:33PM +0200, Ludovic Courtès wrote:

[...]

>>So I would declare
>>
>>  (mapped-device
>>    (source "/dev/sda")
>>    (target "volume_group_name-logical_volume_name")
>>    (kind lvm-device-mapping))
>>
>>and that would give me
>>/dev/mapper/volume_group_name-logical_volume_name, right?
>
> Volume group can be on multiple block devices. For now I rely on autodetect
> abilities of LVM.
>
> So you would declare:
>
> (mapped-device
>  (source "") ; irrelevant for LVM
>  (target "volume_group_name")
>  (type lvm-mapping))
>
> and that would give you
> /dev/mapper/volume_group_name-some_volume
> /dev/mapper/volume_group_name-other_volume
> ...
>
> and more conveniently
> /dev/volume_group_name/some_volume
> /dev/volume_group_name/other_volume
> ...

OK.  So the ‘source’ is irrelevant because ‘vgscan’ magically creates
the device nodes for volumes such that users don’t have to know what the
underlying block devices are, right?


[...]

>>>           (boot-system #:mounts '#$(map file-system->spec file-systems)
>>>                        #:pre-mount (lambda ()
>>> -                                    (and #$@device-mapping-commands))
>>> +                                    (and #$@device-mapping-commands
>>> +                                         ;; If we activated any volume group, we
>>> +                                         ;; need to ensure that device nodes are
>>> +                                         ;; created.  Add code here to call it
>>> +                                         ;; once for all activations.
>>> +                                         #$(when (lvm-mapping-used? mapped-devices)
>>> +                                             #~(zero?
>>> +                                                (system* (string-append
>>> +                                                          #$lvm2/static
>>> +                                                          "/sbin/lvm.static")
>>> +                                                         "vgscan"
>>> +                                                         "--mknodes")))))
>>
>>So ‘lvm vgchange --activate y’ does not create /dev nodes?
>
> Right.
>
>>Would it be possible to change the command returned by
>>‘logical-volume-group-activate’ to somehow create the nodes?  That would
>>be ideal.
>
> There are two actions needed to be taken:
> 1] volume group activation
> 2] creation of nodes
>
> This design choice does as many 1] as needed and 2] once in the end.
>
> I could do always 1] and 2] for every volume group, but I didn't find it nice,
> since previous 2] calls are useless only slowing down the process. Do you
> really think I should change it?

No, you’re right, what you did makes a lot of sense (thanks for bearing
with me!).

Could you send an updated patch?  It sounds like we’re almost there,
I guess.

Thanks,
Ludo’.

Re: LVM support

[Tomáš Čech]

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

On Sun, May 03, 2015 at 09:59:53PM +0200, Ludovic Courtès wrote:
>Sorry for the delay.

Sorry for all the delays :)

>
>Tomáš Čech <sleep_walker@gnu.org> skribis:
>
>> On Tue, Apr 21, 2015 at 05:52:33PM +0200, Ludovic Courtès wrote:
>
>[...]
>
>>>So I would declare
>>>
>>>  (mapped-device
>>>    (source "/dev/sda")
>>>    (target "volume_group_name-logical_volume_name")
>>>    (kind lvm-device-mapping))
>>>
>>>and that would give me
>>>/dev/mapper/volume_group_name-logical_volume_name, right?
>>
>> Volume group can be on multiple block devices. For now I rely on autodetect
>> abilities of LVM.
>>
>> So you would declare:
>>
>> (mapped-device
>>  (source "") ; irrelevant for LVM
>>  (target "volume_group_name")
>>  (type lvm-mapping))
>>
>> and that would give you
>> /dev/mapper/volume_group_name-some_volume
>> /dev/mapper/volume_group_name-other_volume
>> ...
>>
>> and more conveniently
>> /dev/volume_group_name/some_volume
>> /dev/volume_group_name/other_volume
>> ...
>
>OK.  So the ‘source’ is irrelevant because ‘vgscan’ magically creates
>the device nodes for volumes such that users don’t have to know what the
>underlying block devices are, right?

Yes.


>[...]
>
>>>>           (boot-system #:mounts '#$(map file-system->spec file-systems)
>>>>                        #:pre-mount (lambda ()
>>>> -                                    (and #$@device-mapping-commands))
>>>> +                                    (and #$@device-mapping-commands
>>>> +                                         ;; If we activated any volume group, we
>>>> +                                         ;; need to ensure that device nodes are
>>>> +                                         ;; created.  Add code here to call it
>>>> +                                         ;; once for all activations.
>>>> +                                         #$(when (lvm-mapping-used? mapped-devices)
>>>> +                                             #~(zero?
>>>> +                                                (system* (string-append
>>>> +                                                          #$lvm2/static
>>>> +                                                          "/sbin/lvm.static")
>>>> +                                                         "vgscan"
>>>> +                                                         "--mknodes")))))
>>>
>>>So ‘lvm vgchange --activate y’ does not create /dev nodes?
>>
>> Right.
>>
>>>Would it be possible to change the command returned by
>>>‘logical-volume-group-activate’ to somehow create the nodes?  That would
>>>be ideal.
>>
>> There are two actions needed to be taken:
>> 1] volume group activation
>> 2] creation of nodes
>>
>> This design choice does as many 1] as needed and 2] once in the end.
>>
>> I could do always 1] and 2] for every volume group, but I didn't find it nice,
>> since previous 2] calls are useless only slowing down the process. Do you
>> really think I should change it?
>
>No, you’re right, what you did makes a lot of sense (thanks for bearing
>with me!).

Good.

>Could you send an updated patch?  It sounds like we’re almost there,
>I guess.

Not there yet. Now I need to make some changes with mounting order to help
non-root filesystems on LVM volume.

Right now it seems it tries to:
1] mount all filesystems
2] run udev

But I need to make it:
1] mount /dev
2] run udev service (with the `udevadm settle' in the end)
3] mount the rest of filesystems

It seems that /sys and /proc is mounted already from initrd phase using
mount-essential-file-systems. Is there reason not to put /dev there as well?

I see none so I'll try to add /dev filesystem mounting there (and to
move-essential-file-systems) and remove it from %base-file-systems.

Best regards,

S_W

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: LVM support

[Ludovic Courtès]

Tomáš Čech <sleep_walker@gnu.org> skribis:

> On Sun, May 03, 2015 at 09:59:53PM +0200, Ludovic Courtès wrote:

[...]

>>Could you send an updated patch?  It sounds like we’re almost there,
>>I guess.
>
> Not there yet. Now I need to make some changes with mounting order to help
> non-root filesystems on LVM volume.
>
> Right now it seems it tries to:
> 1] mount all filesystems
> 2] run udev

Right.

> But I need to make it:
> 1] mount /dev
> 2] run udev service (with the `udevadm settle' in the end)
> 3] mount the rest of filesystems

OK.

Note that ‘file-system-service’ has a #:requirements parameter, which is
where we could pass '(udev).  But maybe some of the file systems defined
in (gnu system file-systems) need to be mounted before udev is started.
You’ll have to try.  ;-)

> It seems that /sys and /proc is mounted already from initrd phase using
> mount-essential-file-systems. Is there reason not to put /dev there as well?

The reason to do it this way is that it avoids another special case.
That said, in practice /dev is mounted from the initrd because
%devtmpfs-file-system has ‘needed-for-boot?’ set.

> I see none so I'll try to add /dev filesystem mounting there (and to
> move-essential-file-systems) and remove it from %base-file-systems.

I don’t think this is necessary.

Thanks,
Ludo’.

Roadmap for Guix 1.0

[Ludovic Courtès]

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

Hello Guix!

I’ve pushed to guix/maintenance.git a list of things that IMO we should
do or might want to do for 1.0, with the understanding that 1.0 should
happen in 2018 (or early 2019 at the latest!).  :-)

  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org

The list focuses on “big item” features and tasks, omitting routine bug
fixes and improvements.  Some of these items don’t require a lot of work
or expertise though, so hopefully there’s enough on everyone’s plate.

Feel free to comment, volunteer, add items (but not too many!), remove
items, promote items, etc.  Committers should feel free to edit the file
directly in maintenance.git, especially to mark things as done.  ;-)

Copy of the file attached below.

Ludo’.

PS: I’m starting the discussion but will go AFK soon after sending this
    message.  :-)


[-- Attachment #1.2: The road to 1.0. --]
[-- Type: text/x-org, Size: 2236 bytes --]

#+TITLE: Roadmap for Guix 1.0, 2018
#+STARTUP: hidestars

* 'guix pull' & co.
** TODO 'guix pull' honors ~/.config/guix/channels.scm
*** (guix channels) module provides easy way to build a set of channels
*** (guix inferior) uses that to allow interaction with an arbitrary Guix
** MAYBE 'guix pull' & commit authentication <https://bugs.gnu.org/22883>
** TODO 'guix package -m' (?) allows users to specify a Guix channel
** TODO Profile manifest entries record the channel instance they come from
** TODO build-self.scm trampoline runs faster
* UI/UX
** TODO Add colors for messages (error, warnings, hints, and possibly build logs)
** MAYBE Hide build logs in some UIs, as in ‘wip-ui’ branch & Cuirass
** MAYBE Rework grafts and profile hooks to run as “build continuations” <https://bugs.gnu.org/28310>
** MAYBE Add ‘guix install’ alias
** TODO Add ‘guix system --delete-generations’
** MAYBE Polish & merge ‘wip-installer’
* core
** TODO Update & merge ‘wip-build-systems-gexp’
** MAYBE Merge ‘wip-gexp-hygiene’ if we have a portable way to compute gensyms
** TODO Use [[https://notabug.org/cwebber/guile-gcrypt][Guile-gcrypt]] instead of (guix gcrypt) & co.
** TODO Minimal bootstrap with Mes & co. for i686/x86_64 merged (‘wip-bootstrap’)
** MAYBE Use [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] instead of Bash during bootstrap
* infrastructure
** TODO ci.guix.gnu.org points to berlin.guixsd.org
** TODO ci.guix.gnu.org is the default substitute server; hydra.gnu.org is deprecated
** TODO ARM build machines (+ qemu-binfmt) added behind berlin.guixsd.org
** TODO Tatiana's web UI deployed on berlin.guixsd.org
** TODO Clément's Cuirass improvements deployed (inputs, non-blocking SQLite, etc.)
** TODO web site available at guix.gnu.org
*** DNS already set up with two entries, but how to do deal with LE certs and all?
** TODO Mumi web UI available at patches.guix.gnu.org and bugs.guix.gnu.org
** TODO berlin.guixsd.org has big storage, uses a TTL > 60 days
** TODO Nar bandwidth issues on berlin fixed (nginx misconfiguration?)
* miscellaneous
** TODO “GuixSD” renamed to “Guix System”?
** TODO “Cuirass” renamed to “Guix CI”?

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

Re: Roadmap for Guix 1.0

[Pjotr Prins]

On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote:
> #+TITLE: Roadmap for Guix 1.0, 2018
> #+STARTUP: hidestars
> 
> * 'guix pull' & co.
> ** TODO 'guix pull' honors ~/.config/guix/channels.scm
> *** (guix channels) module provides easy way to build a set of channels
> *** (guix inferior) uses that to allow interaction with an arbitrary Guix
> ** MAYBE 'guix pull' & commit authentication <https://bugs.gnu.org/22883>
> ** TODO 'guix package -m' (?) allows users to specify a Guix channel
> ** TODO Profile manifest entries record the channel instance they come from
> ** TODO build-self.scm trampoline runs faster
> * UI/UX
> ** TODO Add colors for messages (error, warnings, hints, and possibly build logs)
> ** MAYBE Hide build logs in some UIs, as in ‘wip-ui’ branch & Cuirass
> ** MAYBE Rework grafts and profile hooks to run as “build continuations” <https://bugs.gnu.org/28310>
> ** MAYBE Add ‘guix install’ alias
> ** TODO Add ‘guix system --delete-generations’
> ** MAYBE Polish & merge ‘wip-installer’
> * core
> ** TODO Update & merge ‘wip-build-systems-gexp’
> ** MAYBE Merge ‘wip-gexp-hygiene’ if we have a portable way to compute gensyms
> ** TODO Use [[https://notabug.org/cwebber/guile-gcrypt][Guile-gcrypt]] instead of (guix gcrypt) & co.
> ** TODO Minimal bootstrap with Mes & co. for i686/x86_64 merged (‘wip-bootstrap’)
> ** MAYBE Use [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] instead of Bash during bootstrap
> * infrastructure
> ** TODO ci.guix.gnu.org points to berlin.guixsd.org
> ** TODO ci.guix.gnu.org is the default substitute server; hydra.gnu.org is deprecated
> ** TODO ARM build machines (+ qemu-binfmt) added behind berlin.guixsd.org
> ** TODO Tatiana's web UI deployed on berlin.guixsd.org
> ** TODO Clément's Cuirass improvements deployed (inputs, non-blocking SQLite, etc.)
> ** TODO web site available at guix.gnu.org
> *** DNS already set up with two entries, but how to do deal with LE certs and all?
> ** TODO Mumi web UI available at patches.guix.gnu.org and bugs.guix.gnu.org
> ** TODO berlin.guixsd.org has big storage, uses a TTL > 60 days
> ** TODO Nar bandwidth issues on berlin fixed (nginx misconfiguration?)
> * miscellaneous
> ** TODO “GuixSD” renamed to “Guix System”?
> ** TODO “Cuirass” renamed to “Guix CI”?

Are these all really necessary for 1.0? Or can it be 1.1? I think we
are pushing ourselves too much to have all deployment tools and
website stuff aligned ;)

Q: how large a big storage do we need for TTL>60d today? I don't have
a build farm in the USA, but I can create a mirror if you allow rsync
and have guix publish running on guix.genenetwork.org (or any name,
really). Is that of interest?

Pj.

Re: Roadmap for Guix 1.0

[Chris Marusich]

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

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

> #+TITLE: Roadmap for Guix 1.0, 2018

A lot of good stuff!  I hope I can find the time to help knock out some
of these things.

At the moment, I only have this to add: It would be nice if we could
decide on how we will use version numbers going forward and publish a
description of that in the manual or on the website.

I think the important thing is that we publish a description.  The
details of it are less important.  We can use Semantic Versioning [1],
Sentimental Versioning [2], or something totally different.  As long as
we publish our decision and stick to it, everyone will know what to
expect.


Footnotes: 
[1]  https://semver.org/

[2]  It's not my top choice, though!  http://sentimentalversioning.org/

-- 
Chris

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

Re: Roadmap for Guix 1.0

[Pierre Neidhardt]

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

> Sentimental Versioning

Didn't know about this, interesting take... :)

My two cents because I'm not sure it fits the list:

- `man' is broken.
	https://lists.gnu.org/archive/html/help-guix/2018-05/msg00084.html
It seems trivial but I don't think we should put a 1.0 stamp on an OS that can't
display standard documentation correctly.
I'll open a bug about it, I can work on it later.

- As Julien mentioned recently, I think we should provide a "stable"
channel.  Is it already implied by the new (guix channel) module?

- `guix package --upgrade' reverses the order of packages.
	https://lists.gnu.org/archive/html/help-guix/2018-04/msg00070.html
	https://bugs.gnu.org/31142
I think "infinite upgrades" will look very ugly to the casual user, we ought to
fix that :)

- TeXlive... (sigh!)
TeXlive is rather important for lots of users but also lots of packages.
Some packages (e.g. "asymptote" and "mit-scheme") currently depend on the full
TeXlive distribution (5GB).  This is way too much for many users (low disk
space, low bandwidth, or simply lack of time).
I'm working on adding the missing individual TeXlive packages, but it's
surprisingly hard, so help is more than welcome.
	https://lists.gnu.org/archive/html/help-guix/2018-05/msg00218.html
We also need a user hook to install individual packages to the user profile:
	https://bugs.gnu.org/27217

Anything among these deemed for a post 1.0 release?
-- 
Pierre Neidhardt

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

Re: Roadmap for Guix 1.0

[Nils Gillmann]

Pjotr Prins transcribed 2.9K bytes:
> On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote:
> > #+TITLE: Roadmap for Guix 1.0, 2018
> > #+STARTUP: hidestars
> > 
> > * 'guix pull' & co.
> > ** TODO 'guix pull' honors ~/.config/guix/channels.scm
> > *** (guix channels) module provides easy way to build a set of channels
> > *** (guix inferior) uses that to allow interaction with an arbitrary Guix
> > ** MAYBE 'guix pull' & commit authentication <https://bugs.gnu.org/22883>
> > ** TODO 'guix package -m' (?) allows users to specify a Guix channel
> > ** TODO Profile manifest entries record the channel instance they come from
> > ** TODO build-self.scm trampoline runs faster
> > * UI/UX
> > ** TODO Add colors for messages (error, warnings, hints, and possibly build logs)
> > ** MAYBE Hide build logs in some UIs, as in ‘wip-ui’ branch & Cuirass
> > ** MAYBE Rework grafts and profile hooks to run as “build continuations” <https://bugs.gnu.org/28310>
> > ** MAYBE Add ‘guix install’ alias
> > ** TODO Add ‘guix system --delete-generations’
> > ** MAYBE Polish & merge ‘wip-installer’
> > * core
> > ** TODO Update & merge ‘wip-build-systems-gexp’
> > ** MAYBE Merge ‘wip-gexp-hygiene’ if we have a portable way to compute gensyms
> > ** TODO Use [[https://notabug.org/cwebber/guile-gcrypt][Guile-gcrypt]] instead of (guix gcrypt) & co.
> > ** TODO Minimal bootstrap with Mes & co. for i686/x86_64 merged (‘wip-bootstrap’)
> > ** MAYBE Use [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] instead of Bash during bootstrap
> > * infrastructure
> > ** TODO ci.guix.gnu.org points to berlin.guixsd.org
> > ** TODO ci.guix.gnu.org is the default substitute server; hydra.gnu.org is deprecated
> > ** TODO ARM build machines (+ qemu-binfmt) added behind berlin.guixsd.org
> > ** TODO Tatiana's web UI deployed on berlin.guixsd.org
> > ** TODO Clément's Cuirass improvements deployed (inputs, non-blocking SQLite, etc.)
> > ** TODO web site available at guix.gnu.org
> > *** DNS already set up with two entries, but how to do deal with LE certs and all?
> > ** TODO Mumi web UI available at patches.guix.gnu.org and bugs.guix.gnu.org
> > ** TODO berlin.guixsd.org has big storage, uses a TTL > 60 days
> > ** TODO Nar bandwidth issues on berlin fixed (nginx misconfiguration?)
> > * miscellaneous
> > ** TODO “GuixSD” renamed to “Guix System”?
> > ** TODO “Cuirass” renamed to “Guix CI”?
> 
> Are these all really necessary for 1.0? Or can it be 1.1? I think we
> are pushing ourselves too much to have all deployment tools and
> website stuff aligned ;)

I think it's okay. In the end version numbers are just numbers. We are
at 0.15, so we can go all the way up to 1.0 with many version releases
between to fit in parts of 1.0.

> Q: how large a big storage do we need for TTL>60d today? I don't have
> a build farm in the USA, but I can create a mirror if you allow rsync
> and have guix publish running on guix.genenetwork.org (or any name,
> really). Is that of interest?
> 
> Pj.
> 
> 

Re: Roadmap for Guix 1.0

[Pierre Neidhardt]

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

Also how far did we go with LVM support?

-- 
Pierre Neidhardt

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

LVM support

[Ludovic Courtès]

Hi!

Pierre Neidhardt <ambrevar@gmail.com> skribis:

> Also how far did we go with LVM support?

This was discussed looong ago (whether/how the device-mapping code would
be a good fit for LVM) but we don’t have any code.

This would be nice to have, though I wouldn’t consider it a blocker for
1.0.

Ludo’.

Re: Roadmap for Guix 1.0

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> At the moment, I only have this to add: It would be nice if we could
> decide on how we will use version numbers going forward and publish a
> description of that in the manual or on the website.
>
> I think the important thing is that we publish a description.  The
> details of it are less important.  We can use Semantic Versioning [1],
> Sentimental Versioning [2], or something totally different.  As long as
> we publish our decision and stick to it, everyone will know what to
> expect.

Good point!  The difficulty here is that Guix is effectively a large
collection of libraries, which makes it hard to map it to the semver
story, I think.  Or to put it differently, we should map to semver in an
“abstract way”: what semver refers to as “API changes” would rather be
important CLI/API changes.

Thoughts?

Ludo’.

Re: Roadmap for Guix 1.0

[Ludovic Courtès]

Hello,

Pierre Neidhardt <ambrevar@gmail.com> skribis:

> My two cents because I'm not sure it fits the list:
>
> - `man' is broken.
> 	https://lists.gnu.org/archive/html/help-guix/2018-05/msg00084.html

[...]

> - As Julien mentioned recently, I think we should provide a "stable"
> channel.  Is it already implied by the new (guix channel) module?
>
> - `guix package --upgrade' reverses the order of packages.
> 	https://lists.gnu.org/archive/html/help-guix/2018-04/msg00070.html
> 	https://bugs.gnu.org/31142

Agreed, these are “regular bugs” that should be fixed.

Regarding the “stable” channel, it sounds nice, but again we need
machinery to do automatic merging from master to stable when things are
built (if I remember Julien’s proposal correctly.)   I don’t know, I’m
not entirely sure how this could happen.  :-)

> - TeXlive... (sigh!)

Oh right, definitely something we need for 1.0!  It’s great that you
already started looking at importing more packages from TeXLive, even if
that turns out to be incredibly tricky.  Then we’ll need a profile hook
so people have the option to directly install individual texlive
packages in their profile.

Thanks,
Ludo’.

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

Hello everyone,

On 2018-07-29 17:18, ludo@gnu.org wrote:
> Hello Guix!
> 
> I’ve pushed to guix/maintenance.git a list of things that IMO we should
> do or might want to do for 1.0, with the understanding that 1.0 should
> happen in 2018 (or early 2019 at the latest!).  :-)
> 
>   
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
> 

I see no mention of containers. What is the status and goal about that 
subject?


-- 
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: Roadmap for Guix 1.0

[Chris Marusich]

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

Hi Ludo,

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

> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> At the moment, I only have this to add: It would be nice if we could
>> decide on how we will use version numbers going forward and publish a
>> description of that in the manual or on the website.
>>
>> I think the important thing is that we publish a description.  The
>> details of it are less important.  We can use Semantic Versioning [1],
>> Sentimental Versioning [2], or something totally different.  As long as
>> we publish our decision and stick to it, everyone will know what to
>> expect.
>
> Good point!  The difficulty here is that Guix is effectively a large
> collection of libraries, which makes it hard to map it to the semver
> story, I think.  Or to put it differently, we should map to semver in an
> “abstract way”: what semver refers to as “API changes” would rather be
> important CLI/API changes.
>
> Thoughts?

I spoke of version numbers, but what I really meant to say is that for
1.0 and beyond we should clearly set expectations regarding stability.
By properly setting expectations, we can avoid surprises and improve the
experience for people using Guix, especially people trying Guix for the
first time.  The version number scheme is just one aspect of that.

I'm not advocating that we change anything; I'm only advocating that we
should make our stability promise (if any) clear by documenting it.  If
you want to know my thoughts about what sort of stability promise we
should provide, I'd be happy to talk about that also, but here I'm only
saying that we should provide a promise.  The details of the promise are
less important.

If you agree, then perhaps we can proceed along the following lines:

1) Discuss what our stability promise should be.  It might be that we
   decide to simply stick with the status quo and document it.  But
   whatever the result, it should be something that hopefully everyone
   agrees on (especially maintainers and contributors).

2) Document it.  Put it on the website, in the manual, etc.

3) Follow it.  Mention it in the Contributing section of the manual, the
   README, etc., and require people to adhere to it when making changes.

As a maintainer, what do you think?  Does it makes sense for the Guix
project to set expectations by documenting our stability promise?

-- 
Chris

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

Re: Roadmap for Guix 1.0

[Ricardo Wurmus]

Amirouche Boubekki <amirouche@hypermove.net> writes:

>> I’ve pushed to guix/maintenance.git a list of things that IMO we should
>> do or might want to do for 1.0, with the understanding that 1.0 should
>> happen in 2018 (or early 2019 at the latest!).  :-)
>>
>>   https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
>>
>
> I see no mention of containers. What is the status and goal about that
> subject?

What feature regarding containers would you like to know more about?

“guix environment”, for example, supports isolation through container
features.

--
Ricardo

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

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

Le lun. 20 août 2018 à 09:45, Ricardo Wurmus <rekado@elephly.net> a écrit :

>
> Amirouche Boubekki <amirouche@hypermove.net> writes:
>
> >> I’ve pushed to guix/maintenance.git a list of things that IMO we should
> >> do or might want to do for 1.0, with the understanding that 1.0 should
> >> happen in 2018 (or early 2019 at the latest!).  :-)
> >>
> >>
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
> >>
> >
> > I see no mention of containers. What is the status and goal about that
> > subject?
>
> What feature regarding containers would you like to know more about?
>

Thanks for your reply. I use containers (via LXC) as lightweight Virtual
Machines
as such I can emulate my use of LXC with guix already using a VM.

The difference I see between guix containers and LXC is that in LXC the
container
has its own network device and an IP. What I usually do with LXC:

a) start the lxc container
b) ssh into it and

proceed as if I was in a Xen Virtuam Machine.


Have nice day!

>
> “guix environment”, for example, supports isolation through container
>

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

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

"There are only two hard problems in Computer Science: cache 
invalidation and naming things"


On 2018-07-30 03:23, Pjotr Prins wrote:
> On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote:
>> #+TITLE: Roadmap for Guix 1.0, 2018

>> * miscellaneous
>> ** TODO “GuixSD” renamed to “Guix System”?

Guix System is not good because "system" is a word that is too generic.

What about "Guix OS"?

>> ** TODO “Cuirass” renamed to “Guix CI”?

OK

Re: Roadmap for Guix 1.0

[Pierre Neidhardt]

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


> >> ** TODO “GuixSD” renamed to “Guix System”?
>
> Guix System is not good because "system" is a word that is too generic.
>
> What about "Guix OS"?
>
> >> ** TODO “Cuirass” renamed to “Guix CI”?
>
> OK

On the one hand, OS and CI are rather ubiquitous.

On the other hand, I've personally always been wary of excessive use of
abbreviations: newcomers will find documentation and communication cryptic,
while abbreviations proliferate, sometimes out of control.

But I don't think it's the case for Guix OS and even Apple went for "macOS" so I
guess "OS" is pretty safe (much more than "SD" at least).

Conversely, "Guix CI" is much less widespread, although I suppose many
developers are familiar with the term.  I personally prefer unique, easy names
to abbreviations.

- The name "Guix CI" tells developers what it is (continuous integration) while
  "Cuirass" does not.  This is mostly true, however, for almost all applications
  (mpv, firefox, chromium, emacs, <add almost everything here>).

- If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
  will end up with a bunch Guix FS, Guix IP, Guix CD...

-- 
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: Roadmap for Guix 1.0

[Ludovic Courtès]

Hello,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Conversely, "Guix CI" is much less widespread, although I suppose many
> developers are familiar with the term.  I personally prefer unique, easy names
> to abbreviations.
>
> - The name "Guix CI" tells developers what it is (continuous integration) while
>   "Cuirass" does not.  This is mostly true, however, for almost all applications
>   (mpv, firefox, chromium, emacs, <add almost everything here>).
>
> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
>   will end up with a bunch Guix FS, Guix IP, Guix CD...

I think “Guix System” is OK.  Most of the time we’ll just say “Guix”, as
is already the case, and when we need to disambiguate (for instance when
addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
using the Guix distro?”, and everything will be fine.  :-)

The motivation for this name change is that “SD” is obscure to most, as
you note, plus it creates confusion when people visit the web site: the
web site has a “GuixSD” logo, but then it talks about features of the
package manager.  Designating the whole tool set as “Guix” will simplify
this, and we can always be more specific when we need to.

For Cuirass, I think “Guix CI” (or “Guix Continuous”?) is good enough.
It remains a tool primarily for Guix developers anyway, and a secondary
tool in the Guix toolbox.

Ludo’.

Re: Roadmap for Guix 1.0

[Ricardo Wurmus]

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

> Hello,
>
> Pierre Neidhardt <mail@ambrevar.xyz> skribis:
>
>> Conversely, "Guix CI" is much less widespread, although I suppose many
>> developers are familiar with the term.  I personally prefer unique, easy names
>> to abbreviations.
>>
>> - The name "Guix CI" tells developers what it is (continuous integration) while
>>   "Cuirass" does not.  This is mostly true, however, for almost all applications
>>   (mpv, firefox, chromium, emacs, <add almost everything here>).
>>
>> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
>>   will end up with a bunch Guix FS, Guix IP, Guix CD...
>
> I think “Guix System” is OK.

I think so too.

> Most of the time we’ll just say “Guix”, as
> is already the case, and when we need to disambiguate (for instance when
> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> using the Guix distro?”, and everything will be fine.  :-)

Exactly.

I wrote this on IRC:

The name “GuixSD” is opaque and creates an arbitrary distinction between
the system running on bare metal and the systems you can create with the
“guix system” commands.  It makes it difficult to communicate about
Guix.  Do we really offer “a package manager” and a “distro” — or is it
really all one thing with various levels?

The “guix system” command can be used without GuixSD to create Guix
virtual machines or containers.  Describing “guix system” is difficult
when we think in terms of “package manager” vs “distro”.  Guix itself is
also a distro – none of the packages it provides link with the host
system, and the collection of packages is a distribution of free
software.

I think that simplifying the name by using “guix” as a category will
make communication easier.

> The motivation for this name change is that “SD” is obscure to most, as
> you note, plus it creates confusion when people visit the web site: the
> web site has a “GuixSD” logo, but then it talks about features of the
> package manager.  Designating the whole tool set as “Guix” will simplify
> this, and we can always be more specific when we need to.

I agree.

--
Ricardo

Re: Roadmap for Guix 1.0

[Tobias Geerinckx-Rice]

Guix,

Ricardo Wurmus wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
>> I think “Guix System” is OK.
>
> I think so too.

Big +1.

If you use 'guix system', you're using Guix System[0].

It doesn't get less confusing than that.

Kind regards,

T G-R

[0]: The only question left is 'on what?'. Everything, of course.

Re: Roadmap for Guix 1.0

[Nils Gillmann]

Tobias Geerinckx-Rice transcribed 340 bytes:
> Guix,
> 
> Ricardo Wurmus wrote:
> > Ludovic Courtès <ludo@gnu.org> writes:
> > > I think “Guix System” is OK.
> > 
> > I think so too.
> 
> Big +1.
> 
> If you use 'guix system', you're using Guix System[0].
> 
> It doesn't get less confusing than that.
> 
> Kind regards,
> 
> T G-R
> 
> [0]: The only question left is 'on what?'. Everything, of course.
> 

Sounds good for me too.

Re: Roadmap for Guix 1.0

[George Clemmer]

Hi,

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

> Hello,
>
> Pierre Neidhardt <mail@ambrevar.xyz> skribis:
>
>> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
>>   will end up with a bunch Guix FS, Guix IP, Guix CD...
>
> I think “Guix System” is OK.  Most of the time we’ll just say “Guix”, as
> is already the case, and when we need to disambiguate (for instance when
> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> using the Guix distro?”, and everything will be fine.  :-)
>
> The motivation for this name change is that “SD” is obscure to most, as
> you note, plus it creates confusion when people visit the web site: the
> web site has a “GuixSD” logo, but then it talks about features of the
> package manager.  Designating the whole tool set as “Guix” will simplify
> this, and we can always be more specific when we need to.

This is good because it declutters the Guix-Verse for new users.

I suggest that the distinction between GuixOS, package manager, QEMU
image, and source can be re-positioned as download options.

We could simplify the choice of these by improving the download
page. For example ...

1) We could simplify the download labels/descriptions, e.g.,

   "GuixSD 0.15.0 QEMU Image QCOW2 virtual machine (VM) image. Download
   options: x86_64"

   ... might become ...

   "x86_64 VM (GuixSD 0.15.0 QEMU Image QCOW2 virtual machine image)"

2) We could add a feature check list that helps with download selection.

With such changes the support question is: what did you download?

IMO it would be desirable to pick a single term for each download option
and use it obsessively throughout the site and doc. This small thing can
be quite helpful to a noob because it eliminates any confusion that
might be caused by multiple terms meaning the same thing. So, IMO we
should settle on only one of Guix System, GuixSD, GuixOS, or maybe "Guix
bare metal".

- George

Re: Roadmap for Guix 1.0

[Hartmut Goebel]

Am 30.08.2018 um 14:04 schrieb Ludovic Courtès:
> “Guix Continuous”

For me this sounds like a fail-save system which will continue running,
and running, and running.

-- 
Regards
Hartmut Goebel

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

Re: Roadmap for Guix 1.0

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> I think “Guix System” is OK.  Most of the time we’ll just say “Guix”, as
> is already the case, and when we need to disambiguate (for instance when
> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> using the Guix distro?”, and everything will be fine.  :-)

Yes, I found that "SD" is often more confusing than not.

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Roadmap for Guix 1.0

[George Clemmer]

Ricardo Wurmus <rekado@elephly.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello,
>>
>> I think “Guix System” is OK.
>
> I think so too.

I recommend against renaming GuixSD >> "Guix System". Here is Why:

1) A noob would expect "guix system" to refer to the whole Guix
enchilada. If we use it to refer to GuixSD, a specific Guix deployment
mode, we have created a new, counter-intuitive thing we have to explain.

2) As Ricardo points out below, the "guix system" command clashes with
this use of Guix system. This is a second counter-intuitive thing we
would have to explain.

Bottom line: we shouln'd use the general term "Guix System" in any way
beyond, perhaps in a descriptway way, e.g., The Guix project develops
the Guix System, a set of tools that manage software environments.

>> Most of the time we’ll just say “Guix”, as
>> is already the case, and when we need to disambiguate (for instance when
>> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
>> using the Guix distro?”, and everything will be fine.  :-)
>
> Exactly.
>
> I wrote this on IRC:
>
> The name “GuixSD” is opaque and creates an arbitrary distinction between
> the system running on bare metal and the systems you can create with the
> “guix system” commands.  It makes it difficult to communicate about
> Guix.  Do we really offer “a package manager” and a “distro” — or is it
> really all one thing with various levels?
>
> The “guix system” command can be used without GuixSD to create Guix
> virtual machines or containers.  Describing “guix system” is difficult
> when we think in terms of “package manager” vs “distro”.  Guix itself is
> also a distro – none of the packages it provides link with the host
> system, and the collection of packages is a distribution of free
> software.
>
> I think that simplifying the name by using “guix” as a category will
> make communication easier.
>
>> The motivation for this name change is that “SD” is obscure to most, as
>> you note, plus it creates confusion when people visit the web site: the
>> web site has a “GuixSD” logo, but then it talks about features of the
>> package manager.  Designating the whole tool set as “Guix” will simplify
>> this, and we can always be more specific when we need to.
>
> I agree.

I agree too. You may recall that I recommendi this approach when we
discussed the web site in January. That thread includes a product
description [1] that might be a good place to start when describing the
"whole tool set".

[1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html

Re: Roadmap for Guix 1.0

[Ricardo Wurmus]

Hi Chris,

> I'm not advocating that we change anything; I'm only advocating that we
> should make our stability promise (if any) clear by documenting it.  If
> you want to know my thoughts about what sort of stability promise we
> should provide, I'd be happy to talk about that also, but here I'm only
> saying that we should provide a promise.  The details of the promise are
> less important.
>
> If you agree, then perhaps we can proceed along the following lines:
>
> 1) Discuss what our stability promise should be.  It might be that we
>    decide to simply stick with the status quo and document it.  But
>    whatever the result, it should be something that hopefully everyone
>    agrees on (especially maintainers and contributors).
>
> 2) Document it.  Put it on the website, in the manual, etc.
>
> 3) Follow it.  Mention it in the Contributing section of the manual, the
>    README, etc., and require people to adhere to it when making changes.
>
> As a maintainer, what do you think?  Does it makes sense for the Guix
> project to set expectations by documenting our stability promise?

This is difficult.  The version jump signalizes that Guix is ready for
“productive” use; it really merely adjusts the version number in
accordance with how the community has been using Guix.

I’d be wary of putting something more than that in writing.  1.0 means
“this works pretty well” and “you shouldn’t expect sudden large changes
to how this works”.

I’d like to leave the discussion of a stability promise to a time when
we decide to maintain a “stable” branch.  The other kind of stability
applies only to using Guix as a library, which I don’t think is a very
popular use outside of Guix itself.

--
Ricardo

Re: Roadmap for Guix 1.0

[Gábor Boskovits]

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

George Clemmer <myglc2@gmail.com> ezt írta (időpont: 2018. aug. 30., Cs,
21:14):

>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >> Hello,
> >>
> >> I think “Guix System” is OK.
> >
> > I think so too.
>
> I recommend against renaming GuixSD >> "Guix System". Here is Why:
>
> 1) A noob would expect "guix system" to refer to the whole Guix
> enchilada. If we use it to refer to GuixSD, a specific Guix deployment
> mode, we have created a new, counter-intuitive thing we have to explain.
>
> 2) As Ricardo points out below, the "guix system" command clashes with
> this use of Guix system. This is a second counter-intuitive thing we
> would have to explain.
>
> Bottom line: we shouln'd use the general term "Guix System" in any way
> beyond, perhaps in a descriptway way, e.g., The Guix project develops
> the Guix System, a set of tools that manage software environments.
>
> >> Most of the time we’ll just say “Guix”, as
> >> is already the case, and when we need to disambiguate (for instance when
> >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> >> using the Guix distro?”, and everything will be fine.  :-)
> >
> > Exactly.
> >
> > I wrote this on IRC:
> >
> > The name “GuixSD” is opaque and creates an arbitrary distinction between
> > the system running on bare metal and the systems you can create with the
> > “guix system” commands.  It makes it difficult to communicate about
> > Guix.  Do we really offer “a package manager” and a “distro” — or is it
> > really all one thing with various levels?
> >
> > The “guix system” command can be used without GuixSD to create Guix
> > virtual machines or containers.  Describing “guix system” is difficult
> > when we think in terms of “package manager” vs “distro”.  Guix itself is
> > also a distro – none of the packages it provides link with the host
> > system, and the collection of packages is a distribution of free
> > software.
> >
> > I think that simplifying the name by using “guix” as a category will
> > make communication easier.
> >
> >> The motivation for this name change is that “SD” is obscure to most, as
> >> you note, plus it creates confusion when people visit the web site: the
> >> web site has a “GuixSD” logo, but then it talks about features of the
> >> package manager.  Designating the whole tool set as “Guix” will simplify
> >> this, and we can always be more specific when we need to.
> >
> > I agree.
>
> I agree too. You may recall that I recommendi this approach when we
> discussed the web site in January. That thread includes a product
> description [1] that might be a good place to start when describing the
> "whole tool set".
>
> [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html
>
> What do you think about  GuixSD >> "Guix Distribution"? This naming seems
to resolve the ambiguities mentioned so far, and has a widespread
use, that exactly matches the intended meaning. WDYT?

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

Re: Roadmap for Guix 1.0

[Taylan Kammer]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> - The name "Guix CI" tells developers what it is (continuous integration) while
>   "Cuirass" does not.  This is mostly true, however, for almost all applications
>   (mpv, firefox, chromium, emacs, <add almost everything here>).

Just an anecdote: I didn't know what Cuirass was until I read this
thread, though I saw the name many times. :-)

Taylan

Re: Roadmap for Guix 1.0

[George Clemmer]

Gábor Boskovits <boskovits@gmail.com> writes:

> George Clemmer <myglc2@gmail.com> ezt írta (időpont: 2018. aug. 30., Cs,
> 21:14):
>
>>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>> > Ludovic Courtès <ludo@gnu.org> writes:
>> >
>> >> Hello,
>> >>
>> >> I think “Guix System” is OK.
>> >
>> > I think so too.
>>
>> I recommend against renaming GuixSD >> "Guix System". Here is Why:
>>
>> 1) A noob would expect "guix system" to refer to the whole Guix
>> enchilada. If we use it to refer to GuixSD, a specific Guix deployment
>> mode, we have created a new, counter-intuitive thing we have to explain.
>>
>> 2) As Ricardo points out below, the "guix system" command clashes with
>> this use of Guix system. This is a second counter-intuitive thing we
>> would have to explain.
>>
>> Bottom line: we shouln'd use the general term "Guix System" in any way
>> beyond, perhaps in a descriptway way, e.g., The Guix project develops
>> the Guix System, a set of tools that manage software environments.
>>
>> >> Most of the time we’ll just say “Guix”, as
>> >> is already the case, and when we need to disambiguate (for instance when
>> >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
>> >> using the Guix distro?”, and everything will be fine.  :-)
>> >
>> > Exactly.
>> >
>> > I wrote this on IRC:
>> >
>> > The name “GuixSD” is opaque and creates an arbitrary distinction between
>> > the system running on bare metal and the systems you can create with the
>> > “guix system” commands.  It makes it difficult to communicate about
>> > Guix.  Do we really offer “a package manager” and a “distro” — or is it
>> > really all one thing with various levels?
>> >
>> > The “guix system” command can be used without GuixSD to create Guix
>> > virtual machines or containers.  Describing “guix system” is difficult
>> > when we think in terms of “package manager” vs “distro”.  Guix itself is
>> > also a distro – none of the packages it provides link with the host
>> > system, and the collection of packages is a distribution of free
>> > software.
>> >
>> > I think that simplifying the name by using “guix” as a category will
>> > make communication easier.
>> >
>> >> The motivation for this name change is that “SD” is obscure to most, as
>> >> you note, plus it creates confusion when people visit the web site: the
>> >> web site has a “GuixSD” logo, but then it talks about features of the
>> >> package manager.  Designating the whole tool set as “Guix” will simplify
>> >> this, and we can always be more specific when we need to.
>> >
>> > I agree.
>>
>> I agree too. You may recall that I recommendi this approach when we
>> discussed the web site in January. That thread includes a product
>> description [1] that might be a good place to start when describing the
>> "whole tool set".
>>
>> [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html
>>
>> What do you think about  GuixSD >> "Guix Distribution"? This naming seems
> to resolve the ambiguities mentioned so far, and has a widespread
> use, that exactly matches the intended meaning. WDYT?

Hi Gábor,

I think this discussion was primarily triggered by the realization that
we can improve the top-level presentation of Guix by downplaying the
distinction between Guix and GuixSD. In fact, we could delay the
introduction of Guix/GuixSD to the download page.

A more informative download page might look like:

Use Guix to manage ...

entire computers: GuixSD download options: x86_64 i686

VMs: download options: GuixSD x86_64-QEMU-image

GNU/Linux user environments: Guix download options: x86_64, i686, armhf,
aarch64

Here we see the primary purpose of the Guix/GuixSD labels is to identify
the different download options and to enable the user to find the
correct install instructions and doc sections for whatever they
download.

GuixSD doesn't necessarily need to be changed. But the issue has been
raised, as mentioned above, that because "SD" is not a recognized
abbreviation "GuixSD" carries no intuitive meaning. If we want an
improved label for the Guix system distribution, the best one is
probably "GuixOS" since "OS" is a widely used and recognized
abbreviation ...

Term                google hits
OS                  3.0 * 10**9
operating system    0.7 * 10**9
system distribution 0.5 * 10**9

I guess the issue with this is that it seems odd to say "the GNU Guix
GNU/Linux System Distribution, abbreviated GuixOS" ;-)

HTH - George

Re: Roadmap for Guix 1.0

[Vincent Legoll]

Hello,

I was refraining to answer, but this:

On Fri, Aug 31, 2018 at 4:29 PM George Clemmer <myglc2@gmail.com> wrote:
> I think this discussion was primarily triggered by the realization that
> we can improve the top-level presentation of Guix by downplaying the
> distinction between Guix and GuixSD. In fact, we could delay the
> introduction of Guix/GuixSD to the download page.
>
> A more informative download page might look like:
>
> Use Guix to manage ...
>
> entire computers: GuixSD download options: x86_64 i686
>
> VMs: download options: GuixSD x86_64-QEMU-image
>
> GNU/Linux user environments: Guix download options: x86_64, i686, armhf,
> aarch64
>
> Here we see the primary purpose of the Guix/GuixSD labels is to identify
> the different download options and to enable the user to find the
> correct install instructions and doc sections for whatever they
> download.
>
> GuixSD doesn't necessarily need to be changed. But the issue has been
> raised, as mentioned above, that because "SD" is not a recognized
> abbreviation "GuixSD" carries no intuitive meaning. If we want an
> improved label for the Guix system distribution, the best one is
> probably "GuixOS" since "OS" is a widely used and recognized
> abbreviation ...

Is exactly my opinion also, so it gets a +1

Bye

-- 
Vincent Legoll

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

> > >If we want an
> > improved label for the Guix system distribution, the best one is
> > probably "GuixOS" since "OS" is a widely used and recognized
> > abbreviation ...
>
> Is exactly my opinion also, so it gets a +1
>

Top 3:

1) GuixOS
2) Guix
3) Guix System

Re: Roadmap for Guix 1.0

[rchar01]

As an example, PureOS had a similar idea for the name.

- https://www.pureos.net/
- from https://www.gnu.org/distros/free-distros.en.html


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On August 31, 2018 5:54 PM, Amirouche Boubekki <amirouche.boubekki@gmail.com> wrote:

> > > > If we want an
> > > > improved label for the Guix system distribution, the best one is
> > > > probably "GuixOS" since "OS" is a widely used and recognized
> > > > abbreviation ...
> >
> > Is exactly my opinion also, so it gets a +1
>
> Top 3:
>
> 1.  GuixOS
> 2.  Guix
> 3.  Guix System

Re: Roadmap for Guix 1.0

[Pjotr Prins]

On Sat, Sep 01, 2018 at 07:36:35AM +0000, rchar01 wrote:
> As an example, PureOS had a similar idea for the name.
> 
> - https://www.pureos.net/
> - from https://www.gnu.org/distros/free-distros.en.html

We should have some flavours:

FunGuixOs
SeriousGuixOs
VerySeriousGuixOS
VerySeriousGuixOSIndeed

Just kidding. GuixOS sounds fine to me. How will be distinguish
between Linux and Hurd?

GuixLinuxOS
GuixHurdOS

or simplify to

GNU Guix Linux
GNU Guix Hurd

Pj.

Re: Roadmap for Guix 1.0

[Nils Gillmann]

Pjotr Prins transcribed 466 bytes:
> On Sat, Sep 01, 2018 at 07:36:35AM +0000, rchar01 wrote:
> > As an example, PureOS had a similar idea for the name.
> > 
> > - https://www.pureos.net/
> > - from https://www.gnu.org/distros/free-distros.en.html
> 
> We should have some flavours:
> 
> FunGuixOs
> SeriousGuixOs
> VerySeriousGuixOS
> VerySeriousGuixOSIndeed
> 
> Just kidding. GuixOS sounds fine to me. How will be distinguish
> between Linux and Hurd?

We don't have to. Why would you want this?
Simply give a download a descriptive name, and put the details in
parens behind it or a proper description box.

Imagine we get support for one of the BSD kernels in the future. And
then a variant which builds our own BSD-based GuixSD/OS.. you don't
need to come up with a new name every time.

GuixOS (Linux-libre)
GuixOS (Hurd)
GuixOS (obsd)

easy as that

> GuixLinuxOS
> GuixHurdOS
> 
> or simplify to
> 
> GNU Guix Linux
> GNU Guix Hurd
> 
> Pj.
> 

Re: Roadmap for Guix 1.0

[fis trivial]

Ludovic Courtès writes:

> Hello Guix!
>
> I’ve pushed to guix/maintenance.git a list of things that IMO we should
> do or might want to do for 1.0, with the understanding that 1.0 should
> happen in 2018 (or early 2019 at the latest!).  :-)
>
>   https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
>
> The list focuses on “big item” features and tasks, omitting routine bug
> fixes and improvements.  Some of these items don’t require a lot of work
> or expertise though, so hopefully there’s enough on everyone’s plate.
>
> Feel free to comment, volunteer, add items (but not too many!), remove
> items, promote items, etc.  Committers should feel free to edit the file
> directly in maintenance.git, especially to mark things as done.  ;-)
>
> Copy of the file attached below.
>
> Ludo’.
>
> PS: I’m starting the discussion but will go AFK soon after sending this
>     message.  :-)

Hi Ludovic,

For near future version of GUIX, maybe 1.1, would it be possible to:

    Upgrade to latest GCC as base compiler

    Use gold linker as default

Based on experience, newer GCC and gold linker could reduce compilation time
and memory requirement dramatically.  It would be beneficial to both build
farm which have heavy load and laptop users who have very limited memory.

Thanks.
-- 
Jiaming

Re: Roadmap for Guix 1.0

[Adam Van Ymeren]

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

Kinda late to the party here but I think a goal for 1.0 should be to ensure every  single package builds on x86_64 and/or i686 and that most substitutes are available at the time of release.

Having guix claim to have packages which then fail to build can leave a poor first impression.  It's fine for alpha/beta but I think it will be really important for 1.0 to feel as robust as possible.

I'd even say that any packages which don't build for 1.0 should be deleted or at least hidden. Maybe of channels happen we could use a stable vs unstable channels.

That's my 2 cents on 1.0 at least.

On September 4, 2018 6:55:57 PM EDT, fis trivial <ybbs.daans@hotmail.com> wrote:
>
>Ludovic Courtès writes:
>
>> Hello Guix!
>>
>> I’ve pushed to guix/maintenance.git a list of things that IMO we
>should
>> do or might want to do for 1.0, with the understanding that 1.0
>should
>> happen in 2018 (or early 2019 at the latest!).  :-)
>>
>>  
>https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
>>
>> The list focuses on “big item” features and tasks, omitting routine
>bug
>> fixes and improvements.  Some of these items don’t require a lot of
>work
>> or expertise though, so hopefully there’s enough on everyone’s plate.
>>
>> Feel free to comment, volunteer, add items (but not too many!),
>remove
>> items, promote items, etc.  Committers should feel free to edit the
>file
>> directly in maintenance.git, especially to mark things as done.  ;-)
>>
>> Copy of the file attached below.
>>
>> Ludo’.
>>
>> PS: I’m starting the discussion but will go AFK soon after sending
>this
>>     message.  :-)
>
>Hi Ludovic,
>
>For near future version of GUIX, maybe 1.1, would it be possible to:
>
>    Upgrade to latest GCC as base compiler
>
>    Use gold linker as default
>
>Based on experience, newer GCC and gold linker could reduce compilation
>time
>and memory requirement dramatically.  It would be beneficial to both
>build
>farm which have heavy load and laptop users who have very limited
>memory.
>
>Thanks.
>-- 
>Jiaming

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