Re: Ganeti with Guix tutorial from the Guix blog post

2020-10-10 Thread Marius Bakke
Hello!

I worked with David off-list on this, and it eventually turned out that
the problems were hardware-related.

The cluster consisted of two Librebooted x200 machines.  One that
happened to support KVM, and one that did not.  The Libreboot wiki entry
on the x200 states that there is only one known microcode revision that
works with KVM:

  https://libreboot.org/docs/hardware/x200.html#compatibility_noblobs

Interestingly, the failing machine did have the mentioned 1067a
microcode version, whereas the other (functioning) node had 10676.

The problem with 1067a manifests with QEMU starting, but not loading the
guest OS.  Live migrating a running VM to the 1067a node *did* work,
adding to the confusion.  Just "offline migration" and starting new VMs
did not.

I'm happy to report that the cluster works fine after replacing the
dysfunctional node.  :-)


signature.asc
Description: PGP signature


Re: Exception on `guix import`

2020-10-10 Thread Joshua Branson


Ah bummer.  I think the guix import feature is one of the harder ones to
keep working.  :(  I'm not certain how to fix it.  I just wanted to
express my emotional support.  :)  

-- 
Joshua Branson
Sent from Emacs and Gnus
https://gnucode.me
https://video.hardlimit.com/accounts/joshua_branson/video-channels
"You can have whatever you want, as long as you help enough other people get 
what they want." - Zig Ziglar



Re: How to install previous versions?

2020-10-10 Thread Zelphir Kaltstahl
Hello Zimoun!

Thank you for your reply! I have a few follow up questions.

On 10/9/20 6:37 PM, zimoun wrote:
> Hi,
>
> On Fri, 9 Oct 2020 at 19:19, Zelphir Kaltstahl
>  wrote:
>
>> http://data.guix.gnu.org/repository/1/branch/master/package/python-redis.
> On this web page, you can click on the date: first commit and last
> commit known to have this version.  You can even see the status
> (build, failed, pending, etc.) on this web page (appending
> 'output-history')
>
> http://data.guix.gnu.org/repository/1/branch/master/package/python-redis/output-history

So far so good, I get until this point.


> For example, clicking leads to:
>
> http://data.guix.gnu.org/revision/f5111b4d2b982d58387188bc3018e4dd2e9a9d4f

Here is where I am lost. Where do I need to click?

I see a link named
`/gnu/store/wlj2bq4g9ki9iz6vqlv366c0v5qmszg7-python-redis-3.3.8`, which
seems to be the latest of the python-redis 3.3.8 version, but that one
leads me elsewhere, leads me to
`http://data.guix.gnu.org/gnu/store/wlj2bq4g9ki9iz6vqlv366c0v5qmszg7-python-redis-3.3.8`.

> And this gives you the commit with 'python-redis@3.8', using the command:
>
>   guix time-machine --commit=f5111b \
>  -- environment --ad-hoc python-redis python \
>  -- python

OK, assume I get the commit id.

I just tried this with the following command:


guix time-machine --commit=f5111b -- environment --ad-hoc 'python-redis@3.3.8' 
'python@3.8' -- python3.8


That runs for a quite while and then I get:


Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
guile: warning: failed to install locale
guix environment: error: python: package not found for version 3.8.2


My guess is, that in this commit of Guix there was no Python 3.8.2 yet?
Or perhaps `python-redis` was not build for that Python version?

I do not have a specific use-case at this moment, but I would like to
know how to get those specific versions, the same every single time I
run the command. To compare, when I create a virtual environment using:


python3 -m venv venv
source venv/bin/activate
pip install --requirement requirements.txt


I can write the version of python-redis in my requirements.txt file and
it will install just fine. That means, that is it compatible, so it's
not a compatibility issue of python@3.8.2 and python-redis@3.3.8.
However, those virtual environments are not reproducible, as there are
no hashes stored or anything and everything relies on version numbers
only. If anyone changed the code behind a version number, it would
install different code. It would be cooler to have it in Guix and
reproducible.

>> So how would I need to write my manifest.scm or my one-liner to get back
>> to that older version?
> The best is to write a manifest file, say manifest.scm containing the
> package you need:
>
> --8<---cut here---start->8---
> (specfications->manifest
>   (list
>"python-redis"
>"python"
>"foo"
>"bar"
>"etc"))
> --8<---cut here---end--->8---
But that is, what I already have, isn't it? There is no part in this,
that indicates `guix time-machine`. If time-machine is necessary to get
the older version of python-redis@3.3.8 in the command line, then there
must be something I need to write in the manifest.scm file to let Guix
know, that I want a specific commit id. Or perhaps this is not possible
with a manifest? Or is the idea, that I need to have a tracked channel
as well to achieve it?
> The other no-so-said is to track "guix describe", you *should* _track_
> the file channels.scm:
>
>guix describe -f channels.scm
OK this is probably the part, where I need to read the docs about it. I
do not have a channels.scm and I do not know what does in there. I only
have a vague idea about channels in my head.
>
> Then later or on another machine, you simply run the command:
>
>guix time-machine -C path/to/channels.scm \
>   --  -m path/to/manifest.scm 
If I understand this correctly, a manifest with specific versions can
only be guaranteed to work, if I track a channel as well. And somehow in
that channel definition, I must specify which commit of Guix I am on?
But wouldn't that limit my choice of libraries to what was available in
one commit?
> Hope that helps,
> simon

Thanks for all that info. There are still many things unclear to me, but
I hope to gain an understanding of those as well : )

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl