[Nix-commits] [NixOS/nixpkgs] 756e69: syncthing: don't import from pkgs (#27029)

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 756e69bf97c5170408b9511d57c04f4c772c458d
  
https://github.com/NixOS/nixpkgs/commit/756e69bf97c5170408b9511d57c04f4c772c458d
  Author: volth <vo...@webmaster.ms>
  Date:   2017-07-02 (Sun, 02 Jul 2017)

  Changed paths:
M pkgs/applications/networking/syncthing/default.nix

  Log Message:
  ---
  syncthing: don't import from pkgs (#27029)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 4fb8f6: lxc: 2.0.7 -> 2.0.8

[Volth]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4fb8f6f7a5b30f4baa5d654929e16174cd750816
  
https://github.com/NixOS/nixpkgs/commit/4fb8f6f7a5b30f4baa5d654929e16174cd750816
  Author: Franz Pletz <fpl...@fnordicwalking.de>
  Date:   2017-06-26 (Mon, 26 Jun 2017)

  Changed paths:
M pkgs/os-specific/linux/lxc/default.nix

  Log Message:
  ---
  lxc: 2.0.7 -> 2.0.8

(cherry picked from commit eb8c14751a3532898e7941ee43a271d8739a6a21)


  Commit: b2bf4d8327b71f67bb7766fc2cb2988152067b02
  
https://github.com/NixOS/nixpkgs/commit/b2bf4d8327b71f67bb7766fc2cb2988152067b02
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-06-26 (Mon, 26 Jun 2017)

  Changed paths:
M pkgs/tools/networking/mtr/default.nix

  Log Message:
  ---
  mtr: do not do 'setcap' on installPhase, it would fail anyway

(cherry picked from commit 8fe525b6c77ca5fdd2d1922d2e863fbb9198781c)


Compare: https://github.com/NixOS/nixpkgs/compare/b00fb69ff895...b2bf4d8327b7___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 85b9ff: rrdtool: apply upstream patch to fix file permissi...

[Volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 85b9ff29e998f3462dd053c27f147de35779e1f1
  
https://github.com/NixOS/nixpkgs/commit/85b9ff29e998f3462dd053c27f147de35779e1f1
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-06-24 (Sat, 24 Jun 2017)

  Changed paths:
M pkgs/tools/misc/rrdtool/default.nix

  Log Message:
  ---
  rrdtool: apply upstream patch to fix file permission

fixes #26780 #26782


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] How to downgrade or patch freetype-2.7 ?

[Volth]

There are still at least one place where
"environment.sessionVariables.LD_LIBRARY_PATH = ..." does not replace
freetype with a custom-built version: in cgi-scripts run under
lighttpd service:

RRD rendered with stock freetype-2.7.1 http://i.imgur.com/HVZ5iPa.png
RRD rendered with freetype-2.7.1 compiled without subpixel rendering
(#define TT_CONFIG_OPTION_SUBPIXEL_HINTING 0):
http://i.imgur.com/Qj4W0Lx.png


On 4/20/17, Volth <vo...@volth.com> wrote:
> On 4/20/17, Thomas Tuegel <ttue...@mailbox.org> wrote:
>> Volth <vo...@volth.com> writes:
>>
>>> The second (http://imgur.com/MDiydzS) is what we get with these
>>> fontconfig rules on NixOS-17.09 (freetype-2.7.1) with default v40.
>>> Antialias is off, but hinting is not in action.
>>
>> Did you intentionally turn off hinting in that sample, or is it just not
>> working? Even with v40, it should be possible to achieve good results
>> with full hinting and no antialiasing.
>
> Hinting is on, the difference between the 2nd and the 3rd images is
> only 35 vs. 40 in the environment variable.
> If you want to reproduce, you may disable antialiasing and enable full
> hinting for pkgs.ubuntu_font_family or pkgs.liberation_ttf_v1_binary
> which are in nixpkgs.
>
>>> PS. v38 works similar to v40. It easy to turn in off by
>>> "config.fonts.fontconfig.ultimate.enable = false;".
>>> What I was looking for is a similar easy way to turn off v40 appeared
>>> in NixOS-unstable.
>>
>> That setting doesn't actually turn off v38! It turns off the
>> fontconfig-ultimate settings, but FreeType 2.6 is still patched to use
>> v38 instead of v35. So, if you could get acceptable rendering with
>> FreeType 2.6 on NixOS (which used v38), we should also be able to fix it
>> with FreeType 2.7 (v40) too.
>
> There was a visually similar issue in 17.03 with liberation_ttf_2.xx
> [1] which forced me to downgrade to 1.07. In 17.09 even
> liberation_ttf_1.07.xx became broken.
>
> There are clearly two diverging ways: the mainstream with
> antialiasing, subpixel rendering, gray-on-white texts, ... and the
> minority people who want to stay with contrast fonts rendered using
> only two colors (foreground and background). In order to stay the
> ground both the fonts and freetype are to be downgraded to their
> previous versions, so it won't be so long to lose the battle. Anyway,
> as dpi grows and pixels became invisible, it won't be the matter at
> all.
>
> 1. https://github.com/NixOS/nixpkgs/issues/21806
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 633d04: clion1: remove package

[Volth]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 633d046590703f5e5ccbff5fcf686c8b884f8a37
  
https://github.com/NixOS/nixpkgs/commit/633d046590703f5e5ccbff5fcf686c8b884f8a37
  Author: Vasiliy Solovey <milta...@yandex.ua>
  Date:   2017-06-22 (Thu, 22 Jun 2017)

  Changed paths:
M pkgs/applications/editors/jetbrains/default.nix

  Log Message:
  ---
  clion1: remove package
It is no longer present on JetBrains download servers and is
very outdated.

(cherry picked from commit d41dee0a9f3f85eec872171565ebb81e1f4b6bb2)


  Commit: eea3211bb4ca296f5628f68da882053f3afacffa
  
https://github.com/NixOS/nixpkgs/commit/eea3211bb4ca296f5628f68da882053f3afacffa
  Author: Jiri Danek <jda...@redhat.com>
  Date:   2017-06-22 (Thu, 22 Jun 2017)

  Changed paths:
M pkgs/applications/editors/jetbrains/default.nix

  Log Message:
  ---
  idea-community: 2017.1.1 -> 2017.1.3

(cherry picked from commit ccef4810caf740198a8428a7734771dcbd9e4c98)


  Commit: aae153cae4a4a79b4871499f8ac02934153021f8
  
https://github.com/NixOS/nixpkgs/commit/aae153cae4a4a79b4871499f8ac02934153021f8
  Author: Gauthier POGAM--LE MONTAGNER <kendos.ken...@gmail.com>
  Date:   2017-06-22 (Thu, 22 Jun 2017)

  Changed paths:
M pkgs/applications/editors/jetbrains/default.nix

  Log Message:
  ---
  idea.webstorm: 2017.1 -> 2017.1.3

(cherry picked from commit 282fba7f0c777f2acd023133d4a8b4fa842dd12d)


  Commit: 011192b5f4bf3aa967720262c28c18601b7dd8e2
  
https://github.com/NixOS/nixpkgs/commit/011192b5f4bf3aa967720262c28c18601b7dd8e2
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-06-22 (Thu, 22 Jun 2017)

  Changed paths:
M pkgs/applications/editors/jetbrains/default.nix

  Log Message:
  ---
  jetbrains.{webstorm,phpstorm}: 2017.1 -> 2017.1.4

(cherry picked from commit bf5c57e1b8e243565469196d033bb61ab0055307)


Compare: https://github.com/NixOS/nixpkgs/compare/6ed463b0585b...011192b5f4bf___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 8fe525: mtr: do not do 'setcap' on installPhase, it would ...

[Volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 8fe525b6c77ca5fdd2d1922d2e863fbb9198781c
  
https://github.com/NixOS/nixpkgs/commit/8fe525b6c77ca5fdd2d1922d2e863fbb9198781c
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-06-20 (Tue, 20 Jun 2017)

  Changed paths:
M pkgs/tools/networking/mtr/default.nix

  Log Message:
  ---
  mtr: do not do 'setcap' on installPhase, it would fail anyway


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 13a8fa: nixos-artwork: do not leak nix hashes to filenames...

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 13a8fa88011a45447ec26f81c473fe7f39172d02
  
https://github.com/NixOS/nixpkgs/commit/13a8fa88011a45447ec26f81c473fe7f39172d02
  Author: volth <vo...@webmaster.ms>
  Date:   2017-06-14 (Wed, 14 Jun 2017)

  Changed paths:
M pkgs/data/misc/nixos-artwork/wallpapers.nix

  Log Message:
  ---
  nixos-artwork: do not leak nix hashes to filenames in /share/artwork/gnome/ 
(#26566)

* nixos-artwork: do not leak nix hashes to filenames /share/artwork/gnome/

* simplify


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 26abdb: xfce4-dockbarx-plugin: fix unwrapped python script...

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 26abdb81c8331797ca4655b73c7a1d4ebfe2d020
  
https://github.com/NixOS/nixpkgs/commit/26abdb81c8331797ca4655b73c7a1d4ebfe2d020
  Author: volth <vo...@webmaster.ms>
  Date:   2017-06-10 (Sat, 10 Jun 2017)

  Changed paths:
M pkgs/desktops/xfce/panel-plugins/xfce4-dockbarx-plugin.nix

  Log Message:
  ---
  xfce4-dockbarx-plugin: fix unwrapped python scripts


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] concatAttrs :: [attrSet] -> attrSet ?

[Volth]

there is also lib.mkMerge to handle nested attrs

On 5/29/17, Domen Kožar  wrote:
> Note that this will fail if you'll nest the attributes, one will override
> the other.
>
> nix-repl> :p concatAttrs [ {x={a =3;};} {x={ b= 4;};} ]
> { x = { b = 4; }; }
>
>
> On Sun, May 28, 2017 at 5:23 PM, Sergiu Ivanov  wrote:
>
>> Hey Leo,
>>
>> Thus quoth  Leo Gaspard  at 13:05 on Sun, May 28 2017:
>> > On 05/28/2017 02:58 PM, Sergiu Ivanov wrote:
>> >> My use case is quite specific. I do this, approximately:
>> >>
>> >>   let func name = { "${name}" = something name; };
>> >>   in concatAttrs (map func [ "name1" "name2" ])
>> >
>> > If this is your use case, you could also be interested in `genAttrs`
>> > defined in `lib/attrsets.nix` ;)
>>
>> Excellent!  Worked like a charm, thanks a lot!  (After I realised I had
>> to use it like pkgs.lib.genAttrs in my context :-) )
>>
>> --
>> Sergiu
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Declarative VMs in libvirt/Qemu

[Volth]

https://github.com/Nekroze/kvms.nix

On 5/16/17, Justin Humm  wrote:
> Thanks for the hint. I've already seen this, and it is quite exactly
> what I want, but I considered it too far away from completion for my use
> case.
>
> Does anyone use declarative VMs right now?
>
> Best,
> Justin
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How to traverse "/nix-support/propagated-native-build-inputs" in nix ?

[Volth]

As a quick hack, I solved it by make a derivation which do the
travercs in its bash code (in buindCommand) producing a text file as
an output.

inspecting "myPackage.propagatedBuildInputs" looks a cleaner solution, thank you

On 5/14/17, Vladimír Čunát <vcu...@gmail.com> wrote:
> On 05/14/2017 05:16 PM, Volth wrote:
>> I would like to get list of all propagated build inputs in nix
>
> In general you can't even get that file.  As it is designed, that list
> is defined by contents of files in build output, so you can't be certain
> until you produce the path (which is what you want to avoid, if I get
> you right).
>
> You can, of course, inspect myPackage.propagatedBuildInputs
> (recursively), etc.
>
> --Vladimir
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] How to traverse "/nix-support/propagated-native-build-inputs" in nix ?

[Volth]

Hi

I would like to get list of all propagated build inputs in nix

But the code like

```
  get-propagated-derivations = s:
if (lib.isStorePath s) then
  if (builtins.pathExists
"${s}/nix-support/propagated-native-build-inputs") then
lib.concatMap get-propagated-derivations (lib.splitString
" " (lib.fileContents
"${s}/nix-support/propagated-native-build-inputs"))
  else
[s]
else
  [s];

```

does not work becase builtins.pathExists throws with "cannot refer to
other paths".
lib.fileContents has no such problem but it throws unless the file exists.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] How to implement fetchMaven as pure function ?

[Volth]

There are already two versions in nixpkgs ("fetchMaven" and
"fetchMavenArtifact") which are just wrappers for "fetchurl".


Basicaly "fetchMaven" is merely a function giving argument
"org.scala-lang:scala-compiler:2.11.11" produces a derivation by
downloading two files

  
https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.11.11/scala-compiler-2.11.11.pom
  
https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.11.11/scala-compiler-2.11.11.jar

into $out/share/java/.


Besides the obvious hacky ways, how would it be possible to implement
"fetchMaven" in a way that the output path in nixstore depend only on
the argument ?

Only on the string "org.scala-lang:scala-compiler:2.11.11" and not on
curl version or buildScript's evolution (e.g. it could download PGP
signature and validate it)

Then the jar files would be easily discoverable by the external tools
doing the same calculation.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] a51663: pngquant: restored 'patchShebangs' because build f...

[Volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a51663f9daba1abcfeeeb4458dc5b4282a831d9f
  
https://github.com/NixOS/nixpkgs/commit/a51663f9daba1abcfeeeb4458dc5b4282a831d9f
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-05-08 (Mon, 08 May 2017)

  Changed paths:
M pkgs/tools/graphics/pngquant/default.nix

  Log Message:
  ---
  pngquant: restored 'patchShebangs' because build failed on Hydra


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Build a derivation using sbt

[Volth]

Hello

Anyone tried to build a derivation using sbt ?
I found no one such project in nixpkgs.

sbt feels very bad running under "nixbld1", it needs to create ~/.sbt
~/.ivy and to download tons of jars there...
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Need any mirror in Asia?

[Volth]

Actually, there are regions with bad connectity to Amazon's Cloudfront.
For example Russia, and, yes, Vietnam.

There are few obstacles:
1. the distribution model is not rsync-friendly and not well suited
for 3rd-party mirrors.
2. there is a  team promising to solve the geo-distribution issue
using IPFS. There is no results yet but the expectation from their
works lower priority of alternative solutions.
3. the majority of developers (and users?) are located in Cenral
Europe (NL,DE,CZ,SI,...) so the geodistrubution issue get very little
traction.

On 5/4/17, Karibu  wrote:
> Thanks for the prompt reply.
> So you don't need any mirror in Asia and no issue from the speed there
> I suppose.
>
> If one day, you will need one, you can count on me.
>
> Thanks
>
> Kari
>
> On Thu, 2017-05-04 at 14:43 +0200, Domen Kožar wrote:
>> This is not Gentoo. Our infrastructure is hosted by Amazon S3 and
>> globally distributed over cloudflare CDN.
>>
>> On Thu, May 4, 2017 at 2:41 PM, Karibu  wrote:
>> > Hi guys,
>> >
>> > Any idea about the RSYNC url I should use to do a mirror?
>> >
>> > Thanks
>> >
>> > On Tue, 2017-05-02 at 21:09 +0700, Karibu wrote:
>> > > Hehe no problem.
>> > >
>> > > Any mirror admin or dev to let me know the RSYNC url.
>> > > Thanks
>> > >
>> > > Kari
>> > >
>> > > On Tue, 2017-05-02 at 00:47 +0800, Wei Tang wrote:
>> > > >
>> > > > Hi Karibu,
>> > > >
>> > > > I live in Hong Kong, and I would definitely appreciate a mirror
>> > in
>> > > > Asia.
>> > > >
>> > > > -- Wei
>> > > >
>> > > > Karibu writes:
>> > > >
>> > > > >
>> > > > >
>> > > > > Hi guys,
>> > > > > I am the admin of the Vietnamese mirror (and blog)
>> > freedif.org
>> > > > > (mirror.freedif.org)
>> > > > >
>> > > > > I have some spare bandwidth and space and would like to
>> > support
>> > > > > your
>> > > > > project.
>> > > > >
>> > > > > Do you need a mirror in Vietnam (no problem to support
>> > > > > neighbourhood
>> > > > > countries)
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > > > Kari
>> > > > > ___
>> > > > > nix-dev mailing list
>> > > > > nix-dev@lists.science.uu.nl
>> > > > > https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>> > > ___
>> > > nix-dev mailing list
>> > > nix-dev@lists.science.uu.nl
>> > > https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>> > ___
>> > nix-dev mailing list
>> > nix-dev@lists.science.uu.nl
>> > https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>> >
>>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [RFC] Declarative Virtual Machines

[Volth]

I did not do benchmarks, just noticed that boot of /-on-tmpfs +
/nix/store on 9pfs is slower. The performance was not critical.
Anyway, thank you for msize suggestion, I will try it.

There was more resentiment than a point :)
If I need to make something just a bit different from what an existing
tool has been designed for, I cannot reuse existing code.
That "a bit different", could be, for example, creating a NixOS .qcow2
on a remote Ubuntu server. I cannot use make-nix-disk, so I copy-paste
some code from it. It uses runInLinuxVM, which cannot be used on
Ubuntu as well, so code from runInLinuxVM is copied with some
modifications ( libguestfs cannot be used, because on its appliance
"switch-to-configuration" does not work). So it results in a new tool
of 500-1000 lines, made of copy-pasted and slightly modified snippets.
What you do is something similar - "same as nixos-containers, but for
qemu", which has some basic assumptions hardcoded, such as "shared nix
store" and "host is nixos too" and "VM is to run on the same machine
where it was built". The next guy, whose task would not fit with the
assumptions, ends up in creating another big tool which also creates
qcow2/vdi/raw/whatever and launch qemu/virtulbox/docker just in a bit
different way.
The point is the existing guest-creation-and-control tools are not
flexible enough, and this results in we have so many of them doing
very similar things and planning and making new ones (besides those
which are already in nixos and nixops, I have seen some other tools on
github, and I believe many of us have own).
Alhough all these tools are happy to use NixOS module system, they may
be happy as well to share and reuse something else: definition of
machines, of networks, a sofisticated tool to work with VM-images
(independent on runInLinuxVM), ...

On 4/23/17, Leo Gaspard <l...@gaspard.io> wrote:
> On 04/22/2017 11:07 PM, Volth wrote:
>> Hello.
>>
>> There are few objections against qemu with shared /nix/store:
>>
>> 1. It is fast to create but slow to run. Boot time with shared
>> /nix/store is about twice slow than with everything on qcow2.
>>
>> 2. 9P is unstable, every couple of months there is a new bug (real
>> bugs, not CVEs: wrong data read, the driver got stuck, etc)
>
> Hmm, I wasn't aware of these two first points (didn't test anything),
> intuitively virtfs was supposed to be faster in my mind, as it skipped
> one level of parsing the qcow2 image. Guess I should have actually
> tested instead of relying on gut feeling. That said, I'd like to ask
> whether you set the msize=262144 (or similarly high value) option for
> the 9p mount on the guest, during these benchmarks? It greatly
> influences performance when the 9p is not over network as it used to be
> designed for.
>
> As for stability, in my test setup I haven't hit any non-permanent issue
> (things like being unable to chown / in a mapped-file mode have
> appeared, though, but it's not anything that would compromise the
> stability of a production system as it can be seen during development),
> so I assumed it was pretty stable.
>
>> 3. host GC cannot see the runtime roots inside the VM, so all the
>> guest system closures from its last boot should be preserved from host
>> GC. It may be tricky to debug.
>
> This is not really an issue, as the store is not shared with the guest,
> but rather a rsync of the part of the store that interests the guest (in
> order to avoid information leaks). So the guest never actually sees the
> host store.
>
> The reason for picking 9p instead of qcow2 to hold this copy of the
> store was to allow upgrades to the VM without rebooting it (as the VM
> doesn't have access to its configuration it can't just perform the
> upgrade from the inside), so I thought that future work may include the
> host rsync'ing the relevant files into the 9p export path, and then just
> push a bash script at a shared place the guest would have a cron to
> execute as root, that would trigger a call to the new profile's
> switch-to-configuration.
>
> This would also be possible with the store on a qcow2 image, but would
> entail also pushing all the store paths through this shared path and
> having the guest copy it to its nix-store. I guess it's possible and
> doesn't involve many drawbacks, except a time-to-upgrade quite increased
> due to the two copies instead of one.
>
> In the downsides of using qcow2, I can see that if using a CoW FS (such
> as btrfs) shared between /nix/store and /var/lib/vm/${vmname}/store,
> it's possible to have the store of the guest take 0 additional space,
> while using a qcow2 image makes it much harder (and I don't think any
> widely used FS performs block-level deduplication, but 

[Nix-commits] [NixOS/nixpkgs] bfff24: qemu: 2.8.1 -> 2.8.1.1

[Volth]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: bfff24189cae0bf6eceacd5c3e4d8464ba72b895
  
https://github.com/NixOS/nixpkgs/commit/bfff24189cae0bf6eceacd5c3e4d8464ba72b895
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-04-23 (Sun, 23 Apr 2017)

  Changed paths:
M pkgs/applications/virtualization/qemu/default.nix

  Log Message:
  ---
  qemu: 2.8.1 -> 2.8.1.1


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 1931ad: qemu: 2.8.1 -> 2.9.0

[Volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1931ad0e2cbb636d9fa09e3aa5afff24cc9b7deb
  
https://github.com/NixOS/nixpkgs/commit/1931ad0e2cbb636d9fa09e3aa5afff24cc9b7deb
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-04-23 (Sun, 23 Apr 2017)

  Changed paths:
M pkgs/applications/virtualization/qemu/default.nix
M pkgs/applications/virtualization/qemu/no-etc-install.patch

  Log Message:
  ---
  qemu: 2.8.1 -> 2.9.0


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 7b8043: qemu: 2.8.0 -> 2.8.1

[Volth]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 7b80438e55a5b35615e4e5cce5fe04cbcb2c8bb0
  
https://github.com/NixOS/nixpkgs/commit/7b80438e55a5b35615e4e5cce5fe04cbcb2c8bb0
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-04-23 (Sun, 23 Apr 2017)

  Changed paths:
M pkgs/applications/virtualization/qemu/default.nix
M pkgs/applications/virtualization/qemu/no-etc-install.patch

  Log Message:
  ---
  qemu: 2.8.0 -> 2.8.1


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] tigervnc service?

[Volth]

I used it to have a graphical console to libvirt-lxc containers in
virt-manager (which has vnc client):

---
  vnc-backdoor = { config, pkgs, lib, ... }: {
config = {
systemd.services."vncserver" = {
  description = "VNC Server";
  after = [ "network.target" ];
  wantedBy = [ "multi-user.target" ];

  path = [ pkgs.xorg.xauth pkgs.perl ];

  environment.HOME = "/root";
  environment.USER = "root";

  preStart = ''
${pkgs.coreutils}/bin/rm   -rf $HOME/.vnc
${pkgs.coreutils}/bin/mkdir -p $HOME/.vnc
echo -e '#!${pkgs.bash}/bin/bash\n${pkgs.xterm}/bin/xterm
&\nwhile [ true ]; do ${pkgs.icewm}/bin/icewm; done' >
$HOME/.vnc/xstartup
${pkgs.coreutils}/bin/chmod 755 $HOME/.vnc/xstartup
  '';

  serviceConfig = {
Type = "forking";
ExecStart = "${pkgs.tigervnc}/bin/vncserver -geometry
1024x768 -securitytypes none :1";
ExecStop = "${pkgs.tigervnc}/bin/vncserver -kill :1";
  };
};
};
  };


On 4/22/17, Tim Sears  wrote:
> Has anyone managed to get tigervnc or any other vnc server running as a
> service under nixos?
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [RFC] Declarative Virtual Machines

[Volth]

Hello.

There are few objections against qemu with shared /nix/store:

1. It is fast to create but slow to run. Boot time with shared
/nix/store is about twice slow than with everything on qcow2.

2. 9P is unstable, every couple of months there is a new bug (real
bugs, not CVEs: wrong data read, the driver got stuck, etc)

3. host GC cannot see the runtime roots inside the VM, so all the
guest system closures from its last boot should be preserved from host
GC. It may be tricky to debug.


Also, the whole idea could be splited to simpler building blocks and
generalized to use with Virtualbox and different kind of containers.
One of the block could be, say, "nix-slave" - the NixOS install which
is always configured on an external machine and then run inside VM or
container or deployed to the cloud.
So it cannot do "nixos-rebuild" from inside and has limited set of
features, no profiles (no need to "boot previous version" if the
previous version could be written to the .qcow2 of a powered-off VM),
no "nix-env", etc
Then, a tool to make container/VM out of configuation.
Then, a VM-agnistic tool to configure network of that slaves.

Well, it sounds very familiar.
We indeed have this pattern in so many places: NixOS containers,
NixOps, test-driver, "nixos-install build-vm", runInLinuxVM,
make-disk-image.nix, your proposal, etc
Each of them solves one narrow task and the code is not reuseful. For
example, when I need to create .qcow2 outside the nix store, or
install/repair nixos on exising .qcow2, I end up writing by own set of
tools (or using RedHat's libguestfs, which is... another VM appliance)
Perhaps, there could be some common ground which unifies that kind of
tasks as an alternative to creating new bloated tools with many
options?

On 4/22/17, Leo Gaspard  wrote:
> Hello world!
>
> Just wanting to bump [1] ; as I opened it two weeks ago and still don't
> have a single comment, despite trying to put the link on IRC twice. (and
> I don't really get whether these "thumbs up" mean "good to go")
>
> So here it is, feel free to say I'm advocating nonsense, I just don't
> really know what to do next :)
>
> Cheers,
> Leo
>
>
> [1] https://github.com/NixOS/rfcs/pull/12
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How to downgrade or patch freetype-2.7 ?

[Volth]

On 4/20/17, Thomas Tuegel <ttue...@mailbox.org> wrote:
> Volth <vo...@volth.com> writes:
>
>> The second (http://imgur.com/MDiydzS) is what we get with these
>> fontconfig rules on NixOS-17.09 (freetype-2.7.1) with default v40.
>> Antialias is off, but hinting is not in action.
>
> Did you intentionally turn off hinting in that sample, or is it just not
> working? Even with v40, it should be possible to achieve good results
> with full hinting and no antialiasing.

Hinting is on, the difference between the 2nd and the 3rd images is
only 35 vs. 40 in the environment variable.
If you want to reproduce, you may disable antialiasing and enable full
hinting for pkgs.ubuntu_font_family or pkgs.liberation_ttf_v1_binary
which are in nixpkgs.

>> PS. v38 works similar to v40. It easy to turn in off by
>> "config.fonts.fontconfig.ultimate.enable = false;".
>> What I was looking for is a similar easy way to turn off v40 appeared
>> in NixOS-unstable.
>
> That setting doesn't actually turn off v38! It turns off the
> fontconfig-ultimate settings, but FreeType 2.6 is still patched to use
> v38 instead of v35. So, if you could get acceptable rendering with
> FreeType 2.6 on NixOS (which used v38), we should also be able to fix it
> with FreeType 2.7 (v40) too.

There was a visually similar issue in 17.03 with liberation_ttf_2.xx
[1] which forced me to downgrade to 1.07. In 17.09 even
liberation_ttf_1.07.xx became broken.

There are clearly two diverging ways: the mainstream with
antialiasing, subpixel rendering, gray-on-white texts, ... and the
minority people who want to stay with contrast fonts rendered using
only two colors (foreground and background). In order to stay the
ground both the fonts and freetype are to be downgraded to their
previous versions, so it won't be so long to lose the battle. Anyway,
as dpi grows and pixels became invisible, it won't be the matter at
all.

1. https://github.com/NixOS/nixpkgs/issues/21806
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How to downgrade or patch freetype-2.7 ?

[Volth]

Unfortunately, $FREETYPE_PROPERTIES is censored by sudo and chrome
sandbox (and the bug is WONTFIX in both freetype and chrome)

On 4/19/17, Vladimír Čunát <vcu...@gmail.com> wrote:
> Just my two cents.
>
> On 04/19/2017 01:25 PM, Volth wrote:
>> There is upstream-recommended way to "globally" set old interpreted
>> version via environment variable FREETYPE_PROPERTIES, which is not a
>> solution obviously: many processes do not inherit parent environment
>> (sudo, browser renderers run in sandbox, ...) .
>
>
>> Oh, LD_LIBRARY_PATH advice is very helpful.
>
> I can't see how setting $LD_LIBRARY_PATH is easier than setting
> $FREETYPE_PROPERTIES.  I believe the latter is safer, as it should only
> affect freetype.
>
> If you want details on (some) potential dangers of $LD_LIBRARY_PATH on
> nontrivial libs, you can study
> https://github.com/NixOS/nixpkgs/issues/16779
>
> --Vladimir
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How to downgrade or patch freetype-2.7 ?

[Volth]

Better to show: http://imgur.com/a/a5XpN

The first image (http://imgur.com/zOyxMh7) is with the default
NixOS-17.09 (freetype-2.7.1) settings.
Approximately the same is on 17.03 with its defaults.
Fonts are blurry, width of cells is wrongly calculated.

This could be fixed with fonconfig, and I did fix it with fontconfig on 17.03:
---
  
  PragmataPro
 
 false
 
 hintfull
 
 false
 
  
---
The same fontconfig settings applied to:

PragmataPro
PragmataPro Mono <- that font family

Liberation Sans
Liberation Serif
Liberation Mono <- version 1.07, not NixOS's default 2.0x

Liberastika <- fork of liberation-1.07 with some fixes

Ubuntu
Ubuntu Condensed
Ubuntu Mono <- these are not so bad with the defaults, it is just a
matter of taste to have them antialiased, especially "Ubuntu
Condensed"

Arial
Times New Roman
Gulim
Meiryo
Microsoft YaHei <- microsoft fonts, copied from windows machine,
antialiasing can make a blotch out of a Chinese hieroglyph.

(As you see, almost all these fonts are either commercial or license
violation, so no wonder gnu's freetype does not support them well)

The second (http://imgur.com/MDiydzS) is what we get with these
fontconfig rules on NixOS-17.09 (freetype-2.7.1) with default v40.
Antialias is off, but hinting is not in action.

The third (http://imgur.com/sKs8ZrB) is v35, explicitly set on
NixOS-17.09 (freetype-2.7.1) or default on NixOS-17.03
(freetype-2.6.5).
Perfect.

PS. v38 works similar to v40. It easy to turn in off by
"config.fonts.fontconfig.ultimate.enable = false;".
What I was looking for is a similar easy way to turn off v40 appeared
in NixOS-unstable.

So I ended up creating a module:

```
{ config, pkgs, lib, ... }:

let
  my-freetype = pkgs.callPackage ./my-freetype { };
  my-freetype-32 = pkgs.pkgsi686Linux.callPackage ./my-freetype { };
  my-pragmatapro = pkgs.callPackage ./pragmatapro { };
  my-win2008fonts = pkgs.callPackage ./win2008fonts { };
  my-win2008fonts-cjk = pkgs.callPackage ./win2008fonts-cjk { };
in {
  config = {
fonts = {
  enableDefaultFonts = false;

  fonts = [
pkgs.xorg.fontbh100dpi
pkgs.xorg.fontmiscmisc
pkgs.xorg.fontcursormisc
pkgs.ubuntu_font_family
pkgs.liberation_ttf
pkgs.liberastika
my-pragmatapro
my-win2008fonts
my-win2008fonts-cjk
  ];

  fontconfig = {
hinting.autohint = false;

defaultFonts.serif = [ "Liberation Serif" "Times New Roman" ];
defaultFonts.sansSerif = [ "Liberastika" "Liberation Sans"
"Arial" "Ubuntu" ];
defaultFonts.monospace = [ "PragmataPro Mono" ];

confPackages = [ (import ./font-conf { inherit (pkgs)
runCommand fontconfig; }) ]; # it adds fontconfig xml

useEmbeddedBitmaps = true; # 17.09+
penultimate.enable = false; # 17.09+
ultimate.enable = false;
  };
};

environment.sessionVariables.LD_LIBRARY_PATH = [
"${my-freetype}/lib" "${my-freetype-32}/lib" ];

nixpkgs.overlays = [
  (self: super: {
# google-chrome, torbrowser (..., gorilla, dropbox,
cytrix-receiver, spideroak, ...) add freetype to LD_LIBRARY_PATH in makeWrapper
torbrowser = super.torbrowser.override {
  freetype = my-freetype;
};
google-chrome = super.google-chrome.override {
  freetype = my-freetype;
};
liberation_ttf = self.liberation_ttf_v1_binary;
  })
];

  };
}

```

On 4/19/17, Thomas Tuegel <ttue...@mailbox.org> wrote:
> Volth <vo...@volth.com> writes:
>
>> Fontconfig does not help here. The problem is with all fonts with
>> manual hinting, also with all old windows fonts. Those fonts are from
>> pre-anti-aliasing ages.
>> Full hinting enabled + anti-aliasing disabled is the only suitable
>> mode for them.
>
> We can use Fontconfig to set per-font hinting and anti-aliasing
> settings! :-)
>
> We can't toggle the interpreter version directly through Fontconfig, but
> at `full' hinting, the v40 interpreter should give the same results as
> v38, especially with anti-aliasing disabled. I can't speak reliably
> about the v35 interpreter because NixOS has always used v38 in the past.
>
> I assume that "old windows fonts" means corefonts? Are you having
> trouble with any other fonts besides PragmataPro? If you give me a list,
> I can put together some samples to see if we can't find something better
> for everyone.
>
> Regards,
> Tom
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How to downgrade or patch freetype-2.7 ?

[Volth]

Oh, LD_LIBRARY_PATH advice is very helpful. Some minor issues left
(including one of how how to concatenate my LD_LIBRARY_PATH and
OpenGL's), but it solved the mass-rebuild problem. Now I could patch
the library or even use the good old 2.6.

Fontconfig does not help here. The problem is with all fonts with
manual hinting, also with all old windows fonts. Those fonts are from
pre-anti-aliasing ages.
Full hinting enabled + anti-aliasing disabled is the only suitable
mode for them.

On 4/19/17, Thomas Tuegel <ttue...@mailbox.org> wrote:
> Volth <vo...@volth.com> writes:
>
>> Freetype changed defaults in 2.7, the truetype interpreter became v40
>> instead of v35.
>> The new defaults are incomatible in a weird way with some old fonts
>> (notably PragmataPro).
>
>> But on NixOS this - flipping one bit in libfreetype.so - means either
>> to recompile all NixOS (too many packages depends on freetype, not
>> only GUI apps, also devtools) or to live with corrupt nixstore.
>>
>> Is there a more elegant solution?
>
> There is a more elegant work-around, and possibly an actual solution.
>
> First, the workaround: add a modified FreeType library to
> LD_LIBRARY_PATH. This environment variable should be passed through to
> every program on NixOS because that is how we handle the impurity of
> OpenGL drivers.
>
> Second, I can probably fix the way PragmataPro renders by applying
> selective Fontconfig rules. Could you please tell me, what settings are
> you using in `fonts.fontconfig'? If you have changed any
> Fontconfig settings like DPI or hinting through your desktop
> environment, please share that also. Unfortunately, it is not possible
> to simply change the interpreter from v40 to v35 through Fontconfig
> rules. However, changing the hinting level for that font only can
> essentially achieve the same thing.
>
> Regards,
> Tom
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] How to downgrade or patch freetype-2.7 ?

[Volth]

Hi

Freetype changed defaults in 2.7, the truetype interpreter became v40
instead of v35.
The new defaults are incomatible in a weird way with some old fonts
(notably PragmataPro).

There is upstream-recommended way to "globally" set old interpreted
version via environment variable FREETYPE_PROPERTIES, which is not a
solution obviously: many processes do not inherit parent environment
(sudo, browser renderers run in sandbox, ...) .

So fretype is to be patched and recompiled. This is simple on say
Ubuntu, make a new .deb, install it.

But on NixOS this - flipping one bit in libfreetype.so - means either
to recompile all NixOS (too many packages depends on freetype, not
only GUI apps, also devtools) or to live with corrupt nixstore.

Is there a more elegant solution?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] NixOS and nix 1.12

[Volth]

Hi

Is nix-1.12 going to replace traditional nix command line utilities on NixOS ?
If yes, when it is going to happen, approximately?
With NixOS-17.09, 18.03 or later?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Is CI of pull requests broken?

[Volth]

I noticed that many pull requests [1] have failed Travis CI tests.
The reasons of failures are often very strange, especially if the
change introduced by PR looks innocent: some "file not found" or
"build times out".

Moreover, many of the merged pull requests [2] also have failed CI. It
looks like the failed CI signal nothing to the people who do merge.
Everybody just knows that CI is broken and its success or failure
means nothing. Is it so?

1. https://github.com/NixOS/nixpkgs/pulls
2. https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aclosed
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 6c5128: kernel: fix 9p issues

[Volth]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 6c5128c9c801645faa95db2dd3b36df24da39d33
  
https://github.com/NixOS/nixpkgs/commit/6c5128c9c801645faa95db2dd3b36df24da39d33
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-04-04 (Tue, 04 Apr 2017)

  Changed paths:
A pkgs/os-specific/linux/kernel/p9-fixes.patch
M pkgs/os-specific/linux/kernel/patches.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  kernel: fix 9p issues

[tuomas: rename the patch from 9p-hacks to something slighly more
meaningful]
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>

(cherry picked from commit ed41d50e9fe3d942cfde37e84de781c096309e5b)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] b78f16: kernel: do not remove .o files on installPhase

[Volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b78f16b33772722d19c9cbe4145953f9c4b76fc8
  
https://github.com/NixOS/nixpkgs/commit/b78f16b33772722d19c9cbe4145953f9c4b76fc8
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-04-01 (Sat, 01 Apr 2017)

  Changed paths:
M pkgs/os-specific/linux/kernel/manual-config.nix

  Log Message:
  ---
  kernel: do not remove .o files on installPhase


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] ed41d5: kernel: fix 9p issues

[Volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: ed41d50e9fe3d942cfde37e84de781c096309e5b
  
https://github.com/NixOS/nixpkgs/commit/ed41d50e9fe3d942cfde37e84de781c096309e5b
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-04-01 (Sat, 01 Apr 2017)

  Changed paths:
A pkgs/os-specific/linux/kernel/p9-fixes.patch
M pkgs/os-specific/linux/kernel/patches.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  kernel: fix 9p issues

[tuomas: rename the patch from 9p-hacks to something slighly more
meaningful]
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Should we drop 9P?

[Volth]

They are not holes if you mean security, they are stability and data
integrity issues we regulary step into as server load and number of
files grow.

The fourth issue is https://lkml.org/lkml/2016/11/24/721, it has not
its own nixpkgs ticket, discussed in
https://github.com/NixOS/nixpkgs/issues/23957 's comments.

On 3/21/17, Jookia <166...@gmail.com> wrote:
> 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

[Nix-commits] [NixOS/nixpkgs] a7732d: babelstone-han: init at 9.0.2

[Volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a7732d6f541d82cbfc8777dfe007efb62bf69656
  
https://github.com/NixOS/nixpkgs/commit/a7732d6f541d82cbfc8777dfe007efb62bf69656
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-03-21 (Tue, 21 Mar 2017)

  Changed paths:
A pkgs/data/fonts/babelstone-han/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  babelstone-han: init at 9.0.2


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 4e7496: virt-manager: 1.4.0 -> 1.4.1 (#24149)

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4e749683e65588028d134628ed70eb129c3df87c
  
https://github.com/NixOS/nixpkgs/commit/4e749683e65588028d134628ed70eb129c3df87c
  Author: volth <vo...@webmaster.ms>
  Date:   2017-03-21 (Tue, 21 Mar 2017)

  Changed paths:
M pkgs/applications/virtualization/virt-manager/default.nix

  Log Message:
  ---
  virt-manager: 1.4.0 -> 1.4.1 (#24149)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Should we drop 9P?

[Volth]

9P is used by NixOS to share host's nix store with Qemu virtual
machines. Such technique is used in the build process, in the
test-driver, so to say in the critical places.
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.

Shouldn't we replace 9P with something battle-tested like NFS or Samba?
It may also improve the performance because 9P server works in qemu
process, in user mode and there are as many servers as virtual
machines running.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How do you work on big packages?

[Volth]

nix-shell on its installPhase has no rights to write to /nix/store,
installPhase always fails.


I am thinking about something like converting a derivation (a .drv
file) into two files:

1. a .sh file, which would do unpackPhase, patchPhase, configurePhase,
buildPhase using the current directory, not something in /tmp.
nix-shell fits very well here.
Ideally, this script just launches nix-shell to perform these phases.

2. a .nix file with src= pointing to the build directory made by the
previous script and performs buildPhase, checkPhase, installPhase,
fixupPhase. this .nix file could be used substitute a .nix file in
all-packages.nix during troubleshooting.

So buildPhase is performed twice (we assume it is to be idempotent,
isn't it?), second time quickly because all .o files are already
compiled. And it would automatically recompile only changed sources.

In practice, it is not so beautiful. For example, kernel derivation
sets environment variables in preUnpack then uses in buildPhase so it
would be a trouble to simply skip all the phases before buildPhase.

On 3/17/17, Profpatsch <m...@profpatsch.de> wrote:
> On 17-03-17 06:04pm, Volth wrote:
>> "nix-shell" would be a super option here if it could handle
>> "installPhase" (this seems easy to fix) and .nix files less trivial
>> than "hello.nix" (this seems not easy to fix; for example "nix-shell
>> '' -A linux_4_4" has no "configurePhase", and there are
>> similar problems with almost every of the big projects; nix-shell
>> launches "make" when "nix-build" launches "cmake" or vice-versa, etc)
>
> That’s a pretty common stumbling block.
>
> If someone defines his own `installPhase` for example,
> the `installPhase` shell function is just the standard
> stdenv `installPhase`. What you want to call is rather
> the contents of `$installPhase` (the variable), since
> that contains the phase you defined in `mkDerivation`.
>
> nix-shell
> $ unpackPhase
> unpacking …
> $ configurePhase
> configuring …
> $ buildPhase
> …
> $ $installPhase
> running your installPhase
>
>
> There is not much abstraction. Every nix attribute within
> `derivation` (and by extension `mkDerivation`) will end up
> as a bash shell variable in your shell (and your build env).
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How do you work on big packages?

[Volth]

What I meant in the original question is more about troubleshooting
than development.
That development is incorporated in the deployment chain all other
steps are already powered by nix: build a (patched) kernel, then build
system closures with it, then test-driver scripts, then deploy/run
them...


On 3/17/17, Vladimír Čunát  wrote:
> On 03/17/2017 10:34 PM, Dmitry Kalinkin wrote:
>> Also it is funny how your statement is followed by some good advice
>> on how to turn nix into even better dev platform. I will only add
>> that one could also use ccache to speedup builds:
>
> I do believe the intention was for "SW distribution" etc, at least
> primarily, and the suitability for development is a by-product due to
> some properties, e.g. easy (non-)mixing of development and stable
> versions/configs.  Marc can surely remember the earlier days of NixOS.
>
> It's even possible to use nix-build instead of make to compile
> individual files, but there it just doesn't seem to be very suitable...
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] How do you work on big packages?

[Volth]

For example, you are working on patch for kernel or chromium or
something huge like this.

src= in your x.nix points to a local working directory, so every
change would result in rebuilding of the deviation and its dependants.
Nice so far.

The problem is any change implies full rebuild, because .o files are
not preserved between the builds, and in case of big projects it takes
hours instead of seconds.

What could be done here?
An nix-build option to forcible preserve tmp directories
(--just-keep-and-reuse-tmp-i-know-what-i-am-doing) ?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] d58891: lxc: ensure directory /var/lib/lxc/rootfs

[Volth]

  Branch: refs/heads/release-17.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d588913bae9611d6af20695b34f3beb352dcccd7
  
https://github.com/NixOS/nixpkgs/commit/d588913bae9611d6af20695b34f3beb352dcccd7
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-03-15 (Wed, 15 Mar 2017)

  Changed paths:
M nixos/modules/virtualisation/lxc.nix

  Log Message:
  ---
  lxc: ensure directory /var/lib/lxc/rootfs

(cherry picked from commit bcc4c261bea58cbababec413c1faa074d1a90efd)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] bcc4c2: lxc: ensure directory /var/lib/lxc/rootfs

[Volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: bcc4c261bea58cbababec413c1faa074d1a90efd
  
https://github.com/NixOS/nixpkgs/commit/bcc4c261bea58cbababec413c1faa074d1a90efd
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-03-15 (Wed, 15 Mar 2017)

  Changed paths:
M nixos/modules/virtualisation/lxc.nix

  Log Message:
  ---
  lxc: ensure directory /var/lib/lxc/rootfs


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] LXC containers on NixOS

[Volth]

Hello

I saw (in blogs, issue comments, ...) then some of you are using LXC
containers with NixOS as host, even in production.

Could you please share your setup?

My attempts to use them encounter the showstopper bugs: raw LXC
containers do not start
(https://github.com/NixOS/nixpkgs/issues/23604).
libvirt-lxc works, but "virsh -c lxc:/// destroy my-container" does
not kill the container processes.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Copy a closure to machine with no Nix installed on it

[Volth]

Oh, I forgot about it.

Anyway, so far I need to distribute test scripts, not the production
software. It would be too slow to upload big bundle each time.
"nix-copy-closure" or "rsync" would reuse common files from previous
uploads.

On 3/2/17, David Kleuker <p...@davidak.de> wrote:
> Hello Volth,
>
> some days ago https://github.com/matthewbauer/nix-bundle was mentioned on
> the ML.
>
> I havn't tested it, so i can't say how mature and stable it is, but it
> should be exactly what you are looking for.
>
> When you have tested it, i would like to know if it works for you.
>
> kind regards
> davidak
>
>>
>> Volth <vo...@volth.com> hat am 2. März 2017 um 17:38 geschrieben:
>>
>> Hello
>>
>> What is a good way to copy a closure to a Linux machine where Nix is
>> not installed (and it is tricky to install: 1. there is only root
>> account and 2. there may be no Internet access) ?
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Copy a closure to machine with no Nix installed on it

[Volth]

Yes, "nix-store -qR ..." and then "rsync" seems a simple and promising solution.
Thank you!

On 3/2/17, Tomasz Czyż <tomasz.c...@gmail.com> wrote:
> I assume you could do
> nix-store --export or nix-store --dump to prepare archive
> or you can query nix store for all dependnecies and with that list you can
> copy them using method of your choice
>
>
> 2017-03-02 16:38 GMT+00:00 Volth <vo...@volth.com>:
>
>> Hello
>>
>> What is a good way to copy a closure to a Linux machine where Nix is
>> not installed (and it is tricky to install: 1. there is only root
>> account and 2. there may be no Internet access) ?
>>
>> "nix-copy-closure" expects "nix-store" on the target machine.
>>
>> Would "nix-store" be a single executable with no dependencies, it
>> could be uploaded beforehand, but it has a lot of dependencies so its
>> uploading is also the task of uploading a closure to a machine without
>> Nix...
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
>
> --
> Tomasz Czyż
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Copy a closure to machine with no Nix installed on it

[Volth]

Hello

What is a good way to copy a closure to a Linux machine where Nix is
not installed (and it is tricky to install: 1. there is only root
account and 2. there may be no Internet access) ?

"nix-copy-closure" expects "nix-store" on the target machine.

Would "nix-store" be a single executable with no dependencies, it
could be uploaded beforehand, but it has a lot of dependencies so its
uploading is also the task of uploading a closure to a machine without
Nix...
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] c771d4: systemtap: 2016-09-16 -> 2017-02-04

[Volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: c771d499f9c44f9b20312d136617d127e090133d
  
https://github.com/NixOS/nixpkgs/commit/c771d499f9c44f9b20312d136617d127e090133d
  Author: Volth <vo...@webmaster.ms>
  Date:   2017-02-06 (Mon, 06 Feb 2017)

  Changed paths:
M pkgs/development/tools/profiling/systemtap/default.nix

  Log Message:
  ---
  systemtap: 2016-09-16 -> 2017-02-04


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 9e299a: liberastika: init at 1.1.5 (#22420)

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 9e299acf873285e30008588ac3e21cda12f865fb
  
https://github.com/NixOS/nixpkgs/commit/9e299acf873285e30008588ac3e21cda12f865fb
  Author: volth <vo...@webmaster.ms>
  Date:   2017-02-04 (Sat, 04 Feb 2017)

  Changed paths:
A pkgs/data/fonts/liberastika/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  liberastika: init at 1.1.5 (#22420)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 762cc1: virt-top: init at 1.0.8 (#21536)

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 762cc106b489a0eba55a72a8fdd17d24054132d9
  
https://github.com/NixOS/nixpkgs/commit/762cc106b489a0eba55a72a8fdd17d24054132d9
  Author: volth <vo...@webmaster.ms>
  Date:   2017-02-04 (Sat, 04 Feb 2017)

  Changed paths:
A pkgs/applications/virtualization/virt-top/default.nix
A pkgs/development/ocaml-modules/curses/default.nix
A pkgs/development/ocaml-modules/ocaml-gettext/default.nix
A pkgs/development/ocaml-modules/ocaml-libvirt/default.nix
M pkgs/top-level/all-packages.nix
M pkgs/top-level/ocaml-packages.nix

  Log Message:
  ---
  virt-top: init at 1.0.8 (#21536)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 69ed58: xorg.xserver: configure --with-xkb-path= (#21653)

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 69ed58d88ff7eb864ddb9cf0fd4fff9eebca9f0c
  
https://github.com/NixOS/nixpkgs/commit/69ed58d88ff7eb864ddb9cf0fd4fff9eebca9f0c
  Author: volth <vo...@webmaster.ms>
  Date:   2017-01-18 (Wed, 18 Jan 2017)

  Changed paths:
M pkgs/servers/x11/xorg/overrides.nix
M pkgs/servers/x11/xquartz/default.nix
M pkgs/servers/x11/xquartz/startx
M pkgs/tools/X11/bumblebee/default.nix
M pkgs/tools/X11/bumblebee/nixos.patch
M pkgs/tools/X11/xpra/default.nix
M pkgs/tools/X11/xpra/gtk3.nix
M pkgs/tools/misc/xvfb-run/default.nix

  Log Message:
  ---
  xorg.xserver: configure --with-xkb-path= (#21653)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 206fb8: flashplayer: 24.0.0.186 -> 24.0.0.194

[volth]

  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 206fb8f01b94d64c1c29c1aa7ed89c7e204614d7
  
https://github.com/NixOS/nixpkgs/commit/206fb8f01b94d64c1c29c1aa7ed89c7e204614d7
  Author: volth <vo...@webmaster.ms>
  Date:   2017-01-11 (Wed, 11 Jan 2017)

  Changed paths:
M pkgs/applications/networking/browsers/chromium/plugins.nix

  Log Message:
  ---
  flashplayer: 24.0.0.186 -> 24.0.0.194

(cherry picked from commit a3778f6e872cfeb95289829e0214b83313d9f22a)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 5bc7ce: xfce.mousepad: use keyfile instead of gconf (#2174...

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5bc7ceecef4a4ace0f8308d3094c718b2f096355
  
https://github.com/NixOS/nixpkgs/commit/5bc7ceecef4a4ace0f8308d3094c718b2f096355
  Author: volth <vo...@webmaster.ms>
  Date:   2017-01-09 (Mon, 09 Jan 2017)

  Changed paths:
M pkgs/desktops/xfce/applications/mousepad.nix

  Log Message:
  ---
  xfce.mousepad: use keyfile instead of gconf (#21747)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 06b372: miredo: init at 1.2.6

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 06b372f24f20dd36cc2b120dbaf0347041fefed3
  
https://github.com/NixOS/nixpkgs/commit/06b372f24f20dd36cc2b120dbaf0347041fefed3
  Author: volth <vo...@webmaster.ms>
  Date:   2016-12-31 (Sat, 31 Dec 2016)

  Changed paths:
M nixos/modules/module-list.nix
A nixos/modules/services/networking/miredo.nix
A pkgs/tools/networking/miredo/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  miredo: init at 1.2.6


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] ac97fb: fte: init at 0.50.02

[volth]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: ac97fbab3a8225343f8a9594821e66af51af048c
  
https://github.com/NixOS/nixpkgs/commit/ac97fbab3a8225343f8a9594821e66af51af048c
  Author: volth <vo...@volth.com>
  Date:   2016-12-19 (Mon, 19 Dec 2016)

  Changed paths:
M lib/maintainers.nix
A pkgs/applications/editors/fte/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  fte: init at 0.50.02


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits