See, that's why I hate the gregorian calendar and new years eve: People
tend to celebrate things that are absolutely irrelevant, like this
comment.
The test however assumed that either beets or its test suite would never
survive 2015, so this test should assure it won't survive in >= 2015 :-)
Anyway, the patch is from upstream master, so we can drop it once 1.3.10
is released.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Without this one cannot mount the backup repository:
$ attic mount /backups/backup.attic mnt
attic: the "llfuse" module is required to use this feature
attic: Exiting with failure status due to previous errors
The website gives no indication that version 4.x is required to build
this package, and even it if were, then there should be an override in
all-packages.nix instead of referring to the 'gnumake40' attribute
directly in this expression.
Beets tries to load oll activated plugins on "beet config -e" (however
only on the second run, thus the dummy), so we just pass all activated
plugins into a generated config file and bail out on any errors.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason for doing this is in order to not forget about possible
dependencies in new upstream releases, so if upstream is introducing a
new plugin where we're lacking dependencies, the build will fail on our
side and we can check whether we'll need those.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using commands such as mp3gain and aacgain is only the default for
backwards-compatible reasons. However, on Nix(OS), we would have to
either patch those tools into beets or rely on an impurity, so let's
depend on audiotools and also default to that backend.
Of course, there is also a GStreamer backend, but it comes with a hell
of additional dependencies (which not only cover audio files), which is
why I decided against defaulting to GStreamer and package audiotools
instead (in eecd932).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This also fleshes out/fixes the unit tests, which I've used for
gathering the individual requirements.
Along various Python dependencies we now also have a build-time
dependency on bashInteractive and a runtime dependency on
bashCompletion, which is needed for command line completion to work
correctly.
However, some tests for the shell completion fail at the moment, so I've
disabled them for now.
The patch for fixing mediafile codec info is a modified version of
sampsyo/beets@903e88a, where I just dropped the second hunk modifying
the changelog. It is already merged to master and thus expected to be in
the next upstream version.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason for doing this is because the package on PyPI is missing some
files needed for running the test suite (for example:
test/test_completion.sh).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The primary use of beets is not as a Python library and users usually
would expect to install it into the env using "nix-env -i beets" rather
than "nix-env -i pythonX.Y-beets".
Having beets in its own package directory also allows for better
customization, where we're going to implement attributes that can be
used to turn on/off various features and plugins.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
New build system using configure script and GNU Make 4.0, and new
releases of the following using the new build system:
execline 2.0.0.0
s6 2.0.0.0
s6-dns 2.0.0.0
s6-linux-utils 2.0.0.0
s6-networking 2.0.0.0
s6-portable-utils 2.0.0.0
skalibs 2.0.0.0
Added configurations to `bumblebee` package to easy multiple monitors on Optimus
machines.
The behaviour of the default `bumblebee` package hasn't change, so this change
is backwards compatible. Users who want to connect a monitor to their discrete
card should use the package `bumblebee_display` instead.
Also added new configuration option to nixos bumblebee module:
```
hardware.bumblebee.connectDisplay = true
```
will enable the new configuration, but the default is still false.
Makes beets actually usable (and configurable) on Nix(OS), if you want
to use more plugins rather than just plain lookup of tracks based on
(fuzzy) string matching.
This also changes the derivation name from "python2.7-beets" to just
"beets".
* Commit summary:
beets: Check dependencies on activated plugins.
beets: Check plugin definitions against package.
beets: Use audiotools backend for replaygain.
beets: Allow to configure plugin dependencies.
beets: Switch to using fetchFromGitHub.
python: Add new package audiotools.
python: Add new package discogs_client.
python: Add pyacoustid and dependencies.
python/mutagen: Update to upstream version 1.27.
mp3gain: Fix output path bin directory.
beets: Add myself to maintainers.
beets: Update to new upstream version 1.3.9.
beets: Move into its own package directory.
Beets tries to load oll activated plugins on "beet config -e" (however
only on the second run, thus the dummy), so we just pass all activated
plugins into a generated config file and bail out on any errors.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason for doing this is in order to not forget about possible
dependencies in new upstream releases, so if upstream is introducing a
new plugin where we're lacking dependencies, the build will fail on our
side and we can check whether we'll need those.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using commands such as mp3gain and aacgain is only the default for
backwards-compatible reasons. However, on Nix(OS), we would have to
either patch those tools into beets or rely on an impurity, so let's
depend on audiotools and also default to that backend.
Of course, there is also a GStreamer backend, but it comes with a hell
of additional dependencies (which not only cover audio files), which is
why I decided against defaulting to GStreamer and package audiotools
instead (in eecd932).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This also fleshes out/fixes the unit tests, which I've used for
gathering the individual requirements.
Along various Python dependencies we now also have a build-time
dependency on bashInteractive and a runtime dependency on
bashCompletion, which is needed for command line completion to work
correctly.
However, some tests for the shell completion fail at the moment, so I've
disabled them for now.
The patch for fixing mediafile codec info is a modified version of
sampsyo/beets@903e88a, where I just dropped the second hunk modifying
the changelog. It is already merged to master and thus expected to be in
the next upstream version.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason for doing this is because the package on PyPI is missing some
files needed for running the test suite (for example:
test/test_completion.sh).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The primary use of beets is not as a Python library and users usually
would expect to install it into the env using "nix-env -i beets" rather
than "nix-env -i pythonX.Y-beets".
Having beets in its own package directory also allows for better
customization, where we're going to implement attributes that can be
used to turn on/off various features and plugins.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
http://support.ntp.org/bin/view/Main/SecurityNotice#Recent_Vulnerabilities
The package would no longer build without libcrypto,
and it wouldn't find it without pkgconfig.
I checked that Debian and Arch do use openssl as a dependency,
so it's probably not so bad a thing to have.
CC maintainer @edolstra.
fetchzip calculates the hash of the extracted archive, so that
(irrelevant) changes done to the dynamically generated archive doesn't
cause our hash to be outdated.
New build system using configure script and GNU Make 4.0, and new
releases of the following using the new build system:
execline 2.0.0.0
s6 2.0.0.0
s6-dns 2.0.0.0
s6-linux-utils 2.0.0.0
s6-networking 2.0.0.0
s6-portable-utils 2.0.0.0
skalibs 2.0.0.0
Now that https://github.com/OpenTSDB/opentsdb/issues/420 is resolved
we can use the official release tarball. This includes all third
party JARs, which vastly simplifies the build expression.
* Add "which" dependency, otherwise it builds with lots of
"command not found" errors.
* -lgcc_s, otherwise many commands basically fail without pthread_cancel.
* Fix X11 dependencies, otherwise it would be plan9port with none of UI
programs working.
This may seem strange, but tor distributes its 'torify' wrapper which in
turn attempts to use torsocks to bridge a connection, meaning 'tor'
users out the box may want it to work.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- The Multi Router Traffic Grapher
- You have a router, you want to know what it does all day long?
- Then MRTG is for you. It will monitor SNMP network devices and draw
- pretty pictures showing how much traffic has passed through each interface.
The previous attempt to patch libcurl used
getenv("CURL_CA_BUNDLE") || getenv("SSL_CERT_FILE")
to get the second environment variable if the first is unset.
Unfortunately, this broke libcurl because the (||) operator is C returns
only 0 or 1, so it is inappropriate for pointer comparisons! Now we use
getenv("CURL_CA_BUNDLE") ? getenv("CURL_CA_BUNDLE") : getenv("SSL_CERT_FILE")
instead. This has one downside: it always calls getenv twice! But,
that's a small price to pay for actually being correct.
Using primusrun will work as expected in a multilib environment. Even if the initial program
executes a antoehr program of the another architecture. Assuming the program does not modify
LD_LIBRARY_PATH inappropriately.
This does not update virtualgl for seemless multilib. I was unable to get a mixed 64/32 bit
environment to work with VirtualGL. The mechanism VirtualGL uses to inject the fake GL library would
fail if both 32bit and 64 bit libraries were in the environment. Instead the bumblebee package
creates a optirun32 executable that can be used to run a 32bit executable with optimus on a 64 bit
host. This is not created if the host is 32bit.
For my usage, gaming under wine, the primusrun executable works as expected regardless of
32bit/64bit.
Also, in case of collectd, the -lgcc_s shouldn't be needed anymore,
as the library is in ${glibc}/lib/ now, which is practically always on RPATH.
In case of seyren it was some stdenv change uncovering the mistake of
putting src into buildInputs.
Says: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
CC: #4803. There will likely appear more of these errors on Hydra in time.
