similar to: [PATCH] python: Fix UnicodeError in inspect_list_applications2() (RHBZ#1684004)

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

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

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

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

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>

gentle ping On Wed, Jun 3, 2020 at 2:52 PM Sam Eiderman <sameid@google.com> wrote: > 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

On Mon, Apr 20, 2020 at 03:37:16PM +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 Mon, Apr 20, 2020 at 3:38 PM Sam Eiderman <sameid@google.com> 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, So what are they? latin1

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 - however in some cases they are not a valid unicode > string, on SLES11 SP4 the encoding of the description of

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

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 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

On Tuesday, 30 June 2020 10:53:54 CEST Sam Eiderman wrote: > Hey Pino, > > Can you search for the previous patches I submitted? I had some discussions > regarding this with Daniel and Nir. Sure, I did read those, and I took it into account. What I said does not invalidate nor contradict that. -- Pino Toscano

Hi Sam, I was doing some work on the Python bindings, starting with removing support for Python 2 since it's EOL. I thought I would have a look at this patch. So firstly I think the last version posted is: https://www.redhat.com/archives/libguestfs/2020-April/msg00190.html My impression of this is that we shouldn't just hack the Python bindings to make this apparently work. But I

Since support for python2 is dropped we can use the new python3 syntax for type hints. Signed-off-by: Sam Eiderman <sameid@google.com> --- generator/python.ml | 39 +++++++++++++++++++++++++++++++++++---- 1 file changed, 35 insertions(+), 4 deletions(-) diff --git a/generator/python.ml b/generator/python.ml index f0d6b5d96..3640ee39a 100644 --- a/generator/python.ml +++

Here's the new API method and update to virt-inspector. I still need to implement app_arch for debian and windows (if applicable), for now they just return empty strings.

Here's the new API method and update to virt-inspector. I still need to implement app_arch for debian and windows (if applicable), for now they just return empty strings. New in v2: incorporated feedback from v1, also added patch #3 which updates the documentation where it references the deprecated API. Take it or leave it.

The current need for #ifdef's based on the presence of PyString_FromString makes both the OCaml code of the generator, and the generated C code a mess to read. Hence, add three simple wrappers to make both the OCaml, and C code more readable, and easier to tweak in the future. --- generator/python.ml | 72 ++++++++++++----------------------------------------- python/handle.c | 65

I am looking for the appropriate field to let package authors to declare the pkg documentation language for spell checkers. The most important case is to specify a preference between "en-US" or "en-GB" which can be used by the hunspell or spelling pkg to select the appropriate dictionary. WRE defines the "Language" field for documentation language, but from the

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,