[Nix-commits] [NixOS/nixpkgs] 756e69: syncthing: don't import from pkgs (#27029)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 756e69bf97c5170408b9511d57c04f4c772c458d https://github.com/NixOS/nixpkgs/commit/756e69bf97c5170408b9511d57c04f4c772c458d Author: volth 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
Branch: refs/heads/release-17.03 Home: https://github.com/NixOS/nixpkgs Commit: 4fb8f6f7a5b30f4baa5d654929e16174cd750816 https://github.com/NixOS/nixpkgs/commit/4fb8f6f7a5b30f4baa5d654929e16174cd750816 Author: Franz Pletz 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 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...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 85b9ff29e998f3462dd053c27f147de35779e1f1 https://github.com/NixOS/nixpkgs/commit/85b9ff29e998f3462dd053c27f147de35779e1f1 Author: Volth 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 ?
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 wrote: > On 4/20/17, Thomas Tuegel wrote: >> Volth 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
Branch: refs/heads/release-17.03
Home: https://github.com/NixOS/nixpkgs
Commit: 633d046590703f5e5ccbff5fcf686c8b884f8a37
https://github.com/NixOS/nixpkgs/commit/633d046590703f5e5ccbff5fcf686c8b884f8a37
Author: Vasiliy Solovey
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
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
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
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 ...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 8fe525b6c77ca5fdd2d1922d2e863fbb9198781c https://github.com/NixOS/nixpkgs/commit/8fe525b6c77ca5fdd2d1922d2e863fbb9198781c Author: Volth 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...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 13a8fa88011a45447ec26f81c473fe7f39172d02 https://github.com/NixOS/nixpkgs/commit/13a8fa88011a45447ec26f81c473fe7f39172d02 Author: volth 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...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 26abdb81c8331797ca4655b73c7a1d4ebfe2d020 https://github.com/NixOS/nixpkgs/commit/26abdb81c8331797ca4655b73c7a1d4ebfe2d020 Author: volth 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 ?
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
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 ?
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 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 ?
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 ?
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...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: a51663f9daba1abcfeeeb4458dc5b4282a831d9f https://github.com/NixOS/nixpkgs/commit/a51663f9daba1abcfeeeb4458dc5b4282a831d9f Author: Volth 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-commits] [NixOS/nixpkgs] 27e8a7: reaver: database on readwrite medium (#25321)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 27e8a7945b0523122ebdbf5350691dcfb9ca7549 https://github.com/NixOS/nixpkgs/commit/27e8a7945b0523122ebdbf5350691dcfb9ca7549 Author: volth Date: 2017-05-07 (Sun, 07 May 2017) Changed paths: M pkgs/tools/networking/reaver-wps-t6x/default.nix M pkgs/tools/networking/reaver-wps/default.nix Log Message: --- reaver: database on readwrite medium (#25321) ___ 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
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?
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
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 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 per
[Nix-commits] [NixOS/nixpkgs] bfff24: qemu: 2.8.1 -> 2.8.1.1
Branch: refs/heads/release-17.03 Home: https://github.com/NixOS/nixpkgs Commit: bfff24189cae0bf6eceacd5c3e4d8464ba72b895 https://github.com/NixOS/nixpkgs/commit/bfff24189cae0bf6eceacd5c3e4d8464ba72b895 Author: Volth 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
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 1931ad0e2cbb636d9fa09e3aa5afff24cc9b7deb https://github.com/NixOS/nixpkgs/commit/1931ad0e2cbb636d9fa09e3aa5afff24cc9b7deb Author: Volth 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
Branch: refs/heads/release-17.03 Home: https://github.com/NixOS/nixpkgs Commit: 7b80438e55a5b35615e4e5cce5fe04cbcb2c8bb0 https://github.com/NixOS/nixpkgs/commit/7b80438e55a5b35615e4e5cce5fe04cbcb2c8bb0 Author: Volth 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?
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
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 ?
On 4/20/17, Thomas Tuegel wrote: > Volth 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 ?
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 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 ?
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 wrote:
> Volth 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 ?
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 wrote: > Volth 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 ?
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
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?
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
Branch: refs/heads/release-17.03 Home: https://github.com/NixOS/nixpkgs Commit: 6c5128c9c801645faa95db2dd3b36df24da39d33 https://github.com/NixOS/nixpkgs/commit/6c5128c9c801645faa95db2dd3b36df24da39d33 Author: Volth 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 (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
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: b78f16b33772722d19c9cbe4145953f9c4b76fc8 https://github.com/NixOS/nixpkgs/commit/b78f16b33772722d19c9cbe4145953f9c4b76fc8 Author: Volth 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
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: ed41d50e9fe3d942cfde37e84de781c096309e5b https://github.com/NixOS/nixpkgs/commit/ed41d50e9fe3d942cfde37e84de781c096309e5b Author: Volth 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 ___ 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?
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
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: a7732d6f541d82cbfc8777dfe007efb62bf69656 https://github.com/NixOS/nixpkgs/commit/a7732d6f541d82cbfc8777dfe007efb62bf69656 Author: Volth 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)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 4e749683e65588028d134628ed70eb129c3df87c https://github.com/NixOS/nixpkgs/commit/4e749683e65588028d134628ed70eb129c3df87c Author: volth 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?
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?
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 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?
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
Re: [Nix-dev] How do you work on big packages?
"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) On 3/17/17, Linus Heckemann wrote: > On 17/03/17 16:00, Volth wrote: >> What could be done here? > nix-shell, and the upstream recommended build procedure. > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] How do you work on big packages?
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
Branch: refs/heads/release-17.03 Home: https://github.com/NixOS/nixpkgs Commit: d588913bae9611d6af20695b34f3beb352dcccd7 https://github.com/NixOS/nixpkgs/commit/d588913bae9611d6af20695b34f3beb352dcccd7 Author: Volth 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
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: bcc4c261bea58cbababec413c1faa074d1a90efd https://github.com/NixOS/nixpkgs/commit/bcc4c261bea58cbababec413c1faa074d1a90efd Author: Volth 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
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
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 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 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
Yes, "nix-store -qR ..." and then "rsync" seems a simple and promising solution. Thank you! On 3/2/17, Tomasz Czyż 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 : > >> 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
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
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: c771d499f9c44f9b20312d136617d127e090133d https://github.com/NixOS/nixpkgs/commit/c771d499f9c44f9b20312d136617d127e090133d Author: Volth 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)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 9e299acf873285e30008588ac3e21cda12f865fb https://github.com/NixOS/nixpkgs/commit/9e299acf873285e30008588ac3e21cda12f865fb Author: volth 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)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 762cc106b489a0eba55a72a8fdd17d24054132d9 https://github.com/NixOS/nixpkgs/commit/762cc106b489a0eba55a72a8fdd17d24054132d9 Author: volth 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)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 69ed58d88ff7eb864ddb9cf0fd4fff9eebca9f0c https://github.com/NixOS/nixpkgs/commit/69ed58d88ff7eb864ddb9cf0fd4fff9eebca9f0c Author: volth 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
Branch: refs/heads/release-16.09 Home: https://github.com/NixOS/nixpkgs Commit: 206fb8f01b94d64c1c29c1aa7ed89c7e204614d7 https://github.com/NixOS/nixpkgs/commit/206fb8f01b94d64c1c29c1aa7ed89c7e204614d7 Author: volth 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...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 5bc7ceecef4a4ace0f8308d3094c718b2f096355 https://github.com/NixOS/nixpkgs/commit/5bc7ceecef4a4ace0f8308d3094c718b2f096355 Author: volth 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] 50ec3f: test-driver: support punctuation in sendChars
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 50ec3fe1ac93d6059f67396fc7954c17084a1b20 https://github.com/NixOS/nixpkgs/commit/50ec3fe1ac93d6059f67396fc7954c17084a1b20 Author: volth Date: 2017-01-08 (Sun, 08 Jan 2017) Changed paths: M nixos/lib/test-driver/Machine.pm Log Message: --- test-driver: support punctuation in sendChars ___ 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
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 06b372f24f20dd36cc2b120dbaf0347041fefed3 https://github.com/NixOS/nixpkgs/commit/06b372f24f20dd36cc2b120dbaf0347041fefed3 Author: volth 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
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: ac97fbab3a8225343f8a9594821e66af51af048c https://github.com/NixOS/nixpkgs/commit/ac97fbab3a8225343f8a9594821e66af51af048c Author: volth 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
