all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#25852: Users not updating their installations of Guix
@ 2017-02-23 21:11 Leo Famulari
  2017-02-24  5:42 ` Pjotr Prins
                   ` (3 more replies)
  0 siblings, 4 replies; 33+ messages in thread
From: Leo Famulari @ 2017-02-23 21:11 UTC (permalink / raw)
  To: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-02-23 21:11 bug#25852: Users not updating their installations of Guix Leo Famulari
@ 2017-02-24  5:42 ` Pjotr Prins
  2017-03-02 18:16 ` sirgazil
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 33+ messages in thread
From: Pjotr Prins @ 2017-02-24  5:42 UTC (permalink / raw)
  To: Leo Famulari; +Cc: 25852

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. 

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-02-23 21:11 bug#25852: Users not updating their installations of Guix Leo Famulari
  2017-02-24  5:42 ` Pjotr Prins
@ 2017-03-02 18:16 ` sirgazil
  2017-03-04 20:29 ` Tomáš Čech
  2017-03-06 21:12 ` Ludovic Courtès
  3 siblings, 0 replies; 33+ messages in thread
From: sirgazil @ 2017-03-02 18:16 UTC (permalink / raw)
  To: 25852@debbugs.gnu.org

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-02-23 21:11 bug#25852: Users not updating their installations of Guix Leo Famulari
  2017-02-24  5:42 ` Pjotr Prins
  2017-03-02 18:16 ` sirgazil
@ 2017-03-04 20:29 ` Tomáš Čech
  2017-03-04 22:43   ` Leo Famulari
  2017-03-06 21:12 ` Ludovic Courtès
  3 siblings, 1 reply; 33+ messages in thread
From: Tomáš Čech @ 2017-03-04 20:29 UTC (permalink / raw)
  To: Leo Famulari; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-04 20:29 ` Tomáš Čech
@ 2017-03-04 22:43   ` Leo Famulari
  2017-03-05  7:56     ` Tomáš Čech
  0 siblings, 1 reply; 33+ messages in thread
From: Leo Famulari @ 2017-03-04 22:43 UTC (permalink / raw)
  To: Tomáš Čech; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-04 22:43   ` Leo Famulari
@ 2017-03-05  7:56     ` Tomáš Čech
  2017-03-05  9:25       ` Pjotr Prins
  0 siblings, 1 reply; 33+ messages in thread
From: Tomáš Čech @ 2017-03-05  7:56 UTC (permalink / raw)
  To: Leo Famulari; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-05  7:56     ` Tomáš Čech
@ 2017-03-05  9:25       ` Pjotr Prins
  2017-03-05  9:43         ` Tomáš Čech
  0 siblings, 1 reply; 33+ messages in thread
From: Pjotr Prins @ 2017-03-05  9:25 UTC (permalink / raw)
  To: Tomáš Čech; +Cc: 25852

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 ;)


-- 

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-05  9:25       ` Pjotr Prins
@ 2017-03-05  9:43         ` Tomáš Čech
  2017-03-06 14:52           ` Ricardo Wurmus
  0 siblings, 1 reply; 33+ messages in thread
From: Tomáš Čech @ 2017-03-05  9:43 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-05  9:43         ` Tomáš Čech
@ 2017-03-06 14:52           ` Ricardo Wurmus
  2017-03-07  6:54             ` Pjotr Prins
  0 siblings, 1 reply; 33+ messages in thread
From: Ricardo Wurmus @ 2017-03-06 14:52 UTC (permalink / raw)
  To: Tomáš Čech; +Cc: 25852


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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-02-23 21:11 bug#25852: Users not updating their installations of Guix Leo Famulari
                   ` (2 preceding siblings ...)
  2017-03-04 20:29 ` Tomáš Čech
@ 2017-03-06 21:12 ` Ludovic Courtès
  2017-03-06 21:34   ` Leo Famulari
  2017-03-07  7:32   ` Mark H Weaver
  3 siblings, 2 replies; 33+ messages in thread
From: Ludovic Courtès @ 2017-03-06 21:12 UTC (permalink / raw)
  To: Leo Famulari; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-06 21:12 ` Ludovic Courtès
@ 2017-03-06 21:34   ` Leo Famulari
  2017-03-07  6:33     ` Tomáš Čech
  2017-03-07  7:32   ` Mark H Weaver
  1 sibling, 1 reply; 33+ messages in thread
From: Leo Famulari @ 2017-03-06 21:34 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-06 21:34   ` Leo Famulari
@ 2017-03-07  6:33     ` Tomáš Čech
  2017-03-07 19:51       ` Leo Famulari
  0 siblings, 1 reply; 33+ messages in thread
From: Tomáš Čech @ 2017-03-07  6:33 UTC (permalink / raw)
  To: Leo Famulari; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-06 14:52           ` Ricardo Wurmus
@ 2017-03-07  6:54             ` Pjotr Prins
  0 siblings, 0 replies; 33+ messages in thread
From: Pjotr Prins @ 2017-03-07  6:54 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: 25852

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.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-06 21:12 ` Ludovic Courtès
  2017-03-06 21:34   ` Leo Famulari
@ 2017-03-07  7:32   ` Mark H Weaver
  2017-03-07 10:35     ` Ludovic Courtès
  1 sibling, 1 reply; 33+ messages in thread
From: Mark H Weaver @ 2017-03-07  7:32 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-07  7:32   ` Mark H Weaver
@ 2017-03-07 10:35     ` Ludovic Courtès
  2017-03-11  1:48       ` Mark H Weaver
  0 siblings, 1 reply; 33+ messages in thread
From: Ludovic Courtès @ 2017-03-07 10:35 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-07  6:33     ` Tomáš Čech
@ 2017-03-07 19:51       ` Leo Famulari
  2017-03-07 20:58         ` Tomáš Čech
  0 siblings, 1 reply; 33+ messages in thread
From: Leo Famulari @ 2017-03-07 19:51 UTC (permalink / raw)
  To: Tomáš Čech; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-07 19:51       ` Leo Famulari
@ 2017-03-07 20:58         ` Tomáš Čech
  2017-03-07 22:22           ` Leo Famulari
  0 siblings, 1 reply; 33+ messages in thread
From: Tomáš Čech @ 2017-03-07 20:58 UTC (permalink / raw)
  To: Leo Famulari; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-07 20:58         ` Tomáš Čech
@ 2017-03-07 22:22           ` Leo Famulari
  2017-03-08  6:25             ` Tomáš Čech
  0 siblings, 1 reply; 33+ messages in thread
From: Leo Famulari @ 2017-03-07 22:22 UTC (permalink / raw)
  To: Tomáš Čech; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-07 22:22           ` Leo Famulari
@ 2017-03-08  6:25             ` Tomáš Čech
  2017-03-08  8:45               ` Leo Famulari
  2017-03-09 10:58               ` Ludovic Courtès
  0 siblings, 2 replies; 33+ messages in thread
From: Tomáš Čech @ 2017-03-08  6:25 UTC (permalink / raw)
  To: Leo Famulari; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-08  6:25             ` Tomáš Čech
@ 2017-03-08  8:45               ` Leo Famulari
  2017-03-08  9:24                 ` Tomáš Čech
  2017-03-09 10:58               ` Ludovic Courtès
  1 sibling, 1 reply; 33+ messages in thread
From: Leo Famulari @ 2017-03-08  8:45 UTC (permalink / raw)
  To: Tomáš Čech; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-08  8:45               ` Leo Famulari
@ 2017-03-08  9:24                 ` Tomáš Čech
  2017-03-08 18:15                   ` Leo Famulari
  0 siblings, 1 reply; 33+ messages in thread
From: Tomáš Čech @ 2017-03-08  9:24 UTC (permalink / raw)
  To: Leo Famulari; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-08  9:24                 ` Tomáš Čech
@ 2017-03-08 18:15                   ` Leo Famulari
  2017-03-09  7:38                     ` Efraim Flashner
  0 siblings, 1 reply; 33+ messages in thread
From: Leo Famulari @ 2017-03-08 18:15 UTC (permalink / raw)
  To: Tomáš Čech; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-08 18:15                   ` Leo Famulari
@ 2017-03-09  7:38                     ` Efraim Flashner
  0 siblings, 0 replies; 33+ messages in thread
From: Efraim Flashner @ 2017-03-09  7:38 UTC (permalink / raw)
  To: Leo Famulari; +Cc: Tomáš Čech, 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-08  6:25             ` Tomáš Čech
  2017-03-08  8:45               ` Leo Famulari
@ 2017-03-09 10:58               ` Ludovic Courtès
  2017-03-09 12:42                 ` Tomáš Čech
  1 sibling, 1 reply; 33+ messages in thread
From: Ludovic Courtès @ 2017-03-09 10:58 UTC (permalink / raw)
  To: Tomáš Čech; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-09 10:58               ` Ludovic Courtès
@ 2017-03-09 12:42                 ` Tomáš Čech
  2017-03-09 15:42                   ` Ludovic Courtès
  0 siblings, 1 reply; 33+ messages in thread
From: Tomáš Čech @ 2017-03-09 12:42 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-09 12:42                 ` Tomáš Čech
@ 2017-03-09 15:42                   ` Ludovic Courtès
  0 siblings, 0 replies; 33+ messages in thread
From: Ludovic Courtès @ 2017-03-09 15:42 UTC (permalink / raw)
  To: Tomáš Čech; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-07 10:35     ` Ludovic Courtès
@ 2017-03-11  1:48       ` Mark H Weaver
  2017-05-10 13:12         ` Ludovic Courtès
  0 siblings, 1 reply; 33+ messages in thread
From: Mark H Weaver @ 2017-03-11  1:48 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 25852

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-03-11  1:48       ` Mark H Weaver
@ 2017-05-10 13:12         ` Ludovic Courtès
  2017-05-10 14:13           ` myglc2
  0 siblings, 1 reply; 33+ messages in thread
From: Ludovic Courtès @ 2017-05-10 13:12 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: 25852

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

^ permalink raw reply related	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-05-10 13:12         ` Ludovic Courtès
@ 2017-05-10 14:13           ` myglc2
  2017-05-10 20:16             ` Ludovic Courtès
  0 siblings, 1 reply; 33+ messages in thread
From: myglc2 @ 2017-05-10 14:13 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 25852

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?

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-05-10 14:13           ` myglc2
@ 2017-05-10 20:16             ` Ludovic Courtès
  2017-05-12  6:06               ` Ricardo Wurmus
  0 siblings, 1 reply; 33+ messages in thread
From: Ludovic Courtès @ 2017-05-10 20:16 UTC (permalink / raw)
  To: myglc2; +Cc: 25852-done

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-05-10 20:16             ` Ludovic Courtès
@ 2017-05-12  6:06               ` Ricardo Wurmus
  2017-05-12  8:29                 ` Ludovic Courtès
  0 siblings, 1 reply; 33+ messages in thread
From: Ricardo Wurmus @ 2017-05-12  6:06 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 25852-done, myglc2


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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-05-12  6:06               ` Ricardo Wurmus
@ 2017-05-12  8:29                 ` Ludovic Courtès
  2017-05-12 17:10                   ` myglc2
  0 siblings, 1 reply; 33+ messages in thread
From: Ludovic Courtès @ 2017-05-12  8:29 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: 25852-done, myglc2

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

* bug#25852: Users not updating their installations of Guix
  2017-05-12  8:29                 ` Ludovic Courtès
@ 2017-05-12 17:10                   ` myglc2
  0 siblings, 0 replies; 33+ messages in thread
From: myglc2 @ 2017-05-12 17:10 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 25852-done

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

^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2017-05-12 17:11 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-23 21:11 bug#25852: Users not updating their installations of Guix Leo Famulari
2017-02-24  5:42 ` Pjotr Prins
2017-03-02 18:16 ` sirgazil
2017-03-04 20:29 ` Tomáš Čech
2017-03-04 22:43   ` Leo Famulari
2017-03-05  7:56     ` Tomáš Čech
2017-03-05  9:25       ` Pjotr Prins
2017-03-05  9:43         ` Tomáš Čech
2017-03-06 14:52           ` Ricardo Wurmus
2017-03-07  6:54             ` Pjotr Prins
2017-03-06 21:12 ` Ludovic Courtès
2017-03-06 21:34   ` Leo Famulari
2017-03-07  6:33     ` Tomáš Čech
2017-03-07 19:51       ` Leo Famulari
2017-03-07 20:58         ` Tomáš Čech
2017-03-07 22:22           ` Leo Famulari
2017-03-08  6:25             ` Tomáš Čech
2017-03-08  8:45               ` Leo Famulari
2017-03-08  9:24                 ` Tomáš Čech
2017-03-08 18:15                   ` Leo Famulari
2017-03-09  7:38                     ` Efraim Flashner
2017-03-09 10:58               ` Ludovic Courtès
2017-03-09 12:42                 ` Tomáš Čech
2017-03-09 15:42                   ` Ludovic Courtès
2017-03-07  7:32   ` Mark H Weaver
2017-03-07 10:35     ` Ludovic Courtès
2017-03-11  1:48       ` Mark H Weaver
2017-05-10 13:12         ` Ludovic Courtès
2017-05-10 14:13           ` myglc2
2017-05-10 20:16             ` Ludovic Courtès
2017-05-12  6:06               ` Ricardo Wurmus
2017-05-12  8:29                 ` Ludovic Courtès
2017-05-12 17:10                   ` myglc2

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.