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 > /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
Re: Upgrade 0.15 to .16 it doesn't work
Jone writes: > Сannot upgrade system, i. g. guix. Its a first problem with upgrade > from 0.13. Upgrading from 0.13 can be tricky. Try first to upgrade to 0.15 and from there use “guix pull” to get the latest Guix. -- Ricardo
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
swedebugia writes: > On 2018-12-28 23:15, cde...@dc.uba.ar wrote: >> 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 ... > > 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.
FAQ draft (Was: Re: Upgrade 0.15 to .16 it doesn't work)
On 2018-12-30 19:19, Jone wrote: snip And additionally I would like to see two things: 1. FAQ Which questions do you propose to include? Where would you suggest to place this faq? In the manual? website? I just wrote the following suggestions to a GuixSD FAQ: General: * Is GuixSD a 'do-it-yourself' GNU/Linux distribution like e.g. Arch Linux and Gentoo? * Yes and no. Both the distributions mentioned mess a lot with states and configuration files in different formats and are based on a completely different way of configuring the OS. With GuixSD the goal is to configure /everything/ in the declaration of the OS and never having to edit a single configuration file in some obscure location. The roll-back functionality of Guix makes it easy to undo almost any changes to the state in Guix imposed by your fiddling with the configuration. GuixSD also makes it possible to /easily/ replicate a friends OS configuration making it possible to collaborate and share your ideas on how to configure the whole OS much more easily than traditional distributions. There are already up to a hundred shared operating system declarations available online for your to copy or get ideas from. * Is it a rolling release distribution? * Yes. But anyone could turn it into any stable or whatever release model via 'guix channel'. * How does channels affect the distribution? * They let you compose and maintain your own release of Guix. * Any stable ones available yet? * No, not known to us. * Can I easily share my installed system configuration and package-manifest with a friend? * Yes. The declaration, usually a file called config.scm, used to instantiate the system makes this easy. It contains no secret information. The same goes for package-manifests. * I am a complete GNU OS beginner. Should I use GuixSD? * If you are a beginner and want to use GuixSD, you must be willing to invest time into learning a new system, and accept that GuixSD is designed as a 'do-it-yourself' or 'copy-from-your-friend' distribution; it is the user who assembles the system via a configuration written in Scheme. Before asking for help, do your own independent research by reading the manual, searching online & searching the mailing lists. There is a reason these resources were made available to you in the first place. Many thousands of volunteered hours have been spent compiling this excellent information. * Is Guix going to be so good that people will have a hard time avoiding it? When will the beta end? * We don't know yet. You can take a look at our ROADMAP http://git.savannah.gnu.org/cgit/guix.git/tree/ROADMAP and look up the latest features in the latest release statement. Package-related: * Why is compilation so time-consuming compared to substitutes? * Compiling is necessary to convert almost any modern program from a high-level language (like Guile Scheme, Python, C++) to low-level machine code. Whether you compile yourself or let others do it for you, your ordinary GNOME enabled desktop takes a total of about 3-5 days of compile time on a consumer level 2-core Intel 64-bit PC. *(is this accurate Mark?) * How will I know if substitutes are available from the build farms before running 'guix pull'? * Generally you don't. This is a missing feature. You are welcome to help improving Guix or Cuirass to make this possible. * Why do Guix mess around with environment variables when other distributions don't? * Why does environment variables need to be manually set sometimes in GuixSD - could that not be automated? * If this is needed you have probably found a bug. Ie. right now many package definitions lack search-path definitions (e.g. guile-readline, guile-colorized, and many others) causing them to not be set automatically. * Is package X available? * Maybe! Take a look at the package list of the website or search our git-repo for the name. If you are up for it, maybe you can package it yourself by importing it *LINK, following the package guide *LINK or by reading the package descriptions of similar programs already in Guix. Any thoughts? See also https://wiki.archlinux.org/index.php/Frequently_asked_questions -- Cheers Swedebugia
Upgrade 0.15 to .16 it doesn't work
Сannot upgrade system, i. g. guix. Its a first problem with upgrade from 0.13. I will try again to provide a output. And I didn't read the manual carefully - a little time, sorry. I'll do this more closely later. And additionally I would like to see two things: 1. FAQ 2. external repo :) (About 2: Nix export - it doesn't work for me either. But we'll see: XFCE, Whisker Menu - no sign of him.)
