tools/wireshark/src/plugin.c | 3 0 + 3 - 0 !
1 file changed, 3 deletions(-)

 wireshark: drop needless declaration of proto_register_libvirt() and
 proto_reg_handoff_libvirt()

Both proto_register_libvirt() and proto_reg_handoff_libvirt() are
declared in packet-libvirt.h which is included from plugin.c.
There's no need to provide another declaration in plugin.c.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

tools/wireshark/util/genxdrstub.pl | 5 1 + 4 - 0 !
1 file changed, 1 insertion(+), 4 deletions(-)

 wireshark: switch header files to #pragma once

The genxdrstub.pl script generates some header files. But they
use the old pattern to guard against multiple inclusion:

  #ifndef SOMETHING_H
  #define SOMETHING_H
  ...
  #endif

Change the script to generate just '#pragma once' used everywhere
else in our code.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

tools/wireshark/src/packet-libvirt.h | 14 14 + 0 - 0 !
tools/wireshark/src/plugin.c | 14 0 + 14 - 0 !
2 files changed, 14 insertions(+), 14 deletions(-)

 wireshark: move wireshark_version macro definition

Soon, other parts of the wireshark code will need to

tools/wireshark/src/packet-libvirt.c | 34 23 + 11 - 0 !
1 file changed, 23 insertions(+), 11 deletions(-)

 wireshark: fix int type of some virnetmessageheader members

Our virNetMessageHeader is a struct that's declared as follows:

  struct virNetMessageHeader {
      unsigned prog;
      unsigned vers;
      int proc;
      virNetMessageType type;
      unsigned serial;
      virNetMessageStatus status;
  };

Now, per RFC 4506 enums are also encoded as signed integers. This
means, that only 'prog', 'vers' and 'serial' are really unsigned
integers. The others ('proc', 'type' and 'status') are encoded as
signed integers. Fix their type when dissecting.

While at it, also follow latest trend in wireshark and switch
from guint32 to uint32_t.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

tools/wireshark/src/packet-libvirt.c | 6 1 + 5 - 0 !
1 file changed, 1 insertion(+), 5 deletions(-)

 wireshark: don't special case retval of get_program_data() in
 dissect_libvirt_message()

The get_program_data() function returns a pointer (in this
specific case to an array of procedure strings) which, if
non-NULL is then passed val_to_str(). Well, if val_to_str() sees
NULL it is treated gracefully, i.e. like if the numeric value
'proc' wasn't found in the array.

Therefore, there's no need to special case call to
col_append_fstr(). Both result into the same behaviour.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

tools/wireshark/src/packet-libvirt.c | 17 13 + 4 - 0 !
1 file changed, 13 insertions(+), 4 deletions(-)

 wireshark: introduce and use vir_val_to_str()

Wireshark offers val_to_str() function which converts numeric
value to string by looking up value ('val') in an array ('vs') of
<val, string> pairs. If no corresponding string is found, then
the value is formatted using given 'fmt' string.

Starting from wireshark-4.6.0 not only this function gained
another argument but also returns a strdup()-ed string. To keep
our code simple, let's introduce a wrapper so which can be then
adjusted as needed.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

meson.build | 20 20 + 0 - 0 !
tools/wireshark/src/meson.build | 1 1 + 0 - 0 !
tools/wireshark/src/packet-libvirt.c | 35 28 + 7 - 0 !
3 files changed, 49 insertions(+), 7 deletions(-)

 wireshark: don't leak column strings

One of the problems of using val_to_str() is that it may return a
const string from given table ('vs'), OR return an allocated one.
Since the caller has no idea which case it is, it resides to safe
option and don't free returned string. But that might lead to a
memleak. This behaviour is fixed with wireshark-4.6.0 and support
for it will be introduced soon. But first, make vir_val_to_str()
behave like fixed val_to_str() from newer wireshark: just always
allocate the string.

Now, if val_to_str() needs to allocate new memory it obtains
allocator by calling wmem_packet_scope() which is what we may do
too.

Hand in hand with that, we need to free the memory using the
correct allocator, hence wmem_free(). But let's put it into a
wrapper vir_wmem_free() because just like val_to_str(), it'll
need additional argument when adapting to new wireshark.

Oh, and freeing the memory right after col_add_fstr() is safe as
it uses vsnprintf() under the hood to format passed args.

One last thing, the wmem.h file used to live under epan/wmem/ but
then in v3.5.0~240 [1] was moved to wsutil/wmem/.

1: https://gitlab.com/wireshark/wireshark/-/commit/7f9c1f5f92c131354fc8b2b88d473706786064c0
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

tools/wireshark/src/packet-libvirt.c | 157 110 + 47 - 0 !
tools/wireshark/util/genxdrstub.pl | 18 9 + 9 - 0 !
2 files changed, 119 insertions(+), 56 deletions(-)

 wireshark: adapt to wireshark-4.6.0

docs/manpages/libvirt-guests.rst | 4 2 + 2 - 0 !
tools/libvirt-guests.sh.in | 15 7 + 8 - 0 !
2 files changed, 9 insertions(+), 10 deletions(-)

 debianize libvirt-guests

src/security/apparmor/libvirt-lxc | 7 7 + 0 - 0 !
src/security/apparmor/libvirt-qemu | 7 7 + 0 - 0 !
2 files changed, 14 insertions(+)

 apparmor_profiles_local_include

Include local apparmor profile

tools/vsh.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 use sensible-editor by default

It is the reasonable default for Debian.

src/remote/libvirtd.service.in | 2 0 + 2 - 0 !
1 file changed, 2 deletions(-)

 drop inter-package also= lines from libvirtd.service

systemctl handles these lines gracefully even when the
corresponding unit is not present, e.g. because the daemon-lock
package is not installed, but deb-systemd-helper doesn't. As a
temporary workaround until this limitation is addressed, drop
the lines triggering the failure.

Note that we would technically only need to drop the reference
to virtlockd.socket, since the daemon-log package is a hard
dependency of the daemon package and thus we know that
virtlogd.socket is always going to be present, but being more
aggressive for consistency's sake seems preferable.

Bug-Debian: https://bugs.debian.org/1082939
Bug-Debian: https://bugs.debian.org/1091519