The gi-r-scanner is generating a list of shared libraries that are
referenced in the shared-library attribute of the <namespace/> element
of the GIR file. However, this attribute only contains the names of the
libraries and not the full store paths, like for example while preparing
to package libblockdev, the following items were included in the
shared-library attribute:
/nix/store/...-libblockdev-1.3/lib/libblockdev.so.0
libm.so.6
libdmraid.so.1.0.0.rc16
libbd_utils.so.0
Unfortunately, loading such a library without setting LD_LIBRARY_PATH is
going to fail finding libm.so.6 and libdmraid.so.1.0.0.rc16.
Now the first attempt at solving this was to put absolute paths of all
the libraries referenced in the shared-library attribute, but this also
led up to including paths of build-time shared objects into that
attribute:
/nix/store/...-libblockdev-1.3/lib/libblockdev.so.0
/nix/store/...-glibc-2.21/lib/libm.so.6
/nix/store/...-dmraid-1.0.0.rc16/lib/libdmraid.so.1.0.0.rc16
/tmp/nix-build-libblockdev-1.3.drv-0/.../utils/.libs/libbd_utils.so.0
This of course is not what we want, so the final solution is to only
use the absolute path whenever it is a Nix path and leave the library
name as-is if the path doesn't reside within the store, like this:
/nix/store/...-libblockdev-1.3/lib/libblockdev.so.0
/nix/store/...-glibc-2.21/lib/libm.so.6
/nix/store/...-dmraid-1.0.0.rc16/lib/libdmraid.so.1.0.0.rc16
libbd_utils.so.0
The downside of this approach is that if not even the output path of the
library is in LD_LIBRARY_PATH, even loading of libbd_utils.so.0 could
fail, so we need to patch the loader as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Currently we have `kde4.konversation` which is version 1.5 of
Konversation.
This adds `kde5.konversation` which is version 1.6 and builds
against the latest KDE Frameworks 5.
See http://nixos.org/nixpkgs/manual/#sec-package-naming
I've added an alias for multipath_tools to make sure that we don't break
existing configurations referencing the old name.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Last maintained in 2013. Building fails due to vanished sources.
Upstream has the following to say:
“As of February 11th 2015, Fuze will no longer support a native
Linux-based client. This means that any customers attempting to
install or use our previous Linux client will be unable to do
so. There are currently no plans to create an updated version
of the Linux client for Fuze. For Linux based customers that
still wish to use Fuze, we recommend that you try our browser
client.” -- https://support.fuze.com/hc/en-us/articles/201527877-Does-Fuze-Support-Linux-
Never marked as broken, but has been so for quite some time.
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.
I didn't see nice patches to apply,
so I exchanged the whole source (-> autoreconf).
/cc maintainer: k0ral. BTW, it's practical to have the maintainers attribute
match the github name exactly so that people know how to /cc you.
'bar' has been officially renamed 'lemonbar'.
Last release (1.1) is almost a year old, but some bugfixes and new features are available in the repository, let's include them in the derivation.
