[openstack-dev] Help with getting keystone to migrate to Debian testing: fixing repoze.what and friends
Jamie Lennox
jamielennox at gmail.com
Thu Nov 12 23:28:06 UTC 2015
On 12 November 2015 at 15:09, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from Clint Byrum's message of 2015-11-11 10:57:26 -0800:
> > Excerpts from Morgan Fainberg's message of 2015-11-10 20:17:12 -0800:
> > > On Nov 10, 2015 16:48, "Clint Byrum" <clint at fewbar.com> wrote:
> > > >
> > > > Excerpts from Morgan Fainberg's message of 2015-11-10 15:31:16 -0800:
> > > > > On Tue, Nov 10, 2015 at 3:20 PM, Thomas Goirand <zigo at debian.org>
> wrote:
> > > > >
> > > > > > Hi there!
> > > > > >
> > > > > > All of Liberty would be migrating from Sid to Testing (which is
> the
> > > > > > pre-condition for an upload to offical Debian backports) if I
> didn't
> > > > > > have a really annoying situation with the repoze.{what,who}
> packages.
> > > I
> > > > > > feel like I could get some help from the Python export folks
> here.
> > > > > >
> > > > > > What is it about?
> > > > > > =================
> > > > > >
> > > > > > Here's the dependency chain:
> > > > > >
> > > > > > - Keystone depends on pysaml2.
> > > > > > - Pysaml2 depends on python-repoze.who >=2, which I uploaded to
> Sid.
> > > > > > - python-repoze.what depends on python-repoze.who < 1.99
> > > > > >
> > > > > > Unfortunately, python-repoze.who doesn't migrate to Debian
> Testing
> > > > > > because it would make python-repoze.what broken.
> > > > > >
> > > > > > To make the situation worse, python-repoze.what build-depends on
> > > > > > python-repoze.who-testutil, which itself doesn't work with
> > > > > > python-repoze.who >= 2.
> > > > > >
> > > > > > Note: repoze.who-testutil is within the package
> > > > > > python-repoze.who-plugins who also contains 4 other plugins
> which are
> > > > > > all broken with repoze.who >= 2, but the others could be dropped
> from
> > > > > > Debian easily). We can't drop repoze.what completely, because
> there's
> > > > > > turbogears2 and another package who needs it.
> > > > > >
> > > > > > There's no hope from upstream, as all of these seem to be
> abandoned
> > > > > > projects.
> > > > > >
> > > > > > So I'm a bit stuck here, helpless, and I don't know how to fix
> the
> > > > > > situation... :(
> > > > > >
> > > > > > What to fix?
> > > > > > ============
> > > > > > Make repoze.what and repoze.who-testutil work with repoze.who >=
> 2.
> > > > > >
> > > > > > Call for help
> > > > > > =============
> > > > > > I'm a fairly experienced package maintainer, but I still consider
> > > myself
> > > > > > a poor Python coder (probably because I spend all my time
> packaging
> > > > > > rather than programming in Python: I know a way better other
> > > programing
> > > > > > languages).
> > > > > >
> > > > > > So I would enjoy a lot having some help here, also because my
> time is
> > > > > > very limited and probably better invested working on packages to
> > > assist
> > > > > > the whole OpenStack project, rather than upstream code on some
> weirdo
> > > > > > dependencies that I don't fully understand.
> > > > > >
> > > > > > So, would anyone be able to invest a bit of time, and help me
> fix the
> > > > > > problems with repoze.what / repoze.who in Debian? If you can
> help,
> > > > > > please ping me on IRC.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Thomas Goirand (zigo)
> > > > > >
> > > > > >
> > > > > It looks like pysaml2 might be ok with < 1.99 of repoze.who here:
> > > > > https://github.com/rohe/pysaml2/blob/master/setup.py#L30
> > > > >
> > > > > I admit I haven't tested it, but the requirements declaration
> doesn't
> > > seem
> > > > > to enforce the need for > 2. If that is in-fact the case that > 2
> is
> > > > > needed, we are a somewhat of an impass with dead/abandonware
> holding us
> > > > > ransom. I'm not sure what the proper handling of that ends up
> being in
> > > the
> > > > > debian world.
> > > >
> > > > repoze.who doesn't look abandoned to me, so it is just repoze.what:
> > > >
> > > > https://github.com/repoze/repoze.who/commits/master
> > > >
> > > > who's just not being released (does anybody else smell a Laurel and
> > > > Hardy skit coming on?)
> > >
> > > Seriously!
> > >
> > > >
> > > > Also, this may have been something temporary, that then got left
> around
> > > > because nobody bothered to try the released versions:
> > > >
> > > >
> > >
> https://github.com/repoze/repoze.what/commit/b9fc014c0e174540679678af99f04b01756618de
> > > >
> > > > note, 2.0a1 wasn't compatible.. but perhaps 2.2 would work fine?
> > > >
> > > >
> > >
> > > Def something to try out. If this is still an outstanding issue next
> week
> > > (when I have a bit more time) I'll see what I can do to test out the
> > > variations.
> >
> > FYI, I tried 2.0 and it definitely broke repoze.what's test suite. The
> API
> > is simply incompatible (shake your fists at whoever did that please). For
> > those not following along: please make a _NEW_ module when you break
> > your API.
> >
> > On the off chance it could just be dropped, I looked at turbogears2, and
> > this seems to be the only line _requiring_ repoze.what-plugins:
> >
> >
> https://github.com/TurboGears/tg2/blob/development/tg/configuration/app_config.py#L1042
> >
> > So I opened this issue:
> >
> > https://github.com/TurboGears/tg2/issues/69
> >
> > Anyway, it seems like less work to just deprecate this particular feature
> > that depends on an unmaintained library (which should be grounds enough
> > to remove python-repoze.what and python-repoze.what-plugins). Then the
> > dep can be dropped from python-turbogears2 and tg2-devtools.
>
> The TurboGears developers were quick to point out that they have not
> recommended this approach for a long time, and that the code doesn't
> require the presence of repoze.what anymore.
>
> I've opened the following bugs in Debian, which, if they all are fixed,
> will result in keystone being unblocked into testing:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804809
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804810
>
> And this one would save python-repoze.what, but would require massive
> changes. Not fixing it will result in it never going into testing, so it
> may be better to mark it RC, but I want to see if anybody responds with
> code first.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804811
>
> So, as long as nobody gets super excited about keeping
> repoze.what-plugins support in TurboGears, this should resolve soon.
Whilst this won't help packaging anything short term it should be pointed
out that repoze in pysaml2 is there for an example of integration and there
*shouldn't* be any actual pysaml2 functionality that requires
repoze.anything. Unfortunately the maintainer packages the repoze
integration plugins in the same repo. We could always look to try and get
upstream to package these individually.
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151113/35493fde/attachment.html>
More information about the OpenStack-dev
mailing list