Re: [arch-dev-public] Goodbye

[Tobias Powalowski via arch-dev-public]

Hi,
I wish you all the best for your future :)
Thanks for all your work.
Have fun
tpowa

Am Do., 21. Jan. 2021 um 14:08 Uhr schrieb Bartłomiej Piotrowski via
arch-dev-public :

> Hi everyone,
>
> I'm stepping down as a developer. It's been mostly fantastic ride for
> the last 10 years but it's clear to me now that for better or worse it's
> far from the project I initially joined.
>
> Thank you and good luck with everything,
> Bart
>


-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org

Re: [arch-dev-public] deprecating git.archlinux.org

[Tobias Powalowski via arch-dev-public]

Hi archboot is on gitlab:
https://gitlab.archlinux.org/tpowa/archboot
greetings
tpowa

Am So., 27. Juni 2021 um 23:18 Uhr schrieb Kristian Klausen via
arch-dev-public :

> On 23.06.2021 22.01, Jelle van der Waa via arch-dev-public wrote:
> > If your project has not been migrated to Gitlab yet please contact
> > devops for help migrating it. A list of known to require migration is
> > listed in this ticket. [1]
> >
> > As the invoice date comes up the 8th, it would be awesome if we can
> > cancel the box before that date.
> >
> > [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/6
>
> We (I and jelle) have already migrated a good chunk of the projects, so
> I think it is time we can begin updating the packages to use their new
> home as "source".
>
> The following packages (found with[1]) use {git,projects}.archlinux.org
> as source and should be updated (TODO here[2]):
> archboot
> arch-install-scripts
> cgit-archweb
> cgit-aurweb
> devtools
> mkinitcpio
> namcap
> netctl
> pacman
> pacman-contrib
>
> Please reach out if the git repository hasn't been migrated and we will
> fast track it. Some of the new homes are documented here[3].
>
>
> [1] grep -lE 'git.archlinux.org|projects.archlinux.org' $(find
> /srv/svntogit/repos -name PKGBUILD) | cut -f6 -d / | sort -u
> [2] https://archlinux.org/todo/gitarchlinuxorg-deprecation/
> [3] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/6
>


-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org

[arch-dev-public] linux-firmware package, some thoughts

[Tobias Powalowski via arch-dev-public]

Hi guys,
lately did a lot of archboot hacking and stumbled over our firmware package.
It needs installed 750 MB, download size is 130 MB.
I tried to get it smaller and uploaded the archboot-linux-firmware package
for my purposes.
Our linux kernel needs only 180 MB installed size, download size is about
37 MB.
Wouldn't it make sense to provide for each kernel we ship, a separate
firmware package?
Just my 2 cwnts,
greetings
tpowa

-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org

Re: [arch-dev-public] linux-firmware package, some thoughts

[Tobias Powalowski via arch-dev-public]

Hi,
according to google in 5.3 the xz compression was introduced so all kernels
we ship should support it.
greetings
tpowa

Am Mo., 27. Sept. 2021 um 21:54 Uhr schrieb Giancarlo Razzolini via
arch-dev-public :

> Em setembro 27, 2021 16:46 Jelle van der Waa via arch-dev-public escreveu:
> > On 27/09/2021 21:13, Jan Alexander Steffens (heftig) via arch-dev-public
> > wrote:
> >> On Mon, Sep 27, 2021 at 8:30 PM Tobias Powalowski via arch-dev-public <
> >> arch-dev-public@lists.archlinux.org> wrote:
> >>
> >>> Hi guys,
> >>> lately did a lot of archboot hacking and stumbled over our firmware
> >>> package.
> >>> It needs installed 750 MB, download size is 130 MB.
> >>> I tried to get it smaller and uploaded the archboot-linux-firmware
> package
> >>> for my purposes.
> >>> Our linux kernel needs only 180 MB installed size, download size is
> about
> >>> 37 MB.
> >>> Wouldn't it make sense to provide for each kernel we ship, a separate
> >>> firmware package?
> >>> Just my 2 cwnts,
> >>> greetings
> >>> tpowa
> >>>
> >>
> >> The method used there wouldn't produce a usable firmware package for me.
> >> For example, `modinfo -F firmware iwlwifi` lists
> >> `iwlwifi-Qu-c0-hr-b0-64.ucode` but linux-firmware does not contain that
> >> file. The driver will fall back to the next lower version,
> >> `iwlwifi-Qu-c0-hr-b0-63.ucode`, which is in linux-firmware but not in
> the
> >> modinfo output.
> >>
> >> I think the best we can do is split some of the more obscure vendors
> that
> >> have large firmware sets, like Netronome, Qualcomm, Mellanox, Marvell,
> >> Cavium, QLogic and NXP.
> >
> >
> > I second this, the biggest firmware sizes are from these fancynetwork
> > equipemnt folks such as netronome. An alternative is enabling xz
> > compression for the firmware itself this should save space as well, but
> > it depends on support in the LTS kernel.
> >
>
> Can't we do both? Enable xz and split the larger firmwares? Or LTS don't
> have
> plans to support xz for firmware?
>
> Regards,
> Giancarlo Razzolini
>


-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org

Re: [arch-dev-public] linux-firmware package, some thoughts

[Tobias Powalowski via arch-dev-public]

Hi,
short summarize from irc:
https://fedoraproject.org/wiki/Changes/CompressKernelFirmware
xz -C crc32 is the only supported mode

mkinitcpio needs to be patched:
https://bugs.archlinux.org/task/72263

>From my side unknown, if dracut and booster can handle compressed firmware
files.

greetings
tpowa

Am Di., 28. Sept. 2021 um 06:55 Uhr schrieb Tobias Powalowski <
tobias.powalow...@googlemail.com>:

> Hi,
> according to google in 5.3 the xz compression was introduced so all
> kernels we ship should support it.
> greetings
> tpowa
>
> Am Mo., 27. Sept. 2021 um 21:54 Uhr schrieb Giancarlo Razzolini via
> arch-dev-public :
>
>> Em setembro 27, 2021 16:46 Jelle van der Waa via arch-dev-public escreveu:
>> > On 27/09/2021 21:13, Jan Alexander Steffens (heftig) via
>> arch-dev-public
>> > wrote:
>> >> On Mon, Sep 27, 2021 at 8:30 PM Tobias Powalowski via arch-dev-public <
>> >> arch-dev-public@lists.archlinux.org> wrote:
>> >>
>> >>> Hi guys,
>> >>> lately did a lot of archboot hacking and stumbled over our firmware
>> >>> package.
>> >>> It needs installed 750 MB, download size is 130 MB.
>> >>> I tried to get it smaller and uploaded the archboot-linux-firmware
>> package
>> >>> for my purposes.
>> >>> Our linux kernel needs only 180 MB installed size, download size is
>> about
>> >>> 37 MB.
>> >>> Wouldn't it make sense to provide for each kernel we ship, a separate
>> >>> firmware package?
>> >>> Just my 2 cwnts,
>> >>> greetings
>> >>> tpowa
>> >>>
>> >>
>> >> The method used there wouldn't produce a usable firmware package for
>> me.
>> >> For example, `modinfo -F firmware iwlwifi` lists
>> >> `iwlwifi-Qu-c0-hr-b0-64.ucode` but linux-firmware does not contain that
>> >> file. The driver will fall back to the next lower version,
>> >> `iwlwifi-Qu-c0-hr-b0-63.ucode`, which is in linux-firmware but not in
>> the
>> >> modinfo output.
>> >>
>> >> I think the best we can do is split some of the more obscure vendors
>> that
>> >> have large firmware sets, like Netronome, Qualcomm, Mellanox, Marvell,
>> >> Cavium, QLogic and NXP.
>> >
>> >
>> > I second this, the biggest firmware sizes are from these fancynetwork
>> > equipemnt folks such as netronome. An alternative is enabling xz
>> > compression for the firmware itself this should save space as well, but
>> > it depends on support in the LTS kernel.
>> >
>>
>> Can't we do both? Enable xz and split the larger firmwares? Or LTS don't
>> have
>> plans to support xz for firmware?
>>
>> Regards,
>> Giancarlo Razzolini
>>
>
>
> --
> Tobias Powalowski
> Archlinux Developer & Package Maintainer (tpowa)
> http://www.archlinux.org
> tp...@archlinux.org
>


-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org

Re: [arch-dev-public] Starting x86_64_v3 port

[Tobias Powalowski via arch-dev-public]

Hi,
A) I can do both with my server, but I don't package a lot.
B) I agree with Andy here it should be automated.

When the automatic setup is realized, we should definitly consider to
support more architectures,
like aarch64 for the new showing up arm servers and Apple Macs.

greetings
tpowa

Am Sa., 29. Jan. 2022 um 01:12 Uhr schrieb Allan McRae via arch-dev-public <
arch-dev-public@lists.archlinux.org>:

> Hi all,
>
> You may remember long in the past we discussed adding an x86_64_v3 port.
>   From memory, pkgstats shows this will benefit ~2/3 (or 3/4?) of our
> users!  So lets get this underway!
>
> Apart from tooling (devtools/dbscripts), we need to make some decisions.
>
> My plan is to seed the x86_64_v3 repos with x86_64 packages and then
> they get replaced as updates/rebuilds happen (potentially supplemented
> with a rebuild party).  Pacman 6.0 can handle this.  This is not a
> perfectly clean new port, but is substantially less of a burden than
> releasing a pure x86_64_v3 port.  Our .BUILDINFO files do record the
> package architecture, so this mixture should not affect (e.g.) our
> reproducible builds etc.
>
>
> The decision to be made is who will package for this repo?  I think
> these are the options:
>
> A) packagers upload both x86_64 and x86_64_v3 to the repos. Our build
> server will help those without x86_64_v3 machines.
>
> B) we recruit some packagers to build the x86_64_v3 packages.
>
> C) Some combination of A+B.
>
>
> My understanding is our x86_64 port started with B, then C, then A.
>
> I think with our build infrastructure now, we can start with A, but that
> is more of a burden for packagers.  I doubt it will be much of a burden
> as x86_64_v3 specific build issues are unlikely.
>
> Is there any particular objection to requiring packagers upload both
> architectures?
>
> Allan
>
>
>
>

-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
https://www.archlinux.org 
tp...@archlinux.org

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
i...@st-martin-apo.de

[arch-dev-public] mkinitcpio some improvements and question on how kernel modules should be treated

[Tobias Powalowski via arch-dev-public]

Hi guys,
did some initcpio optimizing lately and implemented correct symlink
handling. This saves already some space.
https://bugs.archlinux.org/task/73439

Now one major problem left in recent initcpio, uncompressed modules:
https://github.com/archlinux/mkinitcpio/pull/25
https://bugs.archlinux.org/task/72882
At the moment modules are uncompressed during initcpio creation. This leads
to bigger RAM usage during boot, makes it a bit smaller on storage, due to
not recompress compressed modules. On small initrds for normal boot this is
not a big matter.

My measurement with all patches added:
Ramdisk size uncompressed modules: 13261677
Ramdisk size compressed modules: 13112083
(Note the compressed one is smaller due to the symlink patches added)
Unpacked initramfs uncompressed modules: 35 MB
Unpacked initramfs compressed modules:  26 MB
Using this on the biggest "initramfs testsuite" archboot shows the most
advantages.

If you like to test it on your own initramfs setup you can use:
https://gitlab.archlinux.org/tpowa/archboot/-/blob/master/usr/share/archboot/patches/31-initcpio.functions.fixed
for /usr/lib/initcpio/functions and recreate your initramdisk.

Now my question to the list, what should be the default how arch handles
modules in initramfs?
- Shall we leave the modules at compression level used during kernel build?
 --> This means the uncompression should be optional.
- Shall we still uncompress the modules always? (Status now)
--> Then using modules as is needs to be optional.

Thanks for you input.
greetings
tpowa
-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
https://www.archlinux.org 
tp...@archlinux.org

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
i...@st-martin-apo.de

Re: [arch-dev-public] mkinitcpio some improvements and question on how kernel modules should be treated

[Tobias Powalowski via arch-dev-public]

I have built a patched mkinitcpio to test:
https://pkgbuild.com/~tpowa/mkinitcpio-beta/


Am Di., 1. Feb. 2022 um 15:54 Uhr schrieb Tobias Powalowski <
tobias.powalow...@googlemail.com>:

> Hi guys,
> did some initcpio optimizing lately and implemented correct symlink
> handling. This saves already some space.
> https://bugs.archlinux.org/task/73439
>
> Now one major problem left in recent initcpio, uncompressed modules:
> https://github.com/archlinux/mkinitcpio/pull/25
> https://bugs.archlinux.org/task/72882
> At the moment modules are uncompressed during initcpio creation. This
> leads to bigger RAM usage during boot, makes it a bit smaller on storage,
> due to not recompress compressed modules. On small initrds for normal boot
> this is not a big matter.
>
> My measurement with all patches added:
> Ramdisk size uncompressed modules: 13261677
> Ramdisk size compressed modules: 13112083
> (Note the compressed one is smaller due to the symlink patches added)
> Unpacked initramfs uncompressed modules: 35 MB
> Unpacked initramfs compressed modules:  26 MB
> Using this on the biggest "initramfs testsuite" archboot shows the most
> advantages.
>
> If you like to test it on your own initramfs setup you can use:
>
> https://gitlab.archlinux.org/tpowa/archboot/-/blob/master/usr/share/archboot/patches/31-initcpio.functions.fixed
> for /usr/lib/initcpio/functions and recreate your initramdisk.
>
> Now my question to the list, what should be the default how arch handles
> modules in initramfs?
> - Shall we leave the modules at compression level used during kernel build?
>  --> This means the uncompression should be optional.
> - Shall we still uncompress the modules always? (Status now)
> --> Then using modules as is needs to be optional.
>
> Thanks for you input.
> greetings
> tpowa
> --
> Tobias Powalowski
> Archlinux Developer & Package Maintainer (tpowa)
> https://www.archlinux.org 
> tp...@archlinux.org
>
> St. Martin-Apotheke
> Herzog-Georg-Str. 25
> 89415 Lauingen
> https://www.st-martin-apo.de
> i...@st-martin-apo.de
>


-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
https://www.archlinux.org 
tp...@archlinux.org

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
i...@st-martin-apo.de

[arch-dev-public] Arch Linux Secure Boot support, get it done ;)

[Tobias Powalowski via arch-dev-public]

Hi guys,
next topic to step up: Secure Boot support
I wanted to bring this up to the mailing list to collect all info about the
status of SB support.
There are different approaches on how to implement SB.
My question first: Do we want a signed shim for Arch Linux?
If yes, how to achieve this? We should make a process in our infrastructure
and document what needs to be done and who does it.
Morten would you please add your thoughts about this topic on the ML, i
think you are most into SB on linux.
Thanks.
greetings
tpowa

-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
https://www.archlinux.org 
tp...@archlinux.org

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
i...@st-martin-apo.de

[arch-dev-public] possible mkinitcpio-31-3 package

[Tobias Powalowski via arch-dev-public]

Hi folks,
I would like to bring a new mkinitcpio package to [testing],
to finally cleanup my archboot initcpio workaround hacks.

Adressing the following issues on FS:

- Adding NEW parameter MODULES_DECOMPRESS to mkinitcpio.conf:
 https://bugs.archlinux.org/task/72882
 The old behaviour of decompressing modules stays the default

- Adding full symlink support:
 https://bugs.archlinux.org/task/73493

- Allow reproducable builds in case of /var/cache exists in initramfs:
 https://bugs.archlinux.org/task/73817

- Added zst firmware compression support for future kernel versions

The proposed patch to add is located here:
https://pkgbuild.com/~tpowa/symlink-compression.patch
Thanks for your feedback.
greetings
tpowa
-- 
Tobias Powalowski
Arch Linux Developer & Package Maintainer (tpowa)
https://www.archlinux.org
tp...@archlinux.org

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
i...@st-martin-apo.de

Re: [arch-dev-public] possible mkinitcpio-31-3 package

[Tobias Powalowski via arch-dev-public]

Hi
All paches now send as PR on github.
Thanks for reviewing them and if it moves to gitlab perhaps I could
get write access again to mkinitcpio git.

greetings
tpowa

Am Fr., 11. März 2022 um 14:34 Uhr schrieb Tobias Powalowski
:
>
> Hi folks,
> I would like to bring a new mkinitcpio package to [testing],
> to finally cleanup my archboot initcpio workaround hacks.
>
> Adressing the following issues on FS:
>
> - Adding NEW parameter MODULES_DECOMPRESS to mkinitcpio.conf:
>  https://bugs.archlinux.org/task/72882
>  The old behaviour of decompressing modules stays the default
>
> - Adding full symlink support:
>  https://bugs.archlinux.org/task/73493
>
> - Allow reproducable builds in case of /var/cache exists in initramfs:
>  https://bugs.archlinux.org/task/73817
>
> - Added zst firmware compression support for future kernel versions
>
> The proposed patch to add is located here:
> https://pkgbuild.com/~tpowa/symlink-compression.patch
> Thanks for your feedback.
> greetings
> tpowa
> --
> Tobias Powalowski
> Arch Linux Developer & Package Maintainer (tpowa)
> https://www.archlinux.org
> tp...@archlinux.org
>
> St. Martin-Apotheke
> Herzog-Georg-Str. 25
> 89415 Lauingen
> https://www.st-martin-apo.de
> i...@st-martin-apo.de



-- 
Tobias Powalowski
Arch Linux Developer & Package Maintainer (tpowa)
https://www.archlinux.org
tp...@archlinux.org

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
i...@st-martin-apo.de

Re: [arch-dev-public] possible mkinitcpio-31-3 package

[Tobias Powalowski via arch-dev-public]

Hi folks,
6 weeks later, is there a progress to release a new mkinitcpio now soon?
Thanks.
greetings
tpowa

-- 
Tobias Powalowski
Arch Linux Developer & Package Maintainer (tpowa)
https://www.archlinux.org
tp...@archlinux.org

Re: [arch-dev-public] possible mkinitcpio-31-3 package

[Tobias Powalowski via arch-dev-public]

The next 3 weeks later ...
any progress on the project release?
greetings
tpowa

Am Di., 19. Apr. 2022 um 11:10 Uhr schrieb Tobias Powalowski
:
>
> Hi folks,
> 6 weeks later, is there a progress to release a new mkinitcpio now soon?
> Thanks.
> greetings
> tpowa
>
> --
> Tobias Powalowski
> Arch Linux Developer & Package Maintainer (tpowa)
> https://www.archlinux.org
> tp...@archlinux.org



-- 
Tobias Powalowski
Arch Linux Developer & Package Maintainer (tpowa)
https://www.archlinux.org
tp...@archlinux.org

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
i...@st-martin-apo.de

Re: [arch-dev-public] possible mkinitcpio-31-3 package

[Tobias Powalowski via arch-dev-public]

Hi,
sorry but not getting any answer on IRC makes the impression it is
rather unmaintained.
I just wanted to know when I can expect the release, that was promised
for march also the move to gitlab has not yet happened.
greetings
tpowa

Am So., 8. Mai 2022 um 22:18 Uhr schrieb Kristian Klausen via
arch-dev-public :
>
> On 08.05.2022 21.52, Tobias Powalowski via arch-dev-public wrote:
> > The next 3 weeks later ...
> > any progress on the project release?
> > greetings
> > tpowa
>
> This is really not a topic for arch-dev-public, please discuss it
> directly with the maintainer, move the discussion to arch-projects or
> GitHub[1].
>
> [1] https://github.com/archlinux/mkinitcpio
>
> Cheers,
> Kristian Klausen



-- 
Tobias Powalowski
Arch Linux Developer & Package Maintainer (tpowa)
https://www.archlinux.org
tp...@archlinux.org

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
i...@st-martin-apo.de