| *** zbenjamin_ is now known as zbenjamin | 02:27 | |
| *** frinring_ is now known as frinring | 02:37 | |
| tmynttin | Are the tab headers in the phone app of 3.2.1 a (known) issue? They are oddly positioned and do not respect os font size. | 08:07 |
|---|---|---|
| chriadam | by oddly positioned, if you mean "right-aligned" then yes, that's actually intentional | 08:10 |
| chriadam | but the os font size issue sounds like a bug ^ jpetrell | 08:11 |
| chriadam | hi dcaliste | 08:11 |
| chriadam | I hope you had a good week | 08:11 |
| dcaliste | Hello chriadam, sorry to be late today. | 08:11 |
| chriadam | no problem at all | 08:11 |
| dcaliste | I'm reading your remarks on mkcal!30 | 08:12 |
| chriadam | just minor, probably I misunderstood what sets the rv int | 08:13 |
| dcaliste | I'll answer more thouroughly later today, but rv is used in the macros they have defined to wrap sqlite calls. | 08:13 |
| chriadam | yep, figured might be something like that | 08:13 |
| dcaliste | If I remember correctly. | 08:13 |
| tmynttin | Ok. To me the right alignment seems a bit ugly. I think it used to be prettier in earlier versions | 08:13 |
| chriadam | I saw at least one other place where the rv wasn't set explicitly but used afterwards, so I figured it was some macro magic somewhere | 08:13 |
| chriadam | but wasn't sure, thought I'd check | 08:13 |
| dcaliste | In the macro, I think it is set unconditionaly. | 08:13 |
| dcaliste | like rv = sqlite_bla_bla(); if (rv != no error) goto error. | 08:14 |
| chriadam | tmynttin: the UX designers have their reasons, I guess. | 08:14 |
| chriadam | dcaliste: indeed | 08:14 |
| dcaliste | pvuorela would like to remove these macros and rewrite a bit the whole sqlite part without macros and variable sets without seeing them set. It makes sense, it's lower in my todo list though… | 08:15 |
| dcaliste | I need to figure out what is wrong with this quickly : https://together.jolla.com/question/219312/321-new-caldav-calendars-not-syncing-anymore-xa2 | 08:17 |
| dcaliste | I cannot reproduce for the moment, I hope the reporter will send me the failing ICS data. But trying to reproduce on caldav master, I'm obtaining another issue with exception that are reappearing. Feeling bad ! | 08:18 |
| dcaliste | I need to investigate this quickly. | 08:18 |
| chriadam | not to worry, our testers didn't find those issues themselves | 08:19 |
| chriadam | thank you for investigating those | 08:19 |
| chriadam | would be good if we could add repro instructions using an internal nextcloud server or something to our internal test case asset so that testers can ensure things don't regress in future, but not sure our testers have the bandwidth currently for such work unless it's wanted from our corporate customers unfortunately | 08:20 |
| chriadam | dcaliste: I will merge the mkcal PR tonight, along with your caldav PR for the purge support | 08:22 |
| dcaliste | Yes, thank you. | 08:22 |
| chriadam | flypig was working on implementing email folder sync support for other backends (including exchange) so I think he might have some questions for you about that this week? not sure | 08:22 |
| chriadam | or maybe he already contacted you | 08:22 |
| dcaliste | Sure, I'm available this week. | 08:23 |
| chriadam | thanks, I've just pinged him to ask, in case he had something, or whether I was mistaken | 08:24 |
| dcaliste | I find the buteo-syncfw QML binding quite convenient to follow what is appending with the caldav sync. In one glance, I can see if there was an issue in sync like I know I've modified one event upstream and I see it in the log. | 08:27 |
| chriadam | well, I guess he must have stepped away from his keyboard for the moment | 08:27 |
| dcaliste | What do you think of it ? | 08:27 |
| chriadam | conceptually, I agree it's important, and that we should add support for viewing such information to the UI | 08:27 |
| dcaliste | He can ping me whenever he want this morning, tomorrow all day and Thursday also. | 08:27 |
| chriadam | currently, I don't think there's any concrete plan for adding this to the UI yet - need to discuss with jpetrell about how to get such feature added to roadmap | 08:28 |
| chriadam | and I have yet to check the PR. I will add Bea to that one also. | 08:28 |
| dcaliste | Thanks, the most important part is the QML API. After, we can have a separated app in store to view logs waiting for UI inclusion in a proper manner. | 08:29 |
| dcaliste | It's something (the QML bindings) we can discuss in the coming weeks (months) to polish it so it be merged at one point. | 08:30 |
| dcaliste | As mentioned in the MR discussion, there are various things to agree on : like inside Buteo or in a separate package, With changes or not to the API of the SyncLog and SyncResults… | 08:31 |
| chriadam | yep, definitely | 08:31 |
| chriadam | translatable error strings also, or how to expose some stuff to user visible ui | 08:31 |
| flypig | dcaliste, chriadam, was away, missed your message. dcaliste, I do have a query about folder sync if I may? | 08:32 |
| dcaliste | Exactly. And for a longer term, should we keep this read-only or should we make it possible to update the sync profile ? This would be then redundant with some parts in sailfish-component-accounts… | 08:33 |
| dcaliste | flypig: sure, go ehead. | 08:33 |
| chriadam | dcaliste: wow, seems like some nice cleanup done also as part of that PR (ensuring consistent use of error codes etc). great work. definitely look forward to progressing this one further after christmas break | 08:33 |
| chriadam | dcaliste: long term, offering a consistent QML api makes sense, IMO. sailfish-components-accounts exists as implementation detail, nothing more.. | 08:34 |
| chriadam | so, adding write capability also is a worthy goal | 08:34 |
| chriadam | but can look at that later on I guess :-) | 08:34 |
| chriadam | flypig: no worries, please do | 08:35 |
| flypig | Thanks :) So, first question, I was wondering about your choice to integrate the configuration with buteo, rather than nemo-qml-plugin-email. | 08:36 |
| flypig | Second question, it seems to me that the synchronizationEnabled flag is currently strict: turning it off makes it impossible to sync a folder (e.g. through the pulley menu of that folder). So I will make it weaker so it only applies to full syncs. Do you see any problems with that. | 08:36 |
| flypig | For the first question, just to be clear, it's not a criticism, just a genuine query. | 08:37 |
| dcaliste | chriadam: about sailfish-component-account, this is not retiring this one, because we still need bindings for libaccount, but it would move (rewrite due to license) the buteo profile out of it. But it's long term indeed. | 08:38 |
| dcaliste | About having buteo QML having write possibilities, would make the current naming a bit messy : I've called it called SyncProfileWatcher :/ | 08:39 |
| dcaliste | Need to think to something else… | 08:39 |
| dcaliste | flypig: about the email sync folder you mean ? | 08:40 |
| flypig | dcaliste, yes, sorry, should have been clearer. Both questions concern folder sync. | 08:40 |
| dcaliste | Because in my opinion, it is a sync property : you want the automatic sync to look at certain folders. | 08:40 |
| dcaliste | The manual sync (driven by the UI) is still using the nemo QML bindings. | 08:41 |
| flypig | Yes, makes sense. But currently the config changes filter down and apply to all syncs, yes? | 08:41 |
| dcaliste | I prefered to keep the nemo bindings generic and specialise in buteo for the previously mention reason. | 08:41 |
| flypig | There are two sides to this: what the user understands the config options to do, and what is the correct code structure (which the user doesn't care about). | 08:42 |
| dcaliste | About the second question : ah it's something I didn't notice when investigating using this flag to schedule certain folders only. | 08:42 |
| dcaliste | That's bad indeed that it is changing non automatic sync behaviour. | 08:43 |
| dcaliste | I was thinking that this flag was used only when asking for sync, if you ask for a specific folder, it is synced anyway. | 08:44 |
| flypig | I don't necessarily think that's bad. If I do a sync from the accounts menu, or the combined inbox, it may be reasonable for the user to expect this behaviour. | 08:44 |
| dcaliste | But the UI is asking for sync in general when you long press on an account, that's the issue, right ? | 08:44 |
| flypig | There are, I think, at least four different sync mechanisms. | 08:45 |
| dcaliste | Or I thought the UI was triggering an inbox sync only when choosing 'sync' from long press or pulley. | 08:45 |
| flypig | Long press on account; timed sync; "always-on" sync, combined inbox; specific folder. | 08:45 |
| flypig | Sorry, that's five! | 08:45 |
| dcaliste | Ok, let's review them, I agree so it's clear for both of us. | 08:45 |
| dcaliste | Ok, I'm looking in the ocde which routine they are triggering… | 08:46 |
| flypig | Intuitively, I expect the first four to respect the folder sync settings. | 08:46 |
| dcaliste | Mmh, yes I gree. | 08:47 |
| dcaliste | Which finally would have make sense to put the flag assignment logic in nemo bindings ;) | 08:48 |
| flypig | Well, possibly, but that's why the question arose. | 08:48 |
| flypig | It's messy. They start at "EmailAgent::synchronize" or "EmailAgent::synchroniseInbox", or in the last case "EmailAgent::retrieveMesssageLists" | 08:48 |
| flypig | But they all end up going through "qmf/plugins/imap" ImapServiceSource::retrieveMessageList | 08:49 |
| flypig | It's a bit unfair to throw this at you without warning, but does that look right to you? | 08:51 |
| dcaliste | Yes, and underneath, I think it's going to reach QMailActionRetrieval, right ? with tye synchronize method or the retrieveMessages one ? | 08:52 |
| dcaliste | flypig: it's ok, no worry, I digged into this some months ago now, but I still remember some parts. | 08:53 |
| dcaliste | I'm looking into the imap plugin, because it's the part that I master less :/ | 08:53 |
| dcaliste | Well, going back to email agent, there are ::synchronize() which is triggering a synchronize action, and ::synchronizeInbox() which trigger a RetrieveMessageList action. | 08:55 |
| dcaliste | In execute, the Synchronize action, is calling retrievalAction->synchronize(), while retrieve message list is calling retrievalAction->retrieveMessageList(). | 08:57 |
| dcaliste | Now, looking into qmailserviceaction… | 08:57 |
| flypig | It's a bit obfuscated by the queuing, signals and services. | 08:59 |
| dcaliste | Yeh, I agree. | 08:59 |
| flypig | I ended up, in all cases, at an "emit QMailMessageServerPrivate::retrieveMessageList(... folderId...) | 09:00 |
| dcaliste | So, the synchronize call in qmailserviceaction, it calling a QMailRetrieveMessageListCommand, that may be filtered by the flag (or not, checking). | 09:00 |
| dcaliste | flypig: ok, I agree, and we end up in a ImapRetrieveMessageListStrategy, right ? | 09:06 |
| *** gigetoo_ is now known as gigetoo | 09:11 | |
| *** tobbez_ is now known as tobbez | 09:11 | |
| *** mp107_ is now known as mp107 | 09:11 | |
| *** imdeni_ is now known as imdeni | 09:11 | |
| *** timeless_ is now known as timeless | 09:11 | |
| dcaliste | flypig: which itself is always checking for the falg to be set, whatever the caller, so the "manual" triggering of a folder is not working then. | 09:11 |
| dcaliste | That's the issue, right ? | 09:11 |
| flypig_ | Yes, exactly. The flag is tested in imapstrategy.cpp. ImapFolderListStrategy::nextFolder() | 09:12 |
| dcaliste | I see, indeed. | 09:12 |
| flypig_ | I discussed with pvuorela_, and we both agree that relaxing it for full syncs (where the folderId is invalid) would make sense. | 09:14 |
| flypig_ | But we're not 100% sure this won't have side effects. | 09:15 |
| dcaliste | Which raises the question, how to properly correct this… should we overload the nextFolder() to ignore the flag when accountFolderIds is all, or something else… | 09:15 |
| dcaliste | Ah, same idea ;) | 09:15 |
| flypig_ | Yes :) | 09:15 |
| dcaliste | But same concerns… | 09:15 |
| *** yofuh_ is now known as yofuh | 09:15 | |
| dcaliste | Side effects is highly possible here, as we can see for this synchronization flag… | 09:16 |
| flypig_ | Yes, there's a lot going on, and it's hard (at least for me) to get a full picture. | 09:16 |
| dcaliste | I cannot answer now of course. I'll review this possibility and try to figure out a failing case, or not before next Thursday. | 09:17 |
| flypig_ | Of course, I totally appreciate. | 09:18 |
| flypig_ | Would you be happy for me to commit an overloaded nextFolder() to try out, and give me your thoughts? | 09:18 |
| flypig_ | The nice thing with your overload suggestion is that it can be assigned to only apply to message retrieval, and not the other cases where nextFolder() is called. | 09:18 |
| dcaliste | It's hard for me also to follow all possibilities in this code. All files are very long with a lot of entry points. But yeh, more eyes cannot hurt the cause. | 09:19 |
| dcaliste | flypig_ indeed, go ehead, I'll review what you can propose. And indeed, the overload would kind of limit the spread of the modifications. A little… | 09:19 |
| dcaliste | s/ehead/ahead/. | 09:20 |
| flypig_ | Great, thank you. Perhaps you could also ping me if you have further thoughts on it? | 09:20 |
| flypig_ | As I look through the code I'm repeatedly reminded of how poor my understanding of this is compared to yours. | 09:20 |
| dcaliste | Sure, I'll keep IRC up for the next two days. After, I'll be on vacation leave (from IRC at least ;), but I'll read my emails. | 09:21 |
| dcaliste | Oh, I'm not at all feeling confident with this code neither ! | 09:21 |
| flypig_ | I'm amazed at how many layers there are to triggering an email sync ;) | 09:22 |
| flypig_ | Thank you! Let's leave this here then, so you can carry on your meeting with chriadam. | 09:22 |
| dcaliste | The qmailmessage part is fine, but the part related to message server is terrific. | 09:22 |
| flypig_ | The EAS stuff has the benefit of having an extra sailfish-eas layer as well. | 09:23 |
| dcaliste | flypig, thank you for dealing with the mess implied by my changes ;) I'll review your proposition and try to be a bit more confident with its success. | 09:23 |
| flypig_ | dcaliste, not a mess at all. As long as there are no side-effects with this approach, then I think it'll work out nicely. | 09:24 |
| chriadam | thanks :-) | 09:24 |
| chriadam | I'm not sure there is more to discuss on our side. I will merge the mkcal and caldav PRs. I will discuss further with pvuorela about the "extra day" PRs to get us closer to upstream. | 09:25 |
| chriadam | was there anything else which requires action from my side this week? | 09:25 |
| dcaliste | chriadam: yes, thank you. I'll try to figure out the initial sync regression noticed on TJC from my side, and the one I notice trying to debug it… | 09:26 |
| dcaliste | When you have time, with jpetrell and pvuorela and Slava Monic also, you can comment on the design decisions for the Buteo QML bindings. | 09:27 |
| chriadam | yes, I will discuss with Bea tomorrow | 09:27 |
| dcaliste | Sure, and Bea sorry. | 09:27 |
| chriadam | thanks for spending the effort to implement that! and for your practivity with investigating those caldav issues. your time and effort is much appreciated as always! | 09:27 |
| dcaliste | And, thanks for the Google account quick fix ;) | 09:27 |
| chriadam | I won't be here next week - heading away for a week over Christmas | 09:28 |
| chriadam | heh. | 09:28 |
| dcaliste | Ah, yes, I wanted to say, that the next two Tuesday, I'll be off. | 09:28 |
| chriadam | yep, figured that might be the case - I hope you have a great christmas break | 09:28 |
| dcaliste | I'll read my emails, and keep an eye on git and TJC, but won't be able to have this meeting. | 09:28 |
| chriadam | yep, please ignore any emails or PRs over your holiday! I will see you in 3 weeks :-) | 09:29 |
| dcaliste | In addition, I'll have a full day meeting at work the 7th. | 09:29 |
| chriadam | ok, 4 weeks ;-) | 09:29 |
| dcaliste | So maybe next meeting will be January the 14th, indeed. | 09:29 |
| chriadam | sounds good :-) | 09:29 |
| chriadam | see you then! | 09:30 |
| dcaliste | Have a nice Christmas period and summer vacations if you have. | 09:30 |
| chriadam | thanks, will do | 09:32 |
| * chriadam -> home, gnight | 09:32 | |
| ol | Any updates on Aptoide situation? Is it still unsafe to use it? | 14:06 |
| mal | https://together.jolla.com/question/217843/release-notes-321-nuuksio/#217843-update-version-history | 14:07 |
| ol | mal (IRC): Yes, I'm asking about this: "Aptoide is working on this to get the issues eliminated". The last update was from last Thursday, so I'm wondering whether the issue is already resolved or not. | 14:09 |
| mkolman_ | I wonder how this came about - did they hijack some update built-in update functionality in the Aptoide app itself ? | 15:38 |
| mkolman_ | or was modified Aptoide submitted to Jolla store ? | 15:39 |
| mkolman_ | still not really a good situation, given how long this has been dragging on | 15:39 |
| flipper-maniac | last message I saw from jolla is that aptoide needed to be abandoned asap | 16:32 |
| *** Dakon_ is now known as Dakon | 17:40 | |
| * attah starts XA2 for making app screenshots | 19:54 | |
| attah | #justlongphoneproblems | 19:54 |
| attah | Any hint on how i might track down 2GB random "system files", that are blocking upgrading? All info just seems to deal with user files... | 20:53 |
| mal | attah: from commandline you could use "du -hs /*" and then individually check the subfolders that look very big | 21:23 |
| palebluesky | hey | 21:25 |
| attah | mal: hmmm, nothing that really sticks out | 21:28 |
| attah | oh | 21:31 |
| attah | wrong device | 21:32 |
| attah | as a semi-defence i didn't manage to free up any meaningful space on it either | 21:33 |
| mal | attah: which device is that? | 21:37 |
| mal | and where do you get the error? | 21:37 |
| attah | XA2 (having issues), but i was accidentally logged in to my longphone | 21:38 |
| mal | at which point do you see the message about space? | 21:38 |
| attah | Just before executing the install | 21:38 |
| attah | but the update is downloaded | 21:39 |
| mal | show output of "df -h" | 21:39 |
| attah | https://pastebin.com/7sQMJpCc | 21:39 |
| mal | where does the space go based on du -hs /* ? | 21:40 |
| mal | do you have a lot of apps installed? | 21:41 |
| attah | https://pastebin.com/tzaz915f | 21:42 |
| attah | Nowhere? | 21:42 |
| attah | Not really | 21:42 |
| attah | Mostly native ones, and they are tiny | 21:42 |
| mal | what do you have in /root folder it has unusually much stuff based on that, I have less than 1 MB | 21:45 |
| attah | apparently linux-3.12.66.tar.xz | 21:46 |
| attah | dafuq | 21:46 |
| mal | my /usr is only 1.2 GB | 21:47 |
| attah | i guess i did install a few packages from mer-tools | 21:47 |
| mal | check if you have any debuginfo packages installed? | 21:47 |
| mal | or source packags | 21:48 |
| attah | one debuginfo and a dozen sources | 21:49 |
| mal | maybe uninstall those just in case | 21:49 |
| mal | not sure how much space those take | 21:49 |
| attah | pretty sure i didn't install most of them | 21:50 |
| attah | oh, and i'm tired... those were false positives for sources | 21:50 |
| attah | they were *re*source packages | 21:51 |
| mal | ah | 21:51 |
| mal | how big is the debuginfo? | 21:52 |
| mal | did the device tell how much space you need? | 21:52 |
| attah | apparently some 80MB or so | 21:52 |
| attah | 510, and i am at 337 | 21:53 |
| attah | and there we have it | 21:53 |
| attah | llvm apparently | 21:53 |
| attah | counter is still borked says SFOS&misc are 2G, of a total 1.8 | 21:54 |
| mal | hmm, what brought in llvm, it should not be there | 21:55 |
| attah | that would have been me | 21:55 |
| mal | hopefully now you can update it | 21:56 |
| attah | yes, finally :) | 21:56 |
| attah | and i need to stop treating it like a computer for package installs | 21:56 |
| attah | thanks for your time, sorry to have wasted it | 21:57 |
| mal | I was doing some kernel checking while helping you | 22:04 |
| attah | :) | 22:06 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!