Friday, 4 July 2025

+1 Maintenance report from 2025-06-30 to 2025-07-04 (2025 week 27)

Hi,

this is a cross-post from:
https://discourse.ubuntu.com/t/1-maintenance-report-week-27-2025/63944
You can read it there or here. The report is written in Markdown. I just
added some newlines to make it a bit easier to read in plain text.

# +1 Maintenance report from 2025-06-30 to 2025-07-04 (2025 week 27)

This week was another +1 shift for me. @ginggs provided me with some
topics to work on and that took all my time. Most of the topics I worked
on were rabbit holes. The report is short and that makes me feel
unproductive (the imposter syndrome kicks in).

## Work-needed items

None unless you want to investigate why [wp2latex 4.15~ds-1 fails to
build on
armhf](https://bugs.launchpad.net/ubuntu/+source/wp2latex/+bug/2115809).

## Lessons learned

The positive takeaway from this week: Several of the issues that I
reported upstream got fixed within hours. So I highly recommend to
document the failures and forward them upstream.

Autopkgtest can have artifacts. Look at those when the log output does
not give a clue! See my text about the crun package for details.

## Full logs

* **python-psutil**: Fixed FTBFS on s390x and [forwarded this fix
upstream](https://github.com/giampaolo/psutil/pull/2595). Then noticed
it started to fail on ppc64el, because lscpu (from **util-linux**) is
broken on ppc64el. I opened [LP:
#2115636](https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2115636
) and forwarded it to upstream. This got fixed by upstream and I
backported the fix.

* **pyopengl**: I opened [LP
:#2115791](https://bugs.launchpad.net/ubuntu/+source/pyopengl/+bug/2115791
) for it and decided to skip the failing test in case of the permission
error. I [forwarded the patch to
upstream](https://github.com/mcfletch/pyopengl/pull/153). Then took my
Debian Python team hat to release that patch in 3.1.9+dfsg-2 in Debian
(and let this new version autosync).

* **tools-build-clojure**: I opened [LP: #2115740]
(https://bugs.launchpad.net/ubuntu/+source/tools-build-clojure/+bug/2115740)
for it and [forwarded it upstream]
(https://ask.clojure.org/index.php/14602/tools-build-fails-with-httpproxy-httpsproxy-set),
because the test did not use the configured proxy (ignored the
`http_proxy` environment variable). Upstream pointed to Maven and told
me to configure Maven in a `settings.xml` config. I tried different
alternatives (setting some Maven environment variables), but none of the
alternatives worked. So I wrote some shell code for the test to convert
`http_proxy` to `$home/.m2/settings.xml`. In addition the autopkgtest
failed in my schroot environment, because the home directory does not
exist there. So I configured a temporary directory as home directory for
the test. I forwarded both changes [to Debian]
(https://salsa.debian.org/clojure-team/tools-build-clojure/-/merge_requests/1).

* **crun**: I opened [LP
#2115813](https://bugs.launchpad.net/ubuntu/+source/crun/+bug/2115813)
for it. One of the tests failed without logs. I tried to reproduce it
locally and failed. Then I looked at the test and saw one `return 1`
without logs. I added a print command and tried again in a PPA. It
failed again without logs. Then I saw that the test stores the log
output of the tests in an autopkgtest artifact. That artifact revealed
the culprit: Calling `crun --version` failed. I [reported that
upstream](https://github.com/containers/crun/issues/1816) and it got
fixed. So I uploaded the fix to Ubuntu.

* **wp2latex**: I reported that [4.15~ds-1 fails to build on
armhf](https://bugs.launchpad.net/ubuntu/+source/wp2latex/+bug/2115809).
I tried to run the build on my Raspberry Pi Zero 2, but it failed. The
board rebooted itself (reproducible). I haven't looked into the details
why (maybe it's a power supply issue, maybe I should ask @waveform how
to troubleshoot that). I forwarded this wp2latex bug to the upstream
maintainer via email.

--
Benjamin Drung
Debian & Ubuntu Developer

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Tuesday, 1 July 2025

Re: +1 Maintenance report from 23 June 2025 to 29 June 2025

Hi Pragyansh,

On Tue, Jul 1, 2025 at 12:50 PM Pragyansh Chaturvedi
<pragyansh.chaturvedi@canonical.com> wrote:
> ### Sponsorship needed
>
> I'll list all the bugs here, the details are given in the next section.
> - [freecad](https://bugs.launchpad.net/ubuntu/+source/freecad/+bug/2115604)
> - [rust-zune-jpeg](https://bugs.launchpad.net/ubuntu/+source/rust-zune-jpeg/+bug/2115606)
> - [armci-mpi](https://bugs.launchpad.net/ubuntu/+source/armci-mpi/+bug/2115608)
> - [ukui-session-manager](https://bugs.launchpad.net/ubuntu/+source/ukui-session-manager/+bug/2115609)
> - [clanlib](https://bugs.launchpad.net/ubuntu/+source/clanlib/+bug/2115623)
> - [ggml](https://bugs.launchpad.net/ubuntu/+source/ggml/+bug/2115706)
> - [cron](https://bugs.launchpad.net/ubuntu/+source/cron/+bug/2115312)

I've reviewed all of them, sponsored 3 and asked for extra information
(or extra work like forwarding to Debian, et al) for the rest. Thanks
for the work you put in, they were pretty good already. :)


- u

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Opt-in notifications about upcoming special case SRUs

On Tue, Jul 1, 2025 at 2:02 PM Andreas Hasenack
<andreas.hasenack@canonical.com> wrote:
>
> Hi,
>
> On Wed, Jun 25, 2025 at 8:28 AM Christian Ehrhardt
> <christian.ehrhardt@canonical.com> wrote:
> >
> > Hello everyone o/
> >
> > I wanted to update all of you about an effort that tries to further
> > minimize regressions due to the SRU process [1].
> > A few weeks ago, at the sprint in Frankfurt we realized - to no
> > surprise - that there is a bigger chance of regressions when complex
> > updates land.
> > In a discussion about what broke teams over the recent years it became
> > clear that all mentioned examples have been from the list of special
> > cases [2].
>
> Does somebody know if these regressions have all been tagged with
> regression-update (see
> https://documentation.ubuntu.com/sru/en/latest/howto/regression/)? All
> SRU team members are subscribed to that tag.

No, I do not know that.
I've had people tell me what component broke them and we
spotted the repeating pattern.
But I did not get a list of related SRU bugs.

--
Christian Ehrhardt
Director of Engineering, Ubuntu Server
Canonical Ltd

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Opt-in notifications about upcoming special case SRUs

Hi,

On Wed, Jun 25, 2025 at 8:28 AM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
>
> Hello everyone o/
>
> I wanted to update all of you about an effort that tries to further
> minimize regressions due to the SRU process [1].
> A few weeks ago, at the sprint in Frankfurt we realized - to no
> surprise - that there is a bigger chance of regressions when complex
> updates land.
> In a discussion about what broke teams over the recent years it became
> clear that all mentioned examples have been from the list of special
> cases [2].

Does somebody know if these regressions have all been tagged with
regression-update (see
https://documentation.ubuntu.com/sru/en/latest/howto/regression/)? All
SRU team members are subscribed to that tag.

--
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 from 23 June 2025 to 29 June 2025

Hi,

This is a cross-post from:
https://discourse.ubuntu.com/t/1-maintenance-report-week-26-2025/63731
You can also pass the contents of this mail to a markdown viewer for a
better view.

# +1 Maintenance report from 23 June to 29 June

Hi, I was on +1 Maintenance last week. @schopin also shared the new
[+1 Maintenance
Doc](https://canonical-ubuntu-project.readthedocs-hosted.com/contributors/advanced/plus-one-maintenance/)
which was a great help.
I mostly focussed on the
[update-excuses](https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html)
page.

## Work-needed items
- [llama.cpp](https://launchpadlibrarian.net/801854472/llama.cpp_5760+dfsg-1_5760+dfsg-2.diff.gz)
- They (the Debian uploader) have hardcoded the required version for
dependencies, but those versions haven't been uploaded to Debian yet.
Need to contact the uploader to find out what is going on.
- [ggml](https://bugs.launchpad.net/ubuntu/+source/ggml/+bug/2115706)
- Need to forward the proposed fix to Debian (or further upstream,
depending on what the Debian uploader says)

### Sponsorship needed

I'll list all the bugs here, the details are given in the next section.
- [freecad](https://bugs.launchpad.net/ubuntu/+source/freecad/+bug/2115604)
- [rust-zune-jpeg](https://bugs.launchpad.net/ubuntu/+source/rust-zune-jpeg/+bug/2115606)
- [armci-mpi](https://bugs.launchpad.net/ubuntu/+source/armci-mpi/+bug/2115608)
- [ukui-session-manager](https://bugs.launchpad.net/ubuntu/+source/ukui-session-manager/+bug/2115609)
- [clanlib](https://bugs.launchpad.net/ubuntu/+source/clanlib/+bug/2115623)
- [ggml](https://bugs.launchpad.net/ubuntu/+source/ggml/+bug/2115706)
- [cron](https://bugs.launchpad.net/ubuntu/+source/cron/+bug/2115312)

## Full logs

- [libpisp](https://bugs.launchpad.net/ubuntu/+source/libpisp/+bug/2115319)
and [rpicam-apps](https://bugs.launchpad.net/ubuntu/+source/libpisp/+bug/2115319):
upstream broke the API which caused rpicam-apps to FTBFS when built
with `-Wl, --no-undefined`. Thanks @waveform for merging. This change
has also been applied upstream. Now it needs a no-change-rebuild for
libcamera and rpicam-apps should then build successfully, and no
longer show up on the [NBS
tracker](https://ubuntu-archive-team.ubuntu.com/nbs.html)
- [cron](https://bugs.launchpad.net/ubuntu/+source/cron/+bug/2115312):
cron autopkgtests were failing at the start of the week due to logs
spilled in stderr by cloud-init (not a failure of the package but
additional logs from the testbed). This was blocking the migration of
exim4 as well. @utkarsh suggested that we use `allow-stderr` option
for the failing tests.
- [freecad](https://bugs.launchpad.net/ubuntu/+source/freecad/+bug/2115604):
FreeCAD added an autopkgtest which failed as it requires a display
server, but this was not included in the test dependencies. This small
fix allows it to pass.
- [rust-zune-jpeg](https://bugs.launchpad.net/ubuntu/+source/rust-zune-jpeg/+bug/2115606):
autopktests for arm64 were failing due to the introduction of
`color_convert/neon64.rs`, which uses ARM64's Neon SIMD instructions,
but had an incorrect modpath.
- [armci-mpi](https://bugs.launchpad.net/ubuntu/+source/armci-mpi/+bug/2115608):
Prepared a merge for version 0.4-6
- [ukui-session-manager](https://bugs.launchpad.net/ubuntu/+source/ukui-session-manager/+bug/2115609):
Prepared a merge for version 4.0.0.2-1
- [rakarrack](https://bugs.launchpad.net/ubuntu/+source/rakarrack/+bug/2115620):
No remaining delta against Debian anymore, so I put up a sync bug.
Thanks @eeickmeyer for acting on this.
- [clanlib](https://bugs.launchpad.net/ubuntu/+source/clanlib/+bug/2115623):
No remaining delta against Debian anymore, so I put up a sync bug.
- [ggml](https://bugs.launchpad.net/ubuntu/+source/ggml/+bug/2115706):
This turned out to be a pain (and the reason why this report is late).
The ARM support for ggml is very inconsistent and seems to be centered
around Apple Silicon. There is no distinction between arm64 and armhf,
but the source uses features only available in arm64 and tries to
compile them on armhf as well. The fix specifies the FPU while
building libggml-cpu on armhf, skips compiling parts which rely on
Apple's proprietary libraries and fixes some parts where the CMake is
choosing the wrong architecture:
in tests/CMakeLists.txt
```
#
# test-vec2 (arm)
if (${CMAKE_SYSTEM_PROCESSOR} MATCHES "arm")
set(TEST_TARGET test-vec2)
add_executable(${TEST_TARGET} ${TEST_TARGET}.c)
target_link_libraries(${TEST_TARGET} PRIVATE ggml)
endif()
```
- `CMAKE_SYSTEM_PROCESSOR` is `aarch64` on Ubuntu arm64 and `armv7l`
on Ubuntu armhf. This test needs `armv8.2-a+fp16` (hence arm64) to
compile according to it's contents. However, this might work fine on
Apple Silicon Macs, as `uname -m` gives `arm64`, but on Ubuntu this
target was matching `armv7l` (hence armhf) instead of arm64

- [llama.cpp](https://launchpad.net/ubuntu/+source/llama.cpp/5760+dfsg-2):
This is weird - not installable now as it depends on a version of ggml
that is not uploaded yet. I must contact the uploader of llama.cpp and
ggml (both are the same) as to why this is so (and to forward the ggml
patches as well). Checking llama.cpp upstream, I see that they publish
a new release every few hours or so, so I doubt if users will be
installing these from the archive instead of building it from source
themselves, but this still a weird case that should be resolved.

Best regards
Pragyansh

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Monday, 30 June 2025

Ubuntu 24.10 (Oracular Oriole) reaches End of Life on 10th July 2025

Ubuntu announced its 24.10 (Oracular Oriole) release almost 9 months
ago, on 10th October 2024 and its support period is now nearing its
end. Ubuntu 24.10 will reach end of life on 10th July 2025.

At that time, Ubuntu Security Notices will no longer include
information or updated packages for Ubuntu 24.10.

The supported upgrade path from Ubuntu 24.10 is to Ubuntu 25.04
Instructions and caveats for the upgrade may be found at:

https://help.ubuntu.com/community/PluckyUpgrades

Ubuntu 25.04 continues to be actively supported with security updates
and select high-impact bug fixes. Announcements of security updates
for Ubuntu releases are sent to the ubuntu-security-announce mailing
list, information about which may be found at:

https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce

Since its launch in October 2004, Ubuntu has become one of the most
highly regarded Linux distributions with millions of users in homes,
schools, businesses and governments around the world. Ubuntu is Open
Source software, costs nothing to download, and users are free to
customise or alter their software in order to meet their needs.


On behalf of the Ubuntu Release Team,
Utkarsh Gupta

--
ubuntu-announce mailing list
ubuntu-announce@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce

Friday, 27 June 2025

Re: Opt-in notifications about upcoming special case SRUs

On Wed, Jun 25, 2025 at 01:27:33PM +0200, Christian Ehrhardt wrote:
>Hello everyone o/

Hi Christian,

>I wanted to update all of you about an effort that tries to further
>minimize regressions due to the SRU process [1].
>A few weeks ago, at the sprint in Frankfurt we realized - to no
>surprise - that there is a bigger chance of regressions when complex
>updates land.
>In a discussion about what broke teams over the recent years it became
>clear that all mentioned examples have been from the list of special
>cases [2].

Were there any discussions on whether this was due to these having
special processes for their SRUs or due to the frequency these updates
are rolled out?

I understand that in some cases (such as Docker) we explicitly state
that backwards compatibility may not be met for some updates, therefore,
we should indeed do a better job communicating those updates/changes.

>Many teams have worked on improving this over the years, some
>established regular CI, others have tests they can run
>semi-automatically.
>But it turned out what was mostly missing, was getting a heads up when
>new changes are about to land and thereby implying it is a good time
>to test.
>
>We have been discussing what could be a low overhead process to achieve that.
>After all not everybody is interested in everything - nor was anyone
>keen to hard commit to returning a verification result in a timely
>fashion.
>
>What we came up with, and now starting to experiment with and discuss,
>is essentially a simple subscription model.
>Yes, you could just subscribe to the source package, but many stated
>that they had a hard time filtering such traffic well, losing the
>signal in the noise.
>
>Based on the meeting we had I've collected the teams and what packages
>they are interested in.
>But that is only a starting seed for this - anyone else is welcome to
>join as well (the used launchpad groups are open).
>Out of that I have created open interest groups on launchpad:
>
>- https://launchpad.net/~sru-verification-interest-group-landscape
>- https://launchpad.net/~sru-verification-interest-group-snapd
>- https://launchpad.net/~sru-verification-interest-group-containerstacks
>- https://launchpad.net/~sru-verification-interest-group-openstack
>- https://launchpad.net/~sru-verification-interest-group-cloud-init
>- https://launchpad.net/~sru-verification-interest-group-postgresql
>- https://launchpad.net/~sru-verification-interest-group-grub
>- https://launchpad.net/~sru-verification-interest-group-ubuntu-pro-client
>
>Yes there are more special cases [2], but those represent what people
>have been interested in so far.
>Once we agree others can be defined and added following the same pattern.
>
>Those groups are gonna be subscribed to related SRU bugs and therefore
>would only get traffic when an SRU is about to happen.
>On the respective SRU exceptions documents I'm about to add a
>paragraph about it, which is up for review [3].
>
>Thanks for reading!
>I'd be happy to get your input either as reply to this mail or as
>comment on the merge request [3].

+1. Thanks for putting this up!


>[1]: https://documentation.ubuntu.com/sru/en/latest/
>[2]: https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#reference-package-specific-notes
>[3]: https://code.launchpad.net/~paelzer/sru-docs/+git/sru-docs/+merge/487759
>
>P.S. I have added the usual drivers of the packages that are affected
>to CC to make it more likely they are aware of this.
>
>--
>Christian Ehrhardt
>Director of Engineering, Ubuntu Server
>Canonical Ltd

--
Athos Ribeiro

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel