I was on my fourth +1 maintenance shift this week. Thanks to Adrien (@adrien)for the large-scale retrying of autopkgtests in the past week. The update_excuse page this week hardly showed any false failures. I worked on a set of random universe packages, most of them FTBFS. I also addressed the merges listed against my name on merge-o-matic.
I spent considerable time debugging an interesting maven build failure affecting two packages. I haven’t gotten to the bottom of it yet, but learnt a good amount of maven in the process!
This is the list of failures I investigated or fixed:
audioread - I began investigating replacements for some audio packages depracated from the Python standard library, but soon realized this would be better done by upstream maintainers. Here is the [bug report] (https://bugs.launchpad.net/ubuntu/+source/audioread/+bug/2089520) and also a Debian bug.
puppet-agent - I like deleting code! Removed a patch that is no longer needed here. Here is the bug reportand here is the merge proposal. Thanks @giings for sponsoring.
criu - criu has been resurrected after a while, though fixing the FTBFS was possible by ignoring a couple of warnings, the autopkgtests are the elephant in the room here. This is the bug report and this is merge proposal for the FTBFS.
tycho - this failure is also observed in Debian sid. Created this bug report, this LP merge proposal as well as this MR against the debian package.
yubihsm-shell - a new FTBFS due to _FORTIFY_LEVEL redefinition. Here is the bug repoprt and here is the merge proposal
Which is not really a priority for +1 maintenance…
Why do you say this? The goal of +1 maintenance is to resolve outstanding issues that prevent a package from migrating. Do you have reason to think upstream will resolve this soon? Or do you intend for us to remove the package instead of fixing it?
In the context of Python audio processing packages, I have a question I have struggled to find an acceptable answer to. Many of the blocked packages have upstream projects that may not be as active as we expect them to be - this is not to say that they are inactive. And looking at problems like the need to bring in a new dependency, may need significant domain understanding. Though such issues cannot be turned down as “non-packaging issues” they can hog time that could be spent in packages that are clearly blocked on packaging issues. Is requesting for removals OK without an understanding of the adoption? I personally find it difficult to take that investigate vs. don-investigate vs. ask for removal decision.
It there is github or similar, such packages could have badge reporting of their success in upstream ubuntu and similar, but there is also package reporting in a huge list of distributions(although not so popular) which can tell which distributions have problem with some package or lack of maintainers…
Yes, if it’s a leaf package in universe or multiverse, requesting removal is definitely ok. If upstream fixes it, we should pick up the fix via Debian sync (a bug report is also filed in Debian about this, correct? Ubuntu did start the Python 3.13 transition before Debian did but by this point bugs should at least be filed even if not yet raised to serious severity).
And if upstream does not fix it or the fix does not make it into Debian, then the package probably wasn’t important enough to our users to do a lot of extra work to get it building.