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

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:

Re: [Nix-dev] Fwd: Wiki is dead

On 02/22/2016 12:58 AM, Thomas Hunger wrote: > 2/ nix-build is rebuilding GHC 7.8 and 7.10 (for pandoc I think). Basing your work on a channel should remove such problems, as for any regular package. --Vladimir smime.p7s Description: S/MIME Cryptographic Signature

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

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

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

There are quite a lot of international fonts available in nixpkgs. The few I use are IPAFont (Japanese) and baekmuk (Korean) and they look very decent. For other languages, there is the noto font that self advert as "Beautiful and free fonts for all languages" also available. Fonts are easy to

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

Looking forward to this, but I assume Nixos probably doesn't package any decent fonts for languages outside of English. Aloha, RK. On Mon, Feb 22, 2016 at 12:24 PM, Yasuaki Kudo wrote: > Many thanks in advance, looking fward to it! Yasuaki :-) > > > On Feb 22, 2016, at

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

Many thanks in advance, looking fward to it! Yasuaki :-) > On Feb 22, 2016, at 11:14, 宋文武 wrote: > > Eric Sagnes writes: > >> Hi, >> >> The PR to improve the state of input methods [1] in NixOS is ready for >> review. >> Input methods are a

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

Eric Sagnes writes: > Hi, > > The PR to improve the state of input methods [1] in NixOS is ready for review. > Input methods are a way to input characters/symbols that are not > available on the keyboard, see wikipedia for more details [2]. > > Input methods being a very

Re: [Nix-dev] Fwd: Wiki is dead

Thanks Rok! I've given this a try [1] for the zero-build-failures entry and my experience so far was: 1/ How do I actually build docbook? => copy doc/default.nix and adjust 2/ nix-build is rebuilding GHC 7.8 and 7.10 (for pandoc I think). => Wait 2h. 3/ GHC build fails [2] 4/ We're not using

Re: [Nix-dev] How to set up your own Hydra server (video tutorial)

Great video Peter! I learned a few things I didn't know yet about hydra and immediately applied them to our private hydra.lumi.guide. Thank you. Bas On 16 February 2016 at 10:10, Peter Simons wrote: > Hi folks, > > as promised before [1], my presentation from the January

Re: [Nix-dev] Fwd: Wiki is dead

Hi all, As some already seen I create tickets for each page in wiki (more or less) each wiki page. All are assigned to "Move the wiki!"[1] milestone, so we can track the progress. Because of the quantity of content that needs to be migrated, and most importantly reviewed, we must move with small

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

On 02/21/2016 09:10 PM, Patrick Callahan wrote: > Does anyone here know what other distros do to engage more > developers+maintainers? Could we, among other things, organize some kind > of drive to encourage more systematic contributions? Or is integrating > all the current PRs too much work

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

Would you say that this is somewhat comparable to 'contrib' repos in general? I would hope nixpkgs could still manage better quality control and integration than Arch users have with AUR, which is kind of hacky. Does anyone here know what other distros do to engage more developers+maintainers?

Re: [Nix-dev] Debugging a haskellPackages deep override gone wrong

Oh, I incorrectly assumed that the failure has anything to do with your overriding. But if you do $ nix-build -E "with (import {}); with haskell.lib; dontCheck (haskell.packages.ghc801.comonad)" that does fail in the same way, so in fact the overriding is not related at all to the issue your

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

Thanks, what I had in mind is a model similar to Arch Linux. I would like to make some definitions first: committer: person who has commit access to nixpkgs maintainer: person who is listed in a given package's meta.maintainers attribute There is a core set of packages that all work together

Re: [Nix-dev] Debugging a haskellPackages deep override gone wrong

I have no knowledge of Nix internals. I wonder if it is possible to add a debug / tracing commands which will track source of the literal value or tuple? Even more awesome would be to have a data lineage for a tuple, which would contain original tuple location and all spots where this tuple was

Re: [Nix-dev] Debugging a haskellPackages deep override gone wrong

Oops, small to the code example: the line should be `let parent = (oldArgs.overrides or (_: _: {})) new old` (new instead of parent in the second to last word) Benno Fünfstück schrieb am So., 21. Feb. 2016 um 16:59 Uhr: > Hi Kosyrev, > > The problem here is most

Re: [Nix-dev] Debugging a haskellPackages deep override gone wrong

Hi Kosyrev, The problem here is most likely that ghcOrig is already passed an overrides argument, so you need to preserve the changes done by that: ghc = ghcOrig.override (oldArgs: { overrides = with haskell.lib; new: old: let parent = (oldArgs.overrides or (_: _: {})) parent old;

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

On 02/21/2016 03:17 PM, zimbatm wrote: > tl,td; I think that we should split nixpkgs/pkgs in two OK, let's discuss. TL;DR: I quite don't get where to draw the line, and what the relationship of the two sets would be. > nixpkgs is getting pretty huge. There is so much surface, [...] > > We have

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

On 21 February 2016 at 15:17, zimbatm wrote: > Hi list, > > tl,td; I think that we should split nixpkgs/pkgs in two Another way to do it is the Linux kernel way. Instead of splitting the (git) repository in two (or more) pieces, split _maintenance responsibility_ into a

[Nix-dev] On nixpkgs and reasonable code size

Hi list, tl,td; I think that we should split nixpkgs/pkgs in two nixpkgs is getting pretty huge. There is so much surface, I don't think that a single person can keep up with the pace of change and still manage to do other things in the same day. Luckily we do have ~5 super-human people taking