java.lang.NullPointerException on JRES 2022 about giggity HOT 10 CLOSED

Did you manage to reproduce it?

from giggity.

Sorry! Completely missed this. Were people using a Play Store version of Giggity? I don't remember seeing crashes in the dashboard when I checked it a few weeks ago..

from giggity.

Just checked. None in the last 60 days.. :(

from giggity.

I can reproduce that. It is not a crash of the app, but the schedule does not reload anymore. The first time I open JRES 2022 everything is fine. But if I then go back an try to update the data for that conference, then this exception occur and the conference cannot be opened anymore.

from giggity.

Hm I can repro it in an emulator now, even on the first load actually. Now I wonder whether their server spits out .ics in somewhat random format/order.. What I see is there seems to be no header, it goes straight to all the calendar events? Not even a calendar title, or maybe it's somewhere in the middle of the file?

Too late here now or I'd go figure out why it crashes on this, because obviously it should not..

from giggity.

Oddly if I open the ICS file in Thunderbird it loads fine, but if I use xdg-open which sends it to Thunderbird, it complains there are no importable event inside.

from giggity.

import icalendar
f=open('planning_jres.ics','r')
c=icalendar.Calendar.from_ical(f.read())

Gives:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe2 in position 101636: invalid continuation byte

It seems some multibytes UTF-8 sequence got some CR-LF in the middle:

$ cut -z -b 101636-101699 planning_jres.ics | hd
00000000  64 e2 0d 0a 20 80 99 65  78 70 6c 6f 69 74 61 74  |d... ..exploitat|
00000010  69 6f 6e 2e 0d 0d 0a 20  5c 6e 0d 0a 20 0d 0d 0a  |ion.... \n.. ...|
00000020  20 5c 6e 0d 0a 20 20 20  2a 20 54 69 74 72 65 20  | \n..   * Titre |
00000030  64 75 20 42 6f 46 20 3a  20 50 72 c3 a9 73 65 6e  |du BoF : Pr..sen|
00000040  00                                                |.|

0xE2 0x80 0x99 is U+2019 RIGHT SINGLE QUOTATION MARK (not even the correct apostrophe btw).

So I guess you'll have to fix your server to not split UTF-8 sequences 😅

from giggity.

Huh, now I'm curious whether that's the problem with Giggity too... Can definitely confirm that iconv is still unhappy with this file:

wilmer@ruby:/tmp/jres$ iconv -f utf-8 -t utf-8 < planning.ics > /dev/null
iconv: illegal input sequence at position 101940

Which is indeed the same event still, based on your quote above.

from giggity.

Should be fixed in d0fac0f now.

Interestingly it's not too upset by the dodgy Unicode. But the file is even weirder, I did also notice extremely odd line endings (CR-CR-LF) which confuse the new line numbering I've added and adds debugging noise, but not going to try to fix that, IMHO that's just Java doing line breaks wrong. :-/

I see the conf is on Tuesday already, I should be able to push a new version to the Play Store tomorrow at least..

from giggity.

(That's done by the way, version 2.0.8 should fix this problem. But it's VERY unlikely to hit F-Droid in time.)

from giggity.