gnome-calendar 44.1-r0 Segmentation Fault

This is because openrc-settingsd is at version 1.2.0 in Alpine v3.18. It would need to be updated to 1.4.0 to resolve this. (correct me if I'm wrong)

By Newbyte on 2023-06-10T22:20:02

Hmm, I don't think it is that, unless I'm missing something else. I backported 1.4.0 to my L5 running 23.06, and gnome-calendar still segfaults:

....
(gnome-calendar:16780): GLib-CRITICAL **: 00:18:35.153: g_date_time_get_ymd: assertion 'datetime != NULL' failed
(gnome-calendar:16780): GLib-CRITICAL **: 00:18:35.153: g_date_time_get_ymd: assertion 'datetime != NULL' failed
(gnome-calendar:16780): GLib-CRITICAL **: 00:18:35.153: g_date_time_get_ymd: assertion 'datetime != NULL' failed
Segmentation fault
librem5:~$ apk version openrc-settingsd
Installed:                                Available:
openrc-settingsd-1.4.0-r0               > 1.2.0-r1

By clayton craft on 2023-06-10T22:20:02

assigned to @z3ntu and @pabloyoyoista

By Newbyte on 2023-06-10T06:22:30

added release-v23.06 status::confirmed type::bug ui-phosh labels

There seems to be still a couple of issues with this. It's incredible how something like this has so many corner-cases. I managed to reproduce the problem. The solution:

Part 1: make sure that we make use of tzdata for setting the timezone (when available that it's most of the times) https://lists.sr.ht/~postmarketos/pmbootstrap-devel/patches/41791 I wonder if we should also make tzdata a dependency of postmarketos-base-ui. In any case, it seems like it's already installed in phosh, gnome and plasma UIs.
Part 2: fix some small issues in alpine's setup-timezone script, that have consequences in openrc-settingsd and some create some things that it shouldn't.
Part 3: With the things above merged, we should migrate all existing installs. Users should remove /etc/zoneinfo and rerun setup-timezone -i $TZ. This should be part of an edge blogpost, but also of the relase notes for the next release. Quite unfortunate timing, though.

Additionally, we have to make sure that we don't regress, with things like https://gitlab.alpinelinux.org/alpine/aports/-/issues/14844. Although that's already fixed after discussion in IRC: https://git.alpinelinux.org/aports/commit/?id=274b051aa5f0bd1fb5c2630b07ad50e346bc0a1e But needs the three of the parts above to work.

As a temporary workaround, to get this working you can simply rm -rf /etc/zoneinfo, and ln -sf /usr/share/zoneinfo/Europe/Berlin (or your corresponding timezone code), and backport openrc-settingsd. It's unfortunate that gnome-calendar crashes when the timezone is not correctly setup, but at least it lets us identify when and how things can go wrong.

By Pablo Correa Gomez on 2023-06-11T15:59:50

oh wow, thank you for debugging this! (I had just finished building gnome-cal with symbols to run under gdb :P)

Part 1: make sure that we make use of tzdata for setting the timezone (when available that it's most of the times) https://lists.sr.ht/\~postmarketos/pmbootstrap-devel/patches/41791

I tested your pmb patches with phosh, works as intended.

I wonder if we should also make tzdata a dependency of postmarketos-base-ui. In any case, it seems like it's already installed in phosh, gnome and plasma UIs.

The package is 3MB, and it's likely already installed for most UIs anyways (as you said), we probably want to make sure it is installed for everything anyways so having it listed in pmos-base package seems reasonable to me. This way we can guarantee it will always be installed, and not have to rely on every UI to implicitly pull it in (which might be happening today, but that's not a guarantee)

Part 2: fix some small issues in alpine's setup-timezone script, that have consequences in openrc-settingsd and some create some things that it shouldn't.

What small issues?

Part 3: With the things above merged, we should migrate all existing installs. Users should remove /etc/zoneinfo and rerun setup-timezone -i $TZ. This should be part of an edge blogpost, but also of the relase notes for the next release. Quite unfortunate timing, though.

Could we migrate folks in the postmarketos-base.post-upgrade script instead?

By clayton craft on 2023-06-11T15:59:49

Thanks a lot for giving all this a review and a try!

we probably want to make sure it is installed for everything anyways

Perfect! !4175 (merged)

What small issues?

The localtime right now points to //usr/share/zoneinfo/whatever. And GLib does not like the double slash at the beginning. Also, the fix in https://git.alpinelinux.org/aports/commit/?id=274b051aa5f0bd1fb5c2630b07ad50e346bc0a1e depends on /etc/zoneinfo not existing, which right now does regardless of the options sent to setup-timezone.

Could we migrate folks in the postmarketos-base.post-upgrade script instead?

Maybe? I'm not 100% sure, since we need to figure out a way to properly fetch the timezone, but could be an option, yes. Anyway, I'd like to wait for the rest of things to be merged.

By Pablo Correa Gomez on 2023-06-11T16:51:04

mentioned in commit 2b71c9af

By Pablo Correa Gomez on 2023-06-11T16:46:23

mentioned in merge request !4175 (merged)

By Pablo Correa Gomez on 2023-06-11T16:47:04

mentioned in commit ef00e24e

By Pablo Correa Gomez on 2023-06-12T05:52:13

mentioned in issue #1394 (closed)

By Pablo Correa Gomez on 2023-06-13T21:28:42

It was confirmed by @craftyguy and another couple of users that with the current stack, the fixup work well. New installations are still waiting on https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/157. The question is what to do with current installations. The process would be:

If /etc/localtime is pointing to /usr/share/zoneinfo, then it's all good, simply remove /etc/zoneinfo if it exists to cleanup, and we're good.
If /etc/localtime points to /etc/zoneinfo, then we could just move the suffix to point to the same place in /usr/share/zoneinfo (that now exists, we depend on tzdata), remove /etc/zoneinfo and call it a day.

@craftyguy suggested to do this in postmarketos-base post-upgrade script. I'll likely push that the weekend if nobody has a better idea.

By Pablo Correa Gomez on 2023-06-15T14:56:17

mentioned in issue #2253 (closed)

By Pablo Correa Gomez on 2023-08-05T13:03:34

mentioned in commit 110f19cb

By Pablo Correa Gomez on 2023-08-05T21:39:03

mentioned in merge request !4308 (merged)

By Pablo Correa Gomez on 2023-08-05T21:39:07

mentioned in commit 0de5a180

By Pablo Correa Gomez on 2023-08-05T21:40:23

mentioned in commit df92090f

By Pablo Correa Gomez on 2023-08-06T19:32:55

mentioned in commit 876a7ec9

By Pablo Correa Gomez on 2023-08-06T19:33:56

mentioned in commit 04abb5b1

By Pablo Correa Gomez on 2023-08-07T07:42:13

closed

mentioned in commit d709392b

By Pablo Correa Gomez on 2023-08-07T07:46:24

mentioned in commit d7dba8d6

By Pablo Correa Gomez on 2023-08-27T05:52:22

mentioned in commit 7b27cf78

By Pablo Correa Gomez on 2023-09-07T21:51:55

gnome-calendar 44.1-r0 Segmentation Fault

Describe your issue

What's the expected behaviour?

What's the current behaviour?

How to reproduce your issue?

What device are you using?

On what postmarketOS version did you encounter the issue?

On what environment did you encounter the issue?

Environments

How did you get postmarketOS image?

What's the build date of the image? (in yyyy-mm-dd format)

Additional information

Child items 0

Activity