Noble Numbat Beta milestone delayed (xz/liblzma security update)
Hello everyone, Canonical never stops working to keep Ubuntu at the forefront of safety, security, and reliability. As a result of CVE-2024-3094, Canonical made the decision to remove and rebuild all binary packages that had been built for Noble Numbat after the CVE-2024-3094 code was committed to xz-utils (February 26th), on newly provisioned build environments. This provides us with confidence that no binary in our builds could have been affected by this emerging threat. As a result of this, the Beta release for Ubuntu 24.04 LTS (Noble Numbat) has been pushed to April 11, 2024 (previously April 4, 2024). We appreciate your understanding and thank the community members who are collaborating on our collective understanding of this emerging issue. On behalf of the Ubuntu Release team, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Call for testing: first set of 22.04.4 images ready!
Hello everyone! On Friday last week we built our first batch of test .4 images! As always, those can be found on the respective isotracker milestone here: https://iso.qa.ubuntu.com/qatracker/milestones/451/builds There are still some images that we need to get building, but those are RISC-V related. All others should be more-or-less release-candidate worthy (we hope). Please pick up your favorite flavor and start testing! Progress of the whole milestone can be tracked on the tracking post here: https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-4-lts-point-release-status-tracking/42115 Thank you! Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
22.04.4 pre-release SRU -updates and -security freeze - heads up
Hello developers and SRU members, As we're nearing the 22.04.4 preparation date, we're entering a sort-of soft freeze for the -updates and -security pockets. We need to keep things stable during the period of release candidate image creation. SRU members and security: please refrain from releasing any updates into jammy-updates and jammy-security until release (February 22nd), at least without coordination with the release team. I have now committed the sru-freeze hint so that at least the SRU team tooling will warn about the pockets being frozen for releases. Developers: there might be still some updates landing into jammy-updates, but in general the velocity will be slower. Thank you! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [ubuntu-studio-devel] Ubuntu Studio LTS Re-Qualification
Hello Ubuntu Studio! At today's Technical Board meeting we have voted for the LTS status of Ubuntu Studio for 24.04, and the vote has passed! So now it's all official! Congrats! Cheers, -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Ubuntu Studio LTS Re-Qualification
Hey Erich! This sounds very much like what I needed, thank you. I don't consider this as a requirement, but do you think it would be possible to get this support plan written down somewhere on a webpage or some Studio-related wiki-page, so that it's easily accessible? That would make it easier for users to know what kind of support to expect. For contact/bug-filling information, I think the information present right now is sufficient. I think this is everything. This makes me feel confident that the Ubuntu Studio team will be able to provide the necessary support for the flavour for the length of the proposed LTS term (3 years) so I could sign it off form the Technical Board POV. Thanks! On Fri, 24 Nov 2023 at 21:57, Erich Eickmeyer wrote: > > Hi Lukasz, > > I'm going to use Xubuntu's one-paragraph example for this as it seems > reasonable and was approved by Steve, which sets a precedent. > > Our support plan is limited to the Ubuntu Studio package set which is > generally updates and bugfixes to the multimedia packages we include, as > well as our own developed utilities (Ubuntu Studio Installer, Ubuntu > Studio Audio Configuration, etc.). We also assist Kubuntu with bugfixes > from time to time for the desktop environment and KDE application > packages as needed. Most packages come from Debian. We also backport > many packages to the backports repository for inclusion there. > > I hope this is closer to what you're looking for and we can finally > settle this. > > Erich > > On 11/23/23 09:53, Lukasz Zemczak wrote: > > Hello Erich! > > > > I will be handling your LTS re-qualification from the TB side for Ubuntu > > Studio. > > > > Thank you for providing information about your team and contacts, as > > well as regarding the length of the LTS support. I think we almost > > have everything to make a decision here. Per the requirements listed > > here [1], the only thing missing from the 'support plan' POV would be > > setting the expectations regarding the level of support Ubuntu Studio > > would provide for the 3 years. Could we have like a wiki page or a > > page on ubuntustudio outlining this? And mentioning the support > > contacts and where to file bugs. > > > > Thanks! > > > > Cheers, > > > > On Mon, 13 Nov 2023 at 17:16, Erich Eickmeyer wrote: > >> Good morning Technical Board, > >> > >> On behalf of Ubuntu Studio, we'd like to re-qualifiy for LTS for 3 years > >> for 24.04. Our team is https://launchpad.net/~ubuntustudio-dev and I am > >> the primary contact with rosco2 as backup. > >> > >> Thanks, > >> Erich > >> -- > >> Erich Eickmeyer > >> Project Leader - Ubuntu Studio > >> Technical Lead - Edubuntu > >> -- > >> technical-board mailing list > >> technical-bo...@lists.ubuntu.com > >> https://lists.ubuntu.com/mailman/listinfo/technical-board > > On behalf of the Technical Board, > > > -- > Erich Eickmeyer > Project Leader - Ubuntu Studio > Technical Lead - Edubuntu > -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [ubuntu-studio-devel] Ubuntu Studio LTS Re-Qualification
Hello Erich! I will be handling your LTS re-qualification from the TB side for Ubuntu Studio. Thank you for providing information about your team and contacts, as well as regarding the length of the LTS support. I think we almost have everything to make a decision here. Per the requirements listed here [1], the only thing missing from the 'support plan' POV would be setting the expectations regarding the level of support Ubuntu Studio would provide for the 3 years. Could we have like a wiki page or a page on ubuntustudio outlining this? And mentioning the support contacts and where to file bugs. Thanks! Cheers, On Mon, 13 Nov 2023 at 17:16, Erich Eickmeyer wrote: > > Good morning Technical Board, > > On behalf of Ubuntu Studio, we'd like to re-qualifiy for LTS for 3 years for > 24.04. Our team is https://launchpad.net/~ubuntustudio-dev and I am the > primary contact with rosco2 as backup. > > Thanks, > Erich > -- > Erich Eickmeyer > Project Leader - Ubuntu Studio > Technical Lead - Edubuntu > -- > technical-board mailing list > technical-bo...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/technical-board On behalf of the Technical Board, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Call for testing: 23.10 candidate images
Hello everyone, Most of you already know, but sending out an e-mail just in case. We're in the middle of the 23.10 release week right now, with an official set of release candidate images available here: http://iso.qa.ubuntu.com/qatracker/milestones/449/builds Please pick up your favorite flavor images and run through tests on the isotracker. The more testing we get, and the earlier we get it, the higher the chances we can still try doing something to fix those - or at least release note. Thank you for your cooperation! On behalf of the Ubuntu Release team, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Mantic Minotaur (to be 23.10) Beta Freeze
As of now, mantic has entered the Beta Freeze, with a goal of releasing Beta images sometime late Thursday. *From now until the Beta is released, please only upload updates for packages on any release images if you /need/ to get them into the Beta itself.* Please hold off with everything else until after we release on Thursday. The queue freeze will last from now until the final release next month, which means that all seeded packages will now need a spot-check and review in the queue from a release team member before they are let into the archive. As with the previous releases, we have a bot in place that will accept uploads that are unseeded and don't affect images. Don't take this as an open invitation to break Feature Freeze on those components, this is just to reduce the burden on the release team, so we only review the uploads that need very serious consideration. If you find the bot is blocking an upload that you think should have been auto-accepted, let us know and we'll sort it out. We will be spinning a set of Beta candidates in the next 12 hours or so. We then encourage people to start testing ASAP for their favourite flavour(s) as they come off the line. Happy bug-hunting from now until the final release, and please do help out and test images, etc, where you can and let us know what's broken in your environment(s). As a reminder, the Beta images will appear on the ISO Tracker here: http://iso.qa.ubuntu.com/qatracker/milestones/448/builds On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
22.04.3 preparation in progress! Soft freeze of jammy-updates/security
Hello everyone, This is a heads up that we are now working on 22.04.3, with a planned release next week on the 10th of August. As we will be preparing to build our first release candidates soon™, we will be entering a soft-freeze of the jammy-updates and jammy-security pockets. https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-3-lts-point-release-status-tracking/37439 SRU and security teams: please do not release any new updates for jammy until we're done with the release. In cases where the upload is important and needs to go in ASAP, please coordinate with Paride beforehand. Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: 23.04 candidate images
Hello everyone, Most of you already know, but sending out an e-mail just in case. We're in the middle of the 23.04 release week right now, with an official set of release candidate images available here: http://iso.qa.ubuntu.com/qatracker/milestones/445/builds Please pick up your favorite flavor images and run through tests on the isotracker. The more testing we get, and the earlier we get it, the higher the chances we can still try doing something to fix those - or at least release note. Thank you for your cooperation! On behalf of the Ubuntu Release team, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- 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: 20.04.6 images!
Hello everyone! We had to re-spin the image candidates yesterday, so there's a new set of images available on the tracker: http://iso.qa.ubuntu.com/qatracker/milestones/443/builds Since this is an extra not-explicitly-scheduled point-release, there's nothing preventing us from waiting with the release utill Monday. But if you have a moment, please do a spot check of the new images - there should be almost no delta, so not all tests need to be re-done. Thanks! On Wed, 15 Mar 2023 at 01:53, Lukasz Zemczak wrote: > > Hello everyone! > > As already mentioned, this week we're trying our best to get the > good-old 20.04 respun with the new shim. Just recently we were able to > get some release candidate images built: > > http://iso.qa.ubuntu.com/qatracker/milestones/443/builds > > Please note as this is an exceptional extra point-release, we were > only respinning what was needed: amd64 images. All other architectures > should not be affected and do not need to be rebuilt. > > If you have a moment, we'd appreciate some smoke-testing of these > images. As always, submit your test results to the tracker above when > you're done. > > Thank you! > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > Tools Squad Interim Engineering Manager > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: 20.04.6 images!
Hello everyone! As already mentioned, this week we're trying our best to get the good-old 20.04 respun with the new shim. Just recently we were able to get some release candidate images built: http://iso.qa.ubuntu.com/qatracker/milestones/443/builds Please note as this is an exceptional extra point-release, we were only respinning what was needed: amd64 images. All other architectures should not be affected and do not need to be rebuilt. If you have a moment, we'd appreciate some smoke-testing of these images. As always, submit your test results to the tracker above when you're done. Thank you! -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Soft freeze of 20.04 for the incoming auxiliary 20.04.6 point-release
Hello everyone, As you know, we recently had new shims for all the stable series, and to make sure the Ubuntu media for 20.04 are still bootable on secure-boot we need to respin the focal images (as those are still supported). As the build infrastructure doesn't really allow us to easily rebuild the images with just single packages updated, the 20.04.6 rebuilds will have to build from focal-updates as any normal point-release. We want to start building images ASAP, with an estimated delivery date of March 16 (this week). This is all short notice, but this is also a special point-release, as there is no real hard-deadline set for it - it basically needs to be done and the sooner, the better. There's never a good time for this, but seeing that 23.04 Beta is nearing closer and closer, I think we need to at least try it this week. We'll start preparations shortly. In the meantime, a request for both the SRU team and the security team: please coordinate with me/Graham before pushing anything to focal-updates or focal-security this week. Let's assume focal is in a soft freeze as with a regular point-release. Thank you! On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Possibility of accepting a network-based installer of Ubuntu as an official flavor?
Hey Aaron! Actually, this is the one thing that sucks when we don't publish our team's roadmaps to the public (which I'm trying our team to start doing, but it's so busy recently that we didn't manage to yet): there is work ongoing on something like this - and actually this cycle! The MPs for that are still in flight, but Dan Bungert, the maintainer of subiquity, is working on a project called ubuntu-mini-iso. We already had a prototype done and tested, but now we're trying to land all of that to be built by the official infrastructure. The idea is a bit similar to what you described, but with a small difference on how the system-to-install is being downloaded for installation. The ubuntu-mini-iso is a small bootable iso that can be either downloaded and used on a CD/USB-drive or even via UEFI HTTP that brings up a dynamic TUI menu of what Ubuntu images you want to download/install to your target system. It uses simplestreams to select which images, so it'll be quite customizable regarding the selection. The difference is that it then downloads the iso-of-interest into memory and chain-boots into it, allowing the installation of any image as one would normally do. This has some limitations of course, since it needs sufficiently enough RAM. I'm pretty sure Dan can give more details about this when he's up and running. We expect this to be part of lunar in the next weeks. Cheers, On Fri, 24 Feb 2023 at 04:54, Aaron Rainbolt wrote: > > Note, I'm asking this *very* early. I don't have the project I have in > mind even started yet. I'm not even sure what I want to name this > project. This is more of a "testing the waters" to see if this kind of > thing is even a possibility before getting started. > > I've seen more than one person annoyed by the fact that the mini.iso > netinstaller is no more. It was never officially supported anyway, but > apparently people got use out of it, so it seems like something that > would be handy if it still existed. I'm sure we're not going to start > producing it again, so I got the idea of making something that could act > somewhat similar to it. I asked people about this idea on Mastodon and > the response seemed fairly positive. > > My idea is to either write my own installer or use a customized version > of the existing Debian installer, and package it into a "flavor" of its > own, which would be capable of installing any supported version of any > official flavor of Ubuntu. The "flavor" would be able to be held in a > very small ISO file (preferably CD sized), and it would download and > install all of the packages that make up the Ubuntu system at runtime. > This would allow a user to install Ubuntu or any desired flavor thereof > using a single installation medium, rather than having to flash an ISO > every time they want to make a drive install a different flavor. The new > installation would be entirely up-to-date from the get-go, and it would > enable the use of existing small storage media for those users who don't > have sufficiently sized optical discs or flash drives. > > I would eventually aim to make this into an official flavor of Ubuntu, > however it would differ from all existing flavors in several significant > ways: > > * It would be the first flavor that could not be installed onto a target > system by itself. > * It would be the first flavor that could install other flavors onto a > target system by design. > * It would be the first flavor that could install versions of Ubuntu > other than the one it is based on. > * It would have a different installer than any existing flavor of Ubuntu > most likely, and would not be able to make use of existing official > installers in any meaningful way without large changes to one of them. > > Because of these differences, I'm not sure if such a project could ever > become an official flavor, and I may end up simply maintaining it as an > unofficial installer by myself should I end up doing it. > > Is this kind of project a possible candidate for becoming an official > Ubuntu Flavor, or is this enough info to declare it as not a possible > candidate? > > Thanks for your time. > > -- > Aaron Rainbolt > Lubuntu Developer > https://github.com/ArrayBolt3 > https://launchpad.net/~arraybolt3 > @arraybolt3:lubuntu.me on Matrix, arraybolt3 on irc.libera.chat > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- 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: first set of 22.04.2 images building!
Hello everyone! Final stretch for 22.04.2! We rebuilt some of the desktop images during the night, so some of them might need a spot check. Please pick up your favorite flavor images and submit test results to the tracker! http://iso.qa.ubuntu.com/qatracker/milestones/442/builds Almost there! Thank you! On Fri, 17 Feb 2023 at 18:42, Lukasz Zemczak wrote: > > Hello everyone, > > First set of images for the 22.04.2 milestone are building as we > speak. In some hours I expect all flavors to be ready for testing > here: > http://iso.qa.ubuntu.com/qatracker/milestones/442/builds > > It's hard to say if those are release candidates already - everything > should be in place and in theory there is a chance that those are > 'it', but we'll know more after the first round of testing. Please be > sure to download your favorite flavor and give it a quick spin. The > sooner we identify blocking issues, the more likely we'll be able to > figure out something in time for release. > > Good luck! > > Cheers, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > Tools Squad Interim Engineering Manager > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: first set of 22.04.2 images building!
Hello everyone, First set of images for the 22.04.2 milestone are building as we speak. In some hours I expect all flavors to be ready for testing here: http://iso.qa.ubuntu.com/qatracker/milestones/442/builds It's hard to say if those are release candidates already - everything should be in place and in theory there is a chance that those are 'it', but we'll know more after the first round of testing. Please be sure to download your favorite flavor and give it a quick spin. The sooner we identify blocking issues, the more likely we'll be able to figure out something in time for release. Good luck! Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
22.04.2 pre-release SRU freeze - heads up
Hello developers and SRU members, As we're nearing 22.04.2 preparation date, we're entering a sort-of soft freeze for the -updates and -security pockets. We need to keep things stable during the period of release candidate image creation. SRU members and security: please refrain from releasing any updates into jammy-updates and jammy-security until release (February 23rd), at least without coordination with the release team. Developers: there might be still some updates landing into jammy-updates, but in general the velocity will be slower. Thank you! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu 22.04.2 delayed until February 23
Hello everyone, This is basically a copy-paste of the discourse announcement here: https://discourse.ubuntu.com/t/ubuntu-22-04-2-delayed-until-february-23/33319 tl;dr - As there were some unexpected complications during the preparation of our HWE 5.19 kernels for jammy, and with shim 15.7 making its way to the archive, we decided that more time is necessary to get everything ready. We decided to move the 22.04.2 release date to February 23. Every .2 point-release we are providing HWE kernels for the given series [1]. For 22.04 those were to be the kinetic 5.19 kernel, and per the schedule that is always done a bit earlier than the point-release itself. However, the enablement proved to be a bit more challenging due to some unforeseen compiler and dkms issues. This made things take longer than expected, and we think more time is needed to perform the necessary testing of the new kernel. At the same time, we only recently got the new shim (15.7) ready for upload. As this version revokes all currently used keys, this requires a lot of work to get things right so that existing installations continue working as expected. It also requires us to rebuild all the kernels that would be going to the point-release. The extra two weeks should give us more time to prepare and polish everything before starting spinning 22.04.2. With this delay, the expected release date of 22.04.2 is now February 23. # As a regular user of 22.04, am I affected? Not at all. Point releases are done periodically to refresh the installer media, so that users that download images from ubuntu.com and want to perform a fresh installation of Ubuntu get the latest updates without having to download them from the internet afterwards. [1] https://wiki.ubuntu.com/Kernel/LTSEnablementStack On behalf of the Ubuntu Release Team, Łukasz ‘sil2100’ Zemczak -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
The Developer Membership Board Meeting on the 26th of December 2022
Hello everyone, Just sending a quick e-mail that at today's DMB meeting we decided to cancel the next meeting as scheduled for the 26th of December - basically the last one before the end of the year 2022. This means we will only gather once again next year, with the first official meeting of the year being on the 9th of January 2023, 16:00 UTC. See you then! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Extended call for Ubuntu Technical Board candidates
Hello everyone! Some of you might already know me, but just in case: my name is Łukasz Zemczak - also known as 'sil2100' [1] - and I am an official Ubuntu member since 2014. Day-to-day I work from Canonical, joined in 2011, and since around 2014-ish I have been part of the Ubuntu Foundations Team. Since then I have been involved in many things Ubuntu (...previously also Ubuntu Touch, yay landing team!), eventually becoming part of many Ubuntu-specific teams and roles, which currently would be: a Ubuntu Release member, SRU team member, DMB member, Archive Admin and, for now, the Technical Board. The competition is really impressive, but regardless, I'd like to try my chances and run for a re-election on the TB. I don't really know how to do good introductions for things like this, so I'll just say: I love Ubuntu and I love working with everyone involved in it as a whole. If you have any questions, feel free to reach out to me via e-mail, IRC or any other means. Thank you and see you around! [1] https://launchpad.net/~sil2100 On Tue, 29 Nov 2022 at 20:07, Torsten Franz wrote: > > Hi everyone, > > We have received some applications for the new election of the Ubuntu > Technical Board. A lot of great applications from very good candidates. > In order to make a good decision in this selection, we would like to > give the candidates the opportunity to introduce themselves here and to > say a few words about their application and provide a few links to their > work. Everyone will also have the opportunity to ask the candidates > questions. We will start the election on 6 December. All five seats > (besides Mark) will be filled. > > Here is the list of candidates (by alphabetical order of surname): > > - Sebastien Bacher > - Robie Basak > - Ben Collins > - Steve Langasek > - Lukas Märdian > - Alex Murray > - Simon Quigley > - Mathieu Trudel-Lapierre > - Łukasz Zemczak > > If any questions arise, then the Ubuntu Community Council is available > to help. > > On behalf of the Ubuntu Community Council, > Torsten Franz > > > Am 22.11.2022 22:51 schrieb Merlijn Sebrechts: > > WE ARE STILL LOOKING FOR CANDIDATES TO JOIN THE UBUNTU TECHNICAL > > BOARD! > > > > The call remains open until NOVEMBER 27TH, 2022, at 23:59 UTC. This is > > a bit longer than initially anticipated. > > > > Are you interested or do you know of someone who you want to see in > > this role? Please submit the nomination. > > > > WHAT IS THE UBUNTU TECHNICAL BOARD? > > > > The Ubuntu Technical Board is responsible for the technical direction > > of Ubuntu. It makes decisions on package selection, packaging policy, > > installation systems and processes, kernel, X server, display > > management, library versions, and dependencies. The board works with > > relevant teams to establish a consensus on the right path to take, > > especially where diverse elements of Ubuntu cannot find consensus on > > shared components. The current Technical Board is expiring at the end > > of the year, and the Community Council would like to confirm a new > > Technical Board, consisting of five people, who will serve for two > > years. The eligibility requirements are: > > > > WHO IS ELIGIBLE? > > > > Everyone who meets the following criteria: > > > > * Be an Ubuntu Core Developer > > * Be available during typical meeting hours [see > > https://wiki.ubuntu.com/TechnicalBoardAgenda [1]] > > * Have insight into the Ubuntu Development process, architecture, and > > technical culture > > > > HOW DO YOU NOMINATE YOURSELF OR SOMEONE ELSE? > > > > Send the Community Council an email (community-council AT > > lists.ubuntu.com [2]). With your nomination. Note that you can > > nominate yourself too! > > > > HOW DOES THE ELECTION WORK? > > > > The call remains open until November 27th, 2022, at 23:59 UTC. After > > that, the Community Council will review the submissions, submit them > > to Mark Shuttleworth for shortlisting, and proceed with a vote by the > > Ubuntu Development team. > > > > Links: > > -- > > [1] https://wiki.ubuntu.com/TechnicalBoardAgenda > > [2] http://lists.ubuntu.com > > -- > ubuntu-news-team mailing list > ubuntu-news-t...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-news-team -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Kinetic Kudu (22.10) UI Freeze
Hello Ubuntu developers, Effective NOW, we are officially under the User Interface Freeze for Kinetic: https://wiki.ubuntu.com/UserInterfaceFreeze In order to help ensure our documentation is accurate for the release, please notify the documentation team and translation teams of any further changes to artwork, text strings, or UI designs that will be made between now and the release, and please make such changes only where necessary. On behalf of the Ubuntu Release team, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: Call for testing: 20.04.5 release candidate images ready!
Hello everyone! Just a quick heads up: we respun most of the 20.04.5 images to fix the nvidia-390 driver situation (new kernel lrm). Please do some re-testing on the new images! Thank you! On Tue, 30 Aug 2022 at 00:02, Lukasz Zemczak wrote: > > Hello everyone! > > We just finished building our first official set of 20.04.5 release > candidate images. As always, those should be available via the ISO > tracker below: > > http://iso.qa.ubuntu.com/qatracker/milestones/438/builds > > Please pick your favorite flavor and start testing! And be sure to > report your results on the isotracker above. > > As with every recent release, we have a discourse thread for tracking > progress which we try to keep up to date as much as possible: > > https://discourse.ubuntu.com/t/focal-fossa-20-04-5-lts-point-release-status-tracking/29969 > > Best regards, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > Tools Squad Interim Engineering Manager > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: 20.04.5 release candidate images ready!
Hello everyone! We just finished building our first official set of 20.04.5 release candidate images. As always, those should be available via the ISO tracker below: http://iso.qa.ubuntu.com/qatracker/milestones/438/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker above. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/focal-fossa-20-04-5-lts-point-release-status-tracking/29969 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Soft-freeze of focal-updates (and security!) for 20.04.5
Hello developers and SRU members, Just a quick heads up: as 20.04.5 is already next week, we're starting to stabilize focal-updates for the upcoming release candidate images (planned for around Monday next week). This means that things might be a bit slower moving in focal-updates - especially after the candidate images are built - all until 1st of September, which is of course the .5 planned release date. Note to SRU members and ubuntu-security: please do not release any packages into focal-updates without coordination with the ubuntu-release team until 20.04.5 is released. I'd like a soft-freeze on the focal-security pocket starting around Thursday as well so to keep the archive contents in a sane state. Generally accepting packages into focal-proposed should be okay, though best if we keep -proposed open for any last-minute fixes, if needed. Thank you! On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- 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: 22.04.1 release candidate images ready!
Hello everyone! As you know, we had to delay 22.04.1 by a week to get an additional fix in. This has now happened and new release candidate images are building as we speak. Please start testing as soon as the new images for your favorite flavors appear on the tracker: http://iso.qa.ubuntu.com/qatracker/milestones/437/builds The ones with "(re-building)" in the name are still building, but many have already finished. Let's give those as much testing as possible and, hopefully, we'll have a swift release on Thursday. Thank you, On Tue, 2 Aug 2022 at 00:57, Lukasz Zemczak wrote: > > Hello everyone! > > We just finished building our first official set of 22.04.1 release > candidate images. From what we're seeing so far things seem to be > looking quite nice, so fingers-crossed for those being our final ones! > > http://iso.qa.ubuntu.com/qatracker/milestones/437/builds > > Please pick your favorite flavor and start testing! And be sure to > report your results on the isotracker above. > > As with every recent release, we have a discourse thread for tracking > progress which we try to keep up to date as much as possible: > > https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-1-lts-point-release-status-tracking/29102 > > Best regards, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > Tools Squad Interim Engineering Manager > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu Core Developer - Athos Ribeiro
Hello everyone! We are pleased to announce that at today's DMB meeting athos has been formally accepted into the Ubuntu Core Developer family! Welcome aboard and congratulations! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu 22.04.1 delayed until August 11
Hello everyone, This is basically a copy-paste of my discourse announcement earlier. During testing of our 22.04.1 release candidates, we were made aware of an unexpected issue regarding the OEM Installation feature of our Ubuntu Desktop installer images. This bug causes preinstalled snaps not to work on the final target system after the “OEM install” option is selected during installation (i.e. after the end-user setup is performed) (LP: #1983528 3). This behavior would seriously impact the experience of any users whose login was created after an OEM install. In order not to compromise the quality of the installation media, we have decided to delay the release of 22.04.1 by a week, releasing on August 11, 2022. The issue has been identified and a fix is in review, so we are confident it will be resolved shortly. However, moving release to the 11th will give us time to address the bug and test the fix, and will allow users to plan for the update with a definitive date. # As a regular user of 22.04, am I affected? This issue only affects new installations using the OEM Install mode of Ubiquity and using the release candidate images for 22.04.1. Existing users and users installing with the currently available 22.04 images are not affected in any way. # Why delaying and not hotfixing? We identified this issue late in testing. The current identified fix is in a core Ubuntu component (snapd), so we would like to perform a full test cycle on the package and the new images before we ship them to our users. We do not want to risk introducing any new issues while pushing out a hotfix to a core component, so we believe the best approach is to delay the update. On behalf of the Ubuntu Release Team, Łukasz ‘sil2100’ Zemczak -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- 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: 22.04.1 release candidate images ready!
Argh, I need to go through all the flavors and make sure the urls work. Certainly seems to be a checklist-worthy item, and we didn't have this on our checklist. On Wed, 3 Aug 2022 at 20:27, Heather Ellsworth wrote: > > Hey there.. I wanted to help test, chose Mate since I see 0/4 completed > and it appears that the Mate download links are broken. Both the http > link and zsync command listed seem to find nothing > > http://iso.qa.ubuntu.com/qatracker/milestones/437/builds/254991/downloads > > I'd be happy to do some install testing of Mate if someone can provide > me with a correct link. In the mean time I'll go test Kylin. > > Cheers, > Heather > > On 8/1/22 16:57, Lukasz Zemczak wrote: > > Hello everyone! > > > > We just finished building our first official set of 22.04.1 release > > candidate images. From what we're seeing so far things seem to be > > looking quite nice, so fingers-crossed for those being our final ones! > > > > http://iso.qa.ubuntu.com/qatracker/milestones/437/builds > > > > Please pick your favorite flavor and start testing! And be sure to > > report your results on the isotracker above. > > > > As with every recent release, we have a discourse thread for tracking > > progress which we try to keep up to date as much as possible: > > > > https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-1-lts-point-release-status-tracking/29102 > > > > Best regards, > > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: 22.04.1 release candidate images ready!
Hello everyone! We just finished building our first official set of 22.04.1 release candidate images. From what we're seeing so far things seem to be looking quite nice, so fingers-crossed for those being our final ones! http://iso.qa.ubuntu.com/qatracker/milestones/437/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker above. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-1-lts-point-release-status-tracking/29102 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Soft-freeze of jammy-updates for 22.04.1
Hello developers and SRU members, Just a quick heads up: as 22.04.1 is already next week, we're starting to stabilize jammy-updates for the upcoming release candidate images (planned for around EOW or Monday). This means that things might be a bit slower moving in jammy-updates - especially after the candidate images are built - all until 4th of August, which is of course the .1 planned release date. Note to SRU members and ubuntu-security: please do not release any packages into jammy-updates/jammy-security without coordination with the ubuntu-release team until 22.04.1 is released. Generally accepting packages into jammy-proposed should be okay, though best if we keep -proposed open for any last-minute fixes, if needed. Thank you! On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: 22.04 release candidate images ready!
Hello everyone! We are now finishing building our latest batch of 22.04 release candidate images to the iso-tracker. From what we're seeing so far things seem to be looking quite nice, so fingers-crossed for those being our final ones! http://iso.qa.ubuntu.com/qatracker/milestones/432/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-release-status-tracking/27763 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Jammy Jellyfish (22.04) Final Freeze
The final freeze for Impish Indri has now been reached and we are heading into the final stretch of the release cycle with the release of Ubuntu 22.04 next week. The current uploads in the queue will be reviewed and either accepted or rejected as appropriate by pre-freeze standards, but anything from here on should fit two broad categories: 1) Release critical bugs that affect ISOs, installers, or otherwise can't be fixed easily post-release. 2) Bug fixes that would be suitable for post-release SRUs, which we may choose to accept, reject, or shunt to -updates for 0-day SRUs on a case-by-case basis. This second case should have SRU bugs filed with the appropriate template, and be referenced from the changelog. For unseeded packages that aren't on any media or in any supported sets, it's still more or less a free-for-all, but do take care not to upload changes that you can't readily validate before release. That is, ask yourself if the current state is "good enough", compared to the burden of trying to fix all the bugs you might accidentally be introducing with your shiny new upload. We will shut down cronjobs and spin some RC images over the next couple of days (possibly Monday) once the archive and proposed-migration have settled a bit, and we expect everyone with a vested interest in a flavour (or two) and a few spare hours here and there to get to testing to make sure we have another uneventful release next week. Last minute panic is never fun. On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: 22.04 Beta call for testing!
Oh no! Let me look into that. I see that cdimage had some issues contacting the tracker, first time I see this: Unable to contact tracker: Let me manually add it up. Apologies for the inconvenience! On Wed, 30 Mar 2022 at 10:13, David Mohammed wrote: > > Hi Lukasz, > > please can you upload Ubuntu Budgie's ISO - it is missing from the tracker. > > TIA > > David > > On Wed, 30 Mar 2022 at 09:10, Lukasz Zemczak > wrote: > > > > Hello everyone! > > > > As you are all probably aware, we are in the middle of 22.04 Beta > > preparation. Yesterday night we were finally able to get all the > > essential bits landed - therefore our first beta candidate images have > > been built and made available on the ISO Tracker here: > > http://iso.qa.ubuntu.com/qatracker/milestones/431/builds > > > > Beta is a great occasion to find and identify possible serious issues > > that need to be fixed before the final release. So please take a > > moment to pick up a flavor of your liking, do a few test installs, > > follow a few test cases and leave a trace on the tracker! It's > > important, as the earlier we identify those issues, the more likely it > > will be that we might resolve them before Final Freeze. > > > > Huge thanks! > > > > -- > > Łukasz 'sil2100' Zemczak > > Foundations Team > > lukasz.zemc...@canonical.com > > www.canonical.com > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
22.04 Beta call for testing!
Hello everyone! As you are all probably aware, we are in the middle of 22.04 Beta preparation. Yesterday night we were finally able to get all the essential bits landed - therefore our first beta candidate images have been built and made available on the ISO Tracker here: http://iso.qa.ubuntu.com/qatracker/milestones/431/builds Beta is a great occasion to find and identify possible serious issues that need to be fixed before the final release. So please take a moment to pick up a flavor of your liking, do a few test installs, follow a few test cases and leave a trace on the tracker! It's important, as the earlier we identify those issues, the more likely it will be that we might resolve them before Final Freeze. Huge thanks! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Jammy Jellyfish Beta milestone reminder
Hello everyone! Gentle reminder about the nearing Beta milestone for 22.04 next week (along with the usual Beta Freeze on Monday). Make sure to get as much as possible into the release pocket before that time - the Beta is usually a great occasion to test how things are looking before the release. The closer it is to our final product, the better. Thanks. Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
New Ubuntu Contributing Developer - Heinrich Schuchardt
Hello, We are pleased to announce that Heinrich Schuchardt's application for Contributing Developer has been reviewed successfully - and they're now officially part of the team! Welcome! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- 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: preliminary 20.04.4 release candidate images ready!
Follow up to this. I have now started building the first set of real release candidate images (aka ones that, if no blocking issues are found, should be good to be released). Once the rebuilds are finished, please be sure to test your favorite flavors as soon as possible. Thanks again! On Sat, 19 Feb 2022 at 00:34, Lukasz Zemczak wrote: > > Hello everyone! > > Some moments ago we published our first official release candidate > images for the 20.04.4 point-release. We seem to have most known > blocker issues out of the way, but these will not be final images - at > least not for the desktop variants (we're waiting for some OEM kernel > work to happen re: that). > As always, we have an ISO Tracker milestone set up for it: > > http://iso.qa.ubuntu.com/qatracker/milestones/430/builds > > Please pick your favorite flavor and start testing! And be sure to > report your results on the isotracker. The sooner we get testing done, > the earlier we'll catch any possible blockers. > > As with every recent release, we have a discourse thread for tracking > progress which we try to keep up to date as much as possible: > > https://discourse.ubuntu.com/t/focal-fossa-20-04-4-lts-point-release-status-tracking/26490 > > Let's go! > > Best regards, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: preliminary 20.04.4 release candidate images ready!
Hello everyone! Some moments ago we published our first official release candidate images for the 20.04.4 point-release. We seem to have most known blocker issues out of the way, but these will not be final images - at least not for the desktop variants (we're waiting for some OEM kernel work to happen re: that). As always, we have an ISO Tracker milestone set up for it: http://iso.qa.ubuntu.com/qatracker/milestones/430/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker. The sooner we get testing done, the earlier we'll catch any possible blockers. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/focal-fossa-20-04-4-lts-point-release-status-tracking/26490 Let's go! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Soft-freeze of focal-updates for 20.04.4
Hello developers and SRU members, Just a quick heads up: as 20.04.4 is already next week, we're starting to stabilize focal-updates for the upcoming release candidate images (planned for around EOW). This means that things might be a bit slower moving in focal-updates - especially after the candidate images are built - all until 24th of February, which is of course the .4 planned release date. Note to SRU members and ubuntu-security: please do not release any packages into focal-updates/focal-security without coordination with the ubuntu-release team until 20.04.4 is released. Generally accepting packages into focal-proposed should be okay, though best if we keep -proposed open for any last-minute fixes, if needed. Thank you. On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- 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
Hey! I usually don't do those, but thought I'd try. I had 2 days of +1 maintenance (Monday and Tuesday), and even though I wasn't able to give it my 100% due to other responsibilities, here's what I did more-or-less. These are from my slightly chaotic notes: * Looking into capnproto - Stuck in -proposed because of FTBFS on all arches - Fixed the FTBFS by fixing the failing tests - possibly due to the new openssl - Sadly, it seems it fails on ppc64el now only, didn't have time to pursue that yet * fakechroot depwait: - Blocked by jemalloc FTBFS - see below, but now migrated * jemalloc FTBFS checking: - Failed due to glibc 2.34 dropping malloc_hooks, pushed fix - Migrated * Removal of uvp-monitor per request as it was unmaintained Then I moved on to doing some NBS cleanup: * glewlwyd no-change rebuild to clear associated NBS * biboumi and the libidn11 NBS - Looked at botan that's blocking that, but ppc64el test failure makes no sense - Hacked a bit on it but didn't make much progress * emacs - libotf0 NBS - emacs was FTBFS after a no-change rebuild - Cherry-picked fix to make emacs build again * libquvi-0.9-0.9.3 - Its dependency, quvi, had a no-change rebuild FTBFS - Since the package was unmaintained, I filled a removal bug and proceeded with the removal (LP: #1958967) - Please shout if you want it back, but remember that it first needs a build fix! * libslurm36 NBS - Caused by the mpich no-change rebuild FTBFS - Looked into the failure, trying to identify obvious solution - Tried building the new version from Debian - passed - Prepped and uploaded a merge for mpich ...and I think that's it. The rest was outside of +1 maintenance scope, I think. Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
OEM archive plans for 22.04
Hello everyone, With a few of my hats on (technical board, SRU, release team), as I was diving into documenting some of the OEM archive portions, I started thinking a bit more about the OEM situation for the incoming 22.04 release. I was not part of any of the original discussions for the OEM stack, so I'd be grateful for some knowledge sharing from people that know more. We introduced the OEM-specific metapackages in 20.04, enabling the OEM archives for certain certified SKUs. This was limited only to 20.04. Now, the next hot LTS is coming our way and I was wondering: what is the plan there? My main concern is that it was said that the meta packages should be strictly for focal *only*, so none of the meta packages have been in any devel release since then. Those were always going straight and only to 20.04. Since 22.04 is an LTS, people running 20.04 will get the ability to upgrade, so I'd like to make sure we have the upgrade story straight. As said, I might be missing some context - maybe this has been discussed already. But is the plan to get all the current oem-*-meta packages no-change rebuilt for jammy? Or are those going to be re-introduced as certification of machines for 22.04 goes forward? Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Change unattended-upgrades from Depends to Recommends on ubuntu-server-minimal
Hey Matthew! When you check what the ./update script does, it actually executes germinate-update-metapackage from germinate, which on the other hand uses the ubuntu and platform seeds to repopulate the metapackage contents. So to get it removed from ubuntu-server-minimal, you will first need to remove it from the server-minimal seed. All the Ubuntu-specific seeds are hosted on Launchpad in the following git repository: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu Cheers, On Tue, 14 Dec 2021 at 17:23, Matthew Ruffell wrote: > > Hi everyone. > > I was testing Jammy and happened to notice that unattended-upgrades Depends on > ubuntu-server-minimal, and when removing unattended-upgrades, > ubuntu-server-minimal is removed along with it: > > $ sudo apt remove unattended-upgrades > ... > The following packages will be REMOVED: > ubuntu-server-minimal unattended-upgrades > 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. > > $ sudo apt rdepends unattended-upgrades > unattended-upgrades > Reverse Depends: > Recommends: python3-software-properties > Recommends: ubuntu-mate-desktop > Recommends: ubuntu-mate-core > Depends: freedombox > Recommends: fbx-all > Depends: ubuntu-server-minimal > > Should unattended-upgrades be changed from Depends to Recommends for > ubuntu-server-minimal? > > It is very common for our larger users to remove unattended-upgrades so they > can > manage their systems patching manually. > > I filed a bug against ubuntu-meta: > > https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1954724 > > I was in the process of making a debdiff, and I happened to notice that > unattended-upgrades is only in the server-minimal-$ARCH files only: > > $ grep -Rin "unattended-upgrades" . > ./server-minimal-armhf:23:unattended-upgrades > ./server-minimal-riscv64:23:unattended-upgrades > ./server-minimal-arm64:23:unattended-upgrades > ./server-minimal-ppc64el:23:unattended-upgrades > ./server-minimal-s390x:24:unattended-upgrades > ./server-minimal-amd64:23:unattended-upgrades > > When I also ran the ./update script in ubuntu-meta, it automatically > repopulated > server-minimal-$ARCH with unattended-upgrades again, so it seems I am missing > something to do with dependency magic in the archive. > > Thanks, > Matthew > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Developers! New 20.04.4 release date: February 24th
Hello Ubuntu developers, Just a quick heads up: we decided to move the release date of the 20.04.4 point-release to February 24th 2022, so 2 weeks later than planned. The schedule has been updated accordingly. We noticed that the previous date collided with the usual Chinese New Year break, which would mean potentially we'd not have the full test coverage we'd like to have. The new date on the other hand is on the same day as Feature Freeze, but we still think it's a much better trade-off. On behalf of the release team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu Core Developer - William Wilson
Hello, We are pleased to announce that at today's DMB meeting jawn-smith has been accepted into the Ubuntu Core Developer family! Yay! Another great addition to the team! Happy hacking! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu MOTU - Simon Chopin
Hey everyone, Please congratulate Simon Chopin on his successful Ubuntu MOTU application! He has now been added to the respective team and granted the powers of the Masters of the Universe! \o/ Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Impish Indri (21.10) Final Freeze
The final freeze for Impish Indri has now been reached and we are heading into the final stretch of the release cycle with the release of Ubuntu 21.10 next week. The current uploads in the queue will be reviewed and either accepted or rejected as appropriate by pre-freeze standards, but anything from here on should fit two broad categories: 1) Release critical bugs that affect ISOs, installers, or otherwise can't be fixed easily post-release. 2) Bug fixes that would be suitable for post-release SRUs, which we may choose to accept, reject, or shunt to -updates for 0-day SRUs on a case-by-case basis. This second case should have SRU bugs filed with the appropriate template, and be referenced from the changelog. For unseeded packages that aren't on any media or in any supported sets, it's still more or less a free-for-all, but do take care not to upload changes that you can't readily validate before release. That is, ask yourself if the current state is "good enough", compared to the burden of trying to fix all the bugs you might accidentally be introducing with your shiny new upload. We will shut down cronjobs and spin some RC images over the next couple of days once the archive and proposed-migration have settled a bit, and we expect everyone with a vested interest in a flavour (or two) and a few spare hours here and there to get to testing to make sure we have another uneventful release next week. Last minute panic is never fun. On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Call for testing: 18.04.6 release candidate images ready!
Hello, As already mentioned in my earlier e-mail, we are working on a limited 18.04.6 point-release for some of the still-supported flavors this week. Yesterday we built our first release candidates, so if you have a moment please help out with doing some usual ISO testing: http://iso.qa.ubuntu.com/qatracker/milestones/426/builds The relevant arches are of course amd64 and arm64. We have a tracking post on discourse as well: https://discourse.ubuntu.com/t/bionic-beaver-18-04-6-lts-extra-point-release-status-tracking/24053 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Release candidate preparation for 18.04.6
Hello developers, As you know, we are refreshing the 18.04 images with an additional point release to get installation media bootable again after the key revocations. .6 is special because it's not a standard point-release, with most flavors now being over their support timeline - so essentially we'll only be building Ubuntu Desktop and Ubuntu Server images (+ Ubuntu Core a bit later). Also, since this is not a regularly scheduled release, our estimated release date is this Thursday (16th of September) but it's not a hard-set deadline, so we can be more flexible. That being said, we are now slowly preparing for our first release candidates for .6. Will send out a follow up e-mail about image call-for-testing once that's done, but until then a note to all SRU and security-team members: please don't release anything into bionic without consulting with the release team first. Everything will go back to normal once we release. Thank you! Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Impish Indri (21.10) UI Freeze
Hello Ubuntu developers, Effective yesterday, we are now officially under the User Interface Freeze for Impish: https://wiki.ubuntu.com/UserInterfaceFreeze In order to help ensure our documentation is accurate for the release, please notify the documentation team and translation teams of any further changes to artwork, text strings, or UI designs that will be made between now and the release, and please make such changes only where necessary. On behalf of the Ubuntu Release team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Call for testing: 20.04.3 release candidate images ready!
Hello everyone! Some moments ago we published our first official release candidate images for the 20.04.3 point-release. We seem to have all critical blockers resolved, so my hope is that these images will be the final ones we'll be releasing next week. http://iso.qa.ubuntu.com/qatracker/milestones/425/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/focal-fossa-20-04-3-lts-point-release-status-tracking/22948 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Nearing soft-freeze for the upcoming 20.04.3
Hello everyone, Just a reminder: tomorrow we will be freezing focal-updates (and focal-security) for the preparation of release candidates for 20.04.3 (planned to be released on the 26th of August). This means that basically after our release candidate images are built, no packages - other than ones approved by the release team - will be released from -proposed. Note to SRU members: please tread carefully even when accepting new uploads to -proposed - and of course, please do not release any SRUs until 20.04.3 is done. There will be a separate announcement tomorrow once we have the images. Fingers crossed for a smooth release! On behalf of the release team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu 20.04.3 delayed until August 26th
... and the footnotes for the earlier e-mail: [1] https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1937115 [2] https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1934548 On Tue, 10 Aug 2021 at 10:30, Lukasz Zemczak wrote: > > Hello, > > While working towards the 20.04.3 milestone, we received reports of > the currently available shim package causing daily builds of our > installation media to fail to boot on some devices[1]. A fix for that > is now in progress, but as we would like to make sure the new version > of the package is well tested before candidate images are built. > Subsequently, we decided more time is needed. In addition to that we > are also investigating an unrelated issue with our RISC-V images[2], > whose root cause is not yet fully understood. As we feel that rushing > things through is not the right way to go, we decided to play it safe > and delay the point-release date a week, to August 26th. > > That being said, we will be freezing the focal-updates pocket at the > same date as originally planned (on August 12th), afterwards only > releasing packages that are critical for the .3 milestone. Let’s all > use the additional week for further testing. > > Remember that the progress of the 20.04.3 release can be tracked at > any time via our release status tracking post on discourse: > https://discourse.ubuntu.com/t/focal-fossa-20-04-3-lts-point-release-status-tracking/22948 > > Thank you. > > On behalf of the release team, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu 20.04.3 delayed until August 26th
Hello, While working towards the 20.04.3 milestone, we received reports of the currently available shim package causing daily builds of our installation media to fail to boot on some devices[1]. A fix for that is now in progress, but as we would like to make sure the new version of the package is well tested before candidate images are built. Subsequently, we decided more time is needed. In addition to that we are also investigating an unrelated issue with our RISC-V images[2], whose root cause is not yet fully understood. As we feel that rushing things through is not the right way to go, we decided to play it safe and delay the point-release date a week, to August 26th. That being said, we will be freezing the focal-updates pocket at the same date as originally planned (on August 12th), afterwards only releasing packages that are critical for the .3 milestone. Let’s all use the additional week for further testing. Remember that the progress of the 20.04.3 release can be tracked at any time via our release status tracking post on discourse: https://discourse.ubuntu.com/t/focal-fossa-20-04-3-lts-point-release-status-tracking/22948 Thank you. On behalf of the release team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposal: Stop auto-syncs a week earlier (Debian releases on the 14th)
+1 from my side at least. Seems like a sensible thing to do. Cheers, On Thu, 5 Aug 2021 at 17:53, Julian Andres Klode wrote: > > Hi folks, > > with Debian releasing on the 14th, leaving the auto-sync on until > the 19th would have the effect of drawing in a lot of new packages > just before feature freeze. > > I suggest we instead stop the auto syncs a week earlier; either > next Thu or next Friday (12th or 13th), to avoid that. > > This does not change the feature freeze, so people can still manually > syncpackage stuff they want, but please don't overdo it :) > > Thanks, > Julian > -- > 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 -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Question to flavors: touch-base on flavor participation for 21.10!
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 - 21.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 21.10 happen for their users. This is why, similarly to last year, I will need a confirmation follow-up message about impish 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! Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Hirsute Hippo (21.04) Beta Freeze
As of a short while ago, hirsute has entered the Beta Freeze, with a goal of releasing Beta images sometime late Thursday. *From now until the beta is released, please only upload updates for packages on any release images if you /need/ to get them into the beta itself.* Please hold off with everything else until after we release on Thursday. The queue freeze will last from now until final release in April, which means that all seeded packages will now need a spot-check and review in the queue from a release team member before they are let into the archive. As with the previous releases, we have a bot in place that will accept uploads that are unseeded and don't affect images. Don't take this as an open invitation to break Feature Freeze on those components, this is just to reduce the burden on the release team, so we only review the uploads that need very serious consideration. If you find the bot is blocking an upload that you think should have been auto-accepted, let us know and we'll sort it out. We will be spinning a set of beta candidates most probably later today or tomorrow morning EU time, after the last few changes have migrated into hirsute. We then encourage people to do ASAP for their favourite flavour(s) as they come off the line. Happy bug-hunting from now until the final release, and please do help out and test ISOs, netboot, etc, where you can and let us know what's broken in your environment(s). As a reminder, the Beta images will appear on the ISO Tracker here: http://iso.qa.ubuntu.com/qatracker/milestones/422/builds On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Hirsute Hippo (21.04) UI Freeze
Hello Ubuntu developers, Effective yesterday, we are now officially under the User Interface Freeze for Hirsute: https://wiki.ubuntu.com/UserInterfaceFreeze In order to help ensure our documentation is accurate for the release, please notify the documentation team and translation teams of any further changes to artwork, text strings, or UI designs that will be made between now and the release, and please make such changes only where necessary. On behalf of the Ubuntu Release team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Improvements to the point-release release process - stricter processes for fixes
Hello everyone, In an attempt to improve our processes and quality of the LTS point-release images, starting with 20.04.3 (in August) we will be trying a bit of a safer approach. Basically the main noticeable change is that we will now be following the SRU procedures even for any release blockers that we find during the point-release week. This means that, besides some very exceptional cases, every fix (even for a blocker) will have to follow the same verification, regression analysis and aging period process - in which case, if a bug is found in the release candidate images, we will be simply delaying the point release until the fix is verified, aged and only then released into updates. Delaying a point-release is unfortunate, but better than lowering our quality standards. We had a few cases already where our last minute fixes, fast-tracked under time pressure, were not tested thoroughly enough and introduced regressions (or, similarly annoying, appeared to be only partial fixes). As quality is the most important aspect of any Ubuntu release, we want to make sure users get the best experience of our point-release images. To accommodate this change, and to make sure as many release blockers are found as early as possible, we will also be switching -proposed off from the series daily image builds 2 weeks before release (so a week before the first release candidate images are planned). Previously we stuck with proposed-enabled daily images until one week before release (only switching those off for when release candidates are built), mainly as a legacy from old times when -proposed as a whole was flushed to -updates as part of the process. This has not been done since years already (as it's no longer safe), so leaving -proposed on dailies makes less sense than it had in the past. What does it all mean to you, developers? Please be sure to land any critical or important changes for the given point-release as soon as possible, preferably with release -2 weeks as the deadline. Every other last minute SRU will potentially be risking the delay of the release. Also, once -proposed is disabled for dailies, it would also be wonderful if the pre-point-release images could get as much testing as possible. The sooner critical issues are identified, the higher chances are we will not have to slip the release. I'm pretty confident that with these changes we will all benefit equally. Thank you! On behalf or the release team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- 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: ubiquity-based 20.04.2.0 desktop image respins
Ok, apologies for that, Ubuntu Budgie is now published. There was an issue with the disk volume label being too long but I worked-around it and re-published. The manifest diff for Budgie: * Ubuntu Budgie: https://paste.ubuntu.com/p/CYftbNwddq/ Good luck testing! Cheers, On Wed, 10 Feb 2021 at 12:58, Lukasz Zemczak wrote: > > It is, but uh, I see the image build is stuck for some reason (or > failed). Let me investigate! > > On Wed, 10 Feb 2021 at 12:56, David Mohammed wrote: > > > > Lukasz, > > > > So Ubuntu Budgie isn't affected? > > > > On Wed, 10 Feb 2021 at 11:53, Lukasz Zemczak > > wrote: > > > > > > Hello everyone, > > > > > > As some of you know, shortly after release of 20.04.2 a regression in > > > the ubiquity installer was discovered [1], leading to certain systems > > > failing to install the Linux kernel (when the connected to the > > > internet during the installation), resulting in unbootable systems. > > > The issue was found to be in the OEM-archive handling. > > > > > > We think we have fixed the issue and, since this is a rather serious > > > issue, decided to re-spin all the affected ubiquity-based desktop > > > flavors. The images are now available on the ISO tracker's 20.04.2.0 > > > milestone: > > > http://iso.qa.ubuntu.com/qatracker/milestones/421/builds > > > > > > We'd appreciate the usual help with testing of the images. > > > > > > As we have not anticipated a re-spin and the focal-updates gates were > > > open for a day, there are a few additional changes besides the new > > > ubiquity package, so please keep that in mind. The manifest diffs > > > (showing which packages have been upgraded between .2 and .2.0) are > > > available here: > > > > > > * Ubuntu: https://paste.ubuntu.com/p/KyTyYddqgm/ > > > * Kubuntu: https://paste.ubuntu.com/p/F2FNJPSKdy/ > > > * Ubuntu Kylin: https://paste.ubuntu.com/p/THNn5RZ3zp/ > > > * Ubuntu Mate: https://paste.ubuntu.com/p/C2gn5dgj4D/ > > > * Xubuntu: https://paste.ubuntu.com/p/y3gtPQ87jS/ > > > > > > Thank you! > > > > > > [1] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1915114 > > > > > > -- > > > Łukasz 'sil2100' Zemczak > > > Foundations Team > > > lukasz.zemc...@canonical.com > > > www.canonical.com > > > > > > -- > > > ubuntu-devel mailing list > > > ubuntu-devel@lists.ubuntu.com > > > Modify settings or unsubscribe at: > > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- 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: ubiquity-based 20.04.2.0 desktop image respins
It is, but uh, I see the image build is stuck for some reason (or failed). Let me investigate! On Wed, 10 Feb 2021 at 12:56, David Mohammed wrote: > > Lukasz, > > So Ubuntu Budgie isn't affected? > > On Wed, 10 Feb 2021 at 11:53, Lukasz Zemczak > wrote: > > > > Hello everyone, > > > > As some of you know, shortly after release of 20.04.2 a regression in > > the ubiquity installer was discovered [1], leading to certain systems > > failing to install the Linux kernel (when the connected to the > > internet during the installation), resulting in unbootable systems. > > The issue was found to be in the OEM-archive handling. > > > > We think we have fixed the issue and, since this is a rather serious > > issue, decided to re-spin all the affected ubiquity-based desktop > > flavors. The images are now available on the ISO tracker's 20.04.2.0 > > milestone: > > http://iso.qa.ubuntu.com/qatracker/milestones/421/builds > > > > We'd appreciate the usual help with testing of the images. > > > > As we have not anticipated a re-spin and the focal-updates gates were > > open for a day, there are a few additional changes besides the new > > ubiquity package, so please keep that in mind. The manifest diffs > > (showing which packages have been upgraded between .2 and .2.0) are > > available here: > > > > * Ubuntu: https://paste.ubuntu.com/p/KyTyYddqgm/ > > * Kubuntu: https://paste.ubuntu.com/p/F2FNJPSKdy/ > > * Ubuntu Kylin: https://paste.ubuntu.com/p/THNn5RZ3zp/ > > * Ubuntu Mate: https://paste.ubuntu.com/p/C2gn5dgj4D/ > > * Xubuntu: https://paste.ubuntu.com/p/y3gtPQ87jS/ > > > > Thank you! > > > > [1] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1915114 > > > > -- > > Łukasz 'sil2100' Zemczak > > Foundations Team > > lukasz.zemc...@canonical.com > > www.canonical.com > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: ubiquity-based 20.04.2.0 desktop image respins
Hello everyone, As some of you know, shortly after release of 20.04.2 a regression in the ubiquity installer was discovered [1], leading to certain systems failing to install the Linux kernel (when the connected to the internet during the installation), resulting in unbootable systems. The issue was found to be in the OEM-archive handling. We think we have fixed the issue and, since this is a rather serious issue, decided to re-spin all the affected ubiquity-based desktop flavors. The images are now available on the ISO tracker's 20.04.2.0 milestone: http://iso.qa.ubuntu.com/qatracker/milestones/421/builds We'd appreciate the usual help with testing of the images. As we have not anticipated a re-spin and the focal-updates gates were open for a day, there are a few additional changes besides the new ubiquity package, so please keep that in mind. The manifest diffs (showing which packages have been upgraded between .2 and .2.0) are available here: * Ubuntu: https://paste.ubuntu.com/p/KyTyYddqgm/ * Kubuntu: https://paste.ubuntu.com/p/F2FNJPSKdy/ * Ubuntu Kylin: https://paste.ubuntu.com/p/THNn5RZ3zp/ * Ubuntu Mate: https://paste.ubuntu.com/p/C2gn5dgj4D/ * Xubuntu: https://paste.ubuntu.com/p/y3gtPQ87jS/ Thank you! [1] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1915114 -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Call for testing: 20.04.2 release candidate images ready!
Hello everyone! I'm only sending this e-mail now as previously we were still resolving some unexpected issues regarding the .2 point-release. After a rough start, we now have a *hopefully* stable set of 20.04.2 release candidate images built and published on the .2 milestone: http://iso.qa.ubuntu.com/qatracker/milestones/420/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/focal-fossa-20-04-2-lts-point-release-status-tracking/ Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: helping golang-golang-x-sys to migrate
Hey Reinhard, I see that at least golang-github-canonical-go-dqlite seems like a good candidate to hint with a force-reset-test - I'll do that later today (as it only passed *once* in its whole testing history, so it's not a reliable testsuite). I have retried one of the failures there and will try seeing if the other failures make any sense. Cheers, On Sun, 3 Jan 2021 at 22:11, Reinhard Tartler wrote: > > Hi folks, > > I couple of golang packages I care deeply about are stuck in hirsute-proposed > due to autopkgtest failures that I had a hard time understanding. I've come > to the conclusion that the problem must be related to > https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#golang-golang-x-sys > > It seems that there are regressions in the following packages: > > - golang-github-canonical-go-dqlite > - golang-github-lucas-clemente-quic-go > - golang-google-grpc > > I'm not familiar with those testsuites, but on the first look, there might be > timing issues. > > I'd appreciate some thoughts/comments on helping golang-golang-x-sys migrate > to hirsute. > > Thanks! > > -- > regards, > Reinhard > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu Core Developer - Lukas Märdian
Hello everyone! We are pleased to announce that at today's DMB meeting slyon has been accepted into the Ubuntu Core Developer family! Welcome aboard! Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[SRU] "Regression Potential" is now "Where problems could occur"
Dear developers, Per Iain's (and others) proposition, we've made a small tweak to the SRU process in order to help everybody produce SRU bugs that can be accepted with more confidence. = What is the problem? = The "Regression Potential" section is often used as a space for developers to argue why their upload is risk free, and should be accepted. The intention of the section, however, is for developers to demonstrate that they have thought "what could go wrong with this update?" Too often, we're seeing "None" or "Low" as a Regression Potential. In these cases, we will already go back to the uploader asking for them to replace this with an analysis of the *potential* places where regressions could occur. = What is the proposed solution? = The actual change is that we are updating the template to rename this section to "Where problems could occur". We think this is a more clear title that will guide all developers as to the expectations for what should be written here. We've also written some small updates to the StableReleaseUpdates wiki page which hopefully make this a bit clearer. https://wiki.ubuntu.com/StableReleaseUpdates#Procedure = Will you reject my uploads if I still write "Regression Potential"? = No. If the contents of the bug report contain all of the information required, we don't mind what the sections are called. As said, we have renamed the section only to make it more clear of what we expect to see written there. = But there's no actual change in the requirements, this is just a change of wording. = That is correct. On behalf of the Ubuntu SRU team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu Core Developers - Olivier Tilloy and Sergio Durigan Junior!
Hello everyone, After yesterday's DMB meeting, please congratulate our two new Ubuntu core-dev members: oSoMon and sergiodj! Welcome to the team! Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Versions of Theme-D and Theme-D-Gnome
Hey Tommi, As per the release schedule, on the 27th of August groovy entered Debian Import Freeze meaning that the autosyncing of packages from Debian has been disabled. The new versions of Theme-D* have been uploaded to Debian afterwards, in September, so without someone explicitly requesting the sync those package have not been updated before release. Hirsute has already pulled in the new versions if anything via autosync. Cheers, On Fri, 30 Oct 2020 at 12:02, Tommi Höynälänmaa wrote: > > Hi > > The versions of Theme-D and Theme-D-Gnome are 3.0.5-1 and 0.9.4-3 in > Debian testing. Why haven't these versions been updated for Ubuntu? The > corresponding versions in groovy are 1.4.1-1 and 0.9.0-1. > > Yours sincerely, > > Tommi Höynälänmaa > > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Focal update of broken Calibre package
Hello Norbert, With my SRU team hat on, after reading what you said about the status of current calibre, I would say it is possible to update the package version in focal to 5.2.0. But we would need to know a bit more, and there is some (important) paperwork to do. First thing to remember is that for a new version to be releasable to a stable series it also has to be present in all the newer series as well - so groovy upwards. We are long past debian import freeze so groovy is still on 4.99.12+dfsg+really4.23.0-1 - and syncing 5.2.0 now, so late in the cycle, requires an approved Feature Freeze Exception [1], since we're also past feature freeze. It's a very very unfortunate time, since Final Freeze for groovy is tomorrow, and we're a bit reluctant with accepting risky pieces. The 'good' news is, calibre is only seeded in our Ubuntu Studio flavor, so the impact should be manageable. I would like the Ubuntu Studio flavor representatives to chip in and (maybe) help out with the paperwork there. Once we have it in groovy+ we can look into backporting it to focal. This requires filling in some SRU paperwork as per the policy [2]. What makes it a bit problematic from the SRU perspective is that the debdiff between 4.99.4+dfsg+really4.12.0-1build1 (in focal) and 5.2.0 is 7600433 lines long. Looking at the diff itself, most of it are translation changes, but still... it's quite a change nevertheless. The things that need to be thought of before performing the backport: * How badly is calibre broken on focal right now? Is it really unusable in its current state? Examples of how broken things are so that we can understand the situation better * How does the automated test coverage on calibre look like? Do all new features come with unit testing? What about autopkgtests (I don't think I see any?)? * What would be the acceptance criteria for the new version? What testing should be performed to make sure the new version works as expected and doesn't regress any existing users (assuming calibre in focal right now is at least usable to some extent) If needed, we can help a bit with some of the SRU bits. Cheers, [1] https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_upstream_versions [2] https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template On Wed, 14 Oct 2020 at 10:20, Norbert Preining wrote: > > Dear all, > > (please Cc) > > I am the Debian maintainer of Calibre, and unfortunately it seems that > for Focal Ubuntu has pulled a preliminary version of Calibre, which is > **seriously** broken and unusable, not even starting in most cases. > > We were forced by the Python3 transition to temporarily ship pre-release > versions of Calibre. In particular, Ubuntu Focal ships > 4.99.4+dfsg+really4.12.0-1build1 > which is version 4.12 with experimental Python3 patches on top of it. > This worked for a short time being until Calibre 5 was released with > proper Python3 support. > > Due to this unfortunate squeeze in release timing, Ubuntu Focal users > now have a seriously broken Calibre, and upstream is swamped with bug > reports. > > I would strongly suggest and support, and help preparing, an update to > Focal based on the current version in Debian/testing, 5.2.0+dfsg-1, > which has been out since quite some time and field-tested with Python3 > in various environments, due to upstream having switched to Py3, too. > > Is the above (update to 5.2.0) possible in Ubuntu Focal, and if yes, > what kind if steps are necessary? > > Note that I am not an Ubuntu developers, but Debian developer and > maintainer of Calibre. > > Thanks and all the best > > Norbert > > -- > PREINING Norbert https://www.preining.info > Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Groovy Gorilla (20.10) Beta Freeze
As of a short while ago, groovy has entered the beta freeze, with a goal of releasing Beta images sometime late Thursday. *From now until the beta is released, please only upload updates for packages on any release images if you /need/ to get them into the beta itself.* Please hold off with everything else until after we release on Thursday. The queue freeze will last from now until final release in October, which means that all seeded packages will now need a spot-check and review in the queue from a release team member before they are let into the archive. As with the previous releases, we have a bot in place that will accept uploads that are unseeded and don't affect images. Don't take this as an open invitation to break Feature Freeze on those components, this is just to reduce the burden on the release team, so we only review the uploads that need very serious consideration. If you find the bot is blocking an upload that you think should have been auto-accepted, let us know and we'll sort it out. We will be spinning a set of beta candidates most probably tomorrow morning EU time, after the last few changes have migrated into groovy (one of which is the kernel). We then encourage people to do ASAP for their favourite flavour(s) as they come off the line. Happy bug-hunting from now until the final release, and please do help out and test ISOs, netboot, etc, where you can and let us know what's broken in your environment(s). On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Groovy Gorilla Beta milestone reminder
Hello everyone! Yes, time flies! This is a gentle reminder about the nearing Beta milestone for Groovy Gorilla (20.10) next week and the also-related Beta Freeze starting on Monday. Please use the occasion to make sure everything is landed and good to go for next week. Thank you! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: Sponsorship of fix for OpenVDB package in focal
Hello Richard, First of all thank you for your contribution! I have now added an 'affects focal' to the bug which will probably make things a bit clearer regarding what needs to be done. Currently, as far as I know, the sponsorship queue doesn't have a dedicated rotation so sometimes it might take a while before a sponsor notices the change and performs action. That being said, with the bug targeting focal as it should, it's more probable to happen sooner than later. If time allows, I'll also try to take look and see if I can help out. Cheers, On Mon, 21 Sep 2020 at 14:18, Richard Viney wrote: > > Hi, > > I'm a new contributor attempting to get an issue with focal's openvdb package > fixed. The original bug report is here: > https://bugs.launchpad.net/ubuntu/+source/openvdb/+bug/1882998 > > I've done everything I can see for the SRU procedure, i.e. filling out the > issue template, doing a debdiff for the change, and subscribing > ubuntu-sponsors to the bug. > > However, it's been a couple of weeks and I haven't had any response, so I'm > wondering if the problem is that the original bug has already been tagged as > "Fix Released". It's true that a fix has been released, but only as part of > groovy, not as an update to focal, and my aim is to get this regression with > openvdb fixed in the current LTS if at all possible (for the reasons outlined > in the bug report comments). > > Is there anything further I can do to help move this along? > > Thanks. > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Bileto and RiscV64
I think the problem here is the general Bileto architecture, where autopkgtests can only be triggered when all arch builds are finished and 'diffed'. But if there are no objections, I could maybe change Bileto to not care about riscv when performing checks, maybe besides the final publishing step (in case someone wants to do Bileto publish to the archive). On Thu, 27 Aug 2020 at 16:28, Balint Reczey wrote: > > Hi, > > On Thu, Aug 27, 2020 at 1:44 AM Steve Langasek > wrote: > > > > On Wed, Aug 26, 2020 at 06:00:58PM -0300, Andreas Hasenack wrote: > > > Hi, > > > > > The builders for riscv64 are very slow, and since bileto wails for all > > > builds to be ready, each ticket can take dozens of hours. Even if I > > > disable that arch in the ppa (via a #webops request), bileto later > > > enables it again. > > > > > Could we do one of the following: > > > - disable riscv64 by default on bileto, and make it so it can be > > > enabled (and remain enabled) in the ppa if the user so wants it > > > - start bileto tests as soon as an arch build is ready, instead of > > > waiting for them all to be ready as it is today > > > - something else I haven't thought of :) > > Internally we already had discussions about disabling tests in riscv64 > builds to speed them up. > https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1891686 > > As I understand it got a green light, just no one uploaded the fix yet. > > Cheers, > Balint > > > > > I mean, the other alternative is to not use bileto, which is not part of the > > normal workflow and results in duplicate tests anyway? > > > > > I know we want to have packages working on riscv64, but since it's not > > > blocking migration in the real archive, it seems unfair that it blocks > > > bileto so much. > > > > It is possible that updating the britney instance used for bileto to match > > the current code used for -proposed would address 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 > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > 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 -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- 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
Hello! I have just finished my second Ubuntu +1 maintenance shift. There have been some ups and downs again, with quite a few private-life interruptions, but in overall I think it was okay. For the most of it, I was trying to resolve issues mentioned on the +1 maintenance status page [1] - from the "Ongoing transitions" section. In there I have marked those that have been hopefully dealt with and should now migrate, though this won't be instantly visible as the arm64 and s390x autopkgtest queues are quite full. An overview of things that I worked on: * Looking into the pcs and python-tornado autohint. Thought of an easy way to push this through, but it requires a new mitmproxy upstream version (or cherry-picks for new tornado support) to proceed. There is a bug in Debian about it. * Sponsored gummi per maintainer request. * python-traceback2 migration/transition: situation still not resolved in Debian - discussions still in progress. Pushed a new unittest2 and python-funcsigs to unblock from our side. Hopefully everything should migrate now. * Looked into the yara transition. Was confused why Steve's new libguestfs was not pulled in by the autohinter so I added an easy hint for it - only then noticed that it's because libguestfs still wasn't a valid candidate (due to autopkgtests + the riscv64 build). Duh. * nitrpc micro-transition: nfs-ganesha was FTBFS. Investigated the new version in Debian, checked for any Ubuntu-specific changes that might be needed. Synced and hopefully things should migrate once built. * nautilus-python migration/transition: python2 removal, stuck due to some reverse-depends. Adjusted deps of nautilus-owncloud and gnome-shell-extension-gsconnect, converted folder-color to python3 (wanted to delete at first, but then ubuntu-mate has it in its supported seed). Should migrate once built. * Sponsored new initramfs-tools-devices for the HWE team. * pycryptodome migration: promoted the python3-sphinx-rtd-theme binary to main, as the source and all its dependencies were in main already. * Some NBS cleanup work. * Looking at autopkgtests for a few packages. Things to hand off: * pcs and python-tornado are still stuck in -proposed. Maybe someone should just take a look at the PR from #959180 [2] and cherry-pick that to the Ubuntu mitmproxy package to unblock it on our side? * I started looking at python-opengl NBS. This might be just fixed by syncing a new debian-games from Debian, but we'd need to see if the Ubuntu debian/control changes are still needed (and if yes, merge instead). * Making sure the above listed small transitions are indeed good and migrate after all builds and tests finish. Hopefully the next shift will be more productive. Cheers, [1] https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959180 -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- 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 (18th and 19th of May 2020)
Hello everyone, This cycle, a few of our teams (Foundations, Desktop and Server) are trying something new by reintroducing the +1 Maintenance idea [1] - but with a 'twist'. We will be rotating a dedicated staff of people for this purpose every week, each person spending most of his work-time doing +1 maintenance when on the 'shift'. From the Foundations team I was the first one in the rotation, working on the Ubuntu archive on Monday and Tuesday. Matthias will be taking over tomorrow and doing his shift for the next 2 days. At the end of each of our 'shifts', we will be sending out a report e-mail like this one to the ubuntu-devel ML. Those will serve the purpose of 'work handoff' messages, so that the next person in rotation (for the team) knows what other tasks are still pending (like, if a transition is still ongoing etc.). At first we will also include a quick summary of 'what has been done' during every shift, but we'll be gradually moving away from that (as it eats up a lot of time that could be used for actual +1 maintenance!). But for now we want to do that as it might be a good way of introducing new people to what general work items are part of the role. Please note that the format of these might change. So, whenever not in meetings (sadly there was quite a few), I spent most of my time working on packages in groovy-proposed and their migration. A very short summary: * python-apt migration: checked failing apt-clone ADT tests, retriggered, now migrated * pyyaml migration: blocked on removal of the python2 python-yaml, had to remove llvm-toolchain-7, uec-provisioning, pushed new python-jujuclient removing the python2 version. Required some packages moving out of -proposed. Cleaned up NBS, package now migrated * Worked a bit on the re2 migration, then noticed that it's entangled in the protobuf transition. Ultimately tumbleweed and vorlon pushed it through * requests migration: investigated failures, pushed through * dtfabric migration: hinted s390x test failures as they never really passed before, migrated * make-dfsg migration: tests needed retriggering, migrated * python-mock migration: same, migrated * ntirpc migration: package did not migrate due to the nfs-ganesha rdep requiring a rebuild * ucf migration: looked into the bacula failures, was able to reproduce the issue in a local test run with ucf updated - works fine on the release version. Didn't manage to resolve yet * NBS cleanup: did some NBS sweeping, working on a few * Looked briefly into python-dmsh migration, left in the hands of Matthieu who is also looking at it actively * Pulled the apt 2.1.3 version from groovy-proposed * Started to look at python-traceback2 migration - python2 package removal, needs actioning Things that still need work: The python-traceback2 package needs some python2 removals for it to migrate, someone could take a look at that further. And might be nice to poke someone to get the libjs-mathjax MIR reviewed. Best regards, [1] https://wiki.ubuntu.com/PlusOneMaintenanceTeam (wiki page still need updating) -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu Core Developer - Lucas Kanashiro
Hello everyone, I am pleased to announce that Lucas Kanashiro (kanashiro) - after his successful application on today's DMB meeting, has now officially joined the Ubuntu Core Developer team! Congratulations! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Groovy Gorilla is now open for development
We’re pleased to announce that groovy is now *open for development*. auto-sync has been enabled and will run soon. As usual, we expect a large influx of builds and autopkgtests in this initial period, which will cause delays. Please help with fixing any breakage that occurs. For this release we're moving a few of our live documents over to Discourse from the Ubuntu wiki. We have a draft release schedule: https://discourse.ubuntu.com/t/groovy-gorilla-release-schedule/15531 for discussion (please reply to this email with any concerns). A few of us had a conversation a little while ago, where we talked about how we could improve communication around archive-wide changes so that other developers are aware when there is planned disruption in the archive. So if you are planning something which might have a disruptive effect on the archive (e.g. potential to cause build failures), please add it to the second table in the above link. There's also a skeleton of what will be the release notes https://discourse.ubuntu.com/t/groovy-gorilla-release-notes/15533 which we’re also moving over to Discourse. For both of these, redirects from the old locations on the wiki should be set up already. Cheers, happy grooving! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Groovy Gorilla is now open for development
We’re pleased to announce that groovy is now *open for development*. auto-sync has been enabled and will run soon. As usual, we expect a large influx of builds and autopkgtests in this initial period, which will cause delays. Please help with fixing any breakage that occurs. For this release we're moving a few of our live documents over to Discourse from the Ubuntu wiki. We have a draft release schedule: https://discourse.ubuntu.com/t/groovy-gorilla-release-schedule/15531 for discussion (please reply to this email with any concerns). A few of us had a conversation a little while ago, where we talked about how we could improve communication around archive-wide changes so that other developers are aware when there is planned disruption in the archive. So if you are planning something which might have a disruptive effect on the archive (e.g. potential to cause build failures), please add it to the second table in the above link. There's also a skeleton of what will be the release notes https://discourse.ubuntu.com/t/groovy-gorilla-release-notes/15533 which we’re also moving over to Discourse. For both of these, redirects from the old locations on the wiki should be set up already. Cheers, happy grooving! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: stable/ubuntu-20.10 snap channels (lxd, ?) (Re: groovy pre-open analysis)
Yeah, it's part of the new-series checklist to inform the right people to create those snap channels. I have now sent e-mails with reminders to the right people. On Sun, 26 Apr 2020 at 21:36, Julian Andres Klode wrote: > > On Sun, Apr 26, 2020 at 02:17:34PM +0200, Julian Andres Klode wrote: > > I did some work to get python-apt in with groovy added to the > > distribution metadata, so we don't end up with a lot of regressions > > like last cycle. > > > > * Various packages needed retrying with new debootstrap, as they > > missed the groovy link: > > > > - retried piuparts with [python-apt, debootstrap] triggers > > - retried livecd-rootfs with [python-apt, deboostrap] triggers > > lxd needs to have a stable/ubuntu-20.10 channel, I guess some other > snaps too, this is currently breaking livecd-rootfs on armhf (the > other ones ran earlier and still downloaded 20.04): > > error: cannot download snap "lxd": no snap revision available as specified > If the channel (stable/ubuntu-20.10) includes '*/ubuntu-##.##' track per > Ubuntu policy (ex. stable/ubuntu-18.04) the publisher will need > to temporarily create the channel/track to allow fallback during > download (ex. stable/ubuntu-18.04 falls back to stable if the > prior had been created in the past). > > I feel like we need to automate more of this stuff. > > -- > 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 -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Focal Fossa Beta milestone delayed
The image building issues have now been resolved and all the new Beta isos are now built and ready to test [1]. Please pick up your favorite flavor and resume testing as soon as possible. Thank you! [1] http://iso.qa.ubuntu.com/qatracker/milestones/411/builds On Fri, 3 Apr 2020 at 01:05, Lukasz Zemczak wrote: > > We have encountered some issues while building candidate images for > the Ubuntu 20.04 LTS Beta and are forced to delay the release of the > Beta milestone until we get those sorted out. As soon as we have > candidate images available we will let you know. We are sorry for the > inconvenience. > > On behalf of the Ubuntu Release Team, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Focal Fossa Beta milestone delayed
We have encountered some issues while building candidate images for the Ubuntu 20.04 LTS Beta and are forced to delay the release of the Beta milestone until we get those sorted out. As soon as we have candidate images available we will let you know. We are sorry for the inconvenience. On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Proposals] Consult with Flavor Leads before Beta Freeze / Flavors Underrepresented
Hello Erich! Sorry to hear that you are not satisfied with the release process so far. The last thing I, and possibly all other release team members, would want is for flavors and flavor leads to feel underrepresented and ignored. With most releases (point-releases) I tend to always check with flavors if they are satisfied with the current state-of-things before proceeding, which I might have not done explicitly yet, mostly due to the fact as we did not build candidate images just yet. The Beta Freeze is not a hard-stop, and the release team always makes sure to keep track of what lands in the queues, keeping an eye out for any important packages that might be needed for the milestone. Feel free to consult any of us whenever you, or anyone else, feels that there is an upload still missing. I agree with Steve's position here. Even though as you said, the world does not revolve around Ubuntu, being part of the Ubuntu family we all follow the same strictly time-based release schedule. Sometimes there are slips, sometimes there are slides, but generally we all try to strictly follow the schedule, at least to some extent. The dates are well known and we try to communicate the incoming freezes, sending reminders. Delaying a freeze is possible, but would need good reasoning for that to happen - as a delay here can cause the delay of the milestone release date. Which means the delay of all flavors involved. We are all tightly bound together, so we need to work together, considering the well-being of everyone. As Steve mentioned, Beta Freeze is not yet the final call. If you still need something critically in for Beta, please upload and give us a sign through any available media. We trust you, and trust that you know best what is needed for your flavor to shine. Please remember that handling Ubuntu releases is *hard*. Ubuntu is a big project with lots of wonderful flavors. We try to make sure that we consider all the flavors equally, but it's not always possible - there's always so many moving parts that it's a non-trivial task. But most important of all: if at any moment you feel that your concerns or your flavor's voice is ignored and you think you are not treated equally, please give us a sign. Tell us what's wrong. We will try explaining ourselves and then try to make it better. Feel free to tell us of the situations when you thought that some other flavor had more of a voice than yours either here or privately. What I generally mean: we'll try to continue and improve our ongoing communication with flavor leads all the way, but just feel free to reach out to us directly yourself. With anything. Keep us in the loop! Cheers, On Tue, 31 Mar 2020 at 07:46, Steve Langasek wrote: > > Hi Erich, > > On Mon, Mar 30, 2020 at 04:18:07PM -0700, Erich Eickmeyer wrote: > > I have a package (carla) for which I have PPU upload rights for that I > > have been working with the upstream for getting a release today. Despite > > this, the upstream developer could not meet this deadline for their > > release, which is really not their problem as the application isn't > > necessarily developed for Ubuntu specifically (the world doesn't revolve > > around Ubuntu). This is a bugfix release being prepared (carla-2.1-rc2, > > with carla-2.1-rc1 already in the archives) in preparation for a final > > release mid-April prior to Final Freeze. > > > Unfortunately, beta freeze came without any discussion as to if the > > flavors were ready for this freeze, and now flavors must rely on a small > > group of developers (the Release Team) to approve any last-minute, > > intended-for-beta uploads. With carla being a release candidate, it is > > perfect for beta testing in preparation of that final release, not only > > for carla, but for Ubuntu. > > > Additionally, carla is a seeded package in Ubuntu Studio. > > > [Proposal 1] > > > > I believe that the release team needs to check with the flavor leads > > prior to enacting the beta freeze, just to make sure there are no > > last-minute intended-for-beta already-seeded packages preparing for > > upload. A good way would be checking with the flavor leads either in > > #ubuntu-flavors or on #ubuntu-release (which many, if not most, are > > monitoring). I think this is important especially for packages in the > > archive that are in beta or release candidate status that have an > > imminent bugfix or final release from an upstream. > > Speaking with my Release Team hat: we do time-based releases, and the dates > are known well in advance. The manual process of the Release Team approving > exceptions to the milestone freeze exists because we know not all seeded > packages, across all flavors, are going to be ready for beta at the start of > the freeze. Nevertheless, a freeze is necessary to impose control over the > set of changes going into the milestone preparation. > > In this case, you want the carla package to be included in the beta. But > you probably wouldn't appreciate it if some
Focal Fossa Beta milestone reminder
Hello everyone! This is a gentle reminder about the nearing Beta milestone for Focal Fossa (20.04) next week and the also-related Beta Freeze starting on Monday. Please use the occasion to make sure everything is landed and good to go for next week. We're so close! Thanks! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: Staging changes for future SRU landings
Currently sru-report shows the block icon for both block-proposed and block-proposed-SERIES. Seeing that block-proposed is indeed devel-specific, I think it makes sense for us to only block SRU uploads on the -SERIES tag. I can switch that in a moment if there's an agreement on that in the SRU team. If we +1 on that, I'll make sure to add the SERIES tags to all current block-proposed SRU uploads that should be blocked for the given series in the -proposed pockets. Cheers, On Thu, 29 Aug 2019 at 10:48, Colin Watson wrote: > > On Thu, Aug 29, 2019 at 10:33:37AM +0200, Julian Andres Klode wrote: > > On Thu, Aug 29, 2019 at 03:59:04AM +0100, Colin Watson wrote: > > > On Wed, Aug 28, 2019 at 07:41:10PM +0200, Matthias Klose wrote: > > > > afaiu block-proposed tags on bugs are not specific to any series, so > > > > you are > > > > blocking updates across all series. Not really desired. > > > > > > block-proposed is in fact specific to the current development series. > > > block-proposed-$SERIES exists and should work here, though. > > > > block-proposed seems to work across all series. look at > > > > https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1813581 > > > > and > > > > https://people.canonical.com/~ubuntu-archive/pending-sru.html > > > > and you see the blocked icon for the bionic SRU, but the bug > > has block-proposed set, not block-proposed-bionic. > > Sounds like there's a disagreement between proposed-migration and > sru-report. > > -- > Colin Watson[cjwat...@canonical.com] > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: StableReleaseUpdates page (Was: Re: Fw: [scite] Fixed Lua dynamic library loading in Ubuntu 18.04 proposed updates)
The wiki page in the paragraph regarding SRU testing might indeed not be entirely realistic, but it is the *recommended* way of going forward. With my SRU hat on, I personally would never reject someone's SRU verification just because the person performing it was the uploader. Sure, bonus points if the verification is done by the reporter or some unrelated person, but most of the time the uploader is the best we can get - as you already mentioned. I wouldn't rephrase the sentence though, as ideally we would want it to be done by someone else. But as I always understood it, it is not a strict requirement. What matters to me is that someone took the time to take the actual -proposed package, installed it and ran through the test case. If I see that's the case via the bug verification comment (and have no doubts whether the verification was actually performed) and the reporter doesn't seem to be 'involved', it's all good. Sometimes I do request verification to be done by the person that has reported the bug, but only if I see recent activity of that person on the bug. Doesn't happen very frequently though. Cheers, On Mon, 19 Aug 2019 at 22:06, Julian Andres Klode wrote: > > On Mon, Aug 19, 2019 at 09:34:07AM -0700, Bryan Quigley wrote: > > Nope, that's not the standard, expected procedure. It is always better to > > have someone else verify a fix, it's sometimes not feasible though. > > > > "While not ideal it is also possible for the uploader of the fix to perform > > the verification of the package in *-proposed" > > - https://wiki.ubuntu.com/StableReleaseUpdates#Verification > > > > OK, first of all - he SRUed that package in May. > > And re the The wiki page: It might say that, but it's _not_ realistic: > > - I've uploaded quite a few SRUs by now, and maybe a handful have been > (partially) > verified by someone else. Partially because these people only test their > favorite release (and then forget to do some tagging changes, or mention > version numbers), so you still have to do it anyway. > > In practice, people report bugs, and when you push a fix they are gone. > > Waiting days, weeks, or even months so that maybe hopefully someone else > might review it does not work. > > Other random things the wiki page says and people do wrong all the time: > > - Basically everyone sets their tasks to "In Progress" when working > on it, despite "In Progress" being reserved for "fix uploaded to queue". > > - People set "Fix committed" when/before an upload, despite it being > reserved for "fix in -proposed" > > > -- > 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 -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu Core Developer - Thomas Ward
Hello everyone, Please congratulate teward on his today's successful core-dev application! Welcome to the team! Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New ubuntu-budgie packageset uploader - David Mohammed
Hello everyone, Please congratulate David on his successful ubuntu-budgie packageset uploader application! He will be added to the packageset as soon as possible. Congrats! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu SRUs: autopkgtest regression handling, MRE distro changes warning
Hello everyone, Sending out this e-mail on behalf of the Ubuntu SRU team to give some information regarding two SRU policies: clearing out some confusion regarding autopkgtest regressions and a heads up about distro-affecting changes in MRE-covered uploads. It's mostly relevant only to those of you that have upload rights and prepare SRUs on daily basis. 1. Autopkgtest Regression Handling As most of you know (at least those that uploaded SRUs to stable series), most SRU uploads trigger autopkgtests the same way as it happens for uploads to the devel series. We, as the SRU team, require the autopkgtest situation to be 'clean' before considering releasing an update from -proposed to -updates. Whenever the SRU report page [1] lists an ADT regression for the given upload and we have not been provided rationale of why the regression appeared, we will usually *not* take any action on the package. We generally require the autopkgtest regression situation to be resolved before any action can be performed. No upload to the stable series should introduce regressions: doesn't matter if it's one found manually or through automation. We'd generally like to treat manual and automated testing the same way. It is well known that many autopkgtest regressions reported for selected uploads can be unrelated to the actual SRU, usually by being already broken in the -updates pocket. This is actually a very frequent case in the SRU world. In such cases, the uploader (or the package validator, if having enough context) is responsible for checking the autopkgtest regression and making sure the reported failures are not caused by the uploaded SRU. The rationale for that should be provided to the SRU team - best if done as a bug comment on at least one of the bugs attached to the SRU. Once an SRU member that's handling the update sees the rationale and is convinced by the analysis provided, we will create a badtest hint for the failure and proceed with releasing of the update per usual process. The uploader can of course also make the hint change, propose a merge and include the MP link in the bug as part of the rationale, but that is *not* a requirement from our side. Please remember that resolving autopkgtest failures this way requires the uploader providing convincing argumentation and analysis of the failure. It's not just a game of blindly hinting issues on gut feeling only. In case where the reported regression is a real regression, this results in the upload becoming verification-failed and requiring a new upload with the regression fixed. Just like with regular regressions. I have updated the StableReleaseUpdates [2] policy document adding a section about Autopkgtest Regressions, but we'll probably still have to iterate on the wording of that. 2. Minor (Stable) Release Exception covered uploads and distro-affecting changes This one is still a bit fresh and still not entirely part of the official policy, but will become one once we get it formally worded. It's more of a heads-up about what's coming, although we'd like all MRE uploaders to start considering this as soon as possible. Please forgive me if things sound a bit wavey for now. During our last SRU team meeting we had in Malta, in light of some recent regressions in packages that are covered by MRE's (to those that don't know: exceptions allowing new upstream releases on special terms), we have decided to request some additional information for SRUs of this type. Since new upstream release uploads can be really hard to review due to the amount of code changing (as for new minor or even major versions being pulled in), this creates additional risk of regressions that could have been potentially caught during a regular SRU review. Because of that, we would like to ask uploaders of such packages to document any changes to the interaction of the package with the distribution. We're still working on a formal definition of those changes, but it's something like: any systemd unit changes visible from the distro side, interaction with other services etc. This is so that we, as the SRU team, can have more context on what is the rationale for the selected changes and possibly helping out in us making sure the new upstream version would not regress after landing in the archive. Such changes would be required to be stated in either the SRU tracking bug or, in case of bigger changes, in a separate bug attached to the upload. As said, we still have to officially formulate the ruling, but we'd appreciate your cooperation even now. When preparing your new upstream version upload, think about how the new upload changes the way the package interacts with the system and try documenting that in the tracking bug. So that's basically it. As a final word I'd like to thank all you brave uploaders that fix bugs in stable series and make sure they're up-to-date. Let's continue working together on making Ubuntu stable releases shine! Cheers, [1]
Re: [Ubuntu Wiki] Update of "StableReleaseUpdates" by xnox
Hey Dimitri, On Thu, 4 Apr 2019 at 15:59, Dimitri John Ledkov wrote: > > Hi all, > > On Thu, 4 Apr 2019 at 14:26, Lukasz Zemczak > wrote: > > > > I would also prefer not to see those in the description, especially > > that we'll have automated bug comments on autopkgtest regressions > > soon. > > > > That being said, I don't think someone not part of the SRU team should > > be editing the SRU tempate without discussion with the SRU team. Can > > we get this change reverted and at least have a discussion started > > about it? If we allow anyone updating the SRU process as they see fit, > > soon we'll have no official documentation and more people will be > > confused. > > > > The SRU template was started by me, out of experience of having many > of my SRU uploads either linger in unapproved or getting rejected over > repeating reasons. It has improved velocity and quality of the SRU > process as experienced by the submitters. I have no idea if the SRU > team likes the template or not, as it's neither mandatory nor required > to be used, although many SRUs do use it. I have not been around in the early SRU team years, so I don't know who was the original author of the template. One thing I know for sure is that we, the current SRU team, are pointing people to the StableReleaseUpdates wiki page's SRU template whenever the paperwork is insufficient. This means that one way or the other, this became the de-facto standard for SRU paperwork, so at least currently changes to it shouldn't be made without consultation. Especially that for most people, this is the only thing they read, copy-pasting the template and editing it in place, not necessarily reading the other parts of the wikipage. Besides, since it's on the page where the official documentation is present, how can someone know that this particular part of the document is less official because it's somehow isn't under the guidance of the owning team? That wouldn't make sense to me. > > The autopkgtest rergressions section is added by me, based on the > observation that many SRUs in verification-done state are neither > getting released nor getting any comments from neither submitters nor > the SRU team members. I also observed that this often happens when > there are autopkgtest regressions of the reverse triggers, and at the > moment there is no documentation on doing hints merges, nor automatic > notifications to the bug reports about them. I also observed that many > SRU submitters are proactively documenting autopkgtest regressions and > that their SRUs are getting released by the SRU team members faster, > than the other uncommented aging verification-done SRUs. So we will be having automated bug comments on autopkgtest regressions, this is something that already has an MP but just needs a final tweak before getting merged. As for autopkgtest regressions per-se. So I don't know what experiences you had, but generally what the process here is that, as with any upload, the uploader is responsible for making sure the autopkgtest situation is clear. What I mean by that is, the uploader should look at the regressions for their landing and act on those whenever possible. I guess this might need some formal-defining on the wiki page, but generally this means that the uploader checks for regressions, checks if they're real regressions or not, retries if he thinks it's a transient issue. In case where the test regressed in release or should be hinted one way or another, I personally never ever requested people to submit hints by themselves (as MPs or diffs or whatever). I know for the devel series there were some discussions to make that the 'official' way of getting hints into the release, I don't know of anything like that for SRUs. What I personally want is for the uploader to mention the ADT regression situation in the bug as a comment, possibly part of the verification or following the verification. It is then generally my responsibility as the SRU team member to submit the hints when they are necessary. For me at least, so far this worked. Whenever I see a verified upload with lots of ADT regressions, I always open up the bugs and check the latest comments for any leads regarding autopkgtest regression verification. If I see some and agree with the verification, I commit hints for the issues and release (there are really rare cases where I don't commit hints, but those are like 5% of all the cases). Sure, we weren't really strict about applying hints, but on the Malta SRU meeting we have put a strict rule on hinting anything we want to 'let through'. > > Thus the addition of this section, is merely a reflection of the > currently best-known way (which is proven to achieve the intended > result) to get an SRU released as seen performed by multiple people > across foundations, server,
Re: [Ubuntu Wiki] Update of "StableReleaseUpdates" by xnox
I would also prefer not to see those in the description, especially that we'll have automated bug comments on autopkgtest regressions soon. That being said, I don't think someone not part of the SRU team should be editing the SRU tempate without discussion with the SRU team. Can we get this change reverted and at least have a discussion started about it? If we allow anyone updating the SRU process as they see fit, soon we'll have no official documentation and more people will be confused. On Thu, 4 Apr 2019 at 14:33, Robie Basak wrote: > > Hi Dimitri, > > Thank you for updating the wiki - I appreciate your efforts in making > process clearer and helping to streamline SRUs. > > On Thu, Apr 04, 2019 at 12:19:39PM -, Ubuntu Wiki wrote: > > + [Autopkgtest Regressions] > > + > > + Once this package is accepted in proposed, use this space to > > + explain autopkgtest regressions as seen on pending-sru page, and > > + proposed migrations output for releases in question. Proposed > > + migrations output page, has also retry buttons to rerun the tests. > > However in this particular case I'm not sure I want an explanation in > the bug. What I'd like instead is the pending-sru report clear of > autopkgtest regression reports, and for the explanation to be in the > commit message against the hints branch that cleared it through. > Otherwise it's work for somebody to explain it in the bug and more work > for an SRU team member to then create the branch, copy the explanation > into a commit message, merge, etc. > > Instead of having those driving SRUs explain in the bug description, > wouldn't we be better guiding them towards submitting an MP against the > correct hints branch, and putting their justifications in that MP > instead? > > For those not familiar with process and volunteering as best as they > can, I'd be happy to do this for them. But in the general case of Ubuntu > developers who can file MPs, I think I'd prefer them to just file the > MPs. > > The MPs could even be linked to the affected SRU bugs, so it'd be clear > to an SRU team member reviewing via bug that outstanding hints MPs exist > that claim to clear false positives. > > Robie > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New PPU uploader - Erich Eickmeyer
Hello! More good news! Please congratulate Erich his successful PPU uploader application as well! Once the ACLs are applied, Erich will have upload permissions to the following packages: carla grub2-themes-ubuntustudio ubuntustudio-controls ubuntustudio-default-settings ubuntustudio-icon-theme ubuntustudio-installer ubuntustudio-look ubuntustudio-menu Cheers! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New PPU uploader - Ross Gammon
Hey everyone, Please congratulate Ross on his successful PPU uploader application! Once the ACLs are applied, Ross will have upload permissions to the following packages: carla grub2-theme-ubuntustudio ubuntustudio-controls ubuntustudio-default-settings ubuntustudio-icon-theme ubuntustudio-installer ubuntustudio-look ubuntustudio-menu ubuntustudio-meta ubuntustudio-live ubuntustudio-lightdm-theme calf-plugins debian-multimedia gramps lmms pmidi qxgedit sfarklib sfarkxtc Cheers! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: 18.04.2 is coming
Hey Seb! Since I am not driving the release, for now let me answer the question of the language pack updates. Those went into -proposed last week so are in progress and the testing deadline passed basically an hour ago (there were two call-for-testing e-mails on the translation ML). You can see all details regarding that here: https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA Sadly, as with previous point releases, there was not too many languages tested, but better those few than none. I will be releasing the verified ones a bit later today. Cheers, On Wed, 30 Jan 2019 at 16:25, Sebastien Bacher wrote: > > Hey there, > > I feel like there isn't much communication around incoming Ubuntu LTS > point releases nowadays which makes it easy to miss the target. I don't > know if it's only me but hopefully others also find this email useful. > > So first, for those who don't pay attention to the bionic schedule, > Ubuntu 18.04.2 is due on february 7th, now is probably time to > land/verify the fixes you care about! > > Then some questions > > * are we still on track for that date? > > * when do we need to get the SRUs in proposed and moved to -updates to > be on the image? (having a freeze date on the schedule would be useful) > > * do we have a list of "things that need to be in" somewhere? Looking at > the current queues (packages in unapproved or waiting verification in > proposed) and talking to some people we have teams who real care to get > at least those in > > - snapd 2.37.1 (just landed in proposed, > https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1811233) > - hwe/xorg update > (https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1798597) > - fwupdate (blocked in bionic/binNEW for some time, > https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1785165) > > (do we plan a language pack update?) > > Thanks for reading, hopefully we are not too late on the schedule to get > the important SRUs listed before still in > > 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 -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: uploading golang-1.10 everywhere
Thanks! If no one beats me to it, I will review those tomorrow during my SRU shift. Cheers, On Wed, 26 Sep 2018 at 23:22, Michael Hudson-Doyle wrote: > > > > On Thu, 27 Sep 2018 at 06:29, Jamie Strandboge wrote: >> >> On Wed, 26 Sep 2018, Michael Hudson-Doyle wrote: >> >> > Hi all, >> > >> > At the recent sprint in Brussels, there was some discussion of providing a >> > way >> > for packages in older Ubuntu releases a way to build with a newer version >> > of >> > Go. After some discussion with the security team, it was decided that it >> > made >> > sense to upload Go 1.10 (which is after all going to be supported as part >> > of >> > Bionic for 5 years) to the older releases. I'm mentioning this plan here >> > (a) >> > for awareness (b) to get the security team to publicly acknowledge their >> > agreement to the plan :) >> > >> > There is a bug to track the uploads: >> > >> > https://bugs.launchpad.net/ubuntu/+source/golang-1.10/+bug/1794395 >> > >> > All comments here or in the bug gratefully received. >> > >> This is fine with the security team (if it was a golang version that was >> in an interim release, that would be a different story, but we are >> already supporting this in bionic, so why not in earlier?). I commented >> in the bug too. > > > Thanks, I've uploaded golang-1.10 to the various UNAPPROVED queues now. > > Cheers, > mwh > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Inconsistencies in package versions for stable releases
Just a few cents from me as an SRU member. There is no 'inconsistencies' among the SRU team regarding versioning as there is no 'standard' way of versioning packages. Rejection of a package because of the versioning scheme, to me, is only a case of preference and can vary between SRU members. There is no standard that we're trying to force, and no SRU member should enforce that. We *recommend* the security team's versioning scheme as it's the most logical, but some of us also generally aim for consistency. So if a package already used a different scheme for the selected series or others, this is the way to go. Sometimes we accept a differently versioned package as a 'one-time-off' (e.g. ubuntu-report), or sometimes a package follows it's own, rather complicated, different release model (e.g. snapd). In my view the ubuntu-report scheme is the most invalid, but it has been accepted conditionally as the package was not targeted for backporting to anywhere else than bionic. I should have probably rejected it and re-uploaded with a more fitting versioning applied, as I did for a few others like this. But as I said, there generally is no standard we *need* to enforce, so as long as the version works - there's no requirement for rejection. We should keep advertising the security team's versioning as the best way to go, but right now - for what I can tell - there are no rules for that. Cheers, On 6 July 2018 at 06:15, Simon Quigley wrote: > Hello, > > This email is following several discussions I have had over the past few > weeks on how the versioning scheme of packages work with respect to > stable releases. > > It seems there is some inconsistencies with SRU team members accepting > different-versioned packages due to somewhat varied standards. Some > people say that the Security Team document on versions[1] is the > (lowercase c) canonical document on how things should be versioned, > while others just say "as long as the version isn't a problem." > > As someone who has had their packages rejected before because the > version did not match the former of the two preferences, I think it is > worth having a discussion on how we should do version numbers in a > uniform and agreed-on way. > > Here are some uploads that I would have probably seen rejected depending > on the SRU team member because of the version: > https://launchpad.net/ubuntu/+source/snapd/2.33.1+18.04ubuntu2 > https://launchpad.net/ubuntu/+source/ubuntu-report/1.2.0~bionic > https://launchpad.net/ubuntu/+source/shim/13-0ubuntu2 > > With snapd, it seems to be somewhat inverted from the typical case, > where Xenial gets the native package upload with no additions, Xenial+ > gets +XX.YY, and Trusty- gets ~XX.YY. > > With ubuntu-report, I have always been discouraged from using codenames > in the version number, because if, for some reason, we needed this in > Xenial, being consistent with the naming scheme wouldn't work: > > $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~xenial"; echo $? > 1 > $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~16.04.1"; echo $? > 0 > > This means we would have to be inconsistent across releases. > > With shim, I have also been discouraged from doing ubuntuX, as opposed > to ubuntuX.Y. In this case, I would have gone with 13-0ubuntu0.2. > > My objective in pointing these out is not that these versioning schemes > do not work, or to pick on any one package or person. My point is, they > lack consistency with the rest of the archive, and some of these do not > work in other cases where a variable has changed. Most importantly > though, I have observed varied tolerance among the SRU team for these > version numbers. > > Is the existing document by the Security Team[1] lacking any important > considerations? Can we adopt it as the uniform standard for updates in a > stable release, or is there a good reason to continue with inconsistency > here? > > Thanks. > > [1] > https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging > > -- > Simon Quigley > tsimo...@ubuntu.com > tsimonq2 on freenode and OFTC > 5C7A BEA2 0F86 3045 9CC8 > C8B5 E27F 2CF8 458C 2FA4 > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Bionic Beaver (18.04) Final Beta Freeze
In some short while bionic will enter the final beta freeze, with a goal of releasing the Final Beta images hopefully sometime late Thursday. The link to the milestone can be found here: https://launchpad.net/ubuntu/+milestone/ubuntu-18.04-beta The queue freeze will last from now until final release this month, which means that all seeded packages will now need a spot-check and review in the queue from a release team member before they are let into the archive. As with the previous releases, we have a bot in place that will accept uploads that are unseeded and don't affect images. Don't take this as an open invitation to break Feature Freeze on those components, this is just to reduce the burden on the release team, so we only review the uploads that need very serious consideration. If you find the bot is blocking an upload that you think should have been auto-accepted, let us know and we'll sort it out. We will be spinning a set of beta candidates [1] later today which we encourage people to get to testing ASAP for their favourite flavour(s) as they come off the line. Happy bug-hunting from now until the final release, and please do help out and test ISOs, netboot, etc, where you can and let us know what's broken in your environment(s). Be sure to target any milestone relevant bugs to the beta milestone whenever needed. [1]http://iso.qa.ubuntu.com/qatracker/milestones/388/builds On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Bionic Beaver (18.04) Final Beta Freeze
In some short while bionic will enter the final beta freeze, with a goal of releasing the Final Beta images hopefully sometime late Thursday. The link to the milestone can be found here: https://launchpad.net/ubuntu/+milestone/ubuntu-18.04-beta The queue freeze will last from now until final release this month, which means that all seeded packages will now need a spot-check and review in the queue from a release team member before they are let into the archive. As with the previous releases, we have a bot in place that will accept uploads that are unseeded and don't affect images. Don't take this as an open invitation to break Feature Freeze on those components, this is just to reduce the burden on the release team, so we only review the uploads that need very serious consideration. If you find the bot is blocking an upload that you think should have been auto-accepted, let us know and we'll sort it out. We will be spinning a set of beta candidates [1] later today which we encourage people to get to testing ASAP for their favourite flavour(s) as they come off the line. Happy bug-hunting from now until the final release, and please do help out and test ISOs, netboot, etc, where you can and let us know what's broken in your environment(s). Be sure to target any milestone relevant bugs to the beta milestone whenever needed. [1]http://iso.qa.ubuntu.com/qatracker/milestones/388/builds On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Bionic Beaver User Interface Freeze and nearing Final Beta reminder
This is a gentle reminder that Bionic Beaver (18.04) is in User Interface Freeze since last week (March 22th). Remember about that when uploading packages into the archive as any freeze-breaking changes per https://wiki.ubuntu.com/UserInterfaceFreeze need to have an ubuntu-release approved exception [1]. Also, since Final Beta is planned for next week already, remember about the nearing Beta Freeze on Monday. If you still have any high impact changes pending for 18.04, now is the time to upload. Thanks! [1] https://wiki.ubuntu.com/FreezeExceptionProcess -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Qt5 Uploader - Simon Quigley
Hello everyone, Please congratulate Simon on his successful Ubuntu Qt5 Uploaders application! Being part of the team, tsimonq2 now has upload rights to Qt5 packages in the Ubuntu archives. Cheers! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu Server Developer - Andreas Hasenack
Hello everyone, Let's congratulate Andreas on his today's successful Ubuntu Server Developer application! He has now been added to the ubuntu-server-dev team, gaining upload rights to Ubuntu server packages. Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu SRU Developer - Dan Streetman
Hello! After a successful vote on today's DMB meeting, we are pleased to announce a new member of the SRU Developers team - Dan Streetman. Congratulations! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
