Red Hat Bugzilla – Bug 495174
No russian/greek teletext decoding
Last modified: 2009-05-02 12:27:07 EDT
Description of problem:
Alevt, that is included with Fedora 8 (looks like it also applies to Fedora 9 and 10) doesn't support cyrillic and greek teletext decoding, meanwhile patch with such support was included with alevt since 1.6.1 (or even ealier). Another trouble is that doublefont patch that is included with fedora version of alevt is incompartible with alevt rus+greek patch. Even more - rus+greek patch reqired to run alevt with any koi8-r locale to display cyrillic teletext correctly.
My decision was to redone both patches (rus+greek and doublefont) to get things right. In attachments there are two patches: rus+greek and doublefont. They must be applied sequentially, rus+greek first and doublefont next.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install alevt.
2. Open tvtime, tune to any channel with cyrillic teletext available (f.e. ORT - Russian "First Channel")
3. Run alevt.
No cyrillic characters in decoded teletext.
Cyrillic teletext decoded correctly.
I also had sent e-mail with both patches to upstream (alevt author).
Created attachment 339053 [details]
Looks like gzipped patches are not welcome, will not re-submit attaches without compression.
Created attachment 339055 [details]
Alevt rus+greek patch.
Created attachment 339056 [details]
New alevt doublefont patch.
Thanks for the patches. I've built packages for F9 & F10 it should be tested.
I do not think I am able to test cyrillic teletext.
alevt-1.6.2-10.fc10 has been submitted as an update for Fedora 10.
alevt-1.6.2-9.fc9 has been submitted as an update for Fedora 9.
I still use Fedora 8 with KDE 3.x (don't like Gnome and KDE4), so it is hard for me to test built alevt packages for Fedora9/10. In any case I had downloaded alevt-1.6.2-9.fc9.src.rpm and build it on my Fedora 8 system using:
[lexa2@lexa2 Raid0]$ rpmbuild --rebuild --target i686 alevt-1.6.2-9.fc9.src.rpm
Result was successfull, and resulting alevt works almost perfect with russian teletext, but there is a bug with the display of russian letter "ы" with it. Almost the same package I had built with my patches using the original Fedora 8 version of alevt SRPM displays russian letter "ы" correctly. Now it's too late here in Moscow, time to go to bed have some sleep. Will try to investigate what went wrong and correct patches to resolve a bug.
Keep in touch.
Update: Fedora 9 package that were biult by you (http://kojipkgs.fedoraproject.org/packages/alevt/1.6.2/9.fc9/i386/alevt-1.6.2-9.fc9.i386.rpm) installs perfectly on Fedora 8 i386 system. The bug with the correct appearence of russian craracter "ы" is still in place, so more investigations reqired to resolve it. Hope, I'll able to do them tomorrow.
Quick check shows that you have done some modifications to the rus_greek patch, and it results is corruption inside it. The cause is that there are a lot of places in C code where non-utf8 characters are used instead of their numeric representation. Look at the fragment of diff of the rus+greep patch you placed inside SRPM and original version of it (firstly diff, then fed it to iconv):
[lexa2@lexa2 alevt-1.6.2.tst]$ diff -Nur alevt-1.6.2.rus+greek.patch alevt-1.6.2-rus-greek.patch | iconv -f koi8-r -t utf8
--- alevt-1.6.2.rus+greek.patch 2009-04-10 07:25:24.000000000 +0400
+++ alevt-1.6.2-rus-greek.patch 2009-04-10 17:35:00.000000000 +0400
@@ -240,7 +240,7 @@
+ c= *p;
+ if ( (c >= 0x40) && (c <= 0x7f)) *p=l2koi[(c & 0x7f) - 0x40];
-+ if (c=='&') *p='ы';
++ if (c=='&') *p='О©╫';
More lines follows
It is obvious that problems with russian letter 'ы' is caused by erratic correction of "*p='ы';" to "*p='О©╫';" that was applied to the patch somewhere along the way of your workflow with it. I think that it would be reasonable to rewrite the alevt code not to use characters assignments using direct character specification in single quotes. It is more adequate to replace all of such occurences of non-ASCII data with its numeric counterparts.
I can do the above work, but it will take me some time to do it. In the end I'll submit a new rus+greep patch, that would be immune to any 7bit<=>8bit<=>unicode patchfile corrections.
alevt-1.6.2-10.fc9 has been submitted as an update for Fedora 9.
Alexey I've rebuild packages with the correct patch version.
It seems bugzilla (or ultimately my browser) wrongly converted the encoding of the patch, resulting the above problems. I think it will work now.
No luck - patch in src.rpm for 1.6.2-10 is still wrecked up :-(.
I'm on the way of rewriting teletext charset conversion rotines of alevt to use only numeric comparisions and assignments. Hopefully, it'll be done today or tomorrow (depending on my workload over other projects). It is always better to have utf-8-safe patch anyway.
Can you send me the patch by mail (hopefully it will preserve right encoding).
I'm not rushing anything but there's little time available because of development freeze tomorrow. We can do utf-8 stuff later.
Ok, see your point. Mail is in transit already, check your mailbox.
alevt-1.6.2-11.fc9 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 alevt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3580
alevt-1.6.2-12.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 alevt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3622
F9 build works ok for me now. Pretty shure that F10 should be ok too.
alevt-1.6.2-11.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
alevt-1.6.2-12.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.