[Debian-med-packaging] Bug#969804: Bug#969804: bart: autopkgtest should be marked superficial

[Andreas Tille]

Hi Martin,

On Mon, Sep 21, 2020 at 09:26:41AM +0000, Uecker, Martin wrote:
> > To the best of my knowledge the fact that a test runs on amd64 but fails
> > on some other architecture is not only caused by issues in the tool
> > chain.  For instance recently I learned that for instance if char is
> > used as "very short int" it matters whether it is declared as char,
> > signed char or unsigned char.  
> 
> I know, this is also why I originally thought it would be
> a good idea.
> 
> > To spot this kind of issues it makes
> > perfectly sense to run the test suite on all architectures - except
> > for those where we expicitly know that a broken tool chain is breaking
> > the build.
> 
> If there were an easy way to log into a s390x machine
> and debug the problem, the outcome would likely be a useful
> bug report against GCC which would be useful to the community
> and the s390x port.  But as things are, it only causes
> unnecessary work for us to not get the package removed while
> we learned nothing about the underlying issue.

I *really* appreciate your attempt to get access to one of the porter
boxes and its a real shame that this procedure has turned out to be so
complicated that we gave up.

However, the solution I've just uploaded will IMHO reach approach what
you want (letting the package build) and at the same time print possible
issues inside the build logs.  I activated this for other architectures
I consider at least "interesting" (but not for all since I don't know
about potential performance issues).
 
> > Thus my suggestion to exclude only the affected s390x from the test.
> > If my suggestion is not worded clearly enough feel free to ping me and
> > I implement my suggestion in d/rules to show what I mean.
> 
> Well, the idea would be to do exactly this but pro-actively
> for all architectures except amd64. We would still get
> the information when tests fail (which is useful) but
> avoid wasting effort on fixing it each time.

May be I misunderstood you - but if you do not run the test at all
(as done in some architectures) how will you know whether the test
might fail?  May be I miss your point here and thus I implemented
my suggestion and we'll see what happends on the buildd logs soon.
 
Kind regards

       Andreas.

-- 
http://fam-tille.de