Failing tests & upcoming release
Johannes Schindelin
there are some tests failing, and I am willing to release a new version
with the current 'devel' even so, to point out the experimental nature of
msysGit, and that everybody needs to scratch her own itches.
In particular, the tests that fail are:
t0100.1 t0100.2 t0100.3
t0101.2 t0101.3 t0101.4 t0101.5 t0101.6
t1400.22 t1400.27 t1400.38 t1400.40 t1400.41
t1402.15
t1410.1 t1410.2 t1410.3 t1410.4 t1410.5 t1410.7 t1410.8 t1410.9 t1410.10
t1410.11 t1410.12
t1411.2 t1411.3 t1411.4 t1411.5 t1411.6 t1411.7
t1505.2 t1505.3 t1505.4 t1505.5 t1505.6
t1507.7 t1507.13 t1507.14
t1508.3 t1508.4 t1508.5 t1508.7 t1508.8 t1508.9
t2012.4 t2012.5 t2012.7 t2012.8 t2012.10 t2012.11 t2012.12 t2012.13 t2012.14
t3200.5 t3200.30
t3301.10
t3402.4
t3404.6 t3404.17
t3408.2
t3903.7 t3903.8 t3903.9 t3903.10 t3903.13 t3903.14 t3903.15 t3903.16
t3903.17 t3903.19
t4030.9 t4030.10 t4030.11
t5000.12
t5407.4 t5407.5 t5407.6 t5407.7 t5407.8 t5407.9 t5407.10 t5407.11 t5407.12
t5520.11 t5520.12
t5560.2 t5560.3 t5560.4 t5560.5 t5560.6 t5560.7 t5560.8 t5560.9 t5560.10
t5560.11 t5560.12 t5560.13
t6006.30
t7602.3 t7602.4 t7602.5
t7701.1
t9001.8 t9001.10 t9001.12
t9300.37
t9500.1 t9500.2 t9500.3 t9500.4 t9500.5 t9500.6 t9500.7 t9500.8 t9500.10
t9500.11 t9500.12 t9500.13 t9500.14 t9500.15 t9500.16 t9500.17 t9500.18
t9500.19 t9500.20 t9500.21 t9500.22 t9500.23 t9500.24 t9500.25 t9500.26
t9500.27 t9500.28 t9500.29 t9500.30 t9500.32 t9500.33 t9500.34 t9500.35
t9500.36 t9500.38 t9500.39 t9500.40 t9500.41 t9500.42 t9500.43 t9500.44
t9500.45 t9500.47 t9500.48 t9500.50 t9500.51 t9500.52 t9500.53 t9500.54
t9500.55 t9500.56 t9500.57 t9500.58 t9500.59 t9500.60 t9500.61 t9500.62
t9500.63 t9500.64 t9500.65 t9500.66 t9500.67 t9500.68 t9500.69 t9500.70
t9500.71 t9500.72 t9500.73 t9500.74 t9500.75 t9500.76 t9500.77 t9500.78
t9500.79 t9500.80 t9500.81 t9500.82 t9500.83 t9500.84 t9500.85 t9500.86
t9500.87 t9500.88
t9501.1 t9501.2 t9501.3 t9501.4 t9501.5 t9501.6 t9501.7 t9501.8 t9501.9
t9501.10 t9501.11
t9502.2 t9502.3 t9502.4 t9502.5 t9502.6 t9502.7 t9502.8 t9502.9 t9502.10
Ciao,
Dscho
Joshua Jensen
From: Johannes Schindelin
Date: 6/11/2010 11:34 AM
> there are some tests failing, and I am willing to release a new version
> with the current 'devel' even so, to point out the experimental nature of
> msysGit, and that everybody needs to scratch her own itches.
>
> In particular, the tests that fail are:
>
> t0100.1 t0100.2 t0100.3
> t0101.2 t0101.3 t0101.4 t0101.5 t0101.6
> t1400.22 t1400.27 t1400.38 t1400.40 t1400.41
> t1402.15
> t1410.1 t1410.2 t1410.3 t1410.4 t1410.5 t1410.7 t1410.8 t1410.9 t1410.10
> t1410.11 t1410.12
> t1411.2 t1411.3 t1411.4 t1411.5 t1411.6 t1411.7
> t1505.2 t1505.3 t1505.4 t1505.5 t1505.6
> t1507.7 t1507.13 t1507.14
> t1508.3 t1508.4 t1508.5 t1508.7 t1508.8 t1508.9
> t2012.4 t2012.5 t2012.7 t2012.8 t2012.10 t2012.11 t2012.12 t2012.13 t2012.14
Unfortunately, as it always does for me, make test hangs on t3030.18 and
t3030.19 and t3030.22. If I cancel that one, it hangs on some later
ones. After 5 or so times of doing that, I gave up. I don't actually
understand what merge-recursive does, so I have just never been able to
run the test suite.
This happens on two separate Windows 7 machines with an msysGit from the
netinstaller.
Josh
Johannes Schindelin
On Fri, 11 Jun 2010, Joshua Jensen wrote:
> ----- Original Message -----
> From: Johannes Schindelin
> Date: 6/11/2010 11:34 AM
> > there are some tests failing, and I am willing to release a new version
> > with the current 'devel' even so, to point out the experimental nature of
> > msysGit, and that everybody needs to scratch her own itches.
> >
> > In particular, the tests that fail are:
> >
> > t0100.1 t0100.2 t0100.3
> > t0101.2 t0101.3 t0101.4 t0101.5 t0101.6
> > t1400.22 t1400.27 t1400.38 t1400.40 t1400.41
> > t1402.15
> > t1410.1 t1410.2 t1410.3 t1410.4 t1410.5 t1410.7 t1410.8 t1410.9 t1410.10
> > t1410.11 t1410.12
> > t1411.2 t1411.3 t1411.4 t1411.5 t1411.6 t1411.7
> > t1505.2 t1505.3 t1505.4 t1505.5 t1505.6
> > t1507.7 t1507.13 t1507.14
> > t1508.3 t1508.4 t1508.5 t1508.7 t1508.8 t1508.9
> > t2012.4 t2012.5 t2012.7 t2012.8 t2012.10 t2012.11 t2012.12 t2012.13 t2012.14
>
> I ran 'make test', and all of these succeed.
Thanks.
Can you make sure that you are on 4msysgit's 'devel'? (cd /git/ && git
branch)
Ciao,
Dscho
Joshua Jensen
latest, but I had forgotten to merge it in.
The SHA-1 I was successfully running tests against was
602f01ceba0ef8c1ea3c78e68bf12f276059344d.
Josh
Johannes Schindelin
Thank you. The tests I was referring to were failing with
33a93b326ed7e20062e896c7a82986fc9b402774.
FWIW I think that quite a number of the tests fail here because the reflog
files written to .git/logs/ are 0-sized for some reason, although they
work when committing interactively.
Ciao,
Dscho
Joshua Jensen
FWIW, the v1.7.1 tag builds fine and passes the tests until it hangs for
me in the merge-recursive one I mentioned earlier.
Josh
Johannes Schindelin
On Fri, 11 Jun 2010, Joshua Jensen wrote:
I fear that it makes no sense to work on the v1.7.1 tag. We have quite a
few patches on top of v1.7.1, and you risk having to re-fix something that
has been fixed in 'devel' already.
For bisecting a regression relative to v1.7.1, it is okay to test v1.7.1,
sure, but not as a baseline.
Ciao,
Dscho
Johannes Schindelin
Actually, the suggestion to use it in the bisection which was triggered by
your comment led directly to the resolution:
http://repo.or.cz/w/git/mingw/4msysgit.git/commitdiff/298d4c3fb2514cf152645118918e20ef79c0324a
The proper solution would be to return the xstrdup()ed path, but I was not
in the mood to git grep all code paths calling log_ref_setup() and fix it
that way. After all, I did all the hard work already by debugging the
issue, so IMO I deserve some time off.
Ciao,
Dscho
Johannes Schindelin
What I meant was: I think that this is something people even with little
time can do.
As for your t3030 thing: I am pretty certain that it is due to two failed
unlink() calls. Apparently, some file pointers are not closed, so the
respective files cannot be deleted.
FWIW this is where I explained in a lot of detail how you can debug
regression like this one:
https://git.wiki.kernel.org/index.php/What_to_do_when_a_test_fails
Update on the failing tests: many tests pass now with the workaround I
pushed to devel. Still failing:
t5000.12
t5560.2 t5560.3 t5560.4 t5560.5 t5560.6 t5560.7 t5560.8 t5560.9 t5560.10
t5560.11 t5560.12 t5560.13
t7602.3 t7602.4 t7602.5
t9001.8 t9001.10 t9001.12
Joshua Jensen
Here is the discussion about this commit:
http://lists-archives.org/git/720279-refs-split-log_ref_write-logic-into-log_ref_setup.html.
It is even mentioned that the buffer ought to be static. I'm surprised
regular Git isn't dying left and right because of this.
Josh
Joshua Jensen
From: Johannes Schindelin
>> The proper solution would be to return the xstrdup()ed path, but I was
>> not in the mood to git grep all code paths calling log_ref_setup() and
>> fix it that way. After all, I did all the hard work already by debugging
>> the issue, so IMO I deserve some time off.
> What I meant was: I think that this is something people even with little
> time can do.
working. I don't know why. I went back to v1.7.1 and sent the previous
mail.
> As for your t3030 thing: I am pretty certain that it is due to two failed
> unlink() calls. Apparently, some file pointers are not closed, so the
> respective files cannot be deleted.
>
> FWIW this is where I explained in a lot of detail how you can debug
> regression like this one:
>
> https://git.wiki.kernel.org/index.php/What_to_do_when_a_test_fails
to how you are getting past it and I am not. I've now tested the net
installer on 3 machines with the same result. I'm out of town for the
weekend, but I'll look at it soon.
Thanks for the link. It will help.
Josh
Johannes Schindelin
Thanks for the link!
I still think that the static buffer is just an ugly workaround, but not
enough to delay a release.
Sleep must come first, though,
Dscho
Johannes Schindelin
On Fri, 11 Jun 2010, Joshua Jensen wrote:
> ----- Original Message -----
> From: Johannes Schindelin
> Date: 6/11/2010 4:16 PM
> > > The proper solution would be to return the xstrdup()ed path, but I
> > > was not in the mood to git grep all code paths calling
> > > log_ref_setup() and fix it that way. After all, I did all the hard
> > > work already by debugging the issue, so IMO I deserve some time off.
> >
> > What I meant was: I think that this is something people even with
> > little time can do.
>
> Agreed. I was bisecting between v1.7.1 and devel, but then Perl stopped
> working. I don't know why. I went back to v1.7.1 and sent the previous
> mail.
Well, I had problems with "git bisect run", until I realized that that
Windows habit of preferring the current directory's executables over the
ones in the PATH was hurting my workflow. Maybe this is related to your
issue?
> > As for your t3030 thing: I am pretty certain that it is due to two
> > failed unlink() calls. Apparently, some file pointers are not closed,
> > so the respective files cannot be deleted.
> >
> > FWIW this is where I explained in a lot of detail how you can debug
> > regression like this one:
> >
> > https://git.wiki.kernel.org/index.php/What_to_do_when_a_test_fails
>
> I plan on discovering the cause of the t3030 issue, but I am confused as
> to how you are getting past it and I am not. I've now tested the net
> installer on 3 machines with the same result. I'm out of town for the
> weekend, but I'll look at it soon.
Well, I cheated. I ran /share/msysGit/run-tests.sh, which runs the tests
in parallel _and_ continues in spite of errors.
FWIW I really think that you should at least once run t3030 with -i -v to
see the issue and to get an idea what code might have opened the files.
Ciao,
Dscho
Johannes Sixt
> Hi,
>
> On Fri, 11 Jun 2010, Joshua Jensen wrote:
> > ----- Original Message -----
> > From: Johannes Schindelin
> > Date: 6/11/2010 3:58 PM
> >
> > > Actually, the suggestion to use it in the bisection which was triggered
> > > by your comment led directly to the resolution:
> > >
> > > http://repo.or.cz/w/git/mingw/4msysgit.git/commitdiff/298d4c3fb2514cf15
> > >2645118918e20ef79c0324a
> > >
> > > The proper solution would be to return the xstrdup()ed path, but I was
> > > not in the mood to git grep all code paths calling log_ref_setup() and
> > > fix it that way. After all, I did all the hard work already by
> > > debugging the issue, so IMO I deserve some time off.
> >
> > I agree. That code is seriously flawed.
> >
> > Here is the discussion about this commit:
> > http://lists-archives.org/git/720279-refs-split-log_ref_write-logic-into-
> >log_ref_setup.html.
> >
> > It is even mentioned that the buffer ought to be static. I'm surprised
> > regular Git isn't dying left and right because of this.
A thorough fix of this bug is currently discussed on the list:
http://thread.gmane.org/gmane.comp.version-control.git/148862/focus=148864
-- Hannes
Albert Dvornik
<Johannes....@gmx.de> wrote:
> As for your t3030 thing: I am pretty certain that it is due to two failed
> unlink() calls. Apparently, some file pointers are not closed, so the
> respective files cannot be deleted.
The hang itself seems to happen because Git is asking for some input
(when stdin is a tty even though stdout and stderr aren't); I don't
see the hang if I run "/share/msysGit/run-tests.sh < /dev/null", and I
do see it without the redirect. So we should probably fix both the
underlying unlink, and the behavior where the user is queried with a
question they can't see.
(At first I thought we lost commit 7f6094d1, but that's not it... this
just has similar symptoms.)
I hope I'll find some time to look into this within the next few days,
assuming no one else does.
--bert
Heiko Voigt
Maybe this patch does fix the issue ?
http://thread.gmane.org/gmane.comp.version-control.msysgit/9797/
i had a quick glance at the current source and it does not seem to be
applied. It somehow did get lost in the noise for me although I did
answer to it. Albert could you check and verify whether it fixes the
issue? I can then push it to devel if nobody objects.
cheers Heiko
Johannes Schindelin
On Sun, 13 Jun 2010, Heiko Voigt wrote:
> On Sun, Jun 13, 2010 at 03:33:45PM -0400, Albert Dvornik wrote:
> > On Fri, Jun 11, 2010 at 6:16 PM, Johannes Schindelin
> > <Johannes....@gmx.de> wrote:
> > > As for your t3030 thing: I am pretty certain that it is due to two failed
> > > unlink() calls. Apparently, some file pointers are not closed, so the
> > > respective files cannot be deleted.
> >
> > The hang itself seems to happen because Git is asking for some input
> > (when stdin is a tty even though stdout and stderr aren't); I don't
> > see the hang if I run "/share/msysGit/run-tests.sh < /dev/null", and I
> > do see it without the redirect. So we should probably fix both the
> > underlying unlink, and the behavior where the user is queried with a
> > question they can't see.
> >
> > (At first I thought we lost commit 7f6094d1, but that's not it... this
> > just has similar symptoms.)
> >
> > I hope I'll find some time to look into this within the next few days,
> > assuming no one else does.
>
> Maybe this patch does fix the issue ?
>
> http://thread.gmane.org/gmane.comp.version-control.msysgit/9797/
I was under the impression that it _is_ 7f6094d1.
FWIW I applied 012caf01, which I hope will fix the issue at least with
run-tests.sh.
Ciao,
Dscho
Heiko Voigt
I clearly need to do some catching up. I did not know that this patch is
already in devel. I tested it today and the hang occurs on master and on
devel (with and without the patch). I also added stdout here[1] and it
still hangs. So my impression is that isatty() does not always work
correctly. Does anyone know a more stable system call on windows we
could use?
> FWIW I applied 012caf01, which I hope will fix the issue at least with
> run-tests.sh.
I can not find the commit you are referring to. Is it already pushed out?
cheers Heiko
[1] http://repo.or.cz/w/git/mingw/4msysgit.git/blob/devel:/compat/mingw.c#l178
Johannes Schindelin
On Mon, 14 Jun 2010, Heiko Voigt wrote:
> On Sun, Jun 13, 2010 at 11:49:22PM +0200, Johannes Schindelin wrote:
> > On Sun, 13 Jun 2010, Heiko Voigt wrote:
> > > Maybe this patch does fix the issue ?
> > >
> > > http://thread.gmane.org/gmane.comp.version-control.msysgit/9797/
> >
> > I was under the impression that it _is_ 7f6094d1.
>
> I clearly need to do some catching up. I did not know that this patch is
> already in devel. I tested it today and the hang occurs on master and on
> devel (with and without the patch). I also added stdout here[1] and it
> still hangs. So my impression is that isatty() does not always work
> correctly. Does anyone know a more stable system call on windows we
> could use?
Have you tried with < /dev/null ?
> > FWIW I applied 012caf01, which I hope will fix the issue at least with
> > run-tests.sh.
>
> I can not find the commit you are referring to. Is it already pushed
> out?
Yes, but I should have made it clear that this is a patch to msysgit.git,
not 4msysgit.git.
Ciao,
Dscho
Heiko Voigt
On Mon, Jun 14, 2010 at 06:46:49PM +0200, Johannes Schindelin wrote:
> On Mon, 14 Jun 2010, Heiko Voigt wrote:
>
> > On Sun, Jun 13, 2010 at 11:49:22PM +0200, Johannes Schindelin wrote:
> > > On Sun, 13 Jun 2010, Heiko Voigt wrote:
> > > > Maybe this patch does fix the issue ?
> > > >
> > > > http://thread.gmane.org/gmane.comp.version-control.msysgit/9797/
> > >
> > > I was under the impression that it _is_ 7f6094d1.
> >
> > I clearly need to do some catching up. I did not know that this patch is
> > already in devel. I tested it today and the hang occurs on master and on
> > devel (with and without the patch). I also added stdout here[1] and it
> > still hangs. So my impression is that isatty() does not always work
> > correctly. Does anyone know a more stable system call on windows we
> > could use?
>
> Have you tried with < /dev/null ?
Yes and it did fix the hang with ./t3030-merge-recursive.sh < /dev/null
> > > FWIW I applied 012caf01, which I hope will fix the issue at least with
> > > run-tests.sh.
> >
> > I can not find the commit you are referring to. Is it already pushed
> > out?
>
> Yes, but I should have made it clear that this is a patch to msysgit.git,
> not 4msysgit.git.
Found it. As from the experience above that probably is a workaround for
the issue. If I get a chance I will try it tomorrow.
cheers Heiko
Johannes Schindelin
On Mon, 14 Jun 2010, Heiko Voigt wrote:
> On Mon, Jun 14, 2010 at 06:46:49PM +0200, Johannes Schindelin wrote:
> > On Mon, 14 Jun 2010, Heiko Voigt wrote:
> >
> > > On Sun, Jun 13, 2010 at 11:49:22PM +0200, Johannes Schindelin wrote:
> > > > On Sun, 13 Jun 2010, Heiko Voigt wrote:
> > > > > Maybe this patch does fix the issue ?
> > > > >
> > > > > http://thread.gmane.org/gmane.comp.version-control.msysgit/9797/
> > > >
> > > > I was under the impression that it _is_ 7f6094d1.
> > >
> > > I clearly need to do some catching up. I did not know that this patch is
> > > already in devel. I tested it today and the hang occurs on master and on
> > > devel (with and without the patch). I also added stdout here[1] and it
> > > still hangs. So my impression is that isatty() does not always work
> > > correctly. Does anyone know a more stable system call on windows we
> > > could use?
> >
> > Have you tried with < /dev/null ?
>
> Yes and it did fix the hang with ./t3030-merge-recursive.sh < /dev/null
Maybe we should do the "exec < /dev/null" at the start of test-lib.sh, as
was suggested before?
> > > > FWIW I applied 012caf01, which I hope will fix the issue at least
> > > > with run-tests.sh.
> > >
> > > I can not find the commit you are referring to. Is it already pushed
> > > out?
> >
> > Yes, but I should have made it clear that this is a patch to
> > msysgit.git, not 4msysgit.git.
>
> Found it. As from the experience above that probably is a workaround for
> the issue. If I get a chance I will try it tomorrow.
It is a workaround if you use run-tests.sh, which is the case for exactly
one person on this planet, most likely.
Ciao,
Dscho
Heiko Voigt
On Mon, Jun 14, 2010 at 07:31:48PM +0200, Johannes Schindelin wrote:
> On Mon, 14 Jun 2010, Heiko Voigt wrote:
>
> > On Mon, Jun 14, 2010 at 06:46:49PM +0200, Johannes Schindelin wrote:
> > > On Mon, 14 Jun 2010, Heiko Voigt wrote:
> > >
> > > > On Sun, Jun 13, 2010 at 11:49:22PM +0200, Johannes Schindelin wrote:
> > > > > On Sun, 13 Jun 2010, Heiko Voigt wrote:
> > > > > > Maybe this patch does fix the issue ?
> > > > > >
> > > > > > http://thread.gmane.org/gmane.comp.version-control.msysgit/9797/
> > > > >
> > > > > I was under the impression that it _is_ 7f6094d1.
> > > >
> > > > I clearly need to do some catching up. I did not know that this patch is
> > > > already in devel. I tested it today and the hang occurs on master and on
> > > > devel (with and without the patch). I also added stdout here[1] and it
> > > > still hangs. So my impression is that isatty() does not always work
> > > > correctly. Does anyone know a more stable system call on windows we
> > > > could use?
> > >
> > > Have you tried with < /dev/null ?
> >
> > Yes and it did fix the hang with ./t3030-merge-recursive.sh < /dev/null
>
> Maybe we should do the "exec < /dev/null" at the start of test-lib.sh, as
> was suggested before?
I tried this as well and its working for me (Windows 7). It seems to be
the most complete workaround.
> > > > > FWIW I applied 012caf01, which I hope will fix the issue at least
> > > > > with run-tests.sh.
> > > >
> > > > I can not find the commit you are referring to. Is it already pushed
> > > > out?
> > >
> > > Yes, but I should have made it clear that this is a patch to
> > > msysgit.git, not 4msysgit.git.
> >
> > Found it. As from the experience above that probably is a workaround for
> > the issue. If I get a chance I will try it tomorrow.
>
> It is a workaround if you use run-tests.sh, which is the case for exactly
> one person on this planet, most likely.
No at least two ;) But I think the suggestion above makes more sense as
it enables you to run single testcases as well.
cheers Heiko
Johannes Schindelin
On Tue, 15 Jun 2010, Heiko Voigt wrote:
> On Mon, Jun 14, 2010 at 07:31:48PM +0200, Johannes Schindelin wrote:
>
> > Maybe we should do the "exec < /dev/null" at the start of test-lib.sh,
> > as was suggested before?
>
> I tried this as well and its working for me (Windows 7). It seems to be
> the most complete workaround.
Since you almost have the commit, would you care to commit and push it?
Thanks,
Dscho
Heiko Voigt
Done. My Windows 7 machine at $dayjob has a quite "complicated"
relationship to the internet. So this is now also tested on Windows XP.
cheers Heiko
Johannes Schindelin
Thanks!
Dscho
Johannes Schindelin
On Fri, 11 Jun 2010, Johannes Schindelin wrote:
> Dear msysGit fans,
>
> there are some tests failing, and I am willing to release a new version
> with the current 'devel' even so, to point out the experimental nature
> of msysGit, and that everybody needs to scratch her own itches.
The current state of affairs:
t5000.12
t5407.4 t5407.5 t5407.6 t5407.7 t5407.8 t5407.9 t5407.10 t5407.11 t5407.12
t5560.2 t5560.3 t5560.4 t5560.5 t5560.6 t5560.7 t5560.8 t5560.9 t5560.10
t5560.11 t5560.12 t5560.13
t7508.51 t7508.52
t9001.8 t9001.10 t9001.12 (probably only due to a half-working rsh.exe)
t9500.1 t9500.2 t9500.3 t9500.4 t9500.5 t9500.6 t9500.7 t9500.8 t9500.10
t9500.11 t9500.12 t9500.13 t9500.14 t9500.15 t9500.16 t9500.17 t9500.18
t9500.19 t9500.20 t9500.21 t9500.22 t9500.23 t9500.24 t9500.25 t9500.26
t9500.27 t9500.28 t9500.29 t9500.30 t9500.32 t9500.33 t9500.34 t9500.35
t9500.36 t9500.38 t9500.39 t9500.40 t9500.41 t9500.42 t9500.43 t9500.44
t9500.45 t9500.47 t9500.48 t9500.50 t9500.51 t9500.52 t9500.53 t9500.54
t9500.55 t9500.56 t9500.57 t9500.58 t9500.59 t9500.60 t9500.61 t9500.62
t9500.63 t9500.64 t9500.65 t9500.66 t9500.67 t9500.68 t9500.69 t9500.70
t9500.71 t9500.72 t9500.73 t9500.74 t9500.75 t9500.76 t9500.77 t9500.78
t9500.79 t9500.80 t9500.81 t9500.82 t9500.83 t9500.84 t9500.85 t9500.86
t9500.87 t9500.88
t9501.1 t9501.2 t9501.3 t9501.4 t9501.5 t9501.6 t9501.7 t9501.8 t9501.9
t9501.10 t9501.11
t9502.2 t9502.3 t9502.4 t9502.5 t9502.6 t9502.7 t9502.8 t9502.9 t9502.10
Ciao,
Johannes