This is an automatically filed bug for a failed rebuild attempt for GCC 4.3. http://fedoraproject.org/wiki/JesseKeating/gcc43MassRebuildProposal Please verify why this build failed and fix it. http://koji.fedoraproject.org/koji/taskinfo?taskID=436882 Exit code was 1, check the build.log for the failed buildArch task.
checking Evolution Data Server version... 2.22 configure: error: Unsupported version of Evolution Data Server. Please report this to bugs error: Bad exit status from /var/tmp/rpm-tmp.73479 (%build)
A sync with upstream svn trunk followed by "./autogen.sh" should fix this.
Please fix this ASAP, this is causing broken deps in rawhide and we have a freeze pending.
Also looking at PackageDB: https://admin.fedoraproject.org/pkgdb/packages/name/evolution-brutus ACLs for package are closed, so I couldn't fix this even if I wanted to. Please consider checking "cvsextras" can commit option for all branches to allow others to fix your packages.
svn trunk builds fine on rawhide: http://www.42tools.com/sites/default/files/downloads/dist/evolution-brutus/Rawhide/
Created attachment 302262 [details] patch to spec file to use new upstream evolution-brutus which is supposed to work with new eds Can the official maintainer look at this and/or open ACLs so that others can fix the build? It still won't build with this attached patch to the spec file, here's my local koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=564143 errors out with this: In file included from /usr/include/evolution-data-server-2.22/libecal/e-cal-component.h:28, from /usr/include/evolution-data-server-2.22/libecal/e-cal-recur.h:27, from /usr/include/evolution-data-server-2.22/libecal/e-cal.h:29, from ../server/brutus_util.h:27, from brutus_debug.c:37: /usr/include/evolution-data-server-2.22/libical/ical.h:30:2: error: #warning "Please ensure that the memory returned by the functions mentioned at http://bugzilla.gnome.org/show_bug.cgi?id=516408#c1 are free'ed" In file included from /usr/include/evolution-data-server-2.22/libecal/e-cal-util.h:25, from /usr/include/evolution-data-server-2.22/libecal/e-cal.h:30, from ../server/brutus_util.h:27, from brutus_debug.c:37: /usr/include/evolution-data-server-2.22/libical/ical.h:30:2: error: #warning "Please ensure that the memory returned by the functions mentioned at http://bugzilla.gnome.org/show_bug.cgi?id=516408#c1 are free'ed"
This error has been fixed in svn trunk. Another thing - svn trunk will generate a working spec file if you do "./autogen.sh" and it will produce RPMs if you follow that with "make distfiles".
(In reply to comment #7) > This error has been fixed in svn trunk. Another thing - svn trunk will generate > a working spec file if you do "./autogen.sh" and it will produce RPMs if you > follow that with "make distfiles". Doing it that isn't possible, because every goes through the Fedora build system and we can't accept automatically generated spec files. I mean it's fine if you want to generate some private RPMS for yourself, but the build system (koji) needs to be given the .spec file and it automatically pulls in the BuildRequires etc. ON the issue of SVN, it appears that the following files have identical names, but aren't the same files: http://www.42tools.com/sites/default/files/downloads/dist/evolution-brutus/Rawhide/SOURCES/evolution-brutus-1.2.11.tar.gz http://www.42tools.com/sites/default/files/downloads/dist/evolution-brutus/Fedora%208/SOURCES/evolution-brutus-1.2.11.tar.gz I assume the one the rawhide directory is an SVN snapshot? If so, could you rename that file to have a different release number of include the snapshot date or revision number? It's bad practice to have two files with the same name as you can see by my initial confusion in pulling the one from Fedora 8 because I assumed it was the same as the file in the Rawhide directory? See here for more details: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-e104844825856d7c45f2f0241586985c0495966b
Also periodically we attempt to verify the sources in our build system match the versions upstream by using the full URL to the source and comparing the MD5sums. If the two files are different but have the same version it will confuse the automatic checking. e.g. the svn snapshot (if it is a pre-1.2.12 snapshot, for example) could be: evolution-brutus-1.2.12rc1
(In reply to comment #8) > (In reply to comment #7) > > This error has been fixed in svn trunk. Another thing - svn trunk will generate > > a working spec file if you do "./autogen.sh" and it will produce RPMs if you > > follow that with "make distfiles". > > Doing it that isn't possible, because every goes through the Fedora build system > and we can't accept automatically generated spec files. Sure, I know that. I was merely saying that it would be easy to run autogen.sh on the platform for which the koji is targeted (f8, rawhide?) and then replace the existing spec with the new one. Less work for the maintainer I hoped :-) > ON the issue of SVN, it appears that the following files have identical names, > but aren't the same files: > > http://www.42tools.com/sites/default/files/downloads/dist/evolution-brutus/Rawhide/SOURCES/evolution-brutus-1.2.11.tar.gz > http://www.42tools.com/sites/default/files/downloads/dist/evolution-brutus/Fedora%208/SOURCES/evolution-brutus-1.2.11.tar.gz > > I assume the one the rawhide directory is an SVN snapshot? The way I do private release is to get an svn snapshot on the platform in question (it could be 7, f8, rawhide, suse, gentoo or whatever is supported) and then execute: ./autogen.sh && make release The "release" target will do "make distfiles" internally and then scp the resulting release files (in this case the RPMs) and accompanying files (in this case one spec file and a "make dist" tar-ball) to the download directory. The download directory is named after the distribution for which the release files was generated. You have looked into the f8 and rawhide download directories. > If so, could you rename that file to have a different release number of include the snapshot date > or revision number? They are already named differently by their full download path. It's bad practice to have two files with the same name as > you can see by my initial confusion in pulling the one from Fedora 8 because I > assumed it was the same as the file in the Rawhide directory? See here for more > details: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-e104844825856d7c45f2f0241586985c0495966b Yes, nomally I would agree wholeheartedly but, say, "evolution-brutus.spec" is still the spec file for evolution-brutus regardless of the intended fedora target and should not be named differently. The different release files are sufficiently distinguished by their full download path.
(In reply to comment #9) > Also periodically we attempt to verify the sources in our build system match the > versions upstream by using the full URL to the source and comparing the MD5sums. > If the two files are different but have the same version it will confuse the > automatic checking. e.g. the svn snapshot (if it is a pre-1.2.12 snapshot, for > example) could be: > > evolution-brutus-1.2.12rc1 Yes, unfortunately. I know that my way of doing private releases disrupts this check. I can't come up with an easy way to fix it short of doing a special source release that can be used by koji to check the md5 sum. Thoughts?
Created attachment 302268 [details] updated patch that fixes build This patch fixes the build (finally), see this scratch koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=564191
(In reply to comment #11) > Yes, unfortunately. I know that my way of doing private releases disrupts this > check. I can't come up with an easy way to fix it short of doing a special > source release that can be used by koji to check the md5 sum. > > Thoughts? When you generate the tarball from SVN, can't you get your script to include or append the SVN revision number to the tarball name and directory? That would solve all the problems I think.
(In reply to comment #10) > Sure, I know that. I was merely saying that it would be easy to run autogen.sh > on the platform for which the koji is targeted (f8, rawhide?) and then replace > the existing spec with the new one. Less work for the maintainer I hoped :-) Sure it definitely does does help, as you can do a diff between the spec files (which is what I did visually) to port the new changes over. But you can't just replace it because there are various comments and other edits (changelog entries) on the Fedora side that don't get preserved if just do a copy. That can't really be helped though, I guess.
Created attachment 302269 [details] include all files
(In reply to comment #13) > (In reply to comment #11) > > > Yes, unfortunately. I know that my way of doing private releases disrupts this > > check. I can't come up with an easy way to fix it short of doing a special > > source release that can be used by koji to check the md5 sum. > > > > Thoughts? > > When you generate the tarball from SVN, can't you get your script to include or > append the SVN revision number to the tarball name and directory? That would > solve all the problems I think. Yes, that should pose no problems.
Blergh, it failed on ppc: http://koji.fedoraproject.org/koji/taskinfo?taskID=564206 any ideas why? It seemed to work on my earlier x86_64 and on the i386 build.
From #fedora-devel IRC by Dan Williams: "it's totally a glib2 problem and not some thing evo-brutus can fix unless they remove usage of GStaticMutex"
Apparently this is the issue: http://bugzilla.gnome.org/show_bug.cgi?id=316221
Hmm... I'll look into the issue tomorrow. I'm putting the kids to bed now so it has to wait. Sleep well.
Well, Dan Williams rolled back the patch to glib2, which was causing the ppc build failures, but this presented a new problem, now it fails because of a compiler warning: http://koji.fedoraproject.org/koji/getfile?taskID=566060&name=build.log gcc -DHAVE_CONFIG_H -I. -I.. -I/builddir/build/BUILD/evolution-brutus-1.2.11 -DG_LOG_DOMAIN=\"brutus-logd\" -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/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 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c cc1: warnings being treated as errors In file included from main.c:45: brutus-log_impl.c: In function 'impl_BRUTUS_BrutusLog_commit': brutus-log_impl.c:177: error: dereferencing type-punned pointer will break strict-aliasing rules brutus-log_impl.c:184: error: dereferencing type-punned pointer will break strict-aliasing rules Dan knew this would be a problem but decided it would be the lesser of two evils because compiler warnings can be ignored, unfortunately I can't seem to set evolution-brutus to *not* use "-Werror". I thought that enabling the configure option: --enable-compile-warnings=no would do it, but no (the above build did have that configure option). Since the buildsystem doesn't set "-Werror" by default, the package must be doing it itself, how can I tell it not to use "-Werror"?
OK, I looked more carefully at the configure script. It looks like I can override BRUTUS_CFLAGS, I'm testing out the following hack to (temporarily) remove the "-Werror" option: BRUTUS_CFLAGS="$(grep -e '^BRUTUS_CFLAGS=' configure|cut -d'"' -f2|sed -e 's/-Werror //')" %configure
IMHO the right fix is to add -fno-strict-aliasing, not skip the -Werror (unless there are other warnings, in which case both should be done), ignoring those aliasing violations might come back to bite you when you least expect it.
(In reply to comment #23) > IMHO the right fix is to add -fno-strict-aliasing, not skip the -Werror (unless > there are other warnings, in which case both should be done), ignoring those > aliasing violations might come back to bite you when you least expect it. This is strictly temporary to fix the broken deps.
*** Bug 442349 has been marked as a duplicate of this bug. ***
Created attachment 302407 [details] spec file patch to add -fno-strict-aliasing to fix build Fixed to add -fno-strict-aliasing as suggested by Kevin. Patch applies and build tested in koji using uploaded SRPM: http://koji.fedoraproject.org/koji/taskinfo?taskID=566157
I went ahead and checked this patch in and did a build... http://koji.fedoraproject.org/koji/taskinfo?taskID=566180
e-mail to rel-eng to tag as f9-final sent. Closing bug (finally!)
It seems to me that the only way to fix this permanently is to not use GStaticMutex? That seems rather drastic to me, but reading up on #316221 made me rather fearful of GStaticMutex. Another thing is that I won't remove -Werror. I need to see and consider every single warning. Considering this I'll try to remove usage of GStaticMutex.
(In reply to comment #29) > It seems to me that the only way to fix this permanently is to not use > GStaticMutex? That seems rather drastic to me, but reading up on #316221 made me > rather fearful of GStaticMutex. Another thing is that I won't remove -Werror. I > need to see and consider every single warning. I'm not asking you to remove '-Werror' or even not make it the default, but to provide a way to override it via configure options (keep the default to have it on by all means). > Considering this I'll try to remove usage of GStaticMutex. It currently builds and should be tagged for f9-final soon, but this should definitely be fixed in the long run.
Actually in this case, I didn't have to remove '-Werror', just added -fno-strict-aliasing to CFLAGS.
Excellent. I'll have trunk building without GStaticMutex soonish.
Soonish is now. svn trunk is now free of GStaticMutex. Not tested, but it does build.