Bug#586935: Probably just needs upgrade admin/
Hi, I'm not a KDE, nor autotools guru, but it seems to me that the admin directory is old and smelly, maybe just updating it to a newer version would fix this problem (and bring others, of course). :) Thanks, -- "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." -- Edsger W. Dijkstra Saludos /\/\ /\ >< `/ -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100731210154.gj22...@maxy.com.ar
Bug#831759: backup-manager: FTBFS: Running test t15-dupes.sh: failed
Control: tag -1 + unreproducible moreinfo Control: severity -1 important On Tuesday, 19 July 2016 09:04:35 CEST Chris Lamb wrote: > Source: backup-manager > Version: 0.7.12-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > backup-manager fails to build from source in unstable/amd64: > [t 16] Running test t15-dupes.sh: failed Sorry, but I can't reproduce the error. Maybe there is some difference in the running environment. Can you test the failling test with set -x ? Happy hacking, -- "If you optimize everything, you will always be unhappy." -- Donald Knuth Saludos /\/\ /\ >< `/ signature.asc Description: This is a digitally signed message part.
Bug#831759: backup-manager: FTBFS: Running test t15-dupes.sh: failed
On Tuesday, 19 July 2016 18:18:24 CEST Chris Lamb wrote: > > > [t 16] Running test t15-dupes.sh: failed > > > > Sorry, but I can't reproduce the error. Maybe there is some difference in > > the running environment. Can you test the failling test with set -x ? > > Attached. I also had to remove the "2>/dev/null" in run-tests.sh for > the output to show FYI. Thanks, I think that the problem is here: ++ echo ./repository/7a98879f7f9c-home-lamby-temp-cdt. 20160719180425.csSPyc7zqz-backup-manager-0.7.12-t-testdir. 20160719.master.tar.gz ++ sed -e 's/20160719/\*/' + file_pattern='./repository/7a98879f7f9c-home-lamby-temp- cdt.*180425.csSPyc7zqz-backup-manager-0.7.12-t-testdir.20160719.master.tar.gz' It tries to replace the "backup_date" with an "*" to get a file pattern of the same backups, but instead of generating: file_pattern='./repository/7a98879f7f9c-home-lamby-temp-cdt. 20160719180425.csSPyc7zqz-backup-manager-0.7.12-t-testdir.*.master.tar.gz' it ends up modifying parts that are related to the file path. For this particular check, changing the sed expression from: "s/$date_of_file/\*/" to "s/\\(.*\\)$date_of_file/\\1\*/" should be enough (lib/files.sh). Although, not a very "safe" way to mangle filenames. :/ I'll commit the patch, and I guess I should be able to reproduce the issue now. Happy hacking, -- "The sooner you start to code, the longer the program will take." -- Roy Carlson Saludos /\/\ /\ >< `/ signature.asc Description: This is a digitally signed message part.
Bug#831759: fixed in backup-manager 0.7.12-2
¡Hola Santiago! 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 ? Happy hacking, -- “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are–by definition–not smart enough to debug it.” -- Brian Kernighan Saludos /\/\ /\ >< `/ signature.asc Description: Digital signature
Bug#831759: fixed in backup-manager 0.7.12-2
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 /\/\ /\ >< `/ signature.asc Description: Digital signature
