Bug#1016090: python-django breaks lots of autopkgtests
> > On Aug 1, 2022, at 12:33 PM, Chris Lamb wrote: > Hmpf, this is deeply unfortunate. I was working under the incorrect > belief that the 4.0.x series was now the LTS branch. A number of > things encouraged this interpretation, including that the 4.0.x and > 4.1.x were the release streams that were receiving security and > targeted bugfix releases, and this was happening as a relatively > consistent pair. (As in, not the 3.x stream.) To clarify: the LTS is always the third and final (X.2) release of a major version. So 3.2 is the current LTS; the next LTS will be 4.2, then 5.2, etc. At this stage in the cycle: * 4.1 receives full support for bugs of most levels of severity. * 4.0 receives only fixes for security and data-loss bugs, and will become unsupported once 4.2 is released, expected April 2023. * 3.2 LTS receives only fixes for security and data-loss bugs, and will become unsupported in April 2024, approximately 30 months after its initial release.
Bug#806182: Will fix python-django-registration RCs shortly (Was: Re: Request to join DPMT && python-django-registration)
Stephan Sürken wrote: > Let's see if I got this right: > > django-registration is actually no longer discontinued, and now lives at > > https://github.com/ubernostrum/django-registration > > The (incompatible) *-redux fork lives at > > https://github.com/macropin/django-registration Yes. django-registration upstream has been revived and the latest release of it (on PyPI as django-registration 2.0.3) is compatible with Django 1.7 and 1.8, on any Python version supported by those versions of Django. It also has a feature or two added. Probably within a week there will also be django-registration 2.1, compatible with Django 1.8 and 1.9 and some more new stuff in it. There is an upgrade guide in django-registration's documentation for coming from older versions of django-registration (0.8 or 1.0): https://django-registration.readthedocs.org/en/2.0.3/upgrade.html My advice, personally, would be to target the current master branch of django-registration (which will become the 2.1 release very soon). There's a bugfix related to Django making the email field optional, and a workaround for a performance bug in the 1.9 release of Django, both of which are probably worth having (and the one new feature coming in django-registration 2.1 -- checking usernames against a list of reserved names -- can be turned off if needed for compatibility).
Bug#806182: Will fix python-django-registration RCs shortly (Was: Re: Request to join DPMT && python-django-registration)
Stephan Sürken wrote: >> As for p-d-r in general: Has there been any discussion here already >> if/how to package 'p-d-r-redux' (which seems to be a (still maintained) >> fork)? > > As we now have #806182, I am hoping for some discussion/advice there how > to exactly handle this in the future (I have not looked into *-redux at > all yet). > > So the 1st question for me is whether it's really a drop-in replacement, > or if we might, at this point, create a new package *-redux (maybe with > the option to fix #567739, too). -redux is not a drop-in replacement. However, upstream django-registration is 1.8 compatible as of the current release on PyPI, and is about to gain a 1.9-compatible release as well. So please make sure to check on what's happening in upstream before you duplicate the work already done there: https://github.com/ubernostrum/django-registration
Bug#806182: Upstream discontinued, replace with -redux
Actually, upstream is here: https://github.com/ubernostrum/django-registration martin f krafft wrote: > Package: python-django-registration > Version: 1.0+dfsg-2 > Severity: important > > This project has been discontinued: > > https://bitbucket.org/ubernostrum/django-registration/wiki/Home > > please switch to https://github.com/macropin/django-registration > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > >
Bug#797208: Does not work with django 1.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 FYI: a new (1.7, 1.8 and 1.9-compatible) release from upstream is likely to occur on Thursday 19 November :) Chris Lamb wrote: > severity 797208 serious thanks > > Hi, > >> Does not work with django 1.8 > > This is actually causing a FTBFS in sid (in the testsuite), hence > raising severity. For example: > > https://reproducible.debian.net/rbuild/unstable/amd64/python-django-registration_1.0+dfsg-2.rbuild.log > > > > Regards, > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJWRpmfAAoJEC2SZqaAj+BnaAwQAJGeWRgOROmCqLYsv69QCuj2 ihShFxzlPqS+aqnFHeYSxRlFbPtLPdSrSgIoZV6zmUN8NeHgdW4welBs78Yz5Tna 2txXJkEAhcroauKcboO6Yz3SDlnJwtoQULiKwKGQ7fLe9yKCV2dg0dRqvr5hG4bS fRaHRSCjYVim+gWZBGR6Wvrg7cVn+TLnaqb53GtxAt5DqQ5bx+lscQ6KgRsVBj9T 32iQY8SkEboeoBEvZWaTKgDR8DRdEvuIXpv/QzNtICkGhoImaQegwuKrOPQY+s4v ZxdPIMjrzd6GqFh0nKrA47OrzpnTtYh0EbBiaWVjUwKBkfxtA1YGYBn7iK3JedB9 3XcDo7R+P/nu8WoLIkHJrJuMfp03n1s/Q62tRPT5T47P+jWVaM26Y4IyaxAcrkGv pfBpkz2CjZasnQFj5HiDJt1M5lB2w5EIdBP1sbjOE++v04z6KeHaIc+Tdyt0cEn4 ileFNRSyv2yzMdY2dOcQCN77OgfYvqwlUP81pMFPwGa2mJpD5YDxbGQp1B6A3Es6 0WaobffzIfPTtcWPJiHWGnx/Kbhrd8KE5eVLcVSN4Zz3MgbSz2WmfYpTlakCQ5D2 lky2ZhpD5+ask5QrDAP/H4447kQH9ykna4UZHNkDswit3hQdDGdzEBhFi1L8QkzY 9MMkn8yyhOg8E0H/Nyyr =hJhZ -END PGP SIGNATURE-
Bug#683364: New release coming
As a heads-up: a bug affecting Python 2.4 compatibility was found in the 1.3.2 package, and we will be issuing a 1.3.3 release based on that. The relevant commit is visible here: https://github.com/django/django/commit/d0d5dc6cd76f01c8a71b677357ad2f702cb54416 And the 1.3.3 release will likely occur within 24 hours. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641405: several Django security issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raphael Hertzog wrote: The last 2 release (besides the current one) are security maintained, aka 1.1 and 1.2. Since 1.1 has not seen any update, it means it's not affected and thus 1.0 isn't as well. But we can verify this. I'm ccing James Bennett, the Django release manager. Can you confirm what I said, James? I have a subscription that already gets me on these bugs :) Anyway, our policy is that the most recent release (1.3) gets both security and general bug fixes, while the release prior to it (1.2) gets only security. We don't support anything older than that. That means we no longer support 1.1 or earlier versions in any official way. I'm quite certain that at least some of the security issues (especially the URLField problems) are present in 1.1. - -- James Bennett ja...@b-list.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk53AKIACgkQNoTAwIyLKuFtxACgnI8klzgYF/4xs15na09CabT/ p4MAn2AD4shy3d64vAH60XE66nBbRpYC =xCFW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555419: python-django: embedded copies of Python modules: doctest, decimal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FWIW upstream does not consider this a bug; we bundle these and a couple other modules for compatibility with Python versions/environments which lack them, and will continue to do so until Django no longer supports those Python versions/environments. - -- James Bennett ja...@b-list.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr43o4ACgkQNoTAwIyLKuHlywCgk7/40J6kSVNsZesW4Qor5pwh 1/sAoICZBWg6dBmW//EkYsBIkMiBQEcl =OkUe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527492: python-django: FTBFS: Could not import extension djangodocs
On May 7, 2009, at 4:48 PM, Daniel Schepler wrote: Could not import extension djangodocs (exception: No module named htmlwriter) This is a compatibility issue across different versions of Sphinx, and is already open upstream with us as #10539: http://code.djangoproject.com/ticket/10539 -- James Bennett ja...@b-list.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505783: New upstream version available
Excerpts from Chris Lamb's message of Sun Nov 16 14:12:25 -0600 2008: Ah, thanks for that. My recommendation for kinda-botched releases like this would be to increment the least-significant bit and release again. However, you seemed to have caught it early. That particular case didn't really warrant it, since no files in Django changed and it was just a matter of retrieving the copy of the package the checksums were generated from. But speaking of version bumps... one of our developers noted that the packaging process for 1.0.1 omitted a directory needed by django.contrib.gis, and so we *are* going to bump to 1.0.2 and re-roll, with a package due on Tuesday: http://groups.google.com/group/django-developers/msg/b32f923a257c0ee4 -- James Bennett [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481164: Bad tarball for Django 0.96.2
Raphael Hertzog wrote: I wanted to prepare an upload of the Django 0.96.2 to Debian unstable but the package doesn't build without modifications because the new tarball lacks quite a few files compared to the previous 0.96.1 tarball. Hrm. Looks like the setup.py script on 0.96 doesn't pull that stuff in. I can't really go back and tweak that for something that isn't really a security fix, but an svn export from the 0.96-bugfixes branch in the Django repo should get you want you want, after which it's easy enough to make the tarball manually. -- James Bennett [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450913: bash completion script breaks normal file completion
On Feb 25, 2008, at 5:16 AM, Raphael Hertzog wrote: Brett? Can you forward it upstream and prepare an upload? Soeren beat me to it; it's been opened with Django as ticket 6661[1] and I've tested the patch and flagged it for a Django committer to check in. [1] http://code.djangoproject.com/ticket/6661 -- James Bennett [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450913: bash completion script breaks normal file completion
This has been fixed upstream in Django trunk, as changeset 7156[1]. [1] http://code.djangoproject.com/changeset/7156 -- James Bennett [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436983: python-django: pydoc django.db blows up
On Aug 10, 2007, at 12:22 PM, Mark Eichin wrote: As long as it stays open as a bug, that's fine; I suspect there *is* a way to work around it on the django side (for example, can it tell that pydoc is importing it?) or else there needs to be a way to fix it from the pydoc side... Just a heads-up: upstream in Django changeset 6832 [1] we've changed the behavior from raising EnvironmentError to raising ImportError, which pydoc will happily smother as part of walking a tree of modules. You'll still need to have DJANGO_SETTINGS_MODULE set (or manually configure settings) in order to *use* Django, but I believe this deals with the cases where we inadvertently made pydoc explode. [1] http://code.djangoproject.com/changeset/6832 -- James Bennett [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436983: python-django: pydoc django.db blows up
Brett Parker wrote: Hmmm. Yes, it's central, but a lot of the rest of it works with pydoc - I can see why this particular use case doesn't, but I'll take a looksee tomorrow incase there is an easy solution (I don't think there is, I think Raphael is spot on...) There isn't really an easy solution, and from what I understand we're making a conscious trade-off; various bits of Django need to access settings in order to bootstrap themselves, and we go through a lot of contortions to put off the need to do so as long as humanly possible (lots of things initially exist only in potentia, as proxy objects or as lazy containers), but sooner or later the settings have to be there or various bits just don't work. This throws a monkey wrench into any attempt at automated analysis of the code. There is a manual hook -- django.conf.LazySettings.configure() -- which can supply default/dummy values or accept manually-specified values so that bits of Django can be used standalone, but writing a wrapper which would call that before handing off to pydoc would be just as hackish as trying to detect pydoc as the importing module (and would probably also be quite fragile). Also: upstream, we have a history of leaning WONTFIX on tickets having to do with automated API documentation generators. One of our co-BDFLs has eloquently expressed the opinion that automatic API docs a la pydoc/epydoc are a poor excuse for not having real documentation ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407521: Security fix for Django auth system
Package: python-django Version: 0.95-2 A bug in Django's AuthenticationMiddleware was discovered and patched after the 0.95 release; this bug can cause apparent caching of the value of request.user between requests, possibly resulting in inappropriate access when a user is perceived to be logged in as someone else. This was fixed in revision 3754 of Django trunk[1], and that changeset applies cleanly to stock Django 0.95. [1] http://code.djangoproject.com/changeset/3754 -- James Bennett [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407519: Security fix for Django i18n system
Package: python-django Version: 0.95-2 A vulnerability in the script used by Django to compile message files for use by its internationalization system was discovered and fixed after the 0.95 release; the compile-messages script was not escaping the names of files it handled, which meant that arbitrary commands could be executed as a result of maliciously-named .po files. This was fixed in revision 3592 of Django trunk[1], and that changeset applies cleanly to stock Django 0.95. http://code.djangoproject.com/changeset/3592 -- James Bennett [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407607: Minor fix for Django FastCGI handling
package: python-django version: 0.95-2 A minor problem was discovered with Django's use of flup for FastCGI handling after the 0.95 release; flup was allowed to run in 'debug' mode and show full tracebacks on uncaught exceptions, which could expose the contents of application code or settings. This was fixed in revision 4170 of Django trunk, and a patch which applies cleanly to stock Django 0.95 is in Django's 0.95-bugfixes branch (which tracks post-release updates and fixes for the 0.95 release): http://code.djangoproject.com/changeset/4363 -- James Bennett [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
