[libvirt] update keycodemapdb submodule for 4.1.0 release
I mistakenly dropped keycodemapdb commit 6b3d716e from our libvirt 4.1.0 builds only to stumble across the failures in py3 environments that are fixed by that commit. Should the submodule be updated for the 4.1.0 release? Regards, Jim
On Thu, Mar 01, 2018 at 09:47:32AM -0700, Jim Fehlig wrote:
I mistakenly dropped keycodemapdb commit 6b3d716e from our libvirt 4.1.0 builds only to stumble across the failures in py3 environments that are fixed by that commit. Should the submodule be updated for the 4.1.0 release?
Since the release is scheduled for tomorrow I'm pretty wary of updating the submodule before that. You show that we we missing CI coverage for python3 though, so we should address that. We could make our Fedora Jenkins CI builds use py3, along with one of our Travis scenarios, so we get a mix of py2&py3 coverage in both Jenkins & Travis. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Mar 01, 2018 at 04:52:09PM +0000, Daniel P. Berrangé wrote:
On Thu, Mar 01, 2018 at 09:47:32AM -0700, Jim Fehlig wrote:
I mistakenly dropped keycodemapdb commit 6b3d716e from our libvirt 4.1.0 builds only to stumble across the failures in py3 environments that are fixed by that commit. Should the submodule be updated for the 4.1.0 release?
Since the release is scheduled for tomorrow I'm pretty wary of updating the submodule before that.
You show that we we missing CI coverage for python3 though, so we should address that. We could make our Fedora Jenkins CI builds use py3, along with one of our Travis scenarios, so we get a mix of py2&py3 coverage in both Jenkins & Travis.
Do we? I think the builds were switched so that we can run unit tests on virt-manager so now we have CI coverage for py2 as well as py3.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, 2018-03-02 at 08:08 +0100, Martin Kletzander wrote:
On Thu, Mar 01, 2018 at 04:52:09PM +0000, Daniel P. Berrangé wrote:
You show that we we missing CI coverage for python3 though, so we should address that. We could make our Fedora Jenkins CI builds use py3, along with one of our Travis scenarios, so we get a mix of py2&py3 coverage in both Jenkins & Travis.
Do we? I think the builds were switched so that we can run unit tests on virt-manager so now we have CI coverage for py2 as well as py3.
We use both Python 2 and 3, but only for project that are themselves implemented in Python (libvirt-python and virt-manager); what I think Dan is referring to is that we only ever use Python 2 to call keycodemapdb's own tools, so there's no Python 3 coverage for that. -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Mar 02, 2018 at 11:24:03AM +0100, Andrea Bolognani wrote:
On Fri, 2018-03-02 at 08:08 +0100, Martin Kletzander wrote:
On Thu, Mar 01, 2018 at 04:52:09PM +0000, Daniel P. Berrangé wrote:
You show that we we missing CI coverage for python3 though, so we should address that. We could make our Fedora Jenkins CI builds use py3, along with one of our Travis scenarios, so we get a mix of py2&py3 coverage in both Jenkins & Travis.
Do we? I think the builds were switched so that we can run unit tests on virt-manager so now we have CI coverage for py2 as well as py3.
We use both Python 2 and 3, but only for project that are themselves implemented in Python (libvirt-python and virt-manager); what I think Dan is referring to is that we only ever use Python 2 to call keycodemapdb's own tools, so there's no Python 3 coverage for that.
Yeah exactly - some bits of libvirt build process use python scripts and so we should test that under both. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Mar 02, 2018 at 10:45:35AM +0000, Daniel P. Berrangé wrote:
On Fri, Mar 02, 2018 at 11:24:03AM +0100, Andrea Bolognani wrote:
On Fri, 2018-03-02 at 08:08 +0100, Martin Kletzander wrote:
On Thu, Mar 01, 2018 at 04:52:09PM +0000, Daniel P. Berrangé wrote:
You show that we we missing CI coverage for python3 though, so we should address that. We could make our Fedora Jenkins CI builds use py3, along with one of our Travis scenarios, so we get a mix of py2&py3 coverage in both Jenkins & Travis.
Do we? I think the builds were switched so that we can run unit tests on virt-manager so now we have CI coverage for py2 as well as py3.
We use both Python 2 and 3, but only for project that are themselves implemented in Python (libvirt-python and virt-manager); what I think Dan is referring to is that we only ever use Python 2 to call keycodemapdb's own tools, so there's no Python 3 coverage for that.
Yeah exactly - some bits of libvirt build process use python scripts and so we should test that under both.
Oh, thanks for the explanation, that makes sense.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Mar 01, 2018 at 09:47:32AM -0700, Jim Fehlig wrote:
I mistakenly dropped keycodemapdb commit 6b3d716e from our libvirt 4.1.0 builds only to stumble across the failures in py3 environments that are fixed by that commit. Should the submodule be updated for the 4.1.0 release?
BTW, we just hit a problem with macOS homebrew changing python to point to a py3 binary and that showed other libvirt failures. In particular the ESX code generator is broken under py2. I wouldn't be surprised if more of our python scripts are also broken. So I think we need a general work item to fix py3 compat for libvirt - if someone wants to work on it for the 4.2.0 release.... Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 05/03/18 10:27, Daniel P. Berrangé wrote:
BTW, we just hit a problem with macOS homebrew changing python to point to a py3 binary and that showed other libvirt failures. In particular the ESX code generator is broken under py2. I wouldn't be surprised if more of our python scripts are also broken. So I think we need a general work item to fix py3 compat for libvirt - if someone wants to work on it for the 4.2.0 release....
I noticed that in there are only 7 python files which need to be made compatible with Py3. docs/reformat-news.py docs/apibuild.py docs/index.py src/hyperv/hyperv_wmi_generator.py src/esx/esx_vi_generator.py tests/cputestdata/cpu-reformat.py tests/cputestdata/cpu-cpuid.py The 2to3 tool shows some obvious fixes. (e.g. print statement, dict.items(), etc.) In addition, this documentation very helpful: http://www.diveintopython3.net/porting-code-to-python-3-with-2to3.html Radostin
participants (5)
-
Andrea Bolognani -
Daniel P. Berrangé -
Jim Fehlig -
Martin Kletzander -
Radostin Stoyanov