Wednesday 19 June 2024

Re: Motu Application: Sudip Mukherjee

Hey,

On Fri, May 3, 2024 at 8:38 PM Sudip Mukherjee
<sudipm.mukherjee@gmail.com> wrote:
> I hereby apply to become an Ubuntu Motu.
>
> You can find my application at:
>
> https://wiki.ubuntu.com/sudipmuk/MotuApplication

DMB unanimously voted in favor of Sudip's application. Please join me
in welcoming Sudip as the newest member of the MOTU team.

Sudip, you should have all the ACL in order now, please let me know if
you have any questions or concerns.


- u

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

+1 maintenance handovear - vtk9 9.3 edition

Hi,

I was on +1 last week and besides doing what I described in:

1) A better update_excuses.html
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2024-June/019712.html

2) Analyzing migrations: britney, update_output.txt, chdist, dose-distcheck, apt solver 3
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2024-June/019713.html

I also tried to fix the issues I found in 2) which all relate to the
vtk9 9.3 transition. Some of that spilt into this week and I'm starting
to think that doing +1 over two weeks at 50% might be a better fit
(maybe with two people in parallel, thus making pairing possible).

The list of packages that I identified as requiring a transition was:
- camitk
- gdcm
- insighttoolkit5
- odin
- opencv
- sight
- therion

# Infrastructure state

On Monday (8 days ago), arm64 machines were not starting up and tests
were timing out (sometimes, 100% of them). I reported the issue which
was already known and later during the day, as the situation improved
greatly, I re-triggered between one and two hundred tests.

I think there are again many testbed failures at the moment (also known).

# gdcm

The gdcm package was one of the first in the dependencies tree.

There were several build errors which I solved and Graham sponsored
3.0.24-1ubuntu1:
https://launchpad.net/ubuntu/+source/gdcm/3.0.24-1ubuntu1

The vtk9 puzzle is not completely solved so it's not going to migrate:
https://ubuntu.dcln.fr/update_excuses.html#gdcm

Graham also pointed me to an opened debian bug which I replied to and my
patches have been picked up as part of 3.0.24-2:
https://tracker.debian.org/news/1537907/accepted-gdcm-3024-2-source-into-unstable/

# insighttoolkit5

This one was luckily easy and merely a no-change rebuild:
https://launchpad.net/ubuntu/+source/insighttoolkit5

# camitk

This one is more problematic. I've solved some issues but VTK 9.2
dropped some API which was indirectly re-exposed in camitk's API. This
makes it difficult to come up with a patch without upstream.

I've reported this:
- upstream: https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/193
- launchpad: https://bugs.launchpad.net/ubuntu/+source/camitk/+bug/2069740
- debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073793

Since it has no reverse dependencies, I will probably ask to drop it
from the archive if it becomes the last package to hold the transition
back.

# therion

Affected by an issue with tex font generation:
- https://bugs.launchpad.net/ubuntu/+source/therion/+bug/2069714
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072828

I investigated and authored a patch that, I think, is similar to what
was done for the win32 version of the mktexpk command a few weeks ago in
https://tug.org/svn/texlive?revision=71214&view=revision .

I'm not familiar enough with the codebase, or rather I know that
everything tex is a lot of legacy and a very specific world: I'm
unlikely to do something that will fit that.
Therefore I'll show the thing but let upstreams decide what to do. In
the meantime there is an easy work-around which I'll use for therion:
Build-Depends on texlive-fonts-recommended.

For reference, my patch is at:
https://git.launchpad.net/~adrien/ubuntu/+source/texlive-bin/commit/?id=ccb9edaa83fe517936416ab24476351e3ad7ffff

# odin

Fixed in debian in parallel:
https://launchpad.net/ubuntu/+source/odin/2.0.5-6

# sight

FTBFS in libxml2 headers. Seems related to -fpermissive.
I haven't created a bug report for that yet.
Build log:
https://launchpadlibrarian.net/735717211/buildlog_ubuntu-oracular-amd64.sight_23.1.0-2build6~ppa1_BUILDING.txt.gz

# opencv

Gianfranco Costamagna uploaded a no-change rebuild on yesterday.
https://launchpad.net/ubuntu/+source/opencv/4.6.0+dfsg-13.1ubuntu4

There were testbed failures and I re-triggered the tests (and recently
re-triggered one that Gianfranco had already re-triggered, both times
due to testbed failures). Looking good overall.

# Conclusion

There are three packages left to work on:
- camitk
- therion
- sight and/or libxml2

I'll prepare a therion update with the work-around and will monitor
camitk. That leaves sight/libxml2 which should be an interesting topic
with a good reward hopefully.

If that doesn't unblock vtk9 and opencascade, then maybe these two would
be required (but I think I'm reading the transition tracker wrong):
- https://ubuntu.dcln.fr/update_excuses.html#xilinx-runtime
- https://ubuntu.dcln.fr/update_excuses.html#vowpal-wabbit

--
Adrien

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

Re: dpkg 1.22.6ubuntu11 enables ELF packaging metadata

On Mon, Jun 17, 2024 at 02:24:18PM +0100, Luca Boccassi wrote:
> > IOW, I can't think of any situation where mapping VERSION_CODENAME to
> > osVersion would be a problem, and it's more stable. I would be happy
> > to
> > stand corrected, though!
>
> Please don't - these notes are there to be machine-readable, so the
> format needs to be sensible and common, so unnecessary deviations will
> be detrimental to the effort. This is sourced directly from os-release,
> which as Julian said is set at the beginning.

May I suggest that you change the spec then please? As written, it looks
like distributions are free to choose how to populate these fields,
rather than it being a mandatory mapping from /etc/os-release (given
that we provide that). Or, if it's just that you expect the version to
be orderable, perhaps specify that?

> The optimal thing to me would sound like doing an archive-wide
> (ignoring arch:all only) rebuild once os-release is changed at the
> beginning of the cycle (and again if it were to happen later, too), so
> that the change can be picked up. This also solves the problem of
> packages not being rebuilt. And it seems like a desirable thing as
> you'll be using the latest compiler, with the latest hardening fixes,
> and so on, so it would be a win/win.

This would be up to the Ubuntu Release Team to organise, but it would be
a very significant change in our development workflow and I don't think
it would be practical. Notably, Debian doesn't do this either.

> If this is not possible or desirable for any reason, then please just
> omit the field entirely. Anything parsing it needs to expect this to be
> missing anyway, for the rolling distros use case.

Ack. I was concerned before that omitting it would cause more problems
for ecosystem tooling, but given that you're saying it's fine, that
also sounds fine to me.

It might be worth you also adding this specific recommendation to the
spec for distributions that carry forward builds across releases such as
Debian and Ubuntu.

Robie

Tuesday 18 June 2024

Re: dpkg 1.22.6ubuntu11 enables ELF packaging metadata

On Tue, 2024-06-18 at 10:32 +1200, Michael Hudson-Doyle wrote:
> On Sat, 15 Jun 2024 at 10:46, Benjamin Drung <bdrung@ubuntu.com> wrote:
> > Hi everyone,
> >
>
>
> Hi Benjamin,
>  
> > I just uploaded dpkg 1.22.6ubuntu11 to Ubuntu oracular. This version
> > enables ELF packaging metadata via dpkg-buildflags by default. ELF
> > objects will record the spec https://systemd.io/ELF_PACKAGE_METADATA/
> >
>
>
> So these changes break a few things, because they assume that if the
> environment is affected by dpkg-buildflags, it is also affected by code
> that is only part of running dpkg-buildpackage itself. There are a few
> ways that this can go wrong:
>
> 1) running "./debian/rules binary" or whatever instead of dpkg-buildpackage
> (which afaict is still the interface to package building that's dictated
> by policy)
> 2) code like that in cargo-auto-test that sources dpkg-buildflags output to
> get behaviour close to a package build without actually doing a package
> build.
>
> I don't know what the ideal change for this is. I guess the code in
> add_build_flags could check that the DPKG_BUILDPACKAGE_* variables the spec
> files need are defined before including the spec files in LDFLAGS?

This issue is tracked in [1] now and I am working on a solution (set the
variables in case they are not present in the environment).

[1] https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2069722

--
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

Re: dpkg 1.22.6ubuntu11 enables ELF packaging metadata

On Mon, 17 Jun 2024 at 23:32, Michael Hudson-Doyle
<michael.hudson@canonical.com> wrote:
>
> On Sat, 15 Jun 2024 at 10:46, Benjamin Drung <bdrung@ubuntu.com> wrote:
>>
>> Hi everyone,
>
>
> Hi Benjamin,
>
>>
>> I just uploaded dpkg 1.22.6ubuntu11 to Ubuntu oracular. This version
>> enables ELF packaging metadata via dpkg-buildflags by default. ELF
>> objects will record the spec https://systemd.io/ELF_PACKAGE_METADATA/
>
>
> So these changes break a few things, because they assume that if the environment is affected by dpkg-buildflags, it is also affected by code that is only part of running dpkg-buildpackage itself. There are a few ways that this can go wrong:
>
> 1) running "./debian/rules binary" or whatever instead of dpkg-buildpackage (which afaict is still the interface to package building that's dictated by policy)
> 2) code like that in cargo-auto-test that sources dpkg-buildflags output to get behaviour close to a package build without actually doing a package build.
>
> I don't know what the ideal change for this is. I guess the code in add_build_flags could check that the DPKG_BUILDPACKAGE_* variables the spec files need are defined before including the spec files in LDFLAGS?

That could be possible, but it would hide all issues. So first you
should make a decision: do you want to track and fix all of these, or
do you want to accept shipping an undetermined amount of packages that
are lacking the notes? If the former, then it would probably be better
to add an explicit override. That way it can be searched, so you can
know from sources only, without needing to unpack and inspect binary
packages, how many packages need fixing.

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

Monday 17 June 2024

Re: dpkg 1.22.6ubuntu11 enables ELF packaging metadata

On Sat, 15 Jun 2024 at 10:46, Benjamin Drung <bdrung@ubuntu.com> wrote:
Hi everyone,

Hi Benjamin,
 
I just uploaded dpkg 1.22.6ubuntu11 to Ubuntu oracular. This version
enables ELF packaging metadata via dpkg-buildflags by default. ELF
objects will record the spec https://systemd.io/ELF_PACKAGE_METADATA/

So these changes break a few things, because they assume that if the environment is affected by dpkg-buildflags, it is also affected by code that is only part of running dpkg-buildpackage itself. There are a few ways that this can go wrong:

1) running "./debian/rules binary" or whatever instead of dpkg-buildpackage (which afaict is still the interface to package building that's dictated by policy)
2) code like that in cargo-auto-test that sources dpkg-buildflags output to get behaviour close to a package build without actually doing a package build.

I don't know what the ideal change for this is. I guess the code in add_build_flags could check that the DPKG_BUILDPACKAGE_* variables the spec files need are defined before including the spec files in LDFLAGS?

Cheers,
mwh

+1 maintenance report

Last week I did my +1 maintenance shift. I got sick on Wednesday and
had to take Thursday and Friday off, which impacted the amount of work I
was able to do.

* pytorch
- Athos had already done an initial investigation and left his
findings on
https://bugs.launchpad.net/ubuntu/+source/pytorch/+bug/2067720
- I took over from where he stopped and identified more patches that
needed to be backported (including one that needed to be reverted).
- The package builds on all supported architectures now (amd64, arm64
and ppc64el).
- During my investigation I noticed that a possible solution would be
to bump sleef to the version currently in Debian experimental (3.6).
However, while attempting to build that new version in Oracular some
tests fail during build time on a few architectures. I did not
investigate the issue further, although I confirmed that the build
passed on Debian experimental.

* python-nmea2
- Fixed the FTBFS by backporting an upstream patch.
- Forwarded the fix to Debian.

* python-easydev
- Fixed FTBFS in Debian; it will reach Ubuntu soon.

* python-phpserialize
- Fixed the issue in Debian; it will reach Ubuntu soon.

* xgridfit
- Fixed FTBFS in Debian; will reach Ubuntu soon.

* gitaly
- For some reason it was mistakenly copied into the archive again for
Oracular, so I filed
https://bugs.launchpad.net/ubuntu/+source/gitaly/+bug/2069200
requesting its removal again.

--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14