Hi Mateusz,
On Fri, Jun 13, 2014 at 7:22 AM, Mateusz Kowalczyk
wrote:
>
> In environments where one only has regular user rights resources are
> often constrained, be it hard drive space, memory or computational
> power. Incurring the penalty of having to compile everything on top of
> that merel
On Mon, 16 Jun 2014 10:19:59 -0400
Eelco Dolstra wrote:
> > Well, let's not try to decide the undecidable. Would it be so bad to
> > have explicit dependencies?
>
> One of Nix's main selling points is that you *don't* need to specify runtime
> dependencies explicitly. That has worked great for
Hi,
On 14/06/14 17:05, Ertugrul Söylemez wrote:
> Well, let's not try to decide the undecidable. Would it be so bad to
> have explicit dependencies?
One of Nix's main selling points is that you *don't* need to specify runtime
dependencies explicitly. That has worked great for the last ten year
On 06/14/2014 11:05 PM, Ertugrul Söylemez wrote:
Well, let's not try to decide the undecidable. Would it be so bad to
have explicit dependencies? That seems to be the only sound solution.
If you mean *only* using explicit dependencies and not using the
hash-scanning approach, then I think th
>> I think that any proposal would be seriously considered. Any already
>> existing application creating such a problem would increase your chances
>> to make someone else propose a solution… Otherwise — I think the problem
>> can surface, but I have no idea ho to fix it sanely… I think many other
On Sat, 14 Jun 2014 22:09:21 +0400
Michael Raskin <7c6f4...@mail.ru> wrote:
> >It's probably not a big deal. On the other hand consider that it only
> >happens in a rather special scenario and may go unnoticed for quite
> >some time.
> >
> >Consider an application (like a game) with a bunch of se
>It's probably not a big deal. On the other hand consider that it only
>happens in a rather special scenario and may go unnoticed for quite
>some time.
>
>Consider an application (like a game) with a bunch of separate sets of
>data files, each optional and referring to each other, compressed to
>s
On Sat, 14 Jun 2014 13:43:24 -0400
Shea Levy wrote:
> > I can't. I'm just pointing out a potential problem here. If you
> > disagree, I'll be happy to construct a proof of concept.
>
> Of course it could happen, but we have a huge number of packages in nixpkgs,
> including a significant subse
> On Jun 14, 2014, at 13:29, Ertugrul Söylemez wrote:
>
> On Sat, 14 Jun 2014 09:36:21 -0400
> Shea Levy wrote:
>
>> Please point to a specific example of a package with an unretained
>> dependency due to UTF-16 storage
>
> I can't. I'm just pointing out a potential problem here. If you
>
On Sat, 14 Jun 2014 09:36:21 -0400
Shea Levy wrote:
> Please point to a specific example of a package with an unretained dependency
> due to UTF-16 storage
I can't. I'm just pointing out a potential problem here. If you
disagree, I'll be happy to construct a proof of concept.
Greets,
Ertugr
> On Jun 14, 2014, at 4:28, Ertugrul Söylemez wrote:
>
> On Fri, 13 Jun 2014 18:54:53 +0200
> Eelco Dolstra wrote:
>
>>> The path-rewriting proposal is a very bad idea and will cause a lot of
>>> breakage. For many/enough applications rewriting will not work at all,
>>> because they might en
On Fri, 13 Jun 2014 18:54:53 +0200
Eelco Dolstra wrote:
> > The path-rewriting proposal is a very bad idea and will cause a lot of
> > breakage. For many/enough applications rewriting will not work at all,
> > because they might encode paths in data structures or be using a
> > non-UTF8 multi-by
> On Jun 13, 2014, at 12:54, Eelco Dolstra wrote:
>
> Hi,
>
>> On 13/06/14 08:12, Ertugrul Söylemez wrote:
>>
>> The path-rewriting proposal is a very bad idea and will cause a lot of
>> breakage. For many/enough applications rewriting will not work at all,
>> because they might encode paths
Hi,
On 13/06/14 08:12, Ertugrul Söylemez wrote:
> The path-rewriting proposal is a very bad idea and will cause a lot of
> breakage. For many/enough applications rewriting will not work at all,
> because they might encode paths in data structures or be using a
> non-UTF8 multi-byte encoding.
Pa
On 06/13/2014 06:38 PM, Kirill Elagin wrote:
> P.S. I have 14.10pre44331.25351dd here.
>
>
> --
> Кирилл Елагин
>
>
> On Fri, Jun 13, 2014 at 8:37 PM, Kirill Elagin wrote:
>
>> I get 1h8s… on my PC, so you should probably check the version of nixpkgs
>> checkout and all that stuff.
>> I have
P.S. I have 14.10pre44331.25351dd here.
--
Кирилл Елагин
On Fri, Jun 13, 2014 at 8:37 PM, Kirill Elagin wrote:
> I get 1h8s… on my PC, so you should probably check the version of nixpkgs
> checkout and all that stuff.
> I have no idea why one can get different caches, but I hope that stdenv
>
I get 1h8s… on my PC, so you should probably check the version of nixpkgs
checkout and all that stuff.
I have no idea why one can get different caches, but I hope that stdenv
can't mutate depending on kernel version etc…
--
Кирилл Елагин
On Fri, Jun 13, 2014 at 8:25 PM, Mateusz Kowalczyk
wrote
On 06/13/2014 06:06 PM, Kirill Elagin wrote:
> If I got it right, you just create exactly the same environment on your own
> box with nix store wherever you like (its location is controlled by
> NIX_STORE_DIR) and build everything from source, thus you get binaries with
> custom path to the store h
As someone said earlier, the commands are `nix-store --import` and
`nix-store --export`.
--
Кирилл Елагин
On Fri, Jun 13, 2014 at 8:06 PM, Kirill Elagin wrote:
> If I got it right, you just create exactly the same environment on your
> own box with nix store wherever you like (its location is
If I got it right, you just create exactly the same environment on your own
box with nix store wherever you like (its location is controlled by
NIX_STORE_DIR) and build everything from source, thus you get binaries with
custom path to the store hard-wired. Then you copy those to your target
machine
On 06/13/2014 02:33 PM, Vladimír Čunát wrote:
> On 06/13/2014 02:19 PM, Andreas Herrmann wrote:
>> Given a case where you can't get the admin to give you `/nix`, and where
>> you have space/compute constraints on the target, would it be possible
>> to create the full nix install on your own local m
On 06/13/2014 02:58 PM, Michael Raskin wrote:
I think it is called fakechroot¿
There is also fakechrootng, which is slow.
Ah, fakechrooting to your $HOME might actually be usable. You'll still
miss a few important paths in there, though, like /proc, etc.
Vlada
smime.p7s
Description: S/M
>> Another way would be to hook the path handling procedures of the libc.
>> Rewrite "/nix/store" to whatever is in the NIX_STORE variable. This
>> would be a lot of hard work, but would work much more reliably than
>> rewriting paths in binaries, and it would work without help from root.
>
>Hmm,
On 06/13/2014 08:12 AM, Ertugrul Söylemez wrote:
Vladimír Čunát wrote:
So far there's IMHO been no really good solution proposal. And
probably none is currently providing binaries to use.
The path-rewriting proposal is a very bad idea and will cause a lot of
breakage. For many/enough applica
>I've actually had the same question, recently. I was planning to try a few
>things myself before I ask here. But, now that the discussion is there I'll
>just chime in...
>
>Given a case where you can't get the admin to give you `/nix`, and where
>you have space/compute constraints on the target, w
On 06/13/2014 02:19 PM, Andreas Herrmann wrote:
Given a case where you can't get the admin to give you `/nix`, and where
you have space/compute constraints on the target, would it be possible
to create the full nix install on your own local machine in the correct
paths, and then just copy it to t
I've actually had the same question, recently. I was planning to try a few
things myself before I ask here. But, now that the discussion is there I'll
just chime in...
Given a case where you can't get the admin to give you `/nix`, and where
you have space/compute constraints on the target, would i
Vladimír Čunát wrote:
> For some previous discussion you can see
> https://github.com/NixOS/nix/issues/16
>
> So far there's IMHO been no really good solution proposal. And
> probably none is currently providing binaries to use.
The path-rewriting proposal is a very bad idea and will cause a lot
For some previous discussion you can see
https://github.com/NixOS/nix/issues/16
So far there's IMHO been no really good solution proposal. And probably
none is currently providing binaries to use.
Vlada
smime.p7s
Description: S/MIME Cryptographic Signature
_
On 06/13/2014 07:13 AM, Wout Mertens wrote:
> When you compile things, they will store the absolute paths to their
> dependencies, be it libraries, fonts, datafiles...
>
> If it didn't do that, installs wouldn't be stateless.
>
> Try asking your sysadmin if you can have /nix, you never know :-)
Mateusz Kowalczyk napisał:
>In the Nix manual it says:
>
>##
>
>It is best not to change the Nix store from its default, since doing so
>makes it impossible to use pre-built binaries from the standard Nixpkgs
>channels — that is, all packages will need to be built from source.
>
>##
>
>I'd like
When you compile things, they will store the absolute paths to their
dependencies, be it libraries, fonts, datafiles...
If it didn't do that, installs wouldn't be stateless.
Try asking your sysadmin if you can have /nix, you never know :-)
In any case, if you don't manage to compile Nix, perhaps
In the Nix manual it says:
##
It is best not to change the Nix store from its default, since doing so
makes it impossible to use pre-built binaries from the standard Nixpkgs
channels — that is, all packages will need to be built from source.
##
I'd like to know why it is impossible. I don't und
33 matches
Mail list logo
