pybuild leaves empty directories in python3 debug packages

[Ghislain Vaillant]

Dear Python packagers,

I am currently maintaining two Python packages (pyfftw and pynfft),
which I have modernised using pybuild. For both packages, pybuild builds
the Python 2 and 3 packages, their respective debug versions and the
common documentation.

The resulting packages are "lintian -i" clean but "lintian -I" shows up
a "package-contains-empty-directory" only for the Python 3 debug
package.

Is this a bug from pybuild ? Is there a way I can run an additional
command to suppress the empty directory for the install target of the
Python 3 debug package ?

Thanks for your help,

Ghis


-- 
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/1407319919.5793.21.camel@lat644-lap

Re: Help needed to test packages with Django 1.7

[Matthias Urlichs]

Hi,

Barry Warsaw:
> >- beautifulsoup
> 
> Would it be better to port to dependencies to beautifulsoup4 which is already
> Python 3 compatible upstream and available in Debian as python{,3}-bs4?  The
> upstream docs claim it's pretty compatible, albeit with some deprecated
> (non-PEP 8 compliant) names.
> 
Agreed. In fact I'd recommend that bs3's reverse dependencies get converted
to bs4 before the release (and then drop bs3 from the archive) if possible.

-- 
-- Matthias Urlichs


-- 
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/20140806101704.gb15...@smurf.noris.de

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?

[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?

[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: policy for source package names

[Hans-Christoph Steiner]

Barry Warsaw wrote:
> On Aug 05, 2014, at 04:09 PM, Hans-Christoph Steiner wrote:
> 
>> I think it is a good practice to make the source package name the same as the
>> binary package name as long is there isn't a good reason to do otherwise.  So
>> with any source package that produces one binary package, those names should
>> match.  That keeps the Debian namespace smaller and more easy to understand.
>>
>> If a source package produces more than one binary package, then I think it
>> makes the most sense to name the source package using the upstream name,
>> barring name conflicts, too general a name, etc.
> 
> In the context of Python libraries, please try to be pro-active, especially if
> you know that the upstream is or will be supporting both Python 2 and 3.
> 
> plan-for-success-ly y'rs,
> -Barry

I suppose I was being too general.  For python packages, I generally use the
python- form for both the source and python2 package.

.hc


-- 
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/53e23e74.3060...@at.or.at

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?

[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?

[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: Help needed to test packages with Django 1.7

[Brian May]

On 23 July 2014 15:58, Brian May  wrote:

> You are expected to do all database migrations with Django 1.6, then
> upgrade to Django 1.7
>

Some more thoughts.

Are there any packages in Debian that attempt to automatically do database
migrations on upgrade?

If, not, that is good. Will solve the problem with my own package on my
own, it isn't in Debian.

However, if there are, we need to be able to disable this functionality
until the system administrator has manually confirmed that all Django South
migrations have been run.

Was thinking of having some sort of flag file that is created to confirm it
is safe to run Django 1.7 migrations. I picture this to be something like
(not tested) the following - maybe this could be scripted?

virtualenv --system-site-packages ~/old_django
. ~/old_django/bin/activate
pip install django==1.6.5
pip install django-south
django-admin --settings=??? migrate --all
touch /etc/xyz/south_migrations_complete
deactivate
rm -rf ~/old_django

Don't particularly like using --system-site-packages, think it will be
required to find the application however. Hopefully it will still get the
correct version of Django in this case.

Obviously, if this is scripted, you would use a temp directory, not
~/old_django.
-- 
Brian May