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.