bug#25852: Users not updating their installations of Guix
On 05/12/2017 at 10:29 Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> Ludovic Courtès writes: >> >>> myglc2 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
bug#25852: Users not updating their installations of Guix
Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> myglc2 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
Ludovic Courtès writes: > myglc2 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
myglc2 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
On 05/10/2017 at 15:12 Ludovic Courtès writes: > Hi there, > > Mark H Weaver skribis: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Mark H Weaver 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
Hi there, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver 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’. 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 +;;; Copyright © 2013, 2014, 2015, 2017 Ludovic Courtès ;;; Copyright © 2014 Deck Pickard ;;; Copyright © 2015, 2016 Alex Kost ;;; @@ -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\"."
bug#25852: Users not updating their installations of Guix
l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver 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
Tomáš Čech skribis: > On Thu, Mar 09, 2017 at 11:58:12AM +0100, Ludovic Courtès wrote: >>Tomáš Čech 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
On Thu, Mar 09, 2017 at 11:58:12AM +0100, Ludovic Courtès wrote: Tomáš Čech 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 signature.asc Description: Digital signature
bug#25852: Users not updating their installations of Guix
Tomáš Čech 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
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 אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#25852: Users not updating their installations of Guix
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. signature.asc Description: PGP signature
bug#25852: Users not updating their installations of Guix
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 signature.asc Description: Digital signature
bug#25852: Users not updating their installations of Guix
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 signature.asc Description: PGP signature
bug#25852: Users not updating their installations of Guix
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 signature.asc Description: Digital signature
bug#25852: Users not updating their installations of Guix
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. signature.asc Description: PGP signature
bug#25852: Users not updating their installations of Guix
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 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 signature.asc Description: Digital signature
bug#25852: Users not updating their installations of Guix
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 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. signature.asc Description: PGP signature
bug#25852: Users not updating their installations of Guix
Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Leo Famulari 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
l...@gnu.org (Ludovic Courtès) writes: > Leo Famulari 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
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
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 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 signature.asc Description: Digital signature
bug#25852: Users not updating their installations of Guix
On Mon, Mar 06, 2017 at 10:12:21PM +0100, Ludovic Courtès wrote: > Leo Famulari 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
Leo Famulari 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
Tomáš Čech 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
On Sun, Mar 05, 2017 at 09:25:11AM +, 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 signature.asc Description: Digital signature
bug#25852: Users not updating their installations of Guix
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
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 signature.asc Description: Digital signature
bug#25852: Users not updating their installations of Guix
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? signature.asc Description: PGP signature
bug#25852: Users not updating their installations of Guix
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 signature.asc Description: Digital signature
bug#25852: Users not updating their installations of Guix
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/
bug#25852: Users not updating their installations of Guix
We can make package 'daemon' aware if we provide the meta data in channels, see 22...@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
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 signature.asc Description: PGP signature