Re: [Nix-dev] "Package archeology" in nixpkgs

Maybe a secondary git branch would be good to implement it. Em 31/08/2014 00:32, "Daniel Peebles" escreveu: > Hi all, > > I've had a sudden urge to do some Haskell archeology and that led me > to a question about how we feel "philosophically" about keeping > abandoned projects and old versions of

Re: [Nix-dev] processing: new package

Hi, how does this patch relate to pkgs/applications/graphics/processing? As it is now, the patch cannot be applied because both of these packages use the same attribute "processing" in all-packages.nix. Best regards, Peter ___ nix-dev mailing list nix

Re: [Nix-dev] processing: new package

Hi, It's the same package. I didn't notice the patch on the mailing list and added graphic/processing myself yesterday. ewemoa (on IRC) pointed out that it is useful to keep the processing_java script so I can incorporate that. Were there any other parts of your expression that you'd like to keep

Re: [Nix-dev] Keeping nixpkgs up to date

Speed of processing pull requests for new packages is an issue. Anything that can be done to reduce this would be helpful. It's demotivating as a contributor to do what seems to be a simple package update of a minor version and have the pull request take weeks. When I first started using NixOS the

Re: [Nix-dev] Keeping nixpkgs up to date

I have a problem with the pull requests... In github, if I'm not wrong, I can either receive all PRs by mail or none. Hence I unsubscribed. Thankfully, sometimes people do @viric on some packages. I wish I could accept a merge by replying the request letter, instead of clicking the web button. Re

Re: [Nix-dev] Keeping nixpkgs up to date

nixpkgs is a repository that holds maintainers with very different interests, some very narrow, with the common factor of nix/nixos. I really don't want to hear about updates to a very big percent of nixpkgs. :) In nixpkgs, 'meta.maintainers' was a way to get maintainers called upon some update i

Re: [Nix-dev] Keeping nixpkgs up to date

Would a script that checked all PRs if they contain a change to a file with maintainers. help? You could then regulary run that script or run it automatically to get notifications. -- Benno 2014-08-31 17:07 GMT+02:00 Lluís Batlle i Rossell : > nixpkgs is a repository that holds maintainers with

Re: [Nix-dev] Keeping nixpkgs up to date

On 08/31/2014 03:43 PM, Chris Double wrote: > Speed of processing pull requests for new packages is an issue. > Anything that can be done to reduce this would be helpful. It's > demotivating as a contributor to do what seems to be a simple package > update of a minor version and have the pull reque

Re: [Nix-dev] Keeping nixpkgs up to date

Humm I think that I commit to 14.04 any update I need, not waiting for Eelco approval. :) I talk about final program updates, not libraries that cause big rebuilds. I use to think that anything can be reverted, and then the revert has to be justified. That helps as to learn what to commit and what

[Nix-dev] Policy for updates in 14.04 (was: Keeping nixpkgs up to date)

Hi Chris, > > > Updating Tor on 14.04 to version 0.2.4.22 and Tor Browser to 3.6.2. > This has been sitting for two months. Since then a newer version of > Tor and Tor Browser has come out so it's already out of date. the stable release branch is

Re: [Nix-dev] Policy for updates in 14.04 (was: Keeping nixpkgs up to date)

Almost any software update will contain a bunch of bugfixes and only sometimes new features. And for lots of nixpkgs software, having the update in master, doesn't guarantee that it is much tested once it becomes stable. I'd prefer to have a less strict rule about updating the stable branch, and

Re: [Nix-dev] "Package archeology" in nixpkgs

On Sat, 30 Aug 2014 23:31:42 -0400 Daniel Peebles wrote: > I've had a sudden urge to do some Haskell archeology and that led me > to a question about how we feel "philosophically" about keeping > abandoned projects and old versions of live projects in nixpkgs. I think it's a very good idea, but

Re: [Nix-dev] "Package archeology" in nixpkgs

>> How do people feel about this? Is it something I should maintain >> independently of nixpkgs or does it belong in the main repo? > >... please keep it out of the main Nixpkgs, at least for now. Reason >is that currently Nix performance drops linearly with the number of >packages. Until we have

Re: [Nix-dev] Policy for updates in 14.04

Hi Lluís, > Almost any software update will contain a bunch of bugfixes and only > sometimes new features. can you point me to an empirical study that supports this thesis? > And for lots of nixpkgs software, having the update in master, > doesn't guarantee that it is much tested once it be

Re: [Nix-dev] Policy for updates in 14.04

On Sun, Aug 31, 2014 at 06:31:50PM +0200, Peter Simons wrote: > Hi Lluís, > > > Almost any software update will contain a bunch of bugfixes and only > > sometimes new features. > > can you point me to an empirical study that supports this thesis? I mean the impression I got from reading relea

[Nix-dev] [PATCH] Add an 'optimiseStore' RPC

Hi Eelco, The patch below adds an ‘optimiseStore’ RPC, and thus adds a mandatory ‘optimiseStore’ method in ‘StoreAPI’. OK to commit? Ludo’. diff --git a/src/libstore/local-store.hh b/src/libstore/local-store.hh index 09639e7..4404ffc 100644 --- a/src/libstore/local-store.hh +++ b/src/libstore/l

Re: [Nix-dev] "Package archeology" in nixpkgs

On 31 August 2014 18:27, Michael Raskin <7c6f4...@mail.ru> wrote: > I'd say, though, that only name-based operations drop in performance > that way… > > Although for some strange reason we still recommend this way of using > Nix. Nix newb asks: what would be the superiour alternative, then? Regar

Re: [Nix-dev] "Package archeology" in nixpkgs

>On 31 August 2014 18:27, Michael Raskin <7c6f4...@mail.ru> wrote: >> I'd say, though, that only name-based operations drop in performance >> that way… >> >> Although for some strange reason we still recommend this way of using >> Nix. > >Nix newb asks: what would be the superiour alternative, then

[Nix-dev] Packaging a tool that registers in crontab

Hi, I'm packaging backintime, a backup tool that registers itself in the crontab of the user. The tool can have several profiles : a profile is a set of files to backup, a backup destination and a period at which to backup. The tool registers in the crontab one line per profile. For example : $ c

[Nix-dev] Replicant sdk ?

I was wondering if anyone here ever mumbled about attempting to bring the Replicant Sdk in the packages collection. I took a look at the plain vanilla android sdk stuff and it's frightening Specifically I was wondering about patching the binaries with new rpaths and that kind of things. I don't

Re: [Nix-dev] Policy for updates in 14.04 (was: Keeping nixpkgs up to date)

On Mon, Sep 1, 2014 at 3:57 AM, Peter Simons wrote: > > the stable release branch is not supposed to have up-to-date software. > Its purpose is to provide a software environment that is *stable*. > Packages in the release branch should be modified only if the update > fixes an important bug, like

Re: [Nix-dev] Policy for updates in 14.04

Hi Chris, >> The purpose of [stable release branch] is to provide a software >> environment that is *stable*. Packages in the release branch should be >> modified only if the update fixes an important bug, like a security >> vulnerability. > > This seems a great policy when there are people

[Nix-dev] Will there be a systemd replacement at any time in the future?

Hi, I know that systemd is some kind of a basic thing which helps nixos to be what it is, but is there any chance that systemd will be replaced at any time in the future? Or not replaced, but will there be an alternative? This post (to this ML) says pretty much what I think about systemd and why

Re: [Nix-dev] Policy for updates in 14.04

Hi Lluís, >>> Almost any software update will contain a bunch of bugfixes and only >>> sometimes new features. >> >> can you point me to an empirical study that supports this thesis? > > I mean the impression I got from reading release notes of different > programs. For example: > https://

Re: [Nix-dev] Keeping nixpkgs up to date

Many other package systems are decentralised (Gems/Composer/PyPI/NPM). Why not make Nix packages decentralised? So that maintainers can maintain their own packages and update them at any time? This would speed up evolution of Nix packages. One problem to solve is how do we make sure that unresp

Re: [Nix-dev] "Package archeology" in nixpkgs

Can there be a better database rather than a text file? On 1/09/2014 4:04 AM, Michael Raskin wrote: >> On 31 August 2014 18:27, Michael Raskin <7c6f4...@mail.ru> wrote: >>> I'd say, though, that only name-based operations drop in performance >>> that way… >>> >>> Although for some strange reason w

Re: [Nix-dev] "Package archeology" in nixpkgs

>Can there be a better database rather than a text file? The problem is not about a _single_ text file; the problem is that you need to read some file specific to a package to find out its name, as opposed to its attribute name, I am pretty sure we don't want to mention package versions in all-p

Re: [Nix-dev] Will there be a systemd replacement at any time in the future?

I believe at one point the 'jobs' attribute was intended to abstract over the idea of running a service, but I believe this was mostly dropped as no one is interested in building our own buggy/limited version of systemd. ___ nix-dev mailing list nix-dev@l

[Nix-dev] Setting up crontab as nixos user

Hi, how can nixos users (not the nixos system, but simple users) specify cron jobs? If a user writes: $ crontab -e then he is presented with a file that has this warning: DO NOT EDIT THIS FILE - edit the master and reinstall. If the user modifies the file nonetheless, cron will never run the a