On Tue, Sep 7, 2021 at 4:12 PM Arnaud Ferraris wrote: > Mostly scripts and config files, to give just a few examples: > - systemd config file fragments (journal size, power key handling...)
systemd journal size is automatically scaled as needed I thought, so configuring it shouldn't be needed, especially on a per-device basis. What does the power key handling config do? > - script + systemd service for configuring a USB gadget (net + serial) > through configfs IMO this should be switched over to using the libusbgx/gt infrastructure, although some work needs to be done on the system services of gt before that can happen I think. > - initramfs scripts & hooks Any examples? > - device-specific udev rules These should probably go into udev itself? > I'm not sure experimental is fundamentally better than a separate Mobian > repo for those packages Its closer to Debian at least. > Well that's part of the problem: some of those firmwares "magically" > popped on the internet, without anyone being able to tell the license > and whether they're actually redistributable, so they'll probably stick > to the mobian repo for a while. > > For the OnePlus 6 and Poco F1 we also have binary blobs extracted from > the devices' vendor partition, I'm not sure the legal implications of > extracting and distributing those files. It sounds like these are illegal for both Mobian and Debian to redistribute. > It's not a single repo, but a gitlab sub-group for device-specific > packages, such as: > - https://gitlab.com/mobian1/devices/sunxi64-linux > - https://gitlab.com/mobian1/devices/firmware-oneplus6 > - https://gitlab.com/mobian1/devices/pinetab-tweaks > - and so on... Hmm, I would have put those all into one repo. > I assume it mostly works on UEFI-based system, but I doubt it'll ever be > the case on ARM-based machines, unless we make it a device-tree > property? Maybe Guido has more insight about that point. UEFI is (becoming) the standard firmware on ARM devices, although of course many of them aren't following the standards. > Once this (and some other bits) is sorted out, this might be something I > could work on, yes. (no promise though, I don't know when I'll have time > for that Great, let me know if you need access to libusbgx/gt upstream. -- bye, pabs https://wiki.debian.org/PaulWise
