+1 maintenance: June 24 - June 28

[Andreas Hasenack]

I focused on the NBS report, where I saw that a new poppler needed
some reverse dependencies rebuilt. And they were not rebuilding.

This is C++, and it takes a while to build, specially if the failing
arch is armhf, which was the case of two packages.

The common root issue was that poppler switched to std=c++20[1]
because they started using std::string::starts_with, and that is only
defined in C++20. So all reverse dependencies that needed a rebuild
also had to switch, and this was the basic fix I applied.

# dia FTBFS
https://bugs.launchpad.net/ubuntu/+source/dia/+bug/2070284
fixed

# gdcm FTBFS
https://bugs.launchpad.net/ubuntu/+source/gdcm/+bug/2070303
fixed

# inkscape FTBFS
https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/2070367
Partial fix, but it fails to build elsewhere after that. Latest
upstream version is 1.3.2, and ours (and debian's) is 1.2.2, maybe
it's best to update it and see what happens. Debian experimental has
1.3.

# calligra FTBFS
https://bugs.launchpad.net/ubuntu/+source/calligra/+bug/2070399
fixed

# openboard FTBFS
https://bugs.launchpad.net/ubuntu/+source/openboard/+bug/2070403
fixed

# rdma-core FTBFS on armhf
https://bugs.launchpad.net/ubuntu/+source/rdma-core/+bug/2070280
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073050
I troubleshooted and Benjamin Drung fixed it in a debian upload which
was then synced.

# gambas3 FTBFS on armhf
https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/2012420
After many attempts by different people, Gianfranco fixed it in
https://launchpad.net/ubuntu/+source/gambas3/3.19.1-1ubuntu3


On Thursday, I did my usual SRU shift instead of +1 maintenance. I
went over all releasable packages in noble-proposed, and released,
accepted, or dealt with, the following:

https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2070070
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2069828
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2068739
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2063203
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2064280
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2062929
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2064175
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2061121
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2066905
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2007419
https://bugs.launchpad.net/ubuntu/+source/gnome-builder/+bug/2068065
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2067886
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2067585
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2067071
https://bugs.launchpad.net/ubuntu/+source/libfprint/+bug/2067785
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/2067592
https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/2067387
https://bugs.launchpad.net/ubuntu/+source/klayout/+bug/2066026
https://bugs.launchpad.net/ubuntu/+source/dracut/+bug/2065180
https://bugs.launchpad.net/ubuntu/+source/extruct/+bug/2064861
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2064843
https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-18/+bug/2064187
https://bugs.launchpad.net/ubuntu/+source/rtl8812au/+bug/2063820
https://bugs.launchpad.net/ubuntu/+source/xxdiff/+bug/2061637
https://bugs.launchpad.net/horizon/+bug/1728031
https://bugs.launchpad.net/horizon/+bug/2055409
https://bugs.launchpad.net/horizon/+bug/2054799
https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/2037015
https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/2062146
https://bugs.launchpad.net/ubuntu/+source/fwbuilder/+bug/1957168





1. 
https://gitlab.freedesktop.org/poppler/poppler/-/commit/d8ae3ba#9a2aa4db38d3115ed60da621e012c0efc0172aae

-- 
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 starting on 2024-02-19

[Andreas Hasenack]

My goal was to go through the python3-defaults transition and help to
get it done. There was a lot of back and forth between attempt at
fixes, triggers, re-runs,e tc. Here is just a summary. This is a
report, not a diary :)

# distutils deprecation
I started going through the remaining python packages that broke due
to the distutils removal, and there were only two: geopy and
python-sparkpost. Both needed patches that I sent upstream, and
migrated.

# jupyter-notebook, jupyter-client
I sent an email about this one on monday[1]. It was failing to
build[2] due to an incompatible update to jupyter-client. I tried
several patches from upstream for that, but even upstream kind of gave
up and pinned jupyter-client to a lower version, because
jupyter-notebook just wouldn't work with the changes in jupyter-client
>= 8. We ended up doing the same and reverting that jupyter-client
update back to 7.4.9-2[3], and adding a patch on top to fix a dep8
error it was experiencing in that version.

# libapache2-mod-python
Amongst the python 3.12 removals was "imp", an import module.
libapache2-mod-python was crashing[4] with an import error, and had to
be changed[5] to use importutils. Dominik Viererbe worked on a branch
for this, and we colaborated with upstream in a PR[6] that was
eventually merged. In ubuntu, an early version of the patch was used,
so that still needs to be addressed[7]. Or maybe not, it might come
via debian[8] (I haven't followed those updates)

# liquidsoap
While waiting to see the results of the python3 migration efforts in
excuses, I checked another knot in migrations and arrived at
liquidsoap, creating trouble in the ocaml world.

2.2.3 is an FTBFS[9], which 2.2.4 fixes[10]. I tried an update to
2.2.4, but it has a new ftbfs of its own[11] when built with gstreamer
support, which debian does, and upstream discourages[12].
The patch to move away from Pcre does not apply cleanly on 2.2.3, and
my ocaml-foo is nonexistent.
It looks like the debian maintainer is on top of it, trying with
upstream to get it fixed. I subscribed to the bugs to be notified of
any updates, but if this is fixed in debian in the next few days, we
will get it via a sync.

# gnudatalanguage
Just needed a rebuild[13] due to eccodes having been removed from
proposed to facilitate the python3 migration, and gnudatalanguage had
already been built with that version.



And today, Friday, at about 5pm, python 3.12 migrated \o/



1. https://lists.ubuntu.com/archives/ubuntu-devel/2024-February/042918.html
2. https://bugs.launchpad.net/ubuntu/+source/jupyter-notebook/+bug/2054342
3. https://launchpad.net/ubuntu/+source/jupyter-client/7.4.9-2ubuntu1
4. https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-python/+bug/2054133
5. https://github.com/grisha/mod_python/issues/130
6. https://github.com/grisha/mod_python/pull/131
7. 
https://code.launchpad.net/~dviererbe/ubuntu/+source/libapache2-mod-python/+git/libapache2-mod-python/+merge/460705
8. 
https://salsa.debian.org/python-team/packages/libapache2-mod-python/-/merge_requests/1
9. https://bugs.launchpad.net/ubuntu/+source/liquidsoap/+bug/2054815
10. https://github.com/savonet/liquidsoap/issues/3750
11. https://github.com/savonet/liquidsoap/issues/3752
12. 
https://github.com/savonet/liquidsoap/discussions/3751#discussioncomment-8524446
13. https://launchpad.net/ubuntu/+source/gnudatalanguage/1.0.4-1build2

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

Re: early +1 maintenance: jupyter-notebook FTBFS, jupyter-client update ahead of debian

[Andreas Hasenack]

Hi,

On Mon, Feb 19, 2024 at 5:30 PM Andreas Hasenack  wrote:
>
> Hi,
>
> On Mon, Feb 19, 2024 at 5:11 PM Steve Langasek
>  wrote:
> >
> > Hi Andreas,
> >
> > On Mon, Feb 19, 2024 at 05:05:00PM -0300, Andreas Hasenack wrote:
> > > I started working on my +1 maintenance shift with the goal of
> > > trailblazing the python 3.12 migration. A few packages sorted already,
> > > but jupyter-notebook has me stumped, and I thought I would share this
> > > now instead of at the end of the shift.
> >
> > > src:jupyter-notebook[1] is FTBFS[2] due to a test failure in
> > > noble-proposed with src:jupyter-client[3] >= 8. I filed a bug[2] with
> > > my findings.
> >
> > > Upstream and other projects I could find all seem to have settled on
> > > pinning jupyter-client to a version < 8. And indeed, if we build
> > > jupyter-notebook with jupyter-client from noble
> > > release (version 7.4.9-2, same as in debian), then it succeeds.
> >
> > > I don't know why jupyter-client was updated to 8.6.0[4] ahead of
> > > debian. So far, I have exhausted my troubleshooting on this issue. I
> > > suppose we could remove src:jupyter-client 8.6.0-0ubuntu1 from
> > > noble-proposed, as that could help with the python3 migration.
> >
> > Given the uploader and the timing, I suspect this was done to get
> > jupyter-client itself to be sorted for the python3.12 transition.
> >
> > Can you verify that the previous version of the package in Ubuntu builds in
> > noble?
>
> Both locally and in a ppa with noble-proposed enabled[1],
> jupyter-client 7.4.9-2 built, but build-time tests are disabled in
> this package.
>
> > See also https://bugs.debian.org/1059658
>
> I'll try a dep8 run, see what happens with today's archive.

These tests fail with the same error as reported in the bug, with python 3.12:

Testing with python3.12:
/usr/lib/python3/dist-packages/_pytest/config/__init__.py:331:
PluggyTeardownRaisedWarning: A plugin raised an exception during an
old-style hookwrapper teardown.
Plugin: helpconfig, Hook: pytest_cmdline_parse
ConftestImportFailure: DeprecationWarning:
datetime.datetime.utcfromtimestamp() is deprecated and scheduled for
removal in a future version. Use timezone-aware objects to represent
datetimes in UTC: datetime.datetime.fromtimestamp(timestamp,
datetime.UTC). (from
/tmp/autopkgtest.BaOJPJ/build.m7g/real-tree/jupyter_client/tests/conftest.py)
For more information see
https://pluggy.readthedocs.io/en/stable/api_reference.html#pluggy.PluggyTeardownRaisedWarning
  config = pluginmanager.hook.pytest_cmdline_parse(
ImportError while loading conftest
'/tmp/autopkgtest.BaOJPJ/build.m7g/real-tree/jupyter_client/tests/conftest.py'.
jupyter_client/__init__.py:8: in 
from .asynchronous import AsyncKernelClient  # noqa
jupyter_client/asynchronous/__init__.py:1: in 
from .client import AsyncKernelClient  # noqa
jupyter_client/asynchronous/client.py:6: in 
from jupyter_client.channels import HBChannel
jupyter_client/channels.py:15: in 
from .session import Session
jupyter_client/session.py:54: in 
from jupyter_client.jsonutil import extract_dates
jupyter_client/jsonutil.py:15: in 
from dateutil.parser import parse as _dateutil_parse  # type: ignore
/usr/lib/python3/dist-packages/dateutil/parser/__init__.py:2: in 
from ._parser import parse, parser, parserinfo, ParserError
/usr/lib/python3/dist-packages/dateutil/parser/_parser.py:50: in 
from .. import tz
/usr/lib/python3/dist-packages/dateutil/tz/__init__.py:2: in 
from .tz import *
/usr/lib/python3/dist-packages/dateutil/tz/tz.py:37: in 
EPOCH = datetime.datetime.utcfromtimestamp(0)
E   DeprecationWarning: datetime.datetime.utcfromtimestamp() is
deprecated and scheduled for removal in a future version. Use
timezone-aware objects to represent datetimes in UTC:
datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
autopkgtest [17:49:30]: test command1: ---]

Maybe that's easier to fix than the jupyter-notebook failure?

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

Re: early +1 maintenance: jupyter-notebook FTBFS, jupyter-client update ahead of debian

[Andreas Hasenack]

Hi,

On Mon, Feb 19, 2024 at 5:11 PM Steve Langasek
 wrote:
>
> Hi Andreas,
>
> On Mon, Feb 19, 2024 at 05:05:00PM -0300, Andreas Hasenack wrote:
> > I started working on my +1 maintenance shift with the goal of
> > trailblazing the python 3.12 migration. A few packages sorted already,
> > but jupyter-notebook has me stumped, and I thought I would share this
> > now instead of at the end of the shift.
>
> > src:jupyter-notebook[1] is FTBFS[2] due to a test failure in
> > noble-proposed with src:jupyter-client[3] >= 8. I filed a bug[2] with
> > my findings.
>
> > Upstream and other projects I could find all seem to have settled on
> > pinning jupyter-client to a version < 8. And indeed, if we build
> > jupyter-notebook with jupyter-client from noble
> > release (version 7.4.9-2, same as in debian), then it succeeds.
>
> > I don't know why jupyter-client was updated to 8.6.0[4] ahead of
> > debian. So far, I have exhausted my troubleshooting on this issue. I
> > suppose we could remove src:jupyter-client 8.6.0-0ubuntu1 from
> > noble-proposed, as that could help with the python3 migration.
>
> Given the uploader and the timing, I suspect this was done to get
> jupyter-client itself to be sorted for the python3.12 transition.
>
> Can you verify that the previous version of the package in Ubuntu builds in
> noble?

Both locally and in a ppa with noble-proposed enabled[1],
jupyter-client 7.4.9-2 built, but build-time tests are disabled in
this package.

> See also https://bugs.debian.org/1059658

I'll try a dep8 run, see what happens with today's archive.


1. https://launchpad.net/~ahasenack/+archive/ubuntu/plusoneweek/+packages

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

early +1 maintenance: jupyter-notebook FTBFS, jupyter-client update ahead of debian

[Andreas Hasenack]

Hi,

I started working on my +1 maintenance shift with the goal of
trailblazing the python 3.12 migration. A few packages sorted already,
but jupyter-notebook has me stumped, and I thought I would share this
now instead of at the end of the shift.

src:jupyter-notebook[1] is FTBFS[2] due to a test failure in
noble-proposed with src:jupyter-client[3] >= 8. I filed a bug[2] with
my findings.

Upstream and other projects I could find all seem to have settled on
pinning jupyter-client to a version < 8. And indeed, if we build
jupyter-notebook with jupyter-client from noble
release (version 7.4.9-2, same as in debian), then it succeeds.

I don't know why jupyter-client was updated to 8.6.0[4] ahead of
debian. So far, I have exhausted my troubleshooting on this issue. I
suppose we could remove src:jupyter-client 8.6.0-0ubuntu1 from
noble-proposed, as that could help with the python3 migration.


1. https://launchpad.net/ubuntu/+source/jupyter-notebook
2. https://bugs.launchpad.net/ubuntu/+source/jupyter-notebook/+bug/2054342
3. https://launchpad.net/ubuntu/+source/jupyter-client
4. https://launchpad.net/ubuntu/+source/jupyter-client/8.6.0-0ubuntu1

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

[Andreas Hasenack]

Hi,

On Wed, Feb 7, 2024 at 10:42 AM Andreas Hasenack  wrote:
>
> Hi,
>
> On Tue, Feb 6, 2024 at 9:47 PM Pushkar Kulkarni
>  wrote:
> >
> > === freedombox/bootstrapform ===
> > The freedombox package depends on bootstrapform. Autopkgtests of the
> > former fail because the latter imports distutils. I did a Debian MR
> > [15] to replace distutils.StrictVersion with packaging.Version. But I
> > now see bootstrapform also failing, independent of this merge request,
> > with Python 3.12. Test pipelines on the MR are failing and this needs
> > more investigation.
> >
> > [15] 
> > https://salsa.debian.org/freedombox-team/python-django-bootstrap-form/-/merge_requests/4
> >
>
> I worked a little bit on this one the other day, because it was
> blocking my samba upload.
>
> I filed this bug initially:
> https://bugs.launchpad.net/ubuntu/+source/python-django-bootstrap-form/+bug/2050093
>
> Fixing the distutils import. But then, as did you, I saw the django
> failure with python 3.12:

I ended up uploading the distutils fix anyway. I didn't see the django
backtrace locally anymore, just in a ppa, and I'm unsure what's going
on. Since the distusils fix will be needed anyway, I uploaded.

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

Re: git-ubuntu import service temporarily halted

[Andreas Hasenack]

This is now sorted and the service is running again.

On Wed, Feb 7, 2024 at 10:34 AM Andreas Hasenack  wrote:
>
> Hi,
>
> the git-ubuntu import service has been impacted by the recent outage,
> and is currently not running. The service controller VM in prodstack
> is in an "ERROR" state, and we need admin help to further troubleshoot
> it. A ticket[1] has been filed to try to address this.
>
>
> 1. https://portal.admin.canonical.com/C162000/

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

Re: git-ubuntu import service temporarily halted

[Andreas Hasenack]

This is now sorted and the service is running again.

On Wed, Feb 7, 2024 at 10:34 AM Andreas Hasenack  wrote:
>
> Hi,
>
> the git-ubuntu import service has been impacted by the recent outage,
> and is currently not running. The service controller VM in prodstack
> is in an "ERROR" state, and we need admin help to further troubleshoot
> it. A ticket[1] has been filed to try to address this.
>
>
> 1. https://portal.admin.canonical.com/C162000/

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

[Andreas Hasenack]

Hi,

On Tue, Feb 6, 2024 at 9:47 PM Pushkar Kulkarni
 wrote:
>
> === freedombox/bootstrapform ===
> The freedombox package depends on bootstrapform. Autopkgtests of the
> former fail because the latter imports distutils. I did a Debian MR
> [15] to replace distutils.StrictVersion with packaging.Version. But I
> now see bootstrapform also failing, independent of this merge request,
> with Python 3.12. Test pipelines on the MR are failing and this needs
> more investigation.
>
> [15] 
> https://salsa.debian.org/freedombox-team/python-django-bootstrap-form/-/merge_requests/4
>

I worked a little bit on this one the other day, because it was
blocking my samba upload.

I filed this bug initially:
https://bugs.launchpad.net/ubuntu/+source/python-django-bootstrap-form/+bug/2050093

Fixing the distutils import. But then, as did you, I saw the django
failure with python 3.12:

344s autopkgtest [06:02:28]: test command1: [---
344s /tmp/autopkgtest.LCD785/build.iLk/src/runtests.py:61:
RemovedInDjango50Warning: The extra_tests argument is deprecated.
344s   failures = test_runner.run_tests(['bootstrapform'], test_args)
344s Found 1 test(s).
344s Traceback (most recent call last):
344s   File "/tmp/autopkgtest.LCD785/build.iLk/src/runtests.py", line
66, in 
344s runtests(*sys.argv[1:])
344s   File "/tmp/autopkgtest.LCD785/build.iLk/src/runtests.py", line
61, in runtests
344s failures = test_runner.run_tests(['bootstrapform'], test_args)
344s^^^
344s   File "/usr/lib/python3/dist-packages/django/test/runner.py",
line 1060, in run_tests
344s self.run_checks(databases)
344s   File "/usr/lib/python3/dist-packages/django/test/runner.py",
line 977, in run_checks
344s call_command("check", verbosity=self.verbosity, databases=databases)
344s   File "/usr/lib/python3/dist-packages/django/core/management/__init__.py",
line 110, in call_command
344s app_name = get_commands()[command_name]
344s^^
344s   File "/usr/lib/python3/dist-packages/django/core/management/__init__.py",
line 76, in get_commands
344s for app_config in reversed(apps.get_app_configs()):
344s^^
344s   File "/usr/lib/python3/dist-packages/django/apps/registry.py",
line 147, in get_app_configs
344s self.check_apps_ready()
344s   File "/usr/lib/python3/dist-packages/django/apps/registry.py",
line 138, in check_apps_ready
344s raise AppRegistryNotReady("Apps aren't loaded yet.")
344s django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.


I found the debian bug about the distutils import which you filed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062980


Where I also sent my patch to, and also commented on the above django error.


Does someone with some django knowledge know what is going on above?
Unfortunately upstream
(https://github.com/tzangms/django-bootstrap-form) seems abandoned :(

This is the only package with this error:
$ ./retry-autopkgtest-regressions --log-regex "Apps aren't loaded yet"
https://autopkgtest.ubuntu.com/request.cgi?release=noble=amd64=python-django-bootstrap-form=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=arm64=python-django-bootstrap-form=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=armhf=python-django-bootstrap-form=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=ppc64el=python-django-bootstrap-form=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=s390x=python-django-bootstrap-form=python3-defaults%2F3.12.1-0ubuntu1

An on that topic, the distutils import problem affects these:
$ ./retry-autopkgtest-regressions --log-regex "No module named 'distutils'"
https://autopkgtest.ubuntu.com/request.cgi?release=noble=armhf=dolfinx-mpc=petsc4py%2F3.19.6-3ubuntu1=petsc%2F3.19.6%2Bdfsg1-2ubuntu1=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=amd64=onionshare=pyside2%2F5.15.12-4=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=arm64=onionshare=pyside2%2F5.15.12-4=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=armhf=onionshare=pyside2%2F5.15.12-4=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=ppc64el=onionshare=pyside2%2F5.15.12-4=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=s390x=onionshare=pyside2%2F5.15.12-4=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=amd64=faiss=faiss%2F1.7.4-3build1=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble=arm64=faiss=faiss%2F1.7.4-3build1=python3-defaults%2F3.12.1-0ubuntu1

git-ubuntu import service temporarily halted

[Andreas Hasenack]

Hi,

the git-ubuntu import service has been impacted by the recent outage,
and is currently not running. The service controller VM in prodstack
is in an "ERROR" state, and we need admin help to further troubleshoot
it. A ticket[1] has been filed to try to address this.


1. https://portal.admin.canonical.com/C162000/

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

git-ubuntu import service temporarily halted

[Andreas Hasenack]

Hi,

the git-ubuntu import service has been impacted by the recent outage,
and is currently not running. The service controller VM in prodstack
is in an "ERROR" state, and we need admin help to further troubleshoot
it. A ticket[1] has been filed to try to address this.


1. https://portal.admin.canonical.com/C162000/

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

Re: Is there a good solution for this: release-upgrade with dependency moved to universe

[Andreas Hasenack]

Hi,

On Tue, Jan 16, 2024 at 3:02 AM Steve Langasek 
wrote:

> On Fri, Jan 12, 2024 at 11:05:24AM -0500, Nick Rosbrook wrote:
> > Hi,
>
> > > I guess something in do-release-upgrade could be run to, when
> encountering such a situation, automatically select
> bin:samba-vfs-modules-extra for the upgrade as well? Is it worth it? Is
> there a precedence for something like this? And how would this be done in a
> more generic/general case, if at all?
>
> > We have the concept of "quirks"[1] in ubuntu-release-upgrader which
> > allows us to handle special cases like this. For example, a cycle or
> > two ago when flatpak was removed from flavor seeds, we added some code
> > to not auto-remove flatpak if it appeared the user was actively using
> > it. So yes, if nothing else we could add a quirk to make sure
> > samba-vfs-modules-extra is installed upgrades if samba-vfs-modules is
> > currently installed.
>
> I want to weigh in here to say that I think we should NOT do this by
> default.
>
> In my view, every difference between "Install Ubuntu release X; upgrade to
> Ubuntu release X+1" and "Install Ubuntu release X+1" is a bug.
>
> These bugs vary in severity, and we'll probably never zero out the list of
> such bugs.  But we should not knowingly *introduce* such bugs through
> quirking.
>

Something I could to to gather data is to do an actual deployment using
glusterfs (of samba and qemu), upgrade, lose the gluster modules, and see
what happens.

If do-release-upgrade fails outright (because some postinst failed due to
the missing gluster module), then I guess it's a high prio bug and we
should proceed with the do-release-upgrade quirks.

If the upgrade finishes, the system reboots, and then services don't come
back up due to the missing glusterfs modules, and that can be fixed by just
an "apt install ", then it's less severe and can be release-noted. But
the quirk would also solve this situation, and I thought it wouldn't be
such a bad approach.


> This should also apply to "Install Ubuntu release X; apt install Y; upgrade
> to Ubuntu release X+1", when not modifying any configuration files along
> the
> way (though the severity of such a bug should also understandably be
> lower).
>
> If it's possible to detect that the system in question is *using*
> glusterfs,
> and add a quirk at runtime to install samba-vfs-modules-extra, then I think
> this sort of change is ok.  Otherwise, I think the right answer here is:
>

I admit that I was thinking about just checking if `samba-vfs-modules` is
installed in noble-1, and then mark samba-vfs-modules-extra for
installation.

I can do *some* detection of glusterfs usage via testparm[1] on the main
config file, but it will miss some cases:
- included dynamic files, like "include = /etc/samba/%U.conf" (which file
that will be is not known before an actual connection to the share)
- registry-based configurations (due to my lack of experience in that, I
suppose `sudo net conf list` would list it all)

And registry-based[2] happens to be the preferred way to configure a
clustered samba server (with glusterfs as the backend).

This is of course way more complex than the first approach.

1. https://manpages.ubuntu.com/manpages/mantic/en/man1/testparm.1.html
2.
https://wiki.samba.org/index.php/Configuring_clustered_Samba#Using_the_Samba_registry
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Is there a good solution for this: release-upgrade with dependency moved to universe

[Andreas Hasenack]

Hi Nick,

On Fri, Jan 12, 2024 at 1:05 PM Nick Rosbrook 
wrote:

> Hi,
>
> > I guess something in do-release-upgrade could be run to, when
> encountering such a situation, automatically select
> bin:samba-vfs-modules-extra for the upgrade as well? Is it worth it? Is
> there a precedence for something like this? And how would this be done in a
> more generic/general case, if at all?
>
> We have the concept of "quirks"[1] in ubuntu-release-upgrader which
> allows us to handle special cases like this. For example, a cycle or
> two ago when flatpak was removed from flavor seeds, we added some code
> to not auto-remove flatpak if it appeared the user was actively using
> it. So yes, if nothing else we could add a quirk to make sure
> samba-vfs-modules-extra is installed upgrades if samba-vfs-modules is
> currently installed.
>
>
That sounds exactly what I need, thank a log for the pointer!

Is there an easy way to use "do-release-upgrade -d" to test my changes
before proposing them, or will it always download the tarball at
http://archive.ubuntu.com/ubuntu/dists/noble/main/dist-upgrader-all/current/noble.tar.gz
and use that?





> Thanks,
> Nick
>
> [1]
> https://git.launchpad.net/ubuntu-release-upgrader/tree/DistUpgrade/DistUpgradeQuirks.py
>
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Is there a good solution for this: release-upgrade with dependency moved to universe

[Andreas Hasenack]

I have package bin:samba-vfs-modules which ships, among other things, a
glusterfs module:

  /usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs.so
  /usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs_fuse.so

We intend[1] to demote glusterfs to Universe, and since
bin:samba-vfs-modules is in main, one solution is to create another
package, let's say, called bin:samba-vfs-modules-extra, with said glusterfs
module, and ship that in universe.

That's case #7 of the package transition guide[2].

Due to this move, any upgrade from the old bin:samba-vfs-modules to the new
bin:samba-vfs-modules will *lose* the glusterfs module. I cannot make one
depend on the other because bin:samba-vfs-modules-extra is in universe, and
as we all know, we can't have a package in main depend on one in universe.

Such a file move between packages will not happen in an SRU, but in the
devel release. Which means users who were relying on an installation that
used the samba vfs gluster module, and do-release-upgrade to noble, their
samba server will likely break until bin:samba-vfs-modules-extra is
installed. Of course this can and will be noted in the release notes, but
even then, there is nothing the user could do before-hand to not encounter
this problem, other than prepare, and know how to fix it after the upgrade
is finished. Not a super nice experience.

I guess something in do-release-upgrade could be run to, when encountering
such a situation, automatically select bin:samba-vfs-modules-extra for the
upgrade as well? Is it worth it? Is there a precedence for something like
this? And how would this be done in a more generic/general case, if at all?

Another option would be to move bin:samba-vfs-modules to universe, and deal
with those consequences. Then I wouldn't need this specific package split.

In the end, this is still better than just dropping the glusterfs module
from the build, which would leave users with no way out whatsoever.

I used samba as an example, but the same problem exists for qemu (which
also ships a gluster storage driver), and in that case it would probably
mean VMs not coming back up until the new (now in universe) package is
installed.



1. https://launchpad.net/bugs/2045063
2. https://wiki.debian.org/PackageTransition
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Retention period for autopkgtest test logs

[Andreas Hasenack]

Hi,

On Mon, Sep 25, 2023 at 3:56 PM Steve Langasek
 wrote:
>
> On Mon, Sep 25, 2023 at 11:17:50AM -0700, Bryce Harrington wrote:
> > On Mon, Sep 25, 2023 at 10:23:36AM -0700, Brian Murray wrote:
> > > Currently test results and log files for autopkgtest runs are kept until
> > > the release for which the test was run reaches its End of Life. This is
> > > also true for autopkgtest runs for packages in PPAs and the Ubuntu QA
> > > team thinks we should not be keeping these for such a long period of
> > > time.
>
> > > We plan to automatically remove test results for PPAs which ran more
> > > than 8 weeks ago. Does 8 weeks seem like too short of a period to
> > > anybody?
>
> > It does feel a bit short; prior results can sometimes be interesting for
> > comparison purposes,
>
> Why would your baseline be a ppa build >8 weeks old, as opposed to a run in
> the Ubuntu archive?  8 weeks is a long time to be iterating in a PPA without
> uploading it to the devel series.
>
> I have no opinion about whether longer than 8 weeks is ok for autopkgtest
> result retention.  But it seems alarming to me that we would have
> out-of-archive development branches lasting 2 months.

There are PPAs for customer engagements that are long-lived. DEP8
results might be important for some of those.

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

Re: First Mantic Minotaur test rebuild

[Andreas Hasenack]

Hi Steve,

On Wed, Sep 13, 2023 at 6:25 PM Steve Langasek
 wrote:
>
> Hi Andreas,
>
> On Mon, Sep 11, 2023 at 05:37:05PM -0300, Andreas Hasenack wrote:
> > Hi,
> >
> > On Wed, Sep 6, 2023 at 6:19 AM Graham Inggs  wrote:
> > >
> > > The first test rebuild of Mantic Minotaur was started on August 30,
> > > 2023 for all architectures, all components. The rebuild is finished
> > > for the main component on all architectures except riscv64, and still
> > > running for universe and multiverse.
> > >
> > > Results (please also look at the superseded builds) can be found at:
> > >
> > > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20230830-mantic-mantic.html
> >
> > Many of these failures are caused by glibc 2.38 now having strlcat and
> > friends, and this causes a dpkg-gensymbols error like this (example
> > from src:libqb):
>
> 
>
> > Do we have a pattern to fix these, or a checklist? Mark them as
> > optional I suppose, but how can we be sure reverse dependencies aren't
> > relying on these strl* symbols, do we rebuild them all? It may sound
> > far fetched, but I suppose some application could have been relying on
> > strlcat from bin:libqb100 (even though it's not declared in
> > libqb-dev's /usr/include/qb/* anywhere).
> >
> > I saw the fix[1] to krb5's build issue, but there the symbol was
> > internal (but still exposed?). Is that what we need to apply,
> > including the replacing of #MINVER# in the symbols file to a strict
> > "equals", which is what I assume changes the shlibs:Depends from a ">=
> > MINVER" to "= $ver", and thus accounts for the ordering of upgrades?
> > And still a breaks for the other binary packages produced by the same
> > source?
>
> krb5 was a special case because its "internal" symbols used a prefixed name,
> so the glibc implementation was not a drop-in ABI-compatible replacement.
>
> For the common case, libraries are providing symbols with the literal names
> "strlcat" and "strlcpy"; if the build system detects these names in the
> system libc it will omit them at build time.  Unless there's some extremely
> unusual linkage, reverse-dependencies that need this symbol will then just
> pick it up from libc6 instead.
>
> So if these library packages pick up a versioned Depends: on libc6 (>= 2.38)
> automatically, no further source changes should be needed.  And if they
> don't have a versioned Depends: for some reason, it should be sufficient to
> manually add one.

We still need to address the removal of the strl* symbols from each
library package that previously had it in its d/*.symbols packages,
right? Should we settle on marking them as optional?

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

Re: First Mantic Minotaur test rebuild

[Andreas Hasenack]

Hi,

On Wed, Sep 6, 2023 at 6:19 AM Graham Inggs  wrote:
>
> The first test rebuild of Mantic Minotaur was started on August 30,
> 2023 for all architectures, all components. The rebuild is finished
> for the main component on all architectures except riscv64, and still
> running for universe and multiverse.
>
> Results (please also look at the superseded builds) can be found at:
>
> https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20230830-mantic-mantic.html

Many of these failures are caused by glibc 2.38 now having strlcat and
friends, and this causes a dpkg-gensymbols error like this (example
from src:libqb):

dpkg-gensymbols: error: some symbols or patterns disappeared in the
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libqb100/DEBIAN/symbols doesn't match
completely debian/libqb100.symbols
--- debian/libqb100.symbols (libqb100_2.0.8-1_amd64)
+++ dpkg-gensymbolsTJnRGb 2023-09-04 11:09:48.720929506 +
@@ -244,6 +244,6 @@
  qb_vsnprintf_deserialize@Base 2.0.1
  qb_vsnprintf_serialize@Base 2.0.1
  remove_tempdir@Base 2.0.1
- strlcat@Base 2.0.1
- strlcpy@Base 2.0.1
+#MISSING: 2.0.8-1# strlcat@Base 2.0.1
+#MISSING: 2.0.8-1# strlcpy@Base 2.0.1
  use_filesystem_sockets@Base 2.0.1

Do we have a pattern to fix these, or a checklist? Mark them as
optional I suppose, but how can we be sure reverse dependencies aren't
relying on these strl* symbols, do we rebuild them all? It may sound
far fetched, but I suppose some application could have been relying on
strlcat from bin:libqb100 (even though it's not declared in
libqb-dev's /usr/include/qb/* anywhere).

I saw the fix[1] to krb5's build issue, but there the symbol was
internal (but still exposed?). Is that what we need to apply,
including the replacing of #MINVER# in the symbols file to a strict
"equals", which is what I assume changes the shlibs:Depends from a ">=
MINVER" to "= $ver", and thus accounts for the ordering of upgrades?
And still a breaks for the other binary packages produced by the same
source?


1. 
https://git.launchpad.net/ubuntu/+source/krb5/commit/?id=a518233aab27fb7e06b8db2a46e5a2a0e4845b33






>
> Additional build failures for packages in mantic-proposed (not yet in
> mantic) can be found at:
>
> http://qa.ubuntuwire.com/ftbfs/
>
> Please help with fixing the build failures.
>
> Graham
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
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 shift (07/AUG - 11/AUG)

[Andreas Hasenack]

Hi,

On Sun, Aug 13, 2023 at 10:48 AM Shengjing Zhu
 wrote:
>
> On Sat, Aug 12, 2023 at 5:40 AM Andreas Hasenack  
> wrote:
> [...]
> > I spent the whole afternoon today trying to get an arm64 mantic VM to
> > troubleshoot this (it has to be a VM), but that was very difficult.
> > canonistack isn't an option. My raspberry pi4 fails to launch a lxd VM
> > (similar to https://github.com/canonical/lxd/issues/7191, but
> > disabling secureboot didn't help: ~LXD is investigating).
>
> I really like the "Debian Quick Image Baker pre-baked images"
> https://people.debian.org/~gio/dqib/
>
> You just need to download a ZIP archive, and it even contains the
> complicated qemu command to run.
>
> Has someone tried to port it to Ubuntu? Or do we have similar tools?

Oh, there are other ways. multipass is one, uvtool is another.

I ended up using uvtool + libvirt on the pi4. I briefly tried
multipass, and while it would also work it seems, I would heve to
configure it to store the images elsewhere. This is a raspberry pi4
after all: the sd card is not really a good storage place. The
multipass snap only allows /mnt (removable media) and /home for
storage, which didn't really fit my usage scenario.

-- 
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 shift (07/AUG - 11/AUG)

[Andreas Hasenack]

Hi,

On Sat, Aug 12, 2023 at 12:52 AM Steve Langasek
 wrote:
>
> Hi Andreas,
>
> On Fri, Aug 11, 2023 at 06:40:16PM -0300, Andreas Hasenack wrote:
> > canonistack isn't an option.
>
> Why?  Do we need to open RTs?

It's unreliable and/or overcommitted. Sometimes you get a lucky
streak, but other times it just won't launch vms. RTs get auto-closed
after a while with a standard message.

To be fair, right now I was able to launch an arm64 instance, so I'll
use that to further troubleshoot rust-loopdev.

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

+1 maintenance shift (07/AUG - 11/AUG)

[Andreas Hasenack]

# rust-phf & friends
Had to rebuild rust-pallete, which was an FTBFS
Filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043222 and
debian fixed it before I had to upload the package with a delta of our
own.

Then rust-markup5ever was failing to build.
Traced to rust-tendril failing to build. Fixed upstream in 0.4.3
(https://github.com/servo/tendril/issues/67), which also needs a newer
rust-futf. Asked debian to update
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043295), which
they did promptly before I uploaded to mantic (I was testing things in
a ppa before to be sure), and that sorted the problem.


# curl 8.2.1-1ubuntu1 DEP8 failure on ppc64el and s390x
Added a retry loop right after slapd was restarted. Fixed in
https://launchpad.net/ubuntu/+source/curl/8.2.1-1ubuntu2 and sent to
debian via https://salsa.debian.org/debian/curl/-/merge_requests/17

# doxygen FTBFS, causing FTBFS in other packages too
https://bugs.launchpad.net/ubuntu/+source/doxygen/+bug/2026834
I had seen this in a previous shift. Debian said they would update to
the version that has the fix
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040864), but that
didn't happen yet. I had two branches with options:
a) 7 patches to make it work
(https://git.launchpad.net/~ahasenack/ubuntu/+source/doxygen/tree/debian/patches?h=mantic-doxygen-cairo-compat)
b) update to 1.9.7
(https://code.launchpad.net/~ahasenack/ubuntu/+source/doxygen/+git/doxygen/+ref/mantic-update-doxygen
unfinished)

I ended up with (c): export env var to make cairo produce pdfs without
the compressed block, having checked that's the only thing that cairo
uses that variable for, CURRENTLY:
https://git.launchpad.net/ubuntu/+source/fenics-dolfinx/tree/debian/rules#n166

I tried to avoid this, bug given it's the second shift I encounter
this, I decided to go ahead. I hope doxygen gets updated to 1.9.7+
soon.

# dolfin-mpc
uninstallable packages
$ sudo apt install libdolfinx-mpc0.6  -t mantic-proposed
 libdolfinx-mpc0.6 : Depends: libbasix0.6 (>= 0.6.0) but it is not installable
 Depends: libdolfinx-real0.6 (>= 1:0.6.0) but it
is not installable
E: Unable to correct problems, you have held broken packages.

Needed a rebuild with fenics-basix 0.6, done:
https://launchpad.net/ubuntu/+source/dolfinx-mpc/0.6.1-3build1

# fenics saga
Many issues around this ecosystem. One looked simple, and was just a
src:mshr rebuild. But that's an FTBFS with the newer src:cgal 5.6
(https://bugs.launchpad.net/ubuntu/+source/mshr/+bug/2030809). Checked
upstream, and project looks dead. Filed a bug with debian
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043307), hoping
for the best, and they fixed it in
https://launchpad.net/ubuntu/+source/mshr/2019.2.0~git20200924.c27eb18+dfsg1-10


# rust-sequoia-ipc FTBFS
Troubleshooting led to an ftbfs in src:rust-nettle-sys, which was
caused by a src:rust-bindgen bug caused by LLVM-16.
https://bugs.launchpad.net/ubuntu/+source/rust-sequoia-ipc/+bug/2030886
Applied the upstream patch to
https://launchpad.net/ubuntu/+source/rust-bindgen/0.60.1-2ubuntu1 and
uploaded, it's going through migration.
Debian is unaffected because, at the time of this troubleshooting,
they were still using LLVM-14. I did file
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043374, though.
I subscribed to rust-bindgen in debian to be notified whenever they
update or apply the patch, so this package can become a sync again.

If you see rust-* tests failing and using rust-bindgen without the
fix, retrigger them with rust-bindgen from mantic-proposed. I did so
for a few and they became green.


# rust-bindgen (my upload) migration
It's blocked on an arm64-only dep8 failure in rust-loopdev/0.4.0-3:

819s  detach_a_backing_file_default stdout 
819s thread 'detach_a_backing_file_default' panicked at 'assertion
failed: `(left == right)`
819s   left: `0`,
819s  right: `1`: there should be no loopback devices mounted',
tests/integration_test.rs:176:5

I spent the whole afternoon today trying to get an arm64 mantic VM to
troubleshoot this (it has to be a VM), but that was very difficult.
canonistack isn't an option. My raspberry pi4 fails to launch a lxd VM
(similar to https://github.com/canonical/lxd/issues/7191, but
disabling secureboot didn't help: ~LXD is investigating). An arm64
MAAS server I have access to is a lottery to find a node that deploys,
but eventually I got one that deployed, only to find out the error
doesn't happen there. The only place where I reproduced it is in a PPA
with the Canonical DEP8 infrastructure, which means the troubleshoot
cycle is upload to ppa, wait for build/publish, trigger dep8, wait,
repeat, so I didn't get very far in the time that was left. My thought
is that perhaps in our arm64 dep8 vms, /dev/loop3 (hardcoded in the
failing test) is perhaps taken, but changing it to another one didn't
help. Then perhaps there is the 100ms sleep that the test has and that
we might have to tweak. But that's just a 

Re: SRU bug subscription for sponsors

[Andreas Hasenack]

Hi,

On Thu, Jun 15, 2023 at 6:50 AM Sebastien Bacher  wrote:
>
> Le 14/06/2023 à 22:32, Robie Basak a écrit :
> >
> > If sponsors aren't prepared to do this, I question whether what they are
> > doing is actually useful. The harm is that they are leaving
> > non-uploaders in the cold, and review teams are spending unnecessary
> > effort that could be diverted to doing the reviews that only they can
> > do.
>
> The issue is not really 'to be prepared to do this'. I do agree with you

Good ;)

> that the sponsors should be engaged in the process, especially when
> sponsoring work from someone who isn't familiar with all the details of

It's not just familiarity. Sometimes the person just doesn't have
enough privileges to take an action, like nominate a series, or retry
autopkgtests. Specially retry autopkgtests.

> the system. It is especially true for SRU uploads which often need
> follow-ups to deal with the issues you mentioned. Subscribing to the
> corresponding launchpad bug makes sense in that context and that's
> something I would recommend doing.

I agree.

>
> Where I disagree is that it should be forced on us this way, without
> even letting us the change to have a public discussion here before
> having the change in action.

Well, the discussion is happening now.

> A few concerns I have
>
> 1. I've noticed that people (even in our teams at Canonical) don't keep
> up with bug emails and some end up just ignoring anything coming from
> launchpad. The issue isn't new and isn't due to the new bot, but the bot
> is adding to the problem.

gmail is super bad at filtering email, agreed. What other way would we
have to follow the progress of an upload that was sponsored? Who is in
the best position to do that?

> 2. You argue that we should expect that the people asking for sponsoring
> aren't familiar with the processes or they wouldn't ask for sponsoring
> such they need guidance and involvement from their sponsors. While
> that's true for a class of contributors it's often not the case. I'm
> regularly sponsoring work for people in my team who are perfectly able
> to follow up on their changes and know the process, it just happens that
> sometime they need to upload a fix outside of the packagesets they have
> access to

Or retry an autopkgtest with triggers or special options. Besides the
question of ACLs, where most sponsored people wouldn't even be able to
do it, there is a tricky learning curve to deal with autopkgtest and
migration issues. So much that it's a standard recurring question when
someone applies for core dev privileges.

>
> 3. You say "sponsors will follow through on uploads until they land",
> could the script be made to be smart enough to unsubscribe the sponsor

Maybe, but once a bug is "fix released" (since the fix landed), there
normally aren't many follow-ups to it. If there are, then it might
have introduced a regression, in which case you would definitely want
to know about it, or it's another type of comment and you can easily
unsubscribe from the bug then.

> at that point? Launchpad bugs are often noisy (users sometime comment on
> unrelated closed issues which seem similar to what they face, they ask
> for guidance on how to install an SRU updates, ...) which adds to
> problem 1. Yes I can go to unsubscribe manually if I'm bothered enough
> but that's just one more annoyance and manual action needed which
> contributes to the 'it's easier to just filter launchpad emails in a
> folder and ignore those'.

Imagine the annoyance of the SRU team when they find a bug that was
supposedly verified, tags flipped, but the package didn't even build
(it's an FTBFS) :) Somebody must have gotten an email about it. Could
that email be one of those that are being ignored?

Or when somebody asks why the sru hasn't landed yet, and it has
current autopkgtest failures that the sponsored person cannot do
anything about other than ask for help somewhere, perhaps in the bug.
Would that be lost too in some folder?

I do believe sponsoring is more than pressing a button and forgetting
about it. And I wonder how it's working in the new patch pilot
program, if uploads are being followed through, or being forgotten
after dput (my shift will be in a few days).

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

Re: Ubuntu 23.04 is Unusable with GNOME 44.0 Due to Major Bugs - Priority Must Be for GNOME 44.1 ASAP!

[Andreas Hasenack]

Do you have launchpad bugs for these issues? I do have freezes every now
and then, and I have seen the cursor being stuck in the resize icon, and
wanted to check if the reports match what I'm seeing on my system (xorg).

On Tue, May 16, 2023 at 11:44 AM tothepoin...@gmail.com <
tothepoin...@gmail.com> wrote:

> I am sure I am many who have already pointed this out, but Gnome 44.0 in
> Ubuntu 23.04 is plagued with bugs, windows not focusing, random freezes
> which requires a hard-reset, mouse cursor stuck on resize icon and do not
> even try using a Wayland session. And...And...It's a mess.
>
> Gnome 44.1 is a major, MAJOR bug fix release that resolves all these
> problems.  It must be released ASAP to fix 23.04!
>
> Why have you guys not made it a priority so as to make 23.04 stable?
> Other distros had made it a priority and have long put out 44.1, except
> Ubuntu!  I had to downgrade to 22.10.
>
> If you are in the process of releasing it then fantastic.  What's the
> timeline on that?
>
> Thank you in advance.
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: +1 maintenance: 6-10 March 2023

[Andreas Hasenack]

Hi,

On Mon, Mar 13, 2023 at 2:00 AM Steve Langasek
 wrote:
>
> Hi Andreas,
>
> I notice that most of these packages mentioned in your report are in main.
> Were there particular reasons for you to focus on these during +1
> maintenance?  (You mention "not so" random retries)

I started with the find-proposed-cluster script, which flagged java
packages, and then I went to the excuses-by-team page[1]. I guess that
directed me more to main packages indeed. And I totally forgot about
NBS packages this time around.

> While we of course need to take care of the packages in main, a reminder
> that the expectation is that the engineering teams responsible for those
> packages will in general take care of them outside of +1 maintenance, with
> +1 maintenance focused on driving down the -proposed queue overall, with, if
> anything, a de-emphasis on main.

Noted.

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

+1 maintenance: 6-10 March 2023

[Andreas Hasenack]

Hi,

this is my report. I skipped March 9th to do some SRU work.

# php-net-ldap2 blocking openldap
bug #2008825, fixed and uploaded

# strongswan DEP8 test
I'm the one who introduced the new DEP8 tests to strongswan, and
noticed some flakiness, but I believe this was caused by the overall
slowness in fetching packages from the ftpmaster server. I increased
the time I was giving the lxd container to get ready (I need to
install packages in it for the test), and it looks better now.

# (Not so) random retries
netplan.io
openssh: test logs were showing lots of ^@^@^@ characters, indicating
some sort of corruption. A retry worked.
firewalld: timeout
zfs-linux: was failing on "badpkg" errors. Retry worked.

# crash
Sometimes failed on fetching the gpg key needed for the ddeb
repository, other times it was getting a 503 error from apt. Retries
eventually passed these errors, but the test still failed. Took me a
long time to get a test setup ready:
- the kernel ddeb it downloads is huge, and was taking a very long
time. Mentioned to ~is, as I was getting around 200kb/s. This was
before I investigated the DEP8 slowness, maybe it was related
- lunar lxd vms weren't booting, had to disable secure boot
- lunar lxd vms are using the kvm kernel by default, which doesn't
have KCORE enabled (had to investigate that until I finally saw it was
the kernel flavor that didn't enable it). Switched to generic.
- ddebs.ubuntu.com is flaky and slow, so each test run was taking a
long time (there is an internal RT ticket about that, from 7 months
ago)
- finally got a test setup ready and showing a problem in lunar:

ubuntu@l-crash:~$ sudo crash -st /usr/lib/debug/boot/vmlinux-6.1.0-16-generic
WARNING: /usr/lib/debug/boot/vmlinux-6.1.0-16-generic
 and /proc/version do not match!

WARNING: /proc/version indicates kernel version: 6.1.0-16-generic

crash: please use the vmlinux file for that kernel version, or try using
   the System.map for that kernel version as an additional argument.

It is the same version:
ubuntu@l-crash:~$ uname -a
Linux l-crash 6.1.0-16-generic #16-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb
24 14:37:30 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Since those versions look the same to me, I don't know what is going
on, and filed https://bugs.launchpad.net/ubuntu/+source/crash/+bug/2009595
with the update-excuse tag.


# mysql-8.0
Failing a lot on amd64, also taking a long time to run.

Tests on arm64, where mysql-8.0 is already on big_packages, are taking
around 1h30 to run, even less than 1h most of the time.
On amd64 they take 2h or more, and usually fail with a timeout of
"kind test" (so not related to the ftpmaster slowness), where the
timeout is the default 10k seconds (~2h42).
I checked a few logs and the mysql amd64 test suite was killed at
different stages due to the timeout: 46%, 88%, 74%, 90%
Added mysql-8.0/amd64 to big_packages:
https://code.launchpad.net/~ahasenack/autopkgtest-cloud/+git/autopkgtest-package-configs/+merge/438389
After the change, retriggered amd64 and it passed, quickly.
Also retriggered s390x, there was one failure, not related to a
timeout, but infra. There it's still failing, and taking a long time
(3h). Looking at the log, the test was killed mid-apt-download:

Get:13 http://ftpmaster.internal/ubuntu lunar/universe s390x
mysql-testsuite-8.0 s390x 8.0.32-0ubuntu4 [357 MB]
autopkgtest-virt-ssh [11:46:34]: --- nova console-log
014de5df-c6ce-484a-a082-7f6ef2ccb8d6
(adt-lunar-s390x-mysql-8.0-20230312-020749-lrg-root4) --

So another victim of poor network performance to ftpmaster.internal.

# glib2
glib2 blocking netplan.io, let's see
- auto-multiple-choice dep8 test, gets killed due to timeout kind:
install. It was killed mid apt-get install, while downloading packages
https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/arm64/a/auto-multiple-choice/20230306_200519_8770d@/log.gz

# chrony
Blocking tzdata
Two chrony tests are consistently failing on arm64, armhf, i386 and
ppc64el: 113-leapsecond and 124-tai
I picked the easiest of those arches to try to reproduce it locally
(arm64 it is), but it always works. Works in my pi4, on another bare
metal arm64, on a random arm64 VM someone let me use. I don't know
what's going on. This test suite runs each test multiple times (20),
and tolerates up to 2 failures. But these two tests are failing all
runs in the DEP8 infrastructure, and locally they all pass.

# openjdk-XX
Tests affected by the ftpmaster.internal slowness.

# python3.11
$ python3-dbg-config --cflags --libs
/usr/bin/python3-dbg-config: 117: Syntax error: Unterminated quoted string
I filed https://bugs.launchpad.net/ubuntu/+source/python3.11/+bug/2009967
with a patch. I would prefer if foundations uploaded this, as the
package is currently a sync, and I don't want to inadvertently start
another python-related massive DEP8 run.


1. https://lists.ubuntu.com/archives/ubuntu-devel/2023-March/042500.html

-- 
ubuntu-devel mailing list

DEP8 timeouts on install phase

[Andreas Hasenack]

Hi,

taking this as a sample:

https://autopkgtest.ubuntu.com/packages/f/fdroidserver/lunar/ppc64el

It looks like something got slower since a few days ago, and tests started
being killed due to a timeout ("kind: install" timeout, which has a default
of 3000s in autopkgtest).

By the end of February 2023, the passing tests were taking about 20min.
Then a little bit more up to 26min in March 2nd, and then they all started
to fail.

Looking at the logs, we see apt-get install being interrupted by the
autopkgtest timeout mid package download:

Get:242 http://ftpmaster.internal/ubuntu lunar/universe ppc64el
apksigner all 31.0.2-1 [438 kB]
Get:243 http://ftpmaster.internal/ubuntu lunar/main ppc64el
openjdk-17-jdk-headless ppc64el 17.0.6+10-1 [217 MB]
autopkgtest-virt-ssh [04:23:09]: --- nova console-log
766e17f7-5365-4cdf-8202-35b6b88a7cdc
(adt-lunar-ppc64el-fdroidserver-20230303-012357-lrg-root5) --


When the test were passing (in the 20min range), they were also downloading
hundreds of packages. So something got slower since then. Or this is an
isolated case.

We can add fdroidserver/ppc64el to "big_packages", or perhaps "long_tests",
if this is expected, or if it will take a long time to be fixed. Otherwise
I don't know what to do here, as just retrying will just burn through more
energy without any clear indication that it will work.

FYI, fdroidserver/ppc64el is currently one of the packages blocking the
openjdk-* migration.

I did a check with ./retry-autopkgtest-regressions --log-regex '\(kind:
install\)'
That returned 82 urls[1]:
s390x: 32
ppc64el: 31
arm64: 19

Should we wait and see if it gets better, assuming there is ongoing work in
the DEP8 infra? Or bump the timeout? Or something else?

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

dbconfig-common and local databases

[Andreas Hasenack]

Hi,

Today, installs like below fail in Ubuntu because dbconfig-common is
configured before a database is installed and configured:

apt install rsyslog-mysql
apt install rsyslog-pgsql
apt install phpmyadmin #1438706 #1649265
apt install bacula-director-mysql bacula #1116634
apt install redmine-mysql

There may be others.

The dbconfig-common (or dbconfig-mysql, ...) package cannot declare a
Depends or Recommends on the database server, because it could be
remote. It does declare a Suggests on the db server, though
(dbconfig-mysql suggests default-mysql-server, dbconfig-pgsql suggests
postgresql, and so on).

But this also doesn't work:

  apt install mysql-server rsyslog-mysql

or this:

  apt install postgresql-server rsyslog-pgsql

dbconfig-common is still configured before the DB server.

In the other cases I listed above, actually including the database
server in the same apt transaction works, but I'm inclined to believe
it's pure luck, as those are packages with more complex dependencies
and I think it's just chance that the DB server is installed first.
But I could be wrong, and that's why I'm sending this email:

is there something special that packages depending on dbconfig-common
should do, either in d/control, or in maintainer scripts, to avoid the
problem? Or is it just a "known issue", i.e., "you shall install and
configure the DB server first"?

But then, how to handle the case where the DB is remote? The only
chance one gets to input the remote system's details (ip and port), in
an interactive install, is after the postinst first fails: then you
get a menu with the options "abort, retry, retry (skip questions),
ignore", and if you "retry", then it actually asks you more detailed
questions about the database (is it remote, etc). Is this also the
expected workflow? Let it fail, then retry, and then provide the
details?

And what about unattended installs? "apt install -y rsyslog-mysql
mysql-server" will fail, but "apt install -y mysql-server; apt install
-y rsyslog-mysql" will work. Or resort to debconf-set-selections?

I first encountered this when writing DEP8 tests for rsyslog-pgsql and
rsyslog-mysql: if I declared just the "rsyslog-pgsql" (or mysql)
dependency in the autopkgtest control file, the installation would
fail. I had to install the DB server via d/t/control dependencies, and
then inside the test itself install rsyslog-{pgsql,mysql}.

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

Re: Upcoming change: rsyslog's apparmor enforced by default

[Andreas Hasenack]

Hi Steve,

On Sun, Feb 12, 2023 at 2:48 AM Steve Langasek
 wrote:
>
> Hi Andreas,
>
> On Sat, Feb 11, 2023 at 02:45:17PM -0300, Andreas Hasenack wrote:
> > Hi,
>
> > In the next few days, if all goes according to plan, I'll upload
> > rsyslogd to lunar with a change[1] to the way its apparmor profile is
> > applied.
>
> > The confinement status won't be changed during upgrades, but fresh
> > installs will have the apparmor profile enforced by default. Up until
> > now, it's been disabled.
>
> Can you elaborate on this decision not to change the behavior on upgrade?
> It's expected on upgrade between releases that behavior will change; and to

Hmm, you are right, I was thinking in the context of lunar to lunar
upgrades, and not release upgrades, which is what we are aiming for.

> not enforce for upgrading users means a difference in configs between new
> installs and upgrades that complicates the support matrix over the long
> term.
>
> I am strongly in favor of making the behavior on upgrade conform to the
> behavior on new installs - even if that means there might be some unpleasant
> surprises where the package fails to configure because of apparmor being
> enabled.  That seems unlikely to me in any case; even if the user has
> diverged from the stock rsyslog config, it seems more likely to me that the
> daemon would still start up but might in some cases fail to log.  Again,

Correct, I'm not failing the startup because apparmor failed to apply
or load, and that is in line with current rsyslog's behavior towards
its plugins. If a plugin fails to write a log (like mysql is not
available, or apparmor prevented it from doing so), it will just keep
retrying in the background, instead of failing the whole daemon or the
logging to other places.

I'll make the change, thanks for the feedback!

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

Upcoming change: rsyslog's apparmor enforced by default

[Andreas Hasenack]

Hi,

In the next few days, if all goes according to plan, I'll upload
rsyslogd to lunar with a change[1] to the way its apparmor profile is
applied.

The confinement status won't be changed during upgrades, but fresh
installs will have the apparmor profile enforced by default. Up until
now, it's been disabled.

A summary is in the README.apparmor[2] file, and d/NEWS was also
updated/created. I tried a mix of fixed and dynamic profile snippets,
and packages can install their own snippets if needed. These would
usually be packages that alter the rsyslog configuration to log
somewhere else where the normal apparmor profile would have denied
that, but at the same time we don't want to allow that by default if
it's not needed.

There are a few more use cases I would like to tackle, including more
test cases, and the `omprog` plugin is an obvious one. This is not yet
covered, and I hope to get more data about its usage before coming up
with a solution. It's hard to try to detect its usage in the config
file because the config can be in so many different formats. Maybe we
can come up with generic sandbox of some sort for binaries used with
the omprog plugin, or maybe we will just have to leave users to adjust
that via the existing /etc/apparmor.d/local/usr.sbin.rsyslogd
mechanism.

This adds a lot of delta to the package, at least in line count, but I
don't think it's hard to maintain. I'll also of course try to submit
this to debian, once we settled on the approach in lunar.

1. 
https://code.launchpad.net/~ahasenack/ubuntu/+source/rsyslog/+git/rsyslog/+merge/436955
2. 
https://git.launchpad.net/~ahasenack/ubuntu/+source/rsyslog/tree/debian/README.apparmor?h=lunar-rsyslog-enable-apparmor-dep8-take4-dot-d

-- 
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 (2011-11-16 - ~2011-11-22)

[Andreas Hasenack]

Hi,

this +1 maintenance shift was a bit less useful due to external
interrupts and holidays, and of course large test queues, but I tried
to make the most of it.

Since the dep8 queue is clogged, I started by focusing on NBSs, and
lastly FTBFs since the builders are fast:

# gnuradio stack and libuhd transition
Lots of no-change rebuilds here:
gnuradio
soapyuhd
gnss-sdr
gr-osmosdr
gr-radar
gr-air-modes
gqrx-sdr
gr-fosphor
gr-gsm
gr-satellites
gr-funcube
gr-rds
gr-limesdr
gr-iqbal
gr-hpsdr

This are all mostly just waiting for gnuradio to finish testing.
gnss-sdr I'm unsure. It had some failures, but after a trigger the
result became "neutral". Since the excuses page still shows the red
failure (hasn't picked up the new result?), I'm unsure if "neutral"
will be good enough for migration, we will have to wait.


# librcutils0d transition to librcutils1d
ros-image-common
ros-urdf
ros2-rosidl (FTBFS on armhf, see LP: #1996897). Upstream is asking for
help on this one
ros-class-loader
ros-ros-comm


And lastly I fixed a git FTBFS on s390x
https://bugs.launchpad.net/ubuntu/+source/git/+bug/1997475 which was
blocking ubuntu-advantage-tools, docker.io, and perhaps others. What
took a lot of time here was to get a s390x VM to try to reproduce the
problem, as canonistack is in bad shape again (at least for s390x).
Thanks Christian for lending me a mainframe for a few hours ;)

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

Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)

[Andreas Hasenack]

Hi

On Thu, Aug 18, 2022 at 12:28 PM Steve Langasek
 wrote:
>
> Hi Andreas,
>
> On Thu, Aug 18, 2022 at 10:24:31AM -0300, Andreas Hasenack wrote:
>
> > I thought of:
> > a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> > subscribe to the tiff package in debian, and sync it manually the next
> > time there is a debian upload
>
> I'm concerned that this requires subscription to the package in Debian for
> this to not fall off the radar.  We have merges.ubuntu.com which tracks
> which packages need to be updated, and the standing assumption is that the
> person who last uploaded the package to Ubuntu is responsible for following
> through on the merges.  Is this not the current practice of the Ubuntu
> Server team?

It is, and we have a weekly report[1] about it. I just go through this
extra step of subscribing to the package in the tracker so I don't
have to wait for that weekly report.

> There's a commandline tool, 'grep-merges', which lets you grep for packages
> you touched last by email.  'grep-merges hasenack' currently returns empty
> so you're currently good :)

Thanks ;)


1. https://lists.ubuntu.com/archives/ubuntu-server/2022-August/009372.html
(grep-merges is the last section in that email)

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

Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)

[Andreas Hasenack]

Oh, this is a rabbit hole...

I'll just bite the bullet and drop the delta in 4ubuntu2, and watch
for new debian uploads.

On Thu, Aug 18, 2022 at 10:36 AM Marc Deslauriers
 wrote:
>
> On 2022-08-18 09:24, Andreas Hasenack wrote:
> > Hi,
> >
> > On Wed, May 25, 2022 at 9:52 AM Lukas Märdian  wrote:
> >>
> >> Am 25.05.22 um 13:22 schrieb Marc Deslauriers:
> >>> [...]
> >>>> We needed a version that does not contain the word "ubuntu", so it can be
> >>>> auto-synced, once the committed patch is uploaded into Debian. But at 
> >>>> the same
> >>>> time we needed it to be bigger than the current version (1.0.1-3build2) 
> >>>> and
> >>>> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" 
> >>>> version. We
> >>>> came up with the following:
> >
> > I found myself in a similar situation today, but not quite.
> >
> > I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component
> > mismatch. Eventually the MIR[2] was approved, and I can now remove the
> > delta, but debian hasn't uploaded a new version yet. How to version
> > the ubuntu package and allow for auto-sync to sync it in the future?
> >
> > 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new
> > kinetic upload without ubuntu in the version)
> >
> > I thought of:
> > a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> > subscribe to the tiff package in debian, and sync it manually the next
> > time there is a debian upload
> > b) use 4.4.0-5~build1
> > c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if
> > we need another ubuntu upload *with* delta again, it gets messy
> > d) 4.4.0-4maysync1 is lower than the current one in kinetic
> >
> > I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye
> > on the package on the debian side of things, but what do you think of
> > (b)?
> >
>
> Of course, as soon as you use 4.4.0-5~build1, debian will release 4.4.0-4.1 :)
>
> Marc.
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)

[Andreas Hasenack]

And I forgot the links:

1. https://launchpad.net/ubuntu/+source/tiff/4.4.0-4ubuntu1
2. https://bugs.launchpad.net/ubuntu/+source/lerc/+bug/1977551

On Thu, Aug 18, 2022 at 10:24 AM Andreas Hasenack  wrote:
>
> Hi,
>
> On Wed, May 25, 2022 at 9:52 AM Lukas Märdian  wrote:
> >
> > Am 25.05.22 um 13:22 schrieb Marc Deslauriers:
> > > [...]
> > >> We needed a version that does not contain the word "ubuntu", so it can be
> > >> auto-synced, once the committed patch is uploaded into Debian. But at 
> > >> the same
> > >> time we needed it to be bigger than the current version (1.0.1-3build2) 
> > >> and
> > >> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" 
> > >> version. We
> > >> came up with the following:
>
> I found myself in a similar situation today, but not quite.
>
> I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component
> mismatch. Eventually the MIR[2] was approved, and I can now remove the
> delta, but debian hasn't uploaded a new version yet. How to version
> the ubuntu package and allow for auto-sync to sync it in the future?
>
> 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new
> kinetic upload without ubuntu in the version)
>
> I thought of:
> a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> subscribe to the tiff package in debian, and sync it manually the next
> time there is a debian upload
> b) use 4.4.0-5~build1
> c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if
> we need another ubuntu upload *with* delta again, it gets messy
> d) 4.4.0-4maysync1 is lower than the current one in kinetic
>
> I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye
> on the package on the debian side of things, but what do you think of
> (b)?

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

Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)

[Andreas Hasenack]

Hi,

On Wed, May 25, 2022 at 9:52 AM Lukas Märdian  wrote:
>
> Am 25.05.22 um 13:22 schrieb Marc Deslauriers:
> > [...]
> >> We needed a version that does not contain the word "ubuntu", so it can be
> >> auto-synced, once the committed patch is uploaded into Debian. But at the 
> >> same
> >> time we needed it to be bigger than the current version (1.0.1-3build2) and
> >> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. 
> >> We
> >> came up with the following:

I found myself in a similar situation today, but not quite.

I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component
mismatch. Eventually the MIR[2] was approved, and I can now remove the
delta, but debian hasn't uploaded a new version yet. How to version
the ubuntu package and allow for auto-sync to sync it in the future?

4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new
kinetic upload without ubuntu in the version)

I thought of:
a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
subscribe to the tiff package in debian, and sync it manually the next
time there is a debian upload
b) use 4.4.0-5~build1
c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if
we need another ubuntu upload *with* delta again, it gets messy
d) 4.4.0-4maysync1 is lower than the current one in kinetic

I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye
on the package on the debian side of things, but what do you think of
(b)?

-- 
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: 2022-08-08 through 2022-08-12

[Andreas Hasenack]

I started looking at some ffmpeg 5 rdeps, and moved on to pytest and others.
I subscribed to the Debian tracker for all packages where I introduced
delta, so I can sync them when Debian incorporates the changes or
fixes the issue in some other way, or keep merging.


# audacity
ftbfs with libavcodec59
Audacity was removed from debian testing on August 8th, 2022
Debian RC bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004598
Filed Ubuntu bug:
https://bugs.launchpad.net/debian/+source/audacity/+bug/1983862
Latest upstream is 3.1.3, released in December 23rd, 2021. Does not
have ffmpeg 5.0 patches
FFmpeg 5.0 support: https://github.com/audacity/audacity/pull/3121
Resolves: https://github.com/audacity/audacity/issues/2445

Upgrading audacity to 3.1.x requires wxwidgets >= 3.1.x
Needs debian to accept wxwidgets 3.2, then we can update audacity to
3.1.x and apply patch to fix build with ffmpeg 5.0
ITP bug for wxwidgets3.2:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919903
wxwidgets 3.2.0 was just released
(https://www.wxwidgets.org/news/2022/07/wxwidgets-3.2.0-final-release/)
and is in the debian NEW queue:
https://ftp-master.debian.org/new/wxwidgets3.2_3.2.0+dfsg-1.html

Summary: first wxwidgets 3.2, then update audacity to 3.1.3+, and then
apply the ffmpeg5 patches if they are not released yed.
Plan B: try to backport the ffmpeg5.0 patches from that github PR into
the old audacity version we have.


# pytest
I closed https://bugs.launchpad.net/ubuntu/+source/pygments/+bug/1980296
as pygments and pytest are in the archive (pytest still in
kinetic-proposed only, due to introducing regressions in a few other
packages).

pytest 7.1.2-2 induced regressions:
pygmsh pygmsh/7.1.17-2
https://github.com/nschloe/pygmsh 7.1.17 is latest upstream release
segfault during test
pygmsh -> gmsh -> (opencascade transition) -> netgen FTBFS with new opencascade
netgen uploaded and fixed via
https://launchpad.net/ubuntu/+source/netgen/6.2.2006+really6.2.1905+dfsg-5ubuntu1
rebuild of netgen and gmsh needed. gmsh rebuild done:
https://launchpad.net/ubuntu/+source/gmsh/4.8.4+ds2-2build2
netgen upstream patch to fix ftbfs with new opencascade:
https://github.com/NGSolve/netgen/commit/08993ae5e2b687e6c21d045b0a9a3f7e8722f17d
debian bug for above: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014964
Filed ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/netgen/+bug/1983997,
uploaded package to kinetic
Forwarded to debian via Salsa PR:
https://salsa.debian.org/science-team/netgen/-/merge_requests/12

pytest DEP8 error:
unittests-3  FAIL stderr: lsof version information:
Filed https://bugs.launchpad.net/ubuntu/+source/pytest/+bug/1984135
In debian it doesn't fail because lsof is not installed
Uploaded https://launchpad.net/ubuntu/+source/pytest/7.1.2-2ubuntu1 to
ubuntu, forwarded fix to debian via Salsa PR:
https://salsa.debian.org/python-team/packages/pytest/-/merge_requests/1


# netgen
uploaded 
https://launchpad.net/ubuntu/+source/netgen/6.2.2006+really6.2.1905+dfsg-5ubuntu1
to fix ftbfs with new opencascade
FTBFS bug: https://bugs.launchpad.net/ubuntu/+source/netgen/+bug/1983997
Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014964
Forwarded to debian via salsa pr:
https://salsa.debian.org/science-team/netgen/-/merge_requests/12

# deal.ii
Failed test with new opencascade
It needs a no-change rebuild with new opencascade.
Done via https://launchpad.net/ubuntu/+source/deal.ii/9.4.0-1ubuntu2
Failed on riscv64, where it takes about a day and a half to build.
Currently rebuilding again. I don't have the log of the previous build
anymore, but it looks like the compiler was killed. Maybe due to a
timeout limit, or an OOM issue.

# kicad
Rebuild with new opencascade:
https://launchpad.net/ubuntu/+source/kicad/6.0.7+dfsg-1build1

# gmsh
Rebuild with new opencascade:
https://launchpad.net/ubuntu/+source/gmsh/4.8.4+ds2-2build2


# Misc retries
Retries for failed dep8 tests under psmisc:
booth arm64
drumkv1 armhf
openmsx-catapult armhd
All passed.
Some other random retries
zarr armhf
tiff/libreoffice on armhf
opentsne

# tiff component mismatch
New debian upload enabled lerc support, which is in universe and
triggered a component mismatch.
I filed https://bugs.launchpad.net/ubuntu/+source/tiff/+bug/1984327
before finding an existing MIR for it, and uploaded a delta which
removes lerc support from the ubuntu package:
https://launchpad.net/ubuntu/+source/tiff/4.4.0-4ubuntu1
I subscribed to the MIR bug at https://bugs.launchpad.net/bugs/1977551
and am ready to undo the delta once that is approved, if noone beats
me to it.


# pax-utils
lddtree switched from sh to py, it's missing python dependencies. I
filed https://bugs.launchpad.net/ubuntu/+source/pax-utils/+bug/1985093,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017021 and
submitted a salsa PR at
https://salsa.debian.org/debian/pax-utils/-/merge_requests/1.
I uploaded https://launchpad.net/ubuntu/+source/pax-utils/1.3.5-1ubuntu1
to kinetic, 

Re: rsyslog trigger?

[Andreas Hasenack]

Never mind, the trigger exists already :)

On Wed, Jul 20, 2022 at 10:49 AM Andreas Hasenack  wrote:
>
> Hi,
>
> I was working on a few packages that had bugs related to rsyslog
> logging, and noticed that they don't seem to restart or reload rsyslog
> after they install a config snippet in /etc/rsyslog.d/*.conf.
>
> For example, haproxy even has this note in its README.Debian:
> ```
> The default HAProxy configuration in Debian uses /dev/log for logging and
> ships an rsyslog snippet that creates /dev/log in HAProxy's chroot and logs 
> all
> HAProxy messages to /var/log/haproxy.log. To take advantage of this, you must
> restart rsyslog after installing this package.
> ```
> I checked a few others and the only restart/reload I see is in the
> logrotation, which might not even kick in if there is no log file yet,
> or if it's empty.
>
> Would it make sense to use dpkg triggers to restart rsyslog everytime
> a file is updated in /etc/rsyslog.d/*.conf?

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

rsyslog trigger?

[Andreas Hasenack]

Hi,

I was working on a few packages that had bugs related to rsyslog
logging, and noticed that they don't seem to restart or reload rsyslog
after they install a config snippet in /etc/rsyslog.d/*.conf.

For example, haproxy even has this note in its README.Debian:
```
The default HAProxy configuration in Debian uses /dev/log for logging and
ships an rsyslog snippet that creates /dev/log in HAProxy's chroot and logs all
HAProxy messages to /var/log/haproxy.log. To take advantage of this, you must
restart rsyslog after installing this package.
```
I checked a few others and the only restart/reload I see is in the
logrotation, which might not even kick in if there is no log file yet,
or if it's empty.

Would it make sense to use dpkg triggers to restart rsyslog everytime
a file is updated in /etc/rsyslog.d/*.conf?

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

Re: LFS_CFLAGS on 32bits architectures

[Andreas Hasenack]

Hi,

On Mon, May 30, 2022 at 8:29 PM Steve Langasek
 wrote:
>
> Hi Andreas,
>
> On Mon, May 30, 2022 at 02:16:59PM +0000, Andreas Hasenack wrote:
> > I experimented a few things, and this got it building again:
> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -10,6 +10,10 @@ export DH_GOLANG_INSTALL_ALL := 1
> >  # Skip integration tests when building package: they need docker images.
> >  export ADSYS_SKIP_INTEGRATION_TESTS=1
> >
> > +# be sure to set LFS_CFLAGS if needed, required for libsmbclient on 32bits
> > +CGO_CFLAGS  := $(shell getconf LFS_CFLAGS)
> > +export CGO_CFLAGS
> > +
> >  %:
> > dh $@ --buildsystem=golang --with=golang,apport
>
> Would be interesting to know if 'export DEB_BUILD_MAINT_OPTIONS=future=+lfs'
> also fixed the build, as conceptually that's the same level of abstraction
> as fixing dpkg-buildflags per the above.

That works for the build, but fails later override_dh_auto_install
when d/rules does this:
override_dh_auto_install:
dh_auto_install -- --no-source
...
# run go generate to install assets, but don’t regenerate them
GENERATE_ONLY_INSTALL_TO_DESTDIR=$(CURDIR)/debian/adsys go
generate -tags tools $(GOFLAGS) ./...

with:
# run go generate to install assets, but don’t regenerate them
GENERATE_ONLY_INSTALL_TO_DESTDIR=/home/ubuntu/git/packages/adsys/adsys/debian/adsys
go generate -tags tools
-ldflags=-X=github.com/ubuntu/adsys/internal/consts.Version=0.8.6~ppa5
--mod=vendor -buildmode=pie ./...
# github.com/mvo5/libsmbclient-go
In file included from
../../vendor/github.com/mvo5/libsmbclient-go/libsmbclient.go:17:
/usr/include/samba-4.0/libsmbclient.h:84:13: error: size of array
'smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS' is too large
   84 | typedef int
smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS[sizeof(off_t)-7];
  | ^~~
cmd/adsysd/main.go:17: running "go": exit status 2


I'm not sure what this step is doing, but it looks like the lfs flags
are lost. My other approach (with CFO_FLAGS) worked.

Isn't there a place in the golang buildsystem to inject this $(getconf
LFS_CFLASG)? Imagine users who just git clone that repo and build
adsys manually on armhf, against upstream samba (without the LFS patch
in libsmbclient.h). They would get a build with a 32bit off_t type
which would be broken. A plain upstream samba build will expect an
off_t of 64 bits[1].

Given [1], that samba will always be built with LFS, then I think the
LFS_CFLAGS change should be in adsys, somewhere in their build system.

1. 
https://github.com/samba-team/samba/blob/ac16351ff5a0c5b46f461c26516b85e8483bba83/buildtools/wafsamba/wscript#L611

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

LFS_CFLAGS on 32bits architectures

[Andreas Hasenack]

Hi,

on a pi3 (armhf):

$ getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

This only returns a value where it's needed, aka, 32bits (AFAIK).

Shouldn't this be part of our default set of CFLAGS on 32bits architectures?

The reason I ask is this old samba bug[1] ("64bits prototype not
precised")], which iterated over a few fixes:

- force-refine _LARGEFILE64_SOURCE and _FILE_OFFSET_BIGS in
libsmbclient.h[2] (it's been like this since 2011 in the package)
- it was replaced with [3], which uses a `static_assert(sizeof(off_t)
>= 8` check and fails the build on 32bit without LFS
- then it was replaced again with [4], which uses this one liner:
`typedef int 
smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS[sizeof(off_t)-7];`,
which also fails the build because it becomes a very large array on
32bits if off_t is not 64bits.

In Ubuntu builds, only the first original patch was ever used. The
other iterations happened in debian unstable and I encountered them
while starting a new merge from debian for the kinetic cycle.

So far, only adsys is failing to build:

# github.com/ubuntu/adsys/vendor/github.com/mvo5/libsmbclient-go
In file included from
src/github.com/ubuntu/adsys/vendor/github.com/mvo5/libsmbclient-go/libsmbclient.go:17:
/usr/include/samba-4.0/libsmbclient.h:84:13: error: size of array
'smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS' is too large
   84 | typedef int
smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS[sizeof(off_t)-7];
  | ^~~

I experimented a few things, and this got it building again:
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,10 @@ export DH_GOLANG_INSTALL_ALL := 1
 # Skip integration tests when building package: they need docker images.
 export ADSYS_SKIP_INTEGRATION_TESTS=1

+# be sure to set LFS_CFLAGS if needed, required for libsmbclient on 32bits
+CGO_CFLAGS  := $(shell getconf LFS_CFLAGS)
+export CGO_CFLAGS
+
 %:
dh $@ --buildsystem=golang --with=golang,apport

I'm trying a rebuild of all reverse dependencies of libsmbclient to
see if there are any other failures, but I am wondering if this is the
current approach we want to take, or revert to our old-and-tried patch
that just defines it for all apps including libsmbclient.h?



1. http://bugs.debian.org/221618
2. 
https://git.launchpad.net/ubuntu/+source/samba/tree/debian/patches/bug_221618_precise-64bit-prototype.patch?h=import/2%254.13.2%2bdfsg-1
3. 
https://salsa.debian.org/samba-team/samba/-/blob/b141e7178961404a9f9cca92d04e780c5f504878/debian/patches/libsmbclient-ensure-lfs-221618.patch
4. 
https://salsa.debian.org/samba-team/samba/-/blob/d0d8db5c6d6e8b5e26944031f6786031c1a389ca/debian/patches/libsmbclient-ensure-lfs-221618.patch

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

Re: isc-dhcp: should we start phasing it out?

[Andreas Hasenack]

Hi,

On Mon, May 16, 2022 at 2:34 PM Andreas Hasenack  wrote:

> Removing isc-dhcp would also allow us to reduce the need of old compat
> src:bind9-libs package, probably even drop it.

I just learned that upstream is now bundling the necessary bind9 libs
into the upstream code:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942502#25

Debian just did such an upload, in fact:
https://tracker.debian.org/news/1323159/accepted-isc-dhcp-443-1-source-into-unstable/

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

isc-dhcp: should we start phasing it out?

[Andreas Hasenack]

Hi,

isc-dhcp client[1] is no longer actively maintained upstream. The
server still is, but upstream is clearly favoring the Kea[4] project
for that.

This blog post[2] from 2018, which announced that 4.4.x was going to
be the last series, says:
"""
The 4.4 branch will be supported indefinitely – as long as there is
enough financial support from the user community to cover the costs of
ongoing maintenance.
"""
The download table at [3] still has no EOL date for the 4.1.x (ESV)
and 4.4.x series.

Alternatives that come to mind are:
- kea, of course (from ISC). dhcp server only.
- dnsmasq (for small installations?), also server
- systemd-networkd itself obviously does the client part
- others?

isc-dhcp is such a classic that it is undoubtedly referenced in many
places, so phasing it out might be difficult. On the server, Kea is
not a drop-in replacement.

We also have the udebs, but with subiquity being the installer now we
probably don't need to worry about these anymore?

rdeps at 
https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.kinetic/rdepends/isc-dhcp/

Removing isc-dhcp would also allow us to reduce the need of old compat
src:bind9-libs package, probably even drop it.

Could we perhaps start with phasing out the client, get its rdeps to
use alternatives, and then stop building it, and eventually get to the
server? This could be a lot of work, as I said, isc-dhcp is a classic,
but if upstream is shifting its focus elsewhere, soon we will be
alone.


On current kinetic:
$ reverse-depends isc-dhcp-client
Reverse-Recommends
* avahi-autoipd
* ifupdown [amd64 arm64 armhf ppc64el s390x]
* ifupdown-ng [amd64 arm64 armhf ppc64el s390x]
* madwimax [amd64 arm64 armhf ppc64el s390x]

Reverse-Depends
* cloud-init
* dracut-network
* isc-dhcp-client-ddns [amd64 arm64 armhf ppc64el s390x]
* libguestfs0 [amd64 arm64 armhf ppc64el s390x]
* netscript-2.4
* network-manager [amd64 arm64 armhf ppc64el s390x]
* ubuntu-minimal [amd64 arm64 armhf ppc64el s390x]
* walinuxagent [amd64 arm64]
* whereami

$ reverse-depends isc-dhcp-server
Reverse-Recommends
* fai-server

Reverse-Depends
* fai-quickstart
* isc-dhcp-server-ldap [amd64 arm64 armhf ppc64el s390x]


1. https://www.isc.org/blogs/dhcp-client-relay-eom/
2. https://www.isc.org/blogs/isc-dhcp-the-last-branch/
3. https://www.isc.org/dhcp/
4. https://www.isc.org/kea/

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

Re: Log-rotation doesn't work for catalina.out in src:tomcat9 as intended

[Andreas Hasenack]

Hi,

On Thu, May 12, 2022 at 10:53 AM Utkarsh Gupta
 wrote:
>
> Hi Andreas,
>
> On Thu, May 12, 2022 at 6:17 PM Andreas Hasenack  
> wrote:
> > This reminded me that frr is also affected by this:
> > https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1958162
> >
> > And frr is in main now. I'll work on it.
>
> Ah. D'you think there could be somewhat of a common solution here?
> Or are each of them going to be very different from each other?

I don't know yet :)

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

Re: Log-rotation doesn't work for catalina.out in src:tomcat9 as intended

[Andreas Hasenack]

Hi,

On Tue, May 10, 2022 at 5:07 AM Evren Yurtesen  wrote:
>
> Hi Robie and Utkarsh,
>
>
> This issue is not isolated to tomcat9 package. For example, jetty9 package 
> logging does not work. Rsyslog says:

This reminded me that frr is also affected by this:

https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1958162

And frr is in main now. I'll work on it.

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

Sending LTO delta to Debian

[Andreas Hasenack]

Hi,

this came up again in a review, and I wanted to ask a broader audience.

How to we send LTO[1] related delta to Debian, given that Debian isn't
using LTO (yet)?

Case in point was the ust package[2], which has this bit[3] part of
the delta (just showing the first hunk):
@@ -1,5 +1,5 @@
 liblttng-ust-python-agent.so.1 liblttng-ust-python-agent1 #MINVER#
 * Build-Depends-Package: liblttng-ust-dev
- __start_lttng_ust_tracepoints_ptrs@Base 2.13.0
- __stop_lttng_ust_tracepoints_ptrs@Base 2.13.0
+ (optional=lto)__start_lttng_ust_tracepoints_ptrs@Base 2.13.0
+ (optional=lto)__stop_lttng_ust_tracepoints_ptrs@Base 2.13.0

Is this upstreamable to Debian as is? I know this depends most of the
time on the maintainer, but in general what would be our arguments?
Does it change the behavior of package building when lto is not used?
In a non-lto case, would the disappearance of those symbols be caught?

1. https://wiki.ubuntu.com/ToolChain/LTO
2. https://launchpad.net/ubuntu/+source/ust
3. 
https://git.launchpad.net/ubuntu/+source/ust/commit/?id=438c8ae30797d92cacc9d0e041a92583fbd5f09d

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

Re: Missiing bacula-fd for 9.6.7-3 Ubuntu 2204

[Andreas Hasenack]

It was later fixed in debian, and I synced it for ubuntu kinetic, but
it's indeed missing from jammy:

https://launchpad.net/ubuntu/+source/bacula

I suppose an SRU could reintroduce it? Any volunteers?

On Tue, May 3, 2022 at 10:41 PM Alex Murray  wrote:
>
> On Tue, 2022-05-03 at 10:48:21 -0400, Ken Mandelberg wrote:
>
> > All the other packages for bacula (director, sd) are available but not
> > bacula-fd. bacula cannot run without it.
>
> It seems it was removed during the jammy development cycle as it failed
> to build from source:
> https://launchpad.net/ubuntu/+source/bacula/+publishinghistory
>
> >
> >
> > --
> > Ubuntu-devel-discuss mailing list
> > Ubuntu-devel-discuss@lists.ubuntu.com
> > Modify settings or unsubscribe at: 
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

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

+1 maintenance report, 25 through 29/may/2022

[Andreas Hasenack]

Hi,

this was a slow week, due to the post-release freeze still in effect.
I grabbed these packages to work on:

## nmap ftbfs
Submitted to debian via
https://salsa.debian.org/pkg-security-team/nmap/-/merge_requests/3

And also uploaded the same fix to ubuntu. Once debian does a new
upload, I'll sync it back.

## mariadb-10.6

filed bug: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634

https://launchpad.net/ubuntu/+source/mariadb-10.6/1:10.6.7-3/+build/23488405
[Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try
larger memory locked limit, ulimit -l, or
https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under
systemd (262144 bytes required)

Turns out it was LTO related. MP:
https://code.launchpad.net/~ahasenack/ubuntu/+source/mariadb-10.6/+git/mariadb-10.6/+merge/420845

Package migrated already. I'll likely do an SRU for jammy.

Emailed ubuntu-devel about the LDFLAGS leak in krb5:
https://lists.ubuntu.com/archives/ubuntu-devel/2022-April/042013.html

Also filed bug: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1970979
Emailed upstream krbdev@
https://mailman.mit.edu/pipermail/krbdev/2022-April/013543.html


## bacula

sync, new version from debian fixes the ftbfs that removed it from jammy

Community surprised by the removal:
https://lists.ubuntu.com/archives/ubuntu-users/2022-April/307298.html

Even though it builds, there might be issues still:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009012

## sendmail
8.17.x has some openssl3 support, and pkg/debian/experimental builds
fine in ubuntu. This is a merge candidate, even though it's from
experimental.

I filed https://bugs.launchpad.net/ubuntu/+source/sendmail/+bug/1970472

If there is an openssl-3-issues tag, it can be applied to the bug.

## source-highlight

Rebuilt with new boost/icu, this will fix my mariadb ftbfs in kinetic
(and it did).

## node-configurable-http-proxy

Continuing on the bug that Bryce files during his +1 maintenance
(https://bugs.launchpad.net/ubuntu/+source/node-configurable-http-proxy/+bug/1967024),
sorting out the proxy test that fails during build.

I thought I nailed it, but I did only a local test. Turns out the LP
env is still a bit different, and it looks like the DNS servers there
have rebinding protection enabled, so the test still fails. I'll find
another way.

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

Re: I disabled lto, but it comes back in via -config --libs

[Andreas Hasenack]

Hi,


On Fri, Apr 29, 2022 at 10:50 PM Steve Langasek
 wrote:

> I think your main question has been addressed.  But I want to ask, why is it a
> problem to have part of this code with LTO enabled?  Generally we disable
> LTO only when it is causing build failures.  Was that the case here?

I don't think it's related to *part* of the build using LTO, and the
rest not. That was just an observation I made when I saw that
krb5-config --libs was also exporting lto flags, and I filed [4] for
it.

What prompted disabling lto is that mariadb was crashing[1] when it
couldn't initialize the io_uring queue due to a low RLIMIT_MEMLOCK
value we have by default. That baffled upstream, as the code should be
treating that exception[5], but instead we get an abort. They
investigated[2]  and suspected lto was to blame. I tried a build
without lto, and it worked.

Two things out of this, at least:
- why wasn't the exception caught when lto was enabled? gcc bug,
mariadb bug, or something else?
- should we bump our RLIMIT_MEMLOCK value from 64kbytes to something
higher? There is an upstream commit[3] in systemd to bump it to 8Mb. I
added a systemd task to the bug[1] about this

1. https://launchpad.net/bugs/1970634
2. https://jira.mariadb.org/browse/MDEV-25633
3. https://github.com/systemd/systemd/commit/852b62507b2
4. https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1970979
5. 
https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/comments/7

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

Re: I disabled lto, but it comes back in via -config --libs

[Andreas Hasenack]

Hi Sergio, thanks for the reply

On Fri, Apr 29, 2022 at 3:14 PM Sergio Durigan Junior
 wrote:
> Either way, I believe this issue should be addressed in krb5 as I said
> above.  I haven't been able to find any bug about this in upstream's bug
> tracker.

I filed https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1970979
and also subscribed and emailed the upstream krbdev@ mailing list, but
I think it may be subscription-moderated. If my message doesn't show
up over the weekend, I'll file a bug in their bugtracker.

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

Re: I disabled lto, but it comes back in via -config --libs

[Andreas Hasenack]

Same thing with -Wl,-Bsymbolic-functions:

https://lists.ubuntu.com/archives/ubuntu-devel/2018-June/040371.html

On Fri, Apr 29, 2022 at 10:50 AM Andreas Hasenack  wrote:
>
> Hi,
>
> I disabled lto in a build according to the instructions from [1]:
>
> export DEB_BUILD_MAINT_OPTIONS=optimize=-lto
>
> But I saw that it was still present in some steps of the build.
> Notably when krb5/gssapi was used:
> ...
> -- Found GSSAPI: -L/usr/lib/x86_64-linux-gnu/mit-krb5
> -Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto
> -Wl,-z,relro -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
> ...
> /usr/bin/cc -fPIC -g -O2
> -ffile-prefix-map=/home/ubuntu/git/packages/mariadb/mariadb-10.6=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC
> -fstack-protector --param=ssp-buffer-size=4 -Wunused -Wlogical-op
> -Wno-uninitialized -Wall -Wextra -Wformat-security -Wno-init-self
> -Wwrite-strings -Wshift-count-overflow -Wdeclaration-after-statement
> -Wno-undef -Wno-unknown-pragmas -O2 -g -static-libgcc
> -fno-omit-frame-pointer -fno-strict-aliasing  -Wno-uninitialized
> -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
> -Wdeclaration-after-statement -Wextra -Wformat-security
> -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare
> -Wno-unused-parameter -Wvla -Wwrite-strings -DDBUG_OFF
> -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,relro,-z,now -shared  -o
> auth_gssapi_client.so
> CMakeFiles/auth_gssapi_client.dir/plugins/auth/auth_gssapi_client.c.o
> CMakeFiles/auth_gssapi_client.dir/plugins/auth/gssapi_client.c.o
> CMakeFiles/auth_gssapi_client.dir/plugins/auth/gssapi_errmsg.c.o
> -L/usr/lib/x86_64-linux-gnu/mit-krb5 -Wl,-Bsymbolic-functions
> -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -lgssapi_krb5
> -lkrb5 -lk5crypto -lcom_err
>
> Indeed in this case it comes from kerberos/gssapi:
>
> $ krb5-config --libs gssapi
> -L/usr/lib/x86_64-linux-gnu/mit-krb5 -Wl,-Bsymbolic-functions
> -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -lgssapi_krb5
> -lkrb5 -lk5crypto -lcom_err
>
> That sounds bad. It means only portions of the build will have lto
> disabled, while others will flip it back on. How to sort this out?
> Looks like the krb5 package needs some fixing, but I'm unsure how.
>
>
> 1. https://wiki.ubuntu.com/ToolChain/LTO

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

I disabled lto, but it comes back in via -config --libs

[Andreas Hasenack]

Hi,

I disabled lto in a build according to the instructions from [1]:

export DEB_BUILD_MAINT_OPTIONS=optimize=-lto

But I saw that it was still present in some steps of the build.
Notably when krb5/gssapi was used:
...
-- Found GSSAPI: -L/usr/lib/x86_64-linux-gnu/mit-krb5
-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto
-Wl,-z,relro -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
...
/usr/bin/cc -fPIC -g -O2
-ffile-prefix-map=/home/ubuntu/git/packages/mariadb/mariadb-10.6=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC
-fstack-protector --param=ssp-buffer-size=4 -Wunused -Wlogical-op
-Wno-uninitialized -Wall -Wextra -Wformat-security -Wno-init-self
-Wwrite-strings -Wshift-count-overflow -Wdeclaration-after-statement
-Wno-undef -Wno-unknown-pragmas -O2 -g -static-libgcc
-fno-omit-frame-pointer -fno-strict-aliasing  -Wno-uninitialized
-fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
-Wdeclaration-after-statement -Wextra -Wformat-security
-Wno-format-truncation -Wno-init-self -Wno-nonnull-compare
-Wno-unused-parameter -Wvla -Wwrite-strings -DDBUG_OFF
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,relro,-z,now -shared  -o
auth_gssapi_client.so
CMakeFiles/auth_gssapi_client.dir/plugins/auth/auth_gssapi_client.c.o
CMakeFiles/auth_gssapi_client.dir/plugins/auth/gssapi_client.c.o
CMakeFiles/auth_gssapi_client.dir/plugins/auth/gssapi_errmsg.c.o
-L/usr/lib/x86_64-linux-gnu/mit-krb5 -Wl,-Bsymbolic-functions
-flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -lgssapi_krb5
-lkrb5 -lk5crypto -lcom_err

Indeed in this case it comes from kerberos/gssapi:

$ krb5-config --libs gssapi
-L/usr/lib/x86_64-linux-gnu/mit-krb5 -Wl,-Bsymbolic-functions
-flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -lgssapi_krb5
-lkrb5 -lk5crypto -lcom_err

That sounds bad. It means only portions of the build will have lto
disabled, while others will flip it back on. How to sort this out?
Looks like the krb5 package needs some fixing, but I'm unsure how.


1. https://wiki.ubuntu.com/ToolChain/LTO

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

Re: Call for votes: Developer Membership Board restaffing

[Andreas Hasenack]

Hi,

On Tue, Mar 29, 2022 at 11:15 AM Dan Streetman  wrote:
>
> On Tue, Mar 29, 2022 at 9:45 AM Robie Basak  wrote:
> >
> > On Tue, Mar 29, 2022 at 09:19:31AM -0400, Dan Streetman wrote:
> > > For example, in this situation; carrying out an election really
> > > shouldn't be an exceptional event.
> >
> > Normally it isn't. Previous elections have run smoothly and with no
> > issues that I'm aware of.
> >
> > However we now have an interaction between the following exceptional
> > situations, none of which were predicted:
> >
> > 1) The sudden apparent inability to send out announcements in the usual
> > way.
> >
> > 2) The sudden (for us) change in CIVS to require email pre-approval.
> >
> > 3) Our existing email-gathering system means that people now don't
> > necessarily know their own ballot email alias and figuring that out is
> > particularly difficult.
> >
> > This is exceptional and requires exceptional consideration. Nothing we
> > might have had in rules or policies previously could reasonably have
> > predicted this.
> >
> > You seem to be suggesting that the current situation demonstrates that
> > the existing documentation, process or policy around running a DMB
> > election is somehow inadequate. But since this exceptional situation
> > couldn't reasonably have been accommodated in hindsight, I don't think
> > this is the case.
> >
> > > My feedback would be that this election should stick to the process
> > > already in place at the start of the election. There should be no
> > > changes to the process while the election is ongoing. If you think the
> > > election process should change, that should be discussed, agreed on,
> > > and documented. Then the next election can use the new process.
> >
> > Thank you for your feedback.
> >
> > > Can you imagine if a government decided to change the election process
> > > during an election?
> >
> > For a fair comparison, you'd have to imagine what would happen if during
> > a government election it turned out that most of the electorate found
> > themselves unable to receive a ballot and therefore couldn't vote.
>
> Do you have evidence that has actually happened to anyone in this
> case? I was able to vote quite easily, and it seems (from your ML
> comments) that both Christian and yourself were as well, and Christian
> provided explicit steps earlier in this email thread.

I wasn't able to vote. I tried a few different emails and the system
wouldn't recognize any, and I gave up on that day and forgot about it,
until this thread was woken up. Of course, the one email I didn't try
was the correct one, but having to pick an email, request a token,
wait, use token, and then nothing, was too cumbersome that day and I
gave up after 3 attempts.

Today I talked with Robie, and he told me the correct email to use,
and I was able to vote.

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

Re: Second Jammy Jellyfish test rebuild

[Andreas Hasenack]

On Tue, Mar 29, 2022 at 8:02 AM Graham Inggs  wrote:
>
> Hi Christian
>
> On Tue, 29 Mar 2022 at 08:19, Christian Ehrhardt
>  wrote:
> > - Dns-root-data is actually an issue in ldns fixed in jammy-proposed
> ldns migrated, so I retried dns-root-data
>
> > - postgresql-14 was broken by llvm-14, a fix is uploaded to jammy and
> > built fine (https://launchpad.net/bugs/1966319)
> llvm-toolchain-14 migrated, so I retried postgresql-14

https://launchpad.net/ubuntu/+source/postgresql-14/14.2-1ubuntu1 in
proposed fixes the FTBFS with llvm 14.

>
> > - python-tempita was broken by python-3.10, not yet fixed but we know a way
> not doing anything here yet

https://launchpad.net/ubuntu/+source/python-tempita/0.5.2-6ubuntu1 is
in proposed and fixes the FTBFS (and enables tests, that were not
running before)

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

default LLVM change

[Andreas Hasenack]

Hi,

I was going over fixing the postgresql FTBFS[1] reported[2] in this
list a few days ago, and saw that the failure was due to postgresql
not yet supporting llvm-14. Current jammy build was using llvm-13.

Ok, so looks like llvm-defaults changed from 13 to 14 with
0.51ubuntu1[3] on March 12th (wasn't that after FF?)

Christian found a patchset, which I applied and uploaded, but to my
surprise llvm-14, even though it's the default in jammy, is in
universe[4]. UPDATE: was in universe, looks like Doko just moved it
into main a few hours ago.

The end results now, with the above update, is that we will have
postgresql-14 switching from llvm13 to llvm14 one day before beta
freeze. Release team, should I revert the postgresql change and adjust
build-depends so it picks llvm-13?


1. 
https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220317-jammy-jammy.html
2. https://lists.ubuntu.com/archives/ubuntu-devel/2022-March/041957.html
3. https://launchpad.net/ubuntu/+source/llvm-defaults/0.54ubuntu1
4. https://launchpad.net/ubuntu/+source/llvm-toolchain-14

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

Re: Should we change the behaviour of -P for lsblk in util-linux for Jammy?

[Andreas Hasenack]

Hi,

On Fri, Feb 18, 2022 at 2:18 AM Bryce Harrington
 wrote:
>
> On Thu, Feb 17, 2022 at 01:00:07PM +1300, Matthew Ruffell wrote:
> > 3) Revert the single patch which caused all of this,
> > 58b510e580 libsmartcols: sanitize variable names on export output
> > which is a tidier and well tested solution, and drop the patch when 
> > util-linux
> > is rebased to 2.38 in KK. This keeps existing behaviour in Focal/Impish, and
> > enables older MAAS and Curtin to keep working.
> >
> > I'm leaning toward suggesting 3) at this stage, but this is mostly to keep
> > existing users happy on their older versions of MAAS.
>
> I think your hunch for #3 does sound like the safer approach to me as
> well.  Unless there's a huge number of users asking for the new feature,
> those who do need it can either wait until it's generally available, or
> use a workaround with some awk filters or whatnot.

I'd also prefer (3). And the new option for shell compatible output
could always be attempted as an SRU in the future if it's deemed
important enough.

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

Re: MIR question: upstream code in main pulled in code we have in universe

[Andreas Hasenack]

Hi,

On Fri, Feb 11, 2022 at 1:33 PM Steve Langasek
 wrote:
>
> On Fri, Feb 11, 2022 at 11:35:07AM -0300, Andreas Hasenack wrote:
> > Hi, I have a question for the MIR (Main Inclusion Request) team members,
>
> > New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in
> > code (regex.c file) from another upstream project[2], for which we
> > have a package in universe: src:libnfsidmap-regex
>
> > Would this require another MIR review? I mean, in general, once a
> > package is in main, we don't apply the MIR guidelines to it anymore,
> > and they can usually change the code as the project sees fit.
> > It just so happens this time we have this exact scenario where the
> > code that was pulled already exists and is the sole purpose of
> > another, universe, package.
>
> > My options are basically:
> > a) have src:nfs-utils build bin:libnfsidmap-regex and remove
> > src:libnfsidmap-regex from the archive
> > b) build src:nfs-utils without producing bin:libnfsidmap-regex, and
> > keep building src:libnfsidmap-regex from universe as usual
>
> > Option (b) will incurr in delta with debian. I believe[3] Debian will
> > eventually remove/obsolete src:libnfsidmap-regex
>
> > 1. 
> > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
> > 2. https://github.com/isginf/libnfsidmap-regex
> > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20
>
> I think you should submit it for an additional MIR review if and only if
> there is reason to consider the new library security-sensitive.  (If it's a
> library that will be used by one of the NFS daemons, that's a good reason to
> think it's security-sensitive.)

Yeah, it's an libnfsidmap plugin that applies regular expressions to
NFSv4 usernames and group names that come over the wire in the form
user@DOMAIN and group@DOMAIN.

What if I keep bin:libnfsidmap-regex, built from the new
src:nfs-utils, in universe? With a remark in d/control that it should
not be promoted to main without a specific new MIR?

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

MIR question: upstream code in main pulled in code we have in universe

[Andreas Hasenack]

Hi, I have a question for the MIR (Main Inclusion Request) team members,

New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in
code (regex.c file) from another upstream project[2], for which we
have a package in universe: src:libnfsidmap-regex

Would this require another MIR review? I mean, in general, once a
package is in main, we don't apply the MIR guidelines to it anymore,
and they can usually change the code as the project sees fit.
It just so happens this time we have this exact scenario where the
code that was pulled already exists and is the sole purpose of
another, universe, package.

My options are basically:
a) have src:nfs-utils build bin:libnfsidmap-regex and remove
src:libnfsidmap-regex from the archive
b) build src:nfs-utils without producing bin:libnfsidmap-regex, and
keep building src:libnfsidmap-regex from universe as usual

Option (b) will incurr in delta with debian. I believe[3] Debian will
eventually remove/obsolete src:libnfsidmap-regex

1. 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
2. https://github.com/isginf/libnfsidmap-regex
3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20

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

nfs-utils update status

[Andreas Hasenack]

Hi,

I just wrote a lengthy email to a debian bug
(https://bugs.debian.org/1005236) and thought I should share it here
too. CCing ubuntu-devel@ since this is not an Ubuntu Server package.

This is the current situation with nfs-utils regarding LP bug
#1878601[1]. I guess the most important part is how to handle the
migration of /etc/default/nfs-* to /etc/nfs.conf, and changes in
general, considering the next ubuntu release is an LTS. Details in the
text below.

"""
I've been looking at the exp package lately, since I'm trying to
update[1] the ubuntu nfs-utils package as well, which we neglected for
many releases.

There are upstream changes, and packaging changes, and a question on
how to handle upgrades.

src:libnfsidmap and src:libnfsidmap-regex were pulled[2][3] into
upstream's nfs-utils (in 2017 and 2020, respectively), which deprecate
those source packages in debian and ubuntu. libnfsidmap actually
forked, and got some new features like LDAP_tls_reqcert config
support[4] and SASL binds[5] in its new home in nfs-utils, for
example, besides plenty of fixes.

Upstream's most visible change is probably the configuration. Instead
of a complicated mechanism to source different configuration files
(/etc/sysconfig in RH, /etc/default/nfs-* in debian/ubuntu), and then
adjust command-line options to all the different daemons, upstream now
changed the daemons themselves to read a new /etc/nfs.conf ini-style
config file[6]. Fedora has a python conversion script[7] that they use
as a one-shot systemd service unit[8]. I played[9] with it a little
and we can easily make it work with debian/ubuntu, and that opens up
some paths for us to handle the migration.

Maybe the only reason to keep the /etc/default/nfs-* files is for sysv
initscripts, to be able to run or not a particular service
(NEED_=yes|no), if that's still an objective. For systemd, it
will be the usual systemctl enable/disable/mark/unmask.

The old nfs-config.service unit is gone, since there is no need to
generate an aggregated config file for the different systemd units to
source and adjust command line options.

The old libnfsidmap2 package unfortunately has an incorrect major
number, it should have been libnfsidmap0 (the library it carries is
.so.0.3.0 and has a soname of 0). Maybe there is some history behind
this. That creates the odd situation now with the new one, which is
libnfsidmap1. Reminds me of the pcre2/pcre3 situation, where pcre2 is
newer.

There is a new service, nfsdcld, a client tracking daemon, used in
NFSv4. It's just an upgrade from what was called "legacy tracking" in
old kernels, then got replaced by "nfsdcltrack", but that one isn't
container-friendly, and now we have nfsdcld.

NFS, as usual, has many intertwined services, and I'm just happy that
all the systemd units seem to have correct declarations and that it
"just works", so far at least in my testing. But corner cases are for
sure there somewhere. I tested one, where nfs was exporting an iscsi
mounted filesystem, and in older versions that would hang the boot of
the server, but that worked, phew. That sounded exactly like a "corner
case".

Finally, the reverse dependencies need to be rebuilt and checked that
they still work. In Ubuntu, that's nfs-ganesha and sssd, and they at
least build, I haven't checked Debian.

So, my summary:
- it's my opinion that debian and ubuntu need the new version sooner
rather than later. I'm actively working on bringing it into ubuntu,
based on the exp package from debian. My branch is currently at [10],
with a PPA at [11]. The delta we had was basically zeroed, due to a
combination of upstream changes and debian changes.
- we need a plan for an upgrade path. Some choices:
  - do nothing but release notes
  - detect if /etc/default/nfs-* have changes, and warn in that case,
asking the user to move the changes over to /etc/nfs.conf
  - to help with above, also ship fedora's script and let the user
know it exists and could be used. Maybe even run it and place the
output somewhere temporary for analysis
  - actually run fedora's conversion script in postinst, and let the
user know it was done and ask them to double check
- old source packages (src:libnfsidmap and src:libnfsidmap-regex) need
to be removed/obsoleted. I think it's safe to say upstream libnfsidmap
is gone, but libnfsidmap-regex still seems active. We *could* just not
build nfs-utils's regex plugin, and use src:libnfsidmap-regex, but the
libnfsidmap history has shown that at least in that case, nfs-utils'
implementation has diverged over time.

Cheers!


1. https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1878601
2. 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=1ea6d9231f839b968adb44eaf98b363f436cb1d5
3. 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
4. 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=d77ee0f18c0e0658f892932600c38c346c4d5337
5. 

+1 maintenance report: 31/JAN - 04/FEV

[Andreas Hasenack]

Hi all,

I worked mostly on the python3-default blockers.

# fetchmail
Just needed a retrigger

# stunnel4
- DeprecationWarning: ssl.PROTOCOL_TLS is deprecated
- FTBFS + DEP8 failures
Fixed via https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1959615
Sent to debian via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004695

# ansible
- NOT SOLVED
- when built on jammy, the package fails to install due to a broken
symlink included in the build:
$ sudo py3compile -p ansible
[Errno 2] No such file or directory:
'/usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py'

# broken symlink
$ ls -la 
./debian/ansible/usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py
lrwxrwxrwx 1 ubuntu ubuntu 13 Feb  1 20:29
./debian/ansible/usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py
-> ../release.py

The 3.9 symlink is fine:
$ dpkg -L ansible|grep ansible_release\\.py
/usr/lib/python3/dist-packages/ansible/module_utils/ansible_release.py
/usr/lib/python3.10/dist-packages/ansible/module_utils/ansible_release.py

- I have patches for the test issues, hopefully, in
https://code.launchpad.net/~ahasenack/ubuntu/+source/ansible/+git/ansible/+ref/jammy-ansible-dep8,
but couldn't test them due to the above issue.

# python-fysom
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004913
  https://salsa.debian.org/debian/python-fysom/-/merge_requests/2
  https://bugs.launchpad.net/ubuntu/+source/python-fysom/+bug/1959907
  
https://code.launchpad.net/~ahasenack/ubuntu/+source/python-fysom/+git/python-fysom/+merge/415043
uploaded

# python-furl
- actually in python3-orderedmultidict
- fix in https://github.com/gruns/orderedmultidict/pull/20
- fixed in 1.0.1 (deb/ubu have 1.0)
- orderedmultidict uploaded

# python-opcua
https://bugs.launchpad.net/ubuntu/+source/python-opcua/+bug/1959935
https://github.com/FreeOpcUa/python-opcua/pull/1075
https://bugs.debian.org/1004937
https://salsa.debian.org/python-team/packages/python-opcua/-/merge_requests/2
uploaded


# pythonpy
https://bugs.launchpad.net/ubuntu/+source/pythonpy/+bug/1878935
upstream is gone
debian last upload from 2016, no current vcs (link in d/control is 404)
https://bugs.debian.org/1004971
https://code.launchpad.net/~ahasenack/ubuntu/+source/pythonpy/+git/pythonpy/+merge/415105
uploaded

# sepp
https://bugs.launchpad.net/ubuntu/+source/sepp/+bug/1959938
https://github.com/smirarab/sepp/issues/117
https://salsa.debian.org/med-team/sepp/-/merge_requests/1
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004968
Debian took the fix, force-synced

# keras
Fixed the python 3.10 collections import part, but the rest is too old
and upstream moved on. It doesn't build anymore due to failing tests.
We and debian have 2.3.1, from Oct 07, 2019, and upstream is at 2.8.0.
I didn't locate any further development in the 2.3.x series.
https://bugs.launchpad.net/ubuntu/+source/keras/+bug/1959918 (with the
py310 import fix)
There is an RC bug in debian, kind of related:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997068
Note: this package takes hours to build, the tests run for a very long time.
Here is a recent build log, with the collections patch applied:
https://launchpad.net/~ahasenack/+archive/ubuntu/py310-collections/+build/23129048/+files/buildlog_ubuntu-jammy-amd64.keras_2.3.1+dfsg-3ubuntu1~ppa2_BUILDING.txt.gz

# lazygal:
https://bugs.launchpad.net/ubuntu/+source/lazygal/+bug/1959932
dep8 stderr deprecation warning about distutils
https://github.com/niol/lazygal/issues/14
bug class: retry-autopkgtest-regressions --blocks python3-defaults
--log-regex 'DeprecationWarning: The distutils package is deprecated'
The "Deprecate distutils module" PEP: https://www.python.org/dev/peps/pep-0632/
Porting to setuptools guide:
https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html
https://code.launchpad.net/~ahasenack/ubuntu/+source/lazygal/+git/lazygal/+merge/415141
to add allow-stderr
uploaded

# mando
https://bugs.launchpad.net/ubuntu/+source/mando/+bug/1960133
collections + help output issue
Salsa PR: https://salsa.debian.org/python-team/packages/mando/-/merge_requests/2
Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005015
https://code.launchpad.net/~ahasenack/ubuntu/+source/mando/+git/mando/+merge/415154
uploaded


# pyx3
https://github.com/pyx-project/pyx/pull/35
https://bugs.launchpad.net/ubuntu/+source/pyx3/+bug/1960092
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005028
https://salsa.debian.org/debian/pyx3/-/merge_requests/3
https://code.launchpad.net/~ahasenack/ubuntu/+source/pyx3/+git/pyx3/+merge/415156
uploaded

# booth
retrigger with current crmsh 4.3.1-1ubuntu1, which has the python 3.10
collections import fix

# resfinder
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005030
https://bitbucket.org/genomicepidemiology/resfinder/issues/70/
https://bugs.launchpad.net/ubuntu/+source/resfinder/+bug/1960146

Re: A class of errors due to python 3.10: collections import

[Andreas Hasenack]

On Thu, Feb 3, 2022 at 3:38 PM Andreas Hasenack  wrote:
>
> In general:
>
> change
>
>   from collections import 
>
> to
>
>   from collections.abc import 
>
>
> This will list the culprits:
> retry-autopkgtest-regressions --blocks python3-defaults --log-regex
> 'ImportError: cannot import name.*collections'
>
> keras
> python-furl
> python-opcua
> python-orderedmultidict
> pythonpy
> pyvo
> sepp
>

A few more:
booth
mando
oz
python-pgpy
resfinder

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

+1maint: another class of py3.10 issues: "distutils is deprecated"

[Andreas Hasenack]

retry-autopkgtest-regressions --blocks python3-defaults --log-regex
'DeprecationWarning: The distutils package is deprecated'

Which gives:
ansible
hy
lazygal
oz
pytest-mpi
q2-fragment-insertion
q2-sample-classifier
typer
unicycler
zope.testing

I'm currently on lazygal.

These links might be useful when filing upstream bugs:
The "Deprecate distutils module" PEP: https://www.python.org/dev/peps/pep-0632/
Porting to setuptools guide:
https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html

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

A class of errors due to python 3.10: collections import

[Andreas Hasenack]

In general:

change

  from collections import 

to

  from collections.abc import 


This will list the culprits:
retry-autopkgtest-regressions --blocks python3-defaults --log-regex
'ImportError: cannot import name.*collections'

keras
python-furl
python-opcua
python-orderedmultidict
pythonpy
pyvo
sepp

I'm working on python-furl, python-orderedmultidict and python-fysom
(why isn't it in the list...? Hmm)

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

Quagga removal, welcome frr

[Andreas Hasenack]

Hi all,

quagga was removed[1] from Debian, and is unmaintained upstream. I'm
working on a MIR[1] for frr which is a fork from quagga and replaces
it.

I don't know yet if it's a 100% drop-in replacement, and wanted to ask
others at large how they would be impacted by the removal of quagga
from Ubuntu.

The intent is to remove quagga from Ubuntu as well, and replace it with frr.



1. https://tracker.debian.org/news/1281917/removed-124-4-from-unstable/
2. https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1951834

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

ust: mini transition

[Andreas Hasenack]

Hi,

while following up on the migration[1] of my glusterfs upload, I
spotted liburcu[2] which led me to ltt-control[3] which isn't building
because of a missing dependency[4]:

Missing build dependencies: liblttng-ust-dev (>= 2.13.0~)

I then went ahead and tried to update ust to 2.13.0, via a merge from
debian, found an FTBFS[5], and am ready to upload the fix after a
review.

But since that ust 2.13.0 has a soname bump, it will trigger a mini
transition. I haven't checked all rdeps yet, and will use a PPA for
that, but wanted to give a heads up here in case someone else was
working on it, or has some reason why we shouldn't bump the soname
just yet, or ever.

Cheers


1. 
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glusterfs
2. 
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#liburcu
3. 
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ltt-control
4. https://launchpad.net/ubuntu/+source/ltt-control/2.13.1-1/+build/22365825
5. https://bugs.launchpad.net/lttng-ust/+bug/1953065

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

Re: git-ubuntu rich history beta

[Andreas Hasenack]

Hi Dan,

On Mon, Nov 8, 2021 at 7:42 PM Dan Streetman  wrote:
>
> On Wed, Oct 13, 2021 at 12:52 PM Robie Basak  wrote:
> >
> > git-ubuntu is now able to accept rich history directly from any uploader.
> >
> > The CLI is in beta and subject to change. Feedback appreciated!
> >
> > # Summary
> >
> > sudo snap refresh --beta git-ubuntu  # beta channel snap required
>
> sorry to bring this up.
>
> I recently reinstalled my system (hardware upgrades) and I have
> completely removed snap, and I don't plan to reinstall it or use any
> snaps in the future. Is there any place I can get 'git-ubuntu' without
> using snaps?

I don't think there are debs available, but the code is here:

https://code.launchpad.net/usd-importer

This should work, for example:

python3 ./setup.py install --install-layout=deb --root=/tmp/git-ubuntu

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

Re: OpenLDAP 2.5 transition plan

[Andreas Hasenack]

Great!

Please take this opportunity of a soname change to drop some of our old
delta ;)


On Thu, May 20, 2021 at 12:25 PM Sergio Durigan Junior 
wrote:

> Hi folks,
>
> I have been working on getting OpenLDAP 2.5 ready to start the
> transition process in impish.  Ryan Tandy (Debian's OpenLDAP maintainer)
> has been very, very kind and helping me drive this process forward.
>
> I am currently working on solving the remaining FTBFSes (from packages
> that link against libldap) and will then start running and checking the
> results of all autopkgtests involved in this transition.
>
> I am not expecting many problems to arise due to the soname bump itself
> (wine and wine-development have been giving me a bit of a headache due
> to their FTBFSes, but everything seems OK now), but we will certainly
> have "a bit" of work to do in the maintainer scripts to assure a smooth
> upgrade path from 2.4 to 2.5.  Ryan has been working on this for now
> (kudos to him again).
>
> I will keep you posted and will let you know when I update the openldap
> package (which will be sync'ed from Debian experimental once Ryan pushes
> it there).
>
> Thank you,
>
> --
> Sergio
> GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

nfs-common won't restart all services after upgrade

[Andreas Hasenack]

Hi,

tl;dr

I filed https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928259
found while testing
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745 and
verifying that rpc.gssd was not restarted after a package upgrade. Which
means the fix wasn't available until the service was restarted manually.


# Troubleshooting story

I was testing
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745, and while
the fix is correct, it didn't always "stick" after I upgraded the packages.

Further troubleshooting showed that some of the NFS services are not
restarted after a package upgrade, under a specific condition which took a
while to figure out.

Many services make up a NFS server or client, so sometime ago debian
decided to wrap them all around a systemd service called nfs-utils.service,
which is a bit fake, used just to coordinate all the real services. Its
header explains it:
$ systemctl cat nfs-utils.service
# /lib/systemd/system/nfs-utils.service
[Unit]
Description=NFS server and client services
# This service should never be stopped, only restarted.
# When it is re-started, all other services which declare
# themselves to be "PartOf" this service will also be
# restarted. Thus
#   systemctl restart nfs-utils
# will restart all daemons which are part of nfs-utils
# and which are running.  This is useful after a software
# update.

# This is a "service" rather than "target" so that we
# don't need to say "systemctl restart nfs-utils.target".
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true

d/rules has these, and we can see it does not enable nfs-utils.service, but
asks for it to be restarted on upgrade:
dh_systemd_enable -p nfs-common nfs-client.target

dh_systemd_enable -p nfs-kernel-server nfs-server.service

dh_installinit -pnfs-common -R

dh_systemd_start -p nfs-common --restart-after-upgrade
nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade
nfs-server.service

And this "fake" service really can't be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also,
Alias
settings in the [Install] section, and DefaultInstance for template units).
(...long explanation follows this output ...)

We get this during package install:
Setting up nfs-common (1:1.3.4-2.1ubuntu5.3) ...
nfs-utils.service is a disabled or a static unit not running, not starting
it.

Even when upgrading:
Setting up nfs-common (1:1.3.4-2.1ubuntu5.4) ...
nfs-utils.service is a disabled or a static unit not running, not starting
it.

This is because the service is not enabled.

Critically for the bug I'm fixing, rpc.gssd is not restarted, so the fix
isn't applied :/
Before upgrade:
  442 ?Ss 0:00 /usr/sbin/blkmapd
 7146 ?Ss 0:00 /usr/sbin/rpc.gssd
 7399 ?Ss 0:00 /usr/sbin/rpc.idmapd
 7406 ?Ss 0:00 /usr/sbin/rpc.mountd --manage-gids
 7400 ?Ss 0:00 /usr/sbin/rpc.svcgssd
After pkg upgrade:
  442 ?Ss 0:00 /usr/sbin/blkmapd
 7146 ?Ss 0:00 /usr/sbin/rpc.gssd
 8421 ?Ss 0:00 /usr/sbin/rpc.idmapd
 8422 ?Ss 0:00 /usr/sbin/rpc.mountd --manage-gids
 8420 ?Ss 0:00 /usr/sbin/rpc.svcgssd

If I do a manual "sudo systemctl start nfs-utils.service" (or restart)
before upgrading the package, then all these processes are restarted after
the package upgrade, because deb-systemd-invoke sees nfs-utils.service as
"started". From its code:
# If the job is disabled and is not currently running, the job is not
started or restarted.
# However, if the job is disabled but has been forced into the running
state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced
the start.
# We don't autostart static units either.

I filed https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928259
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988430.

Some ideas I'm considering:
a) just do a systemctl start before the #DEBHELPER# marker, like this:
--- a/debian/nfs-common.postinst
+++ b/debian/nfs-common.postinst
@@ -43,6 +43,10 @@ case "$1" in
if [ -f /lib/init/rw/sendsigs.omit.d/statd ]; then
mv /lib/init/rw/sendsigs.omit.d/statd /run/sendsigs.omit.d/statd
fi
+
+# always "start" nfs-utils.service, so package upgrades will restart
it,
+# see LP: #1928259
+systemctl start nfs-utils.service > /dev/null || true
 ;;
 esac


b) Don't use dh_systemd_* in d/rules for nfs-utils.service, and do my own
handling in d/nfs-common.postinst using systemctl directly, instead of
deb-systemd-invoke, i.e., something like (also untested):
diff --git a/debian/nfs-common.postinst b/debian/nfs-common.postinst
index f709d53..feb375a 100644
--- a/debian/nfs-common.postinst
+++ b/debian/nfs-common.postinst
@@ -43,11 +43,19 @@ case "$1" in
if [ -f /lib/init/rw/sendsigs.omit.d/statd ]; then
mv /lib/init/rw/sendsigs.omit.d/statd 

Re: dpkg -V does not consider path-exclude config, fails on ubuntu-minimal

[Andreas Hasenack]

Hi,

On Fri, Nov 20, 2020 at 1:25 PM Balint Reczey
 wrote:
>
> Hi Andreas,
>
> On Fri, Nov 20, 2020 at 3:29 PM Andreas Hasenack  
> wrote:
> > Shouldn't `dpkg -V` take the path-{exclude,include} into
> > consideration? Is this just a bug (which I can file), or was it a
> > conscious decision?
>
> IMO this is just a dpkg bug, observable on Sid, too.


Thanks, I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975338

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

dpkg -V does not consider path-exclude config, fails on ubuntu-minimal

[Andreas Hasenack]

Hi,

I noticed that `dpkg -V` does not take into consideration potential
exclusions defined in its configuration.

An ubuntu-minimal image, for example, has this:
```
$ cat /etc/dpkg/dpkg.cfg.d/excludes
# Drop all man pages
path-exclude=/usr/share/man/*

# Drop all translations
path-exclude=/usr/share/locale/*/LC_MESSAGES/*.mo

# Drop all documentation ...
path-exclude=/usr/share/doc/*

# ... except copyright files ...
path-include=/usr/share/doc/*/copyright

# ... and Debian changelogs
path-include=/usr/share/doc/*/changelog.Debian.*
```

Which results in a lot of noise when `dpkg -V` is run:
```
$ dpkg -V | head
??5??   /usr/share/doc/python3-pkg-resources/pkg_resources.txt.gz
??5??   /usr/share/doc/fonts-ubuntu-console/README
??5??   /usr/share/doc/cryptsetup-bin/NEWS.Debian.gz
??5??   /usr/share/man/man8/cryptsetup-reencrypt.8.gz
??5??   /usr/share/man/man8/cryptsetup.8.gz
??5??   /usr/share/man/man8/integritysetup.8.gz
??5??   /usr/share/man/man8/veritysetup.8.gz
??5??   /usr/share/doc/python3-distutils/README.Debian
??5??   /usr/share/doc/libip4tc2/NEWS.Debian.gz
??5??   /usr/share/doc/libksba8/AUTHORS
...
```

Shouldn't `dpkg -V` take the path-{exclude,include} into
consideration? Is this just a bug (which I can file), or was it a
conscious decision?

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

Kerberos ccache in /tmp, why not kernel keyring?

[Andreas Hasenack]

Hi,

any idea why debian and ubuntu do not use the kernel keyring as the
default storage for the kerberos credentials cache? We still use files
in /tmp, like /tmp/krb5cc_1000 for a user with uid 1000.

Is it because of heimdal compatibility? Its keyring support was merged
in 2018[1], but doesn't seem to be in a release yet.


1. https://github.com/heimdal/heimdal/issues/166,
https://github.com/heimdal/heimdal/commit/fb81598d447305352cd38095ffac701cc3eed0cf

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

Re: Second Groovy Gorilla test rebuild

[Andreas Hasenack]

Hello,

On Tue, Sep 29, 2020 at 7:29 AM Christian Ehrhardt
 wrote:
> And we are by pushing glibc2.32 late in groovy we are forcing everything that
> is left to resolve the same now. I'm not sure should glibc provide a compat
> path - I assume this was made so that every project has to make a concious
> switch?

Others (I checked Fedora, and I think gentoo did it too) did the
switch years ago (circa 2018). They have a master bug[1] which might
be worth checking if someone is looking for patches.

> Note, in most cases this include path should be covered by libtirpc 
> pkg-config.
> # pkg-config --cflags libtirpc
> -I/usr/include/tirpc
> But e.g. in the case of open-vm-tools that seems not to be propagated to all
> toolchain calls :-/

I briefly tried building squid's NIS auth helper with tirpc when
trying to sort out its ftbfs[2]. It worked, but for reasons outlined
in the bug[2] and the WIP branch[3] which I didn't propose, I decided
to drop the NIS auth helper. Other than some annoying autoconf issues,
it seemed to work just fine, but I didn't have a real NIS domain to
test.

Of note is that the final binary wasn't directly linked with tirpc,
but pulled it in via libnsl.

1. https://bugzilla.redhat.com/show_bug.cgi?id=1531540
2. https://bugs.launchpad.net/ubuntu/+source/squid/+bug/1895694
3. 
https://code.launchpad.net/~ahasenack/ubuntu/+source/squid/+git/squid/+ref/groovy-squid-use-tirpc

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

Re: Bileto and RiscV64

[Andreas Hasenack]

Taking openldap as an example:

amd64 build: ~1h
arm64 build: ~1h30
i386: ~1h
armhf build: ~2h
ppc64el: ~1h
s390x: ~1h
riscv64 build: 8h and still going

No tests have started yet as a result.

On Wed, Aug 26, 2020 at 6:00 PM Andreas Hasenack  wrote:
>
> Hi,
>
> The builders for riscv64 are very slow, and since bileto wails for all
> builds to be ready, each ticket can take dozens of hours. Even if I
> disable that arch in the ppa (via a #webops request), bileto later
> enables it again.
>
> Could we do one of the following:
> - disable riscv64 by default on bileto, and make it so it can be
> enabled (and remain enabled) in the ppa if the user so wants it
> - start bileto tests as soon as an arch build is ready, instead of
> waiting for them all to be ready as it is today
> - something else I haven't thought of :)
>
> I know we want to have packages working on riscv64, but since it's not
> blocking migration in the real archive, it seems unfair that it blocks
> bileto so much.

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

Bileto and RiscV64

[Andreas Hasenack]

Hi,

The builders for riscv64 are very slow, and since bileto wails for all
builds to be ready, each ticket can take dozens of hours. Even if I
disable that arch in the ppa (via a #webops request), bileto later
enables it again.

Could we do one of the following:
- disable riscv64 by default on bileto, and make it so it can be
enabled (and remain enabled) in the ppa if the user so wants it
- start bileto tests as soon as an arch build is ready, instead of
waiting for them all to be ready as it is today
- something else I haven't thought of :)

I know we want to have packages working on riscv64, but since it's not
blocking migration in the real archive, it seems unfair that it blocks
bileto so much.

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

Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations

[Andreas Hasenack]

I just did a do-release-upgrade with slapd from my ppa which exits 1
in slapd.preinst when it detects the nssov in use, and the release
upgrader crashed, giving the option to send a report. Note this test
doesn't have a debconf critical prompt, I don't know if that would
have changed anything.

On Fri, May 22, 2020 at 10:57 AM Andreas Hasenack  wrote:
>
> Hello,
>
> On Fri, May 22, 2020 at 10:45 AM Robie Basak  wrote:
> >
> > On Fri, May 22, 2020 at 02:27:48PM +0100, Robie Basak wrote:
> > >  We implemented a least-worst solution there, involving IIRC a
> > > critical debconf prompt. I don't remember the details, but that might be
> > > relevant.
> >
> > Looks like we made the maintainer scripts exit with a success code, but
> > we always present a debconf critical note first if we haven't been able
> > to complete. IIRC, we thought that this would be better than breaking a
> > release upgrade. I think this is limited to dealing with things already
> > being broken though - for every other type of problem we do exit
> > non-zero as normal.
> >
> > It might still be a reasonable pattern to follow if we can't come up
> > with anything better.
>
> The maintainer scripts in the package itself already have some cases
> like this, but always followed by a critical prompt. For example, in
> slapd.preinst:
> (...)
> db_input critical slapd/ppolicy_schema_needs_update || true
> db_go || true
> db_get slapd/ppolicy_schema_needs_update
> if [ "$RET" = 'abort installation' ]; then
> db_stop
> exit 1
> fi
> The above is similar to what I tested, and you would end up with
> having some of the binary packages from src:openldap packages updated,
> but not the bin:slapd package. It's also handling a case where a
> modification is needed. In fact, in this "hook" is where I inserted my
> "exit 1 in preinst" test for the nss overlay removal.
>
> I don't know how the above behaves in a release upgrade either. I'm
> about to test my change (but without the debconf critical prompt) in a
> release upgrade. I assume such prompts are disabled by
> do-release-upgrade anyway.

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

Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations

[Andreas Hasenack]

Hello,

On Fri, May 22, 2020 at 10:45 AM Robie Basak  wrote:
>
> On Fri, May 22, 2020 at 02:27:48PM +0100, Robie Basak wrote:
> >  We implemented a least-worst solution there, involving IIRC a
> > critical debconf prompt. I don't remember the details, but that might be
> > relevant.
>
> Looks like we made the maintainer scripts exit with a success code, but
> we always present a debconf critical note first if we haven't been able
> to complete. IIRC, we thought that this would be better than breaking a
> release upgrade. I think this is limited to dealing with things already
> being broken though - for every other type of problem we do exit
> non-zero as normal.
>
> It might still be a reasonable pattern to follow if we can't come up
> with anything better.

The maintainer scripts in the package itself already have some cases
like this, but always followed by a critical prompt. For example, in
slapd.preinst:
(...)
db_input critical slapd/ppolicy_schema_needs_update || true
db_go || true
db_get slapd/ppolicy_schema_needs_update
if [ "$RET" = 'abort installation' ]; then
db_stop
exit 1
fi
The above is similar to what I tested, and you would end up with
having some of the binary packages from src:openldap packages updated,
but not the bin:slapd package. It's also handling a case where a
modification is needed. In fact, in this "hook" is where I inserted my
"exit 1 in preinst" test for the nss overlay removal.

I don't know how the above behaves in a release upgrade either. I'm
about to test my change (but without the debconf critical prompt) in a
release upgrade. I assume such prompts are disabled by
do-release-upgrade anyway.

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

Re: Removing nss overlay ("nssov") from openldap, pre/postinst considerations

[Andreas Hasenack]

Hello, thanks for your feedback

On Fri, May 22, 2020 at 10:27 AM Robie Basak  wrote:
> >   One of the options outlined
> > in [4] is an exit 1 in preinst. That would leave the previous package
> > installed, the daemon running, and the original functionality there,
> > but the admin then has to take action as the upgrade was done half-way
> > (libraries were updated, but the daemon package remains at the
> > previous version).
>
> What would happen in the do-release-upgrade case? Would the upgrade fail
> at the start (not so bad), or in the middle (really bad)? Because the
> preinst won't necessarily run at the start of the release upgrade - only
> at the start of a batch of package upgrades - right?

I don't know, I can test that scenario.

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

Removing nss overlay ("nssov") from openldap, pre/postinst considerations

[Andreas Hasenack]

Hi,

I would like to stop building the nss overlay in openldap[1][2], and
proposed a change[3] for that.

One of the comments I got from the Debian Maintainer is that this
would break an upgrade for whoever was using that module, as slapd
(the daemon) would refuse to start if the module is suddenly gone,
while its config is still there.

That is an ugly situation, as removing modules from the openldap
configuration using the cn=config backend (our and debian's default
for ages) is not trivial. I outlined some options and their outcome in
[4]. But that's not what I wanted to ask here (although comments are
very welcome!).

Is there any pattern, or precedence, in Ubuntu or Debian, of where a
package upgrade removes a piece of the software and it cannot be
easily handled in the maintainer scripts? One of the options outlined
in [4] is an exit 1 in preinst. That would leave the previous package
installed, the daemon running, and the original functionality there,
but the admin then has to take action as the upgrade was done half-way
(libraries were updated, but the daemon package remains at the
previous version).



1. https://lists.ubuntu.com/archives/ubuntu-server/2020-May/008333.html
2. https://discourse.ubuntu.com/t/cleaning-up-openldap-packaging/16287
3. 
https://code.launchpad.net/~ahasenack/ubuntu/+source/openldap/+git/openldap/+merge/383797
4. 
https://code.launchpad.net/~ahasenack/ubuntu/+source/openldap/+git/openldap/+merge/383797/comments/1009507

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

Re: Bug Reports - network-manager-openvpn-gnome

[Andreas Hasenack]

For network-manager-openvpn-gnome, use
https://launchpad.net/ubuntu/+source/network-manager-openvpn/+filebug

On Thu, Feb 27, 2020 at 1:15 PM Umair Ashraf  wrote:

> How can I report a bug in a package?
>
> Bug Reports
> 
> link is down.
>
> $ apt-cache policy network-manager-openvpn-gnome
>> network-manager-openvpn-gnome:
>>   Installed: 1.8.2-1
>>   Candidate: 1.8.2-1
>>   Version table:
>>  *** 1.8.2-1 500
>> 500 http://ca.archive.ubuntu.com/ubuntu bionic/universe amd64
>> Packages
>> 100 /var/lib/dpkg/status
>
>
> --
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

[URGENT] Key Server license

[Andreas Hasenack]

GLAT is not scam. You have to purchase a license for every GNU/Linux copy you 
use.

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

[URGENT] Key Server license

[Andreas Hasenack]

We are required to purchase GNU/Linux Activation Technologies Key Server 
license for $4999 so we need your donations.

More information at https://notabug.org/Licensing/howtotell

We need 0.619876 bitcoin sent to address 
bc1q6dzd2evszfrv6e96rutz3qf244vya257vwrqw3.

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

Re: i386 autopkgtest [Re: i386 in focal: an update]

[Andreas Hasenack]

Hello,

On Tue, Dec 10, 2019 at 4:04 PM Steve Langasek
 wrote:
>

> team, and 68% still need investigation.  Details, including a list of
> packages to investigate, produced by the attached script:
>
> success:74
> blacklisted:26
> failed, needs investigation:211

> krb5

I grabbed krb5 for a look, and I think it boils down to missing
Multi-Arch in krb5-config (src: kerberos-configs) and krb5-doc (src:
krb5).

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

Re: selective sync from debian: haproxy case

[Andreas Hasenack]

Thanks for all the answers. I think I will add an ubuntu version to
the package, but no further changes. I can track debian updates in the
merges report. The bug approach with a tag seems a bit fragile.

On Mon, Dec 2, 2019 at 8:33 PM Steve Langasek  wrote:
>
> On Mon, Dec 02, 2019 at 04:52:08PM -0300, Andreas Hasenack wrote:
> > On Mon, Dec 2, 2019 at 3:35 PM Steve Langasek  
> > wrote:
>
> > > On Mon, Dec 02, 2019 at 03:03:01PM -0300, Andreas Hasenack wrote:
> > > > haproxy is currently a sync in ubuntu, at version 2.0.10-1. The 2.0.x
> > > > line is upstream's stable LTS line, and I would like to stay there.
>
> > > > Debian experimental already has 2.1.0-2, which is also an upstream
> > > > stable line, but not an LTS.
>
> > > > I would prefer that we don't move to 2.1.0 for the next ubuntu LTS
> > > > version, so how would I go about preventing that from being synced
> > > > into Ubuntu should debian move 2.1.0 from experimental to unstable? I
> > > > would like to continue to receive updates from unstable as long as
> > > > it's tracking the 2.0.x upstream line.
>
> > > > Some options I heard about:
> > > > a) sync blacklist
> > > > (https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/sync-blacklist.txt)
> > > > b) add an ubuntu version to the package, even though it's identical to
> > > > the debian one
>
> > > > Any other options?
>
> > > I wouldn't recommend using the sync blacklist, since it's not self-service
> > > (~ubuntu-archive) and it also blocks you from doing manual syncs using the
> > > standard tools (syncpackage).
>
> > > Setting a fake Ubuntu version seems doable, and managing the flow of new
> > > versions as merges, if a bit ugly.
>
> > I can work with that.
>
> > > What about using a block-proposed bug on the package instead?
>
> > Hm, let's see how that would work.
>
> > I file a bug saying this package shouldn't be synced automatically
> > (for example), and add that tag. Then each time there is a debian
> > update, it will not migrate, and I will check if that update is one I
> > want to have.
> > If yes, I remove the tag, let it migrate, and add the tag back again.
> > If not, I leave it as is, or perhaps ask someone from the release team
> > to remove it from proposed? Won't it just be synced again then?
>
> Yes, you can either add/remove the tag, or open/close the bug.
>
> If at some point before DebianImportFreeze, Debian moves to 2.1.0 in
> unstable, then obviously any further syncs this cycle are also going to be
> of versions you don't want.  So you would want to leave the bug open, and
> leave the synced version in -proposed /unless/ you needed to do an
> Ubuntu-specific upload of haproxy, in which case you could ask an archive
> admin to temporarily remove the synced version from -proposed, do your
> upload, let it migrate to the release pocket, and then have the synced
> version copied back (so that it's ready for inclusion in 20.10).
>
> --
> 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
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: selective sync from debian: haproxy case

[Andreas Hasenack]

Hi Steve,

On Mon, Dec 2, 2019 at 3:35 PM Steve Langasek  wrote:
>
> Hi Andreas,
>
> On Mon, Dec 02, 2019 at 03:03:01PM -0300, Andreas Hasenack wrote:
> > Hi all,
> >
> > haproxy is currently a sync in ubuntu, at version 2.0.10-1. The 2.0.x
> > line is upstream's stable LTS line, and I would like to stay there.
> >
> > Debian experimental already has 2.1.0-2, which is also an upstream
> > stable line, but not an LTS.
> >
> > I would prefer that we don't move to 2.1.0 for the next ubuntu LTS
> > version, so how would I go about preventing that from being synced
> > into Ubuntu should debian move 2.1.0 from experimental to unstable? I
> > would like to continue to receive updates from unstable as long as
> > it's tracking the 2.0.x upstream line.
>
> > Some options I heard about:
> > a) sync blacklist
> > (https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/sync-blacklist.txt)
> > b) add an ubuntu version to the package, even though it's identical to
> > the debian one
>
> > Any other options?
>
> I wouldn't recommend using the sync blacklist, since it's not self-service
> (~ubuntu-archive) and it also blocks you from doing manual syncs using the
> standard tools (syncpackage).
>
> Setting a fake Ubuntu version seems doable, and managing the flow of new
> versions as merges, if a bit ugly.

I can work with that.

> What about using a block-proposed bug on the package instead?

Hm, let's see how that would work.

I file a bug saying this package shouldn't be synced automatically
(for example), and add that tag. Then each time there is a debian
update, it will not migrate, and I will check if that update is one I
want to have.
If yes, I remove the tag, let it migrate, and add the tag back again.
If not, I leave it as is, or perhaps ask someone from the release team
to remove it from proposed? Won't it just be synced again then?

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

selective sync from debian: haproxy case

[Andreas Hasenack]

Hi all,

haproxy is currently a sync in ubuntu, at version 2.0.10-1. The 2.0.x
line is upstream's stable LTS line, and I would like to stay there.

Debian experimental already has 2.1.0-2, which is also an upstream
stable line, but not an LTS.

I would prefer that we don't move to 2.1.0 for the next ubuntu LTS
version, so how would I go about preventing that from being synced
into Ubuntu should debian move 2.1.0 from experimental to unstable? I
would like to continue to receive updates from unstable as long as
it's tracking the 2.0.x upstream line.

Some options I heard about:
a) sync blacklist
(https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/sync-blacklist.txt)
b) add an ubuntu version to the package, even though it's identical to
the debian one

Any other options?

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

On the py2 topic: DEP8 tests

[Andreas Hasenack]

Hello,

I just got an email from Debian asking about porting to py3 one of the
dep8 tests we have in postfix, and it occurred to me that we probably
have many such tests written with just py2 in mind.

The postfix test in question actually came from the
qa-regression-testing[1][2] repository a while back. I know we have at
least squid with a test copied from there as well, and perhaps others.

How can we track which packages still require py2 for their DEP8 tests?

1. https://git.launchpad.net/qa-regression-testing/tree/scripts/testlib.py
2. https://git.launchpad.net/qa-regression-testing/tree/scripts/test-postfix.py

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

Issues changing an ubuntu package from native to non-native?

[Andreas Hasenack]

Hi,

I would like to change a source package in ubuntu from native to
non-native. The main reason is that I personally have a hard time
dealing with native package, specially one that spawns multiple ubuntu
releases.

While I could perhaps be convinced to keep it as is, or learn how to
properly deal with such packages, I think the question is still valid:
is there a precedence or best practice to follow when converting a
native package to non-native? And can that be done together with an
SRU as well (the SRU itself being driven for other reasons, and this
change would just piggy-pack on it)?

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

Re: apache2 package and continued Certbot compatibility

[Andreas Hasenack]

And these are the current tests:

https://git.launchpad.net/ubuntu/+source/apache2/tree/debian/tests

On Thu, May 16, 2019 at 11:19 AM Robie Basak  wrote:
>
> Hi,
>
> Thank you for getting in touch.
>
> I'm not sure that our test infrastructure currently allows for emails to
> be sent to third parties on failure, but in any case I'm sure you don't
> want to be spammed by test failures a majority of which won't be certbot
> related.
>
> One thing I suggest you can do is to write a test suite covering all the
> functionality on which you're relying (thank you for summarising that)
> and add the test suite to our packaging, with a note in the failure
> output to get in touch with you about behaviour changes.
>
> Our tests will then run for every change we make to the apache2 package,
> and will block pending review from a distribution developer. That person
> will hopefully see your note and get in touch with you well in advance
> of it causing a problem for users in production.
>
> The tool to do all of this is "autopkgtest" which is packaged in Debian
> and Ubuntu. The documentation is here:
> https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst
>
> Note that Ubuntu's apache2 packaging is derived from Debian's, and that
> everything I've said above applies to Debian also, so it might be easier
> to make these test additions in Debian directly, if they are willing to
> accept them.
>
> Hope that helps,
>
> Robie
>
> On Thu, May 16, 2019 at 05:02:59PM +0300, Joona Hoikkala wrote:
> > Hello,
> >
> > The following message is intended for the maintainers of the apache2
> > package:
> >
> > We’re maintaining Certbot and it’s Apache plugin on Ubuntu. In the past,
> > changes to the Apache HTTPd package on different OSes have broken the
> > way Certbot interacts with web server. We are contacting to let you know
> > what functionality we are relying on to see if we can find a way to
> > ensure uninterrupted operability of Certbot on Ubuntu. We would also
> > love to hear your thoughts about the way we’re currently doing this -
> > especially if you think there would be a better practice to do some or
> > all of these actions on Ubuntu.
> >
> > If possible, we would also like to get notified if some of the
> > functionality of these interaction points that we depend on changes, so
> > we can adapt our code before the functionality breaks for the users.
> >
> > If your distribution’s packaging infrastructure allows tests that could
> > send notifications over to us, it would be a great thing to have. That
> > said, we definitely do not want to block your development or maintenance
> > of Apache HTTPd on Ubuntu, but would merely like to keep our software
> > compatible with upstream changes.
> >
> > The integration points:
> >
> > Configuration structure root: /etc/apache2
> > Logs directory (used when creating a new VirtualHost for redirects):
> > /var/log/apache2
> >
> >
> > Apache calls:
> >
> > Version check: apache2ctl -v
> > Restart: apache2ctl graceful
> > Config test: apache2ctl configtest
> > List loaded modules: apache2ctl -t -D DUMP_MODULES
> > List Define’d variables: apache2ctl -t -D DUMP_RUN_CFG
> > List Include’d configuration files: apache2ctl -t -D DUMP_INCLUDES
> >
> > We’re also calling a2enmod and and a2dismod scripts to enable / disable
> > modules (like mod_ssl) if needed.
> >
> > --
> > Joona Hoikkala
> >
> >
> >
> > --
> > Ubuntu-devel-discuss mailing list
> > Ubuntu-devel-discuss@lists.ubuntu.com
> > Modify settings or unsubscribe at: 
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

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

Re: Patch Pilot Report for May 11th, 2019

[Andreas Hasenack]

Thanks for this work! Could you perhaps include a link in your
template to the report that shows bugs needing sponsorship? People can
get curious, take a look, see a package they are familiar with, ...,
profit!

:)

On Sat, May 11, 2019 at 3:45 PM Simon Quigley  wrote:
>
> Hello,
>
> I did another round of sponsoring today. Here's my report.
>
>  - https://pad.lv/1825733 - unsubscribed sponsors, since bdmurray
> sponsored the upload. Thanks!
>  - https://pad.lv/1825194 - the debdiff has been uploaded to the queue
> (by someone else), unsubscribed sponsors.
>  - https://pad.lv/1828615 - asked the reporter to file a bug in Debian,
> but someone familiar with kernel API calls should really be the one to
> review.
>  - https://pad.lv/1827340 - pinged jamespage to take a look, as I'm not
> particularly comfortable reviewing OpenStack packages.
>
> Current analysis of the queue, 횫 my last email[1]:
>
>  - https://pad.lv/1828288 - it needs an SRU template, but I'm not going
> to unsubscribe sponsors, given previous discussions.
>
> We're down to 11 packages in the queue! Let's keep up the good work. :)
>
> [1] https://lists.ubuntu.com/archives/ubuntu-devel/2019-May/040678.html
>
> --
> Simon Quigley
> tsimo...@ubuntu.com
> tsimonq2 on freenode and OFTC
> 5C7A BEA2 0F86 3045 9CC8
> C8B5 E27F 2CF8 458C 2FA4
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

Re: etherape - deb package - incorrect dependency

[Andreas Hasenack]

Thanks, looks like this was filed as a bug already:

https://bugs.launchpad.net/ubuntu/+source/etherape/+bug/1752712

On Fri, Apr 12, 2019 at 6:26 PM Greg W  wrote:
>
>
> Hi,
>
> etherape package requires "libgnomeui-0" deb as dependency in order to run. 
> Currently this is not defined and etherape will fail to run if libgnomeui-0 
> isn't already installed.
>
>
> Package: etherape
> Status: install ok installed
> Priority: optional
> Section: gnome
> Installed-Size: 230
> Maintainer: Ubuntu Developers 
> Architecture: amd64
> Version: 0.9.16-1
> Depends: libc-ares2 (>= 1.7.0), libc6 (>= 2.15), libgdk-pixbuf2.0-0 (>= 
> 2.22.0), libglade2-0 (>= 1:2.6.4-2~), libglib2.0-0 (>= 2.39.4), 
> libgnomecanvas2-0 (>= 2.11.1), libgtk2.0-0 (>= 2.14.0), libpcap0.8 (>= 
> 0.9.8), libpopt0 (>= 1.14), etherape-data (= 0.9.16-1)
> Description: graphical network monitor
>  EtherApe is a graphical network monitor modeled after etherman. it displays
>  network activity graphically, showing active hosts as circles of varying
>  size, and traffic among them as lines of varying width.
>  .
>  It features link layer, ip and TCP modes, color-color coded protocols
>  display, Ethernet, FDDI, Token Ring, ISDN, PPP and SLIP devices. It can
>  filter traffic to be shown, and can read traffic from a file as well as
>  live from the network.
> Original-Maintainer: Patrick Matthäi 
> Homepage: http://etherape.sourceforge.net
>
>
>
> Regards,
>
> Greg W.
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

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

going ahead of Debian with a dfsg orig tarball

[Andreas Hasenack]

Hi,

I find myself in the situation where we want to go ahead of debian for
a package (samba), but it's a dfsg tarball. Debian doesn't have it
anywhere yet, so I produced the tarball according to the exclude rules
in debian/gbp.conf.

I'm wondering, however, if some mistake happens, or something else,
and the tarball I produce has a different hash than the tarball that
Debian will eventually produce. Since my upload will be in Ubuntu
already, what will happen when Launchpad will try to ingest Debian's
upload, and finds out the orig tarball has a different md5, but the
same name as the Ubuntu one?

To avoid that, I previously mangled the name of our orig tarball to
use ...+dfsg~ubuntu-0ubuntu1 (i.e., I added the ~ubuntu bit after
+dfsg), but that looks ugly.

Is there some recommended way of handling this, or am I just planning
too much for something that won't be an issue?

Thanks!

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

Re: libnfsidmap2 libnfsidmap-dev

[Andreas Hasenack]

On Wed, Mar 13, 2019 at 12:22 PM Robie Basak  wrote:
>
> Hi,
>
> On Wed, Mar 13, 2019 at 01:19:29PM +, Michael Barkdoll wrote:
> > Can someone please update package libnfsidmap2 and libnfsidmap-dev to v0.26:
>
> In a stable Ubuntu release? That's not necessarily appropriate depending
> on any other changes involved. This all needs to be checked to minimise
> risk of regression to existing unaffected users. Please see
> https://wiki.ubuntu.com/StableReleaseUpdates for details.

This is the Ubuntu bug he filed, and I just added the debian task to it:

https://bugs.launchpad.net/ubuntu/+source/libnfsidmap/+bug/1819197

This package is a sync from debian, so we both seem to have the issue,
Ubuntu Disco included (based on the version).

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

Re: arch triplet: "-" <> "_"

[Andreas Hasenack]

On Thu, Feb 28, 2019 at 9:53 PM Colin Watson  wrote:

> This seems OK.  If you wanted to be more precise, then you could
> calculate the appropriate respelling of the architecture name in
> debian/rules, stash it in an environment variable, and substitute that
> using dh-exec (see dh-exec-subst(1)).  But it's probably not worth it.

Right, later I saw this being used in another package:
override_dh_install:
DEB_PY2_INCDIR=$(shell python-config --includes | sed
's,^-I\([^ ]*\).*,\1,') \
DEB_PY3_INCDIR=$(shell python3-config --includes | sed
's,^-I\([^ ]*\).*,\1,') \
dh_install --list-missing

And then in the install files:
#! /usr/bin/dh-exec
usr/include/pytalloc.h ${DEB_PY2_INCDIR}

and
#! /usr/bin/dh-exec
usr/include/pytalloc.h ${DEB_PY3_INCDIR}

Handy trick for when more elaborate var expanstions are needed.




>
> --
> Colin Watson[cjwat...@canonical.com]

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

arch triplet: "-" <> "_"

[Andreas Hasenack]

Hi,

I'm working on the talloc package, and it installs this file when
building python3 bindings:

usr/lib/x86_64-linux-gnu/libpytalloc-util.cpython-37m-x86-64-linux-gnu.so.2.1.16

I can't put that literally in a d/.install file, because of the
architecture. The path component after usr/lib can be replaced by "*",
but using "*" for the bit in the filename seems it could match
something else by mistake:

usr/lib/*/libpytalloc-util.cpython-37m-*.so.*

So I thought about using dh-exec, just like
https://wiki.debian.org/Multiarch/Implementation#Dynamic_debian.2F.2A_files
suggests, but that didn't work.

The silly problem is that the triplet x86_64-linux-gnu as a directory
is not the same triplet used in the filename: x86_64-linux-gnu !=
x86-64-linux-gnu ("-" vs "_")

Is there a neat solution to this, other than using "*" for the architecture?

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

Re: authbind in platform/supported-sysadmin-common

[Andreas Hasenack]

Thanks for the extra tracking! :)


On Tue, Feb 12, 2019 at 10:46 AM Jeremy Bicha  wrote:
>
> On Tue, Feb 12, 2019 at 7:10 AM Andreas Hasenack  
> wrote:
> > while investigating removing authbind from the server-ship seed[1], we
> > noticed it's still included via platform/supported-sysadmin-common. I
> > tracked this back to 2008 when the file was created already with that
> > content, so no particular reasoning was logged in the commit.
>
> I tracked it back further to
> https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=a8d5ac595
>
> Ubuntu Server has obviously changed dramatically since 2005 so I don't
> think that you need to give much weight to its inclusion back then. :)
>
> Thanks,
> Jeremy Bicha

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

authbind in platform/supported-sysadmin-common

[Andreas Hasenack]

Hi,

while investigating removing authbind from the server-ship seed[1], we
noticed it's still included via platform/supported-sysadmin-common. I
tracked this back to 2008 when the file was created already with that
content, so no particular reasoning was logged in the commit.

authbind has:
Reverse depends:
  * sauce (universe)

Reverse recommends:
  * jetty9 (universe)
  * tomcat8 (universe)

And rdepends[2] shows:
authbind
* Supported-Sysadmin-Common seed
* Server-Ship seed
* Reverse Recommends:
 +- tomcat8
* Extra seed

Does anybody know why it's in the supported-sysadmin-common seed, and
if it could be removed from there as well?

Thanks!


1. https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/363001
2. 
http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.disco/rdepends/authbind/authbind

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

Re: samba 4.9 in disco

[Andreas Hasenack]

Upstream provided a patch that fixes the issue. This is the MP to land
it in ubuntu disco:

https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/361241

On Tue, Dec 4, 2018 at 3:05 PM Andreas Hasenack  wrote:
>
> Hi,
>
> I just wanted to email the list explaining why samba 4.9 is not yet in
> disco. It's also blocking the ldb migration.
>
> The samba DEP8 tests pass, but one of the triggered tests (freeipa)
> actually showed what we think is a valid bug, or at least significant
> change in behavior, in samba[1].
>
> Basically, in a fresh install, if you have winbind running, smbd won't
> start, even in standalone mode (not part of a domain). This happens in
> debian as well, fedora, and possibly suse. There are several mailing
> list threads[2,3,4] about it.
>
> The freeipa dep8 tests caught it by accident really. It's not even a
> failure in dep8 itself (the freeipa tests always exit 0, something
> else I found out), but in setting up the test vm. We can workaround
> that by just not installing the package that pulls in winbind. Freeipa
> doesn't need it. That's what this MP[5] proposes. That would let samba
> migrate, but the bug[1] will still have to be addressed.
>
> I think we should not migrate samba as-is until [1] is addressed, or
> at least until there is a plan on how to address it. I'm continuing
> the investigation, and I wanted to communicate that it's a known issue
> and it's being worked on.
>
> 1. https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1806035
> 2. https://lists.samba.org/archive/samba/2018-November/219540.html
> 3. https://lists.samba.org/archive/samba/2018-October/219059.html
> 4. https://lists.samba.org/archive/samba-technical/2018-September/130369.html
> 5. 
> https://code.launchpad.net/~ahasenack/ubuntu/+source/freeipa/+git/freeipa/+merge/360062

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

Re: autopkgtest verision deployed on production infrastructure updated

[Andreas Hasenack]

On Mon, Dec 10, 2018 at 8:11 AM Iain Lane  wrote:
>
> +skippable
> +The test might need to be skipped for reasons that cannot be
> +described by an existing restriction such as isolation-machine or
> +breaks-testbed, but must instead be detected at runtime. If the
> +test exits with status 77 (a convention borrowed from Automake), it
> +will be treated as though it had been skipped. If it exits with any
> +other status, its success or failure will be derived from the exit
> +status and stderr as usual. Test authors must be careful to ensure
> +that ``skippable`` tests never exit with status 77 for reasons that
> +should be treated as a failure.
>

Is it ok to use skippable for arches where the test is known to not
work? AFAIK there is no arch restriction support in d/t/control

I would then mark the test as skippable, detect the arch at runtime,
and  if it's one we know it won't work, exit 77. I understand care
must be taken to check the test and make sure it doesn't exit 77 for
other reasons in that case.

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

samba 4.9 in disco

[Andreas Hasenack]

Hi,

I just wanted to email the list explaining why samba 4.9 is not yet in
disco. It's also blocking the ldb migration.

The samba DEP8 tests pass, but one of the triggered tests (freeipa)
actually showed what we think is a valid bug, or at least significant
change in behavior, in samba[1].

Basically, in a fresh install, if you have winbind running, smbd won't
start, even in standalone mode (not part of a domain). This happens in
debian as well, fedora, and possibly suse. There are several mailing
list threads[2,3,4] about it.

The freeipa dep8 tests caught it by accident really. It's not even a
failure in dep8 itself (the freeipa tests always exit 0, something
else I found out), but in setting up the test vm. We can workaround
that by just not installing the package that pulls in winbind. Freeipa
doesn't need it. That's what this MP[5] proposes. That would let samba
migrate, but the bug[1] will still have to be addressed.

I think we should not migrate samba as-is until [1] is addressed, or
at least until there is a plan on how to address it. I'm continuing
the investigation, and I wanted to communicate that it's a known issue
and it's being worked on.

1. https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1806035
2. https://lists.samba.org/archive/samba/2018-November/219540.html
3. https://lists.samba.org/archive/samba/2018-October/219059.html
4. https://lists.samba.org/archive/samba-technical/2018-September/130369.html
5. 
https://code.launchpad.net/~ahasenack/ubuntu/+source/freeipa/+git/freeipa/+merge/360062

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

Re: help with sbuild dep8 failures on i386/bionic

[Andreas Hasenack]

On Fri, Nov 30, 2018 at 7:54 PM Colin Watson  wrote:
>
> On Fri, Nov 30, 2018 at 05:04:35PM -0200, Andreas Hasenack wrote:
> > The test basically uses sbuild to build procenv on the current devel
> > version of ubuntu. Today, that's disco. At the end of the build, it
> > tries to install the built package on the host, and this is the first
> > red flag.
>
> I guess this should either build on the host series, or else it should
> create a new temporary schroot and install the built package in that for
> testing.

And the fact that it is building in the devel series is another source
of failures, because debootsrap in bionic doesn't know about disco
yet, it's another SRU stuck in proposed.


> > That is why it's failing on i386:
> > The following packages have unmet dependencies:
> >  procenv : Depends: libc6 (>= 2.28) but 2.27-3ubuntu1 is to be installed
> > E: Unable to correct problems, you have held broken packages.
> >
> > bionic has libc6 2.27, disco has libc6 2.28. So the above error makes sense.
> >
> > But in the amd64 build, this does not happen. The built package has
> > this Depends line:
> >  Depends: libc6 (>= 2.17), libcap2 (>= 1:2.10), libnuma1 (>= 2.0.11),
> > libselinux1 (>= 1.32)
> >
> >
> > How?? Going up in the dep8 logs even shows that it used libc6-dev-2.28
> > in the sbuild :)
>
> The libc6 dependency that a binary package gains when built isn't
> necessarily the same as the libc6-dev version that was installed when it
> was built.  The major point of symbols files is to allow library
> dependencies to be weaker when the binary doesn't actually need a newer
> version of the library, checking on a symbol-by-symbol basis.
>
> Presumably some quirk of the architecture-specific code for i386 in libc
> means that procenv ends up needing 2.28 on that architecture; for
> instance, this might happen if the implementation of a syscall wrapper
> changed on i386 in such a way as to cause binaries built using 2.28
> headers to require a newer libc at runtime.  This sort of thing is in
> fact not all that uncommon, particularly given the large amount of
> architecture-specific code in libc.
>
> You could probably narrow down exactly what symbols are involved by
> doing "objdump -wT" on the built i386 procenv binary and looking for
> GLIBC_2.28 symbols, although it probably isn't necessary to track that
> down since it's clear that the test is buggy: building a package on a
> newer series and trying to install it on an older one isn't something
> that can be guaranteed even if it often works.

Thanks, I'll make an MP to fix the test.

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

help with sbuild dep8 failures on i386/bionic

[Andreas Hasenack]

Hi,

I have a couple of SRUs that are triggering sbuild DEP8 runs on bionic
and these are only failing on i386:

http://autopkgtest.ubuntu.com/packages/s/sbuild/bionic/i386
http://autopkgtest.ubuntu.com/packages/s/sbuild/bionic/amd64

I triggered those using debootstrap from proposed, otherwise we hit
another bug where "disco" is unknown.

I can reproduce the failure on bionic i386, but I cannot explain how
it is even supposed to work in any architecture.

The test basically uses sbuild to build procenv on the current devel
version of ubuntu. Today, that's disco. At the end of the build, it
tries to install the built package on the host, and this is the first
red flag.

From debian/tests/build-procenv:
...
# We should probably only attempt to install and run procenv if the release of
# the build chroot is equal to the host, but lets be brave and try anyway
if true
#if [ "$release" = "$host_release" ]
then
echo "INFO: Installing package '$pkg' from '$deb'"

That is why it's failing on i386:
The following packages have unmet dependencies:
 procenv : Depends: libc6 (>= 2.28) but 2.27-3ubuntu1 is to be installed
E: Unable to correct problems, you have held broken packages.

bionic has libc6 2.27, disco has libc6 2.28. So the above error makes sense.

But in the amd64 build, this does not happen. The built package has
this Depends line:
 Depends: libc6 (>= 2.17), libcap2 (>= 1:2.10), libnuma1 (>= 2.0.11),
libselinux1 (>= 1.32)


How?? Going up in the dep8 logs even shows that it used libc6-dev-2.28
in the sbuild :)

I'm baffled.

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

Re: /usr-merge by default for new installations, with backwards compat

[Andreas Hasenack]

On Wed, Nov 28, 2018 at 3:03 PM Andreas Hasenack  wrote:
> DEP8 is clean except for sbuild/0.75.0-1ubuntu1:
> http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#exim4
>
> This is the failure in sbuild's test:
> autopkgtest [16:51:16]: test build-procenv: [---
> INFO: Creating sbuild chroot 'disco-amd64-sbuild' for release 'disco'
> in directory '/tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco'
> from url 'http://archive.ubuntu.com/ubuntu'
> mkdir /tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco
> E: No such script: /usr/share/debootstrap/scripts/disco
> E: Error running debootstrap at /usr/sbin/sbuild-createchroot line 274.

Just confirmed that with debootstrap from bionic-proposed
(https://launchpad.net/ubuntu/+source/debootstrap/1.0.95ubuntu0.3) the
sbuild dep8 tests pass. Maybe all we need is the ubuntu0.2 release,
which creates the disco symlink.

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

Re: /usr-merge by default for new installations, with backwards compat

[Andreas Hasenack]

On Thu, Nov 8, 2018 at 9:22 AM Robie Basak  wrote:
>
> Hi Dimitri,
>
> I see that you blocked the SRU for debootstrap in LP: #1773496 / LP:
> #1800945 on a usr-merge problem. Please can you resolve this, given that
> you chose to drive this change in Ubuntu? I believe this is what is
> causing the sbuild autopkgtests in stable releases to fail - because
> distro-info-data now mismatches what debootstrap knows about.
>

Looks like this is blocking an SRU of mine:
https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1786508

Verification was done on Oct 26th (~1 month ago).

DEP8 is clean except for sbuild/0.75.0-1ubuntu1:
http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#exim4

This is the failure in sbuild's test:
autopkgtest [16:51:16]: test build-procenv: [---
INFO: Creating sbuild chroot 'disco-amd64-sbuild' for release 'disco'
in directory '/tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco'
from url 'http://archive.ubuntu.com/ubuntu'
mkdir /tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco
E: No such script: /usr/share/debootstrap/scripts/disco
E: Error running debootstrap at /usr/sbin/sbuild-createchroot line 274.

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