Bug 481309

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).

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?

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.

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.

thanks!

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.

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

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

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.

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.

Options:
1.  rebuild rpmfusion stuff
2.  revert builds/abi-breakage in fedora.
3.  ???

Opinions?

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.

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.

requested rebuilds:
xine: https://bugzilla.rpmfusion.org/show_bug.cgi?id=601
mplayer: https://bugzilla.rpmfusion.org/show_bug.cgi?id=602
vlc: https://bugzilla.rpmfusion.org/show_bug.cgi?id=603

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?

> 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.

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.

Well, sh*t happens :-) Thanks for taking care of it, guys! I also feel like quick rebuilds are the right solution here.

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

We know, see comment #14, waiting on dependent rpmfusion apps to be rebuilt (fixed), which include those you mentioned.

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.

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?

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).

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?

Right, new build => new EVR (Epoch-Version-Release), the Release tag will need to be bumped.