This requires somebody from @OpenSC/core to install the app to OpenSC in https://github.com/marketplace/packit-as-a-service

This can help us to get better test coverage on PRs on other linux than Ubuntu we have in GH Actions. We use this in various other projects already, but if you have questions or concerns, please let us know.

Linux distributions are highly fragmented and it's hard to keep track of all the changes. The OpenSC debian template file has not been touched and it seems not to be used anywhere. By adding a Fedora definition, I fear we will sooner or later also loose track of this.

I wish there was a more generic service that's capable of creating a/multiple package(s) for different distributions...

For example, https://github.com/valentindavid/pkcs11-demo creates a snap that works in different distributions. However, the snap's sandbox restrictions only allow exporting PKCS#11 via the p11-kit proxy...

I agree that Linux distributions are fragmented, but the majority is Debian/Ubuntu (we have some test coverage for that already) or Fedora/RHEL based. These are just two packaging formats, deb and rpm. Then there are couple of Arch based and Suse (rpm too) for completeness.

If you would go to the containers waters (yeah, snap is just a container with some wiring around), this is something considered cross-platform, but in reality, it works only on Ubuntu. In Fedora/RHEL, we have flatpak, which serves the similar purposes (but can access smart cards on the pcsc layer). But neither of these is very suitable for such low-level library as OpenSC, which is supposed to be used by other applications on the system. Ignoring the stability of the solution itself -- new Ubuntu starter using Firefox in snaps and since then I see it crashing all the time, the access to filesystem is limited and it has only one cursor icon.

But note that adding a spec file is not a goal of this PR. Having the tests running on different configuration (than the always outdated ubuntu image in Github Actions) is the goal.

I think I previously mentioned that there is a service to build for more different distros from Suse, called OpenBuildService, but I see that more like a publishing service, than something we can do CI on. See for example the darktable repository there: https://build.opensuse.org/project/show/graphics:darktable. In any case, if we would get interest from other distros we can indeed try something like that, but in Fedora/RHEL, we are more striving to keep things working together with the rest of the os, rather than having something generic, where one-size-fits-all, because it usually does not, as we could see recently with the pkcs11-register in Debian.

I don't mind having the packaging stuff here and having it actually maintained is even better 😉

Regarding the packages that this project publishes, I'd like to keep the user friction low. You named two packages formats, but that needs to be multiplied with the number of possible architectures and that doesn't even consider the possible problems with run time dependencies. Deciding which download to choose can be quite challenging, which is why I would opt for a one-size-fits-all solution for the releases, on this website.

But with regard to the official distribution channels, I fully agree that things should hand in hand. But, again, that's typically managed by a different stakeholder...

https://openbuildservice.org/2021/05/31/scm-integration/ at least looks like it could be integrated into CI some day...

So getting back to this PR, do you have some concerns about running packit as part of CI? It has at least advantage of running on fresh dependencies (glibc, gcc, ...) and different architectures. I hope last couple of years showed that we in Red Hat are able to maintain opensc :)

If there are no concerns, can somebody add the application (or give me the access to do so?)? I am in the opensc-maintainers, but not in core or owners of the repo to be able to do it myself.

I'll try to get you into the correct groups.

Update: Done.

Thanks @xhanulik for setting up the integration!

As far as I can tell, the free plan for packit-as-a-service can only be set up for personal accounts, not for organizations (i.e. OpenSC). @Jakuje, please have a second look, thank you!

@frankmorgner hi Frank, Packit dev here.

Our GitHub app is completely free and can be installed into the whole GitHub organization - most of our users utilize it like this.

I just tried the process for one of the orgs I'm part of:

1. Went to https://github.com/marketplace/packit-as-a-service
2. Navigated to "Pricing and setup"
3. Picked "Account: "
4. Clicked "Install it for free" which got me to a new page that confirmed it's indeed $0.00
5. Clicked install
6. Confirmed the organization repositories I want to install the app into

Haven't done this in a while and can completely see how complicated it can feel.

Please let me know if this helps.

P.S. thanks for the pointer to OBS, didn't know about their SCM integration

I tried that and as organization the charge would be 5$...

As account I've chosen the Organization OpenSC

I am part of different github organisations. "OpenSC team" is the only one that is not free (for packit) but 5$ as mentioned by @frankmorgner

I also see a "Current monthly bill $5.00" in https://github.com/organizations/OpenSC/settings/billing

I guess it is because we switched from the free github account a few years back to get higher download quotas or something like that.

Wow, this is the first time I see an upper-tier GitHub org. Please let me know if I can help in any way because this looks like it's outside of our control.

I guess it is because we switched from the free github account a few years back to get higher download quotas or something like that.

AFAIK this was because of the macos build artifacts that were larger than the 50MB (?) limit. But I think in the end we switched back and started splitting the binaries to the the 50MB chunks in https://github.com/OpenSC/OpenSC/blob/master/.github/push_artifacts.sh#L20

So are we actually in some different plan than the default/free one? Given that we are still open-source project, I do not see why we should be charted for using packit. Is there some channel to raise the issue with github for clarifications as a packit package owner?

I can see that GitHub has community support: https://support.github.com/features/organizations

Are you also being charged for using other apps? I.e. AppVeyor and LGTM analysis

@frankmorgner can you clarify if we still have the non-free github organization and if there is still a reason for that? I would be happy to look into that issue, but the state of the OpenSC organization is still not completely clear to me.

@TomasTomecek is there a way to integrate the packit without the installing the app, through the github actions?

We are mostly interested in running build based on the spec file in Fedora anyway, rather than in other more advanced features Packit provides. I read briefly through the integration options and given that there is a integration with the gitlab just with the Gitlab CI, it should not be that complicated.

My question is somebody tried this before and if I miss something obvious that would prevent it from working (as it looks like the installation of the app is not an option here).