For early testing esp. given a lot of users are impatient about this.
You can verify that deno is being used by running yt-dlp with `-v`:
[debug] [youtube] [jsc:deno] Running deno: deno [...]
Be warned that this is still WIP upstream (PR not merged and marked as
Draft) with a lot of TODOs including for documentation, so use at your
own risks. It may also not necessarily magically fix issues if youtube
isn't working with normal releases for you, so keep your expectations
low.
Tarball is generated with a local script from what the PR is currently
based on and may be lacking some commits that are older than than this
version (aka it is not rebased).
Likely will not update this regularly unless there is a specific reason
to, so it may fall behind the PR until a proper release. Also no plans
to make this work with a live ebuild meanwhile.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
This has very little python, its purpose is to provide the .js
files generated by deno and then the minimal python code just
feeds these files as a string to yt-dlp.
Given tests are not wired (may never be, they use deno and have not
managed to get them to run at all yet), and that this is allarches,
went ahead and self-copied yt-dlp keywords. Note would be meaningless
to run tests for PYTHON_COMPAT given they do not use python at all.
yt-dlp currently only allows specific sha512sum for the .js files
meaning that this will need to be kept pinned with yt-dlp versions.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Will (likely) be newly needed by net-misc/yt-dlp to solve YouTube's
JS challenges among other future things, and also been requested
in bug #927139.
I've formerly tried to package the source version, but do not think
I want to be dealing with that after closer inspection. Needs a huge
amount of crates (936+ vendor-filtered, otherwise 1600+) for one,
but the biggest issue is the V8 crate that tries to download various
tools mid-build (or a prebuilt V8 if do not set V8_FROM_SOURCE=1)
and uses Gn to build. Did manage to prevent clang+gn+ninja without
patching but version 2.5.x has an extra hurdle with the rust
toolchain that it downloads and no easy switch to disable it. May
be possible to patch + copy what the chromium ebuild does but it's
all sort of fragile and will be a difficult to maintain across
versions of both deno and the system's toolchain. We *could* use
the same downloaded toolchain through SRC_URI, but then it wouldn't
support anything but amd64+glibc (sounds arm64 would be complicated
too, unless use prebuilt V8... and if using prebuilt may as well use
deno-bin).
In case someone else gets the source build to work for 2.5+, using
"deno-bin" to avoid name clashing with a future package. Either way
we'll likely want to keep -bin given it's a slow build and users
likely won't want to build it just to download youtube videos.
Note that for users that really want to avoid prebuilts or are on an
unsupported profile (e.g. musl), nodejs is technically usable with
yt-dlp but upstream disables it by default due to security concerns
with running untrusted code with it.
Straight to stable and self-keywording for arm64 (without hardware)
given this just dobin a single (~100MB, stripped) file with no tests.
Closes: https://bugs.gentoo.org/927139
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Ionen Wolkens
Arthur Zamarin
Thomas Beierlein
Volkmar W. Pogatzki
Andreas Sturmlechner