On Tue, Jul 18, 2017 at 08:57:36 +0200, Christian Ehrhardt wrote: > On Mon, Jul 17, 2017 at 8:40 PM, Christian Ehrhardt < > christian.ehrhardt@xxxxxxxxxxxxx> wrote: > > > > > > > On Mon, Jul 17, 2017 at 8:17 PM, Christian Ehrhardt < > > christian.ehrhardt@xxxxxxxxxxxxx> wrote: > >> > >> So it is the parsing of the XML into objects I have to track down. > >> Maybe it is even some Ubuntu Delta that no more correctly matches. > >> Will run on build from upstream master as well before next report. > >> > > > > Ok, I was able to confirm with latest upstream master which rules out > > Ubuntu apparmor delta as the source of the issue. > > But I can build and run to check so worst case I can bisect it now. > > > > This becomes a monologue :-/ > Bisect found the breaking change to be in: > > f813fe810fc3f0ce839f450e662e0173d40a5ce1 is the first bad commit > commit f813fe810fc3f0ce839f450e662e0173d40a5ce1 > Author: Peter Krempa <pkrempa@xxxxxxxxxx> > Date: Fri Jan 13 16:50:11 2017 +0100 > > storage: backend: Refactor registration of the backend drivers > > Add APIs that allow to dynamically register driver backends so that the > list of available drivers does not need to be known during compile time. > > This will allow us to modularize the storage driver on runtime. > > > I'll try to debug in more detail how/where it broke it, but since this is a > rather huge refactor and not a small change this might take a while. Any > hints still welcome. Hmmm, in that case probably the registration of the storage driver APIs in the aa-helper does not take place properly, and thus the detection of the backing chain will be wrong. I'll have a look
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
