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
+1 maintenance report
I've been also half-occupied with meetings this week as part of an internal Canonical event but I've managed to look at proposed migration for some of the time at least. On Wednesday I chose to do my SRU shift instead as I assume this is preferable. # apport This looked like it was holding up quite a few migrations so I took a look. Looks like it assumes a dpkg-divert exists but dash no longer has one causing an autopkgtest failure. Additionally it FTBFS because of a change in pylint. I discussed these with bdrung in #ubuntu-devel as I didn't want to step on toes about choices like using (or not using) pylint. I wrote the status up in LP: #2028881 and LP: #2028879. Following discussion and bdrung's suggestions we have a plan and he will upload (follow from the bugs for details). # pandas Newly built six hours ago, autopkgtests not complete yet. Later: pandas armhf failed and I retriggered. Maybe a spurious network error? But I've seen the same error in a few other test failures now, so maybe needs further investigation. Waiting on pandas armhf autopkgtest. # ocaml-ssl ocaml-cohttp already rebuilt but dep-wait on ppc64el. Looks resolved by a rebuild of js-of-ocaml so retried the build. Later: looks like this worked and excuses is out of date. There's a bunch of about 60 packages held up on mathcomp-analysis but the only excuse I see is a missing risc64 build that is now present. # coq-unimath missing build on risc64 but still building (up to 12 hours) from rebuild already submitted. # 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. # pytest This seems to be holding up quite a few packages. python-pytest-flake8 not reproducible on amd64, but looks suspiciously to do with Build-Depends change in pytest 7.4.0-2. Tried retrigger on python-pytest-flake8 on armhf to see if the problem still remains. Later: this succeeded So it seems that failures of this pattern are now resolved. I tried: retry-autopkgtest-regressions -s mantic --blocks pytest --log-regex "module 'py' has no attribute" However this fails with "You submitted an invalid request: Expecting value: line 1 column 1 (char 0)" and also even when using the retry button directly on the xcuses page. Is there an outage or regression somewhere on autopkgtests.u.c? I asked on #ubuntu-devel. 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
Upcoming glibc 2.38 transition
Hi folks, The new version of glibc is about to be released upstream in a few days, and the upload to mantic-proposed shall follow shortly thereafter, my current target being Friday, Aug 4st. As usual, this will result in a massive number of autopkgtests being triggered into the huge queues, so while this shouldn't delay most of the other triggers, the runners will be heavily loaded, resulting in some resource-related test failures. If your package happens to pick up one of the new symbols from the new version, it'll have to wait for glibc to migrate. I'll be working towards making that happen as quickly as possible, but if you want to lend a hand, come talk to me (schopin on IRC). We were planning to do an archive rebuild with a snapshot, but for various reasons this hasn't happened before I had a chance to write this email. However, you can already test your packages against a fresh snapshot using this PPA: https://launchpad.net/~schopin/+archive/ubuntu/glibc-2.38-snapshot What's new? --- On the packaging side, the biggest piece of news is that we finaly managed to merge back with Debian, after a multi-year divergence. I didn't see anything particularly alarming in the Debian changes that we picked up. Of particular import to us in the upstream changelog (that I'll copy below) is the addition of the --enable-fortify-source flag, which in effect is equivalent to `-D_FORTIFY_SOURCE=2` that we already enable for the rest of the distribution. We've opted to enable it. As usual with this sort of flags, it might trip some code that was silently buggy, resulting in FTBFS. You can find a human-readable changelog for the 2.38 release there: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;hb=HEAD Cheers, -- Simon Chopin Foundations TeamUbuntu MOTU/Core Dev simon.cho...@canonical.comscho...@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: Amendment: Update on reducing initramfs size and speed up
On Thu, Jul 27, 2023, Adrien Nader wrote: > On Thu, Jul 27, 2023, Michael Hudson-Doyle wrote: > > On Thu, 27 Jul 2023 at 09:21, Benjamin Drung wrote: > > > > > On Wed, 2023-07-26 at 17:53 +0200, Benjamin Drung wrote: > > > > Hi all, > > > > > > > > A few weeks ago, I posted an idea how to reduce the initramfs size and > > > > speed up the generation: > > > > > > > > https://lists.ubuntu.com/archives/ubuntu-devel/2023-July/042652.html > > > > > > > > This post sparked a lively discussion. The initial idea was ditched for > > > > a better solution: mkinitramfs will put all compressed files (kernel > > > > modules and firmware files) into a cpio archive that is not compressed > > > > (because compressing compressed files makes no sense). All other files > > > > will be added to a cpio archive that gets compressed. As next steps, the > > > > kernel modules and firmware files need to be shipped compressed. > > > > > > > > After several iterations for the implementation and review by Daves > > > > Jones, I just uploaded initramfs-tools 0.142ubuntu8 to mantic that puts > > > > compressed kernel modules and firmware files in an uncompressed cpio > > > > (https://launchpad.net/bugs/2028567). > > > > > > > > I created/updated the follow-up tickets and added my patches to them: > > > > > > > > Ship kernel modules Zstd compressed > > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028568 > > > > > > > > compress firmware in /lib/firmware > > > > https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1942260 > > > > > > > > And without further ado, here come the benchmark results: > > > > > > > > The benchmarks were done either on an AMD Ryzen 7 5700G with schroot and > > > > overlay on tmpfs or on the hardware mentioned. All tests were running > > > > the latest Ubuntu mantic development release. > > > > > > > > * minimal: schroot with linux-image-generic initramfs-tools zstd > > > > * full: minimal + busybox-initramfs cryptsetup-initramfs > > > > isc-dhcp-client kbd lvm2 mdadm ntfs-3g plymouth plymouth-theme-spinner > > > > * nvidia: full + linux-headers-generic nvidia-driver-525 > > > > * nvidia fw: nvidia + compressed /lib/firmware/nvidia/525.125.06/ > > > > * VisionFive 2: VisionFive 2 RISC-V board > > > > * RPi Zero 2: Raspberry Pi Zero 2 ARM board (running armhf) > > > > > > > > "next" means using kernel/firmware/initramfs from ppa:bdrung/ppa i.e. > > > > * initramfs-tools 0.142ubuntu7bd4 > > > > * linux 6.3.0-7.7bd2 > > > > * linux-firmware 20230629.gitee91452d-0ubuntu1bd1 > > > > > > > > > || build | size | uncompressed size | > > > > > | test | time| in bytes | in MiB | in bytes | in MiB | > > > > > ||-|---||| > > > > > | minimal| 4.30 s | 66701818 | 63.6 | 224087608 | 213.7 | > > > > > | minimal next | 4.54 s | 59935186 | 57.2 | 67738810 | 64.6 | > > > > > | full | 7.15 s | 118007038 | 112.5 | 387976843 | 370.0 | > > > > > | full next | 7.29 s | 106937908 | 102.0 | 128610985 | 122.7 | > > > > > | nvidia | 7.04 s | 209200523 | 199.5 | 513554279 | 489.8 | > > > > > | nvidia next| 7.21 s | 195246287 | 186.2 | 235288174 | 224.4 | > > > > > | nvidia fw next | 7.16 s | 191329102 | 182.5 | 213078234 | 203.2 | > > > > > | VisionFive 2 | 142.9 s | 121895035 | 116.2 | 411160836 | 392.1 | > > > > > | VF 2 next | 126.7 s | 111651453 | 106.5 | 134120804 | 127.9 | > > > > > | RPi Zero 2 | 109.5 s | 39803044 | 40.0 | 69592789 | 66.4 | > > > > > | RPi Zero 2 ² | 103.5 s | 39804499 | 40.0 | 69592789 | 66.4 | > > > > > | RPi Zero 2 next| 101.2 s | 31463352 | 30.0 | 41145762 | 39.2 | > > > > > > > > ² Updated initramfs-tools (but no compressed modules or firmware) > > > > > > > > The build time was averaged over five runs. > > > > > > > > > | improvement | build time | size | uncompressed size | > > > > > |--|||---| > > > > > | minimal | 105.6 % | 89.9 % | 30.2 % | > > > > > | full | 102.0 % | 90.6 % | 33.1 % | > > > > > | nvidia | 101.7 % | 91.5 % | 41.5 % | > > > > > | VisionFive 2 | 88.7 % | 91.6 % | 32.6 % | > > > > > | RPi Zero 2 | 92.4 % | 79.0 % | 59.1 % | > > > > > > > > Building the initramfs takes more CPU cycles (see tests on tmpfs), but > > > > saves time on disk IO. Daves Jones saw much bigger time savings on his > > > > Raspberry Pis but his tests were on lunar. > > > > > > > > Build time influence: > > > > + add_directories plus uniq take several milliseconds > > > > + depmod on compressed kernel modules take hundreds of > > > > milliseconds longer > > > > - copying smaller kernel modules (due to compression) is faster > > > > - cpio archive that needs to be compressed is smaller > > > > - not storing intermediate cpio archives saves time > > >
Re: Duplicate Requests in autopkgtest-cloud
Hi Steve, This is something I missed in the initial implementation, but there's now an MP for a fix ready to go into master. Right now, however, I've hotfixed prod so that if you pass `all-proposed`, the duplicate request check is disabled. I made this quick change to unblock ginggs Regards, Tim On Fri, Jul 28, 2023 at 5:19 AM Steve Langasek wrote: > Hi Tim, > > On Thu, Jul 27, 2023 at 11:10:05AM +0100, Tim Andersson wrote: > > Hi all, > > > In the Ubuntu QA team we recently made and deployed a change which now > > makes it impossible to queue duplicate requests. > > > If a request is currently in the queue, or is currently running, and you > > request the same test, you will be taken to an error page which tells you > > the test details and whether it is currently queued or currently running. > > It looks like this: > > ``` > > > > You submitted an invalid request: > > > > Test already queued: > > > > release: lunar > > > > pkg: gzip > > > > arch: arm64 > > > > triggers: gzip/1.12-1ubuntu1 > > > > ``` > > This is to try and ease the load on autopkgtest-cloud. > > > If you experience any bugs or unexpected functionality, please file a bug > > against `autopkgtest-cloud` and let us know. We expect it to work > > seamlessly but always expect the unexpected right :) > > Does the code also properly distinguish between tests queued with > proposed=1 > and those without, so that it's possible to queue both ways in parallel? > > 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 > -- > 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: Call for testing: grub 2.12 mantic PPA
On Thu, Jul 27, 2023 at 06:50:34PM +0200, Julian Andres Klode wrote: > Hello party people, > > grub 2.12~rc1-4~ubuntu1~ppa1 is now available in the Ubuntu > development PPA for testing, signed with the PPA signing > key. > > https://launchpad.net/~ubuntu-uefi-team/+archive/ubuntu/ppa/+packages > > I have tested booting on my laptop and it's fine, but I've > specifically not gotten around to any arm64 or riscv64 testing > or PC BIOS for that matter. Well I booted a kernel in arm64 > qemu. Addendum: Please run grub-install manually after the upgrade. A refactoring of the postinst moved a variable access too far up before it was defined so it tried to check for the wrong thing to see if it should install. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
