[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#770779: marked as done (unblock: django-guardian/1.2.4+git20141124-0.1 (pre-approval))

Your message dated Tue, 9 Dec 2014 12:33:41 +0100
with message-id <20141209113341.GA3512@ugent.be>
and subject line Re: Bug#770779: unblock: python-django-guardian/1.2.4-2
has caused the Debian Bug report #770779,
regarding unblock: django-guardian/1.2.4+git20141124-0.1 (pre-approval)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
770779: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770779
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock

python-django-guardian was RC bug #763222. I believe this is a just a
technical bug in the tests, the actual package should work fine.
However, it means the package won't build.

This in turn has introduced an RC bug in djangorestframework #769216,
and other packages that depend on djangorestframework are scheduled for
removal from testing.

What would be considered an acceptable fix?

I could recommend:

* Just disabling the tests.

  Pros: easy patch.
  Con: potentially risky.

* Continue hacking on the tests until they work.
  I imagine this will mean:
  mv guardian/testapp/migrations guardian/testapp/south_migrations
  build new migrations in guardian/testapp

  Pros: We fix the problem and keep the tests.
  Cons: 1. While the process of generating the patch is going to be simple,
  the actual patch itself is going to be extensive, because of the
  requirement to move the exiting migration directory. 2. We start
  diverging more and more from upstream code.

* Use the upstream git code.

  While there are some bugs that we would have to patch, the total patch
  set would be a lot simpler this way. e.g. the following bugs are open
  upstream:

  https://github.com/lukaszb/django-guardian/issues/284
  https://github.com/lukaszb/django-guardian/issues/254

  Pros: I believe many problems we have hacked/patched in the Debian
  version are already fixed upstream, and if we stop diverging so much
  from upstream, it will make future updates (including security
  updates) much easier.
  Cons: We diverge from the current Debian version.

I don't have a solution just yet, however just trying to solicit
feedback if any of the above solutions would be considered acceptable
for the release team.

My favoured solution is the last one, because it is going to result in
the simplest package, with minimal differences from upstream.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE= (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

--- End Message ---
--- Begin Message --- 
Hi,

On Tue, Dec 09, 2014 at 11:20:06AM +1100, Brian May wrote:
> Ok, it has now been accepted.

Unblocked.

Can you make sure you close the bug in the rdeps once django-guardian migrates
to testing (but not before). You can add a note to the bug now that it should
be fixed once the new version migrates (and mark the bug pending).

Cheers,

Ivo

--- End Message ---
Reply to: