Bug#994151: youtube-dl: the youtube-dl project seams to have died
I'm not very familiar with Debian's packaging rules Do what you think is best. youtube-dl is not just for youtube, other sites get constantly fixed or added And now there's no activity since the 1 of July. Waiting for youtube to brake is a bit too conservative. You can also see a declining activity over time. The forks got created because of this declining activity. That they made no statement whatsoever is more concerning then reassuring. Given their hum... toxic attitude, it's unlikely they'll do any statement. It's practically certain, they will never clearly say that the project is dead.
Bug#994151: reply from maintainer
some one claims to have received an email back from the maintainer... https://github.com/ytdl-org/youtube-dl/issues/29965#issuecomment-922377500 Sergey M. 6:22 AM (10 hours ago) to me Hello, Currently I have no free time to spend on youtube-dl as I'm busy with work, ongoing renovation and other post-relocation stuff. Best, Sergey. пт, 17 сент. 2021 г. в 03:19, JD
Bug#994151: red flags
That's part of the red flags i was trying to tell you. They could have added more maintainers years ago, but they didn't. It's almost 3 months now without a commit and even now still no new maintainer.This is why they forked it. This is not new, this is why they are 800 open PRs that accumulated over years. The project is in serious neglect, yet they are no shortage of willing volunteers. Your guess on what is going through their heads, is as good as mine. This is why i'm saying it's dead. And this is why i called this bug grave, because it's upstream it self that is dead, it's not just a technical issue. It will require packaging a fork, the proposed yt-dlp. Even if it came back to life the general state of neglect will almost certainly continue.
Bug#994151: fixes/state of youtube-dl/transition?
some fixes: pycryptodome in debian is in fact pycryptodomex, the current release expects pycryptodome. Beginning from the next release, it can fallback to pycryptodomex. You just need to add "python3-pycryptodome" in the dependencies, and it will be fine, starting with the next release. Also, it depends at a minimum version of python 3.6 . So it will not work on stretch. copyright mentions youtube-dl - nebula? for nebula, i don't know what change disturbed you, but there's this suspect issue. https://github.com/yt-dlp/yt-dlp/issues/496 He apparently removed something by accident. - The state of youtube-dl Joining ... lol. I tried to explain that you can't join. They are 800 open PRs and 2000 open issues. They are probably 100 downloaders that are not in because no one knows. You get the ignore treatment most of the time. Like now with no more commits for 3 months and no official statement( the e-mail response wasn't official, it's some one that reposted it and is berried in an issue). And this project is not just about youtube, the fixes for other downloaders are ignored for these 3 months. Why do you think yt-dlp has an addition of all this and more? • New extractors: AnimeLab, Philo MSO, Spectrum MSO, SlingTV MSO, Cablevision MSO, Rcs, Gedi, bitwave.tv, mildom, audius, zee5, mtv.it, wimtv, pluto.tv, niconico users, discoveryplus.in, mediathek, NFHSNetwork, nebula, ukcolumn, whowatch, MxplayerShow, parlview (au), YoutubeWebArchive, fancode, Saitosan, ShemarooMe, telemundo, VootSeries, SonyLIVSeries, HotstarSeries, VidioPremier, VidioLive, RCTIPlus, TBS Live, douyin, pornflip, ParamountPlusSeries, ScienceChannel, Utreon, OpenRec, BandcampMusic, blackboardcollaborate, eroprofile albums, mirrativ, BannedVideo, bilibili categories, Epicon, filmmodu, GabTV, HungamaAlbum, ManotoTV, Niconico search, Patreon User, peloton, ProjectVeritas, radiko, StarTV, tiktok user, Tokentube, voicy, TV2HuSeries They either ignore you, or just block the issue so that you can't say anything. That's systematic, not after some good reason. I think it must be the same brain disease that affects gnome and systemd devs. -- transitioning? Can you rename it to youtube-dl (with appropriate version name and warning to users) and push that as a backport for now? preferably with the equivalent of: --compat-options youtube-dl --config-location ~/.config/youtube-dl Until either youtube-dl resumes, or you are satisfied that it's truly dead. Then push normal yt-dlp. Then the youtube-dl package could become a compatibility wrapper depending on yt-dlp. It would need to be in python, some applications expect to load it as a module. That should properly handle the transition between the two.
Bug#994151: new maintainer
This explains why i know more about this then the debian maintainer. Normally, it would have been pretty painless to maintain this. It's just bad luck that this happens now. Ask for some one else to take it over: *Maybe the mpv maintainer will be interested. (mpv uses youtube-dl to play videos from urls directly. With youtube-dl installed, this works "mpv https://www.youtube.com/watch?v=9Gj47G2e1Jc";) *There's also the maintainer of youtubedl-gui
Bug#1016003: yt-dlp: create youtube-dl compatability package
youtube-dl has now become openoffice and yt-dlp libeoffice. It had one release in the last 12 months 6 months ago. It's prospects are bleak. What i'm proposing is just to ease the transition. Many applications are hard coded to expect "youtube-dl". You need a symlink for +90% and maybe more for some, so just adding a virtual package to yt-dlp will not be enough. It's best to have a separate package doing the interface and maybe other hacks(symlink, virtual package, maybe compatibilities options...). The youtube-dl and the compat package should be able to coexist with a reconfigure alternatives and youtube-dl should be the default. On Sun, 24 Jul 2022 23:14:43 -0700 Kip Warner wrote: > On Mon, 2022-07-25 at 08:06 +0200, michel wrote: > > Several applications expect to find youtube-dl, not yt-dlp. Yet, the > > two are almost the same. > > It would be nice to have a new package, that wraps around yt-dlp and > > make it look like youtube-dl. > > I think the way to handle this might be for the yt-dlp source package > to also generate a virtual package with a Provides stanza for youtube- > dl, like so: > > > https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides > > Of course this assumes that the two interfaces are the same. Right now > for 99 % of users in the simple ways that they use the two, I think > they probably are. Over time though they will inevitably diverge in the > same way mplayer's descendants did, or ffmpeg and libav's CLI tools. >
