[gentoo-dev] Last rite: sci-biology/allpaths
# Justin Lecher j...@gentoo.org (17 Jul 2013) # superseeded by sci-biology/allpathslg # Upstream wants anybody to move over sci-biology/allpaths signature.asc Description: OpenPGP digital signature
[gentoo-dev] cmake-utils.eclass and bug 475502
-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] Gentoo Hangouts
On 18:52 Mon 08 Jul , Pavlos Ratis wrote: As far as I can see, opinions about VCs are 50-50. However, I don't see any disadvantages adding video hangouts to the project. VCs _are not_ mandatory and doesn't replace any of our current communication methods. You are not forced to participate. It's all about choice. If there are no objections and if the PR team gives an ack. I'd like to add video hangouts under the PR project (I'll create a simple faq page in wiki about VCs). Go ahead. Experiments are always welcome. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpSNOnrgt6NR.pgp Description: PGP signature
Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.
On 20:19 Thu 04 Jul , Mike Pagano wrote: I have 'relaxed' a tad about what I think should be in g-s, but maybe it has gone a bit farther than I wanted it too. I would like to see a -experimental use flag and base,extras,geek (whatever) so that g-s goes back to what it's original goal was with nothing non-upstream unless the user does a configuration change themselves. This will actually help us solve both issues. 1) it will allow us to pull g-s back to it's original goal as a minimal kernel sources with upstream only patches. Original? Not true. gentoo-sources has, for ages, carried feature patches that were considered useful to Gentoo as a whole or to releng in particular. It's carried whole filesystems like XFS, it's carried EVMS, it's carried pretty much the whole ck- patchset (Con Kolivas), grsec, FreeS/WAN and OpenS/WAN, the bootsplash stuff, etc. 2) we can carry some patches from upstreams trees that possibly aren't yet in -next, or not yet accepted to mainline but do provide some benefit to a smaller group of our users. (Thinking about our thinkpad patches) -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpGcbFM00xhl.pgp Description: PGP signature
Re: [gentoo-dev] cmake-utils.eclass and bug 475502
-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/ iKYEARECAGYFAlHnCfVfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T6ZACcC5cDNBCODxrnzlPCTm+L4EgS wCkAniqjyBFXhIXeXyb0Wbvufkbw68yS =QM3o -END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass and bug 475502
-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
-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
-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
-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
-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
-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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 17 Jul 2013 23:34:36 +0200 hasufell hasuf...@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 sys0m3.096s http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-python/bsddb3/bsddb3-5.3.0.ebuild?revision=1.12view=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 : tom...@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- treecheck.sh Description: application/shellscript
