Re: Reducing initramfs size and speed up the generation
On Sat, 2023-07-08 at 03:23 +0100, Dimitri John Ledkov wrote: > > > On Sat, 8 Jul 2023, 02:49 Benjamin Drung, wrote: > > On Sat, 2023-07-08 at 01:25 +0100, Dimitri John Ledkov wrote: > > > On Sat, 8 Jul 2023 at 01:19, Benjamin Drung > > > wrote: > > > > > > > > Hi all, > > > > > > > > a year ago we changed the default compression and level for the > > > > initramfs to zstd -1. This fixed the very slow creation times on > > > > development boards (see bug #1958148), but that leads to bigger > > > > initramfs sizes that triggered other bugs (like bug #1842320). > > > > Big initramfs sizes can also fill up small sized /boot > > > > partitions easily > > > > (grooming the 850 initramfs-tools bugs revealed several such > > > > reports). > > > > > > > > Using xz -9 would give very good compression, but it takes very > > > > long > > > > (especially on slow development boards) and a lot of memory > > > > (good luck > > > > on Raspberry Pis with small memory like Pi Zeros). > > > > > > > > I propose following approach to address the drawback: Create > > > > cpio > > > > archives (compressed with xz -9) for the kernel modules and > > > > firmware > > > > files when building the kernel/firmware Debian package. Then > > > > ship those > > > > cpio archives in the package (or in a separate binary package). > > > > Then the > > > > CPU load it put on the builders. The cpio archives would contain > > > > the > > > > modules for MODULES=most. > > > > > > > > mkinitramfs will then look for those cpio archives and uses > > > > those in > > > > case they are present. Such a initramfs would look like this: > > > > > > > > * AMD/Intel microcode cpio archive (on amd64) > > > > * main cpio archive compressed with zstd -1 > > > > * kernel modules from the Debian package compressed with xz -9 > > > > * firmware files from the Debian package compressed with xz -9 > > > > > > > > > > Majority of our instances boot without initrd, and there too they > > > don't load most of the modules. > > > Creating xz -9 compressed archive of all modules, still pays the > > > penalty to decompress most of them, and then not modprobe them. > > > I was hoping to achieve a similar in spirit approach, but didn't > > > quite > > > have the time to implement is: > > > > > > 1) change linux-modules and linux-firmware to ship .ko.zst > > > firmware.bin.zst compressed with zstd -19 at .deb build time > > > 2) this saves install size of the packages, with only slightly > > > increased download size > > > 3) modify initramfs-tools to include compressed files into a > > > separate > > > initrd, which is not compressed (i.e. exclude .zst files from the > > > default main compressed cpio archive, and append them in the > > > second > > > main cpio archive that is uncompressed) > > > 4) this should achieve quick initrd creation, which will be > > > smaller in > > > size that current status, and will boot faster as it will only > > > decompress modules/firmware it actually needs at boot > > > > > > For experimentation locally, you can recompress .ko with zstd in > > > place > > > in /lib/modules/; and rerun depmod. To then test initramfs-tools > > > changes that skip over .zst compressed files and add them as is in > > > an > > > uncompressed appended cpio. > > > > That is a very good idea. I created a draft for point 3 in [2]. It > > moves > > the compressed files into a separate directory and creates a > > separate > > cpio archive for that directory without compressing it: > > > > * AMD/Intel microcode cpio archive (on amd64) > > * main cpio archive (compressed) > > * compressed kernel modules / firmware (not compressed) > > > > Sadly this does not work (yet). cpio complains with "premature end > > of > > archive" when looking at it and the kernel fails to extract the last > > cpio part. I am heading to bed now leaving that bug for another day. > > > I had this before with lz4 and lzo compression and fixed this before > in the kernel. It is likely a kernel bug mishandling mixed compression > initrds. It's not only the kernel. It is also cpio that complains. > It will likely work if you Make compressed-files the third early > initrd. Such that we have intel, AMD microcode early initrds, followed > by compressed-files initrd, followed by compressed main initrd. > It did. > > [2] > > https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+ref/ubuntu/compressed > > -- Benjamin Drung Debian & Ubuntu Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reducing initramfs size and speed up the generation
On Sat, 2023-07-08 at 03:49 +0200, Benjamin Drung wrote:
> On Sat, 2023-07-08 at 01:25 +0100, Dimitri John Ledkov wrote:
> > On Sat, 8 Jul 2023 at 01:19, Benjamin Drung wrote:
> > >
> > > Hi all,
> > >
> > > a year ago we changed the default compression and level for the
> > > initramfs to zstd -1. This fixed the very slow creation times on
> > > development boards (see bug #1958148), but that leads to bigger
> > > initramfs sizes that triggered other bugs (like bug #1842320).
> > > Big initramfs sizes can also fill up small sized /boot partitions easily
> > > (grooming the 850 initramfs-tools bugs revealed several such reports).
> > >
> > > Using xz -9 would give very good compression, but it takes very long
> > > (especially on slow development boards) and a lot of memory (good luck
> > > on Raspberry Pis with small memory like Pi Zeros).
> > >
> > > I propose following approach to address the drawback: Create cpio
> > > archives (compressed with xz -9) for the kernel modules and firmware
> > > files when building the kernel/firmware Debian package. Then ship those
> > > cpio archives in the package (or in a separate binary package). Then the
> > > CPU load it put on the builders. The cpio archives would contain the
> > > modules for MODULES=most.
> > >
> > > mkinitramfs will then look for those cpio archives and uses those in
> > > case they are present. Such a initramfs would look like this:
> > >
> > > * AMD/Intel microcode cpio archive (on amd64)
> > > * main cpio archive compressed with zstd -1
> > > * kernel modules from the Debian package compressed with xz -9
> > > * firmware files from the Debian package compressed with xz -9
> > >
> >
> > Majority of our instances boot without initrd, and there too they
> > don't load most of the modules.
> > Creating xz -9 compressed archive of all modules, still pays the
> > penalty to decompress most of them, and then not modprobe them.
> > I was hoping to achieve a similar in spirit approach, but didn't quite
> > have the time to implement is:
> >
> > 1) change linux-modules and linux-firmware to ship .ko.zst
> > firmware.bin.zst compressed with zstd -19 at .deb build time
> > 2) this saves install size of the packages, with only slightly
> > increased download size
> > 3) modify initramfs-tools to include compressed files into a separate
> > initrd, which is not compressed (i.e. exclude .zst files from the
> > default main compressed cpio archive, and append them in the second
> > main cpio archive that is uncompressed)
> > 4) this should achieve quick initrd creation, which will be smaller in
> > size that current status, and will boot faster as it will only
> > decompress modules/firmware it actually needs at boot
> >
> > For experimentation locally, you can recompress .ko with zstd in place
> > in /lib/modules/; and rerun depmod. To then test initramfs-tools
> > changes that skip over .zst compressed files and add them as is in an
> > uncompressed appended cpio.
>
> That is a very good idea. I created a draft for point 3 in [2]. It moves
> the compressed files into a separate directory and creates a separate
> cpio archive for that directory without compressing it:
>
> * AMD/Intel microcode cpio archive (on amd64)
> * main cpio archive (compressed)
> * compressed kernel modules / firmware (not compressed)
>
> Sadly this does not work (yet). cpio complains with "premature end of
> archive" when looking at it and the kernel fails to extract the last
> cpio part. I am heading to bed now leaving that bug for another day.
>
> [2]
> https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+ref/ubuntu/compressed
Okay. It works now. The not-compressed cpio archive must not be the last
one. So the order is now:
* AMD/Intel microcode cpio archive (on amd64)
* compressed kernel modules / firmware (not compressed)
* main cpio archive (compressed)
I'll really stop now. For a first comparison, the firmware files need to
be converted correctly. There are symlinks in /lib/firmware. So running
following was not correct/enough:
find /lib/firmware -name '*.bin' | while read -r fw; do
sudo zstd -19 -z -o "${fw}.zst" "$fw"
sudo rm "$fw"
done
If you want to help, hand me a correct conversion script.
--
Benjamin Drung
Debian & Ubuntu Developer
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reducing initramfs size and speed up the generation
On Sat, 8 Jul 2023, 02:49 Benjamin Drung, wrote: > On Sat, 2023-07-08 at 01:25 +0100, Dimitri John Ledkov wrote: > > On Sat, 8 Jul 2023 at 01:19, Benjamin Drung wrote: > > > > > > Hi all, > > > > > > a year ago we changed the default compression and level for the > > > initramfs to zstd -1. This fixed the very slow creation times on > > > development boards (see bug #1958148), but that leads to bigger > > > initramfs sizes that triggered other bugs (like bug #1842320). > > > Big initramfs sizes can also fill up small sized /boot partitions > easily > > > (grooming the 850 initramfs-tools bugs revealed several such reports). > > > > > > Using xz -9 would give very good compression, but it takes very long > > > (especially on slow development boards) and a lot of memory (good luck > > > on Raspberry Pis with small memory like Pi Zeros). > > > > > > I propose following approach to address the drawback: Create cpio > > > archives (compressed with xz -9) for the kernel modules and firmware > > > files when building the kernel/firmware Debian package. Then ship those > > > cpio archives in the package (or in a separate binary package). Then > the > > > CPU load it put on the builders. The cpio archives would contain the > > > modules for MODULES=most. > > > > > > mkinitramfs will then look for those cpio archives and uses those in > > > case they are present. Such a initramfs would look like this: > > > > > > * AMD/Intel microcode cpio archive (on amd64) > > > * main cpio archive compressed with zstd -1 > > > * kernel modules from the Debian package compressed with xz -9 > > > * firmware files from the Debian package compressed with xz -9 > > > > > > > Majority of our instances boot without initrd, and there too they > > don't load most of the modules. > > Creating xz -9 compressed archive of all modules, still pays the > > penalty to decompress most of them, and then not modprobe them. > > I was hoping to achieve a similar in spirit approach, but didn't quite > > have the time to implement is: > > > > 1) change linux-modules and linux-firmware to ship .ko.zst > > firmware.bin.zst compressed with zstd -19 at .deb build time > > 2) this saves install size of the packages, with only slightly > > increased download size > > 3) modify initramfs-tools to include compressed files into a separate > > initrd, which is not compressed (i.e. exclude .zst files from the > > default main compressed cpio archive, and append them in the second > > main cpio archive that is uncompressed) > > 4) this should achieve quick initrd creation, which will be smaller in > > size that current status, and will boot faster as it will only > > decompress modules/firmware it actually needs at boot > > > > For experimentation locally, you can recompress .ko with zstd in place > > in /lib/modules/; and rerun depmod. To then test initramfs-tools > > changes that skip over .zst compressed files and add them as is in an > > uncompressed appended cpio. > > That is a very good idea. I created a draft for point 3 in [2]. It moves > the compressed files into a separate directory and creates a separate > cpio archive for that directory without compressing it: > > * AMD/Intel microcode cpio archive (on amd64) > * main cpio archive (compressed) > * compressed kernel modules / firmware (not compressed) > > Sadly this does not work (yet). cpio complains with "premature end of > archive" when looking at it and the kernel fails to extract the last > cpio part. I am heading to bed now leaving that bug for another day. > I had this before with lz4 and lzo compression and fixed this before in the kernel. It is likely a kernel bug mishandling mixed compression initrds. It will likely work if you Make compressed-files the third early initrd. Such that we have intel, AMD microcode early initrds, followed by compressed-files initrd, followed by compressed main initrd. > [2] > https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+ref/ubuntu/compressed > > -- > Benjamin Drung > Debian & Ubuntu Developer > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reducing initramfs size and speed up the generation
On Sat, 2023-07-08 at 01:25 +0100, Dimitri John Ledkov wrote: > On Sat, 8 Jul 2023 at 01:19, Benjamin Drung wrote: > > > > Hi all, > > > > a year ago we changed the default compression and level for the > > initramfs to zstd -1. This fixed the very slow creation times on > > development boards (see bug #1958148), but that leads to bigger > > initramfs sizes that triggered other bugs (like bug #1842320). > > Big initramfs sizes can also fill up small sized /boot partitions easily > > (grooming the 850 initramfs-tools bugs revealed several such reports). > > > > Using xz -9 would give very good compression, but it takes very long > > (especially on slow development boards) and a lot of memory (good luck > > on Raspberry Pis with small memory like Pi Zeros). > > > > I propose following approach to address the drawback: Create cpio > > archives (compressed with xz -9) for the kernel modules and firmware > > files when building the kernel/firmware Debian package. Then ship those > > cpio archives in the package (or in a separate binary package). Then the > > CPU load it put on the builders. The cpio archives would contain the > > modules for MODULES=most. > > > > mkinitramfs will then look for those cpio archives and uses those in > > case they are present. Such a initramfs would look like this: > > > > * AMD/Intel microcode cpio archive (on amd64) > > * main cpio archive compressed with zstd -1 > > * kernel modules from the Debian package compressed with xz -9 > > * firmware files from the Debian package compressed with xz -9 > > > > Majority of our instances boot without initrd, and there too they > don't load most of the modules. > Creating xz -9 compressed archive of all modules, still pays the > penalty to decompress most of them, and then not modprobe them. > I was hoping to achieve a similar in spirit approach, but didn't quite > have the time to implement is: > > 1) change linux-modules and linux-firmware to ship .ko.zst > firmware.bin.zst compressed with zstd -19 at .deb build time > 2) this saves install size of the packages, with only slightly > increased download size > 3) modify initramfs-tools to include compressed files into a separate > initrd, which is not compressed (i.e. exclude .zst files from the > default main compressed cpio archive, and append them in the second > main cpio archive that is uncompressed) > 4) this should achieve quick initrd creation, which will be smaller in > size that current status, and will boot faster as it will only > decompress modules/firmware it actually needs at boot > > For experimentation locally, you can recompress .ko with zstd in place > in /lib/modules/; and rerun depmod. To then test initramfs-tools > changes that skip over .zst compressed files and add them as is in an > uncompressed appended cpio. That is a very good idea. I created a draft for point 3 in [2]. It moves the compressed files into a separate directory and creates a separate cpio archive for that directory without compressing it: * AMD/Intel microcode cpio archive (on amd64) * main cpio archive (compressed) * compressed kernel modules / firmware (not compressed) Sadly this does not work (yet). cpio complains with "premature end of archive" when looking at it and the kernel fails to extract the last cpio part. I am heading to bed now leaving that bug for another day. [2] https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+ref/ubuntu/compressed -- Benjamin Drung Debian & Ubuntu Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reducing initramfs size and speed up the generation
On Sat, 8 Jul 2023 at 01:19, Benjamin Drung wrote: > > Hi all, > > a year ago we changed the default compression and level for the > initramfs to zstd -1. This fixed the very slow creation times on > development boards (see bug #1958148), but that leads to bigger > initramfs sizes that triggered other bugs (like bug #1842320). > Big initramfs sizes can also fill up small sized /boot partitions easily > (grooming the 850 initramfs-tools bugs revealed several such reports). > > Using xz -9 would give very good compression, but it takes very long > (especially on slow development boards) and a lot of memory (good luck > on Raspberry Pis with small memory like Pi Zeros). > > I propose following approach to address the drawback: Create cpio > archives (compressed with xz -9) for the kernel modules and firmware > files when building the kernel/firmware Debian package. Then ship those > cpio archives in the package (or in a separate binary package). Then the > CPU load it put on the builders. The cpio archives would contain the > modules for MODULES=most. > > mkinitramfs will then look for those cpio archives and uses those in > case they are present. Such a initramfs would look like this: > > * AMD/Intel microcode cpio archive (on amd64) > * main cpio archive compressed with zstd -1 > * kernel modules from the Debian package compressed with xz -9 > * firmware files from the Debian package compressed with xz -9 > Majority of our instances boot without initrd, and there too they don't load most of the modules. Creating xz -9 compressed archive of all modules, still pays the penalty to decompress most of them, and then not modprobe them. I was hoping to achieve a similar in spirit approach, but didn't quite have the time to implement is: 1) change linux-modules and linux-firmware to ship .ko.zst firmware.bin.zst compressed with zstd -19 at .deb build time 2) this saves install size of the packages, with only slightly increased download size 3) modify initramfs-tools to include compressed files into a separate initrd, which is not compressed (i.e. exclude .zst files from the default main compressed cpio archive, and append them in the second main cpio archive that is uncompressed) 4) this should achieve quick initrd creation, which will be smaller in size that current status, and will boot faster as it will only decompress modules/firmware it actually needs at boot For experimentation locally, you can recompress .ko with zstd in place in /lib/modules/; and rerun depmod. To then test initramfs-tools changes that skip over .zst compressed files and add them as is in an uncompressed appended cpio. > After working on initramfs-tools as part my day job, my fingers were > itching and I had to create a quick and dirty draft in my free night > time. You can find the result of the last two hours in [1]. This draft > has a mkinitramfs-kernel script that creates a cpio archive containing > the kernel modules and firmware (that needs to be split later on). > > The lunar test result on my AMD Ryzen 7 5700G look promising: Building > 6.2.0-24-generic-modules-most.cpio.xz takes around 90 seconds and is > 54.9 MiB in size. Creating the initramfs speeds up from around 8.7 > seconds to 3.5 seconds (saves 60 %). The size reduces from 133.1 MiB to > 80.7 MiB (saves 39.4 %). So the boot needs 52.4 MiB less, but > /lib/modules need 54.9 MiB for the cpio archive. > > The drawback is that building the kernel would take longer, the package > takes more space on the archive and mirrors, and downloading them could > take longer on slow connections. > > Implementing my proposal would be relative easy for initramfs-tools, but > would mean some work for the kernel team. > > What do you think? > > [1] > https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+ref/ubuntu/prebuilt > > -- > Benjamin Drung > Debian & Ubuntu Developer > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- okurrr, Dimitri -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reducing initramfs size and speed up the generation
Hi all, a year ago we changed the default compression and level for the initramfs to zstd -1. This fixed the very slow creation times on development boards (see bug #1958148), but that leads to bigger initramfs sizes that triggered other bugs (like bug #1842320). Big initramfs sizes can also fill up small sized /boot partitions easily (grooming the 850 initramfs-tools bugs revealed several such reports). Using xz -9 would give very good compression, but it takes very long (especially on slow development boards) and a lot of memory (good luck on Raspberry Pis with small memory like Pi Zeros). I propose following approach to address the drawback: Create cpio archives (compressed with xz -9) for the kernel modules and firmware files when building the kernel/firmware Debian package. Then ship those cpio archives in the package (or in a separate binary package). Then the CPU load it put on the builders. The cpio archives would contain the modules for MODULES=most. mkinitramfs will then look for those cpio archives and uses those in case they are present. Such a initramfs would look like this: * AMD/Intel microcode cpio archive (on amd64) * main cpio archive compressed with zstd -1 * kernel modules from the Debian package compressed with xz -9 * firmware files from the Debian package compressed with xz -9 After working on initramfs-tools as part my day job, my fingers were itching and I had to create a quick and dirty draft in my free night time. You can find the result of the last two hours in [1]. This draft has a mkinitramfs-kernel script that creates a cpio archive containing the kernel modules and firmware (that needs to be split later on). The lunar test result on my AMD Ryzen 7 5700G look promising: Building 6.2.0-24-generic-modules-most.cpio.xz takes around 90 seconds and is 54.9 MiB in size. Creating the initramfs speeds up from around 8.7 seconds to 3.5 seconds (saves 60 %). The size reduces from 133.1 MiB to 80.7 MiB (saves 39.4 %). So the boot needs 52.4 MiB less, but /lib/modules need 54.9 MiB for the cpio archive. The drawback is that building the kernel would take longer, the package takes more space on the archive and mirrors, and downloading them could take longer on slow connections. Implementing my proposal would be relative easy for initramfs-tools, but would mean some work for the kernel team. What do you think? [1] https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+ref/ubuntu/prebuilt -- Benjamin Drung Debian & Ubuntu Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Kernel Uploaders
Today, the Kernel Uploaders Team[1] had an ad-hoc IRC meeting with the following people in attendence: Team Members: Andy Whitcroft (~apw) Dimitri Ledkov (~xnox) Ian May(~ian-may) Kamal Mostafa (~kamalmostafa) Kleber Sacilotto de Souza (~kleber-souza) Luke Nowakowski-Krijger(~lukenow) Marcelo Cerri (~mhcerri) Phil Cox (~philcox) Stefan Bader (~smb) Thadeu Cascardo(~cascardo) Tim Gardner(~timg-tpi) Applicants: Andrei Gherzan (~agherzan) Cory Todd (~corytodd) Emil Renner Berthing (~esmil) John Cabaj (~john-cabaj) Roxana Nicolescu (~roxanan) Observers: Kuba Pawlak(~kuba-t-pawlak) [1] https://launchpad.net/~ubuntu-kernel-uploaders We reviewed the application[2] by Cory Todd (~corytodd)[3] for Kernel Upload Rights. After representations by the applicant and their sponsors a vote was held as below: Andy Whitcroft +1 Dimitri Ledkov +1 Ian May+1 Kleber Sacilotto de Souza +1 Luke Nowakowski-Krijger+1 Marcelo Cerri +1 Phil Cox +1 Stefan Bader +1 Tim Gardner+1 The application was unanimously approved; congratulations to Cory Todd. [2] https://wiki.ubuntu.com/corytodd/KernelUploadRightsApplication [3] https://launchpad.net/~corytodd We reviewed the application[4] by Andrei Gherzan (~agherzan)[5] for Kernel Upload Rights. After representations by the applicant and their sponsors a vote was held as below: Andy Whitcroft +1 Dimitri Ledkov +1 Ian May+1 Kamal Mostafa +1 Kleber Sacilotto de Souza +1 Luke Nowakowski-Krijger+1 Marcelo Cerri +1 Phil Cox +1 Stefan Bader +1 Thadeu Cascardo+1 Tim Gardner+1 The application was unanimously approved; congratulations to Andrei Gherzan. [4] https://wiki.ubuntu.com/agherzan/KernelUploadsApplication [5] https://launchpad.net/~agherzan We reviewed the application[6] by Roxana Nicolescu (~roxanan)[7] for Kernel Upload Rights. After representations by the applicant and their sponsors a vote was held as below: Andy Whitcroft +1 Dimitri Ledkov +1 Ian May+1 Kamal Mostafa +1 Kleber Sacilotto de Souza +1 Luke Nowakowski-Krijger+1 Marcelo Cerri +1 Phil Cox +1 Stefan Bader +1 Thadeu Cascardo+1 Tim Gardner+1 The application was unanimously approved; congratulations to Roxana Nicolescu. [6] https://wiki.ubuntu.com/roxanan/KernelUploadRightsApplication [7] https://launchpad.net/~roxanan We reviewed the application[8] by Emil Renner Berthing (~esmil)[9] for Kernel Upload Rights. After representations by the applicant and their sponsors a vote was held as below: Andy Whitcroft +1 Dimitri Ledkov +1 Ian May+1 Kamal Mostafa +1 Kleber Sacilotto de Souza +1 Luke Nowakowski-Krijger+1 Marcelo Cerri +1 Phil Cox +1 Stefan Bader +1 Thadeu Cascardo+1 Tim Gardner+1 The application was unanimously approved; congratulations to Emil Renner Berthing. [8] https://wiki.ubuntu.com/esmil/KernelUploadRightsApplication [9] https://launchpad.net/~esmil We reviewed the application[10] by John Cabaj (~john-cabaj)[11] for Kernel Upload Rights. After representations by the applicant and their sponsors a vote was held as below: Andy Whitcroft +1 Dimitri Ledkov +1 Ian May+1 Kamal Mostafa +1 Kleber Sacilotto de Souza +1 Luke Nowakowski-Krijger+1 Marcelo Cerri +1 Phil Cox +1 Stefan Bader +1 Thadeu Cascardo+1 Tim Gardner+1 The application was unanimously approved; congratulations to John Cabaj. [10] https://wiki.ubuntu.com/john-cabaj/KernelUploadRightsApplication [11] https://launchpad.net/~john-cabaj Congratulations to all of the successful applicants. Enjoy your new rights. Andy Whitcroft (~apw) was tasked with adding them to the ~ubuntu-kernel-uploaders team and announcing these results. -apw (on behalf of the ~ubuntu-kernel-uploaders team) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at:
Re: PPU upload rights application for sosreport
Thank you very much! Regards, Nikhil. On Tue, Jul 4, 2023 at 10:26 PM Utkarsh Gupta wrote: > Hello again, > > On Fri, Jun 30, 2023 at 2:02 PM Utkarsh Gupta > wrote: > > Nikhil, I've added you to ~ubuntu-dev and a TB member shall soon > > adjust ACL for the sosreport package. > > This has been done by Robie already. You're good to go now. :) > > > - u > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
