> > python-sphinx is not backported and you didn't mention any patches
>
> I did backport python-sphinx too. It is present in these packages, and I
> also mentioned it in this list.
you did mention you will backport sphinx. Yes, I missed that and I'm sorry for
that. I did check if it's backported and it still isn't.
> Will do. FYI, I'm still waiting for the removal of
> python-repoze.{what,what-plugins,who-plugins}, which is blocking the
> migration of Keystone, and which therefore makes my efforts useless
> (there's no point of uploading OpenStack without keystone). So for the
> moment, my uploads are stalled.
what's blocking you with sphinx?
> Unless you want to maintain the backports yourself: no. This is not a
> hijack anyway, you're the only one calling it this way.
I don't have time for it now and I don't want additional work caused by
you (sorry, I still don't trust you, not anymore).
Note that even if it "officially" is somewhere else (or is it not?) -
I will get all the DAK emails and bugs. Ubuntu fixed the fist part by
changing Maintainer to a mailing list. It doesn't solve the bugs issue
in our BTS (which is more annoying).
The easiest way is to simply play nice with current maintainer. I asked
you for changes you want to upload and you didn't provide them until
yesterday (and there's a difference between "just a rebuild" and "just a
rebuild with backported other build dependencies") - I could easily read
that from f.e. build logs or resulting binaries (which you didn't
originally provide).
> On 11/26/2015 09:42 PM, Piotr Ożarowski wrote:
> > Building and uploading in the right order was always the plan,
> > right?
>
> Building in the right order is necessary for checking that
you realize some packages will have to go though NEW and sphinx is one of them?
> (build-)dependencies are satisfied, yes. Though I don't think I actually
> need to upload in a specific order: I can push all at once if it is
> within a single dak run (if I'm wrong here, let me know).
if you upload A that doesn't have to go through NEW and new B that A build
depends on, A is broken.
(if all of them will end up in NEW, ftp-masters will take care of that)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
