| cartron | hello! | 07:58 |
|---|---|---|
| sledges | #startmeeting Sailfish OS, open source, collaboration -- 11th February 2021 | 07:59 |
| sailbot_ | Meeting started Thu Feb 11 07:59:59 2021 UTC. The chair is sledges. Information about MeetBot at http://wiki.debian.org/MeetBot. | 07:59 |
| sailbot_ | Useful Commands: #action #agreed #help #info #idea #link #topic. | 07:59 |
| *** sailbot_ changes topic to " (Meeting topic: Sailfish OS, open source, collaboration -- 11th February 2021)" | 07:59 | |
| sledges | #startmeeting Sailfish OS, open source, collaboration -- 11th February 2021 | 08:00 |
| sledges | #info Meeting information and agenda can be found here: | 08:00 |
| sledges | #link https://forum.sailfishos.org/t/community-meeting-on-irc-11th-feb-2021/4306 | 08:00 |
| sledges | I am the meeting's chairperson today, and will be doing my best to keep time and order. Please behave, and respect cambelt timing. | 08:00 |
| sledges | #topic Brief introduction (5 min). Please prefix your name/handle with #info | 08:00 |
| *** sailbot_ changes topic to "Brief introduction (5 min). Please prefix your name/handle with #info (Meeting topic: Sailfish OS, open source, collaboration -- 11th February 2021)" | 08:00 | |
| sledges | #info Simonas Leleiva -- privateer for Jolla | 08:00 |
| Mister_Magister | #info Mister_Magister - community member | 08:01 |
| sledges | (double #startmeeting Irish-style - "to be sure, to be sure!") | 08:01 |
| santhoshm | #info Santhosh Manikandan - Community member | 08:01 |
| ljo | #info Leif-Jöran Olsson, community member | 08:01 |
| Zyuc2G | #info Zyuc2G community member | 08:01 |
| fridl | #info fridlmue - community | 08:01 |
| Mister_Magister | sledges: nice to see you! | 08:01 |
| karry | #info Lukas Karas - developer, community member | 08:01 |
| cartron | #info Nico Cartron, community member | 08:02 |
| ViGe | #info Ville Nummela - sailor@Jolla | 08:02 |
| jpetrell | #info Joona Petrell, Jolla sailor | 08:02 |
| flypig | #info David Llewellyn-Jones, sailor@jolla | 08:02 |
| abranson | #info Andrew Branson, Jolla | 08:02 |
| sledges | o/ | 08:02 |
| sledges | #topic Url aware .desktop file opening (15 min -- asked by Mister_Magister) | 08:05 |
| *** sailbot_ changes topic to "Url aware .desktop file opening (15 min -- asked by Mister_Magister) (Meeting topic: Sailfish OS, open source, collaboration -- 11th February 2021)" | 08:05 | |
| sledges | #info <Mister_Magister> So I made merge request to libcontentaction that allows devs to specify url domain so that if user clicks link with domain that matches specified it will open said app. | 08:05 |
| sledges | #info It's done extremely easy and extremely robust all i did was to in case of x-scheme-handler/https mimetype extract domain from url and convert it into x-url-handler/<domain> mimetype. Then apps can just add x-url-handler/youtube.com or x-url-handler/* in order to handle specific domains. | 08:05 |
| sledges | #info That's it, all mimetype handling and everything is left as it was. I and other devs would love to see it in upstream. It doesn't break anything because if it doesn't find any x-url-handler that would match it just falls back to standard mode. | 08:05 |
| sledges | #info <Jolla> We need better heuristics for sure, current way apps register for mime types it too rudimentary. Overall URL aware file opening sounds great, just need to take into account that the user may want to open Twitter and YouTube links with regular browser. | 08:06 |
| Mister_Magister | This is a bit out of date, i'm in contact with jolla employee so this topic serves as nothing else than bringing atention | 08:06 |
| cartron | so this will likely make it to a next update? cause that's a nice feature indeed | 08:06 |
| jpetrell | sounds likely | 08:06 |
| Mister_Magister | cartron: maybe not next, but probably will make it into sfos | 08:06 |
| Mister_Magister | i've been working with pvuorela on all changes that needs to be done | 08:07 |
| cartron | cool | 08:07 |
| ViGe | next update == the update after 4.0.1 | 08:07 |
| Mister_Magister | maybe update after that | 08:07 |
| Mister_Magister | or 2 updates after that | 08:07 |
| cartron | yeah of course - i don't expect new stuff coming after 4.0.1's EA :) good to know, thx | 08:08 |
| Mister_Magister | because even if 4.0 is EA jolla already is preparing next release and making it ready… so release after next release | 08:08 |
| Mister_Magister | if it gets merged ofc | 08:08 |
| flypig | Mister_Magister, can app devs already start putting hints in their desktop files for when it does arrive? | 08:09 |
| Mister_Magister | flypig: hell you can even test it, test lib is released on openrepos | 08:10 |
| Mister_Magister | and yeah you can, its not like it will break anything | 08:10 |
| Mister_Magister | flypig: thing is, if you need to catch specific url you wiill have to remove x-scheme-handler/http once it gets merged | 08:11 |
| flypig | Okay, that's good to know. | 08:11 |
| Thaodan | #info Björn Bidar - sailor @ jolla | 08:12 |
| Thaodan | had connection issues.. | 08:12 |
| Mister_Magister | before its included you can just add that mimetype so that users that use my lib from openrepos can enjoy it | 08:12 |
| sledges | is there a demo/video about this feature? | 08:12 |
| sledges | so those reading minutes can have a visual | 08:12 |
| Mister_Magister | there's a video https://twitter.com/Mister1Magister/status/1357839807301435392 | 08:13 |
| sledges | #link https://twitter.com/Mister1Magister/status/1357839807301435392 | 08:13 |
| Thaodan | I think it makes sense to test Mister_Magisters lib by the community for everything later down the line | 08:13 |
| Mister_Magister | yep! i'll be more than welcome for any feedback | 08:14 |
| Thaodan | IMHO this should go also to freedesktop.org since it extends the mime type handling which is part of that standard | 08:14 |
| Thaodan | It would make sense for others to adapt that | 08:14 |
| abranson | Well I think it's great. I wondered if it should have used x-domain-handler, but as the PR now talks about including fragments of the path after, url is fine. | 08:15 |
| Mister_Magister | Well, from the talks with pvurela, functionality changed a bit and the additional mimetype will be just additional mimetype | 08:15 |
| Mister_Magister | with conversion functionality | 08:15 |
| Mister_Magister | abranson: greatest thing about this change is that its simple and robust and super easy to implement in apps | 08:16 |
| abranson | btw, if you need to include things like forward-slashes in the second mimetype element, you could use quoted printable like when urls are encoded in others. / => %2f | 08:17 |
| abranson | Mister_Magister: yeah. "elegant" is the word :D | 08:17 |
| Mister_Magister | abranson: but urls can contain @2f | 08:17 |
| Mister_Magister | aaand whole parsing goes bad | 08:17 |
| abranson | %25 <> % | 08:18 |
| Mister_Magister | for separator you need something that urls for sure don't have | 08:18 |
| sledges | 2mins remain | 08:18 |
| abranson | there are libs that can unmunge that for you | 08:18 |
| abranson | it's the standard way to encode URLs | 08:18 |
| Mister_Magister | not sure what u mean but you can leave feedback in mr | 08:18 |
| Mister_Magister | https://git.sailfishos.org/mer-core/libcontentaction/merge_requests/18 | 08:18 |
| Mister_Magister | sledges: maybe we should link this^ | 08:18 |
| dr_gogeta86 | maybe this is the reason other platforms use protocols intested of uris | 08:19 |
| dr_gogeta86 | or a mix and match | 08:19 |
| sledges | #link https://git.sailfishos.org/mer-core/libcontentaction/merge_requests/18 | 08:19 |
| flypig | Anyone can link, I think, can't they? | 08:19 |
| Mister_Magister | possible | 08:19 |
| Thaodan | They also use uris | 08:19 |
| sledges | time's up, anything else? | 08:20 |
| abranson | yeah, we'd be able to integrate android apps with this | 08:20 |
| dr_gogeta86 | like bangood | 08:20 |
| Mister_Magister | sledges: not from me | 08:21 |
| dr_gogeta86 | with sfos browser i dunno why tries to open their app url scheme | 08:21 |
| sledges | ok, moving on, will re-discuss when MR shapes more | 08:21 |
| sledges | #topic SFOS 4.0 UI element changes (10 min -- asked by KeeperoftheKeys) | 08:21 |
| *** sailbot_ changes topic to "SFOS 4.0 UI element changes (10 min -- asked by KeeperoftheKeys) (Meeting topic: Sailfish OS, open source, collaboration -- 11th February 2021)" | 08:21 | |
| sledges | #info <KeeperoftheKeys> In SFOS 4.0.1.45 several QML UI elements have stopped working, so far for gPodder I found IconContextMenu and IconMenuItem to have stopped working. | 08:21 |
| sledges | #info – Are these items being removed or will this be fixed before GA? | 08:22 |
| sledges | #info – Where can we find a list of changes to QML UI elements? | 08:22 |
| sledges | #info – What is the recommended new UI item to use that will allow the application to render properly both in SFOS 4.x and in old SFOS (the work around I have found for IconContextMenu does not render properly on SFOS 3.x)? | 08:22 |
| sledges | #info <Jolla> We need to review your code to see what is broken. By IconContextMenu do you mean IconComboBox? IconComboBox and IconMenuItem make up a combo box variant that was just introduced after the last public release 3.4.0 so both are new components that haven't been documented yet. | 08:22 |
| sledges | #info <Jolla> The new variant is currently only used in People app. There has not been changes to the two components after the initial introduction in internal release 4.0.0, though it is possible some component they depend on broke. | 08:22 |
| sledges | #info <Jolla> We list UI Component area changes in OS release notes, but overall the release notes are not developer oriented so lack API level details. SDK release notes related to SDK, which is not directly bound to an OS so it is not good place to list API changes. | 08:23 |
| sledges | #info <Jolla> We have recently discussed that we should write more about the new APIs in the Sailfish Forum, for example now about the new notification API and Silica TextField/TextArea API changes introduced in 4.0.1. | 08:23 |
| sledges | KeeperoftheKeys looks AWOL :) | 08:23 |
| sledges | since this looks a potential breakage, will need to chase the author through forum to analyse the code | 08:26 |
| jpetrell | yeah | 08:26 |
| sledges | haven't seen feedback from other apps breaking in this way though | 08:26 |
| jpetrell | IconMenuItem and IconComboBox were introduced in 4.0.0, which was only accessible by CBeta | 08:27 |
| jpetrell | I could not find IconContextMenu, so assuming IconComboBox was meant | 08:28 |
| chriadam | (I assume you already checked, but could that IconContextMenu have been very old, e.g. 2.x.x days? and since removed?) | 08:28 |
| jpetrell | I checked 3.4.0, but not 2.x.x old | 08:29 |
| fridl | I find it in the code here: https://github.com/gpodder/gpodder-sailfish/blob/e97804a98b21df934115280d072d80b54be500cc/qml/PodcastItem.qml#L28 | 08:30 |
| ViGe | https://github.com/gpodder/gpodder-sailfish/blob/master/qml/IconContextMenu.qml | 08:30 |
| jpetrell | ah so it is name conflict | 08:31 |
| jpetrell | IconMenuItem was introduced in Silica, Silica import overruled his local IconMenuItem | 08:32 |
| sledges | #link https://github.com/gpodder/gpodder-sailfish/blob/e97804a98b21df934115280d072d80b54be500cc/qml/PodcastItem.qml#L28 | 08:32 |
| sledges | #link https://github.com/gpodder/gpodder-sailfish/blob/master/qml/IconContextMenu.qml | 08:32 |
| sledges | #info IconMenuItem was introduced in Silica, Silica import overruled their local IconMenuItem | 08:32 |
| jpetrell | that is always a risk unless you write import Sailfish.Silica 1.0 as Sailfish ... Sailfish.IconMenuItem to explicitly say what module the component should come from | 08:33 |
| ViGe | well, it's easy for him to fix that :) | 08:33 |
| jpetrell | We try to find intuitive, natural names for the new components so unfortunately these kind of risks hard to avoid | 08:34 |
| sledges | #info looks like an easy fix, and tip for the future: | 08:34 |
| sledges | #info to reduce name conflict risk, write import Sailfish.Silica 1.0 as Sailfish ... Sailfish.IconMenuItem to explicitly say what module the component should come from | 08:34 |
| sledges | #info We try to find intuitive, natural names for the new components so unfortunately these kind of risks hard to avoid | 08:35 |
| sledges | we're overtime on this one, i think it can conclude here | 08:35 |
| sledges | #topic General Discussion (30 min) | 08:35 |
| *** sailbot_ changes topic to "General Discussion (30 min) (Meeting topic: Sailfish OS, open source, collaboration -- 11th February 2021)" | 08:35 | |
| fridl | In discussion with some other Dev we discovered, that a qml CoverBackground{ } behaves unexpected: When setting transparent: false the cover is fully transparent, when setting transparent: true it looks "normal" with half transparent BG. Is that Expected or a Bug? And I would recommend either way to ad a line for that in the Documentation way. | 08:36 |
| ApB | am i the only one that expected more with SFOS 4 or no? | 08:38 |
| Nico[m] | #info Nico, Community | 08:38 |
| jpetrell | yeah it was a naming mistake we did. transparent covers should have glass backgrounds so transparent: true means "with glass background" | 08:38 |
| jpetrell | you only set it off if you have your own background like how some covers are fully opaque | 08:38 |
| fridl | jpetrell: Ok, so giving some hint in the Doku would be nice :-) | 08:39 |
| jpetrell | indeed | 08:39 |
| fridl | thanks :-) | 08:41 |
| fridl | is there another EA-Release planed before the public one for 4.0.1? | 08:41 |
| ApB | with all the bugs found its quite possible | 08:42 |
| ApB | at least thats what has happened in the past | 08:42 |
| ApB | i read a lot of comments in the forum about bash. since gpl3 is problematic why not change the shell in something liek zsh? | 08:42 |
| Nico[m] | Since Sailfish 4 removed statefs, only Qml provides an easy API to access context properties. A lot of those APIs are used in the backend usually, could you maybe add a C++ API back? Then applications could access network status and all the other properties even when they don't currently have a Window, which is useful for messaging applications and System monitors. | 08:43 |
| sledges | about EA vs final -- good things come for those who wait;) (applies to other actualities, too:)) | 08:43 |
| ApB | sledges the community is not patient :D | 08:44 |
| chriadam | ApB: I actually think that Sailfish OS 4 is a pretty huge milestone. the fundamental building blocks for basic application sandboxing are in place. | 08:45 |
| chriadam | the browser was updated significantly. | 08:45 |
| flypig | Nico[m], was there something particular? There should be APIs for most/all things. | 08:45 |
| chriadam | the contacts backend now supports properly separated addressbooks with full sync transaction support. | 08:45 |
| Mister_Magister | i've also heard that my multicamera patches are picked up by mal and being worked on! | 08:45 |
| ApB | chriadam while sandboxing is nice i feel that there are other more important issues to be fixed | 08:45 |
| jpetrell | ApB: bash was replaced with busybox sh in 4.0 | 08:46 |
| chriadam | ApB: a matter of opinion, I guess. I see security as the #1 topic that we need to work on, haha. | 08:46 |
| Nico[m] | flypig: contextkit just has a much nicer API than calling 5 different APIs to access those properties | 08:47 |
| ApB | jpetrell yes i know. but i've seen quite a few comments about bash and intalling it so i had to ask. anyway | 08:47 |
| flypig | Nico[m], I can appreciate the convenience, yes. | 08:47 |
| chriadam | Nico[m]: this is just a personal opinion, but I prefer there being "one canonical way" to do each thing, rather than having multiple ways including wrappers around other things, etc. | 08:48 |
| ApB | chriadam we lack features at the moment. | 08:48 |
| chriadam | Nico[m]: you know my mantra: reduce platform surface, reduce external dependencies ;-) | 08:48 |
| chriadam | ApB: of course, I'd never dispute that | 08:48 |
| Nico[m] | chriadam: Well, I would like to just always use the context properties on Sailfish, instead of using different APIs in Qml vs C++ | 08:49 |
| ApB | any updates on the API polls we run a few weeks back | 08:49 |
| rinigus | Nico: how removed the statefs is in 4.0? can it be installed via pkcon install if it is needed? | 08:49 |
| ApB | qt possitioning made it in but what about the rest that are high on the list | 08:49 |
| Nico[m] | rinigus: No, afaik it is gone | 08:49 |
| flypig | Nico[m], there's an opening for a community lib to pull the APIs together. | 08:49 |
| Nico[m] | flypig: Fair enough :D | 08:50 |
| rinigus | Nico: thanks. that's bad news for me. as collectd (pure C) is using it for stats | 08:50 |
| Nico[m] | rinigus: Well, I only looked at the old contextkit-statefs stuff, that was removed, which provided a nice C++ Api around it | 08:52 |
| flypig | Nico[m]: I don't mean to be flippant about it. All I mean is that, whoever needs the API is usually best-placed to formulate it. | 08:52 |
| ViGe | ApB: Not much to update about the APIs. You can check the results of the polls yourself if you are interested. The results have been used in planning future work, but for most of the APIs the situation is that they will take a lot of work and time. | 08:52 |
| Nico[m] | flypig: No, I just laughed because it could taken that way :3 | 08:52 |
| Nico[m] | I liked the C++ API, that got removed :3 | 08:53 |
| pvuorela | Nico[m]: something specific you'd need? | 08:53 |
| ApB | ViGe yeah. i just wanted to know if there has been any work from jollas part | 08:54 |
| Nico[m] | pvuorela: Just the contextkit Qml API accessible from C++ would be nice :3 | 08:54 |
| sledges | #info (discussing about statefs having been removed in SFOS 4 and [new] API alternatives) | 08:54 |
| rinigus | ok, will have to see what was removed regarding statefs packages specifically when I get to 4.0. | 08:54 |
| sledges | #info API poll concluded and it will be prioritised accordingly in the SFOS roadmap | 08:55 |
| pvuorela | Nico[m]: i mean specific properties. lot of the things imght be accessible by other means and by more proper api. | 08:55 |
| rinigus | pvuorela: would be great to have API (pure C) to access stats regarding battery, network, and such. so far, statefs was filling that role | 08:55 |
| chriadam | where was statefs getting its data for those things from? mce? | 08:56 |
| pvuorela | for c++ the qtnetwork stuff might help. | 08:56 |
| Thaodan | The pure c api would be /sys and /proc probably | 08:57 |
| Nico[m] | pvuorela: I know, that everything is accessible via different APIs, contextkit just gives nice unified access to all og them, as I need them. I'm pretty sure it just uses dbus for all of that or so | 08:57 |
| rinigus | chriadam: good question. don't know, looks like there are several providers involved: mce, power-udev, ofono | 08:58 |
| Mister_Magister | you guys still going :O | 08:58 |
| Nico[m] | This is purely for convenience :3 | 08:58 |
| rinigus | Thaodan: not sure I can get (as regular user) cell network signal strength from /proc or /sys, for example | 08:58 |
| Nico[m] | (and symmetry with Qml) | 08:58 |
| Thaodan | Not sure about cell network but everything else would be there | 08:59 |
| rinigus | was something breaking in statefs or it is dropped to avoid maintenance? I wonder if we can just pull the source and build it on OBS for those who are interested in using it? | 09:02 |
| flypig | Nico[m], back in December you suggested we should do some periodic "community updates". We're looking seriously into going ahead with this. | 09:02 |
| chriadam | rinigus: ask pvuorela ;-) I think it was mostly the maintenance burden, and the tentacles / dependencies. | 09:03 |
| chriadam | but I may be wrong | 09:03 |
| chriadam | either way, I'm personally happy that it's gone haha. | 09:03 |
| Thaodan | There was also duplication between contextkit | 09:04 |
| Nico[m] | flypig: That would be lovely. I really enjoy doing updates for "This week in Matrix" already :3 | 09:04 |
| ViGe | rinigus: maintenance burded was probably the biggest reason. Way too much work for an API which was only used by two apps in Harbour. | 09:04 |
| Thaodan | I only like the plan9 style filesystem | 09:04 |
| Thaodan | api it provided. | 09:04 |
| fridl | No one will answer me, if I would ask when we can officially expect, that the 10 II candidate really is the next device and tell us expected release date, right ;-) | 09:04 |
| flypig | Nico[m], we already had a good discussion about it at a previous meeting, but any tips are appreciated. | 09:05 |
| pvuorela | statefs was pain. often it was d-bus proxy for d-bus interfaces, code that was hard to maintain, context data requests by strings easy to typo, results and errors quite untyped. | 09:05 |
| flypig | And please keep an eye out in the Platform Development section of the forum. I'll make a post there, and as was discussed previously, we'd love to get everyone's input. | 09:05 |
| chriadam | fridl: I have no idea, sorry. | 09:05 |
| Nico[m] | flypig: Well, I don't remember, if it was discussed, but TWIM in the Matrix universe does ig pretty well imo. You basically have one room, where everone posts their updates over the week with a TWIM prefix, and it gets picked up half automatically and then compiled and cleaned up for a blog post | 09:07 |
| fridl | chriadam: sure ;-) | 09:08 |
| flypig | Nico[m], I see your posts there. Neat. | 09:08 |
| Nico[m] | This happens every friday, so of you want to see it in action, I suggest checking it out tomorrow | 09:08 |
| sledges | fridl: currently it's tech. development which will move on to community joining forces on the overall Android 10 hw adaptations | 09:09 |
| flypig | Thanks Nico[m], I'll check it out :) | 09:10 |
| chriadam | half automatically? | 09:10 |
| Nico[m] | Thanks for actually following up on that, I really like TWIM, it helps me motivate myself and advertise cool features :3 | 09:11 |
| sledges | #info back in December Nico[m] suggested we should do some periodic "community updates". We're looking seriously into going ahead with this. Subscribe to "Platform Development" forum section for new topics ;) | 09:11 |
| sledges | we're 6min overdue:) let's press on brakes here | 09:11 |
| rinigus | pvuorela: thanks for insider view on statefs :) | 09:11 |
| sledges | #topic Next meeting time and date (5 min) | 09:11 |
| *** sailbot_ changes topic to "Next meeting time and date (5 min) (Meeting topic: Sailfish OS, open source, collaboration -- 11th February 2021)" | 09:11 | |
| sledges | Proposing Thursday 25th February at 8am UTC | 09:12 |
| Nico[m] | chriadam: Basically benpa has a bot, that reacts to the TWIM message prefix or specific reactions, and automatically adds them to a lisy for a post. He then only needs to proofread and fix up issues. | 09:12 |
| chriadam | sounds useful indeed | 09:12 |
| chriadam | sledges: sounds fine to me, consider +1 | 09:12 |
| santhoshm | @ni | 09:13 |
| santhoshm | Nico[m] TWIM looks cool. | 09:13 |
| sledges | #info Next meeting will be held on Thursday 25th February 2021 at 8:00am UTC: 2021-02-25T08Z | 09:13 |
| sledges | with 45mins to spare before lunchtime in Finland! | 09:13 |
| Zyuc2G | I put in my question regarding GPLv3 too late for this meeting, please don't forget to it to the next one. Thanks! | 09:13 |
| sledges | Zyuc2G: will address your topic in a fortnight | 09:13 |
| Nico[m] | For reference: https://github.com/matrix-org/twim-o-matic is the bot | 09:14 |
| Zyuc2G | thank you | 09:14 |
| sledges | ah, you wrote too:)) | 09:14 |
| chriadam | thanks everyone | 09:14 |
| sledges | give us at least 3 days next time with topics;) cheers! | 09:14 |
| Zyuc2G | will do. Only occurred to me after looking at some git commits ;) | 09:14 |
| sledges | #endmeeting | 09:15 |
| sailbot_ | Meeting ended Thu Feb 11 09:15:05 2021 UTC. | 09:15 |
| sailbot_ | Minutes: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-02-11-07.59.html | 09:15 |
| sailbot_ | Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-02-11-07.59.txt | 09:15 |
| sailbot_ | Log: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-02-11-07.59.log.html | 09:15 |
| flypig | Thanks sledges, everyone. | 09:15 |
| *** sailbot_ changes topic to "Next meeting will be held on Thursday 11th of February 2021 at 8:00am UTC. Topics can be read here: https://forum.sailfishos.org/t/community-meeting-on-irc-11th-feb-2021/4306" | 09:15 | |
| sledges | nextRCsoon(tm) | 09:15 |
| chriadam | gnight | 09:15 |
| Nico[m] | Thanks everyone for your time! | 09:15 |
| fridl | sledges: Nice :-) | 09:16 |
| *** ChanServ changes topic to "Next meeting will be held on Thursday 25th of February 2021 at 8:00am UTC. Topics can be read here: https://forum.sailfishos.org/t/community-meeting-on-irc-25th-feb-2021/4782/2" | 09:34 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!