From mcrha at redhat.com  Wed Nov  1 02:47:12 2017
From: mcrha at redhat.com (Milan Crha)
Date: Wed, 01 Nov 2017 10:47:12 +0100
Subject: Libical 3.0 Branched
In-Reply-To: <2907776.1DXAHR4KH7@zazzy>
References: <7466367.UoxyEaZc3g@zazzy> <2907776.1DXAHR4KH7@zazzy>
Message-ID: <c00098e565c9991ca3e480d7843e570cd15f445b.camel@redhat.com>

On Sat, 2017-10-28 at 12:19 -0400, Allen Winter wrote:
> Libical v3.0.0 is released!

	Hi,
thanks for the release.

I tried to add it into Fedora, but the timezones test fails there.
Verifying locally, using tzdata-2017b works fine, but using
tzdata-2017c [1] makes the test fail with result:
> 40:  *** Summary: 424 zones tested, 379 days failed, 154381 okay => 0% failed ***
> 40/55 Test #40: timezones ........................***Failed    0.64 sec
Downgrading tzdata back to 2017b makes it work:
> 40:  *** Summary: 424 zones tested, 0 days failed, 154760 okay => 0% failed ***
> 40/55 Test #40: timezones ........................   Passed    0.70 sec

The build on the Fedora servers (with tzdata-2017c) shows this:
> 40: @?\?fU: day 014: okay again: 2017-01-14 23:00:00 UTC = libc 2017-01-15 12:00:00 dst 0
> 40:  *** Summary: 424 zones tested, 2204 days failed, 152556 okay => 1% failed ***
> 40/55 Test #40: timezones ........................***Failed    0.83 sec

I also tried libical 2.0.0 with tzdata-2017c and it passes the test
with similar error, but ignores it:
> 6:  *** Summary: 424 zones tested, 527 days failed, 154233 okay => 0% failed ***
> 6:  *** Expect some small error rate with inter-operable vtimezones *** 
> 6/9 Test #6: timezones ........................   Passed    0.30 sec

I'm unsure where to report it, thus I start here.
	Bye,
	Milan

[1] It had been built for Fedora only on this Monday, here is
    the package for rawhide in koji:
    https://koji.fedoraproject.org/koji/buildinfo?buildID=991821
    There are builds down to Fedora 25 too.
    Here are package sources for rawhide:
    http://pkgs.fedoraproject.org/cgit/rpms/tzdata.git/tree/
    if it would help.


From mcrha at redhat.com  Wed Nov  1 10:27:06 2017
From: mcrha at redhat.com (Milan Crha)
Date: Wed, 01 Nov 2017 18:27:06 +0100
Subject: Libical 3.0 Branched
In-Reply-To: <c00098e565c9991ca3e480d7843e570cd15f445b.camel@redhat.com>
References: <7466367.UoxyEaZc3g@zazzy> <2907776.1DXAHR4KH7@zazzy>
 <c00098e565c9991ca3e480d7843e570cd15f445b.camel@redhat.com>
Message-ID: <f3cb98ac9b27e680831b0c8a15e59810a242a578.camel@redhat.com>

On Wed, 2017-11-01 at 10:47 +0100, Milan Crha wrote:
> I tried to add it into Fedora, but the timezones test fails there.

	Hi,
a little follow up, with my findings. The attached are three patches
which help. Each of them contains an explanation in the commit message.

I also received occasional failures in .gir file generation, which
seems to be related to parallel build (they stroke on ppc64, ppc64le
and such architectures only, not on i686, nor x86_64, here (yet)). The
reported error was about broken .gir file, either empty or incomplete.
My workaround for it is to run 'make' with "-j1".

I hope these will help.
	Bye,
	Milan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Increase-element-size-in-libical-glib-array.py-test.patch
Type: text/x-patch
Size: 996 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libical-devel/attachments/20171101/d97370c0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Return-back-fail-forgiveness-into-the-timezones-test.patch
Type: text/x-patch
Size: 1160 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libical-devel/attachments/20171101/d97370c0/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Fix-possible-use-after-free-in-timezones-test.patch
Type: text/x-patch
Size: 3011 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libical-devel/attachments/20171101/d97370c0/attachment-0002.bin>

From winter at kde.org  Fri Nov  3 06:19:00 2017
From: winter at kde.org (Allen Winter)
Date: Fri, 03 Nov 2017 09:19:00 -0400
Subject: Libical 3.0 Branched
In-Reply-To: <f3cb98ac9b27e680831b0c8a15e59810a242a578.camel@redhat.com>
References: <7466367.UoxyEaZc3g@zazzy>
 <c00098e565c9991ca3e480d7843e570cd15f445b.camel@redhat.com>
 <f3cb98ac9b27e680831b0c8a15e59810a242a578.camel@redhat.com>
Message-ID: <7177259.aFGHeQcKTv@zazzy>

Thanks Milan,

I committed your patches to the 3.0 and master branches.
I also updated the zoneinfo to tzdata2017c

On Wednesday, November 1, 2017 1:27:06 PM EDT Milan Crha wrote:
> On Wed, 2017-11-01 at 10:47 +0100, Milan Crha wrote:
> > I tried to add it into Fedora, but the timezones test fails there.
> 
> 	Hi,
> a little follow up, with my findings. The attached are three patches
> which help. Each of them contains an explanation in the commit message.
> 
> I also received occasional failures in .gir file generation, which
> seems to be related to parallel build (they stroke on ppc64, ppc64le
> and such architectures only, not on i686, nor x86_64, here (yet)). The
> reported error was about broken .gir file, either empty or incomplete.
> My workaround for it is to run 'make' with "-j1".
> 
> I hope these will help.
> 	Bye,
> 	Milan
> 






From mcrha at redhat.com  Mon Nov  6 05:36:59 2017
From: mcrha at redhat.com (Milan Crha)
Date: Mon, 06 Nov 2017 14:36:59 +0100
Subject: Libical 3.0 Branched
In-Reply-To: <7177259.aFGHeQcKTv@zazzy>
References: <7466367.UoxyEaZc3g@zazzy>
 <c00098e565c9991ca3e480d7843e570cd15f445b.camel@redhat.com>
 <f3cb98ac9b27e680831b0c8a15e59810a242a578.camel@redhat.com>
 <7177259.aFGHeQcKTv@zazzy>
Message-ID: <583f02cab3723433440c04ecbda7255fe4c85656.camel@redhat.com>

On Fri, 2017-11-03 at 09:19 -0400, Allen Winter wrote:
> I committed your patches to the 3.0 and master branches.
> I also updated the zoneinfo to tzdata2017c

	Hi,
thanks.

I've just discovered one more issue, there could happen a deadlock on
the builtin mutex since commit 0ebf2d9a7183be94991c2681c6e3f009c64cf7cc
caused by icaltimezone_load_builtin_timezone(). The trick was to have a
timezone, which didn't have set location. In such case the function
returns immediately, without releasing acquired mutex. Attached is one
possible change, which fixes it.

I do not know why I didn't notice it earlier. I'm afraid this change
would worth a release, because it's a show stopper.
	Bye,
	Milan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ical.patch
Type: text/x-patch
Size: 976 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libical-devel/attachments/20171106/705b5e9e/attachment.bin>

From winter at kde.org  Sun Nov 12 10:22:56 2017
From: winter at kde.org (Allen Winter)
Date: Sun, 12 Nov 2017 13:22:56 -0500
Subject: libical help with issue 320
Message-ID: <9689599.6lXUxd7rxv@zazzy>

Any OpenBSD people out there who can help debug issue320?
https://github.com/libical/libical/issues/320

I need to create a 3.0.1 release and would like to include a fix for 320, if possible.

-Allen





From mcrha at redhat.com  Mon Nov 13 23:38:54 2017
From: mcrha at redhat.com (Milan Crha)
Date: Tue, 14 Nov 2017 08:38:54 +0100
Subject: libical help with issue 320
In-Reply-To: <9689599.6lXUxd7rxv@zazzy>
References: <9689599.6lXUxd7rxv@zazzy>
Message-ID: <e7982f91e16f53062f8d27daf7f2396ebf8716c4.camel@redhat.com>

On Sun, 2017-11-12 at 13:22 -0500, Allen Winter wrote:
> Any OpenBSD people out there who can help debug issue320?
> https://github.com/libical/libical/issues/320

	Hi,
I do not have OpenBSD, but maybe it's not that related to particular
OS. I'd ask for all data passed into the function (the timezones), to
see what failed. And the pthread version being used (though the
backtrace doesn't seem to be pthread, as mine shows different function
call). I didn't notice any other issue than the forgotten unlock, which
is weird if the reporter has the fix for it applied - maybe verify the
applied fix is really in use? I'd also try to not use recursive mutex,
whether it'll change anything (at the top of the file), but as there is
no real change in the lock/unlock call from the previous libical
version, then it looks like the change not being applied/in use.

Another try would be using helgrind from valgrind 
   valgrind --tool=helgrind
which may eventually catch some issues around mutexes, but I confess I
didn't use it myself, I'm only aware of it.
	Bye,
	Milan


From winter at kde.org  Tue Nov 14 11:05:45 2017
From: winter at kde.org (Allen Winter)
Date: Tue, 14 Nov 2017 14:05:45 -0500
Subject: Libical 3.0 Branched
In-Reply-To: <f3cb98ac9b27e680831b0c8a15e59810a242a578.camel@redhat.com>
References: <7466367.UoxyEaZc3g@zazzy>
 <c00098e565c9991ca3e480d7843e570cd15f445b.camel@redhat.com>
 <f3cb98ac9b27e680831b0c8a15e59810a242a578.camel@redhat.com>
Message-ID: <1742872.1Uf98JLjbU@zazzy>

Thanks Milan,

I committed your patches to the 3.0 and master branches.
I also updated the zoneinfo to tzdata2017c

On Wednesday, November 1, 2017 1:27:06 PM EDT Milan Crha wrote:
> On Wed, 2017-11-01 at 10:47 +0100, Milan Crha wrote:
> > I tried to add it into Fedora, but the timezones test fails there.
> 
> 	Hi,
> a little follow up, with my findings. The attached are three patches
> which help. Each of them contains an explanation in the commit message.
> 
> I also received occasional failures in .gir file generation, which
> seems to be related to parallel build (they stroke on ppc64, ppc64le
> and such architectures only, not on i686, nor x86_64, here (yet)). The
> reported error was about broken .gir file, either empty or incomplete.
> My workaround for it is to run 'make' with "-j1".
> 
> I hope these will help.
> 	Bye,
> 	Milan
> 






From mcrha at redhat.com  Wed Nov 22 08:31:42 2017
From: mcrha at redhat.com (Milan Crha)
Date: Wed, 22 Nov 2017 17:31:42 +0100
Subject: 'zic' WORK_AROUND_QTBUG_53071 breaks libical with interoperable
 timezones
Message-ID: <691241fdc452119163d4bc537c3ab4f44049a3b5.camel@redhat.com>

	Hello,
I spent several hours investigating an issue reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1514912

and it turned out that tzdata's (or in glibc) zic.c
WORK_AROUND_QTBUG_53071 breaks libical 2.0 with interoperable timezones
in a way that it can crash, but also provides incorrect data. You can
see my tests at this comment:
https://bugzilla.redhat.com/show_bug.cgi?id=1514912#c20

and the next comment contains a reproducer. A good news is that only
libical 2.0 with interoperable timezones leads to a crash, libical 3.0
is fine, but libical 3.0 seems to provide wrong timezone.

Maybe that's the reason why the src/test/timezones.c fails in some
cases? Just an idea.

I suppose, from the output of the exact-timezone=1, that the component
in 3.0 should have DTSTART at 1970 and the new one from 2038 is just a
continuation.

Could you comment on the issue, please? Either here, or at the
downstream bugzilla. I'm fine to write your thoughts from here to the
bugzilla, in case you do not have an account there.

	Thanks and bye,
	Milan

P.S.: I hope Kent will not mind I CC'ed him directly, he significantly
changed the zone files parser in 3.0, thus he knows the most about it
at the moment, from my point of view.


