+1 Maintenance Report
I did +1 maintenance from 2024-06-03 to 2024-06-07. I start the week by running the ubuntu-archive-tools find-proposed-cluster script. There was nothing relevant there at this point of the cycle. Then I started looking at individual packages, no hard rules, but I was trying to focus on the bottom half of the list. Coincidently, the first 2 packages I looked at had infrastructure related failures. I then proceeded to run the archive tools retry script: ./retry-autopkgtest-regressions --log-regex='unexpected eof from the testbed' I sticked to this regex for the 5 days I was working on +1 maintainance and found dozens of (non-duplicated) occurrences each day. On Thursday and Friday, mirespace was shadowing me during my +1 shifts as our timezone differences allowed (I suppose she will reply to this thread with her findings later). Below are comments on individual packages I worked on throghout the week (not including test retries). ## qiime and q2-* packages qiime was blocking several q2-* packages. They all had the same python 3.12 compatibility issue. I add a short patch to each of them and forwarded them all to Debian as well. Below are the packages cleared (or in their migration process) from the migration list. If any of those are still in the excuses page, they are most likely waiting to be accepted from the new queue or waiting on a dependency which is pending in new. quiime, q2-phylogeny, q2-types, q2-feature-table, q2-dada2, q2cli, q2-taxa, q2-quality-filter, q2-metadata, q2-fragment-insertion, q2-feature-classifier, q2-diversity-lib, q2-demux, q2-cutadapt, q2-alignment, q2-quality-control, q2-emperor, and q2-sample-classifier ## ruby-toml and ruby-parslet This is related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070989 Here, we applied an upstream fix to ruby-toml and re-triggered ruby-parslet tests. Both packages migrated. ## wannier90 This also had python 3.12 compatibility issues. We uploaded a fix and forwarded it to Debian. ## python-awkward We sent a fix to the debian maintainers so it would no longer use internet connections during the package build. The package is still needing some fixes, so I did not upload it to Ubuntu (it would most likely migrate, I am unsure if we want it to migrate as is). ## edflib Upstream does not support big endian architectures. I applied a patch available in Debian's salsa to avoid building to s390x and asked the ubuntu-archive team to remove it from s390x. This was done and the package migrated. ## node-yarnpkg This was an interesting one. The package initially FTBFS due to issues with "-Bsymbolic-functions". However, removing the flag from the build got us into a different FTBFS issue also affecting Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067283). This happens because the off_t type is being configured to be 72-bit long by cmake. After some investigation and a pair debugging session with sergiodj (thanks, Sergio), we found out that the build of an embedded library injects a hook into cmake to call "node" (JS) with the "--experimental-wasm-threads" option. This option has been removed from node 20 and node now exits with code 9 on errors. This error code ends up being picked up by the embeded library cmake checks which ends up being set as the size of off_t (9 bytes). I reported this to Debian and filed LP: #2068769 ## pytorch pytorch FTBFS with llvm-18. This was already reported last week. there are several other packages blocked on this. I found some more upstream patches related to the issue but we are still getting (different) build failures there. See LP: #2067720. These are the packages directly blocked by pytorch: tabnet, pytorch-geometric, baler, open3d, pytorch-ignite, pytorch-cuda, pytorch-sparse, pytorch-cluster, pytorch-scatter, pytorch-text, pytorch-vision, and skorch ## python-lsp-ruff missing python3-ruff (provided by ruff), which was added to the sync/blocklist due to missing rust-clearscreen. This is now in the archive and we should sync ruff back in. I tried sync'ing it with $ syncpackage -r oracular-proposed -d unstable -v --force ruff and $ copy-package -b -s noble --to-suite oracular-proposed -y -e 0.0.291+dfsg1-3 ruff Both commands reported successful status, but it seems I have no permissions to copy packages in that exclusion list (?). -- Athos Ribeiro -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?
On Tue, Oct 17, 2023 at 05:44:12PM -0700, Steve Langasek wrote: I'd therefore like to propose we close this mailing list and forward the address on to ubuntu-devel-disc...@lists.ubuntu.com, which at least has a larger subscriber base and is more likely to result in users getting help with their questions. Opinions? +1 I´d go further and propose the same for the IRC channel - retire it and redirect people to #ubuntu-devel. Maybe that should be another discussion including the #ubuntu+1-maint (the discussions seem to happen in #ubuntu-release) and #ubuntu-next (-> #ubuntu-devel) channels too. -- Athos Ribeiro -- 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 (Week of 2023-08-21)
I was on +1 maintenance on the week of 2023-08-21. I started the week using the Ubuntu archive tooling to re-triggering a few tests and running the find-proposed-cluster script to find good candidates to work on. The majority of the reported clusters were blocked on the glibc transition then. Therefore, I decided to focus some effort on helping unblocking those. In special, I worked on debugging and trying to advance LP: #2031912 along with other folks (thanks to everyone involved in fixing this one, in special, sergiodj for all the debugging and patches). Other than glibc, there weren't many large clusters to work on. I the focused on retriggering some tests. rust-trust-dns-proto: This was blocking a few rust packages due to a DEP8 failure. Some of the tests perform DNS queries which are not allowed in the autopkgtest infra. I added a delta to the package to mark those tests as flaky (they pass in Debian) and unblock those rust packages. -- Athos Ribeiro -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Duplicate Requests in autopkgtest-cloud
On Fri, Jul 28, 2023 at 10:01:50AM +0100, Tim Andersson wrote: Hi Steve, This is something I missed in the initial implementation, but there's now an MP for a fix ready to go into master. Right now, however, I've hotfixed prod so that if you pass `all-proposed`, the duplicate request check is disabled. I made this quick change to unblock ginggs Hi Tim, is the hotfix still up? I just got a request with all-proposed blocked because a request without it was queued. On Fri, Jul 28, 2023 at 5:19 AM Steve Langasek wrote: Hi Tim, On Thu, Jul 27, 2023 at 11:10:05AM +0100, Tim Andersson wrote: > Hi all, > In the Ubuntu QA team we recently made and deployed a change which now > makes it impossible to queue duplicate requests. > If a request is currently in the queue, or is currently running, and you > request the same test, you will be taken to an error page which tells you > the test details and whether it is currently queued or currently running. > It looks like this: > ``` > > You submitted an invalid request: > > Test already queued: > > release: lunar > > pkg: gzip > > arch: arm64 > > triggers: gzip/1.12-1ubuntu1 > > ``` > This is to try and ease the load on autopkgtest-cloud. > If you experience any bugs or unexpected functionality, please file a bug > against `autopkgtest-cloud` and let us know. We expect it to work > seamlessly but always expect the unexpected right :) Does the code also properly distinguish between tests queued with proposed=1 and those without, so that it's possible to queue both ways in parallel? Thanks, -- Athos Ribeiro -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Sat, Jan 21, 2023 at 08:30:33PM +0100, Gunnar Hjalmarsson wrote: On 2023-01-20 21:47, Steve Langasek wrote: On Thu, Jan 19, 2023 at 01:44:12PM +0100, Gunnar Hjalmarsson wrote: On 2021-01-21 11:20, Robie Basak wrote: https://wiki.ubuntu.com/Testing/EnableProposed will need a rework though. We link to that from every SRU bug. That page was last updated on 2020-06-19, and is obsolete. Would be great i someone could follow up the change and edit the Testing/EnableProposed page so it makes sense again. Have you run into problems with the instructions on that page? I skimmed it and aside from mentioning "Selective upgrading from -proposed" which is redundant for newer releases, I don't immediately see anything incorrect there. If you can point out where it's wrong, I'll happily edit it to correct it but I don't have time just now to run through the full instructions there to find out what doesn't work. Maybe the change of behavior here is the confusing bit? Previously, following the first part of the guide (before the "selective upgrading" docs) would be enough to install the desired package(s) from proposed without specifying the pocket in the apt command. First I have to admit that I thought the change had been implemented already in jammy. I see now that that's not the case, at least not yet. As regards the contents of the wiki page, you are right and I stand corrected — there is not much of directly incorrect information. I think it's mostly about my personal taste: I have long thought that the page is overly complicated. I made use of Ask Ubuntu to illustrate what a less wordy page might look like: https://askubuntu.com/questions/1451256 That Ask Ubuntu answer is not exactly targeted people like the ones who have participated in this list thread. I have rather the not so tech savvy user in mind, like a bug reporter who wants to help verify a proposed SRU fix. I simply fear that the current wiki page contains so much information, so a prospective tester may be discouraged to follow through. Perhaps, in the first section, after "It is recommended to enable selective upgrading from -proposed as described in the next section!" we could metion the NotAutomatic setting and point out that just creating the file under /etc/apt/sources.list.d/, as shown in the guide, will no loger make the user's system to prefer newer packages from proposed, as it would happen in the past. Instead, they should follow the next section (selective upgrading from -proposed). If they desire the former behavior they could change the preferences file priority as well. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Athos Ribeiro -- 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
Hi, I performed my first +1 maintainance shift last week as part of the server team rotation. Before starting the shift, I used the new find-proposed-cluster script available in the ubuntu-archive-tools repository to find where our wokr would be most helpful. The script will print the 5 largest clusters that needs work. I decided to work through them on a bottom-up approach (the first one was python3-defaults). This way, I would avoid duplicating work with any other teams working on the python transition. Later, vorlon mentioned in the #ubuntu-relese channel that it would be better if we all focused on unblocking the python transition due to the size of that cluster. I then started focusing on those packages. python3-defaults transition === I re-triggered several tests with arch related failures. In special, there were lots of those which failed in s390x that were related to the autopkgtest infrastructure itself (the tests did not start properly). Lots of these re-triggers were successful, but then I realized I was duplicating some of vorlon's re-triggers and vice-versa. This includes, but is not limited to unattended-upgrades, ruby-stackprof, python-qtconsole, python-parametrized, python-mechanicalsoup, pyliblo, mutagen, fatrace, conda-package-handling, cachelib, cluster4, python-aiortc, fiat, q2-diversity-lib, and, python-bioblend. Other python related (successful) retriggers, not directly related to python3-defaults include: python-django-postgres-extra, python-weblogo, python-limits, supysonic, python-cheroot, python-ruffus, python-fluids, dbus-fast, mutter, and, python-anyqt. When I realized the amount of duplication being generated, I switched focus to specific failures that would need further changes: inspect.getargspec has been removed in python3.11. Some packages need to be adapted to support python 3.11. A possible alternative is to use getfullargspec instead. foolscap Added a delta to replace getargspec calls with getfullargspec calls. The patch was forwarded upstream but forwarding it to Debian would also be nice. booth - This package is blocked due to the getargpec issue mentioned above being present in crmsh. While I pinged Lucas (current person assigned to this merge) regarding this one, Simon went ahead and filed an MP with the merge (thanks Simon). python-glyphsets I added a delta here to require an implicit dependency which was leading to FTBFS and forwarded a fix to the upstream project. Forwarding it to Debian would also be nice. fastapi --- The test suite here hasn't been passing for a while now. I ran the migration reference for this one (which failed). It would be nice to verify and fix this suite at some point. -- Athos Ribeiro -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
sbcl ppc64le bootstrap
Hello, We (sergiodj and I) will bootstrap the sbcl lisp compiler for ppc64le for kinetic. This message is intended to be a heads-up for any interested party and a reference for the archive admins for whenever we need new binaries accepted as a consequence of this bootstrapping process. Below we provide more context for the matter and describe how the bootstrap process will be performed. While working on pgloader, we realized that the package does not build for ppc64le. Further investigation showed that there are no sbcl binaries for some architectures, such as s390x and ppc64le. Since sbcl build depends on itself, bootstrapping is needed to make those binaries available. While there is evidence of recent work on the s390x bootstrapping in Debian (please refer to the package changelog), the ppc64le package has been available in Debian for a while now, but was never bootstrapped in Ubuntu. We will now bootstrap sbcl for ppc64le by performing a first sbcl build with clisp. Once it is accepted in the archive, we will revert the ppc64le-with-clisp changes and rebuild sbcl using the clisp-built version of sbcl. After the bootstrapping process is completed, there should be no delta left in the sbcl package and the next Debian upload should be a potential sync. With that in mind, we will use the approach proposed back in May [1] and set the version string with a "maysyncX" suffix. Hence, we will - Change the source package to build with clisp for ppc64le and upload sbcl "2:2.2.3-2maysync1"; and - once the new ppc64le binary is accepted, revert the previous change and upload sbcl "2:2.2.3-2maysync2" Then, the next Debian upload will be a sync. If a Debian upload happens in between "2:2.2.3-2maysync1" and "2:2.2.3-2maysync2", it will just mean "2:2.2.3-2maysync2" is no longer necessary. As a matter of fact, we will only upload a "2:2.2.3-2maysync2" version to ensure the new ppc64le binary is also built using sbcl, as the already available binaries for the other platforms. Once "2:2.2.3-2maysync2" is available, we will proceed to perform no-chage-rebuilds for the platform dependent sbcl reverse build dependencies. These are, in a first level: buildapp cafeobj And in a second level (both depend on buildapp): pgloader pgcharts (multiverse) The bootstrap process will be tracked in LP: #1968579. The current change proposal for the bootstrapping process is available at https://salsa.debian.org/athos/sbcl/-/commits/ubuntu-bootstrap [1] https://www.mail-archive.com/ubuntu-devel@lists.ubuntu.com/msg10417.html -- Athos Ribeiro -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Fri, Nov 12, 2021 at 05:03:10PM -0300, Lucas Kanashiro wrote:
Hi all,
This is the summary of my +1 maintenance shift:
# consul
The package in Debian is FTBFS [1], this was reported by me in Ubuntu as
well [2]. I added a commit to salsa backporting an upstream patch which
fixes the FTBFS, but autopkgtest was still failing. Those tests have been
failing in Debian for many years [3], so I believe this was not a blocker.
However, Reinhard submitted a salsa MR to at least make autopkgtest happy,
so I reviewed and merged it [4]. Version 1.8.7+dfsg1-3 was uploaded to
Debian with the fixes.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997133
[2] https://bugs.launchpad.net/ubuntu/+source/consul/+bug/1940152
[3] https://ci.debian.net/packages/c/consul/unstable/amd64/
[4] https://salsa.debian.org/go-team/packages/consul/-/merge_requests/3
# golang-github-vbauerster-mpb
Re-trigger tests with the correct version of golang-github-containers-image
in all architectures. This also unblocked
golang-github-containers-{images,storage}.
# ruby-jekyll-remote-theme
The package was a FTBFS because it was running some tests trying to access
the Internet, it was building fine in Debian but due to the network policy
we use in our builders it was caught by us. Uploaded version 0.4.3-2 to
Debian skipping those tests.
# ruby-tty-prompt
Re-trigger autopkgtest with the needed dependencies from proposed.
Unblocked ruby-pastel, ruby-tty-command, ruby-tty-prompt, ruby-tty-reader.
# ruby-tty-screen
Re-trigger autopkgtest with the needed dependencies from proposed to
unblock itself.
# ruby-acsiidoctor-pdf
Re-trigger autopkgtest with correct version of ruby-prawn-icon and
ruby-prawn-svg to unblock both of them.
# Ruby packages FTBFSes due to 3.0 transition
There are a bunch of ruby packages FTBFS but most of them are because we
need to start rebuilding packages against ruby3.0, the current version of
ruby-defaults we have in -proposed already force the build against both,
ruby2.7 and ruby3.0. I'll be working on the transition in Ubuntu next week,
things will start to look better. In Debian, it is mostly done from the
release team perspective (97% done at the moment) [1], but there are still
some FTBFS needing some work [2], eventually we will need to get those
packages fixed as well or remove them when it is possible.
[1] https://release.debian.org/transitions/html/ruby3.0-add.html
[2]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ruby3.0;users=debian-r...@lists.debian.org
# Python packages FTBFSes due to 3.10 transition (Athos)
Athos got a fix accepted in Debian and once it got sync'ed he needed to
retry the build of a bunch of packages [1]. I helped him with that. I think
he will reply to this email detailing his work.
[1] https://bugs.launchpad.net/ubuntu/+source/unittest2/+bug/1949778
As mentioned by Lucas, I forwarded a few fixes to Debian related to
Python 3.10 support. They are all detailed in the following bugs:
https://bugs.launchpad.net/ubuntu/+source/unittest2/+bug/1949778
unittest2 was FTBFS, once fixed, it unblocked builds for several
packages, which were also FTBFS, these packages are listed in the bug
linked above.
https://bugs.launchpad.net/ubuntu/+source/python-werkzeug/+bug/1950335
python-werkzeug was FTBFS, a fix has been released to Debian, but the
new package has not migrated yet due to regressions in flask.
https://bugs.launchpad.net/ubuntu/+source/python-pyscss/+bug/1950391
python-pyscss was FTBFS. A fix has been forwarded to Debian and the
package was sync'd and migrated. This also unblocked a build for
python-django-pyscss, which also migrated.
https://bugs.launchpad.net/ubuntu/+source/testresources/+bug/1950521
testresources is failing to build from sources. A fix was submitted to
Debian in
https://salsa.debian.org/openstack-team/python/testresources/-/merge_requests/3
and forwarded upstream. Once accepted, this should unblock builds for 3
other packages, listed in the bug.
https://bugs.launchpad.net/ubuntu/+source/python-agate/+bug/1950646
python-agate was FTBFS. A fix was fowarded to Debian and the package has
migrated. It also unblocked python-agate-dbf and python-agate-sql. A fix
was also forwarded to Debian on python-leather to unblock builds for
these packages.
Have a great weekend!
Lucas Kanashiro.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
Athos Ribeiro
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
