The reason for this change is simply to avoid the following messages
that are unnecessary and can be confusing (and these messages will be
repeated for each submodule):
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
With this change the behaviour remains unchanged (apart from the
suppressed "warning" in the console output of course) and therefore this
doesn't cause any hashes to change and by default nix-prefetch-git uses
the "fetchgit" branch anyway (branchName can be set to override the
default):
Switched to a new branch 'fetchgit'
For that reason the initial branch name doesn't matter anyway and since
we're not relying on / hardcoding "master" we could simply switch to
"main" (which seems most common nowadays). See [0] for more details on
why this wouldn't break anything.
However, since the initial branch name doesn't matter and to avoid any
additional risks it was "decided" to keep using "master" (s. #113313).
[0]: https://github.com/NixOS/nixpkgs/pull/113313#issuecomment-780589516
SECURITY ISSUE: Fixed a bug where certain sequences of update() calls
when symmetrically encrypting very large payloads (>2GB) could result in
an integer overflow, leading to buffer overflows. CVE-2020-36242
Note: This also updates {,vectors-}3.3.nix (for Python 2 / nixops)
because of the security issue.
And close#78450 because I'm maintaining Chromium for approximately one
year now and it looks like I can keep maintaining it (at least as long
as I have enough time for it). I'm also working on the documentation,
automation, and cleanups so finding a new maintainer in the future
should hopefully be easier.
Important changes:
- The 'isync' compatibility wrapper was removed.
- The Master/Slave configuration keywords where deprecated and should be
replaced with Far/Near. All users should update their configuration
file accordingly. It's a trivial change and the old Master/Slave
keywords will still work for now but result in the following message:
Notice: Master/Slave are deprecated; use Far/Near instead.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Version 0.1.0 is based on the last commit that included support for V1
encryption policies. Version 1.0 is about to be released and will
include a PR which removes V1 policy support and adds V2 policy support.
Source: https://github.com/google/fscryptctl/issues/12#issuecomment-772888154
When version 1.0 is released we'll likely package it as fscryptctl and
mark fscryptctl-experimental as broken (referring to fscryptctl).
During d6d4228b39 I failed to notice that the current chromiumDev
version is older than the first one that contained the commit to fix the
dependency on opus in webcodecs.
This should hopefully fix build of chromiumDev (if there are no
additional issues).
Unfortunately this requires a crazy hack to support building with
Google's proprietary Widevine DRM technology as that requires fetching
the Google Chrome sources (see also 86ff1e45ce).
The hack is required because ungoogled-chromium doesn't always use tags
that correspond to a Google Chrome release.
The build was failing with:
In file included from ../../third_party/blink/renderer/modules/webcodecs/audio_encoder.cc:7:
In file included from ../../media/audio/audio_opus_encoder.h:16:
gen/shim_headers/opus_shim/third_party/opus/src/include/opus.h:5:10: error: 'opus.h' file not found with <angled> include; use "quotes" instead
#include <opus.h>
^~~~~~~~
"opus.h"
[...]
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
[42272/44233] CXX obj/third_party/blink/renderer/modules/webcodecs/webcodecs/decoder_template.oo[K
Note: This also fixes the ungoogled-chromium channel name in versionRange.
I forgot that string comparison isn't enough because e.g.:
>>> "89.0.4389.9" < "89.0.4389.23"
False
distutils.version.LooseVersion is undocumented but it works and is
already available so why not use it:
>>> LooseVersion("89.0.4389.9") < LooseVersion("89.0.4389.23")
True
This also enables the "list" subcommand of xkbcli.
Since libxkbregistry is an optional library we could install it into a
different output. However, doing this properly is quite challenging and
the best approach would likely be to upstream patches that add a Meson
option for installing libxkbregistry under a separate prefix (so that
the pkg-config file is generated correctly, etc.).
But even then the default fixup phase would try to move
$libxkbregistry/include into the $dev output and the $out output would
depend on the $libxkbcommon output because of the xkbcli binary (though
we could move that into a $bin output).
As a result it seems best not to install libxkbregistry into a dedicated
output path.
- Improve the documentation (Python docstrings for functions and more
meaningful xdotool script names).
- Make more use of the existing methods (e.g. wait_until_succeeds(), and
send_key())
- Note: This increases timeouts from 60 seconds to (currently)
15 minutes but the defaults from test-driver.py should be fine.
This should make it simpler to read the code, understand the test
output, and drop the custom xdotool scripts in the future.
This reverts commit 2dbd08dcbd.
I've fixed the regression in 8a7a8442c1 and the rest of my
refactorings/improvements shouldn't affect the stability of the test.
The create_new_win() function could open multiple windows when used
incorrectly. This change makes sure that a new window will only be
created if the main window could be selected successfully.
This also ignores the out return values as they're never used.
The "channel" variable shouldn't be part of the final derivation. This
also makes it possible to avoid unnecessary rebuilds for identical
channels (e.g. major updates are tested via the "beta" channel first and
usually neither the source-code archive nor the dependencies change when
the update makes it into the "stable" channel - this means we could
better use chromiumBeta to test major updates in advance).
The Hydra build fails since 2020-07-28:
x86_64-linux: https://hydra.nixos.org/build/135234622
The patch was broken by eb627de968 but since there is no maintainer it
seems best to simply mark it as broken and eventually remove it.
By default only `chromium` will be tested but other "channels" can be
selected using e.g.:
nix-build nixos/tests/chromium.nix -A ungoogled
This also adds me as secondary maintainer (I'd like to get notified on
PRs/issues and can review them).
Only execute Ctrl+w to close the currently active window if the
new/secondary window (title: "New Tab") could be selected. This fixes a
test failure since the update to Chromium M88 (cc PR #110010).
Without this additional check the main window (title: "startup done")
could still be selected (and thus will be closed) and the script would
close both windows (i.e. terminate Chromium completely).
Chromium seems to run fine but the VM test fails and prints errors like:
machine # There are no windows in the stack
machine # Invalid window '%1'
machine # Usage: windowfocus [window=%1]
machine # --sync - only exit once the window has focus
This could be due to changes in Chromium's X11 code (or maybe some
changes for Ozone/X11). I'll investigate this but let's temporarily
remove the Chromium test from the tested jobset until I find a proper
solution/fix.
This is required to launch newer versions of Google Chrome:
/nix/store/XXX-google-chrome-dev-89.0.4385.0/share/google/chrome-unstable/google-chrome-unstable:
error while loading shared libraries: libxshmfence.so.1: cannot open
shared object file: No such file or directory
Since c378a33705 we have a patch to add svt-av1 support to
ffmpeg-full. The default AV1 encoder is still libaom but svt-av1 has a
higher priority than rav1e (see libavcodec/allcodecs.c). And since
svt-av1 is much faster than rav1e (which in turn should be faster than
libaom) we don't really need rav1e support by default anymore (I guess
it can be useful but overall svt-av1 should currently be the best
option).
And because rav1e's build did break a few times in the past and needs a
lot of Rust dependencies (including cargo-c to make it C-ABI
compatible) it might be best to simply disable it for now.
Benchmarks (though it is difficult to compare them that way):
- https://openbenchmarking.org/test/pts/svt-av1
- https://openbenchmarking.org/test/pts/rav1e
- https://openbenchmarking.org/test/pts/aom-av1
Michael Weiss