Spec Name or Url: http://gsd.di.uminho.pt/jpo/software/fedora/perl-Text-WikiFormat.spec SRPM Name or Url: http://gsd.di.uminho.pt/jpo/software/fedora/perl-Text-WikiFormat-0.76-1.src.rpm Description: The original Wiki web site had a very simple interface to edit and to add pages. Its formatting rules are simple and easy to use. They are also easy to translate into other, more complicated markup languages with this module. It creates HTML by default, but can produce valid POD, DocBook, XML, or any other format imaginable. Note: This package is an RT 3.4 requirement.
"make test" fails for me on FC4/i386: + ./Build test t/0-signature............WARNING: This key is not certified with a trusted signature! Primary key fingerprint: DF05 D93D BEA3 9DD2 4A44 CD66 05DF 169F 5C08 E9C4 Not in MANIFEST: debugfiles.list Not in MANIFEST: debugsources.list ==> MISMATCHED content between MANIFEST and distribution files! <== t/0-signature............NOK 1# Failed test (t/0-signature.t at line 9) # Looks like you failed 1 tests of 1. t/0-signature............dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay ... Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t/0-signature.t 1 256 1 1 100.00% 1 Failed 1/17 test scripts, 94.12% okay. 1/143 subtests failed, 99.30% okay. error: Bad exit status from /var/tmp/rpm-tmp.81496 (%check)
New SRPM: http://gsd.di.uminho.pt/jpo/software/fedora/perl-Text-WikiFormat-0.76-2.src.rpm Changelog: Disabled the signature test.
(In reply to comment #2) > Disabled the signature test. Well, I am a bit hesitant on accepting this change, without knowing the cause for the testsuite failure. Is the test buggy? Does the test trip a bug in Module::Signature? Is it a configuration issue? Or is it a bug in Text::WikiFormat? I don't know.
Ralf, The problem is that the files "debugfiles.list" and "debugsources.list" are generated automatically by rpmbuild. The files appear during the install step (just try rpmbuild -bi perl-Text-WikiFormat and look into the BUILD/Text-WikiFormat directory). As these files don't have entries in the SIGNATURE file, they cause the signature test to fail. This problem happens if the Module::Signature is installed. We already used this approach in a couple of perl packages (disable/remove the signature test). Another solution would be to BuildConflict: perl(Module::Signature). /jpo
Ah! I understand. Time to file a PR against rpm, I guess ;) APPROVED
Given that this is a noarch package and hence debugfiles.list and debugsources.list are both empty, isn't a cleaner solution to just do: rm -f debugsources.list debugfiles.list at the start of %check ?
Paul, I don't know if that would work for noarch RPMS (I believe rpmbuild uses these files for creating the debuginfo RPMS). I think rpmbuild should only create the above files after %check (the %check section only appeared in RPM 4.2). I'll try to locate a couple of mails I exchanged with Ville about the subject. Meanwhile I place here the link of the review perl-Module-Signature review as it includes a couple of useful comments: https://bugzilla.fedora.us/show_bug.cgi?id=1606
The most severe reasons for disabling Module::Signature checks is that the checks may need a network connection to a keyserver for fetching the keys, and more importantly, it might silently import the fetched keys to the builder's keyring. I've documented my .02⬠of this stuff in the packager's handbook some time ago, snapshot here: http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html#guidelines-perl-cpansign
Oh, and debug*.list are created by find-debuginfo.sh, which runs at end of %install (ie. before %check).
(In reply to comment #6 and #9) > Oh, and debug*.list are created by find-debuginfo.sh, which runs at end of > %install (ie. before %check). Shouldn't unpackaging the package into a subdir (%setup -n -c etc.) be a work around to this issue? (I haven't tried yet) (In reply to comment #8) > The most severe reasons for disabling Module::Signature checks is that the > checks may need a network connection to a keyserver for fetching the keys This should not affect perl-Text-WikiFormat, because it skips its signature check when Module::Signature is not installed. I.e. unless the rpm.spec BR: perl(Module::Signature), this should not affect the build system. Pulling in keys into a user keyring is not of much concern to me, because many programs also so.
Created attachment 118380 [details] Proposal to build the package in a subdir
Why just not move the test suite back into the %build section? ... %build %{__perl} Build.PL installdirs=vendor ./Build +./Build test ...
Regarding importing the keys: any build that alters the system outside of the build dirs is IMO simply unacceptable. Regarding Module::Signature installed or not: that adds uncertainty to the build, which conflicts with the goal of consistent, reproducible builds both in the build system and developer/end user boxes. It's easily circumvented by adding a BuildConflicts on Module::Signature or disabling the signature test. BuildRequiring Module::Signature doesn't make much sense because there are too many other, external factors (which aren't expressible in a specfile) that affect whether the signature check will succeed or not. If you want to move the test suite, moving it to the end of %install section would also be possible (and IMO better than %build, but even better would be to just disable the signature test and be done with it).
(In reply to comment #13) > Regarding importing the keys: any build that alters the system outside of the > build dirs is IMO simply unacceptable. Why? To me, such a restriction is unnecessarily strict. Remember, we are talking about running testsuites. It's a charakteristic of testsuites that they interact with a system. > If you want to move the test suite, moving it to the end of %install section > would also be possible (and IMO better than %build, but even better would be > to just disable the signature test and be done with it). IMO, neither moving tests to %build or %install are acceptable. "tests are tests" and therefore must go to %check and nowhere else. If rpm disturbs Module::Signature, this is definitely is a bug in rpm we currently can't avoid having to work around inside of the SPECS, before it's fixed inside of rpm. Or to put it a bit more verbose: rpm, must not generate arbitrary files inside of the build directory, because they will always conflict somewhere.
(In reply to comment #14) > Why? To me, such a restriction is unnecessarily strict. Common sense. > Or to put it a bit more verbose: rpm, must not generate arbitrary files inside > of the build directory, because they will always conflict somewhere. Uh, so you would be willing to allow a build to trash the system outside of the build dirs, but not inside them?
(Forgot to note that trashing the build dirs isn't nice either, but I don't see what's arbitrary with find-debuginfo.sh always creating two files, debugfiles.list and debugsources.list.)
(In reply to comment #15) > (In reply to comment #14) > > Why? To me, such a restriction is unnecessarily strict. > > Common sense. Naive wishful thinking - Many tools generate files outside of buildtree. The most popular one of these is called gcc another one is called autoconf. > > Or to put it a bit more verbose: rpm, must not generate arbitrary files > inside > > of the build directory, because they will always conflict somewhere. > > Uh, so you would be willing to allow a build to trash the system outside of > the build dirs, but not inside them? You are missing the point: I would allow the tool to be build to perform its nominal operation, but I am not allowing to tool being used during building interfer with the tool to be build.
Package apparently already released.
Package Change Request ====================== Package Name: perl-Text-WikiFormat New Branches: EL-5 Owners: spot
CVS done.