[gentoo-python] Re: [gentoo-commits] gentoo-x86 commit in dev-python/logilab-common: logilab-common-0.59.1.ebuild ChangeLog

[Mike Gilbert]

On Wed, Jun 26, 2013 at 8:30 AM, IAN DELANEY <della5@×××××××××.au> wrote:
> On Mon, 24 Jun 2013 23:21:45 -0400
> Mike Gilbert <floppym@g.o> wrote:
>
>> On Tue, Jun 18, 2013 at 10:55 AM, Ian Delaney (idella4)
>> <idella4@g.o> wrote:
>> > idella4     13/06/18 14:55:23
>> >
>> >   Modified:             logilab-common-0.59.1.ebuild ChangeLog
>> >   Log:
>> >   add py3.3 support
>> >
>> >   (Portage version: 2.1.11.63/cvs/Linux x86_64, signed Manifest
>> > commit with key 0xB8072B0D)
>> >
>> > Revision  Changes    Path
>> > 1.2
>> > dev-python/logilab-common/logilab-common-0.59.1.ebuild
>> >
>> > file :
>> > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/logilab-common/logilab-common-0.59.1.ebuild?rev=1.2&view=markup
>> > plain:
>> > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/logilab-common/logilab-common-0.59.1.ebuild?rev=1.2&content-type=text/plain
>> > diff :
>> > http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/logilab-common/logilab-common-0.59.1.ebuild?r1=1.1&r2=1.2
>> >
>> > Index: logilab-common-0.59.1.ebuild
>> > ===================================================================
>> > RCS
>> > file: /var/cvsroot/gentoo-x86/dev-python/logilab-common/logilab-common-0.59.1.ebuild,v
>> > retrieving revision 1.1 retrieving revision 1.2
>> > diff -u -r1.1 -r1.2
>> > --- logilab-common-0.59.1.ebuild        22 Apr 2013 07:18:10
>> > -0000      1.1 +++ logilab-common-0.59.1.ebuild        18 Jun 2013
>> > 14:55:23 -0000      1.2 @@ -1,10 +1,10 @@
>> >  # Copyright 1999-2013 Gentoo Foundation
>> >  # Distributed under the terms of the GNU General Public License v2
>> > -#
>> > $Header: /var/cvsroot/gentoo-x86/dev-python/logilab-common/logilab-common-0.59.1.ebuild,v
>> > 1.1 2013/04/22 07:18:10 patrick Exp $ +#
>> > $Header: /var/cvsroot/gentoo-x86/dev-python/logilab-common/logilab-common-0.59.1.ebuild,v
>> > 1.2 2013/06/18 14:55:23 idella4 Exp $
>> >
>> >  EAPI=5
>> >  # broken with python3.3, bug #449276
>> > -PYTHON_COMPAT=( python{2_6,2_7,3_2} pypy{1_9,2_0} )
>> > +PYTHON_COMPAT=( python{2_6,2_7,3_2,3_3} pypy{1_9,2_0} )
>> >
>>
>> Why did you choose to ignore the comment above telling you that the
>> package is broken with python3.3?
>>
>> It seems pretty clear that this was not tested properly; the pytest
>> command immediately dies with the same error that is listed in the bug
>> report.
>>
>
> That would be a no.  I always test and test b4 a commit, and frankly 8
> days ago is long enough that I can't recall since I've worked so many
> bumps and testsuites.  Here you have really utterly lost me.  the
> package may be broken, or the testsuite may be mis-matched to py3.3.
> Option 1 proves you right, option 2 makes for the testsuite needs
> fixing.   Considering I spend 90 % of my time working testsuites in
> python, there is ample evidence that option 2 is quite a likely
> candidate.  Python is riddled with packages that fail testsuites, no
> matter how many I seem to fix, it seems to make little impression.  Why
> is logilab-common suddenly so precious?
>

Actually, in the case of logilab-common, both "option 1" and "option
2" are valid. The package is broken, and this causes the test suite to
fail.

The logilab-common package installs the pytest script. The pytest
script blows up when invoked under python3.3.

The logilab-common ebuild invokes pytest script to run its own test
suite. Thus, the test suite was also broken with python3.3.

>> Also, since logilab-common is broken with python3.3, that breaks astng
>> and pylint, which you also updated.
>
> Now what are we about here?  Bringing py3.3 into the fold or not?  Sure
> it makes sense to leave it on hold if it's actually broken, so frankly
> this makes for, despite after all this time and migrates and
> bumps, it hasn't been made clear that py3.3 need pass a testsuite,
> otherwise it's left on hold.  I just can't see how this could occur
> weeks after unmasking py3.3 and beginning to add it to ebuilds as
> mgorny appeared to expect.
>

If the test suite fails for a given python version, you should not add
it to PYTHON_COMPAT. This applies to both masked and unmasked versions
of python. I don't know where you got the idea that we treat masked or
~arch python versions differently in this regard.

There may be exceptions to this if you provide a reasonable
explanation. I have not seen one here.

> It's possible that I missed making it
>         if [[ "${EPYTHON}" == 'python3.3' ]]; then
>                 einfo "python3.3 has failures in testsuite"
> as I said being now 8 days.  I seem to recall adding that to something
> somewhere.
>

Adding python3_3 to PYTHON_COMPAT and then disabling the tests with
that python version is generally unacceptable. Again, there are
exceptions if you know what you are doing.

It certainly is not acceptable for logilab-common.

> So for the inside running on the testsuite buckling.
> # https://www.logilab.org/ticket/144526 was set by 1 Sean Santos, and
> the reviewed patch that passed by upstream oddly is a sham.
> Sean Santos gave them the key and he who patched it missed using it, so
> I made one that works for that issue.  Fixing that sadly simply opened
> the gate to the next point where it stumbled.
> https://www.logilab.org/ticket/149345.
> This makes me wonder whether upstream are dropping the ball in writing
> their testsuites and not making them py3.3 capable.
>

This was not a problem caused by a broken test case; the test suite
errors out because the package itself is broken. There's a huge
difference.

> On further tree updates and futile attempts to figure out just what
> went awry, the net result a sham.
> As for pylint, I'm not even goin' there

Regarding pylint: If you will not to justify your actions or admit
that you made a mistake and change your actions moving forward, then
please stop committing things. I'm happy to have your help in bumping
packages, but throwing your hands up because I pointed out a problem
is not good.