Hi all,
A bit late in the release cycle, but I delayed it to not disrupt the mass rebuild. I'm updating ImageMagick to 6.4.9-9
Which changes the soname (and ABI) of the included libraries. The following packages are affected by this and will need to be rebuild (once the new ImageMagick is in the build repo):
ale-0:0.9.0.1-3.fc11.x86_64 autotrace-0:0.31.1-20.fc11.x86_64 drawtiming-0:0.6.2-4.fc11.x86_64 evolution-brutus-0:1.2.34-2.fc11.x86_64 gdl-0:0.9-0.2.rc2.20090224.fc11.x86_64 imageinfo-0:0.05-7.fc11.x86_64 inkscape-0:0.47-0.5.20090301svn.fc11.x86_64 k3d-0:0.6.7.0-9.fc11.x86_64 kismet-extras-0:0.0.2008.05.R1-3.fc10.x86_64 koffice-karbon-2:1.6.3-19.20090306svn.fc11.x86_64 koffice-libs-2:1.6.3-19.20090306svn.fc11.x86_64 libfprint-0:0.1.0-5.pre1.fc11.x86_64 nip2-0:7.16.4-2.fc11.x86_64 octave-forge-0:20080831-5.fc11.x86_64 oxine-0:0.7.1-3.fc11.x86_64 pfstools-imgmagick-0:1.7.0-3.fc11.x86_64 php-magickwand-0:1.0.8-1.fc11.x86_64 php-pecl-imagick-0:2.2.2-1.fc11.x86_64 psiconv-0:0.9.8-3.fc11.x86_64 pstoedit-0:3.45-6.fc11.x86_64 q-magick-0:7.11-4.fc11.x86_64 ruby-RMagick-0:2.9.1-2.fc11.x86_64 vips-0:7.16.4-2.fc11.x86_64 xastir-0:1.9.5-2.fc11.x86_64 xine-lib-extras-0:1.1.16.2-4.fc11.x86_64
Regards,
Hans
On Mon, 2009-03-09 at 12:03 +0100, Hans de Goede wrote:
A bit late in the release cycle, but I delayed it to not disrupt the mass rebuild. I'm updating ImageMagick to 6.4.9-9
Which changes the soname (and ABI) of the included libraries. The following packages are affected by this and will need to be rebuild (once the new ImageMagick is in the build repo):
Could we be informed when it happens ? Or is it already there ?
Thanks, Regards,
Pierre
"HdG" == Hans de Goede writes:
HdG> Hi all, HdG> A bit late in the release cycle, but I delayed it to not disrupt the HdG> mass rebuild. I'm updating ImageMagick to 6.4.9-9
HdG> Which changes the soname (and ABI) of the included libraries. HdG> The following packages are affected by this and will need to be rebuild HdG> (once the new ImageMagick is in the build repo):
Why are you doing this the *day* of the freeze? Unless you are prepared to rebuild all the deps yourself, this means that beta will probably ship with a boatload of broken deps.
If you haven't done so already, can you please hold off until after the beta freeze is over?
Alex
Alex Lancaster writes:
"HdG" == Hans de Goede writes:
HdG> Hi all, HdG> A bit late in the release cycle, but I delayed it to not disrupt the HdG> mass rebuild. I'm updating ImageMagick to 6.4.9-9
HdG> Which changes the soname (and ABI) of the included libraries. HdG> The following packages are affected by this and will need to be rebuild HdG> (once the new ImageMagick is in the build repo):
Why are you doing this the *day* of the freeze? Unless you are prepared to rebuild all the deps yourself, this means that beta will probably ship with a boatload of broken deps.
If you haven't done so already, can you please hold off until after the beta freeze is over?
Case in point, evolution-brutus failed rebuild due to some kind of API/ABI changes:
checking ifaddrs.h presence... yes checking for ifaddrs.h... yes checking for getifaddrs... yes checking for nanosleep... yes checking for wand/magick-wand.h... no configure: error: development header not installed error: Bad exit status from /var/tmp/rpm-tmp.18zCEt (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.18zCEt (%build) Child returncode was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/evolution-brutus.spec'] Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/util.py", line 324, in do raise mock.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/evolution-brutus.spec'] LEAVE do --> EXCEPTION RAISED
full logs:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1233500 http://koji.fedoraproject.org/koji/getfile?taskID=1233500&name=build.log
So does octave-forge (although it may not be directly related to ImageMagick):
http://koji.fedoraproject.org/koji/taskinfo?taskID=1233493
The point is that other maintainers need time, not just to rebuild, but to track down these build failures and < 24 hours is not long enough.
In general it would be a good idea for those who are breaking ABI/API/soname investigate the possible extent of the breakage by doing some scratch builds of affected packages *before* kicking off the changes, especially when the list of packages is over past the 15-20 number and that maintainer of the package doing the breaking doesn't maintain most of the affected packages. The onus should be on the ABI/API breaker to find out the extent of the problem, possible gotchas and possible fixes/workarounds, not the breakee.
Alex
Alex Lancaster wrote, at 03/10/2009 06:37 AM +9:00:
Alex Lancaster writes:
"HdG" == Hans de Goede writes:
HdG> Hi all, HdG> A bit late in the release cycle, but I delayed it to not disrupt the HdG> mass rebuild. I'm updating ImageMagick to 6.4.9-9
HdG> Which changes the soname (and ABI) of the included libraries. HdG> The following packages are affected by this and will need to be rebuild HdG> (once the new ImageMagick is in the build repo):
Case in point, evolution-brutus failed rebuild due to some kind of API/ABI changes:
checking ifaddrs.h presence... yes checking for ifaddrs.h... yes checking for getifaddrs... yes checking for nanosleep... yes checking for wand/magick-wand.h... no configure: error: development header not installed error: Bad exit status from /var/tmp/rpm-tmp.18zCEt (%build)
This is failing as(from config.log): -------------------------------------------------------------------------- configure:20351: gcc -c -I/usr/include/brutus-keyring-1.0 -DORBIT2=1 -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/orbit-2.0 -I/usr/include/libIDL-2.0 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Werror -Werror-implicit-function-declaration -Wundef -Wbad-function-cast -Wcast-align -Wmissing-declarations -std=gnu89 -D_REENTRANT -I/usr/include/ImageMagick -I/usr/include/evolution-data-server-2.26 conftest.c >&5 In file included from /usr/include/ImageMagick/magick/MagickCore.h:148, from /usr/include/ImageMagick/wand/MagickWand.h:147, from /usr/include/ImageMagick/wand/magick-wand.h:22, from conftest.c:70: /usr/include/ImageMagick/magick/magick-type.h:130:5: error: "_MSC_VER" is not defined configure:20358: $? = 1 --------------------------------------------------------------------------
Possibly a bug on ImageMagick side. Currently I cannot find out where _MSC_VER is defined (perhaps Windows related) and evolution-brutus configure rejects this by "-Werror -Wundef".
"sed -i -e 's|-Wundef||' configure" in evolution-brutus can be a work-around for this issue: http://koji.fedoraproject.org/koji/taskinfo?taskID=1233863
Mamooru
Mamoru Tasaka wrote:
Possibly a bug on ImageMagick side.
s/Possibly/Definitely/ :-)
Currently I cannot find out where _MSC_VER is defined (perhaps Windows related)
_MSC_VER is only defined with M$ Visual C/C++.
"sed -i -e 's|-Wundef||' configure" in evolution-brutus can be a work-around for this issue: http://koji.fedoraproject.org/koji/taskinfo?taskID=1233863
Can you please submit a "real" (non-scratch) build?
Kevin Kofler
Hi:
Kevin Kofler wrote, at 03/10/2009 11:41 AM +9:00:
Mamoru Tasaka wrote:
Possibly a bug on ImageMagick side.
s/Possibly/Definitely/ :-)
Currently I cannot find out where _MSC_VER is defined (perhaps Windows related)
_MSC_VER is only defined with M$ Visual C/C++.
Filed: https://bugzilla.redhat.com/show_bug.cgi?id=489453 (against ImageMagick)
"sed -i -e 's|-Wundef||' configure" in evolution-brutus can be a work-around for this issue: http://koji.fedoraproject.org/koji/taskinfo?taskID=1233863
Can you please submit a "real" (non-scratch) build?
Okay, successfully rebuilt as evolution-brutus-1.2.35-2.fc11
Kevin Kofler
Regards, Mamoru
Alex Lancaster wrote:
"HdG" == Hans de Goede writes:
HdG> Hi all, HdG> A bit late in the release cycle, but I delayed it to not disrupt the HdG> mass rebuild. I'm updating ImageMagick to 6.4.9-9
HdG> Which changes the soname (and ABI) of the included libraries. HdG> The following packages are affected by this and will need to be rebuild HdG> (once the new ImageMagick is in the build repo):
Why are you doing this the *day* of the freeze? Unless you are prepared to rebuild all the deps yourself, this means that beta will probably ship with a boatload of broken deps.
I'm sorry, I was under the (mistaken) impression the freeze was still a few days away. apologies.
If you haven't done so already, can you please hold off until after the beta freeze is over?
I cannot do that (that is beyond my power), rel-eng could untag it, but as I understand some packages have already been rebuild, so I don't know which way is less work (untagging, or fixing the remainder). Either way my apologies for the mess, I got the freeze date wrong, otherwise I wouldn't have done this.
Regards,
Hans
Hans de Goede wrote:
I cannot do that (that is beyond my power), rel-eng could untag it
You can untag at least your own builds, though in this case it'd be counterproductive because of the stuff which has been rebuilt against it already.
I think at this point the best way forward is to just rebuild the remaining affected packages. There don't appear to be any major API changes, xine-lib and koffice rebuilt with no changes.
Kevin Kofler
On Mon, 09 Mar 2009, Hans de Goede wrote:
A bit late in the release cycle, but I delayed it to not disrupt the mass rebuild. I'm updating ImageMagick to 6.4.9-9
Thanks for putting that in one day before freeze :-(
php-magickwand-0:1.0.8-1.fc11.x86_64
Now fixed in -2.
Greetings, Robert