For in NixOS it is beneficial if both plasma5 and pam use the same Qt5
version. Because the plasma5 desktop may use a different version as the
default Qt5 version, we introduce plasma5Packages.
Starting from Linx 5.6, there is partial upstream support for the Multipath TCP
protocol. There are no downsides to enabling it afaict, since
applications need to opt-in when creating a socket.
From https://github.com/multipath-tcp/mptcp_net-next/wiki:
"[...] users of regular TCP continue to get the same type of connection and
performance unless MPTCP is requested."
These packages were duplicated, and often weren't being updated in sync.
The only difference between them was the lack of pkg-config in
libraspberrypi, which is easily fixable.
Write (similar) expressions for GNURadio 3.7 and 3.8 and make 3.8
available as `gnuradio`, and `gnuradio3_7` point to the 3.7 build.
Teach both 3.7 & 3.8 expressions accept a `features` attribute set, that
tells them what features to compile. There are dependencies within the
different features, and we rely on upstream's cmake scripts to make sure
the `configurePhase` will fail if a feature is not enabled and needed by
another feature. All features are enabled by default.
Put shared Nix functions and attributes for both 3.7 and 3.8 in:
pkgs/applications/radio/gnuradio/shared.nix
Add 2 patches accepted upstream, that don't install some python related
examples if python-support is not enabled.
Remove cmake python reference in 3.8 with removeReferencesTo, if
python-support is turned off.
Update gqrx (reverse dependency) to use a build of gnuradio3_7 without
gui components and for it's gr-osmosdr as well.
Write an external, `wrapper.nix` (shared for both 3.7 and 3.8). Teach it
to handle extra `gr-` packages via `GRC_BLOCKS_PATH`. Likely enable it
to accept extra python packages. Wrap the executables with env vars
wrapGAppsHook and wrapQtAppsHook would have likely given them (hence,
fix#87510). Point `gnuradio` to the wrapped 3.8 derivation.
Add @doronbehar to maintainers of both 3.8 and 3.7.
dirty: use upstreamed patches
moved the initial qtcurve package to mkLibsForQt5 function
to decouple from Qt5 version
added an alias qtcurve -> libsForQt5.qtcurve for backward compatibility
add option to disable gtk2 support (still enabled by default)
Intro:
Part of #101369: Every attribute from kdeApplications and kdeFrameworks
can be built with a few different qt5 versions. It's hard to tell the
difference between an application and a library and some applications
rely on inputs from kdeApplications and libsForQt5 alike.
Before this change, some applications that were defined with
`libsForQt5.callPackage` used libraries from the kde* sets compiled with
a specific qt5 version,
Due to `inherit (kde*) <lib or app>;` used in the widest scope, we had
issues with packages that depended on packages defined by this
`inherit`. This led to mismatched qt versions used in the same inputs,
or the inputs of inputs etc.
Hence, we added to all libsForQt5* sets, packages that will be used from
the correct libsForQt5 set, in accordance to the
`libsForQt5*.callPackage` used. All `inherit (kdeApplications) <pkgs>`
and similar inheritance was moved out of all-packages.nix to aliases.nix
only for backwards compatibility.
Now some KDE applications show up in the attribute sets `libsForQt5*`
which didn't show up there previously. This is sort of misleading, as
these are not necessary libraries, but they show up in the wider scope
thanks to them in aliases.nix. Hence it's the best that can be done
considering the circumstances and the urgency of the issue.
Change error messages to start with or at least mention the name of the
package being referenced. This avoids obscure error messages like
"error: Abandoned by upstream." when rebuilding your system.
Also do some trivial cosmetic changes while touching things.
Right now, running `nixos-rebuild` gives an obscure error:
```
$ nixos-rebuild switch
building Nix...
building the system configuration...
error: Abandoned by upstream. Consider switching to bottom instead
(use '--show-trace' to show detailed location information)
```
(And `--show-trace` adds no useful information.)
The error message doesn't indicate that `ytop` is what's causing the problem.
By adding `ytop` to the error message, configurations that still reference
`ytop` will be easier to debug and fix.
This plugin has been merged into the newer "mopidy-local" plugin which I
just added. "mopidy-local-images" and "mopidy-local-sqlite" were added
originally for Mopidy Iris, but Iris now works with mopidy-local, and
does not need the older ones any more.
This plugin has been merged into the newer "mopidy-local" plugin which I
just added. "mopidy-local-images" and "mopidy-local-sqlite" were added
originally for Mopidy Iris, but Iris now works with mopidy-local, and
does not need the older plugins any more.
All packages were outdated.
Asterisk 15 is not supported anymore, but there is 17 now.
All versions bumped pjproject to 2.10 which requires overriding the
prefix.
Since Asterisk 17, `make install-headers` seems to be needed.
Jasper has been marked insecure for a while, and upstream has not
been responsive to CVEs for over a year.
Fixes#55388.
Signed-off-by: David Anderson <dave@natulte.net>
