Re: src:exempi: fails to migrate to testing for too long: FTBFS on s390x

Hi Paul,


since a partial removal of exempi on s390x will have a ripple effect on 
our rdeps (e.g. GNOME), I will probably override dh_auto_test to ignore 
any failures on s390x to avoid unnecessary work for rdeps of src:exempi.
I do not really like this situation though, so I'd very much appreciate 
if Dipak or any other s390x porter would look into this issue.

Regards,
Michael

Am 23.09.22 um 21:38 schrieb Paul Gevers:
> Hi Dipak,
> 
> On Tue, 30 Aug 2022 09:57:44 +0000 Dipak Zope1 <[email protected]> wrote:
>> Apologies for late response. It looks like the issue is related to the 
>> synchronization between atop and atopacctd. I am looking into it 
>> further and will keep this thread updated.
> 
> I think we established that you replied here but had the other bug in 
> mind (in atop).
> 
>> I am looking forward to have a fix for this for s390x.
> 
> Can you still look into the exempi issue in this bug report?
> 
>> On 30/08/22, 12:44 AM, "Paul Gevers" <[email protected]> wrote:
>> Hi Michael
>>
>> On 29-08-2022 14:23, Michael Biebl wrote:
>> > As you are probably aware, this issue is known and tracked in [1].
>>
>> Which I added as a blocker and mentioned in my message, so yes.
>>
>> > The
>> > package FTBFS after enabling the test suite. I raised this issue
>> > upstream but there is no real interest/motivation [2] on their part to
>> > address these (most likely endianess related) issues.
>> > So I informed the s390x porters as well but got not feedback so far.
>>
>> Ack, I saw the latter part.
>>
>> > To me it seems it's better to not continue ship a known broken package
>> > on s390x and think a partial architecture removal is probably the 
>> better
>> > alternative.
>>
>> If you think the package indeed is severely broken, then removal sounds
>> best. If its broken in some less common use cases, it may be OK to leave
>> it for now (skipping those tests on 390x) and let the porters have a
>> look when they have time.
>>
>> > Let me know what you think
>>
>> It all depends on how broken it is. If you would consider the bugs found
>> by the tests RC, then removal is the better choice unless a porter steps
>> up to fix it. If the bugs would be important at most, than skipping
>> broken tests on s390x sounds like the better option. Removal bugs are
>> hard to time predict.
>>
>> Paul
>>
>> PS: I would not disable building on s390x if you have the test suite
>> finding out severe problems (as the d/control file doesn't have negated
>> architecture fields yet). Just getting the binary removed and FTBFS will
>> prevent the architecture from building again.
> 
> Otherwise I think we need to go this route.
> 
> Paul