This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 434008 - evolution-brutus failed massrebuild attempt for GCC 4.3
evolution-brutus failed massrebuild attempt for GCC 4.3
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: evolution-brutus (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Brian Pepple
Fedora Extras Quality Assurance
:
: 442349 (view as bug list)
Depends On:
Blocks: gcc43rebuildfail
  Show dependency treegraph
 
Reported: 2008-02-22 07:55 EST by Jesse Keating
Modified: 2013-01-09 21:48 EST (History)
6 users (show)

See Also:
Fixed In Version: 1.2.11-2.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-14 23:47:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch to spec file to use new upstream evolution-brutus which is supposed to work with new eds (1.81 KB, patch)
2008-04-13 08:35 EDT, Alex Lancaster
no flags Details | Diff
updated patch that fixes build (2.54 KB, patch)
2008-04-13 09:49 EDT, Alex Lancaster
no flags Details | Diff
include all files (3.36 KB, patch)
2008-04-13 10:00 EDT, Alex Lancaster
no flags Details | Diff
spec file patch to add -fno-strict-aliasing to fix build (1.43 KB, patch)
2008-04-14 23:18 EDT, Alex Lancaster
no flags Details | Diff

  None (edit)
Description Jesse Keating 2008-02-22 07:55:06 EST
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.
Comment 1 Jon Stanley 2008-02-23 14:23:33 EST
checking Evolution Data Server version... 2.22
configure: error: Unsupported version of Evolution Data Server. Please report
this to bugs@omesc.com
error: Bad exit status from /var/tmp/rpm-tmp.73479 (%build)
Comment 2 Jules Colding 2008-02-25 03:01:41 EST
A sync with upstream svn trunk followed by "./autogen.sh" should fix this.
Comment 3 Alex Lancaster 2008-03-04 06:03:41 EST
Please fix this ASAP, this is causing broken deps in rawhide and we have a
freeze pending.
Comment 4 Alex Lancaster 2008-03-04 06:07:29 EST
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.
Comment 5 Jules Colding 2008-04-07 09:04:38 EDT
svn trunk builds fine on rawhide:

http://www.42tools.com/sites/default/files/downloads/dist/evolution-brutus/Rawhide/
Comment 6 Alex Lancaster 2008-04-13 08:35:56 EDT
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"
Comment 7 Jules Colding 2008-04-13 08:50:20 EDT
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".
Comment 8 Alex Lancaster 2008-04-13 09:05:13 EDT
(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
Comment 9 Alex Lancaster 2008-04-13 09:11:11 EDT
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
Comment 10 Jules Colding 2008-04-13 09:28:15 EDT
(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.
 
Comment 11 Jules Colding 2008-04-13 09:32:33 EDT
(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?
 
Comment 12 Alex Lancaster 2008-04-13 09:49:26 EDT
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
Comment 13 Alex Lancaster 2008-04-13 09:52:55 EDT
(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.

Comment 14 Alex Lancaster 2008-04-13 09:55:42 EDT
(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.
Comment 15 Alex Lancaster 2008-04-13 10:00:57 EDT
Created attachment 302269 [details]
include all files
Comment 16 Jules Colding 2008-04-13 10:03:53 EDT
(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.

Comment 17 Alex Lancaster 2008-04-13 10:27:05 EDT
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.
Comment 18 Alex Lancaster 2008-04-13 10:36:44 EDT
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"
Comment 19 Alex Lancaster 2008-04-13 10:38:48 EDT
Apparently this is the issue: http://bugzilla.gnome.org/show_bug.cgi?id=316221
Comment 20 Jules Colding 2008-04-13 13:17:04 EDT
Hmm... I'll look into the issue tomorrow. I'm putting the kids to bed now so it
has to wait.

Sleep well.
Comment 21 Alex Lancaster 2008-04-14 20:38:19 EDT
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"?
Comment 22 Alex Lancaster 2008-04-14 20:48:49 EDT
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
Comment 23 Kevin Kofler 2008-04-14 22:23:54 EDT
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.
Comment 24 Alex Lancaster 2008-04-14 22:26:16 EDT
(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.
Comment 25 Alex Lancaster 2008-04-14 23:10:08 EDT
*** Bug 442349 has been marked as a duplicate of this bug. ***
Comment 26 Alex Lancaster 2008-04-14 23:18:30 EDT
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
Comment 27 Kevin Fenzi 2008-04-14 23:44:21 EDT
I went ahead and checked this patch in and did a build... 
http://koji.fedoraproject.org/koji/taskinfo?taskID=566180

Comment 28 Alex Lancaster 2008-04-14 23:47:42 EDT
e-mail to rel-eng to tag as f9-final sent.  Closing bug (finally!)
Comment 29 Jules Colding 2008-04-15 04:28:26 EDT
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.
Comment 30 Alex Lancaster 2008-04-15 05:00:57 EDT
(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.

Comment 31 Alex Lancaster 2008-04-15 05:01:50 EDT
Actually in this case, I didn't have to remove '-Werror', just added
-fno-strict-aliasing to CFLAGS.
Comment 32 Jules Colding 2008-04-15 05:34:46 EDT
Excellent. I'll have trunk building without GStaticMutex soonish.
Comment 33 Jules Colding 2008-04-15 10:03:49 EDT
Soonish is now. svn trunk is now free of GStaticMutex. Not tested, but it does
build.

Note You need to log in before you can comment on or make changes to this bug.