07:00:04 #startmeeting Sailfish OS, open source, collaboration -- 13th April 2023 07:00:04 Meeting started Thu Apr 13 07:00:04 2023 UTC. The chair is ViGe. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic. 07:00:09 #info Meeting information and agenda can be found here: 07:00:12 #link https://forum.sailfishos.org/t/community-meeting-on-irc-13th-april-2023/15242 07:00:16 I am the meeting's chairperson today, and will be doing my best to keep time and order. Please respect the timings and bee-hive. 07:00:19 #topic Brief introduction (5 min). Please prefix your name/handle with #info 07:00:46 #info Ville Nummela - sailor@Jolla and chairperson today 07:01:06 #info Otto Mäkelä, community 07:01:08 #info LSolrac - comunity 07:01:31 #info Simonas Leleiva -- privateer for Jolla 07:01:41 #info Andrew Branson - sailor 07:01:42 #info Raine Mäkeläinen - sailor @ Jolla 07:02:28 #info Crabster - lurker @ meeting 07:04:24 Looks like a win for team Sailors, at least if I can count correctly 07:05:07 #topic Support for passing QR-read Wifi information to Networksettings (3-5 min -- asked by nephros) 07:05:10 #info There have been some efforts to make it possible to support `wifi:` strings as used in QR codes for network configuration. 07:05:14 #info In case there is interest at Jolla, please use the github repo for any comments, and if you like, `git apply https://raw.githubusercontent.com/nephros/wifi-qr-handler/master/patch/unified_diff.patch`. 07:05:18 #info Discussion: https://forum.sailfishos.org/t/codereader-cannot-use-wifi-code-not-supported/15193 07:05:21 #info Some code: https://github.com/nephros/wifi-qr-handler 07:05:31 And the answer: 07:05:34 #info The wifi handler looks like a nice start, but on the details this wouldn’t be necessarily how we’d like this implemented. 07:05:38 #info 1) not sure should the handling be in the settings app (not nice acumulating more and more to the d-bus api of the generic settings framework) or rather the connection dialog, 07:05:43 #info 2) the patch doesn’t enable the QR code network adding from anywhere (suppose that’s called from third party app then), 07:05:46 #info 3) the QR code shouldn’t be included in the details of network addition requests, rather the caller should consume QR code details and proceed with plain network properties. 07:07:42 nephros isn't here, and neither is attah :( 07:08:49 Would it be acceptable to reimplement the patch to link to the native connection prompt and be automatically filled? 07:10:01 Hard to say 07:10:18 Let's move on to next question, also by nephros 07:10:23 #topic Community contributions to Jolla closed components (10 min -- asked by nephros) 07:10:27 #info Over the years, there have been several modifications done to Jolla-distributed apps by community hackers. 07:10:30 #info (Sometimes distributed as so-called Patchmanager Patches, sometimes as separate packages, or just locally). 07:10:33 #info While many of these have been hacks and other modifications not suitable for inclusion in the original apps, often they are fixes to small annoyances, bugs, or provide additional features. 07:10:37 #info Some of the latter category may warrant inclusion in the original app or component. 07:10:40 #info Just for sake of discussion I'll select the following some examples: A small but useful new feature: Sandbox Indicator https://coderus.openrepos.net/pm2/project/patch-sandbox-indicator - 500+ activations. 07:10:44 #info Annoyance fix: Allowed Orientation patch https://coderus.openrepos.net/pm2/project/sailfishos-default-allowed-orientations-patch - 1800+ activations. 07:10:47 #info A new/missing feature: wifi-qr-handler - as discussed in the other meeting topic. 07:10:50 #info Now for the questions (note that they do not mean the examples above explicitly, but in general): 07:10:53 #info 1. Is there interest from Jolla, and a conceivable way to upstream some of those? 07:10:57 #info 2. If yes, what would be the preferred avenue of communication from the community to Jolla? 07:11:00 #info 3. If yes, what are requirements from Jolla to consider inclusion? 07:11:04 #info If there is interest, I would propose something similar to the Bug Coordination team who would vet any community-nominated candidates against Jolla requirements, and propose them in a way similar to we do it with bugs or PRs now. 07:11:17 #info 1. From this particular set of patches we probably wouldn’t be merging any. 07:11:22 #info Sandbox should be enabled more or less always and the user shouldn’t need to care. 07:11:26 #info The orientation is overriding the Silica apis and breaks their expectations. 07:11:31 #info The wifi handler needs a bit more work and architecture adjustments. 07:11:36 #info However that wouldn’t mean there couldn’t be  other community contributions to consider merging mainline. 07:11:41 #info 2 & 3. We have already some precedent on enabling community to work on the closed components. This requires contribution agreement etc for the contributor. 07:13:15 Thats rather nice to hear. However, I'd like to ask, on behalf. Could Jolla provide some feedback regarding what kind of work and adjustments a patch may need to be considered? 07:13:47 Of course 07:14:11 The usual pull request review process includes that :) 07:14:12 I think the patch devs would appreciate that quite a bit. It can also shed light for future patches. 07:14:21 Even better~ 07:15:31 Making the "wide spacebar" a switchable part of the default keyboard would be nice :-D 07:16:04 I completely agree, at least as a setting would be nice as well 07:19:25 Time to move on to the next question, which was asked by remote, who is also not here today 07:20:11 #topic can we get Filter pulley menu in Messages app to search by a contact name/phone? (3 min -- asked by remote) 07:20:14 #info sometimes I have to scroll for way too long to reach the conversation I need 07:20:26 And here is the answer: 07:20:29 #info Searching on Messages is indeed a feature to consider. And in fact we have an open item for that from the very beginning of the project. 07:20:32 #info However cannot give any estimates we’d get around to implement it. 07:20:35 #info So far this feature hasn’t seem to be requested that much, but noted that it is now. 07:22:28 Search by Text, Contact or Date would be incredibly useful 🤔 07:22:40 yup 07:23:03 Time for the last question, asked by rinigus. Who is also not present today. 07:23:09 #topic GCC update (10 min -- asked by rinigus) 07:23:12 #info We are currently on GCC 8 which is showing its limitations. 07:23:15 #info It would make sense to take GCC update into the pipeline. 07:23:18 #info Any plans regarding it? 07:23:19 #info Corresponding bug report: https://forum.sailfishos.org/t/gcc-update-from-gcc-8/15144 07:23:23 #info No, we don’t have any plans at the moment. 07:23:26 #info Updating gcc is a relatively big effort, which includes a lot of testing. 07:23:29 #info On the other hand, we are not aware of any blockers preventing us from updating. 07:24:04 that update would be handy. just got hit by c++20 requirement of angelfish as well 07:24:13 rinigus: Oh, you are here! 07:24:30 in principle, those core components have to be updated. glibc as well 07:24:49 (trying to reply when I can) 07:25:12 rinigus: I would assume that it will be updated eventually. But like said, there are no plans, so we can't give any estimates on when that might happen. 07:25:12 maybe gcc can be squeezed in into the pipeline? 07:25:43 means rinigis will ship it in /opt in a week or so :D 07:26:05 ViGe: then let's try to get that into the plans? 07:26:42 piggz: its far from optimal. means that we will not use sb2 - so compilation will be slow for everything. its possible, but painful 07:27:23 note that Qt6 - which we may ship in /opt - requires newer gcc as well 07:30:04 so, to reformulate - how can we ask Jolla to add gcc update into the plans? 07:30:36 rinigus: Well, I think there's really not much more you can do than to ask here, which you already did. 07:31:15 Would a seperate "runtime" (like Qt 5.15 's case) be a viable option? I'm assuming a few libs would be duplicates 07:32:08 ViGe: all whats missing is a reply: "request noted and will be added to the plans" :) 07:32:44 I can't promise anything added to any plans. But the request has been noted. 07:33:07 Solrac: it is an option and I did it for previous gcc update - shipped it in /opt/gcc. but that means all compilation goes via qemu on OBS and it is slow for aarch64 / armv7 07:33:33 which maybe our most realistic path for now 07:33:33 ViGe: thanks! 07:33:54 Time's up for that one, let's move on 07:33:59 #topic Open PR discussion (5 mins -- asked by jolla) 07:34:02 #info Any open PRs to discuss? 07:34:55 btw. That line basically means that there were no PRs mentioned on the forum 07:38:08 #topic Untracked bug reports (5 min -- asked by Community Bug Coordination Team) 07:38:11 #info Our regular Community Bug Coordination Team update - see the forum for the links to actual bug reports 07:38:15 #info As always, The Community Bug Coordination Team have done a superb job. 07:38:19 #info As a result of their work, we now have 7 high quality bug reports now recorded internally and tagged as "tracked". 07:43:08 #topic General discussion (20 min) 07:44:42 with the success of docker based build env, when compared to sb2, I started to wonder if jolla has any plans for arm64 native build nodes at OBS? do you have such nodes in your closed OBS? 07:47:15 I'm not aware of any such plans. 07:48:22 what about your closed/private OBS? As far as I remember, suse has such nodes in their obs - so it should be supported 07:49:42 we don't have native nodes 07:50:07 Keto and ViGe : thanks for info. 07:51:34 Has any progress been made on debugging loss of sounds? https://forum.sailfishos.org/t/4-1-0-23-4-0-1-48-4-4-0-64-4-5-0-16-no-notification-sounds-ringing-sms-alarm/4886 07:52:28 I guess it could be an option, but it's probably better that it is close to the local build env. so that there isn't cases that something builds locally but doesn't build on obs, or the other way around 07:54:18 ExTechOp: not really. Some work has been done on reducing the amount of feedback sounds played, which should help. But the root cause hasn't been found. 07:55:06 Keto: while compiling Qt5.15 libs, we stumbled on several sb2 bugs. all noted at the forum 07:55:35 in the end, qtwebengine has to be built outside of sb2 - probably due to sdk sitting on a top of i386 07:55:36 Keto: I agree. I would rather have our SDK moved to 64 bit architecture, which should help at least some issues that rinigus is having. 07:56:50 note that other projects (flatpak for example) have moved to native builds entirely. cross-compilation can have some issues and we are just spending lots of time time fighting them 07:58:01 qemu has its own bugs too - for example armv7 on 64bit qemu can mess up filesystem link. have to use 32bit qemu (from jolla's sdk) to work around it 07:58:28 oh I did enjoy those weird file permission problems :) 07:58:31 so, while moving sdk to 64 bit is good, it maybe insufficient for all cases 07:58:49 sb2 bug creating files with permission 000 08:01:38 rinigus: then again, 64 bit SDK would help also other cases, which any OBS changes would not. e.g. issues on running the SDK on Windows. 08:02:23 there are probable cases for both? sdk for most users, and a more advanced option? 08:02:57 piggz[m]: Yeah, you are right, these are not mutually exclusive things. 08:03:15 But perhaps it's time to start wrapping up 08:03:23 #topic Next meeting time and date (5 min) 08:03:29 Proposing Thursday 27th April at 07:00am UTC 08:07:01 I don't hear any objections 08:07:06 #info Next meeting will be held on Thursday 27th April 2023 at 07:00am UTC: 2023-04-27T0700Z 08:07:23 Thanks for the meeting everyone! 08:08:04 #endmeeting