Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t
Hi Paul,
finally found time to tackle this.
Axel Beckert wrote:
> > Can you please investigate the situation
>
> Already done. Issue are mostly hardcoded x86_64 and amd64 strings in
> the test suite.
>
> Problem is IIRC that Lintian's testsuite currently doesn't support a
> templating system, at least not for many of these places. IIRC I fixed
> already some of them which were easy to fix.
Actually there seems a possibility to fix this like in these cases
t/recipes/checks/desktop/gnome/gir/gir/eval/post-test which has the
following sed command in it:
s, usr/lib/[^/${}]+/girepository-1.0$, usr/lib/MULTIARCH/girepository-1.0,
But it doesn't seem to be applied in the comparison, because if I put
"MULTIARCH" into the hints file, it fails on amd64 as well.
Another weird point seems that
t/recipes/checks/desktop/gnome/gir/gir/eval/desc says:
Testname: gir
Check: desktop/gnome/gir
Test-Architecture: amd64
So that clearly means it should only be run on amd64. So why is it run
on arm64 at all?
Hrm, a "git grep Test-Architecture" shows that most if not all other
such cases have "Test-Architectures" (plural with trailing "s") in
that place. So this is a typo which hasn't been caught yet.
So with my commit f415bc56c4b40d25410af21f2ea629e8eb0733b6 this part
of the test failures should be fixed. And with commit
695582b83f397d6bd5f47f99af77b2195ed1e604 we should also have an
internal check which finds such field name typos. (Needs to be
maintained, though, if fields get added or removed.)
Still need to figure out where the issue with bin-sbin-mismatch. But
that tag is known (at least to me) for weird false positives.
Paul Gevers wrote:
> On 10-12-2022 22:55, Axel Beckert wrote:
> > Ehm, that version no more in the archive anywhere. Did you maybe mean
> > 2.115.3 as currently in Testing and Unstable? (Feel free to remove the
> > moreinfo tag once this is clarified.)
>
> I meant, I see the issue *since* that version.
Ah, ok. Yeah, kinda makes sense. I kinda expected that this version is
usually the one the bug report was written against with any additional
version hints being added as secondary version via Control statements.
> But indeed, that's a bit weird if not commented on. I have added a
> `found` version now.
Thanks!
> > Will have to look into it again, but I fear in short term, it means to
> > either reduce the tests or only run a subset on non-amd64
> > architectures.
>
> If the test can't easily support other architectures (which is fine in my
> opinion) than please ensure it only runs on amd64. I advice to do that by
> adding a "Architecture: amd64" field to d/t/control.
Thanks for that hint. But there's already enough code in place for
that so that making it work should be merely fixing a few more lines.
The big question is which lines. ;-) But at least half of the issue is
fixed already.
P.S.: Any idea how we get Salsa CI autopkgtests on arm64?
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Reply to: