Hi Oleg,
I'm hoping that The Upstream Vendor know's about the problem so that it
get's fixed upstream. But I definatly like simple one line fixes. If
it looks like RedHat isn't going to put it in anytime soon, then we'll
put it in testing for a short time, then into errata.
As for building it. we used the 1.4.8 version of m4. There was several
rpm's that wouldn't build without it. That isn't the version that we
shipped, but we thought we had put the src.rpm in our SRPMS/SL area so
that others could use it.
After checking we saw that it wasn't there, so Connie just put it up
there right now.
ftp://ftp.scientificlinux.org/linux/scientific/5x/SRPMS/SL/m4-1.4.8-1.src.rpm
Troy
Oleg Sadov wrote:
> At Sunday Time we spent a lot of time for testing of desktop environment
> in a fresh installation from SL50 and was slightly frustrated by
> crushing of Evolution during startup. In CentOS Evolution started
> without problems (but it has version 2.8.0-33, not 2.8.0-33.0.1).
>
> Further analisys shows dependency of this problem of last evolution-
> data-server timezone description changes. This bug may be reproduced by
> setting TZ environment variable, for example:
>
> TZ=Europe/Moscow evolution
>
> Some of bug-sensitive timezones:
> Russia -- Europe/Moscow, Europe/Volgograd, Asia/Irkutsk
> Indonesia -- Asia/Makassar, Asia/Ujung_Pandang
> Mongolia -- Asia/Ulaanbaatar, Asia/Ulan_Bator
>
> After looking to backtrace & source code debugging I found the root of
> evil -- into the last changes of data-server zoneinfo descriptions
> (evolution-data-server-1.8.0-updated-zoneinfo.patch) removed TZNAME tags
> from Australia/Perth.ics and Asia/Jerusalem.ics. As a consequence --
> NULL pointer for TZ name string references, string comparison with NULL
> pointers an so on...
>
> Because, evolution-data-server is important infrastructure component not
> only for Evolution, but for some other GNOME components too, I think,
> this problem must be resolved. Given above, we have three ways for that:
> 1) quick&dirty -- setting up corresponding UTC-relative TZ (not exactly
> equivalent) or starting of evolution with --disable-eplugin option
> 2) orthodox -- downgrading of evolution-data-server package, or setting
> up TZNAME tags in Australia/Perth and Asia/Jerusalem timezones
> 3) hackers way -- source patching by single line of code (the patch is
> attached)
>
> Of course, further testing will be helpfull and, may be, escalating this
> problem to the upstream vendor will be reasonably.
>
> Apropos, Connie or/and Troy, which procedure was used for evolution-
> data-server package building? My rpmbuild on SL50 was finished with some
> error messages:
>
> ==================================================
> + aclocal
> configure.in:706: /usr/bin/m4: builtin `mkstemp' requested by frozen
> file is not supported
> autom4te: /usr/bin/m4 failed with exit status: 1
> aclocal: autom4te failed with exit status: 1
> ==================================================
>
> Seems like your package built by previous version of automake tool box.
> Package was rebuilded on SL50 only after removing `mkstemp' function
> checking directive in a line 706 of configure.in.
>
> --Oleg
>
>
> ------------------------------------------------------------------------
>
> --- evolution-data-server-1.8.0/calendar/libical/src/libical/icaltimezone.c.orig 2007-05-25 01:20:43.000000000 +0400
> +++ evolution-data-server-1.8.0/calendar/libical/src/libical/icaltimezone.c 2007-05-25 01:23:01.000000000 +0400
> @@ -1433,6 +1433,8 @@
>
> z_offset = get_offset(zone);
>
> + if (zone->tznames == NULL) continue;
> +
> if (z_offset == offset && !strcmp(tzname, zone->tznames))
> return zone;
> }
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
|
