Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #7951 > unrolled thread

Rebuild for packages with entry points?

Back to article view | Back to linux.debian.maint.python

Contents

  Rebuild for packages with entry points? Nikolaus Rath <Nikolaus@rath.org> - 2015-12-07 19:30 +0100
    Re: Rebuild for packages with entry points? Barry Warsaw <barry@debian.org> - 2015-12-07 20:10 +0100
      Re: Rebuild for packages with entry points? Simon McVittie <smcv@debian.org> - 2015-12-07 22:10 +0100
        Re: Rebuild for packages with entry points? Nikolaus Rath <Nikolaus@rath.org> - 2015-12-08 18:00 +0100
          Re: Rebuild for packages with entry points? Simon McVittie <smcv@debian.org> - 2015-12-09 01:40 +0100
      Re: Rebuild for packages with entry points? Nikolaus Rath <Nikolaus@rath.org> - 2015-12-08 17:50 +0100
        Re: Rebuild for packages with entry points? Barry Warsaw <barry@debian.org> - 2015-12-08 18:00 +0100
          Re: Rebuild for packages with entry points? Nikolaus Rath <Nikolaus@rath.org> - 2015-12-08 23:10 +0100
            Re: Rebuild for packages with entry points? Piotr Ożarowski <piotr@debian.org> - 2015-12-09 09:40 +0100
    Re: Rebuild for packages with entry points? Brian May <bam@debian.org> - 2015-12-09 07:10 +0100

#7951 — Rebuild for packages with entry points?

Hello,

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...


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.«

[toc] | [next] | [standalone]

#7952

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.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#7953

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. Conveniently, Python's re uses
Perl-compatible regular expressions, so many Python developers are
probably already familiar with the syntax.

    S

[toc] | [prev] | [next] | [standalone]

#7956

On Dec 07 2015, Simon McVittie <smcv@debian.org> 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.«

[toc] | [prev] | [next] | [standalone]

#7959

On 08/12/15 16:50, Nikolaus Rath wrote:
> On Dec 07 2015, Simon McVittie <smcv@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#7955

On Dec 07 2015, Barry Warsaw <barry@debian.org> 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.«

[toc] | [prev] | [next] | [standalone]

#7957

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

[toc] | [prev] | [next] | [standalone]

#7958

On Dec 08 2015, Barry Warsaw <barry@debian.org> 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.«

[toc] | [prev] | [next] | [standalone]

#7962

[Nikolaus Rath, 2015-12-08]
> 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

it's not always true in case of bandwidth price, though
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

[toc] | [prev] | [next] | [standalone]

#7960

Nikolaus Rath <Nikolaus@rath.org> 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 <bam@debian.org>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web