Bug#402179: tar: FTBFS: race condition in test-suite
On Sun, Jan 07, 2007 at 02:46:42PM -0700, Bdale Garbee wrote: As I've stated before, I'm not sure that fixing this bug for etch is really useful. Of course, if there's a reason to update the tar in etch for a security bug or something similar, fixing this too would make good sense. But since it's only a race condition in the regression suite and makes no difference to the tar binary itself, and the tar package in etch is already built for all relevant release architectures, taking the risk of changing the tar package just to fix this isn't obviously worthwhile to me. I agree for the most part. But if you think this bug shouldn't be fixed for etch, I think it either needs to be marked as non release critical or it should be tagged etch-ignore. I've CC'd the release team, to get their input on it. Anyway, the only reason I see that we want to fix it in etch now is that in case we later want a new version of tar in etch we don't get hit by the problem. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402179: tar: FTBFS: race condition in test-suite
* Kurt Roeckx ([EMAIL PROTECTED]) [070108 19:35]: Anyway, the only reason I see that we want to fix it in etch now is that in case we later want a new version of tar in etch we don't get hit by the problem. If I look at the stats, it doesn't seem too probably to be hit by it, and a simple retry would resolve it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402179: tar: FTBFS: race condition in test-suite
severity 402179 important user debian-release@lists.debian.org usertag 402179 rc-m68k thanks On Mon, Jan 08, 2007 at 07:39:46PM +0100, Andreas Barth wrote: * Kurt Roeckx ([EMAIL PROTECTED]) [070108 19:35]: Anyway, the only reason I see that we want to fix it in etch now is that in case we later want a new version of tar in etch we don't get hit by the problem. If I look at the stats, it doesn't seem too probably to be hit by it, and a simple retry would resolve it. I think we've been fence-sitting on this long enough. Most of the time, timestamp race condition bugs will affect certain kernels or architectures with a high probability because the filesystem's timestamp resolution is high enough that a clock cycle is a significant fraction of it. That doesn't seem to be the case here, with the /possible/ exception of m68k; on all other archs, the probability of hitting the race is low enough that working around it by retrying the package is trivial. So I think downgrading the bug is ok here, with an rc-m68k usertag because of the uncertainty on that arch. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402179: tar: FTBFS: race condition in test-suite
On Sat, 2007-01-06 at 17:26 +0100, Kurt Roeckx wrote: Hi, What's the status of this bug? There's a patch available form upstream for some time now. Would you mind I did an NMU for this? I'm working on 1.16.1 for unstable. Are you contemplating an NMU for unstable or etch? Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402179: tar: FTBFS: race condition in test-suite
On Sun, Jan 07, 2007 at 11:06:33AM -0700, Bdale Garbee wrote: On Sat, 2007-01-06 at 17:26 +0100, Kurt Roeckx wrote: Hi, What's the status of this bug? There's a patch available form upstream for some time now. Would you mind I did an NMU for this? I'm working on 1.16.1 for unstable. Are you contemplating an NMU for unstable or etch? I was planning on getting it into etch. I'm not sure if the release team is going to approve 1.16.1, specially since I don't even know what changed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402179: tar: FTBFS: race condition in test-suite
On Sun, 2007-01-07 at 19:13 +0100, Kurt Roeckx wrote: I was planning on getting it into etch. As I've stated before, I'm not sure that fixing this bug for etch is really useful. Of course, if there's a reason to update the tar in etch for a security bug or something similar, fixing this too would make good sense. But since it's only a race condition in the regression suite and makes no difference to the tar binary itself, and the tar package in etch is already built for all relevant release architectures, taking the risk of changing the tar package just to fix this isn't obviously worthwhile to me. The right fix for unstable is 1.16.1 plus patches from upstream. While I think this version is generally better than 1.16, enough has changed that I would *not* expect the release team to want this version for etch at this late date. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402179: tar: FTBFS: race condition in test-suite
Hi, What's the status of this bug? There's a patch available form upstream for some time now. Would you mind I did an NMU for this? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402179: tar: FTBFS: race condition in test-suite
This bug seems to only occur for the posix format tar archives. It's repeatable outside the tar test suite by doing: #!/bin/sh export TAR_OPTIONS=-H posix --pax-option=exthdr.name=%d/PaxHeaders/%f echo hello file1 echo goodbye file2 while :; do tar cf archive.1 file1 file2 tar cfT archive.2 /dev/null tar rf archive.2 file1 tar rf archive.2 file2 if cmp archive.1 archive.2 /dev/null; then echo -n . else echo -n + fi done The output should be all dots if the assumptions of the test are correct, but I get: +...+..+ ..++.++. .+.. ...+ .+.. ...+ .+.+ Which is to say it fails about 3% of the time on my system (stable over about 2000 iterations). I'd say that warrants downgrading this bug from serious. The fundamental problem seems to be that the POSIX format tarballs include the atime of the files in the archive (which may change between adding the file to the first archive and the second), and the mtime of the archive itself (which likewise may change). I don't see any way to work around that, though -- --atime-preserve helps (by eliminating the atimes), but that still leaves it failing around 1.7% of the time (when the mtimes don't match, presumably). If the test is run on a filesystem that preserves timestamps to the nanosecond (or possibly even the microsecond?), this test will always fail. Cheers, aj signature.asc Description: Digital signature
Bug#402179: tar: FTBFS: race condition in test-suite
Package: tar Version: 1.16-2 Severity: serious Hello Bdale, tar test-suite tests/append02.at has a race condition which cause the test to fail sometimes, and thus the package to FTBFS. echo Creating archive.1 tar cf archive.1 file1 file2 here echo Creating archive.2 tar cfT archive.2 /dev/null tar rf archive.2 file1 tar rf archive.2 file2 If one add sleep 2 at here, the test fails consistently. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
