Open Stack

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.