11:10 a.m.
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
1:07 a.m.
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
3:08 a.m.
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.
--
Fedora release 17 (Beefy Miracle) - Linux 3.3.4-4.fc17.x86_64
loadavg: 0.00 0.07 0.12
3:56 a.m.
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
8:51 a.m.
Ralf Corsepius <rc040203(a)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@(a)GLIBC_2.2.5'
/usr/bin/ld: note: 'pthread_cancel@(a)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
2:17 a.m.
On Sun, 2012-05-06 at 12:10 -0400, Tom Lane wrote:
ankursinha aeskulap
Rebuilt for rawhide and f17.
--
Thanks :-),
Regards,
Ankur: "FranciscoD"
http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/
4:03 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/06/2012 06:10 PM, Tom Lane wrote:
fab gipfel fab vifir
Done
Kind regard,
Fabian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+sLTEACgkQ4jzS3TakOX826ACeMxzJVg/jeuQ9VlqHTmbxjS4E
W5QAoIqLhoeWR824gn/yqk5R6/Ndb83Q
=g77V
-----END PGP SIGNATURE-----
11:15 a.m.
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
4382
days inactive
4387
days old
8 comments
7 participants
participants (7)
-
Ankur Sinha -
Fabian Affolter -
Michael Schwendt -
Pavel Alexeev -
Ralf Corsepius -
Tom Callaway -
Tom Lane