Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 167252 - Review Request: perl-Text-WikiFormat - Translate Wiki formatted text into other formats
Summary: Review Request: perl-Text-WikiFormat - Translate Wiki formatted text into oth...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ralf Corsepius
QA Contact: David Lawrence
URL: http://gsd.di.uminho.pt/jpo/software/...
Whiteboard:
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2005-08-31 22:03 UTC by Jose Pedro Oliveira
Modified: 2010-03-01 16:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-13 08:45:11 UTC
Type: ---
Embargoed:
j: fedora-cvs+


Attachments (Terms of Use)
Proposal to build the package in a subdir (deleted)
2005-09-02 08:34 UTC, Ralf Corsepius
no flags Details | Diff

Description Jose Pedro Oliveira 2005-08-31 22:03:51 UTC
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.

Comment 1 Ralf Corsepius 2005-09-01 07:02:41 UTC
"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)

Comment 2 Jose Pedro Oliveira 2005-09-01 09:13:52 UTC
New SRPM:
http://gsd.di.uminho.pt/jpo/software/fedora/perl-Text-WikiFormat-0.76-2.src.rpm

Changelog:
Disabled the signature test.

Comment 3 Ralf Corsepius 2005-09-01 11:08:44 UTC
(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.

Comment 4 Jose Pedro Oliveira 2005-09-01 11:30:23 UTC
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

Comment 5 Ralf Corsepius 2005-09-01 11:53:53 UTC
Ah! I understand. Time to file a PR against rpm, I guess ;)

APPROVED

Comment 6 Paul Howarth 2005-09-01 15:18:38 UTC
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 ?


Comment 7 Jose Pedro Oliveira 2005-09-01 15:48:30 UTC
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


Comment 8 Ville Skyttä 2005-09-01 17:32:44 UTC
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 

Comment 9 Ville Skyttä 2005-09-01 17:34:40 UTC
Oh, and debug*.list are created by find-debuginfo.sh, which runs at end of 
%install (ie. before %check). 

Comment 10 Ralf Corsepius 2005-09-02 07:19:28 UTC
(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.

Comment 11 Ralf Corsepius 2005-09-02 08:34:04 UTC
Created attachment 118380 [details]
Proposal to build the package in a subdir

Comment 12 Jose Pedro Oliveira 2005-09-02 10:05:12 UTC
Why just not move the test suite back into the %build section?

  ...

  %build
  %{__perl} Build.PL installdirs=vendor
  ./Build
 +./Build test

  ...

Comment 13 Ville Skyttä 2005-09-02 17:24:16 UTC
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). 

Comment 14 Ralf Corsepius 2005-09-03 05:01:01 UTC
(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.

Comment 15 Ville Skyttä 2005-09-03 08:36:04 UTC
 (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? 

Comment 16 Ville Skyttä 2005-09-03 09:42:20 UTC
(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.) 

Comment 17 Ralf Corsepius 2005-09-03 12:04:07 UTC
(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.

Comment 18 Ralf Corsepius 2005-09-13 08:45:11 UTC
Package apparently already released.

Comment 19 Tom "spot" Callaway 2010-03-01 14:15:24 UTC
Package Change Request
======================
Package Name: perl-Text-WikiFormat
New Branches: EL-5
Owners: spot

Comment 20 Jason Tibbitts 2010-03-01 16:51:57 UTC
CVS done.


Note You need to log in before you can comment on or make changes to this bug.