The maintainer has stopped cutting releases[1]. Since the last release,
1.4.9, includes a dependency that is filled with hate speech[2] it's all
the more reason to package the unstable version and eliminate that
requirement.
Moreover a number of fixes, improvements, and features have landed
since.
[1]: https://github.com/beetbox/beets/issues/3625
[2]: https://github.com/NixOS/nixpkgs/pull/90504
Co-authored-by: Doron Behar <doron.behar@gmail.com>
Upstream NextPNR has moved to disable the GUI by default; it tends to
cause the most complications/bug reports and has various complexities
and failure modes (e.g. I've still had problems getting it working
efficiently on my Ice Lake laptop.)
Instead, disable GUI support by default, and add a new `nextpnrWithGui`
derivation that enables it. This cuts the closure size down by 40ish
percent (~800MB -> ~500MB) and makes it a neglibile amount faster.
It also fixes two bugs:
1) We were using the old `ICEBOX_ROOT` parameter for ice40 support,
now known as `ICESTORM_ICE40_PREFIX`, and
2) the CMake option `SERIALIZE_CHIPDB` was renamed to `..._CHIPDBS`
(with an 'S' suffix) which should speed up the build at the cost
of RAM usage
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Adds I2C/SPI support for iCE40 u4k devices (iCE5LP4K?)
PyPy3 is apparently broken for now in the wake of the gcc/glibc upgrade,
so just skip it for now.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
* switch build system to wayland
* enable all backends by adding the following to buildInputs as meson
autodetects which backends are available.
* libtiff
* libheif
* libpng
Open questions:
* imv prints a warning from the tiff backend everytime a non tiff file
is opened: Is this normal? Seems harmless enough though.
* Should we make backends configurable / optional? I readded some
backends which apparently were removed, but still given as an argument
to the derivation.
Resolves#108185.
Previously, after the version bump to v247, we broke journalctl --grep
as libpcre2 was lazily loaded during runtime using dlopen(3). This
ensures that we have a test case that alerts us when it fails again.
This ensures that all the features that are implemented via dlopen(3)
are available (or explicitly deactivated) by pointing dlopen to the
absolute store path instead of relying on the linkers runtime lookup
code.
All of the dlopen calls have to be handled. When new ones are introduced
by upstream (or one of our patches) those must be explicitly declared,
otherwise the build will fail.
As of systemd version 247 we've seen a few errors like `libpcre2.… not
found` when using e.g. --grep with journalctl. Those errors should
become less unexpected now.
There are generally two classes of dlopen calls. Those that we want to
support and those that should be deactivated / unsupported. This change
enforces that we handle all dlopen calls explicitly. Meaning: There is
not a single dlopen call in the code source tree that we did not
explicitly handle.
In order to do this I introduced a list of attributes that maps from
shared object name to the package that contains them. The package can be
null meaning the reference should be nuked and the shared object will
never be loadable during runtime (because it points at an invalid store
path location).
Fabian Affolter