Re: [SailfishDevel] CalDAV/CardDAV Contributor Meeting

[Chris Adams]

Hi,

I'd forgotten that the 1st of May was Vappu / May Day holiday in Finland and 
Australia.
Let's reschedule for the 8th of May (this coming Monday) at 0900 UTC.

I am very sorry for the confusion.

The agenda may be found at 
https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#08.2F05.2F2017_Meeting

Best regards,
Chris.



From: Devel [devel-boun...@lists.sailfishos.org] on behalf of Chris Adams 
[chris.ad...@jolla.com]
Sent: Tuesday, April 11, 2017 4:05 PM
To: Sailfish OS Developers
Subject: Re: [SailfishDevel] CalDAV/CardDAV Contributor Meeting

Hi everyone,

My apologies for being disorganised and forgetting to send the email about the 
next CalDAV/CardDAV Contributor meeting.  Things have been busy with getting 
features and bugfixes ready for the 2.1.1 development branching.

Let's skip the April meeting and instead plan to have the next one on Monday 
the 1st of May 2017 at 0900 UTC.

Activity for the last month can be summarised by saying: I merged all of the 
outstanding PRs for CalDAV.  Big thanks to the contributors!  Some fixes for 
CardDAV are still not merged, and require more testing before I will be able to 
merge those.

If anyone out there is keen to start contributing, please see 
https://bugs.merproject.org/show_bug.cgi?id=1751#c2 for some possible tasks, 
see 
https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#Development_With_The_Sailfish_OS_Application_Developer_SDK
 for information on how to get a build environment, and get in contact with me 
via Email or IRC if you need help or have any questions :-)

Thanks and sorry again for being disorganised this month!

Cheers,
Chris.


From: Devel [devel-boun...@lists.sailfishos.org] on behalf of Chris Adams 
[chris.ad...@jolla.com]
Sent: Monday, March 13, 2017 8:28 PM
To: Sailfish OS Developers
Subject: Re: [SailfishDevel] CalDAV/CardDAV Contributor Meeting

Hi everyone,

Thanks to those who were able to attend the meeting, and to everyone who 
contributed during the last month :-)

Brief summary of meeting:

1) Reviews appreciated on the three outstanding PRs (MER#1751, MER#1727, 
MER#1646).  chriadam will merge the first two soon.
2) dcaliste to look into adding a unit test for MER#1646.  chriadam to build a 
package based on (rebased) 1646 PR, and ask on TJC for testers to help test.
3) chriadam to look into nginx filter rules to allow reproing MER#1624 (but may 
not get a chance for a couple of weeks, probably)
4) Raise TODOs and other feature support investigations at the next meeting
5) New contributors: MER#1751 has a couple of open issues remaining, and one of 
those would be very suitable for a new contributor to investigate - ping me if 
you would like to get involved with development :-)  See 
https://bugs.merproject.org/show_bug.cgi?id=1751#c2 for details!
6) Ijo to continue triaging TJC especially once 2.1.0 is released with the fix 
for for the "upsync fails" issue which was partially tracked by MER#1699.
7) See if dcaliste can reproduce the original "calendars lost" issue from 
MER#1699 again after patch and report.

The next meeting will either be held on the 3rd or 10th of April at 0900 UTC, 
depending on when the Sailfish OS Community Meeting in April is scheduled for 
(will find out after the 15th of March I guess).  I will send an email toward 
the end of this month confirming the details.

Best regards,
Chris.


From: Devel [devel-boun...@lists.sailfishos.org] on behalf of Chris Adams 
[chris.ad...@jolla.com]
Sent: Thursday, March 09, 2017 3:56 PM
To: Sailfish OS Developers
Subject: Re: [SailfishDevel] CalDAV/CardDAV Contributor Meeting

Hi everyone,

Just a reminder that the next Sailfish OS Community CalDAV/CardDAV contributor 
meeting will be held this coming Monday the 13th of March at 0900 UTC.

As always the agenda can be found on the wiki, at 
https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#13.2F03.2F2017_Meeting

The focus of this meeting will be figuring out concrete steps required to get 
any currently outstanding PRs merged, and after that we will discuss 
outstanding bugs as per usual.

To summarise activity from the last month or so:

Jolla currently has high priority on MDM work, so time I can spend on 
CalDAV/CardDAV is limited.  I have  PR to fix some bugs in the CardDAV plugin 
related to sync with Kerio, however there is more to be done there: MER#1751.  
I also fixed a bug in the CalDAV plugin thanks to investigation by community 
members on TJC, MER#1699 (note: it is possible that the original report is a 
different issue than what was reported on TJC - I need to talk to dcaliste to 
confirm whether or not that's the case).

Erik has provided a fix plus unit test for MER#1727 which LGTM I just need to 
test/merge/tag it.

Damien's fix for MER#1646 is still waiting for my review (is it ready for 
review and merge?  

Re: [SailfishDevel] Qt Network: "Network access is disabled" after network change

[Slava Monich]

Here, I copied the most interesting parts from the bug:

Basically, QNetworkAccessManager is sometimes stuck in NotAccessible 
state after switching from mobile data to wifi.


Among other things, it makes QNetworkAccessManager::get () to fail with 
QDisabledNetworkReply which breaks XmlListModel as some people have noted.


Qt 5.2 had a similar problem but this helped:

https://git.merproject.org/mer-core/qtbase/merge_requests/3

Unfortunately, Qt connman bearer plugin has significantly changed in Qt 
5.6 and this trick stopped working.


When the switch (between mobile and wifi) is happening, the action 
occurs in parallel on two threads, Qt bearer thread and the main thread, 
the signals are queued, although the main thread is fetching the current 
state directly from the objects being manipulated by the bearer thread. 
My theory was that configurationChanged, onlineStateChanged and 
networkSessionStateChanged (queued) signals from the past were getting 
mixed with the current state (which was checked directly) in such a way 
that QNetworkAccessManagerPrivate online state remained false even 
though connman service was getting successfully connected. So I came up 
with this:


https://git.merproject.org/mer-core/qtbase/merge_requests/18

but that didn't quite fix it. It does eliminate one scenario (described 
in the merge request) but there must be something else there. The whole 
connman bearer plugin thing looks generally prone to race conditions, I 
would've done it differently but we have what we have.


Cheers,
-Slava



Thanks for the quick reply;
I was actually hoping to collect some more background intel on this issue.


On Sun, Apr 30, 2017 at 10:56 PM, Slava Monich > wrote:


Unfortunately, no, it's an internal bug. If you would like to be
notified via email about a potential fix, you could watch qtbase
pull requests - those are quite rare, it shouldn't be too much of
a spam.

Cheers,
-Slava




Hi Slava;
is there a MER bug for this?

tortoisedoc

On Sun, Apr 23, 2017 at 11:33 AM, Slava Monich
> wrote:

Network status detection in Qt 5.6 is unreliable when the
system is switching between wifi and mobile data. That
results in QNetworkAccessManager sometimes thinking that
network access is disabled when in fact the device is online.
At some point I attempted to fix it
(https://git.merproject.org/mer-core/qtbase/commit/8122f32a
)
however that only eliminated one particular scenario of
failure and reduced the probability. But it's still
happening. As I understood it's a random thing (race
condition) triggered by two connman services changing their
status more or less simultaneously.

Jolla's Weather app also uses XmlListModel and suffers from
the same issue.

Nobody at Jolla is actively working on it at the moment, our
resources are limited these days. If somebody has an idea how
to fix it, feel free to submit a pull request against mer-5.6
branch
(https://git.merproject.org/mer-core/qtbase/commits/mer-5.6
).

Best regards,
-Slava


Hi,

The same happens in my Rush hour app available in
OpenRepos. My only connection to network is via
QtQuick.XmlListModel 2.0. I am using Jolla C and the
latest Iijoki 2.1.0.11

https://github.com/Rikujolla/trafficviewer/issues/2


Best regards, Riku

Sebastian Wolf kirjoitti sunnuntai 23. huhtikuuta 2017:

Hi colleagues,
  some users of my application Piepmatz are reporting
network issues when their
device network connection changes from WiFi to
Cellular and vice versa. I
couldn't reproduce it so far with my FP2 on 2.0.5. As
I'm only using standard Qt
Network classes to access the internet and no own
network detection and
especially that not only my application is affected,
it could possibly be
something in 2.1 itself. For some details see GitHub
issue
https://github.com/Wunderfitz/harbour-piepmatz/issues/11

  Didn't find anything with a quick search on
together.jolla.com , so
does somebody
of you know something about such an issue?
  Thanks for any hints and best 

Re: [SailfishDevel] Qt Network: "Network access is disabled" after network change

[Tone Kastlunger]

Thanks for the quick reply;
I was actually hoping to collect some more background intel on this issue.


On Sun, Apr 30, 2017 at 10:56 PM, Slava Monich 
wrote:

> Unfortunately, no, it's an internal bug. If you would like to be notified
> via email about a potential fix, you could watch qtbase pull requests -
> those are quite rare, it shouldn't be too much of a spam.
>
> Cheers,
> -Slava
>
>
>
> Hi Slava;
> is there a MER bug for this?
>
> tortoisedoc
>
> On Sun, Apr 23, 2017 at 11:33 AM, Slava Monich 
> wrote:
>
>> Network status detection in Qt 5.6 is unreliable when the system is
>> switching between wifi and mobile data. That results in
>> QNetworkAccessManager sometimes thinking that network access is disabled
>> when in fact the device is online. At some point I attempted to fix it (
>> https://git.merproject.org/mer-core/qtbase/commit/8122f32a) however that
>> only eliminated one particular scenario of failure and reduced the
>> probability. But it's still happening. As I understood it's a random thing
>> (race condition) triggered by two connman services changing their status
>> more or less simultaneously.
>>
>> Jolla's Weather app also uses XmlListModel and suffers from the same
>> issue.
>>
>> Nobody at Jolla is actively working on it at the moment, our resources
>> are limited these days. If somebody has an idea how to fix it, feel free to
>> submit a pull request against mer-5.6 branch (
>> https://git.merproject.org/mer-core/qtbase/commits/mer-5.6).
>>
>> Best regards,
>> -Slava
>>
>>
>> Hi,
>>>
>>> The same happens in my Rush hour app available in OpenRepos. My only
>>> connection to network is via QtQuick.XmlListModel 2.0. I am using Jolla C
>>> and the latest Iijoki 2.1.0.11
>>>
>>> https://github.com/Rikujolla/trafficviewer/issues/2
>>>
>>> Best regards, Riku
>>>
>>> Sebastian Wolf kirjoitti sunnuntai 23. huhtikuuta 2017:
>>>
 Hi colleagues,
   some users of my application Piepmatz are reporting network issues
 when their
 device network connection changes from WiFi to Cellular and vice versa.
 I
 couldn't reproduce it so far with my FP2 on 2.0.5. As I'm only using
 standard Qt
 Network classes to access the internet and no own network detection and
 especially that not only my application is affected, it could possibly
 be
 something in 2.1 itself. For some details see GitHub issue
 https://github.com/Wunderfitz/harbour-piepmatz/issues/11
   Didn't find anything with a quick search on together.jolla.com, so
 does somebody
 of you know something about such an issue?
   Thanks for any hints and best regards, Sebastia

>>>
>> ___
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
>> shos.org
>>
>
>
>
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
>
>
>
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe@lists.
> sailfishos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org