Description of problem: The upstream repo contains a tool to list subid ranges: https://github.com/shadow-maint/shadow/blob/master/src/list_subid_ranges.c but the compiled tool is not shipped in the RPM. Version-Release number of selected component (if applicable): shadow-utils-subid-devel-4.8.1-11 at least Expected results: That tool, or a similar one, available in the shadow-utils RPM or a sub-RPM. Additional info: This would be very useful to write integration tests for the FreeIPA feature.
(In reply to François Cami from comment #0) > Description of problem: > The upstream repo contains a tool to list subid ranges: > https://github.com/shadow-maint/shadow/blob/master/src/list_subid_ranges.c > but the compiled tool is not shipped in the RPM. > > > Version-Release number of selected component (if applicable): > shadow-utils-subid-devel-4.8.1-11 at least > > > Expected results: > That tool, or a similar one, available in the shadow-utils RPM or a sub-RPM. > > Additional info: > This would be very useful to write integration tests for the FreeIPA feature. SSSD QE needs this test program to test shadow-utils on component level anyway (even without SSSD/IPA) But I don't think QE automation justifies creation of new sub-package (as Iker approached this). Maybe we could include it directly into `shadow-utils-subid`, but at the very list we need a better name and I'm really not sure all users need it... I think it would be better to bundle source of this test program into QE automation and compile it "on the fly". We already solved this task with @aborah, let's sync with him.
FreeIPA upstream tests will require this, so it needs to be shipped in Fedora. As you mentioned, not all users will need this, so a subpackage is best.
(In reply to François Cami from comment #2) > FreeIPA upstream tests will require this, so it needs to be shipped in > Fedora. Maybe. SSSD QE could reuse it then. But first let me understand what's wrong with the approach to include source code of this test program alongside with tests?
> But first let me understand what's wrong with the approach to include source code of this test program alongside with tests? FreeIPA upstream CI consumes Fedora (rawhide + stable branches) and builds the freeipa packages on top of that before launching test suites. There is currently no facility to compile additional packages at this time. A COPR build could be used but that's far less practical than consuming whatever's available as RPM.
(In reply to François Cami from comment #4) > > But first let me understand what's wrong with the approach to include source code of this test program alongside with tests? > > FreeIPA upstream CI consumes Fedora (rawhide + stable branches) and builds > the freeipa packages on top of that before launching test suites. > There is currently no facility to compile additional packages at this time. You don't need to "compile a package". Just a single binary (merely `gcc list_subid_ranges.c -lsubid`). Source has to be patched a bit, but, as I wrote, this is solved. I really think IPA and SSSD QE should sync here.
Btw, it we will package and ship this tool, this will need to be done in RHEL as well for shadow-utils and SSSD gating.
Alexey, I don't want to argue there. Providing that tool would be useful for QE, support and end-users alike. How it works for FreeIPA: * upstream: a runner builds freeipa.spec and the resulting packages are installed on all test runners * downstream: packages are consumed. FreeIPA test runners typically do not have gcc installed. I still do not understand why you think requiring it to be compiled each time it is needed is better except to avoid shipping it downstream, and if you really do not want to ship downstream - I do advise to ship it, see above -, a simple condition in the spec file will do the job.
> I still do not understand why you think requiring it to be compiled each time it is needed is better I don't know yet what is better. From my point of view, this tool is a part of a test suite. Hence it fits tests better and doesn't justify new package (consisting of a single trivial tool). If we believe this is useful for support and users, then this is a different story. In this case I would vote to figure out appropriate name and ship directly in '-subid' package.
Alexey, Iker, For FreeIPA upstream test perspective it would be really better if the tool was part of Fedora. Downstream, I really do think that for support purposes we should ship it too. Renaming it beforehand is fine.
Another issue is that upstream this binary is wrapped in a libtool script - imo, this is not something we could ship "as is".
I've been speaking with Alexey and we've agreed to include the tool in Fedora. As he's already mentioned, nowadays the binary is wrapped in a libtool script and this is not an option for packaging. I have to take a look at another way of doing it.
The purpose of this tool is very similar to 'getent'. From my point of view, if we want to ship this tool, we should install it to `/usr/bin/` and create a man page. Ideally change to be done upstream. Currently 'list_subid_ranges' is in 'noinst_PROGRAMS' [1]. We should try to move it to 'bin_PROGRAMS' [2] (changing name to something like "getsubids" and making other required changes to get a plain binary). This might take some time. Meanwhile we could try this approach in COPR repo. [1] https://github.com/shadow-maint/shadow/blob/905eb76cecb11a9535d71f288f397baa9e5bea20/src/Makefile.am#L160 [2] https://github.com/shadow-maint/shadow/blob/905eb76cecb11a9535d71f288f397baa9e5bea20/src/Makefile.am#L26
(In reply to Alexey Tikhonov from comment #13) > > We should try to move it to 'bin_PROGRAMS' Actually, 'ubin_PROGRAMS'
COPR repository for a testing purpose: https://copr.fedorainfracloud.org/coprs/ipedrosa/list_subid_ranges/ (The binary is packaged in shadow-utils-examples with the name getsubids. )
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
master getsubids: system binary for user's sub*ids - 3b6ccf642c6bb2b7db087f09ee563ae9318af734
FEDORA-2021-380251ce99 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-380251ce99
FEDORA-2021-380251ce99 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-380251ce99` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-380251ce99 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-380251ce99 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.