Re: [Nix-dev] Hydra queue is in a weird state

[Eelco Dolstra]

Hi,

On 06/12/2017 01:51 PM, Vladimír Čunát wrote:

> Just to be sure, the binaries from staging are cached at least for a few
> days, right?  

Right now, there is no garbage collection of the cache.nixos.org S3 bucket *at
all*, so binaries are kept indefinitely.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra queue is in a weird state

[Vladimír Čunát]

On 06/12/2017 11:23 AM, Eelco Dolstra wrote:
> Can you be more specific (e.g. build IDs)? I don't see anything wrong at the 
> moment.

Hmm, me neither, not anymore.  The number of queued jobs on trunk* has
also dropped to the number I would expected right after the merge and I
see no particular problem anymore.  It's also possible I just got
confused by something.

Just to be sure, the binaries from staging are cached at least for a few
days, right?  Even if they don't belong to the latest evaluation anymore?

--Vladimir

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra queue is in a weird state

[Eelco Dolstra]

Hi,

On 06/12/2017 08:17 AM, Vladimír Čunát wrote:

> around 24h ago I merged some older staging commit, and Hydra somehow
> hasn't recovered since.
> 
> Most of jobs should've been cached from staging - mainly except for
> Haskell stuff because that got updated on master in the meantime - but
> apparently those jobs are stuck in the queue, not being processed in any
> way.  The machines were reportedly idling a lot yesterday after that
> (now they picked some subsequent jobs on staging).

Can you be more specific (e.g. build IDs)? I don't see anything wrong at the 
moment.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra queue is in a weird state

[Vladimír Čunát]

Hi,
around 24h ago I merged some older staging commit, and Hydra somehow
hasn't recovered since.

Most of jobs should've been cached from staging - mainly except for
Haskell stuff because that got updated on master in the meantime - but
apparently those jobs are stuck in the queue, not being processed in any
way.  The machines were reportedly idling a lot yesterday after that
(now they picked some subsequent jobs on staging).

--Vladimir
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Profpatsch]

On 17-06-04 12:35am, Nicolas Pierron wrote:
> So currently, this project is held by a dead-lock between people
> asking me to demonstrate a large scale example, and having the
> infrastructure to doing so.

I think most of the lockup stems from people
not really knowing what your framework means in practice.

Would you be willing to do a talk about that
(and the remaining work tbd) on Nixcon?

-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Nicolas Pierron]

On Sun, Jun 4, 2017 at 1:17 AM, Bjørn Forsman  wrote:
> On 4 June 2017 at 00:35, Nicolas Pierron  wrote:
>> So I started SOS [1] to make Nixpkgs more
>> declarative.  Thus removing some of the function overhead from
>> packages, which would help fixing a lot of the issues reported by the
>> static-analysis.
>
> I think you forgot to add the link to the SOS thing. (I'm interested.)
>
> Best regards,
> Bjørn Forsman

[1] https://github.com/NixOS/rfcs/pull/3

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Bjørn Forsman]

On 4 June 2017 at 00:35, Nicolas Pierron  wrote:
> So I started SOS [1] to make Nixpkgs more
> declarative.  Thus removing some of the function overhead from
> packages, which would help fixing a lot of the issues reported by the
> static-analysis.

I think you forgot to add the link to the SOS thing. (I'm interested.)

Best regards,
Bjørn Forsman
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Nicolas Pierron]

On Sat, Jun 3, 2017 at 1:26 PM, Graham Christensen  wrote:
> This is part of my inclination of not really loving PR#10851, it is
> complicated and goes around the normal proceses, even when we can easily
> deploy fairly quickly.

The problem that I have with the current solutions is that they
involve _user_ actions (*), they do not address all uses cases, and
potentially a lot of local recompilation time.

PR#10851 goals are to address all of these issues.
>From the _maintainer_ point-of-view, this would be as simple as a
cherry-pick (*).
>From the user point of view, this would be like any ordinary channel.
>From hydra point of view, this would be only rebuilding packages which
have patches, or which are statically linked.

(*) goes around the normal processes.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Nicolas Pierron]

On Sat, Jun 3, 2017 at 12:54 AM, Leo Gaspard  wrote:
> On 06/02/2017 12:05 PM, Domen Kožar wrote:
>>> I see two ways of doing this: either having hydra somehow handle with
>>> special care security updates (hard to do)
>>
>> https://github.com/NixOS/nixpkgs/pull/10851
>
> This looks great!
>
> Unfortunately, it doesn't appear to be close to merging (esp. as it has
> merge conflicts), so I guess that's the best solution that isn't coming
> up right now? So having master and stable always build may be a current
> path forward, not yet as good as this PR but a good stop-gap.

I started a branch at the end of last year, which include these
changes and rebased them on top of the latest master, but I gave up as
I did not got any feedback for getting any Hydra infrastructure in
place to make use of this feature in a testing branch.  Having Hydra
infra in place would be among the next step to demonstrate the
usefulness of this approach, and convince more people to help fix the
static-analysis reports.

So currently, this project is held by a dead-lock between people
asking me to demonstrate a large scale example, and having the
infrastructure to doing so.

Most of the time, unpatched dependencies from PR#10851 are coming from
the fact that dependencies are resolved by functions them-self taken
for older generations of the fix-point, breaking the hypothesis on
which PR#10851 is based on. So I started SOS [1] to make Nixpkgs more
declarative.  Thus removing some of the function overhead from
packages, which would help fixing a lot of the issues reported by the
static-analysis.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Graham Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Leo Gaspard  writes:

> I just wanted to point out an issue with hydra: it doesn't make any
> distinction between security updates and normal changes.
>
> For example, [1] was released two days ago. Despite the fix landing two
> days ago too [2], nixos-unstable still doesn't have the vulnerability
> fixed.

nixos-unstable frequently lags behind for quite some time, and has no
guarantees about how quickly it'll receive security patches. You may be
interested in  nixos-unstable-small, which received the security update
much faster.

While it is fun and nice to think through various solutions to making
our unstable channel get security updates faster, I believe three
things that make it somewhat less critical:

1. The stable and ecommended version of NixOS to run is NixOS 17.03,
which also received the patch quite quickly.

2. There are strategies in place that can side-step the long rebuild
process if required, however they're typically not necessary. On a "the
world is burning" scale problem, nixos has seen a full rebuild from
nothing to channel published in 24 hours.

This is part of my inclination of not really loving PR#10851, it is
complicated and goes around the normal proceses, even when we can easily
deploy fairly quickly.

Most distributions have much more than 24 hours to be notified of an
issue and prepare a release, via the embargoed announcements on the
- -distro mailing list. Unfortunately that list is not accepting new
distro members at this time:
https://github.com/NixOS/nixpkgs/issues/14819

3. The much larger, more difficult problem is organizing _around_ the
security updates and getting them done regularly. These big scary bugs
are important yes, but so are the dozens of little bugs that get patched
weekly in various projects. Many of these are currently going unpatched.
For several months, I organized a weekly bug roundup that handled most
of these. When my bug source dried up, I decided to step away for a
time. I think I'm ready to start again, but need to do some research.

Regarding Hydra building PRs, that was an experiment to see how much
hardware and resources it would take. The integration with GitHub was
not as secure as we'd like, and wasn't suitable for merging with the
official hydra. There have been a few attempts at fixing it. If you'd
like to talk about it and take a crack, I'd be happy to talk with you!

Best,
Graham
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEP+htk0GpxXspt+y6BhIdNm/pQ1wFAlkynPoACgkQBhIdNm/p
Q1yIlw/8DkAEebiHjA+WCLDI6EIkqU0DW/xJDgklQOhILb6tyI/v9E5ip4yhHMrK
K9mjNexHTZSMLZJnFZExuznOAKFOro8YaflWu0RQl/gI3ZMXN+deTstM6S/ETFw6
5k4IYQVk/QBud3JpCUKgEPT1xi9q/CakNtdKMG7Mqxbvp1TljUwre8zk9qfHf1d1
mAWJC7Xhte3cuVzD5yMxnRJJVNhzxS1c7E2XSiSBlpJE3NZbBlr41CDTP63ASPIG
N/aslCw7Jj1RK6mxEHpWRXBQ8C88V17eUFrdB/pYggxmawhlQjSsEJSQ3DN4oib/
7bdvje0EGQGlusEycYQmDlVrMYrWSmKwKGqjF5oQgWxiYq9oTU5SU1dGfsFk8Xqc
DBOW1d2wc+9rdfuZbTbSaooJZOU5ACRyDEjxJYAqTdl4kbDXtGcQGUC14PFbGZWm
71Bl3bJE626Q2ioGPTBfhnmnqRcLkHX9kcYIFVV7G15zD23Ekf6VNHBdqnAf7szg
S0qriB+gh4fE8o63IhhCaTP0rwONZd7HoEVXCRa8FmkEypA+Vr9lCowBeik3DPHi
xSKTmOYg8Wr/RnemcwH1Jp1IFsGMy/ZgNKG9SqEv2PS8ocqPpK3j3QjBe0cw+Kyv
Jc9poZJOJdM8a6RxEn/Nq3Pd7bGod9AbP/O5OsE+60tnYLo30+4=
=XNPZ
-END PGP SIGNATURE-
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Danylo Hlynskyi]

So, the assumption is: "security updates hardly should break stuff, so we
can apply them without tests"
And desire is: "don't publish untested changes to channel"

This clearly leads to necessity of two channels, just as described in
https://github.com/NixOS/nixpkgs/pull/10851#issuecomment-212099317

The second channel, like `nixpkgs-secure`, shouldn't be a fork of nixpkgs
with
`quickfix`-es, but perhaps an overlay with security patches.
It is then included like `nixpkgs.overlays = [ (import
).channel-unstable ];`

This would require for user to "configure" security-update system, and
maintainers to
update nixpkgs-secure package database alongside with nixpkgs master and
nixpkgs stable.

--

Another option is to maintain branches with sufficies "-secure".

1. maintainers should add/remove security patches to "XXX-secure" branches
in nixpkgs-channels
2. hydra should regularly merge "XXX-secure" to "XXX"
3. hydra should merge "XXX" to "XXX-secure" on channel updates
4. hydra should build "XXX" and "XXX-secure" in parallel, and publish
channel whichever finishes faster


2017-06-03 4:13 GMT+03:00 Leo Gaspard :

> On 06/03/2017 01:55 AM, Frank wrote:
> > Op 3-6-2017 om 0:59 schreef Leo Gaspard:
> >> On 06/02/2017 06:54 PM, Frank wrote:
> >>> Op 1-6-2017 om 23:32 schreef Leo Gaspard:
>  Hi all,
> 
>  I just wanted to point out an issue with hydra: it doesn't make any
>  distinction between security updates and normal changes.
> >>> Why is this an issue? Security-updates are just as likely to introduce
> >>> bugs as every other update.
> >> If I have to choose between having a security vulnerability and having
> >> some installer tests that don't build (as these seem to be the source of
> >> most test failures)... I know what I'd rather have (especially given
> >> install images aren't generated from every commit of nixpkgs), don't you
> >> think?
> > You mean al the tests that didn't catch the bug in the first place? Or
> > the tests that assure the fix will be installed without problems?
> >
> > If the testing is a problem for distributing the software, the tests are
> > probably wrong. You can't fix things by testing, so don't try to repeat
> > and improve the upstream testing (not during distribution at least).
> >
> > The focus of the distribution is, distributing software, that installs
> > well on all target systems. And if your fix breaks some systems it
> > doesn't matter how important it is for security.
> >
> > I really agree, it's important to roll out security fixes fast. But I
> > don't see why other updates should be very time consuming.
>
> OK, I think I failed explaining what I think the issue is.
>
> In my mind, the issue is not having a security fix that breaks tests*,
> as fixes are(/should be) tested by upstream to not change any observable
> behavior except the actual security flaw.
>
> However, the issue is in having security fixes being delayed by
> unrelated commits that break tests. Because those other packages are way
> more disruptive than a security fix, and can (often) break tests, as
> there is no enforced "must pass tests on hydra" before merging a PR.
>
>
> * Even though I'd bet that may happen with transient test failures --
> and I'd still want that patch, so that anyone can't break in my system,
> even though it may mean some features not working perfectly as intended:
> time for tests is when preparing the patch, patching systems should be
> done within a few hours at most to consistently avoid attacks, and a few
> hours is hardly enough to even rebuild the system and get people to
> patch. Like, major distros get an ahead-of-time notification of serious
> flaws and prepare and pre-build the patch before it's even known to us,
> just to get the patch out faster... But it's not my main point, as this
> should actually just never happen, the choice of behavior in this case
> is irrelevant.
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Leo Gaspard]

On 06/03/2017 01:55 AM, Frank wrote:
> Op 3-6-2017 om 0:59 schreef Leo Gaspard:
>> On 06/02/2017 06:54 PM, Frank wrote:
>>> Op 1-6-2017 om 23:32 schreef Leo Gaspard:
 Hi all,

 I just wanted to point out an issue with hydra: it doesn't make any
 distinction between security updates and normal changes.
>>> Why is this an issue? Security-updates are just as likely to introduce
>>> bugs as every other update.
>> If I have to choose between having a security vulnerability and having
>> some installer tests that don't build (as these seem to be the source of
>> most test failures)... I know what I'd rather have (especially given
>> install images aren't generated from every commit of nixpkgs), don't you
>> think?
> You mean al the tests that didn't catch the bug in the first place? Or
> the tests that assure the fix will be installed without problems?
> 
> If the testing is a problem for distributing the software, the tests are
> probably wrong. You can't fix things by testing, so don't try to repeat
> and improve the upstream testing (not during distribution at least).
> 
> The focus of the distribution is, distributing software, that installs
> well on all target systems. And if your fix breaks some systems it
> doesn't matter how important it is for security.
> 
> I really agree, it's important to roll out security fixes fast. But I
> don't see why other updates should be very time consuming.

OK, I think I failed explaining what I think the issue is.

In my mind, the issue is not having a security fix that breaks tests*,
as fixes are(/should be) tested by upstream to not change any observable
behavior except the actual security flaw.

However, the issue is in having security fixes being delayed by
unrelated commits that break tests. Because those other packages are way
more disruptive than a security fix, and can (often) break tests, as
there is no enforced "must pass tests on hydra" before merging a PR.


* Even though I'd bet that may happen with transient test failures --
and I'd still want that patch, so that anyone can't break in my system,
even though it may mean some features not working perfectly as intended:
time for tests is when preparing the patch, patching systems should be
done within a few hours at most to consistently avoid attacks, and a few
hours is hardly enough to even rebuild the system and get people to
patch. Like, major distros get an ahead-of-time notification of serious
flaws and prepare and pre-build the patch before it's even known to us,
just to get the patch out faster... But it's not my main point, as this
should actually just never happen, the choice of behavior in this case
is irrelevant.



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Frank]

Op 3-6-2017 om 0:59 schreef Leo Gaspard:

On 06/02/2017 06:54 PM, Frank wrote:

Op 1-6-2017 om 23:32 schreef Leo Gaspard:

Hi all,

I just wanted to point out an issue with hydra: it doesn't make any
distinction between security updates and normal changes.

Why is this an issue? Security-updates are just as likely to introduce
bugs as every other update.

If I have to choose between having a security vulnerability and having
some installer tests that don't build (as these seem to be the source of
most test failures)... I know what I'd rather have (especially given
install images aren't generated from every commit of nixpkgs), don't you
think?
You mean al the tests that didn't catch the bug in the first place? Or 
the tests that assure the fix will be installed without problems?


If the testing is a problem for distributing the software, the tests are 
probably wrong. You can't fix things by testing, so don't try to repeat 
and improve the upstream testing (not during distribution at least).


The focus of the distribution is, distributing software, that installs 
well on all target systems. And if your fix breaks some systems it 
doesn't matter how important it is for security.


I really agree, it's important to roll out security fixes fast. But I 
don't see why other updates should be very time consuming.


Greetings,
Frank
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Leo Gaspard]

On 06/02/2017 06:54 PM, Frank wrote:
> Op 1-6-2017 om 23:32 schreef Leo Gaspard:
>> Hi all,
>>
>> I just wanted to point out an issue with hydra: it doesn't make any
>> distinction between security updates and normal changes.
> 
> Why is this an issue? Security-updates are just as likely to introduce
> bugs as every other update.

If I have to choose between having a security vulnerability and having
some installer tests that don't build (as these seem to be the source of
most test failures)... I know what I'd rather have (especially given
install images aren't generated from every commit of nixpkgs), don't you
think?

If the only change is a security patch as released by the vendor, I
think it may even be worth it to short-circuit all the tests in some
cases, as a flawed system is (in my mind at least) strictly worse than a
buggy system (except if the buggy system is rm -Rf /* ; but well, that
kind of security patch wouldn't live a second on oss-security)



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Leo Gaspard]

On 06/02/2017 12:05 PM, Domen Kožar wrote:
>> I see two ways of doing this: either having hydra somehow handle with
>> special care security updates (hard to do)
> 
> https://github.com/NixOS/nixpkgs/pull/10851

This looks great!

Unfortunately, it doesn't appear to be close to merging (esp. as it has
merge conflicts), so I guess that's the best solution that isn't coming
up right now? So having master and stable always build may be a current
path forward, not yet as good as this PR but a good stop-gap.

>> , or having master and stable branches *always* build.
> 
> For that we'd need to have infrastructure that builds PRs and reports
> status on github.
> 
> I think that's the right solution, but it does involve work and Hydra
> improvements :)

Hmm, "[Nix-dev] Hydra Building PRs" (2017-01-28) made me think hydra was
actually ready and the only needed thing was setting it up on
hydra.nixos.org and use a github bot?

I mean, if it's waiting for only a github bot then I guess it'll be easy
to do (and the fact at least two persons said they were doing it 3
months ago makes me think it's actually already ready) but the part
about setting it up at hydra.nixos.org can be made only by a select few
people, so I guess there is not much most of us can do about it?



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Frank]

Op 1-6-2017 om 23:32 schreef Leo Gaspard:

Hi all,

I just wanted to point out an issue with hydra: it doesn't make any
distinction between security updates and normal changes.


Why is this an issue? Security-updates are just as likely to introduce 
bugs as every other update.


Greetings,
Frank
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[Domen Kožar]

> I see two ways of doing this: either having hydra somehow handle with
> special care security updates (hard to do)

https://github.com/NixOS/nixpkgs/pull/10851

> , or having master and stable branches *always* build.

For that we'd need to have infrastructure that builds PRs and reports
status on github.

I think that's the right solution, but it does involve work and Hydra
improvements :)

On Thu, Jun 1, 2017 at 11:53 PM,  wrote:

> On Thu, Jun 1, 2017, at 23:32, Leo Gaspard wrote:
> > Hi all,
> >
> > [ ... ]
>
> I think this is relevant to your interests:
> https://github.com/NixOS/nixpkgs/pull/10851
>
> On a side note, I don't know why anybody would actually run
> nixos-unstable; it gets stuck for long periods of time quite often ... I
> think sticking to the latest release channel or using the -small variant
> is better, depending on whether you want/need the latest bugs.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra and security updates

[joachifm]

On Thu, Jun 1, 2017, at 23:32, Leo Gaspard wrote:
> Hi all,
> 
> [ ... ]

I think this is relevant to your interests:
https://github.com/NixOS/nixpkgs/pull/10851

On a side note, I don't know why anybody would actually run
nixos-unstable; it gets stuck for long periods of time quite often ... I
think sticking to the latest release channel or using the -small variant
is better, depending on whether you want/need the latest bugs.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra and security updates

[Leo Gaspard]

Hi all,

I just wanted to point out an issue with hydra: it doesn't make any
distinction between security updates and normal changes.

For example, [1] was released two days ago. Despite the fix landing two
days ago too [2], nixos-unstable still doesn't have the vulnerability fixed.

Granted, in this specific case exploitation seems to go through SELinux,
and SELinux is not (afaik) supported on NixOS. But that doesn't mean
it'll be the same for all upcoming vulnerabilities.

And for what reason? [3] It seems a few tests didn't pass for all this
time. Apart from the fact [4] doesn't look related to the said build
failures (are there ephemeral failures on hydra?), this looks like an
issue we should fix: in my opinion, security fixes should start being
built by hydra as soon as they land in the repo.

I see two ways of doing this: either having hydra somehow handle with
special care security updates (hard to do), or having master and stable
branches *always* build.

The second option looks more reasonable to me, but implies that all
changes go through PRs, and are never merged before *after* hydra has
built and checked them. In my opinion, this would also make our overall
update delivery process faster, given that it would no longer block on
failing tests on master.

What do you think about this? Do you have any better idea for how to
handle urgent security issues?
Leo


[1] http://www.openwall.com/lists/oss-security/2017/05/30/16

[2]
https://github.com/NixOS/nixpkgs/blob/3c0114d4728aff4158730ccaf89cc1d9115c83ee/pkgs/tools/security/sudo/default.nix

[3]
https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents

[4]
https://hydra.nixos.org/api/scmdiff?type=git&rev1=c9e63ded807c492106273a10009a28e848c44b82&rev2=3f688207e7316f624ea975e578dc0aff3a1ff2a9&branch=&uri=https%3A%2F%2Fgithub.com%2FNixOS%2Fnixpkgs.git



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra problems

[Vladimír Čunát]

On 05/30/2017 12:29 PM, Danylo Hlynskyi wrote:
> 1. https://hydra.nixos.org seems to have problems with HTTPS: in my
> Firefox.

I can't reproduce that.  Perhaps some transient problem?

> 2. no build results can be downloaded

They aren't stored on Hydra (for months, maybe a couple years now).  I
think the easiest way to get the results is to pass their paths to
`nix-store --realize` which will fetch them from the binary cache.

--Vladimir

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] hydra problems

[Danylo Hlynskyi]

1. https://hydra.nixos.org seems to have problems with HTTPS: in my Firefox.
2. no build results can be downloaded
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: no space on aarch64

[Graham Christensen]

Hi,

Thank you for letting me know.

I've corrected the configuration on the aarch64 box to run garbage
collection. It seems a typo prevented it from running.

Best,
Graham
On Fri, May 26, 2017 at 4:49 AM Vladimír Čunát  wrote:

> Another problem: the "mac2" slave is killing all builds, with
> download-from-binary-cache.pl getting "curl error 60" and consequently a
> segfault. (if I interpret it right)
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: no space on aarch64

[Vladimír Čunát]

Another problem: the "mac2" slave is killing all builds, with
download-from-binary-cache.pl getting "curl error 60" and consequently a
segfault. (if I interpret it right)

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra: no space on aarch64

[Vladimír Čunát]

Hi,
the aarch64 machine has been out of space for the past few days at
least, failing whatever builds it attempted.  It doesn't seem like it
will fix itself (this time).

--Vladimir
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra is down?

[Vladimír Čunát]

On 03/12/2017 06:50 PM, Michael Alan Dorman wrote:
> The web interface at least hasn't been available for a number of hours.

Yes, basically the whole weekend, I think.  I expect admins will be
fixing this during Monday's morning (but I'm just guessing from past
experience).

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra is down?

[Michael Alan Dorman]

The web interface at least hasn't been available for a number of hours.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Maarten Hoogendoorn]

Heh, I've been working on this as well today. Do you have a github repo
somewhere?

2017-03-07 14:27 GMT+01:00 Robin Gloster :

> I'm working on a bot to make sure only acknowledged PRs get built.
>
> That is a bit on hold until the release probably but I'm going to continue
> that definitely.
>
> That bot could then also include stuff like mentioning the correct
> maintainers, auto merging if the builds succeed, security tracking etc.
>
> Cheers
> Robin
>
> On 7 March 2017 14:15:56 CET, Graham Christensen 
> wrote:
>>
>> Bas van Dijk  writes:
>>
>>  Hi Graham, what's te status of this project?
>>>
>>
>> Great question. Dezgeg and I are working on bootstrapping some ARM
>> machines now, at which point I'll be working with Eelco to add
>> them to Hydra.
>>
>> I don't have an ETA, but finding a compatible time between Dezgeg and I
>> was a major blocker. From here, I expect the slow parts will be
>> coordinating with Eelco, then having nixpkgs build them.
>>
>> Graham
>> --
>>
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Robin Gloster]

I'm working on a bot to make sure only acknowledged PRs get built.

That is a bit on hold until the release probably but I'm going to continue that 
definitely.

That bot could then also include stuff like mentioning the correct maintainers, 
auto merging if the builds succeed, security tracking etc.

Cheers
Robin

On 7 March 2017 14:15:56 CET, Graham Christensen  wrote:
>Bas van Dijk  writes:
>
>> Hi Graham, what's te status of this project?
>
>Great question. Dezgeg and I are working on bootstrapping some ARM
>machines now, at which point I'll be working with Eelco to add
>them to Hydra.
>
>I don't have an ETA, but finding a compatible time between Dezgeg and I
>was a major blocker. From here, I expect the slow parts will be
>coordinating with Eelco, then having nixpkgs build them.
>
>Graham
>___
>nix-dev mailing list
>nix-dev@lists.science.uu.nl
>http://lists.science.uu.nl/mailman/listinfo/nix-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Graham Christensen]

Bas van Dijk  writes:

> Hi Graham, what's te status of this project?

Great question. Dezgeg and I are working on bootstrapping some ARM
machines now, at which point I'll be working with Eelco to add
them to Hydra.

I don't have an ETA, but finding a compatible time between Dezgeg and I
was a major blocker. From here, I expect the slow parts will be
coordinating with Eelco, then having nixpkgs build them.

Graham
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Maarten Hoogendoorn]

As a stop-gap measure, what about adding an external SSD drive via usb and
enabling swap?

2017-03-06 16:33 GMT+01:00 Bas van Dijk :

> On 28 January 2017 at 14:20, Graham Christensen 
> wrote:
>
>> Packet.net is also one of the only hosting companies I know of which
>> rents Cavium ThunderX ARMv8s, and they're very interested in our
>> supporting this architecture. Soon, with the help of Dezgeg,
>> prs.nix.gsc.io will also building PRs against ARMv8.
>>
>> After that works, I've spoken with Rob, and it sounds like
>> hydra.nixos.org will gain the ability to run ARMv8 builds, too.
>>
>
> Hi Graham, what's te status of this project?
>
> I'm currently upgrading some Raspberry Pi 3's s to NixOS-17.03 but the
> build of gcc is getting killed by what I expect is the OOM killer (Pi's
> only have 1GB of RAM). It would be great to utilise a Cavium ThunderX
> machine for this.
>
> Are there any blockers; technology-wise, timewise, fundingwise for this
> project to succeed? Do you need help? Maybe I can help.
>
> Regards,
>
> Bas
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Bas van Dijk]

On 28 January 2017 at 14:20, Graham Christensen  wrote:

> Packet.net is also one of the only hosting companies I know of which
> rents Cavium ThunderX ARMv8s, and they're very interested in our
> supporting this architecture. Soon, with the help of Dezgeg,
> prs.nix.gsc.io will also building PRs against ARMv8.
>
> After that works, I've spoken with Rob, and it sounds like
> hydra.nixos.org will gain the ability to run ARMv8 builds, too.
>

Hi Graham, what's te status of this project?

I'm currently upgrading some Raspberry Pi 3's s to NixOS-17.03 but the
build of gcc is getting killed by what I expect is the OOM killer (Pi's
only have 1GB of RAM). It would be great to utilise a Cavium ThunderX
machine for this.

Are there any blockers; technology-wise, timewise, fundingwise for this
project to succeed? Do you need help? Maybe I can help.

Regards,

Bas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra build for qtwebengine stuck

[Vladimír Čunát]

On 02/20/2017 06:47 PM, Michael Alan Dorman wrote:
> The latest attempt to build qtwebengine has failed for reasons
> (http://hydra.nixos.org/build/49045866/nixlog/1/tail-reload) that are
> ultimately environmental---but appear to mean that it won't get retried
> automatically.

There's only success now.  I suppose someone has restarted the job.

> What's the best way to report or address such failures?  Here on the
> list, as a github issue, some other list...?

I'm not sure about that.  It seems OK here to me.

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] hydra build for qtwebengine stuck

[Michael Alan Dorman]

The latest attempt to build qtwebengine has failed for reasons
(http://hydra.nixos.org/build/49045866/nixlog/1/tail-reload) that are
ultimately environmental---but appear to mean that it won't get retried
automatically.

What's the best way to report or address such failures?  Here on the
list, as a github issue, some other list...?

Mike.

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Matthias Beyer]

On 30-01-2017 21:28:11, Graham Christensen wrote:
> 
> SIDE NOTE: I'm considering making a bot which comments on PRs with a
> link to their jobset. Unless someone objects, I'll go ahead and do so.
> 

PLEASE go ahead! I'd love to get notifications like this! Also, you 
could email the author of the PR (or all authors of the commits) if 
someone objects against github-issue-comment-noise!


-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Consider switching to free software.
It adds value to your life.
https://www.gnu.org/


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Kevin Cox]

That's excellent to get the integration tests running!

As for the comment. If it's not too much work it would be great to
integrate it with the status API (I think that's what it is called). It is
much tydier and it's nice to get the pass/fail status highlighted in the
UI.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Graham Christensen]

Update:

Before now, PRs were being built using the nixpkgs release.nix.

As of
https://github.com/grahamc/hydra-prs/commit/df790c5c7f36bc0b0f033b1caf9c3188ddfa4065
all builds are being performed now on the NixOS release-combined.nix.

This means each push will trigger affected tests to run in their VMs.
Any outstanding PRs will have their configuration updated before their
next evaluation. ie: If you have a PR open already, and you make a
change to it, it'll start using this new configuration.

SIDE NOTE: I'm considering making a bot which comments on PRs with a
link to their jobset. Unless someone objects, I'll go ahead and do so.

Graham

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Graham Christensen]

You know what they say: inodes make a fool of us all. I collected garbage
and that should fix it / trigger an evaluation on next push to the PR.


I've also enabled auto GC on the master (salves already had it.) I'll be
pushing this confit change to the hydraprs repo soon.

Note stats are available here - https://stats.nix.gsc.io/ though we may
need to track more.

Graham
On Sat, Jan 28, 2017 at 9:06 AM Graham Christensen 
wrote:

> Bas van Dijk  writes:
>
> > Any idea what is going wrong?
>
> No idea :) The joys of Hydra! I'll check in to it :)
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Graham Christensen]

Bas van Dijk  writes:

> Any idea what is going wrong?

No idea :) The joys of Hydra! I'll check in to it :)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Bas van Dijk]

This is just great work!

I'm also very excited about the work on ARM.

I do see one of my PRs failing to evaluate though:

  https://prs.nix.gsc.io/jobset/nixos/pr-22121#tabs-errors

Any idea what is going wrong?

Bas

On 28 January 2017 at 14:20, Graham Christensen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello everyone,
>
> A couple weeks ago I created https://prs.nix.gsc.io/, a Hydra server
> which builds every PR. Every PR will exist at
> https://prs.nix.gsc.io/jobset/nixos/pr-PRNUMBER.
>
> It features:
>  - a web-hook, which means:
>  - the moment a PR is created, the jobset is created on this hydra
>  - every time a PR is updated, the jobset is triggered
>  - every time there is a commit to master, the master jobset is
>triggered
>
> Non-feature:
>  - I haven't published the public key to the binary cache, because that
>would be very expensive for me to pay for. I am personally paying for
>the binary cache storage. Please don't use the binary cache results.
>
> The entire system is open source, publicly available at
> https://github.com/grahamc/hydra-prs/.
>
> HOW
> - 
>
> The build infrastructure is _very_ generously donated by Packet.net, who
> lease dedicated bare metal servers by the hour. Right now we have about
> 250 cores across 30 servers.
>
> This is still a trial run, though, so the number of systems we get can
> and will change.
>
> In exchange for this hardware, I've been working to add NixOS support to
> their platform. I'm also wanting to make NixOps have built-in support
> for deploying to their hardware.
>
> FUTURE (SOON)
> - 
>
> Packet.net is also one of the only hosting companies I know of which
> rents Cavium ThunderX ARMv8s, and they're very interested in our
> supporting this architecture. Soon, with the help of Dezgeg,
> prs.nix.gsc.io will also building PRs against ARMv8.
>
> After that works, I've spoken with Rob, and it sounds like
> hydra.nixos.org will gain the ability to run ARMv8 builds, too.
>
> FUTURE (LONGER TERM)
> - 
>
> Ideally, I think everyone would like this to become part of
> hydra.nixos.org, Eelco included.
>
> The current state of the system has a couple of patches to Hydra, plus a
> PHP webserver calling CLI utilities to create and trigger jobsets.
> Having this integrated with hydra properly would be way more ideal.
>
> Interpreting the results is a bit of a open question. Sometimes a PR
> will cause unrelated packages to start passing or failing, which is very
> mysterious. This seems less bad than Travis (which fails with any PR
> bigger than a light breeze...) but will still be confusing for people
> who aren't deeply familiar with Hydra.
>
> Other interesting things we may want to implement is setting build
> statuses on GitHub.com, or a bot that posts comments.
>
> I would be very, very happy if people contributed and improved the
> system.
>
> - --
>
> Thank you,
> Graham Christensen
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCAAGBQJYjJqwAAoJEAYSHTZv6UNcZSoP/2pXbxcuetM212X8Rld2BFb1
> 3iNOWN/Kr1PzBSxRyWR/naOt6vA2gs1qv8GpXWCn4QTqlyxTk3QtWY7o9tQ1rJ/K
> rdMct5U8brjrUvOZMNDFhLyrYJSDEhV2YC2GhU4co7xPcGpzQnGi+6YiMLKEi6HV
> wzx34Qoy5MnUp+ZAw8yjf6uTWmS1nsMtisn+tE59pzqeikbhfZ9SLaTtkyCpzTDN
> ZtoAMifjsuTSlxsabmvY1sew3FEEVWhYqczaKU2IklUgAgeVuXVA5/rWQSWVaMc2
> hZOEZTOnvZiGks3hsfNlrI49tb+3Y4kUV2efGmLZULJ/wr00oohabnquXg3rc8NF
> LS//PPpPfQECxr8HOlk93kvW8Lwy8jl51UjdOA01GfdwBmsamTrqpD5qBlJD+Pd2
> KpXhIwtb8ftdpJi/nFq5TNm4XSUMbcztEA6xXN7of2JGaVqLOY/sJ0xuRDbGhuAC
> yd8EdfQvUG6bbm5NGmg0gAstCPi8KqdD0nGBIveSnEomintMP2tbIR6wJ1ah1Sug
> 0mYT+76d/JucxFYQPi5GNGzOfLqyqQwDHB8EGbtJRpW5brR+b5hvSLPZJy5EeDV9
> asn3m7Cjrz3mClnExxIRAEOggmzPmUfFqaUS0mwXOonaEbHLWAtU1+32VRirgKJu
> rAHzDlp/avOCPVDM797z
> =CRhX
> -END PGP SIGNATURE-
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Domen Kožar]

Amazing work :) Can't wait to see Github PRs getting a binary cache.

On Sat, Jan 28, 2017 at 2:28 PM, Kevin Cox  wrote:

>
> On Jan 28, 2017 13:21, "Graham Christensen"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello everyone,
>
> A couple weeks ago I created https://prs.nix.gsc.io/, a Hydra server
> which builds every PR. Every PR will exist at
> https://prs.nix.gsc.io/jobset/nixos/pr-PRNUMBER.
>
> It features:
>  - a web-hook, which means:
>  - the moment a PR is created, the jobset is created on this hydra
>  - every time a PR is updated, the jobset is triggered
>  - every time there is a commit to master, the master jobset is
>triggered
>
>
> Wow, this is fantastic news. This should really help with the quality and
> confidence of PRs. This will hopefully also improve merge throughout.
>
> The one question I have is will this show up on the GitHub PR page or will
> I have to remember the URL myself. Either way it is super useful but if it
> could integrate with the GitHub status API that would be much easier for
> maintainers and new submitters alike.
>
> Huge thanks to you and Package.net. (I've been interested in running an
> arm server for a while so I'll check them out 😀)
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Kevin Cox]

On Jan 28, 2017 13:21, "Graham Christensen"  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello everyone,

A couple weeks ago I created https://prs.nix.gsc.io/, a Hydra server
which builds every PR. Every PR will exist at
https://prs.nix.gsc.io/jobset/nixos/pr-PRNUMBER.

It features:
 - a web-hook, which means:
 - the moment a PR is created, the jobset is created on this hydra
 - every time a PR is updated, the jobset is triggered
 - every time there is a commit to master, the master jobset is
   triggered


Wow, this is fantastic news. This should really help with the quality and
confidence of PRs. This will hopefully also improve merge throughout.

The one question I have is will this show up on the GitHub PR page or will
I have to remember the URL myself. Either way it is super useful but if it
could integrate with the GitHub status API that would be much easier for
maintainers and new submitters alike.

Huge thanks to you and Package.net. (I've been interested in running an arm
server for a while so I'll check them out 😀)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Building PRs

[Graham Christensen]

Graham Christensen  writes:

Gosh! I can't believe I left this out: Daiderd Jordan, LnL / LnL7 has
been hugely instrumental in this project, by writing the glue which
actually adds and triggers jobs. Thank you, Daiderd!
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra Building PRs

[Graham Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello everyone,

A couple weeks ago I created https://prs.nix.gsc.io/, a Hydra server
which builds every PR. Every PR will exist at
https://prs.nix.gsc.io/jobset/nixos/pr-PRNUMBER.

It features:
 - a web-hook, which means:
 - the moment a PR is created, the jobset is created on this hydra
 - every time a PR is updated, the jobset is triggered
 - every time there is a commit to master, the master jobset is
   triggered

Non-feature:
 - I haven't published the public key to the binary cache, because that
   would be very expensive for me to pay for. I am personally paying for
   the binary cache storage. Please don't use the binary cache results.

The entire system is open source, publicly available at
https://github.com/grahamc/hydra-prs/.

HOW
- 

The build infrastructure is _very_ generously donated by Packet.net, who
lease dedicated bare metal servers by the hour. Right now we have about
250 cores across 30 servers.

This is still a trial run, though, so the number of systems we get can
and will change.

In exchange for this hardware, I've been working to add NixOS support to
their platform. I'm also wanting to make NixOps have built-in support
for deploying to their hardware.

FUTURE (SOON)
- 

Packet.net is also one of the only hosting companies I know of which
rents Cavium ThunderX ARMv8s, and they're very interested in our
supporting this architecture. Soon, with the help of Dezgeg,
prs.nix.gsc.io will also building PRs against ARMv8.

After that works, I've spoken with Rob, and it sounds like
hydra.nixos.org will gain the ability to run ARMv8 builds, too.

FUTURE (LONGER TERM)
- 

Ideally, I think everyone would like this to become part of
hydra.nixos.org, Eelco included.

The current state of the system has a couple of patches to Hydra, plus a
PHP webserver calling CLI utilities to create and trigger jobsets.
Having this integrated with hydra properly would be way more ideal.

Interpreting the results is a bit of a open question. Sometimes a PR
will cause unrelated packages to start passing or failing, which is very
mysterious. This seems less bad than Travis (which fails with any PR
bigger than a light breeze...) but will still be confusing for people
who aren't deeply familiar with Hydra.

Other interesting things we may want to implement is setting build
statuses on GitHub.com, or a bot that posts comments.

I would be very, very happy if people contributed and improved the
system.

- --

Thank you,
Graham Christensen
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYjJqwAAoJEAYSHTZv6UNcZSoP/2pXbxcuetM212X8Rld2BFb1
3iNOWN/Kr1PzBSxRyWR/naOt6vA2gs1qv8GpXWCn4QTqlyxTk3QtWY7o9tQ1rJ/K
rdMct5U8brjrUvOZMNDFhLyrYJSDEhV2YC2GhU4co7xPcGpzQnGi+6YiMLKEi6HV
wzx34Qoy5MnUp+ZAw8yjf6uTWmS1nsMtisn+tE59pzqeikbhfZ9SLaTtkyCpzTDN
ZtoAMifjsuTSlxsabmvY1sew3FEEVWhYqczaKU2IklUgAgeVuXVA5/rWQSWVaMc2
hZOEZTOnvZiGks3hsfNlrI49tb+3Y4kUV2efGmLZULJ/wr00oohabnquXg3rc8NF
LS//PPpPfQECxr8HOlk93kvW8Lwy8jl51UjdOA01GfdwBmsamTrqpD5qBlJD+Pd2
KpXhIwtb8ftdpJi/nFq5TNm4XSUMbcztEA6xXN7of2JGaVqLOY/sJ0xuRDbGhuAC
yd8EdfQvUG6bbm5NGmg0gAstCPi8KqdD0nGBIveSnEomintMP2tbIR6wJ1ah1Sug
0mYT+76d/JucxFYQPi5GNGzOfLqyqQwDHB8EGbtJRpW5brR+b5hvSLPZJy5EeDV9
asn3m7Cjrz3mClnExxIRAEOggmzPmUfFqaUS0mwXOonaEbHLWAtU1+32VRirgKJu
rAHzDlp/avOCPVDM797z
=CRhX
-END PGP SIGNATURE-
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra isn't seeing visitors again

[Graham Christensen]

It looks like hydra is busted:

> (en) Please come back later

Graham
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[Graham Christensen]

Christian Theune  writes:

> I’m fighting against getting a very current version of Hydra running,
> as something blocks it from compiling. I’m guessing I need to override
> GCC to GCC6, but the overrideCC drops me in an infinite recursion
> (which doesn’t even look like an infinite recursion to me):

You may check out my hydra-prs repo, where I very recently setup a
hydra:
https://github.com/grahamc/hydra-prs/blob/master/modules/hydra-master/default.nix

Graham
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[Christian Theune]

Hahaha,

no, thanks. :)

Infinite is 32G at the moment and we’re on an older version. It’s one of our 
own changes, most likely this one:
https://github.com/flyingcircusio/nixpkgs/commit/2926129b8940e880a7745e44df511a3d6adacfa9
 


I’m fighting against getting a very current version of Hydra running, as 
something blocks it from compiling. I’m guessing I need to override GCC to 
GCC6, but the overrideCC drops me in an infinite recursion (which doesn’t even 
look like an infinite recursion to me):

error: while evaluating the attribute ‘config.system.build.toplevel’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/activation/top-level.nix:246:5:
while evaluating ‘fold’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/lists.nix:29:19, 
called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/activation/top-level.nix:127:12:
while evaluating ‘fold'’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/lists.nix:32:15, 
called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/lists.nix:36:8:
while evaluating ‘showWarnings’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/activation/top-level.nix:93:18,
 called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/activation/top-level.nix:100:16:
while evaluating ‘fold’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/lists.nix:29:19, 
called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/activation/top-level.nix:93:23:
while evaluating ‘fold'’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/lists.nix:32:15, 
called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/lists.nix:36:8:
while evaluating the attribute ‘warnings’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/attrsets.nix:199:44:
while evaluating anonymous function at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:74:45,
 called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/attrsets.nix:199:52:
while evaluating the attribute ‘value’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:291:9:
while evaluating the option `warnings':
while evaluating the attribute ‘isDefined’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:323:5:
while evaluating ‘filterOverrides’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:395:21,
 called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:307:18:
while evaluating ‘concatMap’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/lists.nix:79:18, 
called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:401:8:
while evaluating ‘concatMap’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/lists.nix:79:18, 
called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:302:17:
while evaluating anonymous function at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:302:28,
 called from undefined position:
while evaluating ‘dischargeProperties’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:365:25,
 called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:303:62:
while evaluating the attribute ‘value’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:203:48:
while evaluating the attribute ‘config.warnings’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/boot/systemd.nix:637:5:
while evaluating anonymous function at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/attrsets.nix:224:10,
 called from undefined position:
while evaluating anonymous function at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/boot/systemd.nix:637:51,
 called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/attrsets.nix:224:16:
while evaluating ‘optional’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/lists.nix:175:20,
 called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/boot/systemd.nix:638:7:
while evaluating the attribute ‘serviceConfig.Type’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/attrsets.nix:199:44:
while evaluating anonymous function at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:74:45,
 called from 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/attrsets.nix:199:52:
while evaluating the attribute ‘value’ at 
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:291:9:
while evalua

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[Christian Kauhaus]

Am 19.01.2017 um 11:12 schrieb Christian Theune:
> Nevertheless, it looks like we may have introduced poisonous code that sends
> the evaluator off into infinity. We’ll come back when we find out what it was.

I got it and I would like to share my findings.

We introduced a change that imported an item "nginxModules" into all-packages:

https://github.com/flyingcircusio/nixpkgs/blob/2926129b8940e880a7745e44df511a3d6adacfa9/nixos/modules/flyingcircus/packages/all-packages.nix#L59

The problem was that (1) this import returnes an attrset or attrsets (none
containing a derivation) and that our all-packages gets imported entirely into
our Hydra master job so that all of our custom packages are guaranteed to be
built:

https://github.com/flyingcircusio/nixpkgs/blob/fc-15.09-dev/nixos/release-flyingcircus.nix#L121

This construct seems to send Hydra's evaluator into nowhere land.

After removing the "nginxModules" attribute, everything seems to be fine again:

https://github.com/flyingcircusio/nixpkgs/blob/fc-15.09-dev/nixos/modules/flyingcircus/packages/all-packages.nix#L54

I don't understand the exact reason. My expectation would be that Hydra's
evaluator ignores attrsets defining no derivations (analogous to a Nix
expression like `collect isDerivation nixpkgs`. Obviously, it doesn't exactly
do so. But hey, now it's running again. :-)

Regards

Christian

-- 
Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[Christian Theune]

Hi,

ok, so the best way getting back to a working Hydra was the tip about running 
the system from a checkout and hydra from a checkout.

Picking the versions from Hydra’s own Hydra job to see which ran fine resulted 
in a ~10day  old nixpkgs and the most current Hydra version running properly.

I’ll keep that as the reference procedure for future updates.

Nevertheless, it looks like we may have introduced poisonous code that sends 
the evaluator off into infinity. We’ll come back when we find out what it was.

Cheers,
Christian

> On 18 Jan 2017, at 19:02, Christian Theune  wrote:
> 
> hi,
> 
> jobsets changing can be broken for the moment, but thanks. Especially seeing 
> that I need to go directly to head.
> 
> Appreciated!
> 
> Christian
> 
>> On 18 Jan 2017, at 18:55, stewart mackenzie > > wrote:
>> 
>> The next problem you will have is this:
>> https://github.com/NixOS/hydra/issues/445 
>> 
>> 
>> remove those changes and you will be able to add jobsets.
> 
> --
> Christian Theune · c...@flyingcircus.io  · +49 
> 345 219401 0
> Flying Circus Internet Operations GmbH · http://flyingcircus.io 
> 
> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
> HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. 
> Zagrodnick
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[Christian Theune]

hi,

jobsets changing can be broken for the moment, but thanks. Especially seeing 
that I need to go directly to head.

Appreciated!

Christian

> On 18 Jan 2017, at 18:55, stewart mackenzie  wrote:
> 
> The next problem you will have is this:
> https://github.com/NixOS/hydra/issues/445
> 
> remove those changes and you will be able to add jobsets.

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[stewart mackenzie]

see https://github.com/NixOS/hydra/issues/444

On Thu, Jan 19, 2017 at 1:53 AM, Christian Theune  wrote:
> Hi,
>
> On 18 Jan 2017, at 18:33, Jean-Pierre  wrote:
>
> New version of hydra (2016-12-09) override gcc to gcc6
>
> https://github.com/NixOS/hydra/blob/aef048b3cb3a7db25b1c48366f266031c5905c0b/release.nix#L127
>
>
> yeah, that’s what I’m using. I’m currently struggling trying to find a good
> base channel for the system (16.09 vs unstable) and a version of hydra,
> either by fetching the full module from the repo, …
>
> The newest version I could manage to get working had problems with the bzip
> perl module …
>
> I’ll give up the yak shaving for today, I guess. I had a working
> intermediate setup where the evaluation was still spinning and we’ll likely
> debug that tomorrow trying to find the part of the change that triggers
> this.
>
> Cheers,
> Christian
>
> --
> Christian Theune · c...@flyingcircus.io · +49 345 219401 0
> Flying Circus Internet Operations GmbH · http://flyingcircus.io
> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
> HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian.
> Zagrodnick
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[stewart mackenzie]

The next problem you will have is this:
https://github.com/NixOS/hydra/issues/445

remove those changes and you will be able to add jobsets.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[Christian Theune]

Hi,

> On 18 Jan 2017, at 18:33, Jean-Pierre  wrote:
> 
> New version of hydra (2016-12-09) override gcc to gcc6
> 
> https://github.com/NixOS/hydra/blob/aef048b3cb3a7db25b1c48366f266031c5905c0b/release.nix#L127
>  
> 

yeah, that’s what I’m using. I’m currently struggling trying to find a good 
base channel for the system (16.09 vs unstable) and a version of hydra, either 
by fetching the full module from the repo, …

The newest version I could manage to get working had problems with the bzip 
perl module …

I’ll give up the yak shaving for today, I guess. I had a working intermediate 
setup where the evaluation was still spinning and we’ll likely debug that 
tomorrow trying to find the part of the change that triggers this.

Cheers,
Christian

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[Christian Theune]

Hi,

our Hydra exploded today: after a recent change to our nixpkgs branch, we 
encountered the evaluator consuming infinite CPU and quite a lot of memory.

Updating to a current version of Hydra (nixpkgs trunk) didn’t help. We’re going 
to go through the changes that caused this tomorrow.

However, I wanted to check whether anybody has experienced this before and 
might know what can trigger this behaviour. I also haven’t seen any changes in 
the last year to hydra that would seem relevant, apart from, maybe, the 
concurrent evaluator, which isn’t in nixpkgs master yet.

Christian

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra local build failed

[Walter Franzini]

On Wed, Dec 14, 2016 at 06:40:54PM +0100, Joachim Schiele wrote:

[...]

> in your case you simply are missing some dependencies, how do you build
> it? with nix-build or nix-shell?

I'm installing with nix-env:

$ export NIX_DAEMON=remote
$ nix-env -i hydra
installing 'hydra-2016-04-15'



-- 
walter franzini
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra local build failed

[Joachim Schiele]

On 12.12.2016 13:39, Walter Franzini wrote:
> Hi,
> 
> I'm going to experiment with hydra and installing it in a nix
> multi-user environment I get a compilation error:
> 
> ...
> g++ -DHAVE_CONFIG_H -I. -I../..
> -I/nix/store/xibmb4s2xah92zx2m34gng55in38l2cq-boehm-gc-7.2g-dev/include 
> -I/nix/store/i90xvxfz44hg85yyv9px2vkkvdarfn85-nix-1.12pre4523_3b81b26-dev/include/nix
>  -Wall -laws-cpp-sdk-s3 -g -O2 -std=c++11 -c -o s3-binary-cache-store.o 
> s3-binary-cache-store.cc
> s3-binary-cache-store.cc:6:29: fatal error: aws/s3/S3Client.h: No such file 
> or directory
> compilation terminated.
> make[3]: *** [Makefile:442: s3-binary-cache-store.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[3]: Leaving directory 
> '/tmp/nix-build-hydra-2016-04-15.drv-0/hydra-177bf25d648092826a75369191503a3f2bb763a4-src/src/hydra-queue-runner'
> make[2]: *** [Makefile:363: all-recursive] Error 1
> ...
> 
> What I'm doing wrong?
> 
> Thanks
> 

in your case you simply are missing some dependencies, how do you build
it? with nix-build or nix-shell?

however:

there was no announcement but hydra is now part of nixpkgs which is awesome:










services = {




  openssh.enable = true;
  postfix = {
enable = true;
setSendmail = true;
  };

  hydra = {
enable = true;
dbi = "dbi:Pg:dbname=hydra;host=localhost;user=hydra;";
hydraURL = "https://hydra.nixcloud.io";;
listenHost = "localhost";
port = 3000;
minimumDiskFree = 20;  # in GB
minimumDiskFreeEvaluator = 2;
notificationSender = "j...@lastlog.de";
logo = null;
debugServer = false;
  };
  # Hydra requires postgresql to run
  postgresql.enable = true;
  postgresql.package = pkgs.postgresql;
  postgresql.authentication = pkgs.lib.mkOverride 10 ''
host hydra all 127.0.0.1/8 trust
local all all trust
  '';

  # frontend http/https server
  nginx.enable = true;
  nginx.config =
''
  error_log /var/log/nginx-error.log;
  events {}

  http {
server {
  listen 80 default_server;
  listen [::]:80 default_server;
  server_name _;
  return 301 https://$host$request_uri;
}
server {
  listen 443 ssl;
  access_log /var/log/nginx-access.log;
  server_name hydra.nixcloud.io;
  ssl_certificate /root/ssl/hydra.crt;
  ssl_certificate_key /root/ssl/hydra.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers HIGH:!aNULL:!MD5;
  location / {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Request-Base "https://hydra.nixcloud.io";;
proxy_pass http://localhost:3000/;
  }
}
  }
'';
};



___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] hydra local build failed

[Walter Franzini]

Hi,

I'm going to experiment with hydra and installing it in a nix
multi-user environment I get a compilation error:

...
g++ -DHAVE_CONFIG_H -I. -I../..
-I/nix/store/xibmb4s2xah92zx2m34gng55in38l2cq-boehm-gc-7.2g-dev/include 
-I/nix/store/i90xvxfz44hg85yyv9px2vkkvdarfn85-nix-1.12pre4523_3b81b26-dev/include/nix
 -Wall -laws-cpp-sdk-s3 -g -O2 -std=c++11 -c -o s3-binary-cache-store.o 
s3-binary-cache-store.cc
s3-binary-cache-store.cc:6:29: fatal error: aws/s3/S3Client.h: No such file or 
directory
compilation terminated.
make[3]: *** [Makefile:442: s3-binary-cache-store.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory 
'/tmp/nix-build-hydra-2016-04-15.drv-0/hydra-177bf25d648092826a75369191503a3f2bb763a4-src/src/hydra-queue-runner'
make[2]: *** [Makefile:363: all-recursive] Error 1
...

What I'm doing wrong?

Thanks
-- 
walter franzini
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra Github Status Plugin

[Philipp Hausmann]

Hi,

I managed to figure it out in the meantime. The solution is quite 
simple, add an XML snippet like that to the Hydra extraConfig option:


  services.hydra = {
enable = true;
..
extraConfig = ''
  binary_cache_secret_key_file = 
  
jobs = test:test:test
inputs = src
authorization = Basic {BASE64 of user:pw}
excludeBuildFromContext = 1
  '';

What I found really confusing is that the Hydra config file is a mix of 
XML snippets and INI style values. It took me quite some
time to figure out that the XML snippet really goes into the Hydra 
config file.


Some more "documentation" can be found in the original PR ( 
https://github.com/NixOS/hydra/pull/280 ).


Cheers, Philipp


On 10/12/2016 02:57 PM, Philipp Hausmann wrote:

Hi,

I am using Hydra for CI and I am loving it so far. However, it would 
be really nice to show the build status on Github. I see that there is 
a GithubStatus plugin in the Hydra source code, but I couldn't find 
any examples or documentation on how to use it. Is anybody using the 
GithubStatus plugin and could give me a hint? How do I configure the 
plugin?


Cheers,
Philipp


___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra Github Status Plugin

[Philipp Hausmann]

Hi,

I am using Hydra for CI and I am loving it so far. However, it would be 
really nice to show the build status on Github. I see that there is a 
GithubStatus plugin in the Hydra source code, but I couldn't find any 
examples or documentation on how to use it. Is anybody using the 
GithubStatus plugin and could give me a hint? How do I configure the plugin?


Cheers,
Philipp
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra stuck?

[Eelco Dolstra]

Hi,

On 09/21/2016 02:04 AM, Michael Alan Dorman wrote:

> At least the web interface doesn't appear to have changed anything in
> the last 24 hours or so...

Hydra-evaluator was hanging in a Mercurial checkout. I've restarted it.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra stuck?

[Michael Alan Dorman]

At least the web interface doesn't appear to have changed anything in
the last 24 hours or so...
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra having problems?

[Michael Alan Dorman]

It looks like there's a lot of idle machines, with nothing attempting to
build?

Mike.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra is down

[Vladimír Čunát]

On 07/31/2016 07:27 AM, Daniel Hlynskyi wrote:
> https://hydra.nixos.org/ returns 500 Internal Server Error

Now it's up again, after more than a day, I think.




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra is down

[Daniel Hlynskyi]

https://hydra.nixos.org/ returns 500 Internal Server Error
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra

[Tomas Hlavaty]

Hi Fare,

"Dev.Rideau.Fare"  writes:
> I'm trying to determine how feasible it would be (with how much work)
> to use Hydra for a CI environment at work (replacing buildbot).

we've been using hydra for about a year now.  Not sure how does it
compare to buildbot but we had no CI before, so it is a huge improvement
for us in any case.

The biggest effort was to write nix expressions for everything we wanted
to build, mainly because I was new to nixos.  Most expressions were
reasonably easy, but some, e.g. oracleXE was a challenge and still have
some issues.  It works for our need and we even got an experienced nixos
contributor to help us with plugging mingw based builds and tests into
hydra too.

There is no official hydra release, which can be rather frustrating.
This is hopefully going to change as there seem to be an effort to
change this.

> * I don't see much documentation. Many links are dead or redirect to
> the wrong thing: the old 2008 paper mentions nixos.org/hydra-scp but
> that doesn't exist. The "instructions available" link to a hydra job
> instead of an actual manual, and trying to manually link on "manual"
> goes to 404.
>

https://github.com/peti/hydra-tutorial should help you

> * How do you specify tests with hydra? When tests are stateful
> (especially integration tests), can it distinguish between tests that
> actually failed, and failure to test due to e.g. timeout trying to
> setup a test server? Can it handle retrying such tests?

Normally, software is split into packages, which are often implemented
as derivations in nix (kind of hash-consing).  These derivations depend
on each other, and when you let hydra test a package and some dependency
fails, it will tell you.  You can also restart failed builds.  You can
also write VM tests, where you write a nix expression, which when run,
creates a nixos VM with all your dependencies, runs your code and tells
you if it works or what fails.  You can also run the test locally in
qemu and poke around, quite easily.

> * Can Hydra drive Nix workers on Windows? on MacOS?

https://hydra.nixos.org/ has some OSX slaves.

Windows is a problem.  As I said above, we test our lisp app using mingw
and wine under nixos.  It is challenging but possible this way.

> * How much work would it be to make the above work, if it doesn't work
> yet?

Depends how much and how obscure software do you have.  You can checkout
, poke around and see some packages,
how they are implemented.  Obscure proprietary dependencies can be a
problem.

Good luck!

Tomas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra

[Dev.Rideau.Fare]

Dear NixOS developers,


I'm trying to determine how feasible it would be (with how much work) to use 
Hydra for a CI environment at work (replacing buildbot).


* I don't see much documentation. Many links are dead or redirect to the wrong 
thing: the old 2008 paper mentions nixos.org/hydra-scp but that doesn't exist. 
The "instructions available" link to a hydra job instead of an actual manual, 
and trying to manually link on "manual" goes to 404.


* How do you specify tests with hydra? When tests are stateful (especially 
integration tests), can it distinguish between tests that actually failed, and 
failure to test due to e.g. timeout trying to setup a test server? Can it 
handle retrying such tests?


* Can Hydra drive Nix workers on Windows? on MacOS?


* How much work would it be to make the above work, if it doesn't work yet?


-#f

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra out of disk space

[Matthias Beyer]

Maybe it would be a good idea to remove the old channels (13.10 up to 
14.12).

On 16-07-2016 11:50:32, Mateusz Czaplinski wrote:
> Sorry if this was already discussed, but I had a thought recently,
> that if the Hydra farm has recurring trouble with capacity, maybe
> there is a chance some third-party company or individual would be
> willing to contribute hardware, e.g. if asked for help on Hacker News,
> twitter, etc.
> 
> On Fri, Jul 15, 2016 at 10:13 PM, Bjørn Forsman  
> wrote:
> > Hi all,
> >
> > I don't know if it's needed or not (you are probably aware), but here
> > is a reminder that hydra builds are still failing due to "out of disk
> > space".
> >
> > - Bjørn
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra out of disk space

[Teo Klestrup Röijezon]

How much space does it currently take up?

On 16 July 2016 at 11:50, Mateusz Czaplinski  wrote:

> Sorry if this was already discussed, but I had a thought recently,
> that if the Hydra farm has recurring trouble with capacity, maybe
> there is a chance some third-party company or individual would be
> willing to contribute hardware, e.g. if asked for help on Hacker News,
> twitter, etc.
>
> On Fri, Jul 15, 2016 at 10:13 PM, Bjørn Forsman 
> wrote:
> > Hi all,
> >
> > I don't know if it's needed or not (you are probably aware), but here
> > is a reminder that hydra builds are still failing due to "out of disk
> > space".
> >
> > - Bjørn
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra out of disk space

[Mateusz Czaplinski]

Sorry if this was already discussed, but I had a thought recently,
that if the Hydra farm has recurring trouble with capacity, maybe
there is a chance some third-party company or individual would be
willing to contribute hardware, e.g. if asked for help on Hacker News,
twitter, etc.

On Fri, Jul 15, 2016 at 10:13 PM, Bjørn Forsman  wrote:
> Hi all,
>
> I don't know if it's needed or not (you are probably aware), but here
> is a reminder that hydra builds are still failing due to "out of disk
> space".
>
> - Bjørn
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra out of disk space

[Bjørn Forsman]

Hi all,

I don't know if it's needed or not (you are probably aware), but here
is a reminder that hydra builds are still failing due to "out of disk
space".

- Bjørn
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra out of disk space

[Bjørn Forsman]

I just checked the release-16.03 job, some builds are failing, checked
a random one:

tar: adwaita-icon-theme-3.18.0/Adwaita/32x32/status/appointment-soon.png:
Cannot write: No space left on device
tar: 
adwaita-icon-theme-3.18.0/Adwaita/32x32/status/network-transmit-receive.png:
Cannot write: No space left on device
tar: Exiting with failure status due to previous errors
do not know how to unpack source archive
/nix/store/n7xni4clqcbl8wfdhr7p90bgfg9vfbl6-adwaita-icon-theme-3.18.0.tar.xz
builder for 
‘/nix/store/aj2imi6wzhf96q1wwkhcdd2gvdai3aki-adwaita-icon-theme-3.18.0.drv’
failed with exit code 1

- Bjørn
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra is down (500 Internal Server Error)

[Bjørn Forsman]

Now it works.

- Bjørn
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra is down (500 Internal Server Error)

[Bjørn Forsman]

This is what you get when visiting hydra.nixos.org:

500 Internal Server Error

DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: DBI
connect('dbname=hydra;user=hydra;','',...) failed: could not connect
to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"? at
/nix/store/1v5dnxk26iifwqlqjifk7mql7y5n0n9g-hydra-perl-deps/lib/perl5/site_perl/5.22.1/DBIx/Class/Storage/DBI.pm
line 1489. at 
/nix/store/jvi7r1v8gnbs4v3f463ngd6n6h8db3r5-hydra-0.1.1234.abcdef/libexec/hydra/lib/Hydra/Helper/CatalystUtils.pm
line 357

- Bjørn
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[stewart mackenzie]

On 20 Jun 2016 17:53, "Domen Kožar"  wrote:
> I do agree it's additional work, but it's better than current state where
we all maintain our Hydra from carefully picked commits and that's REALLY
some additional work.

Completely agree, it's kind of annoying going through the commits
determining which one is good. Once selected you're hesitant to move to a
more recent commit as it could blow up.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[Domen Kožar]

On Thu, Jun 16, 2016 at 2:50 PM, Tomasz Czyż  wrote:

>
>
> 2016-06-16 11:31 GMT+01:00 Domen Kožar :
>
>> On Thu, Jun 16, 2016 at 11:23 AM, Tomasz Czyż 
>> wrote:
>>
>>> Domen,
>>>
>>> do you know what's the strategy for hydra in nixos? Looks like module
>>> file is not imported from hydra but is copied/prepared separately in nixos.
>>> That means there are two module versions but one code base.
>>>
>>> Will hydra module be moved to nixos? If not, maybe would be better to
>>> just import it from upstream?
>>>
>>> Is strategy (to keep modules inside nixos for external packages, even
>>> those with nix modules) the way to go for all other projects? If yes, could
>>> you explain why or point to some explanations?
>>>
>>
>>  Currently module in nixpkgs and the module in hydra will be maintained
>> separately. Eelco will deploy Hydra as it's always been and update
>> package/module in hydra.git, I'll port changes to nixpkgs.
>>
>> We currently don't have a better way to deal with this. I'll see how it
>> goes, but the idea is Hydra repository should be self contained.
>>
>
> IMHO, this makes additional work without giving too much.
>
> 1. you have to port module into nixos each time you fetch new hydra change
> 2. if hydra will brake compatibility with nixos you have to fix ported
> version (which makes situation where two modules needs to be maintained)
>
> but if you would just import module from nix you have:
>
> 1. when updating hydra you just check if tests pass
> 2. if something is broken you can fix upstream or override hydra module to
> create temporary fix
>
> So I assume second approach is lot less work with the same weak points.
> Maybe I'm missing something but for me it looks like just adding more
> manual work to do.
> What do you think?
>
> Also, there is a case (not mine yet, but I assume will be at some point)
> when you want to keep specific hydra version with it's module
> implementation, is it possible to do that in a current version? (I mean
> import hydra's module which override local module)?
>

I'd rather talk about specific use cases than hypothetical questions.

I'll port new Hydra changes to nixpkgs now and then, but maybe some day
hydra.nixos.org starts using hydraUnstable package from nixpkgs and we can
get rid of all nix stuff in hydra.git repository.

I do agree it's additional work, but it's better than current state where
we all maintain our Hydra from carefully picked commits and that's REALLY
some additional work.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[Tomasz Czyż]

2016-06-16 11:31 GMT+01:00 Domen Kožar :

> On Thu, Jun 16, 2016 at 11:23 AM, Tomasz Czyż 
> wrote:
>
>> Domen,
>>
>> do you know what's the strategy for hydra in nixos? Looks like module
>> file is not imported from hydra but is copied/prepared separately in nixos.
>> That means there are two module versions but one code base.
>>
>> Will hydra module be moved to nixos? If not, maybe would be better to
>> just import it from upstream?
>>
>> Is strategy (to keep modules inside nixos for external packages, even
>> those with nix modules) the way to go for all other projects? If yes, could
>> you explain why or point to some explanations?
>>
>
>  Currently module in nixpkgs and the module in hydra will be maintained
> separately. Eelco will deploy Hydra as it's always been and update
> package/module in hydra.git, I'll port changes to nixpkgs.
>
> We currently don't have a better way to deal with this. I'll see how it
> goes, but the idea is Hydra repository should be self contained.
>

IMHO, this makes additional work without giving too much.

1. you have to port module into nixos each time you fetch new hydra change
2. if hydra will brake compatibility with nixos you have to fix ported
version (which makes situation where two modules needs to be maintained)

but if you would just import module from nix you have:

1. when updating hydra you just check if tests pass
2. if something is broken you can fix upstream or override hydra module to
create temporary fix

So I assume second approach is lot less work with the same weak points.
Maybe I'm missing something but for me it looks like just adding more
manual work to do.
What do you think?

Also, there is a case (not mine yet, but I assume will be at some point)
when you want to keep specific hydra version with it's module
implementation, is it possible to do that in a current version? (I mean
import hydra's module which override local module)?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[Domen Kožar]

On Thu, Jun 16, 2016 at 11:23 AM, Tomasz Czyż  wrote:

> Domen,
>
> do you know what's the strategy for hydra in nixos? Looks like module file
> is not imported from hydra but is copied/prepared separately in nixos. That
> means there are two module versions but one code base.
>
> Will hydra module be moved to nixos? If not, maybe would be better to just
> import it from upstream?
>
> Is strategy (to keep modules inside nixos for external packages, even
> those with nix modules) the way to go for all other projects? If yes, could
> you explain why or point to some explanations?
>

 Currently module in nixpkgs and the module in hydra will be maintained
separately. Eelco will deploy Hydra as it's always been and update
package/module in hydra.git, I'll port changes to nixpkgs.

We currently don't have a better way to deal with this. I'll see how it
goes, but the idea is Hydra repository should be self contained.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[Tomasz Czyż]

Domen,

do you know what's the strategy for hydra in nixos? Looks like module file
is not imported from hydra but is copied/prepared separately in nixos. That
means there are two module versions but one code base.

Will hydra module be moved to nixos? If not, maybe would be better to just
import it from upstream?

Is strategy (to keep modules inside nixos for external packages, even those
with nix modules) the way to go for all other projects? If yes, could you
explain why or point to some explanations?

2016-06-16 9:54 GMT+01:00 Tomas Hlavaty :

> Hi Domen,
>
> Domen Kožar  writes:
> > Hydra NixOS module and package are now available on nixpkgs master.
>
> thank you!
>
> > There's one bug I need to fix, then I'll backport these changes to
> > 16.03.
>
> great!
>
> > Meanwhile, I used following commit on 16.03 before I moved to the
> > fork using some improvements: https://github.com/snabblab/
> > snabblab-nixos/commit/20a3fe6e9cf9e0da2a855bd1df9ce7ebad434951
>
> good, if I don't succeed with my upgrade, I'll try that.
>
> > Official releases will for now be pinned git revisions on nixpkgs,
> > hopefully that will suffice for most of us.
>
> Will the official hydra be on 16.03 or unstable?
>
> > On Tue, Jun 14, 2016 at 4:21 PM, Tomas Hlavaty <
> >   1258008 2016-04-15 hydraSrc → 177bf25
> >   at https://hydra.nixos.org/jobset/hydra/master/evals?page=2
>
> I am upgrading to hydra 177bf25 on nixos 16.03 and it seems to work
> except that hydra lost the ability to do distributed builds.  Has
> something changed in this regard in hydra/nix/nixos?
>
> In "journal -xe" log, I can see that hydra-queue-runner loads a build
> into nix-daemon but then the build is stuck as queued forever.
>
> I can't see any error messages from nix-daemon.  Is there a way to debug
> nix-daemon in order to see, what is it doing?
>
> Tomas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>



-- 
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[Tomas Hlavaty]

Hi Domen,

Domen Kožar  writes:
> Hydra NixOS module and package are now available on nixpkgs master.

thank you!

> There's one bug I need to fix, then I'll backport these changes to
> 16.03.

great!

> Meanwhile, I used following commit on 16.03 before I moved to the
> fork using some improvements: https://github.com/snabblab/
> snabblab-nixos/commit/20a3fe6e9cf9e0da2a855bd1df9ce7ebad434951

good, if I don't succeed with my upgrade, I'll try that.

> Official releases will for now be pinned git revisions on nixpkgs,
> hopefully that will suffice for most of us.

Will the official hydra be on 16.03 or unstable?

> On Tue, Jun 14, 2016 at 4:21 PM, Tomas Hlavaty <
>   1258008 2016-04-15 hydraSrc → 177bf25
>   at https://hydra.nixos.org/jobset/hydra/master/evals?page=2

I am upgrading to hydra 177bf25 on nixos 16.03 and it seems to work
except that hydra lost the ability to do distributed builds.  Has
something changed in this regard in hydra/nix/nixos?

In "journal -xe" log, I can see that hydra-queue-runner loads a build
into nix-daemon but then the build is stuck as queued forever.

I can't see any error messages from nix-daemon.  Is there a way to debug
nix-daemon in order to see, what is it doing?

Tomas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[Colin Putney]

On Wed, Jun 15, 2016 at 3:40 AM, Domen Kožar  wrote:

> Hydra NixOS module and package are now available on nixpkgs master.
> There's one bug I need to fix, then I'll backport these changes to 16.03.
>
> Meanwhile, I used following commit on 16.03 before I moved to the fork
> using some improvements:
> https://github.com/snabblab/snabblab-nixos/commit/20a3fe6e9cf9e0da2a855bd1df9ce7ebad434951
>
> Official releases will for now be pinned git revisions on nixpkgs,
> hopefully that will suffice for most of us.
>

Hooray! Thank you so much to all the people that contributed to this.

Colin
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[Domen Kožar]

Hydra NixOS module and package are now available on nixpkgs master. There's
one bug I need to fix, then I'll backport these changes to 16.03.

Meanwhile, I used following commit on 16.03 before I moved to the fork
using some improvements:
https://github.com/snabblab/snabblab-nixos/commit/20a3fe6e9cf9e0da2a855bd1df9ce7ebad434951

Official releases will for now be pinned git revisions on nixpkgs,
hopefully that will suffice for most of us.



On Tue, Jun 14, 2016 at 4:21 PM, Tomas Hlavaty <
tomas.hlav...@knowledgetools.de> wrote:

> Hi,
>
> does somebody know, what hydra and nixos versions/commits are deployed
> at hydra.nixos.org?
>
> I am running hydra with nixos 15.09 and hydra
> 993647d1e3b43f1f9b7dc2ebce889b475d156bb9 but I would like to upgrade my
> local hydra machine to nixos 16.03.
>
> I can see that the last successful hydra build was
>
>   1258008 2016-04-15 hydraSrc → 177bf25
>   at https://hydra.nixos.org/jobset/hydra/master/evals?page=2
>
> but it would be nice to know what is actually used.
>
> Even better would be, if I could somehow find it out somewhere publicly
> accessible without having to ask each time.
>
> What is the status of the official hydra releases?
>
> Thank you,
>
> Tomas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[Tomas Hlavaty]

Hi,

does somebody know, what hydra and nixos versions/commits are deployed
at hydra.nixos.org?

I am running hydra with nixos 15.09 and hydra
993647d1e3b43f1f9b7dc2ebce889b475d156bb9 but I would like to upgrade my
local hydra machine to nixos 16.03.

I can see that the last successful hydra build was

  1258008 2016-04-15 hydraSrc → 177bf25
  at https://hydra.nixos.org/jobset/hydra/master/evals?page=2

but it would be nice to know what is actually used.

Even better would be, if I could somehow find it out somewhere publicly
accessible without having to ask each time.

What is the status of the official hydra releases?

Thank you,

Tomas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra jobs from private git repositories

[Teo Klestrup Röijezon]

D'oh! Disabling StrictHostKeyChecking made it work perfectly, thanks!

On 25 March 2016 at 23:28, Domen Kožar  wrote:

> See https://github.com/peti/hydra-tutorial/issues/2
>
> On Fri, Mar 25, 2016 at 9:48 PM, Teo Klestrup Röijezon 
> wrote:
>
>> For the record, it says something about host key verification failing. If
>> I try to run `ssh g...@bitbucket.org` sudoed as either user it works and
>> shows that it should have access to the repo.
>>
>> On 25 March 2016 at 22:47, Teo Klestrup Röijezon  wrote:
>>
>>> Did that for both hydra and hydra-queue-runner, no luck. :/
>>>
>>> On 25 March 2016 at 21:29, Oliver Charles  wrote:
>>>
 I've had luck just doing `sudo -u hydra -i` on the Hydra machine and
 setting up id_rsa and friends in ~/.ssh. I think the full path is
 /var/lib/hydra/.ssh.

 On Fri, Mar 25, 2016 at 3:19 PM Teo Klestrup Röijezon 
 wrote:

> Hi,
>
> Is there any support for setting up Hydra jobs with private git
> repositories as build inputs? I generated a SSH keypair each for hydra and
> hydra-queue-runner, and added them both as deploy keys on Bitbucket, but
> the authentication still seems to fail.
> This was using Hydra 32fa3921463cd7688b6b61602cfc707f406b46ae and
> Nixpkgs 90330c27cd62bd009f0973b92c13af6cfddbca19.
>
> Thanks,
> Teo
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>

>>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra jobs from private git repositories

[Domen Kožar]

See https://github.com/peti/hydra-tutorial/issues/2

On Fri, Mar 25, 2016 at 9:48 PM, Teo Klestrup Röijezon 
wrote:

> For the record, it says something about host key verification failing. If
> I try to run `ssh g...@bitbucket.org` sudoed as either user it works and
> shows that it should have access to the repo.
>
> On 25 March 2016 at 22:47, Teo Klestrup Röijezon  wrote:
>
>> Did that for both hydra and hydra-queue-runner, no luck. :/
>>
>> On 25 March 2016 at 21:29, Oliver Charles  wrote:
>>
>>> I've had luck just doing `sudo -u hydra -i` on the Hydra machine and
>>> setting up id_rsa and friends in ~/.ssh. I think the full path is
>>> /var/lib/hydra/.ssh.
>>>
>>> On Fri, Mar 25, 2016 at 3:19 PM Teo Klestrup Röijezon 
>>> wrote:
>>>
 Hi,

 Is there any support for setting up Hydra jobs with private git
 repositories as build inputs? I generated a SSH keypair each for hydra and
 hydra-queue-runner, and added them both as deploy keys on Bitbucket, but
 the authentication still seems to fail.
 This was using Hydra 32fa3921463cd7688b6b61602cfc707f406b46ae and
 Nixpkgs 90330c27cd62bd009f0973b92c13af6cfddbca19.

 Thanks,
 Teo
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

>>>
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra jobs from private git repositories

[Teo Klestrup Röijezon]

For the record, it says something about host key verification failing. If I
try to run `ssh g...@bitbucket.org` sudoed as either user it works and shows
that it should have access to the repo.

On 25 March 2016 at 22:47, Teo Klestrup Röijezon  wrote:

> Did that for both hydra and hydra-queue-runner, no luck. :/
>
> On 25 March 2016 at 21:29, Oliver Charles  wrote:
>
>> I've had luck just doing `sudo -u hydra -i` on the Hydra machine and
>> setting up id_rsa and friends in ~/.ssh. I think the full path is
>> /var/lib/hydra/.ssh.
>>
>> On Fri, Mar 25, 2016 at 3:19 PM Teo Klestrup Röijezon 
>> wrote:
>>
>>> Hi,
>>>
>>> Is there any support for setting up Hydra jobs with private git
>>> repositories as build inputs? I generated a SSH keypair each for hydra and
>>> hydra-queue-runner, and added them both as deploy keys on Bitbucket, but
>>> the authentication still seems to fail.
>>> This was using Hydra 32fa3921463cd7688b6b61602cfc707f406b46ae and
>>> Nixpkgs 90330c27cd62bd009f0973b92c13af6cfddbca19.
>>>
>>> Thanks,
>>> Teo
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra jobs from private git repositories

[Teo Klestrup Röijezon]

Did that for both hydra and hydra-queue-runner, no luck. :/

On 25 March 2016 at 21:29, Oliver Charles  wrote:

> I've had luck just doing `sudo -u hydra -i` on the Hydra machine and
> setting up id_rsa and friends in ~/.ssh. I think the full path is
> /var/lib/hydra/.ssh.
>
> On Fri, Mar 25, 2016 at 3:19 PM Teo Klestrup Röijezon 
> wrote:
>
>> Hi,
>>
>> Is there any support for setting up Hydra jobs with private git
>> repositories as build inputs? I generated a SSH keypair each for hydra and
>> hydra-queue-runner, and added them both as deploy keys on Bitbucket, but
>> the authentication still seems to fail.
>> This was using Hydra 32fa3921463cd7688b6b61602cfc707f406b46ae and Nixpkgs
>> 90330c27cd62bd009f0973b92c13af6cfddbca19.
>>
>> Thanks,
>> Teo
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra jobs from private git repositories

[Oliver Charles]

I've had luck just doing `sudo -u hydra -i` on the Hydra machine and
setting up id_rsa and friends in ~/.ssh. I think the full path is
/var/lib/hydra/.ssh.

On Fri, Mar 25, 2016 at 3:19 PM Teo Klestrup Röijezon 
wrote:

> Hi,
>
> Is there any support for setting up Hydra jobs with private git
> repositories as build inputs? I generated a SSH keypair each for hydra and
> hydra-queue-runner, and added them both as deploy keys on Bitbucket, but
> the authentication still seems to fail.
> This was using Hydra 32fa3921463cd7688b6b61602cfc707f406b46ae and Nixpkgs
> 90330c27cd62bd009f0973b92c13af6cfddbca19.
>
> Thanks,
> Teo
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra jobs from private git repositories

[Teo Klestrup Röijezon]

Hi,

Is there any support for setting up Hydra jobs with private git
repositories as build inputs? I generated a SSH keypair each for hydra and
hydra-queue-runner, and added them both as deploy keys on Bitbucket, but
the authentication still seems to fail.
This was using Hydra 32fa3921463cd7688b6b61602cfc707f406b46ae and Nixpkgs
90330c27cd62bd009f0973b92c13af6cfddbca19.

Thanks,
Teo
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] hydra on ubuntu

[Tobias Pflug]

Hi,

Is anyone successfully running hydra on ubuntu? If so, could you provide me 
with some info/help on setting it up?

In my current setup using NixOS in production is sadly not an option so I am 
trying to figure out if running hydra on ubuntu is feasible at all. 

My googling only unveiled an outdated inaccurate wiki page about hydra on 
ubuntu.

Any help is appreciated.

Best regards,
Tobi
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra / Builder stability

[Christian Theune]

Hi,

ah, well. So I might try reducing the parallel build load on that machine and 
should see things improve, right?

> On 02 Mar 2016, at 13:07, Eelco Dolstra  wrote:
> 
> Hi,
> 
> On 02/03/16 08:32, Christian Theune wrote:
> 
>> the Hydra server I run frequently has issues completing its jobs correctly. 
>> It
>> usually fails with weird issues but is fine when restarting. Here’s an 
>> example:
>> https://hydra.flyingcircus.io/build/1623/nixlog/2/raw
> 
> Looks like you restarted it so I can't see the error. But yeah, the QEMU tests
> tend to be timing-sensitive, which especially is a problem if the host machine
> is heavily loaded. (E.g. udevd might have an N second timeout which wouldn't
> trigger under real world conditions, but might in the VM if it's slow enough.)
> We should definitely try to fix these, but some are hard to fix because 
> they're
> kernel or QEMU issues.

Definitely sounds like it. I’d be happy to gather logs and upload them to the 
issue tracker if that helps.

Christian

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra / Builder stability

[Eelco Dolstra]

Hi,

On 02/03/16 08:32, Christian Theune wrote:

> the Hydra server I run frequently has issues completing its jobs correctly. It
> usually fails with weird issues but is fine when restarting. Here’s an 
> example:
> https://hydra.flyingcircus.io/build/1623/nixlog/2/raw

Looks like you restarted it so I can't see the error. But yeah, the QEMU tests
tend to be timing-sensitive, which especially is a problem if the host machine
is heavily loaded. (E.g. udevd might have an N second timeout which wouldn't
trigger under real world conditions, but might in the VM if it's slow enough.)
We should definitely try to fix these, but some are hard to fix because they're
kernel or QEMU issues.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra / Builder stability

[Christian Theune]

Hi,

the Hydra server I run frequently has issues completing its jobs correctly. It 
usually fails with weird issues but is fine when restarting. Here’s an example:
https://hydra.flyingcircus.io/build/1623/nixlog/2/raw 


I also had the situation before where the container mechanisms were kinda 
screwed and I had to reboot the box. I guess this isn’t intentional. :)

This is probably a question to @edolstra: should I be reporting those kinds of 
issues in the bug tracker? Is this something we need to take care of 
continuously and incrementally or is it likely that my setup is screwed in some 
fundamental way?

Christian

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra builds for Mac OS X

[Christian Theune]

Hi,

> On 05 Jan 2016, at 00:17, Daniel Peebles  wrote:
> 
> They're so fast that they emptied the queue immediately! :)

Haha :) —  I didn’t quite believe that when looking at the total job numbers of 
the machines earlier.

I also saw that there were a few darwin jobs but they didn’t get processed. Did 
you clean out the queue when adding them?

Cheers,
Christian

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra builds for Mac OS X

[Daniel Peebles]

They're so fast that they emptied the queue immediately! :)

On Mon, Jan 4, 2016 at 4:02 PM, Christian Theune  wrote:

> Sweet!
>
> Although I’m surprised that the Mac OS X queue is empty right now =)
>
> Christian
>
> On 04 Jan 2016, at 19:40, Rob Vermaas  wrote:
>
> Hi,
>
> Lately the queue on hydra.nixos.org has been pretty full, mostly with
> Mac OS X related builds. To start the new year off with a bang, we
> have sextupled the build capacity for Mac OS X (x86_64-darwin), we
> have gone from 2 cores to 12 cores!
>
> This expansion was made possible by Dan Peebles, Snabb.co
> , LogicBlox
> and all other people that have donated to the NixOS Foundation! You
> guys are awesome!
>
> Let's make 2016 the year that Nix/Nixpkgs takes over the Mac OS X world!
>
> Cheers,
> --
> Rob Vermaas
>
> [email] rob.verm...@gmail.com
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
> --
> Christian Theune · c...@flyingcircus.io · +49 345 219401 0
> Flying Circus Internet Operations GmbH · http://flyingcircus.io
> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
> HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian.
> Zagrodnick
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra builds for Mac OS X

[Christian Theune]

Sweet!

Although I’m surprised that the Mac OS X queue is empty right now =)

Christian

> On 04 Jan 2016, at 19:40, Rob Vermaas  wrote:
> 
> Hi,
> 
> Lately the queue on hydra.nixos.org has been pretty full, mostly with
> Mac OS X related builds. To start the new year off with a bang, we
> have sextupled the build capacity for Mac OS X (x86_64-darwin), we
> have gone from 2 cores to 12 cores!
> 
> This expansion was made possible by Dan Peebles, Snabb.co, LogicBlox
> and all other people that have donated to the NixOS Foundation! You
> guys are awesome!
> 
> Let's make 2016 the year that Nix/Nixpkgs takes over the Mac OS X world!
> 
> Cheers,
> --
> Rob Vermaas
> 
> [email] rob.verm...@gmail.com
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

--
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra builds for Mac OS X

[Rob Vermaas]

Hi,

Lately the queue on hydra.nixos.org has been pretty full, mostly with
Mac OS X related builds. To start the new year off with a bang, we
have sextupled the build capacity for Mac OS X (x86_64-darwin), we
have gone from 2 cores to 12 cores!

This expansion was made possible by Dan Peebles, Snabb.co, LogicBlox
and all other people that have donated to the NixOS Foundation! You
guys are awesome!

Let's make 2016 the year that Nix/Nixpkgs takes over the Mac OS X world!

Cheers,
-- 
Rob Vermaas

[email] rob.verm...@gmail.com
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra admins: ssh key change in a build slave

[Eelco Dolstra]

Hi,

On 07/11/15 08:28, Vladimír Čunát wrote:

> a notice in case you haven't seen/fixed it yet: ~21h ago we got some
> abortions due to 52.30.94.163 changing ssh key (likely due to NixOS
> update ;-). http://hydra.nixos.org/build/27399440

This was actually caused by hydra-provisioner not handling the disappearance of
an EC2 spot instance gracefully and getting stuck. I've fixed that. However, now
we have a disk full on lucifer so we're not out of trouble yet :-)

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hydra admins: ssh key change in a build slave

[Vladimír Čunát]

Hi,
a notice in case you haven't seen/fixed it yet: ~21h ago we got some
abortions due to 52.30.94.163 changing ssh key (likely due to NixOS
update ;-). http://hydra.nixos.org/build/27399440

Vladimir



smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra build failures

[Christian Theune]

> On 14 Oct 2015, at 13:32, Vladimír Čunát  wrote:
> 
> On 10/14/2015 01:24 PM, Eelco Dolstra wrote:
>> Well, it's important to note that Hydra *is* unreleased software - it exists 
>> to
>> do continuous builds for nixos.org, and I can't really make any claims about 
>> its
>> suitability for any other purpose.
> 
> I was actually surprised that I did meet people recently who were
> primarily interested in Hydra and planning to use it for CI of some
> company stuff.

:)

We’re using it for customized builds of NixOS. And I’ll be happy to contribute 
once I get more of a handle there. :)

Christian

—
Christian Theune · c...@flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra build failures

[Vladimír Čunát]

On 10/14/2015 01:24 PM, Eelco Dolstra wrote:
> Well, it's important to note that Hydra *is* unreleased software - it exists 
> to
> do continuous builds for nixos.org, and I can't really make any claims about 
> its
> suitability for any other purpose.

I was actually surprised that I did meet people recently who were
primarily interested in Hydra and planning to use it for CI of some
company stuff.


Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra build failures

[Domen Kožar]

Thanks. There are various companies/people using it in the wild, I see no
reason why we couldn't release an alpha, just so people can install it
successfully.



On Wed, Oct 14, 2015 at 1:24 PM, Eelco Dolstra 
wrote:

> Hi,
>
> On 14/10/15 13:01, Domen Kožar wrote:
>
> > It's really sad to me that we have Nix as a core tool to solve packaging
> > problems and then we don't even release hydra and claim minimum versions
> > required for it's dependencies.
>
> Well, it's important to note that Hydra *is* unreleased software - it
> exists to
> do continuous builds for nixos.org, and I can't really make any claims
> about its
> suitability for any other purpose.
>
> However, I've added a version check to Hydra's release.nix to catch
> Christian's
> problem.
>
> --
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev