Bug 1888195

Of course I'm willing to help, but I'm afraid I don't know exactly what to do, e.g. where to file a request or do the work myself. If you can point me to some docs, I'll be glad to also release python3-lasso.

I don't know if there is some internal doc (not aware of it) but I guess someone is responsible to have asked to *not* pushed built packages somehow (and FWIW, it's also impacting plenty of RH projects building upstream projects RPMS through cbs.centos.org koji, also suffering from same issue) .. unfortunately I don't know who took decision to block some packages and I was hoping that maintainer would know :-)

I have a feeling that Josh would be able to help here.

Josh, could we get this added to at least CRB if not AppStream proper?

Here is the documentation we have for requesting unshipped packages.

https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages

Good news, step 1 is already done with this bugzilla.  I'm changing the version of this to CentOS Stream, as that is where it would happen first if accepted.

@carl : great news .. I can temporary use a workaround (like all SIGs are doing : building src.rpm through cbs.centos.org, and then untag it once it becomes available in PowerTools or Devel)

(In reply to Neal Gompa from comment #3)
> I have a feeling that Josh would be able to help here.
> 
> Josh, could we get this added to at least CRB if not AppStream proper?

I don't think CRB is really appropriate here.  It's a python binding likely needed at runtime.

In the Ipsilon case, it's a BuildRequires: https://src.fedoraproject.org/rpms/ipsilon/blob/master/f/ipsilon.spec#_35 *and* Requires: https://src.fedoraproject.org/rpms/ipsilon/blob/master/f/ipsilon.spec#_116

(In reply to Josh Boyer from comment #7)
> (In reply to Neal Gompa from comment #3)
> > I have a feeling that Josh would be able to help here.
> > 
> > Josh, could we get this added to at least CRB if not AppStream proper?
> 
> I don't think CRB is really appropriate here.  It's a python binding likely
> needed at runtime.

You're right, but I figure CRB is the easy ask. Obviously I'd rather see it in AppStream proper.

(In reply to Josh Boyer from comment #7)
> (In reply to Neal Gompa from comment #3)
> > I have a feeling that Josh would be able to help here.
> > 
> > Josh, could we get this added to at least CRB if not AppStream proper?
> 
> I don't think CRB is really appropriate here.  It's a python binding likely
> needed at runtime.

Right, sorry, this was not clear to me from the start either. Even though this might be dumb question -- there is no way to release an additional runtime subpackage in CentOS only?

(In reply to Jakub Hrozek from comment #11)
> (In reply to Josh Boyer from comment #7)
> > (In reply to Neal Gompa from comment #3)
> > > I have a feeling that Josh would be able to help here.
> > > 
> > > Josh, could we get this added to at least CRB if not AppStream proper?
> > 
> > I don't think CRB is really appropriate here.  It's a python binding likely
> > needed at runtime.
> 
> Right, sorry, this was not clear to me from the start either. Even though
> this might be dumb question -- there is no way to release an additional
> runtime subpackage in CentOS only?

Not a dumb question.  There is not.

(In reply to Jakub Hrozek from comment #11)
> 
> Right, sorry, this was not clear to me from the start either. Even though
> this might be dumb question -- there is no way to release an additional
> runtime subpackage in CentOS only?

Can you elaborate please ? Do you mean building (and providing) through EPEL8 a pkg (based on same .spec from something *already* built) that would just in epel provide the pkg that are forbidden to be released publicly ?
And so satisfy deps for Requires:/BuildRequires: for other pkgs in epel8 (and so able to rebuild ipsilon for the noggin/IPA migration for Fedora/CentOS)?
FWIW, currently we use a copr repo with lasso simply rebuilt to be able to test our integration scripts with noggin/IPA but of course we'd probably want to depend on properly built/released pkg content before the real migration (fwiw, copr repo is https://copr.fedorainfracloud.org/coprs/arrfab/noggin/packages/ )

Just coming back for news, as it will also be impacting Stream , now that we'll have to switch from CentOS 8 to CentOS Stream in the following months.
Have to also discuss with Fedora infra (as we're now one team and we'll migrate authentication to *same* platform/IPA instance)

Can we get an ETA about releasing built sub-pkg needed for ipsilon and unblock CentOS and Fedora infra ? don't want to have to maintain a parallel copr repo just for this

Official migration for CentOS and Fedora is approaching (for AAA/IPA) and I'd like to *not* deploy through a temporary pkg built through copr.
Can we get a status update on this ticket please ? 

Thanks

just coming back on this, as I see that we're migrating CentOS auth next week (Fedora was done this week), and so we'll probably have to use the copr workaround
But at the same time , I see that it was tagged with "FutureFeature", so can we still hope that python3-lasso would be authorized to land in public repositories ? that would then unblock the ipsilon pkg build for epel8
That would be awesome

Hi Neal,


I need help either running the tests that I see in tests/integration or with writing new tests to cover some basic use cases.  In order for us to be able to accept this into RHEL, I have to be able to provide some basic level of gating.  At the moment, I don't have capacity to do this on my own.  So I would need help at least providing the initial tests to use for this purpose.

Would you be able to help me with automating tests for this if it is accepted?

Thanks,
Scott

(In reply to Scott Poore from comment #18)
> Hi Neal,
> 
> 
> I need help either running the tests that I see in tests/integration or with
> writing new tests to cover some basic use cases.  In order for us to be able
> to accept this into RHEL, I have to be able to provide some basic level of
> gating.  At the moment, I don't have capacity to do this on my own.  So I
> would need help at least providing the initial tests to use for this purpose.
> 
> Would you be able to help me with automating tests for this if it is
> accepted?
> 

I could try to help, but I'm not entirely sure how to do it either right now.

Ipsilon uses LASSO for SAML2 support, which was largely written by Simo Source and Rob Crittenden: https://pagure.io/ipsilon/history/ipsilon/providers/saml2?identifier=master

Perhaps one of those two could help?

The upstream tests are executed during the build process in the make check step.

These can be the tier0 tests. For an example of running make check as a gating test see the RHEL certmonger package.

I am able to setup tier0 level tests using the same method as certmonger to run the existing make check as Rob suggested.  

I was unable to get the upstream repo's "integration" tests running due to what appear to be old (no longer available?) dependencies.  

We can accept this but, testing for it will be limited.

Verified

Version ::

python3-lasso-2.6.0-13.el8.x86_64

Results ::

# dnf --disablerepo=* --enablerepo=rhel-AppStream list python3-lasso
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

Last metadata expiration check: 0:03:51 ago on Wed 25 May 2022 10:07:49 AM EDT.
Available Packages
python3-lasso.x86_64                            2.6.0-13.el8                             rhel-AppStream

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (lasso bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7559