The source code for this project was removed a while ago and there is no
method to build this from scratch anymore.
The erase decission was probably done by the Proton developers as they
are currently focussing all efforts on the protonvpn-gui app.
it's confusing to have the 'playwright' attribute refer to a python
subpackage when there is already an official playwright repo with its
binaires (referred
to as playwright-driver for now).
This is some thing introduced in 2017 to work around a problem that
no longer seems to exist. Nothing uses it except its own test, which
these days passes even with the standard `clangStdenv`.
I have no idea what this escape sequence even is, but it breaks the nix parser with cryptic errors if not used in a comment.
A friend let me know MacOS is prone to input weird spaces, not sure if that is the source.
Candidates were located and created with:
chr="$(echo -e '\xc2\xa0')"; rg -F "$chr" -l | xe sd -F "$chr" " "
There are some examples left, most being example output from `tree` in various markdown documents, some patches which we can't really touch, and `pkgs/tools/nix/nixos-render-docs/src/tests/test_commonmark.py` which I'm not sure if should be addressed
`fuse` consists of the library and SUID binaries. They serve different
scenarios. Packages depending on libfuse don't want to pull in binaries
which shadow SUID ones like `fusermount` and cause troubles.
With outputs splitted, we can use `fuse.dev` in development environment
without risking shadowing SUID binaries.
The `common` output and top-level `fuse-common` are removed because they
are not useful since a long time ago.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
This package has been broken since 24.05 (`pkg_resources` error when
running `toil --help`), and hasn’t built since Python 3.12 became
the default. There have been two major upstream releases since this
package was last updated. I tried to package the newest version, which
drops the boto dependency, but unfortunately it requires obsolete
versions of other Python libraries that we no longer package. Since
it’s been broken for this long anyway and can’t be updated,
let’s drop it for now.
No release in almost half a decade, no maintainer in Nixpkgs, and
the README describes it as obsolete and recommends alternatives:
<978bc1926c/README.rst (obsolescence-notice)>.
This release branch is 8½ years old and hasn’t received an update
in 6 years. Nothing in the Nixpkgs tree uses it. We can simplify a
lot of logic in the GCC and cc-wrapper derivations by removing this
unsupported version.
gcc-4.9.4 was released in Aug 3, 2016, 8 years ago. It's a branch that
went out of support years ago. Numerous bugs never get backported to
this version.
Let's remove it.
gcc-4.8.5 was released in June 23, 2015, 9 years ago. It's a branch that
went out of support years ago. Numerous bugs never get backported to
this version.
Let's remove it.
gcc-4.8.5 was released in June 23, 2015, 9 years ago. It's a branch that
went out of support years ago. Numerous bugs never get backported to
this version.
Let's remove it.
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
(adapted from commit 51f1ecaa59)
(adapted from commit 1743662e55)
The projects have not been in development for around a decade. The
original source for gamin does not exist. Although it exists in gnome
archive now, it only has one similarily unmaintained tool.
Remove both instead of fixing gamin for the latest clang update.
2.3.0 is the final release, the repo is now archived.
Also I don't use it anymore for quite a while, so it didn't have a real
nixpkgs maintainer either.
Closes#338712
The set-cursor patch is taken from:
<https://github.com/Admicos/minecraft-wayland/pull/56>
And other changes including fractional scaling is already upstreamed in
3.4 thus not needed anymore.
Co-authored-by: oxalica <oxalicc@pm.me>
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
Every version is insecure, none of them build successfully, the
project has been abandoned upstream for years, the website is gone,
and nothing in the tree that works used them.
Unmaintained, abandoned upstream, depends on an outdated version of
the abandoned libav, and doesn’t build even if that dependency is
replaced with FFmpeg.
MuPDF 1.17 was kept for `k2pdfopt` but it is no more needed since 01a2741e7a.
There no good reason to keep this old version with known vulnerabilities.
This was broken by the Rust 1.80 upgrade, and is an old version that
we’d have to patch to keep working.
We have already done the 0.4 → 0.5 update without keeping around
the old version or adding in any additional `stateVersion` logic
in <https://github.com/NixOS/nixpkgs/pull/280221>. As a result,
migration for 0.3 users is going to be a little awkward. I’ve done
my best to provide comprehensive instructions for anyone who hasn’t
already bumped to 0.4.
It is probably a footgun to add `stateVersion` logic for any
package that makes backwards‐incompatible schema changes and only
supports migration from the immediately previous version. Users
won’t get migrated by default and we have to either package and
maintain an endlessly growing list of old versions or add complicated
instructions like this. It’s not really practical for us to support
a significantly better migration story than upstream does.
Long‐dead upstream (completely vanished, in fact), using a release
from 2013, barely surviving on a huge pile of Debian patches and
drive‐by fixes. Even the Debian patch set in our package here is
out of date. The `meta.homepage` was updated to point to a GitHub
repository with commits from as recently as 5½ years ago, but that
appears to be a separate fork from another developer, and we never
actually shipped it.
The last time this package was substantially touched was by @vs49688,
who heroically took the time to patch it to update it from FFmpeg
2(!) to FFmpeg 4 as part of a tree‐wide sweep almost three years
ago. Now that I’m dealing with FFmpeg 4, it would need patching
again, and I really don’t feel like it.
I considered simply dropping the FFmpeg dependency by disabling
compressed CDDA support, but it’s just not worth it to keep
this package alive. The state of PlayStation emulation has improved
dramatically from when this fork was current. DuckStation and Mednafen
are both better options for the majority of people. The PCSX Reloaded
code lives on as PCSX ReARMed, which we package as a libretro core,
but not as a standalone emulator. I would encourage anyone who has
reason to want a packaged PCSX fork to package the standalone version
of PCSX ReARMed from <https://github.com/notaz/pcsx_rearmed>. You
can tag me for review if you’d like.
Essentially unmaintained upstream for almost a decade, kept alive
with treewides and drive‐by fixes, and depends on the deprecated
and removed OpenCV C API. Sorry, it looks like a fun toy! Hopefully
someone can port it to a newer OpenCV.
These versions have been obsolete for 5 to 10 years, and have been
broken since 34cd4905d1 unless the user
specifies manual overrides. Given that nobody seems to have reported
an issue with them, I conclude that demand for them is minimal and
that there’s no need for them to block the removal of OpenCV 2.
krb5 and libkrb5 are two separate derivations that can easily end up
in the same closure. They both provide the same shared libraries and
some packages end up getting both copies. Since both copies come from
the same source, packages often get lucky in this situation and just
use whichever library is found first. Sometimes packages are less
fortunate and end up trying to load both. This has gone largely
unnoticed in Nixpkgs, likely because Kerberos is not widely used
outside of enterprise deployments.
This situation seems to have arisen out of a need to break a cycle
in `fetchurl -> curl -> krb5 -> fetchurl`. The libkrb5 build was able to
avoid depending on bison and libedit, making it easier to break the
cycle.
However, we can break the cycle without resorting to two variants of
krb5. Libedit can be removed with configure flags and byacc can be used
instead of bison, allowing a much smaller build closure that can easily
be resolved when breaking the cycle.
This change also adds a "lib" output to krb5 so that packages depending
on krb5 can still benefit from a smaller runtime closure if they only
need the shared libraries.
A future change will include a tree-wide refactor to switch uses of
libkrb5 to krb5.
