Re: [Nix-dev] Stackage Support Will Be Discontinued

[Mathnerd314]

On Wed, Jun 8, 2016 at 5:34 AM, Peter Simons  wrote:
> Fellow Haskell Hackers,
>
> once the LTS 7.x package set comes out, I intend to make the following
> changes in "master":
>
>  - haskellPackages will loosely follow the most recent LTS release,
>
> where "loosely" means that we'll honor the mandated version bounds for
> libraries but tend to ignore them for executables.

8 months ago, I suggested using the latest versions of all packages
[1]. Apparently, that policy is too simple to receive any discussion.

I don't see any point in "loosely following" LTS releases, when
following the latest Hackage version is equally as prone to breakage
(i.e., very infrequently).

But such breakage does occur, so I propose an extension:
* hackage-packages.nix foo is always the latest Hackage version of the
package; but it will also contain old versions like foo_1_0_2
* Jailbreak all packages by default (because Hackage bounds tend to be
overly conservative), but allow whitelisting bounds on a per-package
basis
* If foo only works with bar version 1 instead of the latest bar, then
foo will depend on bar_1 instead of bar in hackage-packages.nix
* If the latest version of a package does not work on GHC version X,
then configuration-ghc-X.nix should override it to a version that does
work, or mark it as broken if no such version exists.
* If a package update breaks almost all dependencies, then the package
can be overridden to an earlier version in configuration-common.nix
(so all packages will use the old version)

People who want to follow a Stackage release can... use Stack. Stack
has been designed for this purpose and supports all the upgrade
patterns that people would like to follow. On the other hand, Stack
does not support using Haskell libraries from Nix [2][3], so there is
no point in doing anything in nixpkgs beyond providing an executable
Stack binary. If Stack does add support for downloading precompiled
Haskell libraries, it will be using their own infrastructure. Perhaps
this would be implemented with a separate repository and Hydra
instance, as zimbatm suggests, but I think it would probably not use
Nix at all.

-- Mathenrd314

[1] http://article.gmane.org/gmane.linux.distributions.nixos/18306
[2] https://github.com/commercialhaskell/stack/issues/1683
[3] 
https://github.com/commercialhaskell/stack/blob/master/doc/nix_integration.md
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Did we just get windows support for free?

[Mathnerd314]

The talk is finished. There's also a pre-recorded demo:
https://channel9.msdn.com/Events/Build/2016/P488

Apparently the files are stored in a hidden user directory as normal NTFS
files. It's still unclear why the filesystem appears as read-only, but
apt-get does work, so I imagine Nix will work fine too, unless it uses one
of the unimplemented syscalls. it's not going to be available for another
1-2 weeks, and then only to Windows Insiders (but it's free to join that
program).

I don't think Nix should drop MinGW or Cygwin support though (what little
works), since it will still be useful for compiling GUI things (e.g. SDL
games).

-- Mathnerd314

On Wed, Mar 30, 2016 at 1:01 PM, Mathnerd314 <mathnerd314@gmail.com>
wrote:

> The talk was scheduled before today; I think it's too early for April.
>
> https://channel9.msdn.com/Events/Build/2016/C906
>
> What's not clear is how the linux files are stored; it looks like the root
> filesystem is read-only in Dustin Kirkland's post, which would preclude
> using a package manager.
>
> -- Mathnerd314
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Did we just get windows support for free?

[Mathnerd314]

The talk was scheduled before today; I think it's too early for April.

https://channel9.msdn.com/Events/Build/2016/C906

What's not clear is how the linux files are stored; it looks like the root
filesystem is read-only in Dustin Kirkland's post, which would preclude
using a package manager.

-- Mathnerd314

On Wed, Mar 30, 2016 at 12:32 PM, Kosyrev Serge <_deepf...@feelingofgreen.ru
> wrote:

> Kevin Cox <kevin...@kevincox.ca> writes:
> > Hello Nixers,
> >
> > Microsoft has announced that Windows 10 will have a Linux ABI. What this
> > means is that it will be able to run native Linux binaries by presenting
> > them with a Linux compatible system call table.
>
> ...
>
>
> > I'm interesting in hearing what you guys think?
>
> April getting dangerously close?
>
> --
> с уважениeм / respectfully,
> Косырев Сергей
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] On nixpkgs and reasonable code size

[Mathnerd314]

On Mon, Feb 22, 2016 at 9:54 AM, Mathnerd314 <mathnerd314@gmail.com>
wrote:

> What happened to the rule of "Don't keep generated files in version
> control"?
>
Previous discussion:
http://comments.gmane.org/gmane.linux.distributions.nixos/18615

3 months and no progress...

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

Re: [Nix-dev] Call for input method PR review

[Mathnerd314]

I aimed for full Unicode 8.0.0 glyph coverage in
https://github.com/NixOS/nixpkgs/pull/10470, coming pretty close (99.45%).
The remaining glyphs are obscure ancient languages. The easiest (and most
colorful) way I found to test is the Unicode Wikibook:
https://en.wikibooks.org/wiki/Unicode/Character_reference/-0FFF

The glyphs by themselves are not everything; there are some missing
combining forms and ligatures, the kerning/sizing seems weird, and of
course "artistic quality" must be considered, so feel free to package more.

-- Mathnerd314

On Sun, Feb 21, 2016 at 10:40 PM, Raahul Kumar <raahul.ku...@gmail.com>
wrote:

> I see Lohit and Marathi, but that compares poorly to Debian/Fedora/Arch
> etc etc, which have the entire set of Bharati languages working out of the
> box. Fairly massive effort to package
> this many fonts, but I guess the only option is to get started. Is there
> any easy way to test unicode coverage of fonts versus Unicode 8.0.0? I am
> thinking of perhaps starting a Unicode OTF
> font packaging effort, but it would be nice to track how close the goal is.
> http://www.indlinux.org/wiki/index.php/IndicFontsList
> https://github.com/NixOS/nixpkgs/tree/master/pkgs/data/fonts
>
> Aloha,
> RK.
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 6:25 PM, Jookia <166...@gmail.com> wrote:

> On Fri, Jan 08, 2016 at 12:38:52AM +, Tomasz Czyż wrote:
> > 2016-01-08 0:34 GMT+00:00 Jonn Mostovoy <j...@memorici.de>:
> > Still don't see the value in it. I would just prefix them with
> > haskellPackages-, pythonPackages-.
>
> How would we do something like 'buildInputs = with pythonPackages;
> [pycrypto]; '
> with that kind of system? I imagine things would get very verbose very
> quickly.
>

We would still have all-packages.nix, so the attribute paths would not
change.

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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 5:04 PM, Tomasz Czyż  wrote:

> What do you think about moving all packages into flat namespace?
>

GitHub limits directories to 1000 files, for example here:
https://github.com/rust-lang/rust/tree/master/src/test/run-pass
We definitely have more than that in nixpkgs, so some form of hierarchy is
needed.

I would suggest doing it by hosting site / provider: all KDE packages in
one directory, all GNOME in another, GNU in a third, SourceForge in a
fourth, Kernel.org in a fifth, etc., with a final "misc" directory for
one-package sites.

It does mean that packages have to be moved around when their hosting
changes (e.g. VLC's move away from Sourceforge), but on the other hand it
makes it very easy to find all broken packages when a site shuts down (e.g.
Google Code). In general packages change hosting very infrequently, so it
seems reasonable to me.

The directory structure under that can be flat or chosen by maintainers.

Search, nix-env, and command-not-found remain the best way of finding
packages, as in https://nixos.org/wiki/Howto_find_a_package_in_NixOS.

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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 5:44 PM, Tomasz Czyż <tomasz.c...@gmail.com> wrote:

> 2016-01-08 0:37 GMT+00:00 Mathnerd314 <mathnerd314@gmail.com>:
>
>>
>> I would suggest doing it by hosting site / provider: all KDE packages in
>> one directory, all GNOME in another, GNU in a third, SourceForge in a
>> fourth, Kernel.org in a fifth, etc., with a final "misc" directory for
>> one-package sites.
>>
> Looks like good way, but not sure about few things. So github.com whould
> be another provider?
> Seems like haskellPackages, pythonPackages, *Packages could follow that
> rule if we treat lang-repos as providers.
>
Yeah, language specific stuff should be their own directories.
GitHub/SF/etc. are catch-alls; in theory there could be 1000's of projects
from them, but in practice it seems that most of the projects on there are
dead, abandoned, or mirrored somewhere else.

The goal is to have a unique location for each package, so that two people
don't package the same thing twice (which has already happened a few times
with our current structure). Hosting seems like a good index but there
might be something else (month project was founded?).

Search, nix-env, and command-not-found remain the best way of finding
>> packages, as in https://nixos.org/wiki/Howto_find_a_package_in_NixOS.
>>
> Sorry I was not precise. The problem is to locate program nix file, not
> the name/attribute.
>
Well, once you have the attribute it is usually not too hard to find the
file by tracing through the code.

And some packages are spread across multiple files, e.g. kde4.okular has
the source hash in pkgs/desktops/kde-4.14/kde-package/4.14.3.nix, the
description in pkgs/desktops/kde-4.14/kdegraphics/okular.nix, and the glue
code in pkgs/desktops/kde-4.14/kde-package/default.nix. Keeping all the
relevant files in one directory seems like the most one could ask for.

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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 6:56 PM, Tomasz Czyż <tomasz.c...@gmail.com> wrote:

>
>
> 2016-01-08 1:28 GMT+00:00 Mathnerd314 <mathnerd314@gmail.com>:
>
>> Hosting seems like a good index but there might be something else (month
>> project was founded?).
>>
> wow :-) Maybe first letter?
>

Yeah, I guess alphabetical is OK. But clicking on single letters is
s-l-o-w. So 2-letter prefixes.

1000 websites, 676 2-letter prefixes, and 1000 packages for each prefix,
runs to 67600 packages.

npm is the largest package repo currently, with 223942 packages and growth
of 335/day; so we'd run out of space in ~4 years and have to move to 3
levels.
On the other hand, most of their packages are garbage like "Peter is
awesome": https://github.com/peterdemartini/peter/blob/master/index.js; I
don't think it's worth packaging any significant fraction of npm for nix.

So the scheme (host/pa/package) seems reasonable.

The other reason I like using hosting as the first level is that it makes
writing update-crawlers easier.

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

Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Mathnerd314]

On Thu, Jan 7, 2016 at 7:48 PM, Jakob Gillich <ja...@gillich.me> wrote:

> I agree that the current folder structure is a mess. There is a severe
> lack of structure, often there are further category-folders in a folder
> with packages (like misc/, misc/themes/).
>
> FreeBSD has categories at the root level, everything below are packages:
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-categories.html
> <https://freshports.org/categories.php>
>
> Maybe this model could work for us, too?
>

That has 5338 packages in the devel/ folder. I don't think it works.

Gentoo has a tighter category tree, but they too have run into the 1000
files limit:
https://github.com/gentoo-haskell/gentoo-haskell/tree/master/dev-haskell

I'm thinking haskell/<2-letter prefix> is the way to go, if we needed a
separate file for each package. But the current giant-file system is fine
(other than that GitHub doesn't index it).

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

Re: [Nix-dev] Store nixpkgs licenses as JSON instead of .nix

[Mathnerd314]

On Sat, Dec 12, 2015 at 6:23 AM, Luca Bruno <lethalma...@gmail.com> wrote:

> I think that code is so simple that with a small transformation it's json,
> without using libnix.
>
Nix itself does an easy transformation:
nix-instantiate --eval --strict --json ./lib/licenses.nix

It is a bit verbose though, we could make it shorter:
{"afl21":{"fullName":"Academic Free License","spdxId":"AFL-2.1"},
"amazonsl":{"free":false,"fullName":"Amazon Software License","url":"
http://aws.amazon.com/asl/"}}

Other than the quoted names it seems reasonable.


> On Sat, Dec 12, 2015 at 11:52 AM, Arseniy Seroka <ars.ser...@gmail.com>
> wrote:
>
>> 2015-12-12 13:42 GMT+03:00 Freddy Rietdijk <freddyrietd...@fridh.nl>:
>>
>
>>> A practical use case is that I would like to match (using Python) raw
>>> license information to the licenses we have in nixpkgs.
>>>
>> Why not have a big hardcoded table, like in cabal2nix?
https://github.com/NixOS/cabal2nix/blob/master/distribution-nixpkgs/src/Distribution/Nixpkgs/Haskell/FromCabal/License.hs

Then you would not need Nixpkgs's license list at all, except for reference.

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

Re: [Nix-dev] Real documentation, aka "Let's kill the wiki"

[Mathnerd314]

On Wed, Nov 18, 2015 at 7:04 AM, Hajo Möller <das...@gmail.com> wrote:

> "Documentation should teach, not tell."
> As Rok said, handing somebody who is learning a new language a
> dictionary would not help them learn.
>

This is wrong. You can do fine with a dictionary and a few months:
http://www.theguardian.com/education/2012/nov/09/learn-language-in-three-months
"When I went online in search of Lingala resources, the only textbook I
could find was a US Foreign Service Institute handbook printed in 1963 –
when central Africa <http://www.theguardian.com/world/africa> was still a
front of the cold war – and a scanned copy of a 1,109-word Lingala-English
dictionary."

The key here is that he did not have to learn everything at once; he split
it up into many small chunks (vocabulary, in his case) that could be
focused on independently.

His most obvious failing once he went to Africa was that he hadn't
practiced listening or making complete sentences; some extra hours with a
native brought it to an acceptable level.

The applicability of said anecdote to NixOS is left as an exercise for the
reader.

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

Re: [Nix-dev] How to move /nix into /usr?

[Mathnerd314]

On Tue, Nov 10, 2015 at 12:57 PM, Tobias Hunger <tobias.hun...@gmail.com>
wrote:

> I am wondering how I can implement a stateless system with NixOS. On
> arch Linux I rely on systemd to get me most of the way, but that is
> not an option in NixOS. Systemd is unfortunately completely outdated
> in NixOS:-/
>
It's updated to v227 in staging (
https://github.com/NixOS/nixpkgs/issues/6671#issuecomment-153747149), and
staging will be merged "soon": https://github.com/NixOS/nixpkgs/issues/10925

Even if I updated systemd: It will not work with NixOS, since systemd
> assumes all the binaries to be in /usr. So it only offers kernel-flags
> to mount root and usr... which is not really helpful for NixOS.

Right, NixOS uses a shell script for the initrd:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh.


There is also the "ProtectSystem" for service units: That also protects
> /usr, not /nix.
>
The init scripts already mount /nix read-only; I guess ProtectSystem could
too but it would be redundant.

So how can I move /nix into /usr to make systemd happy? Or should
> NixOS ship with a patched systemd that treats /nix special instead of
> /usr? That would require a lot of documentation updates and would be a
> major derivation from all other systemd distributions.
>
NixOS already uses a patched systemd; the changes so far are pretty small:
https://github.com/systemd/systemd/compare/master...NixOS:nixos-v227
There are still many references to /usr left, e.g. in ProtectSystem as you
mentioned.

On Tue, Nov 10, 2015 at 2:06 PM, Tobias Hunger <tobias.hun...@gmail.com>
wrote:

> NixOS does actually go surprisingly far here, but my first test of
> just doing rm -rf /etc did break e.g. root login.

There is some discussion in https://github.com/NixOS/nixpkgs/issues/3192 of
what is needed for /etc. For root login and /etc/passwd in particular you
can set users.mutableUsers=false and security.initialRootPassword.

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

Re: [Nix-dev] Use Function Application To Escape Override Hell

[Mathnerd314]

On Thu, Oct 15, 2015 at 3:58 AM, Peter Simons <sim...@cryp.to> wrote:

> But how many people understand "callPackage"?

Interesting question. The commit logs suggest between 10-20 people could
write it themselves.
Arguably everyone who has read
http://lethalman.blogspot.com/2014/09/nix-pill-13-callpackage-design-pattern.html
understands callPackage, so that would put it in the 50-150 range based on
some pageview stats I found.
These numbers should be compared to the total number of NixOS users; the
NixOS subreddit has 624 users, so maybe 10-25% understand callPackage, 1-3%
could write it.

And more importantly: why
> should our users even care about it?
>
They at least need to know that callPackage provides a .override method, as
this is (or should be) the preferred way to build unusual variants of
packages, like curl with HTTPS support disabled.

So maybe callPackage should be documented in the manual, in preference to
makeOverridable.

 > The only way to use them from a configuration.nix or config.nix is to
>  > write out with import
> /pkgs/development/haskell-modules/lib.nix;
>
> pkgs.haskell.lib works too.
>

Wonderful. This should be documented in the Nixpkgs manual, say under
http://nixos.org/nixpkgs/manual/#how-to-build-with-profiling-enabled

How exactly would one go from that JSON
> file to, say, an Idris binary built with GHC 7.8.4 and shared libraries
> disabled?
>
I already linked to the KDE packages, which go from JSON to (for example)
Dolphin binaries built with Qt 5 and parallel building enabled.
I will repeat the relevant files:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/kde-apps-15.04/packages.json
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/kde-apps-15.04/default.nix
https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/autonix/default.nix

In particular the fold on json in kde-apps/default.nix and the resolveDeps
function in autonix are relevant.

>
> Well, defining a good method to resolve package names to package
> versions and build variants is exactly what this thread is about! Would
> you care to elaborate how exactly that would work for Haskell packages
> in your proposal?
>

I'm not sure how to elaborate beyond saying "Do it like the KDE stuff". I
could do a pull request, if that counts.

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

Re: [Nix-dev] Use Function Application To Escape Override Hell

[Mathnerd314]

quot;base" "bytestring" "hspec" "hspec-contrib" "HUnit" "QuickCheck"
 "quickcheck-instances" "text"
   ],
   "description": "A Lua language interpreter embedding in Haskell",
   "license": "mit"
 }
The package sets then can define their own method of resolving packages to
package versions.

This approach is already in use with KDE 5, using autonix [6] [7], which
aims to become a standard for automated Nix packaging [8]. Autonix assumes
the use of stdenv's mkDerivation and would have to be modified
substantially to achieve its goal of becoming a standard [9], but the basic
resolveDeps function is fine and could be used for Haskell as well.

-- Mathnerd314

[1]
https://github.com/NixOS/cabal2nix/blob/255fd253e04f6eed2531eb2a6119bd6a6f4f9445/hackage2nix/src/Main.hs#L225-L226
[2] http://pastebin.com/5pU9G6D2
[3] http://www.modulecounts.com/
[4]
https://github.com/fpco/stackage/blob/2734cf8fe4fd98fb2ea75f865b4b11eb4a82aac2/build-constraints.yaml#L1552
[5] http://r6.ca/blog/20140422T142911Z.html
[6]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/kde-apps-15.04/packages.json
[7]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/kde-apps-15.04/default.nix
[8] https://github.com/NixOS/nixpkgs/pull/5786#issuecomment-71205805
[9]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/autonix/default.nix#L46
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] how does NixOS ensure focus?

[Mathnerd314]

On Mon, Jul 28, 2014 at 3:55 AM, hasufell hasuf...@gentoo.org wrote:

 However, since I'v seen a lot of things gone wrong in distros (primarily
 gentoo), I am curious if you have a concept for ensuring that NixOS
 stays focussed.

I believe the closest thing available is
https://nixos.org/wiki/The_Many_Cooks_Method. So far, Eelco has maintained
most of the infrastructure, but in the future (according to that wiki page)
other organizations will begin maintaining their own installations as well.
Perhaps this has already started in the form of Guix; they have their own
instance of Hydra, their own Guix packages, etc., but still use Nix, the
underlying software, basically out of the box. As Ertugrul says, the
development model is very open to contributions; you just have to figure
out which repository you want to get them into. The only truly difficult
part is merging everything back together, but so far Git and the
expressiveness of Nix have been sufficient.

 Gentoo here is almost the complete opposite with 200 core developers
 and it is rapidly losing focus and consistency every year.

There have been a fairly steady stream of interested Gentoo users and
developers (yourself included, presumably), but I believe most of them have
turned away. They have said (probably correctly) that the project is still
a bit too experimental / unstable for them to switch. That will change in a
few years if Nix keeps chugging along, so I am not too worried about it,
but it is something to keep in mind. Eventually, they will have to be
recruited somehow into testing all of the unstable packages.


 I almost think that a centralized distribution model is doomed to fail.
 That does not only include the workflow with review platforms, DVCS
 tools etc., but also the political and organizational structure.

Debian is centralized, and I have seen no signs of it failing (other than
that they seem to be intent on rewriting dpkg to be more Nix-like instead
of just adopting Nix :-) ). I've heard some rumors about a NixOS social
contract, but nothing has materialized yet.


 I don't see much information about these points on your website (only
 technical stuff).


NixOS is pretty small now (only 21 people, according to
https://github.com/orgs/NixOS/people) so there hasn't been much need to
write it down.
If you look at contributors to the main Nix repo (
https://github.com/NixOS/nix/graphs/contributors), then it's even tinier;
Eelco wrote all the code (3400+ commits), and everyone else has contributed
to the Nix language or done building/porting fixes (209 commits, if I can
do addition correctly in my head). I've been thinking about writing some
core changes, and shlevy has started on a Haskell rewrite (
https://github.com/shlevy/hnix-store/), but in the meantime it is indeed a
one-man project with random contributions, following the focus by limiting
core developers criteria.

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

Re: [Nix-dev] Reminder about nixpkgs branches

[Mathnerd314]

, e.g. system time dependency, cosmic radiation, evil
hackers/crackers, etc.

On the other side, the release process and picking process becomes easier.
Hydra fetches all of the store paths, and it's just a matter of examining
the results and picking the builds that seem to work and pass tests. A
release is basically a list of known-good store paths; there should be no
dependency at all on the source NixExpr's, just on the derivations. The
OpenSSL problem goes away, because now patching binaries to point to a
different store path is a required operation (it's used for storing
derivations in the first place!) rather than a quick sed hack. There's
still the question of the actual command syntax for saying build this
tarball with these dependencies and how/where to store the path-rewriting
operation, but these are basically just bikeshedding. Regardless, it should
be Hydra or NixOS and their respective configurations that pick stdenv
uses gcc 4.9, not nixpkgs. We could share the configuration and call it
nixreleases or something. The other thing this allows is using e.g.
Guix's GCC, which again currently requires a bunch of hacks.

After this, my vision is that the nixpkgs repository will only contain very
high-level instructions, for example to install firefox: got to mozilla
ftp directory; load a folder (branch); download tarball; install to $out
}. This will mean that the majority of updates (stable or unstable) will
be completely automatic and invisible from a nixpkgs perspective, which
means that the repository explosion will go away. We can merge in projects
like hackage2nix and others since they will not be lost in the update
noise. The only development that will happen in nixpkgs will be adding new
download sources and fixing build scripts. One master branch should be
sufficient for that, modulo forks or global refactorings. Hydra/NixOS/Nix
will do everything else - picking versions, running programs,
calculating/storing hashes, etc.

Anyways, I filed https://github.com/NixOS/nix/issues/296 a week ago, and
received no response besides Dolstra tagging it as feature and Nix 2.0.
So my conclusion is that nobody actually cares enough for this to be
implemented now, besides possibly me (I'm already doing a GSOC; two
projects at once is probably not a good idea). But I could be wrong, please
convince people to work on #296 if you want to remove the hacks and get
these nice features. :-)

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

[Nix-dev] Fwd: Reminder about nixpkgs branches

[Mathnerd314]

On Thu, Jul 24, 2014 at 11:03 PM, Eelco Dolstra eelco.dols...@logicblox.com
 wrote:

 Hi,

 On 24/07/14 21:32, Mathnerd314 wrote:

 Here it's really more appropriate to use nix-env (i.e. the imperative
 package
 management style), which makes it easy to mix packages from different
 Nixpkgs
 revisions.

 The declarative style (environment.systemPackages) doesn't work very well
 for
 this. It's doable if you only want a few packages from one other branch,
 but as
 you point out, it doesn't scale very well.



 Yes, mixing modules from different NixOS versions doesn't really work.
 Here it

 is easier to have a local branch (e.g. based/rebased on release-14.04) onto
 which you can cherry-pick the changes you need.

So in this case, I needed to override the packages used by the modules.
AFAICT there is no way to do that in nix-env, yet here you are telling me
to use nix-env to manage packages. I must have missed that section of the
manual...


  NixOS is inherently a
  state-centric system; it's not this change broke my system but
 version V of
  thing X is broken.

 I don't know what this means.

I believe darcs is pretty much the only example of a change-based system,
so this is more a reply to Vladimír Čunát.

Well, nixpkgs-monitor is intended to help package maintainers, not make them
 redundant :-) Maintainers should still do testing before they push a patch
 from
 the monitor.

And that's impossible, since there are always architectures and
configurations that maintainers don't have access to. So I say go the other
way: if you can't test the dynamic stuff completely, don't test it at all.
On the other hand nix-instantiate is (at least theoretically)
system-independent so it is reasonable to run it over all packages; it can
check syntax, types, etc. - basically everything static. But the dynamic
stuff, e.g. Hydra's builds and tests, should only run as often as you want
to release, not as often as you want to update a package.


  The problem is that, currently, Nix expressions are used for two
 purposes -
  building packages and specifying systems. Due to integration in the
 nixpkgs
  repository, the coupling between these has grown strong. But, as I hope
 my
  example has shown, these are orthogonal and independent activities.
 Sometimes I
  want to build packages, e.g. when I want to build the latest version of
 Firefox
  from mozilla-central. Other times I want to specify my system, e.g.,
 use this
  known-good version of Firefox. If you look closer, you can see the
 difference:
  in the first case, I am referring to a dynamic, changing process. In the
 second
  case, I just need a store path. However, currently Nix is using the
 extensional
  model which intermingles these two.

 I don't see the connection with the extensional model.

Since the extensional model only identifies the inputs, it automatically
assumes that any two runs of a derivation are the same.

 It allows you to specify
 a specific version just fine, e.g.

   environment.systemPackages = [ (builtins.storePath
 /nix/store/gv67fwcwbyha77kxsmgcs41baqxh2ysi-firefox-31.0) ];

There's no way to refer to the result of calling fetchurl http://google.com
on July 1st 2013, which can be described with the intensional model (a
hash of the contents, as usual).


 (Not the prettiest syntax, but NixOS wasn't really intended for this kind
 of
 binary-only package management.)

Well, since that's what all my package paths look like, I guess that's the
problem in a nutshell.


 The main advantage of the intensional model is that it allows untrusted
 users to
 fetch binaries from untrusted binary caches.

It also allows derivations to fetch or produce volatile or time-dependent
data, which I think is a bigger advantage.


  On the other side, the release process and picking process becomes
 easier. Hydra
  fetches all of the store paths, and it's just a matter of examining the
 results
  and picking the builds that seem to work and pass tests.

 This is pretty much the furthest you can get from declarative package
 management.

Not really, the furthest you could get would be using no package management
at all (a.k.a. life without commodities).

 It makes a release the sum of a bunch of packages from different
 Nixpkgs revisions, all built against whatever version of the dependencies
 happened to be the most recently built at the time.

No, they're built with whatever dependencies happened to be *available* at
the time, which is a different story (availability is determined by Hydra;
it can use whichever versions it wants, and the versions it uses are
sha256'd hashed as usual).

 Reproducing such a
 configuration is pretty much impossible.

No, the only commands you're running are of the form execute the script
sha256 hash on list of files' sha256 hashes. The only time they're not
reproducible is when they grab external state. If we continue following our
packaging process, then commands which grab external state will be isolated
to a few fetch

Re: [Nix-dev] Cinnamon quitting

[Mathnerd314]

On 12/21/2013 16:56, Bjørn Forsman wrote:
 On 21 December 2013 19:45, Roelof Wobben rwob...@hotmail.com wrote:
 Hello,

 Because I do not get Cinnamon work because of the error I mentioned
 I forced to quit this project.
 Hold on, don't quit! :-)

 Did you dig through the Gentoo issue[1] already?

 The error: po/Makefile.in.in was not created by intltoolize. issue
 apparently happens when a package is using intltool and gettext
 simultaneously. It seems one should only use one or the other, not
 both at the same time. So this looks like a bug in Cinnamon.

 Oh, I see you have already reported this upstream[2]. Good!

 [1]: https://bugs.gentoo.org/show_bug.cgi?id=240958
 [2]: https://github.com/linuxmint/Cinnamon/issues/2729

I found a more recent (2013) bug with the same error:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724555
Patch was here: https://bugzilla.gnome.org/show_bug.cgi?id=706835

So for Cinnamon, deleting lines 29 and 30 of
https://github.com/linuxmint/Cinnamon/blob/master/configure.ac#L29 ought
to work...

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

Re: [Nix-dev] Distribution compatibility

[Mathnerd314]

 of library versions it needs without
 bothering if we have three instances of glibc on the same system.
Yeah, sorry, I was looking at hack-nix and got confused by his terminology.

 Well, the library versions it needs according to our best guess, if one
 takes into account limited resources.

 And what is the point of all it? Debian packages would have Debian
 dependencies, so you would just get the same as you can have right now
 with debootstrap.
Once you have the Debian packages, you can start thinking about swapping 
out Debian dependencies with other dependencies. So it's more flexible 
than debootstrap.

 I looked over the Mancoosi project, and one of their tasks was
 formalizing maintainer scripts into a DSL. I think they've stopped
 (mostly), but EVOSS (the system they developed) is still up:
 http://mancoosi.di.univaq.it/?page_id=36

 Presumably it wouldn't be too hard to take their translator and modify
 it to output in a format that Nix can read instead of whatever DSL they
 came up with, and then implement whatever glue code is needed to get Nix
 to understand those. After that it's a question of whether the
 infrastructure is up to it; even if Nix works perfectly (which it won't;
 it doesn't have any sort of SAT solver but just brute-forces things,
 correct?), Hydra will run out of disk space. I expect these problems can
 be mostly ignored because they're orthogonal to the actual packages.
 Given that autogenerated packages will lack Nix-side maintainers, Hydra
 will not even start to build them.
Well, I could put myself as the maintainer. But it's probably best to 
stay away from Hydra for the time being.

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

[Nix-dev] Distribution compatibility

[Mathnerd314]

It seems like Nix can be installed on pretty much any system (including 
Windows?), but the reverse does not seem possible: why shouldn't one be 
able to install any system on NixOS?

In a perfect world, I envision having multiple systems running at the 
same time a la Qubes (http://qubes-os.org/trac), all nicely managed 
using nix, but a good start is finding a way to stuff Debian's package 
repository into NixPkgs.

Currently, it seems like installing Debian packages on NixOS requires 
manually writing a derivation, and there are no tools to automate 
writing such a derivation. There's also the question of whether the Nix 
package format is flexible enough to allow installing/breaking up 
packages in something approximating the Debian way, and whether the 
dependency solver in Nix is powerful enough to handle ~26,000 new 
packages, each with 3+ versions from the various debian-stable, 
debian-testing, and debian-unstable repositories.

I looked over the Mancoosi project, and one of their tasks was 
formalizing maintainer scripts into a DSL. I think they've stopped 
(mostly), but EVOSS (the system they developed) is still up: 
http://mancoosi.di.univaq.it/?page_id=36

Presumably it wouldn't be too hard to take their translator and modify 
it to output in a format that Nix can read instead of whatever DSL they 
came up with, and then implement whatever glue code is needed to get Nix 
to understand those. After that it's a question of whether the 
infrastructure is up to it; even if Nix works perfectly (which it won't; 
it doesn't have any sort of SAT solver but just brute-forces things, 
correct?), Hydra will run out of disk space. I expect these problems can 
be mostly ignored because they're orthogonal to the actual packages.

Thoughts? Reasons this won't work that I'm missing?

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