$ [ -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 $
*** Bug 706419 has been marked as a duplicate of this bug. ***
*** Bug 706986 has been marked as a duplicate of this bug. ***
The error message is obviously wrong (and confusing) but actually you just need to install the rpm-sign package.
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.
@ Matteo Corti and Nathanael Noblet : What about this ticket do both of you don't understand?
@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
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.
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.
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.
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.
*** Bug 712507 has been marked as a duplicate of this bug. ***
*** Bug 713954 has been marked as a duplicate of this bug. ***
*** Bug 734534 has been marked as a duplicate of this bug. ***
*** Bug 746200 has been marked as a duplicate of this bug. ***
*** Bug 748114 has been marked as a duplicate of this bug. ***
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
This is still not fixed, and obnoxious.
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.
Still happen in Fedora 17.
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.
*** Bug 710267 has been marked as a duplicate of this bug. ***
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.
(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.
Yup, I dont see popt getting updates in F17 at this point anymore.