[Evolution-hackers] Building Evolution Data Server under GNOME 3.4: GWeather requirements
Dear Evolution folks, using Debian Sid/unstable with GNOME 3.4 to build, I get the following warning running `./configure` without any options. $ git checkout origin/gnome-3-6 $ make clean $ ./autogen.sh […] checking wspiapi.h usability... no checking wspiapi.h presence... no checking for wspiapi.h... no checking if we should build the weather calendar backend... yes checking for LIBGWEATHER... no configure: error: The weather calendar backend requires GWeather = 3.5.0. Alternatively, you may specify --disable-weather as a configure option to avoid building the backend. $ ./configure --disable-weather […] evolution-data-server has been configured as follows: Weather calendar: no Mail Directory: /var/mail, writable by group mail LDAP support: no NNTP support: yes Kerberos 5: no SMIME support: yes IPv6 support: yes Dot Locking:yes File Locking: fcntl Large files:yes Gtk Doc:no Introspection: auto Vala bindings: no GNOME Online Accounts yes Code coverage (gcov): no Matthew stated that it is a goal to ensure that Evolution Data Server and Evolution build under GNOME 3.4. GWeather does not seem an important component, but it would be nice anyway, if that would build under GNOME 3.4 too so packages scripts do not have to be changed and functionality is on par. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Building Evolution Data Server under GNOME 3.4: GWeather requirements
On Fri, 2013-01-04 at 12:32 +0100, Paul Menzel wrote: Matthew stated that it is a goal to ensure that Evolution Data Server and Evolution build under GNOME 3.4. GWeather does not seem an important component, but it would be nice anyway, if that would build under GNOME 3.4 too so packages scripts do not have to be changed and functionality is on par. Yes, I resisted requiring the new and at the time unstable GWeather API, insisting we support both the old and new GWeather APIs for at least one release cycle. But the requirement got bumped anyway. I let it slide since GWeather is an optional dependency. On GNOME 3.4 you'll have to pass --disable-weather to configure. More details here: https://bugzilla.gnome.org/show_bug.cgi?id=672805 Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Building Evolution
sø., 06.03.2011 kl. 10.05 +0530, skrev Manu Gupta: I am sorry for extending this thread, I am attaching the jhbuildrc which I made and I get this error checking for SCANNER... yes checking for FFI... no checking for ffi.h... configure: error: ffi.h not found In the configure phase of gobject-introspection. What should I do? Install libffi-devel. Cheers Kjartan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Building Evolution
Am Sonntag, den 06.03.2011, 10:05 +0530 schrieb Manu Gupta: I am sorry for extending this thread, I am attaching the jhbuildrc which I made and I get this error checking for SCANNER... yes checking for FFI... no checking for ffi.h... configure: error: ffi.h not found In the configure phase of gobject-introspection. What should I do? Please see if my .jhbuildrc is correct / am I missing something. On Sun, 2011-03-06 at 07:57 +0530, Manu Gupta wrote: Hi All I need to get bleeding edge evolution from the git repo. I am trying to use jhbuild but the docs at the website are quite outdated http://projects.gnome.org/evolution/build.shtml Can I know the proper moduleset for building evolution ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers The following might be of help: http://mail.gnome.org/archives/evolution-list/2010-November/msg4.html http://mail.gnome.org/archives/evolution-list/2010-November/msg5.html -- thomas ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Building Evolution
Thanks a lot I am able to resolve dependencies but I am now stuck with one more problem while installing nss I get this error drbg.c: In function ‘RNG_RandomUpdate’: drbg.c:510:5: error: size of array ‘arg’ is negative make[4]: *** [Linux2.6_x86_glibc_PTH_OPT.OBJ/Linux_SINGLE_SHLIB/drbg.o] Error 1 I tried looking for the source file in /usr/include/nss/ I could not find it there, so that I can copy it over. I did look at the following post http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/40c7cdbec15e98fe?pli=1 and tried -arch x86_64 -arch -i386 option but it will not work for other packages I did also look at http://live.gnome.org/JhbuildIssues/evolution?highlight=(\bCategoryJhbuildIssues\b)|(\bCategoryJhbuild\b) But this one is too old. What should I do? On Sun, 2011-03-06 at 19:03 +0100, Kjartan Maraas wrote: sø., 06.03.2011 kl. 10.05 +0530, skrev Manu Gupta: I am sorry for extending this thread, I am attaching the jhbuildrc which I made and I get this error checking for SCANNER... yes checking for FFI... no checking for ffi.h... configure: error: ffi.h not found In the configure phase of gobject-introspection. What should I do? Install libffi-devel. Cheers Kjartan Regards Manu ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Building Evolution
Hi All I need to get bleeding edge evolution from the git repo. I am trying to use jhbuild but the docs at the website are quite outdated http://projects.gnome.org/evolution/build.shtml Can I know the proper moduleset for building evolution -- Regards Manu Gupta ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Building Evolution
I am sorry for extending this thread, I am attaching the jhbuildrc which
I made
and I get this error
checking for SCANNER... yes
checking for FFI... no
checking for ffi.h... configure: error: ffi.h not found
In the configure phase of gobject-introspection.
What should I do?
Please see if my .jhbuildrc is correct / am I missing something.
On Sun, 2011-03-06 at 07:57 +0530, Manu Gupta wrote:
Hi All
I need to get bleeding edge evolution from the git repo. I am trying
to use jhbuild but the docs at the website are quite outdated
http://projects.gnome.org/evolution/build.shtml
Can I know the proper moduleset for building evolution
# -*- mode: python -*-
# edit this file to match your settings and copy it to ~/.jhbuildrc
# if you have a GNOME git account, uncomment this line
#repos['git.gnome.org'] = 'ssh://u...@git.gnome.org/git/'
repos['git.gnome.org']='git://git.gnome.org/'
# what module set should be used. The default can be found in
# jhbuild/defaults.jhbuildrc, but can be any of the files in the
# modulesets directory, or even the URL of a module set file on a web
# server.
# moduleset = 'gnome-suites-core-3.0'
#
# A list of the modules to build. Defaults to the GNOME core:
# modules = [ 'meta-gnome-core' ]
# Or to build GNOME and the GNOME featured apps set:
moduleset = ['gnome-suites-core-3.0', 'gnome-apps-3.0']
# modules = ['meta-gnome-core', 'meta-gnome-apps-featured']
# Or to build the old GNOME 2.32:
#moduleset = 'gnome-2.30'
modules = ['evolution']
# what directory should the source be checked out to?
checkoutroot = os.path.expanduser('~/checkout/gnome')
# the prefix to configure/install modules to (must have write access)
prefix = '/home/hawk/opt/evolution'
# custom CFLAGS / environment pieces for the build
# os.environ['CFLAGS'] = '-Wall -g -O0'
# extra arguments to pass to all autogen.sh scripts
# to speed up builds of GNOME, try '--disable-static --disable-gtk-doc'
#autogenargs=''
# On SMP systems you may use something like this to improve compilation time:
# be aware that not all modules compile correctly with make -j2
# You can also use 'make V=0' if you want less output while compiling.
makeargs = '-j2'
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] building evolution-data-server against the already installed libdb
On Mon, 2006-02-27 at 17:49 -0500, Mikhail Teterin wrote: Hello! I'm trying to convince the maintainers of the evolution-data-server FreeBSD port (http://freshports.org/databases/evolution-data-server) to build the software against the db4-version installed by the separate port of SleepyCat's db4 (http://freshports.org/databases/db43). I'm using the thus built evolution (against db-4.3.29) to type this message, but they remain hesitant, because of the past problems they encountered trying to build evolution using the already installed db3 instead of the version then-bundled with evolution. I'm guessing, you used to have modified version of db3, which allowed it to work, where the standard version did not. Is there anything like that in the db4.1 version bundled with e-d-s 1.4.2.1, or can we safely use any reasonably recent version of db4? Moreover, perhaps, you can be convinced to stop the bundling of db4 completely and turn it into just another pre-requisite? http://bugzilla.gnome.org/show_bug.cgi?id=319393 contains a patch we've been using in the DBus port of EDS to use a dynamic libdb. Instead of simply hacking away at the makefiles it adds an option, so is suitable for integration. EDS comes with a copy of libdb 4.1. It was copied as back in the early days of Evolution some people had db3, and some had db4, but the file format changed. The solution to this was to add migration logic from db3 to db4 in EDS, and to enforce EDS linking to db4.1 by embedding the source. Recently the DB file format hasn't changed, so the problem is moot. I've been running EDS with a dynamically linked libdb 4.1, 4.2 and 4.3 without any problems, on both Intel and ARM. I really would like this patch to be merged into EDS for G2.16, if only for the memory reduction: libdb is statically linked into both the bdb addressbook backend and libedataserver, at a cost of 600K each time. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] building evolution-data-server against the already installed libdb
В Пнд, 27/02/2006 в 17:49 -0500, Mikhail Teterin пишет: I'm trying to convince the maintainers of the evolution-data-server FreeBSD port (http://freshports.org/databases/evolution-data-server) to build the software against the db4-version installed by the separate port of SleepyCat's db4 (http://freshports.org/databases/db43). I'm using the thus built evolution (against db-4.3.29) to type this message, but they remain hesitant, because of the past problems they encountered trying to build evolution using the already installed db3 instead of the version then-bundled with evolution. I'm guessing, you used to have modified version of db3, which allowed it to work, where the standard version did not. Is there anything like that in the db4.1 version bundled with e-d-s 1.4.2.1, or can we safely use any reasonably recent version of db4? Moreover, perhaps, you can be convinced to stop the bundling of db4 completely and turn it into just another pre-requisite? I used to compile e-d-s 1.4 along an external db4.3, by applying a simple patch. It didn't seem to cause any problems. So, what's the purpose of bundling an obsolete version of Berkeley DB inside the project? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] building evolution-data-server against the already installed libdb
On 3/6/06, Mikhail Zabaluev [EMAIL PROTECTED] wrote: I used to compile e-d-s 1.4 along an external db4.3, by applying a simple patch. It didn't seem to cause any problems. You are of course free to apply your own patches; however, in the long term, using a distribution's version of bdb will probably be an intolerable maintenance burden for either distributors or evolution: So, what's the purpose of bundling an obsolete version of Berkeley DB inside the project? I think the idea was that since the berkeley db API is not very stable, and since distributions ship a wide variety of versions of berkeley db, it would be simpler to ship a version of bdb along with evolution to avoid either (1) requiring distributions wishing to ship evolution to either ship a special bdb just for it, or patch evolution on their own (a big maintenance burden for distributors) or (2) requiring evolution to be compatible against multiple versions of bdb (a big maintenance burden for evolution) Maybe the bdb API is more stable these days so this no longer makes sense; I was under the impression it was still changing quite often. Have fun, Peter ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] building evolution-data-server against the already installed libdb
As far as I can recall, when I asked the same thing, the response was that this is how Berkeley DB is supposed to be used, embedded into another product. That some (all?) Linux distributions choose to also ship a separately installed instance was irrelevant ;) --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
