search for: set_program

Since I upgrading to FC27, I *sometimes* fail to virt-sysprep. The debug messages: libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: create: flags = 0, handle = 0x7f4600005dd0, program = python2 libguestfs: trace: set_program "lago" libguestfs: trace: set_program = 0 libguestfs: trace: add_drive_ro "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-0_root.qcow2" libguestfs: trace: add_drive "/home/ykaul/ovirt-system-tests/deployment-basic-su...

...t; Since I upgrading to FC27, I *sometimes* fail to virt-sysprep. > > The debug messages: > > libguestfs: trace: set_verbose true > > libguestfs: trace: set_verbose = 0 > > libguestfs: create: flags = 0, handle = 0x7f4600005dd0, program = python2 > > libguestfs: trace: set_program "lago" > > libguestfs: trace: set_program = 0 > > libguestfs: trace: add_drive_ro > > "/home/ykaul/ovirt-system-tests/deployment-basic-suite- > master/default/images/lago-basic-suite-master-host-0_root.qcow2" > > libguestfs: trace: add_drive > >...

...t-sysprep. > > > > The debug messages: > > > > libguestfs: trace: set_verbose true > > > > libguestfs: trace: set_verbose = 0 > > > > libguestfs: create: flags = 0, handle = 0x7f4600005dd0, program = > python2 > > > > libguestfs: trace: set_program "lago" > > > > libguestfs: trace: set_program = 0 > > > > libguestfs: trace: add_drive_ro > > > > "/home/ykaul/ovirt-system-tests/deployment-basic-suite- > > > master/default/images/lago-basic-suite-master-host-0_root.qcow2" > >...

...o virt-sysprep. > > > > The debug messages: > > > > libguestfs: trace: set_verbose true > > > > libguestfs: trace: set_verbose = 0 > > > > libguestfs: create: flags = 0, handle = 0x7f4600005dd0, program = python2 > > > > libguestfs: trace: set_program "lago" > > > > libguestfs: trace: set_program = 0 > > > > libguestfs: trace: add_drive_ro > > > > "/home/ykaul/ovirt-system-tests/deployment-basic-suite- > > > master/default/images/lago-basic-suite-master-host-0_root.qcow2" > >...

...200, Yaniv Kaul wrote: > Since I upgrading to FC27, I *sometimes* fail to virt-sysprep. > The debug messages: > libguestfs: trace: set_verbose true > libguestfs: trace: set_verbose = 0 > libguestfs: create: flags = 0, handle = 0x7f4600005dd0, program = python2 > libguestfs: trace: set_program "lago" > libguestfs: trace: set_program = 0 > libguestfs: trace: add_drive_ro > "/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-0_root.qcow2" > libguestfs: trace: add_drive > "/home/ykaul/ovirt-system-...

...C27, I *sometimes* fail to virt-sysprep. > > > The debug messages: > > > libguestfs: trace: set_verbose true > > > libguestfs: trace: set_verbose = 0 > > > libguestfs: create: flags = 0, handle = 0x7f4600005dd0, program = python2 > > > libguestfs: trace: set_program "lago" > > > libguestfs: trace: set_program = 0 > > > libguestfs: trace: add_drive_ro > > > "/home/ykaul/ovirt-system-tests/deployment-basic-suite- > > master/default/images/lago-basic-suite-master-host-0_root.qcow2" > > > libguestfs: tr...

...t-sysprep. >>>>> The debug messages: >>>>> libguestfs: trace: set_verbose true >>>>> libguestfs: trace: set_verbose = 0 >>>>> libguestfs: create: flags = 0, handle = 0x7f4600005dd0, program = python2 >>>>> libguestfs: trace: set_program "lago" >>>>> libguestfs: trace: set_program = 0 >>>>> libguestfs: trace: add_drive_ro >>>>> "/home/ykaul/ovirt-system-tests/deployment-basic-suite- >>>> master/default/images/lago-basic-suite-master-host-0_root.qcow2" >...

...> > The debug messages: > > > > > libguestfs: trace: set_verbose true > > > > > libguestfs: trace: set_verbose = 0 > > > > > libguestfs: create: flags = 0, handle = 0x7f4600005dd0, program = > python2 > > > > > libguestfs: trace: set_program "lago" > > > > > libguestfs: trace: set_program = 0 > > > > > libguestfs: trace: add_drive_ro > > > > > "/home/ykaul/ovirt-system-tests/deployment-basic-suite- > > > > master/default/images/lago-basic-suite-master-host-0_root.q...

...+716,10 @@ class GuestFS(object): self._o = libguestfsmod.create (flags) self._python_return_dict = python_return_dict + # If we don't do this, the program name is always set to 'python'. + program = os.path.basename (sys.argv[0]) + libguestfsmod.set_program (self._o, program) + def __del__ (self): if self._o: libguestfsmod.close (self._o) -- 2.5.0

...lity, but I'd like to use mainstream version of libguestfs as well (the version designed for rhel-7 is expected to be quite reliable). So could you please explain why ntfs mounting was forbidden (except for virt-* programs), and how to work around this (I see two options: drop this patch or set_program("virt-hack")). Thanks in advance! -- Your sincerely, Maxim Perevedentsev

...= guestfs_get_hv (g); + guestfs_pop_error_handler (g); + if (!p || STRNEQ (p, "test")) { + fprintf (stderr, "invalid return from guestfs_get_hv\n"); + pthread_exit ((void *)-1); + } + free (p); + + guestfs_push_error_handler (g, NULL, NULL); + guestfs_set_program (g, NULL); /* deliberately cause an error */ + guestfs_pop_error_handler (g); + err = guestfs_last_error (g); + if (!err || !STRPREFIX (err, "set_program: program: ")) { + fprintf (stderr, "invalid error message: %s\n", err ? err : "NULL"); + pthread...

Hi, this series cleans up the Python sources, either static or generated, including also tests, to make them PEP 8 compliant; see https://www.python.org/dev/peps/pep-0008/ and tools like pep8. Almost all the issues reported by pep8 are fixed, reducing the issues from 3818 to 7. The changes should have no effect on the actual code, while it will help Python users with consistency with other

Previous discussion here: https://www.redhat.com/archives/libguestfs/2015-June/thread.html#00048 v2: - Use a cleanup handler to release the lock. - Rebase to upstream. Note I have not fixed the problem(s) with error handling (patch 3).

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html I have rebased and tidied up the patches, fixing a few spelling mistakes, but they are broadly the same as before. I also ran all the tests, which pass. As with the previous versions, this makes a change to the API, where you

This patch isn't ready to go upstream. In fact, I think we might do a quick 1.30 release soon, and save this patch, and also the extensive changes proposed for the test suite[1], to after 1.30. Currently it is not safe to use the same handle from multiple threads, unless you implement your own mutexes. See: http://libguestfs.org/guestfs.3.html#multiple-handles-and-multiple-threads These

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html This series was posted about 4 weeks ago: v3: https://www.redhat.com/archives/libguestfs/2017-June/msg00287.html There is no change in this series except I rebased it against current upstream head and retested. Last time there

...String, "backend")], []; fish_alias = ["backend"]; config_only = true; blocking = false; shortdesc = "set the backend"; @@ -438,7 +438,7 @@ Get the directory used by the handle to store the appliance cache." }; { defaults with name = "set_program"; added = (1, 21, 29); - style = RErr, [String "program"], []; + style = RErr, [String (PlainString, "program")], []; fish_alias = ["program"]; blocking = false; shortdesc = "set the program name"; @@ -481,7 +481,7 @@ See L<guestf...

Very large but mechanical change to the generator. Rich.

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

Split up the huge generator/actions.ml into several smaller files. Rich.