[bug#44197] gnu: khal: Update to 0.10.2.

Hi Leo,

> Unfortunately, the second part of the patch ("hunk 2") does not apply to
> the latest Guix Git master branch:
you’re right. Looks like there is a weird space character between “;;”
and “Reported upstream”. Maybe email ate that? I’m attaching a `git
show` instead and also uploading the change to
https://github.com/PromyLOPh/guix (branch work-khal, commit
503169b39de09e3c3969bb2dc92464f054d79560).

Thanks for taking care of this,
Lars

On Mon, Oct 26, 2020 at 08:37:24AM +0100, Lars-Dominik Braun wrote:
> Thanks for taking care of this,

Thanks for taking care of this package I use every day! :)

> commit 503169b39de09e3c3969bb2dc92464f054d79560
> Author: Lars-Dominik Braun <lars@6xq.net>
> Date:   Sat Oct 24 20:17:48 2020 +0200
> 
>     gnu: khal: Update to 0.10.2.
>     
>     * gnu/packages/calendar.scm (khal): Update to 0.10.2.
>     [source]: Drop upstream patches.
>     [arguments]: Drop substitute* for bug fixed upstream and ignore failing
>     test in 'check.
>     [inputs]: Add missing inputs.

Pushed as 21955a54da2bc171f2745486f62aceeacea7993a.

I wonder, should we disable the test suite entirely? In my experience,
it's not reliable — different parts of it will succeed or fail on
subsequent runs, or on different computers, or when verbose output is
enable, etc. The upstream bug tracker is full of reports like that.

For example:

https://github.com/pimutils/khal/issues/860

Hi,

> Thanks for taking care of this package I use every day! :)
yeah, me too :)

> I wonder, should we disable the test suite entirely? In my experience,
> it's not reliable — different parts of it will succeed or fail on
> subsequent runs, or on different computers, or when verbose output is
> enable, etc.
I just checked on two different machines and you’re right, on my main
machine the test suite works (even across multiple runs), on the other
one three tests[1] fail – with exactly the same Guix version
(commit 6a0fec57092d574c33b997e5972012e9c29a4dd4). This should not
happen in the build environment. Imo it would be worth figuring out why
it does nontheless.

Cheers,
Lars

[1] TestCollection.test_multi_uid_vdir, test_event_different_timezones
and test_default_calendar.

On Tue, Oct 27, 2020 at 09:14:10AM +0100, Lars-Dominik Braun wrote:
> I just checked on two different machines and you’re right, on my main
> machine the test suite works (even across multiple runs), on the other
> one three tests[1] fail – with exactly the same Guix version
> (commit 6a0fec57092d574c33b997e5972012e9c29a4dd4). This should not
> happen in the build environment. Imo it would be worth figuring out why
> it does nontheless.

Alright, I will disable it then.

Can you say more about the differences between the machines where it
succeeds and fails? It could help us figure out what's going on.

For me, I'm building on a Thinkpad (Intel Core i5-6300U CPU) using
Debian with Linux 5.9.1, with a tmpfs filesystem for the build
environment. I use an SSD for storage...  but I don't think the tmpfs is
ever swapping on this machine. There is a lot of unused RAM.

> 
> [1] TestCollection.test_multi_uid_vdir, test_event_different_timezones
> and test_default_calendar.

These fail for me often. I also sometimes see failures of
test_only_update_old_event, test_birthdays, test_birthdays_29feb and
test_birthdays_no_year.

Hi,

> Can you say more about the differences between the machines where it
> succeeds and fails? It could help us figure out what's going on.
they are quite different machines unfortunately. One is Gentoo Linux
running on a Ryzen 5 3600 desktop machine (working), the other one a
Ubuntu 19.10 on a Thinkpad (Intel Core i5-8250U) Laptop (not working).
Both have SSD storage and /tmp on a tmpfs.

Could there be something leaking into the build environment to make it
fail consistently on one machine, but not the other one?

Cheers,
Lars

On Wed, Oct 28, 2020 at 08:22:13AM +0100, Lars-Dominik Braun wrote:
> Hi,
> 
> > Can you say more about the differences between the machines where it
> > succeeds and fails? It could help us figure out what's going on.
> they are quite different machines unfortunately. One is Gentoo Linux
> running on a Ryzen 5 3600 desktop machine (working), the other one a
> Ubuntu 19.10 on a Thinkpad (Intel Core i5-8250U) Laptop (not working).
> Both have SSD storage and /tmp on a tmpfs.

Interesting that we both get failures on Core i5 processors and
Debian-family operating systems. I am not using the Debian kernel (I
build a variant of the Guix kernel), but I do use the Debian package
tooling to manage it.

> Could there be something leaking into the build environment to make it
> fail consistently on one machine, but not the other one?

Could be, but the question is what? The build environment isolation
doesn't account for things like filesystem, kernel version, time of day
(👀), CPU bugs... besides the common culprit of some race conditions in
the test suite.

Are you using the same kernel versions on your two machines? I guess the
kernel configs likely don't match between them.

Hi Leo,

some more data points:

- works consistently inside a VM (Common KVM processor) with Ubuntu
  20.04 → not the kernel version/configuration or OS.
- whether it works or not does not change during the day → not time
  related(?)
- works consistently on a different laptop with i5-8250U and Gentoo →
  not the processor

After looking at how test_birthdays_29feb fails, I’m leaning towards the
possiblity of a bug in khal. So, I commented here:
https://github.com/pimutils/khal/issues/860#issuecomment-718583031

> Are you using the same kernel versions on your two machines? I guess the
> kernel configs likely don't match between them.
No, previously the Ubuntu machine used 5.3 and now after upgrading to
20.04 version 5.4. The test suite is still failing there and still
succeeding on my desktop, which is using a custom kernel configuration
tailored to this particular machine (version 5.8 right now).

Cheers,
Lars