On Sat, 13 Dec 2008 11:19:48 +1100, Paul Fenwick wrote:
Hi Paul,
thanks for picking up my side note so quickly!
> > (Note for Paul: if I add libbsd-resource-perl to Build-Depends-Indep,
> > as required by t/08_core.t, I get:
> I trust this is only if you add libbsd-resource-perl *AND* you set
> TEST_AUTHOR=1 in your environment because you want the extra tests.
Right, I should have mentioned that I've set TEST_AUTHOR=1 in
debian/rules.
> All the
> TEST_AUTHOR tests make (potentially wrong) assumptions about your system or
> other configuration, which is why they're disabled by default.
Hm, we usually run as many tests as possible, and if that involves
setting some variables for POD or AUTHOR or whatever tests, we do it.
Exceptions are if tests need some fancy servers and/or Internet
access etc.
> In particular 08_core.t assumes that zapping a process with a SIGABRT will
> cause your process to dump core. If you're running on a system where
> SIGABRT doesn't cause a core dump, or have a system where core-dumps have
> been disabled using a mechanism other than ulimit-style resource limiting,
> then I'd expect to see the failure you've reported[1].
I did the build (as usual) in a cowbuilder sid chroot.
(If you want me to test something in particular I'm happy to help!)
> In a similar vein, the Perl::Critic tests can potentially fail if it uses a
> different .perlcriticrc file than the one supplied with IPC::System::Simple,
> or a (future) version of Perl::Critic that is more picky about my code. ;)
The build in a chroot shouldn't use anything in $HOME :)
Perl::Critic tests are an interesting topic because they are among
those which are not unlikely to fail. But since most upstream authors
are interested in getting reports about this type of problems we (at
least try to) run them.
> The 05_multi_capture.t author tests may incorrectly fail on non-English systems.
Sounds like a good opportunity to improve the tests :)
> As such, if any of the author tests fail, it indicates there *may* be a bug,
> as opposed to if any of the main tests which, which indicate that there is
> definitely a bug.
I completely agree, and that's why I just removed
libbsd-resource-perl from Build-Depends-Indep to get the package out
and mentioned the issue.
But since any user might have installed libbsd-resource-perl (as
opposed to a clean build environment) they might stumble across this
issue, so just ignoring it is probably not appropriate.
> I don't know how this translates to the building of Debian packages. For
> regular users doing an 'apt-get source' to build their own .debs, the author
> tests should definitely be disabled -- leaving them on will cause far too
> many false positives due to variation between systems.
Hm. Either users don't do this, or they don't report problems, or
they don't have any. At least I don't remember any bug reports
relating to enabled author tests.
> For an actual Debian
> maintainer who is building packages on a known environment, it may be
> reasonable to have them enabled, since they'll be able to properly triage
> any failures reported by them. Even so, I'd be inclined to leave them off
> by default.
Debian packages are/have to be built in a clean environment, i.e. a
base system plus the packages in Build-Depends{,-Indep}. There either
the tests work or we leave them out and try to work out the issues
with upstream.
(And there's no "default", it's a decision on a package-by-package
basis taken by the person(s) working on it.
Maybe we (as in: the Debian Perl Group) have an unwritten default
value of "let's try to enable additional tests, if it's possible".)
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`- NP: U2: In A Little While
Attachment:
signature.asc
Description: Digital signature