bug#25852: Users not updating their installations of Guix

bug#25852: Users not updating their installations of Guix

[Leo Famulari]

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

In my opinion, the recent bug #25775 (Can't install packages after guix
pull) [0] exposed a sort of meta-bug: there are a significant number of
users who were still using the guix-daemon from 0.10.0.

It seems unlikely that they have been updating all of root's
packages except for the guix package. Rather, I bet they never updated
root's packages at all, for ~1 year.

I think this is a serious documentation bug.

[0]
https://bugs.gnu.org/25775

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

bug#25852: Users not updating their installations of Guix

[Pjotr Prins]

We can make package 'daemon' aware if we provide the meta data in
channels, see 22629@debbugs.gnu.org. guix package could also suggest
upgrading with even numbers. Say running 0.12 guix on 0.10
guix-daemon. 

bug#25852: Users not updating their installations of Guix

[sirgazil]

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

Yes, I agree with both of you.

I'd like to see a section in the documentation, referenced from the installation instructions, with prescriptions about keeping Guix(SD) up to date. Say "Keeping a Guix(SD) system up to date". It could have, for example, what to do as a root user, what to do as a non-privileged user.

Also, I usually subscribe to the news feed of the software I use regularly. With Debian, for example, I update the system every time I get notified of new updates.[1] I'm subscribed to Guix news too, but I haven't seen posts recommending users to update their systems to fix security issues (except for release announcements). That's something I'd like to see too.

Guix website is currently using Haunt, which allows to generate feeds per tag in the blog, so we could even recommend users in the documentation to subscribe to a "security" news feed to keep informed of important updates.

My 2¢,


[1]: https://www.debian.org/News/2017/20170114



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

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

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

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

On Thu, Feb 23, 2017 at 04:11:56PM -0500, Leo Famulari wrote:
>In my opinion, the recent bug #25775 (Can't install packages after guix
>pull) [0] exposed a sort of meta-bug: there are a significant number of
>users who were still using the guix-daemon from 0.10.0.
>
>It seems unlikely that they have been updating all of root's
>packages except for the guix package. Rather, I bet they never updated
>root's packages at all, for ~1 year.
>
>I think this is a serious documentation bug.

One problem may be that Guix on top of foreign distribution is not
able to update itself.

I still offer guix-0.12 RPM package for openSUSE installation as there
was no new release. Guix is able to update itself via `guix pull' but
it doesn't affect system installation of guix-daemon.

It would help splitting releases of Guix and guix-daemon.

Best regards,

S_W

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

bug#25852: Users not updating their installations of Guix

[Leo Famulari]

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

On Sat, Mar 04, 2017 at 09:29:41PM +0100, Tomáš Čech wrote:
> On Thu, Feb 23, 2017 at 04:11:56PM -0500, Leo Famulari wrote:
> > In my opinion, the recent bug #25775 (Can't install packages after guix
> > pull) [0] exposed a sort of meta-bug: there are a significant number of
> > users who were still using the guix-daemon from 0.10.0.
> > 
> > It seems unlikely that they have been updating all of root's
> > packages except for the guix package. Rather, I bet they never updated
> > root's packages at all, for ~1 year.
> > 
> > I think this is a serious documentation bug.
> 
> One problem may be that Guix on top of foreign distribution is not
> able to update itself.

I can update my Guix-on-Debian systems without trouble, using the normal
`guix pull && guix package -u .` method.

> I still offer guix-0.12 RPM package for openSUSE installation as there
> was no new release. Guix is able to update itself via `guix pull' but
> it doesn't affect system installation of guix-daemon.

Interesting, I didn't know there was a distro package for openSUSE.

For that package, the root user cannot update the guix-daemon?

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

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

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

On Sat, Mar 04, 2017 at 05:43:59PM -0500, Leo Famulari wrote:
>On Sat, Mar 04, 2017 at 09:29:41PM +0100, Tomáš Čech wrote:
>> On Thu, Feb 23, 2017 at 04:11:56PM -0500, Leo Famulari wrote:
>> > In my opinion, the recent bug #25775 (Can't install packages after guix
>> > pull) [0] exposed a sort of meta-bug: there are a significant number of
>> > users who were still using the guix-daemon from 0.10.0.
>> >
>> > It seems unlikely that they have been updating all of root's
>> > packages except for the guix package. Rather, I bet they never updated
>> > root's packages at all, for ~1 year.
>> >
>> > I think this is a serious documentation bug.
>>
>> One problem may be that Guix on top of foreign distribution is not
>> able to update itself.
>
>I can update my Guix-on-Debian systems without trouble, using the normal
>`guix pull && guix package -u .` method.

I'm sorry, I meant guix-daemon here.

>> I still offer guix-0.12 RPM package for openSUSE installation as there
>> was no new release. Guix is able to update itself via `guix pull' but
>> it doesn't affect system installation of guix-daemon.
>
>Interesting, I didn't know there was a distro package for openSUSE.

I'm trying to maintain it for quite a long time already... It's part
of distribution (but not on installation medium :)

>For that package, the root user cannot update the guix-daemon?

root user can do anything, but that is not the point here. The point
is that root user interaction is _required_.

I may alter guix-daemon service file to use
/root/.guix-profile/... path that that is also unsafe hack relying
that root user will not break his stuff.

Splitting packages into 2 could be another way to do it, better, quite natural.

And IMHO the best and also "Guix way" could be making guix-daemon aware of
possible newer versions in /gnu/store and execing them instead...

Best regards,

S_W


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

bug#25852: Users not updating their installations of Guix

[Pjotr Prins]

On Sun, Mar 05, 2017 at 08:56:41AM +0100, Tomáš Čech wrote:
> And IMHO the best and also "Guix way" could be making guix-daemon aware of
> possible newer versions in /gnu/store and execing them instead...

Giving a loud warning should really be sufficient. The Guix way is to
have a system not surprise us by shifting the sand under our feet ;)


-- 

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

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

On Sun, Mar 05, 2017 at 09:25:11AM +0000, Pjotr Prins wrote:
>On Sun, Mar 05, 2017 at 08:56:41AM +0100, Tomáš Čech wrote:
>> And IMHO the best and also "Guix way" could be making guix-daemon aware of
>> possible newer versions in /gnu/store and execing them instead...
>
>Giving a loud warning should really be sufficient. The Guix way is to
>have a system not surprise us by shifting the sand under our feet ;)

Yes, but the surprise is made when your expectations are different
from what is naturally expected.

My expectation is that when `guix pull' is run, it should update whole
guix, not just part (guix - guix-daemon).

Surprise is when it does not do it.

Removing the surprise can be either by splitting the package to make
obvious it is independent part or making `guix pull' able to update
guix-daemon as well.

Loud warning is really sufficient for user (or admin) but not for
distribution package maintainer.

Another option is that I will do the split by myself and take
guix-daemon sources from GIT but I'm sure I'll make much worse job
than you.

Best regards,

S_W

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

bug#25852: Users not updating their installations of Guix

[Ricardo Wurmus]

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

> My expectation is that when `guix pull' is run, it should update whole
> guix, not just part (guix - guix-daemon).

[…]

> Removing the surprise can be […] by […] making `guix pull' able to update
> guix-daemon as well.

That’s what is planned for “guix pull” anyway IIRC.  I suspect this
would be easier if we had a daemon written in Guile.

--
Ricardo Wurmus

bug#25852: Users not updating their installations of Guix

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> In my opinion, the recent bug #25775 (Can't install packages after guix
> pull) [0] exposed a sort of meta-bug: there are a significant number of
> users who were still using the guix-daemon from 0.10.0.
>
> It seems unlikely that they have been updating all of root's
> packages except for the guix package. Rather, I bet they never updated
> root's packages at all, for ~1 year.
>
> I think this is a serious documentation bug.

I’m not sure documentation would help.

Software like Firefox handles that by calling home to know its latest
version, but I’m not sure we want to have that happen automatically.

Thoughts on how we could address this?

Following discussions at the R-B summit, I considered adding a ‘guix
health’ (or similar) command that would report things like vulnerable
software in the profile.  Such a command could also suggest Guix
updates.

Thanks,
Ludo’.

bug#25852: Users not updating their installations of Guix

[Leo Famulari]

On Mon, Mar 06, 2017 at 10:12:21PM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > In my opinion, the recent bug #25775 (Can't install packages after guix
> > pull) [0] exposed a sort of meta-bug: there are a significant number of
> > users who were still using the guix-daemon from 0.10.0.
> >
> > It seems unlikely that they have been updating all of root's
> > packages except for the guix package. Rather, I bet they never updated
> > root's packages at all, for ~1 year.

They could have been stuck with an old daemon if they copied the systemd
or upstart service files we provide.

That problem should be fixed by 613d0895b92c677e0639d5e77c55043e38e020c8
(build: Don't embed absolute paths in .service and .conf service
files.).

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

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

On Mon, Mar 06, 2017 at 04:34:34PM -0500, Leo Famulari wrote:
>On Mon, Mar 06, 2017 at 10:12:21PM +0100, Ludovic Courtès wrote:
>> Leo Famulari <leo@famulari.name> skribis:
>>
>> > In my opinion, the recent bug #25775 (Can't install packages after guix
>> > pull) [0] exposed a sort of meta-bug: there are a significant number of
>> > users who were still using the guix-daemon from 0.10.0.
>> >
>> > It seems unlikely that they have been updating all of root's
>> > packages except for the guix package. Rather, I bet they never updated
>> > root's packages at all, for ~1 year.
>
>They could have been stuck with an old daemon if they copied the systemd
>or upstart service files we provide.
>
>That problem should be fixed by 613d0895b92c677e0639d5e77c55043e38e020c8
>(build: Don't embed absolute paths in .service and .conf service
>files.).

That is right. But

1) there was no release with this "fix"
2) I (as distro package maintainer) didn't take this patch manually as
   it is fragile and hacky. Have you considered fresh guix installation?

Best regards,

S_W

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

bug#25852: Users not updating their installations of Guix

[Pjotr Prins]

On Mon, Mar 06, 2017 at 03:52:07PM +0100, Ricardo Wurmus wrote:
> > Removing the surprise can be […] by […] making `guix pull' able to update
> > guix-daemon as well.
> 
> That’s what is planned for “guix pull” anyway IIRC.  I suspect this
> would be easier if we had a daemon written in Guile.

This is intriguing. You mean that the daemon would be loading modules
in different versions for different users. So, essentially, every user
is running his/her own daemon.

bug#25852: Users not updating their installations of Guix

[Mark H Weaver]

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

> Leo Famulari <leo@famulari.name> skribis:
>
>> In my opinion, the recent bug #25775 (Can't install packages after guix
>> pull) [0] exposed a sort of meta-bug: there are a significant number of
>> users who were still using the guix-daemon from 0.10.0.
>>
>> It seems unlikely that they have been updating all of root's
>> packages except for the guix package. Rather, I bet they never updated
>> root's packages at all, for ~1 year.
>>
>> I think this is a serious documentation bug.
>
> I’m not sure documentation would help.
>
> Software like Firefox handles that by calling home to know its latest
> version, but I’m not sure we want to have that happen automatically.
>
> Thoughts on how we could address this?

We could simply issue a warning if the version of guix currently in use
is more than N hours old, on the assumption that after N hours it's
likely to be stale.  The default value of N might be in the range 48-96
(2-4 days).  A quick perusal through the recent commit log on our master
branch indicates that it's quite rare for 4 days to pass without a
security update.

What do you think?

      Mark

bug#25852: Users not updating their installations of Guix

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Leo Famulari <leo@famulari.name> skribis:
>>
>>> In my opinion, the recent bug #25775 (Can't install packages after guix
>>> pull) [0] exposed a sort of meta-bug: there are a significant number of
>>> users who were still using the guix-daemon from 0.10.0.
>>>
>>> It seems unlikely that they have been updating all of root's
>>> packages except for the guix package. Rather, I bet they never updated
>>> root's packages at all, for ~1 year.
>>>
>>> I think this is a serious documentation bug.
>>
>> I’m not sure documentation would help.
>>
>> Software like Firefox handles that by calling home to know its latest
>> version, but I’m not sure we want to have that happen automatically.
>>
>> Thoughts on how we could address this?
>
> We could simply issue a warning if the version of guix currently in use
> is more than N hours old, on the assumption that after N hours it's
> likely to be stale.  The default value of N might be in the range 48-96
> (2-4 days).  A quick perusal through the recent commit log on our master
> branch indicates that it's quite rare for 4 days to pass without a
> security update.
>
> What do you think?

That sounds like an easy and reasonable approach.

I wonder what would be the best place to emit this warning.  Upon ‘guix
package -i’ maybe?

Ludo’.

bug#25852: Users not updating their installations of Guix

[Leo Famulari]

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

On Tue, Mar 07, 2017 at 07:33:30AM +0100, Tomáš Čech wrote:
> On Mon, Mar 06, 2017 at 04:34:34PM -0500, Leo Famulari wrote:
> > On Mon, Mar 06, 2017 at 10:12:21PM +0100, Ludovic Courtès wrote:
> > > Leo Famulari <leo@famulari.name> skribis:
> > > 
> > > > In my opinion, the recent bug #25775 (Can't install packages after guix
> > > > pull) [0] exposed a sort of meta-bug: there are a significant number of
> > > > users who were still using the guix-daemon from 0.10.0.
> > > >
> > > > It seems unlikely that they have been updating all of root's
> > > > packages except for the guix package. Rather, I bet they never updated
> > > > root's packages at all, for ~1 year.
> > 
> > They could have been stuck with an old daemon if they copied the systemd
> > or upstart service files we provide.
> > 
> > That problem should be fixed by 613d0895b92c677e0639d5e77c55043e38e020c8
> > (build: Don't embed absolute paths in .service and .conf service
> > files.).
> 
> That is right. But
> 
> 1) there was no release with this "fix"
> 2) I (as distro package maintainer) didn't take this patch manually as
>   it is fragile and hacky. Have you considered fresh guix installation?

This will take effect for the next release of Guix; it addresses a
problem that arises when somebody installs the binary release of Guix.

I'm not addressing downstream packages of Guix with this commit.

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

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

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

On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
>On Tue, Mar 07, 2017 at 07:33:30AM +0100, Tomáš Čech wrote:
>> On Mon, Mar 06, 2017 at 04:34:34PM -0500, Leo Famulari wrote:
>> > On Mon, Mar 06, 2017 at 10:12:21PM +0100, Ludovic Courtès wrote:
>> > > Leo Famulari <leo@famulari.name> skribis:
>> > >
>> > > > In my opinion, the recent bug #25775 (Can't install packages after guix
>> > > > pull) [0] exposed a sort of meta-bug: there are a significant number of
>> > > > users who were still using the guix-daemon from 0.10.0.
>> > > >
>> > > > It seems unlikely that they have been updating all of root's
>> > > > packages except for the guix package. Rather, I bet they never updated
>> > > > root's packages at all, for ~1 year.
>> >
>> > They could have been stuck with an old daemon if they copied the systemd
>> > or upstart service files we provide.
>> >
>> > That problem should be fixed by 613d0895b92c677e0639d5e77c55043e38e020c8
>> > (build: Don't embed absolute paths in .service and .conf service
>> > files.).
>>
>> That is right. But
>>
>> 1) there was no release with this "fix"
>> 2) I (as distro package maintainer) didn't take this patch manually as
>>   it is fragile and hacky. Have you considered fresh guix installation?
>
>This will take effect for the next release of Guix; it addresses a
>problem that arises when somebody installs the binary release of Guix.
>
>I'm not addressing downstream packages of Guix with this commit.

I'm sorry, I may not understand correctly your answer.

Are you saying that situation when user freshly installs Guix on
system with systemd (and thus has empty /gnu/store)?

S_W


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

bug#25852: Users not updating their installations of Guix

[Leo Famulari]

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

On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:
> On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
> > This will take effect for the next release of Guix; it addresses a
> > problem that arises when somebody installs the binary release of Guix.
> > 
> > I'm not addressing downstream packages of Guix with this commit.
> 
> I'm sorry, I may not understand correctly your answer.
> 
> Are you saying that situation when user freshly installs Guix on
> system with systemd (and thus has empty /gnu/store)?

The "fix" I pushed will help anyone who does a new installation of Guix
on a Systemd or Upstart-based system, after the next release of Guix.

Specifically, it is meant to address the issue described here:

http://lists.gnu.org/archive/html/guix-devel/2017-01/msg01199.html

This change won't help anyone who already is affected by that issue.

I view it as one small step towards making it probable that users will
keep their their Guix installations up to date.

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

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

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

On Tue, Mar 07, 2017 at 05:22:15PM -0500, Leo Famulari wrote:
>On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:
>> On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
>> > This will take effect for the next release of Guix; it addresses a
>> > problem that arises when somebody installs the binary release of Guix.
>> >
>> > I'm not addressing downstream packages of Guix with this commit.
>>
>> I'm sorry, I may not understand correctly your answer.
>>
>> Are you saying that situation when user freshly installs Guix on
>> system with systemd (and thus has empty /gnu/store)?
>
>The "fix" I pushed will help anyone who does a new installation of Guix
>on a Systemd or Upstart-based system, after the next release of Guix.

Unless I'm missing some other commit, this won't work.

When I perform these steps:
1] ./configure && make && sudo make install (or package installation)
2] mkdir /gnu/store
3] attempt to start daemon will fail as there is no guix-daemon in
   @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
   because there is no guix-daemon in /gnu/store

Without daemon running you won't be able to make one in that location.

Dead end.

Best regards,

S_W

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

bug#25852: Users not updating their installations of Guix

[Leo Famulari]

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

On Wed, Mar 08, 2017 at 07:25:42AM +0100, Tomáš Čech wrote:
> Unless I'm missing some other commit, this won't work.
> 
> When I perform these steps:
> 1] ./configure && make && sudo make install (or package installation)
> 2] mkdir /gnu/store
> 3] attempt to start daemon will fail as there is no guix-daemon in
>   @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
>   because there is no guix-daemon in /gnu/store

I haven't used `make install`. Does this change break it? On my system,
the old @bindir@ method didn't yield a usable guix-daemon.service
either, because there is no '/usr/local/bin/guix-daemon'.

The binary tarball that we distribute includes the guix-daemon in its
store, and the '/var/guix/...' path works too.

There were lots of people trying to follow the Binary Installation
instructions in the manual [0] and getting stuck on step 5. They weren't
able to symlink the systemd service file, and they had to edit the file
too.

With this change, the instructions in the manual should work whether or
not the user copies or symlinks the service file.

[0]
https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html

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

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

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

On Wed, Mar 08, 2017 at 03:45:47AM -0500, Leo Famulari wrote:
>On Wed, Mar 08, 2017 at 07:25:42AM +0100, Tomáš Čech wrote:
>> Unless I'm missing some other commit, this won't work.
>>
>> When I perform these steps:
>> 1] ./configure && make && sudo make install (or package installation)
>> 2] mkdir /gnu/store
>> 3] attempt to start daemon will fail as there is no guix-daemon in
>>   @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
>>   because there is no guix-daemon in /gnu/store
>
>I haven't used `make install`. Does this change break it? On my system,
>the old @bindir@ method didn't yield a usable guix-daemon.service
>either, because there is no '/usr/local/bin/guix-daemon'.
>
>The binary tarball that we distribute includes the guix-daemon in its
>store, and the '/var/guix/...' path works too.
>
>There were lots of people trying to follow the Binary Installation
>instructions in the manual [0] and getting stuck on step 5. They weren't
>able to symlink the systemd service file, and they had to edit the file
>too.
>
>With this change, the instructions in the manual should work whether or
>not the user copies or symlinks the service file.
>
>[0]
>https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html


Thank you for your explanation and your patience. I finally understand
now what you mean with binary installation and understand how it
doesn't break it.

I'll try to fix source installation somehow.

Best regards,

Tomas

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

bug#25852: Users not updating their installations of Guix

[Leo Famulari]

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

On Wed, Mar 08, 2017 at 10:24:19AM +0100, Tomáš Čech wrote:
> Thank you for your explanation and your patience. I finally understand
> now what you mean with binary installation and understand how it
> doesn't break it.

Thank you for continuing to ask for clarification. It's important that
we review each others' work :)

> I'll try to fix source installation somehow.

Please let me know if I can help test it.

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

bug#25852: Users not updating their installations of Guix

[Efraim Flashner]

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

On Wed, Mar 08, 2017 at 01:15:37PM -0500, Leo Famulari wrote:
> On Wed, Mar 08, 2017 at 10:24:19AM +0100, Tomáš Čech wrote:
> > Thank you for your explanation and your patience. I finally understand
> > now what you mean with binary installation and understand how it
> > doesn't break it.
> 
> Thank you for continuing to ask for clarification. It's important that
> we review each others' work :)
> 
> > I'll try to fix source installation somehow.
> 
> Please let me know if I can help test it.

The recommendation I got for aarch64 was to run 'sudo ./pre-inst-env
guix-daemon ...' I think if we do have people starting from the source
and installing that way then 'sudo ./pre-inst-env guix-daemon...'
followed by 'sudo ./pre-inst-env guix package -i guix' would have them
in the same spot with guix-daemon being in /var/guix/..., allowing them
to stop the pre-inst-env daemon and starting it with the systemd/upstart
service.



-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

bug#25852: Users not updating their installations of Guix

[Ludovic Courtès]

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

> On Tue, Mar 07, 2017 at 05:22:15PM -0500, Leo Famulari wrote:
>>On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:
>>> On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
>>> > This will take effect for the next release of Guix; it addresses a
>>> > problem that arises when somebody installs the binary release of Guix.
>>> >
>>> > I'm not addressing downstream packages of Guix with this commit.
>>>
>>> I'm sorry, I may not understand correctly your answer.
>>>
>>> Are you saying that situation when user freshly installs Guix on
>>> system with systemd (and thus has empty /gnu/store)?
>>
>>The "fix" I pushed will help anyone who does a new installation of Guix
>>on a Systemd or Upstart-based system, after the next release of Guix.
>
> Unless I'm missing some other commit, this won't work.
>
> When I perform these steps:
> 1] ./configure && make && sudo make install (or package installation)
> 2] mkdir /gnu/store
> 3] attempt to start daemon will fail as there is no guix-daemon in
>   @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
>   because there is no guix-daemon in /gnu/store
>
> Without daemon running you won't be able to make one in that location.

Good point.

To address this, we might actually need to revert
613d0895b92c677e0639d5e77c55043e38e020c8 (that is, keep @bindir@ in the
.service files), and instead replace @bindir@ with @localstatedir@ in
the recipe of the ‘guix’ package.

That way, the install-from-source scenario Tomáš describes above would
work, *and* the binary tarball would refer to localstatedir as Leo
intended.

WDYT?

Thanks,
Ludo’.

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

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

On Thu, Mar 09, 2017 at 11:58:12AM +0100, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@gnu.org> skribis:
>
>> On Tue, Mar 07, 2017 at 05:22:15PM -0500, Leo Famulari wrote:
>>>On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:
>>>> On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
>>>> > This will take effect for the next release of Guix; it addresses a
>>>> > problem that arises when somebody installs the binary release of Guix.
>>>> >
>>>> > I'm not addressing downstream packages of Guix with this commit.
>>>>
>>>> I'm sorry, I may not understand correctly your answer.
>>>>
>>>> Are you saying that situation when user freshly installs Guix on
>>>> system with systemd (and thus has empty /gnu/store)?
>>>
>>>The "fix" I pushed will help anyone who does a new installation of Guix
>>>on a Systemd or Upstart-based system, after the next release of Guix.
>>
>> Unless I'm missing some other commit, this won't work.
>>
>> When I perform these steps:
>> 1] ./configure && make && sudo make install (or package installation)
>> 2] mkdir /gnu/store
>> 3] attempt to start daemon will fail as there is no guix-daemon in
>>   @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
>>   because there is no guix-daemon in /gnu/store
>>
>> Without daemon running you won't be able to make one in that location.
>
>Good point.
>
>To address this, we might actually need to revert
>613d0895b92c677e0639d5e77c55043e38e020c8 (that is, keep @bindir@ in the
>.service files), and instead replace @bindir@ with @localstatedir@ in
>the recipe of the ‘guix’ package.
>
>That way, the install-from-source scenario Tomáš describes above would
>work, *and* the binary tarball would refer to localstatedir as Leo
>intended.
>
>WDYT?

That will eliminate the problem introduced by the Leo's change but
still keep original problem.

To adress the latter I'm thinking I'll just make simple wrapper script
which will check whether new version in root user's profile exists and
run from @bindir@ if not.

Not the nicest solution but it is safe.

Best regards,

S_W

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

bug#25852: Users not updating their installations of Guix

[Ludovic Courtès]

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

> On Thu, Mar 09, 2017 at 11:58:12AM +0100, Ludovic Courtès wrote:
>>Tomáš Čech <sleep_walker@gnu.org> skribis:
>>
>>> On Tue, Mar 07, 2017 at 05:22:15PM -0500, Leo Famulari wrote:
>>>>On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:
>>>>> On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
>>>>> > This will take effect for the next release of Guix; it addresses a
>>>>> > problem that arises when somebody installs the binary release of Guix.
>>>>> >
>>>>> > I'm not addressing downstream packages of Guix with this commit.
>>>>>
>>>>> I'm sorry, I may not understand correctly your answer.
>>>>>
>>>>> Are you saying that situation when user freshly installs Guix on
>>>>> system with systemd (and thus has empty /gnu/store)?
>>>>
>>>>The "fix" I pushed will help anyone who does a new installation of Guix
>>>>on a Systemd or Upstart-based system, after the next release of Guix.
>>>
>>> Unless I'm missing some other commit, this won't work.
>>>
>>> When I perform these steps:
>>> 1] ./configure && make && sudo make install (or package installation)
>>> 2] mkdir /gnu/store
>>> 3] attempt to start daemon will fail as there is no guix-daemon in
>>>   @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
>>>   because there is no guix-daemon in /gnu/store
>>>
>>> Without daemon running you won't be able to make one in that location.
>>
>>Good point.
>>
>>To address this, we might actually need to revert
>>613d0895b92c677e0639d5e77c55043e38e020c8 (that is, keep @bindir@ in the
>>.service files), and instead replace @bindir@ with @localstatedir@ in
>>the recipe of the ‘guix’ package.
>>
>>That way, the install-from-source scenario Tomáš describes above would
>>work, *and* the binary tarball would refer to localstatedir as Leo
>>intended.
>>
>>WDYT?
>
> That will eliminate the problem introduced by the Leo's change but
> still keep original problem.
>
> To adress the latter I'm thinking I'll just make simple wrapper script
> which will check whether new version in root user's profile exists and
> run from @bindir@ if not.
>
> Not the nicest solution but it is safe.

Hmm, yeah, not great.

I think most people get Guix through the binary tarball though, so
that’s probably the most important thing to address, and maybe we should
just forget the installed-from-source scenario (but document it).

Thoughts?

Ludo’.

bug#25852: Users not updating their installations of Guix

[Mark H Weaver]

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

> Mark H Weaver <mhw@netris.org> skribis:
>
>> We could simply issue a warning if the version of guix currently in use
>> is more than N hours old, on the assumption that after N hours it's
>> likely to be stale.  The default value of N might be in the range 48-96
>> (2-4 days).  A quick perusal through the recent commit log on our master
>> branch indicates that it's quite rare for 4 days to pass without a
>> security update.
>>
>> What do you think?
>
> That sounds like an easy and reasonable approach.
>
> I wonder what would be the best place to emit this warning.  Upon ‘guix
> package -i’ maybe?

Also "guix package -u" and the "guix system" commands that build
systems.  I suspect that many users run "guix pull" as their normal
users but never think to run it as root.

     Mark

bug#25852: Users not updating their installations of Guix

[Ludovic Courtès]

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

Hi there,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> We could simply issue a warning if the version of guix currently in use
>>> is more than N hours old, on the assumption that after N hours it's
>>> likely to be stale.  The default value of N might be in the range 48-96
>>> (2-4 days).  A quick perusal through the recent commit log on our master
>>> branch indicates that it's quite rare for 4 days to pass without a
>>> security update.
>>>
>>> What do you think?
>>
>> That sounds like an easy and reasonable approach.
>>
>> I wonder what would be the best place to emit this warning.  Upon ‘guix
>> package -i’ maybe?
>
> Also "guix package -u" and the "guix system" commands that build
> systems.  I suspect that many users run "guix pull" as their normal
> users but never think to run it as root.

If there are no objections, I’ll push the attached patch.  It sets a
default value of 7 days (which I think is already more aggressive that
what many are doing), which can be overridden with
GUIX_DISTRO_AGE_WARNING.

Ludo’.


[-- Attachment #2: Type: text/x-patch, Size: 4364 bytes --]

diff --git a/guix/scripts.scm b/guix/scripts.scm
index da35e71ac..b9fa561f1 100644
--- a/guix/scripts.scm
+++ b/guix/scripts.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2013, 2014, 2015 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2013, 2014, 2015, 2017 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2014 Deck Pickard <deck.r.pickard@gmail.com>
 ;;; Copyright © 2015, 2016 Alex Kost <alezost@gmail.com>
 ;;;
@@ -27,13 +27,16 @@
   #:use-module (guix packages)
   #:use-module (guix derivations)
   #:use-module (srfi srfi-1)
+  #:use-module (srfi srfi-19)
   #:use-module (srfi srfi-37)
   #:use-module (ice-9 match)
   #:export (args-fold*
             parse-command-line
             maybe-build
             build-package
-            build-package-source))
+            build-package-source
+            %distro-age-warning
+            warn-about-old-distro))
 
 ;;; Commentary:
 ;;;
@@ -136,4 +139,39 @@ Show what and how will/would be built."
                      #:dry-run? dry-run?)
         (return (show-derivation-outputs derivation))))))
 
+(define %distro-age-warning
+  ;; The age (in seconds) above which we warn that the distro is too old.
+  (make-parameter (or (and=> (getenv "GUIX_DISTRO_AGE_WARNING")
+                             (compose time-second
+                                      string->duration))
+                      (* 7 24 3600))))
+
+(define* (warn-about-old-distro #:optional (old (%distro-age-warning))
+                                #:key (suggested-command
+                                       "guix package -u"))
+  "Emit a warning if Guix is older than OLD seconds."
+  (let-syntax ((false-if-not-found
+                (syntax-rules ()
+                  ((_ exp)
+                   (catch 'system-error
+                     (lambda ()
+                       exp)
+                     (lambda args
+                       (if (= ENOENT (system-error-errno args))
+                           #f
+                           (apply throw args))))))))
+    (define age
+      (match (false-if-not-found
+              (lstat (string-append (config-directory) "/latest")))
+        (#f    (* 2 old))
+        (stat  (- (time-second (current-time time-utc))
+                  (stat:mtime stat)))))
+
+    (when (>= age old)
+      (warning (G_ "Your Guix installation is getting old.  Consider
+running 'guix pull' followed by '~a' to get up-to-date
+packages and security updates.\n")
+               suggested-command)
+      (newline (guix-warning-port)))))
+
 ;;; scripts.scm ends here
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index 92676c222..fbe19d522 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -859,6 +859,9 @@ processed, #f otherwise."
                                   (manifest-transaction-install step2)))))
          (new      (manifest-perform-transaction manifest step3)))
 
+    (unless (null? (manifest-transaction-install step3))
+      (warn-about-old-distro))
+
     (unless (manifest-transaction-null? step3)
       (show-manifest-transaction store manifest step3
                                  #:dry-run? dry-run?)
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index 2872bcae6..9c0976750 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -847,6 +847,8 @@ resulting from command-line parsing."
             ((shepherd-graph)
              (export-shepherd-graph os (current-output-port)))
             (else
+             (warn-about-old-distro #:suggested-command
+                                    "guix system reconfigure")
              (perform-action action os
                              #:dry-run? dry?
                              #:derivations-only? (assoc-ref opts
diff --git a/guix/ui.scm b/guix/ui.scm
index e551d48c3..e7cb40927 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -1008,6 +1008,7 @@ following patterns: \"1d\", \"1w\", \"1m\"."
            (make-time time-duration 0
                       (string->number (match:substring match 1)))))
         ((string-match "^([0-9]+)h$" str)
+         =>
          (lambda (match)
            (hours->duration 1 match)))
         ((string-match "^([0-9]+)d$" str)

bug#25852: Users not updating their installations of Guix

[myglc2]

On 05/10/2017 at 15:12 Ludovic Courtès writes:

> Hi there,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Mark H Weaver <mhw@netris.org> skribis:
>>>
>>>> We could simply issue a warning if the version of guix currently in use
>>>> is more than N hours old, on the assumption that after N hours it's
>>>> likely to be stale.  The default value of N might be in the range 48-96
>>>> (2-4 days).  A quick perusal through the recent commit log on our master
>>>> branch indicates that it's quite rare for 4 days to pass without a
>>>> security update.
>>>>
>>>> What do you think?
>>>
>>> That sounds like an easy and reasonable approach.
>>>
>>> I wonder what would be the best place to emit this warning.  Upon ‘guix
>>> package -i’ maybe?
>>
>> Also "guix package -u" and the "guix system" commands that build
>> systems.  I suspect that many users run "guix pull" as their normal
>> users but never think to run it as root.
>
> If there are no objections, I’ll push the attached patch.  It sets a
> default value of 7 days (which I think is already more aggressive that
> what many are doing), which can be overridden with
> GUIX_DISTRO_AGE_WARNING.
>
> Ludo’.

How about extending this ... 

> +      (warning (G_ "Your Guix installation is getting old.  Consider
> +running 'guix pull' followed by '~a' to get up-to-date
> +packages and security updates.\n")

... to inform the user how old the installation is?

bug#25852: Users not updating their installations of Guix

[Ludovic Courtès]

myglc2 <myglc2@gmail.com> skribis:

> How about extending this ... 
>
>> +      (warning (G_ "Your Guix installation is getting old.  Consider
>> +running 'guix pull' followed by '~a' to get up-to-date
>> +packages and security updates.\n")
>
> ... to inform the user how old the installation is?

Good idea.  I did that and pushed as
7fd952e05203d975fcb6cdabd2f742ade1b31b66.

Thanks for your feedback!

Ludo’.

bug#25852: Users not updating their installations of Guix

[Ricardo Wurmus]

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

> myglc2 <myglc2@gmail.com> skribis:
>
>> How about extending this ...
>>
>>> +      (warning (G_ "Your Guix installation is getting old.  Consider
>>> +running 'guix pull' followed by '~a' to get up-to-date
>>> +packages and security updates.\n")
>>
>> ... to inform the user how old the installation is?
>
> Good idea.  I did that and pushed as
> 7fd952e05203d975fcb6cdabd2f742ade1b31b66.

Does this do the right thing when .config/guix/latest points at a git
checkout?  The mtime of the “.config/guix/latest” link on one of my
machines is from 2016, so Guix says it is too old, but it points to a
git checkout, which is recent.

--
Ricardo

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

bug#25852: Users not updating their installations of Guix

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> myglc2 <myglc2@gmail.com> skribis:
>>
>>> How about extending this ...
>>>
>>>> +      (warning (G_ "Your Guix installation is getting old.  Consider
>>>> +running 'guix pull' followed by '~a' to get up-to-date
>>>> +packages and security updates.\n")
>>>
>>> ... to inform the user how old the installation is?
>>
>> Good idea.  I did that and pushed as
>> 7fd952e05203d975fcb6cdabd2f742ade1b31b66.
>
> Does this do the right thing when .config/guix/latest points at a git
> checkout?

No it doesn’t, but I would argue that it unsupported.  ;-)

> The mtime of the “.config/guix/latest” link on one of my machines is
> from 2016, so Guix says it is too old, but it points to a git
> checkout, which is recent.

I would suggest:

  export GUIX_DISTRO_AGE_WARNING=1000m

as a workaround.  WDYT?

Thanks,
Ludo’.

bug#25852: Users not updating their installations of Guix

[myglc2]

On 05/12/2017 at 10:29 Ludovic Courtès writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> myglc2 <myglc2@gmail.com> skribis:
>>>
>>>> How about extending this ...
>>>>
>>>>> +      (warning (G_ "Your Guix installation is getting old.  Consider
>>>>> +running 'guix pull' followed by '~a' to get up-to-date
>>>>> +packages and security updates.\n")
>>>>
>>>> ... to inform the user how old the installation is?
>>>
>>> Good idea.  I did that and pushed as
>>> 7fd952e05203d975fcb6cdabd2f742ade1b31b66.
>>
>> Does this do the right thing when .config/guix/latest points at a git
>> checkout?
>
> No it doesn’t, but I would argue that it unsupported.  ;-)
>
>> The mtime of the “.config/guix/latest” link on one of my machines is
>> from 2016, so Guix says it is too old, but it points to a git
>> checkout, which is recent.
>
> I would suggest:
>
>   export GUIX_DISTRO_AGE_WARNING=1000m
>
> as a workaround.  WDYT?

This alters guix's stock behavior if/when one switches back to using
'guix pull'. Maybe a better thing to do is the following each time you
update guix from a git checkout ...

ln -f -s -T ~/src/guix/ ~/.config/guix/latest
sudo ln -f -s -T ~/src/guix/ /root/.config/guix/latest