Re: +1 maintenance report
On Fri, Sep 06, 2024 at 04:25:39PM -0400, Nick Rosbrook wrote: > Hello, > tl;dr -- In this report, there are three package removal requests > needing AA review, and one upload that is still stuck in -proposed > that would benefit from another set of eyes. > 1. Package removal requests (rationale is in the bug report): > https://bugs.launchpad.net/ubuntu/+source/nield/+bug/2079349 > https://bugs.launchpad.net/ubuntu/+source/glosstex/+bug/2079355 Removed. > https://bugs.launchpad.net/ubuntu/+source/sslh/+bug/2079513 Follow-up question added. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
Hi, On Fri, Aug 23, 2024 at 9:25 PM Pushkar Kulkarni < pushkar.kulka...@canonical.com> wrote: > Hi there, > > I was on +1 maintenance this week and here is my report. > > ruby-defaults 1:3.3~ubuntu3 transition > = > I spent most of the time on the autopkgtest failures reported against the > transition. I did an initial triage of the failures and then decided to > focus on two categories of failures: > > Category 1: Removal of the three-argument overload of Regexp::new > (Regexp::compile is an alias) > A total of 6 packages are affected by this. I have grouped these packages > under bug 2077502 [1]. > Ruby 3.3 removed support for the "encoding" argument to method > Regexp::new/::compile. This argument was deprecated by Ruby 3.2 and only > values 'n' and 'N', corresponding to Regexp::NOENCODING were supported. > Ruby 3.3 removes the argument and recommends accommodating it in > the 'flags. See the release notes here [2] and the bug report [3]. > > I have merge-proposals submitted for the affected packages. See [1] for > details. > > Category 2: Changes in the minitest gem API > A total of 20 packages seem to be affected by this. I have grouped them > under bug 2077617 [4]. > Ruby 3.3 includes minitest 5.20.0. Version 5.19.0 of the minitest gem, > stopped loading the MiniTest class by default and users are not expected to > use "Minitest" (instead of MiniTest). However, use of environment variable > MT_COMPAT falls back to the old behaviour and no code changes are needed. > See [5]. > > I have merge-proposals submitted for most of the affected packages. See > [4] for details. Thanks to Athos for sponsoring! > I liked this suggestion [6] from Athos, in this context. > Thanks for all your help on this transition, appreciated! I replied to Athos' comment on the bug, in summary, I'd not recommend changing the default behavior of all ruby packages ( >1k) because maybe 50 (?) are not supporting the new Minitest version. Moreover, those same 50 packages will start to FTBFS as soon as we update Minitest and the upstream removes this retro-compatibility flag. I was using another approach in Debian and also in some packages that I added a delta, which is patching the code to actually support the newer Minitest, to avoid any FTBFS in the near future. But for a late in the cycle transition, any solution is valid :) Thanks for all the patches Pushkar, I will continue sponsoring them from where Athos stopped. Lucas Kanashiro. -- 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 - 2024 week 31
On Wed, Aug 07, 2024 at 11:27:31AM +0200, Benjamin Drung wrote: > ## matlab-* > Is it possible to move a single binary package to multiverse (but keep > the others in universe)? matlab-jnifti should be moved to multiverse (is > in contrib on Debian). Same for matlab-brain2mesh. That's not really consistent with the schema we use in Ubuntu. I've moved these packages to multiverse altogether (source and binary). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
Hey, On Fri, Jul 12, 2024 at 5:50 PM Robie Basak wrote: > Looking at further rust issues, rust-chrono seems blocked on some > regressions in dep8 for rust-schemars and rust-serde-with. It looks like > some test runs at least are running out of disk space now, so I prepared > and submitted a merge proposal for these to be added to the big_packages > list. Right, thanks. I'm still waiting for you to get back with the result of retries and other bits before we can merge it. :) - u -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Fri, Jul 12, 2024 at 8:20 AM Robie Basak wrote: > rust-ashpd depwait -> rust-zbus depwait -> rust-zvariant specifically > librust-zvariant-3+enumflags2-dev (>= 3.15.0-~~) previously synced from > experimental version 4.0.0-1 provides librust-zvariant-4+enumflags2-dev. > Looks like there were a bunch of things synced from experimental in late > February that are now causing hold ups because other depending packages > have autosynced and still require an older version. Looks like this is > likely to shake itself out in time as packages are published into > unstable in Debian, so it's perhaps not worth chasing this further > without something we need that is being blocked by it. Yes, I am hoping that the rust-zbus cluster gets fixed on the Debian side by August. Some of the work is being coordinated in https://bugs.debian.org/1069621 There is now a newer rust-zbus in Experimental but there are library transitions involved so it wouldn't migrate without other packages being updated (not yet fully done in Debian) or trying to tweak those dependencies and hoping things work. > Back to rust-gix, migrating rust-hashbrown et al will cause > librust-cookie-store-dev to become uninstallable because it depends on > an older version of librust-indexmap-dev. Looks like rust-cookie and > rust-cookie-store need fixing as part of this cluster but they are held > up by dep8 failures. rust-reqwest looks like it has never passed. > Previously people have tried migration-reference/0 for them, but these > return neutral because of a dependency issue. I think this needs badtest > hinting. rust-reqwest is fixed now, thanks to Simon Chopin & Skia. There is a similar autopkgtest failure likely also due to Ubuntu autopkgtest proxy restrictions: rust-ureq. It looks like it will need to be handled for rust-cookie* to migrate which apparently is needed for rust-hashbrown etc. The rust-gvdb rebuild did not do what you intended. Generally with these Rust packages, you'd need to either add, remove or modify a patch to Cargo.toml and update debian/control. I'll fix rust-gvdb now. Thank you, Jeremy Bícha -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 Maintenance Report
On Fri, Jun 21, 2024 at 04:55:53PM -0600, Zixing Liu wrote:
> ### libxml-grddl-perl / libxml-libxslt-perl
> These require a no-change rebuild due to mismatching libxml sover.
> I can't do that since I am not a CoreDev.
But you know where some core-devs live ;)
There's also no reason in principle that you can't submit a changelog-only
MP to the sponsorship queue.
Can you provide further details here about what precisely is the reason for
a no-change rebuild, so that someone can pick this up?
I do see in the failure log the following:
253s # Warning: program compiled against libxml 212 using older 209
But I think that warning comes from libxml-libxslt-perl, not from the
packages under test? And I've seen this kind of nonsense before with
inappropriately strict checks of compile-vs-runtime versions of C libraries
from perl extensions (quite probably from this one in particular).
libxml2 | 2.9.14+dfsg-1.3ubuntu3 | oracular | source, amd64,
arm64, armhf, i386, ppc64el, riscv64, s390x
libxml2 | 2.12.7+dfsg-3| oracular-proposed | source, amd64,
arm64, armhf, i386, ppc64el, riscv64, s390x
The issue is that libxml-libxslt-perl depends on libxml2 (>= 2.7.4), because
THE ABI HASN'T CHANGED; so I think libxml-libxslt-perl's runtime warning is
wrong and the correct solution here is a sourceful change to remove it.
> ### ypy
>
> This package requires the introduction of new Rust packages
> (`rust-yrs` and `rust-lib0`).
> Since Ubuntu does not maintain Rust micropackages, those need to be
> added through Debian.
Rather than leaving this in -proposed, I've added ypy to the
sync-blocklist's extra-removals file documenting its prerequisite, and
removed the unbuildable source.
> ### rust-imperative
>
> This package requires the introduction of new Rust packages (`rust-stemmers`).
> Since Ubuntu does not maintain Rust micropackages, those need to be
> added through Debian.
Idem
> ### tiledarray / btas
> Lies deep in the abyss, `tiledarray` seems to attract a lot of
> unwanted attention from countless people doing +1 shifts.
> My new findings are, `tiledarray` and `btas` need to be upgraded
> (probably needs to be done in Debian) so that they will build with new
> BLAS + LAPACK.
> The upstream for those two projects is still very much alive; they are
> just too shy to make new releases:
> https://github.com/ValeevGroup/BTAS.
> My recommendation is to remove those packages from the archive and
> re-introduce them once `btas` is upgraded in Debian.
The process for requesting removal of a source package from the archive is
to file a bug against the package and subscribe ~ubuntu-archive to it.
This should include a rationale for why it's correct to remove the current
package. It is unclear to me given the evidence available that btas needs
to be removed; it has failed to build from source on riscv64 in
oracular-proposed but dots would need to be connected showing that this is a
problem requiring an upgrade to a new upstream version for compatibility
with current BLAS + LAPACK, as opposed to some riscv64-specific issue.
> ### node-get-stream
> This package had the autopkgtest crash on ppc64el and s390x.
> Upon investigation, the crash was caused by Node.js Garbage Collector
> being unable to perform GC collections under memory pressure
> (translation: consumed too much memory and then went out of memory).
> This package blocked several Node.js micropackages.
> I am not entirely sure how to fix the issue, maybe we can add
> swapfiles in the autopkgtest runners? The tests in `node-get-stream`
> seem to require about 4 GiB of RAM.
big_packages in
https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs
declares a list of packages per arch whose tests require more than the usual
amount of memory (or cpu) to run. It may become obsolete once all runners
have fully moved over to PS6, but in the meantime I've added
node-get-stream/{ppc64el,s390x} to the list and re-triggered (and it
passed).
FWIW, if big_packages ever becomes insufficient for running tests on a
package like this, I'm -1 on introducing swapfile tricks to make them pass.
The value of per-arch test passes of an arch: all node package which eats
this much memory is marginal, and we should probably just hint it as a bad
test at that point.
> ### rust-secret-service
> This package requires `rust-zbus` package version to be 3.x, while we
> have 4.x in the archive.
> `rust-zbus` underwent a major API overhaul with the 3.x -> 4.x update,
> so patching it is not feasible.
> I don't know what to do with this situation, as upgrading the package
> to a newer version will have a snowball effect.
rust-secret-service is only in oracular-proposed and is not releasable in
its present version because it depends on a too-old version of another
crate. No snowball effect, this can just be removed. (This is a special
case where I don't need a bug report against the package before r
Re: +1 Maintenance Report
Thank you for your work. Here are a few notes. On Mon, Jun 24, 2024 at 12:16 PM Zixing Liu wrote: > ### ypy > > This package requires the introduction of new Rust packages > (`rust-yrs` and `rust-lib0`). > Since Ubuntu does not maintain Rust micropackages, those need to be > added through Debian. This is https://bugs.debian.org/1071899 > ### rust-imperative > > This package requires the introduction of new Rust packages (`rust-stemmers`). > Since Ubuntu does not maintain Rust micropackages, those need to be > added through Debian. This is https://bugs.debian.org/1071889 > ### rust-secret-service > > This package requires `rust-zbus` package version to be 3.x, while we > have 4.x in the archive. > > `rust-zbus` underwent a major API overhaul with the 3.x -> 4.x update, > so patching it is not feasible. > > I don't know what to do with this situation, as upgrading the package > to a newer version will have a snowball effect. More specifically, rust-zbus isn't in Ubuntu right now because its dependencies are at a newer version for rust-zbus 4 but rust-zbus 4 isn't in Debian or Ubuntu yet. I believe the latest status on this is https://bugs.debian.org/1069621 Also, rust-secret-service isn't installable in Debian either because of https://bugs.debian.org/1060321 Thank you, Jeremy Bícha -- 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
Thank you very much, Simon !! On Mon, Jun 17, 2024 at 11:46 AM Simon Chopin wrote: > Hi Miriam, > > On lun. 17 juin 2024 10:29:57, Miriam Espana Acebal wrote: > > (Sorry, I sent incomplete) > > > > Hello everyone, > > > > Sorry for the delay... I was waiting for the resolution > > (reviews/acceptance) of some of the tasks I did > > (learning also . > > As Athos commented, I shadowed him on the last days of his shift rotation > > (thanks, Athos! It was a pleasure). > > That's great to here, I'm really happy to have you joining the +1 ranks :) > > For the record, one of the use cases of the +1 report is as kind of a > hand-off document, so that the next shift can pick up where you left off > if possible. That means that sending a report with items still pending > is perfectly fine, and could even make it easier for those items to be > completed ;). > > Nice work on the report overall! > > Cheers, > Simon > > > These are the fixes I made: > > > > * python-chemspipy: A FTBFS: when tests were running, six module wasn't > > found > > (provided by python3-six package, not listed as (b)dependency in > > d/control). But the > > package was a sync from Debian and there it was built OK [1]. Going > > deeper, python3-six > > was a implicit dependency of python3-request via its direct dependency > > python3-urllib3. > > We have a different version that the one used in sid/trixie: > > Ubuntu: 2.0.7-1 [2], synced from experimental > > Debian (sid/trixie): 1.26.18-2 [3] > > six module was embedded into python3-urllib3 until this last version > (see > > changelog entry). > > > > * geophar: FTBFS. simpy is embedded in upstream source code, but that is > > not the case in Debian > > (so the same is true for Ubuntu). Since the last version we updated, > > there have been new tests covering > > the existence of these embedded simpy files: that test doesn't make > sense > > in Debian, nor in Ubuntu. > > I adapted the check to avoid this test. Also, assertEquals is > deprecated > > [4], so I changed it by refreshing > > the existing correspondent patch. I created an MR in salsa for this > [5]. > > I didn't forward it to upstream, because > > in the Debian tracker, the patches are marked as "need to be submitted > to > > upstream" and I left it to the maintainer > > as the original author of the patch. > > > > * python-phpserialize: FTBFS: since python3.12, the assert_ method no > > longer exists [6]. We could see a deprecation > > warning for this in previous builds, like this one for Focal [7]: > >test_object_hook (tests.PhpSerializeTestCase) ... > > /<>/tests.py:92: DeprecationWarning: Please use assertTrue > > instead. > > self.assert_(b'WP_User' in x) > > In Debian, they still use Python3.11 (so they have the warning, not the > > error like us) [8]. I forwarded the patch I did to Debian [9], > > but in the meantime, I was changing assertTrue by assertIn as pointed > out > > by Benjamin Drung, and Sergio Durigan was faster :). So, > > it's synced to Oracular already. > > > > * python-awkward: I spent sometime with this, but finally Athos made it. > > > > I want to thank Athos and Paride for the sponsorship and Benjamin Drung > and > > Daniel Drapper for their reviews too. > > > > Now, yes, the report is complete (I blame the keyboard shortcut that > > triggered the send). Thanks everyone for reading! > > > > [1] > > > https://buildd.debian.org/status/fetch.php?pkg=python-chemspipy&arch=all&ver=2.0.0-2&stamp=1704269160&raw=0 > > [2] https://launchpad.net/ubuntu/+source/python-urllib3/2.0.7-1 > > [3] https://tracker.debian.org/pkg/python-urllib3 > > > > [4] > https://docs.python.org/3.11/library/unittest.html#deprecated-aliases > > [5] https://salsa.debian.org/georgesk/geophar/-/merge_requests/4 > > > > [6] https://docs.python.org/3/library/unittest.html#assert-methods > > [7] > > > https://launchpadlibrarian.net/448504127/buildlog_ubuntu-focal-amd64.python-phpserialize_1.3-1.1_BUILDING.txt.gz > > [8] > > > https://buildd.debian.org/status/fetch.php?pkg=python-phpserialize&arch=all&ver=1.3-2&stamp=1712878490&raw=0 > > [ 9 ] https://github.com/mitsuhiko/phpserialize/pull/36 > > > > On Mon, Jun 17, 2024 at 10:04 AM Miriam Espana Acebal < > > miriam.esp...@canonical.com> wrote: > > > > > Hello everyone, > > > > > > Sorry for the delay... I was waiting for the resolution > > > (reviews/acceptance) of some of the tasks I did. > > > As Athos commented, I shadowed him on the last days of his shift > rotation > > > (thanks, Athos!). > > > > > > These are the fixes I made: > > > > > > * python-chemspipy: A FTBFS: when tests were running, six module wasn't > > > found > > > (provided by python3-six package, not listed as (b)dependency in > > > d/control). But the > > > package was a sync from Debian and there it was built OK [1]. Going > > > deeper, python3-six > > > was a implicit dependency of python3-request via its direct dependency > > > python3-urllib3. > > > We have a
Re: +1 Maintenance Report
Hi Miriam, On lun. 17 juin 2024 10:29:57, Miriam Espana Acebal wrote: > (Sorry, I sent incomplete) > > Hello everyone, > > Sorry for the delay... I was waiting for the resolution > (reviews/acceptance) of some of the tasks I did > (learning also . > As Athos commented, I shadowed him on the last days of his shift rotation > (thanks, Athos! It was a pleasure). That's great to here, I'm really happy to have you joining the +1 ranks :) For the record, one of the use cases of the +1 report is as kind of a hand-off document, so that the next shift can pick up where you left off if possible. That means that sending a report with items still pending is perfectly fine, and could even make it easier for those items to be completed ;). Nice work on the report overall! Cheers, Simon > These are the fixes I made: > > * python-chemspipy: A FTBFS: when tests were running, six module wasn't > found > (provided by python3-six package, not listed as (b)dependency in > d/control). But the > package was a sync from Debian and there it was built OK [1]. Going > deeper, python3-six > was a implicit dependency of python3-request via its direct dependency > python3-urllib3. > We have a different version that the one used in sid/trixie: > Ubuntu: 2.0.7-1 [2], synced from experimental > Debian (sid/trixie): 1.26.18-2 [3] > six module was embedded into python3-urllib3 until this last version (see > changelog entry). > > * geophar: FTBFS. simpy is embedded in upstream source code, but that is > not the case in Debian > (so the same is true for Ubuntu). Since the last version we updated, > there have been new tests covering > the existence of these embedded simpy files: that test doesn't make sense > in Debian, nor in Ubuntu. > I adapted the check to avoid this test. Also, assertEquals is deprecated > [4], so I changed it by refreshing > the existing correspondent patch. I created an MR in salsa for this [5]. > I didn't forward it to upstream, because > in the Debian tracker, the patches are marked as "need to be submitted to > upstream" and I left it to the maintainer > as the original author of the patch. > > * python-phpserialize: FTBFS: since python3.12, the assert_ method no > longer exists [6]. We could see a deprecation > warning for this in previous builds, like this one for Focal [7]: >test_object_hook (tests.PhpSerializeTestCase) ... > /<>/tests.py:92: DeprecationWarning: Please use assertTrue > instead. > self.assert_(b'WP_User' in x) > In Debian, they still use Python3.11 (so they have the warning, not the > error like us) [8]. I forwarded the patch I did to Debian [9], > but in the meantime, I was changing assertTrue by assertIn as pointed out > by Benjamin Drung, and Sergio Durigan was faster :). So, > it's synced to Oracular already. > > * python-awkward: I spent sometime with this, but finally Athos made it. > > I want to thank Athos and Paride for the sponsorship and Benjamin Drung and > Daniel Drapper for their reviews too. > > Now, yes, the report is complete (I blame the keyboard shortcut that > triggered the send). Thanks everyone for reading! > > [1] > https://buildd.debian.org/status/fetch.php?pkg=python-chemspipy&arch=all&ver=2.0.0-2&stamp=1704269160&raw=0 > [2] https://launchpad.net/ubuntu/+source/python-urllib3/2.0.7-1 > [3] https://tracker.debian.org/pkg/python-urllib3 > > [4] https://docs.python.org/3.11/library/unittest.html#deprecated-aliases > [5] https://salsa.debian.org/georgesk/geophar/-/merge_requests/4 > > [6] https://docs.python.org/3/library/unittest.html#assert-methods > [7] > https://launchpadlibrarian.net/448504127/buildlog_ubuntu-focal-amd64.python-phpserialize_1.3-1.1_BUILDING.txt.gz > [8] > https://buildd.debian.org/status/fetch.php?pkg=python-phpserialize&arch=all&ver=1.3-2&stamp=1712878490&raw=0 > [ 9 ] https://github.com/mitsuhiko/phpserialize/pull/36 > > On Mon, Jun 17, 2024 at 10:04 AM Miriam Espana Acebal < > miriam.esp...@canonical.com> wrote: > > > Hello everyone, > > > > Sorry for the delay... I was waiting for the resolution > > (reviews/acceptance) of some of the tasks I did. > > As Athos commented, I shadowed him on the last days of his shift rotation > > (thanks, Athos!). > > > > These are the fixes I made: > > > > * python-chemspipy: A FTBFS: when tests were running, six module wasn't > > found > > (provided by python3-six package, not listed as (b)dependency in > > d/control). But the > > package was a sync from Debian and there it was built OK [1]. Going > > deeper, python3-six > > was a implicit dependency of python3-request via its direct dependency > > python3-urllib3. > > We have a different version that the one used in sid/trixie: > > Ubuntu: 2.0.7-1 [2], synced from experimental > > Debian (sid/trixie): 1.26.18-2 [3] > > six module was embedded into python3-urllib3 until this last version > > > > > > > > > > On Tue, Jun 11, 2024 at 12:32 AM Brian Murray wrote: > > > >> On Fri, Jun 07, 2024
Re: +1 Maintenance Report
(Sorry, I sent incomplete) Hello everyone, Sorry for the delay... I was waiting for the resolution (reviews/acceptance) of some of the tasks I did (learning also . As Athos commented, I shadowed him on the last days of his shift rotation (thanks, Athos! It was a pleasure). These are the fixes I made: * python-chemspipy: A FTBFS: when tests were running, six module wasn't found (provided by python3-six package, not listed as (b)dependency in d/control). But the package was a sync from Debian and there it was built OK [1]. Going deeper, python3-six was a implicit dependency of python3-request via its direct dependency python3-urllib3. We have a different version that the one used in sid/trixie: Ubuntu: 2.0.7-1 [2], synced from experimental Debian (sid/trixie): 1.26.18-2 [3] six module was embedded into python3-urllib3 until this last version (see changelog entry). * geophar: FTBFS. simpy is embedded in upstream source code, but that is not the case in Debian (so the same is true for Ubuntu). Since the last version we updated, there have been new tests covering the existence of these embedded simpy files: that test doesn't make sense in Debian, nor in Ubuntu. I adapted the check to avoid this test. Also, assertEquals is deprecated [4], so I changed it by refreshing the existing correspondent patch. I created an MR in salsa for this [5]. I didn't forward it to upstream, because in the Debian tracker, the patches are marked as "need to be submitted to upstream" and I left it to the maintainer as the original author of the patch. * python-phpserialize: FTBFS: since python3.12, the assert_ method no longer exists [6]. We could see a deprecation warning for this in previous builds, like this one for Focal [7]: test_object_hook (tests.PhpSerializeTestCase) ... /<>/tests.py:92: DeprecationWarning: Please use assertTrue instead. self.assert_(b'WP_User' in x) In Debian, they still use Python3.11 (so they have the warning, not the error like us) [8]. I forwarded the patch I did to Debian [9], but in the meantime, I was changing assertTrue by assertIn as pointed out by Benjamin Drung, and Sergio Durigan was faster :). So, it's synced to Oracular already. * python-awkward: I spent sometime with this, but finally Athos made it. I want to thank Athos and Paride for the sponsorship and Benjamin Drung and Daniel Drapper for their reviews too. Now, yes, the report is complete (I blame the keyboard shortcut that triggered the send). Thanks everyone for reading! [1] https://buildd.debian.org/status/fetch.php?pkg=python-chemspipy&arch=all&ver=2.0.0-2&stamp=1704269160&raw=0 [2] https://launchpad.net/ubuntu/+source/python-urllib3/2.0.7-1 [3] https://tracker.debian.org/pkg/python-urllib3 [4] https://docs.python.org/3.11/library/unittest.html#deprecated-aliases [5] https://salsa.debian.org/georgesk/geophar/-/merge_requests/4 [6] https://docs.python.org/3/library/unittest.html#assert-methods [7] https://launchpadlibrarian.net/448504127/buildlog_ubuntu-focal-amd64.python-phpserialize_1.3-1.1_BUILDING.txt.gz [8] https://buildd.debian.org/status/fetch.php?pkg=python-phpserialize&arch=all&ver=1.3-2&stamp=1712878490&raw=0 [ 9 ] https://github.com/mitsuhiko/phpserialize/pull/36 On Mon, Jun 17, 2024 at 10:04 AM Miriam Espana Acebal < miriam.esp...@canonical.com> wrote: > Hello everyone, > > Sorry for the delay... I was waiting for the resolution > (reviews/acceptance) of some of the tasks I did. > As Athos commented, I shadowed him on the last days of his shift rotation > (thanks, Athos!). > > These are the fixes I made: > > * python-chemspipy: A FTBFS: when tests were running, six module wasn't > found > (provided by python3-six package, not listed as (b)dependency in > d/control). But the > package was a sync from Debian and there it was built OK [1]. Going > deeper, python3-six > was a implicit dependency of python3-request via its direct dependency > python3-urllib3. > We have a different version that the one used in sid/trixie: > Ubuntu: 2.0.7-1 [2], synced from experimental > Debian (sid/trixie): 1.26.18-2 [3] > six module was embedded into python3-urllib3 until this last version > > > > > On Tue, Jun 11, 2024 at 12:32 AM Brian Murray wrote: > >> On Fri, Jun 07, 2024 at 06:03:35PM -0300, Athos Ribeiro wrote: >> > I did +1 maintenance from 2024-06-03 to 2024-06-07. >> > >> > I start the week by running the ubuntu-archive-tools >> find-proposed-cluster >> > script. There was nothing relevant there at this point of the cycle. >> > >> > Then I started looking at individual packages, no hard rules, but I was >> > trying to focus on the bottom half of the list. Coincidently, the first >> > 2 packages I looked at had infrastructure related failures. I then >> > proceeded to run the archive tools retry script: >> > >> > ./retry-autopkgtest-regressions --log-regex='unexpected eof from the >> testbed' >> > >> > I sticked to this regex for the 5 days I was wor
Re: +1 Maintenance Report
Hello everyone, Sorry for the delay... I was waiting for the resolution (reviews/acceptance) of some of the tasks I did. As Athos commented, I shadowed him on the last days of his shift rotation (thanks, Athos!). These are the fixes I made: * python-chemspipy: A FTBFS: when tests were running, six module wasn't found (provided by python3-six package, not listed as (b)dependency in d/control). But the package was a sync from Debian and there it was built OK [1]. Going deeper, python3-six was a implicit dependency of python3-request via its direct dependency python3-urllib3. We have a different version that the one used in sid/trixie: Ubuntu: 2.0.7-1 [2], synced from experimental Debian (sid/trixie): 1.26.18-2 [3] six module was embedded into python3-urllib3 until this last version On Tue, Jun 11, 2024 at 12:32 AM Brian Murray wrote: > On Fri, Jun 07, 2024 at 06:03:35PM -0300, Athos Ribeiro wrote: > > I did +1 maintenance from 2024-06-03 to 2024-06-07. > > > > I start the week by running the ubuntu-archive-tools > find-proposed-cluster > > script. There was nothing relevant there at this point of the cycle. > > > > Then I started looking at individual packages, no hard rules, but I was > > trying to focus on the bottom half of the list. Coincidently, the first > > 2 packages I looked at had infrastructure related failures. I then > > proceeded to run the archive tools retry script: > > > > ./retry-autopkgtest-regressions --log-regex='unexpected eof from the > testbed' > > > > I sticked to this regex for the 5 days I was working on +1 maintainance > and > > found dozens of (non-duplicated) occurrences each day. > > I expect that the majority of these were on arm64 and a result of > virtual machines taking an extraordinarily long period of time to be > provisioned in PS6. This has been reported in RT 164415 and is > documented at our autopkgtest service page[1]. > > [1] https://discourse.ubuntu.com/t/autopkgtest-service/34490 > > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- [image: Canonical-20th-anniversary] Miriam España Acebal Software Engineer II - Ubuntu Public Cloud/Server Email: miriam.esp...@canonical.com Location: Spain (GMT+2) canonical.com ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 Maintenance Report
On Fri, Jun 07, 2024 at 06:03:35PM -0300, Athos Ribeiro wrote: > I did +1 maintenance from 2024-06-03 to 2024-06-07. > > I start the week by running the ubuntu-archive-tools find-proposed-cluster > script. There was nothing relevant there at this point of the cycle. > > Then I started looking at individual packages, no hard rules, but I was > trying to focus on the bottom half of the list. Coincidently, the first > 2 packages I looked at had infrastructure related failures. I then > proceeded to run the archive tools retry script: > > ./retry-autopkgtest-regressions --log-regex='unexpected eof from the testbed' > > I sticked to this regex for the 5 days I was working on +1 maintainance and > found dozens of (non-duplicated) occurrences each day. I expect that the majority of these were on arm64 and a result of virtual machines taking an extraordinarily long period of time to be provisioned in PS6. This has been reported in RT 164415 and is documented at our autopkgtest service page[1]. [1] https://discourse.ubuntu.com/t/autopkgtest-service/34490 -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 Maintenance Report
On Fri, 2024-05-31 at 18:27 -0700, Bryce Harrington wrote: > ### httpx ### > > This is the source of blockage for a number of python modules, > flask-sqlalchemy, etc. The errors tend to be proxy errors and timeouts > on socket connections. Retriggering them hasn't seemed to resolve > them. I poked around upstream and in debian but whatever is going on > seems to be unique to us. > > My guess it is some conflict with how the httpx proxy's tests are > interacting with our infrastructure squid. Near as I can tell this > worked with httpx/0.26.0-2 and regressed with 0.27, so it seems likely > to be a change in this release. The changelog for > 0.27 (https://github.com/encode/httpx/releases/tag/0.27.0) has only 3 > entries, one of which is a fix to make http1 work, which appears to have > been an issue with squid in the distant past. > > I think this may need someone more conversant in autopkgtest > infrastructure to examine. I have seen failing test cases related to HTTP proxies. The autopkgtest in Ubuntu has http_proxy and/or https_proxy set. Unsetting those two environment variables would be my first try. -- Benjamin Drung Debian & Ubuntu Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 Maintenance Report
On Fri, May 31, 2024 at 12:35 PM Benjamin Drung wrote: > rust-axum-core > == > > update_excuse claims that rust-axum-core has no binaries on any arch, > but https://launchpad.net/ubuntu/+source/rust-axum-core/0.3.4-1 shows > that librust-axum-core-dev was build on all archs. I asked in #ubuntu- > release for an explanation. As of writing this report, I haven't got an > answer. That binary package is now built by source package rust-axum now. rust-axum-core was removed from Debian Unstable and should be removed from Ubuntu also. rust-axum is unable to migrate out of -proposed because of a few issues but removing rust-axum-core doesn't hurt in this case. Thank you, Jeremy Bícha -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 Maintenance Report
On Wed, May 29, 2024 at 07:04:11PM +, Graham Inggs wrote: > I was on +1 maintenance from 2024-05-23 until 2024-25-29. Below are > the things I worked on. > > > The autopkgtest queues were completely empty following the Mardid > sprint. I noticed the update_excuses report [1] still showed many > running tests in various states. I was able to re-queue these using > retry-autopkgtest-regressions from ubuntu-archive-tools [2] (and > piping the output to vipe, etc. as described in the help text). > > Retried 5222 tests in state "Test in progress": > ./retry-autopkgtest-regressions --state=RUNNING > > Retried 374 tests in state "Reference test in progress, but real test > failed already": > ./retry-autopkgtest-regressions --state=RUNNING-REFERENCE --no-proposed > > Retried 359 tests in state "Test in progress (will not be considered a > regression)": > ./retry-autopkgtest-regressions --state=RUNNING-ALWAYSFAIL > > I encountered some 503 errors while queueing these up, so it took a > few tries to get them all queued. > > > r-base / rmatrix > > sync'd r-cran-tmb > https://launchpad.net/ubuntu/+source/r-cran-tmb/1.9.11-2 > > r-cran-glmmtmb needed a no-change rebuild against r-cran-tmb and rmatrix > https://launchpad.net/ubuntu/+source/r-cran-glmmtmb/1.1.8+dfsg-3ubuntu2 > > r-cran-bbmle's autopkgtest regressed on ppc64el only, but it had > already regressed in Debian testing, so I filed Debian bug #1071667 > and added a hint > https://git.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/commit/?id=5bff2fb75385c247d0a9953c4830e8235d21ec1a > > r-cran-mertools' autopkgtest was failing on ppc64el only with: > ! R session crashed with exit code -9 > but passed in Debian. The test succeeded for me on a ppc64el cloud > instance, so I tried adding it to big_packages and it passed > https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs/commit/?id=bc49922e209d3c333469177cf81f6b461245788d > > This was enough for r-base and rmatrix to migrate. > > > octave > == > octave-statistics FTBFS with a dwz error, uploaded a workaround > https://launchpad.net/ubuntu/+source/octave-statistics/1.6.6-2ubuntu1 > > nlopt's autopkgtest was failing when nlopt was built with > -D_FORTIFY_SOURCE=3, uploaded a workaround > https://launchpad.net/ubuntu/+source/nlopt/2.7.1-5ubuntu1 > > octave-fits FTBFS with octave 9 and was removed from Debian, filed LP: > #2067300 for its removal from Oracular > https://bugs.launchpad.net/ubuntu/+source/octave-fits/+bug/2067300 > > > astropy > === > astroquery FTBFS and was removed from Debian testing, filed LP: > #2067093 for its removal from Oracular > https://bugs.launchpad.net/ubuntu/+source/astropy/+bug/2067093 > > > bowtie2 > === > bowtie2's autopkgtest failed on s390x because it is not installable > there. I triggered a migration-reference/0 test which failed, and > bowtie2 migrated. > > > black > = > black's autopkgtest failed on i386 because the package went from > arch:all to arch:any > and is not built on i386, added a hint > https://git.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/commit/?id=28e9f6676dccc3f765c446241556561dd82c934c > > html2text > = > html2text's autopkgtest only passed on amd64, but it had already > regressed in Debian testing and was reported in #1069872, added a hint > https://git.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/commit/?id=5fd1ec260fc922abc14ca89391533685618645fd > > > feature-check vs confget > > confget's autopkgtest regressed with the new version of feature-check, > but it had already regressed in Debian testing, so I filed Debian bug > #1071683 and added a hint > https://git.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/commit/?id=730a71a2e887c5f21e3161b2bdbc9da8b229aaeb > > feature-check's own autopkgtest failed on i386 because the package > went from arch:all to arch:any and is not built on i386, added a hint > https://git.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/commit/?id=5b0c5de382794d8b698fd1e3d90042eb36f50cd1 > > feature-check did not migrate until vorlon uploaded a no-change rebuild > https://launchpad.net/ubuntu/+source/feature-check/2.1.0-2build1 > > I'd love to know what / where / how he spotted the problem. > > > python-libarchive-c > === > python-libarchive-c's autopkgtest failed on i386 due to missing python > extensions, added a hint > https://git.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/commit/?id=219f0c672e6f4df81f8625607f44add741b3c87f > > > dipy > > dipy's autopkgtest regressed on armhf, but also regressed in Debian > testing, so I re-opened #1071448 and added a hint > https://git.launchpad.net/~ubuntu-release/britney/+git/hints-ubuntu/commit/?id=f3e3e4df84c1641c55570b0797b9667ac4d82fe9 > > > various syncs > = > I looked at the Merge-o-Matic report for packages in universe [3], and > sync'd several pac
Re: +1 maintenance report
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
Re: +1 maintenance report
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. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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
Heya Benjamin, Just wanted to followup in sharing the spreadsheet as it is so far. Thanks again for all the suggestions! https://docs.google.com/spreadsheets/d/1wLOIM-mkN02O-n84YXAOMC6MjEetCyID5JMonEAZSIU Definitely let me know if you stumble across other useful things, or even just have ideas/wishlists for capabilities you wish we had for dealing with these things. Bryce On Wed, Jan 03, 2024 at 11:54:47AM +, Benjamin Drung wrote: > Hi Bryce, > > On Fri, 2023-12-15 at 15:54 -0800, Bryce Harrington wrote: > > Heya Benjamin, > > > > Quick question for you. I'm collecting a list of tools people are > > finding useful or interesting for doing +1 maintenance. Can you mention > > any such scripts you used on your rotation this week? I'm in particular > > looking for weird/random/unusual stuff, personal or one-off codes, etc. > > I cannot remember using weird/random/unusual stuff. I used the usual > suspects: looked at the reports in the browser, used Launchpad and > tracker.debian.org, salsa.debian.org, git-ubuntu, sbuild, dput. > > > Thanks! > > Bryce > > > > On Fri, Dec 15, 2023 at 04:46:08PM +0100, Benjamin Drung wrote: > > > Hi, > > > > > > I had a +1 maintenance shift this week. Due to remaining work on apport, > > > sickness, and a vacation day, I spent less time on it. Therefore the > > > report is shorter than desired. Here is the report in Markdown format: > > > > > > * **python-aioice**: Retried python-aiortc test on armhf and s390x (they > > > failed on installation) but it still fails. This is caused by python3- > > > aiortc depending on python3-av < 11 (but having 11.0.0-1). python-aiortc > > > needs to be updated to 1.5.0-3 but that fails to build (due to depending > > > on python3-av < 11). > > > > > > * **dh-make-golang**: Created [dh-make-golang 0.6.0-2 fails to build > > > from > > > source](https://bugs.launchpad.net/debian/+source/dh-make-golang/+bug/2046369 > > > ) > > > > > > * **debvm**: Created [debvm 0.2.13 autopkgtest fails on > > > ppc64el](https://bugs.launchpad.net/ubuntu/+source/debvm/+bug/2046544) > > > and forwarded to Debian > > > > > > * **python-rtree**: autopkgtest failed on i386 due to installation > > > dependency issue. Tried with migration-reference/0 where it failed as > > > well. Then python-rtree migrated. > > > > > > * **python-mceliece**: Documented [python-mceliece 0~20230612.1-1 FTBFS > > > due to missing > > > libmceliece1](https://bugs.launchpad.net/ubuntu/+source/python-mceliece/+bug/2046548 > > > ) > > > > > > * **python-lib25519**: Document [python-lib25519 0~20230630.1-1 FTBFS > > > due to missing lib25519- > > > 1](https://bugs.launchpad.net/ubuntu/+source/python-lib25519/+bug/2046550 > > > ) > > > > > > * **python-libais**: Fixed Python 3.12 related failures and uploaded > > > 0.17+git.20190917.master.e464cf8-4 to Debian unstable > > > > > > * **python-svg.path**: Add patch to use better than nothing font and > > > upload 6.3-2 to unstable to unblock pillow 10.1.0-1 > > > > > > -- > > > Benjamin Drung > > > Debian & Ubuntu Developer > > > > > > -- > > > ubuntu-devel mailing list > > > ubuntu-devel@lists.ubuntu.com > > > Modify settings or unsubscribe at: > > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > -- > Benjamin Drung > Debian & Ubuntu Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On 07.02.24 09:17, Utkarsh Gupta wrote: On Wed, Feb 7, 2024 at 6:17 AM Pushkar Kulkarni wrote: === freedombox/bootstrapform === The freedombox package depends on bootstrapform. Autopkgtests of the former fail because the latter imports distutils. I did a Debian MR [15] to replace distutils.StrictVersion with packaging.Version. But I now see bootstrapform also failing, independent of this merge request, with Python 3.12. Test pipelines on the MR are failing and this needs more investigation. [15] https://salsa.debian.org/freedombox-team/python-django-bootstrap-form/-/merge_requests/4 I wonder what upstream thinks about it. Also it'd be nice to have this forwarded to upstream and get a review before landing it. sorry, we cannot do that unless we skip the 24.04 release and make 24.10 an LTS release instead. distutils had been deprecated two years ago, so if an upstream didn't act on it until now, why are you confident that it would be done in the remaining weeks up to our planned release? we will always have to pick a point in time for such a basic change, where hopefully most upstreams are already supporting a new Python version, and for the remaining ones either backporting unreleased upstream fixes, or writing our own fixes. In this specific case, the replacement seems to be safe, and for the LooseVersion variant, we are looking at providing https://pypi.org/project/looseversion/ Matthias -- 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
Hi, On Wed, Feb 7, 2024 at 10:42 AM Andreas Hasenack wrote: > > Hi, > > On Tue, Feb 6, 2024 at 9:47 PM Pushkar Kulkarni > wrote: > > > > === freedombox/bootstrapform === > > The freedombox package depends on bootstrapform. Autopkgtests of the > > former fail because the latter imports distutils. I did a Debian MR > > [15] to replace distutils.StrictVersion with packaging.Version. But I > > now see bootstrapform also failing, independent of this merge request, > > with Python 3.12. Test pipelines on the MR are failing and this needs > > more investigation. > > > > [15] > > https://salsa.debian.org/freedombox-team/python-django-bootstrap-form/-/merge_requests/4 > > > > I worked a little bit on this one the other day, because it was > blocking my samba upload. > > I filed this bug initially: > https://bugs.launchpad.net/ubuntu/+source/python-django-bootstrap-form/+bug/2050093 > > Fixing the distutils import. But then, as did you, I saw the django > failure with python 3.12: I ended up uploading the distutils fix anyway. I didn't see the django backtrace locally anymore, just in a ppa, and I'm unsure what's going on. Since the distusils fix will be needed anyway, I uploaded. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
Hi Pushkar, On Wed, Feb 7, 2024 at 6:17 AM Pushkar Kulkarni wrote: > I was on my first +1 maintenance shift last week. I began the week > with some reading of +1 report of the past shifts, to get a basic idea > of what to do and how to do it. Nice, thanks for your good work and excellent report. I have a few comments below. > === ccache === > Autopkgtests fail because a new upstream change causes uncaught > exceptions which bring down the ccache utility with a SIGABRT. > Interestingly, the test which core-dumps is deemed as passed, but the > core-dump messages on stderr cause tests to fail. > > I started a discussion on the upstream repository, which was later > accepted as a bug [3] and there is a fix committed. The upstream > maintainer, who also happens to maintain the Debian package mentioned > on the Debian bug report [4] that the fix will be out through a new > upstream release next week. Just in case, it doesn't happen, I have a > merge-proposal with a work-around [5]. > > [3] https://github.com/ccache/ccache/discussions/1390 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062810 > [5] > https://code.launchpad.net/~pushkarnk/ubuntu/+source/ccache/+git/ccache/+merge/459639 I've added a comment on the MP. But since the package is already manually sync'd now, can you reject the MP, please? > === asterisk-espeak === > This package represents an asterisk module related to speech > synthesis. The failing test just tried to load the module into > asterisk, but failed. I have an Ubuntu merge proposal [6] as well as a > Debian merge request [7] for this. Please read the connected bug > reports for more details. > > [6] > https://code.launchpad.net/~pushkarnk/ubuntu/+source/asterisk-espeak/+git/asterisk-espeak/+merge/459769 > [7] https://salsa.debian.org/pkg-voip-team/asterisk-espeak/-/merge_requests/2 Paride has left a comment on the bug and the MP, please take a look whenever you have a sec. > === freedombox/bootstrapform === > The freedombox package depends on bootstrapform. Autopkgtests of the > former fail because the latter imports distutils. I did a Debian MR > [15] to replace distutils.StrictVersion with packaging.Version. But I > now see bootstrapform also failing, independent of this merge request, > with Python 3.12. Test pipelines on the MR are failing and this needs > more investigation. > > [15] > https://salsa.debian.org/freedombox-team/python-django-bootstrap-form/-/merge_requests/4 I wonder what upstream thinks about it. Also it'd be nice to have this forwarded to upstream and get a review before landing it. > === glueviz === > This needs a migration from package "imp", which was purged in Python > 3.12, to package "importlib". I submitted a Debian merge request [16] > for it. > > [16] https://salsa.debian.org/debian-astro-team/glue/-/merge_requests/3 I think it'd be super helpful if this is done upstream and not downstream. This way we can avoid carrying patches and just get the new upstream version. > === factory-boy === > An autopkgtest of factory-boy, evidently picks up zero tests to run, > at least since the past four releases. In Python 3.12, the behaviour > of package "unittest" was modified to return failure (exit code 5) if > zero tests were selected. As a result, the factory-boy autopkgtest > began failing. I submitted a Debian merge request [17]. > > [17] > https://salsa.debian.org/python-team/packages/factory-boy/-/merge_requests/1 I don't think disabling the tests would be the right approach here. The correct and the ideal fix would be to get the tests running. :) Let me know if you have any questions or concerns; many thanks. - u -- 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
Hi,
On Tue, Feb 6, 2024 at 9:47 PM Pushkar Kulkarni
wrote:
>
> === freedombox/bootstrapform ===
> The freedombox package depends on bootstrapform. Autopkgtests of the
> former fail because the latter imports distutils. I did a Debian MR
> [15] to replace distutils.StrictVersion with packaging.Version. But I
> now see bootstrapform also failing, independent of this merge request,
> with Python 3.12. Test pipelines on the MR are failing and this needs
> more investigation.
>
> [15]
> https://salsa.debian.org/freedombox-team/python-django-bootstrap-form/-/merge_requests/4
>
I worked a little bit on this one the other day, because it was
blocking my samba upload.
I filed this bug initially:
https://bugs.launchpad.net/ubuntu/+source/python-django-bootstrap-form/+bug/2050093
Fixing the distutils import. But then, as did you, I saw the django
failure with python 3.12:
344s autopkgtest [06:02:28]: test command1: [---
344s /tmp/autopkgtest.LCD785/build.iLk/src/runtests.py:61:
RemovedInDjango50Warning: The extra_tests argument is deprecated.
344s failures = test_runner.run_tests(['bootstrapform'], test_args)
344s Found 1 test(s).
344s Traceback (most recent call last):
344s File "/tmp/autopkgtest.LCD785/build.iLk/src/runtests.py", line
66, in
344s runtests(*sys.argv[1:])
344s File "/tmp/autopkgtest.LCD785/build.iLk/src/runtests.py", line
61, in runtests
344s failures = test_runner.run_tests(['bootstrapform'], test_args)
344s^^^
344s File "/usr/lib/python3/dist-packages/django/test/runner.py",
line 1060, in run_tests
344s self.run_checks(databases)
344s File "/usr/lib/python3/dist-packages/django/test/runner.py",
line 977, in run_checks
344s call_command("check", verbosity=self.verbosity, databases=databases)
344s File "/usr/lib/python3/dist-packages/django/core/management/__init__.py",
line 110, in call_command
344s app_name = get_commands()[command_name]
344s^^
344s File "/usr/lib/python3/dist-packages/django/core/management/__init__.py",
line 76, in get_commands
344s for app_config in reversed(apps.get_app_configs()):
344s^^
344s File "/usr/lib/python3/dist-packages/django/apps/registry.py",
line 147, in get_app_configs
344s self.check_apps_ready()
344s File "/usr/lib/python3/dist-packages/django/apps/registry.py",
line 138, in check_apps_ready
344s raise AppRegistryNotReady("Apps aren't loaded yet.")
344s django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.
I found the debian bug about the distutils import which you filed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062980
Where I also sent my patch to, and also commented on the above django error.
Does someone with some django knowledge know what is going on above?
Unfortunately upstream
(https://github.com/tzangms/django-bootstrap-form) seems abandoned :(
This is the only package with this error:
$ ./retry-autopkgtest-regressions --log-regex "Apps aren't loaded yet"
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=amd64&package=python-django-bootstrap-form&trigger=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=arm64&package=python-django-bootstrap-form&trigger=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=armhf&package=python-django-bootstrap-form&trigger=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=ppc64el&package=python-django-bootstrap-form&trigger=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=s390x&package=python-django-bootstrap-form&trigger=python3-defaults%2F3.12.1-0ubuntu1
An on that topic, the distutils import problem affects these:
$ ./retry-autopkgtest-regressions --log-regex "No module named 'distutils'"
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=armhf&package=dolfinx-mpc&trigger=petsc4py%2F3.19.6-3ubuntu1&trigger=petsc%2F3.19.6%2Bdfsg1-2ubuntu1&trigger=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=amd64&package=onionshare&trigger=pyside2%2F5.15.12-4&trigger=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=arm64&package=onionshare&trigger=pyside2%2F5.15.12-4&trigger=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=armhf&package=onionshare&trigger=pyside2%2F5.15.12-4&trigger=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=ppc64el&package=onionshare&trigger=pyside2%2F5.15.12-4&trigger=python3-defaults%2F3.12.1-0ubuntu1
https://autopkgtest.ubuntu.com/request.cgi?release=noble&arch=s390x&package=onionshare&trigger=pyside2%2F5.15.12-4&trigger=python3-defaults%2F3.12.1-0ubuntu1
https
Re: +1 maintenance report
Hi Sergio, On Fri, Jan 26, 2024 at 06:31:39PM -0500, Sergio Durigan Junior wrote: > * r-bioc-savr > - There's an RM bug against the package on Debian. I didn't touch the > FTBFS. However, Debian package removal requests take an indeterminate amount of time to be acted on by the ftp team, and in the meantime this leaves the package in update_excuses for other folks to lose time on. In cases such as these, please either: - talk directly to an archive admin in realtime to have the package removed from -proposed (a pointer to a Debian removal bug is sufficient rationale for a removal), or - file a bug tagged update-excuse that documents the situation, pointing to the Debian bug and subscribing ubuntu-archive to it so it can be handled asynchronously. Shameless plug: https://code.launchpad.net/~vorlon/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/444677 gets you halfway there on the bug filing ;) In this case, it appears that in the meantime Debian has decided to fix the package rather than removing it, so no further action is required now by the Archive Team. > * repowerd > - Investigated a bit. I can build the package locally but it fails to > build on LP due to dh_missing complaining. Are you using up-to-date debhelper on noble? There have been recent changes in debhelper's handling of systemd units, precisely for the /lib vs /usr/lib question. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
Hi Bryce, On Fri, 2023-12-15 at 15:54 -0800, Bryce Harrington wrote: > Heya Benjamin, > > Quick question for you. I'm collecting a list of tools people are > finding useful or interesting for doing +1 maintenance. Can you mention > any such scripts you used on your rotation this week? I'm in particular > looking for weird/random/unusual stuff, personal or one-off codes, etc. I cannot remember using weird/random/unusual stuff. I used the usual suspects: looked at the reports in the browser, used Launchpad and tracker.debian.org, salsa.debian.org, git-ubuntu, sbuild, dput. > Thanks! > Bryce > > On Fri, Dec 15, 2023 at 04:46:08PM +0100, Benjamin Drung wrote: > > Hi, > > > > I had a +1 maintenance shift this week. Due to remaining work on apport, > > sickness, and a vacation day, I spent less time on it. Therefore the > > report is shorter than desired. Here is the report in Markdown format: > > > > * **python-aioice**: Retried python-aiortc test on armhf and s390x (they > > failed on installation) but it still fails. This is caused by python3- > > aiortc depending on python3-av < 11 (but having 11.0.0-1). python-aiortc > > needs to be updated to 1.5.0-3 but that fails to build (due to depending > > on python3-av < 11). > > > > * **dh-make-golang**: Created [dh-make-golang 0.6.0-2 fails to build > > from > > source](https://bugs.launchpad.net/debian/+source/dh-make-golang/+bug/2046369 > > ) > > > > * **debvm**: Created [debvm 0.2.13 autopkgtest fails on > > ppc64el](https://bugs.launchpad.net/ubuntu/+source/debvm/+bug/2046544) > > and forwarded to Debian > > > > * **python-rtree**: autopkgtest failed on i386 due to installation > > dependency issue. Tried with migration-reference/0 where it failed as > > well. Then python-rtree migrated. > > > > * **python-mceliece**: Documented [python-mceliece 0~20230612.1-1 FTBFS > > due to missing > > libmceliece1](https://bugs.launchpad.net/ubuntu/+source/python-mceliece/+bug/2046548 > > ) > > > > * **python-lib25519**: Document [python-lib25519 0~20230630.1-1 FTBFS > > due to missing lib25519- > > 1](https://bugs.launchpad.net/ubuntu/+source/python-lib25519/+bug/2046550 > > ) > > > > * **python-libais**: Fixed Python 3.12 related failures and uploaded > > 0.17+git.20190917.master.e464cf8-4 to Debian unstable > > > > * **python-svg.path**: Add patch to use better than nothing font and > > upload 6.3-2 to unstable to unblock pillow 10.1.0-1 > > > > -- > > Benjamin Drung > > Debian & Ubuntu Developer > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Benjamin Drung Debian & Ubuntu Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
Heya Benjamin, Quick question for you. I'm collecting a list of tools people are finding useful or interesting for doing +1 maintenance. Can you mention any such scripts you used on your rotation this week? I'm in particular looking for weird/random/unusual stuff, personal or one-off codes, etc. Thanks! Bryce On Fri, Dec 15, 2023 at 04:46:08PM +0100, Benjamin Drung wrote: > Hi, > > I had a +1 maintenance shift this week. Due to remaining work on apport, > sickness, and a vacation day, I spent less time on it. Therefore the > report is shorter than desired. Here is the report in Markdown format: > > * **python-aioice**: Retried python-aiortc test on armhf and s390x (they > failed on installation) but it still fails. This is caused by python3- > aiortc depending on python3-av < 11 (but having 11.0.0-1). python-aiortc > needs to be updated to 1.5.0-3 but that fails to build (due to depending > on python3-av < 11). > > * **dh-make-golang**: Created [dh-make-golang 0.6.0-2 fails to build > from > source](https://bugs.launchpad.net/debian/+source/dh-make-golang/+bug/2046369 > ) > > * **debvm**: Created [debvm 0.2.13 autopkgtest fails on > ppc64el](https://bugs.launchpad.net/ubuntu/+source/debvm/+bug/2046544) > and forwarded to Debian > > * **python-rtree**: autopkgtest failed on i386 due to installation > dependency issue. Tried with migration-reference/0 where it failed as > well. Then python-rtree migrated. > > * **python-mceliece**: Documented [python-mceliece 0~20230612.1-1 FTBFS > due to missing > libmceliece1](https://bugs.launchpad.net/ubuntu/+source/python-mceliece/+bug/2046548 > ) > > * **python-lib25519**: Document [python-lib25519 0~20230630.1-1 FTBFS > due to missing lib25519- > 1](https://bugs.launchpad.net/ubuntu/+source/python-lib25519/+bug/2046550 > ) > > * **python-libais**: Fixed Python 3.12 related failures and uploaded > 0.17+git.20190917.master.e464cf8-4 to Debian unstable > > * **python-svg.path**: Add patch to use better than nothing font and > upload 6.3-2 to unstable to unblock pillow 10.1.0-1 > > -- > Benjamin Drung > Debian & Ubuntu Developer > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- 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
I was on +1 maintenance this week and worked on the following: - stdgpu: requested to move libthrust-dev to the universe to resolve dependency-wait. Package migrated. LP: 2037908 - atop: investigated the autopkgtest failure on armhf. The root cause was the atopacctd service not starting in the lxc container and leaving behind a 0-length file. Atop client misinterpreted it and used a structure filled with zeroes. This caused a division by zero and the subsequent crash. Submitted MP in Ubuntu and upstream. LP: 2037910. - cataclysm-dda: requested to remove armhf binaries to resolve dependency-wait. Package migrated. LP: 2037912. - abyss: requested to move to the universe to align with Debian: LP 2037916. - casacore: -O2 switch was lost after sync. Added it back, package migrated. LP: 2037921. - zict: upstream fixed the test deadlock. I have backported the upstream patch, and the package migrated. Forwarded to Debian. LP: 2033759. - nix: added missing dependency libssh-dev and disabled autopkgtests requiring internet. Opened MP in Ubuntu. LP: 2037314. - unifrac/unifrac_tools: autokgtests fail due to: 1) rounding error (not present in the latest version), but we will have to add the patch[0] 2) failing test due to the division by zero in unifrac-tools[1]. I have opened PR upstream to fix this[2], but before patching the Ubuntu package, it would be nice to confirm the fix with the upstream as they need to decide the semantics. 3) missing round() method [3]. I could not reproduce it after division by zero was fixed[4]. More details are in LP: 2038397 - slic3r-prusa: the unit tests hang in CI due to the deadlock in Slic3r::GUI::BoostThreadWorker. Enabling verbose mode for tests allows them to pass most of the time[5], but they still hang from time to time. Submitted the issue upstream. LP: 2031340 [0] https://git.launchpad.net/~vpa1977/ubuntu/+source/unifrac/commit/?id=734914616e810713baf38f0579f04befe2856d91 [1] https://github.com/biocore/unifrac-binaries/issues/51 [2] https://github.com/biocore/unifrac-binaries/pull/52 [3] https://github.com/biocore/unifrac/issues/156 [4] https://launchpad.net/~vpa1977/+archive/ubuntu/plusone/+sourcepub/15188389/+listing-archive-extra [5] https://launchpad.net/~vpa1977/+archive/ubuntu/plusone/+sourcepub/15190276/+listing-archive-extra -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On 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: +1 maintenance report (14/Aug - 18/Aug)
On Mon, Aug 21, 2023 at 02:28:50PM -0700, Bryce Harrington wrote: > > The armhf lxd containers do not have hard partitioning of memory > > allocations, so *generally* tests on armhf will have more memory available > > than on other architectures. But that memory is also shared across tests, > > so "noisy neighbor" effect is more of a problem. > Is there a technique for identifying when this may be the case, when > we're troubleshooting armhf-specific issues? If it looks like an OOM error only on armhf, retry it and see if it's reproducible. > You know, it would be super useful if we had a handbook of architectures > for our autopkgtest infrastructure, that explains both the fundamental > differences between the architectures (e.g. cpu-specific uniquenesses) > and the implementational characteristics of how it's set up in Canonical > infrastructure (e.g. the memory configuration strategy with the armhf > lxd containers). Does a doc like this already exist? https://wiki.debian.org/ArchitectureSpecificsMemo is a good overview of architecture differences, which also applies to Ubuntu. It might be a good starting point for someone to create a doc that distills this for just the Ubuntu architectures. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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 (14/Aug - 18/Aug)
On Mon, Aug 21, 2023 at 09:47:18AM -0700, Steve Langasek wrote: > On Mon, Aug 21, 2023 at 10:16:31AM +0800, Shengjing Zhu wrote: > > + golang-github-protonmail-go-crypto > > The error message says "out of memory". I can reproduce this on a VM with > > 500M memory. > > It's because the testdata in TestSymmetricDecryptionArgon2 uses a large > > memory exponent parameter. > > It's same as https://github.com/ProtonMail/go-crypto/pull/178 (But this > > bug is only for 32bit arch, and is fixed in this package). > > TestSymmetricDecryptionArgon2 is passed on 32bit arch, but only fails on > > arm64 and s390x. Maybe the autopkgtest VM for these two architectures > > has less memory? even less than armhf (I know it is lxd container > > instead VM, but not sure about the memory configurations). > > > LP: #2032145 > > The armhf lxd containers do not have hard partitioning of memory > allocations, so *generally* tests on armhf will have more memory available > than on other architectures. But that memory is also shared across tests, > so "noisy neighbor" effect is more of a problem. Is there a technique for identifying when this may be the case, when we're troubleshooting armhf-specific issues? You know, it would be super useful if we had a handbook of architectures for our autopkgtest infrastructure, that explains both the fundamental differences between the architectures (e.g. cpu-specific uniquenesses) and the implementational characteristics of how it's set up in Canonical infrastructure (e.g. the memory configuration strategy with the armhf lxd containers). Does a doc like this already exist? For new +1 maintainers this might help with some of the sense of overwhelm one gets, but also even for experienced folks having itemized lists of idiosyncrasies could help jog the memory. (And as the infrastructure evolves it could help communicate what's changed, and/or identify more ways to improve...) Bryce -- 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 (14/Aug - 18/Aug)
On Mon, Aug 21, 2023 at 10:16:31AM +0800, Shengjing Zhu wrote: > + golang-github-protonmail-go-crypto > The error message says "out of memory". I can reproduce this on a VM with > 500M memory. > It's because the testdata in TestSymmetricDecryptionArgon2 uses a large > memory exponent parameter. > It's same as https://github.com/ProtonMail/go-crypto/pull/178 (But this > bug is only for 32bit arch, and is fixed in this package). > TestSymmetricDecryptionArgon2 is passed on 32bit arch, but only fails on > arm64 and s390x. Maybe the autopkgtest VM for these two architectures > has less memory? even less than armhf (I know it is lxd container > instead VM, but not sure about the memory configurations). > LP: #2032145 The armhf lxd containers do not have hard partitioning of memory allocations, so *generally* tests on armhf will have more memory available than on other architectures. But that memory is also shared across tests, so "noisy neighbor" effect is more of a problem. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Fri, Jul 28, 2023 at 05:43:36PM +0100, Robie Basak wrote: > # rust-block-padding > I didn't really make sense of this. How is a build of > rust-block-buffer-0.9 resulting in a binary > librust-block-buffer-0.9+block-padding-dev that has a versioned binary > dependency on librust-block-padding-0.2+default-dev without a build-dep > on something from rust-block-padding? I could dig deeper but I moved on > for now. Rust packaging uses helpers that autogenerate Debian package metadata from the upstream crate metadata. This includes declaring dependencies on various other crates that are used when building against this package (possibly in an optional non-default configuration), that are not necessarily needed at build time (since the binary package is a -dev package that basically contains rust source files, the runtime deps don't necessarily need to be present as build-time deps). So this is a very common pattern for rust packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Fri, Jun 30, 2023 at 03:18:04PM -0400, Nick Rosbrook wrote: > # lua-resty-core (LP 2025072) [needs AA] > This package is uninstallable due to a dependency on > libnginx-mod-http-lua, which is not in the Ubuntu archive due to an > intentional removal (LP: #1986853). > lua-resty-core has no reverse dependencies, so I suggested that the > package be removed from the archive and added to the sync blacklist. Done. > # triton (LP 2025279) [needs sponsor] > This package FTBFS because the package has Build-Depends: > libmlir-14-dev mlir-14-tools llvm-dev, but llvm-dev on mantic gives > llvm-15-dev. This results in CMake not being able to find the correct > MLIRConfig.cmake, because it wants > /usr/lib/llvm-15/lib/mlir/cmake/MLIRConfig.cmake (which would be > shipped by libmlir-15-dev). > I have proposed a PR to fix this in Ubuntu, and forwarded to Debian. Added a question on the PR. > # rdflib-sqlalchemy (LP 2025166) [needs sponsor] > This package FTBFS because it is missing a Build-Depends: > python3-wheel, and also because of an error in dh_auto_test related to > calling pytest. > > I have proposed a PR to fix this in Ubuntu, and forwarded to Debian. Being reviewed by Utkarsh. > # mlpack (LP 2025291) [needs sponsor] > This package FTBFS in Ubuntu and Debian. Upstream changed the way they > install their python bindings during the build (using python3 -m pip > instead of setup.py), so the Debian build needs to be adjusted for > this. > I have proposed a PR to fix this in Ubuntu, and forwarded to Debian. Looks like this has been sponsored. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Fri, Jun 09, 2023 at 06:20:55PM +0100, Danilo Egea Gondolfo wrote: > I had a shorter week with some Netplan distractions but here we go: > > 1. delve > > FTBFS due to the installed bpftool not matching the running kernel version. > I tried to workaround this by calling bpftool directly from > /usr/lib/linux-tools-. > It kinda worked but the build still fails for a different reason. It needs > more work. > See LP: #2021481 > > 2. bpftrace > > FTBFS on armhf. The problem apparently is a gcc bug. > I created a patch with a workaround and asked the upstream project about > the issue. > See: LP: #2023173 > Also submitted to Debian #1037185 > Github discussion > https://github.com/iovisor/bpftrace/pull/2360#discussion_r1223534659 > > 3. cbmc > > FTBFS on all architectures. > The compiler is catching some errors I believe are false positives. > There are some optional variables that it says are MAYBE uninitialized. > I added -Wno-error=maybe-uninitialized to the CXX FLAGS and it fixed > the build on amd64. It's now failing for a different reason on the other > archs. > LP: #2023276 > > 4. pistache > > FTBFS on all architectures except riscv > One of the unit tests tries to resolve an address via DNS and fails > because the builder doesn't have access to the internet I suppose. > It's not failing on Debian's CI. > A patch was submitted to the upstream project > https://github.com/pistacheio/pistache/pull/1134 > LP: #2023274 > > 5. ctffind > > FTBFS on non-x86 architectures > It uses x86 assembly inline. I implemented an alternative code calling > sinf() and cosf() from the libc instead on non-x86 systems. > LP: #2023288 > Debian bug: #1037227 > The patch was accepted by Debian and is already synced to Ubuntu. > > 6. elinks: > > FTBFS on s390x > A tool used during tests, sgml-parser, is crashing. There is a > use-after-free issue > in the code that is not making it crash on other architectures. > One can see it by using valgrind or compiling elinks with address sanitizer. > See: LP: 2023305 > I also reported the problem upstream: > https://github.com/rkd77/elinks/issues/235 > > 7. libopenmpt > > Autopkgtests failing > The test will build a C file that emits some deprecation warnings. > This is causing the test to fail. > LP: #2023406 > It was already reported to Debian: #1037007 I'm publicly mentioning this as it is the second time (today!) I've seen somebody not add a bug watch[1] to a bug which affects both Debian and Ubuntu. Basically, a bug watch will monitor the upstream bug report (status and comments depending on the bug tracker) in the remote tracker and update the bug task's status in Launchpad. This makes it much easier for future travellers to see what is going on with the bug in other bug trackers. [1] https://wiki.ubuntu.com/Bugs/Watches Happy Friday! -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Sat, Jun 03, 2023 at 10:43:41PM +0800, Shengjing Zhu wrote: > 3. librnd + camv-rnd + pcb-rnd > camv-rnd and pcb-rnd are in dep-wait status, it needs librnd > 4. > It's a small library transition. So I just ask @ginggs to kick off the > transition. > Also ask for revoking the blacklist for sch-rnd since it has stable release > now. https://launchpad.net/bugs/2007172 For the record, the ~ubuntu-archive team receives an unmanageable amount of email (I bitbucket all of mine). So I don't think anyone from the Archive Team saw your follow-up comment on this closed bug - I'm seeing it only because I read the +1 maintenance reports. Better to reopen the bug when commenting, or open a new bug. > 6. libs3 > FTBFS on ppc64el only. Caused by -Werror=stringop-overread. Looks like the > difference is -O3 vs -O2 build flags between Ubuntu and Debian. > Patch attached at https://launchpad.net/bugs/2021564 Followed up on the bug, thanks. > 8. kickpass > FTBFS on amd64 due to LTO. Caused by a pie patch which is added by the > Debian maintainer (Can be safely dropped). > Patch attached at https://launchpad.net/bugs/2021577 and forwarded to > https://salsa.debian.org/debian/kickpass/-/merge_requests/1 Uploaded > 12. beaker > > FTBFS due to tests relying on running redis server. > I don't think we can run a redis server during the build. The package > already ignores tests relying on mongodb server. So it should expand the > ignore list. > > Patch https://launchpad.net/bugs/2022332, forwarded to > https://bugs.debian.org/1037035 Uploaded. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Fri, May 26, 2023 at 09:40:02AM -0700, Simon Chopin wrote: > See https://bugs.launchpad.net/ubuntu/+source/rust-gio/+bug/2020880 > See https://bugs.launchpad.net/ubuntu/+source/rust-graphene-sys/+bug/2020902 Thanks for tagging these update-excuse! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Fri, May 19, 2023 at 05:53:54PM +0200, Benjamin Drung wrote: > * Follow-up on Lukas Märdian +1 shift: matplotlib 3.6.3-1 was not > synced. My sync was rejected: "same version already has published > binaries in the destination archive". I did a fake sync by uploading > 3.6.3-1fakesync1 with only the version number changed. For future reference, copy-package from lp:ubuntu-archive-tools lets you resuscitate source packages with their binaries, in this case by doing: copy-package -b -s lunar-proposed --to-suite mantic-proposed -e 3.6.3-1 \ matplotlib -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
> Overall, it seems that you looked at a large number of packages in > -proposed, but that for most of them you stopped at analysis (which is > useful) without preparing and submitting fixes for the issues identified. > In the future, please focus more on the latter, as that's what's actually > required to resolve the issues - few will read your email on ubuntu-devel in > depth, fewer will remember what your analysis was (or be able to find it > later). As a result, it's more efficient overall to work deeply on a small > number of packages to drive them to completion, than to shallowly touch a > large number of packages. You are right. I thought scanning through the pile first and working from that should work better than working one by one, and it seems I did not get the balance correct. I will note that in my next +1 maintenance week. Thanks, Zixing -- 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
Congratulations on your first +1 maintenance rotation! On Mon, Apr 10, 2023 at 12:45:49AM -0600, Zixing Liu wrote: > rust-criterion (0.3.6-3 to 0.4.0-2) > Due to the `rustc` version discrepancy between Ubuntu and Debian, > `rust-criterion` failed to compile in Ubuntu. > I have backported an upstream patch to `rust-criterion/0.4.0-2`, which > fixed the compiler error by covering all > the possible enumeration variants (missing `match` cases in Rust is an > error). > You can find the fix I proposed at > https://code.launchpad.net/~liushuyu-011/ubuntu/+source/rust-criterion/+git/rust-criterion/+merge/440546 Sponsored, thanks. > hg-git (0.10.4-5 to 1.0.1-1) > The UI test failed with one mismatched output of `remote: found 0 deltas to > reuse` due to the test corpus > did not account for an updated version of Git. > The fix was simply to add this line to the expected output corpus. > You can find the fix I proposed at > https://code.launchpad.net/~liushuyu-011/ubuntu/+source/hg-git/+git/hg-git/+merge/440545 Also sponsored. Please make sure to forward this fix to Debian as well. > === Investigated but Not Fixed > > cataclysm-dda (0.F-3-5 to 0.F-3-9) > We are using GCC 13, which introduced a stricter array out-of-bound (OOB) > access check. > This game used `-Werror` in the `CFLAGS`, which failed to compile due to > the stricter check. Looks like this has since been fixed by a manual sync by Graham from unstable. > git-annex (8.20210223-2ubuntu2 to 8.20210223-2ubuntu3) > This Haskell package failed to sync with Debian upstream due to Ubuntu > deltas. > Please see this sync bug for more information: > https://bugs.launchpad.net/ubuntu/+source/git-annex/+bug/2003918 Synced now, after confirming the delta was no longer needed. However, the new version also FTBFS. https://launchpad.net/ubuntu/+source/git-annex/10.20230126-3 (I think I may have tested this locally previously, though I can't be recall for sure.) > libs3 (2.0-3.1 to 2.0-4) > The package failed to compile on `ppc64el` because of the stricter array > boundary checks. This looks like the same bug as https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/2013140. It's appropriate to work around this by setting DEB_CFLAGS_MAINT_STRIP=-Werror=stringop-overread on ppc64el. > sccache (0.4.0~~pre6-1 to 0.4.0~~pre7-1) > The package failed to compile on `armhf` due to an out-of-memory situation. > Retry did not help. > The angle of attack would be turning off LTO and/or increasing the > `codegen-unit` parameter in the `[profile.release]` > section of the `Cargo.toml` file. > Rust compiler is memory hungry when LTO is turned on because all the > translation units need to be > read into the memory for the Whole Program Analysis (WPA) or the > Inter-Procedural Optimization (IPO) passes. For comparison, we do not enable LTO by default for gcc targets on armhf. > toybox (0.8.8+dfsg-2 to 0.8.9+dfsg-1) > This package lacks several dependencies, including `libssl-dev`, > `zlib1g-dev`. After adding those dependencies, > more dependencies are found to be missing. Not quite sure how Debian > managed to get this to compile. Looking closely at this, I don't think these are missing build-dependencies. Despite being presented as errors in the logs, it looks to me like these are optional libraries that are being probed for availability; they shouldn't have been available in the Debian build either but for some reason there's a difference in verbosity of output? Indeed, it appears Launchpad exports V=1 in the build environment. And if I try to build toybox locally, it succeeds WITHOUT $V, but fails WITH V=1. So a fix for this is to unset V in the build environment. I've uploaded a fix and forwarded to Debian. > ruby-foreman (0.85.0-2 to 0.87.2-1) > The build failed with `No entry for terminal type "unknown"`. > This package probably needs a proper `$TERM` environment variable to be set. Yes. > php-dompdf (0.6.2+dfsg-4 to 2.0.3+dfsg-1) > The dependency package `php-dompdf-svg-lib` was not synced into Ubuntu. $ syncpackage php-dompdf-svg-lib Source package php-dompdf-svg-lib is blacklisted. If this package needs a fakesync, use --fakesync If you think this package shouldn't be blacklisted, please file a bug explaining your reasoning and subscribe ~ubuntu-archive. Blacklist Comments: From sync-blacklist.txt: # vorlon, 2023-03-28, requires horde php-dompdf-svg-lib $ So, removing php-dompdf as well. > ruby-jekyll-remote-theme (0.4.3-2 to 0.4.3-3) > The tests in this package need network access (connects to GitHub). > The sole purpose of this package is to load Jekyll themes from a remote > source. Then it would be appropriate to disable the tests at build-time. > giara (0.3-3 to 1.0.1-2) > `s390x` support removed in 1.0.1-2 (from Debian) Confirmed, binary removed now in Ubuntu. > byte-buddy (1.11.4-1 to 1.12.21-1) > This package needs a newer version of `libbyte-buddy-java (>= 1.12.22)` to > be synchronized into Ubuntu. This seems to not be the c
Re: +1 maintenance report
On Thu, Apr 06, 2023 at 05:59:46PM -0300, Lucas Kanashiro wrote: > This week is shorter than usual because of the holiday tomorrow, so I am > sending my report today: > ruby-mocha > == > > It is blocked by ruby-bourne for more than 3 months. ruby-bourne does not > support ruby 3.1 and it was removed from Debian testing. Requested its > removal (and ruby-terrapin as a reverse dependency) here: > > https://bugs.launchpad.net/ubuntu/+source/ruby-bourne/+bug/2015231 Removed, thanks. > ruby-moneta > === > > It is blocked by ruby-upr. ruby-upr was removed from Debian because > upstream is dead and it was also blocking ruby-moneta there. I filed > another removal request: > > https://bugs.launchpad.net/ubuntu/+source/ruby-upr/+bug/2015298 Removed > ruby-oauth2 > === > > It is blocked in -proposed because of ruby-github-api test failure. > ruby-github-api was already removed from Debian testing and unstable to > allow ruby-oauth2 migration. I'd say we need to do the same in Ubuntu, so > filed this removal request: > > https://bugs.launchpad.net/ubuntu/+source/ruby-jeweler/+bug/2015305 > > The ruby-oauth2 migration will also allow ruby-omniauth-google-oauth2 > migration. Removed! Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Mon, Feb 20, 2023, Steve Langasek wrote: > On Mon, Feb 20, 2023 at 03:51:50PM +0100, Adrien Nader wrote: > > Due to the size of the queues, I decided to start with the oldest > > issues. > > Out of interest, how did you identify these "oldest issues"? I happened to > spend some time on proposed-migration on Thursday, and all of the packages I > worked on are older than the oldest package on your list, AFAICS. (The > *youngest* package I worked on was node-object-inspect, which is currently > 208 days old.) > Ah, right, "oldest issues" was how I approached this initially but most of these were either node ones which I have no experience with, or blocked on purpose, or packages for which I didn't spot a path forward relatively quickly. Since that was my first +1 maintenance, I didn't want to be stuck the whole week on one or two packages which were still problematic even though they had most likely been looked by others before. > > # sparse > > I'm under the impression that upstream doesn't run their own testsuite > > at the moment. > > For instance, there is a diagnostic which has been changed in 2019 in > > 2094267c7d36d8696897c509558fc63e8a695765 and new testcases have been > > added with that diagnostic but older ones have not been updated > > accordingly (the one failing because of that change has been created in > > 2018 and hasn't been changed since then). > > All in all this seemed to much for a +1 shift and I didn't act on the > > package. > > > > # blurhash-python > > I tried to reproduce the issue which occured on armhf but I didn't > > manage to. There were actually two different issues and that made me > > think the issues were unrelated to this package. Due to the size of the > > queues, I didn't ask for re-triggers. > > This package has since migrated. I guess someone did retrigger and it > passed. > > Please don't be shy about retriggering because of the queues; the tests get > run eventually... My main issue was the length of the queues and how long it would take to get some feedback. Overall I asked Lukas to re-trigger two dozens of tests (I thought that was more but I just counted again) but for blurhash-python, it felt like overloading the queues without being able to look at the results. I also identified these as potentially fixed by retries early in the week but since I probably wouldn't get results during the week, I chose to analyse them more first. I think I would have acted very differently had I known roughly when the tests would have run. I jokingly said to Lukas that we would get the results in two weeks, i.e. long enough that I'm done with the +1 shift and that we forget about them. Nonetheless, I'll probably err on the other side next time and begin with retrying in similar situations and look again near the end of the week. -- Adrien -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Mon, Feb 20, 2023 at 03:51:50PM +0100, Adrien Nader wrote: > Due to the size of the queues, I decided to start with the oldest > issues. Out of interest, how did you identify these "oldest issues"? I happened to spend some time on proposed-migration on Thursday, and all of the packages I worked on are older than the oldest package on your list, AFAICS. (The *youngest* package I worked on was node-object-inspect, which is currently 208 days old.) > # sparse > I'm under the impression that upstream doesn't run their own testsuite > at the moment. > For instance, there is a diagnostic which has been changed in 2019 in > 2094267c7d36d8696897c509558fc63e8a695765 and new testcases have been > added with that diagnostic but older ones have not been updated > accordingly (the one failing because of that change has been created in > 2018 and hasn't been changed since then). > All in all this seemed to much for a +1 shift and I didn't act on the > package. > > # blurhash-python > I tried to reproduce the issue which occured on armhf but I didn't > manage to. There were actually two different issues and that made me > think the issues were unrelated to this package. Due to the size of the > queues, I didn't ask for re-triggers. This package has since migrated. I guess someone did retrigger and it passed. Please don't be shy about retriggering because of the queues; the tests get run eventually... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
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: +1 maintenance report
On Thu, Feb 16, 2023 at 02:35:51PM -0500, Sergio Durigan Junior wrote:
> >> * 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?
Done.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
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
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
Re: +1 maintenance report
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)
$
> * 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.
FWIW marking it triaged had no effect here, my ubuntu-archive work list is:
https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-archive&field.status=NEW&field.status=Confirmed&field.status=Triaged&field.status=INPROGRESS&field.status=FIXCOMMITTED&field.status=INCOMPLETE_WITH_RESPONSE&orderby=-id
> * 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
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
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
Hi Nick, On Mon, Feb 13, 2023 at 4:18 AM Nick Rosbrook wrote: > ### openlibm FTBFS on armhf > > LP: #2006501 > > Debian already has a fix committed, but has not released for a few > months now. I verified the fix works for us, and proposed uploading > the fix with a `maysync` version to allow the next Debian upload to > autosync. I am still looking for a sponsor for this patch. As promised before and discussed on #ubuntu-devel, I've sponsored your upload. ;) - u -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Fri, Jan 13, 2023 at 04:24:53PM +0100, Simon Chopin wrote: > nipype (networkx) (LP: #2002811) > > > The nipype autopkgtests fail, but the issue seems to be networkx being > incompatible with numpy 1.24. Filed LP: #2002660 as the package is under the > umbrella of the openstack team. FWIW I separately came across this because it was blocking python-decorator via the failing qiime autopkgtests, and python-decorator is the very last package in lunar blocking the removal of python2. So I went ahead and prepared the merge, then found your bug report about it and added it to the changelog. The teams marked as responsible for a package in main are the maintainers of last resort - if the package is buggy and needs significant engineering work, they have the responsibility to get it fixed. But it's not a maintainer lock; if a change is obvious and you don't have any reason to think it will disrupt the team, it's ok to upload. In this case, there was an incompatibility with new numpy; it is very unlikely we would solve this incompatibility other than by updating to the new upstream release. It's always fine to cross-check with the owning team to confirm, but I wouldn't block on them in such a case. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Mon, Dec 05, 2022 at 05:06:30PM -0800, Steve Langasek wrote: > > However, sometimes you might find --apt-pocket=proposed=... *not* used, > > even when triggers appear to exist. I didn't get to the bottom of this. > > Maybe it's something to do with magic fallback behaviour I've heard > > mentioned (an automatic retry with different conditions?) but couldn't > > find anything documented and didn't find any implementation for this. > > For example, looking at [1], vorlon's test dated 2022-11-28 19:26:59 UTC > > and my subsequent retest dated 2022-11-30 10:20:55 UTC were subsequently > > identical, but looking at the logs, his one was called with > > --apt-pocket=proposed with no pinning defined, whereas mine was. All I > > did was hit the retry button against vorlon's test request and failure, > > and mine got run differently! I'd appreciate someone explaining this to > > me. > > This seems to simply be a bug in what autopkgtest.ubuntu.com considers a > 'retry', in that it is not propagating the all-proposed=1 option. I filed https://bugs.launchpad.net/auto-package-testing/+bug/1999163 for this - thanks. Robie 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
On Mon, Dec 05, 2022 at 05:06:30PM -0800, Steve Langasek wrote: > Second, even though the above should already pick up more packages from > -proposed that we need, I've also added --all-proposed, saying to grab all > packages from -proposed. Two reasons for this: FYI, although this is correct in principle, I was reminded today that there's an unfortunate interaction with NotAutomatic, and so despite the fact that I had been passing --all-proposed, the actual test runs were picking up the versions from the release pocket. So the tests have passed and are green, but the test results are actually invalid despite having the correct triggers. There's no good way to unwind these test results from the database so we'll probably have to roll with it for perl and pick up any regressions in the next mass test (glibc?). So it's fairly urgent that we get this fixed in autopkgtest infrastructure sooner rather than later. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
Sorry to hear that you had a frustrating time with +1 maintenance last week. Large transitions can definitely be frustrating because many times, it's so unclear how to make progress on them. Some notes: - The request.cgi API endpoint does deduplication of test requests on the backend. So provided you are generating your list of tests with matching logic for triggers and options (--all-proposed vs not), it's safe to blindly rerun retry-autopkgtest-regressions as many times as you need to without worrying about duplicates driving up the build queue times. - Although you didn't feel that you made much progress, it is still very valuable in situations like this to have somebody monitoring the things that have continued to fail and drill into them as necessary. So I would not consider this time wasted! If my suggestion had been more than an IRC driveby on the weekend due to my limited time, I would have mentioned the specific pipeline I was using to retrigger tests and why: $ retry-autopkgtest-regressions --all-proposed | grep '=perl%2F' \ | xargs -rn1 -P10 wget --load-cookies ~/.cache/autopkgtest.cookie -O- First, this skips the normal '--blocks perl' option to retry-autopkgtest-regressions in favor of a postprocessing grep. The reason for this is that using --blocks doesn't just limit the tests reported, it also limits the triggers emitted. So if there is a package, say, libcatmandu-mab2-perl, which is failing its autopkgtests against perl because it's using the release version of libcatmandu-mab2-perl, *and* failing its autopkgtests against itself because it's using the release version of perl, this picks up both triggers; which not only ensures the package gets tested with both of these packages from -proposed, it also credits any test pass against both packages in update_excuses. Second, even though the above should already pick up more packages from -proposed that we need, I've also added --all-proposed, saying to grab all packages from -proposed. Two reasons for this: - As previously discussed, there were select packages in the autopkgtest base images that were newer than the versions in lunar release, due to building against kinetic-security. For a mass-retry, --all-proposed was more likely to succeed than to cause false negatives. - In some cases, a test might require two packages (both perl and libfoo-perl) from -proposed in order to pass, but for whatever reason the test against libfoo-perl had already passed (because of luck on the autopkgtest -proposed fallback handling, or a manual retry done in isolation without considering perl itself, or $other), while the same test against perl had failed. In that case, retry-autopkgtest-regressions would output a line with only perl as the trigger, so without --all-proposed, we would fail to pick up libfoo-perl from -proposed. Using --all-proposed for a mass-retry here again increases the chances of the test being run correctly and getting a passing result. I'm sorry this is all as esoteric as it is. I've braindumped to the release team a bit about improvements that could be made to britney to automate retries and improve our success rate in these situations without requiring quite so much manual intervention. On Mon, Dec 05, 2022 at 05:04:47PM +, Robie Basak wrote: > The mechansism used that translates triggers into magic "just these from > proposed" is done via the --apt-pocket=proposed=... autopkgtest > commandline, so the actual apt pinning is done by autopkgtest itself. > The use of --env=ADT_TEST_TRIGGERS= etc was a red herring for me. I > couldn't find anything in autopkgtest itself that uses this variable. I > only saw it being used during test result collection. So what does > ADT_TEST_TRIGGERS= do, anyway? I didn't know the answer to this, so I googled and found https://wiki.debian.org/debci/britneyIntegration telling me that: "This line is the essential bit for recording the test trigger in result.tar so that britney can match a result to a request" And sure enough it appears in the britney source. > However, sometimes you might find --apt-pocket=proposed=... *not* used, > even when triggers appear to exist. I didn't get to the bottom of this. > Maybe it's something to do with magic fallback behaviour I've heard > mentioned (an automatic retry with different conditions?) but couldn't > find anything documented and didn't find any implementation for this. > For example, looking at [1], vorlon's test dated 2022-11-28 19:26:59 UTC > and my subsequent retest dated 2022-11-30 10:20:55 UTC were subsequently > identical, but looking at the logs, his one was called with > --apt-pocket=proposed with no pinning defined, whereas mine was. All I > did was hit the retry button against vorlon's test request and failure, > and mine got run differently! I'd appreciate someone explaining this to > me. This seems to simply be a bug in what autopkgtest.ubuntu.com considers a 'retr
Re: +1 maintenance report
Hi Seb, On Mon, Dec 05, 2022 at 09:01:32PM +0100, Sebastien Bacher wrote: > Hey Robie, your email was interesting to read, I've one question bellow > > Le 05/12/2022 à 18:04, Robie Basak a écrit : > > I thought I recalled a > >colleague mentioning something about this in ubuntu-helpers > > Could you share a reference to ubuntu-helpers? I don't know about that > project and neither apt search, launchpad.net/ubuntu-helpers nor google > leaded me to the right place... Sorry, yes. https://lists.ubuntu.com/archives/ubuntu-devel/2022-April/041996.html and the preceding thread has some discussion, but that never got concluded :-/ Robie 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
Hey Robie, your email was interesting to read, I've one question bellow Le 05/12/2022 à 18:04, Robie Basak a écrit : I thought I recalled a colleague mentioning something about this in ubuntu-helpers Could you share a reference to ubuntu-helpers? I don't know about that project and neither apt search, launchpad.net/ubuntu-helpers nor google leaded me to the right place... Cheers, Sebastien -- 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
Hi, Em sex., 21 de out. de 2022 19:47, Sergio Durigan Junior < sergio.duri...@canonical.com> escreveu: > * 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. > This one requires a new containerd version to get fixed. The update will happen in the "L" cycle. And this is not reproducible in Debian because our containerd package differs from there. Cheers! Lucas Kanashiro > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On 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
Re: +1 maintenance report
Hi Sergio, 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)? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
don't ignore SIGBUS failures [Was, Re: +1 Maintenance Report]
Hi Bryce, On Wed, Oct 05, 2022 at 06:37:06PM -0700, Bryce Harrington wrote: > ### scikit-learn ### > This package hits a 'bus error' on armhf. This issue seems not to have > a bug report in Debian, however bus errors are mentioned on both Deb: > #1008369 and #1003165. Both bugs have extensive discussion, however it's > unclear if a fix is in sight; main suggestions appear to be to drop the > architecture or skip the test case. Those may not be this same issue > though; it seems "Bus error" is a generic error that's been happening > for other tests on armhf. Upstream is also aware of armhf tests being > in a really bad state. > A previous +1'r also suggested skipping the failing test, so I've gone > ahead and added test_dist_metrics to appropriate sections of both > d/rules and d/t/python3, and uploaded this as 1.1.2+dfsg-5ubuntu1. > Since the testsuite bails as soon as it hits the first bus error, it's > possible there will be subsequent tests failing the same way, in which > case maybe just keep adding excludes. > I've filed update-excuse bug LP: #1991621 with the above info. LP: #1991621 is now resolved with the upload of a fix for the unalignment error (per your comments above, somehow you were uploading a version 1.1.2+dfsg-5ubuntu1, which was already older than the 1.1.2+dfsg-6 that had been in -proposed since September 12?), but I think this is still worth responding to. You mention concurring with a previous +1'er about skipping the failing test. But I see no evidence here of analysis of whether this is a buggy test vs. buggy code under test, or the impact to users of this code failing. The purpose of +1 Maintenance is to unstick packages from -proposed - but that does not mean getting new versions of packages into the release pocket at all cost! We should not be ignoring indicators that a new version of the package is going to be buggier than the status quo for users (of some architecture / in general). Bus errors on armhf don't cause build failures in Debian because Debian's armhf builds are done on older ARMv7 CPUs that don't have a problem with unaligned access; so these failures are only noticed ad hoc and after the fact. In Ubuntu, our armhf builds all happen virtualized on top of ARMv8 CPUs that DO care about alignment. I would argue that bus errors ought to be considered RC bugs on Debian, because nowadays users are more likely to be running armhf on ARMv8 hardware. But for Ubuntu, they DEFINITELY should be blockers, because it's not just our builders that are affected (which alone makes it difficult to have such code in the archive, causing failures in arbitrary reverse-dependency stacks at build time), the vast majority of systems supported today by Ubuntu's armhf port are also ARMv8 and, I think, affected by bus errors on unaligned access. So I don't think we should be skipping tests in packages showing that our armhf binaries will SIGBUS on certain CPUs, in order to get the packages to migrate. Now, that doesn't mean that we need to invest extraordinary effort into *fixing* such alignment errors on armhf. +1 Maintenance folks are not expected to all be deep architecture experts / C experts and fix all issues like this. Sometimes the right answer is instead to remove support for the architecture from the package (by talking to the archive admins and getting the binaries from the old version removed). Especially for packages that exist to support intensive numeric operations (like scikit-learn), this is probably a reasonable answer for armhf if it can be done without a mess of reverse-dependency handling (... which is NOT true for scikit-learn), because armhf is not an interesting architecture for heavy math stuff in production. But sometimes the answer is just to leave it be in -proposed until someone can come along and fix it. Also, Seth makes a very important point on the bug that unaligned access impacts *performance* on a lot more CPUs than those which generate SIGBUS: https://bugs.launchpad.net/ubuntu/+source/scikit-learn/+bug/1991621/comments/1 Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Fri, Sep 30, 2022 at 12:17:34PM +0200, Heinrich Schuchardt wrote: > *vectorscan* > > vectorscan does not build on amd64 > This seems to be due to warnings for the implementation of vectors in > libboost. > We have not updated libboost since 2 years. We should have a look at it > after the Kinetic release. I was surprised to look and see that this is true, as this is a package that we normally sync with Debian on at the beginning of a release cycle. But I see there has been no update in Debian either. So we should definitely check with the Debian maintainers about this for next cycle. (Doing the update in advance of Debian would be inviting a lot of extra work for ourselves.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Sun, Sep 18, 2022 at 08:51:51AM -0700, eeickme...@ubuntu.com wrote: > On Fri, 2022-09-16 at 18:12 -0600, Dan Bungert wrote: > > # qtav / matrix-mirage (LP: #1989613) # > > "QtAV is no longer maintained" per > > https://github.com/wang-bin/QtAV/blob/master/.github/ISSUE_TEMPLATE#L19 > > It does have a reverse dependency from matrix-mirage, which itself > > pseudo-unmaintained. Also, these packages are either Orphaned in > > Debian or on > > their way. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004628#16 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013409 > > Please see the LP for a longer form answer, but I believe that > > removal is the > > right choice. > qtav was a dependency of digikam (another high-profile application), > which now FTBFS/dep-waits due to this removal. I apologize for managing to miss this as a build-dependency in the release pocket when removing qtav. I will normally run `reverse-depend src:to-be-removed -a source` before removal but according to my shell history I failed to do so in this case. However, the bug report states: Digikam formerly depended on qtav, and it's immediate solution for this problem was to drop video playback, then psuedo-vendor and cleanup the qtav code as part of the Digikam codebase [3]. If this has happened why does there continue to be a build-dependency on libqtav-dev? Otherwise: if there's a build-dependency on libqtav-dev, why is there not also a runtime dependency on it? A brief look at the digikam 8.0.0~git20220917-0ubuntu1 indicates to me that qtav has been vendored, under core/libs/video/qtav, and that a build-dependency on libqtav-dev is no longer required. Removing the build dependency results in an unrelated failure: CMake Error at CMakeLists.txt:289 (add_subdirectory): The source directory /tmp/digikam-8.0.0~git20220917/po does not contain a CMakeLists.txt file. Removing the build-dependency from the version in the release pocket results in a successful build. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Fri, 2022-09-16 at 18:12 -0600, Dan Bungert wrote: > # qtav / matrix-mirage (LP: #1989613) # > > "QtAV is no longer maintained" per > https://github.com/wang-bin/QtAV/blob/master/.github/ISSUE_TEMPLATE#L19 > > It does have a reverse dependency from matrix-mirage, which itself > pseudo-unmaintained. Also, these packages are either Orphaned in > Debian or on > their way. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004628#16 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013409 > > Please see the LP for a longer form answer, but I believe that > removal is the > right choice. qtav was a dependency of digikam (another high-profile application), which now FTBFS/dep-waits due to this removal. I had been keeping this one alive with 8.0.0 git snapshots which kept its ffmpeg 5 compatibility (as the 7.x series was ffmpeg5 was incompatible), but without qtav this surely kills digikam, which means all that work I had put into it was all for naught. I am severely disappointed in this, because now Ubuntu Studio users are very likely without their primary photo organization software, and I'm running out of time and options. I initially had two proposals that worked with ffmpeg 5 to keep it in the archive: * Use the 7.x (stable), disable a/v capabilities and keep it in the archive, or * Switch to the master branch of 8.0 and use git snapshots to keep it compatible with ffmpeg5. Discussions between Steve Langasek, Rik Mills, and myself went with the latter option. However, with the removal of qtav, that option has disappeared. Right now, my last upload is in dep-wait status, and an attempt to rebuild FTBFS without libqtav-dev. Attempts to build with the the a/v capablitites disabled have proved fruitless as well. It appears that qtav was a hard dependency here. If I report this to the upstream developers of digikam, all I'm going to hear is, "You should never have moved away from ffmpeg 4 in the first place." Moving to the snap of digikam isn't an option either as it's maintained directly by KDE, so this isn't a situation where I can contact them to have a "stable/ubuntu-22.10" track opened, and who knows what other snap components need to be included. I think we can all agree this ffmpeg 5 transition has been a train wreck. So far, with audacity and digikam, we are losing two high- profile applications, and both very late in the cycle. -- Erich Eickmeyer Project Leader - Ubuntu Studio Member - Ubuntu Community Council signature.asc Description: This is a digitally signed message part -- 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
Hey, On Mon, Sep 12, 2022 at 8:20 PM Lucas Kanashiro wrote: > # rails > > It is stuck in -proposed because the new version contains a fix for > CVE-2022-32224 which introduced a behavior change in the way > hashes are serialized. I filed LP: #1988782 and tagged it as > update-excuse. Utkarsh as one of the Debian maintainers will be > pushing this forward. I looked at it during my +1 as well. I fixed it in Debian sid and that has migrated now. Whilst trying to syncpackage today, I found out that it was already sync'd in by someone else so just waiting for the test results and will close the bug once it has migrated here. - u -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Fri, Aug 19, 2022 at 07:30:47PM +0200, Olivier Gayot wrote: > opencolorio: > --- > The package had also been updated recently with a new upstream version ahead > of Debian. Unfortunately, the SONAME was bumped but the binary library > package was not renamed. > To fix it, I decided to merge the new upstream version that landed in Debian > unstable overnight. I had to introduce a delta to declare Conflicts: and > Replaces: fields since we now have two packages in kinetic containing > libOpenColorIO.so.2.1. > The updated binary packages are not yet published. Thanks, these binaries are published now but aren't migrating to the release pocket because olive-editor and openimageio both need to be rebuilt against the new version in order to be installable. I've triggered these no-change rebuilds now. > mplayer: > --- > I decided to backport the relevant upstream patches (there are 12 of them) > to support ffmpeg 5 without packaging the new upstream version. I submitted > a .debdiff at https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/1987114 > and I am looking for a sponsor for it. I also forwarded the diff to Debian. > I did some testing in a kinetic VM and it looks good to go. Thanks, this is uploaded now. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Tue, Aug 16, 2022 at 7:13 PM Steve Langasek wrote: > > On Tue, Aug 16, 2022 at 11:29:34AM -0400, Nick Rosbrook wrote: > > > ## libxsmm FTBFS (https://pad.lv/1984111) > > > This FTBFS with an undefined reference to pthread_yield. Upstream > > already has fixes for this, so I cherry-picked those. > > > I am still looking for a sponsor for this patch. > > Thanks, sponsored. Thanks! > > ## python-duniterpy breaks silkaj autopkgtest (https://pad.lv/1984122) > > > The immediate cause is the BlockUID type being changed to BlockID, but > > the upstream commit that resolves this does not apply cleanly to > > v0.9.0. The best resolution here is probably to wait for v0.10.0 to be > > packaged in Debian unstable (currently in experimental). > > I guess the reason for not syncing from experimental is that the package > there is only an RC version and not 0.10.0 release? Yes, that's right. > > ## bpftrace FTBFS (https://pad.lv/1985648) > > > The bpftrace-aotrt binary is built conditionally, but debian/rules > > always attempts to strip it. This can be fixed by stripping the binary > > only if the file exists. However, if my patch is applied this package > > will still FTBFS on armhf and s390x due to libbpfcc-dev dep-wait. > > > I am still looking for a sponsor for this patch. > > Commented on the bug. If the file is being built in Debian but not in > Ubuntu, we should aim to fix the root issue. Thanks for your review. Your suggestion makes more sense. > (BTW, being dep-wait on an architecture where the package has never built is > not a concern for +1 maintenance.) Ah, thanks for pointing that out. When the package didn't build on those arches in my PPA, I failed to notice that it has never built on those arches. -Nick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Tue, Aug 16, 2022 at 11:29:34AM -0400, Nick Rosbrook wrote: > ## libxsmm FTBFS (https://pad.lv/1984111) > This FTBFS with an undefined reference to pthread_yield. Upstream > already has fixes for this, so I cherry-picked those. > I am still looking for a sponsor for this patch. Thanks, sponsored. > ## python-duniterpy breaks silkaj autopkgtest (https://pad.lv/1984122) > The immediate cause is the BlockUID type being changed to BlockID, but > the upstream commit that resolves this does not apply cleanly to > v0.9.0. The best resolution here is probably to wait for v0.10.0 to be > packaged in Debian unstable (currently in experimental). I guess the reason for not syncing from experimental is that the package there is only an RC version and not 0.10.0 release? > ## bpftrace FTBFS (https://pad.lv/1985648) > The bpftrace-aotrt binary is built conditionally, but debian/rules > always attempts to strip it. This can be fixed by stripping the binary > only if the file exists. However, if my patch is applied this package > will still FTBFS on armhf and s390x due to libbpfcc-dev dep-wait. > I am still looking for a sponsor for this patch. Commented on the bug. If the file is being built in Debian but not in Ubuntu, we should aim to fix the root issue. (BTW, being dep-wait on an architecture where the package has never built is not a concern for +1 maintenance.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Wed, Aug 03, 2022 at 09:21:04PM -0400, Sergio Durigan Junior wrote: > > 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. Given that there may be a delay of multiple weeks (and subsequently +1 maintenance shifts) between the bug being filed in Debian and the package being sync'ed I think the best approach is to create an update-excuse for the issue. Also keep in mind that you don't need to do all of the work of creating a new bug report, rather you can use the script import-bug-from-debian which is part of the package ubuntu-dev-tools and does exactly what you think it would. (Although you would need to tag it update-excuse.) Cheers, -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On 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 ubuntu-devel@
Re: +1 maintenance report
On Mon, 1 Aug 2022 at 11:51, Michael Hudson-Doyle < michael.hud...@canonical.com> wrote: > > > On Mon, 1 Aug 2022 at 11:06, Steve Langasek > wrote: > >> On Sun, Jul 31, 2022 at 05:48:25PM -0400, Jeremy Bicha wrote: >> > On Sun, Jul 31, 2022 at 4:02 PM Steve Langasek >> > wrote: >> > > On Fri, Jul 29, 2022 at 03:36:32PM +1200, Michael Hudson-Doyle wrote: >> > > > There is some stuff on NBS due to a ldc transition: r-to-d, >> > > > appstream-generator, tilix, etc. AFAICT all of these packages have >> been >> > > > removed from Debian testing and I guess we should follow along. >> >> > > Unfortunately, Ubuntu Budgie has tilix seeded so a removal is not >> > > straightforward. Do you want to check with the Budgie developers >> about >> > > unseeding this? >> >> > ldc being broken is common and I don't think we've done a full removal >> > from Ubuntu before for it. Although one thing that is different is >> > that we allow libraries to smoothly migrate out of proposed in Ubuntu >> > now. >> >> It is my understanding that ldc is not broken but that gir-to-d is not >> compatible with the current version. There are 6 source packages in the >> archive that have successfully rebuilt against the new version of >> libphobos2-ldc-shared, it's only gir-to-d and it's reverse-dependencies >> that >> are broken. >> >> And Debian has removed all of these from testing, which implies they agree >> with this analysis. >> >> > Could we instead revert to an older ldc? >> >> We could, but what is going to get gir-to-d fixed to allow the transition >> to >> proceed later? >> > > gir-to-d people appear to think this is a compiler bug: > https://github.com/ldc-developers/ldc/issues/4000 > > Not really sure what the takeaway for Debian/Ubuntu is here. A dh-dlang > change? > I chatted briefly to the Debian maintainer on IRC and they said that they'll upload a workaround to gir-to-d (roughly this https://paste.ubuntu.com/p/bVHGFXQRJF/) "soon". We can fix it in Ubuntu sooner, clearly, but IMHO it's worth just waiting a few days to see if we get the fix via Debian with no effort. Cheers, mwh -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Mon, 1 Aug 2022 at 11:06, Steve Langasek wrote: > On Sun, Jul 31, 2022 at 05:48:25PM -0400, Jeremy Bicha wrote: > > On Sun, Jul 31, 2022 at 4:02 PM Steve Langasek > > wrote: > > > On Fri, Jul 29, 2022 at 03:36:32PM +1200, Michael Hudson-Doyle wrote: > > > > There is some stuff on NBS due to a ldc transition: r-to-d, > > > > appstream-generator, tilix, etc. AFAICT all of these packages have > been > > > > removed from Debian testing and I guess we should follow along. > > > > Unfortunately, Ubuntu Budgie has tilix seeded so a removal is not > > > straightforward. Do you want to check with the Budgie developers about > > > unseeding this? > > > ldc being broken is common and I don't think we've done a full removal > > from Ubuntu before for it. Although one thing that is different is > > that we allow libraries to smoothly migrate out of proposed in Ubuntu > > now. > > It is my understanding that ldc is not broken but that gir-to-d is not > compatible with the current version. There are 6 source packages in the > archive that have successfully rebuilt against the new version of > libphobos2-ldc-shared, it's only gir-to-d and it's reverse-dependencies > that > are broken. > > And Debian has removed all of these from testing, which implies they agree > with this analysis. > > > Could we instead revert to an older ldc? > > We could, but what is going to get gir-to-d fixed to allow the transition > to > proceed later? > gir-to-d people appear to think this is a compiler bug: https://github.com/ldc-developers/ldc/issues/4000 Not really sure what the takeaway for Debian/Ubuntu is here. A dh-dlang change? Cheers, mwh > > appstream-generator also seems important since we use it to build > > https://appstream.ubuntu.com/ although I guess it doesn't have to be > > packaged in the latest Ubuntu for that service. > > It's a temporary removal, and it would have to remain unfixed for 2 LTS > cycles to impact our ability to run appstream.u.c from debs. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Sun, Jul 31, 2022 at 7:06 PM Steve Langasek wrote: > It is my understanding that ldc is not broken but that gir-to-d is not > compatible with the current version. There are 6 source packages in the > archive that have successfully rebuilt against the new version of > libphobos2-ldc-shared, it's only gir-to-d and it's reverse-dependencies that > are broken. Ok, thanks. Jeremy -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Sun, Jul 31, 2022 at 05:48:25PM -0400, Jeremy Bicha wrote: > On Sun, Jul 31, 2022 at 4:02 PM Steve Langasek > wrote: > > On Fri, Jul 29, 2022 at 03:36:32PM +1200, Michael Hudson-Doyle wrote: > > > There is some stuff on NBS due to a ldc transition: r-to-d, > > > appstream-generator, tilix, etc. AFAICT all of these packages have been > > > removed from Debian testing and I guess we should follow along. > > Unfortunately, Ubuntu Budgie has tilix seeded so a removal is not > > straightforward. Do you want to check with the Budgie developers about > > unseeding this? > ldc being broken is common and I don't think we've done a full removal > from Ubuntu before for it. Although one thing that is different is > that we allow libraries to smoothly migrate out of proposed in Ubuntu > now. It is my understanding that ldc is not broken but that gir-to-d is not compatible with the current version. There are 6 source packages in the archive that have successfully rebuilt against the new version of libphobos2-ldc-shared, it's only gir-to-d and it's reverse-dependencies that are broken. And Debian has removed all of these from testing, which implies they agree with this analysis. > Could we instead revert to an older ldc? We could, but what is going to get gir-to-d fixed to allow the transition to proceed later? > appstream-generator also seems important since we use it to build > https://appstream.ubuntu.com/ although I guess it doesn't have to be > packaged in the latest Ubuntu for that service. It's a temporary removal, and it would have to remain unfixed for 2 LTS cycles to impact our ability to run appstream.u.c from debs. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Sun, Jul 31, 2022 at 4:02 PM Steve Langasek wrote: > On Fri, Jul 29, 2022 at 03:36:32PM +1200, Michael Hudson-Doyle wrote: > > There is some stuff on NBS due to a ldc transition: r-to-d, > > appstream-generator, tilix, etc. AFAICT all of these packages have been > > removed from Debian testing and I guess we should follow along. > > Unfortunately, Ubuntu Budgie has tilix seeded so a removal is not > straightforward. Do you want to check with the Budgie developers about > unseeding this? ldc being broken is common and I don't think we've done a full removal from Ubuntu before for it. Although one thing that is different is that we allow libraries to smoothly migrate out of proposed in Ubuntu now. Could we instead revert to an older ldc? appstream-generator also seems important since we use it to build https://appstream.ubuntu.com/ although I guess it doesn't have to be packaged in the latest Ubuntu for that service. Thank you, Jeremy Bicha -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Tue, Jul 26, 2022 at 07:02:02PM -0600, Dan Bungert wrote: > # unpaper (LP: #1982594) # > A newer version of unpaper is in the deferred queue currently and does build > for Kinetic and Sid. I suggest we sync that, when available. Will be synced automatically since the package in Ubuntu is in sync aside from the no-change rebuild. > # motion (LP: #1982886) # > Backported commit, in sponsor queue, forwarded to Debian. Thanks, uploaded. > # minidlna (LP: #1982890) # > Just needs no change rebuild. In sponsor queue. An unusual package that depends on libavformat and libavutil but not libavcodec, which is why I hadn't already picked it up in my mass-rebuild. Sponsored, and also have rerun my script to pick up other revdeps of libavformat. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
Hi Michael, On Fri, Jul 29, 2022 at 03:36:32PM +1200, Michael Hudson-Doyle wrote: > autofdo (last package depending on libgoogle-glog0v5) ftbfs, probably > because our llvm is too new. Upstream /may/ have this fixed in git, > unfortunately in an omnibus commit with the message "Update to the latest > internal version." I suspect the two sensible options here are to just take > upstream git as a new upstream version or remove the package (it has no > rdeps). If you can file a bug against the package in Ubuntu for documentation (since this is an Ubuntu-specific issue at the moment and does not affect Debian) and subscribe ubuntu-archive to it, I will remove it. > There is some stuff on NBS due to a ldc transition: r-to-d, > appstream-generator, tilix, etc. AFAICT all of these packages have been > removed from Debian testing and I guess we should follow along. Unfortunately, Ubuntu Budgie has tilix seeded so a removal is not straightforward. Do you want to check with the Budgie developers about unseeding this? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On 29/07/2022 05:08, eeickme...@ubuntu.com wrote: > Moreover, I cannot find any sign of the source code for 8.x, but > they've somehow released some pre-alpha appimages (???!). master branch on invent.kde.org is 8.0.0 development https://www.digikam.org/download/git/ The project version in the cmakelist.txt there confirms showing 8.0.0 https://invent.kde.org/graphics/digikam/-/blob/master/CMakeLists.txt#L19 Rik -- 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
Hi Michael! On Fri, 2022-07-29 at 15:36 +1200, Michael Hudson-Doyle wrote: > Thanks to sickness and leave and other interruptions I didn't get a > whole lot done in my shift, and I didn't do a very good job of > recording the things I did do I'm afraid. My condolances, I hope you feel better soon! > # ffmpeg 5 > > I spent a while looking at the ongoing ffmpeg 5 transition and it's a > huge mess. ffmpeg itself has now migrated but there are a pretty > large set of packages on NBS depending on the old ffmpeg libraries. > Dan did a great job of sorting out all the easy and easy-ish stuff > here but most (all?) of the remaining packages seem to require at > best moving to much newer upstreams than are present in the archive > or at worse extensive upstream work (some packages may be able to be > built without ffpmeg support until upstream catches up, which > degrades functionality but might be worth doing as a stop gap). I > feel like at this point it is not really something that is suitable > for +1 maintenance work. Unless someone who already has experience > with ffmpeg can devote an entire shift to it, I'm not sure what our > plan should be. Agreed, this is a mess. I was assisting with Steve on the digiKam 7.7.0 issue that is related to this (complete FTBFS due to inability to build with libavcodec59) and he thought of porting it. I investigated upstream and have been met with the developers telling me that they will not support ffmpeg 5 on digiKam 7.7.x, but will on 8.x.x. Moreover, I cannot find any sign of the source code for 8.x, but they've somehow released some pre-alpha appimages (???!). At any rate, I managed to get some builds in my PPA without the video playback support by removing the '-DENABLE_MEDIAPLAYER=ON' line from the debian/rules file. Good news: it builds. Bad news: No video player. I've only been hesitating to upload this because Steve had mentioned perhaps porting the failing portion to ffmpeg 5 compatibility, so I was waiting to hear back from him to see how he wanted to proceed, but I might just upload it and see if he wants to port it later. This is of interest to me because digiKam is a major part of Ubuntu Studio as its premiere photo cataloguing application, in addition to the multitude of other benefits it provides. -- Erich Eickmeyer Project Leader, Ubuntu Studio Member, Ubuntu Community Council Ubuntu MOTU -- 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
Hi Sergio, 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). Can you elaborate how each of these package fixes are getting into Ubuntu, and where the progress is being tracked? Related also to Brian's comments about having a handoff section in reports! But IMO it's ideal to have this all in an update-excuse bug instead so that people don't have to find the right email in the archive to get information about the state. On Wed, Jul 13, 2022 at 05:05:15PM -0400, Sergio Durigan Junior wrote: > 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com
Re: +1 maintenance report
Hi, On 18/07/2022 12:02, Nick Rosbrook wrote: ### ruby-certificate-authority FTBFS (https://pad.lv/1981458) There was a print format change for the x509 v3 authority key identifer field in openssl 3.0, and this test suite appears to depend on that format. Changing the expected test string to match the new format fixes the issue. William sponsored an upload that resolved this. Thanks for the patch. I uploaded it to Debian already. -- Lucas Kanashiro -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Wed, Jul 13, 2022 at 05:05:15PM -0400, Sergio Durigan Junior wrote: > 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. For the record I had to add liburing to the never_run list of packages[1] to break the loop and it'll need to be removed for the tests to run again. Additionally, I created http://launchpad.net/bugs/1981636 with what my cursory investigation revealed and tagged it update-excuse. [1] https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs/tree/never_run Thanks, -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On 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
Re: +1 Maintenance Report
On Fri, Jul 01, 2022 at 05:39:38PM -0700, Brian Murray wrote: > On Fri, Jul 01, 2022 at 03:25:39PM -0700, Bryce Harrington wrote: > > As William Wilson and Graham Inggs mentioned, there seems to be a higher > > than usual amount of FTBFS compared with autopkgtest failures. There > > doesn't seem to be a common pattern going on, just a lot of package > > ecosystems in flux. Like them, I focused mostly on FTBFS issues, and a > > little attention on the sponsoring queue. > > > > (There are also a large number of NBS package issues currently, although > > I didn't look at them. Several transitions like icu, libphobos2, > > libpoppler118, and libqgis appear to be in process.) > > > > > > ### riscv64 ftbfs ### > > > > Bunch of packages were failing to build on riscv64, but succeeded on > > retry: > > > > - rust-fd-find > > - mathcomp-zify > > - mathcomp-finmap > > - mathcomp-bigenough > > - mathcomp-algebra-tactics > > - rust-xcb > > - rust-idna > > - rust-tokio-util > > - libmseed > > - gsequencer > > > > gsequencer took a suprisingly long amount of time to rebuild (nearly a > > full day), and I suspect its prior failure could easily have just been > > hw/nw flakiness during such a long run. > > > > > > ### xnee / dia (libpoppler transition) ### > > > > xnee (riscv64) was ftbfs due to missing build dependency on dia-common. > > Dia was ftbfs due to needing updated for the new poppler API. I pulled > > a patch from an upstream PR that fixed it: > > > > https://gitlab.gnome.org/GNOME/dia/-/merge_requests/88 > > > > With dia successfully migrated, I rebuilt xnee for riscv64 and that also > > succeeded and xnee appears like it should migrate over the weekend. > > > > > > ### pdf2djvu (libpoppler transition) ### > > > > I sponsored Nathan Teodosio's fix for pdf2djvu to update pdf2djvu to the > > new poppler API, similar to dia. > > (LP: #1980518) > > > > > > ### debian-goodies (merge sponsorship) ### > > > > Nathan Teodosio also had a merge proposed for debian-goodies, just > > carrying a single bit of delta forward. I sponsored the upload. > > (LP: #1979538) > > > > > > ### anacron (merge sponsorship) ### > > > > Another merge uploaded for nteodosio. (LP: #1977739) > > > > > > ### mkosi ## > > > > Succeeded on retrigger for ppc64el and migrated successfully. > > I suspect it was just test flakiness on the hw. > > > > > > ### redis-py-cluster ### > > > > Test failure resolved on retrigger, and migrated successfully. > > > > > > ### bibtool / texlive-base ### > > > > texlive-base was blocked by test failure with bibtool. It passed > > on retrigger however texlive-base is still bocked by > > auto-multiple-choice and latexml which I didn't investigate. > > > > > > ### node-zx and node-core-js ### > > > > node-core-js is missing node-zx as build dependency. node-zx FTBFS due > > to a test case that is trying to access example.com. I disabled the > > test case and enabled node-zx to build and migrate; node-core-js also > > succeeded in its build at that point. I tried to flag the issue for > > upstream (https://github.com/google/zx/issues/462), which they've closed > > as fixed but I don't think they understood the issue. > > > > > > ### node-babel7 ### > > > > This is failing its autopkgtest due to "RangeError: Invalid array > > length". I filed update excuse LP: #1980411 for it, and filed a > > corresponding bug with upstream. It affects Debian too but didn't spot > > a patch or bug report there or upstream for it. > > > > > > ### libxcrypt, kopanocore and apache2 ### > > > > Test failure for apache2 on s390x. The error shown in the log is: > > > > Forbidden > > You don't have permission to access this resource.Reason: Cannot > > perform Post-Handshake Authentication. > > > > However, in my experience the autopkgtests around apache2 seem > > especially flaky and resolve on a retrigger or two, and indeed the > > retrigger has passed. > > > > kopanocore also has a test failure blocking libxcrypt, but on amd64. It > > also appears to be a service detection issue, and possibly also just > > flaky so I retriggered it and it also passed. > > > > libxcrypt also shows perl as blocking on autopkgtests on all arches. > > I didn't invesgitate this one; it doesn't look like a flaky test, but > > rather something with missing perl packages in the archive. I'm > > guessing Perl is in a transition, and eventually the perl dependencies > > will become available, at which point libxcrypt should complete its > > migration. > > > > > > ### oscrypto and androguard ### > > > > androguard's v3.4.0~a1-2 FTBFS is due to dependence on oscrypto, which > > itself FTBFS due to an SSL 3 incompatibility. This is fixed upstream, > > and there's a cherrypickable patch, but I think it might be preferable > > to wait for upstream's 1.3.0 release to be included in Debian and let it > > sync in. > > > > I filed LP: #1980298 as update-excuse for tracking, and
Re: +1 Maintenance Report
On Fri, Jul 01, 2022 at 03:25:39PM -0700, Bryce Harrington wrote: > As William Wilson and Graham Inggs mentioned, there seems to be a higher > than usual amount of FTBFS compared with autopkgtest failures. There > doesn't seem to be a common pattern going on, just a lot of package > ecosystems in flux. Like them, I focused mostly on FTBFS issues, and a > little attention on the sponsoring queue. > > (There are also a large number of NBS package issues currently, although > I didn't look at them. Several transitions like icu, libphobos2, > libpoppler118, and libqgis appear to be in process.) > > > ### riscv64 ftbfs ### > > Bunch of packages were failing to build on riscv64, but succeeded on > retry: > > - rust-fd-find > - mathcomp-zify > - mathcomp-finmap > - mathcomp-bigenough > - mathcomp-algebra-tactics > - rust-xcb > - rust-idna > - rust-tokio-util > - libmseed > - gsequencer > > gsequencer took a suprisingly long amount of time to rebuild (nearly a > full day), and I suspect its prior failure could easily have just been > hw/nw flakiness during such a long run. > > > ### xnee / dia (libpoppler transition) ### > > xnee (riscv64) was ftbfs due to missing build dependency on dia-common. > Dia was ftbfs due to needing updated for the new poppler API. I pulled > a patch from an upstream PR that fixed it: > > https://gitlab.gnome.org/GNOME/dia/-/merge_requests/88 > > With dia successfully migrated, I rebuilt xnee for riscv64 and that also > succeeded and xnee appears like it should migrate over the weekend. > > > ### pdf2djvu (libpoppler transition) ### > > I sponsored Nathan Teodosio's fix for pdf2djvu to update pdf2djvu to the > new poppler API, similar to dia. > (LP: #1980518) > > > ### debian-goodies (merge sponsorship) ### > > Nathan Teodosio also had a merge proposed for debian-goodies, just > carrying a single bit of delta forward. I sponsored the upload. > (LP: #1979538) > > > ### anacron (merge sponsorship) ### > > Another merge uploaded for nteodosio. (LP: #1977739) > > > ### mkosi ## > > Succeeded on retrigger for ppc64el and migrated successfully. > I suspect it was just test flakiness on the hw. > > > ### redis-py-cluster ### > > Test failure resolved on retrigger, and migrated successfully. > > > ### bibtool / texlive-base ### > > texlive-base was blocked by test failure with bibtool. It passed > on retrigger however texlive-base is still bocked by > auto-multiple-choice and latexml which I didn't investigate. > > > ### node-zx and node-core-js ### > > node-core-js is missing node-zx as build dependency. node-zx FTBFS due > to a test case that is trying to access example.com. I disabled the > test case and enabled node-zx to build and migrate; node-core-js also > succeeded in its build at that point. I tried to flag the issue for > upstream (https://github.com/google/zx/issues/462), which they've closed > as fixed but I don't think they understood the issue. > > > ### node-babel7 ### > > This is failing its autopkgtest due to "RangeError: Invalid array > length". I filed update excuse LP: #1980411 for it, and filed a > corresponding bug with upstream. It affects Debian too but didn't spot > a patch or bug report there or upstream for it. > > > ### libxcrypt, kopanocore and apache2 ### > > Test failure for apache2 on s390x. The error shown in the log is: > > Forbidden > You don't have permission to access this resource.Reason: Cannot > perform Post-Handshake Authentication. > > However, in my experience the autopkgtests around apache2 seem > especially flaky and resolve on a retrigger or two, and indeed the > retrigger has passed. > > kopanocore also has a test failure blocking libxcrypt, but on amd64. It > also appears to be a service detection issue, and possibly also just > flaky so I retriggered it and it also passed. > > libxcrypt also shows perl as blocking on autopkgtests on all arches. > I didn't invesgitate this one; it doesn't look like a flaky test, but > rather something with missing perl packages in the archive. I'm > guessing Perl is in a transition, and eventually the perl dependencies > will become available, at which point libxcrypt should complete its > migration. > > > ### oscrypto and androguard ### > > androguard's v3.4.0~a1-2 FTBFS is due to dependence on oscrypto, which > itself FTBFS due to an SSL 3 incompatibility. This is fixed upstream, > and there's a cherrypickable patch, but I think it might be preferable > to wait for upstream's 1.3.0 release to be included in Debian and let it > sync in. > > I filed LP: #1980298 as update-excuse for tracking, and pinged Debian > about the solution to the FTBFS, since it affects them too. > > > ### pygments / pytest ### > > pygments is stuck in Dependency Wait due to it requiring pytest 7, > however we're on pytest 6, and moving to 7 seems like a bold jump, since > pytest is used by a couple thousand packages. I think pygments will
Re: +1 Maintenance Report
On Fri, Jul 01, 2022 at 03:25:39PM -0700, Bryce Harrington wrote: > As William Wilson and Graham Inggs mentioned, there seems to be a higher > than usual amount of FTBFS compared with autopkgtest failures. There > doesn't seem to be a common pattern going on, just a lot of package > ecosystems in flux. Like them, I focused mostly on FTBFS issues, and a > little attention on the sponsoring queue. > (There are also a large number of NBS package issues currently, although > I didn't look at them. Several transitions like icu, libphobos2, > libpoppler118, and libqgis appear to be in process.) These transitions have all been under way for quite a while now (>= 1 week). There's of course no obligation to spend time on NBS packages in particular during +1 maintenance, but it is always valuable to look there, as unlike proposed-migration, NBS must be zeroed before we can release. (BTW maybe you meant libgdal rather than libqgis?) From my perspective, it would be particularly helpful if someone would go through the process of filing any necessary bugs in Debian for the reverse-dependencies of libicu70, libgdal30, libnetpbm10, and librocksdb6.11 so that we can in good conscience remove these packages from kinetic pending Debian resolution of the build failures. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Fri, Jul 01, 2022 at 11:54:12AM -0700, Steve Langasek wrote: > On Fri, Jul 01, 2022 at 01:40:53PM -0500, William Wilson wrote: > > Steve, > > > Thank you for your work on this. I apologize for the lack of detail in my > > earlier email. In order to get g-g-j-pgtype to build in my PPA with > > g-g-j-pgx version 3.x, I had to change a line in d/control. I changed the > > dependency "golang-github-jackc-pgx-v4-dev" to > > "golang-github-jackc-pgx-dev" which is the name of the binary package from > > version 3.x. It then built successfully in a PPA: > > https://launchpad.net/~jawn-smith/+archive/ubuntu/devel-proposed/+packages > > > So I may have misunderstood Bryce's instructions. I was under the > > impression I could: > > >1. Build the modified pgtype package with the dependency change (and > >some version number like 1.10.0-0ubuntu1) > >2. Build the pgx package now that the pgtype package is no longer in NEW > >3. Re-sync the pgtype package from Debian and have it build with the now > >available pgx-v4 package > > > Is this not correct? If this is correct can you please delete the pgtype > > package again so I can upload the modified version? > > Yes, the above is all correct but was not apparent to me given that Bryce > referred to version 1.10.0-3 and you appeared to be confirming that you got > this version building. I think it's fine for you to upload this to the > archive as 1.10.0-3ubuntu1, and then we can copy-package 1.10.0-4 over it. Sorry, yes that was a bit ambiguous. By 'prepare' I was trying to imply that's where some delta might be introduced, but the version number did sound like I might be suggesting a sync. In any case, glad to see it was enough clue to get William on the path to a solution. And thanks again for the quick response, Vorlon. Bryce > There should be no blockers for you uploading 1.10.0-3ubuntu1 to the archive > at your pleasure, as it's > the 1.10.0-3 that's currently in -proposed. > > > On Fri, Jul 1, 2022 at 1:32 PM Steve Langasek > > wrote: > > > > > On Fri, Jul 01, 2022 at 11:28:25AM -0700, Steve Langasek wrote: > > > > > So, I think the bootstrap solution might be: > > > > > > > > 1. Verify that g-g-j-pgtype (1.10.0-3) actually does build > > > > > successfully against g-g-j-pgx-dev (3.6.2-2). (This is probably > > > > > best to verify in a PPA.) If so, then... > > > > > > > > 2. Request an Archive Admin to delete from -proposed: > > > > > - golang-github-jackc-pgtype (1.10.0-4) source & binary > > > > > - golang-github-jackc-pgx (4.15.0-4) source & binary > > > > > > > > 3. Prepare and upload g-g-j-pgtype (1.10.0-3), and verify it > > > > > builds ok. Then proceed with syncpackage on both packages to > > > > > pull > > > > > in the newer versions. > > > > > > > Of course, when an in-archive bootstrap is possible, this is always > > > nicer! > > > > > > > Since William has already confirmed that the above works, I'm not > > > > waiting > > > > for him to ask on Monday and have done the above. > > > > > > However, it doesn't appear to have worked in the archive. > > > > > > https://launchpad.net/ubuntu/+source/golang-github-jackc-pgtype/1.10.0-3/+build/24130112 > > > shows the package is dep-wait on golang-github-jackc-pgx-v4-dev, from the > > > newer golang-github-jackc-pgx that we're trying to bootstrap. > > > > > > So I'll hand this back over to y'all to debug and tell me what's missing > > > :) > > > > > > -- > > > Steve Langasek Give me a lever long enough and a Free OS > > > Debian Developer to set it on, and I can move the world. > > > Ubuntu Developer https://www.debian.org/ > > > slanga...@ubuntu.com vor...@debian.org > > > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > -BEGIN PGP SIGNATURE- > > iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmK/QswACgkQVo0w8yGy > Ez1cqA//ZcLjLnsYRtIpmlU4mWc4hbMUMOxRn7HIuUfaSswwslMEmiyf1vWq9uzX > JN3ehmwabNSTOdLp2bwuG/oav9x+14nwRZNBOEi7v34nVyVRw87OkX8cPlf6dsXe > WIN/XpjeU9sMXvzqskANHNybUIJF/SGcEqUnUT/D6Fex/NP8Yp29tYftE2vXpZ6h > 10ZtzHd3DhOwndL2iyV3H/B9yQ+e+aKPSHhcHA6YnSN8neCAzaAwKarpZLTR+8CD > 3T8SAUHxbBfSYT2eBEiqhKbGFsYYC7ZEOWXfhyXkISXO/AoYdqL8ufYN1zMt/UfZ > 7fr/GMFb24qNDde4ipv57DIq4j5PW4L6ImuwhRPwVcwQ2bT+PUgFHMZiFH622mB/ > v3RLAPII03S2fgEB+YIYV+8feHAkUxrOVLa+2P1U6eonqFQqu5vVeUqb7Lcd5VzV > a0kk6Jkiie34lD1PqENtDdUtRV1DKXEtUq7XCrdUzJmMUrwT3BgSL9qHMmm7VDpa > X/FzkVuhkCvWjIRyQtdMrhSqx9IjsBpWAowO4kdamnw9
Re: +1 Maintenance Report
On Fri, Jul 01, 2022 at 01:40:53PM -0500, William Wilson wrote: > Steve, > Thank you for your work on this. I apologize for the lack of detail in my > earlier email. In order to get g-g-j-pgtype to build in my PPA with > g-g-j-pgx version 3.x, I had to change a line in d/control. I changed the > dependency "golang-github-jackc-pgx-v4-dev" to > "golang-github-jackc-pgx-dev" which is the name of the binary package from > version 3.x. It then built successfully in a PPA: > https://launchpad.net/~jawn-smith/+archive/ubuntu/devel-proposed/+packages > So I may have misunderstood Bryce's instructions. I was under the > impression I could: >1. Build the modified pgtype package with the dependency change (and >some version number like 1.10.0-0ubuntu1) >2. Build the pgx package now that the pgtype package is no longer in NEW >3. Re-sync the pgtype package from Debian and have it build with the now >available pgx-v4 package > Is this not correct? If this is correct can you please delete the pgtype > package again so I can upload the modified version? Yes, the above is all correct but was not apparent to me given that Bryce referred to version 1.10.0-3 and you appeared to be confirming that you got this version building. I think it's fine for you to upload this to the archive as 1.10.0-3ubuntu1, and then we can copy-package 1.10.0-4 over it. There should be no blockers for you uploading 1.10.0-3ubuntu1 to the archive at your pleasure, as it's > the 1.10.0-3 that's currently in -proposed. > On Fri, Jul 1, 2022 at 1:32 PM Steve Langasek > wrote: > > > On Fri, Jul 01, 2022 at 11:28:25AM -0700, Steve Langasek wrote: > > > > So, I think the bootstrap solution might be: > > > > > > 1. Verify that g-g-j-pgtype (1.10.0-3) actually does build > > > > successfully against g-g-j-pgx-dev (3.6.2-2). (This is probably > > > > best to verify in a PPA.) If so, then... > > > > > > 2. Request an Archive Admin to delete from -proposed: > > > > - golang-github-jackc-pgtype (1.10.0-4) source & binary > > > > - golang-github-jackc-pgx (4.15.0-4) source & binary > > > > > > 3. Prepare and upload g-g-j-pgtype (1.10.0-3), and verify it > > > > builds ok. Then proceed with syncpackage on both packages to pull > > > > in the newer versions. > > > > > Of course, when an in-archive bootstrap is possible, this is always > > nicer! > > > > > Since William has already confirmed that the above works, I'm not waiting > > > for him to ask on Monday and have done the above. > > > > However, it doesn't appear to have worked in the archive. > > > > https://launchpad.net/ubuntu/+source/golang-github-jackc-pgtype/1.10.0-3/+build/24130112 > > shows the package is dep-wait on golang-github-jackc-pgx-v4-dev, from the > > newer golang-github-jackc-pgx that we're trying to bootstrap. > > > > So I'll hand this back over to y'all to debug and tell me what's missing :) > > > > -- > > Steve Langasek Give me a lever long enough and a Free OS > > Debian Developer to set it on, and I can move the world. > > Ubuntu Developer https://www.debian.org/ > > slanga...@ubuntu.com vor...@debian.org > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
Steve, Thank you for your work on this. I apologize for the lack of detail in my earlier email. In order to get g-g-j-pgtype to build in my PPA with g-g-j-pgx version 3.x, I had to change a line in d/control. I changed the dependency "golang-github-jackc-pgx-v4-dev" to "golang-github-jackc-pgx-dev" which is the name of the binary package from version 3.x. It then built successfully in a PPA: https://launchpad.net/~jawn-smith/+archive/ubuntu/devel-proposed/+packages So I may have misunderstood Bryce's instructions. I was under the impression I could: 1. Build the modified pgtype package with the dependency change (and some version number like 1.10.0-0ubuntu1) 2. Build the pgx package now that the pgtype package is no longer in NEW 3. Re-sync the pgtype package from Debian and have it build with the now available pgx-v4 package Is this not correct? If this is correct can you please delete the pgtype package again so I can upload the modified version? William On Fri, Jul 1, 2022 at 1:32 PM Steve Langasek wrote: > On Fri, Jul 01, 2022 at 11:28:25AM -0700, Steve Langasek wrote: > > > So, I think the bootstrap solution might be: > > > > 1. Verify that g-g-j-pgtype (1.10.0-3) actually does build > > > successfully against g-g-j-pgx-dev (3.6.2-2). (This is probably > > > best to verify in a PPA.) If so, then... > > > > 2. Request an Archive Admin to delete from -proposed: > > > - golang-github-jackc-pgtype (1.10.0-4) source & binary > > > - golang-github-jackc-pgx (4.15.0-4) source & binary > > > > 3. Prepare and upload g-g-j-pgtype (1.10.0-3), and verify it > > > builds ok. Then proceed with syncpackage on both packages to pull > > > in the newer versions. > > > Of course, when an in-archive bootstrap is possible, this is always > nicer! > > > Since William has already confirmed that the above works, I'm not waiting > > for him to ask on Monday and have done the above. > > However, it doesn't appear to have worked in the archive. > > https://launchpad.net/ubuntu/+source/golang-github-jackc-pgtype/1.10.0-3/+build/24130112 > shows the package is dep-wait on golang-github-jackc-pgx-v4-dev, from the > newer golang-github-jackc-pgx that we're trying to bootstrap. > > So I'll hand this back over to y'all to debug and tell me what's missing :) > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 Maintenance Report
On Fri, Jul 01, 2022 at 11:28:25AM -0700, Steve Langasek wrote: > > So, I think the bootstrap solution might be: > > 1. Verify that g-g-j-pgtype (1.10.0-3) actually does build > > successfully against g-g-j-pgx-dev (3.6.2-2). (This is probably > > best to verify in a PPA.) If so, then... > > 2. Request an Archive Admin to delete from -proposed: > > - golang-github-jackc-pgtype (1.10.0-4) source & binary > > - golang-github-jackc-pgx (4.15.0-4) source & binary > > 3. Prepare and upload g-g-j-pgtype (1.10.0-3), and verify it > > builds ok. Then proceed with syncpackage on both packages to pull > > in the newer versions. > Of course, when an in-archive bootstrap is possible, this is always nicer! > Since William has already confirmed that the above works, I'm not waiting > for him to ask on Monday and have done the above. However, it doesn't appear to have worked in the archive. https://launchpad.net/ubuntu/+source/golang-github-jackc-pgtype/1.10.0-3/+build/24130112 shows the package is dep-wait on golang-github-jackc-pgx-v4-dev, from the newer golang-github-jackc-pgx that we're trying to bootstrap. So I'll hand this back over to y'all to debug and tell me what's missing :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Fri, Jul 01, 2022 at 10:08:26AM -0700, Bryce Harrington wrote: > > Are there any methods for dealing with this type of circular dependency? > > In Debian I can see they did a binary-only upload to fix this, but as > > far as I know there is no such thing in Ubuntu. > Right, that's not generally an available option for us. The two > approaches I've had success with are a) bypassing test-during-build, and > b) bootstrapping from earlier versions. Towards the end of this page is > a section on handling circular dependencies that explain these two: > > https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/ProposedMigration.md1 > In this case, it doesn't look like the dependency is due to testing so > option (b) may be worth looking at. It appears that g-g-j-pgtype > used to depend on g-g-j-pgx-dev, at version 1.10.0-3, which is currently > available in kinetic. For the record, Launchpad does have the concept of a bootstrap archive and a bootstrap build, which is how we bootstrap new architectures; it can also be used to bootstrap circular build-dep loops like this. However, it requires the intercession of both an archive admin and a Launchpad admin to make use of, so while I have a certain preference for it wrt centralized auditability of where bootstraps came from, I understand if developers prefer to avoid this - so long as any ppa-based bootstraps get done in properly configured/vetted ppas (devirtualized ppas). > So, I think the bootstrap solution might be: > 1. Verify that g-g-j-pgtype (1.10.0-3) actually does build > successfully against g-g-j-pgx-dev (3.6.2-2). (This is probably > best to verify in a PPA.) If so, then... > 2. Request an Archive Admin to delete from -proposed: > - golang-github-jackc-pgtype (1.10.0-4) source & binary > - golang-github-jackc-pgx (4.15.0-4) source & binary > 3. Prepare and upload g-g-j-pgtype (1.10.0-3), and verify it > builds ok. Then proceed with syncpackage on both packages to pull > in the newer versions. Of course, when an in-archive bootstrap is possible, this is always nicer! Since William has already confirmed that the above works, I'm not waiting for him to ask on Monday and have done the above. Also, rather than "prepare and upload", step 3) should be "use syncpackage with the -V option" to keep the launchpad package history clean. And I'm not sure if syncpackage works to re-copy from Debian the same source packages that had previously been published? I use "copy-package -e $version --force-same-destination "for this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
Bryce, Thanks for replying here and in IRC. it does appear g-g-j-pgtype does successfully build with g-g-j-pgx 3.6.2-2. I'm about to EOW but will contact an AA next week about the next steps. Thanks again! William On Fri, Jul 1, 2022 at 12:08 PM Bryce Harrington < bryce.harring...@canonical.com> wrote: > On Fri, Jul 01, 2022 at 11:34:13AM -0500, William Wilson wrote: > > Greetings ubuntu-devel, > > > > This week I was on +1 maintenance and I noticed an odd circular > dependency > > between two packages. > > > >- Package golang-github-jackc-pgtype is in NEW and is dependency wait > on > >golang-github-jackc-pgx-v4-dev. > >- Package golang-github-jackc-pgx-v4-dev is a new binary package to be > >built from src:golang-github-jackc-pgx as it migrates from major > version v3 > >to v4. > >- src:golang-github-jackc-pgx can not build any v4 binaries without > >golang-github-jackc-pgtype-dev, which is built from > >src:golang-github-jackc-pgtype > > > > > > The TL;DR of this is that src:golang-github-jackc-pgtype cannot build > > without binaries from src:golang-github-jackc-pgx, which cannot build > > without binaries from src:golang-github-jackc-pgtype, and thus there is a > > circular dependency. > > > > Are there any methods for dealing with this type of circular dependency? > In > > Debian I can see they did a binary-only upload to fix this, but as far > as I > > know there is no such thing in Ubuntu. > > Right, that's not generally an available option for us. The two > approaches I've had success with are a) bypassing test-during-build, and > b) bootstrapping from earlier versions. Towards the end of this page is > a section on handling circular dependencies that explain these two: > > > https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/ProposedMigration.md1 > > In this case, it doesn't look like the dependency is due to testing so > option (b) may be worth looking at. It appears that g-g-j-pgtype > used to depend on g-g-j-pgx-dev, at version 1.10.0-3, which is currently > available in kinetic. > > So, I think the bootstrap solution might be: > > 1. Verify that g-g-j-pgtype (1.10.0-3) actually does build > successfully against g-g-j-pgx-dev (3.6.2-2). (This is probably > best to verify in a PPA.) If so, then... > > 2. Request an Archive Admin to delete from -proposed: > - golang-github-jackc-pgtype (1.10.0-4) source & binary > - golang-github-jackc-pgx (4.15.0-4) source & binary > > 3. Prepare and upload g-g-j-pgtype (1.10.0-3), and verify it > builds ok. Then proceed with syncpackage on both packages to pull > in the newer versions. > > If step #1 does *not* work, then the problem is more complex. It might > be worth checking in with the Debian maintainer for ideas at that point. > > Bryce > > > I briefly thought about combining the packages, but that is not idea > > for a few reasons: > > > >1. It breaks our golang-github-- packaging convention. > >2. It would install possibly un-needed source code on people's > machines > >if they install the combined package but really only needed one. > > > > Now for the report of things I was able to solve: I usually focus mainly > on > > failed tests, but I noticed there were quite a few FTBFS packages, so I > > decided to focus on those. > > > > libdigidoc - openssl v3 related regression. This is fixed in Ubuntu and I > > have created a QA upload for Debian. This will be sponsored by ginggs. > > > > rinutils - filed https://launchpad.net/bugs/1980243 and > > https://bugs.debian.org/1014169 to explain that it needs new > dependencies > > packaged > > > > golang-github-masterminds-sprig - I fixed a regression in this package > > which unblocked: > > * golang-step-crypto > > * golang-step-cli-utils > > * golang-github-smallstep-certificates > > Thanks to seb128 for helping shepherd some of these binary packages > through > > the NEW queue > > > > golang-oras-oras-go - Fixed a regression in Ubuntu and forwarded to > Debian > > > > golang-mongodb-mongo-driver - Fixed a regression in Ubuntu (and forwarded > > to Debian) which unblocks: > > * golang-github-go-openapi-strfmt > > * golang-github-go-openapi-validate > > * golang-github-go-openapi-runtime > > > > golang-github-openshift-imagebuilder: Fixed regression in Ubuntu and > > forwarded to Debian > > > > scamper - Fixed a regression in Ubuntu and forwarded to Debian > > > > Thank you for reading, > > > > William 'jawn-smith' Wilson > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 Maintenance Report
On Fri, Jul 01, 2022 at 11:34:13AM -0500, William Wilson wrote: > Greetings ubuntu-devel, > > This week I was on +1 maintenance and I noticed an odd circular dependency > between two packages. > >- Package golang-github-jackc-pgtype is in NEW and is dependency wait on >golang-github-jackc-pgx-v4-dev. >- Package golang-github-jackc-pgx-v4-dev is a new binary package to be >built from src:golang-github-jackc-pgx as it migrates from major version v3 >to v4. >- src:golang-github-jackc-pgx can not build any v4 binaries without >golang-github-jackc-pgtype-dev, which is built from >src:golang-github-jackc-pgtype > > > The TL;DR of this is that src:golang-github-jackc-pgtype cannot build > without binaries from src:golang-github-jackc-pgx, which cannot build > without binaries from src:golang-github-jackc-pgtype, and thus there is a > circular dependency. > > Are there any methods for dealing with this type of circular dependency? In > Debian I can see they did a binary-only upload to fix this, but as far as I > know there is no such thing in Ubuntu. Right, that's not generally an available option for us. The two approaches I've had success with are a) bypassing test-during-build, and b) bootstrapping from earlier versions. Towards the end of this page is a section on handling circular dependencies that explain these two: https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/ProposedMigration.md1 In this case, it doesn't look like the dependency is due to testing so option (b) may be worth looking at. It appears that g-g-j-pgtype used to depend on g-g-j-pgx-dev, at version 1.10.0-3, which is currently available in kinetic. So, I think the bootstrap solution might be: 1. Verify that g-g-j-pgtype (1.10.0-3) actually does build successfully against g-g-j-pgx-dev (3.6.2-2). (This is probably best to verify in a PPA.) If so, then... 2. Request an Archive Admin to delete from -proposed: - golang-github-jackc-pgtype (1.10.0-4) source & binary - golang-github-jackc-pgx (4.15.0-4) source & binary 3. Prepare and upload g-g-j-pgtype (1.10.0-3), and verify it builds ok. Then proceed with syncpackage on both packages to pull in the newer versions. If step #1 does *not* work, then the problem is more complex. It might be worth checking in with the Debian maintainer for ideas at that point. Bryce > I briefly thought about combining the packages, but that is not idea > for a few reasons: > >1. It breaks our golang-github-- packaging convention. >2. It would install possibly un-needed source code on people's machines >if they install the combined package but really only needed one. > > Now for the report of things I was able to solve: I usually focus mainly on > failed tests, but I noticed there were quite a few FTBFS packages, so I > decided to focus on those. > > libdigidoc - openssl v3 related regression. This is fixed in Ubuntu and I > have created a QA upload for Debian. This will be sponsored by ginggs. > > rinutils - filed https://launchpad.net/bugs/1980243 and > https://bugs.debian.org/1014169 to explain that it needs new dependencies > packaged > > golang-github-masterminds-sprig - I fixed a regression in this package > which unblocked: > * golang-step-crypto > * golang-step-cli-utils > * golang-github-smallstep-certificates > Thanks to seb128 for helping shepherd some of these binary packages through > the NEW queue > > golang-oras-oras-go - Fixed a regression in Ubuntu and forwarded to Debian > > golang-mongodb-mongo-driver - Fixed a regression in Ubuntu (and forwarded > to Debian) which unblocks: > * golang-github-go-openapi-strfmt > * golang-github-go-openapi-validate > * golang-github-go-openapi-runtime > > golang-github-openshift-imagebuilder: Fixed regression in Ubuntu and > forwarded to Debian > > scamper - Fixed a regression in Ubuntu and forwarded to Debian > > Thank you for reading, > > William 'jawn-smith' Wilson > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
Hi, On Mon, Jun 13, 2022 at 7:29 AM Simon Chopin wrote: > ruby-gitlab-fog-azure-rm: > The test suite fails due to Ruby 3.0 incompatibilities. > I patched out the Proc.new.call invocations into explicit block.call ones, > submitted both to upstream and Debian. The upstream MR has been merged > and a new version has been released, but the Salsa MR is still opened: > > https://salsa.debian.org/ruby-team/ruby-gitlab-fog-azure-rm/-/merge_requests/1 > I merged your patch and sponsored the upload in Debian. I did a small change where you forgot to add a colon after "Closes" in the changelog. Thanks! Lucas Kanashiro. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Mon, May 30, 2022 at 09:38:33AM -0300, Lucas Kanashiro wrote: > Hi, > > Last week was my +1 maintenance shift, this time I decided to try to unblock > packages stuck in -proposed for too long (bottom of the excuses page). Below > you can find a summary of what I did: > > # debos > > Revisit this package and submitted a patch to implement the solution vorlon > brought up in the discussion (introducing some delta): > > https://bugs.launchpad.net/ubuntu/+source/debos/+bug/1940077 > > Package uploaded and added a comment to the Debian bug about it. > > # ruby-parallel > > Gave it a shot with the latest upstream release and I was not able to > reproduce > the autopkgtest failure anymore. Uploaded version 1.22.1-1 to Debian. It was > synced but it is still failing, and needs further investigation. I tested this locally with the qemu backend and it passed, on amd64, after adding more processors and RAM. Subsequently, I added it to big_packages for all arches except armhf. I'll also retry the tests. Cheers, -- Brian Murray -- 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 23-27 May 2022
And I forgot to mention: astroquery I added a patch to fix the permission denied on accessing files here : https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+sourcepub/13638113/+listing-archive-extra But then autopkgtest fails on armhf https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic-alexghiti-riscv/kinetic/armhf/a/astroquery/20220525_104624_1622f@/log.gz There is no obvious reason in the link above but when launched locally, the error was not the same and may be more helpful: vals = ['9048843364125'] def generic_converter(vals): > return numpy.array(vals, numpy_type) E OverflowError: Python int too large to convert to C long /usr/lib/python3/dist-packages/astropy/io/ascii/core.py:1004: OverflowError I won't have time to follow up on this though. Thanks, Alex On Mon, May 30, 2022 at 11:54 AM Alexandre Ghiti < alexandre.gh...@canonical.com> wrote: > Hi, > > I was on +1 maintenance last week, below what I worked on: > > netdata > == > > It was a simple sync since Debian merged the patch that I had added > previously. This was uploaded by @Graham Inggs . > > node-gulp-coffee > = > > node-gulp-coffee timeouts on tests on arm64 only, I increased the timeout > and the tests passed. This was uploaded by @Graham Inggs . > > libgpg-error > = > > It regressed on i386 because debian removed the test directive > "skip-not-installable". Indeed, Ubuntu i386 autopkgtest runners actually > run on amd64 and use multi-arch which then used to trigger amd64 tests on > for i386 builds which then failed. This was fixed by @Lukas Märdian here > https://bugs.launchpad.net/ubuntu/+source/libgpg-error/+bug/1975673. But > as explained in the bug report, the i386 test still fails: this is because > autopkgtest tries to install gcc-mingw-w64-i686:i386 which does not exist, > gcc-mingw-w64-i686:all does though. Either a fix is needed in autopkgtest > in order to fallback to :all when :$arch does not, or I was told that this > package could be missing Multi-Arch: foreign field. *Anyway, I'm still > working on this.* > > aqsis > > > aqsis FTBFS on armhf because Debian had support for qt5 and armhf qt5 > libraries lack support for some OpenGL functions: indeed, armhf qt5 > libraries use the OpenGL ES 2.0 mode > (qtbase-opensource-src-5.15.4+dfsg/debian/rules), which is only a subset of > OpenGL 2.0 and does not contain the missing functions ( > https://www.khronos.org/registry/OpenGL/specs/es/2.0/es_cm_spec_2.0.pdf). > And it regressed on i386 because the last build for this arch was removed > from release: I added a Britney hint to make it pass (Thanks @Graham Inggs > for this). > > This was uploaded by @Graham Inggs . > > dropbear > === > > dropbear regressed on all archs because of the following issues: > > - mkdir fail because ~/.ssh already exists => use mkdir -p > - tests find the installed kernel by matching kernel packages suffixed by > -$arch (like Debian does) whereas in Ubuntu they are suffixed by -generic > - mmdebstrap fails because the sources.list was grepped against 'Origin: > Debian' => change that for 'Origin: Ubuntu' > > The package built successfully in my PPA and I locally validated that > autopkgtest passes on amd64 but I had to increase the memory size of the > VM, I'll add this package to big_packages too. @Graham Inggs > just told me that autopkgtest failed on > armhf for another reason, I'll fix that and ask for uploading: *I'm still > working on this*. > > That's it, > > Thanks, > > Alex > > -- 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
Hi Robie On Fri, 13 May 2022 at 23:04, Robie Basak wrote: > octave is in dep-wait on riscv64 for libpetsc-real3.16-dev > Produced by src:petsc which FTBFS on riscv64 > FTBFS is because of missing symbol SCOTCH_ParMETIS_V3_NodeND > On amd64 this is shipped in libptscotchparmetisv3-7.0.1.so in > libptscotch-7.0_7.0.1-2_amd64.deb > Also available on riscv64 > So why does the configure script not find it specifically on riscv64? Not > sure but it's not looking in libptscotchparmetisv3.so at all. Looks like this > was fixed in petsc upstream commit 3307d110e72ee4e6d2468971620073eb5ff93529 > that hasn't been released yet. Upstream latest tag is v3.17.1. petsc is > 3.16.6 in Ubuntu and Debian has 3.17.0+dfsg1-1exp1 in experimental. > petsc is currently built on all archs except riscv64, but a rebuild of amd64 > fails for me locally. > Looks like this generally needs a deeper investigation. Upstream has a > very large number of recent commits. It might be easier just to wait for > them to release rather than patch up our older version. This looks like version skew to me; the failed petsc build on riscv64 was against libscotch-dev 7.0.1-2, while the successful builds on the other architectures were against libscotch-dev 6.1.3-1. As you noticed, petsc FTBFS on amd64 (and everywhere else) right now, I believe this is due to the hypre/scalapack/scotch/petsc/slepc transitions being entangled. I have done a bunch of no-change rebuilds for these, and hopefully petsc will be able to build later today. Regards Graham -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Right place to distribute general-purpose dev tools [Re: +1 maintenance report]
On Tue, Apr 05, 2022 at 11:36:20AM +0100, Robie Basak wrote: > On Mon, Apr 04, 2022 at 10:35:36PM -0700, Steve Langasek wrote: > > I unfortunately do not have a good place to publish it at the moment so that > > it's more visible to developers. Suggestions welcome. > On the server team, as an experiment we started a git repository to > share this kind of "I wrote a script". There's no expectation that > scripts published there are polished, and deliberately there's no code > review requirement to make changes. The idea is that it's a low friction > place to share what ad-hoc tools we have quickly knocked up. Think of it > like an incubator for scripts - if something grows to the point where it > would best belong somewhere more specific, it could "graduate" there. > The repository is here: > https://code.launchpad.net/~ubuntu-server/+git/ubuntu-helpers > Would it be useful to make this wider now and bring it to Ubuntu > developers generally? Right now the ACL is ~canonical-server and > ~ubuntu-server-dev. We could for example add ~canonical (or maybe > ~canonical-tech?) and ~ubuntu-dev, and maybe move it into a more > suitable team. If we do that, should we call it ubuntu-dev-tools? Should we be distributing it as snap + deb + git repo? Or should this remain just a low-threshold git repo but with a pipeline for moving tools into ubuntu-dev-tools? I appreciate the suggestion. Foundations has a similar sort of catch-all git repo, but it's not public. There is the lp:ubuntu-archive-tools repository, which has tools that everyone who works on +1 maintenance should have (i.e.: retry-autopkgtest-regressions), but I don't like indefinitely expanding that repo because of the necessarily restricted write ACL. I think a common ubuntu-helpers repo could definitely be a good first step. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
On Mon, Apr 04, 2022 at 10:35:36PM -0700, Steve Langasek wrote: > I unfortunately do not have a good place to publish it at the moment so that > it's more visible to developers. Suggestions welcome. On the server team, as an experiment we started a git repository to share this kind of "I wrote a script". There's no expectation that scripts published there are polished, and deliberately there's no code review requirement to make changes. The idea is that it's a low friction place to share what ad-hoc tools we have quickly knocked up. Think of it like an incubator for scripts - if something grows to the point where it would best belong somewhere more specific, it could "graduate" there. The repository is here: https://code.launchpad.net/~ubuntu-server/+git/ubuntu-helpers Would it be useful to make this wider now and bring it to Ubuntu developers generally? Right now the ACL is ~canonical-server and ~ubuntu-server-dev. We could for example add ~canonical (or maybe ~canonical-tech?) and ~ubuntu-dev, and maybe move it into a more suitable team. 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
Thanks for your work on +1 maintenance! One bit I want to call attention to: On Mon, Apr 04, 2022 at 10:17:44PM -0700, Bryce Harrington wrote: > ## NBS ## > I uploaded no-change rebuilds of the 11 NBS packages to a PPA; 4 of > these build successfully, so I uploaded the no-change rebuilds to jammy: > libosmocore - 1.6.0-3build1 > osmo-pcu - 0.8.0-3build3 > mbedtls - 2.28.0-1build1 > ncbi-vdb - 2.11.2+dfsg-4build2 > libosmocore and mebdtls successfully transitioned. The other two are > still in proposed but I ran out of +1 maint time before I could > investigate, so leaving for next person and hoping they're at least > nudged forward. ncbi-vdb and osmo-pcu were already present in -proposed and blocked by autopkgtests; there was no need for a no-change rebuild here. libosmocore and mbedtls also didn't need rebuilds, they were the source packages whose binaries *are* NBS and it is the other reverse-dependencies of these packages that need to be resolved. I recommend using the attached script for no-change rebuilds, as it will reliably calculate the set of packages that need uploading for a given old NBS dependency and a new expected dependency; it just needs to be run in an environment with a full set of sources for the dev series and the -proposed pocket. It will also tell you exactly *why* no-change uploads are not needed for some packages (i.e.: package is already built in -proposed; package present in -proposed but not built). I unfortunately do not have a good place to publish it at the moment so that it's more visible to developers. Suggestions welcome. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org #!/bin/sh set -e dry_run=false excludes="" changelog="" while [ $# -gt 0 ]; do case $1 in --dry-run) dry_run=: ;; --exclude) shift excludes="$1 $excludes" ;; --changelog) shift changelog="$1" ;; *) if [ -z "$olddep" ]; then olddep=$1 elif [ -z "$newdep" ]; then newdep=$1 else echo "Unknown argument: $1" exit 1 fi ;; esac shift done sudo apt-get install wget ubuntu-dev-tools grep-dctrl devscripts equivs dput \ distro-info release=$(distro-info -d) if [ -z "$changelog" ]; then changelog="No-change rebuild against $newdep" fi echo "Transitioning $olddep -> $newdep" oldre=$(echo "$olddep" | sed -e's/+/\\+/g') newre=$(echo "$newdep" | sed -e's/+/\\+/g') # don't include our own source package in the list of those needing rebuilds... oursrc=$(grep-dctrl -n -sSource:Package -w -FPackage "$oldre" /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_"$release"_*Packages |head -n1) for pkg in $( grep-dctrl -n -sSource:Package \( -w -FDepends "$oldre" \ -o -w -FPre-Depends "$oldre" \) \ -a '!' -X -FSource:Package "$oursrc" \ /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_"$release"_*Packages \ /var/lib/apt/lists/*.ubuntu.com_ubuntu*_dists_"$release"-proposed_*Packages \ | sed -e's/(.*)//' | sort -u) do # special-casing when needed skip_package=false for exclude in $excludes; do if [ "$pkg" = "$exclude" ]; then skip_package=: fi done if $skip_package; then continue fi if grep-dctrl -q -FSource:Package -X "$pkg" \ -a '!' -w -FDepends "$oldre" \ -a -w -FDepends "$newre" \ /var/lib/apt/lists/*.ubuntu.com_ubuntu*_dists_"$release"-proposed_*Packages then echo "Package $pkg already fixed in $release-proposed." continue fi if proposed_ver=$(grep-dctrl -sVersion -n -FPackage -X "$pkg" /var/lib/apt/lists/*.ubuntu.com_ubuntu*_dists_"$release"-proposed_*Sources) then echo "Package $pkg already present in $release-proposed (but not fixed)" if ! grep-dctrl -q -FSource:Package -X "$pkg" \ -a -FVersion -X "$proposed_ver" \ /var/lib/apt/lists/*.ubuntu.com_ubuntu*_dists_$release-proposed_*Packages then echo " (Package $pkg not built in $release-propo
Re: +1 maintenance report
On Fri, Feb 18, 2022 at 05:14:46PM +, Robie Basak wrote: > I was on +1 maintenance this week. > > It's been a long time (years) since I last did this. I'm not sure I had > a good feel for what would be useful to work on, so rather than spending > time changing my mind constantly I just focused on what I saw > regardless. > > There seem to be a lot of delays waiting on amd64 dep8 tests. Near the > start of the week there were 6705 tests in the queue. At the end of the > week there are 4643. But still the queueing time is generally over a > week. It would be nice if I could see what entries in the queue were > submitted manually by others. This doesn't seem to be presented at > https://autopkgtest.ubuntu.com/running. Christian thought this > information was available in the associated json output, but I haven't > looked into this. > > On the topic of delays, I feel like I've only just gotten into a lot of > this. Because of the lag between taking some action and seeing the > result, I ended up with many pending items at any given time, because > most of the time all other items would be waiting on something before I > could proceed further with them. So I'd look for something else. So, as > I am writing up my week, I am finding many loose ends that I did not > resolve because I had started them but then previously blocked items > needed attention again. That does seem to be a pretty good description of the +1 maintenance experience. :-) I imagine every +1'er has their own strategy for dealing with that chaotic workflow. What I do is create a bulleted list of every package I touch, noting the action I take, next steps depending on outcome, theories on what's wrong, and the ultimate resolution (if any). > In general I'd have liked to have seen more coordination with others on > what is going on. Sometimes I might spend an hour tracking something > down, coming to a conclusion about what action is necessary to take, and > then finding that somebody had already figured this out, done it and the > appropriate rebuild or dep8 retry was in progress or in a queue > somewhere. This is frustrating. I'd prefer to spend my efforts on > something nobody else is looking at. But there isn't any clear process > to determine what that is. A process I've seen others use, and that I've adopted myself, is to file bugs tagged update-excuse, and use the bug report for tracking findings and next-actions and such. This seems to work well for the more challenging transition items, but is overkill for smaller stuff where it just needs a customized retriggering or a straightforward patch. But unfortunately, for that smaller stuff we have poor transparency into what's currently running. Since britney can sometimes take a few hours in its processing cycle even for simple things, that creates a big window for people to submit redundant retriggers. Sometimes I wonder if we directed some of the +1 effort towards tool improvements if we could get a better workflow, or maybe even automate away some of the tasks. > I found a common use case was that I'd know the binary or source package > names for extra things in proposed to retry failing dep8 tests against. > But looking up all the versions, converting to source package names and > URL-encoding manually was tedious. retry-autopkgtest-regressions in > ubuntu-archive-tools didn't seem suitable for this, and nor could I find > anything in ubuntu-helpers, so I knocked something up for this use case: > https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak/autopkgtest-urls > I just give it the source or binary package names I want, and it looks > up the details from a chdist and outputs the retry URLs. Yeah I also made a tool for that (I'm sure others have as well). Mine is at: https://launchpad.net/~bryce/+git/excuses-kicker It uses a downloaded autopkgtest.db to identify other packages that the given package has been triggered with before, looks up if those packages have versions in -proposed, and then constructs URLs including triggers for those packages. $ excuses-kicker -a amd64 php-doctrine-dbal https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=amd64&package=php-doctrine-dbal&trigger=php-doctrine-dbal%2F3.3.2%2Bdfsg-1ubuntu1&trigger=php-doctrine-persistence%2F2.3.0-2ubuntu2&trigger=symfony%2F5.4.4%2Bdfsg-1ubuntu2&trigger=orafce%2F3.18.1-1&trigger=doctrine%2F2.11.1%2Bdfsg-1ubuntu1&trigger=php-nesbot-carbon%2F2.55.2-1&trigger=php-twig%2F3.3.8-2&trigger=php-doctrine-data-fixtures%2F1.5.2-1&trigger=gtk4%2F4.6.1%2Bds-1&trigger=php8.1%2F8.1.2-1build1&trigger=php-symfony-security-acl%2F3.3.0-1&trigger=postgresql-14%2F14.2-1&trigger=link-grammar%2F5.10.2~dfsg-2ubuntu1&trigger=php-psr-log%2F3.0.0-1&trigger=php-doctrine-cache%2F2.1.1-3ubuntu1 There's also options to add/remove triggers to customize things a bit. It's still missing a few features and the docs are poor so I hesistate to recommend it broadly but I've found this tool quite
Re: +1 maintenance report
On Mon, Feb 14, 2022 at 03:16:56PM +0100, Alexandre Ghiti wrote: > Hi, > > I was on +1 maintenance last week and I focused on python3-defaults > regressions: > > libapache2-mod-python > --- > > This package must be adapted to support python 3.10, patches can be > found here > https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-python/+bug/1960088 > However, as I explained in the above bug report (and was already > mentioned by the author), a segfault is triggered when we use the > buffer returned by PyArg_ParseTuple. > > pytest > > > Upstream patches were necessary to support 3.10 which allowed > re-enable tests that were removed (thanks to Graham) > Graham uploaded this new version and that fixed autopkgtests. > > pytest-mpi > -- > > No problem with this package, simply a python deprecation warning that > is output to stderr which makes autopkgtest fail: I fixed this warning > in the tox package by simply replacing distutils.sysconfig with > sysconfig. > Graham uploaded this new version and that fixed autopkgtests. > > pytest-skip-markers > -- > > Autopkgtests fails because of pyfakefs usage of _from_parts which > prototype is different in python 3.10: I struggled to cherry-pick > upstream patches to fix in pyfakefs package so I bumped it to version > 4.5.4 and that was merged in debian by Graham. > This package synced to Ubuntu and that fixed autopkgtests. > > python-dugong > > > One test timeout on ppc64el: I was able to reproduce the problem > locally in a VM but not to fix it. > > python-ml-collection > --- > > Simple fix to support python 3.10 which consisted in changing > 'collections' to 'collections.abc'. > Graham uploaded this new version and that fixed autopkgtests. > > python-pip > -- > > Against python 3.10, python-pip installs packages in the wrong > directory: it is installed > /usr/lib/python3.10/site-packages/world-4.1.1.dist-info whereas it is > expected to be in /usr/local/lib/python3.10/dist-packages/. A bug > report can be found here: > https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1960608 > @stefanor advised to enable a patch that was currently disabled in > python 3.10: I rebased it and it's currently building in my PPA. I'll > keep @doko and @stefanor posted if that fixes the problem. > > q2-demux > -- > > Simply a retrigger on the new version from debian, thanks Graham. > > q2-cli > --- > > This package is not compatible with python-click >= 8 and was asked > for removal by Graham (it was already removed in debian): > https://bugs.launchpad.net/ubuntu/+source/q2cli/+bug/1960593 > > shasta > - > > New version 0.8.0-1 fails because the autopkgtest VM is too 'small': I > added it to the list of big_packages, it was merged by Brian Murray > and we should retrigger its build soon. But that may not pass since in > Debian, peak memory usage showed > 9GB. > https://ci.debian.net/data/autopkgtest/testing/amd64/s/shasta/19119761/log.gz It looks like Graham ran these tests on the 13th and a m1.large system was used but that they still failed. What are our options now? -- Brian Murray -- 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
Hiya, On Mon, Jan 24, 2022 at 9:51 PM Utkarsh Gupta wrote: > ## node-pbkdf2 (LP: #191828) > > The tests have been failing on s390x because of it > being big-endian but I've been in touch with people > on the Debian side (we're all part of the JS team) > and we're trying to fix this. The upstream is dead > but we've proposed a first patch, which whilst doesn't > fully resolve the issue, it brings us a lot closer > to fix the issue at hand. I'll keep working with > them and keep updating the bug as and when we have > an update. This has now been fixed via 3.1.2-2 and the package has migrated. \o/ - u -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Fri, Dec 17, 2021 at 12:18 PM Simon Chopin wrote: > I picked up a short +1 shift for the last two days of the week. I > focused on -proposed migrations. > > # ruby-gnome > > Fix the autopkgtests for ruby-gnome, which were missing a dependency on > ruby-webrick after the ruby 3.0 transition, which removed said module from > the standard library. > > # paperwork > > investigated an autopkgtest failure, but it ended up being solved by a > Debian sync before > I could do anything about it ¯\\_(ツ)_/¯ Those two fixes were the last things needed for gobject-introspection and pygobject to migrate out of -proposed. Thank you for the help, and enjoy your holidays! Jeremy Bicha -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Sat, Nov 20, 2021 at 05:59:49PM -0800, Steve Langasek wrote: > segyio: > Tries to use MINSIGSTKSZ as part of a constant expression, but in glibc 2.34 > this now expands to a call to sysconf(). Needs a bit more C++ surgery than > I was prepared to do at the end of my shift. Filed LP: #1951658. The code in question, in turns out, is imported from catch2, a project which is also vendored in spring. Since spring is blocking the glew transition (and therefore also the poppler transition), I adapted the Catch2 upstream fix so that spring would build. If anyone wants to fix segyio, or if this turns out to be embedded in other packages, the fix is c0d0a50bdb2ae2f749443c0386c2b25379bdbf76 from https://github.com/catchorg/Catch2. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
