Hi Paul, I will continue looking into this bug and will see if I can come up with something. Thank you all for your support.
Thanks, Pranav ________________________________________ From: Paul Gevers Sent: Thursday, April 24, 2025 11:41 AM To: 1103...@bugs.debian.org; Pranav P Cc: 1103...@bugs.debian.org Subject: [EXTERNAL] Re: Bug#1103423: src:kitty: fails to migrate to testing for too long: FTBFS on s390x Hi, Looping in Pranav, On 24-04-2025 00:18, Chris Hofstaedtler wrote: > * Nilesh Patra <nil...@debian.org> [250423 20:54]: >> Upstream has explicitly denied to provide any support for s390x see[1]. >> And I don't think I have the interest, time and energy to support a >> port this for big endian arch myself. That's OK. Pranav is already looking (in bug 1103595) and they are one of the 390x porters. >> Given that soft freeze has now started, is it a sensible time to ask >> for removal >> of this package from s390x I think that's quite acceptable given the reply from upstream. Removing it now doesn't block Pranav from coming up with a fix in the near future and that would restore it for s390x in trixie. It would mean a bit of busywork for ftp-master, but alas. Pranav, do you consider kitty interesting enough on s390x to fix the issue (the burden will be on you (s390x porters) as upstream not the maintainer show interest). Nilesh, do you expect upstream to take patches despite the reply? I take it as similar to your reply: not interested to do the work, but if patches are available that look maintainable, then they are OK. >> and specify only rest of the release >> architectures in d/control? > > You don't need to restrict the archs in d/control, as long as kitty > continues to ftbfs on s390x. Fully agree. See also [1]. >> Or do you think I should just go ahead w disabling tests for this arch >> for now? > > Not Paul or RT, but I think it makes sense to keep the tests failing. I > believe very few people will run GUI programs on s390x, so not having > kitty there seems safe. I would hope that those tests are there for a reason and if they fail that's a concern. Obviously there exist also a lot of tests where it's the test that's wrong. Balancing this takes time and effort, but if you don't want to spend the time on it, let Pranav have his shot. Paul [1] https://salsa.debian.org/debian/developers-reference/-/merge_requests/60/diffs
