Bug 697435 - rpm --addsign prints confusing error message when /usr/bin/rpmsign is unavailable
rpm --addsign prints confusing error message when /usr/bin/rpmsign is unavail...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: popt (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Robert Scheck
Fedora Extras Quality Assurance
:
: 706419 706986 710267 712507 713954 734534 746200 748114 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-18 05:20 EDT by Michael Schwendt
Modified: 2013-07-05 17:47 EDT (History)
28 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 838985 (view as bug list)
Environment:
Last Closed: 2013-07-04 03:53:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2011-04-18 05:20:13 EDT
$ [ -e audacious-2.5.0-1.fc15.x86_64.rpm ] && echo "true"
true
$ rpm --addsign audacious-2.5.0-1.fc15.x86_64.rpm 
rpm: audacious-2.5.0-1.fc15.x86_64.rpm: No such file or directory

$ strace rpm --addsign audacious-2.5.0-1.fc15.x86_64.rpm 2>&1 |grep sign
execve("/bin/rpm", ["rpm", "--addsign", "audacious-2.5.0-1.fc15.x86_64.rp"...], [/* 44 vars */]) = 0
execve("/usr/bin/rpmsign", ["/usr/bin/rpmsign", "--addsign", "audacious-2.5.0-1.fc15.x86_64.rp"...], [/* 44 vars */]) = -1 ENOENT (No such file or directory)

$ ll /usr/bin/rpmsign
ls: cannot access /usr/bin/rpmsign: No such file or directory

$ repoquery --whatprovides /usr/bin/rpmsign
rpm-sign-0:4.9.0-6.fc15.x86_64
rpm-sign-0:4.9.0-6.fc15.x86_64

$ rpm -q rpm-sign
package rpm-sign is not installed

$ repoquery --whatrequires rpm-sign
$
Comment 1 Panu Matilainen 2011-05-23 00:49:55 EDT
*** Bug 706419 has been marked as a duplicate of this bug. ***
Comment 2 Panu Matilainen 2011-05-24 01:45:03 EDT
*** Bug 706986 has been marked as a duplicate of this bug. ***
Comment 3 Matteo Corti 2011-05-25 03:23:46 EDT
The error message is obviously wrong (and confusing) but actually you just need to install the rpm-sign package.
Comment 4 Nathanael Noblet 2011-05-25 11:23:44 EDT
that is completely correct - however my bug (706986) is requesting that rpm provide useful error messages for depreciated / split out functions. The error message here is completely useless I spent 20 minutes wondering if I was going insane as I tried to find out what it was doing. If there is an upstream bug tracker I would file this there.
Comment 5 Michael Schwendt 2011-05-25 12:26:12 EDT
@ Matteo Corti and Nathanael Noblet : What about this ticket do both of you don't understand?
Comment 6 Matteo Corti 2011-05-25 12:36:05 EDT
@Michael Schwendt
Sorry but why the tone. The ticket is obvious and the solutions too.
- correct the error message of rpm (which is wrong)
- add the dependency to the rpms (which is missing)

My comment was just to give a quick workaround explained in an easier way as 
$ repoquery --whatprovides /usr/bin/rpmsign

And actually Nathanael is also right. The main problem is *not* the missing dependency but the incomplete error message in rpm.

Matteo
Comment 7 Michael Schwendt 2011-05-25 15:17:54 EDT
I'd just like to know why you felt it was necessary to repeat the obvious in an ambiguous way that starts an argument with Nathanel ("but"... => "however"...)? You both have talked past eachother, since I hope we all understand what is wrong here.

If one has read the beginning of this ticket, it is obvious that one needs to install the "rpm-sign" package to get the missing executable. And the title plus the details given also explain what is wrong/confusing about the error message.

"rpm-sign" has been made a separate package on purpose, so pulling it back into the "rpm-build" or "rpm" dep-chain would be counter-productive as one could move back /usr/bin/rpm-sign and its man page instead.

[...]

Let's look at the dependencies nevertheless. They are a bit strange, IMO.

librpmsign is not included in the rpm-sign package, but in the rpm-build-libs package, although it could be moved into the rpm-sign package due to these external deps:

$ rpm -q --whatrequires 'librpmsign.so.0()(64bit)'
rpm-python-4.9.0-6.fc15.x86_64
rpm-sign-4.9.0-6.fc15.x86_64
rpm-devel-4.9.0-6.fc15.x86_64

The rpm-sign package depends on both librpmsign and rpm-build-libs explicitly:

$ rpm -qR rpm-sign|grep rpm
librpm.so.2()(64bit)  
librpmio.so.2()(64bit)  
librpmsign.so.0()(64bit)  
rpm-build-libs(x86-64) = 4.9.0-6.fc15
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

And it's rpm-build-libs, which pulls in gpg2:

$ rpm -qR rpm-build-libs|grep gpg
/usr/bin/gpg2  

Shouldn't that have been moved to the rpm-sign package?

rpm-sign currently does not add any dependency not required by rpm-build already, so there is no benefit in making it a separate package. If the gpg2 dep were moved, that would change a lot.
Comment 8 Nathanael Noblet 2011-05-25 19:01:09 EDT
Sorry if my comments have come off as argumentative or otherwise unhelpful. Let me try to clarify what I was trying to say.

I *like* that rpm-sign has been split out. However I upgraded from F14 to F15 and when I did rpm --resign (because I didn't know/forgot I needed rpmsign binary) I get an error message that says "File not found". I spent 20 minutes making sure I wasn't going crazy because of the error message.

My bug report is *not* about dependencies, nor requesting anyone add the ability back into the original rpm binary.

All I'm asking is that the depreciated options rpm *used* to accept, print a sane message like "--resign is no longer valid use rpmsign instead". It doesn't even have to be that smart. It can say "--resign has been depreciated and is no longer supported".

If the devs think it isn't worth it, that's fine too. I just think a useful message would be better than what is there.
Comment 9 Nathanael Noblet 2011-05-25 19:05:10 EDT
Now that I see rpm actually supports it if the binary is installed I think I get why there's so much confusion. I've modified all my scripts to use rpmsign not knowing that rpm --addsign would silently call rpmsign and that is where the error comes from.

In this case with this new knowledge, that's great that the devs have tried to make it backwards compatible. I would still suggest that the error message be more sane. Test for ENOENT and return "please install rpmsign to be able to sign binaries" or something like that.
Comment 10 Panu Matilainen 2011-05-26 02:45:36 EDT
No need to repeat the obvious. The problem is HOW to do it, as the backwards compatibility mapping for this (and a few other similar cases such as spec queries) are done with popt exec-aliases, and the exec happens behind rpm's back so rpm hasn't got a clue what's actually going on, other than popt reports an error and we just dump out what popt gives us:

        fprintf(stderr, "%s: %s: %s\n", __progname,
                poptBadOption(optCon, POPT_BADOPTION_NOALIAS),
                poptStrerror(rc));
        exit(EXIT_FAILURE);

poptBadOption() is what's causing the confusion here by returning an argument (which actually had nothing to do with the failure) instead of the failed exec command. I need to see whether this can be fixed in popt (that's how it looks like) or whether we need to come up with something "creative" in rpm to get around it.
Comment 11 Panu Matilainen 2011-06-13 01:24:57 EDT
*** Bug 712507 has been marked as a duplicate of this bug. ***
Comment 12 Panu Matilainen 2011-06-17 03:28:10 EDT
*** Bug 713954 has been marked as a duplicate of this bug. ***
Comment 13 Michael Schwendt 2011-08-30 13:41:17 EDT
*** Bug 734534 has been marked as a duplicate of this bug. ***
Comment 14 Panu Matilainen 2011-10-14 06:51:10 EDT
*** Bug 746200 has been marked as a duplicate of this bug. ***
Comment 15 Bill C. Riemers 2011-10-22 01:53:15 EDT
*** Bug 748114 has been marked as a duplicate of this bug. ***
Comment 16 Tom Trebisky 2012-01-18 16:12:45 EST
I guess this still hasn't gotten fixed, because it just bit me again.

I use the rpmbuild --sign switch and get the message:

rpm: /home/tom/rpmbuild/RPMS/ds9-6.2-1.fc16_tjt.x86_64.rpm: No such file or directory

In fact it is /usr/bin/rpmsign that is missing, not my rpm, and
what I need to do is to install the rpm-sign package.

Running a fully up to date fedora 16 system
Comment 17 Hank Wilde 2012-02-09 10:18:34 EST
This is still not fixed, and obnoxious.
Comment 18 Ted Behling 2012-03-11 10:54:20 EDT
I would just like to upvote this bug please.  I am running FC15, and when trying to sign an RPM, I saw the following:

rpm --addsign example-1-1.noarch.rpm 
rpm: example-1-1.noarch.rpm : No such file or directory

The obvious interpretation there is that example-1-1.noarch.rpm does not exist or is not readable by rpm, but it does.  I spent an inordinate amount of time trying to figure this out, and finally a Web search for "rpm addsign no such file or directory" led me to this ticket.  Now I know I need to install rpm-sign.

I also did an strace to try to figure this out, and I understand now that rpm will do execve("/usr/bin/rpmsign"...).  I would suggest that before the execve(), rpm first checks for the presence and executability of /usr/bin/rpmsign , and prints an error on failure that perhaps says "rpmsign not found; please install package rpm-sign".  This is in addition to catching the error response from execve() and I think would benefit users.

I would also suggest considering including rpm-sign as a dependency of fedora-packager, or Yum group development-tools.
Comment 19 Miroslav Suchý 2012-07-31 10:52:38 EDT
Still happen in Fedora 17.
Comment 20 Panu Matilainen 2012-08-02 09:39:21 EDT
Switching to popt component which is really the guilty part here...
popt >= 1.13-12.fc18 in rawhide has a hack to teach poptBadOption() about exec alias failures so it returns something meaningful (name of the program it failed to exec) instead of garbage like last valid option or first leftover argument:

[pmatilai@localhost ~]$ rpm --addsign /tmp/*.rpm
rpm: /usr/bin/rpmsign: No such file or directory

It might not be ideal but its a whole lot more informative than the former behavior. If it doesn't break anything in rawhide we can then pull it into current releases as well.
Comment 21 Panu Matilainen 2012-08-02 09:40:23 EDT
*** Bug 710267 has been marked as a duplicate of this bug. ***
Comment 22 Fedora End Of Life 2013-07-04 03:05:12 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 23 Jan Pazdziora 2013-07-04 03:51:56 EDT
(In reply to Panu Matilainen from comment #20)
> Switching to popt component which is really the guilty part here...
> popt >= 1.13-12.fc18 in rawhide has a hack to teach poptBadOption() about
> exec alias failures so it returns something meaningful (name of the program
> it failed to exec) instead of garbage like last valid option or first
> leftover argument:
> 
> [pmatilai@localhost ~]$ rpm --addsign /tmp/*.rpm
> rpm: /usr/bin/rpmsign: No such file or directory
> 
> It might not be ideal but its a whole lot more informative than the former
> behavior. If it doesn't break anything in rawhide we can then pull it into
> current releases as well.

In Fedora 19,

# rpm -q rpm
rpm-4.11.0.1-2.fc19.x86_64
# rpm --addsign perl-libs-5.16.3-262.fc19.x86_64.rpm 
rpm: /usr/bin/rpmsign: No such file or directory

After doing yum install -y /usr/bin/rpmsign:

# rpm --addsign perl-libs-5.16.3-262.fc19.x86_64.rpm 
You must set "%_gpg_name" in your macro file
#

I'd call it good enough and propose closing this bugzilla with NEXTRELEASE.
Comment 24 Panu Matilainen 2013-07-04 03:53:53 EDT
Yup, I dont see popt getting updates in F17 at this point anymore.

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