Re: rolling back only a single package
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 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
Re: rolling back only a single package
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.28out /gnu/store/b7kyq7a7p622gf1cwyf4l29hz8840rj2-xmobar-0.28 - xmobar 0.28out /gnu/store/crhjq02nz07wrycvyxr21z00n0g7wxwa-xmobar-0.28 The commit hash it's fine: $guix pull -l Generation 1nov 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.14out /gnu/store/ckklwgqi1hxgcrbpsd9myslwz5p2mgxw-ghc-xmonad-contrib-0.14 - ghc-xmonad-contrib 0.13out /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.26out /gnu/store/d0xc7k7i73dqdzw1cjwg6cypmm3fp8d3-xmobar-0.26 By that time I had got generation 1 of guix: $guix pull -l | head -n 2 Generation 1nov 10 2018 18:52:17 Generation 2nov 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.
Re: rolling back only a single package
Björn Höfling writes: > Hi cdelia, > Hi! > On Thu, 27 Dec 2018 16:52:23 -0300 > cde...@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 1nov 10 2018 18:52:17 Generation 2nov 30 2018 21:21:28 Generation 3dic 08 2018 03:04:20 Generation 4dic 17 2018 13:15:04 Generation 5dic 21 2018 11:18:45 Generation 6dic 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.26out /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.28out /gnu/store/crhjq02nz07wrycvyxr21z00n0g7wxwa-xmobar-0.28 - xmobar 0.26out /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 > /gn
Re: rolling back only a single package
Tonton 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:
Re: rolling back only a single package
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.
Re: rolling back only a single package
Hi On 2018-12-28 08:32, swedebugia wrote: "cde...@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.
rolling back only a single package
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!
Generating System Definitions
Hi, There is a standard way to generate an exportable installer.scm from a specific generation? I installed guix a couple a weeks ago and I'm looking forward to replace my distro with guixSD. To do so, I'm slowly replacing the software that I use with those found on guix. The ones that aren't there will have to wait for someone (maybe myself) to add them. When I'm only using the base distro to boot, I'll switch, but for that I guess it would be cool to simple "export" the state of my machine to the new installation, with the proper 'merging' taking place. With merging I mean that the exported configuration will be a subset of the final full guixSD distro. It should not be a heavy task to do it by hand, but just in case; maybe somebody has it figure out. Thanks!
Re: How to install an old package version?
Hi! real newbie to guix here! You have to make your own package for this version, that would look like this: (define-public python-2.7.10 (package (inherit python) (version "2.7.10") (source (origin (inherit (package-source python-2.7)) (uri (string-append "https://www.python.org/ftp/python/;; version "/Python-" version ".tar.xz")) (sha256 (base32 "some-letters-and-numbers")) and to put it to a file from GUIX_PACKAGE_PATH. See (info "(guix) Package Modules") for details. This brings me some doubts. How does guix resolves de dependency tree in those cases? Say I need a previous package X version, that depends on an earlier package Y version that the one that is defined on the "main" guix. Do I have to do the sema that Alex suggests so guix can resolve it? I guess that'll be the answer. But in that case I'll maybe find myself in a time consuming recursive package definition. Alternatively, you can use a guix git checkout on a specific commit that still has python-2.7.10, but it's probably not what you want. So, to avoid recursive definition of packages: Could I checkout an earlier guix revision, install the package and then checkout the latest guix version? Would that work or it will bring other kind of dragons? If that's the case, it could be done automatically. Does anybody try to do it, so we can simple specify the version of the package to install in "guix package" cmd?
