This adds eg25-manager for managing modem power in userspace instead of
relying on the modem-power stuff in the kernel. The userspace
eg25-manager has proven to be more reliable than using modem-power.
An older setup-modem script is installed for ofono, since eg25-manager
cannot interface with ofono (yet).
The eg25 init script was removed since it only dealt with configuring
the modem-power driver in the kernel
[ci:skip-build]: already built successfully in CI
Alpine's abuild is soon going to complain if an APKBUILD has more than
one "Maintainer:" listed. Work around it by renaming the additional
maintainers to "Co-Maintainer:". While at it, move the devicepkg reference
link to the top in device-xiaomi-santoni for consistency.
In postmarketOS, we require at least two maintainers for devices in
main, therefore it does not make sense to drop additional maintainers
from the file.
In Alpine, this change was made because pkgs.alpinelinux.org apparently
can't handle more than one maintainer. I looked into it, and it would
require a database change to add it there, so it does not seem worth the
effort. I also thought about extending abuild to add an environment
variable to skip the check, but then the package would not build with
plain abuild without using the env var.
Related: dd4cd9d606
[ci:skip-build] [ci:skip-vercheck]
At the moment we have Contributor: lines on some packages (but not all of them),
but often they don't represent the actual contributors to the package very well.
E.g. when we added them retroactively to the device packages we only added
the initial contributor (which isn't necessarily the person
who made most of the work for a device...)
The Git history is the most representative source for figuring out
who contributed to a package, so there is no reason to duplicate that
into the APKBUILD.
[skip ci]: way too many packages
For testing changes for device categorization, it is useful to have
a device in each of the categories. The PinePhone is close to being
moved to main/, but it doesn't fulfill all requirements yet.
The QEMU "device ports" are very simple since QEMU currently only
emulates a rather limited set of hardware features. All available features
are working correctly (especially after the recent rework of the QEMU
packages). I suppose it is also usable as a "daily driver", at least for
its intended purpose (a virtual machine for testing postmarketOS changes). :)
Given that everyone can run QEMU, everyone could potentially maintain
it. For now I have added myself as maintainer since I did most of the
recent cleanup. Add drebrez as second maintainer.
Overall it seems useful to have qemu-* in main/, especially because
it is now the device that is selected by default in pmbootstrap.
