Created attachment 348292 [details] Patch libass to fix vlc release blocker bugs Description of problem: This patch is needed by both mplayer and vlc. (vlc devs took it from MPlayer). Otherwises font rendering issue (using fontconfig) appears. Version-Release number of selected component (if applicable): 0.9.6 For some reasons, it doesn't seems merged in upstream libass yet. Further info can be provided if needed.
(In reply to comment #0) > Created an attachment (id=348292) [details] > Patch libass to fix vlc release blocker bugs > > Description of problem: > This patch is needed by both mplayer and vlc. > (vlc devs took it from MPlayer). > Otherwises font rendering issue (using fontconfig) appears. > > Version-Release number of selected component (if applicable): > 0.9.6 > For some reasons, it doesn't seems merged in upstream libass yet. > > > Further info can be provided if needed. Thanks for reporting the issue. What's the bug number for this in upstream? Also, the patch contains loads of noise (i.e. lots of changes not affecting the code). Could you provide a cleaner one? If not, a test case for this would be helpful (so that I could test whether I'll haven't omitted by accident any of the relevant changes).
There is nothing noisy in this patch, what look empty is indentation fixes. The patch is aimed to be applyed as is. There is no bugreport. Only a comment https://trac.videolan.org/vlc/changeset/3debf72578c1aa15db1566d5d6e12198a4c3784c
(In reply to comment #2) > There is nothing noisy in this patch, what look empty is indentation fixes. > The patch is aimed to be applyed as is. That's the noise I talk about. It's not needed to fix the issue. I'd like to have a patch in cvs that addresses only the specific issue, not some styling fixes alongside... > There is no bugreport. Only a comment > https://trac.videolan.org/vlc/changeset/3debf72578c1aa15db1566d5d6e12198a4c3784c Would be nice to have one though, it's a good practise to reference upstream bug report, when we apply fixes in our packages. It's not a requirement though so I'll probably reference only this bug in rhbz.
(In reply to comment #3) > (In reply to comment #2) > > There is nothing noisy in this patch, what look empty is indentation fixes. > > The patch is aimed to be applyed as is. > That's the noise I talk about. It's not needed to fix the issue. I'd like to > have a patch in cvs that addresses only the specific issue, not some styling > fixes alongside... That's very problematic not to fix the idendation too. If you will not do so, next time you will need to backport something from libass upstream, the patch will not apply/ > > There is no bugreport. Only a comment > > https://trac.videolan.org/vlc/changeset/3debf72578c1aa15db1566d5d6e12198a4c3784c > Would be nice to have one though, it's a good practise to reference upstream > bug report, when we apply fixes in our packages. It's not a requirement though > so I'll probably reference only this bug in rhbz. You want a bugreport at libass upstream, not a vlc/mplayer ones...
(In reply to comment #4) > That's very problematic not to fix the idendation too. If you will not do so, > next time you will need to backport something from libass upstream, the patch > will not apply/ > Isn't it the other way round? Since the patch contains indentation fixes, when I try to apply it on code with these styling fixes in, it will not apply. If I leave these fixes untouched, it will most likely apply. Generally, less unrelated changes in a patch is better. From the change set you referenced, the only changes are two new lines in ass_font.c, while the patch you attached contains much more than that, even if I don't take the indentation fixes into account. The rest seems like various patches mplayer uses in their internal copy of libass. > You want a bugreport at libass upstream, not a vlc/mplayer ones... Yep, that's what I'd like to have.
Hm... on a second thought... You would like me to apply *all* the patches present in vlc/mplayer against libass (which is what you attached) or the specific one that fixes a crasher (which is what you referenced)?
As you want, but it is probably safe to ask libass upstream to do another release if possible. Some part may already be added, indeed. But the attached patch is what is meant to be applied to the 0.9.6 release. The object of this message is that as the libass maintainer for fedora, you can know that libass has a bug, a solution can be found. Please forward other question to libass upstream if needed.
Any answear from upstream ? vlc will drop support from libass from the current maintainer against "greg's version": http://greg.geekmind.org/viewgit/?a=commitdiff&p=libass&h=2b4a7365b172bb0b5ee093329a7acdf6bce1cb8d what is the status of the merge ?
(In reply to comment #8) > Any answear from upstream ? vlc will drop support from libass from the current > maintainer against "greg's version": > http://greg.geekmind.org/viewgit/?a=commitdiff&p=libass&h=2b4a7365b172bb0b5ee093329a7acdf6bce1cb8d > > what is the status of the merge ? I've asked about this issue on the vlc-devel list with this reply so far: http://mailman.videolan.org/pipermail/vlc-devel/2009-July/062628.html I hope we'll be able to come up with a sane resolution of this multiple upstream problem... For now, I'm sticking with the official, separate one, if you know about a specific bug fixed in one of the other places (mplayer, vlc or greg's git) let me know, I'll consider back-porting the patch (and perhaps filling the issue upstream). But generally, I don't want to apply whole lot of patches which both enhance the functionality as well as fix bugs in one batch.
And where is the forward to upstream mail i've requested you to do ?
Hans has rebuilt the package in Rawhide
Can we get rid on this now ! vlc 1.0.2 is nearing few day, And I want a one time push in F-10 F-11 stables upates... Hans, can we get rid of 0.9.6 and move to 0.9.7 ABI
(In reply to comment #12) > Can we get rid on this now ! > > vlc 1.0.2 is nearing few day, And I want a one time push in F-10 F-11 stables > upates... > > Hans, can we get rid of 0.9.6 and move to 0.9.7 ABI Assuming that 0.9.7 is the version we have in rawhide, yes moving F-11 and F-10 over to that is fine.
(In reply to comment #13) > (In reply to comment #12) > > Can we get rid on this now ! > > > > vlc 1.0.2 is nearing few day, And I want a one time push in F-10 F-11 stables > > upates... > > > > Hans, can we get rid of 0.9.6 and move to 0.9.7 ABI > > Assuming that 0.9.7 is the version we have in rawhide, yes moving F-11 and F-10 > over to that is fine. Yup, 0.9.7 is what we have in rawhide and the F11 and F10 versions are sitting in koji for a while now as well. I am not much up2date as how to things work in rpmfusion, so I guess I need to push it (at least) to updates-testing in order for you to be able to rebuild against it?
(In reply to comment #14) > Yup, 0.9.7 is what we have in rawhide and the F11 and F10 versions are sitting > in koji for a while now as well. I am not much up2date as how to things work in > rpmfusion, so I guess I need to push it (at least) to updates-testing in order > for you to be able to rebuild against it? Yes, please let me know when it hits updates-testing, then I'll get matching updated packages in place in rpmfusion updates-testing.
libass-0.9.7-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/libass-0.9.7-1.fc11?_csrf_token=6cbbedf0bd1d0bd0b1fc8b8a1d0effdd424b5051
libass-0.9.7-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/libass-0.9.7-1.fc10?_csrf_token=6cbbedf0bd1d0bd0b1fc8b8a1d0effdd424b5051
libass-0.9.7-1.fc10 has been pushed to the Fedora 10 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 update libass'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9708
libass-0.9.7-1.fc11 has been pushed to the Fedora 11 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 update libass'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9791
gstreamer bad was rebuilt, and vlc is rebuilding... But please don't wait for it, the previous vlc built had libass disabled. Please push libass 0.9.7 ASAP. THX
(In reply to comment #20) > gstreamer bad was rebuilt, and vlc is rebuilding... yup, I've noticed > But please don't wait for it, the previous vlc built had libass disabled. > Please push libass 0.9.7 ASAP. > I'd like it to sit in [rpmfusion-]updates-testing for a week or two first, but if you feel the need for quicker push to stable and if Hans isn't against it as well, I can request the push sooner. Plus we need to sync the libass and gst-plugins-bad pushes to shorten the period with broken deps as much as possible.
Again Please push 0.9.7 to stable now ! gstreamer-plugin-bas was already tested earlier with rawhide. vlc 1.0.2 is a security bugfix, I cannot wait.
Why once again to testing ?! Is this a bug ?
(In reply to comment #25) > Why once again to testing ?! Is this a bug ? Nope, just after it went into testing, I noticed I forgot to add another bug that this update fixes, so I edited the update and resubmitted it. Don't pay attention to this. I've just requested push to stable.
libass-0.9.7-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
libass-0.9.7-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
kwizart, how much do you need the updated libass in F-10? The libass update already went to stable, but the F-10 vlc build is still old enough to want the old libass, but I noticed you already synced cvs for 1.0.2. Should I unpush the update, or are you going to update vlc in F-10 soon? The gst-plugins-bad in F-10 is old enough to not be affected by this (it does not contain the assrender plugin).