* rolling back only a single package @ 2018-12-27 19:52 cdelia 2018-12-28 7:55 ` Pierre Neidhardt ` (3 more replies) 0 siblings, 4 replies; 15+ messages in thread From: cdelia @ 2018-12-27 19:52 UTC (permalink / raw) To: help-guix Hi, I upgraded guix a couple of days ago, installed some things and now I found that xmobar just keeps segfaulting. Switching to specific generation it's really cool, but in this case would "uninstall" all the software that it's between the update-generation and the current one. So, there is any way to just downgrade a single package (resolving it dependencies) with out doing a full switch? I guess this it's connected to https://lists.gnu.org/archive/html/help-guix/2016-08/msg00028.html And I could also switch and then manually re install. But maybe there is a standard or automatic way to do it. Thanks! ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-27 19:52 rolling back only a single package cdelia @ 2018-12-28 7:55 ` Pierre Neidhardt [not found] ` <7bbd5b5a38121bf9a70c1fbe095c39b8@dc.uba.ar> 2018-12-28 11:35 ` Tonton ` (2 subsequent siblings) 3 siblings, 1 reply; 15+ messages in thread From: Pierre Neidhardt @ 2018-12-28 7:55 UTC (permalink / raw) To: cdelia; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 142 bytes --] Hi, I guess you could simply uninstall the offending program: guix package -r xmobar -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <7bbd5b5a38121bf9a70c1fbe095c39b8@dc.uba.ar>]
* Re: rolling back only a single package [not found] ` <7bbd5b5a38121bf9a70c1fbe095c39b8@dc.uba.ar> @ 2018-12-28 22:19 ` cdelia 0 siblings, 0 replies; 15+ messages in thread From: cdelia @ 2018-12-28 22:19 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: help-guix Hi Pierre, sorry for double sending it to you, I forgot CC to the list. > On 2018-12-28 04:55, Pierre Neidhardt wrote: > Hi, > > I guess you could simply uninstall the offending program: > > guix package -r xmobar No I can't because xmobar it's the app launcher of my desktop configuration. Maybe if I switch from xmobar to a launcher that uses: http://hackage.haskell.org/package/xmonad-contrib-0.15/docs/XMonad-Actions-GridSelect.html I already use it to switch app-windows and workspaces when they have a name (other than 1, 2, 3...), with only a couple of haskell code lines. But I have to collect all the executables and I'll rather wait and do it even better: collect all desktops files to not only launch the app, but to show the icon's ... (idk if that's possible with the current API) Anyway, it's another subject entirely. Thanks for answer. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-27 19:52 rolling back only a single package cdelia 2018-12-28 7:55 ` Pierre Neidhardt @ 2018-12-28 11:35 ` Tonton 2018-12-30 22:57 ` cdelia 2018-12-28 13:34 ` Björn Höfling [not found] ` <45406B3B-5E5F-4444-9679-A5DB43D9AE50@pretty.Easy.privacy> 3 siblings, 1 reply; 15+ messages in thread From: Tonton @ 2018-12-28 11:35 UTC (permalink / raw) To: cdelia; +Cc: help-guix Hello, and welcome :) For packages where multiple versions are defined you can choose with packagename@version e.g. guile@1.8.8 for the oldest guile on my system. A simple way to see the versions is with the 'guix package --show=packagename' flag. e.g. 'guix package --show=guile' will give you an entry per guile version available. It seems you are looking for a version of a package where the previous definition was not kept on upgrade. Most likely because guix so far has not kept old versions of leaf packages (i.e. packages with no dependencies); which is why guile and python have several versions but xmobar has none. I think the choice to not keep old definitions is to ease maintenance. But this might be a valid discussion to have as we move towards 1.0. Maybe we should have a policy of keeping one old version when we upgrade, as a kind of fallback. It occurs to me that maybe this is not a problem because of functional/purity aspect of guix, and the package just needs a better definition? idk. As a quick fix for xmobar I see it was updated to 0.28 in commit ccd4fd3f2a614996bff5436cc22e4715a7eb1f31 and only two lines were changed. I would create a file ~/my-guix-pakcages/my-xmobar.scm and put the following in it: ------------------------------------------------------------------------------------------------- (define-module (my-xmobar) ;; The name "my-xmobar" have to be ;; the same as the filename #:use-module (guix packages) #:use-module (guix download) #:use-module (gnu packages) #:use-module (gnu packages wm)) (define-public my-xmobar (package (inherit xmobar) (name "xmobar") (version "0.27") (source (origin (method url-fetch) (uri (string-append "mirror://hackage/package/xmobar/" name "-" version ".tar.gz")) (sha256 (base32 "0agx490q6sbmv3vfq33ys8dsrgwizj3bmha4i1pkxz5wp5q8cx3l")))))) ------------------------------------------------------------------------------------------------- Then add the file to your shells $GUIX_PACKAGE_PATH like 'export GUIX_PACKAGE_PATH=~/my-guix-pakcages/:$GUIX_PACKAGE_PATH' in your .profile or similar. Open a new shell and run: guix package -i xmobar@0.27 Hope that helps. :) Tonton On Thu, 27 Dec 2018 16:52:23 -0300 cdelia@dc.uba.ar wrote: > Hi, > > I upgraded guix a couple of days ago, installed some things and now I > found that xmobar just keeps segfaulting. > > Switching to specific generation it's really cool, but in this case > would "uninstall" all the software that it's between the > update-generation and the current one. > > So, there is any way to just downgrade a single package (resolving it > dependencies) with out doing a full switch? > > I guess this it's connected to > https://lists.gnu.org/archive/html/help-guix/2016-08/msg00028.html > > And I could also switch and then manually re install. But maybe there is > a standard or automatic way to do it. > > Thanks! > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-28 11:35 ` Tonton @ 2018-12-30 22:57 ` cdelia 2018-12-31 15:17 ` Tonton 0 siblings, 1 reply; 15+ messages in thread From: cdelia @ 2018-12-30 22:57 UTC (permalink / raw) To: Tonton; +Cc: help-guix Tonton <tonton@riseup.net> writes: > Hello, and welcome :) Thanks! > > For packages where multiple versions are defined you can choose with > packagename@version e.g. guile@1.8.8 for the oldest guile on my system. A > simple way to see the versions is with the 'guix package --show=packagename' > flag. e.g. 'guix package --show=guile' will give you an entry per guile > version available. > > It seems you are looking for a version of a package where the previous > definition was not kept on upgrade. Most likely because guix so far has not > kept old versions of leaf packages (i.e. packages with no dependencies); > which is why guile and python have several versions but xmobar has none. > ok > I think the choice to not keep old definitions is to ease maintenance. But > this might be a valid discussion to have as we move towards 1.0. Maybe we > should have a policy of keeping one old version when we upgrade, as a kind of > fallback. > Yes, but I check the blog suggested by Björn: https://www.gnu.org/software/guix/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/ and I think that should be enough. Maybe we can add a convenience user interface, to query what guix version/commit a certain package version can be found. > It occurs to me that maybe this is not a problem because of functional/purity > aspect of guix, and the package just needs a better definition? idk. > > As a quick fix for xmobar I see it was updated to 0.28 in commit > ccd4fd3f2a614996bff5436cc22e4715a7eb1f31 and only two lines were > changed. I'm begging to think that it' a problem with GHC version. After all it doesn't make sense to have a segfault in haskell code. Besides, I read a comment on a readme in the github repo that points in that direction. So even if a get this pkg definition to work, maybe xmobar will keep segfaulting now and then. > would create a file ~/my-guix-pakcages/my-xmobar.scm and put the following in > it: > > ------------------------------------------------------------------------------------------------- > (define-module (my-xmobar) ;; The name "my-xmobar" have to be > ;; the same as the filename > #:use-module (guix packages) > #:use-module (guix download) > #:use-module (gnu packages) > #:use-module (gnu packages wm)) > > (define-public my-xmobar > (package > (inherit xmobar) > (name "xmobar") > (version "0.27") > (source (origin > (method url-fetch) > (uri (string-append "mirror://hackage/package/xmobar/" > name "-" version ".tar.gz")) > (sha256 > (base32 > "0agx490q6sbmv3vfq33ys8dsrgwizj3bmha4i1pkxz5wp5q8cx3l")))))) > ------------------------------------------------------------------------------------------------- > > Then add the file to your shells $GUIX_PACKAGE_PATH like > 'export GUIX_PACKAGE_PATH=~/my-guix-pakcages/:$GUIX_PACKAGE_PATH' > in your .profile or similar. Open a new shell and run: > guix package -i xmobar@0.27 > > Hope that helps. :) > It does! It's a good way to getting my hands dirty and learn. So, this it's a little long, sorry... Where do you get that commit hash? Here is what I did to get the hash and see the differences. ------------------------------------------------------------------------------------------------- git clone https://github.com/jaor/xmobar cd xmobar $git rev-list -n1 0.28 661f1a529f0e8416560d0f5f121bce15a1cfc329 $git rev-list -n1 0.26 f897fbe3645d5af96197ee6b9c2dc547f5c036cf $git diff 11fa52601bc486b110252b7c6aa22bae2bafbd86 661f1a529f0e8416560d0f5f121bce15a1cfc329 ------------------------------------------------------------------------------------------------- to know the sha265: ------------------------------------------------------------------------------------------------- $wget http://hackage.haskell.org/package/xmobar-0.26/xmobar-0.26.tar.gz $sha256 xmobar-0.26.tar.gz ------------------------------------------------------------------------------------------------- Then I follow your advice and create a package. ------------------------------------------------------------------------------------------------- (define-module (xmobar-0.26) #:use-module (guix packages) #:use-module (guix download) #:use-module (gnu packages) #:use-module (gnu packages wm)) (define-public xmobar-0.26 (package (inherit xmobar) (name "xmobar") (version "0.27") (source (origin (method url-fetch) (uri (string-append "mirror://hackage/package/xmobar/" name "-" version ".tar.gz")) (sha256 "ff7dd9af151e0336d35fa4741a76fe8a95762649c11877442449b321f106e4a5"))))) ------------------------------------------------------------------------------------------------- Note that I didn't use (base32 "sha256-in-base32") but I try with: ------------------------------------------------------------------------------------------------- $sha256 xmobar-0.26.tar.gz | base32 ------------------------------------------------------------------------------------------------- and then using (base32 ...) and get the same error: $guix package -i xmobar-0.26 guix package: warning: failed to load '(xmobar-0.26)': no code for module (xmobar-0.26) guix package: error: xmobar-0.26: unknown package (after set up the GUIX_PACKAGE_PATH, obviusly) or even: $guix package -i xmobar@0.26 guix package: warning: failed to load '(xmobar-0.26)': no code for module (xmobar-0.26) guix package: error: xmobar: package not found for version 0.2¬ mmm, what's wrong? maybe some dependency change? Or did I put the wrong sha256? The url it's fine, Why it can't found it? This way to do it it's good to learn how to extend packages and maybe beggining packagings other things. But with the problem at hand shouldn't we use the package definition that guix has and is know to work? Anyway for that I'll check the Björn answer. This one has it's own merits XD. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-30 22:57 ` cdelia @ 2018-12-31 15:17 ` Tonton 0 siblings, 0 replies; 15+ messages in thread From: Tonton @ 2018-12-31 15:17 UTC (permalink / raw) To: cdelia; +Cc: help-guix On Sun, 30 Dec 2018 19:57:06 -0300 <cdelia@dc.uba.ar> wrote: > Tonton <tonton@riseup.net> writes: > > Yes, but I check the blog suggested by Björn: > > https://www.gnu.org/software/guix/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/ > Cool, I hadn't seen this post before. So yes, that sounds like a good way forward. :) > > > > As a quick fix for xmobar I see it was updated to 0.28 in commit > > ccd4fd3f2a614996bff5436cc22e4715a7eb1f31 and only two lines were > > changed. > > I'm begging to think that it' a problem with GHC version. After all it > doesn't make sense to have a segfault in haskell code. Besides, I read a > comment on a readme in the github repo that points in that direction. > > So even if a get this pkg definition to work, maybe xmobar will keep > segfaulting now and then. > Oh, yes. If the problem lies in the GHC version this package definition won't solve it. > > would create a file ~/my-guix-pakcages/my-xmobar.scm and put the > > following in it: > > > > ------------------------------------------------------------------------------------------------- > > (define-module (my-xmobar) ;; The name "my-xmobar" have to be > > ;; the same as the filename > > #:use-module (guix packages) > > #:use-module (guix download) > > #:use-module (gnu packages) > > #:use-module (gnu packages wm)) > > > > (define-public my-xmobar > > (package > > (inherit xmobar) > > (name "xmobar") > > (version "0.27") > > (source (origin > > (method url-fetch) > > (uri (string-append "mirror://hackage/package/xmobar/" > > name "-" version ".tar.gz")) > > (sha256 > > (base32 > > "0agx490q6sbmv3vfq33ys8dsrgwizj3bmha4i1pkxz5wp5q8cx3l")))))) > > ------------------------------------------------------------------------------------------------- > > > > Then add the file to your shells $GUIX_PACKAGE_PATH like > > 'export GUIX_PACKAGE_PATH=~/my-guix-pakcages/:$GUIX_PACKAGE_PATH' > > in your .profile or similar. Open a new shell and run: > > guix package -i xmobar@0.27 > > > > Hope that helps. :) > > > > It does! It's a good way to getting my hands dirty and learn. > > So, this it's a little long, sorry... > > Where do you get that commit hash? > The commit hash earlier (ccd4fd3f2a614996bff5436cc22e4715a7eb1f31) is from the guix repository at https://git.savannah.gnu.org/cgit/guix.git/ The hash in the package definition is from guix hash. I get it by running: $ guix download https://hackage.haskell.org/package/xmobar-0.27/xmobar-0.27.tar.gz Starting download of /tmp/guix-file.hS67K3 From https://hackage.haskell.org/package/xmobar-0.27/xmobar-0.27.tar.gz... [...] /gnu/store/l9bz25g4li7g3snasm35cc2c6qf3qmn7-xmobar-0.27.tar.gz 0agx490q6sbmv3vfq33ys8dsrgwizj3bmha4i1pkxz5wp5q8cx3l $ guix hash /gnu/store/l9bz25g4li7g3snasm35cc2c6qf3qmn7-xmobar-0.27.tar.gz 0agx490q6sbmv3vfq33ys8dsrgwizj3bmha4i1pkxz5wp5q8cx3l You might notice that the hash guix download yields is the same as guix hash. I've been recommended running guix hash separately as a best practice, I don't remember the specifics and it costs me nothing. :) > Here is what I did to get the hash and see the differences. > > ------------------------------------------------------------------------------------------------- > git clone https://github.com/jaor/xmobar > > cd xmobar > > $git rev-list -n1 0.28 > 661f1a529f0e8416560d0f5f121bce15a1cfc329 > > $git rev-list -n1 0.26 > f897fbe3645d5af96197ee6b9c2dc547f5c036cf > > $git diff 11fa52601bc486b110252b7c6aa22bae2bafbd86 > 661f1a529f0e8416560d0f5f121bce15a1cfc329 > ------------------------------------------------------------------------------------------------- > > to know the sha265: > > ------------------------------------------------------------------------------------------------- > $wget http://hackage.haskell.org/package/xmobar-0.26/xmobar-0.26.tar.gz > $sha256 xmobar-0.26.tar.gz > ------------------------------------------------------------------------------------------------- > See above, but here I think it's a better idea to use guix download and guix hash. Also because guix download will get the tarball and put it in your store, so you won't have to download it again while testing builds. > Then I follow your advice and create a package. > > ------------------------------------------------------------------------------------------------- > (define-module (xmobar-0.26) > #:use-module (guix packages) > #:use-module (guix download) > #:use-module (gnu packages) > #:use-module (gnu packages wm)) > > (define-public xmobar-0.26 > (package > (inherit xmobar) > (name "xmobar") > (version "0.27") > (source (origin > (method url-fetch) > (uri (string-append "mirror://hackage/package/xmobar/" > name "-" version ".tar.gz")) > (sha256 > "ff7dd9af151e0336d35fa4741a76fe8a95762649c11877442449b321f106e4a5"))))) > ------------------------------------------------------------------------------------------------- > > > Note that I didn't use (base32 "sha256-in-base32") > > but I try with: > > ------------------------------------------------------------------------------------------------- > $sha256 xmobar-0.26.tar.gz | base32 > ------------------------------------------------------------------------------------------------- > > and then using (base32 ...) and get the same error: > > $guix package -i xmobar-0.26 > guix package: warning: failed to load '(xmobar-0.26)': > no code for module (xmobar-0.26) > guix package: error: xmobar-0.26: unknown package > > (after set up the GUIX_PACKAGE_PATH, obviusly) > > or even: > > $guix package -i xmobar@0.26 > guix package: warning: failed to load '(xmobar-0.26)': > no code for module (xmobar-0.26) > guix package: error: xmobar: package not found for version 0.2¬ > > > mmm, what's wrong? maybe some dependency change? Or did I put the wrong > sha256? The url it's fine, Why it can't found it? > Awesome, great work :) I'd double check GUIX_PACKAGE_PATH and that the filename is xmobar-0.26.scm and it exists in GUIX_PACKAGE_PATH. $ echo $GUIX_PACKAGE_PATH $ find $(echo "$GUIX_PACKAGE_PATH" | sed 's/:/ /g') -name xmobar-0.26.scm Then xmobar-0.26 is the variable name for your package definition used for guile hacking. While xmobar@0.26 is sort of the package name used for tools like guix package and guix build. Another great tool when writing package definitions is guix lint. > > This way to do it it's good to learn how to extend packages and maybe > beggining packagings other things. But with the problem at hand > shouldn't we use the package definition that guix has and is know to work? > > Anyway for that I'll check the Björn answer. This one has it's own merits > XD. > Look forward to seeing how you end up solving this. :) Tonton ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-27 19:52 rolling back only a single package cdelia 2018-12-28 7:55 ` Pierre Neidhardt 2018-12-28 11:35 ` Tonton @ 2018-12-28 13:34 ` Björn Höfling 2018-12-28 14:49 ` Ricardo Wurmus ` (2 more replies) [not found] ` <45406B3B-5E5F-4444-9679-A5DB43D9AE50@pretty.Easy.privacy> 3 siblings, 3 replies; 15+ messages in thread From: Björn Höfling @ 2018-12-28 13:34 UTC (permalink / raw) To: cdelia; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 3398 bytes --] Hi cdelia, On Thu, 27 Dec 2018 16:52:23 -0300 cdelia@dc.uba.ar wrote: > Hi, > > I upgraded guix a couple of days ago, installed some things and now I > found that xmobar just keeps segfaulting. > > Switching to specific generation it's really cool, but in this case > would "uninstall" all the software that it's between the > update-generation and the current one. > > So, there is any way to just downgrade a single package (resolving it > dependencies) with out doing a full switch? > > I guess this it's connected to > https://lists.gnu.org/archive/html/help-guix/2016-08/msg00028.html > > And I could also switch and then manually re install. But maybe there > is a standard or automatic way to do it. There is a nice blog post by Ludivic that describes some aspects of it: https://www.gnu.org/software/guix/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/ It looks like the inferior thing he mentioned is already ready, but I haven't yet followed that. Ludo, can you say something about that? Doing it the way described in the post I can downgrade (in my case I use youtube-dl as the package I want to downgrade, as this is in my profile): The trick is to work with the generations of "guix pull". $ guix package --list-generations Generation 122 Dec 15 2018 16:36:58 + youtube-dl 2018.11.07 out /gnu/store/20wr2z2qnm36mwcdmmzpsvr9f4899 - youtube-dl 2018.09.18 out /gnu/store/h7xdi93gag6r9agp5ivppignh4q0k $ guix pull --list-generations Generation 28 Nov 07 2018 20:38:34 guix 91b71cf repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 91b71cfbba03ea484cc6028b3384bf4609cbcf14 [..] Generation 29 Nov 13 2018 18:38:56 guix d540137 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: d5401375099f6e4562b849121265bb1c3e85874f 65 packages upgraded: certbot@0.28.0, crossguid@0.0-2.fef89a4, [..] wxmaxima@18.10.1, youtube-dl@2018.11.07 You see here, I did update my "guix-pull" generation on 13 November that introduced the new youtube-dl version but did update my "guix package" profile only on 15 December. Now I need to use the guix from from generation 28, if I want do downgrade my youtube-dl: $ /var/guix/profiles/per-user/bjoern/current-guix-28-link/bin/guix --version guix (GNU Guix) 91b71cfbba03ea484cc6028b3384bf4609cbcf14 OK, this is really the right version, compared to the above generations of "guix pull". Then let's downgrade: $ /var/guix/profiles/per-user/bjoern/current-guix-28-link/bin/guix package -i youtube-dl The following package will be downgraded: youtube-dl 2018.11.07 -> 2018.11.03 /gnu/store/vw375z5hm4vha0pvfxmadh6qcglacq9g-youtube-dl-2018.11.03 Check it out: $ guix package --list-generations Generation 125 Dec 28 2018 14:02:08 (current) + youtube-dl 2018.11.03 out /gnu/store/vw375z5hm4vha0pvfxmadh6qcglac - youtube-dl 2018.11.07 out /gnu/store/20wr2z2qnm36mwcdmmzpsvr9f4899 ~$ youtube-dl --version 2018.11.03 OK, I'm rolling back, as I don't want to downgrade: $ guix package --roll-back switched from generation 125 to 124 $ youtube-dl --version 2018.11.07 Is that what you are looking for? Björn PS: Can you help fixing the problem with xmobar? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-28 13:34 ` Björn Höfling @ 2018-12-28 14:49 ` Ricardo Wurmus 2018-12-31 7:11 ` cdelia 2018-12-30 23:37 ` cdelia 2018-12-31 0:59 ` cdelia 2 siblings, 1 reply; 15+ messages in thread From: Ricardo Wurmus @ 2018-12-28 14:49 UTC (permalink / raw) To: Björn Höfling; +Cc: cdelia, help-guix Hi cdelia, Björn wrote: > There is a nice blog post by Ludivic that describes some aspects of it: > > https://www.gnu.org/software/guix/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/ > > It looks like the inferior thing he mentioned is already ready, but I > haven't yet followed that. Inferiors work, but you’d use them in manifests. The idea is to install the package with an old version of Guix, but to do it in code instead of manually. Here’s an example: --8<---------------cut here---------------start------------->8--- (use-modules (guix inferior) (guix channels) (srfi srfi-1)) ;for 'first' (define channels ;; This is the old revision from which we want to ;; extract guile-json. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "65956ad3526ba09e1f7a40722c96c6ef7c0936fe")))) (define inferior ;; An inferior representing the above revision. (inferior-for-channels channels)) ;; Now create a manifest with the current "guile" package ;; and the old "guile-json" package. (packages->manifest (list (first (lookup-inferior-packages inferior "guile-json")) (specification->package "guile"))) --8<---------------cut here---------------end--------------->8--- You can instantiate the manifest the usual way: guix package -m /path/to/manifest.scm -- Ricardo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-28 14:49 ` Ricardo Wurmus @ 2018-12-31 7:11 ` cdelia 2018-12-31 8:23 ` Ricardo Wurmus 0 siblings, 1 reply; 15+ messages in thread From: cdelia @ 2018-12-31 7:11 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: help-guix Hi Ricardo, thanks for answering, so basically this is equivalent to find the generation of commit 65956a... and invoking guix-generation-x to install guile-json. Yes, I see why this it's better than using "guix package -i *" and it relates well to my other question about profile -> packages definitions generation. Just write manifests, instantiate them and when it's time to migrate the pacakges definitions will already there. What happens if you then do "guix package -i guile-json" or if somewhere in the future "guix package -U" after a pull? It will honor the manifest or just install the guile-json on the package definition? I don't know if I can make my mind on what sort of behaviur should be best but maybe I'm more towards the idea that a manifest should take precedence, maybe with an override flag. Anyway I can try and check later what guix does. Thanks! and have a happy new year eve. Ricardo Wurmus <rekado@elephly.net> writes: > Inferiors work, but you’d use them in manifests. The idea is to install > the package with an old version of Guix, but to do it in code instead of > manually. Here’s an example: > > (use-modules (guix inferior) (guix channels) > (srfi srfi-1)) ;for 'first' > > (define channels > ;; This is the old revision from which we want to > ;; extract guile-json. > (list (channel > (name 'guix) > (url "https://git.savannah.gnu.org/git/guix.git") > (commit > "65956ad3526ba09e1f7a40722c96c6ef7c0936fe")))) > > (define inferior > ;; An inferior representing the above revision. > (inferior-for-channels channels)) > > ;; Now create a manifest with the current "guile" package > ;; and the old "guile-json" package. > (packages->manifest > (list (first (lookup-inferior-packages inferior "guile-json")) > (specification->package "guile"))) > > You can instantiate the manifest the usual way: > > guix package -m /path/to/manifest.scm > > -- > Ricardo -- Catriel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-31 7:11 ` cdelia @ 2018-12-31 8:23 ` Ricardo Wurmus 0 siblings, 0 replies; 15+ messages in thread From: Ricardo Wurmus @ 2018-12-31 8:23 UTC (permalink / raw) To: cdelia; +Cc: help-guix Hi cdelia, > What happens if you then do "guix package -i guile-json" or if somewhere > in the future "guix package -U" after a pull? When you do “guix package -i” it will use the current version of Guix to create a new profile generation containing all of the previously installed packages as well as “guile-json”. > It will honor the manifest or just install the guile-json on the package > definition? Neither of these commands know about your manifest. Your manifest could be located anywhere. Only “-m manifest.scm” instantiates the manifest in the provided file. -- Ricardo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-28 13:34 ` Björn Höfling 2018-12-28 14:49 ` Ricardo Wurmus @ 2018-12-30 23:37 ` cdelia 2018-12-31 0:59 ` cdelia 2 siblings, 0 replies; 15+ messages in thread From: cdelia @ 2018-12-30 23:37 UTC (permalink / raw) To: Björn Höfling; +Cc: help-guix Björn Höfling <bjoern.hoefling@bjoernhoefling.de> writes: > Hi cdelia, > Hi! > On Thu, 27 Dec 2018 16:52:23 -0300 > cdelia@dc.uba.ar wrote: > >> Hi, >> >> I upgraded guix a couple of days ago, installed some things and now I >> found that xmobar just keeps segfaulting. >> >> Switching to specific generation it's really cool, but in this case >> would "uninstall" all the software that it's between the >> update-generation and the current one. >> >> So, there is any way to just downgrade a single package (resolving it >> dependencies) with out doing a full switch? >> >> I guess this it's connected to >> https://lists.gnu.org/archive/html/help-guix/2016-08/msg00028.html >> >> And I could also switch and then manually re install. But maybe there >> is a standard or automatic way to do it. > > > There is a nice blog post by Ludivic that describes some aspects of it: > > https://www.gnu.org/software/guix/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/ > Just read it. Really nice! > It looks like the inferior thing he mentioned is already ready, but I > haven't yet followed that. > > Ludo, can you say something about that? > > Doing it the way described in the post I can downgrade (in my case I use > youtube-dl as the package I want to downgrade, as this is in my > profile): > > The trick is to work with the generations of "guix pull". > > $ guix package --list-generations > Generation 122 Dec 15 2018 16:36:58 > + youtube-dl 2018.11.07 out /gnu/store/20wr2z2qnm36mwcdmmzpsvr9f4899 > - youtube-dl 2018.09.18 out /gnu/store/h7xdi93gag6r9agp5ivppignh4q0k > > $ guix pull --list-generations > Generation 28 Nov 07 2018 20:38:34 > guix 91b71cf > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 91b71cfbba03ea484cc6028b3384bf4609cbcf14 > [..] > Generation 29 Nov 13 2018 18:38:56 > guix d540137 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: d5401375099f6e4562b849121265bb1c3e85874f > 65 packages upgraded: certbot@0.28.0, crossguid@0.0-2.fef89a4, > [..] > wxmaxima@18.10.1, youtube-dl@2018.11.07 > > You see here, I did update my "guix-pull" generation on 13 November > that introduced the new youtube-dl version but did update my "guix > package" profile only on 15 December. > Ok I did: $guix pull -l | grep -e Generation -e xmobar Generation 1 nov 10 2018 18:52:17 Generation 2 nov 30 2018 21:21:28 Generation 3 dic 08 2018 03:04:20 Generation 4 dic 17 2018 13:15:04 Generation 5 dic 21 2018 11:18:45 Generation 6 dic 29 2018 18:45:24 from this output it seems that xmobar definition it's from before nov 10 and never got updated... strange. $guix package -l | grep -e Generation -e xmobar Generation 18 nov 30 2018 12:10:17 + xmobar 0.26 out /gnu/store/d0xc7k7i73dqdzw1cjwg6cypmm3fp8d3-xmobar-0.26 Generation 19 nov 30 2018 12:19:47 Generation 20 nov 30 2018 14:24:36 ... Generation 27 dic 08 2018 18:42:03 + xmobar 0.28 out /gnu/store/crhjq02nz07wrycvyxr21z00n0g7wxwa-xmobar-0.28 - xmobar 0.26 out /gnu/store/d0xc7k7i73dqdzw1cjwg6cypmm3fp8d3-xmobar-0.26 Generation 28 dic 09 2018 21:44:29 So from this I get that on Dic 08 18hs I upgraded xmobar. Which was installed since nov 18. (really cool to have this history) It must been guix gen-2 that upgrade it. I don't get why xmobar doesn't show as an upgraded package on the first output. Anyway, it seems that any guix generation before dicember 08 should work. Maybe to be shure I'll check the one that worked in the first place: guix generation 2. This was easy, but maybe an user interface to get a commit/generation for certain package version could be usefull here! > Now I need to use the guix from from generation 28, if I want do > downgrade my youtube-dl: > > > $ /var/guix/profiles/per-user/bjoern/current-guix-28-link/bin/guix > --version > guix (GNU Guix) 91b71cfbba03ea484cc6028b3384bf4609cbcf14 > > OK, this is really the right version, compared to the above generations > of "guix pull". > > Then let's downgrade: > > $ /var/guix/profiles/per-user/bjoern/current-guix-28-link/bin/guix > package -i youtube-dl > The following package will be downgraded: > youtube-dl 2018.11.07 -> 2018.11.03 /gnu/store/vw375z5hm4vha0pvfxmadh6qcglacq9g-youtube-dl-2018.11.03 > > Check it out: > $ guix package --list-generations > Generation 125 Dec 28 2018 14:02:08 (current) > + youtube-dl 2018.11.03 out /gnu/store/vw375z5hm4vha0pvfxmadh6qcglac > - youtube-dl 2018.11.07 out /gnu/store/20wr2z2qnm36mwcdmmzpsvr9f4899 > > ~$ youtube-dl --version > 2018.11.03 > > OK, I'm rolling back, as I don't want to downgrade: > > $ guix package --roll-back > switched from generation 125 to 124 > > $ youtube-dl --version > 2018.11.07 > > Is that what you are looking for? > This was just great! Really cool to be able to do this. If I understand this right by coupling the packages definitions with guix as a software we gain a more flexible rapid evolving api at the expense of some a retrocompatibility lose to old packages definitions, that we re gain anyway by just using and old guix version. Cool! And If I'm still understanding this right, by using a old guix version and not a substitute package, we have all the dependency ecosystem. So for instance if this was not a problem of xmobar per se, but of one of it dependencies this should work too. > Björn > > PS: Can you help fixing the problem with xmobar? Well I'm the eternal newbie on haskell. But I think this have to do with some inconpatibility with GHC version. Just see this: https://github.com/jaor/xmobar/commit/a6b2dfc9c9b76fd6a9ec22d71d03b27d9b7689bb from the readme: Xmobar versions >= 0.27 require GHC version >= 8.0.2. Due to an intermittent bug in GHC, we recommend using either GHC 8.0.2, 8.2.2 or 8.6. Catriel. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-28 13:34 ` Björn Höfling 2018-12-28 14:49 ` Ricardo Wurmus 2018-12-30 23:37 ` cdelia @ 2018-12-31 0:59 ` cdelia 2 siblings, 0 replies; 15+ messages in thread From: cdelia @ 2018-12-31 0:59 UTC (permalink / raw) To: Björn Höfling; +Cc: help-guix Hi again, This is odd, it doesn't downgrade: $/var/guix/profiles/per-user/catriel/current-guix-1-link/bin/guix package -i xmobar The following package will be upgraded: xmobar 0.28 -> 0.28 /gnu/store/b7kyq7a7p622gf1cwyf4l29hz8840rj2-xmobar-0.28 $guix package -l ... Generation 31 dic 30 2018 20:57:55 (current) + xmobar 0.28 out /gnu/store/b7kyq7a7p622gf1cwyf4l29hz8840rj2-xmobar-0.28 - xmobar 0.28 out /gnu/store/crhjq02nz07wrycvyxr21z00n0g7wxwa-xmobar-0.28 The commit hash it's fine: $guix pull -l Generation 1 nov 10 2018 18:52:17 guix e8b9aaf repository URL: https://git.savannah.gnu.org/git/guix.git branch: origin/master commit: e8b9aaf0b167812dee6be26772837ef2a271a843 $/var/guix/profiles/per-user/catriel/current-guix-1-link/bin/guix --version guix (GNU Guix) e8b9aaf0b167812dee6be26772837ef2a271a843 Installing xmobar it even builds ghc 8.4.3 derivation, when in guix generation 1 it was 8.0.2 at most. $guix package -l | grep -e Generation -e ghc Generation 21 nov 30 2018 16:09:52 + ghc 8.0.2 out /gnu/store/ljcgfckycml8a2vj47w6ywwn4vdw20zv-ghc-8.0.2 Generation 22 nov 30 2018 16:31:54 ... Generation 27 dic 08 2018 18:42:03 + ghc 8.4.3 out /gnu/store/564215v4ma3jqxai20hf1ymcrn60nm44-ghc-8.4.3 + ghc-xmonad-contrib 0.14 out /gnu/store/ckklwgqi1hxgcrbpsd9myslwz5p2mgxw-ghc-xmonad-contrib-0.14 - ghc-xmonad-contrib 0.13 out /gnu/store/fdkdysalmg8fb5jcyn0wz2jh4syaf6mv-ghc-xmonad-contrib-0.13 - ghc 8.0.2 out /gnu/store/ljcgfckycml8a2vj47w6ywwn4vdw20zv-ghc-8.0.2 Generation 28 dic 09 2018 21:44:29 ... If I do $/var/guix/profiles/per-user/catriel/current-guix-1-link/bin/guix edit xmobar or $/var/guix/profiles/per-user/catriel/current-guix-1-link/bin/guix edit ghc I see the the currents versions (0.28 and 8.4.3) defined in the packages. So I'm not shure what's goin on here. I installed xmobar the 30 of november. Generation 18 nov 30 2018 12:10:17 + xmobar 0.26 out /gnu/store/d0xc7k7i73dqdzw1cjwg6cypmm3fp8d3-xmobar-0.26 By that time I had got generation 1 of guix: $guix pull -l | head -n 2 Generation 1 nov 10 2018 18:52:17 Generation 2 nov 30 2018 21:21:28 this's weird. I don't think I had corrupted my guix installation, never touched the store and never did anything fancy... maybe I'm reading something the wrong way? -- Catriel. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <45406B3B-5E5F-4444-9679-A5DB43D9AE50@pretty.Easy.privacy>]
* Re: rolling back only a single package [not found] ` <45406B3B-5E5F-4444-9679-A5DB43D9AE50@pretty.Easy.privacy> @ 2018-12-28 22:15 ` cdelia 2018-12-29 18:35 ` swedebugia 0 siblings, 1 reply; 15+ messages in thread From: cdelia @ 2018-12-28 22:15 UTC (permalink / raw) To: swedebugia; +Cc: help-guix Hi On 2018-12-28 08:32, swedebugia wrote: > "cdelia@dc.uba.ar" <cdelia@dc.uba.ar> skrev: (27 december 2018 > 20:52:23 CET) > >> Hi, >> >> I upgraded guix a couple of days ago, installed some things and now >> I >> found that xmobar just keeps segfaulting. >> >> Switching to specific generation it's really cool, but in this case >> would "uninstall" all the software that it's between the >> update-generation and the current one. >> >> So, there is any way to just downgrade a single package (resolving >> it >> dependencies) with out doing a full switch? >> >> I guess this it's connected to >> https://lists.gnu.org/archive/html/help-guix/2016-08/msg00028.html >> >> And I could also switch and then manually re install. But maybe >> there is >> a standard or automatic way to do it. >> >> Thanks! > > Hi. > I highly recommend you to use the declarative way of installing > packages instead. See the manual. > I'm intending to, but before that I rather install when need it, when some pseudo complete usable system arise I'll write a declaration. Declarative it's great, but you have to get in your head all the things that you'll need, before even beginning ... > You can use the former xmobar directly from the store if you have it > or you could create an own package/channel that specifies the version > you want. > Well... I never GC nor delete generations. So it should be possible. But I believe that's a temporal work around that should not be used. If I don't delete the generation that holds the earlier working version, I could do that, but then I'll need to use the full path in the store or a symblink manually created. I think that kind of stuff it's a tiny, but accumulative step towards chaos. And I'm using git to scape from it XD > The best thing though is to report a bug and help by providing > information e.g. by stracing it. Guide evolves quickly... It's xmonad, a haskell app. I'm not to proficient in haskell yet to help with that. If I've time I'll report the bug, at least. > -- > Sent from my p≡p for Android. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-28 22:15 ` cdelia @ 2018-12-29 18:35 ` swedebugia 2018-12-30 22:40 ` Catriel Omar D'Elía 0 siblings, 1 reply; 15+ messages in thread From: swedebugia @ 2018-12-29 18:35 UTC (permalink / raw) To: cdelia@dc.uba.ar; +Cc: help-guix@gnu.org On 2018-12-28 23:15, cdelia@dc.uba.ar wrote: > Hi > > On 2018-12-28 08:32, swedebugia wrote: >> "cdelia@dc.uba.ar" <cdelia@dc.uba.ar> skrev: (27 december 2018 >> 20:52:23 CET) >> >>> Hi, >>> >>> I upgraded guix a couple of days ago, installed some things and now >>> I >>> found that xmobar just keeps segfaulting. >>> >>> Switching to specific generation it's really cool, but in this case >>> would "uninstall" all the software that it's between the >>> update-generation and the current one. >>> >>> So, there is any way to just downgrade a single package (resolving >>> it >>> dependencies) with out doing a full switch? >>> >>> I guess this it's connected to >>> https://lists.gnu.org/archive/html/help-guix/2016-08/msg00028.html >>> >>> And I could also switch and then manually re install. But maybe >>> there is >>> a standard or automatic way to do it. >>> >>> Thanks! >> >> Hi. >> I highly recommend you to use the declarative way of installing >> packages instead. See the manual. >> > > I'm intending to, but before that I rather install when need it, when > some pseudo complete usable system arise I'll write a declaration. > > Declarative it's great, but you have to get in your head all the things > that you'll need, before even beginning ... Really? I just add to the manifest every time I stumble over a missing part. I test out stuff with the imperative install and add it to the manifest once I'm sure I need it. You can see my manifest here: https://gitlab.com/swedebugia/guix-config/blob/master/sdb.scm > >> You can use the former xmobar directly from the store if you have it >> or you could create an own package/channel that specifies the version >> you want. >> > > Well... I never GC nor delete generations. So it should be possible. > But I believe that's a temporal work around that should not be used. > > If I don't delete the generation that holds the earlier working version, > I could do that, > but then I'll need to use the full path in the store or a symblink > manually created. > > I think that kind of stuff it's a tiny, but accumulative step towards > chaos. And I'm using git to scape from it XD > >> The best thing though is to report a bug and help by providing >> information e.g. by stracing it. Guide evolves quickly... > > It's xmonad, a haskell app. I'm not to proficient in haskell yet to help > with that. > > If I've time I'll report the bug, at least. Sounds good to me. :) Noone have reported anything about xmobar yet, it seems: https://debbugs.gnu.org/cgi/pkgreport.cgi?include=subject%3Axmobar;package=guix so you might be the first to find the bug. > >> -- >> Sent from my p≡p for Android. -- Cheers Swedebugia ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: rolling back only a single package 2018-12-29 18:35 ` swedebugia @ 2018-12-30 22:40 ` Catriel Omar D'Elía 0 siblings, 0 replies; 15+ messages in thread From: Catriel Omar D'Elía @ 2018-12-30 22:40 UTC (permalink / raw) To: swedebugia; +Cc: help-guix@gnu.org swedebugia <swedebugia@riseup.net> writes: > On 2018-12-28 23:15, cdelia@dc.uba.ar wrote: >> Hi >> >> On 2018-12-28 08:32, swedebugia wrote: >>> "cdelia@dc.uba.ar" <cdelia@dc.uba.ar> skrev: (27 december 2018 >>> 20:52:23 CET) >>> >>>> Hi, >>>> >>>> I upgraded guix a couple of days ago, installed some things and now >>>> I >>>> found that xmobar just keeps segfaulting. >>>> >>>> Switching to specific generation it's really cool, but in this case >>>> would "uninstall" all the software that it's between the >>>> update-generation and the current one. >>>> >>>> So, there is any way to just downgrade a single package (resolving >>>> it >>>> dependencies) with out doing a full switch? >>>> >>>> I guess this it's connected to >>>> https://lists.gnu.org/archive/html/help-guix/2016-08/msg00028.html >>>> >>>> And I could also switch and then manually re install. But maybe >>>> there is >>>> a standard or automatic way to do it. >>>> >>>> Thanks! >>> >>> Hi. >>> I highly recommend you to use the declarative way of installing >>> packages instead. See the manual. >>> >> >> I'm intending to, but before that I rather install when need it, when >> some pseudo complete usable system arise I'll write a declaration. >> >> Declarative it's great, but you have to get in your head all the things >> that you'll need, before even beginning ... > > Really? > > I just add to the manifest every time I stumble over a missing part. > > I test out stuff with the imperative install and add it to the > manifest once I'm sure I need it. > That seems to be a good approach. Anyway I was talking about installing things that can be found. > You can see my manifest here: > https://gitlab.com/swedebugia/guix-config/blob/master/sdb.scm > >> >>> You can use the former xmobar directly from the store if you have it >>> or you could create an own package/channel that specifies the version >>> you want. >>> >> >> Well... I never GC nor delete generations. So it should be possible. >> But I believe that's a temporal work around that should not be used. >> >> If I don't delete the generation that holds the earlier working version, >> I could do that, >> but then I'll need to use the full path in the store or a symblink >> manually created. >> >> I think that kind of stuff it's a tiny, but accumulative step towards >> chaos. And I'm using git to scape from it XD >> >>> The best thing though is to report a bug and help by providing >>> information e.g. by stracing it. Guide evolves quickly... >> >> It's xmonad, a haskell app. I'm not to proficient in haskell yet to help >> with that. >> >> If I've time I'll report the bug, at least. > > Sounds good to me. :) > > Noone have reported anything about xmobar yet, it seems: > https://debbugs.gnu.org/cgi/pkgreport.cgi?include=subject%3Axmobar;package=guix > > so you might be the first to find the bug. > I'm begging to think that it's a problem with GHC. There is a comment on xmobar repo by version 28 that says that should be using 8.x something GHC. Besides, doesn't make sense to segfault with haskell code. I'll check other answers first and then see if I can help. >> >>> -- >>> Sent from my p≡p for Android. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-12-31 15:18 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-12-27 19:52 rolling back only a single package cdelia 2018-12-28 7:55 ` Pierre Neidhardt [not found] ` <7bbd5b5a38121bf9a70c1fbe095c39b8@dc.uba.ar> 2018-12-28 22:19 ` cdelia 2018-12-28 11:35 ` Tonton 2018-12-30 22:57 ` cdelia 2018-12-31 15:17 ` Tonton 2018-12-28 13:34 ` Björn Höfling 2018-12-28 14:49 ` Ricardo Wurmus 2018-12-31 7:11 ` cdelia 2018-12-31 8:23 ` Ricardo Wurmus 2018-12-30 23:37 ` cdelia 2018-12-31 0:59 ` cdelia [not found] ` <45406B3B-5E5F-4444-9679-A5DB43D9AE50@pretty.Easy.privacy> 2018-12-28 22:15 ` cdelia 2018-12-29 18:35 ` swedebugia 2018-12-30 22:40 ` Catriel Omar D'Elía
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).