I have pushed libtiff 4.0.1 into rawhide, replacing libtiff 3.9.5. This entails a library soname bump and a few small source-level incompatibilities, as detailed at http://www.remotesensing.org/libtiff/v4.0.0.html
By my count there are about a hundred dependent packages (see list below), so to avoid breaking rawhide until everything can be rebuilt, I have put the old 3.9.x library into a temporary subpackage "libtiff-compat". (We used the same trick a few months ago for libpng and it seemed to work all right.)
I did trial rebuilds of all these packages against libtiff 4.0.1, and found only three that appear to need any source-code changes; though another dozen have pre-existing FTBFS problems which means I can't tell for sure if they would build against the new libtiff.
If any of these packages are yours, please rebuild at the soonest opportunity. If you need advice about fixing either libtiff- or libpng-dependent code, contact me off-list and I'll be glad to try to help.
regards, tom lane
adrian fbida pre-existing FTBFS (libpng related) agoode nip2 pre-existing FTBFS agoode openslide agoode vips alexlan mapnik ankursinha aeskulap athimm vtk pre-existing FTBFS awjb WindowMaker awjb aterm awjb lcms awjb libAfterImage pre-existing FTBFS (libpng related) awjb scribus bpostle enblend bpostle hugin bpostle libpano12 pre-existing FTBFS (libpng related) bpostle libpano13 bpostle vigra bruno ocaml-camlimages bruno sear chitlesh LabPlot chkr gthumb corsepiu OpenSceneGraph pre-existing FTBFS corsepiu k3d deji grads deji tracker devrim gdal pre-existing FTBFS devrim grass duffy cmyktool ellert root fab gipfel fab vifir fcomida luminance-hdr giallu rawstudio hobbes1069 OpenImageIO hubbitus ImageMagick hubbitus fotoxx ixs GraphicsMagick jcapik openjpeg jcollie spandsp jjames xemacs jnovy netpbm jwrdegoede DevIL jwrdegoede MagicPoint jwrdegoede adanaxisgpl karlik tesseract pre-existing FTBFS kevin fontforge kklic emacs kwizart Pixie kwizart aqsis kwizart cinepaint laxathom libgdiplus pre-existing FTBFS (libpng related) limb Io-language limb SDL_image limb argyllcms lkundrak links pre-existing FTBFS (libpng related) lkundrak xteddy madko darktable mclasen gdk-pixbuf2 mclasen gtk2 mdomsch photoprint mkasik evince mrceresa dcmtk pre-existing FTBFS mtasaka xplanet nphilipp gimp nphilipp sane-backends nphilipp ufraw nphilipp xsane orion paraview orion pslib oron libhocr pghmcfc imlib rakesh djvulibre rakesh freeimage needs work for new libtiff rakesh linphone rakesh opencv rathann dx rdieter calligra rhughes gnome-color-manager rhughes lcms2 roma xpaint s4504kr blender s4504kr gnustep-gui sharkcz podofo sharkcz wxGTK spot R spot evas spot tkimg needs work for new libtiff spot xloadimage needs work for new libtiff steve perl-Imager terjeros gle terjeros mtpaint than kdegraphics-strigi-analyzer than kdelibs3 pre-existing FTBFS than okular than qt tnorth GREYCstoration tnorth rawtherapee tomh libgxps tsmetana imlib2 tsmetana pfstools tuxbrewr digikam twaugh cups twaugh ghostscript volter libgaiagraphics volter libgeotiff wolfy qfaxreader
On 05/06/2012 06:10 PM, Tom Lane wrote:
I have pushed libtiff 4.0.1 into rawhide, replacing libtiff 3.9.5. This entails a library soname bump and a few small source-level incompatibilities, as detailed at http://www.remotesensing.org/libtiff/v4.0.0.html
By my count there are about a hundred dependent packages (see list below), so to avoid breaking rawhide until everything can be rebuilt, I have put the old 3.9.x library into a temporary subpackage "libtiff-compat". (We used the same trick a few months ago for libpng and it seemed to work all right.)
I did trial rebuilds of all these packages against libtiff 4.0.1, and found only three that appear to need any source-code changes; though another dozen have pre-existing FTBFS problems which means I can't tell for sure if they would build against the new libtiff.
If any of these packages are yours, please rebuild at the soonest opportunity. If you need advice about fixing either libtiff- or libpng-dependent code, contact me off-list and I'll be glad to try to help.
regards, tom lane
corsepiu OpenSceneGraph pre-existing FTBFS
Could you point me to this "pre-existing FTBFS"?
Digging BZ, koji and googling did not turn up any formal FTBFS, however when trying to rebuild OSG, it indeed fail to build due to an issue which seems unrelated to libtiff.
corsepiu k3d
Should be rebuilt now.
Ralf
On Mon, 07 May 2012 08:07:22 +0200, RC (Ralf) wrote:
On 05/06/2012 06:10 PM, Tom Lane wrote:
I have pushed libtiff 4.0.1 into rawhide, replacing libtiff 3.9.5. This entails a library soname bump and a few small source-level incompatibilities, as detailed at http://www.remotesensing.org/libtiff/v4.0.0.html
By my count there are about a hundred dependent packages (see list below), so to avoid breaking rawhide until everything can be rebuilt, I have put the old 3.9.x library into a temporary subpackage "libtiff-compat". (We used the same trick a few months ago for libpng and it seemed to work all right.)
I did trial rebuilds of all these packages against libtiff 4.0.1, and found only three that appear to need any source-code changes; though another dozen have pre-existing FTBFS problems which means I can't tell for sure if they would build against the new libtiff.
If any of these packages are yours, please rebuild at the soonest opportunity. If you need advice about fixing either libtiff- or libpng-dependent code, contact me off-list and I'll be glad to try to help.
regards, tom lane
corsepiu OpenSceneGraph pre-existing FTBFS
Could you point me to this "pre-existing FTBFS"?
Digging BZ, koji and googling did not turn up any formal FTBFS, however when trying to rebuild OSG, it indeed fail to build due to an issue which seems unrelated to libtiff.
Which, IMO, is exactly what Tom wants to point out. The package would FTBFS already prior to the libtiff upgrade. Not all FTBFS issues are filed in bugzilla. Only those when the FTBFS checker script is run.
On 05/07/2012 10:08 AM, Michael Schwendt wrote:
On Mon, 07 May 2012 08:07:22 +0200, RC (Ralf) wrote:
On 05/06/2012 06:10 PM, Tom Lane wrote:
I have pushed libtiff 4.0.1 into rawhide, replacing libtiff 3.9.5. This entails a library soname bump and a few small source-level incompatibilities, as detailed at http://www.remotesensing.org/libtiff/v4.0.0.html
By my count there are about a hundred dependent packages (see list below), so to avoid breaking rawhide until everything can be rebuilt, I have put the old 3.9.x library into a temporary subpackage "libtiff-compat". (We used the same trick a few months ago for libpng and it seemed to work all right.)
I did trial rebuilds of all these packages against libtiff 4.0.1, and found only three that appear to need any source-code changes; though another dozen have pre-existing FTBFS problems which means I can't tell for sure if they would build against the new libtiff.
If any of these packages are yours, please rebuild at the soonest opportunity. If you need advice about fixing either libtiff- or libpng-dependent code, contact me off-list and I'll be glad to try to help.
regards, tom lane
corsepiu OpenSceneGraph pre-existing FTBFS
Could you point me to this "pre-existing FTBFS"?
Digging BZ, koji and googling did not turn up any formal FTBFS, however when trying to rebuild OSG, it indeed fail to build due to an issue which seems unrelated to libtiff.
Which, IMO, is exactly what Tom wants to point out.
Thanks, then I likely misunderstood him.
The package would FTBFS already prior to the libtiff upgrade. Not all FTBFS issues are filed in bugzilla. Only those when the FTBFS checker script is run.
Makes me wonder what actually has broken building OSG.
Must be a recent change in of OSGs numerous build-deps, because it had been rebuilt several times without major changes for ca. a year[1]
Ralf
[1] http://koji.fedoraproject.org/koji/packageinfo?packageID=1220
Ralf Corsepius rc040203@freenet.de writes:
On 05/07/2012 10:08 AM, Michael Schwendt wrote:
On Mon, 07 May 2012 08:07:22 +0200, RC (Ralf) wrote:
Digging BZ, koji and googling did not turn up any formal FTBFS, however when trying to rebuild OSG, it indeed fail to build due to an issue which seems unrelated to libtiff.
Which, IMO, is exactly what Tom wants to point out.
Thanks, then I likely misunderstood him.
Yes, I just said that I observed a failure that seemed unrelated to libtiff.
Makes me wonder what actually has broken building OSG. Must be a recent change in of OSGs numerous build-deps, because it had been rebuilt several times without major changes for ca. a year[1]
What I'm seeing looks like something in pthreads changed:
Linking CXX executable ../../bin/osgversion cd /builddir/build/BUILD/OpenSceneGraph-3.0.1/BUILD/applications/osgversion && /usr/bin/cmake -E cmake_link_script CMakeFiles/application_osgversion.dir/link.txt --verbose=1 /usr/lib64/ccache/c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused -fpermissive -Wl,-z,relro CMakeFiles/application_osgversion.dir/osgversion.o -o ../../bin/osgversion -rdynamic ../../lib/libOpenThreads.so.2.6.0 ../../lib/libosg.so.3.0.1 ../../lib/libosgDB.so.3.0.1 ../../lib/libosgUtil.so.3.0.1 ../../lib/libosg.so.3.0.1 ../../lib/libOpenThreads.so.2.6.0 -lm -lrt -ldl -lz -lGL -Wl,-rpath,/builddir/build/BUILD/OpenSceneGraph-3.0.1/BUILD/lib: /usr/bin/ld: ../../lib/libOpenThreads.so.2.6.0: undefined reference to symbol 'pthread_cancel@@GLIBC_2.2.5' /usr/bin/ld: note: 'pthread_cancel@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status
If you are expecting this app to use pthreads then -lpthread would seem to be indicated.
regards, tom lane
On Sun, 2012-05-06 at 12:10 -0400, Tom Lane wrote:
ankursinha aeskulap
Rebuilt for rawhide and f17.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/06/2012 06:10 PM, Tom Lane wrote:
fab gipfel fab vifir
Done
Kind regard,
Fabian
06.05.2012 20:10, Tom Lane wrote:
I have pushed libtiff 4.0.1 into rawhide, replacing libtiff 3.9.5. This entails a library soname bump and a few small source-level incompatibilities, as detailed at http://www.remotesensing.org/libtiff/v4.0.0.html
By my count there are about a hundred dependent packages (see list below), so to avoid breaking rawhide until everything can be rebuilt, I have put the old 3.9.x library into a temporary subpackage "libtiff-compat". (We used the same trick a few months ago for libpng and it seemed to work all right.)
I did trial rebuilds of all these packages against libtiff 4.0.1, and found only three that appear to need any source-code changes; though another dozen have pre-existing FTBFS problems which means I can't tell for sure if they would build against the new libtiff.
If any of these packages are yours, please rebuild at the soonest opportunity. If you need advice about fixing either libtiff- or libpng-dependent code, contact me off-list and I'll be glad to try to help.
regards, tom lane
...
hubbitus ImageMagick hubbitus fotoxx
Done. http://koji.fedoraproject.org/koji/taskinfo?taskID=4070773 http://koji.fedoraproject.org/koji/taskinfo?taskID=4070843