Re: joining the python modules packaging team

[Raphael Hertzog]

Hello,

On Thu, 05 Apr 2007, Michel Casabona wrote:
 Hello,
 
 I'd like to join the team to maintain the python-hachoir packages that I 
 build,
 which will be soon uploaded to debian (thanks a lot to Piotr Ożarowski),
 and help maintaining other packages if possible.

You have been added. Welcome to the group!

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Making all DD members of the team by default

[Raphael Hertzog]

Hello,

this mail is crossposted to two mailing lists. Please reply only to the one
that concerns you (perl or python team).

The collab-maint project gives write access to all DD by default using
ACL (see man setfacl and getfacl).
$ getfacl /svn/collab-maint/
[...]
group:Debian:rwx
[...]
default:group:Debian:rwx

I believe the perl and python team would benefit from using similar ACL
so that any DD who wishes to integrate his packages in the team can do so
without requesting access that we'll grant him anyway. We expect DD to be
educated and to ask before messing up if they're not sure of what
they're doing. In most cases, they'll figure it by themselves because
the available documentation hopefully directed them correctly. :-)

This also let NMUer integrate their NMU in the VCS directly if they so
wish.

As an Alioth admin, I can add those ACL. However I'd like to have your
opinion and agreement first.

Cheers,

PS: If you know other teams that would be interested, feel free to suggest
them and direct them to alioth admins ([EMAIL PROTECTED]) to get the
ACL added.
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Packaging django-openid ? and django dev release in experimental ?

[Raphael Hertzog]

Hello Brett,

I was looking for some OpenID support in Django and found out
http://code.google.com/p/django-openid/

Would you be interested in packaging this ?

Also, given the long time between two stable releases of Django it might
be worth packaging development release in experimental. What do you 
think ?

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com

Freexian : des développeurs Debian au service des entreprises
http://www.freexian.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Making all DD members of the team by default

[Raphael Hertzog]

On Thu, 26 Jul 2007, Raphael Hertzog wrote:
 Hello,
 
 this mail is crossposted to two mailing lists. Please reply only to the one
 that concerns you (perl or python team).

This warning is still valid. :-)

 As an Alioth admin, I can add those ACL. However I'd like to have your
 opinion and agreement first.

Both projects agreed and I just added the ACL. It would be great if some
people could update the respective documentation of each project to share
this information.

It has been noted that when a DD gets highly involved in the team, he
should nevertheless be added to the Alioth project. Non-DD who are looking
for sponsors can then better identify them and that way we keep a list of
core-members.

We'll also publicize this change in debian-devel-announce later (either in
a Bits of Alioth or in a more generic mail, we'll see).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: maintainer field

[Raphael Hertzog]

On Thu, 06 Sep 2007, Steve Langasek wrote:
   So I myself chose to be among Uploaders and set Maintainer to DPMT,
   because this more enforces team work and I like team work.
 
  I had a discussion on #debian-devel about this, and they thought it
  was pretty stupid to have DPMT as uploader, as it would make every
  package NMU.
 
 No, what was said was that it was meaningless to list a mailing list in the
 Uploaders field because a mailing list can never do an upload and therefore
 it misses the /point/ of the Uploaders field.

The only (good) reason of listing the mailing list in the Uploaders field is to
have the package in the group's QA page:
http://qa.debian.org/[EMAIL PROTECTED]

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bugs that'll block python 2.5

[Raphael Hertzog]

On Tue, 15 Apr 2008, Adeodato Simó wrote:
 * Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]:
  The solution is really simple, just add them to python’s Provides: list.
 
 Plus, uhm, can't really be done for (c)elementtree, since python 2.5
 provides the modules under a different name/namespace.

?!

In that case it might be a good idea to build python-celementtree for
python 2.5 as well... I haven't heard of technical incompatibility but
just that it was bundled with python 2.5 and thus unneeded/in conflict.

But if the namespace is different, there's no file conflict and I don't
understand why we cared about not generating the module for python 2.5.

 python-pysqlite2, on the other hand/for example, still provides the
 modules for python 2.5 under the old name. elementtree could do this,
 or else the packages should be somehow checked, I guess?

Indeed. (I should read mails entirely before replying :))

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Migration of Alioth account

[Raphael Hertzog]

Hi,

On Fri, 18 Apr 2008, Vincent Bernat wrote:
 Could someone with appropriate rights remove my account bernat-guest and
 add bernat instead?

Already done by Piotr apparently.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Unexpected Depends: both python-central and python-support

[Raphael Hertzog]

On Mon, 16 Jun 2008, Ben Finney wrote:
 What's causing this, and how can I fix it so it doesn't have this
 unexpected extra dependency?

It's because dh (from debhelper 7) will use dh_pysupport by default
if it's available.

Just use what debhelper uses by default or make sure to skip
that script by using appropriate dh --before pysupport
and dh --after pysupport invocation to skip dh_pysupport (until Joey
decides to implement a --skip option in debhelper at least).

Check the output of dh binary-arch --no-act to verify it by yourself.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#500391: ITP: python-django-debug-toolbar -- Embedded debugging toolbar for Django projects

[Raphael Hertzog]

On Sun, 28 Sep 2008, Chris Lamb wrote:
 Raphael Hertzog wrote:
 
  Do you plan to maintain the various Django related packages in the
  python-modules team ?
 
 I'm open to persuasion on this, otherwise no.

Well, I'm maintaining like you several Django related packages
(python-django itself, python-django-registration, python-django-tagging)
and it would be nice if we could co-maintain all those packages in the same
repository. Currently this repository is python-modules's SVN repo.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#517308: python-syck: lacks a python-support dependency

[Raphael Hertzog]

Package: python-syck
Version: 0.61.2-1
Severity: serious

The package uses python-support but does not depend on it.
The dependency should be auto-generated in a substvar, you just have to
add the proper substvar.

Note: the package is unmaintained, someone from the python team should
probably take it over. It is currently a dependency of dak and thus it
would be nice to have it properly maintained.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Quick analysis of the Python dist-packages transition

[Raphael Hertzog]

On Fri, 18 Sep 2009, Josselin Mouette wrote:
 If there are no objections, I will submit a MBF for those 75 packages in
 a few days.

Go ahead, we have waited too much for python 2.6 already.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: ${python:Breaks}

[Raphael Hertzog]

On Thu, 10 Mar 2011, Piotr Ożarowski wrote:
 seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹,
 we don't have to worry about 2.X transitions when 2.7 will become the
 only supported one. If you don't like Breaks, I will remove it, it
 really doesn't matter - that's why at the beginning I wasn't generating
 either of these dependencies (in Depends and in Breaks).

Well, if upstream changes their plans it will to late to fix the
dependencies...

 What do you want me to do? Can I drop both of them or do you want me to
 drop Breaks only?

So I would suggest to continue as usual and generate only the versioned
Depends.

Better safe than sorry.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110310111501.gc31...@rivendell.home.ouaza.com

Maintainer needed for python-trml2pdf

[Raphael Hertzog]

Hello,

I just uploaded a new version of python-trml2pdf where I removed myself
from Uploaders. I originally packaged this because it's needed for Satchmo
but I never went further to package satchmo. So I have no interest in this
package.

In the mean time it got one reverse dependency, namely kraft. So it can't
be removed. Someone should step up to maintain this package, and quite
possibly one of the kraft maintainers (since we're using the version
released by Kraft's upstream anyway).

The package is currently maintained within the python-modules SVN
repository and all Debian developers have write access. It's trivial
to maintain and should not require much work. On the bad side, it has
no real upstream.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120504064142.ga26...@rivendell.home.ouaza.com

Re: Is python-django still maintained in DPMT svn?

[Raphael Hertzog]

Hi Barry,

On Tue, 28 Jan 2014, Barry Warsaw wrote:
 As the package is supposed to be team maintained, I'm wondering *where* it's
 maintained.  I have some patches to fix build failures against Sphinx 1.2.1.

Good question. Luke, are you using git-svn and you forgot to push or
something?

 PS. I suppose I should add myself to Uploaders?

Not required if you don't intend to work regularly on it. Just put Team
upload in the changelog and lintian will be happy.

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: http://lists.debian.org/20140128131627.gc15...@x230-buxy.home.ouaza.com

Help needed to test packages with Django 1.7

[Raphael Hertzog]

(Please cc me as I'm not subscribed)

Hello,

I have filed 85 bugs against all reverse-deps of python-django
to ask their maintainers to ensure that their packages works well
with Django 1.7 (1). A good chunk of those are maintained or co-maintained
by the Python Modules team, and as usual in a large sample of packages,
some maintainers will be MIA and I won't have any answer.

So it would be highly appreciated if some people could help
process the following bugs so that when Django 1.7 is out we
have a good picture of what needs to be done and/or what will
possibly have to be (temporarily) removed from testing:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django17

It would be nice if all packages had a test suite to ensure whether they
still work but a large part doesn't even have a python-django build
dependency so it's not really the case...

What could be done however is mass-rebuild the packages against django 1.7
and mass-tag as confirmed the set of packages which are failing to build
with Django 1.7.

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/20140722090523.gb27...@x230-buxy.home.ouaza.com

Problem migrating from South to Django migrations for Linux distributions

[Raphael Hertzog]

[ Please keep me in CC ]

Hello,

I'm one of the python-django Debian package maintainers and I have been
working on preparing the field for Django 1.7... and we have one problem
that we don't know how to handle.

Consider that Debian contains Django but also Django applications using
South. When our users will upgrade from Debian 7 to Debian 8
they will upgrade at the same time Django itself and the Django applications.

The new versions of the Django applications are likely to have unapplied
schema migrations managed by South but the system will have Django 1.7
and we have no means to let the users apply those schema changes.

I see two ways to go forward:
- either we find a way to apply South migrations with Django 1.7
- or we enhance Django migrations to be able to tag some point
  in the Django migrations as equivalent to some other point in the
  South migrations, that way we can recreate the supposedly-unapplied
  South migrations with Django 1.7 and mark those as unneeded if all
  South migrations were already applied

How can we solve this problem?

Thank you for your help!
-- 
Raphaël Hertzog ◈ Writer/Consultant ◈ 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/20140724202733.ga8...@x230-buxy.home.ouaza.com

Re: Problem migrating from South to Django migrations for Linux distributions

[Raphael Hertzog]

Hi Brian,

On Fri, 25 Jul 2014, Brian May wrote:
 I can't help but think this might be unrealistic (?). Changes required for
 new versions of Django often break compatibility with old versions, and
 1.4.5 is really old now. Just because many packages don't have versioned
 dependencies on Django (or a versioned dependency on a really old version)
 doesn't necessarily mean they will work with any 1.4.5. Anyone want to test
 every Django package in Debian sid against the Django in wheezy?

I agree with you that this is not realistic. A better alternate solution
is to document the process of how to execute the South migrations with
Django 1.6 in a virtualenv after having done the upgrade to Debian 8.

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/20140725074344.ga15...@x230-buxy.home.ouaza.com

Re: Problem migrating from South to Django migrations for Linux distributions

[Raphael Hertzog]

Hi Andrew, 

thanks for your quick answer.

On Thu, 24 Jul 2014, Andrew Godwin wrote:
 There is no way around this; it's unfortunate that the packaging situation
 means that Django will get auto-upgraded as part of a distribution upgrade;
 I'm surprised that Debian hasn't had this with packages before? (Version
 upgrades that break installed but non-packaged things)

We probably had this kind of things before and the best we can do for
non-packaged things is usally to document this in the release notes.

But for packaged things, we try usually hard to get things to just work
without any human intervention. Hence my question.

 Neither of your suggested ways to go forward will work; the two history
 models are very different, so the tagging of positions isn't going to work,
 and Django 1.7 has changed substantially enough internally that porting
 South 1.x up to it would be a very large amount of work.

OK.

 Also, what are the applications in particular that this will be a problem
 for? I'm curious to know what Django + South things Debian is shipping
 these days.

Applications that depend on South and have different upstream versions
in Debian 7 and Debian 8 are:
http://tracker.debian.org/pkg/python-django-voting
http://tracker.debian.org/pkg/python-django-threadedcomments
http://tracker.debian.org/pkg/python-django-reversion
http://tracker.debian.org/pkg/python-django-picklefield
http://tracker.debian.org/pkg/bcfg2

Given the package names, it probably means only a single end-user application.
The others are Django extensions for use in non-packaged applications.

And looking more closely the case of bcfg2, the package in Debian 7 does
not use South, it started using South in the version in Jessie so it
should be easy to deal with.

For the 4 others, they should provide some NEWS.Debian entry warning
users of the potential upgrade problem.

(Bccing the 5 relevant bug reports to keep a record of this)

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/20140725080457.gc15...@x230-buxy.home.ouaza.com

Re: Help needed to test packages with Django 1.7

[Raphael Hertzog]

On Sun, 03 Aug 2014, Brian May wrote:
  Django 1.7 final isn't even released upstream, and therefore, downstream
  projects didn't even try to run against it. There *will* be issues we
  will have to deal with. 85 packages is quite something. I'm ok, and even
  welcome to *try* to make it before Jessie, though it is my view that
  it's unreasonable to rush without taking care of possible breaking.

I already explained you in another thread on debian-release, that it's not
reasonable security-wise to release Jessie with Django 1.6. And you're
well placed to know what it means to maintain a package that gets security
updates very often...

We have very few Django end-users apps in Jessie, so let's try to take
care of those but it's not a problem if some of the Django extensions
(i.e. apps available for integration in custom developments that have
almost no reverse dependencies) are dropped from jessie.

  FYI, I'm trying to deal with python-memcache support for Python 3.4.
  Until that one is fixed, I wont be able to add support for Python 3 in
  keystoneclient, and therefore *a lot* of other packages will have no
  Python 3 support. I've tried to forward port a patch from
  python3-memcached, though it's still not ready, and unit tests are
  failing. Julien Danjou (eg: acid@d.o) wrote to me he'll try to find time
  to help. I really hope this one issue will be fixed soon, so that I can
  work on adding Python 3 everywhere possible in OpenStack, though right
  now it's a major blocker. I also hope we can upstream Python3 support
  for memcached, as the python3-memcached fork has been a major waste IMO.

If you aren't able to deal with Django 1.7 support and Python 3 support
before the freeze, please treat python 3 support as lower priority to Django
1.7 support. That said it would be nice to have both.

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/20140803072708.gb19...@x230-buxy.home.ouaza.com

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?

[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

[Raphael Hertzog]

On Thu, 07 Aug 2014, Brian May wrote:
 On 23 July 2014 15:58, Brian May br...@microcomaustralia.com.au 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?

I don't think so. The few packages with south migrations were not
concerned in the wheezy-jessie upgrade.

 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.

Can you test something like this? I would like to document something like
this in NEWS.Debian of python-django so that admins are not left in the
cold for their own django apps.

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/20140807214213.ga11...@x230-buxy.home.ouaza.com

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?

[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: guardian and django1.7

[Raphael Hertzog]

Hi,

On Tue, 19 Aug 2014, Brian May wrote:
  For example, I renamed migrations to south_migrations and created a
  Django1.7 compliant migrations directory, however still get the same error.

Did you fill that new directory with an initial migration generated with
./manage.py makemigrations?

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/20140819080439.ga1...@x230-buxy.home.ouaza.com

Re: Playing with git-dpm

[Raphael Hertzog]

Hi Barry,

On Tue, 19 Aug 2014, Barry Warsaw wrote:
 * The egg-info directory is a PITA.
 
 The upstream tarball has a lazr.smtptest.egg-info directory.  debuild -S blows
 this away, and then git thinks I want to delete it.  It doesn't get staged, so
 it's easy to `git checkout -- lazr.smtptest.egg-info`[3], but it gets annoying
 *very* quickly after just a few debuilds.  I'm not sure what the best way to
 handle this is, if there is one.

You can commit the removal, but it will regularly cause merge conflicts.

Or you can build the package in another directory, like svn-buildpackage
does. I'm not sure if git-dpm has something for this but you can
probably use git-buildpackage --git-export-dir=../build-area/ in
combination with git-dpm.

 * debian/patches/* get named automatically
 
 `git-dpm checkout-patched` creates a temporary patch branch.  I had to patch
 the setup.py, so I just edited it as normal.  Note though that you *must*
 commit this file while on the patch branch or it doesn't get quilt-ified, but
 it will still show up as modified on your packaging branch if you switch to
 it.  Oh, and the first line of your commit message gets turned into patch
 name.  I like that it handles quilt-ifying the patch automatically when you
 `git-dpm update-patches` but watch out with your commit messages or you may be
 left with a patch file that has an odd name.  I didn't try to change that and
 see if git-dpm could still grok the patch.

I believe that git-dpm can handle any quilt series as input but it will
always rename it based on the commit after a checkout-patched.

 * Where to push the repo?
 
 I'm not sure that we have a definitive path on git.debian.org for team
 maintained packages under git, but there is a python-modules directory
 containing a few packages.  So I pushed my branches to
 git+ssh://git.debian.org/git/python-modules/packages/lazr.smtptest.git
 
 It takes a bit of work to create this directory initially, but I found that
 gbp has a nice command you can corrupt wink into doing the right thing for
 you, e.g.:

Please do something like this to create new git repositories for
python-modules:
$ ssh git.debian.org
$ cd /git/python-modules
$ ./setup-repository lazr.smtptest lazr.smtptest packaging
$ exit

It will setup some default hooks to to forward the commit notices where
appropriate.

(I just did the required configuration for you.)

 Oddly, I don't see the repo here: http://anonscm.debian.org/cgit/ but I have
 no idea why.

It's there now. The repository listing is not updated in real time (too
much I/O involved).

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/20140820192111.gb2...@x230-buxy.home.ouaza.com

Re: Playing with git-dpm

[Raphael Hertzog]

On Wed, 20 Aug 2014, Barry Warsaw wrote:
 So, because of the way I've named the branches, the full invocation is:
 
 $ git-buildpackage -S --git-export-dir=../build-area/ 
 --git-debian-branch=lazr.smtptest --git-upstream-tree=upstream-lazr.smtptest

So --git-export-dir is usally best set in ~/.gbp.conf:
$ cat ~/.gbp.conf
[DEFAULT]
pristine-tar = True
cleaner = /bin/true

[git-buildpackage]
sign-tags = True
export-dir = ../build-area/

For the other two options, the recommended practice is to put them in
debian/gbp.conf but I generally don't do that and just use standard branch
names (master / upstream).

 Thanks for both the recommendation and the fix!  Once the team decides on a
 workflow, will it be feasible to write the equivalent of svn-inject?  Since
 shell access to g.d.o is required it seems like this won't be completely
 self-services, but teammates who are DDs could do it for other folks.

git-import-dsc is your svn-inject, it will put upstream sources in the upstream
branch and will create the master branch based on that with the packaging
changes. But the quilt patches won't be applied after this operation.

I managed to start using git-dpm on a pre-existing repository but it required
an initial git-dpm init .../mypkg_1.orig.tar.gz IIRC.

Note that all members of the team automatically have shell access to 
git.debian.org
(it's just alioth itself).

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/20140820201709.gc2...@x230-buxy.home.ouaza.com

Re: Playing with git-buildpackage

[Raphael Hertzog]

Hi,

On Thu, 21 Aug 2014, Barry Warsaw wrote:
 Then I `git init`'d a new local repository and used `gbp import-dsc` to
 initialize the git information.  That seemed to work just fine.

FWIW, I usually setup the repository on git.debian.org first and then I
clone that empty repository. With this process, the git repository already
has the origin remote already setup.

 Now I wanted to update the package to 2.0.1, so I used `git-import-orig
 --uscan` which works great, except that it doesn't add a debian/changelog
 entry.  That would be a nice convenience I think.

gbp's developer is relatively active, feel free to file wishlist bug
reports for that kind of things.

 `gbp pq` is the tool to manage the patch branch, but there were a few things
 that seemed messier than with the git-dpm experiment:
 
 * I used `gbp pq switch` to get to the patch-queue/master branch.  Unlike with
   git-dpm, this does *not* delete the debian/ directory.  It did make things
   smoother with Emacs because upon switching back (later) to master, I didn't
   have to revert the files I was visiting.  But I realized that it did leave
   me in a somewhat confusing state.  Should I use quilt?  The patches were not
   automatically applied by `gbp pq switch`.  Maybe I should have imported
   them.

gbp pq import is the right command indeed, it will create the branch with
everything required and switch to it.

 It makes me think that git-dpm's handling of debian/ is probably closer to
 right, so that there'll be no temptation to muck about with quilt while in the
 patches branch.  Maybe a better approach would be to delete just
 debian/patches - that would remove my confusion but wouldn't force me to
 revert all the debian/ files I was editing.

When you analyzed git-dpm, the lack of debian was a negative point, so it
would be weird to want to remove it here.

What you possibly need is an enhanced shell prompt displaying the name of
the current branch, it's relatively easy to do by embedding $(__git_ps1
2/dev/null) somewhere in your $PS1. That way you immediately see that you
are on the patch-queue branch...

 I was disappointed with the documentation surrounding the `gbp pq` workflow.
 It's not really described in the git-buildpackage manpage and the best
 documentation for `gbp pq` is off-site and external to debian.org.

man gbp-pq ?

It effectively points to the website of the author, but that doesn't sound
like a problem. It's possibly because the software is quite well
documented on https://honk.sigxcpu.org/piki/projects/git-buildpackage/
that there's no wiki page or anything like that explains everything.

 The other disappointing thing is that once I was back on the master branch,
 the patch-queue/master branch was not deleted.  That's a nice little cleanup
 that git-dpm handles for you.  After all, who wants that temporary patch
 branch on git.d.o?

Why would you push your temporary branch?

I know this can happen if you do git push --all but that command is
not a good idea in general... you can do git push origin : to push all
the branches that are pre-existing on the remote side.

Keeping the branch makes it easier to rebase it in the future and then
re-export the patches.

 git-buildpackage has --git-ignore-new but that's actually not enough!  Because
 of the vagaries of git, you have an extra level of changes, i.e. the index.
 This means that if you want to include uncommitted changes in the package, you
 need to also use --git-export.  There are two options here: --git-export=INDEX
 obviously includes the staged changes while --git-export=WC includes the
 working copy.  =WC seems much more aligned with my own personal preferences,
 and is closer to what svn-bp does by default.

Note that this is only required because you actually use
--git-export-dir=../build-area/. When you don't do that you build out of
the working copy and --git-ignore-new is then enough.

 Once I uploaded the package, I had trouble with git-bp --git-tag-only
 recognizing my gpg keys.  I didn't investigate further, but just used
 --git-no-sign-tags for now.

I never had any problem with signing the tags. Does your git identity
matches your identity on the GPG key?

 After this experiment, my own personal preference is leaning toward git-dpm.
 It just seems like a cleaner, more self-contained, and better documented
 workflow.  I think there's room for improvement, but git-dpm is just a fancy
 shell script so I hope it's maintainer will be open to patches and
 suggestions.

gbp is Python and the author is also open to patches and suggestions :-)

 In truth though, I bet it won't be hard to convert from one to the other.  The
 biggest difference that I can tell is that if you use the default branch
 names, it's mostly just the tag names that differ:
 
   git-dpm: {debian,patched,upstream)-version
   git-bp: {debian/upstream}/version

In python-django, I just switched to debian/codename +
upstream/upstream-branch following early results of the current

Re: Playing with git-buildpackage

[Raphael Hertzog]

On Fri, 22 Aug 2014, Barry Warsaw wrote:
 Why would you push your temporary branch?
 
 Only because `git push --all` seems like the obvious choice.  But I think
 git's cli is akin to quantum mechanics, i.e. don't trust your intuition. :)

Ideal is when a git push alone is enough, you can do git config
push.default matching to make it push all the branches that exist on both
sides.

That used to be the default but it's counter-intuitive... I agree it's a
pity that there's no git push --matching option instead of the
non-explicit git push origin :.

 It would be nice if the admins could whitelist all mails containing
 an X-Git-Repo header.
 
 In Mailman, that's easy.
 
 Or at least whitelist all *@users.alioth.debian.org emails as those are in
 the From of those emails.  (I just changed a setting so that it uses this
 domain now)
 
 In Mailman, that's easy.
 
 Alternatively you can subscribe to the list with your
 login@users.alioth.debian.org mail and disable mail delivery for that
 address.
 
 In Mailman, that's easy.
 
 Anybody know the maintainer of the mailing list?

http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-commits
= stra...@users.alioth.debian.org
aka Gustavo Franco stra...@debian.org

I'm not sure if Gustavo is still active or if someone else has the
admin password... Gustavo?

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/20140823071521.ga31...@x230-buxy.home.ouaza.com

Re: Proposed git migration plan

[Raphael Hertzog]

Hi Sandro,

On Wed, 27 Aug 2014, Sandro Tosi wrote:
 It seems to me like very vocal Git fanatics, who refuse to touch any
 package which is not maintained in Git (-.-), are pushing and pushing
 to that VCS without any clear advantage.

You might dismiss those people but you're speaking of true contributors
that you're aleniating here. If we really want to stay an all-inclusive
team we should use what the majority of (possible) contribtuors prefer
to use.

python-modules is about the only team I'm part of that is not yet using
git. It's an annoyance to have to continue to use svn-buildpackage when
I only use git everywhere else.

 Upstream releases history? why do we need to care, we are packagers we
 should care about packaging commits history.

Because your packaging decisions are not influenced by upstream changes?

 from the VCS again? seems kinda twisted to me :) And no, not the whole
 programming world is using Git for upstream code (sometimes we're not
 even able to teach upstream to use proper versions), so the usual
 mantra I can pull from upstream repo and be happy ever after is
 kinda weak.

Not everybody is using git but I think that you should face it, most
of the upstreams projects do.

 is there anything else so attractive about git?

It's 200% more easy to manage multiple branches and merge them properly.
Most of the average python modules will not need multiple branches but for
things like python-django, we do need multiple branches... and the fact
that svn is such a pain means that the security updates were not managed
in svn for example...

And handling security updates in svn is a pain because you can't commit
localy and push only when the security update is disclosed publicly.

etc.

All those are real problems for real people doing packaging work.

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/20140827084040.gc23...@x230-buxy.home.ouaza.com

Re: DebConf14 svn-git migration BOF notes

[Raphael Hertzog]

On Wed, 27 Aug 2014, Stuart Prescott wrote:
  I've done some personal investigation since the BOF, and am preparing
  some really simple migration scripts, so we can get a feel for what it
  will look like. My scripts so far (very very simple)
  git://git.debian.org/users/stefanor/dpmt-migration.git
 
 is there any reason to use a loop around git-import-dsc rather than git-
 import-dscs --debsnap here?

I haven't looked at stefano's script but git-import-dscs will import all
source packages in a single linear history (importing the packages by
increasing version) and that isn't representative of the true history.

For python-django, I imported all the normal versions in the debian/sid
branch but manually imported the +deb7uX in a debian/wheezy branch,
the +squeezeX in a debian/squeeze branch, etc.

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/20140827085224.gd23...@x230-buxy.home.ouaza.com

Re: Proposed git migration plan

[Raphael Hertzog]

On Wed, 27 Aug 2014, Sandro Tosi wrote:
 like true contributors are those using svn right now. and what about
 the majority of contributors now? we should change just because maybe,
 eventually, if we're lucky we'll attract more contributors? saying I
 won't contribute to your team if you don't move to Git is IMHO
 arrogance and against team work (but we know. I'm different :) )

Please don't try to split contributors in two camps.

I do continue to use svn-buildpackage for the few django extensions that I
maintain in python-modules. And even if I moved python-django to git, I'm
still a team contributor even if I touch only a small subset of packages.

  Because your packaging decisions are not influenced by upstream changes?
 
 i don't follow? is that an advantage of having the upstream source
 code in the Debian packaging repository?

Yes, I regularly use git log on upstream metadata files to see whether
we missed some new (optional) dependencies and stuff like that.

  Not everybody is using git but I think that you should face it, most
  of the upstreams projects do.
 
 i dont think so. It might be true for the big projects, but look at
 the vast majority of the packages in DMPT/PAPT,  they are small
 modules/apps how many of them are using git? I wont say most more
 few of them.

No point in arguing here (I don't have time to do a proper analysis and
come up with figures).

That said in my experience, most new stuff I tend to package are actually
maintained in github or a similar service. The fact that we are grabbing
.tar.gz on pypi means that we might also not be directly aware that the
tarball is generated out of a git repository.

  It's 200% more easy to manage multiple branches and merge them properly.
  Most of the average python modules will not need multiple branches but for
  things like python-django, we do need multiple branches... and the fact
  that svn is such a pain means that the security updates were not managed
  in svn for example...
 
 branches exist in svn too (I admin they are harderd than git tho) and
 security updates always evolve in 2 separate ways than current
 development (in fact, I think you're referring to update in stable, so
 you'll have a branch for stable and trunk, which likely are at 2
 different versions, evolving indipendently. I did that for matplotlib,
 and it's doable)

I said 200% more easy, I know that they are doable, but it's just
painful...

  All those are real problems for real people doing packaging work.
 
 you skipped the part of what are the problems the teams is facing with
 svn we want to solve with git, while it seems you're talking about
 your experience with Django alone, which is important of course but
 not necessarily representative of a huge amount of packages in our
 teams.

And? If we want a single VCS then we must cater to the most demanding use
cases. Obviously svn-buildpackage is just fine for small packages with a
single branch and no patches...

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/20140827091911.ge23...@x230-buxy.home.ouaza.com

Re: git-dpm vs gbp-pq: new upstream and patch refresh (long)

[Raphael Hertzog]

On Thu, 04 Sep 2014, Barry Warsaw wrote:
 On Sep 04, 2014, at 04:36 PM, Scott Kitterman wrote:
 
 Actually, nevermind.  That's not the problem you were trying to solve,
 although you could remove the patch as described and then apply the updated
 patch at the end of the series.
 
 Yeah, though sometimes for legitimate reasons you can't reorder patches.  It
 vaguely feels like with git-dpm since the patch branch is never pushed, you
 could uncommit (`git reset --hard HEAD^`) and stash each commit until you
 got to the one you wanted to amend, then unstash and recommit back up the
 stack.  E.g. just like quilt push/pop.

As others have mentionned, you should use git rebase -i ancestor. This is 
what
you want to use on your patch-queue branch to modifiy individual commits,
reorder them, or drop them.

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/20140904222559.ga7...@x230-buxy.home.ouaza.com

Re: Recommendation: adopt git-dpm

[Raphael Hertzog]

On Thu, 04 Sep 2014, Barry Warsaw wrote:
 Even with those complaints, git-dpm feels like the better tool for team
 package management in git.  The problems are minor and probably easily
 fixable.

From my point of view, since you're anyway using features of
git-buildpackage, it would be better to improve git-buildpackage...
I like how git-dpm can keep patches applied on the packaging
branch and porting the required shell to gbp pq should not be
too complicated. It would also be nice if we could fix gbp pq to not
rename quilt patches.

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/20140904223231.gb7...@x230-buxy.home.ouaza.com

Re: django 1.7 change for backport to wheezy

[Raphael Hertzog]

Hi,

On Tue, 09 Sep 2014, Brian May wrote:
 Can I please get the following change in python-django git?
 
 Add the following to debian/control:
 
 X-Python-Version: = 2.7
 
 This will make backports to stable a lot easier. Otherwise the package
 builds fine, but won't install in Python 2.6 is installed.
 
 I would do it myself, but not 100% confident of the branches - I guess I
 should use the debian/experimental branch?

Yes, please commit that on the debian/experimental branch.

(Sorry that I lost this in the git conversion.)

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/20140909063146.ga31...@x230-buxy.home.ouaza.com

Re: Help needed to test packages with Django 1.7

[Raphael Hertzog]

Hi Brian,

thanks for those investigations!

On Thu, 11 Sep 2014, Brian May wrote:
 Note that I have explicitly called python. This ensures Python 3 not used
 (not supported by South + the virtualenv is Python 2 only) and that we get
 the python from the virtualenv.
 
 I have tested this and it appears to work, although the above was changed
 not to be specific to my app.

Please document this in python-django's README.Debian and mention where to
find this sample in the current debian/python-django.NEWS entry.

TIA.
-- 
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/20140911062808.gb9...@x230-buxy.home.ouaza.com

Re: django 1.7 bugs

[Raphael Hertzog]

Hi,

On Sat, 13 Sep 2014, Thomas Goirand wrote:
 I think we should all focus first on the Python Team modules, and see
 where that leads us. Also, to me, considering the amount of remaining
 bugs without a single reply, it's too early to upload Django 1.7 to Sid.
 Raphael, do you still plan to upload next week?

Yes. I prefer to do it now, thus raising the bugs to higher severities
soon since that's the only thing that will attract the attention of the
remaining maintainers and of all people who help squash RC bugs.

Also if some packages get removed due to RC bugs, it's better when it
happens soon so that reverse-dep get notified earlier and have a chance
to reintroduce the package if needed, etc.

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/20140914125838.gc20...@x230-buxy.home.ouaza.com

Re: django 1.7 bugs

[Raphael Hertzog]

Hi,

On Fri, 12 Sep 2014, Zygmunt Krynicki wrote:
 I wrote large parts of lava-server and both of the django- packages
 here but I'm not an active upstream anymore (I cannot commit to those
 repositories, only Linaro folks can) . If anyone wants my help though
 I'd gladly render assistance.

I already provided some patches to fix unit test failures but upstream
is concentrated on other stuff in the short term so Neil might appreciate
your help to review the patches and do some higher level testing with
Django 1.7.

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/20140914130225.gd20...@x230-buxy.home.ouaza.com

Re: Help needed to test packages with Django 1.7

[Raphael Hertzog]

Hi,

On Tue, 16 Sep 2014, Brian May wrote:
 On 11 September 2014 16:39, Brian May br...@microcomaustralia.com.au
 wrote:
 
  Ok, will look into this tomorrow.
 Just pushed a change.
 
 Unfortunately, had problems testing this because debian/rules clean
 removes Django.egg-info/* which is flagged by git-buildpackage as
 uncommitted changes.

Recent versions of git-buildpackage should no longer call debian/rules
clean IIRC. But you can disable this with:

[DEFAULT]
cleaner = /bin/true

in ~/.gbp.conf

Alternatively you can build with --git-ignore-new too.

 Also django-migrate-south won't work without virtualenv installed. Was
 wondering if maybe I should add it to recommends (wheezy needs
 python-virtualenv; sid needs virtualenv installed).

I'm not sure that adding such a script in /usr/bin/ is a good idea.
It doesn't have a manpage, it's a temporary hack, etc.

I would put the script in the doc directory and I would document
to run it as:
sh /usr/share/doc/python-django/migrate-south --settings app.settings

Then it's more logical to not change the dependencies and just document
(as you did) the need to install virtualenv.

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/20140916065130.ga23...@x230-buxy.home.ouaza.com

Re: Fwd: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1

[Raphael Hertzog]

Hi,

On Wed, 24 Sep 2014, Julian Taylor wrote:
  Nah. It's a great reason to teach the tool in question to be *way* more
  reasonable. Who needs a single email per commit? Esp. since the number of
  actual commits will go way up with increased git usage – feature branches
  are easy in git, and more granular commits are a great way to help with
  tracking down exactly which change introduced a regression.
 
 Single mails/irc messages per commmit are very useful, they help a lot
 to find mistakes others are making before an upload happens.
 
 What we don't want is messages for upstream changes. This should be
 simple to fix, simply check the changed paths for debian/ before sending
 a message.

The default script in use on Alioth is based on git-multimail:
https://github.com/mhagger/git-multimail

It doesn't have such a path-based filtering. But it's Python \o/
So it would be nice it you could contribute such a feature upstream. :-)

That said using maxCommitEmail is still a good safeguard.

There's also the possibility of only using refchangeList (instead of
mailinList) so that we only send out the summary mail of what has been
pushed.  The caveat being that we don't get diff of the changes wich
is what makes those email notifications interesting.

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/20140924073229.gb5...@x230-buxy.home.ouaza.com

Re: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1

[Raphael Hertzog]

On Thu, 09 Oct 2014, Sandro Tosi wrote:
 so is there any chance you stop this commit storm madness anytime
 soon? another bunch of 300 commit messages arrive this night

I fixed the default configuration in setup-repository to limit to 20
commits per push as a maximum. And I also limited the size of individual
commit emails to 1000 lines.

I updated the configuration of the already existing repositories.

hertzog@moszumanska:/git/python-modules/packages$ for i in *.git; do cd $i; git 
config multimailhook.maxCommitEmails 20; git config multimailhook.emailMaxLines 
1000; cd -; done

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/20141009080251.gf3...@x230-buxy.home.ouaza.com

Re: Fighting commit storm madness (was: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1)

[Raphael Hertzog]

On Thu, 09 Oct 2014, W. Martin Borgert wrote:
 On 2014-10-09 10:02, Raphael Hertzog wrote:
  I fixed the default configuration in setup-repository to limit to 20
  commits per push as a maximum. And I also limited the size of individual
  commit emails to 1000 lines.
 
 I wonder, whether some kind of digest function would be possible
 and useful?

There is already a single mail per push that summarizes all the commits
and the individual commits are sent as replies to that initial mails
(provided that the number of commit doesn't exceed 20, otherwise you only
get the summary mail).

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/20141009093602.gg3...@x230-buxy.home.ouaza.com

Re: Git migration schedule

[Raphael Hertzog]

On Wed, 21 Oct 2015, Sandro Tosi wrote:
> On Wed, Oct 21, 2015 at 11:01 PM, Brian May  wrote:
> > Maybe we should fix #801666 first and then revisit this question?
> 
> git-dpm hasnt seen a single line changed since more than a year
> (http://anonscm.debian.org/cgit/git-dpm/git-dpm.git/) so I wont hold
> my breath on it :(

Yeah :( That makes another point that was missed in the evaluation of
git-dpm vs git-buildpackage and its "gpb pq" command.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: dh-python (pybuild + dh_py*) documentation

[Raphael Hertzog]

Hi Piotr,

On Mon, 26 Oct 2015, Piotr Ożarowski wrote:
> How can I improve it? Do you need more detailed description of options?
> Do you need more examples? Or maybe I should hide most of options, the
> "corner case" ones? I focus on making things work out of the box, if
> possible, and make it very customizable so that weird corner cases are
> possible as well - this means there are a lot of options, is this the
> problem?
> 
> Can you be more specific about what's missing?

I for one lack a high level presentation of how the various bits work together
and a clear description of the "magic" behind each tool.

For instance, dh_python2 explains that it tries to translate Python
dependencies into Debian dependencies but it's not clear that it needs
the corresponding packages installed (so it's not clear that for this
to work you have to add something to Build-Depends).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Django 1.8 in unstable in early November

[Raphael Hertzog]

Hello,

I just filed 20 bugs on packages that FTBFS with Django 1.8. They have
two weeks to be fixed before we upload Django 1.8 to unstable.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django18

If you maintain a package in the Django ecosystem, please double check
that it's ready for Django 1.8. The fact that it doesn't fail to build
does not mean that it will necessarily work if you don't have any tests
or if you don't run them.

If you file more bugs related to Django 1.8, don't hesitate to add
the "django18" usertag associated to the
"python-dja...@packages.debian.org" user. (I wish we could easily
rerun the DEP-8 functional tests with a new version of the package)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Git migration schedule

[Raphael Hertzog]

On Tue, 20 Oct 2015, Brian May wrote:
> Barry Warsaw  writes:
> 
> > Now, in practice, it doesn't matter if you ignore git-dpm and just use quilt
> > *as long as the final state of the repo is compatible with git-dpm*.  
> > Meaning,
> > in general, you can make whatever local decisions you want as long as they
> > don't force other team members to go outside of team recommendations.
> 
> I don't see how you could use quilt and maintain compatability with
> git-dpm. git-dpm expects all patches to be in git, and will update
> debian/patches automatically from git. quilt writes patches directly in
> debian/patches/* and doesn't support git.
> 
> Not something that concerns me personally, quilt was starting to become
> very painful for me. I regularly ended up forgetting the "quilt add"
> operation before editing files, resulting in invalid patches.

And also for import of upstream tarballs you basically have to use git-dpm
as git-dpm keeps state data in debian/.git-dpm whereas git-buildpackage
does not have similar state data (except the generic git data like
availability of a upstream/ tag, and so on).

I really regret to not have invested time earlier to try out git-dpm...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Git migration schedule

[Raphael Hertzog]

On Sun, 11 Oct 2015, Brian May wrote:
> What branches do I need to put the debian/README.source file in? There are
> six debian/* branches, don't think it is a good idea to try and maintain a
> consistent debian/README.source in all branches.
> 
> Maybe debian/experimental would be sufficient? Or perhaps
> debian/experimental + debian/sid?
> 
> In fact, putting in a branch seems wrong, it isn't specific to any one
> branch, not sure where a better place would be though.

IMO, you should just indicate that the repository follows DEP-14 and not be
specific about the branch names. That way you don't have any problem.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: python-django

[Raphael Hertzog]

On Sun, 11 Oct 2015, Brian May wrote:
> Just noticed how it named the upstream branches.
> 
> * [new branch] upstream-debian/experimental -> upstream-debian/experimental
> * [new branch] upstream-debian/jessie -> upstream-debian/jessie
> * [new branch] upstream-debian/sid -> upstream-debian/sid
> 
> Not sure this is ideal :-(

This definetely sucks, I want to continue to use upstream/1.7.x,
upstream/1.8.x and so on. We want to be able to maintain multiple
upstream branches in parallel, no matter where they are uploaded.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: [DPMT] radical changes: automation, carrot and stick

[Raphael Hertzog]

On Wed, 07 Oct 2015, Piotr Ożarowski wrote:
> I assume you all like other ideas, like no team in Maintainer, right?

While I understand the desire to have one identified maintainer for each
package, I don't agree with the rule.

Changing maintainer means changing the flow of information and it is a
pain. When I get interested in a package, I subscribe to the package in
the tracker. At some point, I end up the "maintainer" because the former
maintainer left and here I should put myself in maintainer... that would
mean getting duplicate mails and me having to fix my subscriptions
or add procmail rules to avoid this.

So I don't think that this rule gives us more benefits than annoyances.
If you want to identify someone as in charge, let's define that the first
person in the Uploaders field is that person.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: python-django

[Raphael Hertzog]

Hi,

On Fri, 09 Oct 2015, Brian May wrote:
> We can move the migrated version out of the way, restore the old version,
> and update it to the required standards (e.g. git-dpm). Is everyone happy
> with this approach?

Yes, except for the naming of branches where I would prefer to keep
the DEP-14 naming scheme (we should just rename debian/sid into debian/master).

http://dep.debian.net/deps/dep14/

And I would suggest that we generalize the DEP-14 naming scheme as part of
our git packaging policy...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Bug#812117: RM: simpletal -- RoQA; unmaintained; low popcon

[Raphael Hertzog]

On Wed, 20 Jan 2016, Mattia Rizzolo wrote:
> loggerhead: loggerhead

And that rdep is relatively important since AFAIK we use loggerhead at least on
alioth to browse bzr repositories.

Maybe it's best to invest a bit of time into updating it rather than
dropping it just for the sake of its low popcon?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: django-pipeline / slimit

[Raphael Hertzog]

On Wed, 23 Mar 2016, Brian May wrote:
> Looks like slimit doesn't support Python3 and hasn't had an upstream
> release since 2013-03-26.
> 
> Any suggestions where to go from here?
> 
> Maybe hack pipeline to disable the failing test? I think pipeline can be
> configured to use jsmin instead of slimit and jsmin is packaged in
> python2 and python3 versions.

Yeah, skip the test on Python 3, tell upstream that slimit is not
supported on Python 3 and that the test should be skipped there.

Make sure that slimit is not the default.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: django-pipeline / slimit

[Raphael Hertzog]

On Wed, 23 Mar 2016, Brian May wrote:
> I: pybuild base:184: PYTHONPATH=. python3.5 /usr/bin/django-admin test 
> --settings=tests.settings
^
>   File "/«PKGBUILDDIR»/pipeline/compressors/slimit.py", line 12, in 
> compress_js
> from slimit import minify
> ImportError: No module named 'slimit'
[...]
> Does this mean we need to change the slimit package into python-slimit
> and python3-slimit packages?

Looks like so, indeed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Raphael Hertzog]

On Wed, 10 Aug 2016, Nikolaus Rath wrote:
> I don't believe that switching from git-dpm to git-buildpackage is going
> to make things easier, it'll just be trading one set of problems for
> another.

I don't agree on this. I have been a happy git-buildpackage user for all
my packages. The problem with git-dpm is that the patch series can't be easily
fixed after a merge when it generates conflicts. It's too intricately tied
to git-dpm's own fake merge logic with commit it recorded in
debian/.git-dpm and it's very painful to bring the repository in a state
where git-dpm is happy.

With git-buildpackage, the merge and the update of the patch series are
distinct operations that can be done at different times. Since patches are
unapplied, the merge usually works fine and the patch series
can be easily rebased afterwards with your tool of choice.

Anyway, +1 from me to switch to git-buildpackage and in fact among the
python-django maintainers we are close to decide to switch back to
git-buildpackage because it's really horrible to use when you want to
merge across branches of different releases.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: [Python-modules-team] Bug#849652: faker: FTBFS on 32-bit: ValueError: timestamp out of range for platform time_t

[Raphael Hertzog]

On Mon, 30 Jan 2017, Brian May wrote:
> Help in fixing this RC bug would be appreciated. I have forwarded this
> upstream, however need a quick fix for the Debian package (not sure but
> suspect it might be too late for stretch).
> 
> Unfortunately, not sure where to start. I don't understand this
> date_time_this_century() function that appears to be the cause of it.

I have not looked into this but tzdata is no longer (transitively) part of
build-essential, is the package installed in the failing build?

Maybe try to rebuild with the package explicitely listed in Build-Depends?

Regards,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: git-dpm breakage src:faker

[Raphael Hertzog]

On Sun, 29 Jan 2017, Brian May wrote:
>   3. Update debian/source/options with "unapply-patches" (anything else?).

You don't need that. dpkg-buildpackage unapplies them automatically after
the build if it has applied them. If they were already applied before the
build, then it leaves them applied.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: DPMT Membership request

[Raphael Hertzog]

Hello Marcos,

On Wed, 23 Nov 2016, Marcos Fouces wrote:
> I am still waiting for an answer. I don't know how to proceed in this case.

You should have subscribed to debian-python@lists.debian.org and you would have
seen that you have to reply to
https://lists.debian.org/20161117075743.i7exf7vmpbi4a...@sar0.p1otr.com

That's the blocker right now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Binary naming for Django Related Packages

[Raphael Hertzog]

Hi,

On Wed, 30 Nov 2016, Scott Kitterman wrote:
> Raphael, do you think that the upstream Django project might be willing to 
> make some kind of best practices for naming third party django packages?  If 
> they did that, then that would give us a basis for Debian maintainers talking 
> to their upstreams about moving to django_.

They already partly do that, see:
https://docs.djangoproject.com/en/1.10/intro/reusable-apps/#packaging-your-app

They recommend a "django-" prefix in the PyPi package name. But they say
nothing about the Python module name and the sample just bundles a "polls"
module in a "django-polls" package.

Thus I posted this to gather their feedback on the need to recommend the
prefix on the name of the module too:
https://groups.google.com/forum/#!topic/django-developers/f8yNRkn6Fpo

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Binary naming for Django Related Packages

[Raphael Hertzog]

On Mon, 28 Nov 2016, Piotr Ożarowski wrote:
> [Barry Warsaw, 2016-11-28]
> > Is there any risk of having confusing names because of a conflict between a
> > 3rd party Django module and a Django subpackage?  e.g. python3-django-foo
> > vs. python3-django.foo.
> > 
> > I'm sure it's a non-issue in practice.
> 
> this is a huge issue IMHO beacause Django submodules use global
> namespace and thus any unique django submodule name takes not so unique
> Python module name (i.e. they're installed under
> /usr/lib/python3/dist-packages/ now, not under
> /usr/lib/python3/dist-packages/django)

This is true but it's still a non-issue in practice because that kind of
conflict is usually detected and thus avoided at the pypi level.

And checking for file conflict is part of the job of the packager and we
have QA tools doing that kind of work too.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Binary naming for Django Related Packages

[Raphael Hertzog]

On Mon, 28 Nov 2016, Scott Kitterman wrote:
> > > Please let me know what you think.  I'm open to suggestions on wording. 
> > > I'd like to get this done in the next week and do a python-defaults
> > > upload with this and a few minor (non-policy) changes that are pending.

+1 from me. I'm actually the one who started this convention when I
packaged the first Django extension. When I look for available Django
extension, I like to be able to rely on the prefix.

> > [²] sys.path.append('/usr/lib/python3/django-packages/') in
> > django/__init__.py if django import always prepends other imports
> > (python3-django- namespace would be tolerable then, I guess)
> 
> I'm not one of the python-django uploaders, so we'd need their feedback on 
> [2].  I think something like that is a reasonable compromise if they are 
> willing to support it.

I certainly don't want to introduce this Debian-specific difference, no.
Django applications/extensions are meant to be managed via "pip" and they
must be available in the global namespace. I would not be surprised that
some of the extensions actually rely on being available globally...

I don't see any benefit to this change. The global namespace pollution
already exists at the upstream level, while we have to handle potential
conflicts, it's not up to us to preventively curate the namespace when
upstream has not followed the best practice (i.e. the "django_" prefix
in the module name).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Thu, 01 Jun 2017, Ian Campbell wrote:
> > https://anonscm.debian.org/cgit/python-modules/packages/python-django.git/commit/?id=ded34be
> 
> There's a typo in there:
> 
> +run tests with “-W errro” when you detect that you are running against the
> ^

Fixed, thanks.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Move to salsa? Team structure preview ready

[Raphael Hertzog]

On Thu, 08 Feb 2018, W. Martin Borgert wrote:
> No need to merge the subgroups ever.
> With this structure, it is one team already.
> 
> If there nobody objects, we have to:
>  - migrate the git archives (you volunteered, thanks!)

   - setup the webhook to close bugs
   - configure email on pushes to send commit mails to the package tracker
   - configure IRC notifications (irker?)

>  - ask for membership in the team (everybody)

This is not really needed. In fact I would suggest to de-activate the
"request to join" feature. It mails all "masters" (and all DD are masters
since they need to be able to create new repositories) and it doesn't
offer a way to explain why you need to join the team.

Instead one should go through alioth project members and add them directly
to salsa. And -guest users should create their accound and ask here to be
added (explaining that they were member before already).

But IMO alioth project members should be added to the "modules" sub-group
and not to the top-level group. Otherwise the "interpreter" subgroup will
have way too many members compared to what is desired.

>  - change Python team documentation (who?)

   - document how to setup new repositories (with the webhook, tracker
 integration, etc.)

>  - make an MR for https://salsa.debian.org/salsa/AliothRewriter (who?)
>  - ?
> 

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Move to salsa? Merge modules and apps team?

[Raphael Hertzog]

Hello,

On Wed, 07 Feb 2018, W. Martin Borgert wrote:
> how about moving the Python team(s) to salsa?

Definitely!

But we might want to learn from the perl team to structure the
python-team:
https://lists.debian.org/debian-perl/2018/01/msg00039.html

We could then have everything python related in the same team
but with different sub-groups for modules, applications
and interpreter.

> Moving git packages (modules team) is very easy using
> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git

I used those scripts with a small loop to migrate pkg-security
and it worked fine.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

New upstream version of python-xlwt

[Raphael Hertzog]

Hi,

ccing maintainers of reverse dependencies of python-xlwt. We
switched to a new upstream version (0.7.5 -> 1.3.0) so you might
want to check that your packages are still working with this new
version (rows, python-pandas,

On Thu, 26 Oct 2017, Thomas Goirand wrote:
> I've found out that antlr.py is embedded, and still in use in this
> upstream release. So I added a patch to remove it from upstream.

This change was not good. The embedded antlr.py is patched 
for xlwt. See https://github.com/python-excel/xlwt/issues/73

This change thus got reverted and I uploaded the resulting package
with a few more cleanups.

> However, the package was using git-dpm. As always, importing a new
> release with git-dpm is a nightmare. Therefore, before doing it, I
> simply removed all patches (as I thought no patch was needed). Now,
> what's the way to make it again so that the package uses git-dpm? Is it
> still needed these days, or is it ok to not do it in the team?

AFAIK it's OK to not use git-dpm. However it seems that the team
documentation would need an update... also since we haven't documented
the switch to salsa either.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: PAPT and DPMT membership request for moschlar-guest

[Raphael Hertzog]

Hi,

On Mon, 26 Mar 2018, Piotr Ożarowski wrote:
> [Moritz Schlarb, 2018-02-15]
> > please also add my user "moschlar-guest" to the respective Groups on Salsa.
> 
> looks like my thread is broken, I cannot find referenced emails. Do you
> accept our policy? Which packages do you want to work on?

Original email: https://lists.debian.org/debian-python/2017/01/msg00030.html

So it's about the "nagstamon" package.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Please add me to PAPT

[Raphael Hertzog]

Hello,

I'm part of the DPMT and I have already agreed to follow the policy.
However I'm not part of PAPT and I would like to join this team too
because at multiple times I have felt the need to update some packages
in that team and I just skipped doing it because I did not have access
to the git repositories.

So please add me ("hertzog") to
https://salsa.debian.org/python-team/applications

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

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Dropping Python 2 support for web.py before buster

[Raphael Hertzog]

Hi,

On Tue, 22 Jan 2019, Julien Danjou wrote:
> I'm not actively maintaining rebuildd for years now. I'm not even sure
> it has still any user.

FWIW, the Kali buildd do still use rebuildd.

> I wouldn't spend time on porting rebuildd nor I would let it block it
> updating web.py.
> Not sure what's the other solution would be (removal?) but if you have
> any idea, go ahead.

Anyway, the fact that we have one known user should not forbid you
to go forward with all this. I will change the Kali infrastructure
to use something else, most likely buildd and wannabuild.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: updating mechanize - help concerning tests with pybuild

[Raphael Hertzog]

Hi,

On Sun, 01 Sep 2019, Norbert Preining wrote:
> Fine with me. If you could give me DPMT membership on salsa I can push
> my current work there.

I can't grant you the right to the whole group (I'm not an owner) but
I created the repository and granted you the rights on this repository
at least:
https://salsa.debian.org/python-team/modules/python-mechanize

Let me know if you need anything else.

To get access to the group, you should follow the procedure described
in this document:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

> Do we go through package salvaging?
> https://wiki.debian.org/PackageSalvaging

I don't think it's required here. The bugs have been open for long enough
without any activity.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: updating mechanize - help concerning tests with pybuild

[Raphael Hertzog]

Hello,

On Sat, 31 Aug 2019, Norbert Preining wrote:
> I would be interested in adopting mechanize if the current maintainers
> / uploaders are fine with it. Or we put it into the python modules team
> and I do the stuff there. All is fine for me.

I would like to see the package in the python modules team as well. We
have packages in Kali depending on this module and we also need the Python
3 version.

Hence we also pinged the current maintainers here just one day before you:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912014#10

> How could be proceed here?

Looking at the status of the packages in the team, it's quite clear that
the team is MIA as a whole:
https://qa.debian.org/developer.php?email=pkg-zope-develop...@lists.alioth.debian.org

The only recent upload is from TANIGUCHI Takaki 
on zope.deprecation 4.4.0-1. It's also the only package

Thus I would suggest to go ahead and take over the package in the DPMT
team.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: updating mechanize - help concerning tests with pybuild

[Raphael Hertzog]

Hi,

On Sun, 01 Sep 2019, Norbert Preining wrote:
> At all: anything you want to see before I upload the new version?

I checked the package quickly (without building it), it looks good.
Maybe you could have bumped debhelper to 12 and standards-version to 4.4.0
but that's a minor detail.

Thanks for leading this!

Cheers,

> On September 1, 2019 9:43:33 AM GMT+09:00, Matthias Klose  
> wrote:
> >On 01.09.19 01:59, Norbert Preining wrote:
> >> Hi Raphael,
> >> 
> >> @Matthias, please read on.
> >> 
> >> On Sat, 31 Aug 2019, Raphael Hertzog wrote:
> >>> https://salsa.debian.org/python-team/modules/python-mechanize
> >> 
> >> Thanks, that is perfect. I pushed my work there, changed control VCS,
> >> maintainer, and uploader.
> >> 
> >> ATM I only put me into the uploaders. Please, those who are
> >interested,
> >> put yourself in there, thanks!
> >> 
> >>>> Do we go through package salvaging?
> >>>> https://wiki.debian.org/PackageSalvaging
> >>>
> >>> I don't think it's required here. The bugs have been open for long
> >enough
> >>> without any activity.
> >> 
> >> Hmmm... I don't feel confident simply uploading someone's else
> >package.
> >> Best would probably be if Matthias Klose, one of the current
> >Uploaders,
> >> agrees to that and uploads the current package thus passing over
> >> maintainership.
> >> 
> >> Matthias?
> >
> >did you see my comment in #936270?
> 
> 
> --
> PREINING Norbert http://www.preining.info
> Accelia Inc. + JAIST + TeX Live + Debian Developer
> GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Git, gbp blues

[Raphael Hertzog]

On Sun, 25 Aug 2019, Dmitry Shachnev wrote:
> The correct procedure is running “gbp pq import” *before* importing a new
> tarball. Then after importing you do “gbp pq rebase”.
> 
> Sometimes I myself forget to run “gbp pq import”. In this case I do the
> following:

Instead you should use "gbp pq import --time-machine=X" where X is the
number of commits that you accept to go backwards to try to find a point
where the patch series can be applied.

Then you are on your branch, ready for a rebase...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Streamlining the use of Salsa CI on team packages

[Raphael Hertzog]

Hi,

On Sun, 15 Sep 2019, Louis-Philippe Véronneau wrote:
> For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is
> the most mature solution, has more contributors and has more features
> (including reprotest and piuparts). This option seems to have had the
> most support so far.

Ack. I also deployed this pipeline on 500 Kali packages at
https://gitlab.com/kalilinux/packages/
and it has been working relatively well. There are a couple
of remaining issues but the project is evolving quickly and I'm
confident that we can get past them.

One of the issue is related to the fact that the CI build does not bump
the version and it can conflict with the version in the archive and it
will often confuse piuparts.
https://salsa.debian.org/salsa-ci-team/pipeline/issues/78

The project is a bit lacking in terms of leadership/guidance and there are
pending issues that should have been resolved more quickly to avoid
confusion and better define the rules:
https://salsa.debian.org/salsa-ci-team/pipeline/issues/84
https://salsa.debian.org/salsa-ci-team/pipeline/issues/76
https://salsa.debian.org/salsa-ci-team/pipeline/issues/86

> For step 2, so far people seemed to agree that:
> 
> * having a standardised CI pipeline is a good idea
> * the CI should be used as a tool to help us improve our packages, and
> not be required to pass

On this, I disagree. The CI should pass, but it's perfectly OK to
disable some of the failing tests to make it pass. We want merge requests
to run the CI and we want them to succeed to prove that they are not
making the package regress compared to the current situation.

Consider that the package tracker is likely to display the CI status at
some point.

Note that for merge request, it won't really work until 
https://gitlab.com/gitlab-org/gitlab/issues/30242 gets fixed in GitLab.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Merge Requests

[Raphael Hertzog]

On Fri, 06 Dec 2019, Louis-Philippe Véronneau wrote:
> On 19-12-06 04 h 34, Jonathan Carter wrote:
> > For other MRs, I noticed that many small changes in the packaging didn't
> > have an associated changelog entry with it, so I had to dch to add a
> > changelog entry. I think for small changes I'd prefer the person who
> > submits the MR to add them. For larger ones it probably makes sense not
> > to do that since it might take longer.
> 
> I rarely add a changelog entry when creating MRs, as I feel it often is
> a burden for the maintainers if the MR isn't immediately merged and new
> releases are made (creates merge conflicts, etc.).

And it's also painful when you use "gbp dch", having a commit in the
middle introduce a changelog entry means that the next "gbp dch" run
might miss some commits that need to be documented.

Not everybody is sold to the idea of using "gbp dch" but it's definitely
cleaner IMO. Commits that do not modify debian/changelog are also easier
to cherry-pick between different branches, etc.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes

[Raphael Hertzog]

On Mon, 11 May 2020, Sandro Tosi wrote:
> when i push i always do
> 
> $ git push --all ; git push --tags

To push only branches which are shared on both sides and the associated
tags I use this:
$ git push origin : --follow-tags

Which I alias as "git dpush" so I have this in ~/.gitconfig:

[alias]
dpush = push origin : --follow-tags
drelease = !gbp dch -R --commit

(I left my "git drelease" alias as well, I use it just before to update
the changelog...)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Move python-libusb1 from NEW/Unstable

[Raphael Hertzog]

Hello Mattia,

On Sun, 24 May 2020, Mattia Rizzolo wrote:
> On Sat, May 23, 2020 at 05:03:50PM -0700, debianb...@felinefamily.org wrote:
> > The package maintainer, Arnoud Fountaine uploaded the fix to the last
> > bug a week or so ago but it’s been stuck in the NEW queue ever since.
> > Is there anyone that can approve it so it can get moved to Sid
> 
> NEW is a manual process from the ftp-team.
> It can take from a few hours up to months, and it's not really something
> that can be prodded just to have a quicker backports.
> The queue is processed in a non specified order, and you can see it
> here: https://ftp-master.debian.org/new.html
> 
> *Usually* (not always!), if it's a small packages it is processed quite
> quickly, but poking the ftp team before not even a month has passed
> without a good reason (for example, it's blocking an RC bug fix) is just
> inappropriate.

I don't agree with your assessment. A month is a very long time and I have
prodded members of the FTP team way earlier than that when I had a reason.
And here a reason was given. I don't really see why you judge that reason
to not be a good reason.

Any reason which ends up as "it's blocking further work" is a good reason
IMO.

Mattia, I really appreciate what you have been doing in Debian but at
times I have the feeling that you keep alive the idea that some of the
most glaring deficiencies of Debian are "normal".

Please try to show some compassion to other contributors when they are
stuck. To me, the above response sounded like "yeah, that's normal, don't
complain, it's inappropriate". It would have been much better if it had
been worded as « It's unfortunate that this is blocking your work but
NEW is a manual process 
To speed up the process, you can try to prod ftpmasters on #debian-ftp
explaning your reason why you need it. I'm not convinced that a backport
passes the threshold justifying such a prod but you can always try. »

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Newcomers project: DPMT/PAPT pristine-tar verification

[Raphael Hertzog]

Hi,

On Fri, 10 Jul 2020, Sandro Tosi wrote:
> The checks i have in mind for now, are:
> 
> * pristine-tar branch must exist, if not -> it's a bug
> * pristine-tar + upstream branch must produce the same tarball as
> downloaded from the archive, if not -> it's a bug
> * bonus point: fix the repo if it doesn't generate the right tarball
> and or the branch is missing.
> * bonus point: make this into a service that runs regularly (not
> strictly necessary to be limited to us)

I would suggest that this would be a nice job for the janitor bot.
https://janitor.debian.net/

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Newcomers project: DPMT/PAPT pristine-tar verification

[Raphael Hertzog]

[ Putting Jelmer in copy ]

On Sun, 19 Jul 2020, Sandro Tosi wrote:
> On Sun, Jul 19, 2020 at 11:04 AM Raphael Hertzog  wrote:
> > On Fri, 10 Jul 2020, Sandro Tosi wrote:
> > > The checks i have in mind for now, are:
> > >
> > > * pristine-tar branch must exist, if not -> it's a bug
> > > * pristine-tar + upstream branch must produce the same tarball as
> > > downloaded from the archive, if not -> it's a bug
> > > * bonus point: fix the repo if it doesn't generate the right tarball
> > > and or the branch is missing.
> > > * bonus point: make this into a service that runs regularly (not
> > > strictly necessary to be limited to us)
> >
> > I would suggest that this would be a nice job for the janitor bot.
> > https://janitor.debian.net/
> 
> How would you suggest implementing this?

The janitor bot can be added to our salsa groups and he can be configured
to push changes directly instead of proposing merge requests.

All the above operations are simple automatable jobs that only result in
changes to the git repositories (mainly updates to the pristine-tar
branch).

I would thus suggest to add this functionality to the janitor and I
believe the right place for this is here:
https://jelmer.uk/code/silver-platter/tree/master/silver_platter/debian

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Transfer cherrytree from DPT to Debian group

[Raphael Hertzog]

Hello Andrius,

On Fri, 16 Oct 2020, Andrius Merkys wrote:
> Recently cherrytree [1] has been rewritten from Python to C++, thus it
> no longer belongs in DPT. Could someone with adequate permissions
> transfer it from DPT to generic Debian group on salsa.d.o?
> Alternatively, one could grant me permission to manage cherrytree so as
> I could transfer it myself.
> 
> [1] https://salsa.debian.org/python-team/packages/cherrytree

Transferring to another group requires owner rights on both the
source and the target group, and the "debian" group is owned only
by the salsa admins so you have to ask their help:
https://salsa.debian.org/salsa/support/-/issues

Regards,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#988658: RFP: python3-pyupgrade -- Automatically upgrade syntax for newer versions of the Python language

[Raphael Hertzog]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org

* Package name: python3-pyupgrade
  Version : 2.16.0
  Upstream Author : Anthony Sottile 
* URL : https://github.com/asottile/pyupgrade
* License : BSD
  Programming Lang: Python
  Description : Automatically upgrade syntax for newer versions of the 
Python language

This helper script can help you normalize your Python source code
by rewriting parts of your code to use the latest syntax improvements.

Some examples from the README:

set([])  # set()

'{0} {1}'.format(1, 2)# '{} {}'.format(1, 2)

x is 5  # x == 5

'{foo} {bar}'.format(foo=foo, bar=bar)  # f'{foo} {bar}'


I discovered this tool by reading some documentation and I'd like
it to be available in Debian so that I can try it and use it :-)

ccing debian-python@lists.debian.org in the hope to catch the attention of
someone with more time than me.

Thank you!

-- 
Raphaël Hertzog

Re: Python package situation

[Raphael Hertzog]

Hi,

On Wed, 17 Feb 2021, Brian May wrote:
> I believe there are a number of Python packages in Debian unstable that
> are out of date in respect to latest upstream.
> 
> e.g.
> https://qa.debian.org/developer.php?login=bam%40debian.org=yes
> 
> Somebody needs to do the work to update them. But maybe the fact that
> nobody is doing so, might mean that nobody is using them?

Quite often, we introduce Python packages for the need of a specific
application and then we don't really see a benefit to upgrade the package
unless the application also needs a newer version of the module.

That likely explains partly why so many modules are lagging behind.

> I personally found a while back that keeping these packages up-to-date
> was draining far too much of my time. Time I don't actually have. So I
> now use Docker+pip for my applications.

On the Kali side, I'm trying to work with Jelmer and his janitor bot to
try to automate as much as possible the work of preparing new upstream
releases. We're getting close to having something useful where the bot
does at least the upstream tarball import and a test rebuild and so on.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: upstream python concerns, python3-full package for bullseye

[Raphael Hertzog]

On Fri, 12 Feb 2021, Thomas Goirand wrote:
> What I read from Elana, is that *upstream* think we have a problem. But
> do we really have one? Or are we just being influenced by upstream who
> is trying to impose a view we don't necessary share?

Or is it you that is trying to impose your view on those users?

Let's be clear, I understand what you are saying and I mostly agree
with your view but Debian is about inclusiveness and about meeting
the needs of as many people as possible and I believe that implementing
this python3-full meta-package can only help towards this.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Looking for Python developers that want to improve Debian

[Raphael Hertzog]

Hey people,

I wanted to share the Freexian announce that I just published in my blog:
https://raphaelhertzog.com/2022/03/29/join-freexian-to-help-improve-debian/

We are a small team of Debian developers/contributors. We are bound by
our mission statement:

> Freexian's mission is to help Debian evolve to be the leading Linux
> distribution and a model to follow in the free software world.
> 
> We want to achieve that by enabling passionate contributors to spend most
> of their time working on Debian and free software, combining lucrative
> work in support of enterprise customers, core contributions to Debian's
> processes, and personal goals.

We would like to grow our team to tackle new challenges and we are looking
for Python developers since all our new developments are done with Python. 

I can't promise working only with Python because our main revenue
stream comes from LTS and ELTS so any candidate will have to provide
security updates in a multitude of programming languages.

If any of this sounds interesting to you, please reach out to us at
gera...@freexian.com. 

Cheers,

PS: Take the time to read the full mission statement:
https://www.freexian.com/apropos/index.html#mission
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature