1. 06 5月, 2014 11 次提交
  2. 05 5月, 2014 3 次提交
  3. 04 5月, 2014 5 次提交
  4. 03 5月, 2014 2 次提交
    • G
      Explicitly link virfirewalltest and virsystemdtest against dbus · 4bdb5037
      Guido Günther 提交于
      This fixes link failures like:
      
        CCLD     virfirewalltest
        /usr/bin/ld: virfirewalltest-virfirewalltest.o: undefined reference to
        symbol 'dbus_message_iter_init_append'
      4bdb5037
    • G
      qemuxml2argvtest: Don't use privileged mode upfront · 3cee4c05
      Guido Günther 提交于
      When building packages in a clean chroot the QEMU_USER and QEMU_GROUP
      don't exist making VirQemuDriverConfigNew fail with privileged=true.
      
      Avoid that by not requiring privileged mode upfront but setting it later
      so we skip the user/group existence check.
      
      This solution was suggested by Daniel P. Berrange and tested by Martin
      Kletzander.
      3cee4c05
  5. 02 5月, 2014 8 次提交
    • R
      tests: skip virfirewalltest on non-Linux systems · 064f49a0
      Roman Bogorodskiy 提交于
      Currently firewalling is supported on Linux only, so skip the
      virfirewalltest on other platforms.
      064f49a0
    • J
      Restore skipping of setting capacity · f1856eb6
      John Ferlan 提交于
      Commit id 'ac9a0963' refactored out the 'withCapacity' for the
      virStorageBackendUpdateVolInfo() API.  See:
      
      http://www.redhat.com/archives/libvir-list/2014-April/msg00043.html
      
      This resulted in a difference in how 'virsh vol-info --pool <poolName>
      <volume>' or 'virsh vol-list vol-list --pool <poolName> --details' outputs
      the capacity information for a directory pool with a qcow2 sparse file.
      
      For example, using the following XML
      
      mkdir /home/TestPool
      cat testpool.xml
      <pool type='dir'>
        <name>TestPool</name>
        <uuid>6bf80895-10b6-75a6-6059-89fdea2aefb7</uuid>
        <source>
        </source>
        <target>
          <path>/home/TestPool</path>
          <permissions>
            <mode>0755</mode>
            <owner>0</owner>
            <group>0</group>
          </permissions>
        </target>
      </pool>
      
      virsh pool-create testpool.xml
      virsh vol-create-as --pool TestPool temp_vol_1 \
            --capacity 1048576 --allocation 1048576 --format qcow2
      virsh vol-info --pool TestPool temp_vol_1
      
      Results in listing a Capacity value.  Prior to the commit, the value would
      be '1.0 MiB' (1048576 bytes). However, after the commit the output would be
      (for example) '192.50 KiB', which for my system was the size of the volume
      in my file system (eg 'ls -l TestPool/temp_vol_1' results in '197120' bytes
      or 192.50 KiB). While perhaps technically correct, it's not necessarily
      what the user expected (certainly virt-test didn't expect it).
      
      This patch restores the code to not update the target capacity for this path
      f1856eb6
    • M
      tests: don't fail with newer gnutls · 4cbc15d0
      Martin Kletzander 提交于
      gnutls-3.3.0 and newer leaves 2 FDs open in order to be backwards
      compatible when it comes to chrooted binaries [1].  Linking
      commandhelper with gnutls then leaves these two FDs open and
      commandtest fails thanks to that.  This patch does not link
      commandhelper with libvirt.la, but rather only the utilities making
      the test pass.
      
      Based on suggestion from Daniel [2].
      
      [1] http://lists.gnutls.org/pipermail/gnutls-help/2014-April/003429.html
      [2] https://www.redhat.com/archives/libvir-list/2014-April/msg01119.htmlSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>
      4cbc15d0
    • J
      fix build with older gcc · 1055852a
      Ján Tomko 提交于
      Older gcc (4.1.2-55.el5, 4.2.1 on FreeBSD) reports bogus warnings:
      ../../src/conf/nwfilter_conf.c:2111: warning: 'protocol' may be used
      uninitialized in this function
      ../../src/conf/nwfilter_conf.c:2110: warning: 'dataProtocolID' may be
      used uninitialized in this function
      
      Initialize them to NULL to make the compiler happy.
      1055852a
    • E
      storage: reject negative indices · 5c05e2b1
      Eric Blake 提交于
      Commit f22b7899 stumbled across a difference between 32-bit and
      64-bit platforms when parsing "-1" as an int.  Now that we've
      fixed that difference, it's time to fix the testsuite.
      
      * src/util/virstoragefile.c (virStorageFileParseChainIndex):
      Require a positive index.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      5c05e2b1
    • E
      util: new stricter unsigned int parsing · 7b045c8c
      Eric Blake 提交于
      strtoul() is required to parse negative numbers as their
      twos-complement positive counterpart.  But sometimes we want
      to reject negative numbers.  Add new functions to do this.
      The 'p' suffix is a mnemonic for 'positive' (technically it
      also parses 0, but 'non-negative' doesn't lend itself to a
      nice one-letter suffix).
      
      * src/util/virstring.h (virStrToLong_uip, virStrToLong_ulp)
      (virStrToLong_ullp): New prototypes.
      * src/util/virstring.c (virStrToLong_uip, virStrToLong_ulp)
      (virStrToLong_ullp): New functions.
      * src/libvirt_private.syms (virstring.h): Export them.
      * tests/virstringtest.c (testStringToLong): Test them.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      7b045c8c
    • E
      util: fix uint parsing on 64-bit platforms · f18c02ec
      Eric Blake 提交于
      Commit f22b7899 called to light a long-standing latent bug: the
      behavior of virStrToLong_ui was different on 32-bit platforms
      than on 64-bit platforms.  Curse you, C type promotion and
      narrowing rules, and strtoul specification.  POSIX says that for
      a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
      LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
      ULONG_MAX] with twos-complement wraparound for negatives.  Thus,
      parsing -1 as unsigned long produces ULONG_MAX, rather than a
      range error.  We WANT[1] this same shortcut for turning -1 into
      UINT_MAX when parsing to int; and get it for free with 32-bit
      long.  But with 64-bit long, ULONG_MAX is outside the range
      of int and we were rejecting it as invalid; meanwhile, we were
      silently treating -18446744073709551615 as 1 even though it
      textually exceeds INT_MIN.  Too bad there's not a strtoui() in
      libc that does guaranteed parsing to int, regardless of the size
      of long.
      
      The bug has been latent since 2007, introduced by Jim Meyering
      in commit 5d254191 in the attempt to eradicate unsafe use of
      strto[u]l when parsing ints and longs.  How embarrassing that we
      are only discovering it now - so I'm adding a testsuite to ensure
      that it covers all the corner cases we care about.
      
      [1] Ideally, we really want the caller to be able to choose whether
      to allow negative numbers to wrap around to their 2s-complement
      counterpart, as in strtoul, or to force a stricter input range
      of [0 to UINT_MAX] by rejecting negative signs; this will be added
      in a later patch for all three int types.
      
      This patch is tested on both 32- and 64-bit; the enhanced
      virstringtest passes on both platforms, while virstoragetest now
      reliably fails on both platforms instead of just 32-bit platforms.
      That test will be fixed later.
      
      * src/util/virstring.c (virStrToLong_ui): Ensure same behavior
      regardless of platform long size.
      * tests/virstringtest.c (testStringToLong): New function.
      (mymain): Comprehensively test string to long parsing.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      f18c02ec
    • D
      Misc error reporting bugs in QEMU cli builder · dca027a9
      Daniel P. Berrange 提交于
      A couple of places in the QEMU XML -> ARGV conversion code
      raised an error but then forgot to return an error status
      due to missing gotos. While fixing this also tweak style
      of a couple of other error reports
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      dca027a9
  6. 01 5月, 2014 4 次提交
  7. 30 4月, 2014 6 次提交
  8. 29 4月, 2014 1 次提交