07:00:48 <flypig> #startmeeting Sailfish OS, open source, collaboration -- 23rd June 2022
07:00:48 <sailbot> Meeting started Thu Jun 23 07:00:48 2022 UTC. The chair is flypig. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:48 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
07:00:55 <flypig> #info Meeting information and agenda can be found here:
07:00:58 <flypig> #link https://forum.sailfishos.org/t/community-meeting-on-irc-23rd-june-2022/11888
07:01:07 <flypig> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please respect the timings and don't touch that dial.
07:01:12 <flypig> #topic Brief introduction (5 min). Please prefix your name/handle with #info
07:01:24 <Nico> #info Nico, community <3
07:01:39 <rubdos[m]> #info Ruben De Smet, community
07:01:47 <abr> #info Andrew Branson, sailor
07:01:52 <rainemak_> #info Raine Mäkeläinen, sailor @ Jolla
07:01:54 <Cryx> #info Cryx - Community   first time ever using this kind of chat, so hint me if I do something wrong...
07:02:06 <flypig> #info David Llewellyn-Jones, sailor @ jolla
07:02:11 <pherjung> #info pherjung, community
07:02:25 <flypig> So far so good Cryx :) And welcome to IRC.
07:04:07 <flypig> Just for info, we have quite a packed meeting today -- lots of great questions -- and we rejigged the order slightly so some people can be here for certain questions.
07:04:35 <ExTechOp> #info Otto Mäkelä, community
07:04:58 <rubdos[m]> Already my sincere excuses for my extremely long epistle of a question.
07:05:09 <jwalden> #info JP Walden, sailor @ Jolla
07:05:20 <Nico> Ruben De Smet, I tried to one up you :D
07:05:24 <fridl> #info fridlmue - community
07:05:34 <flypig> Haha, yes, we have a lot of detail today :)
07:06:22 <ExTechOp> rubdos https://twitter.com/tomgauld/status/960465283537391616
07:06:34 <flypig> I think that's 6-4 to the community today; great work :) Last call...
07:07:00 <flypig> Alright, first up we have your question Cryx.
07:07:04 <flypig> #topic Adding additional Media Codecs to Sailfish OS (5 min -- asked by Cryx)
07:07:08 <flypig> #info <Cryx> Sailfish OS is missing some Media Codecs that are available by default on other systems (both mobile and desktop).
07:07:12 <flypig> #info <Cryx> This results in files being unsupported by SFOS and can't be opend and show an error message about the missing codec.
07:07:19 <flypig> #info <Cryx> For example: Photos taken with other devices and uploaded to Nextcloud aren't viewable in Gallery - in my case these are Photos taken with an iPhone that are in HEIC format. Same thing for videos in H. 265/HEVC.
07:07:26 <flypig> #info <Cryx> And beside that I'd like to see especially Support for *ALAC* (Apple Lossless) as well. As far as I know (didn't do further Research right now) these Codecs could be used for free.
07:07:27 <sledges> #info Simonas Leleiva - nearly made the introductions:)
07:07:37 <flypig> #info <Cryx> So adding them - and maybe other additional Codecs that might be useful - to SFOS by default the whole system would be better up to date and would also offer a better User experience instead of dissapointment because of unplayable media files.
07:07:44 <flypig> #info <Cryx> (Maybe something that's related to missing codecs: Disney+ can't play Videos and ends up with error 39...).
07:07:50 <flypig> #info <Cryx> Wish/Conclusion: Add native supports for following codecs: ALAC; HEIC; H. 265/HEVC
07:07:57 <flypig> #link https://forum.sailfishos.org/t/compiling-gstreamer-plugin/11805/7?u=cryx
07:08:12 <flypig> Thanks for the detailed question Cryx. We have quite a detailed answer too.
07:08:21 <flypig> #info <Jolla> Sailfish OS has two sources of codecs. Generally, all software codecs are built as GStreamer plugins, whether they’re packaged as separate libs, ffmpeg codecs or built-into GStreamer itself.
07:08:30 <flypig> #info <Jolla> We don't allow any license-encumbered codecs in there, e.g. we don't build the 'ugly' set at all. Hardware codecs come from the underlying Android drivers and are exposed to GStreamer through our 'gst-droid' GStreamer plugin.
07:08:44 <flypig> #info <Jolla> Most of these require licenses, which is why we use the codecs from the device rather than bundle our own - they're already licensed for your device.
07:08:55 <flypig> #info <Jolla> H.265/HEVC is not a free codec, but if you have a recent Sailfish X device then you should already have support through a hardware codec (which unfortunately older devices don't support).
07:09:03 <flypig> #info <Jolla> There's a tricky bug to solve in thumbnail generation in the Gallery app though - that only uses software codecs so you won't see a thumbnail but the video should play fine.
07:09:10 <flypig> #info <Jolla> However, that same bug would stop you from viewing HEIC files too.
07:09:14 <flypig> #info <Jolla> ALAC looks more promising as it seems to be available in FFmpeg, though we're not building it in right now.
07:09:22 <flypig> #info <Jolla> We'd have to double check if there are any licensing restrictions for that, and if it's clear (which looks likely) then we could add it for the next release.
07:09:36 <flypig> #info <Jolla> A quick test seemed to work anyway, and prompted by the request we have a PR to add it in.
07:09:39 <flypig> #link https://github.com/sailfishos/ffmpeg/pull/2
07:09:58 <flypig> That's the answer. Does that answer your question Cryx?
07:10:13 <Cryx> Yes, it does.
07:10:18 <rubdos[m]> Makes me wonder whether there's a legal-ish workaround for thumbnails for HEVC et al...
07:10:37 <flypig> Great to hear Cryx. And, I'd add, thanks to abr for the PR and for the nice detail.
07:11:47 <abr> it'd be nice to use the hw codecs somehow, but the reason that's never been a thing is there's a fear that background thumbnail generation could interfere with camera video recording
07:12:16 <abr> perhaps it could be a fallback, or some policy based thing to avoid conflicts. dunno.
07:12:34 <Cryx> From a user point of view it would be great if codecs works out of the box - so standard codecs that are free should be implemented if possible. That was my main thought...
07:12:37 <rubdos[m]> Sounds like quite some engineering work indeed
07:13:10 <flypig> Perhaps tracker should be paused during video recording?
07:13:42 <abr> Cryx: yeah, h265 isn't free at all though. btw, which device do you have? most of the recent ones will have h265 working out of the box
07:14:04 <thilo[m]> abranson: couldnt this be solved by introducing a lock? Background thumbnail generation doesnt need to run while the camera is running?
07:14:42 <abr> yeah that's what i meant by policy. we already have such things for audio and I think camera use too.
07:14:44 <rubdos[m]> Maybe also worth mentioning: H.265/HEVC in software makes probably very little sense to implement, because of the performance requirements. So even as a fallback it's probably not useful anyway.
07:14:52 <abr> flypig: that's nice and simple
07:14:59 <Cryx> I ran into that primary with alac and heic. Dind't really try h.265. I'm on 10 III now.
07:15:26 <abr> though I think tracker doesn't generate the thumbs for anything anymore. but it does do a lot of IO on new files, which is what the camera is creating
07:15:52 <flypig> Ah, thanks for clarifying, I hadn't appreciated that.
07:15:59 <abr> Cryx: ah ok, then it should work, though might look like it doesn't until you actually try to play the file
07:16:24 <Cryx> I'll try ist and report in the forum...
07:16:45 <flypig> We only had 5 mins on this, should we extend?
07:17:00 <abr> think we're done?
07:17:23 <Cryx> I think yes
07:17:28 <flypig> Okay, great. Thanks for the question Cryx. Yours is up next rubdos[m].
07:17:30 <Cryx> means done
07:17:34 <flypig> #topic Update Rust (10m -- asked by rubdos)
07:17:48 <flypig> Quite a long question, bear with me...
07:17:49 <flypig> #info <rubdos> Whisperfish requires Rust 1.56. I don't like to put this forward, but the shipped Rust compiler is getting old. It is currently on version 1.52, which is today one year and one month old.
07:17:56 <flypig> #info <rubdos> This is not usually old in Compiler Land, but sadly, for Rust, it is. There are a few problems with this. I will take Whisperfish for context.
07:18:03 <flypig> #info <rubdos> It's becoming increasingly difficult to deal with Rust 1.52. I fear that in a month or two, we will need to move towards Rust 2021, which is only available as of 1.56
07:18:10 <flypig> #link https://doc.rust-lang.org/edition-guide/rust-2021/index.html
07:18:13 <flypig> #info <rubdos> The reasoning behind this, is that libsignal-client is moving forward, and has transitive dependencies that already moved on to Rust 2021.
07:18:19 <flypig> #info <rubdos> Among these are cryptographic base libraries, for which I'm rather angry that they put these requirements already, given their important position in the whole ecosystem.
07:18:26 <flypig> #info <rubdos> Another reason for a bump of the required Rust version, is that many libraries and dependencies are adopting new features from even before edition 2021.
07:18:31 <flypig> #info <rubdos> Another reason for a bump of the required Rust version, is that many libraries and dependencies are adopting new features from even before edition 2021.
07:18:36 <flypig> #undo
07:18:36 <sailbot> Removing item from minutes: <MeetBot.items.Info object at 0x7f23b9c8e080>
07:18:41 <flypig> #info <rubdos> Among those are Actix (MSRV 1.53), and even libsignal-client itself.
07:18:51 <flypig> #info <rubdos> All of the above, summarized: for Whisperfish to be able to function and keep up with Signal's developments, we require a version bump of Rust to at least 1.56, relatively soon.
07:18:59 <flypig> #info <rubdos> Not updating means not updating libsignal (I'm maintaining a fork now, to patch around new features, but I won't be able to hold that much longer), and not updating libsignal means potentially getting booted from their servers, or losing compatibility with future clients.
07:19:07 <flypig> #info <rubdos> Signal is very lenient in this, and they promise to maintain compatibility for three months, but in reality it's usually more like a year.
07:19:12 <flypig> #info <rubdos> Now, I understand that the Rust version is tied to the Gecko ESR release that Jolla builds for.
07:19:16 <flypig> #info <rubdos> The required Rust version for different Firefox versions are tabulated here:
07:19:18 <flypig> #link https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html
07:19:22 <flypig> #info <rubdos> From that table, it's clear that Jolla doesn't *need* to update Rust in order to get even Firefox 100, so I understand that Jolla does not want to do the heavy lifting unless strictly necessary.
07:19:31 <flypig> #info <rubdos> I'm willing to chip in and bump the versions, but I'd love some feedback on whether Jolla will accept such big changes.
07:19:50 <flypig> Okay, that was the question. We have a prepared answer. It's quite long too, but we'll get there :)
07:19:56 <rubdos[m]> I'm so sorry :'-)
07:19:57 <flypig> #info <Jolla> Thanks for your question rubdos; you shouldn't feel bad about putting it forwards, it’s a great question.
07:20:05 <flypig> #info <Jolla> Whisperfish is one of the few Sailfish OS community apps that relies on Rust, so it’s really helpful and important to get your perspective on its use.
07:20:13 <flypig> #info <Jolla> In addition, as you point out, Rust is needed for the gecko engine that powers the Sailfish browser. Rust isn't an officially supported language on the Sailfish SDK, but of course we want to support developers and would love to see wider use of Rust in the future.
07:20:23 <flypig> #info <Jolla> You’ve very kindly offered to do the heavy lifting, and that's great because unfortunately, in the spirit of openness, we’re unlikely to be able to prioritise this in the near future.
07:20:31 <flypig> #info <Jolla> Getting this change through will still require significant work from Jolla (e.g. reworking the browser build process; testing the results).
07:20:37 <flypig> #info <Jolla> We can’t guarantee any timescales, but we do offer to work as closely as we can with you given resource constraints to help the process through.
07:20:44 <flypig> #info <Jolla> If you’d be willing to start the process, please ask any questions as things progress, and we will be happy to look at any PRs you submit.
07:20:51 <flypig> #info <Jolla> We’d also be interested to work with you to test out the gecko build process with the newer Rust. Our contributions will to be on a best-effort basis for now (I.e. no timescales or guarantees).
07:21:12 <flypig> That's the answer. Hopefully that provides a starting point rubdos[m], but feel free to comment further.
07:21:32 <flypig> We have 10 mins on this.
07:21:33 <rubdos[m]> That sounds like a great starting point, and it also sounds like the answer I wanted to hear, so that's great :-)
07:21:52 <rubdos[m]> Yeh, maybe I should've asked 5 minutes, but that depended on the kind of answer you'd come with.
07:22:11 <flypig> Good to hear rubdos[m]. And it's always better to ask for more time, not less :)
07:22:33 <rubdos[m]> Maybe this: you'll be happy to work as closely as possible; what channels would that be? Mostly the two Github repos?
07:22:33 <Nico> Those 10 minutes were just for posting the wall of text :3
07:22:41 <flypig> True :D
07:23:10 <flypig> Do you have what you need to start things off rubdos[m], or would you need Jolla to do anything first?
07:23:23 <rubdos[m]> I'm asking because the last few issues I opened didn't get a lot of attention. Granted, they were mostly showing off my naiveness on the whole SB2 build system and its integration with Rust.
07:23:47 <rubdos[m]> flypig: I think I can start off. My understanding is that Jolla takes whatever they can from the rpm specs of Fedora, and patches things on top.
07:24:55 <flypig> I wasn't involved in the Rust packaging, but if that's what it looks like... Concerning traction with PRs, you may well have to be patient, and occasionally push a bit.
07:25:27 <Nico> Worst case just make a new community meeting topic with "these are my open PRs, please review" ;p
07:25:41 <rubdos[m]> ack. Maybe I can ask Jolla a favour, and have a look at the three issues I have open. I think they can all be closed, but then at least someone could be "the responsible"?
07:25:47 <rubdos[m]> Nico: Good point
07:26:07 <flypig> rubdos[m], do you have links to hand for the minutes?
07:26:15 <rubdos[m]> sure
07:26:35 <rubdos[m]> #link https://github.com/sailfishos/rust/issues/4
07:26:39 <rubdos[m]> #link https://github.com/sailfishos/rust/issues/11
07:26:44 <rubdos[m]> #link https://github.com/sailfishos/rust/issues/12
07:26:54 <rubdos[m]> Oh the first one is from thigg, sorry about that.
07:26:59 <flypig> #info rubdos[m] requested that Jolla review these ^^ open issues.
07:27:12 <rubdos[m]> but yes, please also review the one from thigg :-)
07:27:20 <flypig> That works :)
07:27:24 <rubdos[m]> open, stale issues don't look nice.
07:27:32 * rubdos[m] looks away from the Whisperfish tracker
07:27:46 <flypig> :D
07:28:07 <flypig> Okay, anything else for the minutes, or comments? Otherwise we should move onwards.
07:28:26 <rubdos[m]> I think we can move on, I've got my answers :-)
07:28:29 <rubdos[m]> Thanks!
07:28:35 <flypig> Great, thanks rubdos[m].
07:28:41 <Nico> You might want to shorten my topic
07:28:56 <flypig> We're not quite there yet Nico, but noted.
07:28:57 <flypig> #topic 4G should work on both SIMs simultaneously (5 min -- asked by remote)
07:29:03 <flypig> #info <remote> Sailfish OS doesn't support 4G on both SIM slots, Android (and HW) does. So why do we have this artificial limitation and when will Sailfish OS allow both SIMs run in 4G?
07:29:06 <thilo[m]> :D i didnt even remember that i opened that issue ;)
07:29:36 <flypig> A one line question. Nice :) The answer is short and to the point too.
07:29:41 <flypig> #info <Jolla> We have an internal task about this issue and it has been worked on; unfortunately on some devices running 4G on both slots does cause issues for the modem on some devices, and it's currently not clear why.
07:29:49 <flypig> #info <Jolla> This needs to be addressed before we can enable it and this is why the limitation has been introduced. It is something that we are looking into however.
07:30:24 <flypig> That's the answer. Is remote here today?
07:31:51 <Nico> What devices are affected by that? Is 4G on both slots disabled on all devices unconditionally, even if that issue only affects a few devices?
07:33:13 <flypig> I don't have an answer to that I'm afraid. Maybe another sailor does? My understanding is that at least the 10 II is affected, but I could be wrong.
07:33:47 <Nico> Damn, so my device!
07:33:50 <Nico> Thanks :3
07:34:10 <flypig> Well, like I say, I could be wrong, so don't take what I say too strictly!
07:34:26 <Nico> Already have written it down, it is law now
07:34:35 <flypig> :(
07:35:25 <flypig> I think remote isn't here, so should we move on? Any other comments welcome.
07:36:02 * Nico has written up a shorter version of his topic
07:36:34 <flypig> Okay, moving on then.
07:36:38 <flypig> #topic Community Bug Coordination Team summary (5 min -- asked by pherjung)
07:36:45 <flypig> #info <pherjung> A summary of the results from the Community Bug Coordination Team's activity during the last fortnight.
07:37:02 <flypig> #info <Jolla> The Community Bug Coordination Team have done a superb job once again this fortnight.
07:37:07 <flypig> #info <Jolla> As a result of their work, we now have:
07:37:12 <flypig> #info <Jolla> - An addition 10 high quality bug reports now recorded internally and tagged as "tracked".
07:37:17 <flypig> #info <Jolla> - Four bug reports tagged as "fixed".
07:37:22 <flypig> #info <Jolla> - Two duplicate bug reports closed
07:37:26 <flypig> #info <Jolla> - One bug report that was tagged incorrectly now tagged as "tracked".
07:37:35 <flypig> #info <Jolla> - One thread moved out of the bug report category.
07:37:44 <flypig> Superb work once again; thank you CBCT!
07:38:07 <Nico> Yay!
07:39:32 <flypig> I have a quick question concerning the last of these bugs. Rather than tag it, I just moved it to a different category. Will that avoid it causing trouble for the scripts in future?
07:40:12 <flypig> Nico, maybe it was you that looked at that one?
07:41:03 <pherjung_> Well, we don't use a script :)
07:41:14 <Nico> Uhhh, was it? Was it the one with the lots of discussion that I commented on about being just noise? :D
07:41:45 <flypig> Nico, yes, exactly. And sorry pherjung_, my mistake :)
07:41:49 <Nico> Anyway, if it causes issues with scripts, that is just a bug we should fix, if there are any ;p
07:42:04 <pherjung_> I usually use a small bash script downloading all bugs from our list and check their tag
07:42:09 <Nico> flypig, neat :3
07:42:16 <pherjung_> so, it's even good to move the category
07:42:20 <flypig> I moved it from Bug Repots to General.
07:42:33 <pherjung_> it was exactly what I thought
07:42:55 <flypig> Okay. If it needs any more action in future, then ping me :)
07:42:56 <pherjung_> There are still some bug reports that are pending
07:43:12 <Nico> 👍
07:43:12 <pherjung_> I'll add them for the next meeting, it's the easiest way
07:43:27 <pherjung_> (was some duplicates bug reports)
07:43:35 <flypig> pherjung_, are those the duplicates from the last meeting? I'm afraid I didn't have a chance to follow them up.
07:43:43 <pherjung_> no problem
07:43:56 <pherjung_> they'll follow you until they're get closed hahaha
07:44:09 <flypig> :D
07:44:25 <pherjung_> other point: some bug reports only appears in some special conditions and disappear once the user flash his phone again
07:44:46 <pherjung_> For such bug reports, I think we can just tag them as pending
07:45:10 <flypig> That's tricky. I agree it can be hard to know how to tackle them.
07:45:25 <pherjung_> And if someone encounter the same problem, then it can be filled in your internal bug tracker
07:46:09 <flypig> Okay, that sounds reasonable. You probably have to use your judgement with some of them. But I'm happy to mark them as pending if that helps.
07:46:38 <pherjung_> For instance this one: https://forum.sailfishos.org/t/saved-alarms-and-timers-disappearing-after-reboot/11066
07:47:17 <pherjung_> flypig: Is the process still good for you?
07:47:25 <pherjung_> Something to improve?
07:47:34 <flypig> #info <pherjung_> some bug reports only appears in some special conditions and disappear once the user flash his phone again. I think we can just tag them as pending. For instance:
07:47:40 <flypig> #info https://forum.sailfishos.org/t/saved-alarms-and-timers-disappearing-after-reboot/11066
07:47:59 <flypig> pherjung_, the process is still working for me, yes. Thank you for asking. I say we continue :)
07:48:07 <pherjung_> cool
07:48:21 <flypig> Thanks as always for the whole team's efforts.
07:48:39 <flypig> I suggest we move to Nico's epic question.
07:48:43 <fridl> Yeah, thanks!
07:48:53 <Nico> Do you want my shortened version?
07:49:06 <flypig> I already cut it down a little, but I think the info you put in is useful.
07:49:08 <flypig> #topic Updating kf5bluezqt - MediaTransport conflict (15min -- asked by Nico)
07:49:15 <flypig> #info <Nico> Jolla intends to deprecate QBluetooth (part of QtConnectivity) usage in Sailfish
07:49:16 <Nico> Oki
07:49:19 <flypig> #link https://forum.sailfishos.org/t/deprecation-notice-bluez-gnutls-qtconnectivity-qtsysteminfo-repomd-pattern-builder/
07:49:27 <flypig> #info <Nico>Some applications currently use this to talk to advanced bluetooth gadgets. One of them is OBDFish:
07:49:31 <flypig> #link https://github.com/explit7/OBDFish
07:49:37 <flypig> #info <Nico> I wanted to update that application to use kf5bluezqt, since doing raw Dbus calls is not something I am comfortable with. The characteristics stuff in kf5bluezqt should be usable as a replacement for QBluetoothSocket.
07:49:44 <flypig> #info <Nico> This was however added after the 5.50 version currently available in Sailfish.
07:49:57 <flypig> #info <Nico> While that package was updated in February, it was only updated to 5.50, since newer version add a MediaTransport API which the Sailfish package added independently as a patch.
07:50:04 <flypig> #info <Nico> I would like to figure out how to move forward with that conflict to get a newer kf5bluezqt before QBluetooth is removed.
07:50:12 <flypig> #info <Nico> Ideally we could just switch to the upstream implementation of MediaTransport, but this doesn't expose some properties Sailfish does and some things have different names.
07:50:17 <flypig> #info <Nico> You can find my current work in progress upgrade to 5.82.0 here:
07:50:20 <flypig> #link https://github.com/deepbluev7/kf5bluezqt
07:50:36 <flypig> We have quite a long response too. Do you want to add anything first Nico?
07:51:09 <Nico> Maybe that I figured out that I don't need the characteristics stuff for this particular dongle and I do have it working without the upgrade now :D
07:51:23 <ExTechOp> :-D
07:51:23 <Nico> Buuuut and upgrade of that package is probably a good thing still :3
07:51:28 <flypig> I did notice your message about it on the forum. That's great news :)
07:51:51 <flypig> Okay, let me give our prepared answer then.
07:51:54 <flypig> #info <Jolla> First of all, kudos for taking the plunge and updating your application, and for the nice work you've already done looking into kf5bluezqt.
07:52:01 <flypig> #info <Jolla> Just to clarify a point to avoid any confusion, the current version of kf5bluezqt on Vanha Rauma is 5.24.0.
07:52:08 <flypig> #info <Jolla> It has since been updated to 5.50.0 on our internal development branch (i.e. in the repositories) but this won't go out to devices until a later release.
07:52:15 <flypig> #info <Jolla> For reference, the 5.24.0 version currently on devices:
07:52:19 <flypig> #link https://github.com/sailfishos/kf5bluezqt/tree/4e8986ee4faaff717185f69f49d6ed4c7191c75a
07:52:22 <flypig> #info <Jolla> The latest version 5.50.0 for a future Sailfish release:
07:52:26 <flypig> #link https://github.com/sailfishos/kf5bluezqt
07:52:29 <flypig> #info <Jolla> The latest upstream version 5.95.0 (mirror):
07:52:32 <flypig> #info <Jolla> #link https://github.com/sailfishos-mirror/bluez-qt
07:52:38 <flypig> #info <Jolla> We’d also like to upgrade to the latest release. The reason we haven't yet is for the reasons you've cited: that the best path to the latest release while retaining the Sailfish specific modifications isn't clear.
07:52:46 <flypig> #info <Jolla> This means that switching directly to upstream isn't possible and some work is needed to patch the code.
07:52:52 <flypig> #info <Jolla> We’d like to work with you to perform the upgrade, but this will depend on availability on both sides (and especially not everyone will be available at all times during the summer).
07:52:58 <flypig> #info <Jolla> We had a look at your changes to move up to 5.82.0 and you’ve already made a good start.
07:53:05 <flypig> #info <Jolla> It's hard to comment on the changes in generality, but if you have specific questions, then if you ask them here, we will do our best to follow up and discuss with the relevant Sailors (if they're not already present today).
07:53:13 <flypig> #info <Jolla> It would also help if you could create a PR of your changes into the Sailfish repository, even as a WiP PR if it’s not yet in mergeable form.
07:53:33 <flypig> That's the answer. Feel free to round things out Nico.
07:53:41 <Nico> Oki, sounds good
07:54:01 <Nico> I think I mostly had 2 questions specifically about the differences
07:54:16 <Nico> Me grabs some links for the audience
07:54:42 <flypig> Can you prefix "#info" to relevant bits for the minutes please?
07:54:43 <Nico> Jolla properties for the media stuff: https://github.com/deepbluev7/kf5bluezqt/blob/7a7473bc87fc3a7c78b3028f432c77fdf2bc4ded/rpm/0002-Add-MediaTransport-org.bluez.MediaTransport1-wrapper.patch#L342
07:55:08 <Nico> Hm, I'm not sure yet what is relevant :D
07:55:17 <flypig> No worries, I can pick some stuff out.
07:55:39 <flypig> #info <Nico> Jolla properties for the media stuff:
07:55:42 <flypig> #link https://github.com/deepbluev7/kf5bluezqt/blob/7a7473bc87fc3a7c78b3028f432c77fdf2bc4ded/rpm/0002-Add-MediaTransport-org.bluez.MediaTransport1-wrapper.patch#L342
07:55:46 <Nico> Upstream list of properties: https://github.com/sailfishos-mirror/bluez-qt/blob/e10c3a398b0571dcdf4866091bffbbace3899345/src/mediatransport.h#L31
07:56:05 <flypig> #info <Nico> Upstream list of properties:
07:56:08 <flypig> #link https://github.com/sailfishos-mirror/bluez-qt/blob/e10c3a398b0571dcdf4866091bffbbace3899345/src/mediatransport.h#L31
07:56:09 <Nico> As we can see Jolla mostly exposes a few more properties and one enum is named differently
07:56:17 <Nico> Are those actually in use?
07:57:22 <Nico> But that shouldn't be that hard to add upstream
07:57:51 <flypig> That would probably need looking in to. I guess it's impossible to say whether they're used by apps in harbour, say
07:58:10 <Nico> Well, that API is not allowed in harbour :D
07:58:23 <flypig> Sorry, quite right. I meant OpenRepos.
07:58:31 <Nico> That's true
07:58:56 <Nico> I guess it makes the most sense to just open the PR and discuss the specifics there
07:59:26 <Nico> Another issue is that MediaTransport upstream uses TPendingCall instead of PendingCall, which would cause ABI issues
07:59:28 <flypig> Well, it's good that you raised it here. The question is clear, but the answer... I think querying it on a PR would be a good way to go.
08:00:02 <Nico> Mhm, I'll write it up properly on the PR then :3
08:00:41 <flypig> Perfect. Maybe check dependencies on QtBluez using pkcon/zypper to see if those features are used?
08:01:10 <Nico> I think a problem there will be that openrepos are... multiple repos :D
08:01:32 <flypig> Are, I meant for the default device install..
08:01:36 <Nico> But I can probably do that for the not so open repos
08:01:52 <Nico> Yeah, I will do that
08:02:20 <Nico> I think in general kf5bluezqt is a nicer API to work with once you figure out how it works
08:03:16 <flypig> That's good to hear. Do you mean nicer than QtBluetooth, or nicer than bluez5 Dbus?
08:03:24 <Nico> Both :D
08:03:34 <Nico> It is just a typed layer for bluez5 dbus
08:03:46 <Nico> So it gives you qml models and such by default
08:04:00 <flypig> Okay, nice. I've not used kf5bluezqt, so that's useful to know.
08:04:34 <Nico> But doesn't have quite as many abstractions as QBluetooth, which means it is easier to map to what it does on bluez and also gives you more flexibility
08:04:54 <Nico> Only downside is cross-platform compatibility of course :3
08:05:37 <Nico> One thing I had to learn is that you actually need to register a Profile now for bluez to connect you to some things
08:05:46 <Nico> Which explains why I couldn't do it from the CLI
08:06:00 <Nico> But yeah, I'll open a PR then
08:06:15 <Nico> Only question then will be, if that API will ever be allowed on harbour :3
08:06:51 <flypig> For info, running "zypper se --requires kf5bluezqt" throws up about seven or so packages.
08:07:01 <Nico> That sounds doable
08:07:07 <flypig> Yeah, not so many.
08:08:07 <flypig> I think your harbour question will have to be for another meeting :)
08:08:13 <Nico> I guess the transferengine will be what needed the MediaTransports
08:08:28 <Nico> flypig: Sure :3
08:08:41 <flypig> We've hit time on this. Any final comments, or additions for the minutes?
08:08:49 <Nico> Is there sources available for the transferengine?
08:09:38 <Nico> I guess you can add that I will open a PR to discuss the codey bits, otherwise I am good
08:09:59 <flypig> I think transferengine source isn't public.
08:10:16 <Nico> I'll reverse engineer what functions it calls then .-.
08:10:20 <flypig> If you add a request to the PR, or message me, I can try to help with that.
08:10:27 <Nico> Oki
08:10:55 <flypig> #info <Nico> I will open a PR to discuss the codey bits, otherwise I am good
08:11:04 <Nico> :D
08:11:20 <flypig> Thanks for the question Nico. Let's go to General discussion.
08:11:21 <flypig> #topic General discussion (15 min)
08:12:10 <Nico> So after I spent so much time in the car talking to OBD2, my dad also wanted me to fix his phone not vibrating when the volume is turned up
08:12:31 <Nico> It seems that the ringtone haptics effect type doesn't work?
08:12:46 <Nico> Has anyone else experienced that?
08:13:52 <Nico> (I worked around it by just redefining it as an alarm in the nf-random letters daemon config)
08:14:04 <flypig> How to check that?
08:14:17 <Nico> 1. Set viration to always
08:14:25 <Nico> 2. Turn up ringtone volume
08:14:36 <Nico> 3. get a call
08:14:58 <flypig> Okay, 1 and 2 were easy, 3 will require more work :)
08:15:08 <Nico> The phone should vibrate
08:15:24 <flypig> Should but doesn't, on an X 10 II?
08:15:30 <Nico> I didn't file a bug yet, since I did that yesterday in the middle of the night not at home
08:15:40 <Nico> No, that was an Xperia X
08:15:57 <Nico> But I think I experienced the same on my 10 II, didn't test it yet though
08:16:24 <Nico> (Again, it was this night)
08:16:38 <flypig> If you fixed it by redefining the ringtone, then it sounds like it may be by design.
08:16:51 <flypig> although, I'm not sure why that would be.
08:17:07 <Nico> Well, I changed the haptics type in some config file
08:17:35 <Nico> Ah, maybe my dad had a weird ringtone
08:17:40 <flypig> If you really think it's a bug, and also have a solution, you may find creating a PR generates more discussion about it.
08:18:08 <Nico> I haven't yet checked what repo that would be, but that should be doable :D
08:18:17 <Nico> I'll do some more experiments
08:18:36 <Nico> It might be that certain ringtones don't work with that haptics effect
08:18:47 <flypig> It's definitely good if you can get to the bottom of it.
08:18:51 <Nico> Maybe if they have a very short duration and loop quickly
08:19:30 <Nico> It was a fun evening exercise, I didn't think I would find a workaround, but I did :D
08:19:38 * Nico is pretty happy about that
08:19:50 <flypig> I'm impressed :)
08:20:31 <rainemak> I like that Nico's "these are my open PRs, please review" ? Maybe we could have a slot at the end?
08:20:33 <Nico> That's the good thing about having an OS with a terminal program and text config files :3
08:21:17 <Nico> rainemak, wouldn't that be mean to jolla? .-.
08:22:03 <flypig> It'd certainly keep things on the agenda.
08:22:37 <flypig> We could do that for future meetings: have a topic to discuss open PRs?
08:22:38 <Nico> I usually try to avoid telling people, that they don't review my stuff. And PRs Jolla usually gets to after a month or so, so it isn't that bad
08:23:05 <fridl> we could have it as dedicated category in the announcement as an agenda topic. And perhaps we could restrict it to PRs that have not been reviewed for a certain time?
08:23:06 <rainemak> I'd not start reviewing PRs per se, just raise the PRs up and let's figure right attention level for the PRs that there on the list
08:23:32 <flypig> Right, so really just to raise the profile and avoid things getting missed.
08:23:40 <rainemak> all open PRs cannot really be listed at the end of the meeting
08:23:45 <Nico> Mhm, I think in general having an overview of what PRs the community would like to see attention with might be good
08:24:03 <rainemak> Exactly
08:25:28 <flypig> fridl, having it as a category in the announcement sounds good to me. But then, let anyone add a commit to the list prior to the meeting?
08:26:34 <flypig> Or, should we create our own list from the oldest PRs for the next meeting?
08:27:26 <Nico> Well, it probably makes sense for the community to bring up the ones they want attention on
08:27:31 <fridl> I would do it like with the question, but people can submit PRs they would love to see a commented.?
08:27:41 <Nico> That way they might also be available to discuss what is blocking it
08:28:08 <fridl> And probably a restriction like the PR has to be open longer than 6 weeks or something?
08:28:23 <Nico> Or no changes for 3 weeks?
08:28:52 <flypig> We can start with 3 weeks and maybe adjust it if we have too many/few?
08:29:23 <fridl> Yeah, I just came up with some number ;-) 3 weeks sounds great :-)
08:30:11 <flypig> Okay, I'll add a note to the next meeting announcement encouraging people to submit PRs they want to see movement on.
08:30:24 <Nico> Sounds good
08:30:38 <Nico> Nice to see such a development focused meeting :D
08:30:49 <flypig> Yeah, nice idea rainemak.
08:30:57 <flypig> Everyone here must submit your favourite PR.
08:31:02 <fridl> We get a lot of structure these days with the meetings. CBC-Team, PRs. Nice!
08:31:18 <flypig> Not too much structure?
08:31:56 <fridl> I think it is very targeted and streamlined structure. So its good IMHO.
08:32:03 <Nico> fridl: Now we need to add the qt topic as a regularly repeating entry and everything is covered!
08:32:22 <fridl> Nico: haha, yes.
08:32:28 <flypig> Haha :) And good to have the feedback fridl.
08:32:46 <flypig> Talking of structure, we hit time on this agenda item I'm afraid, so we're wrapping up.
08:33:04 <Nico> Time for lunch :3
08:33:15 <rubdos[m]> lunch, at this time of the day? :o
08:33:17 <flypig> #action flypig to add a "Pending PR" request to the community meeting announcement.
08:33:20 <flypig> Excellent. Good to have the feedback fridl.
08:33:31 <flypig> #topic Next meeting time and date (5 min)
08:33:36 <flypig> Proposing Thursday 7th July at 07:00am UTC
08:33:51 <Nico> Pending PR? Public relations? ;p
08:34:05 <flypig> :D
08:34:36 <flypig> All good for that date? Enough time to subit your PRs?
08:34:42 <Nico> Anyway, meeting is good, as always. Although I had to set an alarm and am pretty tired now
08:34:48 <Nico> *meeting date
08:35:12 <flypig> Thanks Nico, and sorry for the sleep deprivation.
08:35:16 <flypig> Going with that then.
08:35:19 <flypig> #info Next meeting will be held on Thursday 7th July 2022 at 07:00am UTC:  2022-07-07T0700Z
08:35:30 <ExTechOp> Thank you everyone!
08:35:36 <flypig> #endmeeting