Re: [Nix-dev] Representation DevOpsDays Austin / Logo License?

[Profpatsch]

On 16-04-28 07:19pm, Vladimír Čunát wrote:
> Hi.
> 
> On 04/28/2016 05:54 PM, Graham Christensen wrote:
> > 1. Is there any promotional material I should pre-print / take with me /
> >whatever to pitch NixOS?
> 
> I'm fairly certain we don't have any official stuff like that.
> 
> > 3. What is the license of the logo files? Can I freely make stickers? I
> >was going to make some up for the conference, but I think I'll need
> >to demonstrate I'm allowed to.
> 
> TL;DR: you certainly can consider the logo as "free", but IMHO it will
> be hard to really demonstrate it. The original logo was taken by Eelco
> from among Haskell logo-contest non-winners, with author's permission
> (though I don't think there's ever been any legally clean
> license/permission). Several months ago we were discussing logo changes,
> and the work was done mainly by one of the community. Again, I don't
> think we were touching such "nitpicks" as licensing.

I think we should really clean that up and license as CC NoDerivatives
or similar.
Don’t know if BY makes sense, non-commercial certainly doesn’t.


-- 
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
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Why not use SONAME instead of RPATH

[Thomas Tuegel]

On Thu, Apr 28, 2016 at 1:45 PM, Vladimír Čunát  wrote:
> On 04/28/2016 08:20 PM, Александр Цамутали wrote:
>> Is it possible to apply this approach to binary packages?
>
> I don't think so, but that doesn't seem really relevant. The suggestion
> is to change what our compiler produces...

patchelf can do this, but only for shared libraries that are actually
linked. RPATH has the advantage of affecting dlopen() calls, too.

It makes me sad that I know this. :-(

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

Re: [Nix-dev] Why not use SONAME instead of RPATH

[Vladimír Čunát]

On 04/28/2016 08:20 PM, Александр Цамутали wrote:
> Is it possible to apply this approach to binary packages?

I don't think so, but that doesn't seem really relevant. The suggestion
is to change what our compiler produces...

--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] Why not use SONAME instead of RPATH

[Александр Цамутали]

Is it possible to apply this approach to binary packages?


--
Александр Цамутали

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

[Nix-dev] Representation DevOpsDays Austin / Logo License?

[Graham Christensen]

Hello Nixers,

I'll be attendending DevOpsDays Austin this year (May 2nd, 3rd in
Austin, TX) and I suppose I have a few questions.

1. Is there any promotional material I should pre-print / take with me /
   whatever to pitch NixOS?
2. Is there anyone else in the community in or near Austin, TX? Coming
   to DevOpsDays Austin? *
3. What is the license of the logo files? Can I freely make stickers? I
   was going to make some up for the conference, but I think I'll need
   to demonstrate I'm allowed to.

I'd also like to hear from anyone else who has represented Nix at
conferences for advice.

Thanks!
Graham Christensen

* If there are other of you in Austin, we should do a meetup!


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

Re: [Nix-dev] Help with PR: libuv update

[Rok Garbas]

i'm not that familiar with node ecosystem, but maybe we should have a
set of node packages per node version like we do with python, ruby,
etc...

On Thu, Apr 28, 2016 at 7:58 AM, Tobias Pflug  wrote:
> Hi,
>
> I am looking for some help with my PR which updates libuv to the most recent 
> version:
>
> https://github.com/NixOS/nixpkgs/pull/14973
>
> I want to introduce nodejs 6.0.0 which needs libuv 1.9.0 and I am blocked by 
> this. The PR will always fail with travis because nox-review needs too long. 
> I tried it locally where some (very outdated) nodejs packages will fail 
> during node-gyp build.
>
> I have already proposed that the various nodejs libraries that we maintain 
> should be removed and tools should be separate packages. I already started 
> with a PR that extracts npm2nix and more will follow.
>
> Would it thus be OK to go ahead and merge the libuv update? If not what is 
> the alternative?
>
> Thanks in advance.
> - Tobi
>
> Sent from my iPhone
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



-- 
Rok Garbas
http://www.garbas.si
r...@garbas.si
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Continuous Integration

[Domen Kožar]

That's a good point, but I don't see how a separate tab would contrain
hydra from adding extra input parameters to the eval. It's just a perl
"controller" for UI separation.

/cc aszlig

On Thu, Apr 28, 2016 at 11:37 AM,  wrote:

> IMO putting the logic completely into hydra will be too limiting. If hydra
> just gives a nix expression some info about the PRs, then the nix
> expression can do arbitrary things (e.g. only build PRs from trusted users,
> or that don't change stdenv, or whatever). If it's a jobset tab then you
> have to add every possible variation into the hydra UI.
>
>
>
> - Original Message -
> From:
> "Domen Kožar" 
>
> To:
> "Shea Levy" 
> Cc:
> "Graham Christensen" , "Ericson John" <
> john_eric...@brown.edu>, "nix-dev" 
> Sent:
> Thu, 28 Apr 2016 11:32:53 +0100
>
> Subject:
> Re: [Nix-dev] Continuous Integration
>
>
> I was talking to Aszlig about this and it would be best if PRs would be a
> tab on the jobset. Since jobset defines the inputs, it would be tested for
> PRs against that specific branch.
>
> On Thu, Apr 28, 2016 at 11:30 AM,  wrote:
>
>> It can set pull request statuses (e.g. see
>> https://github.com/shlevy/hydra-github-status-test/pull/3), but
>> currently you have to manually create the jobset corresponding to the PR
>> and ensure that the relevant jobs are captured by the status plugin.
>>
>> If https://github.com/NixOS/hydra/pull/277 is merged, then there is one
>> step left to get automatic PR management: An input plugin which fetches
>> information about open PRs on a repo. I'll write it if 277 ever gets in,
>> but without 277 or something like it there's no point.
>>
>>
>> - Original Message -
>> From:
>> "Graham Christensen" 
>>
>> To:
>> "Domen Kožar" 
>> Cc:
>> "Ericson John" , "nix-dev" <
>> nix-dev@lists.science.uu.nl>
>> Sent:
>> Wed, 27 Apr 2016 18:23:55 -0500
>> Subject:
>> Re: [Nix-dev] Continuous Integration
>>
>>
>>
>>
>>
>> Domen Kožar  writes:
>>
>> > It doesn't build PRs, just updates the status.
>> >
>>
>> Does this mean it can build specific branches (master, release-16.04..)
>> and set the commit status on those commits? ie: doesn't have anything to
>> do with pull request statuses?
>>
>> Best,
>> Graham
>> ___
>> 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] Continuous Integration

[shea]

IMO putting the logic completely into hydra will be too limiting. If
hydra just gives a nix expression some info about the PRs, then the
nix expression can do arbitrary things (e.g. only build PRs from
trusted users, or that don't change stdenv, or whatever). If it's a
jobset tab then you have to add every possible variation into the
hydra UI.

- Original Message -
From:
 "Domen Kožar" 

To:
"Shea Levy" 
Cc:
"Graham Christensen" , "Ericson John"
, "nix-dev" 
Sent:
Thu, 28 Apr 2016 11:32:53 +0100
Subject:
Re: [Nix-dev] Continuous Integration

I was talking to Aszlig about this and it would be best if PRs would
be a tab on the jobset. Since jobset defines the inputs, it would be
tested for PRs against that specific branch.

On Thu, Apr 28, 2016 at 11:30 AM, 
 wrote:
It can set pull request statuses (e.g.
see https://github.com/shlevy/hydra-github-status-test/pull/3 [2]),
but currently you have to manually create the jobset corresponding to
the PR and ensure that the relevant jobs are captured by the status
plugin.

If https://github.com/NixOS/hydra/pull/277 [3] is merged, then there
is one step left to get automatic PR management: An input plugin which
fetches information about open PRs on a repo. I'll write it if 277
ever gets in, but without 277 or something like it there's no point.

- Original Message -
From:
 "Graham Christensen" 

To:
"Domen Kožar" 
Cc:
"Ericson John" , "nix-dev"

Sent:
Wed, 27 Apr 2016 18:23:55 -0500
Subject:
Re: [Nix-dev] Continuous Integration

 Domen Kožar  writes:

 > It doesn't build PRs, just updates the status.
 >

 Does this mean it can build specific branches (master,
release-16.04..)
 and set the commit status on those commits? ie: doesn't have anything
to
 do with pull request statuses?

 Best,
 Graham

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

 

Links:
--
[1] mailto:s...@shealevy.com
[2] https://github.com/shlevy/hydra-github-status-test/pull/3
[3] https://github.com/NixOS/hydra/pull/277
[4] mailto:gra...@grahamc.com
[5] mailto:do...@dev.si
[6] mailto:john_eric...@brown.edu
[7] mailto:nix-dev@lists.science.uu.nl
[8] mailto:do...@dev.si
[9] mailto:nix-dev@lists.science.uu.nl
[10] 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] Continuous Integration

[Domen Kožar]

I was talking to Aszlig about this and it would be best if PRs would be a
tab on the jobset. Since jobset defines the inputs, it would be tested for
PRs against that specific branch.

On Thu, Apr 28, 2016 at 11:30 AM,  wrote:

> It can set pull request statuses (e.g. see
> https://github.com/shlevy/hydra-github-status-test/pull/3), but currently
> you have to manually create the jobset corresponding to the PR and ensure
> that the relevant jobs are captured by the status plugin.
>
> If https://github.com/NixOS/hydra/pull/277 is merged, then there is one
> step left to get automatic PR management: An input plugin which fetches
> information about open PRs on a repo. I'll write it if 277 ever gets in,
> but without 277 or something like it there's no point.
>
>
> - Original Message -
> From:
> "Graham Christensen" 
>
> To:
> "Domen Kožar" 
> Cc:
> "Ericson John" , "nix-dev" <
> nix-dev@lists.science.uu.nl>
> Sent:
> Wed, 27 Apr 2016 18:23:55 -0500
> Subject:
> Re: [Nix-dev] Continuous Integration
>
>
>
>
>
> Domen Kožar  writes:
>
> > It doesn't build PRs, just updates the status.
> >
>
> Does this mean it can build specific branches (master, release-16.04..)
> and set the commit status on those commits? ie: doesn't have anything to
> do with pull request statuses?
>
> Best,
> Graham
> ___
> 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] Continuous Integration

[shea]

It can set pull request statuses (e.g.
see https://github.com/shlevy/hydra-github-status-test/pull/3), but
currently you have to manually create the jobset corresponding to the
PR and ensure that the relevant jobs are captured by the status
plugin.

If https://github.com/NixOS/hydra/pull/277 is merged, then there is
one step left to get automatic PR management: An input plugin which
fetches information about open PRs on a repo. I'll write it if 277
ever gets in, but without 277 or something like it there's no point.

- Original Message -
From: "Graham Christensen" 
To:"Domen Kožar" 
Cc:"Ericson John" , "nix-dev"

Sent:Wed, 27 Apr 2016 18:23:55 -0500
Subject:Re: [Nix-dev] Continuous Integration

 Domen Kožar  writes:

 > It doesn't build PRs, just updates the status.
 >

 Does this mean it can build specific branches (master,
release-16.04..)
 and set the commit status on those commits? ie: doesn't have anything
to
 do with pull request statuses?

 Best,
 Graham
 ___
 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