Update for Gentoo testing routines
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
bzr-buildbot-net |
In Progress
|
High
|
Unassigned | ||
Gentoo Linux |
New
|
Undecided
|
Unassigned |
Bug Description
Follow up from bug 614713:
>>>>> Christian Faulhammer writes:
> A word from the Bazaar Gentoo maintainer:
You're very warmly welcome !
> I disabled the tests
All the tests or just these ones ? How did you disable them ?
> in Gentoo, the rest is fine, so 2.4 is the first version in a long
> time that can be emerged with tests.
\o/
> Vincent, I would like to see the test runs done within the Portage
> system because that is the most common case where Bazaar users
> will see the test suite in action.
I read that as the same goal we're trying to achieve in Ubuntu where the
full test suite is run as part of the package build for our stable
series.
I'm all for achieving this goal on as many supported platforms as is
humanly possible.
> There is a live ebuild in the Gentoo Bazaar overlay which always
> fetches the current code.
And by that you mean lp:bzr or lp:bzr/2.4 ? I.e. do you track the trunk
or the latest stable series ?
> Should I open a new issue for that?
Yes, please do ! And let's try to align what is done on your side with
what is done on
http://
bzr.dev (lp:bzr) runs the full test suite daily with only sporadic
failures.
I.e.: I'd really like to address the distortion between the gentoo
install where *all* tests pass every *day* without any significant
failure and your install (probably not the right word nor concept[1])
where there seem to be far too much failures for you to enable all the
tests.
Feel free to contact me privately if you want to discuss this or let's
do that on a new bug, both are fine with me.
[1]: I'm only trying to do a minimal amount of administration on the
babune's gentoo slave while maintaining a "standard" gentoo install. If
several configurations needs to be tracked (openssl/nss/you name it),
I'd like to understand which ones are needed and how we can maintain
them.
-------
1. Tests are disabled through the -x switch of bzr selftest, it is a hand-made collection.
2. The live ebuild builds trunk lp:bzr but needs an overhaul.
3. Gentoo's Portage runs the test suite if FEATURES=test is set, this can be done locally on the command-line for an emerge run or globally in make.conf.
My proposal is to regularly pull from the Bazaar overlay (lp:bzr-gentoo-overlay) to a local directory, go to dev-vcs/bzr in that directory and
$ FEATURES=test ebuild bzr-9999.ebuild test
Maybe one can run:
$ USE="ssl -gnutls -nss" emerge curl -1
$ FEATURES=test ebuild bzr-9999.ebuild test
$ USE="ssl gnutls -nss" emerge curl -1
$ FEATURES=test ebuild bzr-9999.ebuild test
$ USE="ssl -gnutls nss" emerge curl -1
$ FEATURES=test ebuild bzr-9999.ebuild test
To find possible problems with different SSL implementations.
Is anything still unclear?
Thinking about other permutations worth trying:
1. Different versions of Python.
# echo 'USE_PYTHON="2.4 2.5 2.6 2.7"' >> /etc/make.conf
# emerge python:2.{4..7}
Doing so once should cause bzr to be installed and tested for all four versions of python, using the commands above.
2. Stable and testing. KEYWORDS= amd64 in /etc/make.conf) and the other at testing (e.g. ACCEPT_ KEYWORDS= ~amd64) . This would influence the version numbers of a large number of direct and indirect dependencies, and should reflect common sets of package versions installed by Gentoo users.
It would be nice to have two setups of Gentoo, one at stable (e.g. ACCEPT_
Thanks for making this effort of getting the selftests running on Gentoo! I guess that there still will be a large number of possible combinations of configuration details out in the wild, way too many to test up front. So there may still be occasional bug reports coming in from users, in which case we'd have to identify the involved config aspects and perhaps add them to the testing server in one way or another. Think of it as a community testing effort...