Opened 17 years ago
Closed 16 years ago
#2090 closed enhancement (fixed)
Tar-1.19
| Reported by: | Matthew Burgess | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.0 |
| Component: | Book | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
New version. Release announcement at http://lists.gnu.org/archive/html/bug-tar/2007-10/msg00009.html.
Change History (6)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Failing test 26 is not exactly new. FWIW I saw this in the build up to 6.3. See e.g. http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg10267.html where Greg pointed out this and test 29 commonly failed.
comment:3 by , 17 years ago
OK, given that they intermittently occur and reports appear to have fallen on deaf ears, I think we should change the test suite instructions to be similar to Glibc/GCC's. 'make check' becomes 'make -k check' then we advise the reader to check the results of the tests noting that tests 26 and 29 are known to fail intermittently.
Sorry for not acting on your previous report of this, Ken.
follow-up: 5 comment:4 by , 17 years ago
I didn't think it needed any action. I think it still runs all the tests without '-k' (or did it stop after failing 26?), and you get an error indication with or without '-k'. We don't ostensibly support automation/scripts, so unless it needs something for jhalfs I think the current commands are ok.
Wouldn't do any harm to mention possible failures, I suppose. (I'd overlooked that earlier).
comment:5 by , 17 years ago
Replying to ken@linuxfromscratch.org:
I didn't think it needed any action. I think it still runs all the tests without '-k' (or did it stop after failing 26?), and you get an error indication with or without '-k'. We don't ostensibly support automation/scripts, so unless it needs something for jhalfs I think the current commands are ok.
| true' type construct to support jhalfs. |
Wouldn't do any harm to mention possible failures, I suppose. (I'd overlooked that earlier).
Yeah, they certainly caught me out. Having never had a single failure in the tar testsuite, despite them occuring pretty widely for different folks, I thought they were new.
This fails test 26:
If someone can reproduce this, that'd be great, then I'll look into reporting it upstream. Note that this was done using gcc-4.2.2 and glibc-2.7. Test results against other toolchains would be useful too though. Tar-1.18 passes with the same toolchain though, so this certainly looks like a regression.