New component-mismatches for source universe -> main
The following universe packages have new reverse dependencies in main or got seeded. They need to get a MainInclusionReport and be promoted, or the reverse dependencies in main need to be dropped: MIR: #1576812 (Won't Fix) [MIR] ipmitool Please see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt for the full report. Please contact https://launchpad.net/~ubuntu-archive for problems with this notification. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
openQA
On Tue, Aug 2, 2022 at 3:14 PM Aaron Rainbolt wrote: > The tool is called openQA. Quoting from the description of its package > in the Ubuntu universe repository: Some volunteers in Debian use openQA. Here are links with more information: https://debconf21.debconf.org/talks/31-openqadebiannet-automated-testing-of-debian-installer-and-beyond/ https://openqa.debian.net/ I believe the service is from openSUSE and is also used by Fedora. Thank you, Jeremy Bicha -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Ubuntu Studio 22.04.1 and Secure Boot
On Tue, Aug 2, 2022 at 12:39 PM Erich Eickmeyer wrote: > > On Tuesday, August 2, 2022 10:16:53 AM PDT Simon Quigley wrote: > > As for why this is coming up *now* in the first place, I don't have the > > slightest clue. In the year 2022, flavors need to at least smoke test > > *once*, *especially* for an LTS release, to ensure Secure Boot works. > > Look, I get it, flavor teams may be short-staffed, some more than > > others, but we really need to take a look at our QA processes as the > > Ubuntu project to ensure something basic like this is caught in every > > flavor. (Yes, I'm volunteering to write the ISO QA tests.) It's > > embarrassing, as a fellow Ubuntu Flavor RM, that something like this was > > not caught and brought to the attention of the Release Team > > *immediately*. This isn't personal, I'm not trying to roast anyone in > > particular, but come on everyone, we really need to do better here. I'll > > link Lubuntu's thorough test suite here[2], and I would suggest other > > flavors take our example. > > > [snip] > > [1] > > https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config#n132 > > [2] https://phab.lubuntu.me/w/release-team/testing-checklist/ > > > > This happened partially because of the transition from Xfce to KDE Plasma back > in 2020 and the subsequent transition from Ubiquity to Calamares since > Ubiquity's KDE modules are hard-coded for Kubuntu's branding. Ubiquity has the > necessary facility to handle interfacing with mokutils and creating a MOK, > whereas Calamares does not, and this was missed during the Ubuntu Studio > testing. And yes, your analysis of Ubuntu Studio lacking the manpower and > resources to test every scenario of installation is correct. We're just not > popular enough to attract the willing participants to want to help test. > > Additionally, I tested on real hardware. I was unaware, until recently, that > my own hardware that I was testing on did not have secure boot enabled. This > was a mistake on my part and I own this mistake. > > However, I will say that Calamares not having a facility for MOK is quite a > shortcoming and also prevents the installation of drivers such as Nvidia > drivers, which is something that Ubiquity can do. This makes other installers, > such as Ubiquity and even the new flutter-based installer more attractive all > the time for use cases like Ubuntu Studio, where advanced graphics processing > is paramount for video production, photography, and graphics design. This, > however, is a digression and probably worthy of a separate discussion. > > -- > Erich Eickmeyer > Project Leader - Ubuntu Studio > Member - Ubuntu Community Council-- As an avid user of both Ubuntu Studio and Lubuntu, I will be more than happy to help with the testing process for Ubuntu Studio in the future. I have the necessary hardware to do so painlessly, and we can just do a full Ubuntu Studio installation test any time something happens with Calamares that would warrant a Lubuntu installation test. In case it would be helpful for future testing, I would like to point out a new testing tool I discovered. It may work to reduce our testing workload immensely, for Ubuntu Studio, Lubuntu, and possibly even the larger Ubuntu ecosystem. The tool is called openQA. Quoting from the description of its package in the Ubuntu universe repository: > openQA is a testing framework that allows you to run tests on pretty-much > anything that you can get 'remote' control of (most often, anything you can > run > in a VM and point VNC at). This allows testing of things including GUI > applications, system boot-up (BIOS, bootloaders, kernels), installers and > whole > operating systems. > > Tests (using Perl syntax) generally consist mostly of sequences of code like: > assert_and_click 'some_icon'; > assert_screen 'some_prompt'; > send_key 'ret'; > which are run using the os-autoinst test engine, by a worker. The tags named > in > scripts can then be associated with 'needles' (elements of screenshots) via > the > webUI (either from past tests, or while controlling a live test). Other > testing > possibilities include: serial-connected headless systems, multi-host networked > tests, and non-VM 'real' systems. I would like to suggest that we take a look at this tool and see if it will help us. We're spending days of our time just testing the installation procedure for our flavours - being able to automate away a large portion of that work may be a huge benefit, especially in time crunches like the one we're under now. And it might help us catch bugs like this more easily in the future. Hopefully this is helpful. Thank you all for all the work you put into this system, and thank you for letting me contribute! Sincerely, Aaron Rainbolt Newbie Lubuntu developer-in-training -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Ubuntu Studio 22.04.1 and Secure Boot
On Tuesday, August 2, 2022 10:16:53 AM PDT Simon Quigley wrote: > As for why this is coming up *now* in the first place, I don't have the > slightest clue. In the year 2022, flavors need to at least smoke test > *once*, *especially* for an LTS release, to ensure Secure Boot works. > Look, I get it, flavor teams may be short-staffed, some more than > others, but we really need to take a look at our QA processes as the > Ubuntu project to ensure something basic like this is caught in every > flavor. (Yes, I'm volunteering to write the ISO QA tests.) It's > embarrassing, as a fellow Ubuntu Flavor RM, that something like this was > not caught and brought to the attention of the Release Team > *immediately*. This isn't personal, I'm not trying to roast anyone in > particular, but come on everyone, we really need to do better here. I'll > link Lubuntu's thorough test suite here[2], and I would suggest other > flavors take our example. > [snip] > [1] > https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config#n132 > [2] https://phab.lubuntu.me/w/release-team/testing-checklist/ > This happened partially because of the transition from Xfce to KDE Plasma back in 2020 and the subsequent transition from Ubiquity to Calamares since Ubiquity's KDE modules are hard-coded for Kubuntu's branding. Ubiquity has the necessary facility to handle interfacing with mokutils and creating a MOK, whereas Calamares does not, and this was missed during the Ubuntu Studio testing. And yes, your analysis of Ubuntu Studio lacking the manpower and resources to test every scenario of installation is correct. We're just not popular enough to attract the willing participants to want to help test. Additionally, I tested on real hardware. I was unaware, until recently, that my own hardware that I was testing on did not have secure boot enabled. This was a mistake on my part and I own this mistake. However, I will say that Calamares not having a facility for MOK is quite a shortcoming and also prevents the installation of drivers such as Nvidia drivers, which is something that Ubiquity can do. This makes other installers, such as Ubiquity and even the new flutter-based installer more attractive all the time for use cases like Ubuntu Studio, where advanced graphics processing is paramount for video production, photography, and graphics design. This, however, is a digression and probably worthy of a separate discussion. -- Erich Eickmeyer Project Leader - Ubuntu Studio Member - Ubuntu Community Council signature.asc Description: This is a digitally signed message part. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Ubuntu Studio 22.04.1 and Secure Boot
Hello, This email is meant to provide an update on Ubuntu Studio's Secure Boot situation in 22.04.1. Currently, UEFI Secure Boot installs fail with Ubuntu Studio 22.04 due to the inclusion of the v4loopback DKMS module, which Erich intends to remove from the seed in order to fix this bug. In #ubuntu-release I was reading scrollback from Erich and Łukasz, and there seems to be an issue with germinate grabbing that dependency despite removing it in the seed post-release. Iain Lane chimed in and pointed me to this line[1] in germinate which grabs those packages. I have to agree, it's an impressive line of code. I am willing and able to do the vast majority of the work in fast-tracking this through. However, I am in unfamiliar territory since I do not have SSH access to the server to just take a peek at logs. In terms of testing it, I'd like someone from Canonical to provide technical advice on how to properly solve this. Iain (while his feedback was very useful), did note he may be rusty. As for why this is coming up *now* in the first place, I don't have the slightest clue. In the year 2022, flavors need to at least smoke test *once*, *especially* for an LTS release, to ensure Secure Boot works. Look, I get it, flavor teams may be short-staffed, some more than others, but we really need to take a look at our QA processes as the Ubuntu project to ensure something basic like this is caught in every flavor. (Yes, I'm volunteering to write the ISO QA tests.) It's embarrassing, as a fellow Ubuntu Flavor RM, that something like this was not caught and brought to the attention of the Release Team *immediately*. This isn't personal, I'm not trying to roast anyone in particular, but come on everyone, we really need to do better here. I'll link Lubuntu's thorough test suite here[2], and I would suggest other flavors take our example. Despite my personal regrets on how this should have been handled, we have two days. Let's focus on this first, and we can bikeshed on QA processes afterwards. [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config#n132 [2] https://phab.lubuntu.me/w/release-team/testing-checklist/ Thanks, -- Simon Quigley si...@tsimonq2.net tsimonq2 on LiberaChat and OFTC @tsimonq2:linuxdelta.com on Matrix 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 OpenPGP_signature Description: OpenPGP digital signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
New component-mismatches for source universe -> main
The following universe packages have new reverse dependencies in main or got seeded. They need to get a MainInclusionReport and be promoted, or the reverse dependencies in main need to be dropped: MIR: #1978144 (Won't Fix) [MIR] ipmitool Please see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt for the full report. Please contact https://launchpad.net/~ubuntu-archive for problems with this notification. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
New component-mismatches for source universe -> main
The following universe packages have new reverse dependencies in main or got seeded. They need to get a MainInclusionReport and be promoted, or the reverse dependencies in main need to be dropped: MIR: #1978144 (New) [MIR] ipmitool Please see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt for the full report. Please contact https://launchpad.net/~ubuntu-archive for problems with this notification. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Call for testing: 22.04.1 release candidate images ready!
Hi Lukasz, On Mon, 1 Aug 2022 at 23:58, 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. > I downloaded the abovementioned iso, Ubuntu 22.04.1 on an HP Elitebook 8730w largish laptop. It has 4GiB RAM and a 320GB HDD. The install went like a dream and it works. I went to the isotracker and, after logging in, reported the successful install. In fact, the Canonical website stuff was the most demanding part of the process. HTH, Ian -- -- ACCU - Professionalism in programming - http://www.accu.org -- My writing - https://sites.google.com/site/ianbruntlett/ -- Free Software page - https://sites.google.com/site/ianbruntlett/home/free-software -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
