Re: [Nix-dev] still waiting for https://cache.nixos.org after 5 seconds...

2017-05-13 Thread Jookia
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...

2017-05-13 Thread Jookia
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...

2017-05-12 Thread Jookia
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

2017-04-23 Thread Jookia
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

2017-04-03 Thread Jookia
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?

2017-03-21 Thread Jookia
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

2017-03-18 Thread Jookia
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

2017-03-18 Thread Jookia
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

2017-03-18 Thread Jookia
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

2017-02-27 Thread Jookia
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

2017-02-27 Thread Jookia
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?

2017-02-27 Thread Jookia
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...

2017-02-26 Thread Jookia
  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

2017-01-28 Thread Jookia
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

2016-10-30 Thread Jookia
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

2016-09-23 Thread Jookia
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

2016-08-31 Thread Jookia
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

2016-08-29 Thread Jookia
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

2016-07-19 Thread Jookia
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)

2016-07-10 Thread Jookia
  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

2016-07-06 Thread Jookia
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

2016-07-06 Thread Jookia
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

2016-07-06 Thread Jookia
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]

2016-06-17 Thread Jookia
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

2016-03-01 Thread Jookia
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

2016-01-16 Thread Jookia
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

2016-01-12 Thread Jookia
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

2016-01-07 Thread Jookia
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

2016-01-07 Thread Jookia
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++

2016-01-02 Thread Jookia
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

2015-12-29 Thread Jookia
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

2015-12-29 Thread Jookia
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

2015-12-26 Thread Jookia
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.

2015-11-19 Thread Jookia
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.

2015-11-18 Thread Jookia
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.

2015-11-17 Thread Jookia
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

2015-11-16 Thread Jookia
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?

2015-09-25 Thread Jookia
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?

2015-09-25 Thread Jookia
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?

2015-09-22 Thread Jookia
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?

2015-04-28 Thread Jookia
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.

2015-04-27 Thread Jookia
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.

2015-04-27 Thread Jookia
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.

2015-04-27 Thread Jookia
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.

2015-04-16 Thread Jookia
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