[Touch-packages] [Bug 1817376] Re: krb5-admin-server postinst has broken debconf if RUN_KADMIND set in /etc/default/krb5-admin-server
We ran into this doing the upgrade from trusty to xenial. Perhaps address that transition (though trusty is nearing EOL). Maybe just remove the defaults file check all together so that package installs work reliably. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to krb5 in Ubuntu. https://bugs.launchpad.net/bugs/1817376 Title: krb5-admin-server postinst has broken debconf if RUN_KADMIND set in /etc/default/krb5-admin-server Status in krb5 package in Ubuntu: Confirmed Bug description: Package installation fails on postinst due to broken debconf when /etc/default/krb5-admin-server sets RUN_KADMIND to a value. This happens because the .config script [0] sets debconf question krb5 -admin-server/kadmind to the defaults file value when set to a value. But the .templates file [1] has no entry for this question resulting in a lookup failure. [0] https://git.launchpad.net/ubuntu/+source/krb5/tree/debian/krb5-admin-server.config#n16 [1] https://git.launchpad.net/ubuntu/+source/krb5/tree/debian/krb5-admin-server.templates This bug seems to go back to at least Xenial (and also affects debian packaging too). We worked around this locally by removing RUN_KADMIND from our local defaults file, but this was an annoying bug to sort out and should probably be fixed. That said I'm not sure if it would be more appropraite to remove the db_set from [0] or add the question back to [1]. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1817376/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1817376] [NEW] krb5-admin-server postinst has broken debconf if RUN_KADMIND set in /etc/default/krb5-admin-server
Public bug reported: Package installation fails on postinst due to broken debconf when /etc/default/krb5-admin-server sets RUN_KADMIND to a value. This happens because the .config script [0] sets debconf question krb5 -admin-server/kadmind to the defaults file value when set to a value. But the .templates file [1] has no entry for this question resulting in a lookup failure. [0] https://git.launchpad.net/ubuntu/+source/krb5/tree/debian/krb5-admin-server.config#n16 [1] https://git.launchpad.net/ubuntu/+source/krb5/tree/debian/krb5-admin-server.templates This bug seems to go back to at least Xenial (and also affects debian packaging too). We worked around this locally by removing RUN_KADMIND from our local defaults file, but this was an annoying bug to sort out and should probably be fixed. That said I'm not sure if it would be more appropraite to remove the db_set from [0] or add the question back to [1]. ** Affects: krb5 (Ubuntu) Importance: Undecided Status: New ** Summary changed: - krb5-admin-server postinst has broken debconf if RUN_KADMIND set to false in /etc/default/krb5-admin-server + krb5-admin-server postinst has broken debconf if RUN_KADMIND set in /etc/default/krb5-admin-server -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to krb5 in Ubuntu. https://bugs.launchpad.net/bugs/1817376 Title: krb5-admin-server postinst has broken debconf if RUN_KADMIND set in /etc/default/krb5-admin-server Status in krb5 package in Ubuntu: New Bug description: Package installation fails on postinst due to broken debconf when /etc/default/krb5-admin-server sets RUN_KADMIND to a value. This happens because the .config script [0] sets debconf question krb5 -admin-server/kadmind to the defaults file value when set to a value. But the .templates file [1] has no entry for this question resulting in a lookup failure. [0] https://git.launchpad.net/ubuntu/+source/krb5/tree/debian/krb5-admin-server.config#n16 [1] https://git.launchpad.net/ubuntu/+source/krb5/tree/debian/krb5-admin-server.templates This bug seems to go back to at least Xenial (and also affects debian packaging too). We worked around this locally by removing RUN_KADMIND from our local defaults file, but this was an annoying bug to sort out and should probably be fixed. That said I'm not sure if it would be more appropraite to remove the db_set from [0] or add the question back to [1]. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1817376/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1367907] Re: Segfault in gc with cyclic trash
I have confirmed that running `tox -epy34` against oslo.messaging with the old python3.4 packages continues to segfault. After upgrading to the newly built python3.4.3-1ubuntu1~14.04 package the segfaulting stops and the tests pass. This looks good to me. Thank you. Version of python from aptitude: $ aptitude show python3.4 Package: python3.4 State: installed Automatically installed: no Multi-Arch: allowed Version: 3.4.3-1ubuntu1~14.04 Priority: important Section: python Maintainer: Ubuntu Core Developers ubuntu-devel-disc...@lists.ubuntu.com Architecture: amd64 Uncompressed Size: 353 k Depends: python3.4-minimal (= 3.4.3-1ubuntu1~14.04), libpython3.4-stdlib (= 3.4.3-1ubuntu1~14.04), mime-support Suggests: python3.4-venv, python3.4-doc, binutils Conflicts: python3.4 Provides: python3.4:any Description: Interactive high-level object-oriented language (version 3.4) ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1367907 Title: Segfault in gc with cyclic trash Status in oslo.messaging: Invalid Status in Python: Fix Released Status in python3.4 package in Ubuntu: Fix Released Status in python3.4 source package in Trusty: Fix Committed Bug description: Trusty's python3.4 package is affected by python bug http://bugs.python.org/issue21435. This bug was fixed in http://hg.python.org/cpython/rev/64ba3f2de99c. Trusty should pull this fix into the python3.4 package. Note this definitely affects some python projects. `git clone https://git.openstack.org/openstack/oslo.messaging cd oslo.messaging edit tox.ini file, copy py33 target and rename to py34 tox -repy34` will segfault due to this bug. With previous versions of python unaffected by this bug there is no segfaulting. Now for details, broken using: $ lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 $ apt-cache policy python3.4 python3.4: Installed: 3.4.0-2ubuntu1 Candidate: 3.4.0-2ubuntu1 Version table: *** 3.4.0-2ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status If I install the following python3.4 packages for Unicorn on Trusty this bug is corrected. The Unicorn packages here on lp for python3.4 are python3.4.1 which includes the bug fix for this bug. libpython3.4_3.4.1-10ubuntu1_amd64.deb libpython3.4-dev_3.4.1-10ubuntu1_amd64.deb libpython3.4-stdlib_3.4.1-10ubuntu1_amd64.deb python3.4-dbg_3.4.1-10ubuntu1_amd64.deb python3.4-minimal_3.4.1-10ubuntu1_amd64.deb libpython3.4-dbg_3.4.1-10ubuntu1_amd64.deb libpython3.4-minimal_3.4.1-10ubuntu1_amd64.deb python3.4_3.4.1-10ubuntu1_amd64.deb python3.4-dev_3.4.1-10ubuntu1_amd64.deb Note I installed the -dbg packages too just in case I needed to use gdb but that wasn't necessary as the test case works with these newer versions of python. $ apt-cache policy python3.4 python3.4: Installed: 3.4.1-10ubuntu1 Candidate: 3.4.1-10ubuntu1 Version table: *** 3.4.1-10ubuntu1 0 100 /var/lib/dpkg/status 3.4.0-2ubuntu1 0 500 http://az2.clouds.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages [Impact] This python bug can cause python processes that tickle it to segfault python. This means there could be a significant number of python packages that are broken when run under this interpreter. The fix for this bug should be backported to avoid seemingly random and hard to debug segfaults from happening when users use python. Unicorn's 3.4.1 packages fix this bug by including the patch at http://hg.python.org/cpython/rev/64ba3f2de99c. [Test Case] There is a test case detailed in the upstream bug http://bugs.python.org/issue21435, though I have been doing the following instead: git clone https://git.openstack.org/openstack/oslo.messaging cd oslo.messaging git fetch https://review.openstack.org/openstack/oslo.messaging refs/changes/90/118790/2 git checkout FETCH_HEAD tox -repy34 # This should end with segfaulting test runners. Note if you don't have tox installed you will need to install version 1.7.2 or greater. `sudo pip install tox==1.7.2` will do this. [Regression Potential] The patch in question is small. If we go straight to python 3.4.1 the diff will be larger but that isn't necessary to fix this particular issue. The biggest regression potential would be that the garbage collector is newly broken by the this bug fix. Considering that the garbage collector is already broken and this patch comes with test cases to check it is less broken the risk of regression here is less than the pain of dealing with this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.messaging/+bug/1367907/+subscriptions
[Touch-packages] [Bug 1382607] [NEW] Backport python3.4 logging module backward incompatibility fix.
Public bug reported:
Python 3.4 released with a backward incompatible change in the logging module.
This bug has been tracked and fixed
upstream in http://bugs.python.org/issue22386. Summary is that
logging.getLevelName(lvl)
would return an integer value for a string lvl and a string value for an
integer lvl.
It mapped the two representations of log levels to each other. This behavior
existed
in python2.6 through python3.3 but was removed in 3.4. The new behavior in 3.4
was to
only map integer lvl values to strings.
[Impact]
Any python code that aims to be compatible with python2.6 and python3.4 must
carry its
own log level mappings (which may change under it because the loglevels are
extensible)
or access private data within the python logging module. Both approaches are
fragile
but thankfully upstream python 3.4 has patched this behavior so a downstream
update
to Trusty python3.4 would allow code to easily support 2.6 and 3.4.
[Test Case]
As detailed in the upstream bug you can test this easily via the
interactive interpreter.
Desired Behavior:
logging.getLevelName('INFO')
20
logging.getLevelName(20)
'INFO'
Current Trusty Behavior:
# This function call should return 20.
logging.getLevelName('INFO')
'Level INFO'
logging.getLevelName(20)
'INFO'
logging.getLevelName(logging.INFO)
'INFO'
[Regression Potential]
The upstream patch is tiny and comes with a test case to track the desired
behavior
(upstream already had tests for the other behavior of this function). Beacuse
this
patch is so small and comes with new tests I think the regression potential is
very
small. Probably the only thing to consider is that new python3.4 code may have
come
to rely on this new backward incompatible behavior. But that would only be the
case
if code specifically looked for the mapping of 'Level %s' % 'stringlevelhere'.
** Affects: python
Importance: Unknown
Status: Unknown
** Affects: python3.4 (Ubuntu)
Importance: Undecided
Status: New
** Bug watch added: Python Roundup #22386
http://bugs.python.org/issue22386
** Also affects: python via
http://bugs.python.org/issue22386
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3.4 in Ubuntu.
https://bugs.launchpad.net/bugs/1382607
Title:
Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Unknown
Status in “python3.4” package in Ubuntu:
New
Bug description:
Python 3.4 released with a backward incompatible change in the logging
module. This bug has been tracked and fixed
upstream in http://bugs.python.org/issue22386. Summary is that
logging.getLevelName(lvl)
would return an integer value for a string lvl and a string value for an
integer lvl.
It mapped the two representations of log levels to each other. This behavior
existed
in python2.6 through python3.3 but was removed in 3.4. The new behavior in
3.4 was to
only map integer lvl values to strings.
[Impact]
Any python code that aims to be compatible with python2.6 and python3.4 must
carry its
own log level mappings (which may change under it because the loglevels are
extensible)
or access private data within the python logging module. Both approaches are
fragile
but thankfully upstream python 3.4 has patched this behavior so a downstream
update
to Trusty python3.4 would allow code to easily support 2.6 and 3.4.
[Test Case]
As detailed in the upstream bug you can test this easily via the
interactive interpreter.
Desired Behavior:
logging.getLevelName('INFO')
20
logging.getLevelName(20)
'INFO'
Current Trusty Behavior:
# This function call should return 20.
logging.getLevelName('INFO')
'Level INFO'
logging.getLevelName(20)
'INFO'
logging.getLevelName(logging.INFO)
'INFO'
[Regression Potential]
The upstream patch is tiny and comes with a test case to track the desired
behavior
(upstream already had tests for the other behavior of this function). Beacuse
this
patch is so small and comes with new tests I think the regression potential
is very
small. Probably the only thing to consider is that new python3.4 code may
have come
to rely on this new backward incompatible behavior. But that would only be
the case
if code specifically looked for the mapping of 'Level %s' % 'stringlevelhere'.
To manage notifications about this bug go to:
https://bugs.launchpad.net/python/+bug/1382607/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: Backport python3.4 logging module backward incompatibility fix.
I should also note that https://hg.python.org/cpython/rev/a4c5effb8698
is where the upstream bug was fixed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3.4 in Ubuntu.
https://bugs.launchpad.net/bugs/1382607
Title:
Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Unknown
Status in “python3.4” package in Ubuntu:
New
Bug description:
Python 3.4 released with a backward incompatible change in the logging
module. This bug has been tracked and fixed
upstream in http://bugs.python.org/issue22386. Summary is that
logging.getLevelName(lvl)
would return an integer value for a string lvl and a string value for an
integer lvl.
It mapped the two representations of log levels to each other. This behavior
existed
in python2.6 through python3.3 but was removed in 3.4. The new behavior in
3.4 was to
only map integer lvl values to strings.
[Impact]
Any python code that aims to be compatible with python2.6 and python3.4 must
carry its
own log level mappings (which may change under it because the loglevels are
extensible)
or access private data within the python logging module. Both approaches are
fragile
but thankfully upstream python 3.4 has patched this behavior so a downstream
update
to Trusty python3.4 would allow code to easily support 2.6 and 3.4.
[Test Case]
As detailed in the upstream bug you can test this easily via the
interactive interpreter.
Desired Behavior:
logging.getLevelName('INFO')
20
logging.getLevelName(20)
'INFO'
Current Trusty Behavior:
# This function call should return 20.
logging.getLevelName('INFO')
'Level INFO'
logging.getLevelName(20)
'INFO'
logging.getLevelName(logging.INFO)
'INFO'
[Regression Potential]
The upstream patch is tiny and comes with a test case to track the desired
behavior
(upstream already had tests for the other behavior of this function). Beacuse
this
patch is so small and comes with new tests I think the regression potential
is very
small. Probably the only thing to consider is that new python3.4 code may
have come
to rely on this new backward incompatible behavior. But that would only be
the case
if code specifically looked for the mapping of 'Level %s' % 'stringlevelhere'.
To manage notifications about this bug go to:
https://bugs.launchpad.net/python/+bug/1382607/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1367907] [NEW] Segfault in gc with cyclic trash
Public bug reported: Trusty's python3.4 package is affected by python bug http://bugs.python.org/issue21435. This bug was fixed in http://hg.python.org/cpython/rev/64ba3f2de99c. Trusty should pull this fix into the python3.4 package. Note this definitely affects some python projects. `git clone https://git.openstack.org/openstack/oslo.messaging cd oslo.messaging edit tox.ini file, copy py33 target and rename to py34 tox -repy34` will segfault due to this bug. With previous versions of python unaffected by this bug there is no segfaulting. Now for details: $ lsb_release -rd Description:Ubuntu 14.04.1 LTS Release:14.04 $ apt-cache policy python3.4 python3.4: Installed: 3.4.0-2ubuntu1 Candidate: 3.4.0-2ubuntu1 Version table: *** 3.4.0-2ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status ** Affects: oslo.messaging Importance: Undecided Assignee: Clark Boylan (cboylan) Status: New ** Affects: python Importance: Unknown Status: Unknown ** Affects: python3.4 (Ubuntu) Importance: Undecided Status: New ** Bug watch added: Python Roundup #21435 http://bugs.python.org/issue21435 ** Also affects: python via http://bugs.python.org/issue21435 Importance: Unknown Status: Unknown ** Description changed: Trusty's python3.4 package is affected by python bug http://bugs.python.org/issue21435. This bug was fixed in http://hg.python.org/cpython/rev/64ba3f2de99c. Trusty should pull this fix into the python3.4 package. Note this definitely affects some python projects. `git clone https://git.openstack.org/openstack/oslo.messaging cd oslo.messaging - tox -repy34` will segfault due to this bug. With previous versions of - python unaffected by this bug there is no segfaulting. + edit tox.ini file, copy py33 target and rename to py34 tox + -repy34` will segfault due to this bug. With previous versions of python + unaffected by this bug there is no segfaulting. Now for details: $ lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 $ apt-cache policy python3.4 python3.4: - Installed: 3.4.0-2ubuntu1 - Candidate: 3.4.0-2ubuntu1 - Version table: - *** 3.4.0-2ubuntu1 0 - 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages - 100 /var/lib/dpkg/status + Installed: 3.4.0-2ubuntu1 + Candidate: 3.4.0-2ubuntu1 + Version table: + *** 3.4.0-2ubuntu1 0 + 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages + 100 /var/lib/dpkg/status ** Also affects: oslo.messaging Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1367907 Title: Segfault in gc with cyclic trash Status in Messaging API for OpenStack: New Status in Python: Unknown Status in “python3.4” package in Ubuntu: New Bug description: Trusty's python3.4 package is affected by python bug http://bugs.python.org/issue21435. This bug was fixed in http://hg.python.org/cpython/rev/64ba3f2de99c. Trusty should pull this fix into the python3.4 package. Note this definitely affects some python projects. `git clone https://git.openstack.org/openstack/oslo.messaging cd oslo.messaging edit tox.ini file, copy py33 target and rename to py34 tox -repy34` will segfault due to this bug. With previous versions of python unaffected by this bug there is no segfaulting. Now for details: $ lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 $ apt-cache policy python3.4 python3.4: Installed: 3.4.0-2ubuntu1 Candidate: 3.4.0-2ubuntu1 Version table: *** 3.4.0-2ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.messaging/+bug/1367907/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1367907] Re: Segfault in gc with cyclic trash
** Description changed: Trusty's python3.4 package is affected by python bug http://bugs.python.org/issue21435. This bug was fixed in http://hg.python.org/cpython/rev/64ba3f2de99c. Trusty should pull this fix into the python3.4 package. Note this definitely affects some python projects. `git clone https://git.openstack.org/openstack/oslo.messaging cd oslo.messaging edit tox.ini file, copy py33 target and rename to py34 tox -repy34` will segfault due to this bug. With previous versions of python unaffected by this bug there is no segfaulting. - Now for details: + Now for details, broken using: $ lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 $ apt-cache policy python3.4 python3.4: Installed: 3.4.0-2ubuntu1 Candidate: 3.4.0-2ubuntu1 Version table: *** 3.4.0-2ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status + + If I install the following python3.4 packages for Unicorn on Trusty this + bug is corrected. The Unicorn packages here on lp for python3.4 are + python3.4.1 which includes the bug fix for this bug. + + libpython3.4_3.4.1-10ubuntu1_amd64.deb + libpython3.4-dev_3.4.1-10ubuntu1_amd64.deb + libpython3.4-stdlib_3.4.1-10ubuntu1_amd64.deb + python3.4-dbg_3.4.1-10ubuntu1_amd64.deb + python3.4-minimal_3.4.1-10ubuntu1_amd64.deb + libpython3.4-dbg_3.4.1-10ubuntu1_amd64.deb + libpython3.4-minimal_3.4.1-10ubuntu1_amd64.deb + python3.4_3.4.1-10ubuntu1_amd64.deb + python3.4-dev_3.4.1-10ubuntu1_amd64.deb + + Note I installed the -dbg packages too just in case I needed to use gdb + but that wasn't necessary as the test case works with these newer + versions of python. + + $ apt-cache policy python3.4 + python3.4: + Installed: 3.4.1-10ubuntu1 + Candidate: 3.4.1-10ubuntu1 + Version table: + *** 3.4.1-10ubuntu1 0 + 100 /var/lib/dpkg/status + 3.4.0-2ubuntu1 0 + 500 http://az2.clouds.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages + + [Impact] + + This python bug can cause python processes that tickle it to segfault + python. This means there could be a significant number of python + packages that are broken when run under this interpreter. The fix for + this bug should be backported to avoid seemingly random and hard to + debug segfaults from happening when users use python. + + Unicorn's 3.4.1 packages fix this bug by including the patch at + http://hg.python.org/cpython/rev/64ba3f2de99c. + + [Test Case] + + There is a test case detailed in the upstream bug http://bugs.python.org/issue21435, though I have been doing the following instead: + git clone https://git.openstack.org/openstack/oslo.messaging + cd oslo.messaging + git fetch https://review.openstack.org/openstack/oslo.messaging refs/changes/90/118790/2 git checkout FETCH_HEAD + tox -repy34 + # This should end with segfaulting test runners. Note if you don't have tox installed you will need to install version 1.7.2 or greater. `sudo pip install tox==1.7.2` will do this. + + [Regression Potential] + + The patch in question is small. If we go straight to python 3.4.1 the + diff will be larger but that isn't necessary to fix this particular + issue. The biggest regression potential would be that the garbage + collector is newly broken by the this bug fix. Considering that the + garbage collector is already broken and this patch comes with test cases + to check it is less broken the risk of regression here is less than the + pain of dealing with this bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1367907 Title: Segfault in gc with cyclic trash Status in Messaging API for OpenStack: New Status in Python: Unknown Status in “python3.4” package in Ubuntu: New Bug description: Trusty's python3.4 package is affected by python bug http://bugs.python.org/issue21435. This bug was fixed in http://hg.python.org/cpython/rev/64ba3f2de99c. Trusty should pull this fix into the python3.4 package. Note this definitely affects some python projects. `git clone https://git.openstack.org/openstack/oslo.messaging cd oslo.messaging edit tox.ini file, copy py33 target and rename to py34 tox -repy34` will segfault due to this bug. With previous versions of python unaffected by this bug there is no segfaulting. Now for details, broken using: $ lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 $ apt-cache policy python3.4 python3.4: Installed: 3.4.0-2ubuntu1 Candidate: 3.4.0-2ubuntu1 Version table: *** 3.4.0-2ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status If I install the following python3.4 packages for Unicorn on Trusty this bug is corrected. The Unicorn packages here on lp for python3.4 are python3.4.1
