ReiserFS has not been actively maintained for many years. It has been
marked as obsolete since Linux 6.6, and is scheduled for removal
in 2025. A warning is logged informing users of this every time a
ReiserFS file system is mounted. It suffers from unfixable issues
like the year 2038 problem.
JFS is a slightly more ambiguous case. It also has not been actively
maintained for years; even in 2008 questions were being raised
about its maintenance state and IBM’s commitment to it, and some
enterprise distributions were opting not to ship support for it as
a result. It will [indefinitely postpone journal writes], leading
to data loss over potentially arbitrary amounts of time. Kernel
developers [considered marking it as deprecated] last year, but
no concrete decision was made. There have been [occasional fixes]
to the code since then, but even the developer of much of those was
not opposed to deprecating it.
[considered marking it as deprecated]: https://lore.kernel.org/lkml/Y8DvK281ii6yPRcW@infradead.org/
[indefinitely postpone journal writes]: https://www.usenix.org/legacy/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf
[occasional fixes]: https://www.phoronix.com/news/JFS-Linux-6.7-Improvements
Regardless of whether JFS should be removed from the kernel, with all
the implications for existing installations that entails, I think
it’s safe to say that no new Linux installation should be using
either of these file systems, and that it’s a waste of space and
potential footgun to be shipping support for them on our standard
installation media. We’re lagging behind other distributions on
this decision; neither is supported by Fedora’s installation media.
(It also just so happens that `jfsutils` is the one remaining package
in the minimal installer ISO that has reproducibility issues, due to
some cursed toolchain bug, but I’m not trying to Goodhart’s law
this or anything. I just think we shouldn’t be shipping it anyway.)
The macOS deployment target has been set to 12.0, and the collection
of patches and reverts to keep older macOS versions working has been
dropped, as maintaining what is effectively a fork of QEMU solely for
the sake of versions no longer supported by Apple has become untenable.
It may or may not still work on older macOS versions, potentially with
reduced functionality. Upstream only officially supports the latest
two versions of macOS, so this is still extending support further back
than QEMU will support. To continue supporting back to macOS 10.12,
at least the following upstream commits would have to be reverted,
and possibly more:
* <2d27c91e2b>
* <e9c9d8dc3b>
* <7b60b971cc>
However, if you want to do that, you should be prepared to take up the
burden of maintaining the monotonically‐increasing set of patches
that will be required to keep this working in future.
Fixes: CVE-2024-7409
Co-authored-by: Emily <vcs@emily.moe>
Various warnings are emitted when building in Darwin environments,
apparently due to the use of Clang as opposed to GCC. We could continue
to add more `-Wno-xxx` flags as they arise, either with the existing
`stdenv.isDarwin` condition or with the more correct
`stdenv.cc.isClang`, but for an older codebase it seems more prodent to
stick with the latest standard where it builds cleanly. The newer
`-std=c++11` was also attempted, but it still failed to build.
This packages the garmin_connect component from cyberjunky.
I decided to not package the latest release, but the master branch,
because the latest release hard depends on a specific version of
python3Packages.garminconnect. The master branch does not.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
