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
*Date: *Tuesday, 30 August 2022 at 3:28 PM
*To: *Paul Gevers , 1018...@bugs.debian.org
<1018...@bugs.debian.org>, debian-s390
*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" 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.
OpenPGP_signature
Description: OpenPGP digital signature
