Pjotr Prins skribis:
> True if you ignore my message about the state being in two places and
> the database can go out of sync/be corrupt.
>
> Rebuilding the database from a store layout would take many of my
> concerns away. What do we have against it?
It’s not about being for or against. :-)
Pjotr Prins skribis:
> To make guix loved by system deployments you have to cater for quick
> and dirty.
Not sure. GuixSD is clearly a departure from “traditional Unix.” I
agree that we have to work to make this acceptable and intelligible to
those used to traditional Unix.
That said, what it
On Tue, Apr 21, 2015 at 12:17:54PM +0200, Pjotr Prins wrote:
> On Tue, Apr 21, 2015 at 12:08:39PM +0200, Ricardo Wurmus wrote:
> > If I were to sync /gnu/store/ across different machines with rsync, I'd
> > make sure to keep any additional state by also copying the
> > localstatedir: /var/guix/. B
On Tue, Apr 21, 2015 at 12:08:39PM +0200, Ricardo Wurmus wrote:
> You could rebuild the database only if the contents of the /gnu/store
> directory were authoritative (which they are not). The database only
> contains four tables and none of the entries are magical:
That is good.
> Someone darin
Pjotr Prins writes:
> On Tue, Apr 21, 2015 at 10:11:29AM +0200, Ludovic Courtès wrote:
>> The important thing is that currently, the DB is authoritative. So it
>> cannot be corrupt (that would be equivalent to having lost /gnu/store
>> altogether), and thus it cannot be repaired.
>
> The point r
On Tue, Apr 21, 2015 at 10:18:51AM +0200, Ludovic Courtès wrote:
> No, it does nothing remotely. The manual has an example showing how to
> use it over SSH, but it???s just an example...
>
> > Would it be an idea to use rsync instead with the --delete
> > switch.
>
> ... and it has a discussion
On Tue, Apr 21, 2015 at 10:11:29AM +0200, Ludovic Courtès wrote:
> The important thing is that currently, the DB is authoritative. So it
> cannot be corrupt (that would be equivalent to having lost /gnu/store
> altogether), and thus it cannot be repaired.
The point really is that it is not so har
Pjotr Prins skribis:
> guix archive copies via ssh it appears.
No, it does nothing remotely. The manual has an example showing how to
use it over SSH, but it’s just an example...
> Would it be an idea to use rsync instead with the --delete
> switch.
... and it has a discussion of bandwidth ef
Pjotr Prins skribis:
> When you administrate a large amount of servers things can go wrong
> due to system failures, failed backup recoveries, hacking attempts and
> adminstrators trying to be clever ;). Murphy's law dictates that the
> store and the sqlitedb meta information will go out of sync.
guix archive copies via ssh it appears. Would it be an idea to use
rsync instead with the --delete switch. That way a copy is efficient
and faithful. You really want the same package quaranteed. I trust
guix, but I don't trust systems.
You give an example of copying profiles. How about copying a s
> What do you mean by ???rebuild should not be necessary If you
> remove files from the store manually?
When you administrate a large amount of servers things can go wrong
due to system failures, failed backup recoveries, hacking attempts and
adminstrators trying to be clever ;). Murphy's law
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
> Would it be possible to bundle meta-data files together with store
> items?
>
> I guess one could in principle make each store item a directory with any
> number of meta-data files plus the actual content of the store item (a
> fi
Pjotr Prins skribis:
> On Sat, Apr 18, 2015 at 11:23:50PM +0200, Ludovic Courtès wrote:
[...]
>> What do you meaning by moving a package with dependencies?
>
> I am thinking about Nix-style closures. But it may only confuse
> things. I don't think the Guix manual covers closures.
I think “Invo
l...@gnu.org (Ludovic Courtès) writes:
> Pjotr Prins skribis:
>
>> BTW when Nix decided to go for a meta-database they lost something. I
>> know it has good reasons (performance mostly) but it took away the
>> self-containedness of packages. It would be nice just to be able to
>> copy/del package
On Sat, Apr 18, 2015 at 11:23:50PM +0200, Ludovic Courtès wrote:
> Pjotr Prins skribis:
>
> > Great :). I would make it a little clearer that this is
> > 'bootstrapping' and hype it a little more that now there is no reason
> > NOT to install Guix. Only 100Mb on your HDD.
>
> Not sure how to do
Pjotr Prins skribis:
> Great :). I would make it a little clearer that this is
> 'bootstrapping' and hype it a little more that now there is no reason
> NOT to install Guix. Only 100Mb on your HDD.
Not sure how to do that, would you like to propose actual text?
The thing is, I want it to remain
Great :). I would make it a little clearer that this is
'bootstrapping' and hype it a little more that now there is no reason
NOT to install Guix. Only 100Mb on your HDD.
The warning about overwriting a Guix installation should be earlier.
Maybe point out that if you want to move a package with de
I’ve documented installation from the binary tarball (which I plan to
distribute for the next release) in commit 09722b1. Please let me know
what you think.
Ludo’.
2.1 Binary Installation
===
This section describes how to install Guix on an arbitrary system from a
self-cont
Mark H Weaver skribis:
> Could we add a package to Guix to build this? If that is undesirable
> for some reason, could we add a command to build it, and jobs on Hydra
> to build it automatically on all platforms supported by the build farm,
> analogous to the 'usb-image' jobs?
Commit b607593 ad
On Sun, Apr 12, 2015 at 4:07 PM, Ludovic Courtès wrote:
>
> I’ve given that a try since it’s actually quite simple to do. The
> procedure in the attached file produces a self-contained tarball. It
> contains the closure of Guix, as well as /var/guix and an initial
> /root/.guix-profile from whic
l...@gnu.org (Ludovic Courtès) writes:
> Pjotr Prins skribis:
>
>> Very nice. GNU Guix out of a box. No more installation pain.
>>
>> The tar-ball should go in the standard download directory. I would
>> name the tar ball with something 'binary', maybe add the supported
>> Linux versions (3.x?)
On Mon, Apr 13, 2015 at 11:57:20AM +0200, Ludovic Courtès wrote:
> Yes, something like guix-binary-0.8.2.x86_64.tar.gz?
>
> I guess we???ll publish it for the next release.
>
> Thanks for your feedback!
So far, I have installed the tarball on 5 machines. And counting...
It is beautiful.
Pj.
Pjotr Prins skribis:
> The tar-ball works a treat!! Simply download and
>
>tar -C / --lzip -xvf guix-tarball-0.8.1.1140.tar.lz
>export ~/.guix-profile/bin:$PATH
>
> Add the build users, update the /gnu/store permissions
Normally guix-daemon adjusts the permissions/ownership of /gnu/stor
The tar-ball works a treat!! Simply download and
tar -C / --lzip -xvf guix-tarball-0.8.1.1140.tar.lz
export ~/.guix-profile/bin:$PATH
Add the build users, update the /gnu/store permissions and start the
daemon and that is it (which could be covered by a simple shell
script).
This should w
Pjotr Prins skribis:
> Well yes, you need to install all prerequisites and that is not always
> trivial. Try bootstrapping on an old Centos install, for example.
> Can't even get Docker going there.
>
> It would be nice to have an installable binary tar ball for Guix. Just
> unpack in root and go
25 matches
Mail list logo
