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 + Dipak Zope1 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" 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 OpenPGP_signature Description: OpenPGP digital signature
Re: RE: src:exempi: fails to migrate to testing for too long: FTBFS on s390x
Hi Dipak, On Tue, 30 Aug 2022 09:57:44 + Dipak Zope1 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" 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 OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1018224: src:exempi: fails to migrate to testing for too long: FTBFS on s390x
Hi, On 07-09-2022 21:57, Michael Biebl wrote: I fail to see the connection between exempi and atop. Have you copied the wrong bug report number? Seems like this should have gone to 1016937 indeed (doing so now). Paul 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. OpenPGP_signature Description: OpenPGP digital signature
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 *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
RE: src:exempi: fails to migrate to testing for too long: FTBFS on s390x
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.
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. -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.
Re: src:exempi: fails to migrate to testing for too long: FTBFS on s390x
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
Re: src:exempi: fails to migrate to testing for too long: FTBFS on s390x
Hi Paul Am 27.08.22 um 13:49 schrieb Paul Gevers: Source: exempi Version: 2.6.1-2 Severity: serious Control: close -1 2.6.2-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1014061 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:exempi has been trying to migrate for 62 days [2]. Hence, I am filing this bug. Your package failed to build from source on s390x while it built the successfully in the past. Reported in bug 1014061. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=exempi As you are probably aware, this issue is known and tracked in [1]. 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. 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. Let me know what you think Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014061 [2] https://gitlab.freedesktop.org/libopenraw/exempi/-/issues/23#note_1448295 OpenPGP_signature Description: OpenPGP digital signature
