Re: [Nix-dev] monitor.nixos.org

[zimbatm]

Thanks, makes sense. Let's do this!

On Thu, 1 Dec 2016, 23:39 Rok Garbas,  wrote:

> > Are we always updating to the latest version? For example on a release
> > branch we might want to pin to a major.minor if the project follows
> semver,
> > but maybe on master we always want the latest version.
> >
>
> The maintainer who writes nix expression for the package also decides
> which version update script will follow.
>
> > How do we iterate over all the packages? Do we regularly run all the
> update
> > scripts? Are the updates directly pushed to master or are new PR
> > automatically created?
> >
>
> Initially updates will happen as now, done manually by the
> maintainers. The only this that changes is that maintainers will be
> asked/required to write an update script that and to use that update
> script.
>
> Later we can see how we can hook this script in Hydra/CI, but we first
> need to have some update scripts :)
>
>
> > Let's say the convention is that derivations exposes an "updater"
> passthru.
> > Does it mean that all the derivations need to be updated or can we
> magically
> > support all github projects?
> >
>
> I wouldn't magically support all github projects, but rather provide
> update script one by one. As we go along adding an update which follow
> a branch might look like:
>
> https://github.com/mozilla-releng/services/blob/master/nix/tools/default.nix#L10
>
> > I still think that some of this need to be tried out so we might as well
> > adopt garbas' approach for now but it would be nice to have a clearer
> > picture as well.
> >
>
> The PR I created (https://github.com/NixOS/nixpkgs/pull/20844) leaves
> all the door open for improvement, but brings us just a step closer to
> the future where we could easily manage 1000x more packages then we do
> now.
>
>
>
> -- Rok
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] monitor.nixos.org

[Rok Garbas]

> Are we always updating to the latest version? For example on a release
> branch we might want to pin to a major.minor if the project follows semver,
> but maybe on master we always want the latest version.
>

The maintainer who writes nix expression for the package also decides
which version update script will follow.

> How do we iterate over all the packages? Do we regularly run all the update
> scripts? Are the updates directly pushed to master or are new PR
> automatically created?
>

Initially updates will happen as now, done manually by the
maintainers. The only this that changes is that maintainers will be
asked/required to write an update script that and to use that update
script.

Later we can see how we can hook this script in Hydra/CI, but we first
need to have some update scripts :)


> Let's say the convention is that derivations exposes an "updater" passthru.
> Does it mean that all the derivations need to be updated or can we magically
> support all github projects?
>

I wouldn't magically support all github projects, but rather provide
update script one by one. As we go along adding an update which follow
a branch might look like:
https://github.com/mozilla-releng/services/blob/master/nix/tools/default.nix#L10

> I still think that some of this need to be tried out so we might as well
> adopt garbas' approach for now but it would be nice to have a clearer
> picture as well.
>

The PR I created (https://github.com/NixOS/nixpkgs/pull/20844) leaves
all the door open for improvement, but brings us just a step closer to
the future where we could easily manage 1000x more packages then we do
now.



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

Re: [Nix-dev] monitor.nixos.org

[zimbatm]

Yeah but I'm still wondering how that would work in the context of nixpkgs.

Are we always updating to the latest version? For example on a release
branch we might want to pin to a major.minor if the project follows semver,
but maybe on master we always want the latest version.

How do we iterate over all the packages? Do we regularly run all the update
scripts? Are the updates directly pushed to master or are new PR
automatically created?

Let's say the convention is that derivations exposes an "updater" passthru.
Does it mean that all the derivations need to be updated or can we
magically support all github projects?

I still think that some of this need to be tried out so we might as well
adopt garbas' approach for now but it would be nice to have a clearer
picture as well.

On Thu, 1 Dec 2016, 03:13 Tomasz Czyż,  wrote:

> zimbatm: I don't think you need that branch selection thing. All the
> custom logic you want for that package you can put in the update script and
> you can even parametrize it from the outside I assume (update script
> generated by nix expression). That should be enough to do whatever custom
> logic you want.
>
> 2016-11-29 15:05 GMT+00:00 Profpatsch :
>
> On 16-11-28 11:05pm, Rok Garbas wrote:
> > On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch  wrote:
> > > Exactly.
> > > And of course the interface of what the script at this point should do.
> >
> > We don't need to define what that update script should do, since a
> > maintainer of that package also makes sure that generated files
> > (json/nix/...) that this update script provides will be read by the
> > package expression.
>
> In order for CI to check for updates there needs to be a standard
> way to call these update scripts. And more than that, a standard
> behaviour of these update scripts. I expect CI to completely sandbox
> them.
> Maybe even go so far as to loosen the “fixed input” rule only a tiny
> bit, meaning the update scripts have to specify exactly what state
> they are going to inspect to find new versions.
>
> > I think Nix has the advantage here actually. A maintainer can write an
> > update script in any language that he is most comfortable with. On the
> > end they have to support it etc... BUT everybody can run the update
> > without knowing that this is a ruby script since ``nix-shell``
> > provides all the needed dependencies for us.
>
> As long as updates always behave the same. And don’t rm -rf your $HOME …
> I’ve had enough untrusted source code run for two lifetimes.
>
> > So on the end we really need to just figure out the name ;) and start
> > writing update scripts. Even if they are full of regex :P
>
> If there is no interface, I’d rather not even have a fix name, or people
> will think updates are specified somehow. Maybe even go the other way
> and reserve the name until someone figures out a nice way to do this.
>
> --
> 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
>
>
>
>
> --
> Tomasz Czyż
> ___
> 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] monitor.nixos.org

[Rok Garbas]

i created a PR with an a one updateScript example for firefox-bin
https://github.com/NixOS/nixpkgs/pull/20844

I'd love to hear what you think.

On Thu, Dec 1, 2016 at 3:13 AM, Tomasz Czyż  wrote:
> zimbatm: I don't think you need that branch selection thing. All the custom
> logic you want for that package you can put in the update script and you can
> even parametrize it from the outside I assume (update script generated by
> nix expression). That should be enough to do whatever custom logic you want.
>
>
> 2016-11-29 15:05 GMT+00:00 Profpatsch :
>>
>> On 16-11-28 11:05pm, Rok Garbas wrote:
>> > On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch  wrote:
>> > > Exactly.
>> > > And of course the interface of what the script at this point should
>> > > do.
>> >
>> > We don't need to define what that update script should do, since a
>> > maintainer of that package also makes sure that generated files
>> > (json/nix/...) that this update script provides will be read by the
>> > package expression.
>>
>> In order for CI to check for updates there needs to be a standard
>> way to call these update scripts. And more than that, a standard
>> behaviour of these update scripts. I expect CI to completely sandbox
>> them.
>> Maybe even go so far as to loosen the “fixed input” rule only a tiny
>> bit, meaning the update scripts have to specify exactly what state
>> they are going to inspect to find new versions.
>>
>> > I think Nix has the advantage here actually. A maintainer can write an
>> > update script in any language that he is most comfortable with. On the
>> > end they have to support it etc... BUT everybody can run the update
>> > without knowing that this is a ruby script since ``nix-shell``
>> > provides all the needed dependencies for us.
>>
>> As long as updates always behave the same. And don’t rm -rf your $HOME …
>> I’ve had enough untrusted source code run for two lifetimes.
>>
>> > So on the end we really need to just figure out the name ;) and start
>> > writing update scripts. Even if they are full of regex :P
>>
>> If there is no interface, I’d rather not even have a fix name, or people
>> will think updates are specified somehow. Maybe even go the other way
>> and reserve the name until someone figures out a nice way to do this.
>>
>> --
>> 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
>
>
>
>
> --
> Tomasz Czyż



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

Re: [Nix-dev] monitor.nixos.org

[Tomasz Czyż]

zimbatm: I don't think you need that branch selection thing. All the custom
logic you want for that package you can put in the update script and you
can even parametrize it from the outside I assume (update script generated
by nix expression). That should be enough to do whatever custom logic you
want.

2016-11-29 15:05 GMT+00:00 Profpatsch :

> On 16-11-28 11:05pm, Rok Garbas wrote:
> > On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch  wrote:
> > > Exactly.
> > > And of course the interface of what the script at this point should do.
> >
> > We don't need to define what that update script should do, since a
> > maintainer of that package also makes sure that generated files
> > (json/nix/...) that this update script provides will be read by the
> > package expression.
>
> In order for CI to check for updates there needs to be a standard
> way to call these update scripts. And more than that, a standard
> behaviour of these update scripts. I expect CI to completely sandbox
> them.
> Maybe even go so far as to loosen the “fixed input” rule only a tiny
> bit, meaning the update scripts have to specify exactly what state
> they are going to inspect to find new versions.
>
> > I think Nix has the advantage here actually. A maintainer can write an
> > update script in any language that he is most comfortable with. On the
> > end they have to support it etc... BUT everybody can run the update
> > without knowing that this is a ruby script since ``nix-shell``
> > provides all the needed dependencies for us.
>
> As long as updates always behave the same. And don’t rm -rf your $HOME …
> I’ve had enough untrusted source code run for two lifetimes.
>
> > So on the end we really need to just figure out the name ;) and start
> > writing update scripts. Even if they are full of regex :P
>
> If there is no interface, I’d rather not even have a fix name, or people
> will think updates are specified somehow. Maybe even go the other way
> and reserve the name until someone figures out a nice way to do this.
>
> --
> 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
>



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

Re: [Nix-dev] monitor.nixos.org

[Profpatsch]

On 16-11-28 11:05pm, Rok Garbas wrote:
> On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch  wrote:
> > Exactly.
> > And of course the interface of what the script at this point should do.
> 
> We don't need to define what that update script should do, since a
> maintainer of that package also makes sure that generated files
> (json/nix/...) that this update script provides will be read by the
> package expression.

In order for CI to check for updates there needs to be a standard
way to call these update scripts. And more than that, a standard
behaviour of these update scripts. I expect CI to completely sandbox
them.
Maybe even go so far as to loosen the “fixed input” rule only a tiny
bit, meaning the update scripts have to specify exactly what state
they are going to inspect to find new versions.

> I think Nix has the advantage here actually. A maintainer can write an
> update script in any language that he is most comfortable with. On the
> end they have to support it etc... BUT everybody can run the update
> without knowing that this is a ruby script since ``nix-shell``
> provides all the needed dependencies for us.

As long as updates always behave the same. And don’t rm -rf your $HOME …
I’ve had enough untrusted source code run for two lifetimes.

> So on the end we really need to just figure out the name ;) and start
> writing update scripts. Even if they are full of regex :P

If there is no interface, I’d rather not even have a fix name, or people
will think updates are specified somehow. Maybe even go the other way
and reserve the name until someone figures out a nice way to do this.

-- 
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] monitor.nixos.org

[Rok Garbas]

On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch  wrote:
> On 16-11-28 03:11pm, Rok Garbas wrote:
>> On Mon, Nov 28, 2016 at 2:37 PM, Bjørn Forsman  
>> wrote:
>> To start this we _only_ need to agree how we call this passthru
>> attribute :) ... update, updateSrc, refresh, refreshSrc, nextVersion,
>> ...
>
> Exactly.
> And of course the interface of what the script at this point should do.
>
> I’m not sure how to apply the changes to the source files in a sane way.
> No, regex replacement is definitely *not* a sane way.
> To be fair, the lisp guys have an advantage of about half a century
> with source code modification.
>

We don't need to define what that update script should do, since a
maintainer of that package also makes sure that generated files
(json/nix/...) that this update script provides will be read by the
package expression.

Now even if update script does some weird regex etc... and fails also
the build afterwards will fail and we don't merge the updated files.

I think Nix has the advantage here actually. A maintainer can write an
update script in any language that he is most comfortable with. On the
end they have to support it etc... BUT everybody can run the update
without knowing that this is a ruby script since ``nix-shell``
provides all the needed dependencies for us.

here are two examples:
 - update script stores a json and that json is passed to fetchFromGitHub
   
https://github.com/mozilla-releng/services/blob/master/nix/tools/default.nix#L66
 - update script generated nix files (pypi2nix, go2nix, cabal2nix, ...)
   
https://github.com/mozilla-releng/services/blob/master/nix/tools/default.nix#L18

and this is the main entry script which i use to run multiple update commands
https://github.com/mozilla-releng/services/blob/master/nix/update.nix
 - to run update on one package ->nix-shell nix/update.nix --argstr
pkg releng_docs
 - to run updates on all packages -> nix-shell nix/update.nix

So on the end we really need to just figure out the name ;) and start
writing update scripts. Even if they are full of regex :P


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

Re: [Nix-dev] monitor.nixos.org

[Profpatsch]

On 16-11-28 03:11pm, Rok Garbas wrote:
> On Mon, Nov 28, 2016 at 2:37 PM, Bjørn Forsman  
> wrote:
> To start this we _only_ need to agree how we call this passthru
> attribute :) ... update, updateSrc, refresh, refreshSrc, nextVersion,
> ...

Exactly.
And of course the interface of what the script at this point should do.

I’m not sure how to apply the changes to the source files in a sane way.
No, regex replacement is definitely *not* a sane way.
To be fair, the lisp guys have an advantage of about half a century
with source code modification.

> Anyway I'm currently managing many projects like this which would be
> impossible to do if i wouldn't automate this.

Exactly.

-- 
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] monitor.nixos.org

[Profpatsch]

On 16-11-28 05:04pm, phree...@yandex.ru wrote:
> On Monday, November 28, 2016 13:32:16 Tomasz Czyż wrote:
> > 2016-11-28 13:18 GMT+00:00 Profpatsch :
> > debian has such a strategy:
> > - https://wiki.debian.org/debian/watch
> 
> That happens to not work all that well:
> https://github.com/Phreedom/nixpkgs-monitor/blob/master/debian-watchfiles/watchfiles.md
> 
> It turns out that debian watchfiles were much less reliable at getting 
> updates 
> from SourceForge, than a generic SourceForge updater. This is because naming 
> schemes change, devs forget to update the updater script and lots of other 
> tiny but important reasons.

Since we have a unified packageset written in a turing-complete language
we can do a lot better. e.g. lib.updaters.updateSourceForge

-- 
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] monitor.nixos.org

[Profpatsch]

On 16-11-28 01:32pm, Tomasz Czyż wrote:
> debian has such a strategy:
> - https://wiki.debian.org/debian/watch
> -
> https://github.com/FedericoCeratto/debian-package-init/blob/master/deb_create_watch.py
> 
> I think better place to execute this would be in CI pipeline, when you can
> decide if after upgrading the package you are still able to build the
> project.

Yes, of course it would have to be integrated in the CI pipeline.

> Also, I'm not sure if automatic upgrades would be that great without manual
> verification. There are cases when packages have no signatures and somebody
> switched the code on the website (this happens from time to time).

Depends. In combination with working acceptance/integration tests
this could be completely automated, save for the maintainer clicking
merge. I have a working testing infrastructure in the pipeline,
once I push it the basic building blocks will be in place.

> Also I had an idea that would be nice to integrate this update command into
> "meta" of derivation. What do you think?

The point is defining an interface that CI can then use to provide
automation. That is mainly defining an attribute and what success
and failure mean.

Basic idea:
meta.update (or maybe just passthru.update, not sure yet) is a
shell script that returns 0 on success and prints an attributeset
to stdout that can be merged with the source somehow. On failure
various exit codes are defined, like 1=no_change 2=not_found e.g.

Next problem: Automatic application would require basic nix expr
source introspection (as long as it’s not tried with regex)

-- 
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] monitor.nixos.org

[Tomasz Czyż]

Nice research, thanks for providing a link.



2016-11-28 15:04 GMT+00:00 :

> On Monday, November 28, 2016 13:32:16 Tomasz Czyż wrote:
> > 2016-11-28 13:18 GMT+00:00 Profpatsch :
> > > On 16-11-12 06:39pm, Rok Garbas wrote:
> > > > On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
> > > > I wrote recently[1] how we tackle this problem at RelEng team at
> > > > Mozilla. I'm slowly moving all my nix projects to do the same. I will
> > > > also do the same for the packages I manage in nixpkgs at least that
> is
> > > > what I will write to Santa this year, to give me more time to play
> > > > work on nixpkgs :)
> > > >
> > > >
> > > > [1] https://garbas.si/2016/updating-your-nix-sources.html
> > >
> > > So you had a very similar idea about update scripts.
> > >
> > > We should chat about that; I think there should be a system
> > > in place for derivations to specify how the next version can
> > > be found and if possible how to automatically update the version
> > > tags & hashes.
> >
> > debian has such a strategy:
> > - https://wiki.debian.org/debian/watch
>
> That happens to not work all that well:
> https://github.com/Phreedom/nixpkgs-monitor/blob/master/
> debian-watchfiles/watchfiles.md
>
> It turns out that debian watchfiles were much less reliable at getting
> updates
> from SourceForge, than a generic SourceForge updater. This is because
> naming
> schemes change, devs forget to update the updater script and lots of other
> tiny but important reasons.
>
> In practice, having developers maintain package-specific update scripts is
> just
> as hard if not harder than maintaining the package itself.
>
> This is why the strategy chosen for nixpkgs-monitor was to develop updaters
> that can tackle at least hundreds of packages.
>
> -- Evgeny
> ___
> 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] monitor.nixos.org

[phreedom]

On Monday, November 28, 2016 13:32:16 Tomasz Czyż wrote:
> 2016-11-28 13:18 GMT+00:00 Profpatsch :
> > On 16-11-12 06:39pm, Rok Garbas wrote:
> > > On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
> > > I wrote recently[1] how we tackle this problem at RelEng team at
> > > Mozilla. I'm slowly moving all my nix projects to do the same. I will
> > > also do the same for the packages I manage in nixpkgs at least that is
> > > what I will write to Santa this year, to give me more time to play
> > > work on nixpkgs :)
> > > 
> > > 
> > > [1] https://garbas.si/2016/updating-your-nix-sources.html
> > 
> > So you had a very similar idea about update scripts.
> > 
> > We should chat about that; I think there should be a system
> > in place for derivations to specify how the next version can
> > be found and if possible how to automatically update the version
> > tags & hashes.
> 
> debian has such a strategy:
> - https://wiki.debian.org/debian/watch

That happens to not work all that well:
https://github.com/Phreedom/nixpkgs-monitor/blob/master/debian-watchfiles/watchfiles.md

It turns out that debian watchfiles were much less reliable at getting updates 
from SourceForge, than a generic SourceForge updater. This is because naming 
schemes change, devs forget to update the updater script and lots of other 
tiny but important reasons.

In practice, having developers maintain package-specific update scripts is just 
as hard if not harder than maintaining the package itself.

This is why the strategy chosen for nixpkgs-monitor was to develop updaters 
that can tackle at least hundreds of packages.

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

Re: [Nix-dev] monitor.nixos.org

[Tomasz Czyż]

2016-11-28 13:18 GMT+00:00 Profpatsch :

> On 16-11-12 06:39pm, Rok Garbas wrote:
> > On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
> > I wrote recently[1] how we tackle this problem at RelEng team at
> > Mozilla. I'm slowly moving all my nix projects to do the same. I will
> > also do the same for the packages I manage in nixpkgs at least that is
> > what I will write to Santa this year, to give me more time to play
> > work on nixpkgs :)
> >
> >
> > [1] https://garbas.si/2016/updating-your-nix-sources.html
>
> So you had a very similar idea about update scripts.
>
> We should chat about that; I think there should be a system
> in place for derivations to specify how the next version can
> be found and if possible how to automatically update the version
> tags & hashes.
>
debian has such a strategy:
- https://wiki.debian.org/debian/watch
-
https://github.com/FedericoCeratto/debian-package-init/blob/master/deb_create_watch.py

I think better place to execute this would be in CI pipeline, when you can
decide if after upgrading the package you are still able to build the
project.

Also, I'm not sure if automatic upgrades would be that great without manual
verification. There are cases when packages have no signatures and somebody
switched the code on the website (this happens from time to time).

Probably topic worth discussing.

Maybe workflow like that could be a start point:

- monitor - checks if upgrades are possible
- CI/hydra
- checks if upgrades are possible
- if yes, tries to upgrade package and build it
- if package is built correctly, sends email to package maintainers
with a patch (or open pull request) and asks for verification.

Also I had an idea that would be nice to integrate this update command into
"meta" of derivation. What do you think?




>
> Those can obviously not be executed by nix itself, but by other
> systems like the nixos monitor.
>
> --
> 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
>



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

Re: [Nix-dev] monitor.nixos.org

[Profpatsch]

On 16-11-12 06:39pm, Rok Garbas wrote:
> On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
> I wrote recently[1] how we tackle this problem at RelEng team at
> Mozilla. I'm slowly moving all my nix projects to do the same. I will
> also do the same for the packages I manage in nixpkgs at least that is
> what I will write to Santa this year, to give me more time to play
> work on nixpkgs :)
> 
> 
> [1] https://garbas.si/2016/updating-your-nix-sources.html

So you had a very similar idea about update scripts.

We should chat about that; I think there should be a system
in place for derivations to specify how the next version can
be found and if possible how to automatically update the version
tags & hashes.

Those can obviously not be executed by nix itself, but by other
systems like the nixos monitor.

-- 
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] monitor.nixos.org

[Rok Garbas]

On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
 wrote:
> I didn't know about that website before. It looks vers useful, but 
> monitor.nixos.org seems to be outdated for about 5 months.
> It suggests [1] that I update mbuffer from version 20151002 to version 
> 20160228.
> On June 26th I already updated mbuffer to version 20160613. monitor.nixos.org 
> has not picked that up yet.
>
> [1] http://monitor.nixos.org/outdated?m=Daniel+Frank


I wrote recently[1] how we tackle this problem at RelEng team at
Mozilla. I'm slowly moving all my nix projects to do the same. I will
also do the same for the packages I manage in nixpkgs at least that is
what I will write to Santa this year, to give me more time to play
work on nixpkgs :)


[1] https://garbas.si/2016/updating-your-nix-sources.html



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

Re: [Nix-dev] [monitor.nixos.org]: Monitor generates patches where the subject does not fit the new scheme

[Kirill Elagin]

On Fri, Jun 26, 2015 at 8:02 PM Eelco Dolstra eelco.dols...@logicblox.com
wrote:

 BTW, this really should be in the Nixpkgs manual, not in some random
 markdown file.


Actually, the file is not random, it is the one that GitHub suggests to
review when someone opens an issue or a pull-request (and probably in other
situations, I’m not sure).
It should probably also go to the manual nevertheless, maybe as a link to
avoid maintatining the same things in two different places.

-- 
Кирилл Елагин
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [monitor.nixos.org]: Monitor generates patches where the subject does not fit the new scheme

[phreedom]

On Friday, June 26, 2015 16:55:43 Matthias Beyer wrote:
 Hi,
 
 just wanted to report this: monitor.nixos.org generates patches which
 do not fit the new scheme of how to name package update commits.
 
 Someone fix this please, as I'm developing a script[0] which uses
 monitor.nixos.org to generate commits and I want to develop it even
 further so one can auto-generate-and-build patches for N packages
 automatically.
 
 [0]: https://github.com/matthiasbeyer/nixos-scripts/pull/25

Assuming that you want to extract package name and new version strings, both 
the monitor's current scheme and the new scheme have a fairly similar 
structure. You could easily write a generic enough regexp  Or we can wait 
for Rob to go back since he holds the keys to the monitor's production 
instance

Btw, this could be useful for your script: 
http://stackoverflow.com/questions/2180270/check-if-current-directory-is-a-git-repository
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [monitor.nixos.org]: Monitor generates patches where the subject does not fit the new scheme

[Matthias Beyer]

On 27-06-2015 16:24:01, phree...@yandex.ru wrote:
 On Friday, June 26, 2015 16:55:43 Matthias Beyer wrote:
  Hi,
  
  just wanted to report this: monitor.nixos.org generates patches which
  do not fit the new scheme of how to name package update commits.
  
  Someone fix this please, as I'm developing a script[0] which uses
  monitor.nixos.org to generate commits and I want to develop it even
  further so one can auto-generate-and-build patches for N packages
  automatically.
  
  [0]: https://github.com/matthiasbeyer/nixos-scripts/pull/25
 
 Assuming that you want to extract package name and new version strings, both 
 the monitor's current scheme and the new scheme have a fairly similar 
 structure. You could easily write a generic enough regexp  Or we can wait 
 for Rob to go back since he holds the keys to the monitor's production 
 instance

Thanks for your reply, but I do not want to extract anything, I want
to use the patch as-is.

Anyways, thanks for your reply!

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

Proudly sent with mutt.
Happily signed with gnupg.


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

[Nix-dev] [monitor.nixos.org]: Monitor generates patches where the subject does not fit the new scheme

[Matthias Beyer]

Hi,

just wanted to report this: monitor.nixos.org generates patches which
do not fit the new scheme of how to name package update commits.

Someone fix this please, as I'm developing a script[0] which uses
monitor.nixos.org to generate commits and I want to develop it even
further so one can auto-generate-and-build patches for N packages
automatically.

[0]: https://github.com/matthiasbeyer/nixos-scripts/pull/25

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

Proudly sent with mutt.
Happily signed with gnupg.


pgp5U7rCAGTbw.pgp
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] [monitor.nixos.org]: Monitor generates patches where the subject does not fit the new scheme

[Pascal Wittmann]

On 06/26/2015 04:55 PM, Matthias Beyer wrote:
 just wanted to report this: monitor.nixos.org generates patches which
 do not fit the new scheme of how to name package update commits.

Maybe I missed something, but how does this new scheme looks like and
where was it announced?



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] [monitor.nixos.org]: Monitor generates patches where the subject does not fit the new scheme

[Matthias Beyer]

On 26-06-2015 17:01:03, Pascal Wittmann wrote:
 On 06/26/2015 04:55 PM, Matthias Beyer wrote:
  just wanted to report this: monitor.nixos.org generates patches which
  do not fit the new scheme of how to name package update commits.
 
 Maybe I missed something, but how does this new scheme looks like and
 where was it announced?
 

https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md


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

Proudly sent with mutt.
Happily signed with gnupg.


pgpDwWPUZA2cI.pgp
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] [monitor.nixos.org]: Monitor generates patches where the subject does not fit the new scheme

[Eelco Dolstra]

Hi,

On 26/06/15 17:30, Matthias Beyer wrote:

 just wanted to report this: monitor.nixos.org generates patches which
 do not fit the new scheme of how to name package update commits.

 Maybe I missed something, but how does this new scheme looks like and
 where was it announced?

 
 https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md

Who decided that scheme?

BTW, this really should be in the Nixpkgs manual, not in some random markdown 
file.

-- 
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