Tuesday, 2020-09-08

*** zbenjamin is now known as Guest7666301:17
*** zbenjamin_ is now known as zbenjamin01:17
dcalisteHello chriadam, it's been a while, how are you ?06:58
chriadamhi dcaliste, I'm well thank you.  How are you?06:58
dcalisteI'm ok, thank you. Let's start if you agree with QMF related matters.06:59
chriadampvuorela: flypig: available currently to discuss?06:59
dcalisteYou may have noticed https://forum.sailfishos.org/t/email-text-disappears-with-pgp-signature/176806:59
dcalisteIt's about malformed emails when signed with the QMF plugin.07:00
chriadamah, not quoting the multipart correctly?07:00
dcalisteWith the help of rozgwi, we've found that it's an issue in QMF, where some parameters of the Content-Type are not quoted when needed.07:01
dcalisteSee https://codereview.qt-project.org/c/qt-labs/messagingframework/+/312509 for the fix.07:01
flypigchriadam, sure, I'm available, but a bit clueless today.07:01
dcalisteIt seems that the '/' character was missing somehow in the list of protected characters.07:02
dcalisteand thus "application/pgp-signature" was not escaped.07:02
chriadamthat is very strange, would have thought that mime types would often be of that form, and thus be hit frequently... but i guess not...07:03
dcalisteLooking at the commit history it seems that the slash has never been part of the protected characters.07:03
chriadamthe PR LGTM but I've also pinged Matt in case he has some concern07:04
dcalisteYes, but it's more subtile :07:04
dcalistethe Content-Type value should _not_ be quoted (even if with slash), but the parameter values _must_ be quoted when containing a protected character.07:04
dcalisteS you write Content-Type: multipart/signed; protocol="application/pgp-signature"; myParam=foo;07:05
dcalisteNormally the MR is chaging the quoting only for value of parameters.07:06
chriadamI see07:06
dcalisteIf the MR is accepted, there is another issue at hand : the CI is now using the Qt6 to-be dev branch in one of the bot. And the code is not Qt6 ready at all :/ So Ci is always failing and the MR won't go in.07:08
dcalisteAs suggested by pvuorela, I've compiled locally Qt6 and begun to compile QMF on top.07:08
chriadamI have this problem with QtPIM also - which I hope to address within the next two weeks, by porting QtPIM to build against Qt6/dev07:08
dcalisteIt's a lot of work, almost all files have issues.07:08
chriadamouch :-(07:09
chriadamooi what sort of issues are you hitting frequently?  I thought qt6 was supposed to be mostly compatible, but apparently not?07:09
dcalisteQRegExp has been replaced with QRegularExpression but with a different API, QTextCiodec is not part of QtCore anymore…07:09
dcalisteSome of the QMetaType functions have disappeared (because they are handled automatically).07:09
dcalisteMaybe some unforseen other issues, since at the moment, it has stopped on every 5 or 6 first files.07:11
dcalisteI'm afraid it will take some days to finish the transition.07:14
chriadamif you don't have time / inclination to finish the qmf porting, my advice would be: once the codereview PR is +2'd, make similar PR to our qmf repo, and we can just merge it on our side.07:14
dcalisteBut if you say that you're doing the same for QtPim, I'm feeling safer.07:14
chriadambut if you are willing to do the work, that would be fantastic07:15
chriadamyes, I am definitely going to do it for QtPIM07:15
chriadamhopefully within next two weeks.07:15
*** vilpan is now known as Guest9129407:17
*** Guest91294 is now known as vilpan07:17
chriadamdcaliste: should we discuss your calendar PRs next?  I think jpetrell has some time to discuss those07:18
dcalisteI will do it, I think for QMF.07:19
dcalisteYes, we can discuss them, sure.07:19
chriadamyou mentioned that upstream kcalcore accepted the MR related to the volatile properties from other sources (e.g. mkcal)07:21
chriadamflypig: did you review some of the PRs related to the volatile property support also?07:22
dcalisteYes, now our KCalcore MR contains exactly what is upstream.07:22
jpetrellsorry am not really up-to-speed with the calendar status. the proposed time zone combo box looks good, would yeah integrate it with time picker dialog like how alarm dialogs in Clock app integrate custom UI below time picker07:23
flypigchriadam, if I did, it was a while ago. Are they still pending? I can take another look.07:24
chriadamflypig: yes, kcalcore MR#19 and nemo-qml-plugin-calendar MR#6107:25
chriadamjpetrell: can you expand a bit on that regarding the time picker dialog?07:25
chriadampvuorela: did you have any issues with the function naming in nemo-qml-plugin-calendar MR#51 (start time in event timezone etc exposed in event), or anything else?  Or is it good to go?07:26
flypigMR#19 already LGTM. Sorry dcaliste for making you suffer my comments on it.07:26
jpetrelldcaliste mentioned time zone picker could fit nicely time picker dialog so when you pick time you can also choose the reference point / time zone07:27
flypigAnd thanks for your helpful explanation.07:27
jpetrellwould not like to add new things to calendar event dialog, e.g. we will need to add attachment picker there at some point07:28
dcalistejpetrell, yes I agree, if we can avoid to add new combo / entries in the EventEditDialog, that would be great !07:28
dcalisteAs you said, for the time zone MR, it would require to add a TZ combo at the bottom of the time picker.07:29
dcalisteBut this require modifications to silica, and at first I think it was to invasive.07:29
dcalisteAnd was afraid that will make the MR rejected.07:30
chriadamdoes dcaliste have access to the appropriate silica repo for that, or is that something we would have to do?07:30
dcalisteYes, I have access to theis repo.07:30
dcalisteThere is a design issue also with this (because at home I indeed tried to modify it already…) :07:30
jpetrelldcaliste: TimePickedDialog is just Dialog { TimePicker {}}, can make own dialog i.e. Dialog { Column { TimePicker {} TimeZonePicker {}}07:30
dcalisteon landscape orientation, I don't know where to put the zone combo.07:31
jpetrelloh true that is a bit tricky (clock doesn't turn landscape on phone and on tablet there is plenty of space in landscape)07:32
dcalistejpetrell, you're right, remembering it I hacked it like that during first tries.07:32
dcalistejpetrell, yes for clock, but calendar is rotating on phone.07:32
dcalisteAnd on phone (and particularly on lastest elongated form-factor), there is no space below the time wheel.07:33
dcalisteAt least on my JollaC, there is already no space :(07:33
dcalisteMoving the wheel to the left and add a combo on the right, like a two colomn thing looks ugly in my opinion.07:34
pvuorelapong, joined the party here.07:35
dcalisteflypig, thank you the review, don't worry for the comments, it's always better to ask. Questions are always relenvant.07:36
pvuoreladon't have any complaining myself on the timezone stuff. was planning on doing a final round and then getting it in.07:36
jpetrelldcaliste: this is how clock does it http://www.joona.net/clock_timerdialog_landscape.png07:36
pvuorelathe timepicker alternative could be actually tricky in the sense that event has start and end time and we probably want to keep them in the same zone.07:37
jpetrellso the footer content is either anchored to the bottom or right side of time picker07:37
jpetrellpvuorela: but event (like trip) may start in different country and end in another07:38
dcalistepvuorela, thanks, but the question of adding more wdgets is still under debate it seems. Would be nice to find a way not to add too many things there.07:38
jpetrellif you don't specify end time time zone it could automatically follow start time time zone07:38
pvuorelajpetrell: yes, it's an allowed thing by the spec but supporting that might have needless complication. e.g. then we need to show both in the main calendar editor anyway.07:39
jpetrellpvuorela: well only if they differ07:39
dcalisteIn QML binding, there is no problem to have different timezones for start and end, so at least on the implementation side, it's ok.07:39
jpetrellsimilarly if time zone is the same as systems no need to show time zone info07:40
dcalistejpetrell, to go in pvuorela direction, there is also the issue of display in the editor: in the time picker implementation, then we need to write CEST or what ever timezone name somewhere.07:40
dcalisteWe have space to do it, but we don't have these shorter names easily available I think ? Or do we ?07:41
jpetrellthat is true, the current "starts/ends" item is tiny07:41
dcalisteAnd, often people don't know their meaning anyway, while with the combo it's written Paris time, which is easily understandable for everyone.07:41
jpetrellok I am also leaning toward having it in main calendar dialog since you need an item there anyways to show differing time zone07:43
jpetrelland the different time zones for start and end is kind of edge case07:43
jpetrelllooks like most platforms provide only one time zone option in event dialog07:44
jpetrellcalendar event dialog would benefit from some landscape optimization07:45
dcalisteYep, and about adding more stuff there, I've got some initial implementation of timed reminders which could be convenient for all day events to set a reminder at 18.00 two days before for instance, but this is adding yet another combo in the editor dialog…07:46
dcalisteThere is no MR yet though, I was waiting for the previous reminder MR about displaying unsupported duration to enter first to avoid too many conflicts on my side.07:47
chriadamsorry which repository is that MR?07:49
dcalisteIt's the jolla-calendar one.07:49
dcalistepvuorela recently accepted it,.07:49
dcalisteIt was MR#26507:50
dcalisteYou still cannot select arbitrary value though…07:50
chriadamok, so what was the result from the above discussion: are we all happy with merging those two MRs (nqpc#51 + jolla-calendar#252) as-is, or are there some changes required still?07:51
dcalisteThe timed value is easier to implement, that's why I started with this, custom reminder still need more thoughts from a design point of view at least.07:51
dcalisteBut diverging, about the timezone MRs, I think pvuorela and jpetrell agree on the current implementation. But I let them answer ;)07:52
chriadamI think that was the case too.  pvuorela are you happy to do the merge/tag of those ones, then?07:53
pvuorelayes, no complaining. i'll still do that check so cannot promise yet i'll approve it, but likely will :)07:53
chriadamthank you07:53
chriadamok, on the other one (sync errors): I pinged MartinS again to check the comment you made on jolla-calendar PR#26607:54
flypigAm I safe to merge MR#19 and MR#61 independent of all this?07:54
chriadamfrom my perspective, yes - so long as pvuorela is ok with the naming of those event start time in tz methods etc07:54
chriadamI was/am happy with both of those07:54
chriadam(haven't yet looked at the related caldav buteo PR, however, but that's separate / can wait I think)07:55
dcalistechriadam, about the buteo MR, I've been using it daily without issues at the moment for several weeks. I'm adding unit tests at the moment.07:56
dcalisteMay take some more days / few weeks if I put the QMF migration as a priority though ;)07:57
chriadamindeed, thanks07:59
chriadamok, were there any other PRs to discuss, or other topics?08:00
chriadamOh, I saw another jolla-calendar PR08:01
chriadamthe time span labels for multi-day events08:01
pvuoreladcaliste: excellent that you've started looking into qmf/qt6!08:02
dcalisteYes, other MRs are mainly cosmetic but annoying me !08:02
chriadamjpetrell: have you had a chance to look at that one (jollca-eldnar PR#264)?08:02
pvuorelahope it gets easier at some point.08:02
dcalistepvuorela, yes but it could be long.08:02
flypigIs https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/267 still alive?08:03
chriadamhrm, interesting one.08:05
chriadamI outsource all of my focus knowledge to andrew :-P08:06
pvuorelaas commented there, it's tricky and wouldn't necessarily want to have page specific handling.08:07
jpetrellchriadam: not yet, but I trust pvuorela's judgement on time formatting topic, he understands localization better :)08:08
chriadamI guess that PR#264 was one which pvuorela was going to check again soon08:10
chriadampvuorela: on the one hand, I agree in principle.  but in practice, if this is a pain point for many users, maybe worth making an exception?08:11
dcalisteAbout the multi-day formatting, having 12.30-23.59 or 12.30- looks not nice in my opinion, but having it with text may not be convenient for every languages…08:11
chriadamregarding 267 here I mean ^08:11
flypigFor #267 is the status that the behaviour is good, but the implementation needs looking at more?08:12
dcalistechriadam, yes indeed thanks ;) I'm always closing the keyboard when editing an event.08:12
pvuorelachriadam: also an option, but would be still nice to investigate the common solution.08:13
chriadamcan you elaborate a bit on how you envisage such a common solution might work/look?08:14
chriadamis this some hint to vkb about how to react to focus changes or so?08:14
pvuorelafrom the top of my head, one option could be some page status handling for removing focus, that's at least on one place, but then again it prevents using hardware keyboards when coming back. then again do we want to support focus but no vkb requested, dunno.08:18
pvuorelathere is already softwareInputPanelEnabled property, controlling whether focus asks for vkb, but that's for a generic case.08:19
dcalistepvuorela, ah, indeed making the focus lost for hardware keyboard, is not nice inded. That's a good point making search for a better option desirable.08:21
dcalisteBut I'm afraid it's out of my competences at the moment :/08:21
pvuorelaqwdiget side has focus reason passed, if we had that it could be used to alter behavior, but recall qtquick focus doesn't have such.08:22
dcalisteOk, that's a valid enough reason for me (the hardware keyboard stuff) not to accept #367 as is. Indeed, I can live with closing the vkb by hand a bit more ;)08:24
dcalisteNot that far yet.08:25
dcalistechriadam, jpetrell, flypig and pvuorela, thanks for the discussion today and the advance in various topics at hand. I need to go soon to the physiotherapist and will have to leave in 5 minutes.08:27
chriadamthank you for your time and efforts, dcaliste08:27
chriadamas always, greatly appreciated08:27
chriadamI think we made some good progress today, and will see some of those MRs being merged shortly I hope08:27
chriadamI hope your physio appt goes well!08:27
chriadamwill see you next week :-)08:27
pvuoreladcaliste: thank you, good stuff happening!08:27
flypigThanks dcaliste.08:27
dcalisteThank you also for your time and considering all my MRs ! My hand is slowly but consistently recovering, so everything's fine.08:28
dcalisteHave a nice week.08:28
flypigYeah, glad to hear it. Good recovery.08:29
chriadamthanks to everyone for helping also08:30
chriadamwith PRs and reviewing etc.  much appreciated.08:30
niqoscan the autorithy (police, government) make wiretapping pushing on a jolla device using android malware or need an sailfish malware?09:26
ggabriellong story short: in most cases, yes09:27
ggabriel(you don't need any of the conditions in your OR statement)09:28
*** frinring_ is now known as frinring11:15
attahcoderus: Have you seen mb2 and sdk-assistant claiming to not have any targets inside Docker? (only version shows up)18:57
attahTrying to split your yaml file to a named Docker step in its own repo18:57
coderusattah: probably you trying to use -base image instead of normal image with preinstalled targets20:19
attahHmmm, but it does work locally with the same Dockerfile20:20
attahi.e. this https://github.com/attah/buildfish/blob/master/Dockerfile20:20
Nico[m]Are you sure you are running as the nemo user? I'm not sure if dockerfiles keep the same user or default to root20:43
Nico[m]Ah, looks like they should be20:45
attahNoted, will check, tomorrow21:09

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!