Ticket #181 (closed defect: fixed)

Opened 1 year ago

Last modified 1 year ago

Bogus line reporting when find-provides expansion is in use

Reported by: jengelh Assigned to: pmatilai
Priority: major Milestone: rpm-4.9.0
Component: rpm Version: RPM Development
Keywords: Cc:

Description

Hi,

I have here a tarball with specfile, and building with rpm fails with the mysterious message

Processing files: vitalnix-devel-3.3~beta2+git3-jng3.i586 Finding  Provides: /usr/lib/rpm/find-provides vitalnix error: line 126: Illegal char '@' in: %changelog error: Failed to find Provides: Requires(rpmlib): rpmlib(PayloadFilesHavePrefix?) <= 4.0-1  rpmlib(CompressedFileNames?) <= 3.0.4-1 rpmlib(VersionedDependencies?)  <= 3.0.3-1 RPM build errors:     line 126: Illegal char '@' in: %changelog

The point is, there is absolutely no @ anywhere in there. Upon close inspection of rpmbuild, I notice this in the function call chains:

Breakpoint 8, appendStringBufAux (sb=0x6fd240,

s=0x7fffffffb740 "pkgconfig(vitalnix) = @PACKAGE_VERSION_SIMPLE@\n", nl=0) at rpmstring.c:77

Upon inspection, I find that my vitalnix.pc has

Version: @PACKAGE_VERSION_SIMPLE@

Which once was defined, now is not anymore. But the point here is that rpm gave me a very strange error message. pkgconfig() is openSUSE 11.3's /usr/lib/rpm/pkgconfigdeps.sh that is run as part of find-provides and find-requires. So line 126 perhaps isn't line 126 after all, because this new Provides: does not come from my spec file in the first place.

It would have been much more useful if rpm printed the problem, that is, the "s" variable here, and preferably, that it came from outside the specfile. That would have instantly hinted me towards pkgconfig without having to fire up gdb.

Using rpmbuild-4.8.0.

Change History

08/27/10 06:12:45 changed by pmatilai

  • owner changed from RpmTickets to pmatilai.
  • status changed from new to assigned.

Yup, known (ancient) bug. rpmbuild's spec-line error reporting is off in various cases, but this is the most ridiculous of them all: the automated dependency generation is using the same routine to parse + add both the manually and automatically added dependencies. For manual dependencies the reported lines are at least thereabouts, but for automatic dependencies its completely bogus as they never originate from the spec. Might as well finally fix it...

12/01/10 15:19:18 changed by pmatilai

  • status changed from assigned to closed.
  • resolution set to fixed.
  • milestone set to rpm-4.9.0.

Fixed in HEAD now and will be in rpm 4.9.0.