On 2/21/10 10:11 AM, Paweł Hajdan, Jr. wrote:
On 2/21/10 5:08 AM, Ryan Hill wrote:
I have one simple request. When you make a non-trivial change to an ebuild -
a patch, a version bump, anything that can effect the behaviour of the
package - please run the test suite.
Yeah, on my dev box I
Le dimanche 21 février 2010 à 10:53 +0100, Paweł Hajdan, Jr. a écrit :
On 2/21/10 10:40 AM, Thilo Bangert wrote:
Paweł Hajdan, Jr. phajdan...@gentoo.org said:
By the way, for packages that fail the test suite and refuse to disable
it, I change the env locally so that FEATURES=-test (via
On 2/22/10 2:01 PM, Gilles Dartiguelongue wrote:
Le dimanche 21 février 2010 à 10:53 +0100, Paweł Hajdan, Jr. a écrit :
$ tree /etc/portage/env
/etc/portage/env
|-- app-portage
| `-- portage-utils.env
|-- dev-libs
| |-- boost.env
| `-- libevent.env
|-- dev-python
| `-- pygtk.env
On 2/21/10 5:08 AM, Ryan Hill wrote:
I have one simple request. When you make a non-trivial change to an ebuild -
a patch, a version bump, anything that can effect the behaviour of the
package - please run the test suite.
Yeah, on my dev box I just run with FEATURES=test all the time. Then
Paweł Hajdan, Jr. phajdan...@gentoo.org said:
On 2/21/10 5:08 AM, Ryan Hill wrote:
I have one simple request. When you make a non-trivial change to an
ebuild - a patch, a version bump, anything that can effect the
behaviour of the package - please run the test suite.
Yeah, on my dev box
On 2/21/10 10:40 AM, Thilo Bangert wrote:
Paweł Hajdan, Jr. phajdan...@gentoo.org said:
The concern here may be that it's papering over the real problem, but
the good side is that it'd make running with FEATURES=test much easier.
which is a good thing, since more tests will be run.
Hi!
On Sat, 20 Feb 2010, Ryan Hill wrote:
[... Please use the test suites, you're making lives easier. ...]
Also, if the test failure is portable, you don't waste the time
of N arch maintainers that run into the same problem on wy
slower machines than yours.
Thanks,
Tobias
On 21.2.2010 1.11, Paweł Hajdan, Jr. wrote:
Is it acceptable for another dev to jump in and add RESTRICT=test to
an ebuild if the maintainer does not respond to a bug report in a timely
manner?
Preference order:
1. Fix the tests
2. Disable just the failing test
3. RESTRICT=test
Regards,
(this isn't directed at any one person or group or any recent incident, this
has been bugging me for years)
I have one simple request. When you make a non-trivial change to an ebuild -
a patch, a version bump, anything that can effect the behaviour of the
package - please run the test suite. If
