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

Dipak,

I fail to see the connection between exempi and atop.
Have you copied the wrong bug report number?

Michael

Am 07.09.22 um 19:00 schrieb Dipak Zope1:
> Hi Paul,
> 
> Setting the environment variable ATOPACCT to empty value disables this 
> issue.
> 
> Please use this workaround in the caller script of atop till we get a 
> final fix.
> 
> export ATOPACCT=""
> 
> The behaviour is described in the source as below:
> 
>                  /*
> 
>                  ** when a particular environment variable is present, 
> atop should
> 
>                  ** use a specific accounting-file (as defined by the 
> environment
> 
>                  ** variable) or should use no process accounting at all 
> (when
> 
>                  ** contents of environment variable is empty)
> 
>                  */
> 
> -Dipak
> 
> *From: *Dipak Zope1 <[email protected]>
> *Date: *Tuesday, 30 August 2022 at 3:28 PM
> *To: *Paul Gevers <[email protected]>, [email protected] 
> <[email protected]>, debian-s390 <[email protected]>
> *Subject: *[EXTERNAL] RE: src:exempi: fails to migrate to testing for 
> too long: FTBFS on s390x
> 
> 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 am looking forward to have a fix 
> for this for s390x. ‍ ‍ ‍ ‍ ‍
> 
> ZjQcmQRYFpfptBannerStart
> 
> *This Message Is From an External Sender *
> 
> This message came from outside your organization.
> 
> ZjQcmQRYFpfptBannerEnd
> 
> 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 am looking forward to have a fix for this for s390x.
> 
> -Dipak
> 
> 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.
>