[openstack-dev] Help with getting keystone to migrate to Debian testing: fixing repoze.what and friends

Clint Byrum clint at fewbar.com
Fri Nov 13 00:11:27 UTC 2015


Excerpts from Jamie Lennox's message of 2015-11-12 15:28:06 -0800:
> 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.
> 

Yeah that wouldn't really help the situation. If the plugins get shipped,
they want to be in testing (and thus, pulling in repoze.who >= 2.0),
or removed from Debian entirely. A general policy of "drop the things
depending only on the old things" is really the only way Debian python
maintainers can stay sane. ;)



More information about the OpenStack-dev mailing list