That's exactly what the job included in the craft-windows-x86-64-qt6.yml template does. If packageAppx
is True then the job creates an APPX package additionally to the other installers. (I saw that the documentation at https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/gitlab-templates/README.md could probably be improved. It does mention packageAppx, but it's not clear which template this is related to.)
The craft-windows-appx-qt6.yml template "Provides a job for publishing in the Microsoft Store" so it's only needed for publishing the APPX that's created by the job in the other template in the Microsoft Store.
So, this MR (if it targets master) could keep the change to the .craft.ini file, but it shouldn't add the template to the .gitlab-ci.yml.
This was missed in !138
Looks good to me.
I doubt that we want to publish unstable nightlies in the Microsoft Store. I think this MR should target 24.02.
I'm also not sure whether it's worth to enable the creation of APPX packages for master. I think it's a waste of resources. The exe installers are perfectly fine for the nightly builds. I think you can even install the unstable nightly exe installer next to a stable APPX.
Ingo Klöcker (31c0c16c) at 28 Mar 12:17
Yeah, that's historic. I chose the names of the config groups for the first service using those settings. Some settings are used by shared functionality so that I cannot change them for the AAB signer. In hindsight it may have been better to use more generic config group names. I'll consider cleaning this up in a follow-up MR.
Okay, I added all of kde/frameworks. Additionally, I merged the CI package list, added kirigami-addons and removed a few low-level packages that are anyway added transitively by Qt 6.
Ingo Klöcker (f1535dca) at 27 Mar 21:24
Use all of kde/frameworks, merge CI package list, and add kirigami-...
Ingo Klöcker (5cd45858) at 27 Mar 19:47
(for signing Android and Windows packages)
Looks good! I trust that you added the correct applicationid because I don't know how Krita's build scripts are going to use the signing service.
Thanks! Looks mostly good.
"should" is too strong. I suggest
`applicationid` only needs to be specified if the service is used for signing
APPX packages. If your project signs normal binaries only (.exe/.dll), then the
`applicationid` field can be omitted.
GnuPG-Bug-ID: 7020
Based on !138
Looks good. Just one final final comment.
This allows listing all card a certain subkey is stored on, which is not possible when only using GpgME api.
GnuPG-Bug-ID: 7020
Let's also decode percent-encoding just in case.
split.size() > 4 ? QString::fromUtf8(split[4]).trimmed().replace(QLatin1Char('+'), QLatin1Char(' ')).percentDecoded()