Hi, I have finished what I think is needed for this package.
> > uwsgidecorators.py would make sense in this package but is not > > provided by uwsgi-src. OK to add it? > > Yes: Anything needed for plugin/module packages should be included in > uwsgi-src package. Waiting for an upload to uncomment uwsgidecorators.py stuff. > > My packaging only builds for the default python version. Should we > > plan for multiple python versions supported in sid? My view on this is > > to wait for the need to arise. If ok with this, src:uwsgi should > > probably clean out all the alternatives provided. You view on this? > > I used to strongly favor offering each available version, but nowadays I > don't really care, so if you prefer to reduce to a single non-versioned > package then go ahead - but yes, then be careful to handle the migration > (personally I would find it simpler to *continue* with versioned > packages now that it has been established already, but I leave the > choice to you). Implemented. Left out the rtupdate stuff: very complicated for would require a binNMU in most cases. > > greenlet should be restricted to some archs, looking into that and > > considering specific source package. Advice? > > I recommend to use the same method that I have used. Done. I initially went for a debian/control.in template but later was confused and editing debian/control directly so now I understand your approach of having only debian/control. > You might consider adding support for pypy3, and close bug#732019. pypy is a different set of build deps, so a different source package I think. Thanks, Alex
