Jobs starting with a '.' are templates so never run unless
referenced by another job.

Fixes: 6872a7cc
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Daniel P. Berrangé authored 3 months ago and Daniel P. Berrangé committed 3 months ago

This parameter is a string list of disk names, not a boolean
flag.

Changing the type is an API break for any current user what is
setting this field, however, if they were setting this, then
libvirt would be failing with an error about the incorrect type
already.

To strictly preserve ABI though, we don't change the existing
field type, just document it as now unused, and add a second
parallel field with the correct type.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Notable changes:

 * Switch to URLs for referencing projects in manifest

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Inspired by one of previous commits, we can not assume that an
array passed to an API has any items, thus getting its pointer to
pass to C API like this: "&array[0]" may lead to a runtime error.
If that's the case, pass nil instead.

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

Inspired by one of previous commits, we can not assume that an
array passed to an API has any items, thus getting its pointer to
pass to C API like this: "&array[0]" may lead to a runtime error.
If that's the case, pass nil instead.

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

Inspired by one of previous commits, we can not assume that an
array passed to an API has any items, thus getting its pointer to
pass to C API like this: "&array[0]" may lead to a runtime error.
If that's the case, pass nil instead.

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

Inspired by one of previous commits, we can not assume that an
array passed to an API has any items, thus getting its pointer to
pass to C API like this: "&array[0]" may lead to a runtime error.
If that's the case, pass nil instead.

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

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

Inspired by one of previous commits, we can not assume that an
array passed to an API has any items, thus getting its pointer to
pass to C API like this: "&array[0]" may lead to a runtime error.
If that's the case, pass nil instead.

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

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

Inspired by one of previous commits, we can not assume that an
array passed to an API has any items, thus getting its pointer to
pass to C API like this: "&array[0]" may lead to a runtime error.
If that's the case, pass nil instead.

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

When SSH keys slice passed to AuthorizedSSHKeysSet()
was empty, the code would panic.

Signed-off-by: Andrej Krejcir <akrejcir@redhat.com>

The Golang 'uint' type varies in size either 4 bytes or 8 bytes
depending on host arch 32-bit vs 64-bit.

The C 'unsigned int' type is always 4 bytes.

Passing scalar values is OK, but when we pass an array to C we
need to re-build the array using the C.uint type otherwise the
C code will access incorrect array indexes.

Closes: #3


Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Distro changes:

  * Drop AlmaLinux 8, add 9
  * Drop CentOS Stream 8
  * Drop Fedora 37 and 38, add 39 and 40
  * Drop Ubuntu 20.04, add 24.04

Also, adapt .gitlab-ci.yml jobs to those defined in
ci/gitlab/build-templates.yml.

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

The code for serializing a 'double' value mistakenly accesses
the 'int' value field.

Fixes: #17


Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

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

The way our wrapper code generator works is the following:

1) Libvirt public API function pointer is declared, e.g.:

  typedef int
  (*virDomainAttachDeviceType)(virDomainPtr domain,
                               const char *xml);

  where the type name is constructed as "${funcName}Type".

2) A wrapper function is generated, e.g.

  int
  virDomainAttachDeviceWrapper(virDomainPtr domain.
                               const char *xml,
                               virErrorPtr err)

  which inside its body has a static variable:

  static virDomainGraphicsReloadType virDomainGraphicsReloadSymbol;

  which is then set to a corresponding libvirt API via dlopen().

This works beautifully, except it makes an assumption about
naming that no longer works in our favor. Specifically, another
part of our generator that handles generating typedefs for
function arguments (that are enums really, though uint
officially), uses the same naming scheme:

  ${funcName}${argName}

This is guaranteed to clash with each other when ${argName} =
"type" (the first letter of ${argName} is capitalized to follow
golang's naming scheme).

And we can already see an example of this in our code:

libvirt_generated_functions_dlopen_domain.go has:

  typedef int
  (*virDomainGraphicsReloadType)(virDomainPtr domain,
                                 unsigned int type,
                                 unsigned int flags);

and libvirt_generated_typedefs.h has:

  #if !LIBVIR_CHECK_VERSION(10, 2, 0)
  typedef int virDomainGraphicsReloadType;
  #endif

To make this kind of conflicts harder to hit, generate the
function type as:

  ${funcName}FuncType

and hope there won't be any API with 'funcType' as an argument
any time soon.

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

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

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Daniel P. Berrangé authored 1 year ago and Daniel P. Berrangé committed 1 year ago

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Daniel P. Berrangé authored 1 year ago and Daniel P. Berrangé committed 1 year ago

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Distro changes include:

  * Fedora 35/36 -> 37/38
  * Debian 10 -> Debian 12
  * OpenSUSE Leap 15.3 -> Leap 15

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Ray Lee <hburaylee@gmail.com>

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

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

go fmt made some changes in doc.go.

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

I have a C library that has a function that accepts virConnectPtr
and I want to write Golang bindings for it. For instance:

  struct VirtLint *virt_lint_new(virConnectPtr conn);

Ideally, any consumer would use libvirt's Golang bindings to open
the connection and then just merely pass it to my library. But
since the raw connection pointer is not accessible outside of the
module, it's impossible to do so.

Therefore, introduce new RawPtr() function, that returns the raw
pointer. But since this is potentially dangerous (e.g. it can
mess up the global state we keep in @connections map) document
the function unsafe and discourage people from using it.

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

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>