Release imminent!

Release imminent!

[Ludovic Courtès]

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

Hello!

The time has come!  :-)

I think we’ve reached, and even surpassed (integration of the daemon
code, /bin/sh, etc.) the goals for the first milestone.  So I’d like to
release Guix 0.1 (on alpha.gnu.org) by the end of the week (ideally on
Friday, 18th).

There are a few things to do by then: I’ll take care of augmenting the
doc, we’ll apply Nikita’s --roll-back patch and I’ll probably add
--upgrade.  Please check whether guix-package works for use cases of
interest to you.  The next few days are also a good time to add more
packages, to make the distro less tiny.

Any other ideas?  Comments?

Thanks,
Ludo’.

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

Re: Release imminent!

[Andreas Enge]

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

Am Samstag, 12. Januar 2013 schrieb Ludovic Courtès:
> Any other ideas?  Comments?

One thing that could be improved: Right now, I still need to start the 
daemon with
   guix-daemon --build-users-group=nixbld
Since this is the recommended setup (at least from the nix manual, I did 
not check if the guix manual gives details), would it be possible to change 
the daemon code in the following way:
If --build-users-group is not given explicitly, check for the group nixbld 
and use it if it exists.

Andreas

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

Re: Release imminent!

[Andreas Enge]

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

Am Sonntag, 13. Januar 2013 schrieb Andreas Enge:
> One thing that could be improved: Right now, I still need to start the
> daemon with
>    guix-daemon --build-users-group=nixbld
> Since this is the recommended setup (at least from the nix manual, I did
> not check if the guix manual gives details), would it be possible to
> change the daemon code in the following way:
> If --build-users-group is not given explicitly, check for the group
> nixbld and use it if it exists.

I did read the manual now; replace "nixbld" by "guix-builder" in the above.
There is a small typo in the manual; the "-m" parameter for useradd should 
be "-c".

Andreas

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

Re: Release imminent!

[Ludovic Courtès]

Hi!

Andreas Enge <andreas@enge.fr> skribis:

> Am Sonntag, 13. Januar 2013 schrieb Andreas Enge:

[...]

>> If --build-users-group is not given explicitly, check for the group
>> nixbld and use it if it exists.

I’m not sure if we want to automatically use a given group name.  What
if that name was used for something else on this machine?  Granted, it’s
unlikely, but it’s not completely impossible either.

> There is a small typo in the manual; the "-m" parameter for useradd should 
> be "-c".

Indeed, fixed.

Thanks,
Ludo’.

Re: Release imminent!

[Andreas Enge]

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

Am Sonntag, 13. Januar 2013 schrieb Ludovic Courtès:
> >> If --build-users-group is not given explicitly, check for the group
> >> nixbld and use it if it exists.
> I’m not sure if we want to automatically use a given group name.  What
> if that name was used for something else on this machine?  Granted, it’s
> unlikely, but it’s not completely impossible either.

In that case, the user would have to give the builder group explicitly 
anyway. I think that using the guix-builder group as a default should be a 
very safe bet.

Andreas

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

Re: Release imminent!

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Am Sonntag, 13. Januar 2013 schrieb Ludovic Courtès:
>> >> If --build-users-group is not given explicitly, check for the group
>> >> nixbld and use it if it exists.
>> I’m not sure if we want to automatically use a given group name.  What
>> if that name was used for something else on this machine?  Granted, it’s
>> unlikely, but it’s not completely impossible either.
>
> In that case, the user would have to give the builder group explicitly 
> anyway.

Yes, but if they don’t, it’ll end up using real users, which could be a
bad idea.

Note that currently, when --build-users-group is omitted and the daemon
runs as root, a warning is emitted.

Ludo’.

Re: Release imminent!

[Nikita Karetnikov]

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

> One thing that could be improved: Right now, I still need to start the daemon
> with

> guix-daemon --build-users-group=nixbld

I don't see the problem.  Save the above to a file if you don't want to
type the option.  And run that file instead.

Nikita

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

Re: Release imminent!

[Nikita Karetnikov]

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

> There are a few things to do by then: I’ll take care of augmenting the
> doc, we’ll apply Nikita’s --roll-back patch and I’ll probably add
> --upgrade.

I have some comments about the manual [1] and questions about Guix
itself.

1. Can we change quotes?

  "Although GNU programs traditionally used 0x60 (‘`’) for opening and
   0x27 (‘'’) for closing quotes, nowadays quotes ‘`like this'’ are
   typically rendered asymmetrically, so quoting ‘"like this"’ or
   ‘'like this'’ typically looks better." [2]

2. "The build procedure for Guix is the same as for other GNU
   software, and are not covered here." [1]

   I think that it would be better to change it like this: "The build
   procedure for Guix is the same as for other GNU software and it is not
   covered here."

3. Could anyone add more about these?

  `--disable-log-compression'
       Disable compression of the build logs.

  `--disable-store-optimization'
       Disable automatic file "deduplication" in the store.

   Do compression and optimization have any disadvantages?

4. "as a unprivileged user" [1] should be changed to "as an
   unprivileged user."

5. Will it be possible to change 'guix-daemon' to run without root
   privileges and also catch impurities?

   I read the corresponding section.  Does it describe the current
   state of Guix or the limitations of the GNU system?

6. "By default, `guix-daemon' launches build processes under different
   UIDs, taken from the build group specified with
   `--build-users-group'.  In addition, each build process is run in a
   chroot environment that only contains the subset of the store that
   the build process depends on, as specified by its derivation (*note
   derivation: Programming Interface.), plus a set of specific system
   directories." [1]

   I guess that "runs" should be used instead of "is run."

7. "The command provides the obvious install, remove, and upgrade
   operations.  Each invocation is actually a _transaction_: either the
   specified operation succeeds, or nothing happens.  Thus, if the
   `guix-package' processed is terminated during the transaction, or if a
   power outage occurs during the transaction, then the user's profile
   remains in its previous state, and remains usable." [1]

   Will it be possible to resume the terminated transaction later?
   It's useful if you have a bad connection.

8. "The `guix-gc' command has three modes of operations: it can be
   used [...]" [1]

   It would be better to remove "of operations."

9. What is the difference between 'guix-build' and 'guix-package -i'?
   And why do we need both?

   'guix-package -i' creates a new profile, right?

Nikita

[1] http://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi
[2] https://www.gnu.org/prep/standards/standards.html#Quote-Characters

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

Re: Release imminent!

[Ludovic Courtès]

Hi,

Nikita Karetnikov <nikita@karetnikov.org> skribis:

> 1. Can we change quotes?

Not in Texinfo source: Texinfo (and TeX) interpret ASCII quotation marks
and emit the right thing.

> 2. "The build procedure for Guix is the same as for other GNU
>    software, and are not covered here." [1]
>
>    I think that it would be better to change it like this: "The build
>    procedure for Guix is the same as for other GNU software and it is not
>    covered here."

Indeed.

> 3. Could anyone add more about these?
>
>   `--disable-log-compression'
>        Disable compression of the build logs.
>
>   `--disable-store-optimization'
>        Disable automatic file "deduplication" in the store.
>
>    Do compression and optimization have any disadvantages?

Not really.  I’ll add something about that.

> 4. "as a unprivileged user" [1] should be changed to "as an
>    unprivileged user."

Right.

> 5. Will it be possible to change 'guix-daemon' to run without root
>    privileges and also catch impurities?
>
>    I read the corresponding section.  Does it describe the current
>    state of Guix or the limitations of the GNU system?

On GNU/Linux and GNU/kFreeBSD, chroot(2) is only available to root; on
GNU/Hurd, unprivileged users can use it too.

> 6. "By default, `guix-daemon' launches build processes under different
>    UIDs, taken from the build group specified with
>    `--build-users-group'.  In addition, each build process is run in a
>    chroot environment that only contains the subset of the store that
>    the build process depends on, as specified by its derivation (*note
>    derivation: Programming Interface.), plus a set of specific system
>    directories." [1]
>
>    I guess that "runs" should be used instead of "is run."

No, because it means “is run [by the daemon] in a chroot environment”.

> 7. "The command provides the obvious install, remove, and upgrade
>    operations.  Each invocation is actually a _transaction_: either the
>    specified operation succeeds, or nothing happens.  Thus, if the
>    `guix-package' processed is terminated during the transaction, or if a
>    power outage occurs during the transaction, then the user's profile
>    remains in its previous state, and remains usable." [1]
>
>    Will it be possible to resume the terminated transaction later?
>    It's useful if you have a bad connection.

Of course.  If you hit C-c in the middle of an installation, you can
start over, and only packages that have not been built yet will get
built.

> 8. "The `guix-gc' command has three modes of operations: it can be
>    used [...]" [1]
>
>    It would be better to remove "of operations."

Hmm, I just removed the ‘s’.  :-)

> 9. What is the difference between 'guix-build' and 'guix-package -i'?
>    And why do we need both?
>
>    'guix-package -i' creates a new profile, right?

‘guix-build’ is for packagers, when you want to build something without
actually adding it to your profile, whereas ‘guix-package -i’ is for
when you want to add something to your profile.

Do you think this should be clarified somehow?

Thanks!

Ludo’.

Re: Release imminent!

[Nikita Karetnikov]

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

> ‘guix-build’ is for packagers, when you want to build something without
> actually adding it to your profile, whereas ‘guix-package -i’ is for
> when you want to add something to your profile.

> Do you think this should be clarified somehow?

Yes.  Could you add something to the "Invoking guix-build" section?

For example:

The guix-build command builds packages or derivations and their
dependencies, and prints the resulting store paths. Note that it doesn't
add anything to the user's profile. So it is mainly useful for
distribution developers.

Nikita

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

Re: Release imminent!

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

>> ‘guix-build’ is for packagers, when you want to build something without
>> actually adding it to your profile, whereas ‘guix-package -i’ is for
>> when you want to add something to your profile.
>
>> Do you think this should be clarified somehow?
>
> Yes.  Could you add something to the "Invoking guix-build" section?
>
> For example:
>
> The guix-build command builds packages or derivations and their
> dependencies, and prints the resulting store paths. Note that it doesn't
> add anything to the user's profile. So it is mainly useful for
> distribution developers.

I incorporated this suggestion, thanks!

Ludo’.

Re: Release imminent!

[Ludovic Courtès]

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

Hi!

We did it!  ;-)  Congratulations, and special thanks to you, Nikita and
Andreas, for your hard work and for your confidence.

Ludo’.

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