When dunst is detected *and* awesomeWM is used (its internal notification system to be exact)
then betterlockscreen waits for dunst to reply on the DBus. Due to dunstctl being in PATH
through the wrapper, dunst will always be tried to reach.
None of the workarounds mentioned in the awesome and betterlockscreen repos do not work with
this version, as dunstctl is always called and has to time out first.
In the current master of BLS there is a change that makes BLS check and env-var first, and
would ignore any dunstctl in PATH.
Once the new release happened this could still be used to reduce the closure size.
These packages were identified as broken when ffmpeg = ffmpeg_5.
Tested _only_ by building them. If you are a maintainer of one of these
packages, please test whether your package still works.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
c733f0bf8a switched JACK to using overlay-style
mkDerivation, but forgot to change a reference to `version` to `finalAttrs.version`.
This wasn't caught at eval time because `with lib` was used, making the
source derivation try to fetch (at the time of writing) tag "23.05pre-git",
which obviously doesn't exist :D
Thanks to V for catching this [0].
[0]: https://github.com/NixOS/nixpkgs/pull/216096#issuecomment-1437763295
This reverts commit 8b3a31f923.
commit 8c80bd08b7
("build-support/cc-wrapper: pass in non-existent --sysroot= to untangle
from libc") was reverted. We can drop the workaround.
This is in preparation for native builds of DXVK, but it also allows
users to choose to use an older version if that is more compatible with
their hardware.
Upstream will remove the `setup_dxvk.sh` in DXVK 2.1. To avoid breaking
users of the current derivation, vendor `setup_dxvk.sh`. This script is
based on the upstream script with some modifications:
- Update command-line parsing; and
- Reorganized action processing logic.
`ubootTools` build broke after https://github.com/NixOS/nixpkgs/pull/210004
where we started dropping default libc include path and switched to
`-idirafter` way of specifying libc headers.
Unfortunately the way it's implemented it injects -idirafter after
user's flags, not before. That allows users to inject their paths before
libc include paths, not after (as it would notmally happen).
The change works it around for u-boot by pulling -idirafter libc flags
before user's flags.
Makes the build independency of the default.nix and update.sh file by
explicitly specifying the files that are needed in the result
This allows changing those files without causing a rebuild
Many packages have some kind of flag indicating whether or not to build with
systemd support. Most of these default to `stdenv.isLinux`, but systemd does
not build on (and is marked `broken` for) `isStatic`. Only a few packages have
the needed `&& !isStatic` in the default value for their parameter.
This commit moves the logic for the default value of these flags into
`systemd.meta.{platforms,badPlatforms}` and evaluates those conditions using
`lib.meta.availableOn`.
This provides three benefits:
1. The default values are set correctly (i.e. including `&& isStatic`)
2. The default values are set consistently
3. The way is paved for any future non-Linux systemd platforms (FreeBSD is
reported to have experimental systemd support)
checkInputs used to be added to nativeBuildInputs. Now we have
nativeCheckInputs to do that instead. Doing this treewide change allows
to keep hashes identical to before the introduction of
nativeCheckInputs.
Add a new U-boot flavor for LibreComputer's AML-S905X-CC (Le Potato).
Board's SoC is based on Trusted Firmware-A architecture and needs extra
closed-source early bootloaders to be combined with U-boot in order to
boot properly, similar to Odroid-C2 board.
Proprietary blobs and related tooling are fetched from
github.com/LibreELEC/amlogic-boot-fip and used in postBuild along with
build output.
Hardware: https://libre.computer/products/aml-s905x-cc/
U-boot doc: https://u-boot.readthedocs.io/en/latest/board/amlogic/libretech-cc.html
Note that cups-pdf refuses to run without root privileges.
To use the binary, one has to either convince cups to
call it with root privileges, or install it suid root.
Also note that currently, this cups-pdf-fork produces
small pdfs with selectable text, as promised.
However, copying the text produces "garbled" text
(characters are randomly reassigned).
This is a known issue and I don't know how to fix it:
https://github.com/alexivkin/CUPS-PDF-to-PDF/issues/7
sptool was replaced by a Python script. It wouldn't be too hard to install/wrap
the new script, but I doubt anyone uses it. I made sptool part of the
armTrustedFirmwareTools package when I created it simply because it was trivial
to add, not because it was actually necessary.
* Rename `cups-kyodialog3` -> `cups-kyodialog`
* Update from 8.1601 (2016) to 9.2 (2022) with support for more and
recent printer models (170 vs. 373 PPD files)
* Make Qt GUI optional to reduce closure size, Qt4 -> Qt5
* Avoid full paths to kyodialog filters in PPD files. A PPD file is
copied to /etc/cups/ppd/ for each configured printer and is not
updated when the cups-kyodialog package is updated, thus,
potentially creating dangling references to /nix/store or invoking
the old version of the cups filters.
The cups.socket unit shouldn't be part of cups.service: stopping the
service would stop the socket and break subsequent socket activations.
See https://github.com/apple/cups/issues/6005
`foomatic-db-ppds` uses the Foomatic database from the packages
`foomatic-db` and -- optionally -- `foomatic-db-nonfree`
and the perl modules from `foomatic-db-engine`
to generate about 8,800 ppd files.
The general structure of the build recipe is as follows:
* Merge `foomatic-db` and `foomatic-db-nonfree` into
one package that represents the Foomatic database.
The package `foomatic-db-nonfree` is optional
as it taints the result license-wise;
it will only be used if `withNonfreeDb`
is to to `true` in the `callPackage` call.
We create a tiny setup hook script that provides the combined
database and sets an environment variable pointing to the
database direcotry, which is expected by the foomatic engine.
* The final package's license and version are computed
from the licenses and versions of the database packages.
The license is set to `free` if each database-providing
package has a free license, and to `unfree` otherwise.
The version is simply the highest version
of the database-providing packages.
* The final package uses `foomatic-compiledb`
from the `foomatic-db-engine` package to extract
all ppd files from the database packages.
`patchPpdFilesHook` is used to patch most
executable invocations in the ppd files
so that they point to nix store paths.
Finally, ppd files are gzipped to reduce storage
(from about 550 MiB to 90 MiB installed).
The "nonfree" version of the package, i.e. the version that is
based on `foomatic-db-nonfree` in addition to `foomatic-db`,
contains about 120 additional ppd files
compared to the "free" version.
Since the "free" version already produces about 8,700
ppd files and hydra won't build the "nonfree" version,
the commit adds two package variables to `all-packages.nix`:
* `foomatic-db-ppds` is based on `foomatic-db` only
* `foomatic-db-ppds-withNonfreeDb`
is also based on `foomaitc-db-nonfree`
The package introduced by this commit
is the result of combining other packages;
it is not the build product of a simple source tarball.
While it would also be possible to perform the ppd file
generation directly in the build process of the database
packages, this would yield further complexity as the
`foomatic-db-nonfree` package needs to be combined with the
`foomatic-db` package before ppd file extraction is possible.
There is no upstream product with a name that
could/should be used for the `name` attribute,
the variable name, or for the filename in nixpkgs.
Similar packages have different names across distributions:
* https://repology.org/projects/?search=openprinting
* https://repology.org/projects/?search=foomatic
The name `foomatic-db-ppds` seems to be most common
(albeit not really *that* common):
* https://repology.org/project/foomatic-db-ppds/versions
At least openSUSE splits their corresponding
package into multiple "binary" packages
(similar to our multi-output packages):
* https://build.opensuse.org/package/binaries/Printing/OpenPrintingPPDs/openSUSE_Tumbleweed
I considered something similar.
However, after doing some statistics,
I concluded that it's not worth the effort:
The biggest dependencies (`perl` and `cups-filters`) are
already present on most NixOS systems, and they cannot
be "split away" easily since it cannot be
done along a canonical line (e.g. printer driver).
Splitting directly by dependency risks that ppd files
unexpectedly "move from output to output" on package updates;
disappearing ppd files can be quite annoying for package users.
`foomatic-db-nonfree` contains -- similar to its sister
package `foomatic-db` -- knowledge about printers,
drivers, and driver options from OpenPrinting in xml files.
It needs to be combined with the `foomatic-db`
package to yield a working database.
It also provides about 100 (gzipped) ppd files.
In contrast to `foomatic-db`, this package contains
data that is provided under non-free licenses.
Quoting
https://github.com/OpenPrinting/foomatic-db-nonfree/blob/master/README
> This is a repository of PPD and Foomatic XML files that may
> have restrictions that keep them from being used on a variety
> of machines for licensing and other non-technical reasons.
ppd files can be found in
`$out/share/cups/model/foomatic-db-nonfree`.
The subdirectory `foomatic-db-nofree` is used to avoid conflicts
with other packages that might be combined with the package
`foomatic-db-nonfree` in `config.services.printing.drivers`.
ppd files in this package are *not* patched
to call executables from the nix store:
The only executable "rastertophaser6100" that is
called from ppd files isn't available in nixpkgs.
There is a daily snapshot of a source archive available at
https://www.openprinting.org/download/foomatic/ .
However, these files rotate daily and
cannot be used as a stable download source.
So we rely on OpenPrinting's Github repository
instead and pinpoint a fresh commit.
Note that the current version is from 2015,
so updates are unlikely.
`foomatic-db` contains the collected knowledge about printers,
drivers, and driver options from OpenPrinting in xml files.
It also provides thousands of ppd files.
The build process patches those files to reference executables
in the nix store and gzips them to reduce storage
(from about 670 MiB to 90 MiB installed).
In contrast to the sister package `foomatic-db-nonfree`
(packaged in a follow-up commit),
this package only includes files published under a free license.
Most files are published under the GPL,
some under the MIT license.
For details see
https://github.com/OpenPrinting/foomatic-db/blob/master/COPYING .
To encompass the different licenses, the package's
license is set to "free" as the common denominator.
ppd files can be found in `$out/share/cups/model/foomatic-db`.
The subdirectory `foomatic-db` is used to avoid conflicts
with other packages that might be combined with the package
`foomatic-db` in `config.services.printing.drivers`.
There is a daily snapshot of a source archive available at
https://www.openprinting.org/download/foomatic/ .
However, these files rotate daily and
cannot be used as a stable download source.
So we rely on OpenPrinting's Github repository
instead and pinpoint a fresh commit.
`foomatic-db-engine` contains several perl scripts to parse
and process XML files from the Foomatic database packages.
It can be used to extract ppd files,
which will be accomplished in a follow-up commit.
The package also contains scripts
to handle print queues and jobs.
It can -- optionally -- talk to the local cups server,
to network printers and to SMB print servers.
The build recipe contains switches to enable these features;
however, they are not needed when generating ppd files.
There is a daily snapshot of a source archive available at
https://www.openprinting.org/download/foomatic/ .
However, these files rotate daily and
cannot be used as a stable download source.
So we rely on OpenPrinting's Github repository
instead and pinpoint a fresh commit.
