Re: +1 maintenance day report
On Tue, 19 Jul 2022 at 05:31, Paride Legovini wrote:
> mathcomp-multinomials:
> - holding 3 packages
> - missing builds on all archs but riscv64
> - reason: missing b-deps (riscv64 got lucky because it slow)
> - retriggered builds; built everywhere but on arm64.
> - reason for missing arm64 build:
>.
>The following packages have unmet dependencies:
> libcoq-mathcomp-bigenough : Depends: libcoq-mathcomp-ssreflect-94ef7
>E: Unable to correct problems, you have held broken packages.
>.
> - HANDOVER: I think we just need a no-change rebuild of
>src:mathcomp-bigenough to rebuild against a newer ssreflect.
>
I did this.
qiime:
> - holding 2 packages
> - direct autopkgregression on armhf, with error:
>AssertionError: dtype('int64') !=
> - I wasn't expecting this to ever pass on armhf and did a
>migration-reference/0 retrigger, but it actually passed!
> - I expect the package to now be a candiate.
>
This is backwards, I think? The reference test succeeded but the new
version fails --> this is a regression on armhf. However the Debian
maintainer has requested removal on 32 bit arches:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014692. I guess we
should follow.
Cheers,
mwh
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance report
Hi, I was on +1 last week. Here is my report: ### python-llfuse autopkgtest regression on armhf This was caused by a 32-bit integer overflow in one of the tests. I changed the offending test value to fit in 32-bit, and forwarded the patch upstream. William sponsored an upload that resolved this. ### gtk-gnutella FTBFS (https://pad.lv/1981474) The FTBFS is due to checking PTHREAD_STACK_MIN != 0 with preprocessor directives. But, PTHREAD_STACK_MIN may be defined dynamically, so it should be checked at run time. William sponsored an upload that resolved this. ### 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. ### reprotest FTBFS (https://pad.lv/1981624) This package hardcodes py39 in tox.ini, so when python 3.10 is the default this FTBFS. This package should dynamically set the tox env in debian/rules. William sponsored an upload that resolved this. ### pydantic FTBFS (https://pad.lv/1981341) The failing test interacts with environment variables to initialize a configuration (as a Python object). The test adds a 'v' field to the class, with the default value of 'default'. The test case expects that this class will *not* be changed by the execution environment. However, in launchpad builds, the env var V=1 is configured. This causes the assertion failure seen in the FTBFS log. William sponsored an upload that resolved this. ### fastapi FTBFS This needed the new version of pydantic, and a re-build succeeded after we uploaded pydantic. ### sqlmodel FTBFS The build time tests fail because of a bug in python3-fastapi (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005635). That bug was fixed by fastapi in kinetic-proposed, so once fastapi built again (as a result of the pydantic fix), this package was able to build again too. ### tcpreplay no build on armhf (https://pad.lv/1981635) The immediate cause of this is that armhf is not enabled in debian/control. When armhf is re-enabled, it FTBFS with https://github.com/appneta/tcpreplay/issues/725. That can be worked-around by patching configure.ac to set FORCE_ALIGN on arm* arches. But, then there is another bug (https://github.com/appneta/tcpreplay/issues/726) that causes FTBFS. It seems that the second bug is a todo item for the next upstream release, so maybe it is best to just wait for the next upstream release to resolve this. ### ruby-jwt FTBFS The ruby-jwt package does not yet support openssl 3.0, so it is FTBFS. There is work being upstream on this, so I just created https://pad.lv/1981456 (with relevant upstream links), and tagged it update-excuse. ### ruby-html-proofer Did not spend too long looking at this one. I get different (and disjoint) sets of failures in my local sbuild and on launchpad builders. ### ocrad autopkgtest regressions (https://pad.lv/1981846) The autopkgtest failures are due to undefined references to symbols in libpng. This package's autopkgtest is a bit odd because it compiles a new binary called ocradcheck, and uses that to perform the tests. I tried to quick-fix the build in the autopkgtest, but predictably I hit other issues. I wasn't able to push this one over the line, but it seems like the best course would be for this package to have an additional binary package (ocrad-test or ocradcheck) to be used in autopkgtest (I suggested this on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004508). ### probabel FTBFS I think this is a candidate for removal. The Debian maintainer has also indicated this (https://lists.debian.org/debian-med/2022/02/msg00093.html), which is noted in the package's debian/Readme.Debian. $ reverse-depends src:probabel -r kinetic Reverse-Recommends * med-bio (for probabel) * med-cloud (for probabel) Packages without architectures listed are reverse-dependencies in: amd64, arm64, armhf, i386, ppc64el, s390x $ reverse-depends src:probabel -r kinetic -a source No reverse dependencies found Thanks to William for reviewing and sponsoring several things. -Nick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance day report
Note: search the message for "HANDOVER" for what I believe is a bitesize
task that will unblock a migration (I didn't get to it in time).
--
I spent some time trying to figure out why autopkgtests for src:pyside2
take between 2 and 3 hours in Ubuntu and about 25 minutes in Debian, see:
- https://autopkgtest.ubuntu.com/packages/pyside2/kinetic/amd64
- https://ci.debian.net/packages/p/pyside2/unstable/amd64/
but I didn't get to a definitive conclusion. The only thing I can say
is that I don't think there's a single step slowing down the test run,
but it's overall slower. The test has a lot of dpkg operations, and
hence a lot of filesystem sync operations. Perhaps the Debian infra
is making more/better use of eatmydata-like tricks.
Coming to migration excuses, I worked on:
perl:
- holding 18 other packages
- causes two regressions:
- cluster-glue/1.0.12-20ubuntu/ppc64el
Retriggered and it passed, see:
https://autopkgtest.ubuntu.com/packages/cluster-glue/kinetic/ppc64el
- adduser/3.121ubuntu1/i386
This one requires a hint (thanks bdmurray and vorlon for the pointers):
https://code.launchpad.net/~paride/britney/+git/hints-ubuntu/+merge/427039
- hint merged (thanks vorlon)
- perl should be able to migrate now.
ssreflect:
- holding 7 other packages
- mini transition (src:coquelicot needs to be rebuilt)
- A new src:coquelicot upload is already in -proposed, but the arm64
build was unlucky and built against the old version of ssreflect.
- Did a no-change rebuild upload of src:coquelicot
- The autopkgtest now pass:
https://autopkgtest.ubuntu.com/packages/coquelicot/kinetic/arm64
- I expect the package to now be a candiate.
webkit2gtk:
- holding 4 packages
- Causes test regression on src:surf on armhf.
It was already retriggered by jbicha. I tried again and it failed.
- I triggered a surf autopkgtest run without -proposed triggers
(trigger=surf/2.1+git20220504-1). It failed, so the failure has
actually nothing to do with webkit2gtk.
- Passes in Debian:
https://ci.debian.net/data/autopkgtest/unstable/i386/s/surf/23618675/log.gz
- I didn't get to the bottom of this.
rakudo:
- holding 3 packages, 50 days old
- mini transition, did no-change rebuild uploads of:
- perl6-readline
- raku-tap-harness
- retriggered builds of (previously FTBFS on all archs):
- raku-getopt-long (succeeding, s390x not built yet while writing)
- we'll see if there's anything else blocking with the next britney run.
mathcomp-multinomials:
- holding 3 packages
- missing builds on all archs but riscv64
- reason: missing b-deps (riscv64 got lucky because it slow)
- retriggered builds; built everywhere but on arm64.
- reason for missing arm64 build:
.
The following packages have unmet dependencies:
libcoq-mathcomp-bigenough : Depends: libcoq-mathcomp-ssreflect-94ef7
E: Unable to correct problems, you have held broken packages.
.
- HANDOVER: I think we just need a no-change rebuild of
src:mathcomp-bigenough to rebuild against a newer ssreflect.
fonttools:
- holding 3 packages
- causes regression in glyphslib/5.3.2+ds1-1
- the failure also happens in Debian:
https://ci.debian.net/packages/g/glyphslib/unstable/amd64/
- Debian (release critical) bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013363
- filed update-excuse bug linking to the Debian bug:
https://bugs.launchpad.net/debian/+source/fonttools/+bug/1981989
qiime:
- holding 2 packages
- direct autopkgregression on armhf, with error:
AssertionError: dtype('int64') !=
- I wasn't expecting this to ever pass on armhf and did a
migration-reference/0 retrigger, but it actually passed!
- I expect the package to now be a candiate.
- cool that we have a tool for microbiome analysis :)
neovim:
- missing build: s390x
- retrigged build and it worked
- I expect the package to now be a candiate.
Cheers,
Paride
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: VT console font
Hi, On Mon, 18 Jul 2022 at 13:36, Daniel van Vugt wrote: > > I find myself increasing the VT console font size on practically all modern > machines: > >sudo dpkg-reconfigure console-setup > > Is it perhaps time that Kinetic defaulted to a larger console font? > Is this upgraded machine, or fresh install? i think when we enabled auto-detected high-dpi console fonts, we couldn't really do an upgrade case as it was not possible to check/know if configuration was default or manual. Or do you want font even bigger, than what we boot into by default? You can check stock behaviour by booting live usb stick and checking how vt console font looks there for you. -- okurrr, Dimitri -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: VT console font
On Mon, Jul 18, 2022 at 2:57 PM Heinrich Schuchardt wrote: > > Thanks Daniel for bringing up this topic. > > We should choose a font that is easily legible on a 28" 4K monitor. Honestly this feels like one of those "you help one and at the same time make it worse for others" cases. Could we instead of changing the default make this dynamic based on the HW properties detected on install or any such? IIRC the Desktop team has some data [1] on HW specs present on install which could help to make such a decision. [1]: https://www.omgubuntu.co.uk/2018/02/ubuntu-data-collection-opt-out > Best regards > > Heinrich > > On Mon, Jul 18, 2022 at 2:36 PM Daniel van Vugt > wrote: >> >> I find myself increasing the VT console font size on practically all modern >> machines: >> >>sudo dpkg-reconfigure console-setup >> >> Is it perhaps time that Kinetic defaulted to a larger console font? >> >> - Daniel >> >> -- >> 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 -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: VT console font
Thanks Daniel for bringing up this topic. We should choose a font that is easily legible on a 28" 4K monitor. Best regards Heinrich On Mon, Jul 18, 2022 at 2:36 PM Daniel van Vugt < daniel.van.v...@canonical.com> wrote: > I find myself increasing the VT console font size on practically all > modern > machines: > >sudo dpkg-reconfigure console-setup > > Is it perhaps time that Kinetic defaulted to a larger console font? > > - Daniel > > -- > 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
VT console font
I find myself increasing the VT console font size on practically all modern machines: sudo dpkg-reconfigure console-setup Is it perhaps time that Kinetic defaulted to a larger console font? - Daniel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
