Looks like the new rpm 4.4.2.3-9.el5 package brings this bug to RHEL 5.3. This is proving to be quite serious. +++ This bug was initially created as a clone of Bug #304121 +++ Description of problem: When a the source directory for a file ends with a '/', debugedit can spit out a "canonicalization unexpectedly shrank by one character" error and fail. That's not really enough for most people to figure out what's gone wrong or how to fix it. Version-Release number of selected component (if applicable): rpm-build-4.4.2.2-0.5.rc2 How reproducible: Always Steps to Reproduce: 1. mkdir src 2. cat > src/foo.c <<- EOF int main(int argc, char **argv) { return 0; } EOF 3. cd src 4. gcc -g3 -o foo ../src//foo.c 5. /usr/lib/rpm/debugedit -b `pwd` -d / foo Actual results: /usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character Expected results: Either not fail, or indicate that a directory name in the table ended with a '/', which it probably shouldn't have contained. Additional info: I actually ran into this with openafs 1.4.4, but I'm including a smaller reproducer which I think triggers the same bug. --- Additional comment from on 2007-09-27 04:49:46 EDT --- Hmm, it's not the trailing '/' that troubles debugedit per se but the fact that the canonicalized path is exactly one character shorter than the original which is a case that it can't (and can't be made to AFAICT) handle. Roland, care to comment? The error message could certainly be clearer on what sort of problem to look for (basically single extra '/' somewhere in the path). --- Additional comment from on 2007-09-27 19:26:18 EDT --- Indeed, the format makes it impossible to do rewriting in place unless the table shrinks by at least 2 or not at all (it's beyond the scope of debugedit to resize things). For cases in the directory table you could do an ugly kludge by repeating the leading / or adding a trailing one to preserve the size. But there is no trick like that to do in the file table, where any leading or trailing slash would change the final file name so it doesn't work (not just is wrongly ugly). The !=-1 size restriction is for the whole table cumulatively, so with extra slashes removed by canonicalization, it is only a problem when there is only one such file name. It could do a kludge of adding a trailing slash to some dir table entry when this arises, which would work and only uglify some of the names to /foo//bar. Still, I suspect packagers will be OK with it being an error they have to fix or work around, if they can tell what to do. The error message you get now is certainly pretty arcane. The other error of the same ilk has a better message. Looking at canonicalize_path, I think it is true that a doubled / is the only way it could shrink by exactly one. But I could use a second set of eyes to verify there really is no obscure innocent case that could do that. If that's true, then we can simply change the error message to identify this problem. --- Additional comment from on 2007-11-14 05:53:44 EDT --- FYI, the instance that triggers this bug has apparently been "fixed" in the Fedora-8-specific OpenAFS SRPM at http://openafs.org/dl/openafs/1.4.5/fedora-8/SRPMS/openafs-1.4.5-fc8.2.src.rpm Nonetheless, this could of course affect other packages as well.. --- Additional comment from on 2007-12-06 18:43:46 EDT --- Just a note that a koji build for syslog-ng failed with the same error: http://koji.fedoraproject.org/koji/taskinfo?taskID=265344 I'm not sure what would have changed to cause this package to stop building in this manner. --- Additional comment from on 2007-12-06 20:21:12 EDT --- This line from the log suggests the problem: /home/bazsi/zwa/git//syslog-ng/syslog-ng--mainline--2.0/src/cfg-lex.l:247: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result The common reason for this error is // instead of / inside a file name. This arises from using a trailing / on a directory name in a macro or makefile variable usually. It may be a further problem that this absolute directory name appears in the build. Presumably it is in # line file name strings in cfg-lex.c, which is generated from cfg-lex.l. If this file is included in the upstream tarball like this, then so it is and that is fine from the rpm-reproducible-builds perspective. Even so, upstream should be taught how to generate genericized file names for their dist tarballs, so it winds up just # line "cfg-lex.l" or suchlike. If the rpm build is running lex/flex to generate cfg-lex.c itself, then it's just our spec file that has to be fixed. --- Additional comment from