Created attachment 462550 [details] This is my attempt at an ebuild(largely copied from previous versions) that works for me There is a new version of minitube available that fixes problems playing vevo video
not sure whether it is correct or not but I add my google key to make.conf and it may be worth adding that advice to pkg_pretend?
I realise everyone is busy but it is 2 months since reporting this bug and I provided what I considered to be a working ebuild. Is there anything further I can do to help push this update into the tree? The existing ebuild version is largely non functiioning
As far as I know this package has seen no love because nobody on the team uses it and it apparently requires some API key to even merge, making it a higher barrier to even just test. Are you interested in proxy maintaining this package at all? You (or anyone else listening) are more than welcome to take it over if interested. https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
(In reply to Michael Palimaka (kensington) from comment #3) > As far as I know this package has seen no love because nobody on the team > uses it and it apparently requires some API key to even merge, making it a > higher barrier to even just test. FWIW, minitube-2.9 (!!) is out, now, but... The API key thing is google (thus not minitube-specific), and at least in the 2.5.2 version that's the last in-tree, it's not needed to /build/ only at runtime to search on youtube, and there's postpkginst instructions for adding it to a user's runtime config file. It can also be set in the environment using GOOGLE_API_KEY=. But... While gentoo apparently has a common google api key, greppable from other packages in the repo (but don't ask me to post it here!), unfortunately, while this key may well work for some things (e.g. location API in firefox/seamonkey, according to the comments there), based on the URLs in the comments, google puts a different quota on various aspects of their service, some of which can be quite limited, and based on the error I get when I try to use that gentoo google api key with minitube, either gentoo's normal key isn't activated for the youtube api (perhaps it was added later and the gentoo dev that applied for it never agreed to the related service-specific TOS), or it was, but the quota was limited enough it's well exceeded by now, and all I get is a forbidden error, even using the normal gentoo google api key that seems to be used in various other packages. Unfortunately, google appears to require a google account to link their api key to, and I don't have one nor do I intend to have one, so I can't get a proper api key for myself. =:^( Other than that I might be inclined to try my hand at being a proxied maintainer. But there's no way unless whoever registered the gentoo google api key used elsewhere can update it to enable the youtube service quota for minitube, or someone else with a google account is willing to sign up for one and make it available, presumably in the ebuild similar to the normal gentoo google api key usage. So... minitube was nice while I could use it, but since the API key thing that hasn't been possible. Oh, well, nice while it /was/ possible. =:^\
(In reply to Duncan from comment #4) > FWIW, minitube-2.9 (!!) is out, now, but... > > The API key thing is google (thus not minitube-specific)... > Unfortunately, google appears to require a google account to link their api > key to, and I don't have one nor do I intend to have one, so I can't get a > proper api key for myself. =:^( Got a key that works. The in-tree minitube-2.5.2-r1 will search with it, so partially works, but apparently youtube changed something up since then and nothing will actually play. But a straight rename of the 2.5.2-r1 ebuild to 2.9 got me a fully working build. Now I do have much of qt5 merged for kde-*, so I can't say for sure that the old 2.5.2-r1 deps are still absolutely correct for 2.9, but whatever I had already merged was enough so I had no deps to build, only minitube itself, and (with a working api key set, I actually still set it at build time by setting MINITUBE_GOOGLE_API_KEY= via package.env tho setting it at runtime as the ebuild instructs should work as well), the 2.5.2-r1 ebuild renamed to 2.9 both builds and runs absolutely fine. =:^)
I'm not sure this should be in Gentoo ebuild repo then.
(In reply to Andreas Sturmlechner from comment #6) > I'm not sure this should be in Gentoo ebuild repo then. Surely you have to have your own Google Api key to let minitube work. And they automaticly adjusted mine when access limits where exceeded. But don't you have to have an email account when using thunderbird ? Isn't this like with any other hosting service ? media-vidio/minitube-3.1 is out now, which works even better. Needs a new mpv[libmpv] as dependency.
(In reply to Ulenrich from comment #7) > (In reply to Andreas Sturmlechner from comment #6) > > I'm not sure this should be in Gentoo ebuild repo then. > > Surely you have to have your own Google Api key to let minitube work. I have my own key but I am pretty sure that that a Distro key would be sufficient > > media-vidio/minitube-3.1 > is out now, which works even better. Needs a new mpv[libmpv] as dependency. Do you have an ebuild for 3.1? My attempt would not build due to missing directories and building the latest from git compiles but skips all the videos
(In reply to barrie backhurst from comment #8) > (In reply to Ulenrich from comment #7) > > (In reply to Andreas Sturmlechner from comment #6) > > > I'm not sure this should be in Gentoo ebuild repo then. > > > > Surely you have to have your own Google Api key to let minitube work. > > I have my own key but I am pretty sure that that a Distro key would be > sufficient Indeed. As mentioned in my June 2018 comment, Gentoo has its own Google API key for a bunch of other stuff, but apparently it's either not activated for whatever sub-API (youtube?) is required here, or it's activated but the associated quota is used up, perhaps due to someone non-gentoo abusing the key for other usage. > > media-vidio/minitube-3.1 > > is out now, which works even better. Needs a new mpv[libmpv] as dependency. > > Do you have an ebuild for 3.1? My attempt would not build due to missing > directories and building the latest from git compiles but skips all the > videos Same here with the missing dirs for the versioned ebuild. The missing components are in theory independent libraries that really should be built and packaged separately, but they're new libs from the same author and are not yet available in gentoo. Live-git actually includes them as git sub-modules, however, which is why the live-git version builds (the git-r3 eclass supports submodules automatically and they're placed in the right spot either by it or the minitube build scripts, I'm not exactly clear on which, but pleasantly it "just works"). As for the video-skipping bug, try again. I was having that problem here with many but not all videos, but the git log says the problem was fixed, and indeed, I don't seem to have the problem any longer here. There does remain (at least for me, as of my last update a week or so ago) an audio bug behaving like some sort of race condition, where hit-or-miss sometimes a video won't play any audio on first play, but if I click around between it and other videos, I can eventually get audio on the video that originally was playing with no audio. The 3.x series certainly has had issues, the video-skipping one being extremely frustrating, and youtube itself had result-sorting issues that applied to all users of the API (not just minitube) earlier this year, but both of those have been fixed, one by google/youtube and one in minitube, and I'm hopeful the audio one will soon be fixed as well, bringing 3.x back to 2.x functionality once again. I /am/ enjoying 3.x's 4K support (with appropriate 4K supporting VLC), however. 4K/60hz never played smoothly in either firefox or chromium, but it does in minitube, so the computer handles it fine with the optimized vlc code, it's the browser implementation that's not properly optimized that's the problem.
(In reply to Duncan from comment #9) Thank you for your prompt and comprehensive reply :) > > As for the video-skipping bug, try again. I was having that problem here > with many but not all videos, but the git log says the problem was fixed, > and indeed, I don't seem to have the problem any longer here. > I have just tried re-emerging and still get the skipping, running from the terminal gives the following output repeatedly $ minitube [unknown] QObject::connect(QWindow, SearchView): invalid null parameter [unknown] Cannot capture signature function name QRegExp(patternSyntax=0, pattern='"\\b[cs]\\s*&&\\s*[adf]\\.set([^,]+\\s*,\\s*encodeURIComponent\\s*\\(\\s*([a-zA-Z0-9\\$_]+)\\("') [unknown] Cannot capture signature function name QRegExp(patternSyntax=0, pattern='"\\b[cs]\\s*&&\\s*[adf]\\.set([^,]+\\s*,\\s*encodeURIComponent\\s*\\(\\s*([a-zA-Z0-9\\$_]+)\\("')
Created attachment 585502 [details] My git ebuild This is the ebuild I am using, perhaps you could compare with your own as I have most likely overlooked something?
Created attachment 585504 [details] minitube-9999.ebuild (from ?? overlay) (In reply to barrie backhurst from comment #11) OK, here's the -9999 ebuild I'm using. It's not original to me tho I believe I made a single trivial change, commenting the phonon dep as 3.x doesn't require that. IIRC I googled it from an overlay, where it was the same as the 2.x ebuild in the same overlay, so I guessed it hadn't been updated for the 3.x changes, but it worked pretty much as-is, which actually surprised me due to the degree of upstream code change. It's different, but at a quick look I didn't see what in your ebuild would be different enough to be triggering the video-skip problems you mentioned. I think mine's missing the mpv dep in yours but that shouldn't be it. But now that I think a bit more about it, I recall a different problem that you may well be running into, google-API related and thus not minitube or gentoo specific (I've seen it mentioned on the minitube forums by users building from sources on other distros and thus not using the distro key, as well). To be clear this is only my best guess, but it fits the two different sets of symptoms I've seen. Apparently: If you don't have an API key at all, or it's invalid, you can't even get youtube search results, so the video lists won't populate at all. But a valid API key that simply hasn't had the youtube sub-API and its related quota from google activated (so 0 available, as it'd be if a non-zero quota had been exceeded) has different behavior; it lets you get search results and thus populate the play lists in minitube, but once you request actual videos, the 0 available quota kicks in and google/youtube gives you an error, which in minitube results in it skipping that video and trying the next, only to get the same error... If that's correct, then you have to activate the youtube API/quota for your valid key, and /then/ you should be able to play videos in minitube, not just populate the results lists with videos. (And that would have been my problem back when I was trying to use gentoo's valid API key, copied from the firefox or chromium ebuilds, as well. Obviously it's valid and activated for normal browser use, but at least back then, it presumably wasn't activated for the youtube sub-API and quota, so I got search results but couldn't play videos.)
The current latest version is 3.2. Could someone please update the summary? https://flavio.tordini.org/minitube-3-2 https://flavio.tordini.org/minitube-3-1 https://flavio.tordini.org/minitube-3-0 https://flavio.tordini.org/minitube-2-9-released https://flavio.tordini.org/minitube-2-8 https://flavio.tordini.org/minitube-2-7-released Of importance for packagers is probably that v3.0 now uses libmpv and Qt 5.12.
If it still needs an API key, I'm not sure what we are supposed to do though except last-rite it?
(In reply to Andreas Sturmlechner from comment #14) > If it still needs an API key, I'm not sure what we are supposed to do though > except last-rite it? No idea... How is that done for other packages? I assume for Akonadi's Google integration, we also need some kind of key?
(In reply to Dennis Schridde from comment #15) > (In reply to Andreas Sturmlechner from comment #14) > > If it still needs an API key, I'm not sure what we are supposed to do though > > except last-rite it? > > No idea... How is that done for other packages? I assume for Akonadi's > Google integration, we also need some kind of key? Why does Gentoo's normal Google API key, used in chromium, firefox, etc, not work here? Is it simply that it hasn't been activated for youtube's (sub?) API? If so, why hasn't it simply been activated for youtube as well? And if simply needing an API key is grounds for kicking an app, why are those apps not being kicked? If getting a Google API key for Gentoo for them is worth it, what's the difference here? Why is it still being debated? Not that there's not some difference justifying the different treatment here. I don't know; there well could be. But it'd be useful to know what it is, if so.
@Duncan When using minitube with an api key - like I do - you get the youtube all without advertisenment. I would guess Google doesn't want give away videos for consumtion without advertising. ... But I recognized the new minitube for Debian unstable works !! ?? !! ?? @asturm For me the Google Api key is just another user account for the service on youtube watching videos with minitube. Just like an email account. Therefore a purging of minitube should go forward along with the purge of thunderbird, evolution alike packages, which have no usage agenda without an additional user account. --- the diff needed is very minimal for to have a new working minitube: # diff minitube-2.5.2-r1.ebuild minitube-3.1.ebuild 28a29 > media-video/mpv[libmpv] --- So it is a simple bump only just with a new dependency
Arrrgh: the newer minitube-3.2 errors out --- In file included from src/main.cpp:26: src/mainwindow.h:26:10: fatal error: media.h: No such file or directory #include "media.h" ^~~~~~~~~ compilation terminated. make: *** [Makefile:1745: build/obj/main.o] Error 1 ---
(In reply to Dennis Schridde from comment #15) > I assume for Akonadi's Google integration, we also need some kind of key? No.
(In reply to Ulenrich from comment #18) > Arrrgh: the newer minitube-3.2 errors out > --- > In file included from src/main.cpp:26: > src/mainwindow.h:26:10: fatal error: media.h: No such file or directory > #include "media.h" > ^~~~~~~~~ > compilation terminated. > make: *** [Makefile:1745: build/obj/main.o] Error 1 > --- As comment #9 says, that's due to new dependencies for 3.x, three abstraction libs (including the media lib that's triggering the above error) by the same author. Were minitube-3.x properly packaged for gentoo, these would likely be separately packaged library ebuilds with the minitube-3.x ebuild depending on them, but now that minitube is package-masked for tree-cleaning due to lack of maintainer volunteer, that doesn't appear likely to happen. Luckily the author included them as git submodules in his minitube repo, and the live-git minitube-9999 ebuild listed in the attachments worked pretty much as-is -- the sub-modules are automatically pulled by the git eclass and either it or the minitube build system puts them in the right place in the build tree so the build "just works" without them as separate deps, at least here. Note however while the -9999 ebuild already attached can work and works for me, I have kde pulling in most of the deps already, including vlc for kde's phonon dep via phonon-vlc, so it's quite likely I could delete /all/ the deps from the minitube-9999 ebuild and still have it "just work" for me. That of course being part of the reason I've not stepped up myself to be a proxied-maintainer for minitube. So for those (who have already solved the API key problem on their own) who still want a working minitube after the tree-cleaning, if they haven't already downloaded the -9999 ebuild to their local overlay and installed it from there, I'd suggest doing so. Then keep your live-git minitube current using app-portage/smart-live-rebuild or the like. (smart-live-rebuild is marvelous! I already use it routinely as I'm running all live-git kde from the gentoo/kde overlay, so adding minitube as just one more live-git package to check for updates and rebuild as necessary is trivial.) And CC this bug if you haven't already. If the -9999 breaks here and I can fix it, I'll try to post an updated ebuild. Chances are it'll thus remain at least "works-for-me" usable until qt6 (which is probably a year out or more but the kde devs are beginning to prepare for it now) anyway. Whether I (or others) will be able to successfully port the ebuild to qt6 when the time comes, and for that matter, whether the minitube author will port it to qt6, remains to be seen, but I expect that should buy us 18 months to 2 years, anyway, and we'll see what happens after that. Or just do what I did and google minitube-9999.ebuild and see what pops up. Obviously it wasn't ported to minitube-3.x yet when I grabbed it to install here, then posted it above, but with any luck, there's a better one out there now, and someone will port it to qt6 when that becomes necessary.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=523ea70346737a0642483be2e7345f19ebabc75f commit 523ea70346737a0642483be2e7345f19ebabc75f Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-11-25 16:30:51 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-11-25 16:32:06 +0000 media-video/minitube: Drop last-rited package Bug: https://bugs.gentoo.org/608334 Bug: https://bugs.gentoo.org/671652 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> media-video/minitube/Manifest | 1 - .../files/minitube-2.5.1-disable-updates.patch | 11 --- media-video/minitube/metadata.xml | 14 ---- media-video/minitube/minitube-2.5.2-r1.ebuild | 88 ---------------------- profiles/package.mask | 6 -- 5 files changed, 120 deletions(-)
