Hi Nilesh, On 2024-04-16 17:03, Nilesh Patra wrote:
On Tue, Apr 16, 2024 at 04:52:01PM +0300, Andrius Merkys wrote:On 2024-04-16 15:04, Nilesh Patra wrote:OTOH, does anyone actually use s390x for any med team package? If not, can we consider to add this too along with other 32-bit archs to our policy?Personally, I do not like the idea of deny-listing architectures in team policy. But I am not an uploader of emboss, I merely care for it as a dependency for oscar4.Sure, but if there is no user for those packages at all on s390x, would that not translate to: a) extra maintenance
True.
b) more build cycles / load on porter machines / more cost so on?
I think this is a reasonable price to keep an architecture among release architectures.
I would suggest the following course of action for emboss: 1. Add a build-time test calling emboss executable(s). This way builds will fail on s390x (and possibly other architectures) until #1069098 is fixed. 2. RM emboss for s390x without excluding s390x from build architectures. This way emboss will be able to migrate and there will be no action needed if/when #1069098 is fixed.Makes sense to me.
I have added the build-time test and filed the needed RM bugs + removed python-biopython test-dependency on emboss on s390x.
Best, Andrius