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

[Ganesh Sittampalam]

On 31/08/2014 04:31, 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 could be valuable to preserve important pieces of Haskell
> history (and perhaps other projects) and it seems like nix is uniquely
> positioned to be able to do that well. I don't propose keeping all
> versions of all the compilers around, but I'd like to pick out key
> points in history and preserve them.

On a related note, I've thought that nix would be a great way of trying
to bootstrap things like GHC from the original version (or at least the
oldest version we can find).

It's also sometimes useful to have old compilers around for testing,
though nixpkgs does go back a reasonable amount itself.

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

Re: [Nix-dev] "Failed to execute login command"

[Mateusz Kowalczyk]

On 09/02/2014 09:44 PM, Luca Bruno wrote:
> It happened to me a couple of times after big nixos-rebuild. It may
> happened that some X drivers were updated.
> 
> 
> On Tue, Sep 2, 2014 at 10:33 PM, Bjørn Forsman 
> wrote:
> 
>> Hi,
>>
>> Since about a month now, whenever I do "nixos-rebuild switch" (after
>> also updating channel sources) I'm being kicked out of the desktop
>> environment and cannot login graphically unless I reboot (maybe there
>> is a way to recover, but haven't yet bothered to investigate that
>> further).
>>
>> When this happens, I get the message "Failed to execute login command"
>> (or something similar) in the middle of the screen in a "graphical"
>> big font. After a second or two I see a text console (ctrl-alt-f1?)
>> and then back to the "Failed to execute login command".
>>
>> Anyone else getting these?
>>
>> The problem "fixes itself" by rebooting. But it's very annoying. I'm
>> running nixos unstable with gnome3.12 and lightdm login manager.
>>
>> Best regards,
>> Bjørn Forsman
>> ___
>> 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
> 

My personal experience with drivers being updated (say, along with the
kernel) is that X keeps running but if I try to restart it then it won't
work unless I reboot which is understandable considering they are now
linked against new kernel. Perhaps a similar thing is happening here,
big driver update. I think you should say what your DE/DM is, I thought
those never get restarted by default.

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

Re: [Nix-dev] systemd in the long run: Revisiting How We Put Together Linux Systems (it's almost Nix...)

[Roger Qiu]

Based on Lennart's blog article, once systemd 215 rolls around, will Nix 
adapt its structure to take advantage of these systemd features?


Although this does make Nix and Systemd much more coupled, which is fine 
by me if it makes the system easier to understand and more easier to 
control.


On 2/09/2014 9:02 PM, Vladimír C(unát wrote:

On 09/02/2014 12:06 PM, Luca Bruno wrote:

I believe in no way Lennart will be interested in Nix, since it changes
things way too much and requires nix programming understanding for
system administration.


Lennart doesn't appear to shy away from unconventional approaches ;-)

As noted, IMHO it's still more likely he'll try to implement something 
on his own... but anyway we will probably benefit from some bits.



Vladimir




___
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] "Failed to execute login command"

[Luca Bruno]

It happened to me a couple of times after big nixos-rebuild. It may
happened that some X drivers were updated.


On Tue, Sep 2, 2014 at 10:33 PM, Bjørn Forsman 
wrote:

> Hi,
>
> Since about a month now, whenever I do "nixos-rebuild switch" (after
> also updating channel sources) I'm being kicked out of the desktop
> environment and cannot login graphically unless I reboot (maybe there
> is a way to recover, but haven't yet bothered to investigate that
> further).
>
> When this happens, I get the message "Failed to execute login command"
> (or something similar) in the middle of the screen in a "graphical"
> big font. After a second or two I see a text console (ctrl-alt-f1?)
> and then back to the "Failed to execute login command".
>
> Anyone else getting these?
>
> The problem "fixes itself" by rebooting. But it's very annoying. I'm
> running nixos unstable with gnome3.12 and lightdm login manager.
>
> Best regards,
> Bjørn Forsman
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>



-- 
www.debian.org - The Universal Operating System
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] "Failed to execute login command"

[Bjørn Forsman]

Hi,

Since about a month now, whenever I do "nixos-rebuild switch" (after
also updating channel sources) I'm being kicked out of the desktop
environment and cannot login graphically unless I reboot (maybe there
is a way to recover, but haven't yet bothered to investigate that
further).

When this happens, I get the message "Failed to execute login command"
(or something similar) in the middle of the screen in a "graphical"
big font. After a second or two I see a text console (ctrl-alt-f1?)
and then back to the "Failed to execute login command".

Anyone else getting these?

The problem "fixes itself" by rebooting. But it's very annoying. I'm
running nixos unstable with gnome3.12 and lightdm login manager.

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

Re: [Nix-dev] Some staging regressions

[Domen Kožar]

>
> >
> > There is also a Qt 5 build failure on i686-linux:
> >
> >   http://hydra.nixos.org/build/13929055
> >
> > It fails because it doesn't pass -lpq to build the PostgreSQL binding.
> Turns out
> > this is due to this line:
> >
> >   !contains(LIBS, .*pq.*):LIBS += -lpq
> >
> > so -lpq is only added if LIBS doesn't contain the string "pq". And of
> course, in
> > this particular build, the path to PostgreSQL is
> > "/nix/store/h5ym9*pq*4fjkv7d4fxzs1qbb601xyl9gk-postgresql-9.2.9" :-)
> >
>
> I don't know whether to laugh or cry…
>
>
I just laughed.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Some staging regressions

[Mateusz Kowalczyk]

On 09/02/2014 01:04 PM, Eelco Dolstra wrote:
> Hi,
> 
> On 02/09/14 12:32, Vladimír Čunát wrote:
> 
>> Also pypy tests timeouted on i686-linux...
> 
> There is also a Qt 5 build failure on i686-linux:
> 
>   http://hydra.nixos.org/build/13929055
> 
> It fails because it doesn't pass -lpq to build the PostgreSQL binding. Turns 
> out
> this is due to this line:
> 
>   !contains(LIBS, .*pq.*):LIBS += -lpq
> 
> so -lpq is only added if LIBS doesn't contain the string "pq". And of course, 
> in
> this particular build, the path to PostgreSQL is
> "/nix/store/h5ym9*pq*4fjkv7d4fxzs1qbb601xyl9gk-postgresql-9.2.9" :-)
> 

I don't know whether to laugh or cry…

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

Re: [Nix-dev] About merge vs non-merge

[Luca Bruno]

>
>
> I'm not sure what the purpose of this thread is. Is it to incite people
> to use the green button? Is it to ask them to manually merge smarter?
>
> Not lose track of multiple-commit merges, and not lose track of the PR
information when manually pushing PRs.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Setting up crontab as nixos user

[Lluís Batlle i Rossell]

Ah right, in my user crontabs I set PATH.

On Tue, Sep 02, 2014 at 09:53:02PM +0200, Bjørn Forsman wrote:
> On 1 September 2014 08:10, Damien Cassou  wrote:
> > 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.
> 
> I installed NixOS (unstable) on a new machine just a few days ago.
> When I ran crontab -e, as a regular, I was presented with an empty
> file. What nixos version do you run?
> 
> > If the user modifies the file nonetheless, cron will never run the
> > added jobs. I tried with:
> >
> > */1 * * * * date >> /tmp/crontest.txt
> >
> > and the file crontest.txt never contains any date.
> 
> I noticed this too. It turns out that user cron runs with
> PATH=/usr/bin:/bin, so "date" cannot be found. There will be some
> output on stderr saying that the command cannot be found, but this
> output seems to only somewhere if using MAILTO. I hope running system
> cron with a (exported) PATH will propagate to user cron. I'll push
> if/when I've tested that it works.
> 
> > If the user creates its own crontab file and then registers it, it won't 
> > work:
> >
> > $ crontab /tmp/my.cron
> > cannot chdir(/var/cron), bailing out.
> > /var/cron: Permission denied
> 
> Never tried that.
> 
> Best regards,
> Bjørn Forsman
> ___
> 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] Setting up crontab as nixos user

[Bjørn Forsman]

On 1 September 2014 08:10, Damien Cassou  wrote:
> 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.

I installed NixOS (unstable) on a new machine just a few days ago.
When I ran crontab -e, as a regular, I was presented with an empty
file. What nixos version do you run?

> If the user modifies the file nonetheless, cron will never run the
> added jobs. I tried with:
>
> */1 * * * * date >> /tmp/crontest.txt
>
> and the file crontest.txt never contains any date.

I noticed this too. It turns out that user cron runs with
PATH=/usr/bin:/bin, so "date" cannot be found. There will be some
output on stderr saying that the command cannot be found, but this
output seems to only somewhere if using MAILTO. I hope running system
cron with a (exported) PATH will propagate to user cron. I'll push
if/when I've tested that it works.

> If the user creates its own crontab file and then registers it, it won't work:
>
> $ crontab /tmp/my.cron
> cannot chdir(/var/cron), bailing out.
> /var/cron: Permission denied

Never tried that.

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

Re: [Nix-dev] About merge vs non-merge

[Mateusz Kowalczyk]

On 09/02/2014 05:51 PM, Luca Bruno wrote:
> Somebody does not like merges because it makes the history "less clean".
> However, just today, I encountered a case where the merge was needed for
> a revert.
> 
> The good thing about the green merge button is that:
> 1) It retains a message about the PR. So you have information if you
> need to do a revert.
> 2) If it's a multi-commit PR, you may need to revert multiple commits.
> Without merge this information is lost.
> 
> For manual merges, yes it's very inconvenient. In theory one should either:
> 1) Edit every commit message saying that it was part of a given PR
> 2) or create a local branch mirroring the requester branch
> In both cases it's annoying.
> 
> However for anti-merge people, it may make the history less clean for
> you, but the lose of information is not worth it in my opinion. So I
> please everyone, if you can choose to have a merge commit, please keep it.
> 
> Best regards,
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 

There is no anti-merge sentiment, there's a ‘don't have 1:1 commit to
merge message ratio’. If it's a multi-commit PR that shouldn't be
squashed into one, sure, keep your merge message. If it's a single
commit PR, in 95% of cases the merge message is just noise.

If you're after the PR for a commit without merge message, simply put in
the author's name on the PR page with is:pr filter.

I don't want to hide merge messages because they *can* be useful as you
say, the problem is that there number of actually useful merge messages
is small, not to mention they are hidden behind all the green-button merges.

I'm not sure what the purpose of this thread is. Is it to incite people
to use the green button? Is it to ask them to manually merge smarter?

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

Re: [Nix-dev] About merge vs non-merge

[Vladimír Čunát]

On 09/02/2014 08:23 PM, Rok Garbas wrote:

so all "merge loving ppl" please keep history clean. github merges are_bad_
practise said by not only me, i guess you can search google for this so i wont
spoil you the fun reading on this topic.


I don't understand why merges are considered to "dirty" the history. If 
I don't want to see commits from the offshooting branches, I just pass 
--first-parent to git log. It's just github that shows history in a dumb 
way.


(I actually have an alias git l = log --first-parent --find-renames 
--find-copies --irreversible-delete --color=always --no-prefix 
--cherry-mark)



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] Will there be a systemd replacement at any time inthefuture?

[Ricardo M. Correia]

FWIW, yesterday I've also experienced loss of stderr messages in a service
I was trying to debug. In this case, it might have been either because the
process exited immediately afterwards or because of rate limiting, I don't
know which.

I've also always experienced HDD thrashing issues on machines which have
large journals (although for me, the command usually completes in 30-60
seconds or so, but it's still rather slower than "tail").

Just to give some more info, I'm using ZFS as my root filesystem on most of
my machines and also, for some reason, on the machines where I've been
using NixOS for a longer time journalctl complains about corrupted journals
when I use "journalctl --verify", even though my fully checksummed ZFS
filesystems never complained about a checksum error and I never noticed
corruption in any other part of the system.



On Tue, Sep 2, 2014 at 2:53 PM, Michael Raskin <7c6f4...@mail.ru> wrote:

> >I would like to add I absolutely love systemd, as it provides proper
> >dependency management, helping immensely for more dynamic setups where
> >hardware changes should trigger services reconfiguration, or for
> >changing services/vpn/routing based on wifi access point and more.
> >It's really nice that - when configured well - things just work, no
> >matter if you're booting, restarting some service or switching to a new
> >configuration. No more subtle timing errors or things that need manual
> >restarts in edgy situations. Systemd's "state manager" is extremely
> >capable. And extremely fast compared to oldschool linear scripts.
>
> Unfortunately, making SystemD _not_ do something is harder than making
> it do something. It would be irrelevant if it didn't become bigger with
> time, but deconfiguring new functionality is sometimes needed.
>
> >If we ever want to move to some other init system, I think this will
> >be easier than the upstart->systemd move. That move was mostly
> >complicated by the fact that upstart just didn't have most config
> >settings and abstractions, so stuff for run-as-user and daemonization
> >logic was put into a bash script. That had to be extracted into
>
> If we migrate to a new init system, we will have (for example) to
> rewrite all the dependencies.
>
>
>
> ___
> 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] About merge vs non-merge

[Luca Bruno]

If you do that when manually merging that's ok. Give references to the PR,
not just push multiple-commits without any track if they were bundled or
not, that was my main point.
If you don't understand what's happening, there's git log --no-merges.


On Tue, Sep 2, 2014 at 8:23 PM, Rok Garbas  wrote:

> Quoting Luca Bruno (2014-09-02 18:51:39)
> > Somebody does not like merges because it makes the history "less clean".
> > However, just today, I encountered a case where the merge was needed for
> > a revert.
> >
> > The good thing about the green merge button is that:
> > 1) It retains a message about the PR. So you have information if you
> > need to do a revert.
> > 2) If it's a multi-commit PR, you may need to revert multiple commits.
> > Without merge this information is lost.
> >
> > For manual merges, yes it's very inconvenient. In theory one should
> either:
> > 1) Edit every commit message saying that it was part of a given PR
> > 2) or create a local branch mirroring the requester branch
> > In both cases it's annoying.
> >
> > However for anti-merge people, it may make the history less clean for
> > you, but the lose of information is not worth it in my opinion. So I
> > please everyone, if you can choose to have a merge commit, please keep
> it.
> >
>
> all of the above points are non an issue when manually merging, becuase:
>  - you squash all commits into one
>  - you also add some more descriptive message if the one provided wasnt
> clear
>  - you resolve conflicts with master since some PR can get outdates quite
> fast
>and asking 10 times the contributor to rebase on top of master is waste
> of
>time.
>  - you check changes localy before you actually merge them anyway, so
> there is
>no reason also for not keeping history clean.
>
> so all "merge loving ppl" please keep history clean. github merges are
> _bad_
> practise said by not only me, i guess you can search google for this so i
> wont
> spoil you the fun reading on this topic.
>
> merges should be used with long living branches or bigger arhitecural
> changes
> not with _every_ pull request. becuase looking at current nixpkgs history
> it
> doesnt make much sense what is happening.
>
>
> --
> Rok Garbas - http://www.garbas.si
>



-- 
www.debian.org - The Universal Operating System
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] About merge vs non-merge

[Rok Garbas]

Quoting Luca Bruno (2014-09-02 18:51:39)
> Somebody does not like merges because it makes the history "less clean".
> However, just today, I encountered a case where the merge was needed for
> a revert.
> 
> The good thing about the green merge button is that:
> 1) It retains a message about the PR. So you have information if you
> need to do a revert.
> 2) If it's a multi-commit PR, you may need to revert multiple commits.
> Without merge this information is lost.
> 
> For manual merges, yes it's very inconvenient. In theory one should either:
> 1) Edit every commit message saying that it was part of a given PR
> 2) or create a local branch mirroring the requester branch
> In both cases it's annoying.
> 
> However for anti-merge people, it may make the history less clean for
> you, but the lose of information is not worth it in my opinion. So I
> please everyone, if you can choose to have a merge commit, please keep it.
> 

all of the above points are non an issue when manually merging, becuase:
 - you squash all commits into one
 - you also add some more descriptive message if the one provided wasnt clear
 - you resolve conflicts with master since some PR can get outdates quite fast
   and asking 10 times the contributor to rebase on top of master is waste of
   time.
 - you check changes localy before you actually merge them anyway, so there is
   no reason also for not keeping history clean.

so all "merge loving ppl" please keep history clean. github merges are _bad_
practise said by not only me, i guess you can search google for this so i wont
spoil you the fun reading on this topic.

merges should be used with long living branches or bigger arhitecural changes
not with _every_ pull request. becuase looking at current nixpkgs history it
doesnt make much sense what is happening.


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

Re: [Nix-dev] Replicant sdk ?

[Sander van der Burg]

Hi,

I did most of the packaging of the Android SDK and I agree that the whole
things isn't particularly elegant. Furthermore, Google does not seem to
provide any proper source release either.

Of course it would be nice to have the ability to build a free Android
distribution entirely from source. However, this requires someone to
investigate and actually do it. But so far, I couldn't find the time for it.

Best, Sander


On Sun, Aug 31, 2014 at 9:20 PM, Catonano  wrote:

> 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 know much about the binaries that come with the Replicant sdk
>
> Theorically, being Replicant open source, the sources should be available
> and the build process should be reproducible, relying on binaries shouldn't
> be strictly required.
>
> But I really don't know enough about this.
>
> Does anyone here know more ?
>
> ___
> 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] About merge vs non-merge

[Luca Bruno]

Somebody does not like merges because it makes the history "less clean".
However, just today, I encountered a case where the merge was needed for
a revert.

The good thing about the green merge button is that:
1) It retains a message about the PR. So you have information if you
need to do a revert.
2) If it's a multi-commit PR, you may need to revert multiple commits.
Without merge this information is lost.

For manual merges, yes it's very inconvenient. In theory one should either:
1) Edit every commit message saying that it was part of a given PR
2) or create a local branch mirroring the requester branch
In both cases it's annoying.

However for anti-merge people, it may make the history less clean for
you, but the lose of information is not worth it in my opinion. So I
please everyone, if you can choose to have a merge commit, please keep it.

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

Re: [Nix-dev] Some staging regressions

[Vladimír Čunát]

On 2 September 2014 14:04, Eelco Dolstra  wrote:
> so -lpq is only added if LIBS doesn't contain the string "pq". And of course, 
> in
> this particular build, the path to PostgreSQL is
> "/nix/store/h5ym9*pq*4fjkv7d4fxzs1qbb601xyl9gk-postgresql-9.2.9" :-)


Hell, this is exactly why I hate bash and similar
do-what-you-guess-I-mean languages. Scripts doing more complex stuff
get either fragile or extremely complicated. When working on
multiple-outputs stdenv stuff I partially attempted to be safe
whatever characters are in paths, but the code would be extremely
cumbersome if I wanted to cover all cases. UNIX is insane in that way,
allowing almost any characters in paths but not providing good tools
to handle them.


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

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

[Michael Raskin]

>I would like to add I absolutely love systemd, as it provides proper
>dependency management, helping immensely for more dynamic setups where
>hardware changes should trigger services reconfiguration, or for
>changing services/vpn/routing based on wifi access point and more.
>It's really nice that - when configured well - things just work, no
>matter if you're booting, restarting some service or switching to a new
>configuration. No more subtle timing errors or things that need manual
>restarts in edgy situations. Systemd's "state manager" is extremely
>capable. And extremely fast compared to oldschool linear scripts.

Unfortunately, making SystemD _not_ do something is harder than making
it do something. It would be irrelevant if it didn't become bigger with
time, but deconfiguring new functionality is sometimes needed.

>If we ever want to move to some other init system, I think this will
>be easier than the upstart->systemd move. That move was mostly
>complicated by the fact that upstart just didn't have most config
>settings and abstractions, so stuff for run-as-user and daemonization
>logic was put into a bash script. That had to be extracted into

If we migrate to a new init system, we will have (for example) to 
rewrite all the dependencies.



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

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

[Mathijs Kwik]

I also don't see these issues with journald (on non-SSD systems).

I would like to add I absolutely love systemd, as it provides proper
dependency management, helping immensely for more dynamic setups where
hardware changes should trigger services reconfiguration, or for
changing services/vpn/routing based on wifi access point and more.
It's really nice that - when configured well - things just work, no
matter if you're booting, restarting some service or switching to a new
configuration. No more subtle timing errors or things that need manual
restarts in edgy situations. Systemd's "state manager" is extremely
capable. And extremely fast compared to oldschool linear scripts.

Also - althoughh nix abstracts over it - configuration through unit
files is declarative and clean. Unifying things like daemonizing,
run-as-other-user, run-in-chroot, apply capabilities and logging is
brilliant compared to ambiguous scripting hacks.

I really feel systemd is a perfect match for nixos. Nix manages state on
disk, systemd manages runtime state. Both try to do this as
deterministically as possible, though a declarative configuration.

Sure there might be some operational bugs, but I would suggest turning
them into issues, tracking them down and taking things up with
upstream as they are probably not all that huge. The overall design
seems very well thought-out and clean. 

If we ever want to move to some other init system, I think this will
be easier than the upstart->systemd move. That move was mostly
complicated by the fact that upstart just didn't have most config
settings and abstractions, so stuff for run-as-user and daemonization
logic was put into a bash script. That had to be extracted into
attributes. If we move to something else, we now have nicely abstracted
configurations for most services (although named systemd.services.*
instead of something more generic), so exporting config files for
anything (even upstart) based on these attributes is probably gonna be
easy, making a "port" way simpler than before.

Just my 2 cents :)
Mathijs
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Some staging regressions

[Eelco Dolstra]

Hi,

On 02/09/14 12:32, Vladimír Čunát wrote:

> Also pypy tests timeouted on i686-linux...

There is also a Qt 5 build failure on i686-linux:

  http://hydra.nixos.org/build/13929055

It fails because it doesn't pass -lpq to build the PostgreSQL binding. Turns out
this is due to this line:

  !contains(LIBS, .*pq.*):LIBS += -lpq

so -lpq is only added if LIBS doesn't contain the string "pq". And of course, in
this particular build, the path to PostgreSQL is
"/nix/store/h5ym9*pq*4fjkv7d4fxzs1qbb601xyl9gk-postgresql-9.2.9" :-)

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

Re: [Nix-dev] Some staging regressions

[Eelco Dolstra]

On 02/09/14 12:32, Vladimír Čunát wrote:
> On 09/02/2014 11:44 AM, Luca Bruno wrote:
>>> From http://hydra.nixos.org/eval/1150396?compare=trunk it seems that the
>> ghc and swig build failures are the main reason of about 800 failures
>> more compared to trunk.
>> Both swig and ghc test suites fail.
> 
> Actually, if we look at diff from the last point of master merge
> http://hydra.nixos.org/eval/1150396?compare=1149952
> then the number of new failures is ~250 (but 6k jobs still queued).

Most of these are due to a failure in the test suite of "haskell-auto-update":

  http://hydra.nixos.org/build/13927207/nixlog/1/raw

which is probably a random failure.

I've fixed the swig issue.

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

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

[Michael Raskin]

>>> It did not. There was no way with Upstart to get the log output of a 
>>> service.
>> 
>> In NixOS the problem wasn't noticeable…
>
>Again, the logging situation with systemd is vastly superior than it was with
>Upstart. With Upstart you simply couldn't do something like "systemctl status
>foo.service" and see the most recent log messages of a service. Or do
>"journalctl --since yesterday -p err" to see important recent messages. And so 
>on...

Observed situation is _worse_ for me. 

I cannot do ```systemctl status sshd``` because I need to manage 
fragmentation manually for this to ever finish.

Using grep and tail does work, journalctl is simply too slow to use.

Also, any situation where part of logs is lost in the same situation,
is _not_ vastly superior to a situation where logs were strangely 
distributed but not lost.

>> Logging of output was implemented in a way that didn't require an edit
>> to every jobs and the logs looked the same as all the other logs on the
>> system…
>
>What is the "edit to every job" that you refer to? Also, it's only with the

I cannot understand how to edit vsftpd job in a way that ensures that in
case I specify incorrect configuration and vsftpd correctly exists after
sending a description of the problem to stderr I can retrieve the error
message. 

Obviously, if there is a workaround for this systemd journalling 
property, it would be nice to apply it once for all the services…

>journal that logs can be accessed consistently, rather than being scattered
>across a zillion files, each in a different format.

I always prefer any somehow usable text files to a binary format that
requires _more_ I/O for filtering. I thought is has been a few years 
since I/O is more expensive than CPU cycles.

>I'm simply not seeing the journal issues you seem to run into constantly. Did
>you make an issue for them?

For what? For journald trashing HDD like crazy? Wasn't it always common 
knowledge?

For losing logs you showed me a link that shows it is a known problem
with no known solution. I asked around a few times on IRC and got the
same impression minus the link. 

I don't see _what_ can be done on NixOS level — as you confirmed, 
upstream is aware and is not going to fix it.



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

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

[Eelco Dolstra]

On 02/09/14 12:06, Michael Raskin wrote:

>> It did not. There was no way with Upstart to get the log output of a service.
> 
> In NixOS the problem wasn't noticeable…

Again, the logging situation with systemd is vastly superior than it was with
Upstart. With Upstart you simply couldn't do something like "systemctl status
foo.service" and see the most recent log messages of a service. Or do
"journalctl --since yesterday -p err" to see important recent messages. And so 
on...

> Logging of output was implemented in a way that didn't require an edit
> to every jobs and the logs looked the same as all the other logs on the
> system…

What is the "edit to every job" that you refer to? Also, it's only with the
journal that logs can be accessed consistently, rather than being scattered
across a zillion files, each in a different format.

I'm simply not seeing the journal issues you seem to run into constantly. Did
you make an issue for them?

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

Re: [Nix-dev] Some staging regressions

[Peter Simons]

The test suite failure in haskell-auto-update feels like it's caused by
an issue in the test suite itself. I've filed a report upstream and
disabled tests for that package in the meanwhile.

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

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

[Eelco Dolstra]

Hi,

On 02/09/14 11:58, Paul Colomiets wrote:

>> On 02/09/14 11:50, Michael Raskin wrote:
>>
 It's funny, for me it's the opposite - logging with systemd is sooo much 
 better
 than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
 NixOS-specific hack, and other than that there was no logging support.)
>>>
>>> Somehow, it work reliably…
>>
>> It did not. There was no way with Upstart to get the log output of a service.
> 
> Doesn't it always write to /var/log/upstart/.log ?

No, it might log to syslog. In which case you have no way to easily query the
messages belonging to a specific service.

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

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

[Michael Raskin]

>> However, there is a long-standing issue with stdout/stderr logging: if the
>> process dies before systemd has had a change to process its log message, then
>> systemd may not be able to figure out the unit corresponding to the message, 
>> so
>> it may be lost (or not attributed to the unit). See
>>
>>http://lists.freedesktop.org/archives/systemd-devel/2012-June/005590.html
>
>I didn't investigate details, but I suspect that losing the last parts 
>of logs could be caused by the fact that stdout is buffered by default 
>(and stderr is not). I don't know if the contents of the buffer residing 
>in the crashed process can be well recovered. Perhaps they have some 
>hack to force the flush externally, I don't know.

The real problem is not about crashes, it is about deliberate exit of 
a process with stdout and stderr flushing



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

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

[Luca Bruno]

On 02/09/2014 13:10, Luca Bruno wrote:
> On 02/09/2014 12:53, Damien Cassou wrote:
>> I don't understand how that will help. What about distributions with
>> no systemd? What about the fact that it's the tool that writes and
>> updates the cron jobs (with the period and arguments). As the
>> packager, I have no clue about the profiles the users will have. 
> Confirming. I think you can report an issue in nixpkgs. It is annoying,
> systemd must not be the only way to set a timer to run a command. Since
> ever, users were able to use crontab.
I think the system is missing /var/spool/cron and /var/mail/ with
proper permissions. Didn't investigate deeply yet. However let's open a
nixpkgs issue, I think it should be solved with a couple of commands to
be executed in ExecStartPre of cron.service.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Luca Bruno]

On 02/09/2014 12:53, Damien Cassou wrote:
> I don't understand how that will help. What about distributions with
> no systemd? What about the fact that it's the tool that writes and
> updates the cron jobs (with the period and arguments). As the
> packager, I have no clue about the profiles the users will have. 
Confirming. I think you can report an issue in nixpkgs. It is annoying,
systemd must not be the only way to set a timer to run a command. Since
ever, users were able to use crontab.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Some staging regressions

[Gergely Risko]

Hi,

On Tue, 02 Sep 2014 12:32:06 +0200, Vladimír Čunát  writes:

> On 09/02/2014 11:44 AM, Luca Bruno wrote:
> Actually, if we look at diff from the last point of master merge
> http://hydra.nixos.org/eval/1150396?compare=1149952
> then the number of new failures is ~250 (but 6k jobs still queued).
>
> The two test suite failures may likely have nothing with the changes
> introduced in staging. I'll probably look closer after more of the
> evaluation finishes, and e.g. try to reproduce them.
>
> Also pypy tests timeouted on i686-linux...

Thanks for looking into this!

If this turns out to be one of my changes (er...@nilcons.com), please CC
me, sometimes I skip threads on the mailing list!  Also, feel free to
assign bugs to me on the github issues page when I'm at fault...

Thanks,
Gergely

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

Re: [Nix-dev] systemd in the long run: Revisiting How We Put Together Linux Systems (it's almost Nix...)

[Vladimír Čunát]

On 09/02/2014 12:06 PM, Luca Bruno wrote:

I believe in no way Lennart will be interested in Nix, since it changes
things way too much and requires nix programming understanding for
system administration.


Lennart doesn't appear to shy away from unconventional approaches ;-)

As noted, IMHO it's still more likely he'll try to implement something 
on his own... but anyway we will probably benefit from some bits.



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] Will there be a systemd replacement at any time inthe future?

[Wout Mertens]

On Tue, Sep 2, 2014 at 12:05 PM, Vladimír Čunát  wrote:

> On 09/01/2014 10:59 PM, Wout Mertens wrote:
>
>> Furthermore, it's still not available out-of-the-box in Docker, so you
>> can't install a NixOS image in Docker.
>>
>
> IIRC, at the sprint last week, @offlinehacker claimed he made nixos work
> inside docker. I know no details... there probably still were some caveats.


Yup, it needs extra privileges for now, see
https://github.com/NixOS/nixpkgs/pull/3779

So until Docker mounts cgroups you can't ship people a Docker NixOS image
that they can run on third-party providers. Pretty trivial to run locally
with the correct flags of course.

Zef's Nix on Docker uses supervisord instead:
https://github.com/zefhemel/nix-docker and the systemd shim is
https://github.com/zefhemel/nix-docker/blob/master/nix-docker/modules/shim/systemd.nix

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

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

[Damien Cassou]

On Tue, Sep 2, 2014 at 11:42 AM, Eelco Dolstra
 wrote:
> The best solution is not to use cron but systemd timer units. Just create 
> units
> $out/etc/systemd/system/.service and $out/etc/systemd/system/.timer.
> On NixOS, add the package to the systemd.packages option to ensure that its
> units are picked up.


I don't understand how that will help. What about distributions with
no systemd? What about the fact that it's the tool that writes and
updates the cron jobs (with the period and arguments). As the
packager, I have no clue about the profiles the users will have.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Some staging regressions

[Vladimír Čunát]

On 09/02/2014 11:44 AM, Luca Bruno wrote:

From http://hydra.nixos.org/eval/1150396?compare=trunk it seems that the

ghc and swig build failures are the main reason of about 800 failures
more compared to trunk.
Both swig and ghc test suites fail.


Actually, if we look at diff from the last point of master merge
http://hydra.nixos.org/eval/1150396?compare=1149952
then the number of new failures is ~250 (but 6k jobs still queued).

The two test suite failures may likely have nothing with the changes 
introduced in staging. I'll probably look closer after more of the 
evaluation finishes, and e.g. try to reproduce them.


Also pypy tests timeouted on i686-linux...


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] Will there be a systemd replacement at any time inthefuture?

[Luca Bruno]

On 02/09/2014 12:27, Lluís Batlle i Rossell wrote:
> I set systemd log files to nocow. Yet the reading of the journal does so many
> seeks, that it's slow everywhere unless the journal is cached. I guess that
> spinning disks are unsupported. :)
journald has some options to split the files per-time and per-size. I do
that, it may help.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Lluís Batlle i Rossell]

On Tue, Sep 02, 2014 at 12:22:33PM +0200, Vladimír Čunát wrote:
> On 09/02/2014 07:30 AM, Michael Raskin wrote:
> >So all in all: it writes to a file in a way that ensures fragmentation,
> >then reads it randomly in small chunks, reads most of it, and ends up
> >way slower than just reading the entire file…
> 
> Could it be a bad interaction with COW of btrfs? I've also had
> problems with journalctl needing huge amount of time. I do have the
> autodefrag option.

I set systemd log files to nocow. Yet the reading of the journal does so many
seeks, that it's slow everywhere unless the journal is cached. I guess that
spinning disks are unsupported. :)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Lluís Batlle i Rossell]

On Tue, Sep 02, 2014 at 12:21:20PM +0200, Vladimír Čunát wrote:
> On 09/02/2014 11:36 AM, Eelco Dolstra wrote:
> >However, there is a long-standing issue with stdout/stderr logging: if the
> >process dies before systemd has had a change to process its log message, then
> >systemd may not be able to figure out the unit corresponding to the message, 
> >so
> >it may be lost (or not attributed to the unit). See
> >
> >   http://lists.freedesktop.org/archives/systemd-devel/2012-June/005590.html
> 
> I didn't investigate details, but I suspect that losing the last
> parts of logs could be caused by the fact that stdout is buffered by
> default (and stderr is not). I don't know if the contents of the
> buffer residing in the crashed process can be well recovered.
> Perhaps they have some hack to force the flush externally, I don't
> know.
> 
> See e.g. 
> http://stackoverflow.com/questions/7876660/how-to-turn-off-buffering-of-stdout-in-c

If that is the case, maybe we can run the daemons with "stdbuf -o 0 daemon". I
understood from previous letters that *stderr* messages were lost, not *stdout*,
but that maybe was a reference to upstart. The systemd archive reference
mentions some unlink between unit and log, which would be a completely differen
case.

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

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

[Vladimír Čunát]

On 09/02/2014 07:30 AM, Michael Raskin wrote:

So all in all: it writes to a file in a way that ensures fragmentation,
then reads it randomly in small chunks, reads most of it, and ends up
way slower than just reading the entire file…


Could it be a bad interaction with COW of btrfs? I've also had problems 
with journalctl needing huge amount of time. I do have the autodefrag 
option.



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] Will there be a systemd replacement at any time inthe future?

[Vladimír Čunát]

On 09/02/2014 11:36 AM, Eelco Dolstra wrote:

However, there is a long-standing issue with stdout/stderr logging: if the
process dies before systemd has had a change to process its log message, then
systemd may not be able to figure out the unit corresponding to the message, so
it may be lost (or not attributed to the unit). See

   http://lists.freedesktop.org/archives/systemd-devel/2012-June/005590.html


I didn't investigate details, but I suspect that losing the last parts 
of logs could be caused by the fact that stdout is buffered by default 
(and stderr is not). I don't know if the contents of the buffer residing 
in the crashed process can be well recovered. Perhaps they have some 
hack to force the flush externally, I don't know.


See e.g. 
http://stackoverflow.com/questions/7876660/how-to-turn-off-buffering-of-stdout-in-c



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] Will there be a systemd replacement at any time inthe future?

[Luca Bruno]

On 02/09/2014 12:05, Vladimír Čunát wrote:
> On 09/01/2014 10:59 PM, Wout Mertens wrote:
>> Furthermore, it's still not available out-of-the-box in Docker, so you
>> can't install a NixOS image in Docker.
>
> IIRC, at the sprint last week, @offlinehacker claimed he made nixos
> work inside docker. I know no details... there probably still were
> some caveats.
I was able to run his nixos docker image from nix on ubuntu (that is,
installed nix on ubuntu, installed docker via nix, run his nixos image):
https://github.com/NixOS/nixpkgs/pull/3779
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Setting up crontab as nixos user

[Lluís Batlle i Rossell]

I use user crontabs since years in nixos. Both with vixie and fcron. I don't
remember seeing this trouble. Maybe I lag one month or so in nixos, so I'm not
running master HEAD.

On Mon, Sep 01, 2014 at 08:10:19AM +0200, Damien Cassou wrote:
> 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
> added jobs. I tried with:
> 
> */1 * * * * date >> /tmp/crontest.txt
> 
> and the file crontest.txt never contains any date.
> 
> If the user creates its own crontab file and then registers it, it won't work:
> 
> $ crontab /tmp/my.cron
> cannot chdir(/var/cron), bailing out.
> /var/cron: Permission denied
> 
> 
> Can you please tell me how simple users can register jobs on nixos?
> 
> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Success is the ability to go from one failure to another without
> losing enthusiasm."
> Winston Churchill
> ___
> 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] systemd in the long run: Revisiting How We Put Together Linux Systems (it's almost Nix...)

[Alexander Zubkov]

On 2014-09-02 14:06, Luca Bruno wrote:
> On 02/09/2014 12:02, Alexei Robyn wrote:
>> Unless I'm missing something, Lennart's only response to you was: "we
>> actually try to do our homework before we propose something. We looked
>> at a variety of systems, and not just on Linux ones, but also what
>> MacOS, Android, ChromeOS, and even Windows do..."
>>
>> Which - given it is completely generic and mentions none of the points
>> you raised (or heck, Nix itself at all) - sounds a lot more like he's
>> deflecting to buy time to grok Nix. I would think otherwise, but he
>> wrote detailed responses to almost every other poster both before and
>> after you...
>>
>> Hopefully if this is the case he comes back with a solid understanding
>> of it and not just enough of one to come up with seemingly plausible
>> reasons why their plan is the superior option. Past experience of people
>> in general tells me the latter is the more likely outcome but then I
>> don't know Lennart in specific. Still, here's hoping this instead
>> results in Nix getting some larger groups interested in it,  as well as
>> in this class of problems :).
> I believe in no way Lennart will be interested in Nix, since it changes
> things way too much and requires nix programming understanding for
> system administration.
>
> Instead I think he will come up with some other solution which is
> similar to OSX, OSTree or 0install, together with some system-level changes.
> I hope he will take a closer look at Nix, but in no way I think he will
> even try it.

Given the history. He will prefer to reimplement Nix, than try it. :)

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

Re: [Nix-dev] systemd in the long run: Revisiting How We Put Together Linux Systems (it's almost Nix...)

[Luca Bruno]

On 02/09/2014 12:02, Alexei Robyn wrote:
> Unless I'm missing something, Lennart's only response to you was: "we
> actually try to do our homework before we propose something. We looked
> at a variety of systems, and not just on Linux ones, but also what
> MacOS, Android, ChromeOS, and even Windows do..."
>
> Which - given it is completely generic and mentions none of the points
> you raised (or heck, Nix itself at all) - sounds a lot more like he's
> deflecting to buy time to grok Nix. I would think otherwise, but he
> wrote detailed responses to almost every other poster both before and
> after you... 
>
> Hopefully if this is the case he comes back with a solid understanding
> of it and not just enough of one to come up with seemingly plausible
> reasons why their plan is the superior option. Past experience of people
> in general tells me the latter is the more likely outcome but then I
> don't know Lennart in specific. Still, here's hoping this instead
> results in Nix getting some larger groups interested in it,  as well as
> in this class of problems :). 
I believe in no way Lennart will be interested in Nix, since it changes
things way too much and requires nix programming understanding for
system administration.

Instead I think he will come up with some other solution which is
similar to OSX, OSTree or 0install, together with some system-level changes.
I hope he will take a closer look at Nix, but in no way I think he will
even try it.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Michael Raskin]

>A program that takes v1.deb and v2.deb can output the list of patches added
>and removed, as well as whether the meta-data for the package (scripts/* ?)
>was changed.

This means that we switch to debian releases as our upstream?

>For both of these packages it is fairly easy to generate a fully patched
>source directory which can be diffed.  Alternatively the patches are also
>kept in a structured manner and can be extracted.

The patches monitor needs are patchs to the Nix expressions to fetch
fresher tarball.

>I can see a need for adding a bit more meta-data into nixpkgs when
>"upstream" is no longer the author of the software, but "upstream" is a
>collection of distributions as well.  For example, the latest .deb or .rpm
>that has been "processed" or "consumed" so that only new patches relative
>to those bases should be considered by the monitor.

I doubt that switching between Debian patched versions and Fedora 
patched versions at random moments is a good idea. For various reasons…



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

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

[Vladimír Čunát]

On 09/01/2014 10:59 PM, Wout Mertens wrote:

Furthermore, it's still not available out-of-the-box in Docker, so you
can't install a NixOS image in Docker.


IIRC, at the sprint last week, @offlinehacker claimed he made nixos work 
inside docker. I know no details... there probably still were some caveats.


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] systemd in the long run: Revisiting How We Put Together Linux Systems (it's almost Nix...)

[Alexei Robyn]

Unless I'm missing something, Lennart's only response to you was: "we
actually try to do our homework before we propose something. We looked
at a variety of systems, and not just on Linux ones, but also what
MacOS, Android, ChromeOS, and even Windows do..."

Which - given it is completely generic and mentions none of the points
you raised (or heck, Nix itself at all) - sounds a lot more like he's
deflecting to buy time to grok Nix. I would think otherwise, but he
wrote detailed responses to almost every other poster both before and
after you... 

Hopefully if this is the case he comes back with a solid understanding
of it and not just enough of one to come up with seemingly plausible
reasons why their plan is the superior option. Past experience of people
in general tells me the latter is the more likely outcome but then I
don't know Lennart in specific. Still, here's hoping this instead
results in Nix getting some larger groups interested in it,  as well as
in this class of problems :). 

- Alexei

On Tue, Sep 2, 2014, at 05:22 PM, Luca Bruno wrote:
> On 02/09/2014 09:06, Nathan Bijnens wrote:
> > The systemd kabal just wrote a blog post detailing their long term
> > vision on Linux. They have great issue with traditional package
> > managers (who can blame them?). 
> >
> > They sketch a possible solution, based on a whole lof of BTRFS
> > subvolumes, sort of used like docker images but linked to each other
> > (it sounds as complicated as it is).
> >
> > http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
> >
> > I have the feeling they're trying to recreate what already exists and
> > works in Nix, I have the feeling they're unaware of this little great OS.
> I've replied to G+, and Lennart also replied to me. You can find the
> discussion easily on G+. They are well aware of Nix and other systems
> such as GoboLinux or 0install and so on.
> However this is the direction in the future, more stateless and
> reproducible systems. Nix is not the perfection so I don't think yet
> another project like this will hurt. Systems are evolving through this
> path, so expect to see more and more attempts to achieve what Nix does.
> 
> Not only, they may even solve problems at kernel/system level for which
> we don't have manpower or enough marketing impact, and Nix may even take
> advantage of their work. In other words, let the system itself be more
> stateless instead of writing hacks in Nix all the way to make it work
> statelessly.
> 
> We're heading toward a new paradigm, and having new ideas on how to
> solve the same problem is about a necessity I'd say. What tool will
> survive in the end I don't know (might even be a Nix fork).
> 
> So +1 if they are really able to bring something new to table. -1 if
> they don't even solve what Nix is able to solve currently without proper
> system support. We'll see.
> 
> Best regards,
> ___
> 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] Will there be a systemd replacement at any time inthefuture?

[Michael Raskin]

>>> It's funny, for me it's the opposite - logging with systemd is sooo much 
>>> better
>>> than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
>>> NixOS-specific hack, and other than that there was no logging support.)
>> 
>> Somehow, it work reliably…
>
>It did not. There was no way with Upstart to get the log output of a service.

In NixOS the problem wasn't noticeable…

Logging of output was implemented in a way that didn't require an edit
to every jobs and the logs looked the same as all the other logs on the
system…

Upstart not caring about logs was probably a plus.

>>> However, there is a long-standing issue with stdout/stderr logging: if the
>>> process dies before systemd has had a change to process its log message, 
>>> then
>>> systemd may not be able to figure out the unit corresponding to the 
>>> message, so
>>> it may be lost (or not attributed to the unit). See
>>>
>>>  http://lists.freedesktop.org/archives/systemd-devel/2012-June/005590.html
>> 
>> Apparently, the fix got merged? Why doesn't it work?
>
>It only works if the sender is root.

Painful.

Is there a _reasonable_ way to work around this? I guess duplication of
most messages in system journal is not nice, and you won't approve 
logging all output _also_ to plain text files using tee?



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

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

[Paul Colomiets]

On Tue, Sep 2, 2014 at 12:51 PM, Eelco Dolstra
 wrote:
> Hi,
>
> On 02/09/14 11:50, Michael Raskin wrote:
>
>>> It's funny, for me it's the opposite - logging with systemd is sooo much 
>>> better
>>> than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
>>> NixOS-specific hack, and other than that there was no logging support.)
>>
>> Somehow, it work reliably…
>
> It did not. There was no way with Upstart to get the log output of a service.
>

Doesn't it always write to /var/log/upstart/.log ?

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

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

[Alexander Kjeldaas]

On Tue, Sep 2, 2014 at 11:33 AM, Michael Raskin <7c6f4...@mail.ru> wrote:

> >>   1 not sure if 0.8.0.3 is relevant on linux
> >>   1 patch OK
> >>   2 hard to say
> >>   2 not linked on homepage
> >>   3 build failure
> >>  11 patch ok
> >>  12 build pending
> >>  23 irrelevant
> >>  29 no patch
> >>
> >>
> >What does "no patch" mean? (a new release without a patch or a tarball
> >makes no sense)
>
> We know some other distribution has a newer version but cannot
> automatically patch out expression to fetch the new tarball.
>

Thanks for the explanation.  I think analyzing .deb or .rpm files is doable.

A program that takes v1.deb and v2.deb can output the list of patches added
and removed, as well as whether the meta-data for the package (scripts/* ?)
was changed.

For both of these packages it is fairly easy to generate a fully patched
source directory which can be diffed.  Alternatively the patches are also
kept in a structured manner and can be extracted.

Then only if the meta-data was changed is it hard to automate.

I can see a need for adding a bit more meta-data into nixpkgs when
"upstream" is no longer the author of the software, but "upstream" is a
collection of distributions as well.  For example, the latest .deb or .rpm
that has been "processed" or "consumed" so that only new patches relative
to those bases should be considered by the monitor.



>
> >"irrelevant" could be baked into monitor.nixos.org, if it is non-security
> >related.
>
> These should be just ignored — some of these are trivial to automate.
>
> >"not linked on homepage" means that monitor.nixos.org missed it?
>
> No, it misses way more.
>
> There are multiple packages where some distributions package versions
> not acknowledged by software's homepage.
>
> Think gcc-2.96, but with less critical software.
>
>
monitor.nixos.org could also issue a "warning" when the number of commits
from the last tag or release starts getting significant.  Like "this
package has 200 commits since last release.. time to investigate?".


> >"hard to say"??
>
> Looking at two versions it is not always obvious if the package is
> newer. I didn't want to spend inordinate effort but I didn't want to
> hide throwing data out.
>

Yes, this is the core of what  maintainer needs to do.  Figure out if this
is a new version, whether it is important, security-related etc.


>
> >It seems like you have 3 "build failures" and 2 "not linked on homepage"
> >that could not be automated.  Am I reading your numbers correctly?
>
> Nope, our real problem is 30 «no patch» + 3 build failures + (expected)
> 3 out of 12 pending builds failing — vs. 12 patch OK + (expected) 9 more
> patches from pending builds.
>

I think those numbers are pretty good.  It seems like getting support for
digesting .deb .rpg, gentoo, arch linux or whoever has the most up-to-date
packages is important, but the patches exist, they are just a bit hard to
get at.

Here is a sketch of how this can be realized:  Create a large git-tree
(with submodules for each nixpkgs package) that contains all source code
for all distributions.  Whenever the monitor finds a new .deb, .rpm or
similar it will unpack and commit to the distribution's branch with a
proper tag.  Then another tool could create patches based on that.  The
gist is to use git as the shared state for monitor.nixos.org.  Using git as
the shared state makes it possible to create lots of smaller tools that can
be used by developers directly without having to bake everything into the
monitor (and being dependent on it being up - that's the hackage failure
mode).  The files are already (mostly) stored on github already, so this
doesn't cost much in terms of storage for github.

In the meta-data for packages in nixpkgs, references into that git tree can
be used as distribution-neutral meta-data that describes which patches have
been processed.

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

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

[Eelco Dolstra]

Hi,

On 02/09/14 11:50, Michael Raskin wrote:

>> It's funny, for me it's the opposite - logging with systemd is sooo much 
>> better
>> than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
>> NixOS-specific hack, and other than that there was no logging support.)
> 
> Somehow, it work reliably…

It did not. There was no way with Upstart to get the log output of a service.

>> However, there is a long-standing issue with stdout/stderr logging: if the
>> process dies before systemd has had a change to process its log message, then
>> systemd may not be able to figure out the unit corresponding to the message, 
>> so
>> it may be lost (or not attributed to the unit). See
>>
>>  http://lists.freedesktop.org/archives/systemd-devel/2012-June/005590.html
> 
> Apparently, the fix got merged? Why doesn't it work?

It only works if the sender is root.

-- 
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] Some staging regressions

[Luca Bruno]

>From http://hydra.nixos.org/eval/1150396?compare=trunk it seems that the
ghc and swig build failures are the main reason of about 800 failures
more compared to trunk.
Both swig and ghc test suites fail.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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

[Michael Raskin]

>It's funny, for me it's the opposite - logging with systemd is sooo much better
>than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
>NixOS-specific hack, and other than that there was no logging support.)

Somehow, it work reliably…

>However, there is a long-standing issue with stdout/stderr logging: if the
>process dies before systemd has had a change to process its log message, then
>systemd may not be able to figure out the unit corresponding to the message, so
>it may be lost (or not attributed to the unit). See
>
>  http://lists.freedesktop.org/archives/systemd-devel/2012-June/005590.html

Apparently, the fix got merged? Why doesn't it work?

Obviously, stderr of a failing service is the most interesting piece of
logs on a personal notebook.

>Also note that the journal has rate-limiting that may cause messages to be 
>dropped.

I remember that story with flooding the kernel…



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

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

[Eelco Dolstra]

On 31/08/14 20:16, Damien Cassou wrote:

> I'm looking for a solution to package this tool for both nixos and
> non-nixos nix-based distributions.

The best solution is not to use cron but systemd timer units. Just create units
$out/etc/systemd/system/.service and $out/etc/systemd/system/.timer.
On NixOS, add the package to the systemd.packages option to ensure that its
units are picked up.

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

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

[Eelco Dolstra]

Hi,

On 01/09/14 23:26, Michael Raskin wrote:

> Also, could you submit a patch that makes systemd log stderr of services
> reliably (stdout too)? We had it with Upstart, but with Systemd it got
> lost and I am not sure how to make it automatic for all services.

It's funny, for me it's the opposite - logging with systemd is sooo much better
than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
NixOS-specific hack, and other than that there was no logging support.)

However, there is a long-standing issue with stdout/stderr logging: if the
process dies before systemd has had a change to process its log message, then
systemd may not be able to figure out the unit corresponding to the message, so
it may be lost (or not attributed to the unit). See

  http://lists.freedesktop.org/archives/systemd-devel/2012-June/005590.html

Also note that the journal has rate-limiting that may cause messages to be 
dropped.

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

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

[Michael Raskin]

>But with a proper database implementation, perhaps it can do full text 
>indexing on its description, or indexing on the names, and proper 
>caching mechanisms as well.
>
>Why reinvent the wheel?

Because every package is a piece of code in Nix programming language.



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

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

[Michael Raskin]

>>   1 not sure if 0.8.0.3 is relevant on linux
>>   1 patch OK
>>   2 hard to say
>>   2 not linked on homepage
>>   3 build failure
>>  11 patch ok
>>  12 build pending
>>  23 irrelevant
>>  29 no patch
>>
>>
>What does "no patch" mean? (a new release without a patch or a tarball
>makes no sense)

We know some other distribution has a newer version but cannot 
automatically patch out expression to fetch the new tarball.

>"irrelevant" could be baked into monitor.nixos.org, if it is non-security
>related.

These should be just ignored — some of these are trivial to automate.

>"not linked on homepage" means that monitor.nixos.org missed it?

No, it misses way more. 

There are multiple packages where some distributions package versions
not acknowledged by software's homepage.

Think gcc-2.96, but with less critical software.

>"hard to say"??

Looking at two versions it is not always obvious if the package is 
newer. I didn't want to spend inordinate effort but I didn't want to 
hide throwing data out.

>It seems like you have 3 "build failures" and 2 "not linked on homepage"
>that could not be automated.  Am I reading your numbers correctly?

Nope, our real problem is 30 «no patch» + 3 build failures + (expected)
3 out of 12 pending builds failing — vs. 12 patch OK + (expected) 9 more
patches from pending builds.



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

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

[Roger Qiu]

But with a proper database implementation, perhaps it can do full text 
indexing on its description, or indexing on the names, and proper 
caching mechanisms as well.

Why reinvent the wheel?

On 1/09/2014 3:04 PM, Michael Raskin wrote:
>> 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-packages.nix because the version in name will never match the actual
> tarball version…
>
> So the solution would require some way of careful caching (note that to
> find updates reliably you need to stat() all the files — so caching has
> to sometimes lag behind the actual files…)
>
>> 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 we still recommend this way of using
> Nix.
 Nix newb asks: what would be the superiour alternative, then?
>>> nix-env -iA insted of nix-env -i
>>>
>>> The difference is that you use attribute name, not package name; lookup
>>> by attribute name allows to read only all-packages.nix and relevant
>>> sources, not entire NixPkgs tree.
>
>

-- 
Founder of Polycademy & SnapSearch
http://polycademy.com
https://snapsearch.io
+61420925975

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

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

[Alexander Kjeldaas]

On Tue, Sep 2, 2014 at 10:52 AM, Michael Raskin <7c6f4...@mail.ru> wrote:

> >With the awesome monitor.nixos.org system, we're prety close to 1)
> deriving
> >trivial patches (update version and sha256) automatically, 2) building
> >these trivial patches in a monitor.nixos.org-controlled branch, and 3)
> >notifying maintainers that a successful build of a new version exists so
> >they can 4) expose a particular commit as a pull request.
> >
> >I have a feeling that 97% of the updates could be handled like this,
> >bringing the maintainance job down to a couple of mouse clicks.
>
> I am a package maintainer and can look up…
>
> irrelevant is for stable-to-unstable with existing unstable expression
> and for cross-branch upgrades.
>
>   1 not sure if 0.8.0.3 is relevant on linux
>   1 patch OK
>   2 hard to say
>   2 not linked on homepage
>   3 build failure
>  11 patch ok
>  12 build pending
>  23 irrelevant
>  29 no patch
>
>
What does "no patch" mean? (a new release without a patch or a tarball
makes no sense)
"irrelevant" could be baked into monitor.nixos.org, if it is non-security
related.
"not linked on homepage" means that monitor.nixos.org missed it?
"hard to say"??

It seems like you have 3 "build failures" and 2 "not linked on homepage"
that could not be automated.  Am I reading your numbers correctly?

Alexander



> So, happiness is, as usual, delayed… Although I should probably apply
> this dozen of patches.
>
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] automatically mount vboxsf

[Andreas Herrmann]

Hi everyone,

I've been playing around with nixops and virtualbox deployments for a bit.

nixops offers a configuration option to forward a host folder into the guest os 
like so:

deployment.virtualbox.sharedFolders = {
  hostHome = { hostPath = "/home"; };
};

However, inside the virtual machine these are not available immediately. These 
folders have to be mounted manually by executing the following command as root:

mount.vboxsf hostHome /host_home

I was wondering if there was some way to automate this process. I couldn't find 
vboxsf anywhere in the supported file-systems. Is there another way to 
automatically mount it when the virtual machine boots?

Best,

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

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

[Michael Raskin]

>With the awesome monitor.nixos.org system, we're prety close to 1) deriving
>trivial patches (update version and sha256) automatically, 2) building
>these trivial patches in a monitor.nixos.org-controlled branch, and 3)
>notifying maintainers that a successful build of a new version exists so
>they can 4) expose a particular commit as a pull request.
>
>I have a feeling that 97% of the updates could be handled like this,
>bringing the maintainance job down to a couple of mouse clicks.

I am a package maintainer and can look up…

irrelevant is for stable-to-unstable with existing unstable expression
and for cross-branch upgrades.

  1 not sure if 0.8.0.3 is relevant on linux
  1 patch OK
  2 hard to say
  2 not linked on homepage
  3 build failure
 11 patch ok
 12 build pending
 23 irrelevant
 29 no patch

So, happiness is, as usual, delayed… Although I should probably apply
this dozen of patches.



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

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

[Alexander Kjeldaas]

With the awesome monitor.nixos.org system, we're prety close to 1) deriving
trivial patches (update version and sha256) automatically, 2) building
these trivial patches in a monitor.nixos.org-controlled branch, and 3)
notifying maintainers that a successful build of a new version exists so
they can 4) expose a particular commit as a pull request.

I have a feeling that 97% of the updates could be handled like this,
bringing the maintainance job down to a couple of mouse clicks.

Alexander



On Mon, Sep 1, 2014 at 1:24 AM, Roger Qiu  wrote:

> 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 unresponsive
> maintainers can be replaced by responsive maintainers.
>
> At this point, the all-packages.nix file will grow bigger and bigger. If
> maintainers can independently update their packages, which might
> introduce more bugs, I think there will need to be a stringent
> tagging/semantic versioning of each package, so that its possible to
> have many versions of the same package.
>
> If the package update process is kept the same, the more people that use
> nix, the more people who contribute to nix, the more work to accept
> pull-requests, which would have to mean an increase in the number of
> people who have the privilege to merge pull-requests. Otherwise there's
> going to be an increasing amount of work for a constant number of people.
>
> Thanks,
> Roger
>
> On 1/09/2014 12:43 AM, 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 request take weeks.
> >
> > When I first started using NixOS the tor package was way out of date
> > so I updated it. That went pretty quickly. 3 months ago I did a pull
> > request to update to a recent tor minor release on unstable. This went
> > through ok. I waited a couple of weeks for testing then did a pull
> > request to get it in 14.04;
> >
> > 
> >
> > 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. I
> > haven't bothered trying to do a pull request to update to the new
> > version as there seems no point given that processing pull requests
> > must be overloaded.
> >
> > I can see this only getting worse as more people do pull requests for
> > package updates.
> >
> > New packages are no doubt worse since it takes more analysis of the
> > pull request for someone to approve it.
> > ___
> > 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] systemd in the long run: Revisiting How We Put Together Linux Systems (it's almost Nix...)

[Luca Bruno]

On 02/09/2014 09:06, Nathan Bijnens wrote:
> The systemd kabal just wrote a blog post detailing their long term
> vision on Linux. They have great issue with traditional package
> managers (who can blame them?). 
>
> They sketch a possible solution, based on a whole lof of BTRFS
> subvolumes, sort of used like docker images but linked to each other
> (it sounds as complicated as it is).
>
> http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
>
> I have the feeling they're trying to recreate what already exists and
> works in Nix, I have the feeling they're unaware of this little great OS.
I've replied to G+, and Lennart also replied to me. You can find the
discussion easily on G+. They are well aware of Nix and other systems
such as GoboLinux or 0install and so on.
However this is the direction in the future, more stateless and
reproducible systems. Nix is not the perfection so I don't think yet
another project like this will hurt. Systems are evolving through this
path, so expect to see more and more attempts to achieve what Nix does.

Not only, they may even solve problems at kernel/system level for which
we don't have manpower or enough marketing impact, and Nix may even take
advantage of their work. In other words, let the system itself be more
stateless instead of writing hacks in Nix all the way to make it work
statelessly.

We're heading toward a new paradigm, and having new ideas on how to
solve the same problem is about a necessity I'd say. What tool will
survive in the end I don't know (might even be a Nix fork).

So +1 if they are really able to bring something new to table. -1 if
they don't even solve what Nix is able to solve currently without proper
system support. We'll see.

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

[Nix-dev] systemd in the long run: Revisiting How We Put Together Linux Systems (it's almost Nix...)

[Nathan Bijnens]

The systemd kabal just wrote a blog post detailing their long term vision
on Linux. They have great issue with traditional package managers (who can
blame them?).

They sketch a possible solution, based on a whole lof of BTRFS subvolumes,
sort of used like docker images but linked to each other (it sounds as
complicated as it is).

http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

I have the feeling they're trying to recreate what already exists and works
in Nix, I have the feeling they're unaware of this little great OS.

Nathan.
---
nat...@nathan.gs | nathan.gs
 |
@nathan_gs  | linkedin.com/in/nbijnens
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev