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
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
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
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
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
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)
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
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
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.
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
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
On Tue, Sep 2, 2014 at 12:51 PM, Eelco Dolstra
eelco.dols...@logicblox.com 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
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
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
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
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
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,
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
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
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
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
On Tue, Sep 2, 2014 at 11:42 AM, Eelco Dolstra
eelco.dols...@logicblox.com wrote:
The best solution is not to use cron but systemd timer units. Just create
units
$out/etc/systemd/system/foo.service and $out/etc/systemd/system/foo.timer.
On NixOS, add the package to the systemd.packages option
On Tue, Sep 2, 2014 at 12:05 PM, Vladimír Čunát vcu...@gmail.com 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
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
Hi,
On Tue, 02 Sep 2014 12:32:06 +0200, Vladimír Čunát vcu...@gmail.com 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
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
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
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
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
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
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
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
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.
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:
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
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 -
On 2 September 2014 14:04, Eelco Dolstra eelco.dols...@logicblox.com 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 :-)
rant
Hell, this is
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.
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
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
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
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
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
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
On 1 September 2014 08:10, Damien Cassou damien.cas...@gmail.com 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
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 damien.cas...@gmail.com wrote:
Hi,
how can nixos users (not the nixos system, but simple users) specify
cron jobs? If a user writes:
$
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
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
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 bjorn.fors...@gmail.com
wrote:
Hi,
Since about a month now, whenever I do nixos-rebuild switch (after
also updating channel sources)
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 bjorn.fors...@gmail.com
wrote:
Hi,
Since about a month now, whenever I do
50 matches
Mail list logo
