Re: [Nix-dev] restarting a mongodb
Tomasz Kontusz tomasz.kont...@gmail.com writes:
I think you can add `systemd.services.mongodb.requires =
[mongo.mount]` to tell systemd to mount (and wait for) /mongo when
starting MongoDB.
You need `systemd.services.mongodb.after = [mongo.mount]`
as well. require does not wait for a dependency to come up
On 07/08/2015 07:13 AM, stewart mackenzie wrote:
Hello all,
So rebuilding our database server with this bit in our config:
```
services = {
mongodb = {
enable = true;
bind_ip = 0.0.0.0;
dbpath = /mongo/db;
};
};
fileSystems./mongo = {
device = /dev/xvdb;
fsType = ext4;
autoFormat = true;
};
```
resulted in this issue:
```
starting the following units: cron.service, fetch-ec2-data.service,
kmod-static-nodes.service, network-local-commands.service,
network-setup.service, nix-daemon.service, nscd.service, ntpd.service,
print-host-key.service, rngd.service, systemd-logind.service,
systemd-modules-load.service, systemd-sysctl.service,
systemd-tmpfiles-clean.timer, systemd-tmpfiles-setup-dev.service,
systemd-udev-settle.service, systemd-udev-trigger.service,
systemd-udevd.service, systemd-vconsole-setup.service
the following new units were started: mongo-bak.mount, mongo.mount,
postfix.service
warning: the following units failed: mongodb.service
● mongodb.service - MongoDB server
Loaded: loaded
(/nix/store/5kvf87w82nk9kfh5p2iamdq7gzc9nfr3-unit-mongodb.service/mongodb.service)
Active: failed (Result: exit-code) since Wed 2015-07-08 12:38:15
HKT; 12ms ago
Process: 15082
ExecStart=/nix/store/ifx5xm0m625gv003v1zsn15pr447zwmf-mongodb-2.6.5/bin/mongod
--quiet --config
/nix/store/18ahs474r1gbpkacy22rl6vy7q8jwxfq-mongodb.conf (code=exited,
status=100)
Process: 15041
ExecStartPre=/nix/store/sig4djkyinm552svg58ryzvs0apxjbf2-unit-script/bin/mongodb-pre-start
(code=exited, status=0/SUCCESS)
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
mongod.27017[15137]: [initandlisten] warning caught exception
(assertion src/mongo/db/dur_journal.cpp:362) in preallocateFiles,
continuing
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
mongod.27017[15137]: [initandlisten] exception in initAndListen: 13516
couldn't open file /mongo/db/journal/j._0 for writing errno:2 No such
file or directory, terminating
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
mongod.27017[15137]: [initandlisten] dbexit:
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
mongod.27017[15137]: [initandlisten] shutdown: going to close
listening sockets...
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
mongod.27017[15137]: [initandlisten] shutdown: going to flush
diaglog...
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
mongod[15082]: ERROR: child process failed, exited with error number
100
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
systemd[1]: mongodb.service: control process exited, code=exited
status=100
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
systemd[1]: Failed to start MongoDB server.
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
systemd[1]: Unit mongodb.service entered failed state.
Jul 08 12:38:15 ip-172-30-0-78.ap-southeast-1.compute.internal
systemd[1]: mongodb.service failed.
warning: error(s) occured while switching to the new configuration
```
It seems the mongo db directory didn't exist yet as it was probably
still formatting.
Please note the autoFormat = true; in the script.
We ran the script immediately afterwards and it ran without failures.
As this is the database (which we're deprecating for datomic) it's important.
How do I avoid such errors in future?
Thanks in advance
Stewart
___
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] multi-user.target must not be After network.target
I agree. But please note that network.target doesn't do much and probably cannot fail. It basically _starts_ networking, but does not wait for anything to come up. Either a static ip address for an interface or _starting_ dhcpcd (without waiting for it to acquire a lease or whatever) is enough to satisfy network.target so there probably isn't a lot to wait for anyway. Luca Bruno lethalma...@gmail.com writes: The multi-user.target must be kept slim, network should not be a prerequisite. I find my server system to have systemctl show multi-user.target|grep After: After=nix-daemon.socket basic.target rescue.service rescue.target swap.target nss-user-lookup.target nss-lookup.target network.target sshd.service [various other services] systemd-user-sessions.service systemd-logind.service getty.target AFAIK fedora does not have network.target in After for multi-user.target. Neither systemd show network in any of the bootup diagrams. If anything goes wrong in the networking phase, the system might become unbootable. Whether networking works or not, the multi-user init should not depend on networking. There are two questions we should answer when writing services: 1. Is it good to run X before multi-user? Yes. 2. Is it necessary to run X before multi-user? No. Choose the latter. Is it necessary to run network before multi-user? No, in most cases. If you have any case where it's really necessary, please explain here, otherwise I will go deep in eliminating this hard dependency. Where can this be a problem? Let's say there's a oneshot service that is After network and Before multi-user. Because by default oneshot services have no timeouts, if the script fails your system will not boot. 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] patch gnupg 2.1.1
We already have the socket activation patch. Karn Kallio just upgraded it. Domen Kožar do...@dev.si writes: In general I'd like to avoid such things and be consistent with upstream. Nix makes is really easy to override such packages for your own use. On Wed, Dec 24, 2014 at 4:29 PM, Karn Kallio tierplusplusli...@skami.org wrote: Attached is a patch which ports the socket activation patch for gnupg to the version 2.1.1 ___ 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
[Nix-dev] escaping /* in emacs nix mode
Hi all, How do I prevent something like this to screw over emacs' font coloring for nix files? foo = '' rm some/path/*.o ''; bar = ... It seems the /* makes everything after it (including bar) appear as comments. Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] escaping /* in emacs nix mode
Ah, that's not too bad. Thanks :) Peter Simons sim...@cryp.to writes: Hi Mathijs, the standard hack to avoid this issue is to write: rm some/path/*.o It sucks, but it works. Peter ___ 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] ghc-mod depends on Wayland
ghc-mod should not have a runtime dependency on emacs at all.
At build-time, emacs-nox sounds fine indeed.
Andreas Herrmann andreas...@gmx.ch writes:
Hello everyone,
Recently, I tried to install the ghc-mod package. I was surprised to
see that nix-env intended to install a _large_ amount of dependencies
down to quite unexpected ones such as Wayland.
I dug into the dependency tree:
nix-store -qR --tree $(nix-instantiate -A haskellPackages.ghcMod
'nixpkgs')
/nix/store/0b7bmyslyidn7iq7bcmxzgxqa0wcd786-haskell-ghc-mod-ghc7.8.3-5.1.1.0-shared.drv
+---/nix/store/gzgrizf2xw537hnnbycbnpbxzrwddxjw-emacs-24.4.drv
| +---/nix/store/lp9z54f5snvrdnvlih815m28lxb5080l-librsvg-2.36.4.drv
| | +---/nix/store/l89khlm6piiilivpnx618w13cfqqj223-cairo-1.12.16.drv
| | |
+---/nix/store/ib90dbdwvijmv44v7ij7ghs1md5nfrf2-mesa-noglu-10.2.6.drv
| | | |
+---/nix/store/gl09hmxv11fvsz2dkr6s6i5xsbvp2c55-wayland-1.6.0.drv
As it turns out this comes from Emacs and the problem is fixed with a simple
package override:
{ pkgs }: {
packageOverrides = self: with pkgs; {
emacs = self.emacs.override { withX = false; withGTK = false; };
}
}
However, I'm wondering if this really is the intended default behavior for
that package. Wouldn't it be better to have ghc-mod depend on a nox-emacs by
default?
Best, Andreas
___
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] Proposal: Standard installation procedure
Have a look at
https://github.com/bluescreen303/bluenix/blob/master/jobs.nix
It's overly complicated and I'm gonna simplify it, but it does build
multiple systems.
Ertugrul Söylemez ert...@gmx.de writes:
On Mon, 20 Oct 2014 09:50:15 +0200
Eelco Dolstra eelco.dols...@logicblox.com wrote:
The basic idea is this: To build a system, you use a standard
function from Nixpkgs and pass it a configuration module. The
result is a derivation that represents a complete self-contained
system.
How does that differ from how NixOS is currently implemented? You can
do:
$ nix-build 'nixpkgs/nixos' -A system
which gives you a complete system in ./result, where
e.g. ./result/init is the stage 2 init script that runs the activation
script and invokes systemd.
How would I refer to multiple systems with different configurations from
within a Nix expression? The change would allow this:
{ system1 = import nixos/build-system.nix module1;
system2 = import nixos/build-system.nix module2;
system3 = import nixos/build-system.nix module3; }
Programs like nixos-rebuild, nixos-install, nixos-container and even
NixOps are really just wrappers around this (except that they add
various levels of provisioning).
They all make the assumption that there is exactly one current system
configuration.
In other words a container-based NixOS system is really just a Nix
store, nothing more. It doesn't need to contain any additional
files or directories and building it does not require us to
understand the complexity of nixos-install, because it will all be
moved to the system initialisation phase.
I don't think nixos-install is that complex. Almost all of the
initialisation it does in the target file system is to make nix-build
work in the chroot. The NixOS initialisation is done by the activation
script.
Check out nixos-container create - it does almost no initialisation
of the container file system, since everything is done by the
activation script during the first boot of the container.
That's already most of what I need. What remains is a way to build
multiple configurations and deploy them to different systems in a
functional way, in particular without environment variables.
Greets,
Ertugrul
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] chromium widevine CDM
Hi all, Recently, netflix enabled support for the chrome browser, running on linux. This means it should now be possible to watch netflix without silverlight in pure HTML5 video. This became possible because w3c's controversial EME (encrypted media extensions) which enables netflix to enforce DRM schemes. Chrome 37 and higher have full support for EME, but EME is only an interface which plugs into the actual DRM component. The key component for this scheme is called widevine CDM, which is also used by youtube for some content. It turns out that the widevine technology was acquired by google and also used for android and chromeOS video streaming. This CDM component is part of the official chrome distribution, but from googling a bit I found it should have been part of chromium by default as well now. I checked our stable, beta and dev releases, but chrome://components does not show it. I suspect we need to (optionally) enable extra flags during building, but I'm not familiar with the build process. Can someone please give me some pointers? it appears there is a third_party/widevine/cdm/widevine_cdm.gyp file in our sources, so that should probably be included somehow. Thanks, Mathijs ___ 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?
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
[Nix-dev] libreoffice build fails without chroot
Hi all, I recently built my systems locally using nixpkgs release 2bc609155d31d214b21a509956504a83d184502b I did some stdenv tweaking so everything built from scratch. All was fine, except for libreoffice. I expected my local changes to be the problem at first, but after some investigation got it to build when turning on chroot-building. Unfortunately, I don't have the exact error message anymore, but it was related to running tests that wanted to write to /var/empty, which was disallowed in non-chroot. This probably got introduced with libreoffice 4.3, as I've never run into it on 14.04 (which has libreoffice 4.0.5). Regards, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Reminder about nixpkgs branches
Vladimír Čunát vcu...@gmail.com writes: Hi, it's not at all so bad as it used to be. Last year it happened we had ~10 months running stdenv-updates that was in the middle getting more and more breakages with added commits. That wasn't good and all agreed on that. I'm glad things currently go a lot smoother. I wasn't trying to point any fingers, just to remain aware of the issues that caused that situation. Extremely short (1 week) one-topic branches may seem ideal, but currently they're very impractical, for several reasons: 1) Testing several changes at once is typically much easier than testing one-by-one, both in build-time and testing-by-using time. 2) Most people can't manipulate Hydra jobsets (including me), which would be needed for each mass-rebuilding update. I can see how this is an issue indeed. 3) Sure I want features stabilized fast, but wishing it isn't enough. Moreover, how much a mass-rebuild change is potentially destabilizing can be tricky to estimate. For example, with freetype I tested building my whole system, including KDE, xfce and several gtk3 apps, and still I didn't discover dozens of build regressions until Hydra tried building all. Those took me a few whole days of work to fix. I don't see how this would become worse by having smaller feature-branches. Something like a freetype-upgrade or fonts-handling branch would quickly show which packages break. Of course that's provided hydra wants to build the branch for you indeed. On 07/23/2014 11:29 AM, Mathijs Kwik wrote: - staging hasn't been merged for 2 weeks That's good, as there are quite a lot of build regressions ATM. Then they should not have been in staging. Eelco's original email about staging clearly stated staging should be mergeable into master at any time and is only meant to get hydra up to speed so the channel won't lag for days on large rebuilds. If stuff causes regressions, revert it and move it to a feature-branch to debug. - big long-running x-updates branch [...] This iteration of x-updates runs for about 5 weeks now (since June 16), which isn't so terribly long. Also, note that it started *before* the staging branch was even announced (~week after that), so I was now finishing it in a-kind-of old-style workflow. Ah, that's quite short indeed :) Please remember, I wasn't pointing fingers. I'm fine with x-updates. Having staging around doesn't change anything in this regard. The changes in x-updates deserve their own branch. I was just worried about x-updates becoming a bit more than just core X11 stuff (mesa, freetype, xorg). IMHO stuff like qt / gtk should not get into x-updates but straight to staging (minor upgrades) or a separate branch (larger upgrades). Note that there are no added stuff in x-updates like enlightenment. That got merged in from master and needed a fixup after x-updates changes. I probably didn't look well enough then. Sorry for the noise. - upgrades that will probably break stuff - add the new version to master - users and maintainers can try if their packages work with it - change the default in a separate branch (ex: gcc-upgrade) - or change the default and pin breaking packages to the previous version I don't remember agreeing on anything like adding updates as new versions instead of changing the old one (maybe I misunderstood you). I rather think it would tend to create a high version bloat (think ffmpeg and worse), as maintainers will rarely be so responsive to update the dependency to newer. The discussion was about llvm that time. And I believe it happened before with gcc in stdenv-updates. There really is no reason to not get a new LLVM version in master, just because some X stuff uses it. A minor llvm upgrade should just go into master or staging. If this potentially breaks X stuff, just add the new version and stick X to the previous version. x-updates can then takes its time to work out how to build against the latest version. I do see the danger of having way too many versions around, so indeed we should be careful about this. However, for non-x stuff like LLVM, I don't see the logic in having users wait for some X stuff to stabilize. All in all, the current situation is way better than it used to be and I'm just nitpicking to find out how others think about this branching stuff. Thanks for your input, Mathijs Vlada ___ 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] Reminder about nixpkgs branches
Some time ago, there was some discussion about stdenv-upgrades and similar long-living branches. I believe we decided: - we would like short-lived, single-issue branches, like: - glibc upgrade - changing the default gcc version. - new packages should just go into master - upgrades that will cause lots of rebuilds, without expected breakage go into staging - upgrades that will probably break stuff - add the new version to master - users and maintainers can try if their packages work with it - change the default in a separate branch (ex: gcc-upgrade) - or change the default and pin breaking packages to the previous version - for releases - default version of a package = latest version - packages that cannot use this latest default should be pinned to the older version - we want this inside all-packages.nix, so it's clear in 1 file which packages need fixing - staging is only meant to give hydra some headstart - a big queue in hydra for master means people cannot easily test/try their changes - reacting to security patches cannot be given priority if there's already a lot of changes building for master - staging should be always mergeable - staging is supposed to be merged every 1 or 2 weeks I'm sending this email because I noticed a few things. - staging hasn't been merged for 2 weeks - big long-running x-updates branch - contains a lot more than just xorg upgrades - upgrades to qt and lots of other non-core-x11 packages - new packages / enlightenment - LLVM 3.4.2 hasn't been available in master for 1 month+ - I understand xorg/mesa depends on it - Why not add it to master, make mesa use the new version in x-updates? - If more packages are expected to break by changing the default shouldn't we just create llvm-upgrade for that? Not to complain :) I'm on 14.04 with some custom cherry-picks myself, so I haven't had issues with the above flow. It's just that I think we can try a bit harder to stick to these guidelines, or discuss them a bit more if people feel they won't work for some reason. Feel free to share your thoughts! Kind regards, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fonts
Kirill Elagin kirela...@gmail.com writes: Why would anyone ever want to add a font to `sytemPackages`? I think this is a leftover from pre-nixos experiences :) I too, when coming from other distros, initially thought everything you use should go into systemPackages. It's the closest thing to installing a package in the traditional sense. Not just that, I thought nixos modules were still supposed to put their configs in /etc somewhere, the only difference was they were now generated. All this is unnecessary, and stuff only gets better without it. I even feel that nixos modules should not add themselves to systemPackages when enabled. Why should every user gain a bunch of binaries in their paths just because there's a LAMP installation on the system? Of course there are still some valid cases. I expect x11 utilities available when the system boots into x11 for example. That's why I'm not too vocal about the current practices :) So, the proper way to install a font globally is to add it to `fonts.fonts`. It should also be possible to install fonts as normal packages into your user environment. If something is wrong, run `fc-cache -v` and look for the dir you expect your font to be in. You should see something like: ~~~ $HOME/.nix-profile/share/fonts/truetype: skipping, existing cache is valid: 1 fonts, 0 dirs ~~~ Then `fc-list` and `grep` for your font. If it's there, then the issue is in your application. -- Кирилл Елагин On Tue, Jun 10, 2014 at 12:05 PM, Wout Mertens wout.mert...@gmail.com wrote: Shouldn't the fonts module add defined fonts to environment.systemPackages then? On Tue, Jun 10, 2014 at 7:03 AM, Michael Raskin 7c6f4...@mail.ru wrote: On 06/10/2014 02:29 AM, Daniel Bergey wrote: A few weeks back I struggled with fonts, asked some questions on IRC, and wrote up what I learned on the wiki: https://nixos.org/wiki/Fonts I should add some notes on packaging fonts there, too. I have no idea why Cantata and chromium aren't picking up fonts, though; I don't use either one. cheers, bergey Ah, I wasn't sure whether I should be adding things to fonts.fonts, clearly I am. I should have a go and getting some extra fonts and putting them there to see if that works. Thank you for putting up the wiki page. If you guys have some knowledge that's not searchable on the web at the moment then please do make wiki pages! It's frustrating to get stuck on something and then asking on IRC for hours, waiting for mailing list replies, source diving, …, knowing that *someone* already knows! Well, not all knowledge is easily transferrable… Maybe the good habit to start would be blindly pasting to the wiki whatever conversation was deemed helpful by the asking person (because arguably the description in it is already somewhat useful and it can be edited later). ___ 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 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Openssl and fast security updates
Alexander Kjeldaas a...@formalprivacy.com writes: On Fri, Jun 6, 2014 at 10:20 AM, Vladimír Čunát vcu...@gmail.com wrote: On 06/06/2014 08:59 AM, Ertugrul Söylemez wrote: When we use priorities generously we could avoid a lot of delay even in less critical cases. The main problem I see is that normally you don't want to release a channel until *all* parts have rebuilt. +1 Rebuilding for a server that runs, say ssh, apache, nginx, postfix and a few such services takes maybe 2% of the time required to build a full desktop distribution. I think being able to release packages used on public facing servers could be prioritized over, say LibreOffice, Qt, Webkit etc. If the system environment is not polluted by the desktop packages, it could be possible to upgrade the system environment before user environments that needs one or two orders of magnitude more time to compile. Calculating the transitive closure for all nixos modules / services run by systemd is one way to prioritize. A populatiry contest could be added to that. That still doesn't solve the question how to do a half build. If there have been 5 commits since the last channel build, and you add an important security fix, there is no way to only build that fix without building the other stuff. A build takes a full nixpkgs checkout and builds that. In its output, it includes a tarball with the nixpkgs tree that was used. The only way to _only_ get the fix is to have a separate git branch (on top of what? release-14.04?) with just these changes and a separate hydra target/job that only builds a few important server packages and does not perform the expensive run-in-vm tests. But even then, I don't know how this would magically end up on people's systems, because I don't think you can merge 2 channels that both provide nixpkgs/nixos. Alexander We do have meta.schedulingPriority, but it's used little, and from earlier discussions I think it's really hard to objectively determine which packages are more important than others ;-) BTW, aborting jobs would need to be done very carefully, because we have some jobs that run for hours, so that could lead to wasting lots of time. Vlada ___ 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] Openssl and fast security updates
Michael Raskin 7c6f4...@mail.ru writes: When we use priorities generously we could avoid a lot of delay even in less critical cases. The main problem I see is that normally you don't want to release a channel until *all* parts have rebuilt. +1 Rebuilding for a server that runs, say ssh, apache, nginx, postfix and a few such services takes maybe 2% of the time required to build a full desktop distribution. I think being able to release packages used on public facing servers could be prioritized over, say LibreOffice, Qt, Webkit etc. If the system environment is not polluted by the desktop packages, it could be possible to upgrade the system environment before user environments that needs one or two orders of magnitude more time to compile. Calculating the transitive closure for all nixos modules / services run by systemd is one way to prioritize. A populatiry contest could be added to that. Maybe having a channel which is a subset of the main channel and includes at least ssh, apache, nginx, postgresql, mysql, and some ftp server would be a nice start? How are people supposed to use that channel? I don't think I can _add_ a secondary channel which provides a conflicting source (nixos). Switching back and forth doesn't sound easy. Also, this would just make your system start to build all the additional packages (not built by this new channel) by itself. No matter how much stuff gets pre-built, a channel always contains a specific nixpkgs version, so with or without binary archives, a nixos-rebuild _will_ build everything for that release. ___ 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] Openssl and fast security updates
Michael Raskin 7c6f4...@mail.ru writes: Calculating the transitive closure for all nixos modules / services run by systemd is one way to prioritize. A populatiry contest could be added to that. Maybe having a channel which is a subset of the main channel and includes at least ssh, apache, nginx, postgresql, mysql, and some ftp server would be a nice start? How are people supposed to use that channel? I don't think I can _add_ a secondary channel which provides a conflicting source (nixos). Switching back and forth doesn't sound easy. Also, this would just make your system start to build all the additional packages (not built by this new channel) by itself. No matter how much stuff gets pre-built, a channel always contains a specific nixpkgs version, so with or without binary archives, a nixos-rebuild _will_ build everything for that release. This will be a channel for server systems. You will checkout master and do a rebuild, and this channel would provide you with prebuilt packages for most of your server needs. So server systems need to start following a channel that does not run lengthy tests? And I think people don't usually use local git repos on their servers. The nixpkgs/nixos tree gets provided by the channel. I just want to run `nix-channel --update nixos-rebuild switch` on my server. Not supply it with a local git checkout that I need to keep up to date and do custom rebuilds against. I do see what you are aiming for, but I don't think there's a clean way to combine it with the default workflow (nicely tested channel which provides nixpkgs/nixos sources and binaries). If there's a way to be able to add _both_ channels, this would be great. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Openssl and fast security updates
Eelco Dolstra eelco.dols...@logicblox.com writes: Hi, On 06/06/14 13:29, Mathijs Kwik wrote: How are people supposed to use that channel? I don't think I can _add_ a secondary channel which provides a conflicting source (nixos). Switching back and forth doesn't sound easy. Switching to another channel is very easy: $ nix-channel --add http://nixos.org/channels/channel-name nixos The command is not the uneasy part :) I just don't think that switching backforth for security-updates is a sane thing to do. Leaving the system at the security channel means you will end up with untested stuff that probably fails the default channel build. I would rather have a secondary channel that gets merged (packageOverrides style) into nixpkgs, which only contains overrides that haven't made it into the main channel yet. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Openssl and fast security updates
Luca Bruno lethalma...@gmail.com writes: On 05/06/2014 17:49, Shea Levy wrote: Pass in the system derivation and use nix-env --set to switch your system to the resultant derivation. I have used it in the past but only for short periods while waiting for a rebuild. Can't it be done in configuration.nix rather than command line? Would it be possible somehow? I think you can use nixpkgs.config.packageOverrides for that. ___ 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] New website
Kirill Elagin kirela...@gmail.com writes: On Sat, May 31, 2014 at 12:19 PM, Michael Raskin 7c6f4...@mail.ru wrote: Carousels with blurbs are often annoying. You start to read and it switches. Just hover it with your mouse and [if it is implemented properly] it won't switch. I've seen carousels that keep switching if you hover them two or three times in my life. That's braindead. And without a mouse? Do I need to tap it every few seconds and hope that does not follow some link? ___ 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] haskell ide
On 05/11/2014 09:50 AM, Roelof Wobben wrote: but can someone explain to me what holes and missing cases are. Sorry, I missed this part of your question somehow. While I agree with Vladimir that there's already an immense lot to learn with just the basic haskell2010 stuff/concepts, these 2 features _are_ useful while learning. And the reason I mentioned these, is because they _are_ tightly bound to advanced editor support. Something which at the moment only emacs and vim provide. Both have to do with getting stuck in a place in your code, where you would like a hint and ask the compiler what do you expect me to type here?. In the case of holes (a ghc 7.8 extension) you can place an underscore somewhere in your code, and ghc will treat it like undefined, but provide good information of what type is needed in that hole and what the other variables in scope are. This is very very helpful if you are nested below top-level (where clause for example) and really teaches you to think about types and just filling the details. See http://www.haskell.org/haskellwiki/GHC/TypedHoles for more info. Missing cases have been available for a long time as well (as compilation warnings) to warn you about cases you forgot to specify. data TrafficLight = Red | Orange | Green handleLight :: TrafficLight - IO () handleLight Red = stopTheCar handleLight Green = hitTheGas In this case, it's clear that this function forgot to specify what to do on orange. Of course examples can get far more difficult when fancier types are involved, or when combinations were tried (Orange | mySpeed 30) but not all of them. Both these things are of course available as console output on compilations so you _can_ use them next to whichever editor you use. But of course if your editor integrates deeply with this machinery (like a REPL/editor conversation), this means you can have your editor fill in the missing cases, or create new cases by just expanding over a variable name via a keystroke or mouse menu. Once again, you can absolutely do without these features. But if you are going to learn a new editor/ide anyway, I would stick to the 2 giants instead of to some glorified notepad with a few fancy buttons which only highlights some keywords, without understanding language structure itself :) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell ide
On Mon, May 12, 2014 at 11:00 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: Honestly I'm not quite sure why this thread ended up on nix-dev rather than haskell-cafe or haskell-beginners. Because we have an opinion about everything :P ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell ide
One (silent) movie can say more than a thousand words: https://www.youtube.com/watch?v=pP7ynVdVY9A That's not haskell you see there, but a language that's close to it. It clearly demonstrates what it means to integrate your editor with your repl/compiler/typechecker. That's really all you should go for, while still keeping everything very transparent and manageable. Complicated IDEs which can setup a project for you almost always fail by being too restrictive or by obscuring things behind tons of dialogs and menus, while at the same time they lack the more helpful/intelligent code editing features. On Mon, May 12, 2014 at 11:04 PM, Mathijs Kwik math...@bluescreen303.nl wrote: On Mon, May 12, 2014 at 11:00 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: Honestly I'm not quite sure why this thread ended up on nix-dev rather than haskell-cafe or haskell-beginners. Because we have an opinion about everything :P ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell ide
On Mon, May 12, 2014 at 11:18 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: The downside is the crowd of vim users that complain about basically having to use emacs for Agda ;) Idris does this way better in this respect. Also, for haskell, ghc-mod works with both emacs and vim. So it's really just Agda who has an ugly emacs-only solution (I believe they generate lisp code to execute). It's a great mode but I just hope one day copying and pasting works in it properly one day. I'm an emacs user at least until Yi is at acceptable level for me to use for everything. Heh, I didn't know about Yi yet. Sounds promising. Although I don't expect they will finish soon _and_ have some org-mode replacement ready. Damn emacs lock-in :P ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] network interface naming
Hi all, Some time ago, udev changed to stable interface names for networking. So instead of eth0 and eth1 you would get enp0s3 (wired) and wlp1s5 (wireless) for example. And I think there existed a (nixos?) option to stick to the previous behaviour for some time. I recently upgraded an older system to our new 14.04 release and noticed it now uses the new naming scheme, while it previously still used the old scheme. I could not find the use-old-scheme option, nor did I enable such a thing in the past. I do not mind the new names (actually, I prefer them), so I changed all references to the new names (firewall rules, custom networking setup, vpn tweaking). This works fine on the real system, but I run into issues when running such configuations in a vm. It seems qemu/kvm still has the guest create eth0. Now, I can of course parameterise the entire config by an interface name to easily modify the configuration for a vm build. But this is somewhat ugly, especially because of the networking.interfaces.name. attrset. But I'm hoping there's a better/nicer way to either force some interface name to vms, or have the real system stick to the old naming scheme. Any pointers? Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] network interface naming
Lluís Batlle i Rossell vi...@viric.name writes: networking.usePredictableInterfaceNames = false; :) I must have been sleepy A must since it 'appeared' and got the default true! :) I wonder why this didn't affect me sooner. My system was upgraded just 2 or 3 months back, but kept on using 'eth0' (as that's what I used in network.interfaces and other places). Probably systemd-212 became a bit more aggressive about interface naming. Anyway, thanks! On Sun, May 11, 2014 at 10:29:45PM +0200, Mathijs Kwik wrote: Hi all, Some time ago, udev changed to stable interface names for networking. So instead of eth0 and eth1 you would get enp0s3 (wired) and wlp1s5 (wireless) for example. And I think there existed a (nixos?) option to stick to the previous behaviour for some time. I recently upgraded an older system to our new 14.04 release and noticed it now uses the new naming scheme, while it previously still used the old scheme. I could not find the use-old-scheme option, nor did I enable such a thing in the past. I do not mind the new names (actually, I prefer them), so I changed all references to the new names (firewall rules, custom networking setup, vpn tweaking). This works fine on the real system, but I run into issues when running such configuations in a vm. It seems qemu/kvm still has the guest create eth0. Now, I can of course parameterise the entire config by an interface name to easily modify the configuration for a vm build. But this is somewhat ugly, especially because of the networking.interfaces.name. attrset. But I'm hoping there's a better/nicer way to either force some interface name to vms, or have the real system stick to the old naming scheme. Any pointers? Thanks, Mathijs ___ 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] haskell ide
Roelof Wobben r.wob...@home.nl writes: Hello, I get the impressing that there are a lot of Haskell programmers here. I wonder which ide everyone use except vim and emacs. I find them not well to use. I looked at leksah in the past. It's quite nice for starters. And there's some haskell plugin for eclipseFP I think. Of both, I'm not sure if they are still maintained. As Haskell is moving more and more towards the interactive refinements style of programming (like Agda and Idris have) by supporting things like holes and suggesting missing cases, I would really suggest you give emacs or vim another try, or you will probably miss out on all the action :) Most other editors are just not flexible/powerful enough for this kind of fine-grained editor/compiler/typechecker interaction. All other IDEs/editors I've seen for haskell will only give some syntax coloring and local name completion with very basic error handling. If that's all you need, you can probably use gedit (gnome) or kate (kde) as well. Roelof ___ 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] haskell ide
Yes, it really doesn't matter much. Haskell is a very lightweight language to edit by hand. I mean that compared to other languages there are not a lot of braces, curly braces and ceremonial keywords all over the place. So every simple notepad will suffice without giving you lots of typing work. Some support for indentation would be nice, because of haskell's layouting rules. If you are just starting, you should really focus on the language itself and on understanding the error messages you get from the compiler. Advanced IDE stuff will be nice later on, but won't help for learning the language and might even obscure things. On Sat, May 10, 2014 at 10:24 PM, Roelof Wobben r.wob...@home.nl wrote: Mathijs Kwik schreef op 10-5-2014 21:23: As Haskell is moving more and more towards the interactive refinements style of programming (like Agda and Idris have) by supporting things like holes and suggesting missing cases, oke, I do not know Agda and Idris and Im a super begunner in haskell so holes and suggesting missing cases says nothing to me. So in your oponion something like fpcomplete ( a cloud ide ) is also not good. Roelof ___ 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] Libreoffice fails to build
Raahul Kumar raahul.ku...@gmail.com writes: Curl -04 works. My ISP is Dodo, what should I tell them is broken with their ipv6 setup? It's not necessarily your ISP. It can be a misbehaving home-router as well. Your computer obviously thinks it has ipv6 connectivity beyond link-local (your ethernet/wireless subnet), while in reality it doesn't. If you are not aware of ever trying to configure anything related to ipv6 (static address, tunneling account), you probably have a home router that is advertising IPv6 routing capabilities without having a proper uplink itself or everything gets firewalled. It's also possible your ISP is supplying you with a global IPv6 address/subnet without routing traffic for it, but that's not very common yet (at least in EU/US). An easy workaround might be to just disable IPv6 (nixos has an option for it networking.enableIPv6 which is on by default) until it's properly supported by your ISP and home router, but you might want to investigate, because this will get back to you. You might be wondering why wget does work while curl doesn't. Both perform a DNS lookup (for dev-www.libreoffce.org), but in case they get multiple answers (both IPv4 and IPv6 addresses), curl only tries the first one, while wget tries them all until one succeeds. While the wget behaviour seems nice in general, it's actually covering up broken setups while imposing a slowdown for each and every connection to an IPv6 enabled host (because of the retry). I think if things are broken, they should be fixed, instead of worked around :) Aloha, RK. On Sat, Apr 26, 2014 at 9:59 PM, Mathijs Kwik math...@bluescreen303.nlwrote: Raahul Kumar raahul.ku...@gmail.com writes: Thanks Kirill, that solved the temp problem. What would be nicer is if Nixos used a backup downloader, like wget in case curl fails for some reason. I don't know where to start figuring out why curl fails to connect. Also why only libreoffice and it works fine with all the others. can you please try curl -O4 ' http://dev-www.libreoffice.org/src/1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz ' If that works, there's something wrong with the ipv6 setup in your home/ISP/work. On Fri, Apr 25, 2014 at 7:58 PM, Kirill Elagin kirela...@gmail.com wrote: I don't know why it fails either, but you can try to download using wget or whatever you like and then nix-prefetch-url it via file: url. On Apr 25, 2014 12:24 PM, Raahul Kumar raahul.ku...@gmail.com wrote: trying http://dev-www.libreoffice.org/src/1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- 0:02:06 --:--:-- 0curl: (7) Failed to connect to dev-www.libreoffice.orgport 80: Connection timed out error: cannot download xmlsec1-1.2.14.tar.gz from any mirror builder for `/nix/store/824qydk3gyxrcmimglfq9dslfr9qg8f1-xmlsec1-1.2.14.tar.gz.drv' failed with exit code 1 However, the file is available, I can download it using wget. I don't know why curl fails - err msg claims connection timed out. Aloha, RK. ___ 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] Cinnamon update to 2.2
Roelof Wobben r.wob...@home.nl writes: Hello, I need to update Cinnamon to version 2.2 Arch and Fedora have already updated it so the old patches cannot be found. Arch (and probably Fedora as well) keep a full history of their build scripts and patches. For example: https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/cinnamon-session Roelof ___ 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] python3.4-bedup-20140206 doesn't build
Raahul Kumar raahul.ku...@gmail.com writes: Hi guys, I tried to get bedup running, refuses to build. Any idea what's wrong with this package? Yes, I copied the private github url and used nix-prefetch-git locally. Should be fixed now. exporting g...@github.com:g2p/bedup.git (rev 80cb217d4819a03e159e42850a9a3f14e2b278a3) into /nix/store/j3bz1nhqxgpq5f11v7qbpzr02pnp0liy-git-export Initialized empty Git repository in /nix/store/j3bz1nhqxgpq5f11v7qbpzr02pnp0liy-git-export/.git/ error: cannot run ssh: No such file or directory fatal: unable to fork error: cannot run ssh: No such file or directory fatal: unable to fork Unable to checkout 80cb217d4819a03e159e42850a9a3f14e2b278a3 from g...@github.com:g2p/bedup.git. builder for `/nix/store/4sihkx15ygp5n42ykms46l7b15qd0k9s-git-export.drv' failed with exit code 1 cannot build derivation `/nix/store/2d4pk9rfji9iml59s0xkhhga43cqzy3x-python3.4-bedup-20140206.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/9dhy1wq67g32cv99ap120ncicddsb5xa-system-path.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/m5vbabdv4lawsb1jl7mjqclm6wznyli2-nixos-14.04pre42122.e572b5c.drv': 1 dependencies couldn't be built error: build of `/nix/store/m5vbabdv4lawsb1jl7mjqclm6wznyli2-nixos-14.04pre42122.e572b5c.drv' failed Aloha, RK. ___ 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] Deduplication
Raahul Kumar raahul.ku...@gmail.com writes: Thanks Kirill, I'll go email the BTRFS devs, see if they have a fix for this hardlink issue. Anyone else got a workaround for the dedup issue with Btrfs and nixos? I think you misunderstood the output. There are X files with equal contents out of Y files in total is just the statistic that gets reported on finish. It does not mean there are now still X files that can be deduplicated. When all goes well, it means X files have all now been deduped. On ext4 you get this same message as well. So you can't really get an indication of the still-duplicate files that are left because of btrfs' limit. But I think it's safe to just ignore it. Files that have 3000+ (current btrfs max hardlink limit is just under 4k) copies are probably just empty files/dirs anyway. Aloha, RK. On Mon, Apr 14, 2014 at 4:30 PM, Kirill Elagin kirela...@gmail.com wrote: I've just googled a bit, and you are probably hitting this: http://lists.science.uu.nl/pipermail/nix-dev/2012-October/010017.html. So, you don't get around it. Or consider changing your FS ;). -- Кирилл Елагин On Mon, Apr 14, 2014 at 10:04 AM, Raahul Kumar raahul.ku...@gmail.comwrote: I followed Eelco's suggestion of running nix-store --optimise. Output: `/nix/store/.links/09d75zzfhid0v9azq4qpprhfpfyjb27b89qnarqwz6bqgjxl7pq6' has maximum number of links 172.20 MiB freed by hard-linking 34905 files; there are 351670 files with equal contents out of 365448 files in total There are a lot files still duplicated. How do I get around the file has maximum number of links error? Aloha, RK. ___ 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] Cinnamon 2.2.0
Roelof Wobben r.wob...@home.nl writes: Hello, I saw that in the last few hours everything of Cinnamon is updated to 2.2.0. Is it wise to stay on the 2.0.14 version and update till everything is ported or it is wise to update everything to the new version and port that version. If the structure of the components did not change much, upgrading is probably not much more than changing the hash and maybe adding an extra dependency. If it's more than that, you should probably complete 2.0.14 first. Once everything is in a working state, it's much easier to upgrade and assess it went OK. Roelof ___ 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] systemPackages vs. services.dbus.packages
Vladimír Čunát vcu...@gmail.com writes: On 04/07/2014 11:36 AM, Kirill Elagin wrote: So, the question is: what is the purpose of having services.dbus.packages if those configs are considered anyway due to packages being in systemPackages? AFAIK there are cases where packages are not put into systemPackages, only to services.dbus.packages. (But that can't prevent the users or other options from independently adding the very same package to systemPackages.) I use that as much as possible. There's really no need for a lot of packages to be in systemPackages or in some user profile if they only provide a service and don't have lots of often-used CLI tools. Same goes for udevPackages. However, wouldn't it be possible to uniq/nub these lists on evaluation? It's perfectly functional/declarative, but I don't know if derivations are comparable (for equality). Vlada ___ 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] systemPackages vs. services.dbus.packages
Kirill Elagin kirela...@gmail.com writes: Yes, we can nub them (to be precise, it makes sense to subtract `systemPackages` from `dbus.packages`), those lists contain package names, not derivations. Why should systemPackages be subtracted? There are packages that I want in my path _and_ as a dbus service. But, why not simply require all the packages that provide DBus services to be added to `dbus.packages`? That way we avoid duplication and have an explicit list of packages that have something to do with DBus (it might be useful in the future). Adding packages to dbus.packages will cause them to be installed. I do not want each and every dbus-providing package to get installed and activated. -- Кирилл Елагин On Tue, Apr 8, 2014 at 11:29 PM, Mathijs Kwik math...@bluescreen303.nlwrote: Vladimír Čunát vcu...@gmail.com writes: On 04/07/2014 11:36 AM, Kirill Elagin wrote: So, the question is: what is the purpose of having services.dbus.packages if those configs are considered anyway due to packages being in systemPackages? AFAIK there are cases where packages are not put into systemPackages, only to services.dbus.packages. (But that can't prevent the users or other options from independently adding the very same package to systemPackages.) I use that as much as possible. There's really no need for a lot of packages to be in systemPackages or in some user profile if they only provide a service and don't have lots of often-used CLI tools. Same goes for udevPackages. However, wouldn't it be possible to uniq/nub these lists on evaluation? It's perfectly functional/declarative, but I don't know if derivations are comparable (for equality). Vlada ___ 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] Repo for incomplete/unmaintained work
Shea Levy s...@shealevy.com writes: Hi all, Currently we have quite a lot of unmaintained, broken, or work-in progress components in nixpkgs. It would be great if we could get to the point where everything in nixpkgs was expected to work and be maintained, but part of that I think is having a place for this other work that isn't quite up to scratch but still may be valuable can live (it could also include experimental coding styles, proprietary services, etc.). Thoughts on the idea? Any idea for a name for the repo? I propose nixnut :P But that might not be clear to non-dutch-speaking users. The idea itself sounds good. But isn't the `broken` attribute aiming for something similar? Eelco, would you be able to make the repo if you think this is a good approach? ~Shea ___ 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] after install problem
Roelof Wobben r.wob...@home.nl writes: Roelof Wobben schreef op 5-4-2014 18:27: Hello, I booted from the minmal cd and installed according to the manual, On the configuration.nix I enabled X and KDE. But after the reboot it started up and I see the prompt. I tried startx but then I see a message file not found. How to solve this ? Roelof It looks if kde is not installed at all. systemctl kdm.service start gives a message that the kdm.service is not found. Is there a way I can install kde manually See http://bit.ly/1ehKjcm first link. There is even a section on kde. nix-env -i kde fails because there is not derivation called kde. Roelof ___ 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] chromium fails to build
Bjørn Forsman bjorn.fors...@gmail.com writes: Hi all, Does anyone know what's up with the failing chromium build? I reverted the upgrade for file locally. This fixes chromium. http://hydra.nixos.org/build/9819641/nixlog/1/tail-reload Build error: building /nix/store/9xzfnd38zpxcl840024220a6wi0kzsw6-chromium-33.0.1750.152 unpacking sources unpacking source archive /nix/store/qbmp81w0fvjsp8ibk9gw89k2al6873as-chromium-source-33.0.1750.152 source root is chromium-source-33.0.1750.152 patching sources configuring Updating projects from gyp files... gyp: Call to '../build/linux/python_arch.sh /usr/lib/libpython2.6.so.1.0' returned exit status 1. while trying to load /tmp/nix-build-chromium-33.0.1750.152.drv-0/chromium-source-33.0.1750.152/build/all.gyp builder for `/nix/store/101sh751v91zfws8k9gjcz4z2rqqp111-chromium-33.0.1750.152.drv' failed with exit code 1 error: build of `/nix/store/101sh751v91zfws8k9gjcz4z2rqqp111-chromium-33.0.1750.152.drv' failed The changes that (supposedly) caused it to break look quite irrelevant: https://github.com/NixOS/nixpkgs/compare/c814dab2eeb97c15f4a309e69435988fc3e65c6a...58857096fb679848730892d3f939be471e185cd1 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] ntp monlist ddos vulnerability
After some more investigation, I think we should just add disable monitor to nixos' ntpd.conf. It seems the monitoring functionality is not needed for normal operation so it was a mistake (upstream) to enable it by default. However, it is not a security vulnerability for the system itself, so no patch/fix is done for stable. Development releases seem to happen way too often, so tracking those is not a good solution. Since we already suffer from option-bloat, I suggest we add the line unconditionally, unless someone actually uses this feature. In that case I'm happy to create an option with a big fat warning description. Please let me know. On Mon, Feb 24, 2014 at 5:27 PM, Mathijs Kwik math...@bluescreen303.nl wrote: Hi all, Our ntpd version (stable, 2011) contains a feature called 'monlist', which is enabled by default. This feature has recently been abused by huge ntp-amplification ddos attacks. However, the vulnerability has only been fixed in the development version and security firms recommend upgrading to that (at least v4.2.7p26, 03/2010 release, so not really bleeding edge). Another option is to disable the problematic 'monlist' service in our current version by adding a line to the config file disable monitor. However, the replacement 'mrulist' functionality is only available in the development release, so just disabling monlist probably cripples operations (I'm not very familiar with ntp). Given the fact that the stable release hasn't been updated with a fix, I would suggest we start following development releases for ntp, because there are probably other issues lurking in stable. Does anyone object to that? Or does anyone propose a different solution? http://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks Regards, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ntp monlist ddos vulnerability
Eelco Dolstra eelco.dols...@logicblox.com writes: On 24/02/14 17:27, Mathijs Kwik wrote: Our ntpd version (stable, 2011) contains a feature called 'monlist', which is enabled by default. This feature has recently been abused by huge ntp-amplification ddos attacks. AFAIK, this commit works around the problem: https://github.com/NixOS/nixpkgs/commit/9e7fe29e416736bf2be5aeaf7adbad05d4e175cf I think it needs 1 more line: disable monitor My hosting provider sent me this: (in dutch) https://www.transip.nl/vragen/583-bescherm-mijn-server-tegen-misbruik Do you think we should add that too? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ntp monlist ddos vulnerability
sorry for the noise, we are fine. The link in your commit explains it. noquery does the trick indeed. On Mon, Feb 24, 2014 at 7:22 PM, Mathijs Kwik math...@bluescreen303.nl wrote: Eelco Dolstra eelco.dols...@logicblox.com writes: On 24/02/14 17:27, Mathijs Kwik wrote: Our ntpd version (stable, 2011) contains a feature called 'monlist', which is enabled by default. This feature has recently been abused by huge ntp-amplification ddos attacks. AFAIK, this commit works around the problem: https://github.com/NixOS/nixpkgs/commit/9e7fe29e416736bf2be5aeaf7adbad05d4e175cf I think it needs 1 more line: disable monitor My hosting provider sent me this: (in dutch) https://www.transip.nl/vragen/583-bescherm-mijn-server-tegen-misbruik Do you think we should add that too? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] haskellPackages_ghc763_profiling
Hi all, Before nixos, I remember that enabling profiling in .cabal/config lead to double compilation times, because things got compiled twice. Once normal/optimized, and once with profiling info. With nixos, I wired haskellPackages to haskellPackages_ghc763_profiling through packageOverrides, but I don't see things get compiled twice. Did something change regarding this? Or have I now ended up with only profiling versions (potentially slower) of all haskell packages? Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nixpkgs monitor moved!
I have seen these commits. Is there anything we (maintainers) should do to get our packages monitored? Some extra meta info to help discovery? And thanks phreedom for creating this! I think this will eventually save a lot of time for everyone. Rob Vermaas rob.verm...@gmail.com writes: Hi guys, The Nixpkgs monitor server made by phreedom (Evgeny Egorochkin) has moved to a new (easier to remember) URL: http://monitor.nixos.org/ I have started using it already to update packages. It provides a nice overview of packages that might have updates, you can download patches for updates, it has links to possibly connected CVE items. All in all, in my opinion we should all start using this awesome project and give phreedom credits, and feedback to make it even better and more useful! Cheers, Rob ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] /tmp
Hi all, Is there a way to tell nix(-daemon) to build somewhere other than /tmp ? I'm currently using a tmpfs there, but for big rebuilds(stdenv) this won't do. Make the tmpfs too small and big builds will run out of space. Make the tmpfs too large and hit swap, rendering the system unusable for minutes in bad cases, which is not nice if you are using it in the mean time. Of course I can keep build-max-jobs low, but for most of the build, it is very capable of building 8 derivations simultaneously without issues, it's just that big ones like xulrunner, ghc, mongodb, libreoffice hog up everything once they come along. Of course I can choose to not use a tmpfs on /tmp, but I'm very happy with it for almost everything else (including nix building). It's really just these huge full-system-rebuilds that I need to work around. Any suggestions? Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] overriding node packages
Hi all, It seems the way we currently handle nodePackages has become a bit monolithic, making it very hard to override the stuff that gets generated by npm2nix. 2 simple reasons why one wants to override: - Add an optional dependency (runtime check) - Patch/disable tests (that got enabled by recent prepublish change) The packages themselves are overridable, but there is no clean way to plug those overrides back into self, other than a cumbersome manual deep-merge through packageOverrides [1]. This is necessary in case you need to fix a dependency that is used by other generated packages. node-packages.nix has a comment line mentioning manual packages could go below it, but those will be overriden (by //) by anything in node-packages-generated.nix and the current by-spec and by-version attrset structures complicate this even further. I can think of 3 solutions: - provide more hooks in the generated stuff we already do this for nativeDeps, but we can extend this for optional dependencies, flags and preConfigure hooks. This will work, but gives a lot of dynamic checks and makes the generated sources quite verbose. - store hooks/overrides in npm2nix this is the route that cabal2nix uses. Main issue is that source/logic will be in 2 places and npm2nix itself becomes a cyclic dependency even more. People using an older version of npm2nix might overwrite the customizations any time they add a new package or perform upgrades. - something involving recursiveUpdate. But the lazy self seems to become problematic in case you want to refer to the original. These solutions feel suboptimal. I think this kind of thing (nested attrset override / looped-back self) happens more, but the current best practise changed a few times over time. Does anyone know of a way to improve the current situation? Thanks, Mathijs [1] https://github.com/bluescreen303/bluenix/blob/master/pkgs/overrides.nix scroll down to nodePackages. first 2 overrides are just for the sed fix, last one adds 1 optional dependency ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [***SPAM***] Re: Fix libreoffice build
I tried 0.5.0, 0.5.1 and 0.7.0 but they all have the same issue. This patch fixes the problem for all of them, but as libreoffice advises the use of 0.3.0 (which we had), we better stick to that. On Sun, Dec 22, 2013 at 1:50 AM, phree...@yandex.ru wrote: I seem to have failed to notice that I broke LO. Have you tried updating liborcus instead? ___ 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] npm prepublish hook
On Tue, Dec 10, 2013 at 3:01 PM, Shea Levy s...@shealevy.com wrote: maintaining a manual list, as unfortunate as that sounds. Hopefully this will be fixed soon in most packages. For packages that are installed from a tarball (which is most), issues with read-only paths shouldn't come up. If there's a common set of utilities always expected in $PATH we may as well resign ourselves to adding those to buildInputs unconditionally. The 2 cases I found are: bytebuffer-2.1.0: bug in the package itself, wants to run hardcoded path ./node_modules/testjs/bin/testjs but of course this path is not available in the (extracted) tarball. protobufjs: runs tests like test1 tests/test1.out, which will fail because tests is not writable, so the issue _does_ come up. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] npm prepublish hook
I'm not gonna push broken stuff :) On Tue, Dec 10, 2013 at 3:23 PM, Shea Levy s...@shealevy.com wrote: On 12/10/2013 09:16 AM, Mathijs Kwik wrote: On Tue, Dec 10, 2013 at 3:01 PM, Shea Levy s...@shealevy.com wrote: maintaining a manual list, as unfortunate as that sounds. Hopefully this will be fixed soon in most packages. For packages that are installed from a tarball (which is most), issues with read-only paths shouldn't come up. If there's a common set of utilities always expected in $PATH we may as well resign ourselves to adding those to buildInputs unconditionally. The 2 cases I found are: bytebuffer-2.1.0: bug in the package itself, wants to run hardcoded path ./node_modules/testjs/bin/testjs but of course this path is not available in the (extracted) tarball. protobufjs: runs tests like test1 tests/test1.out, which will fail because tests is not writable, so the issue _does_ come up. Hmm, that first one could be fixed by running the npm install in $out since we've already set up the deps there. Not sure about the second one, I can't seem to find it in nixpkgs? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] branches and rebuilds
Hi all, I would like to give my opinion on the current flow we seem to have and would like to hear your opinions. I've been trying to find my own flow of staying up-to-date, submitting changes and keeping my unplanned nix-improvement/fixing time below a certain level. To do this, I've been creating my own stable branches on a monthly basis, while only doing master stuff when I have some time, and only in a virtual machine, so it doesn't disrupt my normal setup. Like many others, I soon needed stuff that was only available in stdenv-updates (like gcc 4.8) or in x-updates (llvm 3.3). In both cases, there wasn't a real reason for those to be in a separate branch, as they could just as well be pushed to master, without switching the default just yet. Anyway, I decided to just merge x-updates into my master and fix the stuff that broke for me. Usually, stuff was easy to fix by upgrading or adding some patch, but in problematic cases I just added the previous version from master and made problematic packages use these. Same goes for x-updates. In the end, everything worked fine and I've actually been running with stdenv-updates+x-updates for 2 months now. I have some upgrades and new packages, but committing them back to nixpkgs becomes more problematic now, because I need to check whether they still work on master or whatever branch. They might depend on something that's only in 1 branch yet, or break with the old/current versions available. I think others will recognize these things. Now, what bothers me is the fact that these feature-branches seem to live like a full year before getting merged, and stuff gets piled onto them, just to avoid rebuilds on master. Other reasons might be that developers themselves are running and testing these branches on their every-day systems so it's actually easier to commit there because they might not work on master yet. I think that watch out for causing rebuilds should not be a reason for committing stuff to some other branch (and waiting 6+ months for it to be generally available). If rebuilds are an issue, I think they should be tackled in hydra somehow (low prio for these changes) or - if that's not around the corner just yet - be put on a very short-lived (1 or 2)weekly-merged causes-rebuilds branch, instead of to a this might break a lot of stuff so we make a big project out of it branch. The fact that I've been running my stuff on stdenv+x for some time must mean there aren't fundamentally broken :) My stuff is actually quite a lot, as I build for a laptop, a desktop and 2 servers: LAMP, vpn, kde desktop, parts of xfce, firefox, libreoffice, chromium, node+npms, lots of haskell libs/envs, bunch of databases. I think these branches should just be merged and we shouldn't allow such long-running branches to spring up again. First of all, we now have a stable branch. Furthermore, with nix, it's almost always easy to quick fix some important package by just keeping an old version of some dependency around. Of course maintainers should focus a bit on keeping these separate versions to a minimum (hello boost and ffmpeg :), but I think it's way better to just upgrade something and find 90% working (sticking the 10% to the old version) than to have 90% wait for the other 10% to get fixed. Keeping things more as 1 codebase will improve the general workflow. Massive find-and-replace style changes won't just be applied to 1 branch (leading to merge conflicts, or forgetting stuff that will get merged later) and because people see future work in 1 place, it's probably more clear to them that the patch they are adding to version X should also be considered for version Y, because otherwise it will be lost when Y becomes default. Currently, Y is in some other branch you haven't payed attention to yet, so it's up to the people working on that branch to find out about your patch and be smart enough to apply it to their current version as well. But most people (including me) who merge master into some other branch only fix merge conflicts and don't bother with logic like this got applied to all things X, we have an additional X in our branch so that should probably get it too. All in all, I think we currently have too many tools to make sure stuff won't disrupt anything else. In my eyes, this complicates things more than we get back out of it. I would rather see master turned into a more hack/break/fix style branch, with only short-lived (1 month?) feature branches that are really just there for 1 thing and are not abused just to save rebuilds. People can always decide to work from stable + their own cherry-picks if they want a bit more stability. Of course there should be some rules like a stabilization period before a new stable release, say 1 or 2 weeks where people are not allowed to push anything disruptive. Also: breakage should be avoided mostly, so no pushing of half-finished changes. But pushing some upgrade (which you test yourself with 1 or 2 dependent packages)
Re: [Nix-dev] add xslt to a derivation
$ grep 'xslt.*=' pkgs/top-level/all-packages.nix
libxslt = callPackage ../development/libraries/libxslt { };
docbook_xml_xslt = docbook_xsl;
first result
On Wed, Dec 4, 2013 at 1:31 PM, Roelof Wobben rwob...@hotmail.com wrote:
when compiling cinnamon-control-center I see this message:
checking whether gcc understands -Wno-sign-compare... yes
checking what warning flags to pass to the C compiler... -Wall
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare
checking what language compliance flags to pass to the C compiler...
checking for X... no
checking for glib-mkenums...
/nix/store/1kh7gl673vp4zpilrvsi4cmxwk7il27n-glib-2.36.4/bin/glib-mkenums
checking for xsltproc... no
configure: error: xsltproc is required to build documentation
builder for
`/nix/store/m6mhqzk71kd6y5ci9qylsjknffcy9bqc-cinnamon-control-center-2.0.9.drv'
failed with exit code 1
error: build of
`/nix/store/m6mhqzk71kd6y5ci9qylsjknffcy9bqc-cinnamon-control-center-2.0.9.drv'
failed
but if I add xslt to the buildInputs I see that xsltproc is not known as a
package.
How to solve this ?
Roelof
___
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] gnome-menus
inherit it from gnome2 or gnome3 On Wed, Dec 4, 2013 at 1:54 PM, Roelof Wobben rwob...@hotmail.com wrote: How can I add this the best to a derivation. Just add gnome_menus do not work. You will see this error : error: an anonymous function at `/home/roelof/nixpkgs/pkgs/desktops/cinnamon/cinnamon-control-center.nix:1:1' called without required argument `gnome_menus' Roelof ___ 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] what is wrong with this ?
Roelof Wobben rwob...@hotmail.com writes:
I need gnome-common as a dependency.
So i add this to all-packages.nix :
cinnamon = recurseIntoAttrs {
cjs = callPackage ../desktops/cinnamon/cjs.nix { };
cinnamon-desktop = callPackage ../desktops/cinnamon/cinnamon-desktop.nix{
inherit(gnome) gnome_common };
};
missing semicolon after gnome_common
but now I see this error message:
error: syntax error, unexpected '}', expecting ID or OR_KW or ';' or '', at
`/home/roelof/nixpkgs/pkgs/top-level/all-packages.nix:9572:35'
What did I do wrong ?
Roelof
___
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] NixOS 13.10
https://github.com/bluescreen303/nixpkgs/commit/e5bcb378fae0e38379b0b365ab2a2431ae5d6c07 On Fri, Nov 1, 2013 at 11:10 AM, Oliver Charles ol...@ocharles.org.uk wrote: On 10/31/2013 11:07 PM, Mathijs Kwik wrote: Congratulations on another great milestone :) It will be interesting to see how this stable experiment goes. But together with the new nixos-rebuild profiles, I think this will be very smooth. What are the new nixos-rebuild profiles? Where could I read about these? - ocharles ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS 13.10
oops, linked to own fork, ah well :) it's the same thing On Fri, Nov 1, 2013 at 11:51 AM, Mathijs Kwik math...@bluescreen303.nl wrote: https://github.com/bluescreen303/nixpkgs/commit/e5bcb378fae0e38379b0b365ab2a2431ae5d6c07 On Fri, Nov 1, 2013 at 11:10 AM, Oliver Charles ol...@ocharles.org.uk wrote: On 10/31/2013 11:07 PM, Mathijs Kwik wrote: Congratulations on another great milestone :) It will be interesting to see how this stable experiment goes. But together with the new nixos-rebuild profiles, I think this will be very smooth. What are the new nixos-rebuild profiles? Where could I read about these? - ocharles ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] type for path-or-string ?
Hi all,
I used to put local/relative paths in my openssh.authorizedKeys.keyFiles.
Basically, I store the public ssh keys in the git repo that contains
my configuration.nix so I point to them by [ ./laptop.pub ./server.pub
]
However, the type for this option got set to listOf str, breaking my setup.
Changing to ./laptop.pub of course won't work. I tried
${./laptop.pub} as well, but that moves the file to the nix store,
then complains about the path referencing other paths.
So I changed the type of this option to listOf path locally.
Is there a way to allow both? Something like listOf (Either str path)?
Thanks,
Mathijs
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS 13.10
Congratulations on another great milestone :) It will be interesting to see how this stable experiment goes. But together with the new nixos-rebuild profiles, I think this will be very smooth. On Thu, Oct 31, 2013 at 11:59 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, I'm pleased to announce the availability of the first stable branch of NixOS, namely 13.10 (a.k.a Aardvark)! The purpose of this branch is to receive only conservative changes, such as bug fixes, safe minor package upgrades and new packages [1]. This is important for people who want to use NixOS in a production environment: you do want to get (security) fixes, but you don't want to be afraid of the system changing in fundamental ways, as may be the case on the master branch. Note that NixOS 13.10 is a branch, not a release in the sense of a static revision. Just like the NixOS master branch, it receives updates, just safer ones. The idea is to maintain this branch at least until the next stable branch (14.04?) is created. The 13.10 branch lives here in GitHub: https://github.com/NixOS/nixpkgs/tree/release-13.10 It also has an associated channel: http://nixos.org/channels/nixos-13.10 (Notice that versions of releases in the 13.10 channel have no pre string, indicating they're stable versions, such as 13.10.35427.6fda96b.) If you want to switch an existing machine from the nixos-unstable channel over to the 13.10 channel, just do: $ nix-channel --add http://nixos.org/channels/nixos-13.10 nixos After this, subsequent calls to nixos-rebuild switch --upgrade will fetch from the nixos-13.10 channel. See here for details on switching between NixOS channels: http://nixos.org/nixos/manual/#sec-upgrading Like the nixos-unstable channel (which gets build from the master branch), the 13.10 channel is updated only after Hydra has built all packages and all release-critical tests have succeeded. The Hydra jobset is: http://hydra.nixos.org/jobset/nixos/release-13.10 and the status of the release-critical jobs can be seen here: http://hydra.nixos.org/job/nixos/release-13.10/tested#tabs-constituents The plan for maintaining the branch is that it will primarily receive cherry-picked commits from master. Other than that, doing a stable branch is an experiment, and we'll have to see what the best way to do it is. Any feedback/suggestions are welcome. On that topic, now is probably a good time to start thinking about what the next release should look like, in terms of features. If you have any features (especially potentially high-impact ones like upgrading GCC) that you would like to see, please create GitHub issues for them, and add them to the 14.0x milestone: https://github.com/NixOS/nixpkgs/issues?milestone=4state=open [1] New major versions of existing packages are also fine as long as they are marked as lowPrio in all-packages.nix. That is, nix-env -i package should continue to install the old version. -- 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 mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] configuring xdg-open
it works now. okular.desktop is called kde4/okular.desktop in nixos. So the files and locations were right, but nothing happened because this desktop entry wasn't found in any of the dirs. On Sat, Oct 5, 2013 at 1:19 PM, phree...@yandex.ru wrote: On Friday, October 04, 2013 03:39:34 PM Mathijs Kwik wrote: Hi all, I'm running a custom i3 desktop setup with some kde base apps. When I click a pdf file in dolpin, kde correctly launches okular to view the file. However, using xdg-open to open the file leads to my web browser (conkeror) trying to download the file. I googled a bit on xdg-open and it seems I need to add some configuration files to ~/.local/share to configure default applications per mimetype. However this did not work. Looking at my environment, it seems XDG_* variables only point to system-wide or nix-controlled locations. Is this by design? How should I configure this correctly? PS: I'm using the new zsh stuff, which might be related. from http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html : $XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used. $XDG_CONFIG_DIRS defines the preference-ordered set of base directories to search for configuration files in addition to the $XDG_CONFIG_HOME base directory. The directories in $XDG_CONFIG_DIRS should be seperated with a colon ':'. and the same for XDG_DATA* Thus nixos setup seems to be just fine and xdg is actually used by many packages such as kde. Have a nice weekend, Mathijs ___ 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
[Nix-dev] configuring xdg-open
Hi all, I'm running a custom i3 desktop setup with some kde base apps. When I click a pdf file in dolpin, kde correctly launches okular to view the file. However, using xdg-open to open the file leads to my web browser (conkeror) trying to download the file. I googled a bit on xdg-open and it seems I need to add some configuration files to ~/.local/share to configure default applications per mimetype. However this did not work. Looking at my environment, it seems XDG_* variables only point to system-wide or nix-controlled locations. Is this by design? How should I configure this correctly? PS: I'm using the new zsh stuff, which might be related. Have a nice weekend, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Clear all
Stewart Mackenzie setor...@gmail.com writes: Mathijs Kwik math...@bluescreen303.nl wrote: You can go a step further and define multiple sub-profiles. For example 1 you typically use during c development. And another for haskell development, and yet another for an experimental python3 environment. Then you can jump between those environments on a per-terminal basis (no interferance, do many different things at once). Like this, you keep the default packageset (and thus commands available in your shell path) to a minimum. Look for myEnvFun in nixpkgs if you want to try this. Yes this is exactly where I want to go. I need a C++ and Mozart/oz environment, now does one have this default.nix committed to the mozart/oz project's repo? No you just keep it somewhere in your own repo or somewhere in your HOME. Should one use nix-shell to change to this environment? No, the myEnvFun environments create their own scripts for this. If you have an environment called foo, you will have a ~/.nix-profile/dev-envs/foo file containing most stuff that needs to be set. And a load-env-foo script in your path that sources this and does some additional things. You can use that or build your own wrapper. I personally do a little more, like setting the PS1 so I can visually identify in which environment one terminal is. So portablility is ensured by committing the new environment to some folder branch in nixpkgs, or just ship default.nix? I compile the mozart2 compiler (which is dependent on boost) as soon as I try execute the development environment it blowsup because it can't see boost deps. So I obviously need a hybrid C++/mozart-oz solution. I think we are getting things mixed up here :) The stuff I mentioned up to now is for creating custom environments, which is useful if you need to work with local projects that you have no desire to turn into a full nix expression, or at least not yet. Or if you have a bunch of similar projects with similar dependencies. So a c++ environment with a set of libraries available, a ruby environment (specific version) with a set of gems, nodejs with a bunch of npms. This resembles a typical environment you would have on other systems and is very useful for working on local projects (ones you share with non-nixos users). nix-shell (and predecessors) is used if you want to work on nix expressions to get an environment that is very similar to what builders would use if you install them normally (systemPackages or nix-env, doesn't matter). Most of the time this is for working on a package that you maintain for nixpkgs (or want to in the near future), or for local (outside of nixpkgs) projects that you want to deploy to nixos machines, for example through nixops. So this is more than just dependencies, but for specifying the full build instructions for a package. (full nix expression / derivation). Of course there is an overlap between these methods. If you want to use the nix-shell way, it depends on whether your package is supposed to become part of nixpkgs or if it's just a personal/proprietary thing. If you want it in nixpkgs, just put it in your local nixpkgs copy and submit it when it's ready (through a pull request). If it's personal you can store the expression anywhere you like (point nix-build/nix-env/nix-shell to it) or plug it into nixpkgs externally through packageOverrides. See http://nixos.org/wiki/Howto_develop_software_on_nixos My dependencies are Boost, Tcl, Tk, xlibs, xproto, Java, clang, llvm, gtest, gcc, I also have a load of environmental variables. I noticed there is a build.sh which allows me to abstract away Mozart's build. Kind regards Stewart ___ 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] Clear all
See http://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once That way, you install (and upgrade) only 1 package through nix-env and keep everything in there. To clean up: nix-env -q | xargs nix-env -e Then install your my-env package. Regarding your second question: Depends on who uses it. If your system has multiple users, you can keep stuff like firefox in systemPackages, so it's available to everyone. Of course if every user installs it for himself, it will be shared anyway, so this is not a space-saving, but just a convenience. You can go a step further and define multiple sub-profiles. For example 1 you typically use during c development. And another for haskell development, and yet another for an experimental python3 environment. Then you can jump between those environments on a per-terminal basis (no interferance, do many different things at once). Like this, you keep the default packageset (and thus commands available in your shell path) to a minimum. Look for myEnvFun in nixpkgs if you want to try this. On Sat, Sep 21, 2013 at 7:18 PM, Stewart Mackenzie setor...@gmail.com wrote: Hi all, I've only recently found out about nix-shell or what was nix-env --run-env. Though i've completely polluted my user space by installing everything with nix-env -i pkgs . I'd like to clear it up and start from scratch properly. How do i do that? Delete the profiles directory? Secondly, what typically should be installed with nix-env? I would imagine its the programs one would want access to in the standard terminal environment. Things like firefox etc. Correct? Kind regards Stewart ___ 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] Fwd: Dealing with dbus
I think you have a valid point. I too have walked into similar
situations with other packages.
Restricting dbus calls sounds like a useful solution.
Personally I would like these kinds of meta-configuration accessible
in the package expression itself (special attribute sets) and then
have nixos treat them some special way.
On Fri, Sep 13, 2013 at 3:23 PM, Sergey Mironov grr...@gmail.com wrote:
not replyed to all by mistake
-- Forwarded message --
From: Sergey Mironov grr...@gmail.com
Date: 2013/9/13
Subject: Re: [Nix-dev] Dealing with dbus
To: Mathijs Kwik math...@bluescreen303.nl
Thanks for the clarifications. Yes, it is nixos who currently handles
systemd units and it surely can deal with dbus services so I would
probably have no problems packaging some dbus service. But there is a
thing bothering me - it is the inability to specify reverse
dependencies from nixpkgs to nixos.
Lets look at the situation from the client side: for example,
xfce4-power-manager wants to call upower in order to suspend the
system. Had it used the command line-tool like pm-suspend, we would
just write { .. pm-utils .. } in the xfce4-power-manager.nix as
usual. But we can't do similar thing for upower due to it's dbus
nature. Or, to be more precise, we can, but we can't restrict
power-manager from calling anything else so it would not actually help
us to maintain the package. Heh I even didn't know it needs upower
until I looked into sources.
Naturally, Nixpkgs handles link-level dependencies very well by
allowing only some specific libs to link with. Also, it handles
path-level deps by restricting PATH calls. Network-level deps is out
of it's scope and the question is - may we extend the usual logic to
this case and restrict DBus calls somehow? IMHO we need something to
error loudly when a program calls a dbus interface which is not
enabled for it in its *nix file.
Regards,
Sergey
2013/9/10 Mathijs Kwik math...@bluescreen303.nl:
Sergey Mironov ier...@gmail.com writes:
This kind of thing touches the boundaries between nixpkgs and nixos.
First of all, I think your usecase should be handled by systemd.
Systemd knows about dbus, knows which services exist and their dbus
names. It is capable of handling requirements/ordering of these.
But currently, a nixos module has to be written for every nixpkg that
provides a service, which means stuff ends up somewhat separated. If a
binary within a package moves from /bin to /sbin, any nixos module that
uses it needs to be fixed. Getting nixos and nixpkgs a little out of
sync will break things.
For other os-level functionality though, packages can provide things
like udev rules and kernel modules themselves. You tell nixos to use
these, but leave the implementation to the package.
I think something similar can/should be done for systemd units.
Some packages already include a unit file, but for others I think a
passthru attribute systemd-units would be nicer. Then you would only
need to tell nixos to use these, or do this automatically for
environment.systemPackages. Of course these would still be
overridable/tweakable if people need slightly different configs.
(that's why I think passthru is better than including a plain unitfile)
Similar things can probably be done for things like firewall rules.
If daemon-containing packages would carry info about which ports to
open, just saying something like
networking.firewall.daemons = [ pkgs.mysql ];
would be very nice.
Of course this is all a bit offtopic to your question, but you reminded
me about the somewhat unclear nixpkgs/nixos distinction by pointing out
you want to put os-level settings/deps inside a package description,
which I think is a natural thing to do.
For now: just use nixos' systemd.services attributes to tell systemd
about dbus names and dependencies of your services.
Mathijs
Hi. Let me suggest discussing the DBus and the guidelines for
packaging software which uses this technology. I suppose that plain
including dbus into the dependencies list of a package like that:
{ stdenv, fetchurl, pkgconfig, ... dbus ... }:
stdenv.mkDerivation rec {
name = udisks-1.0.4;
..
buildInputs = [ dbus ];
}
is not the best thing to do because we are offering little guaranties
to the user this way. We are actually saying that the package needs a
network, but in reality this package needs the network AND one or more
specific servers in order to work correctly. Could we do something
better? For example, could we treat DBus as just another way of
launching programs, develop the concept of DBUS_PATH and write
something like
{ stdenv, fetchurl, pkgconfig, ... dbus ... dbus_server1, dbus_derver2 }:
stdenv.mkDerivation rec {
name = udisks-1.0.4;
..
buildInputs = [ dbus ];
// Means that udisks should have it's DBUS_PATH containing at least
dbus_server1 and dbus_server2
dbusPath = [ dbus_server1 dbus_server2
Re: [Nix-dev] Dealing with dbus
Sergey Mironov ier...@gmail.com writes:
This kind of thing touches the boundaries between nixpkgs and nixos.
First of all, I think your usecase should be handled by systemd.
Systemd knows about dbus, knows which services exist and their dbus
names. It is capable of handling requirements/ordering of these.
But currently, a nixos module has to be written for every nixpkg that
provides a service, which means stuff ends up somewhat separated. If a
binary within a package moves from /bin to /sbin, any nixos module that
uses it needs to be fixed. Getting nixos and nixpkgs a little out of
sync will break things.
For other os-level functionality though, packages can provide things
like udev rules and kernel modules themselves. You tell nixos to use
these, but leave the implementation to the package.
I think something similar can/should be done for systemd units.
Some packages already include a unit file, but for others I think a
passthru attribute systemd-units would be nicer. Then you would only
need to tell nixos to use these, or do this automatically for
environment.systemPackages. Of course these would still be
overridable/tweakable if people need slightly different configs.
(that's why I think passthru is better than including a plain unitfile)
Similar things can probably be done for things like firewall rules.
If daemon-containing packages would carry info about which ports to
open, just saying something like
networking.firewall.daemons = [ pkgs.mysql ];
would be very nice.
Of course this is all a bit offtopic to your question, but you reminded
me about the somewhat unclear nixpkgs/nixos distinction by pointing out
you want to put os-level settings/deps inside a package description,
which I think is a natural thing to do.
For now: just use nixos' systemd.services attributes to tell systemd
about dbus names and dependencies of your services.
Mathijs
Hi. Let me suggest discussing the DBus and the guidelines for
packaging software which uses this technology. I suppose that plain
including dbus into the dependencies list of a package like that:
{ stdenv, fetchurl, pkgconfig, ... dbus ... }:
stdenv.mkDerivation rec {
name = udisks-1.0.4;
..
buildInputs = [ dbus ];
}
is not the best thing to do because we are offering little guaranties
to the user this way. We are actually saying that the package needs a
network, but in reality this package needs the network AND one or more
specific servers in order to work correctly. Could we do something
better? For example, could we treat DBus as just another way of
launching programs, develop the concept of DBUS_PATH and write
something like
{ stdenv, fetchurl, pkgconfig, ... dbus ... dbus_server1, dbus_derver2 }:
stdenv.mkDerivation rec {
name = udisks-1.0.4;
..
buildInputs = [ dbus ];
// Means that udisks should have it's DBUS_PATH containing at least
dbus_server1 and dbus_server2
dbusPath = [ dbus_server1 dbus_server2 ];
}
Does dbus provide an opportunity to organize thing like that?
Regards,
Sergey.
___
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] libreoffice java impurity
Hi all, When starting libreoffice, I get this notice (on CLI): javaldx: Could not find a Java Runtime Environment! Warning: failed to read path from javaldx After installing openjre to my profile, this message no longer appears. So we should probably wrap libreoffice so it can find java in its PATH. But as as everything seems to work fine without it (I'm not a heavy user though), I figure this is an optional dependency and might have been left out intentionally to keep the closure smaller. Can someone enlighten me about this? Or should I just wrap it? Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] libreoffice java impurity
Lluís Batlle i Rossell vi...@viric.name writes: On Tue, Sep 03, 2013 at 09:27:58AM +0200, Mathijs Kwik wrote: When starting libreoffice, I get this notice (on CLI): javaldx: Could not find a Java Runtime Environment! Warning: failed to read path from javaldx After installing openjre to my profile, this message no longer appears. So we should probably wrap libreoffice so it can find java in its PATH. But as as everything seems to work fine without it (I'm not a heavy user though), I figure this is an optional dependency and might have been left out intentionally to keep the closure smaller. Can someone enlighten me about this? Or should I just wrap it? I remember that *some* import formats required java, at some point. Then, I used the same trick fo having openjre in the PATH to make them work. I think that along time, they move more and more parts from java to c++. So no need to wrap it in nixpkgs? 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] bup - test suite
I no longer use bup. People that do can probably just revert your change locally. I would like to warn you for bup though. I've used it for daily backups for at least half a year. While it never gave any errors, I noticed that repositories broke after some time somehow. As in: they must probably still contain your data somewhere (judging sizewise and from the fact that nothing ever gets deleted), but accessing it (bup ls / bup web / restore) shows up as empty. I've started over a few times, thinking it was something I messed up or because of version upgrades, but it happened more than once. Currently, I moved to using btrfs send, which is awesome, but somewhat experimental too :) I reported a few bugs, which got fixed (mostly), but still require some kernel patches that will not make it into 3.11. And even with those I believe I've hit an edge case, but haven't been able to reproduce with logging yet. Anyway, at least when it fails, it reports about it :) Furthermore it's ridiculously fast, supports deleting old revisions and does not have a separate on-disk format like bup (which effectlively doubles space requirements if you want your bup history available on the same machine as your live data). If you would like to try it out yourself, use https://github.com/bluescreen303/bluenix/blob/master/pkgs/kernel/btrfs-updates-against-3.10.7.patch , which is just a plain git diff patch comparing mainline with linux-btrfs. On Sun, Sep 1, 2013 at 2:32 PM, Marc Weber marco-owe...@gmx.de wrote: I've updated bup adding two tests: a simple manual one which can be implemented for all backup solutions easily, and I tried activating the make test for bup. The make test succeeded on my machine and on Evgeny Egorochkin's but failed on hydra. Is anybody depending on the tool or do I have a couple of days to investigate? The quickest fix is commenting the line make test probably. Marc Weber ___ 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] bup - test suite
On Sun, Sep 1, 2013 at 3:00 PM, Marc Weber marco-owe...@gmx.de wrote: Excerpts from Mathijs Kwik's message of Sun Sep 01 14:51:09 +0200 2013: I would like to warn you for bup though. I've used it for daily backups for at least half a year. Well - I guess you should have started a new repo each month .. That's what I did. For at least 6 months :) But after the third month, I thought it would be a nice tryout to see if restoring worked as advertised. So before throwing the previous month away, I used it for a restore and found out it had nothing :( After noticing this 2 months in a row, I started checking bup ls daily, but didn't hit the issue. After starting over again (next month) the daily bup ls check did notice my repo get killed after 18 days or so. I could not find anything special in the logs and in the repo, but of course I do not have a backup of my repo to check for differences. Also, issues like this are fairly hard to reproduce (to file bug reports) and as backups contain quite some private data, providing snapshots or machine access to devs is not an option. I've started over a few times, thinking it was something I messed up or because of version upgrades, but it happened more than once. Currently, I moved to using btrfs send, which is awesome, but somewhat experimental too :) Didn't knew about it. Anyway, at least when it fails, it reports about it :) supports deleting old revisions I've added this as warning. If you think you should have a new full backup each month anyway, then it does not matter that much. It does, for me, it happened 3 out of 4 months. But of course this might depend on my data. All I'm saying is: automate regular checking the consistency of your repo So what do you do now? btrfs send on the machine, and btrfs receive on the backup machine? Well of course it all starts with btrfs snapshots. I do them every 6 hours, as they are so cheap. They are taken in an instant, take up very little space if you don't change a lot on disk, and far less than block-based snapshotting (lvm) gives you. Also, you do not have to reserve space for them upfront (live lvm). I sync these snapshots with my backup machine daily, which itself sync my most important stuff to an off-site cloud vps overnight. The cool part is: this all happens with the same tools and with 1 on-disk format (normal, accessible volumes). btrfs send itself works incrementally (and even has settings where you can point out which other older snapshots the receiving end has, so it can cheat if you put back data that you had some days ago, but no longer with the last snapshot). This not only means the transfers are relatively small, but by using the fact that btrfs is really just 1 big journal, it does not need to scan everything to find out what has changed. Every other backup solution needs to do this, which will take a long time (and slow your system) if you have a few gigs of data, shattered over many thousands of files. Of course they can cheat by looking at ctimes/atimes or some index they keep, but it still takes a lot of time and those cheats can lead to data loss if you happen to use software that changes file contents, while keeping ctime/mtime/atime and size the same. Lastly, I employ a simple cleaner cronjob on all machines. So I only keep the 6-hour snapshots on my laptop for 3 days, while my backup system throws them out and only keeps 1 per day for up to a week, it keeps 1 per week for up to 2 months. The off-site VPS only keeps the most recent one (as cloud disk space is relatively pricey). So you see these locations have different data-safety purposes. The local ones are for when I make a mistake and find out quickly. The ones on the backup machine are there for longer-term backup, and mainly provides RAID, which my laptop doesn't provide. The off-site backup is only there in case my house explodes or something, so it doesn't need history. So the nice thing is that all these purposes are served by a single tool. and does not have a separate on-disk format like bup (which effectlively doubles space requirements if you want your bup history available on the same machine as your live data). I compared a use case (500 MB with many git repos) and it was not that bad - eg compared tar j or storebackup - but fastest (initial and incremental backup). The initial backup was 4 times faster. I'm not talking about the stuff bup keeps locally. I'm mainly talking about the real repo size. I know it is able to compress normal files quite well. But try making a bup repo of your 100g+ music collection. It will take up another 95g at least, which is wasteful if you're on a laptop with a 160g ssd or something. Of course you decide not to use bup for your music (use rsync for that), or to only make backups to a remote bup repo and use some snapshotting solution locally (for protecting against mistakes), but then you end up using 3 tools It could be a little risk trusting btrfs as main fs
Re: [Nix-dev] Libreoffice update to 4.0.5.2
Domen Kožar do...@dev.si writes: Hi all, I've updated libreoffice to latest stable (released few days ago). Thanks for this! libreoffice probably isn't the easiest package to maintain :) There are two caveats though: - Due to help being translated to so many packages total size when unpacked is 2.1G (help is 1.4G). Any objections for making help optional? Do we keep English help? And an option to install all others? I don't think we need more fine grained selections. This might be a nice target for multiple-outputs though. That way, the core (with english help) is shared, meaning people who select the all-languages option won't need to build everything from scratch if hydra provides both outputs. - libreoffice has quite some external dependencies and the way we build them now is messy (we just fetch all of them inside and run make), there is space for improvements Domen ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev And just curious... Why upgrade to 4.0, while 4.1 is out? I would expect skipping a version would save some work, but maybe going step-by-step it's easier to follow dependency/build-system changes. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Libreoffice update to 4.0.5.2
On Sun, Sep 1, 2013 at 7:04 PM, Domen Kožar do...@dev.si wrote: On Sun, Sep 1, 2013 at 6:59 PM, Mathijs Kwik math...@bluescreen303.nl wrote: Domen Kožar do...@dev.si writes: Hi all, I've updated libreoffice to latest stable (released few days ago). Thanks for this! libreoffice probably isn't the easiest package to maintain :) Don't mention all the fun :) There are two caveats though: - Due to help being translated to so many packages total size when unpacked is 2.1G (help is 1.4G). Any objections for making help optional? Do we keep English help? And an option to install all others? I don't think we need more fine grained selections. This might be a nice target for multiple-outputs though. That way, the core (with english help) is shared, meaning people who select the all-languages option won't need to build everything from scratch if hydra provides both outputs. We could build only English help for now and have that as parameter. When multiple-outputs branch is merged, we can make the next step :) That branch is for splitting huge parts of the stdenv and other big packages. The multiple-outputs nix functionality itself has been available for some time and is already being used by some packages (including mesa). So no need to wait for multiple-outputs to merge. - libreoffice has quite some external dependencies and the way we build them now is messy (we just fetch all of them inside and run make), there is space for improvements Domen ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev And just curious... Why upgrade to 4.0, while 4.1 is out? I would expect skipping a version would save some work, but maybe going step-by-step it's easier to follow dependency/build-system changes. 4.1 is still considered somewhat not final (from libreoffice.org: This version of LibreOffice is prepared with care and presented with pride by the LibreOffice community. PLEASE NOTE that, since this is the very second version in the series, make sure to read the release notes (under Handy resources).). I'd stick to using stable releases, but we could have a libreoffice_latest expression in nixpkgs for testing. Only if that doesn't take twice your time. Honestly, I never missed anything using 3.6, it's not that office tools are on an invention-spree :P ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Treating emacs24-nox as an alternative to emacs
Danie Roux li...@danieroux.com writes: Hi all, How do I mark/alternative/indicate that emacs24-nox=emacs for any package that requires emacs? This for example still wants to fetch all of X: nix-env --dry-run -iA nixpkgs.emacs24-nox nixpkgs.mu mu has a dependency on emacs and I don't know how to make it believe that emacs24-nox satisfies that dependency. You should probably use packageOverrides, see the nixpkgs.config option in the configuration.nix manpage. Or use it locally (in your user profile) as explained here: http://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once Thanks, -- Danie Roux ___ 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] Treating emacs24-nox as an alternative to emacs
Aristid Breitkreuz arist...@gmail.com writes:
Try something more like this:
{
packageOverrides = pkgs:
rec
{
emacs = pkgs.emacs24-nox;
djr = pkgs.buildEnv {
name = djr;
paths = with pkgs; [emacs mu];
};
};
}
And note that the djr buildEnv is not really related to the fact that
you want to override emacs. It's just a better/more convenient way to
keep all your packages up to date.
But the following would suffice:
{ packageOverrides = pkgs:
{ emacs = pkgs.emacs24-nox; };
}
Or just
{ packageOverrides = pkgs:
{ emacs24 = pkgs.emacs24.override { withX = false; }; };
}
So we don't end up with lots of top-level variations in
all-packages.nix for emacs-without-gtk-but-with-alsa,
emacs-noimagemagick, and other combinations :)
2013/9/1 Danie Roux li...@danieroux.com
On Sun, Sep 1, 2013 at 10:54 PM, Mathijs Kwik math...@bluescreen303.nl
wrote:
Danie Roux li...@danieroux.com writes:
mu has a dependency on emacs and I don't know how to make it believe
that emacs24-nox satisfies that dependency.
You should probably use packageOverrides, see the nixpkgs.config option
in the configuration.nix manpage.
Or use it locally (in your user profile) as explained here:
http://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once
This was an attempt in that direction, which doesn't have the desired
effect:
{
packageOverrides = pkgs:
let
emacs = pkgs.emacs24-nox;
in
rec
{
djr = pkgs.buildEnv {
name = djr;
paths = with pkgs; [emacs mu];
};
};
}
nix-env --dry-run -i djr
--
Danie Roux
___
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] What monitoring tools do you currently prefer?
Thanks for the tips. I will look into datadog probably, although I was hoping to uncloud myself a bit by moving more stuff to my own infrastructure ;) On Wed, Aug 28, 2013 at 11:54 AM, Domen Kožar do...@dev.si wrote: It is worth mentioning datadog (as aggregation server) builds upon very strong concepts of https://github.com/etsy/statsd/ (as client-side statistics collecting tool). For application developers it's nice because you can collection system and application data under same api. Jaka also added Graphite (OSS web tool for drawing graphs from statsd) support to NixOS, but it's far from datadog capabilities. On Wed, Aug 28, 2013 at 11:47 AM, Rob Vermaas rob.verm...@gmail.com wrote: Hi Matthijs, Tools like sysstat/sar come to mind, but as these have been around for eons, there might be more modern alternatives that I don't know about yet. If you have a small amount of servers, you could try using DataDog (http://www.datadoghq.com/), up to 5 machines are for free. It is very easy to use, there is a NixOS module for it. I have used DataDog for EC2 machines for which they have an integration available to allow getting performance information that EC2 offers. Perhaps they have something similar for your cloud provider as well. If you have more machines, it might be worth to switching to a system like Zabbix. Zabbix should also be relatively easy to set up in NixOS, there is an example in the nixos-org-configuration repository of the NixOS organization on github. Cheers, Rob ___ 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] SECURITY: default SSH host keys are weak
I currently only have an ecdsa host key and would like to keep it that way. This patch would give me a dsa key too which I don't want. On Fri, Aug 23, 2013 at 7:28 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, On 23/08/13 18:05, Peter Simons wrote: I am in favor of changing the default key type to something stronger than 1024 bit DSA for newly generated keys. I do not want any of my existing keys re-generated or replaced, though. Can the change in NixOS be made in such a way that accomplishs this? We can just generate an ECDSA key in addition to the DSA key, which is in fact what upstream's make host-key does. I suggest we apply the attached patch that does that. It's completely backwards compatible in that it will generate an ECDSA host key on systems that don't have one, while clients that have the DSA key in their known_hosts will continue to use that. (It also drops the configurability of the host key type since that doesn't support having multiple host keys.) -- 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 mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] SECURITY: default SSH host keys are weak
There probably is some MITM trick to force DSA. That will then indeed lead to a host changed warning in case the client has never used the dsa key before, so it probably won't hurt indeed. But an option to disable it would be better. Kind of like the hostKeyType we have now :) On Fri, Aug 23, 2013 at 8:36 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, On 23/08/13 20:25, Mathijs Kwik wrote: I currently only have an ecdsa host key and would like to keep it that way. This patch would give me a dsa key too which I don't want. The ssh client prefers ECDSA host keys over DSA keys so I don't think this is a big deal. But we could have an option to enable/disable generation of DSA keys. -- 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] where did hydra's tested view go?
It was quite useful to find out if the channel has issues. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] packageOverrides for tests
Hi all,
I wanted to try running some nixos tests locally when I noticed my
package overrides don't get applied. This leads to testing a different
system config than what would be installed.
With some tracing, I found that (nixos)/lib/build-vms imports nixpkgs
using config = {}, but with that removed, it still doesn't work.
The easiest way to trigger an error is to change
pkgs = applyGlobalOverrides (config.packageOverrides or (pkgs: {}));
into
pkgs = applyGlobalOverrides config.packageOverrides;
in all-packages.nix, to find out when nixpkgs is being initialized
without consulting nixpkgs-config. Then run a test:
nix-build 'nixos/release-combined.nix' -A nixos.tests.firefox.x86_64-linux
And see it fail (packageOverrides missing).
Unfortunately, the resulting trace does not help in revealing where
the config is being overwritten.
Does anyone know where this could be?
Thanks,
Mathijs
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fwd: Hardened Linux kernel with grsec/PaX + AppArmor
Hi Ricardo, It has been some time I've looked into these security-hardening systems, but I was under the impression that grsecurity, selinux and apparmor were somewhat competative solutions for the same problems. I know there are some differences (path-based vs inode based) and that grsecurity provides a bunch of generic improvements (process hiding for example) too. However, I've never heard of combining grsec with apparmor. Why would one do that? On Wed, Aug 7, 2013 at 2:59 PM, Ricardo M. Correia rcorr...@wizy.org wrote: Hi, I'm attaching a simple patch that allows you to use a kernel with grsecurity, PaX and AppArmor enabled, just in case it's useful to anyone. It requires the following changes to be applied first: https://github.com/NixOS/nixpkgs/pull/802 I am not sending a pull request for this new kernel directly because it needs further work to allow customization of the grsec kernel config options from /etc/nixos/configuration.nix and I don't have time to investigate how to do that right now. In particular, you need to specify whether the machine is a server or a desktop; whether it's running as a VM guest, host or simply on bare metal; whether hardware or software virtualization is being used and whether you prefer more security or more performance. You can accomplish that by changing the GRKERNSEC_CONFIG_* options which you can see in the patch (I enabled the ones I personally use). You can find a reference for these options here: https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Configuration_Method In order to use the new kernel and features, you also need to add boot.kernelPackages = pkgs.linuxPackages_3_2_hardened; and security.apparmor.enable = true; to your configuration. You may also need to create AppArmor profiles for the programs you are interested in confining. If you are doing chroot builds and running the new kernel, package installation may fail due to chmod +s protection (apparently it can be used to break out of the chroot). As a quick workaround, you can disable this protection temporarily during package installation: # sysctl -w kernel.grsecurity.chroot_deny_chmod=0 You should probably re-enable it afterwards. I'm sure there are better ways to do this, though. To make sure the kernel has been properly installed and is running, I suggest running dmesg as a normal user: it should fail with operation not permitted. I hope this is useful to someone. PS: you can re-enable the following kernel config options, but you will lose the corresponding security features: Xen support - disables Prevent invalid userland pointer dereference (MEMORY_UDEREF) Hibernation - disables Sanitize all freed memory (MEMORY_SANITIZE) Thanks, Ricardo ___ 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] x-updates
Hi all, I just had to push a non-X-related package to x-updates because it needs llvm 3.3. This is probably a sign that things got tangled a bit. We can either: - provide multiple versions for llvm in master - avoid package upgrades that depend on llvm 3.3 - merge x-updates soon I know x-updates was merged quite recently and not a whole lot got added this iteration, but perhaps that's a good thing? I've been running a merge of master with x-updates on 3 systems since the previous merge with no issues, but as there is no X project on hydra currently, I don't know if there are any showstoppers for other people. Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] .so file containing INPUT(...)
Ludo, as you are maintainer for ncurses in nixpkgs, can you shed a light on this? https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/ncurses/default.nix#L44 On Sat, Jul 27, 2013 at 8:14 PM, Mathijs Kwik math...@bluescreen303.nlwrote: Hi all, I'm upgrading the expression for wine to the latest version and investigating some (optional) dependencies wine claims to be missing. One of these is ncurses. Tracing the configure phase I found that our libncurses.so is a text file containing INPUT(-lncursesw) From the ncurses expression this seems to have been done deliberately and it's been there for a long time. On my system, I could not find other packages that use something similar, so I'm wondering what it's for and if it can be the cause for gcc ... -lncurses failing in wine's configure. Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] .so file containing INPUT(...)
Why whould you want to do this instead of using a symlink? On Wed, Jul 31, 2013 at 12:31 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, On 27/07/13 20:14, Mathijs Kwik wrote: I'm upgrading the expression for wine to the latest version and investigating some (optional) dependencies wine claims to be missing. One of these is ncurses. Tracing the configure phase I found that our libncurses.so is a text file containing INPUT(-lncursesw) From the ncurses expression this seems to have been done deliberately and it's been there for a long time. On my system, I could not find other packages that use something similar, so I'm wondering what it's for and if it can be the cause for gcc ... -lncurses failing in wine's configure. It's a directive for the linker to use libncursesw instead of libncurses. On a Fedora 13 machine I see these INPUT directives as well, e.g.: /usr/lib64/libbfd.so:INPUT ( /usr/lib64/libbfd.a -liberty -lz ) /usr/lib64/libcurses.so:INPUT(-lncurses) /usr/lib64/libcursesw.so:INPUT(-lncursesw) /usr/lib64/libncurses.so:INPUT(libncurses.so.5 -ltinfo) /usr/lib64/libncursesw.so:INPUT(libncursesw.so.5 -ltinfo) /usr/lib64/libopcodes.so:INPUT ( /usr/lib64/libopcodes.a -lbfd ) etc. However, Fedora and Ubuntu don't seem to unify libncurses and libncursesw. -- 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 mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] .so file containing INPUT(...)
Hi all, I'm upgrading the expression for wine to the latest version and investigating some (optional) dependencies wine claims to be missing. One of these is ncurses. Tracing the configure phase I found that our libncurses.so is a text file containing INPUT(-lncursesw) From the ncurses expression this seems to have been done deliberately and it's been there for a long time. On my system, I could not find other packages that use something similar, so I'm wondering what it's for and if it can be the cause for gcc ... -lncurses failing in wine's configure. Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] .so file containing INPUT(...)
I think wine uses ncurses for dos/cli based programs. On Sat, Jul 27, 2013 at 8:19 PM, Vladimír Čunát vcu...@gmail.com wrote: Hi, thanks for looking at wine. On 07/27/2013 08:14 PM, Mathijs Kwik wrote: I'm upgrading the expression for wine to the latest version and investigating some (optional) dependencies wine claims to be missing. Side note: what is ncurses good for in wine? Vlada ___ 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] [nixpkgs] upgrade to haskell-mode 13.07 (emacs) requires small config change
Hi all, If you use emacs with haskell-mode, you should make a small adjustment: -(load haskell-site-file) +(load haskell-mode-autoloads) There are some more options available now as well that require activation. Announcement: http://projects.haskell.org/pipermail/haskellmode-emacs/2013-June/000188.html ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] firefox 21 font rendering
From the screenshots, it's clear that firefox 21 uses subpixel rendering. The 20 screenshot only has grayscale anti-aliasing. To me, the 21 rendering (in your screenshots) looks much better, sharper, clearer. But there are times when subpixel rendering does not work out well. - On a VGA output - because it lacks (sub)pixel-perfect targeting of output pixels - Some outputs don't have RGB subpixel order but BGR - When rotating your display, the default RGB subpixel rendering should change to V-RGB. xrandr and other tools do not always detect this correctly There are ways to configure these, or to turn off subpixel rendering, but I don't know the details. Also, this is not firefox related I think. The old behavior (ff20) was not to use the system libraries and thus not use the system-wide font rendering config, but use an oldschool default, regardless of the rest of the system. The only thing that changed for ff21 is that it now does things the same way as other applications. Anyway, let's first try to find out why subpixel rendering doesn't look good for you. Please have a look at http://www.lagom.nl/lcd-test/img/subpixel.png to find out the subpixel-order of your screen. On Thu, Jun 20, 2013 at 1:53 PM, Petar Bogdanovic pe...@smokva.net wrote: Hi, while the search box is working again in the latest pre-built firefox 21, font rendering changed too. It's not ugly but it's not as good as whatever was there before. See cropped screenshots: http://smokva.net/ff/20.png http://smokva.net/ff/21.png I'm not sure if the binary I'm using reflects the latest commit (the one making system-cairo optional) so it's possible that my build is out of date again. Thanks, Petar Bogdanovic ___ 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] firefox 21 font rendering
On Thu, Jun 20, 2013 at 2:20 PM, Vladimír Čunát vcu...@gmail.com wrote: On 06/20/2013 02:07 PM, Mathijs Kwik wrote: From the screenshots, it's clear that firefox 21 uses subpixel rendering. The 20 screenshot only has grayscale anti-aliasing. To me, the 21 rendering (in your screenshots) looks much better, sharper, clearer. The point is that with system cairo you get consistent rendering in the whole system. Now with infinality you can tweak the rendering style to anything you want (or switch it off). But there are times when subpixel rendering does not work out well. - On a VGA output - because it lacks (sub)pixel-perfect targeting of output pixels - Some outputs don't have RGB subpixel order but BGR - When rotating your display, the default RGB subpixel rendering should change to V-RGB. xrandr and other tools do not always detect this correctly I think all this can be set. CRTs do have sub-pixels -- I admit that subpixel rendering is not important there, but who really uses CRT nowadays. Indeed I forgot to mention CRTs :) But as CRTs have always had VGA connectors, they fall into the VGA trap. VGA is not able to target each and every hardware pixel individually (even after careful calibration). Not on CRTs, and not on LCDs. So when a pixel falls between 2 hardware pixels the result gets smeared out over both. This will look odd, especially when fonts were subpixel-rendered. Vlada ___ 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] firefox upgrade (20 - 21) breaks search box
What branch/revision are you on? This is supposed to be fixed by https://github.com/NixOS/nixpkgs/commit/1fb979b4f553a457948c3d95d34642a3f1a664b5 Let me know if it didn't fix it for you On Sun, Jun 16, 2013 at 1:29 PM, Petar Bogdanovic pe...@smokva.net wrote: Hi, the problem seems to be described here: http://forums.famillecollet.com/viewtopic.php?id=2015 although the indicated solution is rather vague. Is anyone able to reproduce the problem? Thanks, Petar Bogdanovic ___ 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] some fixes for multiple-outputs
Hi all, I tried to build a next-generation system: - stdenv-fixes - x-updates - multiple-outputs I got quite far, most server-stuff (LAMP) builds and after some patching/fixing, most GUI stuff builds too (gtk and qt at least). I needed to do a few fixes, but I'm not confident they are the best solution. Also, I won't be able to continue hacking this branch for some time, so I'll just share my commits as some kind of cherry-pick request :) https://github.com/bluescreen303/nixpkgs/commits/multiple-outputs I hope this helps. Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Nix-commits] [NixOS/nixpkgs] 5fb93b: firefox: enable the (enabled by default) elf hack
yes, only that. but you can easily feel the difference. Not that that's any good indicator though :) On Mon, Jun 10, 2013 at 9:58 AM, Lluís Batlle i Rossell vi...@viric.name wrote: By speed things up, it speeds up the start of firefox mainly, isn't it? (when ELF pages are read). On Sun, Jun 09, 2013 at 11:59:17PM -0700, Mathijs Kwik wrote: Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 5fb93bd27ecbaf684c57f626daf1e52eebd02712 https://github.com/NixOS/nixpkgs/commit/5fb93bd27ecbaf684c57f626daf1e52eebd02712 Author: Mathijs Kwik math...@bluescreen303.nl Date: 2013-06-09 (Sun, 09 Jun 2013) Changed paths: M pkgs/applications/networking/browsers/firefox/20.0.nix M pkgs/applications/networking/browsers/firefox/21.0.nix Log Message: --- firefox: enable the (enabled by default) elf hack It's supposed to speed things up but had some troubles in the past that seem to have been fixed ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stable NixOS releases
On Tue, May 14, 2013 at 1:26 PM, Eelco Dolstra
eelco.dols...@logicblox.com wrote:
Hi all,
I would like to propose making periodic stable releases of NixOS. Currently
we
only have an unstable channel that tracks the master branches of NixOS and
Nixpkgs. The fact that these branches receive potentially major changes at
indeterminate times can make upgrading NixOS somewhat adventurous. Of course,
the great thing about NixOS is that recovering from a bad upgrade is easy.
But still, for a production server, you'd rather not run a nixos-rebuild
--upgrade and find that the Linux kernel or PostgreSQL or PHP suddenly
changed
to a different major version. On the other hand, you do want to get
(security)
bug fixes.
Therefore it would be good to have stable releases that get bug fixes for a
certain amount of time. For instance, we could make a stable release every 3
months or so, named (Ubuntu-style) year.month, e.g. 13.06, 13.09, and so
on.
A release would consist of:
- Archived installation CD images (e.g. unlike the current NixOS ISOs, they
wouldn't be deleted after a while).
- Likewise, Amazon EC2 AMIs.
- Branches in the NixOS/Nixpkgs GitHub repositories that receive updates to
the
release, e.g. nixos/13.06-release and nixpkgs/13.06-release.
- A channel that tracks the release branches, e.g.
http://nixos.org/channels/nixos-13.06, just like how the channel
http://nixos.org/channels/nixos-unstable tracks the master branches. A system
installed from a release ISO/AMI would be automatically subscribed to the
corresponding channel. Upgrading to a newer release or to the master branch
is
just a matter of running nix-channel --add
http://nixos.org/channels/nixos-...
nixos nixos-rebuild
So what kinds of updates would be suitable for release branches? Typically,
conservative bug fix releases (e.g. Linux 3.4.45 - 3.4.46, Firefox 20.0 -
20.0.1), in particular security fixes.
I also think there should be a distinction between available and default.
If our release cycle is more than a couple of weeks, chances are I
want 1 or 2 more recent packages. I don't want to be forced to run
master just because of this.
If a new firefox/kde/kernel comes around, I would like it to be
available in stable. Of course this means manually
setting/installing an explicit version, so it's clear I have to check
if it works for me. On the next stable upgrade, I have to remove these
overrides to go with the default stable version again.
We can probably achieve this by splitting all-packages.nix into 2
parts. A pool with (versioned) packages that follows upstream,
shared between master and stable. And a pinned set, containing
overrides to pin specific upstream versions. The end result (pkgs) is
the merge between these 2. As our master is probably tracking upstream
closely, its pinned set is mostly empty.
Example:
the pool contains {
firefox17 = ...;
firefox20 = ...; # support drops 05/2013
firefox21 = ...;
firefox_lts = firefox17;
firefox = firefox21;
}
master's pinnedVersions contains {
# nothing, just following upstram
}
while stable's pinnedVersions has {
firefox = firefox20;
}
This would mirror the exact upstream situation. The moment firefox20
is no longer supported upstream, it is taken out of the pool. If
stable depends on it, it should be clear that something has to be
done. Either pin to firefox_lts, or move the expression to the pinned
set, making clear it is nixos-maintained, not upstream.
I think this layout allows us to track upstream closely, while still
giving what's needed to maintain our own release-cycle. This would
also make it far easier to maintain the nixpkgs stable branch, as it
can just pull master every few days and see if there are overrides
needed. A stable release is not much more than emptying
pinnedVersions (apart from a few packages that track some lts by
default in stable).
What shouldn't go into a release branch is major package upgrades that might
break compatibility (e.g. Linux 3.4 - 3.9, KDE 4.7 - 4.10, Mesa 8 - 9 or
PostgreSQL 9.2 - 9.3), or removing or renaming NixOS configuration options.
Adding new packages should be fine. Adding new (major) versions of packages
is
also fine if they're marked as low-priority and don't change the default
version
of the package (so you can add PostgreSQL 9.3 as long as the default stays
9.2).
Likewise, adding NixOS modules is fine as long as they don't enable anything
by
default. However, I don't anticipate that there would be many of these
backports, but that depends on interest.
For creating releases, we should have a tracking issue (per release) in GitHub
that depends on all features scheduled for that release. These tracking
issues
could also serve as a roadmap for future NixOS development, which we currently
lack. For instance, as targets for a hypothetical NixOS 13.06 I would
nominate
(off the top of my head) KDE 4.10, GCC 4.8, and the current
Re: [Nix-dev] firefox elf-hack
Hrm, That proves to be harder than I hoped. I got it to build, but it won't start yet (but gives no errors/warnings). So I will have to dig deeper. On Wed, May 15, 2013 at 3:05 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, On 15/05/13 13:55, Mathijs Kwik wrote: Our current expression for firefox [1] contains the --disable-elf-hack configureFlag. By default this hack is enabled and is supposed to improve performance [2]. After a bit of googling, I found that old versions of firefox had issues with this hack, so probably this is the reason it got disabled. However, these issues are fixed and I've been running with firefox20 _with_ the elf hack for over a week now. Can we remove this configure flag and stick with the default (hacked) behavior? Sure. Maybe you can update to Firefox 21 while you're at it ;-) -- 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 mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] firefox elf-hack
Hi all, Our current expression for firefox [1] contains the --disable-elf-hack configureFlag. By default this hack is enabled and is supposed to improve performance [2]. After a bit of googling, I found that old versions of firefox had issues with this hack, so probably this is the reason it got disabled. However, these issues are fixed and I've been running with firefox20 _with_ the elf hack for over a week now. Can we remove this configure flag and stick with the default (hacked) behavior? Or should this be done conditionally for certain architectures? Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] firefox elf-hack
[1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/browsers/firefox/20.0.nix#L138 [2] http://glandium.org/blog/?p=1177 On Wed, May 15, 2013 at 1:55 PM, Mathijs Kwik math...@bluescreen303.nl wrote: Hi all, Our current expression for firefox [1] contains the --disable-elf-hack configureFlag. By default this hack is enabled and is supposed to improve performance [2]. After a bit of googling, I found that old versions of firefox had issues with this hack, so probably this is the reason it got disabled. However, these issues are fixed and I've been running with firefox20 _with_ the elf hack for over a week now. Can we remove this configure flag and stick with the default (hacked) behavior? Or should this be done conditionally for certain architectures? Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stable NixOS releases
Eelco Dolstra eelco.dols...@logicblox.com writes: Hi all, I would like to propose making periodic stable releases of NixOS. Currently we only have an unstable channel that tracks the master branches of NixOS and Nixpkgs. The fact that these branches receive potentially major changes at indeterminate times can make upgrading NixOS somewhat adventurous. Of course, the great thing about NixOS is that recovering from a bad upgrade is easy. But still, for a production server, you'd rather not run a nixos-rebuild --upgrade and find that the Linux kernel or PostgreSQL or PHP suddenly changed to a different major version. On the other hand, you do want to get (security) bug fixes. Therefore it would be good to have stable releases that get bug fixes for a certain amount of time. For instance, we could make a stable release every 3 months or so, named (Ubuntu-style) year.month, e.g. 13.06, 13.09, and so on. A release would consist of: - Archived installation CD images (e.g. unlike the current NixOS ISOs, they wouldn't be deleted after a while). - Likewise, Amazon EC2 AMIs. - Branches in the NixOS/Nixpkgs GitHub repositories that receive updates to the release, e.g. nixos/13.06-release and nixpkgs/13.06-release. - A channel that tracks the release branches, e.g. http://nixos.org/channels/nixos-13.06, just like how the channel http://nixos.org/channels/nixos-unstable tracks the master branches. A system installed from a release ISO/AMI would be automatically subscribed to the corresponding channel. Upgrading to a newer release or to the master branch is just a matter of running nix-channel --add http://nixos.org/channels/nixos-... nixos nixos-rebuild So what kinds of updates would be suitable for release branches? Typically, conservative bug fix releases (e.g. Linux 3.4.45 - 3.4.46, Firefox 20.0 - 20.0.1), in particular security fixes. What shouldn't go into a release branch is major package upgrades that might break compatibility (e.g. Linux 3.4 - 3.9, KDE 4.7 - 4.10, Mesa 8 - 9 or PostgreSQL 9.2 - 9.3), or removing or renaming NixOS configuration options. Adding new packages should be fine. Adding new (major) versions of packages is also fine if they're marked as low-priority and don't change the default version of the package (so you can add PostgreSQL 9.3 as long as the default stays 9.2). Likewise, adding NixOS modules is fine as long as they don't enable anything by default. However, I don't anticipate that there would be many of these backports, but that depends on interest. For creating releases, we should have a tracking issue (per release) in GitHub that depends on all features scheduled for that release. These tracking issues could also serve as a roadmap for future NixOS development, which we currently lack. For instance, as targets for a hypothetical NixOS 13.06 I would nominate (off the top of my head) KDE 4.10, GCC 4.8, and the current x-updates branch. (See https://fedoraproject.org/wiki/Releases/19/FeatureList for an example of how Fedora does this.) If a feature is not finished/stable on time, it would not go into the release. I haven't thought very much yet about the actual release process (like when to branch a release off the master). Comments, ideas, suggestions? Wow, (y)our little distro is growing up so fast :') Congrats on reaching the point where the user base has become large enough and is running serious production stuff on it, mandating a stable channel. I would prefer a 3 months cycle. 6 months is quite long, making upgrades (possibly) harder to do. Also, we probably want releases to be backward compatible 1 release (regarding configuration.nix and nix features), so a long cycle might complicate things or hold back master development. Also, I'm against these extremely-managed/planned bureaucratic projects, with a feature freeze and various beta/RC phases that affect what you can and cannot do on master. I think the process should be very simple: - You send out an email saying it's release time again - People nominate a git revision that's at least 1 week old so it has been tested a little bit. - this revision becomes stable-RC - we decide if RC is good enough or whether small things need to be fixed/cherry-picked - merge stable-RC into stable Preferably the whole process takes at most 4 or 5 days. Announcement on wednesday, release on monday. This makes the weekend into a nice community-hackathon :) That way, maintainers/users will probably invest some time to test/fix things. If the timeframe is 2 or 3 weeks, people might get sloppy and postpone testing it out and collaborating. But that's just my thought and I'm in no way good at releasing and deadlines and stuff like that :P So I'm interested in what others would do. Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl
Re: [Nix-dev] Stable NixOS releases
On Tue, May 14, 2013 at 3:54 PM, Marc Weber marco-owe...@gmx.de wrote: Excerpts from phreedom's message of Tue May 14 15:44:24 +0200 2013: It isn't only about production. I'm sure that we managed to scare away some newbie users with a temporarily broken master branch. I don't understand why, because nixos is the *only* distribution you can just use older revision and continue. So it should even make those newbe users use nixos with even more joy. You can only roll back if you had at least 1 successful build. A new user might end up with build errors during installation. The problem is there are many packages - and there will be more - we will not have a chance to test all of them (eg games) - so we should define what we want to call breakage. Eg breaking ati/nvidia proprietary drivers is bader than breaking a particular game (for work). There will always be new users who find bugs .. So maybe the better way is to emphasize that using nixos its a smaller problem compared to other distros. Marc Weber ___ 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] Stable NixOS releases
On Tue, May 14, 2013 at 5:33 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, On 14/05/13 14:25, Mathijs Kwik wrote: I would prefer a 3 months cycle. 6 months is quite long, making upgrades (possibly) harder to do. Agree. OTOH, there is the question of how long release branches are maintained. For now I'd say that a release branch should be maintained until the next release comes out. In the future we could have releases that are maintained for longer (such as a LTS branch). Also, we probably want releases to be backward compatible 1 release (regarding configuration.nix and nix features), so a long cycle might complicate things or hold back master development. Also, I'm against these extremely-managed/planned bureaucratic projects, with a feature freeze and various beta/RC phases that affect what you can and cannot do on master. I think the process should be very simple: - You send out an email saying it's release time again - People nominate a git revision that's at least 1 week old so it has been tested a little bit. - this revision becomes stable-RC - we decide if RC is good enough or whether small things need to be fixed/cherry-picked - merge stable-RC into stable Preferably the whole process takes at most 4 or 5 days. Announcement on wednesday, release on monday. This makes the weekend into a nice community-hackathon :) But the risk with this approach is that people will be tempted to squeeze in wildly destabilizing changes at the last moment :-) I don't think this needs a lot of bureaucracy or rules though, just some good sense not to (say) merge a major GCC update into master just before the release is about to be branched. I think stdenv-updates is still the only right place for those. Same for x-updates. We should not declare master anything-can-break-now just because we have stable, so maintaining master somewhat the same as we do now (with feature branches for larger undertakings) seems best. Also, having release goals (as in these are the features we'd like to have in this release) seems like a good way to focus development (and to get people to volunteer to work on those features). -- 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 mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] I broke btrfs :(
Good evening all. It appears I've broken btrfs root booting. The upgraded version needs 2 more libraries (or a static build). I can just have the nixos btrfs module copy these to ramdisk, but I believe I remember some automatic functionality that did this, or at least detect this type of breakage? Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] I broke btrfs :(
ah, then that's probably the thing I remembered. For now I will just build a static binary. Thanks On Mon, May 13, 2013 at 11:01 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, On 13/05/13 22:42, Mathijs Kwik wrote: It appears I've broken btrfs root booting. The upgraded version needs 2 more libraries (or a static build). I can just have the nixos btrfs module copy these to ramdisk, but I believe I remember some automatic functionality that did this, or at least detect this type of breakage? I don't think there is, except that you can set boot.initrd.extraUtilsCommandsTest to test the initrd binaries (e.g. we run $out/bin/udevadm --version to see if all its dynamic library dependencies are there). -- 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 mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] cron's timezone
Hi all, I recently upgraded an old (pre-systemd) system. After the upgrade, I noticed that cronjobs started running at the wrong time (UTC). My configuration.nix contains: '' time.timeZone = Europe/Amsterdam; '' And I verified that /etc/systemd/system/cron.service contains: '' [Service] Environment=PATH=/nix/store/k0kd4brqjm1017bhyj8rkyy36n0v5kmh-coreutils-8.21/bin:/nix/store/0fabgj3075kk0llvcgxllkrilf72amns-findutils-4.4.2/bin:/nix/store/s1ifw2i2x0kcisnrs4yyx31m6gv7sysj-gnugrep-2.14/bin:/nix/store/1d1jkg0qb7ci05dc5chjkz4872zycj24-gnused-4.2.1/bin:/nix/store/8v9gwcswr6n4p4c5mdanh8qi6j2d8j3s-systemd-201/bin:/nix/store/l5xk9g3xrjh0nayzcfnsz85fnfzaccdq-cron-4.1/bin:/nix/store/k0kd4brqjm1017bhyj8rkyy36n0v5kmh-coreutils-8.21/sbin:/nix/store/0fabgj3075kk0llvcgxllkrilf72amns-findutils-4.4.2/sbin:/nix/store/s1ifw2i2x0kcisnrs4yyx31m6gv7sysj-gnugrep-2.14/sbin:/nix/store/1d1jkg0qb7ci05dc5chjkz4872zycj24-gnused-4.2.1/sbin:/nix/store/8v9gwcswr6n4p4c5mdanh8qi6j2d8j3s-systemd-201/sbin:/nix/store/l5xk9g3xrjh0nayzcfnsz85fnfzaccdq-cron-4.1/sbin Environment=LD_LIBRARY_PATH= Environment=TZ=Europe/Amsterdam '' What else should I check? Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Nix-commits] [NixOS/nixpkgs] fd7630: vlc: enable support for the opus codec
ffmpeg has opus enabled indeed, and for mplayer this seems to be enough. VLC however won't play any opus files without this. I suspect vlc only uses ffmpeg's decoder but has its own code for demultiplexing (opening the .opus container file). Lluís Batlle i Rossell vi...@viric.name writes: On Sun, Apr 07, 2013 at 11:38:24PM -0700, Mathijs Kwik wrote: Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: fd76305a9b81325bf044e9689574215d95e86f8c https://github.com/NixOS/nixpkgs/commit/fd76305a9b81325bf044e9689574215d95e86f8c Author: Mathijs Kwik math...@bluescreen303.nl Date: 2013-04-07 (Sun, 07 Apr 2013) Changed paths: M pkgs/applications/video/vlc/default.nix Log Message: --- vlc: enable support for the opus codec How is it different than the support being present in ffmpeg? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] read-only store on its own filesystem
Hi all, I have my /nix/store on a separate filesystem. It seems that because of this, the new read-only store functionality does not work. In stage-2-init.sh (line 53): if [ -n @readOnlyStore@ ]; then if ! mountpoint -q /nix/store; then mount --bind /nix/store /nix/store mount -o remount,ro,bind /nix/store fi fi mountpoint -q will return successfully in my case and skip setting up the read-only stuff. Why is this check there? Is there a reason not to use this functionality when a mountpoint (store on other fs) is detected? Thanks, Mathijs ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Node.JS package and build inputs
Sander van der Burg - EWI s.vanderb...@tudelft.nl writes:
Hi everyone,
Lately, I'm using Node.js and I wanted to create a package that requires some
of the
NodeJS modules that we have defined in node-packages.nix. However, when I add
them to
buildInputs, they cannot be found.
Of course, I could set the NODE_PATH environment variable in every package
expression
that I write, but I find it more elegant when we can just add these to
buildInputs.
Enabling this functionality is not that hard. We just have to provide a setup
hook with
Node.js that adds packages with a node_modules subdirectory to NODE_PATH. I
can
implement that hook quite easily.
What do you think?
I do something similar, I create a virtual package, containing just
the dependencies for my project. The output of this package is a dir
that contains a valid node_modules dir for my project.
modules = node.buildNodePackage rec {
name = my-project-modules;
phases = [ configurePhase installPhase];
src = runCommand empty-dir {} mkdir $out;
deps = [
node.coffee-script-1.4.0
node.less-1.3.0
node.cssmin-0.3.1
node.underscore-1.4.2
node.backbone-0.9.2
node.showdown-0.0.1
node.datetime-0.0.3
node.mrclean-0.1.0
node.escape-html-0.0.1
node.mongodb-1.1.11
node.connect-2.4.4
node.hat-0.0.3
node.sockjs-0.3.1
node.ws-0.4.21
node.source-map-0.1.2
node.async-0.1.22
node.wu-0.1.8
];
};
Then my project itself just links this directory:
stdenv.mkDerivation rec {
name = my-project-1.3;
src = fetchgit { ... };
buildInputs = [nginx nodejs redis modules];
configurePhase = ''
ln -s ${modules}/node_modules .
...
'';
installPhase = ''
mkdir -p $out/share/my-project
...
ln -s ${modules}/node_modules $out/share/my-project
'';
}
This has the added advantage that I can use this modules-dir from my
development environment as well by creating a simple symlink.
Mathijs
-- Sander
___
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] Who and when, Fosdem 2013
Picknix? :D On Thu, Jan 31, 2013 at 2:44 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, On 29/01/13 19:14, Lluís Batlle i Rossell wrote: finally I can reach Fosdem on Saturday afternoon, and be there until Monday. Yay! I'll be at FOSDEM from Saturday morning (or so) till Sunday evening. Anyone would join a nix meeting, nix supper, whatever, those days? I'm up for dinner or lunch or whatever ;-) -- 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 mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
