I made a request, and the iwlwifi .deb packages have now been renamed to end with .backup suffixes in any existing builds that produced it in error. This should prevent any automated scripts to attempt to download or install those packages.
It is correct action to skip installing this packages / remove it, if it was installed.
The 5.18.1 and 5.17.12 ppa builds are broken as they either show no packages or some architectures show 5.15 kernel packages ? Could you please check ? Thanks.
I’m late to the party in asking a question, but here’s mine: what’s the status and effort being applied to get the Ubuntu Sauce patches to AppArmor that are required in addition to upstream AppArmor in the kernel so that snapd is able to enable strict confinement out of the box. I ask because as the kernel currently stands upstream, I believe there are bits missing that snapd requires. Certainly the WSL2 kernel which is based on upstream 5.10 does not have enough Ubuntu Sauce (as it is directly forked from upstream by Microsoft, without adding any Ubuntu patches because MS has no reason to do so) to enable strict confinement.
AppArmor development in Ubuntu has more features than vanilla upstream kernel. And this will remain to be so in the foreseeable future, as we have more resources to include, test, support and use new AppArmor features in Ubuntu kernels ahead of inclusion in the vanilla releases. We do not limit ourselves to using vanilla-only features in obsolete kernel versions.
Separately, there is ongoing work to make systemd and snapd, and hence snaps work on top of WSL2 with the Microsoft provided kernel. This is possible because snapd is able to adapt to the available confinement features to still offer snaps. Also we are open in providing and supporting Microsoft to integrate more up to date features of Linux to their WSL offering than they currently provide.
You missed the point I was making. By adding Ubuntu-only AppArmor extensions to the kernel and using those within snapd we are seriously limiting the functionality and security story of Snap Packages in other native distros and WSL2. By not pushing the AppArmor patches upstream quickly enough there will never be a time that a third-party distro can be supported by snapd, which will (and currently does) always report “partial confinement” and therefore not apply the Strict Confinement rules on those distros meaning that any Snap package will be able to escape the sandbox easily.
I apologise in advance if I am in the wrong forum. I have a concern about a particular Linux API (AIO). A specific kernel function (io_destroy) blocks for a long time on 5.15.0-40-generic. I’ve observed the same on an older kernel. It is so slow that I am wondering if this is a performance bug?
My question is, where should I report this? I can provide my observations and a minimally reproducible C test code.
Great question! it is usually either subsystem mailing list or kernel bugzilla.
For the correct workflow on how to report upstream kernel bugs you can follow this excellent kernel newbies article. It tells you step by step, how to prepare bug report and where to submit it.
Once you submit it to a mailing list of kernel bugzilla, drop the URL to it here. I would be delighted to read it and see if I know anybody who would be able to help with it further!
I’m not quite sure what you mean by roadmaps for new releases. Can you please elaborate what sort of information you are looking for, or expect to find?
Kinetic Release Schedule has Kernel Feature Freeze as 6th of October. v5.19 is out and is prepared to be in Kinetic, it is already in kinetic-proposed with some known regressions.
It is unlikely that v6.0 will be out and stabalised in time to make it before Kernel Feature Freeze.
if there are important features to backport and include in Kinetic kernel, this can be requested via ubuntu-bug linux or via email to kernel-team@lists.ubuntu.com (archives) which is the Public Ubuntu Kernel Mailing list used for feature discussion, next kernel developments, and patch reviews.
Kinetic and Jammy will have other kernels too, for specific partners and OEMs which will have features specific to a given partner. PMs of those partners can query things privately via their Salesforce account.
Could you please check the 5.19.4 builds ? Only arm64 and s390 builds completed successfully.
The amd64 build looks like it failed due to a missing header file (likely wrong path for -I include files) :
fuse_mnt.c:17:10: fatal error: fuse.h: No such file or directory
@thetick the mainline builds ppa is entirely unsupported. it is merely there to provide a means to test wether a bug in the official kernel has been fixed upstream in the https://kernel.org/ releases. You are not supposed to run them full time, so the fact that a build or two fails should be irrelevant to anyone outside the kernel team for whom it should be very low priority to fix.
