Nixpkgs is meant to link everything dynamically. We don’t want to
expose static packages at the top level. If some package needs
statically built binaries, it should use a custom override.
* kodi-cli: init at 1.1.1 (#50892)
* kodi-cli: nitpicks
nitpicks applied are:
- The pname thing
staging-next has been merged.
- Moved to tools/misc
applications/video is more appropriate for video applications.
This is a script used to interact with one.
- Changed platforms to unix
This script can only be used where kodi is present.
This fixes an impurity in nix-index: Previously it would take the nix-env
binary from the users PATH. I discovered this while trying to run nix-index in a
systemd service, which by default doesn't have nix-env in its path. The
errors it threw were not informative at all and it took me hours to
finally figure out the reason.
The install.sh script looks for all perls in $PATH, tries to execute
these to test whether that perl is "good", if it is, takes it and
puts it into the shebang.
This obviously can't work for cross. As installation seems to be pretty
trivial, do it in a custom install phase.
- use nix build instead of nix-build
- writes per-build log in the current working directory
- symlinks the builds in the current working directory
- detects & deduplicates build aliases
- markdown reports
- filter builds by regex
- generate nix expression files that can be build by the user
xfsprogs started using icu in bff5d1a4e8df8a23957e5739850754991ad2b9c8, part of v4.16.0
xfsprogs-4.15.0-docdir.patch is needed to avoid cyclic references in the outputs.
./glibc-2.27.patch is no longer necessary as it was included in xfsprogs 8041435de7ed028a27ecca64302945ad455c69a6
To make updating large attribute sets faster, the update scripts
are now run in parallel.
Please note the following changes in semantics:
- The string passed to updateScript needs to be a path to an executable file.
- The updateScript can also be a list: the tail elements will then be passed
to the head as command line arguments.
Introduce an extent-layer (as opposed to the existing file-level) deduplication
system for btrfs. This provides a means of finding similarities within
non-identical files, when they contain identical, aligned blocks.
I've introduced the plugin and have been maintaining it ever since, so
it's time to make myself the official maintainer in order to avoid
confusion about who to address when issues about the alternatives plugin
arise.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @wisp3rwind
This introduces the following upstream changes:
* The package is now on PyPI
* Require at least beets v1.4.7
* Update album art in alternatives when it changes
* Python 3 support (Python 2.7 continues to be supported)
* Support the format aliases defined by the convert plugin ('wma' and
'vorbis' with current beets)
* Bugfix: Explicitly write tags after encoding instead of relying on
the encoder to do so
* Bugfix: If the formats config option is modified, don't move files
if the extension would change, but re-encode
I updated this because I was pinged by @wisp3rwind about moving back to
@geigerzaehler's repository at [1].
This is what @wisp3rwind wrote in the comment[2] (which was originally
directed to @Profpatsch):
(I hope you're the one to bug, or at least can ping someone else), I
just noticed that you switched the NixOS package to my repository.
Would you please switch it back to this repo soon-ish? The code here
is better tested, and [3] is handled less elegantly on my fork since
it requires changes to the configuration. The latter are undocumented,
but whoever has bothered to take a look at the code might end up with
(harmless) unused config entries.
So in essence we're now back to the original upstream repository again,
which I changed to @wisp3rwind's fork in 29e89248bf
because it fixed issues with Python 3.
Stripping the long_description from setup.py also doesn't seem to be
required anymore, but I didn't investigate why (might be because either
our Python tooling now sets a default language or the README simply no
longer has non-ASCII characters).
[1]: https://github.com/geigerzaehler/beets-alternatives
[2]: https://github.com/geigerzaehler/beets-alternatives/issues/23
[3]: https://github.com/geigerzaehler/beets-alternatives/pull/27
Signed-off-by: aszlig <aszlig@nix.build>
Since 0f38d9669f, the default Python
version for Python 3 is now Python 3.7.
It has been a while since beets had a new release, but the fix for
Python 3.7 is already in master (and it's also rather small), so I
decided to cherry-pick the commit as a patch.
I've built the package along with its tests and they failed at first,
but the errors were unrelated. So I disabled the tests for pylint, as
they're failing right now.
In addition I also needed to temporarily revert
0d2f06ae3a, which supposedly should fix
issues with Python 2 but aparently breaks Python 3 support and during
the beets tests we get a ModuleNotFoundError for the "_gi_gst" module.
However I didn't further investigate why this happens, as I'm time
constrained right now. But after disabling the pylint tests and the
revert of the mentioned gst-python commit, the beets tests succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jtojnar, @lopsided98 (for introducing the gst-python change)
Cc: @domenkozar, @pjones (other beets maintainers)
* woeusb: add p7zip to runtime deps enable extra feature (#47982)
WoeUSB depends on presence of '7z` binary in the path to execute an extra step.
As Windows 7's installation media doesn't place the required EFI bootloaders
in the right location, WoeUSB extracts them from the system image manually
using '7z' binary which it checks with 'command -v 7z'.
See related code at:
aea4f91783/src/woeusb (L1530)
* woeusb: split native build inputs
