Summary: | media-libs/phonon-vlc-0.12.0-r1 with media-video/vlc-9999: src/utils/libvlc.h:33:38: error: cannot convert ‘libvlc_instance_t*’ to ‘const char*’ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | cuteanongirl300 |
Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | cjgibb, cuteanongirl300, kajanos, leohdz172, unhappy-ending |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=489694 https://bugs.gentoo.org/show_bug.cgi?id=936240 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Full build log. |
Description
cuteanongirl300
2024-05-04 22:28:41 UTC
Please always include the full build.log Created attachment 892270 [details]
Full build log.
Sorry for not attaching it originally..
Not a big surprise:
> -- Found LibVLC version: 4.0.0-dev (searched for: 0.0)
Does not seem as if there has been any work towards supporting yet-unreleased VLC even in upstream git master, so if you want to keep using vlc-9999 with this you would want to make KDE aware of the need for porting work, provided they want to put work into a moving target.
(In reply to Andreas Sturmlechner from comment #3) > Not a big surprise: > > > -- Found LibVLC version: 4.0.0-dev (searched for: 0.0) > > Does not seem as if there has been any work towards supporting > yet-unreleased VLC even in upstream git master, so if you want to keep using > vlc-9999 with this you would want to make KDE aware of the need for porting > work, provided they want to put work into a moving target. Then can you remove the broken package from the plasma-meta 6 deps...? Or downgrade the plasma-meta dependency to media-libs/phonon-vlc-0.12.0-r1 or 0.11.3-r1. Absolutely not. "You" broke it by using media-video/vlc-9999. (In reply to Andreas Sturmlechner from comment #6) > Absolutely not. "You" broke it by using media-video/vlc-9999. I wouldn't use it if I could, it's a dependency of plasma-meta:6, attempting to remask the package gives this error. !!! The following update has been skipped due to unsatisfied dependencies: media-libs/phonon:0 selected: (media-libs/phonon-4.12.0-r2:0/0::gentoo, installed) skipped: (media-libs/phonon-4.12.0-r2:0/0::gentoo, ebuild scheduled for merge) (see unsatisfied dependency below) !!! All ebuilds that could satisfy ">=media-libs/phonon-vlc-0.12.0[qt5?,qt6?]" have been masked. !!! One of the following masked packages is required to complete your request: - media-libs/phonon-vlc-0.12.0-r1::gentoo (masked by: ~amd64 keyword) (dependency required by "media-libs/phonon-4.12.0-r2::gentoo" [ebuild]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. I'm not asking to downgrade or remove the package entirely, I meant plasma-meta:6 should not have a broken version of the package as dependency. No, read again. Nothing is "broken" from KDE side. > media-libs/phonon-vlc depends on > media-video/vlc the latter which *you* have chosen to unmask to get 9999. Just don't do that. Would it be best in this case to change the USE requirements for media-libs/phonon-vlc[qt6] to media-video/vlc[-gui] to avoid the Qt6 vs Qt5 issue? This way, there is no need to depend on a live version and current VLC can still be used. I personally just tested this and media-libs/phonon-vlc-0.12.0-r1 built fine. Masked packages may have an inconsistent depgraph - that's part of why KDE Plasma 6 et. al are still masked. This is both kind of "because it's masked" (because our QA tooling doesn't run on it, or doesn't run as strictly) and also "because we know it's not ready". From a reddit post, I was able to guess that for some people, autounmask suggests vlc-9999. That would be helpful information to share here if that's indeed what happened for you. But in any case, this is really precisely the kind of issue we expect people to work out while things are masked. It's an example of the kind of issue we want to figure out before unmasking. It's fine to report issues to let us know about them, but we expect people to have enough Portage experience to know how to work around them. -- *In this case*, it's not actually clear to me still why Portage (if it even did) would suggest this, though. I don't see a chain of things which would lead to it needing vlc-9999 (i.e. VLC with Qt 6 support). *IF* someone can show us a chain where that happens (with output, not just speculation), we can look at at least mitigations for now, possibly masking USE flags or whatever. But right now, I don't get how this happens other than "user put vlc-9999 in package.accept_keywords", which isn't something we can do much about. (In reply to unhappy-ending from comment #9) > Would it be best in this case to change the USE requirements for > media-libs/phonon-vlc[qt6] to media-video/vlc[-gui] to avoid the Qt6 vs Qt5 > issue? This way, there is no need to depend on a live version and current > VLC can still be used. > > I personally just tested this and media-libs/phonon-vlc-0.12.0-r1 built fine. But phonon-vlc *doesn't* depend on media-video/vlc[gui]? The dep is: > media-libs/phonon-vlc/phonon-vlc-9999.ebuild:24: media-video/vlc:=[dbus,ogg,vorbis(+)] (In reply to Sam James from comment #11) > But phonon-vlc *doesn't* depend on media-video/vlc[gui]? > > The dep is: > > media-libs/phonon-vlc/phonon-vlc-9999.ebuild:24: media-video/vlc:=[dbus,ogg,vorbis(+)] No, but VLC defaults to +gui and I'm under the assumption most people with VLC installed probably want/have the gui flag enabled. That's why I suggested changing the media-libs/phonon-vlc[-qt5 qt6] dependency to media-video/vlc[-gui] to make sure the build error doesn't happen. (In reply to unhappy-ending from comment #12) > (In reply to Sam James from comment #11) > > > But phonon-vlc *doesn't* depend on media-video/vlc[gui]? > > > > The dep is: > > > media-libs/phonon-vlc/phonon-vlc-9999.ebuild:24: media-video/vlc:=[dbus,ogg,vorbis(+)] > > No, but VLC defaults to +gui and I'm under the assumption most people with > VLC installed probably want/have the gui flag enabled. That's why I > suggested changing the media-libs/phonon-vlc[-qt5 qt6] dependency to > media-video/vlc[-gui] to make sure the build error doesn't happen. I think we're likely to get people complaining of the opposite because they're not using vlc-9999 then. It's not a good fix and it doesn't really fix the problem - someone could easily then complain about this in another context because they used vlc-9999. What we could do is update a bunch of deps to <media-video/vlc-4 if we know things are using libvlc. I generally resent having to do this because of a live ebuild though. There's no real indication that vlc-4 is any closer to release than it was before, even if I wish it were. (In reply to unhappy-ending from comment #9) > This way, there is no need to depend on a live version It does not depend on a live version, I have been trying to tell you this all the time. There is absolutely nothing to do from packaging side here. (In reply to Andreas Sturmlechner from comment #14) > It does not depend on a live version, I have been trying to tell you this > all the time. > > There is absolutely nothing to do from packaging side here. Sorry, I was under the assumption that phonon-vlc[qt6] was trying to pull in a qt6 version of vlc which doesn't exist in the current branch, so it automatically wanted to auto-unmask vlc-9999. I don't use auto-unmask so I can't confirm if it's pulling it in. That's my fault for the misunderstanding. My suggestion was in the event that does happen, having phonon-vlc[qt6] + live vlc[-gui] avoids the build failure. I think it's a weak workaround but it lets phonon-vlc build with vlc-9999 in this case. I don't expect you to go out of your way to account for live packages, but at the very least it's documented here so a user can find it if they search for it. We don't go out of our way for supporting 9999 packages, we're basically back to here: (In reply to Andreas Sturmlechner from comment #3) > Does not seem as if there has been any work towards supporting > yet-unreleased VLC even in upstream git master, so if you want to keep using > vlc-9999 with this you would want to make KDE aware of the need for porting > work, provided they want to put work into a moving target. *** Bug 935867 has been marked as a duplicate of this bug. *** |