<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 04/19/2012 09:56 PM, Stephen Gallagher wrote: <blockquote cite="mid:1334887013.2968.18.camel@sgallagh520.sgallagh.bos.redhat.com" type="cite"> <pre wrap="">On Tue, 2012-04-17 at 20:10 +0200, Matthias Runge wrote: </pre> <blockquote type="cite"> <pre wrap="">On 17/04/12 19:43, Adam Young wrote: </pre> <blockquote type="cite"> <pre wrap="">While looking into EPEL support for Openstack, we came across the issue that EPEL ships with 1.2.7 and Openstack expects 1.3. Upon looking at <a class="moz-txt-link-freetext" href="https://docs.djangoproject.com/en/1.3/releases/1.3/#backwards-incompatible-changes-in-1-3">https://docs.djangoproject.com/en/1.3/releases/1.3/#backwards-incompatible-changes-in-1-3</a> I see that one of the major differences is protection against XSRF. This alone is sufficient reason to upgrade. Installing an RPM from the Sourceforge site worked well with Openstack, so it seems to fit our needs as well. Are there any objections to upgrading EPEL's version of Django To the latest? </pre> </blockquote> <pre wrap="">Umh, my fault. I'm planning to upgrade django for epel6 to version 1.3.x since two weeks now; sadly, real life kept me really busy. There have been some requests to upgrade to version 1.4 (to skip 1.3.x). I'm aware of at least one application, which would break, if we upgrade to django-1,4: reviewboard. So, I'd do an update to django-1.3.1 in the next few days. An additional reason to upgrade is, that django developers only support the two latest versions, so 1.2.7 is not actively maintained any more. </pre> </blockquote> <pre wrap=""> Yes, ReviewBoard currently cannot work with Django 1.4. This is a known issue and last I heard probably won't be fixed until ReviewBoard 1.7.0 (not yet in beta release). However, now that your 1.3.1 packages are in updates-testing, I have been able to package up ReviewBoard 1.6.5 which requires Django 1.3, so thanks for that. :) There are a lot of improvements in the 1.6.x series that I think people will like. <a class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/updates/django-evolution-0.6.7-1.el6,python-djblets-0.6.16-1.el6,RBTools-0.4.1-1.el6,ReviewBoard-1.6.5-2.el6">https://admin.fedoraproject.org/updates/django-evolution-0.6.7-1.el6,python-djblets-0.6.16-1.el6,RBTools-0.4.1-1.el6,ReviewBoard-1.6.5-2.el6</a> </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ epel-devel-list mailing list <a class="moz-txt-link-abbreviated" href="mailto:epel-devel-list@redhat.com">epel-devel-list@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/epel-devel-list">https://www.redhat.com/mailman/listinfo/epel-devel-list</a> </pre> </blockquote> One caveat. Any DJango app (Probably most Python wsgi apps, actually) is going to give an AVC Denial warning upon startup. DJango imports Python's UUID module which in turn imports ctypes. Ctypes does dynamic code generation, specifically by writing a file andd then trying to execute it, which, as you can imagine, is a pretty big security hole. Let the wsgi community know that, until we have that fixed, we should not attempt to get rid of the AVC denial warning message, but instead should push on the Python upstread to get a fix in. Yes, David Malcolm is aware of it. <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=814391">https://bugzilla.redhat.com/show_bug.cgi?id=814391</a> By not allowing this action, the UUID generation code becomes inactive, but DJango continues to function normally. For ReviewBoard, and most apps, this is acceptable. </body> </html>