Re: [Nix-dev] still waiting for https://cache.nixos.org after 5 seconds...
On Sat, May 13, 2017 at 09:32:21AM +, Denis wrote: > It is a server-side setting Oh sorry, I thought you meant the proxy on my end. No, that's a good idea. ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] still waiting for https://cache.nixos.org after 5 seconds...
On Sat, May 13, 2017 at 08:34:29AM +0100, Kevin Cox wrote: >You can turn that off Yeah, but I'm not going to do that. ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] still waiting for https://cache.nixos.org after 5 seconds...
On Mon, May 08, 2017 at 11:46:02AM +, Denis wrote: > I really do not understand the reasons of the strong opposition to > another mirror on Cloudflare (free of cost, although it may not solve > the problem completely - it has no endpoint in Vietnam, for example - > it may increase availability and reduce Amazon bills) and to allowing > the people in regions to host mirrors (it should not be a security > breach as the packages are cryptographic signed). It wouldn't be great for proxy users who get blocked by CAPTCHAs ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Easier GTK theming
On Sun, Apr 23, 2017 at 07:09:43AM -0700, William Casarin wrote: > ... > > Thoughts? Has there been progress down these lines before? Well I got a patch in to GTK3 to read themes from XDG_DATA_PATH (or something like that) so installed themes should just work. GTK2 has a patch, but it's not upstream. Here it is: commit 0df8a7c7ba26f368f01ada4233dedc4193cdbebf Author: Jookia <166...@gmail.com> Date: Sat Apr 8 20:16:54 2017 +1000 gtk2: Patch theme paths diff --git a/pkgs/development/libraries/gtk+/2.x.nix b/pkgs/development/libraries/gtk+/2.x.nix index 306e2db..f6e718d 100644 --- a/pkgs/development/libraries/gtk+/2.x.nix +++ b/pkgs/development/libraries/gtk+/2.x.nix @@ -30,7 +30,7 @@ stdenv.mkDerivation rec { nativeBuildInputs = [ setupHook perl pkgconfig gettext ]; - patches = [ ./2.0-immodules.cache.patch ]; + patches = [ ./2.0-immodules.cache.patch ./gtk2-theme-paths.patch ]; propagatedBuildInputs = with xorg; [ glib cairo pango gdk_pixbuf atk ] diff --git a/pkgs/development/libraries/gtk+/gtk2-theme-paths.patch b/pkgs/development/libraries/gtk+/gtk2-theme-paths.patch new file mode 100644 index 000..397cc97 --- /dev/null +++ b/pkgs/development/libraries/gtk+/gtk2-theme-paths.patch @@ -0,0 +1,35 @@ +diff -Naur gtk+-2.24.28.new/gtk/gtkrc.c gtk+-2.24.28/gtk/gtkrc.c +--- gtk+-2.24.28.new/gtk/gtkrc.c 2016-03-13 10:31:14.413644362 +1100 gtk+-2.24.28/gtk/gtkrc.c 2016-03-13 12:51:34.723398423 +1100 +@@ -808,6 +808,8 @@ + gchar *path = NULL; + const gchar *home_dir; + gchar *subpath; ++ const gchar * const *xdg_data_dirs; ++ gint i; + + if (type) + subpath = g_strconcat ("gtk-2.0-", type, +@@ -830,6 +832,22 @@ + } + + if (!path) ++{ ++ xdg_data_dirs = g_get_system_data_dirs (); ++ for (i = 0; xdg_data_dirs[i]; i++) ++{ ++ path = g_build_filename (xdg_data_dirs[i], "themes", name, subpath, NULL); ++ if (g_file_test (path, G_FILE_TEST_EXISTS)) ++break; ++ else ++{ ++ g_free (path); ++ path = NULL; ++} ++} ++} ++ ++ if (!path) + { + gchar *theme_dir = gtk_rc_get_theme_dir (); + path = g_build_filename (theme_dir, name, subpath, NULL); ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix init system
On Mon, Apr 03, 2017 at 11:14:32AM +0200, Luescher Claude wrote: > Hello, > > After watching some videos about nix I gave it a try but as soon as I > noticed systemd I deleted the VM image right away. Either remove it or just > close the development of this whole OS. Oh but why? You don't have to use NixOS, and there's a lot of people perfectly happy with systemd. No need to close development. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Should we drop 9P?
On Tue, Mar 21, 2017 at 11:29:09PM +0100, Profpatsch wrote: > On 17-03-20 10:27pm, Volth wrote: > > Recently few bugs in 9P were found (#23957 #23020 #22695) which > > reveals that 9P code is not very mature and perhaps NixOS is the first > > team which uses 9P heavily and relies on it in production. > > Could you please provide links? 9P is a protocol, > do you mean holes in the protocol have been found? https://github.com/NixOS/nixpkgs/issues/23957 https://github.com/NixOS/nixpkgs/issues/23020 https://github.com/NixOS/nixpkgs/issues/22695 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The Church of Suckless NixOS is looking for followers
On Sat, Mar 18, 2017 at 12:56:14PM +0100, Matthias Beyer wrote: > Never thought about what you wrote there. Thanks for the new > perspective! > > -- > Mit freundlichen Grüßen, > Kind regards, > Matthias Beyer > > Consider switching to free software. > It adds value to your life. > https://www.gnu.org/ No problem! :) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The Church of Suckless NixOS is looking for followers
On Sat, Mar 18, 2017 at 11:32:18AM +0100, Matthias Beyer wrote: > But then you have to think about why these people are doing it. > Clearly because they think they can do something better - which is > fine IMO. > > But if a fork is necessary this also means their voices were not heard > when they announced that things are not optimal for them - which means > bad community management. If they did not tell the community what they > dislike, though, I fully agree with you. The thing that bothered me a little about your email is the assumption that a fork is what happens when there's trouble. I don't think that's always the case, and now might be a good example. Without working relationships to hold our projects together, we get forks. This isn't a good or bad thing, it just is: Often it's how projects start before pull requests happen. The *why* is what we need to focus on. Sometimes there's fights and drama that destroy relationships and leave a fork in the road, or sometimes there's new contributors who have a fork but want to get it mainlined. In this case, there's two important things to note here: - There's no reason why we're not working together, so we might as well try to build a relationship and lessen the fork of what we don't share in common. - We need both parties to want to work together. NixOS can have the best community management in the universe, but if the other half of the relationship doesn't want this then a fork will be there. This is the first I've heard of this Suckless NixOS project, and to me since I don't see a reason why there's a fork it means opportunity. Regards, Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The Church of Suckless NixOS is looking for followers
On Sat, Mar 18, 2017 at 11:10:51AM +0100, Matthias Beyer wrote: > On 18-03-2017 11:39:15, Jookia wrote: > > Having enough interest to get forked is certainly a good thing. Who > > knows, maybe NixOS will join the ranks of other distros with > > spin-offs. > > Oh please no! > > Whether it is a good thing what is proposed here or not - we really > should try to hear all voices and try to get the best of all worlds > Having many spinoffs won't help anyone and result in a _lot_ of work > duplicated. That is _never_ a good thing. That's one way to look at it. Another way to look at it is that duplicated work is a cost of doing a fork, and if you're okay with it then it's not so much a big deal as long as the people doing the duplicated work are ok with it. In the end, people would use what they want to use. :) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Gajim and OMEMO
On Mon, Feb 27, 2017 at 08:50:39PM +0100, Jörg Thalheim wrote: > In unstable you should get by default all dependencies required for Omemo: > > https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/instant-messengers/gajim/default.nix#L13 > > These are the packages added to make it working: > > https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/instant-messengers/gajim/default.nix#L102 > > You can actually remove your own override. Neat! I haven't updated since 2016-08-30 since I've been too lazy to update stuff like that. Though this is an unusal case since updating takes around 4 days of work. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Gajim and OMEMO
I have this as a package: { stdenv, makeWrapper, fetchurl, pythonPackages, buildPythonPackage, python , gajim, potr }: let gajim-omemo = stdenv.mkDerivation { name = "gajim-omemo"; src = fetchurl { url = "https://api.github.com/repos/kalkin/gajim-omemo/tarball/8356479;; sha256 = "1czfayh0dhijy4ycph4krwq1zl8g0x0hbj952x75fbxs1jr7qpdk"; name = "gajim-omemo-8356479.tar.gz"; }; phases = [ "unpackPhase" "installPhase" ]; installPhase = "cp -r . $out"; }; gajim-otr = stdenv.mkDerivation { name = "gajim-otr"; src = fetchurl { url = "https://api.github.com/repos/python-otr/gajim-otr/tarball/0613803;; sha256 = "1ng3pwl8z31zpipkwp8m24xm2hwpj70i1hlrcqkklqx9ar7yxj4h"; name = "gajim-otr-0613803.tar.gz"; }; phases = [ "unpackPhase" "installPhase" ]; installPhase = "cp -r src/gotr $out"; }; in stdenv.mkDerivation { name = "gajim-crypto"; buildInputs = with pythonPackages; [ makeWrapper python python-axolotl python-axolotl-curve25519 potr protobuf2_6 google_apputils ]; buildCommand = '' mkdir -p $out/share/gajim/plugins for i in share/{applications,icons,locale,man} \ share/gajim/{data,icons,src}; do ln -s ${gajim}/$i $out/$i done for i in ${gajim}/share/gajim/plugins/*; do ln -s $i $out/share/gajim/plugins/$(basename $i); done ln -s ${gajim-omemo} $out/share/gajim/plugins/${gajim-omemo.name} ln -s ${gajim-otr} $out/share/gajim/plugins/${gajim-otr.name} cp -r --no-preserve=all ${gajim}/bin $out for i in $out/bin/*; do chmod +x $i wrapProgram $i \ --set GAJIM_BASEDIR "$out/share/gajim" \ --prefix PYTHONPATH : "$PYTHONPATH" ; sed -i "s/APP=.*/APP=$(basename $i)/g" $out/bin/.$(basename $i)-wrapped done ''; } (and potr:) { stdenv, fetchurl, pythonPackages, buildPythonPackage }: buildPythonPackage rec { version = "1.0.1"; name = "python-pure-otr-${version}"; src = fetchurl { url = "https://github.com/python-otr/pure-python-otr/archive/${version}.tar.gz;; sha256 = "0xwzxvmvz7dbd6ahf6nscgby6wc469xgmjq8bqcazgv59h83i5lh"; }; buildInputs = [ pythonPackages.pycrypto ]; } Might be outdated, set it up a while ago. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Best Practices on Modularizing Configuration.nix?
On Mon, Feb 27, 2017 at 09:15:27AM -0500, Mark Gardner wrote: > So far, this seems like a good approach. Except that each machine has its > own configuration.nix that I would like to keep in the git repository too > but of course I can't have different top level files with the same name. To > solve this, I could moved the current configuration.nix inside of cfg (as > cfg/mylaptop.cfg.nix perhaps) or merge with the existing cfg/mylaptop.nix > then making configuration.nix a symlink to it. That way the only thing to > do by hand is create the symlink to select a particular configuration. Is > this reasonable? Is there a better way to do it? > > How do you modularize your configuration and put it into a repo such that > you can easily create a configuration for a new machine (and put it in the > repo too) without a lot of hand work? > > Mark > -- > Mark Gardner > -- I have a configuration for each host, but then I set my nix path like so: NIX_PATH=nixpkgs=/home/jookia.data/nixos/nixpkgs.git:nixos-config=/home/jookia.data/nixos/configuration.git/novena.nix nixos-config points to my host-specific configuration. Then in that host configuration I set the path something like this: nix.nixPath = [ "nixos-config=/home/jookia.data/nixos/configuration.git/novena.nix" ]; ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] e2c95b: nftables module: Add new module for nftables firew...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: e2c95b46e5fbd9f28cc7714802f9cd3b632fd979 https://github.com/NixOS/nixpkgs/commit/e2c95b46e5fbd9f28cc7714802f9cd3b632fd979 Author: Jookia <166...@gmail.com> Date: 2017-02-26 (Sun, 26 Feb 2017) Changed paths: M nixos/modules/module-list.nix A nixos/modules/services/networking/nftables.nix Log Message: --- nftables module: Add new module for nftables firewall settings fixes #18842 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] linux-ck kernel config
On Sat, Jan 28, 2017 at 12:42:16PM +, Azul wrote: > Anyone here uses a linux-ck patched kernel ? > http://users.tpg.com.au/ckolivas/kernel/ > > and willing to share their config ? > > my laptop tells me he seriously misses that kernel from it's Arch days Here's my somewhat dated Novena kernel source: http://sprunge.us/QKjP (named kernel-novena.nix) and somewhat how to use it: let novenaKernelPackages = pkgs.callPackage ./kernel-novena.nix {}; in boot.kernelPackages = novenaKernelPackages; Enjoy! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Override php xslSupport config option
On Sun, Oct 30, 2016 at 09:59:20PM +0300, Игорь Пашев wrote: > Something like this: > > { php70 }: php70.merge { > cfg = { > apxs2Support = false; > ldapSupport = false; > mssqlSupport = false; > pdo_pgsqlSupport = false; > postgresqlSupport = false; > sqliteSupport = false; > xslSupport = false; > }; > } > > Use this with nixpkgs.config.packageOverrides It's really obscure how to use these old-timey .merge{} operations. Maybe it should be documented somewhere or finally replaced with proper overrides? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Bootstrap Nix
On Sat, Sep 24, 2016 at 01:42:09AM +0300, Игорь Пашев wrote: > Hello guys :-) > How do you bootstrap Nix on an entirely new platform? I wrote this guide on how to bootstrap NixOS back a while ago: https://nixos.org/wiki/Bootstrapping_NixOS_on_ARM Bootstrapping nixpkgs is another issue entirely ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
On Thu, Sep 01, 2016 at 01:17:02AM +0800, stewart mackenzie wrote: > Throw beers at Garbas! Shower him in the best beer possible! > > *Garbas rubs his nipples* 2.7.5: Administrators SHOULD block or ban "bad actors" who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] 6 month C4 adoption period
On Tue, Aug 30, 2016 at 07:28:43AM +0800, stewart mackenzie wrote: > due to multiple causes, but the latest straw on the camel's back is > this pull request: https://github.com/NixOS/nixpkgs/pull/18101 Hey there, I think you need to calm down a little with the comments. You seem to want people to review or reply to things in very fast fashion, which I don't think a lot of people can do. You also aren't that good at communicating what you want from people, which I think you can do better if you try. For instance, saying you wish for something then someone not replying to your wish, doesn't mean they voted against it (there wasn't even a vote!) Jookia ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 584b66: ddrescue: lzip is a nativeBuildInput
4 Author: Tuomas Tynkkynen <tuo...@tuxera.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/stdenv/linux/make-bootstrap-tools-cross.nix Log Message: --- make-bootstrap-tools-cross.nix: Support 'dist' target Commit: 3d509896511fac1c73307fedf2060c9dddebf73a https://github.com/NixOS/nixpkgs/commit/3d509896511fac1c73307fedf2060c9dddebf73a Author: Tuomas Tynkkynen <tuo...@tuxera.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/stdenv/linux/make-bootstrap-tools-cross.nix M pkgs/stdenv/linux/make-bootstrap-tools.nix Log Message: --- make-bootstrap-tools{,-cross}.nix: Create deterministic tars Commit: d0e25d815ce610c34581860abc1269408323ca1e https://github.com/NixOS/nixpkgs/commit/d0e25d815ce610c34581860abc1269408323ca1e Author: Tuomas Tynkkynen <tuo...@tuxera.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/top-level/release-cross.nix Log Message: --- release-cross.nix: Drop any platforms not having a single working build Commit: ee1a647bc292248f4745fa040b4d5ed75117d227 https://github.com/NixOS/nixpkgs/commit/ee1a647bc292248f4745fa040b4d5ed75117d227 Author: Tuomas Tynkkynen <tuo...@tuxera.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/top-level/release-cross.nix Log Message: --- release-cross.nix: Remove bunch of packages that don't build Commit: cd645c417a162debb695691b0b94ef438ac21f39 https://github.com/NixOS/nixpkgs/commit/cd645c417a162debb695691b0b94ef438ac21f39 Author: Tuomas Tynkkynen <tuo...@tuxera.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/top-level/release-cross.nix Log Message: --- release-cross.nix: Build the bootstrap tools for ARM Commit: 322faf92196ddf282703ddc608e221eeaaa6578c https://github.com/NixOS/nixpkgs/commit/322faf92196ddf282703ddc608e221eeaaa6578c Author: Tuomas Tynkkynen <tuo...@tuxera.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/top-level/platforms.nix Log Message: --- platforms.nix: Switch ARMv7 to vfpv3-d16 Make ARMv7 compatible with non-NEON chips, changing to the same float ABI that Debian and Arch Linux use. This is apparently required for the binaries to work on Scaleway, for instance. Commit: ad16c9ac31f4eb2b5a6b5a4615df8e9ea4c3a405 https://github.com/NixOS/nixpkgs/commit/ad16c9ac31f4eb2b5a6b5a4615df8e9ea4c3a405 Author: Tuomas Tynkkynen <tuo...@tuxera.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/development/interpreters/spidermonkey/17.0.nix Log Message: --- Revert "spidermonkey: Disable tests on ARM" This reverts commit f9654a88e76703a80b8d1464f384bba21abeaf52. At least for now, the problem has gone away on ARMv7 by the switch of FPU flags used by GCC. Some details of the bug at: https://github.com/NixOS/nixpkgs/pull/16850#issuecomment-232339143 Commit: 6c4ba06597be6efec7e2036c76d4dd8d2e53443c https://github.com/NixOS/nixpkgs/commit/6c4ba06597be6efec7e2036c76d4dd8d2e53443c Author: Jookia <166...@gmail.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/development/interpreters/spidermonkey/185-1.0.0.nix A pkgs/development/interpreters/spidermonkey/arm-flags.patch Log Message: --- spidermonkey: Fix building 185-1.0.0 on ARMv7. Commit: cde9fb47a9027e95b452dca23d451dc7ec3a2c0a https://github.com/NixOS/nixpkgs/commit/cde9fb47a9027e95b452dca23d451dc7ec3a2c0a Author: Jookia <166...@gmail.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/development/interpreters/spidermonkey/31.5.nix Log Message: --- spidermonkey: Fix building 31.5 on GCC 5. Commit: 33a1d8080b50bdbf0143f4513db2fb4fe3acbd2e https://github.com/NixOS/nixpkgs/commit/33a1d8080b50bdbf0143f4513db2fb4fe3acbd2e Author: Jookia <166...@gmail.com> Date: 2016-07-20 (Wed, 20 Jul 2016) Changed paths: M pkgs/development/interpreters/spidermonkey/31.5.nix Log Message: --- spidermonkey: Enable tests on 31.5. Compare: https://github.com/NixOS/nixpkgs/compare/b3adffcd5681...33a1d8080b50___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] ba2232: srelay: init at 0.4.8b6 (#16833)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: ba2232f1f2759766df55d65bb0d81eaa0219a856 https://github.com/NixOS/nixpkgs/commit/ba2232f1f2759766df55d65bb0d81eaa0219a856 Author: Jookia <166...@gmail.com> Date: 2016-07-11 (Mon, 11 Jul 2016) Changed paths: A pkgs/tools/networking/srelay/arm.patch A pkgs/tools/networking/srelay/default.nix M pkgs/top-level/all-packages.nix Log Message: --- srelay: init at 0.4.8b6 (#16833) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Packaging free software that costs money
On Thu, Jul 07, 2016 at 12:10:41AM +0200, Profpatsch wrote: > No, but we should strife to enable developers however we can. Could we perhaps find a way to do this without requiring the user to lie about paying for something just to install something they don't need to pay for? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Packaging free software that costs money
On Wed, Jul 06, 2016 at 06:46:11PM +0200, Profpatsch wrote: > On 16-07-07 01:18am, Jookia wrote: > > On Wed, Jul 06, 2016 at 04:35:51PM +0200, Moritz Ulrich wrote: > > Is it really Nix's job to enforcing the business models of software, rather > > than > > just packaging it? Surely the application could just have a nag screen (if > > it > > doesn't already.) > > How about we check whether the NIXPKGS_ALLOW_UNPAID variables (good name?) is > set > and supress the abortion in that case? Same as with NIXPKGS_ALLLOW_UNFREE. > > env NIXPKGS_ALLOW_UNPAID=1 nix-shell -p ardour --run ardour Should Nix really be involved in questions of morality like this? For where binaries aren't publically available we already have packages that handle 'commercial' software, like andyetitmoves. For software that wants the user to pay or donate, GNU Parallel for one requires you to agree to citing the software in scientific papers to avoid a nag screen, I don't see why Ardour shouldn't do the same. This isn't a technical feature, it's a morality feature. I also think it's wrong to present software as required to be paid in order to use when it's not, and making users say they paid for it when they didn't, just to install free software that they're entitled to install and use. Is this going to be the Nix software store? Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Packaging free software that costs money
On Wed, Jul 06, 2016 at 04:35:51PM +0200, Moritz Ulrich wrote: > > Philip Carlsen <plc...@gmail.com> writes: > > > Consider instead something like thks in nixpkgs config: > > ardour = { > > isPaid = true; > > } > > I like this approach. It's plain and simple. We just need to make sure > that `nixos-rebuild` and `nix-env` display appropriate messages telling > users how/where to set this. Possibly with a link to a wiki page or a > section in the manual. I don't think such an approach is fair for people that don't have the money, want to trial the software or test if it works on their machine. In this case Ardour is packaged by many distros for free. Is it really Nix's job to enforcing the business models of software, rather than just packaging it? Surely the application could just have a nag screen (if it doesn't already.) Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]
On Fri, Jun 17, 2016 at 03:01:00PM +, zimbatm wrote: > I don't mean to say that GPG is a bad idea. It just that using SSL is a > better idea unless we nail the GPG bit. Not everyone is getting > state-sponsored attacks. TLS and GPG aren't mutually exclusive, you can use both. It's also worth noting that states aren't the only people attacking TLS: Tor exit nodes like to do it too. It does trouble me that there's no way to really verify that I have a copy of Nix that the maintainers have. Right now I check out with an unverified Git repository which isn't much better either. It'd be nice to at least try to have verification. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Configuring vim with override
On Wed, Mar 02, 2016 at 12:08:05AM +0300, Nikita Karetnikov wrote: > I'd like to enable cscope and clipboard support in vim by editing only the > configuration.nix file. If I understand the NixOS manual correctly, it should > look like this: > > [...] > > No luck, though. What's the right way? vim_configurable is used like this: myVim = pkgs.vim_configurable.merge { features = "huge"; # one of tiny, small, normal, big or huge gui = "gtk"; cfg = { pythonSupport = true; python3Support = true; multibyteSupport = true; }; flags = { xim.enable = true; }; }; Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Container notification broken
Hey there, Spawning a container fails on my system with this error: Spawning container vpn on /var/lib/containers/vpn. Press ^] three times within 1s to kill container. /etc/localtime does not point into /usr/share/zoneinfo/, not updating container timezone. Failed to create mount point /var/lib/containers/vpn/var/lib/private/host-notify: No such device or address Perhaps it's best to drop "--bind=/run/systemd/notify:/var/lib/private/host-notify" and use systemd's notifcation system if it breaks everything? Cheers, Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get correct length of a string containing non-ascii characters
On Mon, Jan 11, 2016 at 11:29:37PM +, Erik Rybakken wrote: > Hi, > > In nix, when finding the length of a string containing non-ascii characters, > the number of bytes in the representation is returned, instead of the actual > number of characters: > > > nix-repl> builtins.stringLength "å" > > 2 > > Is there any way to get the number of characters instead, or does this > require changes in the core language? It's probably best to leave it like it is now. A string's length is two if that's the number of bytes it uses. You'd have to start asking some hard questions if you want other behaviour like: Why do you want the string's length? Do you want to truncate it? What if that creates an invalid sequence of characters somehow? Do you want to compare lengths or equality? Should text be normalized somehow? Which way? What should the base 'unit' be for a string? A code point? A character? A glyph? A grapheme? How would this be implemented? > Best Regards, > Erik Rybakken Cheers, Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
On Fri, Jan 08, 2016 at 12:38:52AM +, Tomasz Czyż wrote: > 2016-01-08 0:34 GMT+00:00 Jonn Mostovoy: > Still don't see the value in it. I would just prefix them with > haskellPackages-, pythonPackages-. How would we do something like 'buildInputs = with pythonPackages; [pycrypto]; ' with that kind of system? I imagine things would get very verbose very quickly. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
On Thu, Jan 07, 2016 at 06:29:35PM -0700, Mathnerd314 wrote: > On Thu, Jan 7, 2016 at 6:25 PM, Jookia <166...@gmail.com> wrote: > > > On Fri, Jan 08, 2016 at 12:38:52AM +, Tomasz Czyż wrote: > > > 2016-01-08 0:34 GMT+00:00 Jonn Mostovoy <j...@memorici.de>: > > > Still don't see the value in it. I would just prefix them with > > > haskellPackages-, pythonPackages-. > > > > How would we do something like 'buildInputs = with pythonPackages; > > [pycrypto]; ' > > with that kind of system? I imagine things would get very verbose very > > quickly. > > > > We would still have all-packages.nix, so the attribute paths would not > change. > > -- Mathnerd314 Would this still work with conflicting namespaces, such as Python3Packages? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Perl -> C++
On Sat, Jan 02, 2016 at 10:12:50PM +1100, stewart mackenzie wrote: > I'm aware that Rust can replace Perl via FFI it's the added deps that > concern me Could you elaborate on this? I've seen a lot of talk about dependencies but what exactly is the problem? Portability sounds like a genuine concern, but you can still be portable with a lot of dependencies as long as they're portable. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Disabling patchelf on ARM
On Tue, Dec 29, 2015 at 12:32:35PM +0100, Lluís Batlle i Rossell wrote: > For what I remember, Patchelf is used in most stdenv.mkDerivation just to > shorten the number of dependencies (shrink-rpath). Yeah- shrink-rpath is doing the damage. > In armv5tel, I remember that my binaries were broken if I run patchelf > *ONCE*. If I run patchelf *TWICE*, they worked fine. That's clearly an > jnsolved bug worked around. I think it was never fixed in patchelf, > because there was this work-around and noone looked at the problem > anymore. > I think that for arv6 or armv7 the double-patchelf was not required > anymore; I can't tell. I have not checked how does it work now with those > archs. I may have to test that- but it's still definitely something that breaks on my machine. > Jokia, it'd be great if you would gather details beyond "it breaks > binaries", and even better if you could propose a fix. :) On an ARM system, install vim_configurable (doesn't matter which configuration)- it'll segfault after being stripped by patchelf. I can't remember off the top of my head any other examples, but I know that one certainly breaks. The most I can find is https://github.com/NixOS/patchelf/issues/8 which may or may not be related as it affects Fedora. My solution is to disable patchelf since it's breaking things without good reason. > Regards, > Lluís. Cheers, Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Disabling patchelf on ARM
On Tue, Dec 29, 2015 at 12:24:33PM +0100, Joachim Schiele wrote: > if they are good patches we will merge them! I appreciate the enthusiasm. :) Unfortunately the mailing list doesn't seem to do many patch reviews which conflicts with my want to do things slowly. The only way I can see merging happening is if I showered a ton of patches for review, some related to ARM, some not but still required for the Novena, and hope people review them and cherry pick them. I suppose I could always privately contact the maintainers of wherever I'm patching, but that feels a little too opaque for my tastes. Maintaining my own fork public nixpkgs is impossible given how long compile times are when it comes to Nix. Rebasing could take a few days on my stripped down install since I don't (nor does anyone seem to) have an ARM build farm, I shudder to think if any Novena users want to run more than i3, it'd probably take a magnitude longer considering some builds only work single-threaded, and as we focus more on reproducible builds I imagine we'll be reverting back for things like Haskell. At that point it may actually be impossible to build and run NixOS using just an ARM machine and no binary caches. Pessimism aside, an ARM build farm is a solvable, unrelated problem to my patches. As long as I can get some review upstreaming shouldn't be a problem. > patchelf is used to deploy the initial bootstrap-tools. later one there > is only minimal use, as you already said, for binary only applications. > > please provide an exaple, where patchelf is doing something wrong with > some paste from the shell. > > thank you Installing vim_configurable on ARM seems to do the trick. I can't reproduce it right now, mysterious. Perhaps I have a patched version, I'll check later. Cheers, Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Disabling patchelf on ARM
Hey there, I've been working for a few months on getting a Novena port of NixOS running. The overall Nix infrastructure works, though I still have a ton of issues to solve before publishing any patches required on a git repository (they probably won't be merged in to nixpkgs anyway.) A problem I've been dealing with is mysterious segmentation faults affecting the system along with bugs that aren't present in Debian on the same system. patchelf has been the culprit for quite a few of them and upstream doesn't seem to be working on fixing this. I haven't looked at this too deeply, but I'm wondering: Is there a way to disable patchelf to stop it corrupting my binaries? I'm not running any nonfree software so I'm not too worried about working with unchangeable code. Cheers, Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [PATCH] pulseaudio: Add support for package configuration files.
On Thu, Nov 19, 2015 at 09:59:09AM +0100, Vladimír Čunát wrote: > On 11/18/2015 12:08 PM, Jookia wrote: > > I wonder if there's any review tools that support a github > > bridge that someone could set up. It doesn't look like it from first glance. > I've seen the command-line tool, but I almost haven't used it yet. > $ hub --help > [...] > Vladimir hub is pretty good, but I'm not sure if you can sign up or verify emails through it. I've used hub in the past to contribute to projects, but the problem is that there's a block for joining using only free software. Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [PATCH] pulseaudio: Add support for package configuration files.
On Wed, Nov 18, 2015 at 10:02:33AM +0100, Luca Bruno wrote: > I hope somehow will review this. Personally I'd prefer if you made a > pull request on github. While github allows use of its services for registered users without nonfree javascript, unfortunately it doesn't allow you to register without it. In my tests I got as far as email validation. Nitpicky I know, but it'd really make me feel uncomfortable using a service that disallows people to join in without using only free software. I've heard that the mailing list is okay for patches, and given the speed of things I'm fine if it takes longer to get a patch reviewed or in. I don't have a good solution to fix this problem, or even if others acknowledge that it's a problem. I wonder if there's any review tools that support a github bridge that someone could set up. It doesn't look like it from first glance. Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH] pulseaudio: Add support for package configuration files.
In a fashion like udev's support, this patch allows configurations from packages to be merged in to directories for PulseAudio to read from. Currently supported directories are the alsa-mixer mdoule's profile-sets and paths. This is accomplished by patching PulseAudio to read directories from environment variables globally defined by NixOS rather from the data path in the Nix store. Modules that support it (such as the alsa module) can still be configured at runtime to use specific paths, this just changes the default paths. The environment variables are only used if they're defined, as such the previous behaviour can be reverted to if the variables are unset or NixOS isn't running. --- nixos/modules/config/pulseaudio.nix | 43 + pkgs/servers/pulseaudio/custom-dirs.patch | 52 +++ pkgs/servers/pulseaudio/default.nix | 2 +- 3 files changed, 96 insertions(+), 1 deletion(-) create mode 100644 pkgs/servers/pulseaudio/custom-dirs.patch diff --git a/nixos/modules/config/pulseaudio.nix b/nixos/modules/config/pulseaudio.nix index 2ebc612..bad4bf3 100644 --- a/nixos/modules/config/pulseaudio.nix +++ b/nixos/modules/config/pulseaudio.nix @@ -52,6 +52,37 @@ let } ''); + # Create a directory full of configuration files for PulseAudio to use for + # various modules. Packages are scanned similiar how udev does it. + moduleEnvVars = { +PA_ALSA_PATHS_DIR = "${moduleConf}/alsa-paths"; +PA_ALSA_PROFILE_SETS_DIR = "${moduleConf}/alsa-profiles"; + }; + moduleConf = stdenv.mkDerivation { +name = "pulseaudio-moduleconf"; + +preferLocalBuild = true; +allowSubstitutes = false; + +buildCommand = '' + mkdir -p $out/{alsa-profiles,alsa-paths} + shopt -s nullglob + set +o pipefail + + function copy_dir() { +for j in $1/$2/*; do + echo "Copying $i to $out/$3/$(basename $j)" + cat $j > $out/$3/$(basename $j) +done + } + + for i in ${toString cfg.packages}; do +echo "Adding configuration for package $i" +copy_dir $i/usr/share/pulseaudio/alsa-mixer profile-sets alsa-profiles +copy_dir $i/usr/share/pulseaudio/alsa-mixer paths alsa-paths + done +''; + }; in { options = { @@ -96,6 +127,17 @@ in { ''; }; + packages = mkOption { +type = types.listOf types.path; +description = '' + List of packages containing additional PulseAudio configuration. + All files found in the following directories: + pkg/usr/share/lib/pulseaudio/alsa-mixer/profile-sets + pkg/usr/share/lib/pulseaudio/alsa-mixer/paths + will be included. +''; + }; + package = mkOption { type = types.package; default = pulseaudioLight; @@ -130,6 +172,7 @@ in { }; hardware.pulseaudio.configFile = mkDefault "${cfg.package}/etc/pulse/default.pa"; + environment.sessionVariables = moduleEnvVars; } (mkIf cfg.enable { diff --git a/pkgs/servers/pulseaudio/custom-dirs.patch b/pkgs/servers/pulseaudio/custom-dirs.patch new file mode 100644 index 000..00e2ee7 --- /dev/null +++ b/pkgs/servers/pulseaudio/custom-dirs.patch @@ -0,0 +1,52 @@ +diff -Naur pulseaudio-7.0/src/modules/alsa/alsa-mixer.c pulseaudio-7.0.new/src/modules/alsa/alsa-mixer.c +--- pulseaudio-7.0/src/modules/alsa/alsa-mixer.c 2015-09-15 14:46:06.0 +1000 pulseaudio-7.0.new/src/modules/alsa/alsa-mixer.c 2015-11-18 12:58:33.490001078 +1100 +@@ -2521,10 +2521,11 @@ + } + + static const char *get_default_paths_dir(void) { ++char *env = getenv("PA_ALSA_PATHS_DIR"); + if (pa_run_from_build_tree()) + return PA_SRCDIR "/modules/alsa/mixer/paths/"; + else +-return PA_ALSA_PATHS_DIR; ++return (env ? env : PA_ALSA_PATHS_DIR); + } + + pa_alsa_path* pa_alsa_path_new(const char *paths_dir, const char *fname, pa_alsa_direction_t direction) { +@@ -4347,6 +4348,7 @@ + pa_alsa_profile *p; + pa_alsa_mapping *m; + pa_alsa_decibel_fix *db_fix; ++char *env; + char *fn; + int r; + void *state; +@@ -4392,9 +4394,10 @@ + if (!fname) + fname = "default.conf"; + ++env = getenv("PA_ALSA_PROFILE_SETS_DIR"); + fn = pa_maybe_prefix_path(fname, + pa_run_from_build_tree() ? PA_SRCDIR "/modules/alsa/mixer/profile-sets/" : +- PA_ALSA_PROFILE_SETS_DIR); ++ (env ? env : PA_ALSA_PROFILE_SETS_DIR)); + + r = pa_config_parse(fn, NULL, items, NULL, ps); + pa_xfree(fn); +diff -Naur pulseaudio-7.0/src/tests/alsa-mixer-path-test.c pulseaudio-7.0.new/src/tests/alsa-mixer-path-test.c +--- pulseaudio-7.0/src/tests/alsa-mixer-path-test.c2014-02-15 03:06:12.0 +1100 pulseaudio-7.0.new/src/tests/alsa-mixer-path-test.c2015-11-18 12:57:40.750001071 +1100 +@@ -15,10 +15,11 @@ + + /*
Re: [Nix-dev] NixCon thanks
On Mon, Nov 16, 2015 at 06:32:20PM +0100, Domen Kožar wrote: > https://www.youtube.com/watch?v=PjAmr22FZts=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy Here's a non-youtube mirror, useful for those that find youtube slow: https://media.ccc.de/b/conferences/nixcon/2015 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] What license does the content of the nixos wiki and the manuals have?
On Fri, Sep 25, 2015 at 09:28:36AM +0200, Joachim Schiele wrote: > two problems i see here: > - text can't be covered by GPL thus they created CC > - some edits in the wiki are anonymous (whom to ask?) > i like that we are adressing this issue now. it is very important. > i'd go for CC BY SA 3.0 > https://creativecommons.org/licenses/by-sa/3.0/ > as IMHO this fits the other licenses pretty well I might as well chime in given I wrote https://nixos.org/wiki/Bootstrapping_NixOS_on_ARM but had someone else upload it as Tor users are blocked from editing but I still want to contribute. People can use my contributions licensed under the CC-BY-SA 4.0 or GPLv3+. Text can be covered by the GPL (there's no reason they can't, it's a copyright license at heart.) I'm not sure why you'd choose a 3.0 license when 4.0 is out. I've heard 4.0 solves a lot of internalization problems too. There's some people talking about copyleft licenses requirng you to disclose your work, which isn't true. You only have to disclose the source code to people you distribute your work to, which seems fair to everyone involved. If there's a consensus for another license or a copyright agreement, people can take my contribution as CC0 and combine them in to the permissively licensed work. IMHO copyright agreements are unneccesary unless you disagree on the license chosen. In which case you should probably have chosen a license. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?
On Fri, Sep 25, 2015 at 03:49:08PM +0200, Eelco Dolstra wrote: > Hi, > > On 25/09/15 14:24, Matthias Beyer wrote: > > > So, an idea came up - why not using static pages for all of this? If you > > want to do contributions via git, you can use github. If one want to > > host it, one can use github pages and build it with travis-ci. These > > things are documented and they _work_ for other people, so why not for > > a wiki? > > > > To be able to build pages with travis-ci and github pages, one needs a > > static site compiler. > > This is essentially how the NixOS homepage is built, i.e., a git repository + > Template Toolkit + a makefile. And of course you can make pull requests on > GitHub. But I wouldn't call that a wiki, since you can't easily edit it from a > browser, or make it world-writable. But if we do want go that way, another > possibility is GitHub Pages + Jekyll. > > The main advantage of using a GitHub wiki is that we then don't have to manage > user accounts and deal with spammers. But as you say, the downside is that we > can't customize much. A huge disadvantage of using github tools are that they're proprietary, so people using free systems can't contribute (easily.) What about ikiwiki? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Providing Debian, Arch etc. packages counterproductive?
On Tue, Sep 22, 2015 at 11:37:58AM +0200, Eelco Dolstra wrote: > Hi, > > On 22/09/15 11:35, Thomas Hunger wrote: > > > I can think of two solutions 1) make the packages set up nix correctly so > > nix-env is usable out of the box and 2) Remove all custom packages and tell > > people to use the installer script. > > +1 on option 2. Why not both? Have the packages run the installer script. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Where would I put the bootstrapping guide?
Hello! Recently I've bootstrapped NixOS on to a new ARM platform from an existing Debian install on the same platform. I figured this is useful knowledge so I've written up some documentation which I'm in the process of convert to Docbook. It's kind of a tutorial but expects users to modify commands. The guide includes how to install Nix, the NixOS installer and finally NixOS on a system such as Debian. It's three sections long and intended for development and porting NixOS to new platforms. I originally wrote it for inclusion in the Wiki but I'm barred from it as I use Tor, so I'm beginning to wonder if there's a place for it in the official documentation around the installation section. The obviously place would be in the installer section but it focuses on using a CD. Any suggestions? I'd really love to make it easier to install NixOS when there isn't already an installer image. Jookia. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH 2/2] nixos-install: Fix chroot flag not defaulting to Bash outside NixOS.
Passing the chroot flag to nixos-install without arguments should now give you a Bash shell as intended rather than try an empty path. This was masked by the user's shell (usually /bin/bash) being defaulted to by chroot, and being found since their paths used NixOS conventions. --- nixos/modules/installer/tools/nixos-install.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/nixos/modules/installer/tools/nixos-install.sh b/nixos/modules/installer/tools/nixos-install.sh index 86e57f7..097631e 100644 --- a/nixos/modules/installer/tools/nixos-install.sh +++ b/nixos/modules/installer/tools/nixos-install.sh @@ -45,7 +45,9 @@ while [ $# -gt 0 ]; do ;; --chroot) runChroot=1 -chrootCommand=($@) +if [[ $@ != ]]; then +chrootCommand=($@) +fi break ;; --help) -- 2.3.6 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH 1/2] nixos-install: Fix password prompt failing outside NixOS.
When bootstrapping from other distributions, nixos-install is unable to find various tools in the chroot since their paths aren't aware of NixOS conventions. This makes a small change to existing code by specifying nixpkgs/nixos instead of just nixos when running nix-instantiate in the chroot. I haven't tested this outside of bootstrapping, but the same specification is used elsewhere in the code so I don't see why it wouldn't work. --- nixos/modules/installer/tools/nixos-install.sh | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/nixos/modules/installer/tools/nixos-install.sh b/nixos/modules/installer/tools/nixos-install.sh index 14ae3da..86e57f7 100644 --- a/nixos/modules/installer/tools/nixos-install.sh +++ b/nixos/modules/installer/tools/nixos-install.sh @@ -254,8 +254,14 @@ NIXOS_INSTALL_GRUB=1 chroot $mountPoint \ chroot $mountPoint /nix/var/nix/profiles/system/activate +# Some systems may not be prepared to use NixOS' paths. +export PATH=/run/current-system/sw/bin:/run/current-system/sw/sbin:$PATH +export NIX_PATH=/nix/var/nix/profiles/per-user/root/channels/nixos:nixpkgs=/etc/nixos/nixpkgs +export NIX_PATH=$NIX_PATH:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/profiles/per-user/root/channels + + # Ask the user to set a root password. -if [ $(chroot $mountPoint nix-instantiate --eval 'nixos' -A config.users.mutableUsers) = true ] [ -t 0 ] ; then +if [ $(chroot $mountPoint nix-instantiate --eval 'nixpkgs/nixos' -A config.users.mutableUsers) = true ] [ -t 1 ] ; then echo setting root password... chroot $mountPoint /var/setuid-wrappers/passwd fi -- 2.3.6 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH 0/2] Fix nixos-install when running outside NixOS.
Due to issues with environmental variables, nixos-install failed to install when the host operating system wasn't NixOS. This broke bootstrapping from Debian. Jookia (2): nixos-install: Fix password prompt failing outside NixOS. nixos-install: Fix chroot flag not defaulting to Bash outside NixOS. nixos/modules/installer/tools/nixos-install.sh | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) -- 2.3.6 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH] Fixed zImage installation when building Linux.
When building kernels outputting a zImage, the zImage wasn't correctly copied in to the installation. This broke the build process entirely, at least on my ARM machine. --- pkgs/os-specific/linux/kernel/manual-config.nix | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pkgs/os-specific/linux/kernel/manual-config.nix b/pkgs/os-specific/linux/kernel/manual-config.nix index ea29c7f..620df6d 100644 --- a/pkgs/os-specific/linux/kernel/manual-config.nix +++ b/pkgs/os-specific/linux/kernel/manual-config.nix @@ -116,7 +116,9 @@ let ++ optional installsFirmware INSTALL_FW_PATH=$(out)/lib/firmware; # Some image types need special install targets (e.g. uImage is installed with make uinstall) - installTargets = [ (if platform.kernelTarget == uImage then uinstall else install) ]; + installTargets = [ (if platform.kernelTarget == uImage then uinstall else + if platform.kernelTarget == zImage then zinstall else + install) ]; postInstall = (optionalString installsFirmware '' mkdir -p $out/lib/firmware -- 2.3.3 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev