Adding debian-release to get their take. On Sun, Jul 15, 2012 at 11:51:20PM +0200, Jakub Wilk wrote: > * Jakub Wilk <jw...@debian.org>, 2012-07-15, 15:07: > >>this is most likely caused by building _hashlib as an extension, > >>not a builtin anymore, to address #680930. rebuilding vim should > >>fix it. > >Indeed, rebuild fixed the problem for me. > > However, in comparison to version in testing (2.7.3~rc2-2.1), > libpython2.7 not only removed two symbols (init_hashlib, init_ssl) > but also added one (init_heapq). This new symbol doesn't have > correct dependency declared in the symbols file. As a consequence, > if you rebuild vim in unstable, and then run it against libpython2.7 > from testing, you get this: > > $ LD_BIND_NOW=1 vim > vim: symbol lookup error: vim: undefined symbol: init_heapq
So a simple binNMU won't help because it wouldn't have a tight enough dependency and therefore could transition before python2.7, leaving a broken Vim in Wheezy. Shall I make a sourceful upload of Vim with a libpython2.7 (>= 2.7.3-2) Depends and request it be unblocked or is there another way we should solve this? > >I'll check if other source packages are affected later. > > I checked all i386 binaries depending on libpython2.7: > > - There are no other users of init_hashlib. > > - ntop uses init_ssl. However, the intention was to use this one: > > $ readelf -s /usr/lib/ntop/libntopreport.so | grep -w init_ssl > 446: 00046480 1804 FUNC GLOBAL DEFAULT 12 init_ssl > > So if libpython2.7 dropping init_ssl makes any difference for ntop, > then it should rather fix things than break them. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <james...@debian.org>
signature.asc
Description: Digital signature