Control: tag -1 + moreinfo help ¡Hola Santiago! El 2016-08-16 a las 19:02 +0100, Santiago Vila escribió:
On Tue, Aug 16, 2016 at 07:21:43PM +0200, Maximiliano Curia wrote:El 2016-08-16 a las 15:40 +0200, Santiago Vila escribió:found 831759 0.7.12-3 thanks
Does not seem fixed:
https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/backup-manager_0.7.12-3.rbuild.log
I doubt that it's the same issue. Anyway, I can't reproduce the issue here. Can you test the failling test with set -x ?
Apparently, you have to test it a lot of times until it fails, like a lottery (so please don't ask me for more debugging, I don't even use this package myself).
Attached you will find the output of one of the times I managed to make it fail.
> + /usr/bin/nice -n 10 /bin/tar -p -c -z -f ./repository/uranio1-tmp-BM-backup-manager-0.7.12-t-testdir.20160815.master.tar.gz /tmp/BM/backup-manager-0.7.12/t/testdir > ++ get_md5sum ./repository/uranio1-tmp-BM-backup-manager-0.7.12-t-testdir.20160815.master.tar.gz > ++ md5='ee176eaec8040e7230c18d2b8404d313 ./repository/uranio1-tmp-BM-backup-manager-0.7.12-t-testdir.20160815.master.tar.gz' > + debug '/usr/bin/nice -n 10 /bin/tar -p -c -z -f ./repository/uranio1-tmp-BM-backup-manager-0.7.12-t-testdir.20160816.master.tar.gz "/tmp/BM/backup-manager-0.7.12/t/testdir" > /tmp/backup-manager/bm-tarball.log.FwLAvP 2>&1' > ++ md5='f39797a9ee7c033e291d34b4304386eb ./repository/uranio1-tmp-BM-backup-manager-0.7.12-t-testdir.20160816.master.tar.gz'Mmh, the script is creating two "identical" tarballs but they get different md5sum (which is what's used to detect the duplicated tarballs). tar is know to introduce some "undefined" bits in the files, that's what pristine-tar's delta files manage.
From the tar invocation, I would suspect that a difference might occur if by any reason the file order in which tar processes the directory varies. This could be the case if a filesystem reorders/rebalances its directories after the first transversal, for example.
If this is the case then, maybe, using --sort=name in the tar invocation fixes the issue.
How many times was needed to run the test to trigger a fail? What kind of filesystem are you using? Is that filesystem using any special mounting options?
Do you still have the failling tarballs? It would be better to list the tarballs contents to check if the file order is in fact the issue here or if the difference lies somewhere else.
Happy hacking, -- "The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time." -- Tom Cargill Saludos /\/\ /\ >< `/
Attachment:
signature.asc
Description: Digital signature