+1 maintenance report
Tooling: I don't know what others do already, but for bulk no-change rebuild uploads I left behind some of my usual one liners and put together a couple of quick tools: prep-rebuild: given a list of source packages, automate fetching, bumping the changelog and preparing the upload. This leaves a pile of changes files in the current directory ready to debsign and dput. lp_build_status.py: some people might have already attempted no change rebuilds, so if I look at the current state of things to get a list of packages that look like they need a no change rebuild, I might be duplicating effort and wasting build resources. This tool takes a list of source packages, examines Launchpad, and lists any packages whose highest versions are currently not built on amd64 for whatever reason (eg. in the queue, build in progress, failed to build). This allows me to remove these from my list of no-change rebuild uploads and investigate these manually. Get these from: https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak My running notes are below. It's getting late so I'm not going to polish them up right now. If you need any more detail on anything, please ask. boost No change rebuilds uploaded: ball freecad lgogdownloader supercollider FTBFS: frogatto (fixed and uploaded) slic3r-prusa (I didn't get to this but I see Graham has) dep8 failures: icinga2 - needs a hint? Further discussion at https://lists.ubuntu.com/archives/ubuntu-devel/2022-May/042051.html libreoffice - since fixed in https://cgit.freedesktop.org/libreoffice/core/commit/sw/qa/uitest/writer_tests7/tdf144439.py?id=a31a7b53c42eef3a8007766c60ec5a2539054a7c and already uploaded and migrated so just needed retests hilive - looks flaky but previous migration-reference reset attempts failed (ie. the test passed) so tried just a retry. This failed, so tried a migration-reference/0 pytest beets arm64: seems to need net access. Not sure how it passed previously. Looked at s390x which already always fails for the same reason (plus one other). Submitted retry with trigger=migration-reference/0, but then jbicha kindly reminded me about Internet-requiring tests so I also just retried einsteinpy arm64: looks like maybe the OOM killer. One spurious past in far history (Jammy). Submitted retry with trigger=migration-reference/0 These packages also needed resubmitting because they require Internet access: fiat arm64 pandas arm64 pytest-doctestplus arm64 pytest-mpi arm64 python-cooler python-css-parser python-mechanicalsoup rdflib repo snakemake sphinx-astropy sphinx-automodapi python-parameterized i386: build depends on python3-nose which depends on python3-coverage which is not available on i386. Not sure why it worked previously in Hirsute, but don't think it will now, so submitted a migration-reference/0. libzstd ccache: armhf retest already pending debspawn arm64 needed a retry due to needing Internet access golang-github-valyala-gozstd looks like a genuine failure against the newer libzstd. I think this needs further investigation octave octave 6.4.0-2 Provides octave-abi-56 in the release pocket octave 7.1.0-2 Provides octave-abi-57 in the proposed pocket Submitted no change uploads Added transition tracker for octave after getting some FTBFSs back and realising it needs multiple levels 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. 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: [ubuntu/kinetic-proposed] bluez 5.64-0ubuntu2 (Accepted)
Hey Brian, I noticed that upload and I'm curious about the motivation. It's really early in the cycle and we will get bluez updates and time for archive rebuilds later on so I guess the aim is not to get packages built with a new LTO by release time. Did we have a buggy LTO version in the archive and are we rebuilding things with a fixed version? Which packages do need a rebuild and do we need to organize the rebuilds with the owning teams? Cheers, Sebastien Bacher Le 13/05/2022 à 21:56, Brian Murray a écrit : bluez (5.64-0ubuntu2) kinetic; urgency=medium * No change rebuild to pickup a new version of LTO. Date: Fri, 13 May 2022 12:36:19 -0700 Changed-By: Brian Murray Maintainer: Ubuntu Bluetooth team https://launchpad.net/ubuntu/+source/bluez/5.64-0ubuntu2 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: autopkgtest missed regression for kinetic
On Fri, May 13, 2022 at 12:06:46PM -0400, Jeremy Bicha wrote: > Hi, > > I am concerned that the excuses page is ignoring that webkit2gtk > 2.36.1-1 caused an autopkgtest regression for devhelp. > > https://autopkgtest.ubuntu.com/packages/d/devhelp/kinetic/amd64 > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html > > The regression was correctly caught in Debian: > https://tracker.debian.org/pkg/webkit2gtk > > I am concerned because I would expect other packages could have > introduced regressions but been allowed in to Kinetic. It seems the state of the 2 autopkgtest-web workers is inconsistent, not all results were copied up on all instances. I noticed that it retried a migration-reference/0 test after the failure which indicated it did not allow the failure, but a later run might have hit the different backend and hence might have a different view. So it's unclear if that's the reason, but bdmurray is cleaning that up right now. -- 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
autopkgtest missed regression for kinetic
Hi, I am concerned that the excuses page is ignoring that webkit2gtk 2.36.1-1 caused an autopkgtest regression for devhelp. https://autopkgtest.ubuntu.com/packages/d/devhelp/kinetic/amd64 https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html The regression was correctly caught in Debian: https://tracker.debian.org/pkg/webkit2gtk I am concerned because I would expect other packages could have introduced regressions but been allowed in to Kinetic. 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: Question to flavors: touch-base on flavor participation for 22.10!
Xubuntu will be participating in the 22.10 cycle. Thanks for checking in! On Wed, May 11, 2022 at 4:56 PM Dani Llewellyn wrote: > I'm not certain, but I believe Martin's address is > flexiondot...@ubuntu.com > > Dani. > > On Wed, 11 May 2022 at 11:09, David Mohammed > wrote: > >> Graham, >> >> as an aside I did a reply to all and got the following >> >> "The response from the remote server was: >> >> 550 5.1.1 : Recipient address rejected: >> User unknown in relay recipient table " >> >> I'm not sure of Martin's current email address >> >> David >> >> On Wed, 11 May 2022 at 10:52, David Mohammed >> wrote: >> > >> > Hi Graham, >> > >> > the Ubuntu Budgie team are looking forward to participating in the >> > 22.10 release - team-members are already working on 22.10 plans & >> > activities >> > >> > thx >> > >> > David (Project Lead Ubuntu Budgie) >> > >> > On Wed, 11 May 2022 at 10:40, Graham Inggs wrote: >> > > >> > > Hello flavors! >> > > >> > > As we do around the start of every new cycle, I am reaching out to all >> > > the current official Ubuntu flavors to confirm active participation in >> > > the upcoming Ubuntu release - 22.10. >> > > >> > > Working towards a release requires a lot of effort, so we'd like to >> > > make sure all the flavors are ready, properly staffed and have enough >> > > time allocated to make 22.10 happen for their users. This is why, >> > > similarly to last year, I will need a confirmation follow-up message >> > > about kinetic participation from every flavor, that is: >> > > >> > > * Kubuntu >> > > * Xubuntu >> > > * Ubuntu Studio >> > > * Lubuntu >> > > * Ubuntu Kylin >> > > * Ubuntu MATE >> > > * Ubuntu Budgie >> > > >> > > If you have any concerns regarding your participation, feel free to >> > > reach out to me or anyone else from the ubuntu-release team. >> > > >> > > Thank you! >> > > >> > > Graham >> > > >> > > -- >> > > 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 >> > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Error Tracker data retention
Hey Brian, Le 12/05/2022 à 22:38, Brian Murray a écrit : Keeping in mind that a crash bucket would still indicate that old release and package version were affected are there any objections to this change in data retention? Would that include the details of the 'number of report by version on the series' table? If so deleting the individual reports should be ok. Speaking of that table, could be consider removing older series from the table, or maybe reverse the table older and put the newest serie in the first column? Currently it starts on precise, which means on a standard lowdpi resolution you need to scroll to the right to see the information about the maintained series which is suboptimal. Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Legality of using free VMware Workstation Player for alpha and beta testing of Ubuntu?
I am digging deep into the world of Ubuntu development and am trying to make sure my alpha and beta testing is as effective as possible. I also don't want to cash out an arm and a leg for expensive software to do so. I've been using virt-manager (QEMU/KVM) for testing on virtual machines, and while things seem to be going well, I'd like to test on other hypervisors too for the sake of catching as many bugs as possible. VMware provides their Workstation Player product for free, *for non-commercial use.* Problem is, I can't figure out if using VMware for Ubuntu testing would be considered commercial use. One one hand, I'm not a Canonical employee, nor am I using VMware for employment purposes, so that would be non-commercial, but on the other hand, I'm helping a large enterprise build an OS that is used for commercial purposes, so that seems like commercial use. Do any of y'all do QA testing in the free version of VMware Workstation Player? Does anyone know if this is a legal use of VMware? Thank you for your help and time. (Note: I *think* these kinds of questions are what this mailing list is for, but if I'm misguided and should have sent this to ubuntu-devel-discuss, please let me know and I'll direct these kinds of questions there instead.) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
