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 attachment 52426 [details, diff] 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 attachment 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
