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 <
Dipak...@ibm.com>
> *Date: *Tuesday, 30 August 2022 at 3:28 PM
> *To: *Paul Gevers <
elb...@debian.org>,
101...@bugs.debian.org
> <
101...@bugs.debian.org>, debian-s390 <
debia...@lists.debian.org>
> *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" <
elb...@debian.org> 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.
>