Bugzilla Bug 79704

http://gnunet.org/libextractor/ 

Seems like it's time to have a "xpf issue" list.

net-p2p, please bump.

net-p2p: We may need to mask this (and gnunet) if it isn't patched soon.

No reaction from net-p2p.

Please mask this package.

package.masked media-libs/libextractor by request of the security team.

Does gnunet need to be masked also?

FYI tried bumping to 0.4.1 with the following changes:

HOMEPAGE="http://gnunet.org/libextractor/"
SRC_URI="http://gnunet.org/libextractor/download/${P}.tar.bz2"

But it does not compile.

Here is some extra info for whoever wants to solve this.

It fails because it tries to link against a static gobject-2.0, which we don't 
have on our systems.

libextractor-0.4.1/src/plugins/ole2/Makefile.am specifies:

# Ok, linking this one is complicated, see Mantis #787.
libextractor_ole2_la_LDFLAGS = \
  -Wl,-Bstatic -Wl,-lgobject-2.0 -Wl,-lglib-2.0 -Wl,-Bdynamic \
  -Wl,-Bsymbolic -avoid-version -module

The issue the author refers to can be found here:
http://gnunet.org/mantis/view.php?id=787

As a test I changed the makefile to build without -Bstatic and it succeeded.

gnunet requires libextractor (and is the only package that does) so it's broken
for the time being, I would say mask it too.

Temporary solution found --> enhancement status

libextractor 0.4.2 is out.

I'm sorry, some things came up and I was out-of-service. I appologize, I should
have coordinated better.
Anyways, 0.4.2 is now in portage. Test away :)

x86, sparc: please test and mark libextractor-0.4.2 stable. I suppose you can
test it using gnunet...

for some reason, libextractor tries to build with "-Wl,-Bstatic
-Wl,-lgobject-2.0 -Wl,-lglib-2.0" .. but on x86 at least we dont have a static
libgobject.. so it fails. 

alright its the same problem as comment 7... but its not fixed for x86... Can't
mark stable.. should probably go back to ebuild status... 

squinky86: could you please look into that ?

Created an attachment (id=52426) [details]
Workaround for ole2 linking problem

Disabling glib support disbables the ole2 plugin which avoids the linking
problem.

tested on amd64

The Changelog also mentions:

Sun Feb 20 16:36:17 EST 2005
	Fixed similar problem in REAL extractor.  Added support
	for new Helix/Real format to REAL extractor.

Sun Feb 20 12:48:15 EST 2005
	Fixed (rare) integer overflow bug in PNG extractor.

Sorry for the confusion, back to ebuild status. Squinky please provide a fixed
ebuild.

Package remains masked until maintainer comes back to fix it.

removed x86.. get us back if this is ever fixed.... 

Bumped libextractor to 0.5.0. I added patch which fixes above problems.

x86, sparc: please test and mark libextractor-0.5.0 stable before we unmask it.

0.5.0 fails on x86 with FEATURES=test :
make[4]: Entering directory
`/var/tmp/portage/libextractor-0.5.0/work/libextractor-0.5.0/src/test'Loading
'libextractor_ole2' plugin failed: libextractor_ole2.so: cannot open shared
object file: No such file or directory
Loading 'libextractor_ogg' plugin failed: libextractor_ogg.so: cannot open
shared object file: No such file or directory
Loading 'libextractor_qt' plugin failed: libextractor_qt.so: cannot open shared
object file: No such file or directory
Loading 'libextractor_html' plugin failed: libextractor_html.so: cannot open
shared object file: No such file or directory
Loading 'libextractor_man' plugin failed: libextractor_man.so: cannot open
shared object file: No such file or directory
[....]
Loading 'libextractor_oo' plugin failed: libextractor_oo.so: cannot open shared
object file: No such file or directory
Loading 'libextractor_asf' plugin failed: libextractor_asf.so: cannot open
shared object file: No such file or directory
Failed to load default plugins!
FAIL: multiload
=========================================
3 of 4 tests failed


and without the tests if fails in src_install with the following error.. for
some reason it puts the name of the install script instead of a lib path..

creating build/lib.linux-i686-2.3
i686-pc-linux-gnu-gcc -pthread -shared -fno-strict-aliasing -march=pentium4 -O2
-pipe build/temp.linux-i686-2.3/libextractor_python.o
-Llibextractor_python_setup.py -lextractor -o build/lib.linux-i686-2.3/extractor.so
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lextractor
collect2: ld returned 1 exit status
error: command 'i686-pc-linux-gnu-gcc' failed with exit status 1
make[4]: *** [install-exec-local] Error 1
make[4]: Leaving directory
`/var/tmp/portage/libextractor-0.5.0/work/libextractor-0.5.0/src/main'

So it should stay un p.mask at least until this is fixed.. 

Created an attachment (id=60172) [details]
libextractor-0.5.0 emerge log

Install phase failed.
It tried to do a lot of work for a simple install, in my opinion.

Just commited new patch which fixes linking problems.

the tests are still broken, but it seems to install ok...

Install OK for me, too.

Do we really need to fix problems with test? i don't know why it crashes.

just add an empty src_test() {}  and I'll x86 it tonight

I disabled the tests and marked it stable on x86.. 

gustavoz said sparc doesn't need it stable, as it's not needed by any stable
package anyway.

so we just need to unmask libextractor and gnunet, and maybe remove the affected
versions of libextractor. sekretarz: can you do it ?

Yup, fine with sparc since only gnunet depends on it and there's no single
version stable for us.

gnunet and libextractor have been unmasked. libextractor is ready for GLSA.

GLSA 200506-06