A very good point.
On 05/21/2013 06:49 AM, Nicolas Pierron wrote:
Having a release cycle larger than the release cycle of the packages
is a security issue. Firefox has a release cycle of 6 weeks, which
means that every 6 weeks users are by default updated to the latest
version of the browser.
On Tue, May 14, 2013 at 1:26 PM, Eelco Dolstra
eelco.dols...@logicblox.com wrote:
Hi all,
I would like to propose making periodic stable releases of NixOS. Currently
we
only have an unstable channel that tracks the master branches of NixOS and
Nixpkgs. The fact that these branches receive
On 05/21/2013 08:31 AM, Mathijs Kwik wrote:
I also think there should be a distinction between available and default.
If our release cycle is more than a couple of weeks, chances are I
want 1 or 2 more recent packages. I don't want to be forced to run
master just because of this.
If a new
On 05/21/2013 09:19 AM, Mathijs Kwik wrote:
Vladimír Čunát vcu...@gmail.com 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
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 =
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
if
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
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. IMHO,
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 changing the
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
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
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 already
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 marco-owe...@gmx.de writes:
1) I remember having hit this case, too.
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
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 github
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 github
16 matches
Mail list logo
