libva maintainer here, I'm going to unpush this as this wasn't coordinated with me.
I don't get why this update would solve anything as:
1/ Recommend isn't taken into accounts by the install media set.So if the update is already installed, recommend will not be triggered and the livemedia won't have it.
2/ Intel and freeworld users won't need this recommend , so there is a need to implement it in a more "vendor agnostic way" and not shoke on the mesa-freeworld counterpart.
Last, It's not because you have triggered libva installation that you wan't vaapi backend as a mandatory dependencies as a consequence.
@kwizart I just noticed (a bit too late to stop it) that you edited the update and took out the libva build. The mesa build that was supposed to be pushed together with the libva update was now pushed to stable without it, which means there is nothing now to require/recommend the split out mesa-va-drivers. This is going to lead to a lot of broken installs and is completely unacceptable.
I also disagree with what you said on all counts. First, like Neal mentioned above, recommends are indeed taken into account when composing images. Second, you say that mesa freeworld packages don't need it. This is completely false because the change to split out the VA API drivers was done only to make the rpmfusion mesa freeworld packages possible and it was requested by rpmfusion developers.
Not sure how to best sort out this mess now. I am not at all happy here. @kwizart Can you sort this mess out so that the split works for Fedora (so that the package gets installed by default) and rpmfusion both? I don't have any more time to spend on it this week.
I was the one who helped Jiri to make his computer boot into gdm again, just by installing mesa-va-drivers, so I know his experience is genuine. But we have troubles retrieving the log, it seems that the failed boots weren't saved, they're not visible in systemctl --list-boots. I have no explanation for this, perhaps we figure it out later, but currently that log is unavailable. That doesn't invalidate the story, though.
This update has been submitted for testing by pwalter.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
This update has been pushed to testing.
generally working on intel so far, don't have amd here to test.
Boots on AMD. Doesn't have h264/h265. Works.
This update has been submitted for stable by bodhi.
mesa-va-drivers gets installed as a weak dependency. I don't know if this may cause problems for those who disables installing weak dependencies.
libva maintainer here, I'm going to unpush this as this wasn't coordinated with me.
I don't get why this update would solve anything as: 1/ Recommend isn't taken into accounts by the install media set.So if the update is already installed, recommend will not be triggered and the livemedia won't have it. 2/ Intel and freeworld users won't need this recommend , so there is a need to implement it in a more "vendor agnostic way" and not shoke on the mesa-freeworld counterpart.
Last, It's not because you have triggered libva installation that you wan't vaapi backend as a mandatory dependencies as a consequence.
kwizart edited this update.
Removed build(s):
Karma has been reset.
This update has been submitted for testing by kwizart.
@kwizart
Recommendsare factored into media creation. We use this extensively in the KDE Plasma spin.This update has been pushed to testing.
This update has been submitted for stable by bodhi.
This update has been pushed to stable.
@kwizart I just noticed (a bit too late to stop it) that you edited the update and took out the libva build. The mesa build that was supposed to be pushed together with the libva update was now pushed to stable without it, which means there is nothing now to require/recommend the split out mesa-va-drivers. This is going to lead to a lot of broken installs and is completely unacceptable.
I also disagree with what you said on all counts. First, like Neal mentioned above, recommends are indeed taken into account when composing images. Second, you say that mesa freeworld packages don't need it. This is completely false because the change to split out the VA API drivers was done only to make the rpmfusion mesa freeworld packages possible and it was requested by rpmfusion developers.
Not sure how to best sort out this mess now. I am not at all happy here. @kwizart Can you sort this mess out so that the split works for Fedora (so that the package gets installed by default) and rpmfusion both? I don't have any more time to spend on it this week.
@kwizart @pwalter It seems that Radeon/Nouveau systems don't boot now. We need to resolve this ASAP. Please read https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c17
I distrust this report, there is no log
I was the one who helped Jiri to make his computer boot into gdm again, just by installing mesa-va-drivers, so I know his experience is genuine. But we have troubles retrieving the log, it seems that the failed boots weren't saved, they're not visible in
systemctl --list-boots. I have no explanation for this, perhaps we figure it out later, but currently that log is unavailable. That doesn't invalidate the story, though.there is no need for libva to recommends here really, and there is also no reason for this to crash.
intel has no va drivers installed and I haven't seen an issue there. I've also just installed an f37 machine with no va drivers and it seems to work.
Do you have some local configuration or tweak or something that might cause this?