The wrong usage of unfree-redistributable fixed in
ea242619fb can be explaind by unclear
documention, specifically the section in the nixpkgs manual describing
generic licenses it is written to use attributes from `stdenv.lib.licenses`
but in the list the strings form was documented without quotation marks.
This confuses people because the package builds fine locally but failes
the tests on travis-ci.
What I missed when I began using Nix and NixOS was a clear overview of
how packages, channels, Hydra, the master branch and updates to channels
relate to each other.
I've noticed I am not the only one, given the amount of times these
questions pop up.
For now I propose to include this in the Nixpkgs manual, since this
seems to be the best fit. However, I think it would be good to include
this in either a new manual, i.e., a user manual, or an 'official'
tutorial.
It seemed very fine on Hydra before it was cancelled due to glibc rebuild,
in particular the nixpkgs unstable job succeeded except for
bootstrap-tarball tests which should be fine after ee994dfae6.
Therefore, let's avoid another mass rebuild by merging now when we don't
have binaries for master anyway.
* authorization token is optional
* registry url is taken from X-Docker-Endpoints header
* pull.sh correctly resumes partial layer downloads
* detjson.py does not fail on missing keys
This adds changes to the rebar3 expression that patch rebar3 to force it
to be hermetic. Now, by default, rebar3 literally can't download
anything. A 'rebar3-open' expression was added for those folks whe want
the normal rebar3.
This commit adds some very minimial documentation to the Nix
manual. Hopefully, its enough to get someone started and serve as a
first footstep for future documentation writers
There's no change in content except for amending the title of the
section to mention "frameworks", as e.g. I don't consider Qt a language,
and it's likely there will be more of similar cases in future.
To be certain, I checked diff of the generated HTMLs.
Editing Docbook is no fun, IMHO, so I'd rather store the Haskell
documentation in Markdown format and use Pandoc to convert that into
Docbook as part of the build process.
