As a consequence of the hermetic-usr work, /etc/udev/rules.d is slowly
disappearing. This can results in errors like:
18:05:30.180191 hookfiles: unable to process hook file "/usr/share/mkinitfs/files/05-ci.files": unable to add "/etc/udev/rules.d": getFile: failed to stat file "/etc/udev/rules.d": stat /etc/udev/rules.d: no such file or directory (also tried "/etc/udev/rules.d.zst": stat /etc/udev/rules.d.zst: no such file or directory)
from
https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8863#note_563184
due to the directory not being present.
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8866>
Replace the dmabuf import patch with the two series that it grow into
during upstreaming, shipping in the next libcamera release. This will:
1. Improve performance for all devices using the GPU-ISP, including
those not able to use dmabuf import.
2. Simplify debugging.
3. Ensure the patches get enough testing before the upstream release.
While on it backport some additional patches:
1. A follow-up patch adding the last required step to allow dmabuf import
for input buffers to work in almost all cases *if* the V4L2 driver
handles custom bytesperline requests for bayer formats.
2. A small logging fix
3. A fix for bad bottom lines of pixels seen on some devices. This is
the only patch with visual impact - and a quite desirable one.
4. A patch to log the used driver for easier debugging.
This leaves us with only two downstream patches, both specific to the
PinePhone (OG).
Finally, add a "py3-$pkgname-pyc:pyc" subpackage in order to stay in
sync with the upstream package.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8650>
The lack of rationales for device categorization has lead to a lot of
discussions, misunderstandings, and frustrations, as of why the
requirements are the way they are. Even though it's always good to
keep improving and exploring ways to change our processes, having
rationales can help to explain the "why"s that do not really get
addressed by the "how"s of the actual requirements. Hopefully, this
will lead to less discussions and misunderstandings around the
specific requirements.
Closes https://gitlab.postmarketos.org/postmarketOS/postmarketos/-/work_items/146
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8595>
This fixes two issues:
1. I was investigating why currently, pmbootstrap build --force
libcamera would fail. It turns out that the problem was possible to
reduce down to apk add eudev-dev resulting in installing eudev-dev
instead of systemd-dev, even with the systemd repository enabled.
This is because apk actually thinks it has a higher version:
name <eudev-dev> selected from selectable list
select_package: eudev-dev (requirers=1, autosel=1, iif=0, order_id=0x40005807)
consider systemd-dev-261_rc4-r0 iif_triggered=0, tag_ok=1, selectable=1, available=1, flags=0x0, provider_priority=100, installed=0
prefer existing package
choose as new provider
consider eudev-dev-3.2.14-r6 iif_triggered=0, tag_ok=1, selectable=1, available=1, flags=0x0, provider_priority=100, installed=0
select latest by requested name (greater)
choose as new provider
consider libudev-zero-dev-1.0.4-r0 iif_triggered=0, tag_ok=1, selectable=1, available=1, flags=0x0, provider_priority=20, installed=0
select latest by requested name (less)
selecting: eudev-dev-3.2.14-r6, available: 1
assign eudev-dev to eudev-dev-3.2.14-r6
disqualify_package: systemd-dev-261_rc4-r0 (conflicting provides)
disqualify_package: libudev-zero-dev-1.0.4-r0 (conflicting provides)
And why is that? It's because we have two providers here: One is
eudev-dev with a provider version of 3.2.14-r6, and the other is
systemd-dev with a provider version that is empty. This then results
in apk thinking the version number is greater, as seen above in the
verbose output. An unversioned provides= for an exact package name
match will never, ever, ever have any effect, even if the priority is
set super high, because the version number comparison is before apk
even starts looking at provider priorities.
Therefore, we should not have unversioned provides for eudev,
eudev-dev, eudev-libs and udev. Since those have fairly low version
numbers, we can just provide them with systemd's version number and
we'll be fine. This will now result in apk actually installing
systemd-dev when eudev-dev is prompted for installation.
2. After fixing the aforementioned issue, I noticed that I couldn't
build anything anymore. This is because my dependency tree would pull
in systemd and systemd-udev - completely normal. However, both
systemd and systemd-udev were providing eudev, and apk will refuse to
install two packages that provide the same thing at the same time.
The fix for this is to just not provide eudev in the top-level
systemd package and rather let systemd-udev do that.
With this, I can now finally build libcamera again!
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8857>
initramfs starts USB NCM gadget and unudhcpd for SSH login.
This requires special handling since unudhpcd is unmanaged by the
service manager until the userspace is started. Once entered in userspace,
the usb-moded-developer-mode needs to be activated which configures
NetworkManager and starts unudhcpd under the service manager.
This way, a full handover is possible and the gadgets can be properly
switched without any leftovers from the initramfs due to the unmanaged
situation.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8553>
Persisted_Captules.sh is huge (70 MB) and can cause boot-deploy failures
when doing transactions that do large modifications to `/boot/`, such as
switching kernel packages. Persisted_Capsules.sh is recreated on reboot
and we do not use it for anything currently, so it is safe to remove in a
hook.
Signed-off-by: Aster Boese <asterboese@mailbox.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8368>
Adds support for the kernels in main (lts, mainline, stable) and removes
support for linux-postmarketos-qcom-laptop after discussion with the
kernel's maintainers, as it is most likely going to be dropped, or at
least moved to testing.
Signed-off-by: Aster Boese <asterboese@mailbox.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8368>
This adds two new subpackages, one pulls in in gnome software and the
other pulls in bazaar. Both subpackages provide a new virtual
(gnome-app-provider), and the main base GNOME UI pkg now depends on
this virtual. This allows us to ship bazaar in Duranium instead of GNOME
Software, and to continue to use GNOME Software by default on mutable
pmOS.
Previously there was an "optional" dependency on a sw
app provider (gnome-software, via pmb_recommends), but I made it a hard
dependency now because:
1) I think users can expect *some* app store thing to be available
by default, and the number of users who would remove all of them is
probably approaching 0
2) Ignoring pmb_recommends made the rest of this easier to implement,
since I'm not entirely sure how pmb would react to a virtual provided
by the pkg it is processing pmb_recommends for, and I didn't want to
find out.
Fixes#4634
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8831>
