Bug#840930: vmware-nsx: FTBFS: AttributeError: 'module' object has no attribute 'SecurityGroup'

2017-08-08 Thread Allison Randal
IIRC, in the OpenStack packaging sprint at DebCamp last week we agreed to remove vmware-nsx from unstable. (The package never made it to testing or any stable release.)

Bug#840930: vmware-nsx: FTBFS: AttributeError: 'module' object has no attribute 'SecurityGroup'

2017-02-27 Thread Allison Randal
On 02/27/2017 05:34 PM, Thomas Goirand wrote: > > Yes, because it FTBFS as well. Thanks Thomas. How important would you rate vmware-nsx? It's currently removed from testing. It has no rdepends, so I'm thinking it's probably fine to leave it out of stretch, and fix it in unstable for future releas

Bug#840930: vmware-nsx: FTBFS: AttributeError: 'module' object has no attribute 'SecurityGroup'

2017-02-27 Thread Allison Randal
The version of the neutron package currently in unstable and stretch (9.1.1) is incompatible with the version of vmware-nsx in unstable (8.0.0). During the Newton release cycle, Neutron was changed to move SecurityGroup from: neutron.db.securitygroups_db to: neutron.db.models.securitygroup For

Bug#674213: gpsdrive: not installable in sid

2013-01-25 Thread Allison Randal
Hi Hamish, What's the status on the upstream work here? Is it worth waiting for a new upstream release, or is it better to go ahead and package 2.11? Could the fixes for mapnik be applied to the 2.11 packages as patches, or are the changes too extensive for that? Note that this FTBFS has been (te

Bug#694808: libv8: CVE-2012-5120 CVE-2012-5128

2012-12-16 Thread Allison Randal
The details on these two CVE's are 403 for me: CVE-2012-5120 https://code.google.com/p/chromium/issues/detail?id=150729 CVE-2012-5128 https://code.google.com/p/chromium/issues/detail?id=157124 So presumably they're still embargoed and only accessible to certain members of pkg-javascript. Alliso

Bug#650453: magics++: as-needed.patch doesn't apply, causing, FTBFS

2011-12-06 Thread Allison Randal
On 12/06/2011 02:48 PM, Julien Cristau wrote: > > I know about no-add-needed, but that doesn't make it ok for a library > such as libemosR64.so to have undefined symbols. It's also possible to make the fix for the linking flags in libemos instead. If -lm -lquadmath -lgfortran are really only used

Bug#650453: magics++: as-needed.patch doesn't apply, causing, FTBFS

2011-12-06 Thread Allison Randal
On 12/06/2011 01:15 PM, Julien Cristau wrote: > On Tue, Dec 6, 2011 at 11:41:00 -0800, Allison Randal wrote: > >> /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libemosR64.so: >> undefined reference to `sqrtq' >> > That sounds like a bug in libemos. It'

Bug#650453: magics++: as-needed.patch doesn't apply, causing, FTBFS

2011-12-06 Thread Allison Randal
e debian/as-needed.patch so it applies to changed +config/ltmain.sh. + * debian/rules: Add "-lm -lquadmath -lgfortran" to LIBS in configure +line to directly link libraries that are needed. + * Update debian/patches/dynamic_link.patch to add +"-lm -lquadmath -lgfortra

Bug#650453: magics++: as-needed.patch doesn't apply, causing, FTBFS

2011-12-05 Thread Allison Randal
The attached file is an update for the as-needed.patch file, and applies cleanly during the build. However, the package is still FTBFS with this change, failing later in override_dh_auto_configure with: dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/i

Bug#646446: gpsdrive: FTBFS: mapnik.cpp:33:15: error: 'mapnik::Image32' has not, been declared

2011-12-01 Thread Allison Randal
ing gpsdrive with mapnik 2.0 +-- + +* Gpsdrive is incompatible with the new APIs of mapnik 2.0.0. This + optional library is now disabled in the package. + + -- Allison Randal Thu, 01 Dec 2011 12:48:22 -0800 + Upgrading from gpsdrive 2.09 (etch) --