Project

General

Profile

Pull request #184

Update omniORB & omniORBpy to 4.2.2

Added by Guilhem Saurel 5 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Repository URL:
Repository branch:

Description

Hi,

Following discussions in
https://github.com/Gepetto/gepetto-viewer-corba/issues/85, we would like to update omniORB to 4.2.2, to add python 3 support.

These commits https://github.com/nim65s/robotpkg/tree/omniorb will update omniORB, but not yet enable python3 support, because I am not sure about how to do it properly in the robotpkg environment. Maybe should we add ${PKGTAG.python-} to the PKGNAME ? Or could we the package for both python2 & python 3

Associated revisions

Revision 8b4e03e4 (diff)
Added by Guilhem Saurel 5 months ago

[middleware/omniORB] Update to v4.2.2

Addresses issue #184

Changes since omniORB 4.2.1
---------------------------

omniORB 4.2.2 is primarily a bug fix release. See update.log for full
details of changes. Highlights include:

- Support for cross-compilation using the configure script.
- New defaultCharCodeSet and defaultWCharCodeSet configuration
parameters to handle code set conversion with corbaloc URIs and
badly-behaved servers.
- Suppression of many compiler warnings.

Changes since omniORB 4.2.0
---------------------------

omniORB 4.2.1 is primarily a bug fix release. See update.log for full
details of changes. Highlights include:

- Improved Python 3 support.
- Additional SSL / TLS options.
- The default DH parameters for TLS are now 2048 bits.
- More efficient marshalling of messages including large numbers of
valuetypes.

Changes since omniORB 4.1.x
---------------------------

omniORB 4.2 has a number of new features compared to omniORB 4.1.x,
both large and small. Here are the highlights:

- Full Asynchronous Method Invocation (AMI) support.
- Support for ZIOP, which compresses large messages.
- Call timeouts are indicated with the CORBA::TIMEOUT exception,
rather than CORBA::TRANSIENT (unless suppressed with the
throwTransientOnTimeout configuration parameter).
- Servers can be limited to a range of ports to listen on.
- Performance improvements to Any, sequence buffer management,
unions, and other areas.
- Ancient Python versions are no longer supported. omniidl and
omniORBpy now only work with Python 2.5 or later.
- omniidl works with Python 3.x as well as 2.x.

Changes since omniORB 4.1.6
---------------------------

- Bug fixes and platform updates. See bugfixes-416.xml
- ZIOP support. See src/examples/ziop/README.txt for details.

Changes since omniORB 4.1.5
---------------------------

- Bug fixes. See bugfixes-415.xml
- New clientOpenConnection and serverAcceptConnection interceptors.

Changes since omniORB 4.1.4
---------------------------

- Bug fixes. See bugfixes-414.xml
- Support for building with the newest versions of Cygwin.
- Incoming SSL connections can time out waiting for SSL_accept to complete.
- Ability to disable longdouble support during compilation.

Revision 09b31432 (diff)
Added by Guilhem Saurel 5 months ago

[middleware/omniORBpy] Update to v4.2.2

Addresses issue #184

Packaging changes:
------------------

- update patch-a{a,c,d}
- add patch-ae to remove the "module.so" extension from python2 C modules, and
just use ".so", so as to not break the PLIST with python2.

Changes since omniORB 4.2.1
---------------------------

omniORB 4.2.2 is primarily a bug fix release. See update.log for full
details of changes. The main omniORBpy highlight is better support for
Python 3. For other new features, see the omniORB release notes.

Changes since omniORB 4.2.0
---------------------------

The big highlight of this release is full Python 3 support. Versions
from 3.2 onwards are supported.

Other changes are minor bug fixes. See update.log for full details.

Changes since omniORB 4.1.x / omniORBpy 3.x
-------------------------------------------

omniORBpy 4.2 has a number of new features and changes compared to
omniORB 4.1.x / omniORBpy 3.x. Here are the highlights:

- The omniORBpy version number now matches the core omniORB version
number.
- Full Asynchronous Method Invocation (AMI) support.
- Support for ZIOP, which compresses large messages.
- Call timeouts are indicated with the CORBA.TIMEOUT exception,
rather than CORBA.TRANSIENT (unless suppressed with the
throwTransientOnTimeout configuration parameter).
- Servers can be limited to a range of ports to listen on.
- When CORBA.BAD_PARAM is raised due to parameter types that do not
match the IDL definitions, detailed information about the cause is
now reported.
- IDL attributes can now be accessed as properties of object
references. i.e. IDL attribute 'example' can be accessed as
obj.example as well as with obj._get_example() and
obj._set_example().
- Ancient Python versions are no longer supported. omniidl and
omniORBpy now only work with Python 2.5 or later.

Changes since omniORBpy 3.6
---------------------------

- Minor fixes.
- Track ORB core 4.1.7 release.

Changes since omniORBpy 3.5
---------------------------

- Build fixes.
- Track ORB core 4.1.6 release.

Changes since omniORBpy 3.4
---------------------------

- Bug fixes. See bugfixes-34.xml.
- Allow passing of peer address and identity to interceptors.
- Exceptions can be pickled.

Changes since omniORBpy 3.3
---------------------------

- Bug fixes. See bugfixes-33.xml.

Changes since omniORBpy 3.2
---------------------------

- Bug fixes. See bugfixes-32.xml.

Changes since omniORBpy 3.1
---------------------------

- Bug fixes. See bugfixes-31.xml.

History

#1

Updated by Anthony Mallet 5 months ago

The default PREFER.omniORB on ubuntu 18.04 should not be 'robotpkg',
as this would create a big mess for people normally installing it via
system packages - and it would as a side effect create binary packages
pulling a custom version of omniORB.

#2

Updated by Anthony Mallet 5 months ago

Also, middleware/omniORB and middleware/omniORBpy should be in sync.
It looks like you only updated middleware/omniORBpy.

#3

Updated by Guilhem Saurel 5 months ago

I updated both:
- omniORB https://github.com/nim65s/robotpkg/commit/279f087fa29d681f5f8b0ec5cdc674f7c40eddb5
- omniORBpy https://github.com/nim65s/robotpkg/commit/1ed1a91be34ce1879415120a9685a6e8943989b8

About the PREFER, I don't really mind, as long as we can build packages with the python 3 version :)

#4

Updated by Anthony Mallet 5 months ago

On Friday 26 Oct 2018, at 12:12, Guilhem Saurel wrote:

https://github.com/nim65s/robotpkg/commit/279f087fa29d681f5f8b0ec5cdc674f7c40eddb5

Sorry, I missed that one ...

#5

Updated by Joseph Mirabel 5 months ago

I do not know if it is possible to have simultaneously omniORB with python 2 and 3. The issue comes with omniidl (part of omniORBpy) which installs files in /usr/lib/omniidl/ regardless of the version of Python.

It will work only if theses files are compatible with Python 2 and 3. I believe the libraries won't be and the Python files will.

#6

Updated by Guilhem Saurel 5 months ago

Then, we could either patch a few things to put omniidl in a path dependent of the python version, or rename it omniidl-py2 / omniidl-py3, or rename the packages to be robotpkg-py27-omniorb / robotpkg-py35-omniorb and set them incompatible to each other.

#7

Updated by Anthony Mallet 5 months ago

On Friday 26 Oct 2018, at 16:11, Joseph Mirabel wrote:

I do not know if it is possible to have simultaneously omniORB with
python 2 and 3. The issue comes with omniidl (part of omniORBpy) which
installs files in /usr/lib/omniidl/ regardless of the version of
Python.

This is the debian packaging that installs files to /usr/lib/omniidl
for omniORBpy. robotpkg (or rather omniORBpy by default) installs them
in an appropriate location (PYTHON_SITELIB).

omniidl is however not part of omniORBpy, it's from omniORB. The fact
that omniidl is implemented in python is unrelated (although bringing
in a lot of confusion) to the omniORBpy target python version. For
instance, on ubuntu-18.04, omniidl uses python3 as it's interpreter,
but python-omniorb is for python2 (don't ask why).

It happens sometimes that a package is implemented in python (which
is an internal concern) and also produces or deal with python
code (I'm looking at sphinx or morse). Then the two python versions
are in principle unrelated, but in practice it's a mess to separate
the two. In particular, robotpkg cannot depend on more than one python
version for a package.

#8

Updated by Guilhem Saurel 4 months ago

  • Status changed from New to Closed

I checked that we can now get gepetto-viewer-corba (on the devel branch, with minor updates) working with python3, so it's OK for me, thanks !

Also available in: Atom PDF