Re: [libvirt] [dbus PATCH 0/7] additional cleanups and improvements
On 08/08/2017 11:25 AM, Pavel Hrdina wrote:
Pavel Hrdina (7):
maint: cleanup gitignore
maint: ignore dist tarball
build: fix distcheck
build: move test related bits to test/Makefile.am
maint: move service file into data directory
data: add system dbus service file
data: add system dbus service policy configuration
.gitignore | 21 +++++++++++----------
Makefile.am | 6 +-----
configure.ac | 23 +++++++++++++++++++++++
data/Makefile.am | 33 +++++++++++++++++++++++++++++++++
data/session/org.libvirt.service.in | 3 +++
data/system/org.libvirt.conf | 12 ++++++++++++
data/system/org.libvirt.service.in | 4 ++++
libvirt-dbus.spec.in | 2 ++
src/Makefile.am | 17 -----------------
src/org.libvirt.service.in | 3 ---
test/Makefile.am | 16 ++++++++++++++++
test/libvirttest.py | 2 +-
12 files changed, 106 insertions(+), 36 deletions(-)
create mode 100644 data/Makefile.am
create mode 100644 data/session/org.libvirt.service.in
create mode 100644 data/system/org.libvirt.conf
create mode 100644 data/system/org.libvirt.service.in
delete mode 100644 src/org.libvirt.service.in
create mode 100644 test/Makefile.am
You know... It might be nice to add something regarding how to build,
test, use distcheck, etc. into HACKING. I know I can never remember for
-perl and I can always go there to cut-n-paste... Including running
"run" from libvirt master tree use those bits.
FWIW:
Even after applying these and building I get:
$ git status
On branch rvw-phrdina-dbus-more
Your branch is ahead of 'master' by 7 commits.
(use "git push" to publish your local commits)
Untracked files:
(use "git add <file>..." to include in what will be committed)
src/org.libvirt.service
nothing added to commit but untracked files present (use "git add" to track)
So that may need to stay in patch 5 or somehow be magically removed if
it exists since it's now moved/created elsewhere.
Beyond that - things look OK to me. I can successfully build for each
patch and they all look reasonable to me (although I'm far from an
expert - I count on others for that!).
Reviewed-by: John Ferlan <jferlan(a)redhat.com>
John