Russ Allbery wrote: > Raphael Geissert <atomo64+debian-re5jqeeqqe8avxtiumw...@public.gmane.org> > writes: > >> I found a difference on the results of the file-info parsing: >> >> diff --git a/t1 b/t2 >> index 14783a7..1e3fbb1 100644 >> --- a/t1 >> +++ b/t2 >> @@ -648,4 +648,4 @@ unit_tests/urls.nocomment.ref^@ >> unit_tests/urls.notags.ref^@ >> unit_tests/valgrind.supp^@ >> unit_tests/valgrind_tests.sh^@ >> -unit_tests/virusaction-test.sh^@ >> +unit_tests/virusaction-test.s^@ >> >> The former is from my machine, the latter is from the provided index. > > Where is this generated at? A nul followed by a newline is strange. Or > was this just from debugging code?
This is what collection/file-index pipes to xargs which later calls file(1). Since unit_tests/virusaction-test.s does not exist file(1) fails which returns the error code that later aborts the check of that package. > >> Although there's definitely a bug in how the index is generated, I found >> another bug, in file-info: chop was being used instead of chomp; >> attached mbox corrects that (and should probably workaround the index >> file generation bug). > > chomp is better coding style, but it should be exactly equivalent here > since the index is newline-terminated records. Am I missing something? No, you are not. I've read multiple times the code in unpack/unpack-src-l1 and see no reason why the generated index has no trailing new line; I mean, sort adds it on its own even if missing! $ echo -n foo | hd 00000000 66 6f 6f |foo| 00000003 $ echo -n foo | sort | hd 00000000 66 6f 6f 0a |foo.| 00000004 So, like I said: chomp workarounds the bug by simply not removing the trailing character which in this case is *not* the, expected, line feed. Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
