Re: New coreutils release 8.32
Hi, On Sat, 18 Jul 2020 at 19:09, Nicholas Guriev wrote: > > Dear Ubuntu developers, > > GNU coreutils 8.32 have been released on March 6th, 2020, yet the > package is not updated in groovy. The new version has enhanced support > of file creation time in stat(1) and introduced the "--time=birth" sort > rule for ls(1). It would be great to have these features in the coming > Ubuntu release. Please take a look at my merge request LP#1888046. > > https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1888046 > > Debian revision of the package has not migrated to testing yet due to > build failure on ARM64. Is there a chance to get the update for AMD64 at > least? > > https://buildd.debian.org/status/fetch.php?pkg=coreutils&arch=arm64&ver=8.32-2&stamp=1592917386&raw=0 > There are patches applied to coreutils to Ubuntu, thus it will need a merge. Separate architectures are not updated separately. Packages must match across architectures, and not regress in the support. Ubuntu supports 7 architectures, and coreutils must be build on them all. The issue might be related to the kernel headers shipped vs expected, and the problem may or may not reproduce on Ubuntu, as our kernels are different. It doesn't seem like a hard thing to fix on arm64. -- Regards, Dimitri. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance status − July 13-17
On Friday, July 17 2020, Rafael David Tinoco wrote: > This was my week and here is some of my notes about achievements and > highlights: I helped Rafael a little bit on Tuesday and Wednesday. Here's my brief report. > > Overall status: > -- > > - read all the maint+1 docs and @piloted in ubuntu-devel > > - qemu TCG memory issue causing spinned qemu instances to be killed > > casper has a qemu instance killed because of TCG (cdrom file cant be found) > > => lost some time here trying to reproduce, unfortunately lack of attention > as @paelzer had already warned me about, but I did not link cause and > effect for this case. I investigated casper one with Rafael on Wednesday, but he continued the investigation (and eventually talked to @paelzer and found what was happening) on Thursday. > > Detailed information of what I remembered to take notes of: > -- [...] > Excuses [universe]: dropbear (helping sergiodj in ramping up maint+1) > > 4 hands with sergiodj for maint+1 and core-dev skills ramp up. > > (he will send his notes) This was an interesting case. dropbear version 2020.79-1 failed at a certain point in the past, and this failure blocked libtommath from migrating (it's worth mentioning that libtommath had *also* failed, so it was blocking itself). Then, a new upload of dropbear was made (version 2020.80-1), and this version did pass. However, libtommath was still listed as blocked due to dropbear 2020.79-1. Rafael and I tried to understand what was happening, and why libtommath's tests were not retriggered when the new dropbear version was uploaded. Long story short, after talking to Lucas Kanashiro we learned that these retries have to be submitted by hand. So that's Rafael did. - rsync I investigated the failure, submitted a bug & an MP to fix it: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1887572 https://code.launchpad.net/~sergiodj/ubuntu/+source/rsync/+git/rsync/+merge/387393 The new version has been uploaded and the package has migrated. - libtommath I also spent some time investigating this one. It was failing with "badpkg" on i386, and I noticed that it had a hint (force-badtest) for another version of the package, so I thought it made sense to expand this hint and just ignore all versions of libtommath on i386. I filed an MP for this, but vorlon did not accept it & kindly fixed the package instead (it was actually a problem with cross dependencies & cross GCC). Thanks, -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New coreutils release 8.32
Dear Ubuntu developers, GNU coreutils 8.32 have been released on March 6th, 2020, yet the package is not updated in groovy. The new version has enhanced support of file creation time in stat(1) and introduced the "--time=birth" sort rule for ls(1). It would be great to have these features in the coming Ubuntu release. Please take a look at my merge request LP#1888046. https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1888046 Debian revision of the package has not migrated to testing yet due to build failure on ARM64. Is there a chance to get the update for AMD64 at least? https://buildd.debian.org/status/fetch.php?pkg=coreutils&arch=arm64&ver=8.32-2&stamp=1592917386&raw=0 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
Ubuntu +1 Maintenance Report (July 16 -17)
Hi Everyone, I've asked for the removal of libselinux 3.1-1 from groovy-proposed because .symbols' symbol version were broken and broke packages built with it. Luckily the only reverse dependency affected was systemd which I rebuilt. libselinux also breaks glibc's autopkgtest which I plan fixing outside of +1 maintenance, next week: LP: #1887919 I've rebased https://code.launchpad.net/~rbalint/ubuntu-archive-tools/retry-intermittent/+merge/384468 hoping that eventually it will be merged. I used the pending changes in my shift again to re-trigger a fair amount of tests. I've NMU-d hyperkitty and postorius via Debian and that will hopefully unblock the migration of glewlwyd. The new proposed-migration page [0] helps a lot in triaging installability issues, thanks Laney for rebasing Britney! Mysql-8.0 regressed in the release pocket, thus I've filed LP: #1887979 and a hint. BTW the hints I've filed in my previous +1 maintenance shift were not merged for 10 days, just now, after explicitly adding reviewing users despite that I've pinged ubuntu-release on 2020-07-06. I'd like to suggest that every active team in Ubuntu should adopt a monitoring process to handle reviews without users set explicitly and ensuring timely reply to merge requests. I started going through the rust-* packages and introduced rust-jobserver to get rust-*git* migrated. The rust-jobserver was removed from the archive but I could not find any trace of why, since there was no removal bug. This is an example of the systematic issue we are having in Ubuntu. There are packages without Ubuntu-specific delta which are stuck to a version lower than in Debian because or completely missing from Ubuntu no new Debian upload triggered the sync since the package was removed. Sometimes the absence of the package or the lower version does match the intention because the package was not ready for release or should not be part of Ubuntu, but in rust-jobserver's case it looks like the package was just lost. Most likely if the package entered testing in Debian it is in good enough shape to be released in Ubuntu so I've came up with the following UDD query: SELECT sources.source, ubuntu_groovy.max_version AS ubuntu_version, sources.version FROM sources LEFT JOIN (SELECT source, MAX(version) as max_version FROM ubuntu_sources WHERE release LIKE 'groovy%' GROUP BY source) as ubuntu_groovy ON sources.source = ubuntu_groovy.source WHERE sources.release='bullseye' AND ( (ubuntu_groovy.max_version < sources.version AND ubuntu_groovy.max_version NOT LIKE '%ubuntu%') OR ubuntu_groovy.max_version is NULL) AND NOT sources.section = 'debian-installer' GROUP by sources.source, sources.version, ubuntu_groovy.max_version ORDER BY sources.source; There are a few rough edges like versions are compared as strings and debian-installer components should be filtered better, but the results [1] is worth checking. This would probably be better as an archive report automatically linking to removal bug reports and I may start working on that after my previous merge request gets merged [2]. Did I mention stale merge requests? ;-) Cheers, Balint [0] https://lists.ubuntu.com/archives/ubuntu-devel/2020-July/041078.html [1] https://paste.ubuntu.com/p/pnwp2v2vVv/ [2] https://code.launchpad.net/~rbalint/ubuntu-archive-scripts/bzr-by-team-report/+merge/359222 -- Balint Reczey Ubuntu & Debian Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
