| *** zbenjamin_ is now known as zbenjamin | 01:51 | |
| dcaliste | Good evening chriadam, how are you ? | 07:12 |
|---|---|---|
| chriadam | hi dcaliste, I'm well thank you :-) | 07:12 |
| chriadam | How are you? | 07:12 |
| dcaliste | Fine, thank you. I've seen your comment from earlier today on pending MRs. | 07:13 |
| dcaliste | Thank you. | 07:13 |
| dcaliste | About the one in kcalcore, importing changes from upstream to have time zone support in memorycalendar, I'm going to answer on gitlab. | 07:14 |
| chriadam | sounds good | 07:14 |
| dcaliste | But I'm also going to add an additional commit from one that has just been accepted upstream yesterday. | 07:15 |
| dcaliste | https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/11 | 07:15 |
| dcaliste | It would allow to remove a bit more code from ExtendedCalendar that is duplicated in memorycalendar. | 07:15 |
| dcaliste | I've restart to look at extendedcalendar simplification through inheritage from memorycalendar. | 07:16 |
| dcaliste | I've restarted this because I've also updated the mKCal migration to latest kcalendarcore and notice that a lot of changes appears in extendedcalendar due to usage of kdatetime there. | 07:17 |
| dcaliste | And most of these changes could be avoid if inheriting from memorycalendar. | 07:17 |
| chriadam | ah, that would be good | 07:17 |
| chriadam | although I wonder about the inheritance direction | 07:18 |
| dcaliste | Yeh, it would make the migration more straightforward to understand. | 07:18 |
| dcaliste | Because of less code changes. | 07:18 |
| dcaliste | What is bothering you with the inheritance ? | 07:18 |
| chriadam | would it be the case that ExtendedCalendar would inherit from MemoryCalendar? | 07:20 |
| dcaliste | Yes, that's the plan, because I notice that all the code from memorycalendar is actually duplicated in extendedcalendar. | 07:20 |
| chriadam | even though, for our case, the ExtendedCalendar provides some extra API and is implemented as a filesystem-backed database, rather than in in-memory datastore | 07:21 |
| dcaliste | Besides some very variation due to the divergence of the two projects. The upstream commits in memorycalendar are there to remove these tiny differences. | 07:21 |
| chriadam | it just seems a bit strange to be considered an "is-a" inheritance. but not necessarily a problem. | 07:21 |
| dcaliste | We can keep the extra API in ExtendedCalendar, just that most of the common implementation can live in one class only. | 07:22 |
| chriadam | yeah, the common implementation should definitely be consolidated, definitely | 07:22 |
| dcaliste | In fact, ExtendedCalendar is a in-memory calendar defacto, that has a calendar storage on disk with a SQlite backend. | 07:22 |
| dcaliste | I say defacto, because loaded events are cached in memory. | 07:23 |
| chriadam | ah, I see | 07:23 |
| chriadam | hmm. interesting nomenclature | 07:23 |
| dcaliste | I think all calendar, if they cache their results can be seen and implemented as MemoryCalendar. | 07:23 |
| dcaliste | I think it's consistent with the KCalendarCore API that separate calendar and storage into two classes already. | 07:24 |
| chriadam | right, that makes sense. naming is hard, I guess in my head when I hear MemoryCalendar I guess I should be seeing it more as "in memory view onto the underlying stored data" | 07:24 |
| dcaliste | Exactly. | 07:25 |
| pvuorela | i hope some day we could revisit the interfaces to make the notebooks better separated. e.g. allowing to have same event in multiple notebooks, move between them and actually get the deleted events lists properly. | 07:25 |
| pvuorela | but maybe that's some day after we've first catch up with kcalcore upstream. | 07:25 |
| dcaliste | Hello pvuorela. Getting the deleted event list is already in the API. What is broken in your opinion ? | 07:26 |
| pvuorela | dcaliste: it doesn't work if event is moved to another notebook. it's not deleted from mkcal pov. | 07:26 |
| dcaliste | Ah, but this is solved already with the purge API I added ;) I think so ?? | 07:26 |
| dcaliste | You can delete + purge an event and it will disappear from the database without being listed as deleted. | 07:27 |
| pvuorela | i think purge is a different thing, as in removing it altogether. the deleted instance detection i was more meaning synchronization fetching a list of deleted events since last time. not that can't be trusted if we allowed moving events between notebook. | 07:27 |
| pvuorela | thus the moving is still disabled. | 07:27 |
| dcaliste | I've in mind to make the move work again and I thought about it for a while now. That's what I see: | 07:28 |
| dcaliste | - mark an event as deleted in notebook 1, so the deletion can be propagated by sync to the server it is inside. | 07:29 |
| dcaliste | - when the event is also deleted from server, purge it on local db. | 07:29 |
| dcaliste | - in the meantime, create a clone in notebook 2, so it can be upsync to the server and next Buteo round. | 07:30 |
| dcaliste | What do you think is broken is this scheme ? | 07:30 |
| pvuorela | think the system doesn't now allow multiple events with the same uid. that needs some working around by creating a second event with different uid. | 07:31 |
| dcaliste | I think we can have the same UID if the deletedDate is different. Let me check the constraint. | 07:31 |
| dcaliste | Otherwise, the clone can be given a new UID. | 07:31 |
| pvuorela | also that uid problem is now bypassed in some sync plugins by modifying the uid, i think. | 07:32 |
| chriadam | yeah, we do some addressbook-name-prefixing | 07:32 |
| chriadam | in the google plugin at least | 07:32 |
| chriadam | perhaps caldav also, I don't recall | 07:32 |
| pvuorela | i think ideally the uid wouldn't change if we move it around to different notebooks. and we'd just synchronize remote events with uid untouched. | 07:32 |
| dcaliste | I think UID is irrelevant here because it has no meaning. The event will be new to server 2 anyway. | 07:33 |
| chriadam | yeah. in that case, the actual event needs to be separate (i.e. no "notebook/calendar" field), and then need a separate table: NotebookEvents (which has notebookId+eventId) | 07:33 |
| chriadam | dcaliste: not different server, but different calendar on same server | 07:33 |
| dcaliste | Beside, the UNIQUE constraint contains the dateDeeleted, so no problem to have the same UID with a deleted event. | 07:33 |
| dcaliste | chriadam, ah I see, didn't think about this possibility. | 07:34 |
| dcaliste | But even like that, we should give a new UID to the clone, I think. | 07:35 |
| dcaliste | Like that the event is not moved, it is copied and erased. | 07:35 |
| dcaliste | copied to notebook 2, and erased from notebook 1. The sync will propagate the changes if necessary. | 07:35 |
| chriadam | perhaps. maybe we can come back to this topic again some time in the future, as I suspect it will require some investigation etc | 07:37 |
| dcaliste | in CalDAV, we do some UID changed to prepend notebook ID also, but only for down sync events. Locally created event to be upsync have a "real" UID in the RFC sense of the term. | 07:37 |
| dcaliste | Sure, at the moment, this is just some thoughts about it. | 07:37 |
| pvuorela | same thing here, just hoping we could fix some of that mess by allowing the event moving and not relying on all sync plugins + qml wrapper to work around problems. | 07:38 |
| dcaliste | Reworking ExtendedCalendar on MemoryCalendar, it also strucks me, that we could have a db per account, instead of a db for everything. That would simplify corruption issues and backup. | 07:39 |
| chriadam | interesting idea | 07:39 |
| chriadam | would the ExtendedCalendar then load all available databases, in order to expose an "everything" view to, e.g. jolla-calendar? | 07:40 |
| dcaliste | I would require to change significantly the calendar worker in QML binding to "aggregate" the various DBs, | 07:40 |
| dcaliste | it would… | 07:40 |
| pvuorela | was also pondering if we should have per notebook dbs or tables. | 07:40 |
| dcaliste | The calendar worker is a nice place I think to aggregate (with many workers I guess), because the QML API of the nemo binding is doing the aggregation naturally with the CalendarManager object. | 07:41 |
| chriadam | I guess we don't backup/restore calendar events synced from accounts anyway, as we assume they will be re-synced / cloud is canonical | 07:46 |
| chriadam | so backup/restore would just affect the "local calendars" db | 07:46 |
| dcaliste | Yeh, it's not a change that is necessary in fact. I was just wondering about pros and cons. | 07:47 |
| dcaliste | About the UNTIL and COUNT parameter MR, I've got some news here. | 07:47 |
| chriadam | I'd be interested in startup performance impact, opening multiple files rather than one file, etc | 07:47 |
| dcaliste | chriadam, sure, performences should be taken seriously into account if we separated the dbs. | 07:48 |
| dcaliste | On the UNTIL and COUNT problem, this is a bit more serious than I thought first. Discussing with a developper of OpenXChange about it, he told me that the RFC says that in case of several STANDARD and DAYLIGHTSAVING observance, the closest to the date should taken into account. | 07:49 |
| dcaliste | See https://tools.ietf.org/html/rfc5545#section-3.6.5 | 07:50 |
| dcaliste | It's not at all implemented like that in kcalcore and all observance are applied for any date. Thus my funny issue of many hour changes in the Paris time zone. | 07:50 |
| chriadam | eek. | 07:51 |
| dcaliste | This is still present upstream, but highly mitigated by the fact that they are not using the provided time zone definition, but take the one from the system that match the name. | 07:51 |
| dcaliste | I'm wondering what you could suggest here : | 07:51 |
| dcaliste | - either rewrite the time zone in kcalcore to solve the problem and conform to RFC, | 07:52 |
| dcaliste | - or follow the upstream route and use the system time zone corresponding to the name. | 07:52 |
| dcaliste | In case the name is not matched, upstream is doing this: | 07:52 |
| dcaliste | - they read the time zone defintion | 07:53 |
| dcaliste | - and they try to match it with a system one. | 07:53 |
| chriadam | my preference would, in general, be to match upstream... | 07:53 |
| dcaliste | In case it succeed, the found system time zone is used, otheriwse they give up and raise a warning. | 07:53 |
| dcaliste | What would be the consequence in your opinion on time zone coming from exchange that you studied before ? | 07:54 |
| chriadam | it's a very good question | 07:54 |
| dcaliste | Because going upstream way means to drop most of the time zone code and rely on time zone naming matching the system. | 07:54 |
| dcaliste | They do this upstream: | 07:55 |
| dcaliste | if (QTimeZone::isTimeZoneIdAvailable(icalTz.id)) then take this one. | 07:55 |
| dcaliste | else const auto ianaTzid = QTimeZone::windowsIdToDefaultIanaId(icalTz.id); | 07:56 |
| dcaliste | if (!ianaTzid.isEmpty()) take this one. | 07:56 |
| chriadam | pvuorela / flypig: do you have an opinion here? using the system timezone info seems preferable to me... but I don't recall the specifics of why we required the VTIMEZONE definition to come from the exchange event, in that case, etc | 07:56 |
| chriadam | I mean, I guess one possibility is custom timezone definitions which don't match any known system tzid. in that case, having some "best effort" might make sense ... but I dunno. | 07:57 |
| pvuorela | don't have opinions myself yet on this. | 07:58 |
| flypig | Sorry, I'm not sure. My recollection of the existing timezone code is hazy. I'm sure I recall some timezone matching going on in the code already, but maybe that's unrelated. | 07:58 |
| chriadam | my memory is hazy too | 07:59 |
| dcaliste | I think the question may be simplified to "do KDE have a plugin for Exchange ?" | 07:59 |
| dcaliste | If so, it seems that their solution upstream is working, otherwise they would have bug report on time zone issues. | 08:00 |
| chriadam | true | 08:00 |
| dcaliste | If not, well, their solution may be problematic for us. | 08:00 |
| dcaliste | But, I've no idea, I'm using Gnome ;-D | 08:00 |
| chriadam | in the meantime, is there an issue with merging the UNTIL patch as-is, given that it presumably fixes the issue at least in some cases? | 08:02 |
| dcaliste | No, I agree. flypig commented about the tests that are not up to date anymore in our kcalcore. | 08:03 |
| dcaliste | I can fix them if you prefer. | 08:03 |
| dcaliste | I mean, using the patch from upstream ;) | 08:03 |
| chriadam | oh, I didn't see that. Yes, if possible, that would be excellent, thank you | 08:03 |
| dcaliste | No special work here. | 08:03 |
| dcaliste | Ok, I'll amend the commit later today. | 08:04 |
| chriadam | tyvm | 08:04 |
| chriadam | at some point in the near future, we should discuss kcalcore upgrade things, and what the best way for us to help with that effort is | 08:05 |
| chriadam | well, once we figure out who has some bandwidth to work on this from our side, in the coming weeks | 08:05 |
| chriadam | pvuorela: perhaps blam might, depending on what else is in the pipeline currently? | 08:05 |
| dcaliste | Yeh, thanks. I've updated the mKCal part, with a better understanding of the clock time and local time changes. I need to update the QML nemo bindings also and the sync plugin Google and CalDAV. | 08:06 |
| dcaliste | What do you think is using kcalcore directly otherwise ? The main pain being the use of KDateTime. | 08:07 |
| pvuorela | chriadam: yea, blam would be good. or you or david if there's any capacity. | 08:07 |
| chriadam | dcaliste: my head is a bit scrambled, currently. Is there any chance you could send me an email with a quick summary of the current state, as well as the upgrade path to where we should go, and any tradeoffs / tricky things? | 08:09 |
| chriadam | then perhaps pvuorela, blam and I could discuss it at the sprint planning next week, before our meeting with you next Tuesday | 08:09 |
| dcaliste | Ok, I'll summarize what is the current status for migration. I'll CC flypig and pvuorela if they don't mind. | 08:09 |
| dcaliste | And blam also if you think so. | 08:10 |
| chriadam | yes please, tyvm | 08:10 |
| pvuorela | thanks already! | 08:10 |
| chriadam | I'll poke bree again about the caldav PR and check whether there is anything preventing that one from being merged. otherwise, will hopefully merge that one on Thursday. | 08:11 |
| flypig | Thanks dcaliste, I certainly don't mind (I'd be interested). | 08:11 |
| chriadam | were there any other discussion topics for today's meeting, which I have forgotten? | 08:11 |
| dcaliste | No, but I would like to discuss an issue with visibility of calendars with flypig. Depending on your availability you may be interested. | 08:12 |
| chriadam | yep, I will be here for at least another hour yet | 08:12 |
| chriadam | thanks! | 08:12 |
| chriadam | (am working on the qtpim/qt6 unit test failures, currently) | 08:13 |
| dcaliste | The symptom is disabled calendars (unchecked ones in calendar app) coming back to visibility after sync, mau=inly for Google. | 08:13 |
| flypig | I thought mainly EAS? | 08:13 |
| dcaliste | See https://forum.sailfishos.org/t/calendar-bug-for-disabled-calendars-in-3-4-ea/2563 | 08:14 |
| dcaliste | Well Google also, and CalDAV I guess also under certain circumptances. | 08:14 |
| dcaliste | Let's wrap up what did changed in 3.4.0: | 08:14 |
| flypig | Ah, I'm just confused... it was perhaps just the EAS stuff I was looking at. | 08:14 |
| dcaliste | - we linked alarms in timed with notebook visibility directly inside mkcal. When a notebook changes visibility, the alarms are removed or added. | 08:16 |
| dcaliste | - the visibility in the calendar app has been changed to use notbook visibility instead of custom qsettings. | 08:16 |
| dcaliste | So all is nice, if you see a calendar in the app, it will ring, if not, there will be no alarm from this calendar. | 08:17 |
| dcaliste | But… | 08:17 |
| dcaliste | we needed to link account status (enable / disable) with notebook visibility to avoid the user to disable calendar one by one in the calendar app when an account is disabled. | 08:18 |
| dcaliste | And reverse to switch on calendar visibilities when a disabled account is enabled again, so the user see his calendars. | 08:18 |
| dcaliste | And we did this via a plugin in contactsd. | 08:19 |
| dcaliste | Do you remember / agree ? | 08:19 |
| flypig | That sounds right, yes. I think these were the MRs. | 08:19 |
| flypig | https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/55 | 08:19 |
| flypig | https://git.sailfishos.org/mer-core/contactsd/merge_requests/9 | 08:19 |
| dcaliste | The plugin in contactsd is running an AccountManager to follow account changes. | 08:19 |
| flypig | In CDCalendarController | 08:20 |
| dcaliste | Yep, that's the corresponding MR and source code. Indeed. | 08:21 |
| dcaliste | But, sadly, the AccountManager signal is triggered not on account status change (the account is disabled or enabled), but everytime an account is changed… So every single call to account->sync() or account->syncAndBlock() is triggerring the plugin. | 08:22 |
| dcaliste | This is documented in libaccount-glib that this signal can be emitted "randomly", not necessary on status change. | 08:23 |
| chriadam | sigh | 08:23 |
| dcaliste | So, at every touch of an account, and we're doing it in _many_ places, the calendar visibilities are changed. | 08:23 |
| dcaliste | Or, that's my finding :/ | 08:23 |
| dcaliste | The worst is that, the visibility need to be changed on an account status change and not on an account status value. | 08:24 |
| dcaliste | So as far as I think of it, we cannot find in the contactsd plugin if we need to change the visibility on, or off because we have access only to the status value, and not to its change. | 08:25 |
| dcaliste | That's very bad… | 08:26 |
| flypig | Good observations, but I just need to digest. | 08:26 |
| dcaliste | Sure, of course. I notice the triggerring at each syncandblock call, with a printf in the plugin and running contactsd from the command line with debug on. | 08:27 |
| flypig | Could you elaborate on this please? " the visibility need to be changed on an account status change and not on an account status value" | 08:27 |
| flypig | "status" meaning "enabled status"? | 08:28 |
| dcaliste | I mean that a disable account doesn't mean that calendar should be hidden, the user may want to see his calendar but not sync them. Or worst, the visibility of all calendar of this account should not be on when the account is enabled, because the user may want to see only two of the three of its remote calendars. | 08:30 |
| dcaliste | I mean, it's fine to change the visibility on account status change. But only on change. | 08:30 |
| dcaliste | If we switch on visibility of all calendars because the Google refresh token has changed and is saved in syncAndBlock, that's not fun. | 08:31 |
| dcaliste | But the signal is triggered not only on change. | 08:31 |
| flypig | Okay, I see. So the plan should be: "if the account becomes disabled, make it invisible. If it becomes enabled make it visible. But if the visibility changes, don't change the enabled/disabled status". | 08:31 |
| flypig | But the "if the account becomes disabled, make it invisible; if it becomes enabled make it visible" part is being executed at other times, not just on enabled/disabled status changes. | 08:32 |
| dcaliste | Exactly. | 08:33 |
| dcaliste | And from the signal slot, I think we cannot guess if it was triggered from a status change or from any other change. | 08:33 |
| flypig | Unless we record the old value, I suppose. | 08:33 |
| dcaliste | Er yeh, but I'm afraid that's a problem by itself ! Where to save this value ? | 08:35 |
| flypig | Yes, sure. | 08:35 |
| chriadam | have I mentioned how much I like accounts&sso? :-P | 08:35 |
| flypig | :D | 08:36 |
| dcaliste | After thinking about this for a while, I think, we should keep the notebook visibility separated from account status. | 08:36 |
| dcaliste | chriadam, I agree, so strange API with these service thingies. And now this … | 08:36 |
| dcaliste | To keep this paradigm, I see now only one solution : | 08:37 |
| dcaliste | change notebook visibility in jolla-settings-accounts itself, when the status is changed. | 08:37 |
| dcaliste | If a user change account status by command line with ag-tool, well he knows what he's doing. | 08:38 |
| dcaliste | But do we have another place in the system where we're changing account status behind the scene ? | 08:38 |
| chriadam | not that I can recall off the top of my head, although that probably doesn't mean anything. | 08:39 |
| chriadam | one alternative: we could actually reload the account settings from the db in the contactsd slot, and check the value of the enabled setting (for both the global service, and the calendar-related subservice) | 08:40 |
| flypig | We could add another signal to libaccounts-qt. One that does what it's supposed to. | 08:40 |
| chriadam | this would hit the fs more often than might be optimal | 08:40 |
| chriadam | or, yes, that might be a possibility also | 08:40 |
| dcaliste | chriadam, I think that's not solving the problem, or I misunderstood. Because we're not interesting on the status value but on it's change and I think that the value on disk has already changed when the signal is received. | 08:42 |
| dcaliste | flypig: yes, but it must be done in libaccount-glib, because libaccount-qt is quite an empty shell. I've looked at the code and it's just passing glib signals. | 08:42 |
| dcaliste | But it's a good idea. | 08:42 |
| flypig | Yes, I see what you mean. | 08:43 |
| dcaliste | I was thinking first to patch libaccount-glib to emit the signal only when it makes sense, but this would have break compatibilitiy for those who rely on the current behaviour. | 08:43 |
| dcaliste | But I discarded the idea because of this. | 08:43 |
| dcaliste | But creating a new dedicaded signal, that's smart ! | 08:44 |
| dcaliste | Besides, the technical feasbility ;) | 08:44 |
| dcaliste | I'll look at libaccount-glib code to see where to add it and if it's tracktable. | 08:44 |
| dcaliste | If so, I much prefer this idea compared to fix things in jolla-settings-accounts which would be always fragile. | 08:45 |
| flypig | There's probably some complexity from the fact that the real info needed is "account enabled and at least one service enabled". | 08:47 |
| flypig | Rather than just "something was enabled/disabled". | 08:47 |
| flypig | But if you're happy to look at it dcaliste? | 08:48 |
| dcaliste | Yeh, but we can forge a signal that is triggered for status changed with a service argument. When empty, it's for account, when it's not, well it's for the service. And in the handler, we can still check for the other one. If you understand what I mean. | 08:49 |
| dcaliste | Yes, I will look at this solution. I prefer it than patching the UI code. | 08:50 |
| flypig | I'm just thinking that contactsd can't calculate an overall change from the subchanges without storing some state. | 08:54 |
| flypig | I guess, as long as every change triggers an event (e.g. two state changes don't get bundled into one) then it's okay. | 08:55 |
| flypig | But, these are details. | 08:55 |
| dcaliste | Yeh, I need to see in the -glib project where the status (for a service or globally) is changed and put the signal there. But I need to pay attention that the values are already changed in memory if we use the account in the handler. | 08:57 |
| dcaliste | Anyway, if you think it's the right way to go, I'll look into this and report when ready. | 08:57 |
| dcaliste | This reminds me that next week I won't be able to attent the meeting. It's the automn vacation in France for Children, and I'll be off with my family. | 08:58 |
| flypig | Yes, I guess stuff like that needs some care. But if you're happy to look into it, then that's great as far as I'm concerned. | 08:59 |
| chriadam | no worries - have a nice vacation :-) | 08:59 |
| chriadam | thanks again for your efforts and help - it is greatly appreciated. | 08:59 |
| flypig | Same from me; have a good vacation. | 08:59 |
| dcaliste | Thank you, I'll keep you informed on this topic. I think that's all for me today. | 09:05 |
| chriadam | thanks again, have a great week | 09:14 |
| Mister_Magister | mal: abranson: If video is played/destroyed enough times in app, app will crash. Its qml Video { } element nothing fancy | 10:05 |
| Mister_Magister | ah i forgot link https://photos.google.com/share/AF1QipMFbImhR0_dJKp2kVOD5mn4QY5coVi2JfBVGvu5baaE02Z8bPn-Zu4Fq7A723uPjA?key=d0JmWmRrdFppTkNqYllJVkt6SDhCS3VldXBaU1B3 | 10:06 |
| Ingvix | How does one solve this error with pkcon refresh: 'Fatal error: Medium not attached: plugin:/ssu?repo=adaptation0' | 11:59 |
| Ingvix | I'm not sure what it even means | 12:00 |
| Ingvix | nevermind, probably found my solution here: https://forum.sailfishos.org/t/application-with-overlay-crashed-device-3-4-0-22/2278/6 | 12:05 |
| antis | Hey, while looking on libhybris wiki I noticed merproject.org is not reachable (since few days now). Has the domain moved or something? | 12:34 |
| *** frinring_ is now known as frinring | 12:52 | |
| pketo | antis: wiki.merproject.org is having some issues, hopefully will be back up later this evening | 13:05 |
| antis | pketo, thanks for the info | 13:06 |
| *** DennisRoczek is now known as DennisRoczek|afk | 13:36 | |
| thigg[m] | currently resetting my xperia X by flashing android on it first. Does it matter if I flash NOBA, UK or FR? | 14:07 |
| jmlich | I am trying to run update, but it complains "Unable to determine update size". I am trying to fix it according to https://jolla.zendesk.com/hc/en-us/articles/217190827--Unable-to-determine-update-size-unable-to-update-how-to-fix In the end it complains that https://releases.jolla.com/features/3.3.0.16/customers/jolla/armv7hl/drpms/sailfish-content-configuration-jolla-0.1.1-1.1.25.jolla_0.1.1_1.3.1.jolla.noarch.drpm is missing | 15:19 |
| *** ahjolinna_ is now known as ahjolinna | 15:32 | |
| thigg[m] | works with fr, so i guess it doesnt make a difference... | 15:46 |
| thigg[m] | now I am missing a .ssh folder with 3.4, I can only log in with pw, but cannot add my ssh key anymore | 15:47 |
| thigg[m] | ssh-copy-id is throwing some warnings | 15:49 |
| * thigg[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/ZRcDGEWkqfkIBWOxRKwYbAzC/message.txt > | 15:49 | |
| thigg[m] | creating a new device in sailfishide was able to push the key to the device | 15:56 |
| attah | Any ideas when the SDK ssh key handling might get unborked? | 18:40 |
| Nico[m] | Dunno, it works for me, so this may be system specific | 18:44 |
| attah | It just rots from one day to the other... how is that even possible? | 18:44 |
| Nico[m] | Or which direction are you talking about? | 18:44 |
| attah | deploying RPMs | 18:44 |
| Nico[m] | Solar flare? | 18:44 |
| attah | And it *is* a known issue | 18:44 |
| Nico[m] | Hm, I did that just 5 minutes ago... :D | 18:45 |
| attah | And i did yesterday... and now, just a reboot alter is is borked again | 18:45 |
| Nico[m] | Weird | 18:45 |
| attah | The damned test button even says everything is OK just to tease | 18:46 |
| Nico[m] | Ah, does ssh work locally from your pc, but not from the sfsdk? | 18:46 |
| attah | yes | 18:46 |
| Nico[m] | Are you using the docker stuff? | 18:46 |
| attah | yes | 18:47 |
| Nico[m] | That one caused me a lot of issues | 18:47 |
| attah | screw it, reinstalling | 18:47 |
| Nico[m] | I need to restart the docker service everytime my phone reconnects to the wifi | 18:47 |
| Nico[m] | And when I regenerated the key, I needed to do that too, iirc | 18:48 |
| attah | huh? | 18:48 |
| Nico[m] | Yeah, it was weird | 18:48 |
| attah | Nico[m]: very good suggestion with the docker restart | 18:53 |
| Nico[m] | Did it work? :D | 18:56 |
| attah | Yes... although to be fair, sample size of one puts it on par with whatever woodoo i have done before | 18:57 |
| Nico[m] | Well, it worked for my similar issues too. I should write that down in the forum at some point... | 18:58 |
| attah | yes, yes you should | 18:59 |
| Nico[m] | I had a lot of fun last weekend trying to get the sdk to work, I'm still waiting for more issues to show up... But so far it works, even with livebench | 19:01 |
| attah | I realized yesterday that i had made a mistake in SeaPrint affecting all those with non-PDF printers :/ the intermediary format ended up being 2-4 times bigger than it needed to | 19:11 |
| Nico[m] | Doesn't sound that bad | 19:16 |
| Nico[m] | I broke a few 100 matrix servers, because my db migration code was bad :D | 19:16 |
| attah | heh... i bet i have something like it waiting at work sooner or later | 19:16 |
| Nico[m] | At least it was fixable :3 | 19:18 |
| Nico[m] | Now if only I was good at designing Sailfish icons... | 19:18 |
| attah | Design in general is not easy... | 19:20 |
| attah | I often know what i want and what looks good, but actually putting it together... that's where it fails | 19:21 |
| Nico[m] | Well, so far I'm somewhat happy with how my app looks, but it has no icon yet :D | 19:22 |
| attah | which one? | 19:22 |
| attah | or should i know about it? | 19:22 |
| Nico[m] | I'm making a matrix client, but I haven't published it yet | 19:22 |
| attah | ah | 19:22 |
| thigg[m] | bluepill? | 19:22 |
| Nico[m] | thilo: No :D | 19:23 |
| attah | JSEHV hooked me up with two nice icons | 19:23 |
| attah | Tint and S'Play | 19:24 |
| * Nico[m] takes a look | 19:24 | |
| Nico[m] | Oh, yeah, those look awesome! | 19:25 |
| attah | Rudi T contributed the SeaPrint one by asking a friend... also super nice, but maybe not someone to cold-call for graphic design (too far removed) | 19:27 |
| Nico[m] | Well, I'm slowly making progress | 19:28 |
| attah | Although in that case i actually knew what i wanted and asked for it | 19:28 |
| Nico[m] | I'll just let someone clean it up, if it is too horrible :D | 19:28 |
| attah | sounds good | 19:28 |
| *** smj is now known as SanMJ | 22:26 | |
| Wikiwide | I do not see MS Exchange in Jolla Store: https://jolla.zendesk.com/hc/en-us/articles/201440117-Setting-up-an-Exchange-account-on-Sailfish | 22:39 |
| Wikiwide | Under "Jolla", I see only eight apps, all installed - Weather, Clock, Notes, Calendar, Calculator, Documents, Media, Mail. | 22:39 |
| Nico[m] | You dohave a license connected to your account? | 22:40 |
| Wikiwide | Sailfish OS 3.3.0.16 | 22:42 |
| Wikiwide | What licence? I have a Jolla account, I am running Sailfish on Fxtec Pro1 - what licence is needed? | 22:42 |
| Nico[m] | You need a Sailfish X license, community ports do not get access to Exchange, the maps app and android support, iirc | 22:43 |
| Nico[m] | Since those are at least partially licensed features, where jolla needs to pay license fees per user or so | 22:43 |
| Wikiwide | Hmm, tricky - I don't care about Android support, and there are plenty of maps apps out there (Pure Maps, Navit), but ActiveSync is tricky. I am tired enough of Sailfish OS running as a stowaway with hybris - I don't even get how exactly it works... | 22:46 |
| Wikiwide | Mail is easy, IMAP/SMTP something. But Microsoft doesn't provide CardDAV/CalDAV interfaces. It sounds like I have got to figure out an open-source CardDAV/CalDAV server and migrate my data to that. No, not to Google - I don't like it. | 22:48 |
| Nico[m] | You could use nextcloud for your CalDAV/CardDAV | 22:49 |
| Wikiwide | I don't like Outlook much, either, but this Outlook account was provided to me as "lifetime" account, aka, it's not going to have data deleted just because, for example, I didn't log in for a year. | 22:49 |
| Nico[m] | That's what I use and it works pretty well | 22:49 |
| Wikiwide | Hmm, I am a member of FSF. I haven't tried to log in to their website in years. Let's check if their server (and it's undoubtedly open-source) provides CardDAV/CalDAV... | 22:54 |
| Nico[m] | Well, that could work too. The nextcloud integration in Sailfish is great though, not sure, if the FSF runs that? | 22:56 |
| Wikiwide | Yahoo seems to offer CalDAV/CardDAV something, but I don't like Yahoo - even adding their email account to Sailfish OS was a pain, with two-factor authentication nonsense. | 22:57 |
| Nico[m] | Yahoo also did get hacked twice or so | 22:58 |
| Wikiwide | Five member.fsf.org email aliases for forwarding; A member.fsf.org XMPP Jabber account for instant messaging; Access to freedom-respecting videoconferencing via our Jitsi Meet instance | 23:00 |
| Nico[m] | Heh, I run pretty much all of that myself (just matrix instead of XMPP) | 23:05 |
| *** Oksana_ is now known as Oksana | 23:23 | |
| r0kk3rz | Wikiwide: hybris is easy to understand, it just allows linking against android libraries | 23:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!