See bug #663103 for more info. Copied from there:
> Explaination of the problem in detail:
> The new version of Genshi tries to everything "compressable" (e.g. <script
> ...></script>) turn into self-closed tags (i.e. <script ... />). Because luci
> is by default served with "text/html" content type, internally another parser
> is used (than in "application/xhtml+xml" case), which causes denying the
> self-closed "script" tags.
Is this issue happening in EPEL6?
python-genshi06 is a compatibility package for EPEL6 only. It doesn't exist in any other branches.
Perhaps you meant this to be against python-genshi in rawhide (which happens to be the 0.6 version)?
Sorry -- didn't realize that. I've moved the component.
Is anyone working with Luci or Genshi upstreams to solve this and release an update? I'm extremely hesitant to add a patch to the Genshi package to fix bugs which are arguably due to browser bugs/incompatibilities.
We're currently working around the problem in luci. We haven't talked with genshi upstream.
Re comment #3:
I agree that this is not necessarily a bug and if, it might be due to
incomplete configuration of Genshi middleware on TurboGears2 side (this
could be solved in newer version of TG2 than is packaged, which might
take this new version of Genshi into account).
We now serve luci with "application/xhtml+xml" content type to web browsers
that declare to know this type, which solves the situation for Firefox.
This is rather a "proper solution" then a "workaround" (according to
W3C specifications/recommendations). MSIE still has to be tested but
I guess there will be a path to get it rendering the pages as well
as with other browsers if it doesn't apply now (cannot check this myself
natively and not sure about new versions of MSIE under Wine).
So I would say that the "bug" status of this depends more on other users
of Genshi, whether they see a bug in the mentioned little change in
behaviour compared to its older versions. Frankly, I didn't dig into
depth to be able to tell any authoritative statement here.
(In reply to comment #5)
> Re comment #3:
> I agree that this is not necessarily a bug and if, it might be due to
> incomplete configuration of Genshi middleware on TurboGears2 side (this
> could be solved in newer version of TG2 than is packaged, which might
> take this new version of Genshi into account).
This is indeed the case: I've just run into this same problem (with <textarea>, not <script>) and found that version 2.1.1 which came out lately fixes this, see http://codersbuffet.blogspot.com/2011/06/announcement-turbogears-211-released.html for details. Note that this needs a new version of python-webob (needs 1.0.7 but 1.0.8 came out lately) and I think keeping tg2devtools in sync would be good as well which might have other updated version requirements.
I can update these packages in Rawhide, but the question remains what we'll do for F-15 -- update as well or backport the fix?
F15 has TG2-2.1.
F14 has a TG-2.1 rc.
I think updating F15, at least, makes sense.
As discussed on IRC, I'll update tg2 to 2.1.1 and python-webob to 1.0.8.
TurboGears2-2.1.1-1.fc15,python-webob-1.0.8-1.fc15 has been submitted as an update for Fedora 15.
TurboGears2-2.1.1-1.fc16,python-webob-1.0.8-1.fc16 has been submitted as an update for Fedora 16.
Package TurboGears2-2.1.1-1.fc15, python-webob-1.0.8-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing TurboGears2-2.1.1-1.fc15 python-webob-1.0.8-1.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
TurboGears2-2.1.1-1.fc16, python-webob-1.0.8-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
TurboGears2-2.1.1-1.fc15, python-webob-1.0.8-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.