Re: perl-String-ShellQuote-1.03-1.rf.src.rpm build problem

Dag Wieers <[email protected]>
Newsgroups gmane.linux.freshrpms.user
Organization 3TI Web Hosting Services
Message-ID <[email protected]>
On Fri, 6 Jan 2006, Dean Takemori wrote:

> Following up on my own report ...
> 
> The build logs for perl-String-ShellQuote-1.03-1.rf.src.rpm on FC1, FC3 and
> EL4 all
> show the following snippits.
> 
> 
> > Installing
> > /dar/tmp/perl-String-ShellQuote-1.03-1.1.fc1.rf-root/usr/bin/shell-quote
> 
> > Installing
> > /dar/tmp/perl-String-ShellQuote-1.03-1.1.fc1.rf-root/usr/share/man/man1/shell-quote.1
> 
> > Checking for unpackaged file(s): /usr/lib/rpm/check-files
> > /dar/tmp/perl-String-ShellQuote-1.03-1.1.fc1.rf-root
> > sort: close failed: -: No space left on device
> > sort: close failed: -: No space left on device
> 
> 
> In each case looking at the prebuilt rpms shows that neither
> /usr/bin/shell-quote, nor the shell-quote.1
> man page is part of the binary rpm.
> 
> ~ > rpm -qlp perl-String-ShellQuote-1.03-1.1.fc1.rf.noarch.rpm
> warning: perl-String-ShellQuote-1.03-1.1.fc1.rf.noarch.rpm: V3 DSA signature:
> NOKEY, key ID 6b8d79e6
> /usr/lib/perl5/vendor_perl/5.8.3/String/ShellQuote.pm
> /usr/share/doc/perl-String-ShellQuote-1.03
> /usr/share/doc/perl-String-ShellQuote-1.03/Changes
> /usr/share/doc/perl-String-ShellQuote-1.03/README
> /usr/share/man/man3/String::ShellQuote.3pm.gz
> 
> 
> When trying to build my own binary RPM, I get
> 
> > Checking for unpackaged file(s): /usr/lib/rpm/check-files
> > /var/tmp/perl-String-ShellQuote-1.03-1.rf-root
> > error: Installed (but unpackaged) file(s) found:
> >   /usr/bin/shell-quote
> >   /usr/share/man/man1/shell-quote.1.gz
> 
> 
> I'm not a .spec expert, but it appears to me that either
> a) the specfile %files section should be updated to include shell-quote and
> shell-quote.1.gz and the binary rpms rebuilt
> or
> b) shell-quote and shell-quote.1.gz need to be removed after the %install so
> they don't show up as "installed but unpackaged." during the build

Yes, I'm not sure why a disk-full condition can cause a package to 
succeed, however you're correct. I issued an update. The file you reported 
to be unpackaged are already part of the SPEC file. My bet is that Dries 
committed it with the missing files, it somehow got build on my system and 
then Dries fixed it. Dries used to commit broken SPEC files prior to 
building them (and fixing them finally) and if I pick those up, sometimes 
bad things happen.

Kind regards,
--   dag wieers,  [email protected],  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.