On Mon, 2010-05-10 at 16:48 +0100, Lukas Zeller wrote: > Hi Patrick, > > On May 10, 2010, at 9:04 , Patrick Ohly wrote: > > > Confirmed, works for me. > > Thanks! > > > I should have mentioned that I had already made similar changes as you > > on the moblin.org master branch (check for NULL obj in debug macros, > > enable debug logging inside vtimezone code when invoked by mimedir > > profile parser). > > > > My own debug logging patches go a bit further: > > - log an error when parsing a VTIMEZONE fails > > - logging of libical timezone conversion > > - logging of timezone matching > > > > I'm trying to track down an unexpected timezone failure with this which > > occurs when normal Evolution events are involved. > > > > Do you agree with these changes? Would you mind merging them? I rebased > > them on your "luz" branch. > > The attempt to init the time zones after reading config (fc000b0f45 > (TSyncAppBase: moved system time zone parsing after config reading)) > creates a chicken and egg problem. The config reading process relies > itself on the time zone stuff being initialized, most prominently for > <definetimezone>, but also for other tags that have ISO8601 timestamp > values.
I see. > Maybe the dilemma can be solved by adding an optional, second > initialize run after config reading that can be switched on > specifically to track down timezone init problems. That would imply redoing some of the work. What about the following (code in master, as I need to fix that anyway): commit 7bbec4fd20cde059973d4d1c840fcee85d947e60 Author: Patrick Ohly <[email protected]> Date: Tue May 11 16:57:35 2010 +0200 time zone init and logging: split into part before and after config parsing This patch reverts the "move system time zone parsing after config reading" part of commit fc000b0f45. As Lukas pointed out, config parsing already depends on time zones, for example for <definetimezone>. But this patch keeps the finishConfig() callback and uses it to invoke a second global time zone function. On Linux, that function is used to add the libical time zone definitions and logs them at the same time. Builtin time zones are added at the original time, before parsing the config. This is a compromise between having no time zones while parsing the config and not logging the libical time zones. It works for SyncEvolution, because it doesn't reference the additional time zones in the config. > Another option would be to use the ConferrPuts() channel, which is > ready before config is read by definition. That won't help, because I need this information in the normal log file to simplify remote debugging. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
