This is required for certain URIs that require launching external
programs (e.g. mailto:, magnet:, or irc:) or setting the default browser
via xdg-settings.
Fix#96897 and fix#92751.
Backwards incompatible changes:
- Removed support for idna based U-label parsing in various X.509
classes. This support was originally deprecated in version 2.1 and
moved to an extra in 2.5.
Note: The following might also need to be updated:
substituteStream(): WARNING: pattern '/usr/share/xcb' doesn't match anything in file 'ui/gfx/x/BUILD.gn'
I didn't look into this yet but IIRC M86 will finally have a flag for
Linux to enable VA-API. So we shouldn't need
enable-video-acceleration-on-linux.patch anymore.
But we likely need to update enable-vdpau-support-for-nvidia.patch
when/before M86 hits the stable channel if we want to keep VDPAU
support.
Ok, so I was about to update the patch (didn't apply anymore) when I
also started looking at it's usage and realized that
NIX_CHROMIUM_PLUGIN_PATH_ (and other substrings) only appears in the
patch itself (i.e. it seemed like we don't need this patch anymore).
Turns out that we have this patch since 2014 (1b84fbf0ca) and it was
only ever used for NIX_CHROMIUM_PLUGIN_PATH_WIDEVINE (and from the log
it isn't clear if/when or how well that worked). But in 2019 that last
usage got removed (545d58a1ef) so we should be able to safely drop this
patch now :) \o/
(I just wanted to note that as it seemed somewhat of a funny story :D
But there is of course nothing wrong with it.)
Git history (git log --oneline -S NIX_CHROMIUM_PLUGIN_PATH_):
7205bd64a3 ungoogled-chromium: init at 81.0.4044.92-2
545d58a1ef chromium: fix widevine
cd3283f921 chromium: 67.0.3396.99 -> 68.0.3440.75
72d7b5ddb1 chromium: fix nix_plugin_paths for 68+
7a3a16dd80 chromium: Remove plugin paths patch for version 50
79d18eb604 chromium: Update dev channel to v52.0.2743.10
c7a3645e7b chromium: Remove stuff for versions <= v51
8b97ca270e chromium: Update all channels to latest versions
b9093f1c64 chromium: Updates, fixes#11492471cdd15e2 chromium: Update beta and dev channels.
5c6aa391fc chromium: Cleanup old patch and update stable
af54ddf8b6 chromium: Drop plugin_paths patch for old versions.
6a8afa4bb3 chromium: Fix plugin_paths patch for version 44.
0aad4b7ee4 chromium: Update all channels to latest versions.
1b84fbf0ca chromium: Allow env vars for passing plugin paths.
This is used by mesa.drivers (still on LLVM 9) as a cache key. I've
ported that change to LLVM 11 to test it and so that it doesn't get lost
in future versions. Credit for the change goes to David McFarland.
See #93946 for details.
Co-Authored-By: David McFarland <corngood@gmail.com>
This is more robust than depending on the channel, though the version
should only matter if the configuration phase fails.
This also switches to the intended version for `chromium` which should
be higher since M85 is in the stable channel.
Thanks `@volth` for pointing this out.
This merges #94204 with the only difference being that I modified the
history into three commits that should be easier to review and
understand.
Original history: 3524f4cfa94744bf5058bed6f2e3f6490f4c8e1b
Modified history: df267a4cca
Thanks to Ilya Fedin and John Preston we're now allowed to reuse the
API ID of the Snap package to avoid hitting rate limits.
This finally resolves#55271 #YAY \o/
This disables the WebRTC integration for now (I didn't really look into
it so far, but probably until we have something like
TDESKTOP_USE_PACKAGED_WEBRTC=OFF).
The effective change is that "drirc.d/00-mesa-defaults.conf" will now be
installed to $out instead of $drivers and not appear under
"/run/opengl-driver/share/" anymore.
This is done to fix#89421, i.e. so that Mesa will find and load the
included DriConf defaults. The other files in "$drivers/share" will not
be moved to $out as some Nixpkgs logic might depend on them being
available under "/run/opengl-driver/share/" (e.g. addOpenGLRunpath).
"The former date based internal versioning (snapshot) is replaced by the
regular version numbering which corresponds to the kernel version." [0]
File changes (additions/removals):
+share/man/man8/ip-mptcp.8.gz
+share/man/man8/tc-gate.8.gz
[0]: https://marc.info/?l=linux-netdev&m=159681449423365
This will now properly wrap the gns3 binary using wrapQtApp instead of
unnecessarily adding qt5Full to the PATH (which significantly increases
the closure and often causes the build to break due to broken transitive
dependencies).
This supersedes the old approach from commit 0eaec4dee2.
Note: Since Gammastep is a fork of Redshift the mkRedshift will be
reused as long as they don't diverge too far.
Also: Gammastep should eventually replace redshift-wlr.
There are some Nixpkgs specific issues that we could fix but due to
changes in Git it currently isn't possible to source git-completion.bash
from ZSH (at least not how tig-completion.bash expects it).
Upstream issue: https://github.com/jonas/tig/issues/940
For the meantime it seems best to simply not install it anymore so that
the fallback implementation from ZSH can be used (more inaccurate as the
git-log completion is reused but it is helpful to complete remotes,
branches, tags, etc. and doesn't emit an error to the console).
Mark chromiumDev as broken since the build requires LLVM 11 which is not
yet in Nixpkgs (due to the lack of an RC, see #93324). Build error:
clang (LLVM option parsing): Unknown command line argument '-basic-aa-recphi=0'. Try: 'clang (LLVM option parsing) --help'
clang (LLVM option parsing): Did you mean '--basicaa-recphi=0'?
ninja: build stopped: subcommand failed.
Backwards incompatible changes:
- Removed support for passing an Extension instance to
from_issuer_subject_key_identifier(), as per our deprecation policy.
- Support for LibreSSL 2.7.x, 2.8.x, and 2.9.0 has been removed (2.9.1+
is still supported).
- Dropped support for macOS 10.9, macOS users must upgrade to 10.10 or
newer.
- RSA generate_private_key() no longer accepts public_exponent values
except 65537 and 3 (the latter for legacy purposes).
- X.509 certificate parsing now enforces that the version field contains
a valid value, rather than deferring this check until version is
accessed.
Deprecations:
- Deprecated support for Python 2. At the time there is no time table
for actually dropping support, however we strongly encourage all users
to upgrade their Python, as Python 2 no longer receives support from
the Python core team.
Michael Weiss