Bug 481309 - libcaca: update to 0.99beta14 (or newer) for xine-lib (F-9) ?
libcaca: update to 0.99beta14 (or newer) for xine-lib (F-9) ?
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libcaca (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-23 09:51 EST by Rex Dieter
Modified: 2009-05-12 08:24 EDT (History)
6 users (show)

See Also:
Fixed In Version: 0.99-0.7.beta16.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-11 11:34:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2009-01-23 09:51:57 EST
I'm working on a xine-lib update, and it appears that it's libcaca support now requires 0.99beta14 or newer.

We could consider dropping support (or hack/patching it to work), but I'd rather it just work as upstream intended.

I'm aware this involves at least a minor abi break, so I'd like your advice/input on how best to proceed.
Comment 1 Kevin Kofler 2009-01-23 09:55:53 EST
FYI, hacking is what we did for the xine-lib-1.1.16 security update to get that out of the door, but 1.1.16.1 now properly checks for the minimum version so we'd have to redo the hack, and would certainly prefer not to (the hack reintroduces a bug which is fixed in 1.1.16).
Comment 2 Matthias Saou 2009-04-04 19:21:55 EDT
I'm still unsure how to handle this. Updating the package would be easy, it's avoiding any breakage which would be trickier. I still haven't tried to find out how many packages actually link against libcaca, though, so it might be a lot easier than I'm thinking.

Is it such a big deal to have the F9 xine caca output use a hack and/or be buggy?
Comment 3 Rex Dieter 2009-04-13 12:28:52 EDT
Interesting... my quick repoquery reveals only 1 pkg in fedora currently 
BuildRequires: libcaca-devel
and that is xine-lib

(and one non-fedora one:  xine)

But updating libcaca or leaving F-9 xine-lib with (possible) caca-related breakage here is ok with me really, though I'd prefer the former.
Comment 4 Matthias Saou 2009-04-15 10:15:45 EDT
I've just built an updated package for F-9. You should be able to request it being overridden to the build root in order to build against it, then push both the updated xine-lib and libcaca to updates (or updates-testing).

Note that I've also built an updated package for F-10 in order to keep the upgrade path, it's the same version but fixes the multilib issues it had.
Comment 5 Rex Dieter 2009-04-15 10:20:01 EDT
thanks!
Comment 6 Matthias Saou 2009-04-15 10:34:49 EDT
Oh, FWIW, the F-10 mplayer-gui package I have (non Fedora of course) also
requires libcaca, so you might have missed some packages when you've checked,
unless the F-9 one wasn't built against it.
Comment 7 Fedora Update System 2009-04-17 13:09:28 EDT
libcaca-0.99-0.7.beta16.fc9,xine-lib-1.1.16.3-2.fc9.1 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/libcaca-0.99-0.7.beta16.fc9,xine-lib-1.1.16.3-2.fc9.1
Comment 8 Fedora Update System 2009-04-21 21:02:30 EDT
libcaca-0.99-0.7.beta16.fc9, xine-lib-1.1.16.3-2.fc9.1 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update libcaca xine-lib'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3834
Comment 9 Fedora Update System 2009-05-09 00:03:40 EDT
libcaca-0.99-0.7.beta16.fc9, xine-lib-1.1.16.3-2.fc9.1 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 Rex Dieter 2009-05-10 13:01:20 EDT
OK, seems there's ABI breakage for 3rd party repos (rpmfusion, in particular) where older libcaca provided libcucul.so.0 and the newer build does not.

My bad, my previous repoquery's only included fedora proper.

I'll re-open this until the breakage is sorted out.
Comment 11 Rex Dieter 2009-05-10 13:03:13 EDT
Options:
1.  rebuild rpmfusion stuff
2.  revert builds/abi-breakage in fedora.
3.  ???

Opinions?
Comment 12 Kevin Kofler 2009-05-10 13:10:42 EDT
At this point, I'd just rebuild the RPM Fusion stuff. The update already went to stable, I think pushing another update to revert it is a bad solution.

Note that there was a comment from Michael Schwendt back in April:
> mschwendt - 2009-04-22 08:57:09
> Will require rebuilds at RPM Fusion for: mplayer, vlc, xine
which you must have missed.
Comment 13 Rex Dieter 2009-05-10 14:03:49 EDT
I saw the comments, and I compaired the shlibs provided in the %%files lists were (essentially) the same.  Except, it would appear that libcucul.so.0 isn't a shlib anymore, but a symlink (or similar?), and that's the part I missed.
Comment 15 Otto J. Makela 2009-05-10 16:04:36 EDT
And the RPMfusion people shut down the bugs:

ABI changes as during release lifetime are illegitimate...
At least, it should have been announced and the related maintainer warned...
Please report bug to the libcaca maintainer...
Closing to INVALID

So, is this to degenerate into a pissing match between Redhat and Rpmfusion, or
will the smarter party actually fix the problem?
Comment 16 Kevin Kofler 2009-05-10 16:12:41 EDT
> And the RPMfusion people shut down the bugs:

No, they didn't. 602 and 603 are still open, 601 has been fixed already.

And they shouldn't. ABI changes during the release time are perfectly possible if coordinated. In this case, we screwed up, but Rex is remediating by filing those 3 bugs.
Comment 17 Kevin Kofler 2009-05-10 16:18:01 EDT
I marked RPM Fusion bugs 598 to 600 as dupes of bugs 601 to 603.
xine-lib in Fedora and xine in RPM Fusion have already been rebuilt, the rebuild is halfway done and just needs to be completed.
Comment 18 Matthias Saou 2009-05-11 04:21:08 EDT
Well, sh*t happens :-) Thanks for taking care of it, guys! I also feel like quick rebuilds are the right solution here.
Comment 19 Bruce Brackbill 2009-05-11 10:05:48 EDT
On Updates I'm getting:

Dependency resolution failed

libcucul.so.0 is needed by package vlc-0.9.9-2.fc9.i386
libcucul.so.0 is needed by package mplayer-1.0-0.100.20090204svn.fc9.i386 : Success - empty transaction
Comment 20 Rex Dieter 2009-05-11 10:12:07 EDT
We know, see comment #14, waiting on dependent rpmfusion apps to be rebuilt (fixed), which include those you mentioned.
Comment 21 Rex Dieter 2009-05-11 11:34:40 EDT
OK, seems rpmfusion is shipping rebuilt pkgs.

    mplayer-1.0-0.100.20090204svn.fc9.1
    vlc-0.9.9-2.fc9.1
    xine-0.99.5-5.fc9

Closing now.
Comment 22 Brian Morrison 2009-05-12 07:10:20 EDT
I have the updated xine-0.99.5-5.fc9.x86_64 package installed now, but I still get the same error shown above in comment #19 but with the xine package shown as the one requiring libcucul.so.0

Maybe this could be due to being on x86_64?
Comment 23 Kevin Kofler 2009-05-12 08:11:51 EDT
Please see: https://bugzilla.rpmfusion.org/show_bug.cgi?id=601#c4 for what happened.

Unfortunately, third-party repo builds are not guaranteed to use the same versions of the dependencies across all arches (something builds within Fedora's Koji instance are guaranteed to do).
Comment 24 Brian Morrison 2009-05-12 08:18:38 EDT
Thanks for the explanation, I assume that the version numbers will have to increment again then to ensure that the second rebuilt version is picked up?
Comment 25 Kevin Kofler 2009-05-12 08:24:01 EDT
Right, new build => new EVR (Epoch-Version-Release), the Release tag will need to be bumped.

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