>>>Yes those fetchurl are my mistake and weren't used in the build anyway.
>>>I've however made it to use_system_mpfr and removed the useless fetchs
>>>(including the pcre source one which doesn't seem used).
>>>To do so I had to bump the mpfr version to 3.1.2.
>>>Patch attached. I'll be sure to se
>>Yes those fetchurl are my mistake and weren't used in the build anyway.
>>I've however made it to use_system_mpfr and removed the useless fetchs
>>(including the pcre source one which doesn't seem used).
>>To do so I had to bump the mpfr version to 3.1.2.
>>Patch attached. I'll be sure to setup a
Hi Lluís,
> Mh I think the manual mainly helps to tell people "please read the
> manual", when they ask the question. ;)
yes, that is true. We cannot expect that people will read the entire
user manual before they begin to hack Nix expressions.
However, Google's web crawler does read those man
Not sure how correct this is, but I grepped my nixpkgs in attempted to
quantify this a bit, here are the results:
$ grep -R configureFlags . | wc -l
951
$ grep -R configureFlags . | grep -E '\$[^{]' | wc -l
156
Marc Weber writes:
> 1) I remember having hit this case, too.
>
> 2) If we don't wan
Excerpts from Lluís Batlle i Rossell's message of Tue May 21 14:11:46 +0200
2013:
> > configureFlags = "--whoami-expression=$USER";
> > configureFlags = "--initial-array=( 'state 1' 'state 5' )";
Let's start from scratch:
configureFlags is a list of space separated arguments, right?
So we alr
Hello!
FYI a paper presenting the design of Guix’s Scheme API and packaging
EDSL has been accepted for the 2013 European Lisp Symposium (ELS), which
will take place in Madrid on June 3–4:
http://arxiv.org/abs/1305.4584
Ludo’.
___
nix-dev mailing lis
1) I remember having hit this case, too.
2) If we don't want to break builds, we could at least change setup.sh
to test whethet it countains $out, if it does, cause error message:
use preConfigure = ''
...
''
instead.
About changing semantics: I don't think it would affect any existing
buil
On Tue, May 21, 2013 at 12:57:10PM +0200, Peter Simons wrote:
> Hi Lluís,
>
> >> Maybe it would be sufficient to document the current behavior in
> >> more detail?
> >
> > Many people hit this problem, when they started using mkDerivation.
>
> yes, that is true. I'm just not convinced that ch
Hi Lluís,
>> Maybe it would be sufficient to document the current behavior in
>> more detail?
>
> Many people hit this problem, when they started using mkDerivation.
yes, that is true. I'm just not convinced that changing the semantics of
configureFlags is the best solution for this issue. IM
Hi All,
On 21/05/2013 06:49, Nicolas Pierron wrote:
[...]
> Having a release cycle larger than the release cycle of the packages
> is a security issue.
[...]
> then we should better constantly follow the latest release instead of keeping
[...]
> because this version will have no more security upda
On Tue, May 21, 2013 at 11:33:26AM +0200, Peter Simons wrote:
> A change to the semantics of 'configureFlags' has significant potential
> to break existing builds. Why would we take that risk? What exactly do
> we gain?
>
> Personally, I've rarely had the need to pass $out in configureFlags, and
A change to the semantics of 'configureFlags' has significant potential
to break existing builds. Why would we take that risk? What exactly do
we gain?
Personally, I've rarely had the need to pass $out in configureFlags, and
if I do need that, then
preConfigure = ''configureFlags="--foo=$out/e
On 05/21/2013 09:19 AM, Mathijs Kwik wrote:
Vladimír Čunát writes:
I don't think we should do this. I thought about similar setups, but
IMHO they get way too much complicated for little gain. Reasons:
(1) Proposed solution. I plan to do something like this:
let stable = (import ./nixpk
13 matches
Mail list logo
