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]