On 26. Sep2014, at 18:55, Domen Kožar wrote:
>
>
> On Fri, Sep 26, 2014 at 6:53 PM, Christian Theune wrote:
>
> On 25. Sep2014, at 20:00, Domen Kožar wrote:
>
> > Note that from business perspective server admin usually wants to do
> > following two things:
> >
> > 1) to be notified if an
On Fri, Sep 26, 2014 at 6:53 PM, Christian Theune wrote:
>
> On 25. Sep2014, at 20:00, Domen Kožar wrote:
>
> > Note that from business perspective server admin usually wants to do
> following two things:
> >
> > 1) to be notified if any of software packages has a security vuln
> > 2) to take au
On 25. Sep2014, at 20:00, Domen Kožar wrote:
> Note that from business perspective server admin usually wants to do
> following two things:
>
> 1) to be notified if any of software packages has a security vuln
> 2) to take automated/manual actions to upgrade ONLY those packages and not
> bump
Very true, but isn't the stable branch supposed to do exactly that? Only
upgrade things for security reasons or harmless bugfixes? If we're not
doing that, I think we should have clearer guidelines for updating stable.
Wout.
On Thu, Sep 25, 2014 at 8:00 PM, Domen Kožar wrote:
> Note that from
Note that from business perspective server admin usually wants to do
following two things:
1) to be notified if any of software packages has a security vuln
2) to take automated/manual actions to upgrade ONLY those packages and not
bump and versions
Having faster hydra doesn't solve 2)
Domen
On
On Thu, Sep 25, 2014 at 6:33 PM, Michael Raskin <7c6f4...@mail.ru> wrote:
> >> I bet against our package set being buildable in 2 hours — because of
> >> time-critical path likely hitting some non-parallelizable package.
> >>
> >
> >I think most large projects can be compiled via distcc, which mea
>> I bet against our package set being buildable in 2 hours — because of
>> time-critical path likely hitting some non-parallelizable package.
>>
>
>I think most large projects can be compiled via distcc, which means that
>all you need is parallel make.
WebKitGTK… (there is a comment about failure
On Thu, Sep 25, 2014 at 2:41 PM, Michael Raskin <7c6f4...@mail.ru> wrote:
> >It sounds like a necessary evil.
> >
> >Another option would be to make Hydra super fast... What has been explored
> >to optimize compile speeds? Using distcc, ccache, SSD, elastic scaling?
> >
> >What if we had a securit
>It sounds like a necessary evil.
>
>Another option would be to make Hydra super fast... What has been explored
>to optimize compile speeds? Using distcc, ccache, SSD, elastic scaling?
>
>What if we had a security build fund that we could use to briefly run 500
>machines to complete security builds
It sounds like a necessary evil.
Another option would be to make Hydra super fast... What has been explored
to optimize compile speeds? Using distcc, ccache, SSD, elastic scaling?
What if we had a security build fund that we could use to briefly run 500
machines to complete security builds? Would
My proposal is to have an hydra security channel independent of nixpkgs.
SAMPLE USAGE
nix-channel --add
http://hydra.nixos.org/jobset/nixos/security/channel/latest
The channel will provide a to be imported by the
users in their configuration.nix.
The nixos-sec/module.nix will add the relevant
11 matches
Mail list logo
