[gentoo-soc] Gentoo musl Support Expansion for Qt/KDE Week 9

[gentoo-soc] Gentoo musl Support Expansion for Qt/KDE Week 9

[cat]

This week I’ve tested every application in the kde-apps-meta meta package, I have also spent a lot of time learning ebuild development tooling by working with the mauikit ebuilds.


To start with I’ll talk about the mauikit ebuilds, and more generally using tools related to ebuild development. I had look over a lot of dependencies, and making sure that I had no unneeded deps. So I learned how to use things like iwdevtools, lddtree, and scanelf. A limitation of iwdevtools is that it can only look for linked libraries and not things like QML plugins. So I decided to make my own tool I call “ehide”.


Ehide hides dependencies from the system, so you can run applications and see if they actually need the dependencies or not. It works by creating a new mount namespace, then enumerates files via ‘equery files ‘, then checks if it’s a file with stat(2) and finally bind mounts /dev/null to the files and spawns a new shell in the created namespace. This shell can now run commands and programs as if the dependency wasn’t on the system to begin with. Creating a new mount namespace with unshare(CLONE_NEWNS) required CAP_SYS_ADMIN. So I also learned how to check for capabilities with libcap, as well as setting capabs with fcaps.eclass in my ebuild. All in all I learned a lot when working with this.



Example of how I used it with Clip:
 1) $ qa-vdb clip
 dev-qt/qtmultimedia:5 <
 # This indicates that qtmultimedia may be a wrong/unneeded RDEPEND, let’s verify with ehide.
 2) $ ehide qtmultimedia
 3) (from spawned shell) $ clip
 CREATING INSTANCE OF MAUI APP
 QQmlApplicationEngine failed to load component
 qrc:/main.qml:5:1: module “QtMultimedia” is not installed
 This means that QtMultimedia is in fact required!



It also works with multiple atoms, just like you’d expect. Sam had an idea of integrating it into Portage so that you could hide every non-dependency of a package, to make sure that you have exactly the dependencies you need in the ebuild, no more, no less. Think the inverse of emerge –emptytree, and the “universe” being world.


Back to the ebuilds themselves: they are mostly finished but I just need to clean up the commits so it becomes one commit per package. This is probably easiest to do by just copying the ebuilds to some temp dir, git reset –hard, and then copying back and commiting one by one. But I feel like untangling this with git-rebase and friends is probably really good for me to further learn using git.


The second thing I did was kde-apps-meta testing. Most things just worked except for these following packages: Postgres, poxml, FreeRDP, and Okular. Poxml was actually an old error related to a gettext issue me and Sam spent a lot of time working on, but it’s still not fixed. (Upstream bug: https://savannah.gnu.org/bugs/?62659). So that leaves Postgres, FreeRDP and Okular, though I’ve used Okular and it works just fine. So I will start working on Postgres and FreeRDP next week, and do Okular last. I’ll also mention here that the Konsole test from two weeks ago is still not fixed https://bugs.gentoo.org/862594.


When I first wanted to emerge kde-apps-meta with FEATURES=test I wanted a way to emerge deps of deps. Much like –emptytree but with a specified max depth. This is because kde-apps-meta depends on other meta packages like kde-apps/kdeaccessibility-meta, kde-apps/kdeadmin-meta, and kde-apps/kdeedu-meta. I did some initial work on a tool I called rdeps which is used like “emerge $(rdeps kde-apps-meta 2)”. It kind of worked but it had some bugs. As I just wanted to emerge my packages and not spend too much time I instead made a much simpler program used like this: ’emerge $(rdeps “$(rdeps kde-apps-meta)”)’ which worked!


Looking back at this week I feel like I’ve learnt a whole lot, especially regarding ebuild development and how to properly check for *DEPENDS. To summarize I’ve ran test suites for kde-apps-meta, wrote two ebuild development applications, and almost finished writing the mauikit ebuilds. Personally I feel like I’ve done relatively little actual work but a whole lot of learning compared to previous weeks.


Today I will continue playing a bit with my PinePhone so I can get an initial sketch of my PPP Gentoo musl guide as requested. I got some help from megi debugging a levinboot buildtime issue, so I’ll go for that instead of Tow-boot since it has a very annoying charging bug fixed. Megi is a developer who does the majority of the low level PinePhone Pro work.


Next week I’ll untangle the mauikit ebuild commits, fix Postgres, poxml, FreeRDP, and Okular tests, and also work on getting accountsservice rewritten. In my proposal schedule next week is actually about getting test suites to run for kde-apps-meta, so I am right on schedule!

Re: [gentoo-soc] Gentoo musl Support Expansion for Qt/KDE Week 9

[cat]

Huh, apparently the blog inputted a lot of extra spaces.
oh well


Aug 15, 2022, 01:22 by cat@catcream.org:

>
> This week I’ve tested every application in the kde-apps-meta meta package, I have also spent a lot of time learning ebuild development tooling by working with the mauikit ebuilds.
>
>
> To start with I’ll talk about the mauikit ebuilds, and more generally using tools related to ebuild development. I had look over a lot of dependencies, and making sure that I had no unneeded deps. So I learned how to use things like iwdevtools, lddtree, and scanelf. A limitation of iwdevtools is that it can only look for linked libraries and not things like QML plugins. So I decided to make my own tool I call “ehide”.
>
>
> Ehide hides dependencies from the system, so you can run applications and see if they actually need the dependencies or not. It works by creating a new mount namespace, then enumerates files via ‘equery files ‘, then checks if it’s a file with stat(2) and finally bind mounts /dev/null to the files and spawns a new shell in the created namespace. This shell can now run commands and programs as if the dependency wasn’t on the system to begin with. Creating a new mount namespace with unshare(CLONE_NEWNS) required CAP_SYS_ADMIN. So I also learned how to check for capabilities with libcap, as well as setting capabs with fcaps.eclass in my ebuild. All in all I learned a lot when working with this.
>
>
>
> Example of how I used it with Clip:
>  1) $ qa-vdb clip
>  dev-qt/qtmultimedia:5 <
>  # This indicates that qtmultimedia may be a wrong/unneeded RDEPEND, let’s verify with ehide.
>  2) $ ehide qtmultimedia
>  3) (from spawned shell) $ clip
>  CREATING INSTANCE OF MAUI APP
>  QQmlApplicationEngine failed to load component
>  qrc:/main.qml:5:1: module “QtMultimedia” is not installed
>  This means that QtMultimedia is in fact required!
>
>
>
> It also works with multiple atoms, just like you’d expect. Sam had an idea of integrating it into Portage so that you could hide every non-dependency of a package, to make sure that you have exactly the dependencies you need in the ebuild, no more, no less. Think the inverse of emerge –emptytree, and the “universe” being world.
>
>
> Back to the ebuilds themselves: they are mostly finished but I just need to clean up the commits so it becomes one commit per package. This is probably easiest to do by just copying the ebuilds to some temp dir, git reset –hard, and then copying back and commiting one by one. But I feel like untangling this with git-rebase and friends is probably really good for me to further learn using git.
>
>
> The second thing I did was kde-apps-meta testing. Most things just worked except for these following packages: Postgres, poxml, FreeRDP, and Okular. Poxml was actually an old error related to a gettext issue me and Sam spent a lot of time working on, but it’s still not fixed. (Upstream bug: https://savannah.gnu.org/bugs/?62659). So that leaves Postgres, FreeRDP and Okular, though I’ve used Okular and it works just fine. So I will start working on Postgres and FreeRDP next week, and do Okular last. I’ll also mention here that the Konsole test from two weeks ago is still not fixed https://bugs.gentoo.org/862594.
>
>
> When I first wanted to emerge kde-apps-meta with FEATURES=test I wanted a way to emerge deps of deps. Much like –emptytree but with a specified max depth. This is because kde-apps-meta depends on other meta packages like kde-apps/kdeaccessibility-meta, kde-apps/kdeadmin-meta, and kde-apps/kdeedu-meta. I did some initial work on a tool I called rdeps which is used like “emerge $(rdeps kde-apps-meta 2)”. It kind of worked but it had some bugs. As I just wanted to emerge my packages and not spend too much time I instead made a much simpler program used like this: ’emerge $(rdeps “$(rdeps kde-apps-meta)”)’ which worked!
>
>
> Looking back at this week I feel like I’ve learnt a whole lot, especially regarding ebuild development and how to properly check for *DEPENDS. To summarize I’ve ran test suites for kde-apps-meta, wrote two ebuild development applications, and almost finished writing the mauikit ebuilds. Personally I feel like I’ve done relatively little actual work but a whole lot of learning compared to previous weeks.
>
>
> Today I will continue playing a bit with my PinePhone so I can get an initial sketch of my PPP Gentoo musl guide as requested. I got some help from megi debugging a levinboot buildtime issue, so I’ll go for that instead of Tow-boot since it has a very annoying charging bug fixed. Megi is a developer who does the majority of the low level PinePhone Pro work.
>
>
> Next week I’ll untangle the mauikit ebuild commits, fix Postgres, poxml, FreeRDP, and Okular tests, and also work on getting accountsservice rewritten. In my proposal schedule next week is actually about getting test suites to run for kde-apps-meta, so I am right on schedule!
>