Re: [Nix-dev] Nixos wiki project

2017-05-10 Thread Matthew Bauer
Mic92  writes:

> We invite you to dump your knowledge and useful snippets,
> if you found out something cool about Nix/NixOS.

I've added a few entries! Hope that didn't break anything.

Hopefully the best entries can be added into the main repo eventually.
That FAQ article would definitely be super helpful to beginners.
nix-dev mailing list

[Nix-dev] Issuepocalypse?

2017-05-09 Thread Matthew Bauer
I think the number of issues in Nixpkgs is getting a little out of hand.
It’s become way too easy for issues to get buried. Lots of old issues
aren’t even relevant any more but they stay open because no one see
them. Others are more of support unanswered questions that there really
isn’t a good answer for.

Regardless, 1600+ seems like too many for even a project as ambitious and
large as Nixpkgs. Perhaps we need to be more aggressive in closing
issues? Are there any other ways to reduce issues?

Anyways, I’m going to call on everybody to look through all of the
issues you’ve submitted and verify that they are still valid. You can
filter these by clicking "Author" under the Issues tab
( and selecting your name.
There’s nothing wrong with having lots of open issues if they are
actually valid, but there’s definitely a lot of bogus ones out there.

nix-dev mailing list

Re: [Nix-dev] Would love to get feedback / help to a kodi problem

2017-05-08 Thread Matthew Bauer
Stefan Huchler  writes:

> The main problem I have to debug that is that I dont even know if I have
> nix problems or if this plugin does fix the problem. So I cant just use
> the normal make install, and if that solves the issue seperately do the
> packaging.

Partly this is understanding the split between Nix, Nixpkgs, and NixOS.
You might not actually be rebuilding your changes to nixpkgs. This part
of the manual explains this somewhat:

So, you may have to do:

# nixos-rebuild switch -I nixpkgs=/my/sources/nixpkgs

and hope everything builds and nothing breaks (if it does you can always
do a rollback)

> Well again I try to find the time to upload my changes as branch. Is
> there no maintainer of the kodi package?

I just pinged @edwtjo who did the initial work on the Kodi plugins.
Hopefully he can at least provide some tips. Not everyone’s quick to
respond, sadly.

> I mean the bug is open since 4 5 days, and I did not even get a notice
> that somebody have seen the bugreport, or is assigned or anything.

Yeah there's so many issues in Nixpkgs it's very easy to get lost. If
there's no Nix developers using Kodi + Xbox360 it’s fairly likely it
will get broken.
nix-dev mailing list

Re: [Nix-dev] Would love to get feedback / help to a kodi problem

2017-05-06 Thread Matthew Bauer
Stefan Huchler  writes:

> Because I dont think that the nixos / nix documentation is very good
> (imho) and some experience with kodi packaging could help, I would be
> happy if somebody could help me get the plugin packaged.

This is definitely a struggle. The big issue is that Nix/Nixpkgs are
much more complicated than the average package manager. We probably have
/more/ documentation than RPM/DEB/Homebrew/etc. but we also have lots
more abstraction and hacks. It’s useful when you understand it but a
pain in the ass when it’s not working right.

> As far as I get it making a package for that plugin:
> My first question for that would be: do I
> need to create a own package for that or do I have to modify the
> existing kodi package?

I don’t have Kodi setup but looking at the code you are probably going
to need to use it as plugin. You can follow the basic structure of
advanced-launcher for peripheral.joystick:

That plugin will need to be referenced under wrapKodi in
all-packages.nix. I’d recommend call it "enablePeripheralJoystick":

If you run into trouble definitely feel free to ask for help. Especially
on the #NixOS on freenode. Usually they can be really helpful.

To test it you will need to create ~/.nixpkgs/config.nix and put
something like this in it:

  kodi = {
enablePeripheralJoystick = true;
enableControllers = true; # might not be needed

To build it, run:

nix-env -iA nixpkgs.kodi -f/home/user/path-to-nixpkgs/

Then kodi should be in your environment. Just run it with kodi if you
can. You’ll need to do some modifications to get it building under NixOS
but you’ll hopefully have a better handle on things. Make sure if you
get it working you submit a PR for it though! Don’t be afraid to ask for
help if you have issues.
nix-dev mailing list

Re: [Nix-dev] NixOS on Pinebook?

2017-05-04 Thread Matthew Bauer
Matthias Beyer  writes:

> Has someone successfully got NixOS on a pinebook[0] running?
> [0]:

I haven't but it looks like a pretty good laptop! I just added my name
to the queue. $99 is a pretty good price point.

So, now that we have aarch64 in the binary cache that means it should
work pretty well out of the box? I guess you’d need to generate your own
ISO first. I wonder if anyone has discussed providing a aarch64-linux
target for NixOS releases? Might be a good thing to look into for the
17.09 release.
nix-dev mailing list

[Nix-commits] [NixOS/nixpkgs] 123482: xsv: fix "has invalid meta attribute"

2017-05-02 Thread Matthew Bauer
  Branch: refs/heads/master
  Commit: 1234825656bfed1d617d03a32a1a91a97850570b
  Author: Matthew Bauer <>
  Date:   2017-05-02 (Tue, 02 May 2017)

  Changed paths:
M pkgs/tools/text/xsv/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  xsv: fix "has invalid meta attribute"

Without this there's an eval error, when running nix-env -f ''
--query --available --json.

  derivation ‘xsv-0.11.0’ has invalid meta attribute ‘override’
  derivation ‘xsv-0.11.0’ has invalid meta attribute ‘overrideDerivation’

[Bjørn: extend commit message.]

nix-commits mailing list

[Nix-commits] [NixOS/nixpkgs] aac487: jing-trang: supports all unix

2017-05-02 Thread Matthew Bauer
  Branch: refs/heads/master
  Commit: aac48708c1a9d5443d11e206fe38b0ebbd4cb930
  Author: Matthew Bauer <>
  Date:   2017-05-02 (Tue, 02 May 2017)

  Changed paths:
M pkgs/tools/text/xml/jing-trang/default.nix

  Log Message:
  jing-trang: supports all unix

This is needed to build the manual on macOS.

nix-commits mailing list

Re: [Nix-dev] nix-bundle: Bundle Nix derivations to run anywhere

2017-02-07 Thread Matthew Bauer
> Any chance this could be combined with lethalman's work on turning
> derivations into docker containers?

Do you have a link to this project? All I can find is this blog post:

We can get most of the advantages of the container features of Docker
using just cgroups/namespaces. The main advantage of using Docker is
that lots of different systems support it. The Open Container standard
might be an easier way to go: it's just a folder with a /config.json

On Tue, Feb 7, 2017 at 8:32 AM, Peter Hoeg  wrote:
> Nice work Matthew!
>>> I would vote for mirroring this tool in nixos github namespace (or even
>>> trying to make this project official one) as it can have big impact of
>>> propagating/implementing nix ideas into environments where it's not
>>> straight forward to use it.
> Any chance this could be combined with lethalman's work on turning
> derivations into docker containers? There seems to be a fair amount of
> overlap and having a generic mechanism to create a runable closure means
> we could relatively easily support the containerization mechanism and/or
> application distribution format of the day.
> --
> Regards,
> Peter
> ___
> nix-dev mailing list
nix-dev mailing list

Re: [Nix-dev] nix-bundle: Bundle Nix derivations to run anywhere

2017-02-07 Thread Matthew Bauer
> One question: Will it create a persistent /nix directory on the machine
> the generated binary is running?

No, it just creates a temporary chroot in /tmp and bind mounts the
/nix/ there. As a side effect, though, you will not have access to
your regular /nix/ directory within the bundle (which is probably good
for purity reasons).
nix-dev mailing list

[Nix-dev] nix-bundle: Bundle Nix derivations to run anywhere

2017-02-06 Thread Matthew Bauer
GitHub page:

I just wanted to post about a little project I've been working on. I'm
calling it "nix-bundle".

Basically, what it does is: take a Nix closure, compress it into a
tarball, and turn that tarball into an executable using "Arx". The
final result looks like a plain shell script, but actually has a
tarball closure appended to it. When you run that script, Arx will
execute "nix-user-chroot" (which is included in the closure) which
will setup a /nix/ directory, then execute a target executable. All of
this should work "out of the box" for any Nix derivation folder with a
valid executable.

For example, to generate a "hello" bundle:

./ hello /bin/hello

"hello" specifies pkgs.hello and /bin/hello specifies the file
${pkgs.helloi}/bin/hello to be executed. The output file will just be
called "hello".

The result is a "bundle" that can run without Nix being installed! No
external dependencies are needed because they are all contained within
the Nix closure.

There are two main drawbacks: slow startup and large file size.
Extracting the tarball takes time and this adds on to startup times.
Also, because everything is included from the Nix closure, complicated
apps tend to be much larger because of the dependency tree.

I've been experimenting with using AppImage as a format to package
them in, but it is not currently ready yet.
nix-dev mailing list

Re: [Nix-dev] Google Summer of Code 2017

2017-01-06 Thread Matthew Bauer
Domen Kožar  writes:

> I'll prepare a list of things each idea needs and send a call for mentors.
> There's a GSoC label on github, so let's use that.

Okay sounds good! We can start adding issues that were on the wiki that
may still be viable.
nix-dev mailing list

Re: [Nix-dev] Google Summer of Code 2017

2017-01-04 Thread Matthew Bauer
On Wed, Jan 4, 2017 at 12:54 PM Vladimír Čunát <> wrote:

> On 01/04/2017 03:49 AM, Matthew Bauer wrote:
> > Ideas
> I suggest we create a GitHub ticket for each hopeful idea.  There each
> gets a thread to discuss it and come to a better specification in the
> end.  For this could add a GSoC label.

Some of the ideas I listed already have issues associated. I'll create
issues for the ones that don't though.
Matthew Bauer <>
University of Kansas
nix-dev mailing list

[Nix-dev] Google Summer of Code 2017

2017-01-03 Thread Matthew Bauer
Google Summer of Code applications open on January 19 for organizations[1].
NixOS had previously applied to be an organization in 2014 and 2015 but
neither time was accepted. I think it would be great if we could get an
application in for this year. It's not clear what criteria the GSoC use for
accepting orgs but I'm thinking that the growth the Nix* projects have
experienced over the last 2 years gives us a pretty good shot.

The most important thing right now is getting a list of mentors. Lots of
the mentors from 2015 are still active[2] so I'm hoping to get input from
them. New mentors would also be welcome! I think @iElectric organized the
efforts previously, so I'm hoping to see if he is

I am currently eligible to work as a student over this summer if NixOS gets
accepted. I'd really enjoy working on NixOS-stuff and I think it would be
really helpful to the Nix* project.

These are some various ideas. Some are new and some are based on the wiki

- NixOS graphical installer: Use something like Calamares[3], make it
generate a NixOS config, then run some basic installation commands.
- Nix graphical package manager: Extending on my original efforts in
getting PackageKit[4] working with Nix, this would be a GUI application
that makes managing Nix/NixOS easier.
- Improve Nix build output: This would either be reporting progress
(NixOS/nix#896) or "Improve nix-build output for post-processing"[5] or
- In-memory representation of derivations: get rid of the .drv files in Nix

Obviously there are lots of other ideas that are worthwhile, hopefully
potential mentors can contribute more.


Gist URL:
Matthew Bauer <>
University of Kansas
(913) 671-0636
nix-dev mailing list

[Nix-commits] [NixOS/nixpkgs] 15daf1: pyopenssl: 0.15.1 -> 16.0.0

2016-08-17 Thread Matthew Bauer
  Branch: refs/heads/python-wip
  Commit: 15daf1c3435986b755176c2c895974356bcc71f4
  Author: Matthew <>
  Date:   2016-08-17 (Wed, 17 Aug 2016)

  Changed paths:
M pkgs/top-level/python-packages.nix

  Log Message:
  pyopenssl: 0.15.1 -> 16.0.0

This will fix the error in certbot.

  Commit: 8a089aca600785fc5723fe58fbfc8dc732932f81
  Author: Matthew Bauer <>
  Date:   2016-08-17 (Wed, 17 Aug 2016)

  Changed paths:
M pkgs/top-level/python-packages.nix

  Log Message:
  service-identity: 14.0.0 -> 16.0.0

- adds attrs as input

  Commit: 405ee1d4b16d5eb7c0bcaa9323bedb7d27cc7968
  Author: Matthew Bauer <>
  Date:   2016-08-17 (Wed, 17 Aug 2016)

  Changed paths:
M pkgs/top-level/python-packages.nix

  Log Message:
  searx: force to use new pyopenssl

nix-commits mailing list

[Nix-dev] i686-darwin?

2016-03-01 Thread Matthew Bauer
Has anyone been able to use i686-darwin with nixpkgs? I'm trying to get
Dwarf Fortress working on my Mac, and it looks like the binaries are i686
(which is what the Linux version is too). It looks like it depends on:

   - SDL
   - SDL_image
   - SDL_ttf
   - fmod

Is there any chance that a i686-darwin stdenv will *just work*? It ships
with all of those as universal Mach-O binaries but I'm hoping to get not
use them (and it looks like they're outdated). I want to know if anyone
here has tried anything like that and any thoughts on whether this is worth
even trying.

-Matt Bauer
nix-dev mailing list