1. 11 Mar, 2021 5 commits
  2. 10 Mar, 2021 1 commit
  3. 24 Feb, 2021 6 commits
    • Andrea Bolognani's avatar
      extconf: Don't reset $DEFLIBPATH · a1054972
      Andrea Bolognani authored
      The intention here was to make sure that a system-wide copy of
      libvirt would not be picked up instead of the one that the command
      line options point to; however, since the bindings don't only link
      against libvirt itself but also against other libraries, by doing
      so we can make it impossible to correctly link the module and,
      even before we get to that point, to detect the availability of
      functions.
      
      For example, when building on macOS with
      
        $ rake build -- \
          --with-libvirt-include=$(brew --prefix libvirt)/include \
          --with-libvirt-lib=$(brew --prefix libvirt)/lib
      
      detecting functions will fail with
      
        have_func: checking for virStorageVolWipe()
                            in libvirt/libvirt.h... ----- no
      
        clang [...]
              -I/usr/local/Cellar/ruby/3.0.0_1/include/ruby-3.0.0
              -I/usr/local/opt/libvirt/include -L/usr/local/opt/libvirt/lib
              -lruby.3.0 -lvirt
        ld: library not found for -lruby.3.0
        clang: error: linker command failed with exit code 1
      
      Note how the include path for Ruby is present on the compiler
      command line, but the library path for it isn't.
      
      We can simply not reset $DEFLIBPATH and that will work correctly
      anyway, because we add the paths provided on the command line to
      $LIBPATH which takes precedence over $DEFLIBPATH.
      
      #3
      
      Signed-off-by: Andrea Bolognani's avatarAndrea Bolognani <abologna@redhat.com>
      a1054972
    • Andrea Bolognani's avatar
      extconf: Don't try to detect macros with have_const() · cfd4d479
      Andrea Bolognani authored
      
      
      have_const() can detect enum values correctly, but it won't work
      for things like VIR_MIGRATE_PARAM_* which are defined as
      preprocessor macros.
      
      We could use have_macro() instead but, unlike the other have_*()
      functions, that one doesn't add any symbol to extconf.h when the
      macro is found, so it's useless for the purpose of conditionally
      compiling some code.
      
      Luckily, all of the macros we are trying to detect have been
      part of libvirt for a very long time, so we can just assume that
      they are present and still build correctly on all the platforms
      we target.
      Signed-off-by: Andrea Bolognani's avatarAndrea Bolognani <abologna@redhat.com>
      cfd4d479
    • Andrea Bolognani's avatar
      extconf: Look for QEMU_AGENT_COMMAND_SHUTDOWN in libvirt-qemu.h · cd15d6d0
      Andrea Bolognani authored
      
      
      qemu-guest-agent commands are not defined in the main header.
      Signed-off-by: Andrea Bolognani's avatarAndrea Bolognani <abologna@redhat.com>
      cd15d6d0
    • Andrea Bolognani's avatar
      extconf: Drop local have_const() implementation · 618fa67d
      Andrea Bolognani authored
      
      
      This might have been necessary when it was introduced back in
      2011, but these days all target platforms ship with a reasonably
      modern version of mkmf.
      Signed-off-by: Andrea Bolognani's avatarAndrea Bolognani <abologna@redhat.com>
      618fa67d
    • Andrea Bolognani's avatar
      ci: Improve dependencies between jobs · 981f4c77
      Andrea Bolognani authored
      
      
      DCO checking can start immediately, as it doesn't depend on any
      other job; build jobs can start as soon as the corresponding
      container has been built instead of having to wait for all
      containers having been built.
      Signed-off-by: Andrea Bolognani's avatarAndrea Bolognani <abologna@redhat.com>
      981f4c77
    • Andrea Bolognani's avatar
      ci: Move DCO check to the end of the pipeline · 060b0678
      Andrea Bolognani authored
      
      
      This is consistent with what we do for other subprojects, and
      allows changes that are not ready to be submitted to undergo
      testing while still preventing accidental merge by failing the
      pipeline.
      Signed-off-by: Andrea Bolognani's avatarAndrea Bolognani <abologna@redhat.com>
      060b0678
  4. 20 Jan, 2021 3 commits
  5. 05 Jan, 2021 1 commit
  6. 15 Dec, 2020 1 commit
  7. 01 Dec, 2020 3 commits
  8. 23 Nov, 2020 1 commit
  9. 29 Sep, 2020 1 commit
  10. 04 Aug, 2020 1 commit
  11. 23 Jul, 2020 1 commit
  12. 15 May, 2020 4 commits
  13. 30 Apr, 2020 1 commit
  14. 07 Apr, 2020 1 commit
    • Daniel P. Berrangé's avatar
      github: enable lockdown of issues and merge requests · 5e172b32
      Daniel P. Berrangé authored
      Libvirt uses GitHub as an automated read-only mirror. The goals were to
      have a disaster recovery backup for libvirt.org, a way to make it easy
      for people to clone their own private copy of libvirt Git, and finally
      as a way to interact with apps like Travis.
      
      The project description was set to a message telling people that we
      don't respond to pull requests. This was quite a negative message to
      potential contributors, and also did not give them any guidance about
      the right way to submit to libvirt. Many also missed the description and
      submitted issues or pull requests regardless.
      
      It is possible to disable the issue tracker in GitHub, but there is no
      way to disable merge requests. Disabling the issue tracker would also
      leave the problem of users not being given any positive information
      about where they should be reporting instead.
      
      There is a fairly new 3rd party application built for GitHub that
      provides a bot which auto-responds to both issues and merge requests,
      closing and locking them, with a arbitrary comment:
      
         https://github.com/apps/repo-lockdown
      
      
      
      This commit adds a suitable configuration file for libvirt, which
      tries to give a positive response to user's issue/pullreq and guide
      them to the desired contribution path on GitLab.
      Reviewed-by: Andrea Bolognani's avatarAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: Pavel Hrdina's avatarPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: Eric Blake's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: Daniel P. Berrangé's avatarDaniel P. Berrangé <berrange@redhat.com>
      5e172b32
  15. 21 Feb, 2020 1 commit
  16. 23 Nov, 2019 1 commit
  17. 24 Apr, 2018 1 commit
    • Daniel P. Berrangé's avatar
      git: add config file telling git-publish how to send patches · 9f71ff5a
      Daniel P. Berrangé authored
      
      
      The "git-publish" tool is a useful git extension for sending patch
      series for code review. It automatically creates versioned tags
      each time code on a branch is sent, so that there is a record of
      each version. It also remembers the cover letter so it does not
      need re-entering each time the series is reposted.
      
      With this config file present it is now sufficient[1] to run
      
        $ git publish
      
      to send all patches in a branch to the list for review, with the
      correct subject prefix added for this non-core libvirt module.
      
      [1] Assuming your $HOME/.gitconfig has an SMTP server listed
      at least e.g.
      
         [sendemail]
              smtpserver = smtp.example.com
      Signed-off-by: Daniel P. Berrangé's avatarDaniel P. Berrangé <berrange@redhat.com>
      9f71ff5a
  18. 18 Feb, 2018 3 commits
  19. 17 Feb, 2018 1 commit
  20. 11 Feb, 2018 1 commit
  21. 22 Sep, 2016 2 commits