Re: pastebinit default target on Ubuntu

[Sergio Durigan Junior]

On Monday, April 15 2024, Robie Basak wrote:

> Reason to keep it dpaste.com:
>
> People have complained that the login requirement makes it unusable for
> helping Ubuntu users at large who don't necessarily have an Ubuntu SSO
> account.

The requirement for login is really a pain.  I find myself avoiding
paste.ubuntu.com most of the time because of it, especially if I know
that the target audience might not even have a Launchpad account.

> Reason to keep it paste.ubuntu.com:
>
> I'm not keen on relying on third party services when not necessary,
> especially ad-supported ones. I have no reason to distrust the current
> operator, but in general, these things tend to go wrong sooner or later.

dpaste.com also runs a proprietary backend, so I'm -1 on using it.
There's dpaste.org, which is FLOSS and doesn't seem to load any ads.

Thanks,

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

Re: +1 maintenance report

[Sergio Durigan Junior]

On Tuesday, February 27 2024, Colin Watson wrote:

> On Fri, Jan 26, 2024 at 06:31:39PM -0500, Sergio Durigan Junior wrote:
>> * celery
>>   - Spent a long time investigating the Python 3.12 segfault that
>> happens when running dh_auto_test.  I was able to obtain a usable
>> stacktrace.
>>   - I'll file an upstream bug.
>
> I don't know if you ever did this, but in case it's still on your to-do
> list, this is https://github.com/python/cpython/issues/115874; I
> suggested a cherry-pick of the proposed patch there in
> https://bugs.debian.org/1063345.

Thanks for the heads up.  This was still on my TODO list (I even have an
LXD container still running with the corefile ready...).  Good to know
that upstream is aware of it and that there's a tentative fix.

I'm Cc'ing doko to the thread.

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

+1 maintenance report

[Sergio Durigan Junior]

This week I did my +1 maintenance shift.  I was swamped with other
unrelated, high priority work so it was a bit tricky to juggle
everything.

I like to start from the bottom of update_excuses and choose some of the
more challenging FTBFSes.  schopin also pinged me about some FTBFSes
that were caused by the upcoming glibc transition, and on Friday I was
pinged by Christian who asked me to take a look at the
device-tree-compiler FTBFS.

Investigations
==

* yotta
  - Blocked by python-mbed-ls.  See below.
  - Now unblocked.
  
* python-mbed-ls
  - Submitted fix upstream: https://github.com/ARMmbed/mbed-os-tools/pull/288
  - Uploaded fix to Debian.
  - Ubuntu package has been removed
(https://bugs.launchpad.net/ubuntu/+source/python-mbed-ls/+bug/2049255).
We might want to reintroduce it now that the problem has been fixed.
  - That's been done.

* jool
  - Sync'ed package from Debian, which fixed the issue.

* zmap
  - Fixed the issue with the Debian package (which is severely outdated,
but that's a problem for another day/person), uploaded it.  The
fix should reach Ubuntu soon.
  - Done.
  
* taurus
  - Fixed the package in Debian.  Should reach Ubuntu soon.
  - Done.
  
* taurus-pyqtgraph
  - Fixed indirectly by taurus.
  
* r-bioc-savr
  - There's an RM bug against the package on Debian.  I didn't touch the
FTBFS.
  
* tiledarray
  - btas builds correctly on Debian/Ubuntu now.
  - I spent a considerable amount of time playing with
btas/blaspp/tiledarray and trying to make the latter compile.  I was
able to pass the cmake configuration stage (after patching btas),
but unfortunately tiledarray's build fails during the compilation
phase.  I decided to move on.
  
* celery
  - Spent a long time investigating the Python 3.12 segfault that
happens when running dh_auto_test.  I was able to obtain a usable
stacktrace.
  - I'll file an upstream bug.
  
* h5py
  - Filed https://bugs.launchpad.net/ubuntu/+source/h5py/+bug/2051291
  - There's an upstream bug filed against it.
  
* dolphin-emu
  - Found upstream patch to fix FTBFS.  Applied to the Ubuntu package
and uploaded.
  - Fixed.
  
* blobwar
  - Fixed & uploaded to Ubuntu.  Upstream is dead and the Debian package
is pretty much orphaned.
  
* repowerd
  - Investigated a bit.  I can build the package locally but it fails to
build on LP due to dh_missing complaining.
  
* device-tree-compiler
  - Got a request to take a look at this one.
  - Found the reason for the FTBFS, but couldn't find a proper way to
fix it.
  - Filed https://github.com/dgibson/dtc/issues/123
  - Filed 
https://bugs.launchpad.net/ubuntu/+source/device-tree-compiler/+bug/2051399
  - I'll keep an eye during the weekend.  If there's any movement
upstream, I'll upload a fix.  Otherwise, I'll patch the Ubuntu
package and adjust the expected output of the failing tests.

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


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

Re: +1 maintenance report

[Sergio Durigan Junior]

On Friday, September 01 2023, Benjamin Drung wrote:

> * **gsl**: Retried failing ruby-gsl/2.1.0.3+dfsg1-5build2 on ppc64el.
>   It is still failing and needs to be investigated.

I did a little investigative work and found that the problem can be
workarounded by compiling with -O2 instead of -O3.  This is a temporary
fix and I believe the real problem lies with GCC/GMP and problems with
precision arithmetic.

Anyway, I uploaded the package and hopefully it will migrate this time.

Cheers,

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

Re: Mantic QEMU, segfault in nested VMs and autopkgtest.u.c

[Sergio Durigan Junior]

On Tuesday, August 01 2023, Michael Hudson-Doyle wrote:

> On Wed, 2 Aug 2023 at 13:30, Sergio Durigan Junior 
> wrote:
>
>> Hi,
>>
>> Just a heads up that the QEMU package on Mantic is currently affected by
>> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2016252.  This about
>> using QEMU in a nested VM environment, and as such is impacting dep8
>> tests that make use of such feature (systemd tests come to mind, but
>> there are other packages affected like QEMU itself).
>>
>> If you see a failure in a dep8 test and it's a QEMU segfault, be aware.
>> This is actually a glibc regression that hasn't yet been fixed upstream.
>> I'm following the discussion there and plan to backport the patch ASAP
>> (unfortunately it's not part of glibc 2.38 either).
>>
>
> Can you coordinate that with the impending upload of 2.38 please? (Hi Simon)

Yes, absolutely, I was already planning to ping Simon about it tomorrow
(it's late here so I'm going to be now), should have mentioned that in
my initial email.  Thanks, Michael.

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

Mantic QEMU, segfault in nested VMs and autopkgtest.u.c

[Sergio Durigan Junior]

Hi,

Just a heads up that the QEMU package on Mantic is currently affected by
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2016252.  This about
using QEMU in a nested VM environment, and as such is impacting dep8
tests that make use of such feature (systemd tests come to mind, but
there are other packages affected like QEMU itself).

If you see a failure in a dep8 test and it's a QEMU segfault, be aware.
This is actually a glibc regression that hasn't yet been fixed upstream.
I'm following the discussion there and plan to backport the patch ASAP
(unfortunately it's not part of glibc 2.38 either).

Thanks,

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

Re: Duplicate Requests in autopkgtest-cloud

[Sergio Durigan Junior]

On Thursday, July 27 2023, Tim Andersson wrote:

> In the Ubuntu QA team we recently made and deployed a change which now
> makes it impossible to queue duplicate requests.
[...]

Thank you very much, Tim.  This is a much appreciated feature.

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

+1 maintenance report

[Sergio Durigan Junior]

This week I did my +1 maintenance shift.  As usual, I got a bit
sidetracked on Monday due to other pressing matters.

I like to start from the bottom of update  -excuses and choose some of the
more challenging FTBFSes.  Here's my report:

Investigations
==

* wtforms  -alchemy
  - https://bugs.launchpad.net/ubuntu/+source/wtforms  -alchemy/+bug/2013156
  - Rebuilt the package.
  - Build succeeded.
  - This should unblock wtforms  -json.

* maxima
  - Triggered rebuild on ppc64el to see if it works this time.
- No luck.  Decided to move to another package.

* git  -annex
  - https://bugs.launchpad.net/ubuntu/+source/git  -annex/+bug/2019992
  - Fixed the FTBFS by removing   -Wl,  -Bsymbolic  -functions from LDFLAGS.
Debian accepted the patch as well, which is good.
  - ... Unfortunately this did not solve all the problems.  It seems
like there's some LTO issue going on.  Investigating.
  - ... Indeed, disabling LTO seems to fix the FTBFS on ppc64el.  Still
not sure what's going on with the riscv64 build.
  - ... A bit more investigation and I found that we apparently have to
enable certain Build  -Deps for riscv64 as well.  Submitted a new bug
to Debian.
  - Still not sure what causes the crash on armhf.  I tried obtaining a
machine to test the build, but after half a day waiting on an
internal MAAS to reserve me a machine, it failed.  I gave up.
  - I will sync the package again when Debian accepts my second round of
changes.  Let's check if the new upstream version will have any
impact on the armhf bug.

* golang  -github  -pion  -transport
* golang  -github  -pion  -datachannel
* golang  -github  -pion  -dtls.v2
* golang  -github  -pion  -ice.v2
* golang  -github  -pion  -interceptor
* golang  -github  -pion  -mdns
* golang  -github  -pion  -rtcp
* golang  -github  -pion  -sctp
* golang  -github  -pion  -srtp.v2
* golang  -github  -pion  -stun
* golang  -github  -pion  -turn.v2
* golang  -github  -pion  -udp
* golang  -github  -pion  -webrtc.v3
  - Made them all migrate by using the correct incantation when
retriggering the tests.

* rust  -sequoia  -net
  - Depends on rust  -sequoia  -openpgp >= 1.13, which is packaged in Debian
experimental, so I sync'ed it.
  - Unfortunately, rust  -sequoia  -openpgp depends on a newer version of
rust  -base64.  There is an update ready to be uploaded on salsa,
which leads me to believe that we should be able to untangle this
soon.

* bind  -dyndb  -ldap
  - This will need a rebuild when we merge bind9 from Debian.  I left a
comment in the merge bug.

* netatalk
  - dep8 test fails due to wrong regexp.
  - There's a fix on salsa, but it hasn't been uploaded to Debian yet.
I believe we should see an upload soon now that bookworm is out.
  - https://bugs.launchpad.net/ubuntu/+source/netatalk/+bug/2023728
  - My initial intention was to leave the package as is instead of
introducing unnecessary delta, but given that I've been called out
before when I did that, I went ahead and uploaded a fixed package to
Ubuntu.

* simde
  - dep8 failing on ppc64el.
  - I noticed that the Debian maintainer uploaded a new version to
unstable today (2023  -06  -13).  I hasn't been picked up by LP yet, so
I'll give it some time and see if that fixes the problem.
  - ... Unfortunately the new upload did not fix the failure.

* emacs  -corfu
  - Depends on elpa  -compat >= 29.1.4.0, but Debian and Ubuntu carry
29.1.3.0.
  - I uploaded compat  -el 29.1.4.0 to Debian, it should help resolve this
situation.

* fwupd
  - Retriggered the amd64 dep8 test; passed.

* libvcflib
  - FTBFSing on s390x.
  - Filed
https://bugs.launchpad.net/ubuntu/+source/libvcflib/+bug/2024021 and
the upstream equivalent https://github.com/vcflib/vcflib/issues/386

* libgnatcoll  -db
  - Retriggered build for ppc64el, which passed.

* mac  -fdisk
  - The package only builds on architectures that aren't support by Ubuntu.
  - Filed
https://bugs.launchpad.net/ubuntu/+source/mac  -fdisk/+bug/2024062
asking for its removal.

* libssh
  - dep8 test fails on ppc64el/s390x.
  - Passes on debci.
  - I tried reproducing it using a ppc64el canonistack box, but the test
always passes there, too.
  - Filed https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/2024064
to document what I did.  It seems to be something specific to our
autopkgtest infra, so I stopped the investigation.

* intercal
  - Retriggered amd64 build.  Passed.

* taglib
  - i386 build has been stuck for a while due to a missing dependency
(utfcpp).
  - I checked and utfcpp seems to be the only missing piece to build
taglib on i386.  Everything else is already built for the
architecture, and utfcpp itself only Build  -Depends on packages
already available for i386, too.
  - Pinged vorlon and ask if there's any interest in adding utfcppp to
i386's whitelist in order to unblock taglib.
  - ... all done:

Re: +1 maintenance report

[Sergio Durigan Junior]

On Thursday, February 16 2023, I wrote:

> On Monday, February 13 2023, Steve Langasek wrote:
>
>> On Fri, Feb 10, 2023 at 01:58:56PM -0500, Sergio Durigan Junior wrote:
>>> * gatb-core
>>>   - Debian dropped s390x from the list of supported architectures.
>>>   - Pinged ubuntu-archive and asked them to reflect this decision so
>>> that britney lets the package migrate.
>>
>> Missed in backlog while I was unavailable.  This package has
>> reverse-dependencies on s390x so further surgery is needed.  Please file a
>> bug with a complete analysis confirming the revdeps should also be removed.
>>
>> $ reverse-depends src:gatb-core -a s390x
>> Reverse-Recommends
>> * med-bio   (for gatb-core)
>> * med-bio-dev   (for libgatbcore-dev)
>>
>> Reverse-Depends
>> * bcalm (for libgatbcore3)
>> * discosnp  (for libgatbcore3)
>> * discosnp  (for gatb-core)
>> * mindthegap(for libgatbcore3)
>> * minia (for libgatbcore3)
>> * simka (for libgatbcore3)
>
> Will do.

This is done: https://bugs.launchpad.net/ubuntu/+source/simka/+bug/2007735

The same issue affects Debian; I filed bugs and uploaded packages there
to fix the problem.  These new packages should be sync'ed until
tomorrow.

Thanks,

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

Re: What's going on with proposed migration?

[Sergio Durigan Junior]

On Thursday, February 16 2023, Brian Murray wrote:

> First off I want to apologize for not sending this earlier. The Ubuntu
> QA team was focused on restoring the service but could have been more
> communicative regarding what was going on.
>
> In brief there was an outage with some underlying infrastructure
> provided by Canonical IS which took us a little while to catch and then
> a while longer to work around due to a multitude of failures. However,
> the set of failures we encountered have exposed some issues with
> the service running the autopkgtests which we plan to address in the
> near future.

Thanks for your and the QA team's work on this, Brian.

> If anybody is interested in the potentially boring nitty-gritty details
> I'd be happy to send a follow up email.

I'm personally interested in the details, and I also think it's a good
idea to leave a more detailed record for posterity.

Cheers,

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

Re: +1 maintenance report

[Sergio Durigan Junior]

On Monday, February 13 2023, Steve Langasek wrote:

> On Fri, Feb 10, 2023 at 01:58:56PM -0500, Sergio Durigan Junior wrote:
>> * gatb-core
>>   - Debian dropped s390x from the list of supported architectures.
>>   - Pinged ubuntu-archive and asked them to reflect this decision so
>> that britney lets the package migrate.
>
> Missed in backlog while I was unavailable.  This package has
> reverse-dependencies on s390x so further surgery is needed.  Please file a
> bug with a complete analysis confirming the revdeps should also be removed.
>
> $ reverse-depends src:gatb-core -a s390x
> Reverse-Recommends
> * med-bio   (for gatb-core)
> * med-bio-dev   (for libgatbcore-dev)
>
> Reverse-Depends
> * bcalm (for libgatbcore3)
> * discosnp  (for libgatbcore3)
> * discosnp  (for gatb-core)
> * mindthegap(for libgatbcore3)
> * minia (for libgatbcore3)
> * simka (for libgatbcore3)

Will do.

>> * bcbio & mosdepth & nim-{unicodeplus,regex}
>>   - In -proposed for 95 days.
>>   - bcbio is FTBFSing because it B-D on mosdepth.
>>   - mosdepth is FTBFSing because it B-D on nim-regex.
>>   - nim-regex and its B-D nim-unicodeplus were removed because they B-D
>> on nim, which (at the time) failed to build with openssl3.
>>   - nim now builds successfully.
>>   - I syncrequest'ed nim-{unicodeplus,regex}.
>
> Unfortunately these sync requests from Debian will fail, because
> - a sync from Debian is a source-only sync
> - these same versions have already existed in the Ubuntu archive in previous
> series, so a binary sync is needed
>
> I've rejected the packages from the NEW queue and synced the package from
> jammy with the following commands:
>
> $ copy-package --auto-approve -y -b -s jammy --to-suite lunar-proposed \
>   -e 0.17.0+ds-2 nim-regex
> $ copy-package --auto-approve -y -b -s jammy --to-suite lunar-proposed \
>   -e 0.5.1-2 nim-unicodeplus

Thanks.  While at it, could you please copy nim-docopt from jammy as
well?

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

+1 maintenance report

[Sergio Durigan Junior]

This week I did my +1 maintenance shift.  I got sidetracked a few times
due to some urgent requests/tasks.  Also, due to the size of
autopkgtests.u.c's queue I decided to focus on old FTBFSes.

Investigations
==

* pspp
  - In -proposed for 219 days.
  - armhf is FTBFSing due to a module mismatch error.
  - https://bugs.launchpad.net/pspp/+bug/1979610 has been filed.
  - Upstream also has http://savannah.gnu.org/bugs/?63392.
  - Filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030827
  - I tagged the LP bug as "update-excuse", but haven't spent much more
time on it.

* mmc-utils
  - In -proposed for 187 days.
  - ppc64el is FTBFSing due to a bogus -Werror=maybe-uninitialized
  - Filed...
  - Curiously, Nick Rosbrook and I worked on this bug at the same time
without knowing.  Fortunately, upstream already has the fix and we
both suggested the backport.
  - Uploaded in Ubuntu.  Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030829

* sbcl
  - In -proposed for 93 days.
  - FTBFS on arm64 due to LTO
  - Filed https://bugs.launchpad.net/ubuntu/+source/sbcl/+bug/2006524
  - Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015656
  - Uploaded fix to Ubuntu.

* gatb-core
  - Debian dropped s390x from the list of supported architectures.
  - Pinged ubuntu-archive and asked them to reflect this decision so
that britney lets the package migrate.

* libcleri
  - In -proposed for 94 days.
  - Affected by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020507
  - Attempting a no-change rebuild of siridb-server.  According to the
bug above, this should make siridb-server's dep8 tests pass and
libcleri migrate.

* php-laravel-lumen-framework & php-slim
  - In -proposed for 86 and 94 days, respectively.
  - These packages should be removed from Lunar.  They have bugs filed
for that (with ubuntu-archive subscribed), so I marked them as
Triaged (as suggested by xnox) in the hopes that it helps moving the
request forward.

* emacs-non-dfsg
  - In -proposed for 94 days.
  - Depends on emacs >= 28.1, which isn't available in Ubuntu yet.
  - I merged emacs 28.1 from Debian unstable.
  - I also merged dh-elpa 2.0.16.
  - Rebuilt evil-el.

* flycheck
  - FTBFS with emacs 28.1.  Uncovered this issue while merging emacs
28.1 from Debian unstable.
  - Filed https://bugs.launchpad.net/ubuntu/+source/flycheck/+bug/2006963
  - Uploaded a build1 version to explicitly trigger the FTBFS.

* cssutils
  - In -proposed for 95 days.
  - FTBFS due to incompatibilities with Python 3.x.
  - Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026728
  - Filed https://bugs.launchpad.net/ubuntu/+source/cssutils/+bug/2006741
  - Upstream is apparently dead; I couldn't find a bug tracker to report this.

* bcbio & mosdepth & nim-{unicodeplus,regex}
  - In -proposed for 95 days.
  - bcbio is FTBFSing because it B-D on mosdepth.
  - mosdepth is FTBFSing because it B-D on nim-regex.
  - nim-regex and its B-D nim-unicodeplus were removed because they B-D
on nim, which (at the time) failed to build with openssl3.
  - nim now builds successfully.
  - I syncrequest'ed nim-{unicodeplus,regex}.

* quorum
  - In -proposed for 198 days.
  - FTBFSing because of -Walloc-size-larger-than.  After some
investigation and reasoning about g++, new[] and warnings, I figured
out that the problem is caused by LTO.
  - Filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030954
  - Filed https://bugs.launchpad.net/debian/+source/quorum/+bug/2006787
  - Filed https://github.com/gmarcais/Quorum/issues/8 (even though
upstream seems dead).
  - Uploaded a package to disable LTO.

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

Re: OpenLDAP 2.6 transition

[Sergio Durigan Junior]

On Thursday, December 15 2022, Steve Langasek wrote:

> On Thu, Dec 15, 2022 at 07:15:21PM -0500, Sergio Durigan Junior wrote:
>> On Monday, November 21 2022, I wrote:
>
>> > On Monday, November 21 2022, Steve Langasek wrote:
>> >
>> >> On Mon, Nov 21, 2022 at 06:32:39PM -0500, Sergio Durigan Junior wrote:
>> >>> Hello,
>> >>
>> >>> This is a heads up that the OpenLDAP 2.6 transition has started.  I have
>> >>> just uploaded the package to lunar-proposed and will be performing
>> >>> no-change uploads to its reverse dependencies soon.
>> >>
>> >>> The list of packages that are going to be affected by this transition
>> >>> can be obtained by running:
>> >>
>> >>>   $ reverse-depends -r lunar src:openldap
>> >>
>> >>> I did a mass-rebuild of said packages in a bileto PPA and everything
>> >>> looks good (aside from some unrelated FTBFSes).
>> >>
>> >> I would ask you to hold off right now on doing no-change rebuilds of any
>> >> packages currently in -proposed.  There are in-progress language 
>> >> transitions
>> >> for perl, python, and R, and rebuilding all the openldap language bindings
>> >> right now will entangle all of those transitions and likely make it harder
>> >> to get them migrated.
>> >
>> > Ah, no problem.  It can wait.
>> >
>> >> Hopefully, the autopkgtest backlogs on arm64 and s390x will clear this 
>> >> week
>> >> and then we'll have a better view on what it takes to finish the above
>> >> in-progress transitions, and then rebuild anything still linking against
>> >> libldap-2.5-0.
>> >
>> > +1.  Thanks, and enjoy your PTO.
>
>> Perl and Python have migrated, so I will go ahead with the no-change
>> uploads tomorrow.
>
> FWIW seeing that these hadn't been done yet and openldap had migrated (so
> all of the reverse-dependencies were on the NBS report), I went ahead and
> did uploads today of a filtered list of reverse-dependencies, excluding any
> of those that are currently in -proposed.
>
> Uploading those other packages won't cause entanglements between any
> remaining transitions, but it may slow down the migration of some of them,
> so I didn't upload them - but if you want to upload them now, there's no
> fundamental reason you can't.
>
> Remaining packages would be:
>
> Package gvm-libs already present in lunar-proposed (but not fixed)
>  (Package gvm-libs not built in lunar-proposed)
> Package lua-apr already present in lunar-proposed (but not fixed)
>  (Package lua-apr not built in lunar-proposed)
> Package openscap already present in lunar-proposed (but not fixed)
> Rebuilding openscap
> Rebuilding postgresql-14
> Package sssd already present in lunar-proposed (but not fixed)
>  (Package sssd not built in lunar-proposed)
> Package uwsgi already present in lunar-proposed (but not fixed)
>  (Package uwsgi not built in lunar-proposed)
> Package virtuoso-opensource already present in lunar-proposed (but not fixed)
>  (Package virtuoso-opensource not built in lunar-proposed)
> Package wine already present in lunar-proposed (but not fixed)
>  (Package wine not built in lunar-proposed)
> Package wine-development already present in lunar-proposed (but not fixed)
>  (Package wine-development not built in lunar-proposed)
>
> This also gives you the list of reverse-dependencies that FTBFS.

Thanks, Steve.  I will start working on this list tomorrow.

Cheers,

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

Re: OpenLDAP 2.6 transition

[Sergio Durigan Junior]

On Monday, November 21 2022, I wrote:

> On Monday, November 21 2022, Steve Langasek wrote:
>
>> On Mon, Nov 21, 2022 at 06:32:39PM -0500, Sergio Durigan Junior wrote:
>>> Hello,
>>
>>> This is a heads up that the OpenLDAP 2.6 transition has started.  I have
>>> just uploaded the package to lunar-proposed and will be performing
>>> no-change uploads to its reverse dependencies soon.
>>
>>> The list of packages that are going to be affected by this transition
>>> can be obtained by running:
>>
>>>   $ reverse-depends -r lunar src:openldap
>>
>>> I did a mass-rebuild of said packages in a bileto PPA and everything
>>> looks good (aside from some unrelated FTBFSes).
>>
>> I would ask you to hold off right now on doing no-change rebuilds of any
>> packages currently in -proposed.  There are in-progress language transitions
>> for perl, python, and R, and rebuilding all the openldap language bindings
>> right now will entangle all of those transitions and likely make it harder
>> to get them migrated.
>
> Ah, no problem.  It can wait.
>
>> Hopefully, the autopkgtest backlogs on arm64 and s390x will clear this week
>> and then we'll have a better view on what it takes to finish the above
>> in-progress transitions, and then rebuild anything still linking against
>> libldap-2.5-0.
>
> +1.  Thanks, and enjoy your PTO.

Hi,

Perl and Python have migrated, so I will go ahead with the no-change
uploads tomorrow.

Thanks,

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

Re: Bind 9.16.1 crash on Ubuntu

[Sergio Durigan Junior]

On Thursday, December 08 2022, Ben Bridges wrote:

> Hi Robie (and Marc),
>
> I've never reported a bug to Ubuntu before.  I ran ubuntu-bug against
> the crash report and told it to send the report.  It appears to have
> uploaded it to the Ubuntu error tracker
> (https://errors.ubuntu.com/user/1be5ee847bb6c14eae7458cbbda7ac91a5fd65d5d01f3f9d3dbc4480e44712035ed9c455e3cf04ec7eeadf72dd7f5414771cff9ba752940658ff902749b175e9),
> but I don't know how to verify that it sent what it was supposed to
> send.  Please let me know if there's anything else I need to do.

Hello Ben,

First of all, thanks for the interest in making Ubuntu better by
reporting bugs.

This is a known issue and I've been on top of it for a while now:

https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1258003
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1970252

Upstream is also aware of the issue, but unfortunately the fix is very
complicated and isn't totally done yet.  There are several sub-issues
affecting dig, host and other bind9 commands.  But things are
progressing.

The good news is that the Server team has plans to work on getting bind9
into the MIR list.  Ultimately, this means that minor version
updates/bugfixes should be much easier to do for us.

Please feel free to subscribe yourself to the bugs I linked above.
There hasn't been much movement lately, but we will soon get back to
them.

Cheers,

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

-- 
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: Bind 9.16.1 crash on Ubuntu

[Sergio Durigan Junior]

On Friday, December 09 2022, Ben Bridges wrote:

> Hi Sergio,
>
> I appreciate the information.  Are you sure, though, that the bug(s)
> you referenced are the applicable bugs in my case?  The bugs you
> referenced appear to be problems with dig in 9.18 on jammy.  In my
> case, it was named itself version 9.16 on focal that crashed.

Ops, you're correct.  This is another bug, indeed.  It looks similar to
the one we're facing in Jammy, that's why I got confused.  Sorry about
the noise.

> What is the MIR list?

Sigh, yesterday wasn't a good day for me, apparently.  I should have
said "MRE list", sorry.  MRE means Micro Release Exception; it's an
exception given by the SRU team to allow micro/minor release updates of
packages that have already been released in previous Ubuntu series.
This is a good thing to have when upstream provides minor releases that
contain only bug fixes.

Either way, please file a bug against bind9 and I/we will take a look
into what's happening.  If you can provide a step-by-step reproducer for
the failure you're experiencing, that'd be great.

Thanks,

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

-- 
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: OpenLDAP 2.6 transition

[Sergio Durigan Junior]

On Monday, November 21 2022, Steve Langasek wrote:

> Hi Sergio,

Hi Steve,

> On Mon, Nov 21, 2022 at 06:32:39PM -0500, Sergio Durigan Junior wrote:
>> Hello,
>
>> This is a heads up that the OpenLDAP 2.6 transition has started.  I have
>> just uploaded the package to lunar-proposed and will be performing
>> no-change uploads to its reverse dependencies soon.
>
>> The list of packages that are going to be affected by this transition
>> can be obtained by running:
>
>>   $ reverse-depends -r lunar src:openldap
>
>> I did a mass-rebuild of said packages in a bileto PPA and everything
>> looks good (aside from some unrelated FTBFSes).
>
> I would ask you to hold off right now on doing no-change rebuilds of any
> packages currently in -proposed.  There are in-progress language transitions
> for perl, python, and R, and rebuilding all the openldap language bindings
> right now will entangle all of those transitions and likely make it harder
> to get them migrated.

Ah, no problem.  It can wait.

> Hopefully, the autopkgtest backlogs on arm64 and s390x will clear this week
> and then we'll have a better view on what it takes to finish the above
> in-progress transitions, and then rebuild anything still linking against
> libldap-2.5-0.

+1.  Thanks, and enjoy your PTO.

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

OpenLDAP 2.6 transition

[Sergio Durigan Junior]

Hello,

This is a heads up that the OpenLDAP 2.6 transition has started.  I have
just uploaded the package to lunar-proposed and will be performing
no-change uploads to its reverse dependencies soon.

The list of packages that are going to be affected by this transition
can be obtained by running:

  $ reverse-depends -r lunar src:openldap

I did a mass-rebuild of said packages in a bileto PPA and everything
looks good (aside from some unrelated FTBFSes).

Thanks,

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


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

Re: +1 maintenance report

[Sergio Durigan Junior]

On Friday, October 21 2022, Steve Langasek wrote:

> Hi Sergio,

Hello,

> On Fri, Oct 21, 2022 at 06:47:09PM -0400, Sergio Durigan Junior wrote:
>> * cryfs
>>   - FTBFS on ppc64el due to RLIMIT_MEMLOCK being too low.
>>   - After spending some time playing with setrlimit et al, it's clear to
>> me that the problem cannot be easily fixed in the source code.  I
>> believe we will need to increase RLIMIT_MEMLOCK in the ppc64el
>> builders.
>>   - Debian isn't affected by this problem.
>>   - There's also an s390x dep8 failure, which is also affecting Debian.
>> I opened an upstream issue.
>>   - https://bugs.launchpad.net/ubuntu/+source/cryfs/+bug/1993578
>
> Is there any reason not to instead change the package to skip these tests
> when RLIMIT_MEMLOCK is too low (which seems detectable)?

My initial reason would be that the package is in universe and in sync
with Debian.  On top of that, after reading #ubuntu-devel's log, it
seems like we've encountered similar situations where RLIMIT_MEMLOCK got
in the way.  As far as I have investigated, these other cases were
solved (correctly) by using setrlimit to properly extend RLIMIT_MEMLOCK
when needed, but the packages in question had the necessary capabilities
to do that.  cryfs doesn't.

Since cryfs in Debian doesn't suffer from this problem, and given that,
based on local experiments, the RLIMIT_MEMLOCK value necessary to
trigger this problem seems rather low, I think it's worth at least
considering increasing it in our ppc64el builders.

Please take the above with more than a grain of salt, since I obviously
don't have access to our builders and didn't try to do a deep-dive into
how their resource limits are configured.

Thanks,

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

+1 maintenance report

[Sergio Durigan Junior]

Investigations
==

* spaln
  - Upstream (and therefore Debian) dropped support for 32-bit
architectures, so the armhf binary had to be removed.
  - On top of that, there as an FTBFS happening on riscv64 due to LTO.
"Fixed" in Debian (with the proper "LP:..." mark).  The fix should
land in Ubuntu when the archive reopens.
  - https://bugs.launchpad.net/ubuntu/+source/spaln/+bug/1993202

* cryfs
  - FTBFS on ppc64el due to RLIMIT_MEMLOCK being too low.
  - After spending some time playing with setrlimit et al, it's clear to
me that the problem cannot be easily fixed in the source code.  I
believe we will need to increase RLIMIT_MEMLOCK in the ppc64el
builders.
  - Debian isn't affected by this problem.
  - There's also an s390x dep8 failure, which is also affecting Debian.
I opened an upstream issue.
  - https://bugs.launchpad.net/ubuntu/+source/cryfs/+bug/1993578

* luajit2
  - Debian has removed ppc64el from the list of supported architectures
for this package.  We need to make sure this change is also
reflected in Ubuntu.  I left a message on #ubuntu-release asking for
an AA to act on it.  Also filed the bug below, and subscribed
~ubuntu-release.
  - https://bugs.launchpad.net/ubuntu/+source/luajit2/+bug/1993752

* loggerhead
  - Filed a bug against the Debian package and provided a patch to fix
the current autopkgtest issue.
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022140
  - Also update the details on our bug:
  - https://bugs.launchpad.net/debian/+source/loggerhead/+bug/1991613

* osslsigncode
  - FTBFS on s390x; tests failing due to endianess.  There a Debian and
an upstream bugs filed for this, and an upstream PR is open.  I
filed a bug on our side to keep track of this.
  - https://bugs.launchpad.net/ubuntu/+source/osslsigncode/+bug/1993757

* bpftrace
  - FTBFS because one of the binaries isn't being compiled.  This
doesn't affect Debian.
  - I tracked it down to a missing bpftool binary package in the
archive.  This has been reported already.
  - https://bugs.launchpad.net/ubuntu/+source/bpftrace/+bug/1981089
  - Added bpftrace as one of the affected packages in the bug above.

* ipykernel
  - FTBFS on amd64 due to missing dependency: python3-debugpy.
  - python3-debugpy is FTBFSing as well, including on Debian.
  - Filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022188.
  - Also:
https://bugs.launchpad.net/ubuntu/+source/debugpy/+bug/1993849.

* resampy
  - Failing to test on s390x, possibly due to endianess.
  - This has been reported against Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019101
  - The Debian maintainer said he's waiting to obtain access to a
porterbox so that he can work on this.  I will contact him and see
if I can help in any way.
  - I filed our own bug to keep track of the failure.
  - https://bugs.launchpad.net/debian/+source/resampy/+bug/1993858

* golang-github-containerd-stargz-snapshotter
  - FTBFSing on Ubuntu, but not on Debian, which is strange.
  - I've started investigating it but couldn't progress much further
before my EOW.

Misc


Some retriggers here and there, nothing really important.

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

Re: New service announcement: https://debuginfod.ubuntu.com

[Sergio Durigan Junior]

On Thursday, September 15 2022, Dan Streetman wrote:

> Hurray!
>
> Awesome to see this arrive, even if it's slightly after I left Canonical xD
>
> Thanks for the hard work setting this up for Ubuntu (and Debian)!

Thanks, Dan!  And thanks for the support and encouragement while you
were still working here ;-).

Cheers,

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

New service announcement: https://debuginfod.ubuntu.com

[Sergio Durigan Junior]

[ Sending to ubuntu-devel as well.  ]

Hello,

I would like to announce a new service for the Ubuntu community: an
instance of debuginfod, running at https://debuginfod.ubuntu.com.

Debuginfod is a project whose purpose is to serve ELF/DWARF/source-code
information over HTTP(S).  In a nutshell, by using a debuginfod service
you will not need to install debuginfo (a.k.a. ddebs) packages anymore;
the symbols will be served to GDB (or any other debuginfo consumer that
supports debuginfod) over the network.

I consider the service to be in a beta state right now.  There are no
plans for outages or anything drastic, but I don't want to promise a
99.% uptime either.  I am constantly working to improve the
deployment and it will be very interesting to see how it will cope with
real usage after this announcement hits the news.

Our debuginfod instance will be serving debug symbols for all currently
supported releases of Ubuntu, plus the development version.  All
repositories are supported: main, universe, restricted and multiverse.

If you are using an Ubuntu release that still doesn't have automatic
configuration for the service, you can easily set up your system to use
it by exporting the DEBUGINFOD_URLS shell variable, like this (assuming
you are using Bash as your shell):

  export DEBUGINFOD_URLS="https://debuginfod.ubuntu.com;

If you would like to know more about the service, including a more
detailed explanation on how to set it up, I strongly encourage you to
visit the Ubuntu Server Guide's page on debuginfod:

  https://ubuntu.com/server/docs/service-debuginfod

There is also a FAQ available, where I am gradually answering questions
that the community might have:

  https://ubuntu.com/server/docs/service-debuginfod-faq

I would like to thank everybody who helped me set this up.  The list is
long to write here, but you certainly know who you are.

Thank you, and enjoy!

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


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

New service announcement: https://debuginfod.ubuntu.com

[Sergio Durigan Junior]

Hello,

I would like to announce a new service for the Ubuntu community: an
instance of debuginfod, running at https://debuginfod.ubuntu.com.

Debuginfod is a project whose purpose is to serve ELF/DWARF/source-code
information over HTTP(S).  In a nutshell, by using a debuginfod service
you will not need to install debuginfo (a.k.a. ddebs) packages anymore;
the symbols will be served to GDB (or any other debuginfo consumer that
supports debuginfod) over the network.

I consider the service to be in a beta state right now.  There are no
plans for outages or anything drastic, but I don't want to promise a
99.% uptime either.  I am constantly working to improve the
deployment and it will be very interesting to see how it will cope with
real usage after this announcement hits the news.

Our debuginfod instance will be serving debug symbols for all currently
supported releases of Ubuntu, plus the development version.  All
repositories are supported: main, universe, restricted and multiverse.

If you are using an Ubuntu release that still doesn't have automatic
configuration for the service, you can easily set up your system to use
it by exporting the DEBUGINFOD_URLS shell variable, like this (assuming
you are using Bash as your shell):

  export DEBUGINFOD_URLS="https://debuginfod.ubuntu.com;

If you would like to know more about the service, including a more
detailed explanation on how to set it up, I strongly encourage you to
visit the Ubuntu Server Guide's page on debuginfod:

  https://ubuntu.com/server/docs/service-debuginfod

There is also a FAQ available, where I am gradually answering questions
that the community might have:

  https://ubuntu.com/server/docs/service-debuginfod-faq

I would like to thank everybody who helped me set this up.  The list is
long to write here, but you certainly know who you are.

Thank you, and enjoy!

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


signature.asc
Description: PGP signature
-- 
ubuntu-devel-announce mailing list
ubuntu-devel-announce@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce

Re: +1 maintenance report

[Sergio Durigan Junior]

On Friday, July 22 2022, Steve Langasek wrote:

> Hi Sergio,

Hello,

Sorry for the delay.  I was travelling and then on medical leave.

> I notice in this report that most of the items you worked on requiring
> source changes have Debian bugs or MPs as references, but there is no
> mention of what is done to get them resolved in Ubuntu.  We want to push
> fixes upstream to Debian and minimize unnecessary delta, but the purpose of
> +1 maintenance is to resolve items in the devel-proposed queue.  As long as
> these packages remain in -proposed, there's a cost to the team (both in
> terms of contributing to longer britney run times, and in retreading
> packages in the queue that have already been looked at).

As I understand it, we are constantly trying to unblock packages from
-proposed while at the same time judging whether it makes sense to add
extra delta that will inevitably be carried forward for some time,
especially when we are dealing with packages in universe.

This specific +1 shift was done mid-cycle, and as it turned out I ended
up working (coincidentally) on issues that also affected the Debian
packages, so I made a judgment call and considered it better to try and
fix problems there first knowing that the fixes will eventually reach
Ubuntu (because none of the packages I worked on had any pre-existing
delta).

On top of what I said above, there is also the fact that +1 maintenance
reports seem to be meant to provide guidance for the person who is going
to be on shift during the following week.  My report is not the only one
to mention a lot of Debian work that will eventually need to be followed
up later.

> Can you elaborate how each of these package fixes are getting into Ubuntu,
> and where the progress is being tracked?

I am not entirely sure I understand the question, but I will try my best
to answer.

Each of these fixes are getting into Ubuntu ideally when the respective
Debian maintainers accept the proposed changes and perform the
corresponding uploads.  If that doesn't happen before the final freeze,
I/we can certainly pick the fixes up and upload them to Ubuntu.

I was unsure whether I should file an Ubuntu-specific bug for each fix,
so I decided not to do so in order not to pollute our bug tracking
system.  So, for now, the progress for each of these issues is being
tracked in the respective links I posted (BTS, salsa, upstream repo,
etc).  I am subscribed to all of them, and get notified whenever there
is an update.

Arguably, I should have probably filed corresponding Ubuntu bugs (tagged
update-excuse) for each of these issues.  This is a workflow improvement
that I am considering for the next shift.

>> Investigations
>> ==
>>
>> * barectf
>>   - s390x dep8 test is failing.  According to upstream, the testsuite
>> requires a little-endian architecture.
>>   - https://salsa.debian.org/debian/barectf/-/merge_requests/1

This hasn't been accepted by the Debian maintainer yet.  I left a ping.

>> * python-django-celery-results
>>   - The tests are failing because python-psycopg2cffi is still at
>> version 2.8.1, the minimum required version is 2.8.4.  There's a new
>> upstream version (2.9.0) available.
>>   - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014827

No response yet.  This will likely demand a bit of work, so I truly
believe it should be done in Debian.

>> * r-cran-vegan
>>   - Tests are failing because the dep8 unit test script assumes that
>> every upstream test will have a corresponding ".save" output file
>> that can be used to compare the results against, but that's not the
>> case.
>>   - https://salsa.debian.org/r-pkg-team/r-cran-vegan/-/merge_requests/1

Merged and uploaded.  Fixed.

>> * r-cran-tmb & r-cran-glmmtmb
>>   - The problem is that r-cran-glmmtmb needs to be rebuilt with the
>> newest r-cran-tmb, but hasn't.  There was an upload to Debian
>> unstable with the purpose of rebuilding the package, but I believe
>> it was made too soon and the build ended up using the old version of
>> r-cran-tmb.
>>   - 
>> https://tracker.debian.org/news/1345185/accepted-r-cran-glmmtmb-113-3-source-into-unstable/

Rebuilt.  Fixed.

>> * tpot
>>   - Build failing due to a testcase issue.  I found a PR upstream that
>> fixes the problem.
>>   - https://salsa.debian.org/science-team/tpot/-/merge_requests/1
>>   - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014618#10

No response yet.  Left a ping.

>> * sbcl
>>   - As Athos mentioned
>> (https://lists.ubuntu.com/archives/ubuntu-devel/2022-July/042200.html),
>> we're starting to work on bootstrapping sbcl on ppc64el.
>>   - Unfortunately we've hit some bumps...  The build is mysteriously
>> segfaulting on ppc64el in a PPA.  So we're investigating things
>> before proceeding with the upload.

This is finished.

Thank you,

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

-- 
ubuntu-devel mailing list

Re: +1 maintenance report

[Sergio Durigan Junior]

On Wednesday, July 13 2022, I wrote:

> * sbcl
>   - As Athos mentioned
> (https://lists.ubuntu.com/archives/ubuntu-devel/2022-July/042200.html),
> we're starting to work on bootstrapping sbcl on ppc64el.
>   - Unfortunately we've hit some bumps...  The build is mysteriously
> segfaulting on ppc64el in a PPA.  So we're investigating things
> before proceeding with the upload.

I actually forgot to mention a very interesting case that Athos and I
faced while working on the sbcl bootstrap.

The dep8 test for the osicat package was initially failing on amd64 and
blocking sbcl from migrating, so we started checking what could be
happening.  Strangely, the failing test had to do with a check for a
non-existent username in the system; this check (performed using the
'(user-info)' call) was returning a valid user instead of nil.

Neither Athos nor I were able to reproduce this problem locally, even
after trying several incantations when invoking autopkgtest.  I also
tried checking if the problem would manifest on canonistack, to no
avail.  An autopkgtest run against a PPA build also succeeded.  We were
really puzzled by this.

All in all, we spent several hours building and testing the package, and
every time it succeeded.  I performed a no-change upload in the hopes
that rebuilding the package would have an effect on the test result, but
it didn't.  I was running out of ideas (and energy) when, by Monday
night, I started suspecting that the root cause could be the fact that
the trigger list for the failing tests had only sbcl in it.  I decided
to retrigger the test passing sbcl *and* osicat in the trigger list, and
it finally succeeded.

I have absolutely no idea what happened, and I don't have access to
autopkgtest's infrastructure in order to debug the problem.  But I
thought I'd mention this very strange case here just in case someone
faces a similar scenario.

Thanks,

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

+1 maintenance report

[Sergio Durigan Junior]

I've been on +1 maintenance shift from Monday to Wednesday.  I'm also
working on my DebConf presentation & debuginfod in parallel.

Retriggers that worked
==

sqlite> SELECT DISTINCT test.package, result.version, result.triggers
sqlite> FROM result INNER JOIN test ON test.id = result.test_id WHERE
sqlite> result.requester = 'sergiodj' AND result.exitcode = 0 AND result.run_id
sqlite> LIKE '2022071%';

starjava-connect|0.1+2020.10.01-1|ant/1.10.12-3
starjava-array|0.2+2022.03.23-1|ant/1.10.12-3
starjava-fits|0.1+2022.05.13-1|ant/1.10.12-3
starjava-table|4.1.1-1|ant/1.10.12-3
starjava-topcat|4.8.5-1|ant/1.10.12-3
starjava-util|1.0+2022.06.09-1|ant/1.10.12-3
starjava-vo|0.2+2022.01.20-2|ant/1.10.12-3
starjava-votable|2.0+2022.04.04-1|ant/1.10.12-3
starjava-ttools|3.4.5-1|ant/1.10.12-3
osicat|0.7.0+git20220117.a45eb3b-1build1|sbcl/2:2.2.3-2 
osicat/0.7.0+git20220117.a45eb3b-1build1

Retriggers that didn't work
===

sqlite> SELECT DISTINCT test.package, result.version, result.triggers
sqlite> FROM result INNER JOIN test ON test.id = result.test_id WHERE
sqlite> result.requester = 'sergiodj' AND result.exitcode != 0 AND result.run_id
sqlite> LIKE '2022071%';

osicat|0.7.0+git20220117.a45eb3b-1|sbcl/2:2.2.3-2
osicat|0.7.0+git20220117.a45eb3b-1build1|sbcl/2:2.2.3-2
python-django-celery-results|2.3.1-1|python-django-celery-results/2.3.1-1
tinyssh|20220311-2|tinyssh/20220311-2
r-cran-vegan|2.6-2+dfsg-1|r-cran-vegan/2.6-2+dfsg-1
golang-github-klauspost-compress|1.15.4+ds1-1|golang-github-klauspost-compress/1.15.4+ds1-1

Investigations
==

* barectf
  - s390x dep8 test is failing.  According to upstream, the testsuite
requires a little-endian architecture.
  - https://salsa.debian.org/debian/barectf/-/merge_requests/1

* python-django-celery-results
  - The tests are failing because python-psycopg2cffi is still at
version 2.8.1, the minimum required version is 2.8.4.  There's a new
upstream version (2.9.0) available.
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014827

* r-cran-vegan
  - Tests are failing because the dep8 unit test script assumes that
every upstream test will have a corresponding ".save" output file
that can be used to compare the results against, but that's not the
case.
  - https://salsa.debian.org/r-pkg-team/r-cran-vegan/-/merge_requests/1

* r-cran-tmb & r-cran-glmmtmb
  - The problem is that r-cran-glmmtmb needs to be rebuilt with the
newest r-cran-tmb, but hasn't.  There was an upload to Debian
unstable with the purpose of rebuilding the package, but I believe
it was made too soon and the build ended up using the old version of
r-cran-tmb.
  - 
https://tracker.debian.org/news/1345185/accepted-r-cran-glmmtmb-113-3-source-into-unstable/

* tpot
  - Build failing due to a testcase issue.  I found a PR upstream that
fixes the problem.
  - https://salsa.debian.org/science-team/tpot/-/merge_requests/1
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014618#10

* sbcl
  - As Athos mentioned
(https://lists.ubuntu.com/archives/ubuntu-devel/2022-July/042200.html),
we're starting to work on bootstrapping sbcl on ppc64el.
  - Unfortunately we've hit some bumps...  The build is mysteriously
segfaulting on ppc64el in a PPA.  So we're investigating things
before proceeding with the upload.

* liburing
  - Tests were in a broken state (still running after 13+ days).  I sent
a message to #ubuntu-devel and bdmurray kindly looked into the issue.

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


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

Re: Bileto

[Sergio Durigan Junior]

On Monday, June 06 2022, Dan Streetman wrote:

> On Mon, Jun 6, 2022 at 5:18 PM Sergio Durigan Junior
>  wrote:
>>
>> On Thursday, June 02 2022, Dan Streetman wrote:
>>
>> > How do I get access to bileto? Everyone in canonical product engineering
>> > seems to use this system but I've never had access. Is it restricted to
>> > only some canonical employees?
>>
>> Hey Dan,
>>
>> I remember gaining access to bileto automatically when I became a Core
>> Dev.  I didn't have to ask permission to anyone.
>
> Looking at the LP team that (I think?) controls Bileto access, i.e.
> ~bileto-users, I appear to be already in that team...which I never
> realized. However, I've even if I do magically have access to use
> Bileto, I never knew that, and I still don't know how I can actually
> 'use' (i.e. upload anything to) it...
>
> is there some docs on how to 'use' bileto?

There's https://wiki.ubuntu.com/Bileto, but I always found the page to
be a bit confusing if you just want to build & test your changes (which
is all I do with Bileto).

Here's what I do:

- After logging in, click on "Create New Ticket".  Give it a Description
  (usually the name of the package(s) being tested) and provide a Test
  Plan (I personally just write "dep8" in this field).  Choose the
  "Target Series" for this ticket.

- After the ticket is created, click on "Build" and then on "Build
  Packages".  This will create a new PPA associated with your ticket,
  where you can upload the package(s) you want to build.

- After you upload the package(s) and they've been accepted by the PPA,
  you can click on "Diff" and then "Regenerate Diffs".  This is a
  necessary step in order to have Bileto run dep8.

- After the PPA has finished building & publishing, and if everything
  looks good to you, you can set the "Lander Signoff" field to
  "Approved".  This will let Bileto know that it can proceed with the
  dep8 tests.

- If everything is working OK, after a while (which can be a long time)
  you will see links under the "Automated Test Results" field which will
  contain the dep8 results.

That's about it.

I know other people use Bileto for more complex stuff, but the above is
all I need.  Bileto is really great to have an idea of how a transition
will unfold because it automatically tests everything related to the
package you're building (i.e., it runs the dep8 tests for the package(s)
and their rdeps).  I don't recommend using it for a single package
upload/test, though; a regular PPA is more than enough for it.

HTH,

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

-- 
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: Sending LTO delta to Debian

[Sergio Durigan Junior]

On Thursday, May 05 2022, Andreas Hasenack wrote:

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

TBH I think it depends on the Debian maintainer.  I myself will gladly
accept a patch disabling LTO in Debian if it's been identified that LTO
will break my package, even if it's just to make things easier for the
derivative distro's (Ubuntu usually, but can be others) maintainer
(given that the patch will be a no-op in Debian, as you mentioned).  But
I'm talking about a simple d/rules patch that will just touch
DEB_BUILD_MAINT_OPTIONS...

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

... this, OTOH, is more involved.

Using "=XYZ" after "optional", in my experience, is only informational.
If a symbol disappears, it will be reported even if it's marked as
optional:

  
https://git.dpkg.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Shlibs/Symbol.pm#n485

But dpkg-gensymbols won't make the distinction between "this symbol
disappeared because of LTO" vs. "this symbol disappeared, period".

With my DD hat on, I'd say that I probably wouldn't be happy accepting
such a patch because it's much easier to introduce problems due to the
fact that the symbol will be marked as optional regardless of the
reason, but really shouldn't.

Thanks,

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

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

[Sergio Durigan Junior]

On Friday, April 29 2022, Andreas Hasenack wrote:

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

Thanks, Andreas.  I've subscribed myself to the bug, let's see how it
unfolds.

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

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

[Sergio Durigan Junior]

On Friday, April 29 2022, 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.

Just reiterating what I told you during standup, this leakage is wrong
and should be fixed in krb5's pkg-config definitions.

Some interesting things to consider here:

- Debian/Ubuntu differ from Fedora in the sense that we specify the LTO
  flags during link time as well (LDFLAGS), while Fedora only specifies
  them during compile time.  GCC can auto-detect LTO bytecode during
  link time and will do the right thing even if no LTO flags are passed
  (as long as we use GCC to perform the link, which we do).  So in
  theory we could remove the "-flto -ffat-lto-objects" from our LDFLAGS
  and still have LTO-enabled binaries.

- As a direct consequence of the above, the exact same command yields a
  different result in Fedora, even though they also have LTO enabled.

- GCC will also be smart enough when mix & matching object files and
  libraries that were compiled with and without LTO, so no worries
  here.

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.

Thanks,

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

Re: First Jammy Jellyfish test rebuild

[Sergio Durigan Junior]

On Friday, January 14 2022, Graham Inggs wrote:

> On Thu, 13 Jan 2022 at 23:11, Sergio Durigan Junior  
> wrote:
>> While at it, there's this annoying bug that happens when the packageset
>> and the team names are the same; in this case, the internal links will
>> point to the same place as well (packageset currently, because that's
>> what comes first in the list).
>>
>> I filed an MP to fix it:
>> https://code.launchpad.net/~sergiodj/lp-ftbfs-report/+git/lp-ftbfs-report/+merge/414130
>
> Thanks for that!  The latest version of the reports were generated
> with your fix in place and now clicking on ubuntu-server in packageset
> and teams takes you to the correct place.

Thank you, Graham!

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

Re: First Jammy Jellyfish test rebuild

[Sergio Durigan Junior]

On Thursday, January 13 2022, Christian Ehrhardt wrote:

> thanks for that work!

Seconded.

> I've found two details I wanted to ask about ...

While at it, there's this annoying bug that happens when the packageset
and the team names are the same; in this case, the internal links will
point to the same place as well (packageset currently, because that's
what comes first in the list).

I filed an MP to fix it:
https://code.launchpad.net/~sergiodj/lp-ftbfs-report/+git/lp-ftbfs-report/+merge/414130

Thanks,

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

+1 maintenance report

[Sergio Durigan Junior]

I've been on +1 maintenance part of this week (from Tuesday to Friday).
Unfortunately, due to a combination of meetings + other work priorities
+ some personal stuff I wasn't able to dedicate as much time as I
initially planned.

Retriggers that worked
==

sqlite> SELECT DISTINCT test.package, result.version, result.triggers FROM 
result INNER JOIN test ON test.id = result.test_id WHERE result.requester = 
'sergiodj' AND result.exitcode = 0 AND result.run_id LIKE '2022010%';
lebiniou-data|3.64.0-1|lebiniou-data/3.64.0-1
asterisk|1:16.16.1~dfsg-4build1|systemd/249.5-2ubuntu3 dpdk/21.11-1
cluster-glue|1.0.12-20ubuntu2|curl/7.81.0-1
ceph|16.2.7-0ubuntu1|binutils/2.37.50.20220106-2ubuntu1
asterisk|1:16.16.1~dfsg-4build1|curl/7.81.0-1
tang|11-1|curl/7.81.0-1
apt|2.3.13|dpkg/1.21.1ubuntu1
casper|1.465|finalrd/9
pkg-js-tools|0.10.3|dpkg/1.21.1ubuntu1
node-redis|3.1.2+~cs6.15.1-1|pkg-js-tools/0.10.5
python-parsel|1.6.0+dfsg-3|lxml/4.6.4-1ubuntu1
python-oslo.vmware|3.10.0-0ubuntu1|lxml/4.6.4-1ubuntu1
dvisvgm|2.12-4|lxml/4.6.4-1ubuntu1
node-labeled-stream-splicer|2.0.2+~2.0.0-1|node-labeled-stream-splicer/2.0.2+~2.0.0-1
node-grunt-contrib-copy|1.0.0-4|pkg-js-tools/0.10.5
python3.9|3.9.9-2|readline/8.1.2-1
macaulay2|1.19.1+ds-4|readline/8.1.2-1

Retriggers that didn't work
===

sqlite> SELECT DISTINCT test.package, result.version, result.triggers FROM 
result INNER JOIN test ON test.id = result.test_id WHERE result.requester = 
'sergiodj' AND result.exitcode != 0 AND result.run_id LIKE '2022010%';
exim4|4.95-2ubuntu2|systemd/249.5-2ubuntu3 dpdk/21.11-1
pg-fact-loader|1.6.0-5|pglogical/2.4.1-1
golang-github-komkom-toml|0.0~git20211215.3c8ee9d-1|golang-github-komkom-toml/0.0~git20211215.3c8ee9d-1
mediawiki|1:1.35.5-1|mediawiki/1:1.35.5-1 postgresql-14/14.1-5 curl/7.81.0-1 
php8.1/8.1.1-4 openssl/3.0.1-0ubuntu1 php-defaults/91 ocamlnet/4.1.8-3
python-pypowervm|1.1.24-0ubuntu1|lxml/4.6.4-1ubuntu1
node-chokidar|3.4.3-3|node-is-binary-path/2.1.0-4
gtk4|4.4.1+ds1-3|mesa/21.3.3-1
dpdk|20.11.3-0ubuntu3|hwdata/0.355-1
dgit|9.15|sqlite3/3.37.2-1 diffoscope/198 php-doctrine-cache/2.1.1-2 
supysonic/0.6.2+ds-4
pyopencl|2021.2.9-1|mesa/21.3.3-1

Investigations
==

kma & kmerresistance


Debian dropped support for 32-bit architectures on kma.  This required
manual intervention from the AAs in order to deleted the old armhf
binaries and make the package migrate.  I requested this, and cjwatson
pointed out that kmerresistance was actually a rdep that needed to be
fixed first.  I noticed the fix was available in the salsa repo but
never got uploaded.  Got in touch with the author, he had just forgotten
about it.  Uploaded the fix to Debian, which got sync'ed to Ubuntu, but
didn't solve the problem because we still had kma's armhf binary
available in -release.  I decided to patch kmerresistance and just use
the same Architecture line as kma in d/control.  This finally solved the
problem, and the two packages finally migrated (kma had been stuck in
-proposed for more than 80 days, IIRC).

dnsdbq
--

Package is FTBFS'ing due to changes in glibc 2.34.  I filed
https://bugs.launchpad.net/dnsdbq/+bug/1956639 and
https://github.com/dnsdb/dnsdbq/issues/198.  Upstream is willing to
accept a temporary solution to fix the issue; I will file a PR soon.

libsdl & osk-sdl
-

osk-sdl's autopkgtest is failing with libsdl >= 2.0.18.  This is also
impacting the Debian package, and there's an upstream bug where a
discussion is happening.  I filed
https://bugs.launchpad.net/debian/+source/osk-sdl/+bug/1956534.  I've
just got notified that the bug has been fixed in Debian, which means
that it will likely be fixed in Ubuntu as well.  I will monitor the
situation and close the Ubuntu bug if everything is OK.

guile-3.0
-

guile-3.0 is FTBFS'ing with glibc 2.34.  There's an upstream bug which
has apparently been fixed, but is not present in any release yet.  I
filed https://bugs.launchpad.net/ubuntu/+source/guile-3.0/+bug/1956636.
I chose not to backport the upstream patch that fixed the problem
because it's a really long diff (gnulib update, for those who are
curious), so I will just wait until the fix is released, packaged into
Debian, and then the bug can be safely closed.

python-aioamqp
--

autopkgtest fails due to python-pamqp 2->3 transition.  Upstream seems a
bit abandoned, but there's a PR to fix the issue and it seems OK.  I
backported the patch to the Debian package and did the upload.
Eventually this will be fixed in Ubuntu.


Thanks,

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

Re: Heads up: OpenSSL3 transition

[Sergio Durigan Junior]

On Wednesday, November 17 2021, Simon Chopin wrote:

> Hi all,

Hey Simon,

Thanks for your work on this, BTW.  Much appreciated :-).

> You might have noticed that the OpenSSL 3 transition was supposed to get
> started a couple of weeks ago. As usual with these things, it slipped
> away as there were some issues with packages in main that needed to be
> resolved first. Now that it's mostly sorted out, I'm planning on (asking
> nicely someone to) upload the new version of OpenSSL later this week or
> early next week, unless someone raises an objection?

I'd like to raise something.  I apologize for sending this message in
such short notice.

I am working on net-snmp, squid and a few other packages during this
transition, and I am feeling concerned with how uncomfortable some of
our upstreams seem to be regarding their patches to support OpenSSL 3.
I can mention a few cases here.

net-snmp has a patch to support OpenSSL 3 in theory, but they are still
discussing a few details here:
https://github.com/net-snmp/net-snmp/issues/294 .  It seems like they
have sorted out most of the issues so far, which is good, but I'm still
not 100% confident in backporting their patch yet.

squid has an open pull request with a bunch of changes needed to support
OpenSSL 3.  The patches backport and build OK on Jammy, but upstream is
still looking for more reviewers/testers before they merge the PR.  I
decided to run some tests here and give them some feedback, and one of
the things I wanted to do was to run autopkgtest with their patches
applied.  That led me to the discovery that apache2's mod-ssl doesn't
work with OpenSSL 3 either, so I filed a bug for it.

apache2 also has an open PR to implement OpenSSL 3 support for the 2.4.x
series.  They've apparently found a regression on OpenSSL while testing
things in Fedora (https://github.com/openssl/openssl/issues/15946), and
I found the following thread which is an interesting read:

  https://www.mail-archive.com/dev@httpd.apache.org/msg75615.html

While it should be possible to backport the upstream patches and make
things build, I'm not entirely sure if this is the right way forward
here.  I don't want to suggest that we postpone anything, but I thought
it would be good to raise these issues here.

Thanks,

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

Re: git-ubuntu rich history beta

[Sergio Durigan Junior]

On Wednesday, October 13 2021, 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!
[...]
> # Caveats
>
>  * Note that error paths are not currently well handled. I intend to fix
>these before a final release. I'd appreciate feedback on what edge
>cases you hit, so I can make sure I handle those.

Thanks for working on this.

As I've mentioned during our meeting earlier today, I'm not sure the
folowing can be characterized as a problem or not, but it's something
that I think is worth considering.

I noticed that prepare-for-upload doesn't force-push a branch.  In most
cases this is fine because you will use the command only when preparing
the final upload, which will hopefully be accepted and then there's
nothing else you need to do.  However, in specific scenarios this
limitation gets in the way a little bit.

For example, when you prepare an SRU upload but the SRU team requests a
few changes to the package before accepting it.  For me, this involves
going back to the branch you're developing the SRU fix on, rewriting its
history, and then preparing the upload again.  I remember doing this at
least on two occasions, and then invoking prepare-for-upload would lead
to an error because it wouldn't force-push the changes to the repo.

The error displayed comes from git, so it's simple to understand and
fix: I just had to manually run "git push pkg branchname --force".
However, it would have been nice to have git-ubuntu do that for me.
Maybe, as you mentioned, we could have a "--force-push" option that can
be passed to prepare-for-upload (I think only "--force" is too simple
and maybe ambiguous here).

Thanks,

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

+1 maintenance report

[Sergio Durigan Junior]

This week has been my +1 maintenance shift.  I had some interruptions
here and there during the week, but here's what I did:

* Retriggers

I didn't do many retriggers over the week; I preferred to focus on
investigating and solving bugs.  Here are the successful retriggers I
did (there are a few unsuccessful ones that I'm not listing here).

Package: cluster-glue [amd64]
Package: cluster-glue [impish/s390x]
Package: fence-agents [impish/armhf]
Triggers: libxml2/2.9.12+dfsg-2
Status: PASSED

Package: ruby-libxml [impish/amd64]
Package: ruby-libxml [impish/arm64]
Package: ruby-libxml [impish/armhf]
Package: ruby-libxml [impish/ppc64el]
Package: ruby-libxml [impish/s390x]
Triggers: ruby-libxml/3.2.0-1ubuntu1 libxml2/2.9.12+dfsg-2
Status: PASSED

Package: kopanocore [impish/amd64]
Triggers: libical3/3.0.10-1
Status: PASSED

Package: wcc [impish/amd64]
Triggers: openssh/1:8.4p1-6ubuntu1
Status: PASSED

Package: libreoffice [impish/amd64]
Triggers: openjdk-16/16.0.2+7-2
Status: PASSED

Package: kopanocore [impish/armhf]
Triggers: python3.9/3.9.7-1
Status: PASSED

* Investigation

** ruby-libxml

- https://bugs.launchpad.net/ubuntu/+source/ruby-libxml/+bug/1942130

A bunch of failures due to some libxml2 upstream changes.  I fixed them
all and also forwarded whatever was necessary to upstream.

** thin

- 
https://code.launchpad.net/~sergiodj/ubuntu/+source/thin/+git/thin/+merge/407931

this is the oldest blocked package on update_excuses.  I found the
problem and submitted an MP for the Ubuntu package as well as a PR for
upstream, but we decided to wait to hear what upstream thinks about the
proposal before going ahead and uploading.  I will wait until next week,
and if there's no feedback from upstream I will revive the MP.

** mpich

- https://bugs.launchpad.net/ubuntu/+source/mpich/+bug/1942265

Problem with GCC-11/GFortran.  Uploaded fix to Ubuntu and also forwarded
the patch to the Debian package.

** docker.io & glibc

- https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1942276 & 
https://github.com/tianon/debian-docker/pull/12
- https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1942276

This one was interesting.  I was able to reproduce the issue locally,
and after some investigation it became clear that the issue was not on
docker.io itself.  Eventually, we found that this was actually a glibc
bug at play.  I've added the glibc component to the bug and started an
attempt to investigate what was actually going on.  I felt I was on the
right track, but mwhudson beat me to it and came up with a fix that was
later approved & uploaded.

** golang-github-go-resty-resty: 
https://bugs.launchpad.net/ubuntu/+source/golang-github-go-resty-resty/+bug/1942491
** golang-github-google-martian: 
https://bugs.launchpad.net/ubuntu/+source/golang-github-google-martian/+bug/1942639

These two packages have been blocking golang-golang-x-net from migrating
for 103 days.  I investigated and tracked down the problem: both
packages were being affected by proxy issues.  After some though on how
to best deal with this, I decided to hack their d/rules, override
dh_auto_test and unset $http_proxy (anything else would involve patches
and more complex things).  Aside from workarounding the problem, the
other positive outcome here was to set up a local container with squid
in order to reproduce these dreaded proxy failures (instead of resorting
to building packages on a PPA and then running autopkgtest there).

Thanks,

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


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

+1 maintenance report

[Sergio Durigan Junior]

This week was my +1 maintenance shift, and I was shadowed by Athos (who
will send a separate report).

Here's what I did.

* Retriggers

I did a lot of retriggers over the week, including one for libreoffice
that was repeated (sorry).  The list below contains all of the
retriggers that passed, and a few of the failures (I did not include all
failures).

Package: hg-git [impish/i386]
Triggers: hg-git/0.10.1-1
Status: FAILED

Package: volatildap [impish/amd64]
Package: volatildap [impish/arm64]
Package: volatildap [impish/armhf]
Package: volatildap [impish/ppc64el]
Package: volatildap [impish/s390x]
Triggers: setuptools/52.0.0-4 openldap/2.5.5+dfsg-1~exp1ubuntu1
Status: PASSED

Package: reprotest [impish/arm64]
Package: python-fakeredis [impish/arm64]
Triggers: setuptools/52.0.0-4
Status: PASSED

Package: ruby-diaspora-federation [impish/i386]
Triggers: ruby-diaspora-federation/0.2.6-4
Status: FAILED

Package: debos [impish/amd64]
Triggers: debos/1.0.0+git20201203.e939090-4 nftables/0.9.8-3
samba/2:4.13.5+dfsg-2ubuntu2 qemu/1:5.2+dfsg-9ubuntu3
libreswan/3.32-3ubuntu3 suricata/1:6.0.1-2 glibc/2.33-0ubuntu8
Status: FAILED

Package: asymptote [impish/armhf]
Triggers: mesa/21.1.4-1 asymptote/2.70+ds-2 llvm-toolchain-12/1:12.0.1~+rc4-1
Status: PASSED

Package: node-millstone [impish/amd64]
Triggers: nodejs/12.21.0~dfsg-5ubuntu1
Status: FAILED

Package: node-redis [impish/amd64]
Triggers: nodejs/12.21.0~dfsg-5ubuntu1
Status: PASSED

Package: picolibc [impish/amd64]
Triggers: picolibc/1.7-1
Status: FAILED

Package: glibc [impish/amd64]
Triggers: linux-meta-oracle/5.11.0.1012.12+21.10.1
linux-oracle/5.11.0-1012.12+21.10.1
linux-signed-oracle/5.11.0-1012.12+21.10.1
Status: PASSED

Package: delve [impish/amd64]
Triggers: delve/1.6.1-1
Status: PASSED

Package: golang-github-keltia-archive [impish/arm64]
Package: golang-github-getkin-kin-openapi [impish/arm64]
Package: golang-github-bep-go-tocss [impish/ppc64el]
Package: golang-github-schollz-progressbar [impish/arm64]
Package: golang-github-schollz-progressbar [impish/armhf]
Package: golang-github-schollz-progressbar [impish/ppc64el]
Package: golang-github-keltia-archive [impish/ppc64el]
Package: golang-github-keltia-archive [impish/s390x]
Package: golang-github-schollz-progressbar [impish/s390x]
Triggers: golang-testify/1.6.1-2
Status: PASSED

Package: awesome [impish/armhf]
Package: ubuntu-release-upgrader [impish/armhf]
Triggers: xorg-server/2:1.20.11-1ubuntu2 xorgxrdp/1:0.2.15-1
Status: PASSED

Package: django-ldapdb [impish/armhf]
Triggers: setuptools/52.0.0-4 openldap/2.5.5+dfsg-1~exp1ubuntu1
Status: PASSED

Package: acpi-call [impish/arm64]
Triggers: linux-meta-raspi/5.11.0.1014.15+21.10.10
linux-raspi/5.11.0-1014.15+21.10.1 acpi-call/1.1.0-6
Status: PASSED

Package: munin [impish/armhf]
Triggers: systemd/248.3-1ubuntu2 clevis/16-2 conntrack-tools/1:1.4.6-2
debootstrap/1.0.124 dns-root-data/2021011101 dpdk/20.11.1-1
dq/20181021-1 gpsd/3.22-3 hddemux/0.4-7ubuntu2
libreswan/3.32-3ubuntu3 libvirt-dbus/1.4.0-2ubuntu1 nagios-tang/7-2
netplan.io/0.102-0ubuntu4 nftables/0.9.8-3 nix/2.3.10+dfsg1-1
pystemd/0.7.0-4build2 python-dbusmock/0.23.0-1 runit/2.1.2-40ubuntu2
samba/2:4.13.5+dfsg-2ubuntu2 suricata/1:6.0.1-2 tang/8-3
tinyssh/20190101-1build1 webhook/2.6.9-1build2
Status: PASSED

Package: mir [impish/ppc64el]
Triggers: wlcs/1.3.0-1
Status: PASSED

Package: ruby-webmock [impish/arm64]
Triggers: ruby-addressable/2.7.0-2
Status: PASSED

Package: booth [impish/ppc64el]
Triggers: crmsh/4.2.0-4ubuntu2
Status: PASSED

Package: pcs [impish/amd64]
Package: pcs [impish/arm64]
Package: pcs [impish/ppc64el]
Package: pcs [impish/s390x]
Triggers: fence-agents/4.7.1-1ubuntu5
Status: PASSED

Package: crmsh [impish/amd64]
Package: crmsh [impish/arm64]
Package: crmsh [impish/ppc64el]
Package: crmsh [impish/s390x]
Triggers: openssh/1:8.4p1-5ubuntu2
Status: PASSED

* Rebuilds & syncs

I did a few rebuilds and syncs.

Package: rustc 1.51.0+dfsg1+llvm-1~exp3ubuntu1 riscv64

Package: mesa 21.1.4-1 riscv64

Package: kldap 21.04.3-0ubuntu1 riscv64 (this will likely unblock openldap).
 Update: it didn't unblock openldap.

Package: akonadi-calendar 4:21.04.3-0ubuntu1 riscv64

Package: golang-github-hillu-go-yara sync'ed from experimental (trying
 to unblock yara)

* Investigation

I spent a lot of time investigating several failures and interesting
cases.  Here are my notes.

Package: openldap

*** The package and its dependencies are sorted out and everything is
just waiting for gnome-shell et al to become installable.

*** I've been talking to the Desktop team and I know they're on it.

*** Unfortunately the week has finished and openldap is still stuck.
This is my top priority right now so I'll keep working on it next
week.

Package: hg-git

*** Failing on i386.

*** mercurial-git:i386 uninstallable.  Not sure why it's trying to
install the arch-dependent version of it.

*** MP filed: 

Re: OpenLDAP 2.5 transition plan

[Sergio Durigan Junior]

On Thursday, May 20 2021, Andreas Hasenack wrote:

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

Absolutely will do!  Thanks :-).

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

OpenLDAP 2.5 transition plan

[Sergio Durigan Junior]

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


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

+1 maintenance report

[Sergio Durigan Junior]

Hi,

This week was my +1 maintenance rotation.  I got distracted by other
things that showed up along the way, but overall I managed to do a lof
of retriggers and investigate a few bugs here and there.

Retriggers that succeeded
=

devscripts [hirsute/amd64]
2.20.5ubuntu6   faketime/0.9.8-9

r-cran-projpred [hirsute/armhf]
1.1.6-1build1   r-cran-mass/7.3-53.1-1

ubuntu-image [hirsute/amd64]
1.10+20.10ubuntu4   grub2/2.04-1ubuntu40 grub2-signed/1.162

auto-multiple-choice [hirsute/armhf]
1.5.0~rc2-1ubuntu2  tex-common/6.16

php-doctrine-cache [hirsute/amd64]
1.10.2-2sqlite3/3.34.1-2

python3.9 [hirsute/armhf]
3.9.2-0ubuntu2  sqlite3/3.34.1-2

balsa [hirsute/armhf]
2.6.1-1 sqlite3/3.34.1-2

asterisk [hirsute/armhf]
1:16.15.1~dfsg-1sqlite3/3.34.1-2

libtimedate-perl [hirsute/armhf]
2.3300-2libtimedate-perl/2.3300-2

cluster-glue [hirsute/amd64]
1.0.12-20ubuntu1libtimedate-perl/2.3300-2

unattended-upgrades [hirsute/armhf]
2.8 xz-utils/5.2.5-1.0build1

systemd [hirsute/armhf]
247.3-1ubuntu3  net-tools/1.60+git20181103.0eebece-1ubuntu2

vg [hirsute/amd64]
1.30.0+ds-1 boost1.74/1.74.0-8ubuntu2 chiark-tcl/1.3.4ubuntu3 
cmake-extras/1.5-7 dateparser/1.0.0-1 dpdk/20.11-2 gem2deb/1.4 
glibc/2.33-0ubuntu2 grep/3.6-1 ipolish/20210105-1 link-grammar/5.8.1-1 
natsort/7.1.0-1 openconnect/8.10-2build1 orafce/3.14.0-1 osinfo-db/0.20210202-1 
pandas/1.1.5+dfsg-2 pgpool2/4.1.4-2 php-nesbot-carbon/2.32.2-1 
php-shellcommand/1.6.3-1 php-twig/2.14.3-1 postgresql-13/13.2-1 
postgresql-common/225 postgresql-multicorn/1.4.0-3 reprotest/0.7.16 
rows/0.4.1-3 snapd/2.49+21.04build1 symfony/4.4.19+dfsg-1 
systemd/247.3-1ubuntu2 tracker/2.3.6-2 vis/0.7-1

sphinx [hirsute/armhf]
3.4.3-1 texlive-base/2020.20210202-3 fig2dev/1:3.2.8-2 
hevea/2.34-2build3 jupyter-sphinx-theme/0.0.6+ds1-10 nbsphinx/0.8.0+ds-1 
ocamlweb/1.41-4build2 python-pweave/0.25-3 pyx3/0.15-3build2 
r-bioc-beachmat/2.6.4+ds-1 r-cran-tikzdevice/0.12.3.1-1 recommonmark/0.6.0+ds-1 
texlive-extra/2020.20210202-1 tth/4.15+ds-1

metakernel [hirsute/amd64]
0.27.5-1man-db/2.9.4-2 apparmor/3.0.0-0ubuntu5 dgit/9.13 
firejail/0.9.64.4-1 krop/0.6.0-2 metakernel/0.27.5-1 streamlink/2.0.0-1 
timew/1.4.2+ds.1-3ubuntu1 ubuntu-image/1.10+20.10ubuntu4

golang-github-hashicorp-raft [hirsute/armhf]
1.1.2-1 golang-github-armon-go-metrics/0.3.4-1

r-cran-webutils [hirsute/armhf]
1.1-1build1 r-cran-httpuv/1.5.5+dfsg-1

node-mimic-response [hirsute/armhf]
3.1.0-5 node-mimic-response/3.1.0-5

jupyter-notebook [hirsute/armhf]
6.2.0-1 jupyter-core/4.7.1-1

python-anndata [hirsute/armhf]
0.7.5+ds-3  matplotlib/3.3.4-1

victoriametrics [hirsute/amd64]
1.51.0+ds-3 golang-github-aws-aws-sdk-go/1.36.33-1

useful-clojure [hirsute/amd64]
0.11.6-4clojure/1.10.2-1

r-cran-irkernel [hirsute/armhf]
1.1.1-1 r-cran-crayon/1.4.0-1

r-cran-crayon [hirsute/armhf]
1.4.0-1 r-cran-crayon/1.4.0-1

lua-http [hirsute/armhf]
0.4-1   lua-http/0.4-1

tcpslice [hirsute/armhf]
1.3-2   libpcap/1.10.0-2

cl-ironclad [hirsute/arm64]
0.54-1  clisp/1:2.49.20180218+really2.49.92-3build5 chiark-tcl/1.3.4ubuntu3 
cmake-extras/1.5-7 dateparser/1.0.0-1 dpdk/20.11-2 gem2deb/1.4 
glibc/2.33-0ubuntu2 grep/3.6-1 ipolish/20210105-1 link-grammar/5.8.1-1 
natsort/7.1.0-1 openconnect/8.10-2build1 orafce/3.14.0-1 osinfo-db/0.20210202-1 
pandas/1.1.5+dfsg-2 pgpool2/4.1.4-2 php-nesbot-carbon/2.32.2-1 
php-shellcommand/1.6.3-1 php-twig/2.14.3-1 postgresql-13/13.2-1 
postgresql-common/225 postgresql-multicorn/1.4.0-3 reprotest/0.7.16 
rows/0.4.1-3 snapd/2.49+21.04build1 symfony/4.4.19+dfsg-1 
systemd/247.3-1ubuntu2 tracker/2.3.6-2 vis/0.7-1

cl-interpol [hirsute/arm64]
20201106.git70a1137-1   clisp/1:2.49.20180218+really2.49.92-3build5 
chiark-tcl/1.3.4ubuntu3 cmake-extras/1.5-7 dateparser/1.0.0-1 dpdk/20.11-2 
gem2deb/1.4 glibc/2.33-0ubuntu2 grep/3.6-1 ipolish/20210105-1 
link-grammar/5.8.1-1 natsort/7.1.0-1 openconnect/8.10-2build1 orafce/3.14.0-1 
osinfo-db/0.20210202-1 pandas/1.1.5+dfsg-2 pgpool2/4.1.4-2 
php-nesbot-carbon/2.32.2-1 php-shellcommand/1.6.3-1 php-twig/2.14.3-1 
postgresql-13/13.2-1 postgresql-common/225 postgresql-multicorn/1.4.0-3 
reprotest/0.7.16 rows/0.4.1-3 snapd/2.49+21.04build1 symfony/4.4.19+dfsg-1 
systemd/247.3-1ubuntu2 tracker/2.3.6-2 vis/0.7-1

golang-github-miekg-dns [hirsute/armhf]
1.1.35-1golang-github-miekg-dns/1.1.35-1

node-reinterval [hirsute/armhf]
1.1.0-2 node-mocha/8.2.1+ds1+~cs29.4.27-3

node-browser-resolve [hirsute/armhf]
1.11.3-3node-browser-resolve/1.11.3-3

golang-gopkg-square-go-jose.v2 [hirsute/armhf]
2.5.1-2 golang-go.crypto/1:0.0~git20201221.eec23a3-1 
golang-gopkg-square-go-jose.v2/2.5.1-2

goval-dictionary [hirsute/armhf]
0.1.1-2build1   golang-go.crypto/1:0.0~git20201221.eec23a3-1

jupyter-notebook [hirsute/armhf]
6.2.0-1 node-marked/0.8.0+ds+repack-2

ssl-utils-clojure [hirsute/arm64]
3.1.0-4   

Re: +1 maintenance report (dogtag-pki vs 389-ds-base)

[Sergio Durigan Junior]

On Friday, January 22 2021, Lukas Märdian wrote:

> Hey!
>
> Together with Timo I was debugging this issue a little further, and we were
> able to pinpoint the faulty commit, introducing the regression:
> https://github.com/389ds/389-ds-base/commit/2ccd0bed4e60e44303d5f1cf96bd30572ffea85b
>
> We reverted that commit and tested dogtag-pki vs custom 389-ds-base in a
> PPA, to confirm it passes:
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute-slyon-testing/hirsute/s390x/d/dogtag-pki/20210122_114408_9ecb1@/log.gz
>
> And Timo got in touch with the upstream developers to raise the issue there:
> https://github.com/389ds/389-ds-base/issues/4563

Thanks a lot for the investigative work, guys!

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

Re: +1 maintenance report (dogtag-pki vs 389-ds-base)

[Sergio Durigan Junior]

On Friday, January 22 2021, Brian Murray wrote:

> On Thu, Jan 21, 2021 at 03:25:02PM -0500, Sergio Durigan Junior wrote:
>> On Thursday, January 21 2021, Timo Aaltonen wrote:
>> 
>> > On 21.1.2021 18.59, Lukas Märdian wrote:
>> >> NO - dogtag-pki vs ['389-ds-base/1.4.4.9-1build2',
>> >> 'net-snmp/5.9+dfsg-3ubuntu1']
>> >>
>> >> So I had a closer look into the dogtag-pki failure on s390x. I could
>> >> easily reproduce the problem inside a s390x LXD container, but
>> >> wasn't able to isolate the root cause... After quite some
>> >> investigation I was able to produce a debug trace of the problem,
>> >> and to me it looks like the issue is actually not inside this
>> >> package, but rather inside the LDAP server (i.e. 389-ds-base), as
>> >> the debug log shows an "SEVERE: Unable to modify o=pki-tomcat-CA:
>> >> netscape.ldap.LDAPException: error result (1); Operations error",
>> >> i.e. "Internal Server Error"
>> >> (https://docs.oracle.com/cd/E19957-01/816-5618-10/netscape/ldap/LDAPException.html#OPERATION_ERROR
>> >> <https://docs.oracle.com/cd/E19957-01/816-5618-10/netscape/ldap/LDAPException.html#OPERATION_ERROR>).
>> >>  I
>> >> do not really understand why the LDAP server would behave
>> >> differently on s390x than on all the other architectures, but I
>> >> guess this is for another time...
>> >>
>> >> Debug log: https://paste.ubuntu.com/p/vx9JB6VTjF/
>> >> <https://paste.ubuntu.com/p/vx9JB6VTjF/>
>> >
>> > This seems to go back to at least 389-ds-base 1.4.4.4, probably
>> > longer. Would be useful to know where it regressed.
>> >
>> > As to why it only happens on s390x my guess would be that it's related
>> > to endianness (it's big-endian). Upstream tests only on amd64 (LE).
>> 
>> I'm also very interested in solving this, because it's blocking net-snmp
>> and a bunch of other packages from migrating.
>> 
>> Last week I did some investigation and pretty much stopped at the same
>> point as Lukas did.  I wasn't able to pinpoint exactly what the root
>> cause is, but Timo's guess is a good starting point.
>> 
>> I fiddled a bit with autopkgtest.db and confirmed that the failures
>> started with 389-ds-base/1.4.4.4-1:
>> 
>>   sqlite> SELECT test.package, result.version, result.triggers,
>> result.exitcode FROM result INNER JOIN test ON test.id =
>> result.test_id where test.package = 'dogtag-pki' and result.triggers
>> LIKE '%389-ds-base%';
>
> I find your querying of the SQLite database pretty interesting. Is there
> any documentation about the structure of the database and queries that
> might be useful?

Hey Brian,

Not that I know of.  The database is pretty simple, though; you can
obtain the schema for the tables by doing:

  PRAGMA TABLE_info(test);
  PRAGMA TABLE_info(result);

From there, you can start playing with queries.  I specifically like to
use the database at the end of a +1 maintenance week, because it's
pretty convenient to let you know what you did.

Cheers,

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

Re: +1 maintenance report (dogtag-pki vs 389-ds-base)

[Sergio Durigan Junior]

On Thursday, January 21 2021, Timo Aaltonen wrote:

> On 21.1.2021 18.59, Lukas Märdian wrote:
>> NO - dogtag-pki vs ['389-ds-base/1.4.4.9-1build2',
>> 'net-snmp/5.9+dfsg-3ubuntu1']
>>
>> So I had a closer look into the dogtag-pki failure on s390x. I could
>> easily reproduce the problem inside a s390x LXD container, but
>> wasn't able to isolate the root cause... After quite some
>> investigation I was able to produce a debug trace of the problem,
>> and to me it looks like the issue is actually not inside this
>> package, but rather inside the LDAP server (i.e. 389-ds-base), as
>> the debug log shows an "SEVERE: Unable to modify o=pki-tomcat-CA:
>> netscape.ldap.LDAPException: error result (1); Operations error",
>> i.e. "Internal Server Error"
>> (https://docs.oracle.com/cd/E19957-01/816-5618-10/netscape/ldap/LDAPException.html#OPERATION_ERROR
>> ).
>>  I
>> do not really understand why the LDAP server would behave
>> differently on s390x than on all the other architectures, but I
>> guess this is for another time...
>>
>> Debug log: https://paste.ubuntu.com/p/vx9JB6VTjF/
>> 
>
> This seems to go back to at least 389-ds-base 1.4.4.4, probably
> longer. Would be useful to know where it regressed.
>
> As to why it only happens on s390x my guess would be that it's related
> to endianness (it's big-endian). Upstream tests only on amd64 (LE).

I'm also very interested in solving this, because it's blocking net-snmp
and a bunch of other packages from migrating.

Last week I did some investigation and pretty much stopped at the same
point as Lukas did.  I wasn't able to pinpoint exactly what the root
cause is, but Timo's guess is a good starting point.

I fiddled a bit with autopkgtest.db and confirmed that the failures
started with 389-ds-base/1.4.4.4-1:

  sqlite> SELECT test.package, result.version, result.triggers, result.exitcode 
FROM result INNER JOIN test ON test.id = result.test_id where test.package = 
'dogtag-pki' and result.triggers LIKE '%389-ds-base%';

I'll see if I have the time to investigate a bit more.

Thanks,

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

+1 maintenance report

[Sergio Durigan Junior]

Hi,

This was my first week working in the +1 maintenance effort.  Here are
(most?) of the things I did:

Retriggers that succeeded
=

$ sqlite3 autopkgtest.db "SELECT DISTINCT test.package, result.version FROM 
result INNER JOIN test ON test.id = result.test_id WHERE result.requester = 
'sergiodj' AND result.exitcode = 0 AND result.run_id LIKE '2020121%';"

gvfs|1.46.1-1ubuntu1
reprotest|0.7.15
rspamd|2.6-1
libgdata|0.17.13-1
pillow-sane|2.8.3-5
python-setoptconf|0.2.0-5
satpy|0.24.0-1
zarr|2.6.1+ds-1
asterisk|1:16.15.0~dfsg-1
puma|3.12.4-1ubuntu2
cryptominisat|5.8.0+dfsg1-1build2
stunnel4|3:5.56+dfsg-6
booth|1.0-237-gdd88847-1
systemd|246.6-5ubuntu1
beets|1.4.9-7
ros-robot-state-publisher|1.15.1-3build2
balsa|2.6.1-1
leiningen-clojure|2.9.1-3
libaperture-0|0.1.0+git20200908-1
libtoxcore|0.2.12-1
libgwenhywfar|5.4.1-1
txzmq|0.8.0-2
libcrypt-openssl-x509-perl|1.9.02-1
libmongodb-perl|2.2.2-1
python-etelemetry|0.2.0-4
fdroidserver|1.1.10-1
libreoffice|1:7.0.3-0ubuntu2
python3.9|3.9.1~rc1-2
uwsgi-plugin-php|0.0.10build1
ros-perception-pcl|1.7.2-1
vorta|0.7.1-2ubuntu1
mdtraj|1.9.4+git20201015.068f29a-5ubuntu2
sonic-pi|3.2.2~repack-6
syncthing|1.10.0~ds1-1
r-cran-projpred|2.0.2+dfsg-1
libmodulemd|2.9.4-2
scikit-learn|0.23.2-3build2
macaulay2|1.16+git55.94c4b7d+ds-1
pandas|1.1.4+dfsg-1
ros-urdf|1.13.2-2build2
ros-ros-comm|1.15.9+ds1-4
ros-diagnostics|1.10.1+ds1-2
ros-geometry|1.13.2-2
postgis|3.0.3+dfsg-2ubuntu1
ros-perception-pcl|1.7.2-2
ros-geometry2|0.7.5-2
ros-image-pipeline|1.15.2-3
ros-kdl-parser|1.14.1-1
golang-github-blevesearch-bleve|0.5.0+git20170912.278.6eea5b78-4
feersum|1.410-1
node-redis|3.0.2+~cs5.18.1-1
automake-1.16|1:1.16.3-1ubuntu1
netplan.io|0.101-0ubuntu1
php-amqplib|2.12.1-3
php-arthurhoaro-web-thumbnailer|2.0.3+dfsg-1
ruby-backbone-on-rails|1.3.3+dfsg-1
ruby-jquery-rails|4.3.5-2
ruby-jquery-ui-rails|6.0.1+dfsg-6
ruby-markdown-it-html5-embed|1.0.0+dfsg-5
ruby-rails-assets-blueimp-gallery|2.33.0-2
ruby-rails-assets-fine-uploader|5.13.0-2
ruby-rails-assets-highlightjs|9.12.0-3
ruby-rails-assets-jquery.are-you-sure|1.9.0-2
ruby-bootstrap-switch-rails|3.3.4+dfsg+REALLY.3.3.3-1
ruby-rails-assets-corejs-typeahead|1.2.1-2
ruby-rails-assets-perfect-scrollbar|1.4.0-4
mariadb-10.5|1:10.5.8-3
edk2|2020.11-2
php-proxy-manager|2.2.3-2
update-manager|1:21.04.2
aptdaemon|1.1.1+bzr982-0ubuntu36
libcache-fastmmap-perl|1.54-1
glance|2:21.0.0+git2020120911.f102b74a-0ubuntu1
nbsphinx|0.8.0+ds-1
node-http-signature|1.3.5-1
node-stylus|0.54.8-1
dbus-cpp|5.0.1-5build1
ruby-leaflet-rails|1.6.0+dfsg-1
useful-clojure|0.11.6-3
breezy|3.1.0-8
dnspython|2.0.0+really1.16.0-2ubuntu2
pyscanfcs|0.3.6+ds-2build2
ironic|1:16.0.2+git2020120911.42bf964c8-0ubuntu1
q2-feature-table|2020.11.0+dfsg-1
joblib|0.17.0-1ubuntu1
tracker|2.3.6-2
diaspora-installer|0.7.6.1+debian2
gyoto|1.4.4-3build4
boost1.74|1.74.0-3ubuntu1

- A bunch of these passes unblocked other packages that were trying to migrate.

- There are some armhf retriggers that have not yet run.

Retriggers that failed
==

$ sqlite3 autopkgtest.db "SELECT DISTINCT test.package, result.version FROM 
result INNER JOIN test ON test.id = result.test_id WHERE result.requester = 
'sergiodj' AND result.exitcode != 0 AND result.run_id LIKE '2020121%';"

libvirt|6.9.0-1ubuntu4
python-scrapy|2.3.0-1
python3.8|3.8.6-1
software-properties|0.99.5
systemd|246.6-5ubuntu1
aptdaemon|1.1.1+bzr982-0ubuntu35
grml2usb|unknown
grubzfs-testsuite|unknown
sepp|4.3.10+dfsg-4
ubiquity|unknown
ubuntu-image|unknown
zsys|unknown
pam-mysql|0.8.1-4
sonic-pi|3.2.2~repack-6
gnudatalanguage|0.9.9-13build1
gnutls28|3.6.15-4ubuntu2
libdbd-mariadb-perl|1.21-1ubuntu2
aptdaemon|1.1.1+bzr982-0ubuntu36
securefs|0.11.1+ds-1build1
libgdf|0.1.3-6build1
fence-agents|4.7.0-1
ruby-jquery-rails|4.3.5-2
bundler|2.1.4-2
cl-trivial-garbage|20200801.git2319892-1
r-cran-rstanarm|2.19.3-1build1
simde|0.6.0-3
cwltool|3.0.20200807132242-3
python-os-client-config|2.1.0-0ubuntu3
chrony|4.0-2ubuntu1
redmine|4.0.7-1
xrayutilities|1.6.0-4build2
cod-tools|3.1.0+dfsg-1build2
useful-clojure|0.11.6-3
openstack-trove|2:14.0.0+git2020121012.9a6d4163-0ubuntu1
ruby-defaults|1:2.7+2

- There are some armhf retriggers that have not yet run.

Packages


I worked a bit on getting some packages building again, based on Bryce's
email from last week.

** tiffile

- Has been uploaded during the last weekend; FTBFS fixed.

** cura

- Bug filed and patch proposed:
  https://bugs.launchpad.net/debian/+source/cura/+bug/1908134

- I noticed that the Debian maintainers did some work on the VCS but
  never uploaded a new package.  I asked one of them (Myon) and he
  told me there are some failing tests on the new version.

- Uploaded.

** dfwinreg

- Bug filed and patch proposed:
  https://bugs.launchpad.net/debian/+source/dfwinreg/+bug/1908149

- I'm also proposing an NMU to the Debian package.

- Uploaded.

Unblocking rubygems + ruby-defaults
===

This has been in our 

+1 maintenance report

[Sergio Durigan Junior]

Hi,

I spent Wednesday and Thursday doing +1 maintenance this week.  Lucas
Kanashiro did the test retriggers for me (thanks!).  Also, most of the
work below was done aiming at getting php7.4 migrated.  Spoiler alert:
in the end, it wasn't possible to do that because of libffi.

- php-amqplib/groovy/arm64: asked Lucas to retrigger it using
  php7.4/7.4.9-1ubuntu1 libffi/3.4~20200819gead65ca871-0ubuntu3 as
  triggers.  It passed.

- phpmyadmin-sql-parser: fixed a FTBFS (LP: #1890341; upstream:
  https://github.com/phpmyadmin/sql-parser/pull/312), then retriggered
  the groovy/s390x tests.  It passed.

- symfony: filed a FTBFS (LP: #1893128) and fixed it by removing a now
  unneeded patch to workaround a testcase.  It passes now.

- diaspora-installer: always causing headaches :-/.  It was failing on
  ppc64el; I did a build & test on canonistack just to make sure the
  failure was non-flaky.  Andreas also investigated this and eventually
  managed to retrigger it and make it pass.

- fscrypt: it was missing a build on ppc64el due to an apparently flaky
  testcase failure.  I asked Andreas to retry the build (after
  successfully building it many times on a ppc64el canonistack
  instance), and it succeeded.  Then, I asked Lucas to retrigger the
  test on ppc64el, and it passed.

- libreswan: asked Lucas to retrigger it using iputils/3:20200821-2 as
  trigger.  Passed.

- cyrus-imapd/groovy/armhf: asked Lucas to retrigger it using
  postgresql-12/12.4-1.  Passed.

- libio-tee-perl/groovy/arm64: asked Lucas to retrigger it.  Passed.

- network-manager: asked Lucas to retrigger
  network-manager/1.26.0-1ubuntu1 using dnsmasq/2.82-1 on amd64, arm64
  and ppc64el.  Failed.  I reproduced it locally, but decided not to
  investigate it further because I was already busy with other failures,
  and network-manager is really big.

- cffi/groovy/amd64: asked Lucas to retrigger it using
  libffi/3.4~20200819gead65ca871-0ubuntu3 as a trigger *and* with
  all-proposed=true (because I was able to make the test pass using
  autopkgtest --apt-pocket=proposed locally).  It passed.  This
  unblocked cffi.

- update-manager/groovy/armhf: asked Lucas to retrigger using
  pygobject/3.36.0-4build2 libffi/3.4~20200819gead65ca871-0ubuntu3,
  because the failure seemed flaky to me.  It passed.

- software-properties/groovy/armhf: asked Lucas to retrigger using
  pygobject/3.36.0-4build2 libffi/3.4~20200819gead65ca871-0ubuntu3,
  because the failure seemed flaky to me.  It failed with a timeout
  again, so I'm still thinking it's worth retriggering.

- aptdaemon/groovy/amd64: asked Lucas to retrigger using
  pygobject/3.36.0-4build2 libffi/3.4~20200819gead65ca871-0ubuntu3,
  because the failure seemed flaky.  It failed with a timeout again.  I
  see that vorlon has also retriggered it, and it failed one more time,
  with a timeout.  Maybe worth an investigation.

- pygobject: ran the dep8 tests locally, verified that they pass, and
  therefore started requesting retriggers to make it unblock other
  packages.

- pam/1.3.1-5ubuntu6: asked Lucas to retrigger using fscrypt/0.2.9-1 as
  a trigger.  It passed.

Thanks,

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


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

Re: +1 Maintenance report

[Sergio Durigan Junior]

On Friday, August 14 2020, Christian Ehrhardt wrote:

> 2. groovy rsync was one of the many packages waiting for
>armhf test backlog to resolve - it just needed some help with test
> triggers
>and then migrated.

Hm, I still see rsync blocked (or maybe you were referring to a previous
version of rsync in your email...):

  
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#rsync

It's being blocked by dgit (failing on all arches), diaspora-installer
(failing on armhf; but it seems to have passed now), and livecd-rootfs
(failing on arm64; I think it's worth a retry just to make sure it's not
an intermitted failure).

Thanks,

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

Re: New coreutils release 8.32

[Sergio Durigan Junior]

On Saturday, July 18 2020, Dimitri John Ledkov wrote:

> On Sat, 18 Jul 2020 at 19:09, Nicholas Guriev  wrote:
>>
>> Dear Ubuntu developers,
>>
>> GNU coreutils 8.32 have been released on March 6th, 2020, yet the
>> package is not updated in groovy. The new version has enhanced support
>> of file creation time in stat(1) and introduced the "--time=birth" sort
>> rule for ls(1). It would be great to have these features in the coming
>> Ubuntu release. Please take a look at my merge request LP#1888046.
>>
>> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1888046
>>
>> Debian revision of the package has not migrated to testing yet due to
>> build failure on ARM64. Is there a chance to get the update for AMD64 at
>> least?
>>
>> https://buildd.debian.org/status/fetch.php?pkg=coreutils=arm64=8.32-2=1592917386=0
>>
>
> There are patches applied to coreutils to Ubuntu, thus it will need a merge.
>
> Separate architectures are not updated separately. Packages must match
> across architectures, and not regress in the support. Ubuntu supports
> 7 architectures, and coreutils must be build on them all.
>
> The issue might be related to the kernel headers shipped vs expected,
> and the problem may or may not reproduce on Ubuntu, as our kernels are
> different. It doesn't seem like a hard thing to fix on arm64.

Hey,

I'd like to give it a try at merging coreutils.  I'll see if I can do it
tomorrow.

Thanks,

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

Re: +1 maintenance status − July 13-17

[Sergio Durigan Junior]

On Friday, July 17 2020, Rafael David Tinoco wrote:

> This was my week and here is some of my notes about achievements and
> highlights:

I helped Rafael a little bit on Tuesday and Wednesday.  Here's my brief
report.

> 
> Overall status:
> --
>
> - read all the maint+1 docs and @piloted in ubuntu-devel
>
> - qemu TCG memory issue causing spinned qemu instances to be killed
>
> casper has a qemu instance killed because of TCG (cdrom file cant be found)
>
> => lost some time here trying to reproduce, unfortunately lack of attention
> as @paelzer had already warned me about, but I did not link cause and
> effect for this case.

I investigated casper one with Rafael on Wednesday, but he continued the
investigation (and eventually talked to @paelzer and found what was
happening) on Thursday.

> 
> Detailed information of what I remembered to take notes of:
> --
[...]
> Excuses [universe]: dropbear (helping sergiodj in ramping up maint+1)
>
> 4 hands with sergiodj for maint+1 and core-dev skills ramp up.
>
> (he will send his notes)

This was an interesting case.  dropbear version 2020.79-1 failed at
a certain point in the past, and this failure blocked libtommath from
migrating (it's worth mentioning that libtommath had *also* failed, so
it was blocking itself).  Then, a new upload of dropbear was made
(version 2020.80-1), and this version did pass.  However, libtommath
was still listed as blocked due to dropbear 2020.79-1.

Rafael and I tried to understand what was happening, and why
libtommath's tests were not retriggered when the new dropbear version
was uploaded.  Long story short, after talking to Lucas Kanashiro we
learned that these retries have to be submitted by hand.  So that's
Rafael did.

- rsync

I investigated the failure, submitted a bug & an MP to fix it:

https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1887572
https://code.launchpad.net/~sergiodj/ubuntu/+source/rsync/+git/rsync/+merge/387393

The new version has been uploaded and the package has migrated.

- libtommath

I also spent some time investigating this one.  It was failing with
"badpkg" on i386, and I noticed that it had a hint (force-badtest) for
another version of the package, so I thought it made sense to expand
this hint and just ignore all versions of libtommath on i386.  I filed
an MP for this, but vorlon did not accept it & kindly fixed the package
instead (it was actually a problem with cross dependencies & cross GCC).


Thanks,

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

Re: Adjusting what fstypes df displays

[Sergio Durigan Junior]

On Friday, May 29 2020, Bryce Harrington wrote:

> On Fri, May 29, 2020 at 10:31:56AM -0400, Sergio Durigan Junior wrote:
>> On Friday, May 29 2020, Bryce Harrington wrote:
>> > I've drafted a POC implementation for df here:
>> >
>> >   
>> > https://github.com/bryceharrington/coreutils/commit/cc372d778b44abcf81af42743a5174685f9bb4db
>> 
>> Hey Bryce,
>> 
>> Overall I like the idea of using an environment variable to control this
>> behaviour, but I feel compelled to raise the point of discoverability.
>> 
>> If the distro ships a file under /etc/profile.d/ which silently sets
>> this variable for all users, and if the user is not aware of that, it
>> may take her some non-trivial effort to figure out why her tmpfs mount
>> is being listed by df.
>> 
>> I'm sure you must have thought of that, but if you go forward with the
>> environment variable idea, extra care will need to be taken when writing
>> the documentation for it.  Perhaps (and that's a big "perhaps"; I
>> haven't thought much about it) it's even worth mentioning somehow that
>> DF_EXCLUDE_FSTYPES is being used in the output of df,
>
> It's a good point.  My plan is to mention it in --help, and also add an
> ENVIRONMENT section to the df man page, since at least to me that'd be
> the second and third places I'd look (the first being google
> obviously...)  I notice that df has a couple other environment variables
> (POSIXLY_CORRECT and DF_BLOCK_SIZE) mentioned in --help but not the man
> page, which could go in as well.

Yeah, man page, info and --help come to mind when I think about
documenting this.  I'd say it's worth putting something in the NEWS file
(from upstream) as well.

POSIXLY_CORRECT is accepted throughout coreutils, but unfortunately is
not documented everywhere.

I didn't know about DF_BLOCK_SIZE; I believe its existence sets a good
precedence for your proposal.

> This is probably too low-level to be worth including in the Groovy
> release notes, but I can propose a sentence or two just for some extra
> visibility.

Agreed.

>> or having a new
>> "--full-output" option (or some such) that would ignore the variable and
>> print everything.
>
> There is a 'df --all' option that sounds like it should suit that need.
> Thanks for raising this idea -- in testing it I notice the new code
> isn't honoring it.  I'll add a check to skip the env var if -a,--all is
> specified.

Ah, there you go.

>> I kind of like the idea of a configuration file, but I agree that an
>> environment variable is more flexible.  Also, I don't think the creation
>> of a configuration file would be justified for just this single option.
>
> Yeah, those were my thoughts as well.  df itself doesn't currently use a
> config file, but I wonder if coreutils itself has something.

Yeah...  I could not find anything, TBH.  And I know you can control
other aspects of coreutils via environment variables (like LS_COLORS,
for example), so that seems like the way to go, indeed.

>> Let me know when you submit the patch upstream; I'm interested in
>> following the discussions :-).
>
> Sure thing,

Thanks!

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

Re: Adjusting what fstypes df displays

[Sergio Durigan Junior]

On Friday, May 29 2020, Bryce Harrington wrote:

> These days, df displays a lot of mount points, due to the increased use
> of non-consumable filesystems such as tmpfs and squashfs.  This clutter
> is particularly noticeable using df in Ubuntu, due to the increased
> popularity of snaps, but the general problem affects all Linux distros,
> and shows up in other commands such as lsblk, blkid, fdisk -l, and
> mount.
>
> A commonly documented user customization[1] is to use aliases, e.g.:
>
> alias df='df -h -x squashfs -x tmpfs -x devtmpfs'
> alias lsblk='lsblk -e 7'
>
> df's upstream is aware of the issue, and would like to address it in
> their code.  They've considered a number of solutions[2], but do not
> appear to have come to a consensus as of yet.  Among the raised concerns
> are variations in distro requirements, and providing an ability for
> users to override/customize the exclusions.
>
> A solution I am considering to propose would add an environment
> variable, DF_EXCLUDE_FSTYPES, that df would treat similar to the -x
> flag.
>
>
> I've drafted a POC implementation for df here:
>
>   
> https://github.com/bryceharrington/coreutils/commit/cc372d778b44abcf81af42743a5174685f9bb4db

Hey Bryce,

Overall I like the idea of using an environment variable to control this
behaviour, but I feel compelled to raise the point of discoverability.

If the distro ships a file under /etc/profile.d/ which silently sets
this variable for all users, and if the user is not aware of that, it
may take her some non-trivial effort to figure out why her tmpfs mount
is being listed by df.

I'm sure you must have thought of that, but if you go forward with the
environment variable idea, extra care will need to be taken when writing
the documentation for it.  Perhaps (and that's a big "perhaps"; I
haven't thought much about it) it's even worth mentioning somehow that
DF_EXCLUDE_FSTYPES is being used in the output of df, or having a new
"--full-output" option (or some such) that would ignore the variable and
print everything.

> Here's what it does inside a container...
>
> Before:
>
> $ df
> Filesystem   1K-blocks  Used Available Use% Mounted on
> default/containers/coreutils  24891008   2258816  22632192  10% /
> none   492 4   488   1% /dev
> udev  32862724 0  32862724   0% /dev/tty
> tmpfs  100 0   100   0% /dev/lxd
> /dev/nvme0n1p2   982940092 348781368 584158392  38% 
> /home/bryce/pkg
> tmpfs  100 0   100   0% 
> /dev/.lxd-mounts
> tmpfs 32892912 0  32892912   0% /dev/shm
> tmpfs  6578584   224   6578360   1% /run
> tmpfs 5120 0  5120   0% /run/lock
> tmpfs 32892912 0  32892912   0% 
> /sys/fs/cgroup
> tmpfs  6578580 0   6578580   0% 
> /run/user/1001
>
> After:
>
> $ export DF_EXCLUDE_FSTYPES=tmpfs,devtmpfs,squashfs
>
> $ df
> Filesystem   1K-blocks  Used Available Use% Mounted on
> default/containers/coreutils  24891008   2258816  22632192  10% /
> /dev/nvme0n1p2   982940092 348781372 584158388  38% 
> /home/bryce/pkg
>
> (It's even more drastic on my desktop - from 39 lines down to 6.)
>
> For Ubuntu, DF_EXCLUDE_FSTYPES could be set in the global profile (under
> /etc/profile.d/ perhaps?)  This would make it straightforward to add
> new non-consumable filesystems that may crop up down the road.  Perhaps
> other tools could use a similar/same env var approach, giving us a
> uniform way to control fs listings in the distro.
>
> Two alternate approaches I'm weighing are a config file in /etc, or just
> a package patch to carry in coreutils, but the env var approach feels
> like it would be more flexible to users and hopefully more suitable for
> upstream.  Before I forward it upstream, though, what does ubuntu-devel@
> think?

I kind of like the idea of a configuration file, but I agree that an
environment variable is more flexible.  Also, I don't think the creation
of a configuration file would be justified for just this single option.

Let me know when you submit the patch upstream; I'm interested in
following the discussions :-).

Thanks,

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