linux-firmware: move MediaTek firmware

[Sapein]

Currently only some MediaTek firmware is moved.

Testing the changes

• I tested the changes in this PR: YES

[leahneukirchen]

Should also move

linux-firmware-20220209_1	/usr/lib/firmware/vpu_d.bin -> /usr/lib/firmware/mediatek/mt8173/vpu_d.bin
linux-firmware-20220209_1	/usr/lib/firmware/vpu_p.bin -> /usr/lib/firmware/mediatek/mt8173/vpu_p.bin

[leahneukirchen]

... that doesnt make sense. you need to move the symlinks, the targets are already there.

[sgn]

This looks sketchy

[Sapein]

... that doesnt make sense. you need to move the symlinks, the targets are already there.

Apologies, I had misread what you meant, but I'm still somewhat confused as to what is needed to be done. I'm somewhat new with this.

[paper42]

Please fix this PR, it should only contain one commit. If you have questions about this, we can help you on IRC.

[Sapein]

Please fix this PR, it should only contain one commit. If you have questions about this, we can help you on IRC.

Alright this should be fixed now. Apologies for the mess.

[nicegamer7]

Is there anything blocking this? It'd be nice to get this merged.

[JamiKettunen]

I believe @leahneukirchen's comment from March still applies, /usr/lib/firmware/vpu_{d,p}.bin are still not being moved to the -network subpackage as well.

[q66]

fwiw i don't think a bunch of the mediatek firmware should go to -network (notably the vpu_* stuff as that's not network-related at all)

there is also a lot of firmware in the main package that should go to -network though

[nicegamer7]

From a cursory glance, it looks like all the files in in the mediatek folder are network related, but the directories aren't.

[JamiKettunen]

Here's how Chimera Linux does it currently, maybe we could do something similar? would allow us to separate the network-related and ARM SoC specific files by moving the ladder to a linux-firmware-mediatek subpackage and then bringing rest of mediatek dir and mt7*.bin into linux-firmware-network.

Also this commit currently is very vague: linux-firmware: move MediaTek firmware, move them where? obviously into -network subpackage but it could be more specific for commit history readability

@Sapein are you interested in continuing (to fix) this PR?

[Sapein]

Here's how Chimera Linux does it currently, maybe we could do something similar? would allow us to separate the network-related and ARM SoC specific files by moving the ladder to a linux-firmware-mediatek subpackage and then bringing rest of mediatek dir and mt7*.bin into linux-firmware-network.

Also this commit currently is very vague: linux-firmware: move MediaTek firmware, move them where? obviously into -network subpackage but it could be more specific for commit history readability

@Sapein are you interested in continuing (to fix) this PR?

Hey, sorry for the disappearance, but yes I am still interested in continuing this PR and attempting to fix it. Part of the issue is that I am a bit unfamiliar with Packaging in general (and Void Linux packaging in particular), so I'm unsure how to go about fixing it. I can adjust the commit message to be something like: move MediaTek firmware into linux-firmware-network if desired, although I'm not sure how to best adjust the commit message.

[Sapein]

Here's how Chimera Linux does it currently, maybe we could do something similar? would allow us to separate the network-related and ARM SoC specific files by moving the ladder to a linux-firmware-mediatek subpackage and then bringing rest of mediatek dir and mt7*.bin into linux-firmware-network.

Also this commit currently is very vague: linux-firmware: move MediaTek firmware, move them where? obviously into -network subpackage but it could be more specific for commit history readability

@Sapein are you interested in continuing (to fix) this PR?

Hey, I've been trying to do some work locally, if I should split off the firmware into two packages, would I need two separate PRs? Additionally, what would I need to do to move the vpu_d.bin and vpu_p.bin files, as I'm unsure what to do with that in particular.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.