Created attachment 346794 [details] Updated fribidi config+code for fribidi >= 0.19 note: after writing the patch, I've noticed the related bug #441847 Later I'll try to add there a pointer to this bug/patch. Description of problem: * Fribidi support enable correct display of RTL (right to left) languages (Hebrew, Arabic, Farsi). * Due to interface changes in fribidi (>= 0.19) it wasn't compiled into the Fedora binaries in the last year (I don't play it, so I didn't notice). * As a result, the game is cannot be used in RTL languages. Version-Release number of selected component (if applicable): Since fribidi >= 0.19 Steps to Reproduce: No need to understand Hebrew/Arabic/Farsi for this, just run: ldd /usr/bin/wesnoth It's evident that libfribidi isn't linked in. Additional info: Attached a patch that fix two files: - In configure.ac changed the test to use the modern pkg-config test, since fribidi does not ship fribidi-config anymore. - Fix src/font.cpp for the new fribidi API. Notes: - The patch is applied in the .spec as patch2 -- this is important since another patch in this spec file modifies configure.ac as well. This ordering should be considered when pushing it upstream. - The configure.ac patch should be safe for upstream, since pkg-config support in fribidi existed for quite some time before fribidi-config was dropped. I.e: it should not break other distributions using older fribidi (wasn't tested though). - The patch of src/fonts.cpp, would clearly break with older interfaces. This means it may have problem being included upstream as it would break other distros. Maybe we should ask fribidi maintainer for the recomended migration path.
Sheesh, it was filed against the wrong component (instead of wesnoth). Fixed, sorry.
Grumble. Committed and built for rawhide, but the build died due to some parted deps not having been rebuild yet for the new parted. Building for F-11 and F-10, will reattempt rawhide next week.
wesnoth-1.6.4-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/wesnoth-1.6.4-2.fc10
wesnoth-1.6.4-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/wesnoth-1.6.4-2.fc11
Tested on Fedora 11. Works.
Pushed upstream to trunk/ http://svn.gna.org/viewcvs/wesnoth/trunk/configure.ac?rev=36767&view=log Need to get some feedback from packagers in other distros before pushing it to 1.6.x or 1.4.x branches (they may carry legacy fribidi).
Is this really important enough to push another 1.6.4 immediately after the 1.6.4 went out? It seems these new versions come often.
It's a show-stopper for any Bidi language (Hebrew, Arabic, Farsi). On the other hand, it's been broken on Fedora since fribidi >= 0.19 (more than a year) and I only noticed it by coincidence when testing a translation sent to me by someone... Conclusions: * I'm not a gamer, so I won't hold my breath for it. * There aren't any Hebrew, Arabic or Farsi Fedora gamers... or * The Hebrew/Arabic/Farsi Fedora gamers prefers gaming in English ;-) A more serious issue is that wesnoth package has hard version+release dependency on the huge wesnoth-data. This is why we have to think at all whether the push is "worthwhile". Maybe it should only "Require: wesnoth-data = %{version}" so a minor release would not pull the whole wesnoth-data package? What does upstream think about engine/data upgrades?
I hate pushing frequent, huge releases as well, and I'd rather this had been filed against the right component at first so the initial 1.6.4 could have included it. I'd also have liked a unicorn and a car that runs on rainbows for my birthday. :) I agree that this sucks, but it's kind of a big deal bug, and WRT engine/data, it's been my understanding that they change together and really need to be updated together. Maybe we let it sit in testing, and push to stable if someone else requests it, or obsolete it when the inevitable 1.6.5 comes along. Workable?
> A more serious issue is that wesnoth package has hard version+release > dependency on the huge wesnoth-data. This is why we have to think at all > whether the push is "worthwhile". > Maybe it should only "Require: wesnoth-data = %{version}" so a minor > release would not pull the whole wesnoth-data package? What does > upstream think about engine/data upgrades? Good idea, we should Require only %{version} and nothing else. > Maybe we let it sit in testing, and push to stable if someone else requests it, > or obsolete it when the inevitable 1.6.5 comes along. Please no. Then both the updates and updates-testing package takes up space on mirrors. Ask upstream when 1.6.5 is coming? It has been broken for more than a year, and this fix was late by only a few days or it would have made the 1.6.4-1 build. Let's just wait?
(In reply to comment #10) > > A more serious issue is that wesnoth package has hard version+release > > dependency on the huge wesnoth-data. This is why we have to think at all > > whether the push is "worthwhile". > > Maybe it should only "Require: wesnoth-data = %{version}" so a minor > > release would not pull the whole wesnoth-data package? What does > > upstream think about engine/data upgrades? > > Good idea, we should Require only %{version} and nothing else. What would this help, since the -data package is a subpackage and gets rebuild each time? > > Maybe we let it sit in testing, and push to stable if someone else requests it, > > or obsolete it when the inevitable 1.6.5 comes along. > > Please no. Then both the updates and updates-testing package takes up space on > mirrors. Ask upstream when 1.6.5 is coming? > > It has been broken for more than a year, and this fix was late by only a few > days or it would have made the 1.6.4-1 build. Let's just wait? I've pulled the updated, and those who want it can get it from koji or wait until 1.6.5.