Joining DPMT / PAPT

2015-12-08 Thread Pierre Equoy
Hello!

I've been working on packaging and maintaining Checkbox [1] packages.

I would like to join the Debian Python Modules Team and the Python
Applications Packaging Team in order to maintain the Checkbox-related
packages on Debian.

My Alioth login is pierre-equoy-guest.

I have read and accept the policy if this team:
https://python-modules.alioth.debian.org/policy.html

Regards,

[1]: https://launchpad.net/checkbox

-- 
Pierre Equoy
QA & Certification Engineer | Canonical
www.canonical.com | www.ubuntu.com



Re: Rebuild for packages with entry points?

2015-12-08 Thread Nikolaus Rath
On Dec 07 2015, Simon McVittie  wrote:
> On 07/12/15 19:00, Barry Warsaw wrote:
>> On Dec 07, 2015, at 10:22 AM, Nikolaus Rath wrote:
>>> It'd be nice to have https://bitbucket.org/pypa/setuptools/issues/443/
>>> fixed in stretch.
>> 
>> I'm also not sure how many packages it affects in practice.  We could also 
>> let
>> rebuilds be bug-driven.
>
> This looks like a job for Lintian, assuming setuptools entry points are
> easy to detect with a regex.

Well, yes, but what's the point? New uploads will not be affected by
this bug anyway, and if you just want the warnings for old packages,
wouldn't the time consumed by writing a Lintian check be better spent
writing a script that triggers rebuilds directly?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«



Re: Rebuild for packages with entry points?

2015-12-08 Thread Nikolaus Rath
On Dec 07 2015, Barry Warsaw  wrote:
> On Dec 07, 2015, at 10:22 AM, Nikolaus Rath wrote:
>
>>Would it make sense to do a no-change rebuild for all Python packages
>>that use setuptool's entry point functionality?
>>
>>It'd be nice to have https://bitbucket.org/pypa/setuptools/issues/443/
>>fixed in stretch. I believe most packages will see new releases anyway
>>(and thus get the change), but I believe there are at least some
>>packages that are rarely touched...
>
> I'm also not sure how many packages it affects in practice.  We could also let
> rebuilds be bug-driven.

Aeh, you know about a bug and you want to delay fixing it until someone
has reporeds it for every affected package? This seems like a pretty
inconsiderate waste of time for both users and maintainers.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«



Re: Rebuild for packages with entry points?

2015-12-08 Thread Barry Warsaw
On Dec 08, 2015, at 08:48 AM, Nikolaus Rath wrote:

>Aeh, you know about a bug and you want to delay fixing it until someone
>has reporeds it for every affected package? This seems like a pretty
>inconsiderate waste of time for both users and maintainers.

There are always lots of bugs that affect people.  But hey, don't let me stop
you if you want to fix this particular one.

Cheers,
-Barry



Re: Rebuild for packages with entry points?

2015-12-08 Thread Simon McVittie
On 08/12/15 16:50, Nikolaus Rath wrote:
> On Dec 07 2015, Simon McVittie  wrote:
>> This looks like a job for Lintian, assuming setuptools entry points are
>> easy to detect with a regex.
> 
> Well, yes, but what's the point? New uploads will not be affected by
> this bug anyway, and if you just want the warnings for old packages,
> wouldn't the time consumed by writing a Lintian check be better spent
> writing a script that triggers rebuilds directly?

If you already know a complete set of packages that have entry points,
sure, rebuild away. For binNMUs of arch:any packages the thing to do is
to ask the release team; for arch:all packages, it needs to be done as
individual sourceful uploads, unfortunately.

If you don't already know a complete set of affected packages, a Lintian
check + a bit of waiting would tell you, with progress tracking. I've
found that very useful for various issues with dbus policy files.

S



Re: Rebuild for packages with entry points?

2015-12-08 Thread Brian May
Nikolaus Rath  writes:

> Would it make sense to do a no-change rebuild for all Python packages
> that use setuptool's entry point functionality?

Not that I even pretent to understand what this bug is about. Why are
tests even using these wrappers? They aren't intended to be imported.

However this isn't automatically going to fix all packages. There are
some packages (e.g. python-django-common provides django-admin) that
replace the wrapper with a Debian specific copy of the file that can
automatically choose the Python2.7 or Python3 interpreter as required.

This particular example is not a good one, django-admin looks like it is
already fine. celery does something similar, and it looks fine to. So
rebuilding these packages won't do anything, because they are already
OK.

My point being however that just rebuilding the package is not a
guarantee that this problem will be solved.
-- 
Brian May 



Multiarch-renamed python extensions not found during autopkgtest testing

2015-12-08 Thread Afif Elghraoui
Hi, debian-python,

For Debian Med's python packages that have compiled extensions, I
noticed that test suites run via autopkgtest fail because the package
cannot find those extensions, as they've been renamed with the multiarch
triplet.

It seems to only be a problem with autopkgtest because I have in one
case manually installed such a package and successfully ran its test
suite. I therefore reported #798066 [1] against autopkgtest, but quite
some time has elapsed since then and I'd like to get this resolved.

Does anyone know why this might be the case? Autopkgtest for these
packages is currently not very helpful because there are many spurious
failures due to this issue. There are more details in my original bug
report [1].

Many thanks and regards
Afif

1. http://bugs.debian.org/798066

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name



Re: Rebuild for packages with entry points?

2015-12-08 Thread Nikolaus Rath
On Dec 08 2015, Barry Warsaw  wrote:
> On Dec 08, 2015, at 08:48 AM, Nikolaus Rath wrote:
>
>>Aeh, you know about a bug and you want to delay fixing it until someone
>>has reporeds it for every affected package? This seems like a pretty
>>inconsiderate waste of time for both users and maintainers.
>
> There are always lots of bugs that affect people.

True - but I have to admit that I don't get the connection to what we
(or at least I) were discussing until now..?

> But hey, don't let me stop you if you want to fix this particular one.

Well, my proposal is to just do a mass rebuild. It will be redundant for
a lot of packages, but computer time is much cheaper than developer time
(which would be required for Lintian checks, or writing, reacting to,
and closing per-package bugreports).

However, I don't know how to trigger such a rebuild, and I think if I
knew it I'd still be unable to actually do it because I'm only a
DM. Thus my mail to this list :-).


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«