Re: Two django packages for Debian?

[Barry Warsaw]

On Aug 19, 2014, at 11:14 AM, Barry Warsaw wrote:

>I usually don't care much about preserving local intra-upload vcs history

Ah, except for the case where I want to collaborate with someone on the new
version, e.g. to get a code review of some packaging change *before* it gets
uploaded.  This is especially true for team members who don't have upload
rights.  I think it would be great if they could push their proposed packaging
changes, which I could fetch, review, edit, push, merge, and upload.  It would
be nice to be able to capture a conversation between developers, e.g. as in a
github pull request[*].

-Barry

[*] No, I don't suggest using github; it's not free software.


signature.asc
Description: PGP signature

Re: Two django packages for Debian?

[Sandro Tosi]

> If it were well integrated with quilt, I think it would be fine to have
> source-full branches.  I like this aspect of UDD, but I've also become
> comfortable working with our svn debian-only branches.  It usually means
> unpacking the tarball, cd'ing into that directory and symlinking in debian/ to
> work with the patch stack.

you might want to try svn-do

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cab4xwxw8rx20ad42wjtnvjeojrdqc44chpsqrduroj+j5wc...@mail.gmail.com

Re: Two django packages for Debian?

[Barry Warsaw]

On Aug 09, 2014, at 06:02 PM, Brian May wrote:

>At the moment, in subversion, we only store the debian/* directory. Is
>there any requirement/benefit in putting the full upstream source in git
>too?

If it were well integrated with quilt, I think it would be fine to have
source-full branches.  I like this aspect of UDD, but I've also become
comfortable working with our svn debian-only branches.  It usually means
unpacking the tarball, cd'ing into that directory and symlinking in debian/ to
work with the patch stack.

It's a bit jarring though, since I have to go back to the svn branch directory
to build the packages (source or binary), so I'm always flipping between the
two directories.

The other thing that *has* to work flawlessly for source-full checkouts is
importing new upstream versions.  If you do this naively in a UDD branch,
you're screwed.  `bzr merge-upstream` is the trick to make this work, since it
updates the upstream source to match the tarball.  I think this step should
re-apply the quilt stack automatically, but of course scream loudly if it gets
to a patch that is out of date.

I guess I can summarize this as comfort != joy.  :)

-Barry


signature.asc
Description: PGP signature

Re: Two django packages for Debian?

[Barry Warsaw]

On Aug 06, 2014, at 04:08 PM, Piotr Ożarowski wrote:

>and I would love to try them all before we make a decision¹

Me too.

Should we relax the team preference for one vcs to rule them all, at least for
a period of experimentation and experience sharing?   I still *really* want to
end up in a place where team packages use one vcs and one common workflow, but
it may be time to allow for some non-svn managed packages.

If we did, I would pick one or two of the ones I touch and experiment with
some of the git packaging tools.

(I suspect this may be a big topic for us at DC14 :).

-Barry


signature.asc
Description: PGP signature

Re: Two django packages for Debian?

[Barry Warsaw]

On Aug 06, 2014, at 02:28 PM, Dimitri John Ledkov wrote:

>I am on the edge. I prefer dgit, as it's the only one the guarantees
>round-trip save with the archive even when someone NMUs things without using
>dgit.

From this description, it sounds like dgit is the closest equivalent to Ubuntu
Distributed Development (UDD) branches, which of course I am a big fan of[*].
Even with today's svn-based workflow, it bothers me that a packaging branch
and the archive might not agree about the state of a package.  I've seen this
a few times IRL, and it's always a mess to unwind because usually one is not a
superset of the other.  It's no fun to merge.

>However, it does not integrate with git-dpm at the moment and there is
>no clear conversion / vcs history import available. Do we care about
>preserving vcs history for our packages? Do we want synthetic history
>(e.g. per upload granularity)?

I usually don't care much about preserving local intra-upload vcs history, and
think that it's fine to have per-upload granularity in the public package
repo.  Yes, I'll use lots of intermediate commits locally until I'm happy that
the next version of the package is ready to upload, but those can be safely
rebased away on upload.

(Ironically, this is opposite of my preferences when doing upstream
development.  In those cases, I want the intermediate commits to be preserved,
but in a bzr-style mainline approach, where they're generally hidden to log
and bisect commands.  In git parlance I think that's --first-parent by
default, which doesn't seem to be what git fans use or expect.)

We've had debates in UDD circles about whether it's okay to push UDD branches
or let the package importer do that step.  I personally prefer the latter
because it's safer - i.e. if the importer updates the branch on package
upload, then there's less chance that the UDD branch breaks.  But that's a
superstition.  From reading the manpage, it sounds like `dgit push` is ideal -
it does the upload and pushes the branch so that collaborators would have
immediate access to the new version without the need for an importer run.

I just tried `dgit clone tox` since that's a package I intend on working on
today.  It's nice that I got a quilt-pushed source checkout; it means I can
start hacking right away.  I was dismayed though that there doesn't seem to be
any upload history.  There's only one commit and it's the last upload.  There
are no tags.  I want the upload history to be reflected in the commit log and
tags.  Is there a way to synthesize the entire upload history with dgit?

Also, reading the dgit manpage it seems like `3.0 (quilt)` integration isn't
entirely smooth.  I like working with quilt, but would also like better vcs
integration.  In my limited experience git-dpm seemed the nicest here.

Cheers,
-Barry

[*] In the parallel universe where import failures never occur, bzr is
blindingly fast, and bzr won the war. ;)


signature.asc
Description: PGP signature

Re: Two django packages for Debian?

[Thomas Goirand]

On 08/06/2014 10:08 PM, Piotr Ożarowski wrote:
>> I am on the edge. I prefer dgit
> 
> and I would love to try them all before we make a decision¹
> 
> If one wants us to consider XYZ, please send a link to test repo and a
> list of commands that will let us deal f.e. with such problems:
> 
> * how can I fetch foo sources?

IMO, it should be contained in the Git repository.

With the workflow I'm using, it's already on your local repo after you
do "debcheckout", since it's contained in the tag (though it's not
suitable for an upload because "xz" doesn't produce the same output
twice, so your orig.tar.xz may be different from what's already in the
Debian archive).

With pristine-tar, no need to explain, it's there.

> * what about updating all packages in one command?
>   (XYZ pull? mr update?)

mr sounds like the correct tool. Anyway, in about 2 years, the only
archive-wide commit that I saw was about the VCS fields, which I think
isn't so important. Do you have other examples of team-wide commits that
have occurred?

> * how can I build it?
>   (is debuild/sbuild enough or do I need to use XYZ-buildpackage/whatever?)

git-buildpackage is the natural tool, IMO.

> * old patch needs an update, what should I do?
>   (quilt edit? quilt refresh? XYZ rebase on a different branch?)

Do whatever is needed to edit the patch in debian/patches. What's the
issue exactly?

> * there's new upstream release, how can I import it?
>   (uscan in source pkg's root dir?)

What I do:
./debian/rules fetch-upstream-remote
git merge -X theirs 

That's in the case of upstream using Git (which, these days, is maybe
95% of the packages I maintain). Otherwise, use git-import-orig and
pristine-tar...

> * new patch is needed, how can I add it?
>   (quilt new? another branch?)

Same as above. Do whatever you feel right to edit stuff in
debian/patches, and git push the result.

> * how can I share my changes?
>   (XYZ push?)

Is there any other way than "git push"?

> etc. (i.e. describe workflow)

My workflow is described here:
http://openstack.alioth.debian.org/

> I don't ask anyone to convert the whole repo, I ask to provide one/few
> packages for tests. If someone knows dgit, git-dpm, git-buildpackage,
> hg-buildpackage then (s)he probably already have at least one package
> that uses it, no? Just copy it to dpmt's git/hg/bar² repo and let others
> play with it.

I would need to learn dgit and git-dpm. Pointers to howto welcome!

> [¹] note that, unless someone will provide a wrapper that unifies it all,
> there will be no 2 or more VCSs/tools at the same time

Like it or not, this has already happened (with people using
collab-maint for example).

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee426f.7020...@debian.org

Re: Two django packages for Debian?

[Raphael Hertzog]

On Wed, 13 Aug 2014, Piotr Ożarowski wrote:
> [Raphael Hertzog, 2014-08-13]
> > > * old patch needs an update, what should I do?
> > >   (quilt edit? quilt refresh? XYZ rebase on a different branch?)
> > > * new patch is needed, how can I add it?
> > >   (quilt new? another branch?)
> > 
> > I don't see the need for the team to impose anything here. patches are
> > stored in quilt format, people can use "quilt" or "git-dpm" or "gbp-pq".
> 
> that's the problem. I'm lazy and I rather stop helping / sponsoring than
> learn 650 ways to add a patch.

You don't have to learn multiple ways to add a patch. You pick your
preferred tool and you use it. Others use their preferred tool and
everybody is happy since the exchange format (quilt series stored in
debian/patches) is well defined.

git-dpm and gbp-pq uses local branches that don't get pushed to update
the patch series but the result is a simple update of debian/patches in
whatever branch we store the Debian packaging.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140814154758.ga2...@x230-buxy.home.ouaza.com

Re: Two django packages for Debian?

[Ben Finney]

Raphael Hertzog  writes:

> So let me give my own answer to some of the questions asked here.

These questions would best be answered in a ‘debian/README.source’
document giving all the information needed to work with the Debian
source for the package.

-- 
 \   “You can be a victor without having victims.” —Harriet Woods, |
  `\ 1927–2007 |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85r40k6i54@benfinney.id.au

Re: Two django packages for Debian?

[Piotr Ożarowski]

[Raphael Hertzog, 2014-08-13]
> > * old patch needs an update, what should I do?
> >   (quilt edit? quilt refresh? XYZ rebase on a different branch?)
> > * new patch is needed, how can I add it?
> >   (quilt new? another branch?)
> 
> I don't see the need for the team to impose anything here. patches are
> stored in quilt format, people can use "quilt" or "git-dpm" or "gbp-pq".

that's the problem. I'm lazy and I rather stop helping / sponsoring than
learn 650 ways to add a patch.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


signature.asc
Description: Digital signature

Re: Two django packages for Debian?

[Raphael Hertzog]

So let me give my own answer to some of the questions asked here.

On Wed, 06 Aug 2014, Dimitri John Ledkov wrote:
> However, it does not integrate with git-dpm at the moment and there is
> no clear conversion / vcs history import available. Do we care about
> preserving vcs history for our packages? Do we want synthetic history
> (e.g. per upload granularity)?

I believe it's useful to have some history, at least on a per-upload
basis (and it's relatively easy to do do with git-import-dscs + debsnap).

On Wed, 06 Aug 2014, Piotr Ożarowski wrote:
> If one wants us to consider XYZ, please send a link to test repo and a
> list of commands that will let us deal f.e. with such problems:

Feel free to use "debcheckout python-django" as a test bed (just don't
"git push" your tests).

> * how can I fetch foo sources? what about updating all packages in one 
> command?
>   (XYZ pull? mr update?)

"git clone"

For the multiple repositories, yes it's "mr" that most teams use.

> * how can I build it?
>   (is debuild/sbuild enough or do I need to use XYZ-buildpackage/whatever?)

I do use "git-buildpackage" but it's really not a requirement. debbuild
should be usable on a git clone.

> * old patch needs an update, what should I do?
>   (quilt edit? quilt refresh? XYZ rebase on a different branch?)
> * new patch is needed, how can I add it?
>   (quilt new? another branch?)

I don't see the need for the team to impose anything here. patches are
stored in quilt format, people can use "quilt" or "git-dpm" or "gbp-pq".

> * there's new upstream release, how can I import it?
>   (uscan in source pkg's root dir?)

git-import-orig --pristine-tar --uscan

> * how can I share my changes?
>   (XYZ push?)

git push origin :
git push origin --tags

On Sat, 09 Aug 2014, Brian May wrote:
> At the moment, in subversion, we only store the debian/* directory. Is
> there any requirement/benefit in putting the full upstream source in git
> too?

Not putting the upstream sources would be non-sense. We want to be able to
use the git tools to maintain the quilt series and for this we need the
sources in git. It also makes it possible to use standard tools like
debuild instead of needing some pre-build setup logic to extract the
upstream sources and inject the debian directory.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140813190835.ga18...@x230-buxy.home.ouaza.com

Re: Two django packages for Debian?

[Brian May]

On 7 August 2014 00:08, Piotr Ożarowski  wrote:

> > I am on the edge. I prefer dgit
>
> and I would love to try them all before we make a decisionน
>

Would be interested in a brief summary of the different workflows possible,
and a comparison. I have not been keeping up.

At the moment, in subversion, we only store the debian/* directory. Is
there any requirement/benefit in putting the full upstream source in git
too?
-- 
Brian May 

Re: Two django packages for Debian?

[Raphael Hertzog]

Hi Matthew,

On Wed, 06 Aug 2014, Matthew Vernon wrote:
> Is 1.7 released yet? At least Grappelli only aims to work with released
> versions, so I think it's currently only 1.6-compatible. I'd expect
> 1.7-support to be along once that's been out for a bit.

1.7 will be out in a few days/weeks and we aim to include it in Debian
Jessie. We have opened bugs against all reverse dependencies asking them
to validate their package with Django 1.7rc2 in experimental.

See https://lists.debian.org/debian-python/2014/07/msg00085.html

So please ensure they work with Django 1.7 before upload, or file a bug
yourself and user tag them so that they appear in:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django17

Thank you!
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140806192529.gb13...@x230-buxy.home.ouaza.com

Re: Two django packages for Debian?

[Matthew Vernon]

Hi,

On 06/08/14 07:47, Raphael Hertzog wrote:
> Hi,
> 
> On Tue, 05 Aug 2014, Matthew Vernon wrote:
>> https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git
>> https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git
> [...]
>> Naturally, I'd like to upload these as maintained by
>> python-modules-t...@lists.alioth.debian.org. Is that going to be OK? If
>> so, I'll make some ITPs, and initial uploads.
> 
> I would feel uncomfortable having the name of the team on it while the package
> is not on a repository writable by all members.

Oh, sure. It seemed a bit presumptive to stick a repo into
git.debian.org without asking first was all :-)

> Looking on git.debian.org, it looks like that some people started using
> git for team maintained packages:
>
> So please move your git repository there.

Will do.

> /me notes to switch python-django to git.

:-)

Regards,

Matthew


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e24d3f.4010...@debian.org

Re: Two django packages for Debian?

[Matthew Vernon]

On 06/08/14 04:25, Brian May wrote:
> On 6 August 2014 03:11, Matthew Vernon  > wrote:
> 
> I've packaged up django-grappelli and django-stronghold (since we have
> need for them at work). I think my debianisations are sane, but I've
> done them in git not subversion. Repos:
> 
> 
> Please make sure these work with Django 1.7 in experimental...

Is 1.7 released yet? At least Grappelli only aims to work with released
versions, so I think it's currently only 1.6-compatible. I'd expect
1.7-support to be along once that's been out for a bit.

Regards,

Matthew


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e24cd3.20...@debian.org

Re: Two django packages for Debian?

[Piotr Ożarowski]

> I am on the edge. I prefer dgit

and I would love to try them all before we make a decision¹

If one wants us to consider XYZ, please send a link to test repo and a
list of commands that will let us deal f.e. with such problems:

* how can I fetch foo sources? what about updating all packages in one command?
  (XYZ pull? mr update?)
* how can I build it?
  (is debuild/sbuild enough or do I need to use XYZ-buildpackage/whatever?)
* old patch needs an update, what should I do?
  (quilt edit? quilt refresh? XYZ rebase on a different branch?)
* there's new upstream release, how can I import it?
  (uscan in source pkg's root dir?)
* new patch is needed, how can I add it?
  (quilt new? another branch?)
* how can I share my changes?
  (XYZ push?)
etc. (i.e. describe workflow)

I don't ask anyone to convert the whole repo, I ask to provide one/few
packages for tests. If someone knows dgit, git-dpm, git-buildpackage,
hg-buildpackage then (s)he probably already have at least one package
that uses it, no? Just copy it to dpmt's git/hg/bar² repo and let others
play with it.

[¹] note that, unless someone will provide a wrapper that unifies it all,
there will be no 2 or more VCSs/tools at the same time
[²] if it's not enabled for DPMT and you want to provide examples,
please ping me to enable it on alioth for you


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140806140833.gc4...@sts0.p1otr.com

Re: Two django packages for Debian?

[Dimitri John Ledkov]

On 6 August 2014 14:18, Barry Warsaw  wrote:
> On Aug 06, 2014, at 08:47 AM, Raphael Hertzog wrote:
>
>>(That said I'm also rather annoyed by the fact that the team hasn't switched
>>to git yet.)
>
> We've had these discussions on this mailing list before, but I think we should
> discuss it at Debconf.  While obviously we won't have full representation
> (whatever that means ;) from team members, we should take advantage of the
> high bandwidth setting to discuss the future vcs for the Python teams.
>
> In the past we've all had the important and worthy goal of using a consistent
> packaging and workflow for team maintained projects.  However, if folks are
> abandoning the team in order to use git, then we already have fragmentation,
> and it will only increase.  I'm not particularly a git fan, but it's clear
> where this is heading. :)
>
> I don't think the question is if, but when and how.  There are at least two
> git-based packaging tools and workflows: gbp and git-dpm.  In my limited
> exposure, I've had problems with the former but have been pretty happy with
> the latter.  There's also this interesting thread:
>

I am on the edge. I prefer dgit, as it's the only one the guarantees
round-trip save with the archive even when someone NMUs things without
using dgit.
However, it does not integrate with git-dpm at the moment and there is
no clear conversion / vcs history import available. Do we care about
preserving vcs history for our packages? Do we want synthetic history
(e.g. per upload granularity)?

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANBHLUia+dHSdA_-T5wAy_=z1r-m1btwcdjer4bkykdh4hh...@mail.gmail.com

Re: Two django packages for Debian?

[Barry Warsaw]

On Aug 06, 2014, at 08:47 AM, Raphael Hertzog wrote:

>(That said I'm also rather annoyed by the fact that the team hasn't switched
>to git yet.)

We've had these discussions on this mailing list before, but I think we should
discuss it at Debconf.  While obviously we won't have full representation
(whatever that means ;) from team members, we should take advantage of the
high bandwidth setting to discuss the future vcs for the Python teams.

In the past we've all had the important and worthy goal of using a consistent
packaging and workflow for team maintained projects.  However, if folks are
abandoning the team in order to use git, then we already have fragmentation,
and it will only increase.  I'm not particularly a git fan, but it's clear
where this is heading. :)

I don't think the question is if, but when and how.  There are at least two
git-based packaging tools and workflows: gbp and git-dpm.  In my limited
exposure, I've had problems with the former but have been pretty happy with
the latter.  There's also this interesting thread:

https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038418.html

What I really want to avoid is having to think about which vcs or workflow
team packages have adopted.  I really value the ability to use the same tool
(svn-buildpackage) and workflow for all team packages.  It makes it easy to do
drive-by fixes and updates.  I'm happy to adopt something else, but I don't
want to adopt 5, 10, or M number of something elses. ;)

We need a plan for transition, documentation for team members, and volunteers
to see it through.  I am offering to help.  I hope the intersection of Debian,
Python, and git fans will come to Debconf and help us lay the groundwork for a
successful team-wide transition.

Cheers,
-Barry


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140806091809.5c942...@anarchist.wooz.org

Re: Two django packages for Debian?

[Raphael Hertzog]

Hi,

On Tue, 05 Aug 2014, Matthew Vernon wrote:
> https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git
> https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git
[...]
> Naturally, I'd like to upload these as maintained by
> python-modules-t...@lists.alioth.debian.org. Is that going to be OK? If
> so, I'll make some ITPs, and initial uploads.

I would feel uncomfortable having the name of the team on it while the package
is not on a repository writable by all members.

(That said I'm also rather annoyed by the fact that the team hasn't switched
to git yet.)

Looking on git.debian.org, it looks like that some people started using
git for team maintained packages:

$ ls -al /git/python-modules/packages/
total 48
drwxrwsr-x+ 6 bzed  scm_python-modules 4096 juil. 22 09:26 .
drwxrws---+ 5 root  scm_python-modules 4096 janv. 30  2014 ..
drwxrwsr-x+ 7 obergix   scm_python-modules 4096 nov.  29  2013 
django-ldapdb.git
drwxrwsr-x+ 7 azatoth-guest scm_python-modules 4096 mars  18  2013 
plastex.git
drwxrwsr-x+ 7 zigo  scm_python-modules 4096 mai   16  2013 
python3-pyparsing.git
lrwxrwxrwx  1 aelmahmoudy-guest scm_python-modules   36 juil. 22 09:26 
python-whoosh.git -> ../../collab-maint/python-whoosh.git
drwxrwsr-x+ 7 dkg   scm_python-modules 4096 mars  18  2013 
python-xlrd.git

So please move your git repository there.

/me notes to switch python-django to git.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140806064730.ga13...@x230-buxy.home.ouaza.com

Re: Two django packages for Debian?

[Brian May]

On 6 August 2014 03:11, Matthew Vernon  wrote:

> I've packaged up django-grappelli and django-stronghold (since we have
> need for them at work). I think my debianisations are sane, but I've
> done them in git not subversion. Repos:
>

Please make sure these work with Django 1.7 in experimental...
-- 
Brian May