[PKG-Openstack-devel] Helping with OpenStack packaging
thomas at goirand.fr
Sat Sep 9 18:28:19 UTC 2017
On 09/09/2017 04:13 PM, Geoffrey Thomas wrote:
> I have two packages I'd like review on:
> 1. I've pushed two commits to python-openstackdocstheme to fix doc
> generation. The first reverts two upstream commits that got rid of the
> built-in search, and the second one makes the built-in search actually
> work (because openstackdocstheme does not inherit from layout.html in
> the base Sphinx theme). We should probably upstream some version of this
> commit, but I think we want to upload this now to unblock the rest of
> the work, and we can do binNMUs later if needed.
Thanks a lot for this work, this is *very* helpful.
On top of your work, I have rebased and re-added the patches that were
on Newton. The result is that there's no top menu, and no references to
external resources (to keep on our user's privacy when they browse).
Maybe some stuff are broken though, feel free to check.
BTW, there's no such thing as binNMU for arch: all packages.
> 2. I updated python-json-patch, a dependency of python-openstackclient
> and a few others, to the latest upstream which supports Python 3.6, and
> I've pushed it to DPMT git and made it align with DPMT standards to the
> best of my knowledge. Is this the right thing to do, and did I do the
> move right? (If so, I'll do the same thing for other generic Python
> packages I need to fix, and just ask DPMT for review/sponsorship.)
> The code is at
> forked from 86ed5791 in OpenStack git (so `git log 86ed5791...` or something).
> Should I do anything with the OpenStack git repo, e.g. push
> a commit to master that includes a README saying the package moved?
While it's fine to move the package to the DPMT, please don't hijack it
and keep the previous uploaders (ie: myself). I don't think Julien and
Mehdi are doing anything in Debian anymore though, so it is safe to
Please also write [ Geoffrey Thomas ] to debian/changelog when you're
adding new entries there. If you do "dch -i" then it will do it
automatically (just amend the version if dch changes it and it's not
I don't agree with:
* Move /usr/bin/jsonpatch and /usr/bin/jsondiff to a new binary
package jsonpatch, and stop using alternatives. Recommend jsonpatch
from python(3)-jsonpatch for smoother upgrades.
The reason is that for OpenStack, we want to have a full python 2 stack
for the moment, until we can switch everything to Python 3. Otherwise,
in production, you end up with a mixture of python 2 and python 3 stuff,
which is heavier. Once we have switched everything to Python 3 (which we
should be able to do right after Pike is packaged), then we can
completely remove Python 2 support all together (and then remove the
update-alternatives stuff, or at least make it use Python 3 as default).
In the mean while, I think it is too early to flip the switch. On top of
this, I don't think it is relevant to add a new binary package just for
2 binaries in /usr/bin. That's added metadata to the Debian archive,
which the FTP masters have already expressed concerns about. It is a
good idea that all Debian developers make an effort to minimize the
amount of binaries when needed. And in this case, it really is avoidable
without any issue.
Let me know when you've done all of the above, and I'll sponsor the package.
You can follow Ondrej advice to move the files to the "old" folder in
Alioth once it's uploaded.
> After this, I think it would be worth uploading the Oslo libraries that
> Thomas has already updated, with doc generation re-enabled. Since I'm
> not a DD, I cannot upload these myself, so I think it makes more sense for
> someone else to do the work (revert the commit to disable dh_sphinxdoc,
> build, test, push to git and upload). But if it would help for me to do
> these steps other than uploading, I'm happy to do that.
I've already started doing all the uploads, and I hope to finish this
over the week-end. I feel bad that my work is *much much* slower than it
used to be as I'm not full time, but hey, not my choice... :/
> Also, I see there's some infrastructure in openstack-pkg-tools to do
> autobuilding -- is that still operational
This is *very very* old stuff. We should not use it.
> and if not, would it be worth
> setting up something (probably outside of upstream OpenStack
> infrastructure) to host an apt repository for packages in development
> and backports to stable?
I already discussed with Holger at debconf, and it should be possible
for us to use the infrastructure from jenkins.debian.org. The only thing
we need to produce is a small patch for jenkins.d.o to build packages on
git push. Unfortunately, I forgot what Holger told me, ie: where to
commit the patch. Though it shouldn't be hard to figure it out.
Though the most important bit of infrastructure we need is a final
functional testing suite machine. I used to functiona testing using a
Debian live booted over PXE, on where I was deploying using the
"openstack-deploy" package, plus a bit of scripting magic. All of this
is written in the openstack-meta-packages package. We would need this
type of hardware sponsored by someone so we could use it through jenkins
(or something else). It would need IPMI (or some other ways of hitting
the reset button, like a remote APC with an API), and 32 GB of RAM
minimum, plus maybe 100 GB of HDD (preferaby SSD) to use as scratch disk
for swift tests.
Thanks again for your contrib,
Thomas Goirand (zigo)
More information about the Openstack-devel