[gentoo-dev] cmake-utils.eclass and bug 475502

[gentoo-dev] cmake-utils.eclass and bug 475502

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know there was an announcement about the upcoming change to
cmake-utils.eclass, however... it is not enough to give a deadline
without caring if people actually fixed it by then.

By doing that you risk breaking stable packages which is not trivial.

You _must_ do a tinderbox run, test that stuff in an overlay or
whatever. You are responsible for ALL reverse deps.

The way it was done... was not appropriate. Please be more careful
next time. There are still incoming bugs about broken base_src_*
calls. (see the tracker)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR5wUcAAoJEFpvPKfnPDWzaqsIAJT1Rukvn6waAxCR/YX7EJ3C
0KX5WoB+IE9Whuf9/EdUmHegp23S3hB6C2dJU3z7CX+QiVGHmqTxXTGT0KB7uaHI
deLfmzG6eL+9kSPfVYaf/PuKWVCvNnUBvr0d51NV92VfNuqDasxlTSfxJySv93wU
82P9VAuyPS18kJNRqBy698lhbH8KHybHkqfilkmHQ9tyh65sDK2I6F3QtS6JLc8B
PFoh0JyjSpJKfrCjQDKJuaEV8x5JEFjiklsXAdcrzdyt1gtbhFHXrHw1F1PMoXBp
W7QFsQBpXleHinnJVi1QAU/YVMtuUhJwUmgxv6z2NzlJ2TrCL/eusKwYZNXEQLk=
=NLqH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Chris Reffett]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/17/2013 04:57 PM, hasufell wrote:
> I know there was an announcement about the upcoming change to 
> cmake-utils.eclass, however... it is not enough to give a deadline 
> without caring if people actually fixed it by then.
> 
> By doing that you risk breaking stable packages which is not
> trivial.
> 
> You _must_ do a tinderbox run, test that stuff in an overlay or 
> whatever. You are responsible for ALL reverse deps.
> 
> The way it was done... was not appropriate. Please be more careful 
> next time. There are still incoming bugs about broken base_src_* 
> calls. (see the tracker)
> 

I discussed this with hasufell on IRC, but I'll lay out the response
on the list too. Yes, this was my fault. We (KDE team) tested in our
overlay, but none of the packages there use the base_src_* calls,
which is why it didn't come up in testing, and I did not realize that
there were packages that did rely on the implicit base inherit to call
base_src_* directly.

Chris Reffett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlHnCfVfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T6ZACcC5cDNBCODxrnzlPCTm+L4EgS
wCkAniqjyBFXhIXeXyb0Wbvufkbw68yS
=QM3o
-----END PGP SIGNATURE-----

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/17/2013 05:17 PM, Chris Reffett wrote:
> On 07/17/2013 04:57 PM, hasufell wrote:
>> I know there was an announcement about the upcoming change to 
>> cmake-utils.eclass, however... it is not enough to give a deadline 
>> without caring if people actually fixed it by then.
> 
>> By doing that you risk breaking stable packages which is not
>> trivial.
> 
>> You _must_ do a tinderbox run, test that stuff in an overlay or 
>> whatever. You are responsible for ALL reverse deps.
> 
>> The way it was done... was not appropriate. Please be more careful 
>> next time. There are still incoming bugs about broken base_src_* 
>> calls. (see the tracker)
> 
> 
> I discussed this with hasufell on IRC, but I'll lay out the response
> on the list too. Yes, this was my fault. We (KDE team) tested in our
> overlay, but none of the packages there use the base_src_* calls,
> which is why it didn't come up in testing, and I did not realize that
> there were packages that did rely on the implicit base inherit to call
> base_src_* directly.

...and that is why it isn't permitted to directly use an eclass that you
don't inherit.  While I agree testing could (should) have been better,
the fact that people ignore the rules for writing ebuilds shouldn't
entirely fall on the KDE team.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5wyLAAoJEKXdFCfdEflK0LsP/3nXF+sRXcrRBmkysF7mLGjP
7iJ9Wwh2VkJyPihYxvG1O7YQkoMr+ohiQvMg6a0SbK6CPzND6Wu2d80r9/5DUUOx
NUqvtbX+SdNIj/VgoYC4aDuS6ln+3BDENR5JT90jfs1v7HNh1G/bSA78ppj1cDS7
Hsnym7pQxRYLnQuDbitVeFKp2UHBchXAkoaW8QJ/pf4FQwiXX0JXmOdt+ogCICGC
W6YP4fbt4zv4zKpt3AFD9jKXle4wcCoAXjixOIfdWSURy+BFWGDJXOKuPsqaXFki
U4qlbOI6xrf7l5ApmjZOndfarqGiwSfxV3qOLKglyHQp3I63FXfAqiVvH6uz8g2L
YVXqZ7BrkZKMADfR+Ha8nHbyW0CX0Z4iK62P/BPH4aLfLPzJKZa6804++a2i7Vx/
0EfB4rSSYC6IAMWhSxCJD5SL0q1MBefNAGFttVO5gGMUbyoIZ2YGd4fNW6bLFffu
Ca3twnU5yvvjn9auofWsh6Mji6U76L4xcVN/SUSI4ASC1q0GtPs6BbHI+WY4mo40
lYJUe3wXK3LgUfdDcrw9LennsO71lE96OuM1dhwxqrnIexAyKKIBMQtzIzYekBJx
Q3D6s3sCtxgOOhbDpWFp1rEohmHLY6SJzbMW9+BbN6+rEqZw0o11DYivOfiwSwso
wgRZQ55XSKzpZVPdifhp
=q7zW
-----END PGP SIGNATURE-----

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote:
> On 07/17/2013 05:17 PM, Chris Reffett wrote:
>> On 07/17/2013 04:57 PM, hasufell wrote:
>>> I know there was an announcement about the upcoming change to 
>>> cmake-utils.eclass, however... it is not enough to give a
>>> deadline without caring if people actually fixed it by then.
> 
>>> By doing that you risk breaking stable packages which is not 
>>> trivial.
> 
>>> You _must_ do a tinderbox run, test that stuff in an overlay or
>>>  whatever. You are responsible for ALL reverse deps.
> 
>>> The way it was done... was not appropriate. Please be more
>>> careful next time. There are still incoming bugs about broken
>>> base_src_* calls. (see the tracker)
> 
> 
>> I discussed this with hasufell on IRC, but I'll lay out the
>> response on the list too. Yes, this was my fault. We (KDE team)
>> tested in our overlay, but none of the packages there use the
>> base_src_* calls, which is why it didn't come up in testing, and
>> I did not realize that there were packages that did rely on the
>> implicit base inherit to call base_src_* directly.
> 
> ...and that is why it isn't permitted to directly use an eclass
> that you don't inherit.  While I agree testing could (should) have
> been better, the fact that people ignore the rules for writing
> ebuilds shouldn't entirely fall on the KDE team.
> 

It doesn't matter in the slightest whos fault it is or who should be
blamed.

It is about maintaining stability for the user. Especially when it
comes to stable ebuilds.

That means the methods for eclass changes must be more thoroughly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR5w3sAAoJEFpvPKfnPDWzPLEH/jXlCgVFOFT2lj3OPxjE8E7o
6IFEPMFUwlEvWHGnCXG2Go8f9UEUxinvzfE6x0K8IT2NrffBbTjDvM1n/aJmNMkf
89pLjCqsra6iM4WJhIGxoXq/lIJcoJ3dJkxMS6kz7U0VWeH2wTAY0pQ/qIlJ3e30
XHcXhQZP9LzD1GEA43v0bO9FRYuh/zjJpzNVGHsj3jUmijQsglYyMSN8YGS4vBbe
y5gCHZcsjMOWkRlzUsCd0qn3EF6WgUzs9Ty7MreRDoI4pfvxcVu0PrhcrciLOCzx
2OHylKFU6btOJpUrjYJbUss+53jfPWLvo8AThz/I6ClItJxGjNsrDukpdtXXH6A=
=Tc2N
-----END PGP SIGNATURE-----

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/17/2013 05:34 PM, hasufell wrote:
> On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote:
>> On 07/17/2013 05:17 PM, Chris Reffett wrote:
>>> On 07/17/2013 04:57 PM, hasufell wrote:
>>>> I know there was an announcement about the upcoming change to 
>>>> cmake-utils.eclass, however... it is not enough to give a
>>>> deadline without caring if people actually fixed it by then.
> 
>>>> By doing that you risk breaking stable packages which is not 
>>>> trivial.
> 
>>>> You _must_ do a tinderbox run, test that stuff in an overlay or
>>>>  whatever. You are responsible for ALL reverse deps.
> 
>>>> The way it was done... was not appropriate. Please be more
>>>> careful next time. There are still incoming bugs about broken
>>>> base_src_* calls. (see the tracker)
> 
> 
>>> I discussed this with hasufell on IRC, but I'll lay out the
>>> response on the list too. Yes, this was my fault. We (KDE team)
>>> tested in our overlay, but none of the packages there use the
>>> base_src_* calls, which is why it didn't come up in testing, and
>>> I did not realize that there were packages that did rely on the
>>> implicit base inherit to call base_src_* directly.
> 
>> ...and that is why it isn't permitted to directly use an eclass
>> that you don't inherit.  While I agree testing could (should) have
>> been better, the fact that people ignore the rules for writing
>> ebuilds shouldn't entirely fall on the KDE team.
> 
> 
> It doesn't matter in the slightest whos fault it is or who should be
> blamed.
> 
> It is about maintaining stability for the user. Especially when it
> comes to stable ebuilds.
> 
> That means the methods for eclass changes must be more thoroughly.
> 
I completely agree with you, the changes should have been tested better.
 The ebuilds with these errors popping up ALSO should have been tested
better.  Considering this is a QA violation, perhaps it is possible to
add a check in repoman for using something from an eclass which you
didn't inherit.  I doubt the slowdown would be horrible and clearly it
would catch a huge number of QA violations.

I'm not saying this isn't bad, I'm not saying KDE team didn't mess up,
I'm saying a lot of people messed up and the not well enough tested
eclass change found a lot of QA violations which should have been caught
much earlier.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5w/IAAoJEKXdFCfdEflKUQ4P/24f/wkmQHCFskq2P+b8xgpY
PpRkE4XV/AV4oYRFWJ0HNmPcx1gqNVHdjED8yhQ8JqEPFJbgMWRMa1vfkY84Qkqb
b4CIDcmCd1A9jkdFtP6llgCSP/ub0cokB9O1Cb5kAZrDy+VzctB81x6X2uuUF53N
dcoVEga4gqZf5W4RBBE5R7yneB92K5bZjulQsPG22pAfWmKCoVUoaPOh4c104mXt
r+qMboTdHhfNldYdTykKQy5wSMERpKxzPBw9sG3ON96qajSD9nnmVzCVmWZrixfG
WJWf2G5RhLoIjjGPR0d9wUp5w212W7E6OVIpbeye5nX/YpePEYL4YAboAPbBs9Ws
XRWJOpy+/+W4Wr7J+pic41S96w2r31kBoXRpR6+Qrn+JZAaWbRBMadqVhHnYJx+w
cxOFhpKnJRF7l0t76wRevUMoD4aMRi3ZqEjH6SdqIJ9QHq40k6fITrmahq5k8Y24
TZOsGVpGi1XhrjrSfNXnVy9Dstjf5D6W39nzYQI+AaXURynV276fb/BPABHdoRuR
4eITAA6vIQ6rxoTAsOjmy+w2ySOzJkEVK0WrrcaJJAxhu1+ztjmcaq9d5kO7mdIt
5iyEcgNielhrf7wkpe+yM0SwhE5h1/+znhMRgxMAwuktWxK43KMBV39G28b9XMb6
LjG8NvQO4K4LGeNOhWAA
=elf2
-----END PGP SIGNATURE-----

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/17/2013 11:42 PM, Rick "Zero_Chaos" Farina wrote:
> On 07/17/2013 05:34 PM, hasufell wrote:
>> On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote:
>>> On 07/17/2013 05:17 PM, Chris Reffett wrote:
>>>> On 07/17/2013 04:57 PM, hasufell wrote:
>>>>> I know there was an announcement about the upcoming change
>>>>> to cmake-utils.eclass, however... it is not enough to give
>>>>> a deadline without caring if people actually fixed it by
>>>>> then.
> 
>>>>> By doing that you risk breaking stable packages which is
>>>>> not trivial.
> 
>>>>> You _must_ do a tinderbox run, test that stuff in an
>>>>> overlay or whatever. You are responsible for ALL reverse
>>>>> deps.
> 
>>>>> The way it was done... was not appropriate. Please be more 
>>>>> careful next time. There are still incoming bugs about
>>>>> broken base_src_* calls. (see the tracker)
> 
> 
>>>> I discussed this with hasufell on IRC, but I'll lay out the 
>>>> response on the list too. Yes, this was my fault. We (KDE
>>>> team) tested in our overlay, but none of the packages there
>>>> use the base_src_* calls, which is why it didn't come up in
>>>> testing, and I did not realize that there were packages that
>>>> did rely on the implicit base inherit to call base_src_*
>>>> directly.
> 
>>> ...and that is why it isn't permitted to directly use an
>>> eclass that you don't inherit.  While I agree testing could
>>> (should) have been better, the fact that people ignore the
>>> rules for writing ebuilds shouldn't entirely fall on the KDE
>>> team.
> 
> 
> Considering this is a QA violation, perhaps it is possible to add a
> check in repoman for using something from an eclass which you 
> didn't inherit.  I doubt the slowdown would be horrible and clearly
> it would catch a huge number of QA violations.
> 

That will yield false positives. Some eclases are explicitly designed
in a way that you do NOT need to directly inherit it's helpers such as
python-r1 and python-utils-r1.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR5xECAAoJEFpvPKfnPDWzzRQH/RbkJCvLvpvdLHnb6grJWf3K
hiKYl2ee5ziqPgx2rLY6HY6L2QN2XuKJ2nmUluvi8s7OIqnKvcH7l3HSJzK5d+2C
48FNmacLvOJPVpN3cw5h1uH3Jcff0lFXtcYaPBDNlMoYdbY+b3ad+AbXpTHR9rBX
UkM7W8ung1cH30oed8HZreK4a+6G+8MsqJbZlHJhnAstyWWklIUrpgvKo2kiorfl
fPvtWhz05hxRUji/Nv3rf4gln9o2MPj0/pa9KZNTKqvBZtX/3SRWVCWvMH6xqXDw
zQa4pYwkYdbiFS3WW6p08D9I3vMQ/gJ0ZY51OVTVLAVYBrWqd5WA4r4CT7x9QTI=
=2B+w
-----END PGP SIGNATURE-----

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/17/2013 05:47 PM, hasufell wrote:
> On 07/17/2013 11:42 PM, Rick "Zero_Chaos" Farina wrote:
>> On 07/17/2013 05:34 PM, hasufell wrote:
>>> On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote:
>>>> On 07/17/2013 05:17 PM, Chris Reffett wrote:
>>>>> On 07/17/2013 04:57 PM, hasufell wrote:
>>>>>> I know there was an announcement about the upcoming change
>>>>>> to cmake-utils.eclass, however... it is not enough to give
>>>>>> a deadline without caring if people actually fixed it by
>>>>>> then.
> 
>>>>>> By doing that you risk breaking stable packages which is
>>>>>> not trivial.
> 
>>>>>> You _must_ do a tinderbox run, test that stuff in an
>>>>>> overlay or whatever. You are responsible for ALL reverse
>>>>>> deps.
> 
>>>>>> The way it was done... was not appropriate. Please be more 
>>>>>> careful next time. There are still incoming bugs about
>>>>>> broken base_src_* calls. (see the tracker)
> 
> 
>>>>> I discussed this with hasufell on IRC, but I'll lay out the 
>>>>> response on the list too. Yes, this was my fault. We (KDE
>>>>> team) tested in our overlay, but none of the packages there
>>>>> use the base_src_* calls, which is why it didn't come up in
>>>>> testing, and I did not realize that there were packages that
>>>>> did rely on the implicit base inherit to call base_src_*
>>>>> directly.
> 
>>>> ...and that is why it isn't permitted to directly use an
>>>> eclass that you don't inherit.  While I agree testing could
>>>> (should) have been better, the fact that people ignore the
>>>> rules for writing ebuilds shouldn't entirely fall on the KDE
>>>> team.
> 
> 
>> Considering this is a QA violation, perhaps it is possible to add a
>> check in repoman for using something from an eclass which you 
>> didn't inherit.  I doubt the slowdown would be horrible and clearly
>> it would catch a huge number of QA violations.
> 
> 
> That will yield false positives. Some eclases are explicitly designed
> in a way that you do NOT need to directly inherit it's helpers such as
> python-r1 and python-utils-r1.
> 
> 
It is my understanding that if you directly use a function from an
eclass you are REQUIRED to inherit that eclass.  Given that kind of
sanity would have prevented these failures I find it difficult to
believe my understanding is wrong, but I am willing to learn.

I think I'll start inheriting base.eclass so I can use multilib
functions.  I mean, base.eclass inherits eutils.eclass which inherits
multilib.eclass so it should work out fine, right?

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5xLGAAoJEKXdFCfdEflKe/sP/jo7mFijN9jzpbK4/4IAigR/
CuF+gyMh6r8fxDRCKBZ02T04hMhM6XDbafNKGaDstXbLLI6o6xAgGLboeZxo6tj+
GFD+u4gqjN4EWRGeuHS+bzJErEBEt1XpMecaPHyNs6CZF+/XTL6zOZOsKWYAELzO
1mlTLp5dn4XCbtC8llsgey1sxq42kuN93JWRqODVPlU5lwZD7cbTpgVV6nQrz36n
NeS0FfjIs/UN8/Rix0xaC4frEG86Zv+ES1R/HB6UqDhx+P1hdRpBGVTNF6eLOMvV
JJA735pWeN6xgcdrcOrCIGVQTfptaD+tlYfSjL1aeN/Bw1LemyChwsCHd5PE8sgv
z63zTiMvR4Mm12KG8xYtm2ygTSdrjCvZz5/ZaX6wnJuCAALGs6Z2dTa27YQBBtlD
z4UXXG1fWImcYL1J26rMzapzSzQeXPYThedpCSRIiIs876RQhuE/M7/ZACNveTAR
I5QwxY9ZOtol9+ucvRn+8BqS24pRw0DwlWEUTYOWxHcgcMHFw3EzH0Zy0AUYj7yc
JrawQlWrhtSYSzScEpEvwlbU+zvZbWi/BXo+K8gUGq+hqseq2vLcfAyTzUA/lyYS
oBeAlJVBxFBKsO/64byItWY0la5E4w8T6qy+sgFvlnoFG3rO+/jWSfiEhDOSffCS
BLycpk3pzcBSOmTBnJrf
=Xgsq
-----END PGP SIGNATURE-----

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/17/2013 11:55 PM, Rick "Zero_Chaos" Farina wrote:
> 
> 
> It is my understanding that if you directly use a function from an 
> eclass you are REQUIRED to inherit that eclass.  Given that kind
> of sanity would have prevented these failures I find it difficult
> to believe my understanding is wrong, but I am willing to learn.
> 
> I think I'll start inheriting base.eclass so I can use multilib 
> functions.  I mean, base.eclass inherits eutils.eclass which
> inherits multilib.eclass so it should work out fine, right?
> 

You are wrong. What matters is the API of an eclass and how it is defined.

There is no such definition of base.eclass guaranteeing that it will
always either a) inherit eutils.eclass or b) provide certain functions
from eutils.eclass (maybe by defining them directly in the future).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR5xd0AAoJEFpvPKfnPDWzaxQH/0HZgEuSFwxO9yAwktAFLlW4
FdvNaUS+bn1oYGi/0vr/7E/j17ZH5/0nych/kw7kOa6009BpBjzdmDeAeZhIGI3n
tGGJtYNAsnZ16Rp7yrD0IZNj71ozSiLr6cBJs6m4rpOEJls9O0I1qazxnD+45o6W
iPfiDpfcUPFmTa/P3PJ69lAlNQA3EymmKXfB5SJdbt3QELxQR6wGdnpfrev0ieiG
gwpmzQzVjgt/PBpw4+tH/HFNdEXF+YjfbGGXoYNkO0FS+GppMtKaTYLEzbLPVORz
1v1oBWw/Ysz7CYML1C5R+uZpbf8cZK26mrQMj5gOSeyem/o5vgD7R3uhHFAgsgs=
=7JSh
-----END PGP SIGNATURE-----

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 17 Jul 2013 23:34:36 +0200
hasufell <hasufell@gentoo.org> wrote:

> That means the methods for eclass changes must be more thoroughly.

So must the methods to write ebuilds be more thoroughly; therefore, I
think that we can somewhat build a script that checks this from an
ebuild perspective. If we optimize this and make it more perfect by
no false positives, more efficient code, caching; we might perhaps be
able to turn this into a QA check in the future. See the attachment; as
a demonstration of what I think, I quickly hacked something together:

 $ time treecheck /usr/portage/dev-python/bsddb3/bsddb3-5.3.0.ebuild

 distutils-r1_python_compile used
 in /usr/portage/dev-python/bsddb3/bsddb3-5.3.0.ebuild, but eclass
 distutils-r1 might be missing!

 python_execute_function used
 in /usr/portage/dev-python/bsddb3/bsddb3-5.3.0.ebuild, but eclass
 python might be missing!

 real	0m6.558s
 user	0m3.482s
 sys	0m3.096s

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-python/bsddb3/bsddb3-5.3.0.ebuild?revision=1.12&view=markup

Only 6 to 7 seconds to check an ebuild against 2000+ eclass functions!

For those interested in QA reports automation or some wicked IRC bot,
you can also run this against the whole tree by not passing an ebuild;
but at the moment, I consider this not well enough yet for that purpose.
I don't think the speed matters too much; given that the amount of
functions is limited and you don't need to run this too often, the
focus here should lie more on dealing with the false positives.

Another thing that comes to mind and shouldn't be hard to implement is
to give it an eclass, then have it just check the functions of that
eclass only across the tree; a matter of implementing a extension check
on $1 and depending on that fill in eclass_funcs or ebuilds.

To summarize it can benefit three groups of people:

1) A script (perhaps future QA check) to check for missing inherits.

2) A script for eclass maintainers to check for incorrect usage across
the three; can possible be extended to check situations were an
inherit is removed, give all cmake consumers with missing base inherit. 

3) A script for QA people and reports to have an overview over the tree.

There is some potential here; so, I hope people are interested to help
contribute to or fork this piece of code into something more powerful.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJR5yQ6AAoJEJWyH81tNOV9/zoH/jp915kmOxBTasfyyRbWr1Na
/XCEw9u5EStWId6hirls1RII3xvqlMn2CZ0VZXC2x/ZZibQCB79ij6jw/lcnSKao
otFOy7h4Pp4zD6a8pofYW6DXMwBPESIVDKB3TT0g/BJtA84gX1hO2ApEYPmKZjGi
dTMSxLgr57rnmg6syIE1LYk/iaeZLTgfiLE5qdBGXFbbNDgWrBGi++y4s3s44jww
s44ZbKrPlIxwHfCvZd4px7hMUvym37p259kStfmU7eAzs88oXh9MqsffM48Z1Tt7
Mw2lHqlPQprjhgE3ikul/uMuKXFH2epfuGlV43tFUx4fsGiKr7E25lwqfGbjB4g=
=2RGb
-----END PGP SIGNATURE-----

[-- Attachment #2: treecheck.sh --]
[-- Type: application/x-shellscript, Size: 855 bytes --]

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Michał Górny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dnia 2013-07-17, o godz. 17:42:32
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/17/2013 05:34 PM, hasufell wrote:
> > On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote:
> >> ...and that is why it isn't permitted to directly use an eclass
> >> that you don't inherit.  While I agree testing could (should) have
> >> been better, the fact that people ignore the rules for writing
> >> ebuilds shouldn't entirely fall on the KDE team.
> > 
> > 
> > It doesn't matter in the slightest whos fault it is or who should be
> > blamed.
> > 
> > It is about maintaining stability for the user. Especially when it
> > comes to stable ebuilds.
> > 
> > That means the methods for eclass changes must be more thoroughly.
> 
> I completely agree with you, the changes should have been tested better.
>  The ebuilds with these errors popping up ALSO should have been tested
> better.  Considering this is a QA violation, perhaps it is possible to
> add a check in repoman for using something from an eclass which you
> didn't inherit.  I doubt the slowdown would be horrible and clearly it
> would catch a huge number of QA violations.

Repoman has such check already. It pops up for specific functions
listed in repoman source code. This allows us to catch the common
mistakes while avoiding false positives.

Maybe it should always pop up for phase functions. I don't immediately
see a reason why an ebuild would use a phase function of an eclass it
doesn't inherit directly.

- -- 
Best regards,
Michał Górny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQJ8BAEBCgBmBQJR55QGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC
QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKHMcQAIwiDjgyegvvuHl9dzSlRK9S
uTZH/kSBrIRppXIDWqC48Cj1LrRGVZoWIbHE9xd4qd0Hb37jva07JmTRW5/p/6aI
62a7Rfb9WZl0z75PZbk4id9idAPF1Gu35gAS1mEjncUlz/jC5pQlVB0kdF0F+feU
FIXfoXD7U4LZBIjCmD3fvf6GBaQN4M/i0ZKj56BnHzVUqMUkOzSSmMLc9M+TqQZR
dFG7GlgUrUz6G86XwXMY0OCu85lo8VVDE7bcDDK+Yh5RXr7ZQ7GozPQR25VJ8G2K
PIxIS4hIZ0+W+zuPqDs0skjWhcdpIlYGEV5p35GVzmiHqqyaDKd/WVuVM6e4xl+2
CrcWjy9OJnmyVOGmjtG3QJBlG6MIRbPpF1B2NYNLkk14Vnw/iDCRjkU28WzeyKlf
x9j6BCWLFP4g8StyW0e6f9aprg3/svD6XH84oPD3+8AfbBud5s7w4r+bL2UpDalU
PsdUmBLdEfMzQroZP9jYGGEtzyzLIAnO8WKmRn73Pi9Heg43TN7KdZJMqwDqu2ZM
Nzpm4xH0SK/iz6QlGMJ86hLkV2TdkU+KLUn0Bd8785hqw1ozdVZm0LhtygnluJij
pCrFnbomR7z9a8yvB1eLbnbbgd6Q8oKoVXM/h2ap0ncoz3tqaJ+9ccKryV4fOi3T
prdfHAfmIU1YJFYCvY6B
=i8Zv
-----END PGP SIGNATURE-----

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Alexis Ballier]

On Wed, 17 Jul 2013 17:17:41 -0400
Chris Reffett <creffett@gentoo.org> wrote:
> I discussed this with hasufell on IRC, but I'll lay out the response
> on the list too. Yes, this was my fault.

It doesn't really matter whose fault it is, but since you introduced the
change, please fix the blockers of the bug # in subject, thanks.

A more permanent repoman check can be added later.

Alexis.

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Zac Medico]

On 07/18/2013 12:06 AM, Michał Górny wrote:
> Dnia 2013-07-17, o godz. 17:42:32
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> napisał(a):
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
> 
>> On 07/17/2013 05:34 PM, hasufell wrote:
>>> On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote:
>>>> ...and that is why it isn't permitted to directly use an eclass
>>>> that you don't inherit.  While I agree testing could (should) have
>>>> been better, the fact that people ignore the rules for writing
>>>> ebuilds shouldn't entirely fall on the KDE team.
>>>
>>>
>>> It doesn't matter in the slightest whos fault it is or who should be
>>> blamed.
>>>
>>> It is about maintaining stability for the user. Especially when it
>>> comes to stable ebuilds.
>>>
>>> That means the methods for eclass changes must be more thoroughly.
> 
>> I completely agree with you, the changes should have been tested better.
>>  The ebuilds with these errors popping up ALSO should have been tested
>> better.  Considering this is a QA violation, perhaps it is possible to
>> add a check in repoman for using something from an eclass which you
>> didn't inherit.  I doubt the slowdown would be horrible and clearly it
>> would catch a huge number of QA violations.
> 
> Repoman has such check already. It pops up for specific functions
> listed in repoman source code. This allows us to catch the common
> mistakes while avoiding false positives.
> 
> Maybe it should always pop up for phase functions. I don't immediately
> see a reason why an ebuild would use a phase function of an eclass it
> doesn't inherit directly.

That check is only enabled in portage-2.2, because I really want it to
parse the relevant info directly from the eclasses. That way, we won't
have to update repoman for eclass changes.
-- 
Thanks,
Zac