Bug 1250214 - rebuild for new Xorg ABI version
rebuild for new Xorg ABI version
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-qxl (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Alon Levy
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 14:16 EDT by David Shea
Modified: 2015-08-11 04:02 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-06 12:14:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fixit (4.88 KB, patch)
2015-08-04 14:16 EDT, David Shea
no flags Details | Diff

  None (edit)
Description David Shea 2015-08-04 14:16:40 EDT
Created attachment 1059199 [details]
fixit

Description of problem:
xorg-x11-drv-qxl-0.1.4-3.fc23, the latest in rawhide, requires xserver-abi(videodrv-20), which is no longer in rawhide. rawhide composes have been impossible for a week because of this.

Obviously the ABI change that broke everything shouldn't have just gone in to the tree without warning, but, well, here we are.

Also, I am aware that xorg-x11-drv-qxl as it exists in dist-git does not currently build in rawhide, which is why I attached a patch that does all of the actual work short of bumping the release number and adding a changelog.
Comment 1 Adam Williamson 2015-08-04 14:36:24 EDT
I applied David's fixes and rebuilt for Rawhide. http://koji.fedoraproject.org/koji/taskinfo?taskID=10602216
Comment 2 Christophe Fergeau 2015-08-05 05:46:56 EDT
*sight*, the first patch has been stale for 6 months on spice-devel, I would not include it in rawhide without checking first what's going on. The second patch (fixing the compilation breakage) has been reported as being broken... http://lists.freedesktop.org/archives/spice-devel/2015-August/021216.html

Some better patches have been sent yesterday:
http://lists.freedesktop.org/archives/spice-devel/2015-August/021235.html
http://lists.freedesktop.org/archives/spice-devel/2015-August/021236.html
Comment 3 David Shea 2015-08-05 08:03:20 EDT
(In reply to Christophe Fergeau from comment #2)
> *sight*, the first patch has been stale for 6 months on spice-devel, I would
> not include it in rawhide without checking first what's going on. 

The nice thing about setting initial values to get around uninitialized value warnings is the worst case is that it'll be exactly as broken as it is right now.


> The second
> patch (fixing the compilation breakage) has been reported as being broken...
> http://lists.freedesktop.org/archives/spice-devel/2015-August/021216.html
> 
> Some better patches have been sent yesterday:
> http://lists.freedesktop.org/archives/spice-devel/2015-August/021235.html
> http://lists.freedesktop.org/archives/spice-devel/2015-August/021236.html

I don't see how the second patch is any different from the patch and spec file change I applied, but fine, use those. Rawhide composes have been dead in the water for a week because of this.
Comment 4 poma 2015-08-05 08:20:10 EDT
If something is buildable, does not necessarily mean it is usable in the same time.

You Shea and Williamson also made the mistake - patching without proper testing,
patching without a conversation with the upstream.

Again you deserve the prestigious award - "Happy Campers".

Ref.
https://bugzilla.redhat.com/show_bug.cgi?id=1249976
Comment 5 Christophe Fergeau 2015-08-06 06:14:59 EDT
(In reply to David Shea from comment #3)
> (In reply to Christophe Fergeau from comment #2)
> > *sight*, the first patch has been stale for 6 months on spice-devel, I would
> > not include it in rawhide without checking first what's going on. 
> 
> The nice thing about setting initial values to get around uninitialized
> value warnings is the worst case is that it'll be exactly as broken as it is
> right now.

I'm not worried about this patch having issues, I'm worried about this patch staying downstream in rawhide and not staying in limbo upstream for no good reason.

> 
> 
> > The second
> > patch (fixing the compilation breakage) has been reported as being broken...
> > http://lists.freedesktop.org/archives/spice-devel/2015-August/021216.html
> > 
> > Some better patches have been sent yesterday:
> > http://lists.freedesktop.org/archives/spice-devel/2015-August/021235.html
> > http://lists.freedesktop.org/archives/spice-devel/2015-August/021236.html
> 
> I don't see how the second patch is any different from the patch and spec
> file change I applied, but fine, use those. Rawhide composes have been dead
> in the water for a week because of this.

The patch which is currently in rawhide unnecessarily changes uxa-glyphs.c, and this has been reported as causing a Xorg crash (even though this is very unexpected). Currently upgrading my rawhide VM in order to be able to test this.
Comment 6 Christophe Fergeau 2015-08-06 06:16:04 EDT
(In reply to Christophe Fergeau from comment #5)
> I'm not worried about this patch having issues, I'm worried about this patch
> staying downstream in rawhide and not staying in limbo upstream for no good
> reason.
> 

_about this patch being used downstream in rawhide and staying in limbo on the upstream mailing list_

(makes more sense this way)
Comment 7 Christophe Fergeau 2015-08-06 12:14:02 EDT
Testing confirmed that -4 was causing Xorg to crash at startup. I've pushed a -5 build which should address this, even though after starting the session I got a frozen desktop. This happens with VNC+VGA as well, so unrelated.
Comment 8 Adam Williamson 2015-08-10 19:14:52 EDT
I don't see how applying a patch downstream makes it any more likely to stay in limbo upstream. It being in limbo upstream is a problem regardless. The package not building for Rawhide was a problem that needed fixing urgently.

I never like coming across packages which have patches *with no upstream references*, but David's changes to the spec file very clearly explained the patches and linked to the appropriate upstream discussions, which pretty much entirely avoids any likelihood of them not being progressed upstream.
Comment 9 Christophe Fergeau 2015-08-11 04:02:32 EDT
(In reply to Adam Williamson from comment #8)
> I don't see how applying a patch downstream makes it any more likely to stay
> in limbo upstream. It being in limbo upstream is a problem regardless. The
> package not building for Rawhide was a problem that needed fixing urgently.

That stale patch was not fixing the build, it's fixing some non-breaking compile-time warnings. Applying a patch which has been stale downstream for 6+ months without pinging upstream about it makes it very likely that the patch will stay downstream-only.

> which pretty much entirely avoids any likelihood of them not being 
> progressed upstream.

I don't understand your point here.

Note You need to log in before you can comment on or make changes to this bug.