On 09/09/2013 10:01 AM, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange"
>
> This patch series demonstrates the minimum possible changes required
> to split the python binding out into a separate GIT repository.
>
> These patches do not apply to current GIT. Instead you have to first
> create a new git repo, initializing based on the history of the
> python/ subdirectory.
>
> Assuming your current checkout of libvirt is in a directory 'libvirt',
> then
>
> $ git clone libvirt libvirt-python
> $ cd libvirt-python
> $ git filter-branch --subdirectory-filter python --tag-name-filter cat --
> --all
> $ git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git
> update-ref -d
> $ git reflog expire --expire=now --all
> $ git gc --prune=now
>
> You should now have a repo that's a couple of MB in size, showing only the
> files from python/ dir, in the root.
>
> The tags have been re-written to show content from the python/ directory.
>
> One problem I've not yet solved is tag signatures. Many of the original
> vN.N.N tags are signed by Daniel Veillard, and the CVE-XXX ones
> signed by Eric Blake.
I'm actually fine if we drop the CVE tags (so far, all of our CVEs have
been against C code, not the python bindings; so by splitting into a new
package, we have code that is unfettered by any of the CVEs being patched).
I'm also fine with the older vn.n.n tags being unsigned - they are handy
to have as a reference point, and having them remain unsigned is a clue
to the user that the actual python package was not released at that
point as a standalone package. Starting from v1.1.3, we will once again
have signed tags, because that is the first point where we have
standalone releases.
>
> Obviously when re-writing the tags those signatures are now invalid.
> I can't find a way to get 'git filter-branch' to prompt me to sign the
> new tags it is creating, and AFAIK, you can't sign an existing tag without
> deleting and re-creating it ?
I think you are correct that delete and re-create is the only way to
inject a signed tag into a split repo; but I also argue that we don't
care about signed tags for past history, only from this point forward.
>
>
> Anyway, with the repo as above, you can now apply the 17 patches from
> this series onto that
>
> The build system uses python distutils instead of autoconf/automake.
> It still uses the code generator as before though, pulling the XML
> files from /usr/share/libvirt/api (or whever you installed libvirt,
> as indicated by pkg-config)
>
> I created a simple autobuild.sh to do an end-to-end build, including
> the RPM generation. Or you can just do
>
>
>python setup.py build ('make' equiv)
>python setup.py test('make check' equiv)
>python setup.py rpm ('make rpm' equiv)
>python setup.py clean ('make clean' equiv)
Cool!
>
> Historically libvirt python only worked with the exact matching libvirt
> binary. Before releasing this, I think we need to make it possible to
> compile libvirt-python against any recent-ish libvirt version.
>
> This shouldn't actually be too hard - the generator will take care of
> most of it. All we need do is fix up the -override.c files to make
> use of version checks to hide APIs not present in older libvirt.
And we still have a bit of time before 1.1.3 to actually do this. We'd
also have to commit a patch to libvirt.git that nukes the python subdir
and replaces it with a README that points to the new libvirt-python.git
(assuming that we're ready to commit to the split).
>
> The RPM is designed to be drop in compatible/identical to/with the
> existing libvirt-python RPM, so users should notice no difference
> in any way when upgrading.
>
> If you don't want to try the filter-branch steps yourself, you can
> clone this complete series + repo from
>
> http://fedorapeople.org/cgit/berrange/public_git/libvirt-python-split.git/
>
> Notice how the history is intact right back to the first commit of the
> python bindings.
Yes, very nice (tag CVE-2013-4297 is broken, but all the other tags
seemed to work; and I argued above that we don't really care about the
existing CVE tags since none of them affected python bindings, just C code).
>
> Daniel P. Berrange (17):
> Update generator for new code layout
> Remove from source files
> Remove obsolete Makefile.am
> Remote compiler annotation attributes
> Fix potential use of uninitialized value in virDomainGetVcpuPinInfo
> Remove use of VIR_FREE from code
> Remove use of VIR_ALLOC_N
> Import STREQ macro from libvirt
> Add decl of MIN macro
> Update header file includes
> Import gnulib's xalloc_oversized macro
> Import gnulib's ignore_value macro
> Remove use of virStrcpyStatic
> Remove use of VIR_FORCE_CLOSE
> Add build/ to python module path for sanitytest.py
> Add execute permission for sanitytest.py
> Setup distutils buld system
>
> .gitignore | 4 +
> AUTHORS.in
