rolling back only a single package

rolling back only a single package

[cdelia]

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!

Re: rolling back only a single package

[Pierre Neidhardt]

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

Re: rolling back only a single package

[cdelia]

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

[Tonton]

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!
> 

Re: rolling back only a single package

[cdelia]

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.

Re: rolling back only a single package

[Tonton]

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

Re: rolling back only a single package

[Björn Höfling]

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

Re: rolling back only a single package

[Ricardo Wurmus]

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

Re: rolling back only a single package

[cdelia]

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

Re: rolling back only a single package

[Ricardo Wurmus]

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

Re: rolling back only a single package

[cdelia]

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.

Re: rolling back only a single package

[cdelia]

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.

Re: rolling back only a single package

[cdelia]

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.

Re: rolling back only a single package

[swedebugia]

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

Re: rolling back only a single package

[Catriel Omar D'Elía]

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.