Hello, This week I partly shadowed Christian on his +1 maintenance.
Whilst I don't have the core-dev powers yet, Christian & Gianfranco sponsored uploads & did re-triggers on my request. So a huge thanks to them! As Christian mentioned, transitions were actively being driven and things were already being looked at, so I decided to work on things which didn't get enough attention, hoping that my Ruby experience could help. :) Here's what I did: ### schleuder ### This has been lurking around since so long. The armhf failure isn't reproducible and passes locally everytime, even with different armhf setups. Passes in Debian, too. Since this has become so hard to debug & blocks other packages, added a hint[1] & has now migrated. [1]: https://code.launchpad.net/~utkarsh/britney/+git/britney/+merge/404025 ### ruby-httpclient ### ruby-httpclient had some HTTP_PROXY issues (which were LP builders specific) and some test_proxy_ssl which resulted in FTBFS randomly (cf: debbug #861456). We hit some in the past and decided to disable on the Debian side and not forward them because these work fine locally & only hangs in specific environments, more so in LP's builders. Anyhow, uploaded the fixed package, ruby-httpclient/2.8.3-3, to Debian which built fine on all architectures & the package migrated. ### ruby-gitlab-pg-query ### This package didn't build on any architecture (ever) because of FTBFS as it accesses the internet during the build (cf: debbug #981878). This was initially packaged because src:gitlab needed it but now gitlab has switched to using the original source, ruby-pg-query, and stopped relying on its fork, therefore, this isn't needed by any package anymore. Opened LP: #1931257, requesting its removal; thanks to Iain Lane for processing that. ### python-django-debug-toolbar ### Did a loop-rebuild on amd64 to ensure that it wasn't actually a legit failure. Asked Christian to re-trigger python-django-debug-toolbar/1:3.2.1-1 for amd64 and it passed & migrated. ### ruby-loofah ### The package is blocked by the regression induced in ruby-rails-html-santizier because of some API changes in ruby-loofah. The tests weren't adjusted and were recently patched upstream. Cherry-picking those patches makes it happy and so got it uploaded to Debian to avoid "delta"; thanks Hideki for doing that. Simultaneously, uploaded newer ruby-loofah, too, to Debian and both of them are happy. ruby-rails-html-sanitizer already migrated and ruby-loofah should soon do, too. Asked Gianfranco to re-trigger the tests (w/ triggers) on all architectures and it passed, as expected. ### ruby-stackprof | ruby-ferret | ruby-hiredis ### glibc had these three blockers^. The first two needed a re-trigger on amd64 & the last one needed a re-trigger on armhf. I did a loop-rebuild to ensure there are no legit failures, turns out there weren't. So I requested Gianfranco to do it for me & all of them passed & migrated. ### ruby-excon ### Long-due failure on s390x. Not reproducible; passes locally & also in a s390x canonistack VM. So opened an issue upstream, explaining the same, and added a hint[2]. Hopefully it will migrate soon. [2]: https://code.launchpad.net/~utkarsh/britney/+git/britney/+merge/404113 - u -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
