Seeing a log message saying 'flags=93' is ambiguous & confusing unless
you happen to know that libvirt always prints flags as hex.  Change our
debug messages so that they always add a '0x' prefix when printing flags,
and '0' prefix when printing mode. A few other misc places gain a '0x'
prefix in error messages too.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

* docs/news.xml: update for release
* po/*.po*: regenerated

* docs/news.xml: updated for the release
* po/*.po*: regenerated

* docs/news.xml: update
* po/*.po* : regenerated

* docs/news.xml: updated for the release
* po/*.po*: regenerated

* docs/news.xml: updated for release
* po/*.po*: regenerated

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

* docs/news.xml: update for release
* po/*.po*: regenerated

* docs/news.xml: updated and regenerated NEWS
* po/*.po*: regenerated

* po/*.po*

* docs/news.html.in: update for the release
* po/*.po*: regenerated

* docs/news.html.in: updated for release
* po/*.po*: regenerated

* docs/news.html.in: update for release
* po/*po*: regenerate

* docs/news.html.in: updated for release
* po/*.po*: regenerated

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

* docs/news.html.in: update documentation
* po/*.po*: regenerate

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po* : regenerated

- docs/news.html.in libvirt.spec.in: update for release
- po/*.po*: regenerated

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: regenerated

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: regenerated

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: regenerated

* docs/news.html.in libvirt.spec.in: Updated for the release
* po/*.po*: regenerated

* docs/news.html.in libvirt.spec.in: update for new release
* po/*.po*: regenerate localization

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*.po*: regenerated

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: regenerated

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*po*: regenerated

- docs/news.html.in libvirt.spec.in: update for the release
- po/*.po*: regenerate

- docs/news.html.in libvirt.spec.in: update for the release
- po/*.po*: regenerated

- docs/news.html.in libvirt.spec.in: update for the release
- po/*.po*: regenerated localization

Delete .po files which contain zero translated strings. Refresh
the .pot file and pull down latest translations from Zanata.

When refreshing the libvirt.pot, it can be pushed to zanata
and .po files resynchonized using

 # cd po
 # rm libvirt.pot
 # make libvirt.pot
 # zanata-cli push
 # zanata-cli pull

Note there is no need for 'make update-po', as long as you do
a zanata push, immediately followed by zanata pull, as the
Zanata server will ensure the .po files downloaded match the
just pushed .pot file.

Note at time of writing, it is strongly recommended to only
use the zanata Java client binary (zanata-cli), and not the
python client binary (zanata). This is because the moderately
large size of the libvirt pot file is causing errors when the
python client tries to push, which have been known to result
in the loss of all translations on the server, as well as also
preventing uploading of .po files themselves :-(

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*.po*: regenerated the po

- docs/news.html.in libvirt.spec.in: update for release
- po/*.po*: updated localization and regenerated

- docs/news.html.in libvirt.spec.in: update for release
- po/*.po*: fetched loclalization and regenerated

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: updated localizations and regenerated

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: new localizations and regenerate pos