similar to: [PATCH] python: Add type hints

On Mon, Jul 06, 2020 at 07:50:19PM +0300, Sam Eiderman wrote: > Since support for python2 is dropped we can use the new python3 syntax > for type hints. Interesting - didn't know about this. I have pushed this, and another patch to update the published minimum version of Python to 3.6. I don't test anything earlier, although in theory it could work for 3.5 still. Rich. >

Notice that I have added the closing bracket and return type hint into the indentation function as a hack to line wrap correctly when the return type hint is causing > 79 chars per line: So that instead of: def btrfs_subvolume_create(self, dest: str, qgroupid: Optional[str] = None) -> None: We correctly get: def btrfs_subvolume_create(self, dest: str,

Fixes the majority of the pycodestyle issues in the Python bindings, leaving only an overly length line in setup.py. Add a simple optional pycodestyle-based test to avoid regressions in the future. Pino Toscano (7): python: PEP 8: adapt empty lines python: PEP 8: adapt whitespaces in lines python: tests: catch specific exception python: tests: improve variable naming python: tests:

Fixes all the pycodestyle issues in the Python bindings, overring one that does not make sense to change (and it's in setup.py, so almost irrelevant). Add a simple optional pycodestyle-based test to avoid regressions in the future. Pino Toscano (8): python: PEP 8: adapt empty lines python: PEP 8: adapt whitespaces in lines python: tests: catch specific exception python: tests:

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

The python3 bindings create unicode objects from application strings on the guest (i.e. installed rpm, deb packages). It is documented that rpm package fields such as description should be utf8 encoded - however in some cases they are not a valid unicode string, on SLES11 SP4 the following packages fail to be converted to unicode using guestfs_int_py_fromstring() (which invokes

The python3 bindings create unicode objects from application strings on the guest (i.e. installed rpm, deb packages). It is documented that rpm package fields such as description should be utf8 encoded - however in some cases they are not a valid unicode string, on SLES11 SP4 the following packages fail to be converted to unicode using guestfs_int_py_fromstring() (which invokes

The python3 bindings create PyUnicode objects from application strings on the guest (i.e. installed rpm, deb packages). It is documented that rpm package fields such as description should be utf8 encoded - however in some cases they are not a valid unicode string, on SLES11 SP4 the encoding of the description of the following packages is latin1 and they fail to be converted to unicode using

For a very long time we have maintained two sets of utility functions, in mllib/common_utils.ml and generator/utils.ml. This changes things so that the same set of utility functions can be shared with both directories. It's not possible to use common_utils.ml directly in the generator because it provides several functions that use modules outside the OCaml stdlib. Therefore we add some

Hey Pino, Can you search for the previous patches I submitted? I had some discussions regarding this with Daniel and Nir. Thanks! On Tue, Jun 30, 2020 at 11:43 AM Pino Toscano <ptoscano@redhat.com> wrote: > On Sunday, 26 April 2020 20:14:03 CEST Sam Eiderman wrote: > > The python3 bindings create PyUnicode objects from application strings > > on the guest (i.e. installed

By creating an empty disk and using it as the first disk of the vm (i.e. /dev/sda, /dev/sdb{1,2} contains the windows fses) we change the iteration order of the disks. This causes inspect_os() to fail since Parted returns a Unix_error if the device does not contain any partitions - fix this by handling this Unix_error. Signed-off-by: Sam Eiderman <sameid@google.com> ---

This map was originally included just for the java bindings, but is generally useful to any binding which uses camel case by requirement or convention. --- generator/generator_haskell.ml | 4 ++-- generator/generator_java.ml | 10 +++++----- generator/generator_main.ml | 2 +- generator/generator_structs.ml | 12 +++++------- generator/generator_structs.mli | 8 ++++---- 5

Yea, I noticed that commit, but since it was used in gpt too regardless of that commit, I decided not to mention this regression. I also noticed that list_filesystems() still works, this is probably due to filtering of devices (daemon/listfs.ml): "let devices = List.filter is_not_partitioned_device devices in" What do you have in mind here? On Tue, Jun 30, 2020 at 12:33 PM Pino

On Wed, May 13, 2020 at 10:06 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Sun, Apr 26, 2020 at 09:14:03PM +0300, Sam Eiderman wrote: > > The python3 bindings create PyUnicode objects from application strings > > on the guest (i.e. installed rpm, deb packages). > > It is documented that rpm package fields such as description should be > > utf8 encoded

I see, thanks for the clarification. On Thu, Aug 27, 2020 at 12:05 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Thu, Aug 27, 2020 at 11:24:57AM +0300, Sam Eiderman wrote: > > Yes, I understand that, I am just surprised to know that we bind /sys > > for g.sh() commands. > > > > However, "g.command([self.mkconfig, '-o', self.config])"

Hi, It seems that on Windows we create the following dir: /Program Files/Guestfs/Firstboot/ Where '/' is the os volume (where /Windows reside) Is it possible that Program Files is not actually located on the os volume? (i.e. C:\Windows, D:\Program Files on original vm) Does virt-v2v or even libguestfs's inspect_os() even support that? (Looking around in the code tells me that if

On Mon, Apr 20, 2020 at 01:17:35PM +0300, Sam Eiderman wrote: > The python3 bindings create unicode objects from application strings > on the guest (i.e. installed rpm, deb packages). > It is documented that rpm package fields such as description should be > utf8 encoded - however in some cases they are not a valid unicode > string, on SLES11 SP4 the following packages fail to be

On Thu, Aug 27, 2020 at 11:08 AM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Thu, Aug 27, 2020 at 10:50:12AM +0300, Sam Eiderman wrote: > > Hi, > > > > I'm using libguestfs 1.42, > > > > When I run the following python3 commands on a rhel7.8: > > > > print(g.ls('/sys')) > > [] > > This lists the files in /sys in

Hi Nir, I think latin1, How do you think we should handle latin1 errors then? Replace on latin1 or replace on utf-8? for codec in ["utf8", "latin1"]: try: return decode(b, codec) except: pass return decode(b, "utf8", errors="replace") (Pseudocode, will be implemented in c) On Thu, Apr 23, 2020, 21:34 Nir Soffer <nsoffer@redhat.com>

Hi, I'm using libguestfs 1.42, When I run the following python3 commands on a rhel7.8: print(g.ls('/sys')) print(g.sh('ls /sys')) I get: [] block bus class dev devices firmware fs hypervisor kernel module power It seems that g.ls('/sys') is chrooted correctly. But g.sh('ls /sys') isn't. I came across this behavior when I used