It was unintuitive that the withGTK option controlled whether a
fontforge GUI was enabled at all, since fontforge supports multiple
GUIs (a GTK one and an X11 one -- confusingly the X11 one still
requires GTK).
With the new withGUI option, it is possible to build the X11 GUI by
setting withGTK to false and withGUI to true. I haven't added an
attribute for this configuration because I expect it to be pretty
obsure -- my rationale for adding this option was code clarity rather
than utility.
Kept 1.42 around for Thunderbird.
i686-apple-darwin is no longer supported upstream. We could still
support building it, for this one release, since we have the binary
for the previous release, (or bootstrap it for future releases from
Rust 1.42,) but since this release is the one that drops support, I
think it makes sense to do it now. (And probably nobody is using it
anyway.)
"paladin" doesn't seem to be up to date, whereas "full" seems to match
what cros-updates-serving.appspot.com reports is currently being
shipped to Chromebooks.
There are lots of other scripts in contrib that we should probably
also install, but I didn't feel like taking the time to review them
all and figure out what dependencies they would need.
It would have been a shame to add a mandatory dependency on Ruby (and
all that entails) to a package that otherwise has basically no
dependencies, so I've made the Ruby dependency optional.
git-cinnabar calls into Mercurial as a library, so we make use the
same version of Python as Mercurial.
Support for Python 3 is an experimental feature in git-cinnabar, but
we unconditionally use it here because:
* Mercurial in Nixpkgs only supports Python 3.
* git-cinnabar touches a network, and for that purpose it's good to
use a version of Python that is going to get security updates.
I checked through haskellPackages looking for packages that were
marked as broken, but successfully built.
I identified these 162 packages that were marked as broken in spite of
building successfully for me with NIXPKGS_ALLOW_BROKEN.
Like all supported formats (I think), LZO is optional. I don't see
any reason to bother with options for now, so I've just enabled it. Plus,
there's a bug in this release that makes compilation fail if LZO is
disabled due to a missing include. I've sent a fix[1] for that
upstream.
[1]: https://github.com/AgentD/squashfs-tools-ng/pull/41
This is built from the same source as minijail, but is for all intents
and purposes a seperate package. It builds different things, with no
overlap, and is under a different license.
I find it extremely unlikely we'll ever package two different patch
versions of the same minor Rust version. New patch versions should
generally be compatible, so we shouldn't give people the expectation
they'll be able to pin to one. And by including the patch version in
the attribute name, we'd have to change the attribute every time a
patch version was released, which would unnecessarily create diff
noise and maintenance headaches for what should be a seamless upgrade.
freedesktop.org tarballs haven't been published since 0.7.0. I've
sent a message to the mailing list (<87eev3cgcz.fsf@alyssa.is>),
suggesting newer tarballs be published.
Build system has changed from autoconf to meson+cmake/ninja, and the
vtest/util.c patch doesn't seem to be necessary any more.
The bang was missing! What was there before would still have worked,
but I think it would end up being executed by /bin/sh since it had no
shebang line.
The bang was missing! But there's a neater way to do this anyway.
What was there before would still have worked, but I think it would
end up being executed by /bin/sh since it had no shebang line.
I thought about doing a seperate output for these, but they're tiny
compared to the size of the binary, so there's no point.
(cherry picked from commit 0489c1b4b20d13fa04e6460ead73893889ff2529)
As explained by Orivej (reformatted from Markdown):
> These (except libsignal-protocol-c) are private dependencies of the
> actual dependencies that should neither be propagated nor added
> manually to dino. For example, libpsl and brotli come from
> libsoup-2.4.pc:
>
> Requires: glib-2.0 >= 2.38, gobject-2.0 >= 2.38, gio-2.0 >= 2.38
> Requires.private: libxml-2.0, sqlite3, libpsl >= 0.20, libbrotlidec, zlib
>
> (To be precise, glib uses utillinuxMinimal rather than utillinux.)
>
> The warnings we see, such as Package 'mount', required by 'gio-2.0',
> not found, come from CMake running both pkg-config --libs and
> pkg-config --static --libs to populate both <XXX>_LIBRARIES and
> <XXX>_STATIC_LIBRARIES[1], but dino has no use for the latter.
> Currently these warnings can not be disabled:
> https://gitlab.kitware.com/cmake/cmake/issues/18158
>
> (They could be prevented by pruning Requires.private from shared-only
> libraries akin to <https://github.com/NixOS/nixpkgs/pull/51767>,
> although it can not be detected if a library is shared-only from the
> .pc file alone, and this is just a warning.)
>
> [1]: docs: https://cmake.org/cmake/help/v3.16/module/FindPkgConfig.html
Previously, some files were copied into the Nixpkgs tree, which meant
we wouldn't easily be able to update them, and was also just messy.
The reason it was done that way before was so that a few NixOS
options could be substituted in. Some problems with doing it this way
were that the _package_ changed depending on the values of the
settings, which is pretty strange, and also that it only allowed those
few settings to be set.
In the new model, mailman-web is a usable package without needing to
override, and I've implemented the NixOS options in a much more
flexible way. NixOS' mailman-web config file first reads the
mailman-web settings to use as defaults, but then it loads another
configuration file generated from the new services.mailman.webSettings
option, so _any_ mailman-web Django setting can be customised by the
user, rather than just the three that were supported before. I've
kept the old options, but there might not really be any good reason to
keep them.
We already had python3Packages.mailman, but that's only really usable
as a library. The only other option was to create a whole Python
environment, which was undesirable to install as a system-wide
package.
It's likely that a user might want to set multiple values for
relay_domains, transport_maps, and local_recipient_maps, and the order
is significant. This means that there's no good way to set these
across multiple NixOS modules, and they should probably all be set
together in the user's Postfix configuration.
So, rather than setting these in the Mailman module, just make the
Mailman module check that the values it needs to occur somewhere, and
advise the user on what to set if not.
This replaces all Mailman secrets with ones that are generated the
first time the service is run. This replaces the hyperkittyApiKey
option, which would lead to a secret in the world-readable store.
Even worse were the secrets hard-coded into mailman-web, which are not
just world-readable, but identical for all users!
services.mailman.hyperkittyApiKey has been removed, and so can no
longer be used to determine whether to enable Hyperkitty. In its
place, there is a new option, services.mailman.hyperkitty.enable. For
consistency, services.mailman.hyperkittyBaseUrl has been renamed to
services.mailman.hyperkitty.baseUrl.
Using a custom path in the Nix store meant that users of the module
couldn't add their own config files, which is a desirable feature. I
don't think avoiding /etc buys us anything.
Previously:
** (dino:7442): CRITICAL **: 00:35:22.373: file /build/source/main/src/ui/unified_window.vala: line 86: uncaught error: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
(dino:7442): Gtk-WARNING **: 00:35:22.601: Found an icon but could not load it. Most likely gdk-pixbuf does not provide SVG support.
The system libsignal-protocol-c is preferred now, so fetching
submodules is no longer required.
The other libraries added are ones that the build complained about. I
suspect they are optional dependencies. Adding them makes the build
quieter, and has basically no impact on runtime closure size, so no
harm in making them available to keep the build system happy.
I don't think there's any situation in which an unwrapped execlineb is
useful -- if you want to use different versions of the execlineb tool
it'll still prefer ones in PATH. At the same time, implementing the
wrapper in this way, as a series of two derivations, meant that we
didn't get stdenv goodness for the wrapper. This meant that, for
example, the wrapper was not stripped, and so execline ended up with
runtime dependencies on gcc and the Linux headers. I don't want to
have to reimplement this sort of stuff when it's already in stdenv,
and so it makes much more sense to create the wrapper in the
mkDerivation call, where all of stdenv's normal magic will find it.
The previously propagated build inputs are optional, and so are
included in checkInputs so the tests can run, but not propagated so
they aren't included if unneeded.
This fixes some two-digit year rounding bugs that started triggering
because 2020 is closer to 2070 than 1970. Apparently two digits years
are still a thing.
This reverts commit a1eacb900e.
Adding dev outputs to python packages means they can't be included in
a Python environment created with python3.withPackages, because
makePythonPath will include the dev output, which is empty apart from
nix-support, rather than the out output, which contains all the Python
code.
Supporting a path here is important because it allows e.g. fetching a
configuration from a URL. To do this and provide the configuration as
a string, IFD would be necessary. It's just written into a path
anyway.
Airwave itself is free software, but the VST SDK it depends on is not.
This means that trying to build airwave fails with an error about
manually adding VST SDK to the store, rather than the expected error
that non-free software has been requested.
Setting a Bundler version with GEM_PATH doesn't seem to work in Ruby
2.7, so we need to use the LOAD_PATH instead. Without this,
bundlerEnv environments will always use the version of Bundler that
comes with Ruby, which won't necessarily work because it isn't the
version that was used to generate the bundle.
For example, building ronn with Ruby 2.7 without this change results
in a broken executable, but it works (when built with all packaged
Ruby versions) after this change.
I removed the "propagatedbuildInputs" line because it's misspelled, and
so will never have worked. Nobody seems to have complained, so
presumably wasn't necessary.
Replaced src munging with a custom unpackPhase because the previous
approach couldn't handle a newly introduced path with a space, and
this is cleaner anyway (but was impossible at the time due to
unpackPhase not being forwarded to fetchcargo).
Alyssa Ross