Re: +1 maintenance report
On Mon, Feb 20, 2023 at 03:51:50PM +0100, Adrien Nader wrote: > Due to the size of the queues, I decided to start with the oldest > issues. Out of interest, how did you identify these "oldest issues"? I happened to spend some time on proposed-migration on Thursday, and all of the packages I worked on are older than the oldest package on your list, AFAICS. (The *youngest* package I worked on was node-object-inspect, which is currently 208 days old.) > # sparse > I'm under the impression that upstream doesn't run their own testsuite > at the moment. > For instance, there is a diagnostic which has been changed in 2019 in > 2094267c7d36d8696897c509558fc63e8a695765 and new testcases have been > added with that diagnostic but older ones have not been updated > accordingly (the one failing because of that change has been created in > 2018 and hasn't been changed since then). > All in all this seemed to much for a +1 shift and I didn't act on the > package. > > # blurhash-python > I tried to reproduce the issue which occured on armhf but I didn't > manage to. There were actually two different issues and that made me > think the issues were unrelated to this package. Due to the size of the > queues, I didn't ask for re-triggers. This package has since migrated. I guess someone did retrigger and it passed. Please don't be shy about retriggering because of the queues; the tests get run eventually... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance report
Hello, I was on +1 from 2023/02/13 to 2023/02/17. Due to the size of the queues, I decided to start with the oldest issues. # sparse I'm under the impression that upstream doesn't run their own testsuite at the moment. For instance, there is a diagnostic which has been changed in 2019 in 2094267c7d36d8696897c509558fc63e8a695765 and new testcases have been added with that diagnostic but older ones have not been updated accordingly (the one failing because of that change has been created in 2018 and hasn't been changed since then). All in all this seemed to much for a +1 shift and I didn't act on the package. # blurhash-python I tried to reproduce the issue which occured on armhf but I didn't manage to. There were actually two different issues and that made me think the issues were unrelated to this package. Due to the size of the queues, I didn't ask for re-triggers. # python3-cssutils FTBFS. Sergio had a look at this a few days ago; I took it further. Development stopped in 2017 and someone else resumed it later on but the package source has not changed since then. Some things changed in the land of python2/3; some have been patched over the years and it seems this could be done again but I'm not sure there are people interested in doing that anymore. There are a number of issues related to this lack of update: - "python3-cssutils: Please package latest version 2.4.0" - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009955 - FTBFS - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026728 Marked for autoremoval on 15 March: #1026728 - "FTBFS during dh_auto_test" - https://bugs.launchpad.net/ubuntu/+source/cssutils/+bug/2006741 I've opened a ticket titled "How compatible to 1.0 is the 2.4 version?" at https://github.com/jaraco/cssutils/issues/31 in order to get a hint about the impact of the possible version jump but didn't get a reply so far. I didn't get to actually drop it last week but that's what should be done (I think I have time to do it but I need to learn that). # crystal It build-depends on itself. It is causing issues in Debian too. I'm not sure what to do exactly; drop it too? # bettercap-caplets This depends on bettercap-ui which is uninstallable since it's not packaged and I haven't seen work towards packaging it (it being an electron app probably doesn't help). I think the caplets don't make much sense without the UI. I'm not sure why it's being kept in Debian and updated there; maybe for some downstream distributions. # ocaml-odoc/ocaml-odoc-parser I believe the issue has been fixed in debian and the packages will migrate to testing in a couple days. # ddnet Added to big_packages. Interestingly, this didn't require being a big package on my computer. I guess the testbed had less available memory for some reason; I tested with various amounts of memory and the tests started failing around 1.5G - 64M of memory. It might be a good idea to test packages with less than 1.5G of memory on our machines, maybe 1.4G; packages that get that close to the limit are likely to go over it rather sooner than later and they are also probably slowed down noticeably due to the low memory situation. # other Got many tests re-triggered. More tests than usual encountered connectivity issues and that was the vast majority of the re-triggers I asked for. -- Adrien -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[ubuntu-studio-devel] Ubuntu Studio daily CD health check
This is a daily health check report on the Ubuntu Studio CD images. If you have any questions, contact Colin Watson . ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116137472 bytes (5116137472) -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
