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 importan
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"
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
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 o
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 h
>
> >
> > 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
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 t
>
>
> 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.
___
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
> >
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 i
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 P
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" t
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
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
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.
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.
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 an
>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
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/routi
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:
!con
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
>>> 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.
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 somethi
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://list
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 tha
>> 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). Se
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
>> packag
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 use
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)
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
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 wor
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 ar
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
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
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 ent
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 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 ha
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
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 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 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
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
>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 p
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
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 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 n
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
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
> >> 2
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
>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.n
>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
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
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 opposit
>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.
>> 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
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?
> T
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, an
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 virt
>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
>the
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
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
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
63 matches
Mail list logo
