snapcraft

KDE neon: KDE neon is extremely important to the KDE snaps eco-system as I briefly mentioned in my last post. Why? KDE neon is based on Jammy LTS which is the same as Core 22 base for snaps. Neon has a very useful continuous integration system in place that tests all the things, including dependencies, qml, cmake errors, debian packaging lintian tool and the list go on. This is very important to get packages out that don’t break things on user desktops. Once the packages are a lovely shade of green on the neon CI ( or at least all the important issues are resolved ) it is in good shape for snapping. I have scripts that pull the build and runtime dependency information for our application package to use in the snapcraft.yaml. We know this list is complete, because it passed the tests! As applications gain features, they requires newer dependencies than what is provided in the ubuntu jammy repositories. Neon builds those newer dependencies and provides them to our users in the neon aptly repositories. It is much easier and more reliable than tracking down PPAs and hoping they stay maintained. We use the neon user edition repository in our snapcraft file to ensure we are up to date on KDE applications dependency needs. This week my work in Neon included turning jobs green and fixing kio-gdrive which is still qt5, but it’s dependency libkgapi is qt6! We have to provide both versions in cases like this which entails tracking both master and the qt5 release branch. Snaps: This week begun the big transition from single repository remote-builds to per repository snapcraft and using snap recipes on launchpad. This is an important move for a couple of reasons. We were having major issues with build failures as I pointed out in this bug report on launchpad: https://bugs.launchpad.net/launchpad/+bug/2031307 . This was due to the way remote-build works. It creates temporary snap recipes that builds once and sends back the snap or failure status. This made it very difficult to debug build failures as once the failure status was sent the job disappeared off of launchpad, taking all build logs with it. Now with the per repository snapcraft files, I have set up proper snap recipes on launchpad and the builds are automated by polling the github mirror for changes and it publishes the shiny new snap to candidate for testing or sends me the failure log that I can view at my convenience. This of course is a work in progress as we have 186 snaps currently and there are a few steps to get each one done. But once it is done, it will reduce my workload immensely and make debugging build issues faster. While making the move, I am also updating the snapcraft files for changes within snapcraft, adding cleanup to decrease bloat and fixing bugs! Snap move complete: Current WIP: Audiotube, Digikam, Cantor, Neochat I also made a new content pack with KDE frameworks 5.110, but a new Qt 5.15.11 was just released so I will be making a new one tomorrow. The kf6 content snap has come to a halt as the qt6 content snap has stalled. I asked to be given access to the snapcraft file so that I may collaborate, but have not heard back. My mysterious project has reached its end for me. I might get a part time gig doing snaps out of it, but I do not meet the requirements to do any of the engineering of it. It is what it is. Thank you to all who vouched for me, alas it wasn’t meant to be. If you can spare some change, I would appreciate it, especially to pay my phone/Internet bill so I can do more Neon and snaps 🙂 Thank you for stopping by. Donate https://gofund.me/b8b69e54