re #1: ACK, understood. So, rpi-eeprom will stay around in "main" regardless.
re #2: Thanks for pointing out the Breaks/Replaces! The upstream raspberrypi-userland README states that it is deprecated and improved tools from raspi-utils should be used instead. So, what's the transitioning plan for raspberrypi-userland -> raspi-utils? Ideally, we would have only one of them in "main" at all times. Can the old package be demoted & dropped from the seeds? re #3: ACK, ignoring. re #4: see bug #2092065 (needs-packaging: kms++) => This also needs MIR, if we keep it as a Recommends here! re #5: Thanks, looks reasonable. Fix pending in https://code.launchpad.net/~r41k0u/ubuntu-manual-tests/+git/ubuntu- manual-tests/+merge/480718 re #6: - Fix for raspinfo (checking for elevated privileges, instead of calling sudo) pending in https://code.launchpad.net/~r41k0u/ubuntu/+source/raspi-utils/+git/raspi-utils/+merge/480344 - How about overlaycheck? You say it's meant to be used in a kernel git tree, that sounds very developer specific. Is this really something needed in "main"? Could it be split to a separate binary package that we keep in "universe" instead? re #7: ACK, team bug subscriber confirmed. re #8: see LP comment #6: have you considered some of those options for hardening the raspi-utils .service unit? Without knowing much about the context, there are some hardening options that sound generally useful, e.g.: - PrivateTmp= - PrivateUsers= - PrivateNetwork= - ProtectHome=vestigate if we can have some automated build-time tests. Thinking of the device-tree overlay merging util, - ProtectProc= - ProtectSystem= - PrivateDevices= # maybe this can be limited - DeviceAllow= # to just the device needed for flashing the eeprom? - ProtectKernelModules= - ProtectControlGroups= - ProtectKernelLogs= - NoNewPrivileges= - User=/DynamicUser= # can it run as non-root? - ProtectClock= re #9: ACK, thanks. Every little bit that can be tested automatically is better than nothing! Please reference/link the changes here, once ready. re #10: ACK, thanks. Please reference/link the lintian fixes here, once ready. re #11: Yes, consider my suggestion to be optional. It just feels weird pulling a tarball from the rpi.org deb repository instead of from the upstream project. re #12: ACK, thanks. Please reference/link the CMake fix here, once ready. re #13: ACK, fixed with GCC 14.2 (Noble+) see LP comment #8 Thank you for your continued work on this! This leaves us with the following tasks blocking the MIR: - #2 demote src:raspberrypi-userland? - #4 MIR kms++ (LP: #2092065) - #5 manual test plan pending in https://code.launchpad.net/~r41k0u/ubuntu-manual-tests/+git/ubuntu-manual-tests/+merge/480718 - #6 fix for raspinfo pending in https://code.launchpad.net/~r41k0u/ubuntu/+source/raspi-utils/+git/raspi-utils/+merge/480344, open question about overlaycheck -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2094805 Title: [MIR] raspi-utils To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/raspi-utils/+bug/2094805/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
