09:02:50 <abranson> #startmeeting Sailfish OS, open source, collaboration – 12th December 2019
09:02:50 <merbot`> Meeting started Thu Dec 12 09:02:50 2019 UTC.  The chair is abranson. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
09:02:50 <merbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:03:30 <abranson> oh dear
09:04:07 <flypig> Broken bot?
09:04:17 <abranson> or it's not listening to me
09:04:20 <ViGe> it is
09:04:28 <ViGe> but it's replies are not visible here
09:04:41 <ViGe> they are visible in the bots own log
09:04:44 <Nico[m]> Is it not logged in?
09:04:53 <ViGe> http://merproject.org/meetings/mer-meeting/2019/mer-meeting.2019-12-12-09.02.log.txt
09:05:13 <abranson> well, if it'll still generate the minutes then that's fine. we can wing it with the topic
09:05:28 <abranson> #info Meeting information and agenda can be found here:
09:05:28 <abranson> https://lists.sailfishos.org/pipermail/devel/2019-December/008965.html
09:06:18 <abranson> I’m chairing this meeting today! I'll be trying to keep time and order.
09:06:28 <abranson> #topic Brief introduction (5 min). Please prefix your name/handle with # info
09:07:09 <Kaffeine> #info Alexander Akulich - Telepathy developer
09:07:17 <ViGe> #info Ville Nummela - sailor@jolla
09:07:24 <Nico[m]> #info Nico - community member
09:07:47 <flypig> #info David Llewellyn-Jones - sailor @ Jolla
09:07:50 <ljo> #info Leif-Jöran Olsson, community
09:07:53 <abranson> #info Andrew Branson - sailor at Jolla and first time chair!
09:08:09 <vknecht> #info Vincent Knecht - community
09:08:14 <M4rtinK> #info Martin Kolman - community member & modRana developer
09:08:29 <dcaliste> #info Damien Caliste, community (read-only today :)
09:12:05 <abranson> ok, i think there are some people not able to speak, and the bot's given up completely. but let's carry on regardless :)
09:12:34 <abranson> #topic Introduce (some more) packaging conventions (Asked by Kaffeine - 10 mins)
09:12:50 <abranson> #info we have a lot of layouts and approaches in (external, not MER) projects packaging. To name a few, we have: 1. "rpm dir + 'upstream' git submodule", 2. "rpm + upstream submodule + a dir with extracted and patched sources", 3. "spec + tarball" (not in OBS, but right in the packaging git repo), 4. "rpm + git subtree with applied patches", 5... .
09:12:50 <abranson> #info As far as I understand, the modern approach is to have "rpm + <package-name> directory with git submodule". I would like this approach to be approved and documented. Just a few lines on a page in Sailfish wiki will prevent the further disorder and let other developers help you to clean up the current packaging stuff
09:13:40 <r0kk3rz> rip merbot
09:14:10 <abranson> it's not just the bot from what i'm hearing
09:14:30 <abranson> Kaffeine: anything to add?
09:14:43 <Nico[m]> Time to get the forum up or everyone to use Matrix ;p
09:15:25 <Kaffeine> abranson: Not yet. I want someone to confirm that we want to use rpm directory + git submodule :)
09:15:42 <abranson> ok, well here's what we put together:
09:15:44 <M4rtinK> Freenode registration issues again ?
09:15:44 <Kaffeine> abranson: Or at least to confirm that we want to use submodules instead of subtrees.
09:15:50 <r0kk3rz> that is the current thing yes
09:16:02 <abranson> #info These packaging formats are described in detail on the wiki https://sailfishos.org/wiki/Building_packages#Packaging_formats
09:16:02 <abranson> #info Repo with rpm folder (with few patches if needed) with package named submodule is the preferred way if there are not many changes to the submodule code.
09:16:02 <abranson> #info If there are a lot of changes to the upstream code then a submodule+patches might become quite complicated to maintain so then the third option mentioned in the link above with a upstream submodule and a package named folder with whole source in the repo might be more convenient.
09:16:02 <abranson> The selected option of course depends on whether the upstream sources are available in a git repository, if not then a copy of the sources in git is needed. Use of the obsolete spec+tarball format should not be used.
09:16:11 <abranson> #info The selected option of course depends on whether the upstream sources are available in a git repository, if not then a copy of the sources in git is needed. Use of the obsolete spec+tarball format should not be used.
09:16:45 <Venemo> sorry, but from reading the topic, it's not clear to me what the problem with packaging is that you're trying to solve Kaffeine
09:17:41 <abranson> I guess he's saying that summary should be on the wiki. Which is a good point.
09:18:14 <Venemo> ah, okay
09:18:17 <abranson> It kind of is all there though, just a bit spread out
09:19:12 <Kaffeine> Venemo: My specific problem is that telepathy-qt used to be a submodule, then it was converted to subtree and I find it harder to handle, so I proposed to convert it back to submodule. pvuorela seems to agree, but I would like to have this process clearly documented.
09:19:35 <Venemo> I see
09:20:17 <abranson> I find that the trouble with subtree is that you get no git blame. everything squashed.
09:20:52 <abranson> but arguing about the merits of different packaging formats is a popular hobby here
09:21:29 <r0kk3rz> i dont think theres a one size fits all, if a submodule would make your life easier and pvuorela agrees, then do that
09:21:35 <Kaffeine> Venemo: I had to be brave enough :) to propose a reverting MR (from subtree back to submodule), but if the repos layout will be documented then it will be much easier to do.
09:22:00 <jusa> Kaffeine: how about this style packaging? https://sailfishos.org/wiki/Git_Packaging_-_Upstream_Git_with_Long-Lived_Topic_Branch_Approach
09:22:14 <Venemo> why does it matter so much?
09:22:31 <jusa> Kaffeine: I find that much nicer than submodule+patches when there are a lot of changes
09:22:38 <Venemo> I think subtree is a bit easier to maintain, but I'm also fine with submodules
09:22:40 <Kaffeine> If we only have criterias like "if this and that -- use subtree; use submodule otherwise"...
09:24:45 <abranson> I think that's all there but spread about on that Packaging formats page. It could do with distilling into an easy list or something though.
09:25:16 <abranson> Anyone got anything to add? Time's up for this one
09:25:23 <Kaffeine> abranson: Let's go on. :)
09:25:31 <abranson> ok cool
09:25:39 <abranson> i'll do an action for this because I can
09:26:09 <abranson> #action Look at summarizing the format criteria on the wiki page to make things clearer for community devs
09:26:22 <pvuorela> i'll just note git submodules = good :)
09:26:28 <abranson> #topic Bad audio quality on Xperia X and Jolla phone (Asked by Nico[m] - 10 mins)
09:26:44 <abranson> #topic Bad audio quality on Xperia X and Jolla phone (Asked by Nico[m] - 10 mins)
09:26:44 <abranson> #info some details about the topic: I listen to a lot of music on the go. One thing that always bothered me, is that the audio quality in Sailfish seems a lot worse than when using Android or even my Nokia N9 (iirc). There seems to be a consistent noise floor, when using high quality head phones.
09:26:45 <abranson> #info More info: https://together.jolla.com/question/169231/poor-audio-quality-sailfish-x-jolla-1/ I would really appreciate it, if there would be some way to fix that, as it seems to be an issue with the way SailfishOS handles the hardware, not in the software decoding, etc.
09:27:31 <abranson> is Nico[m] around? anything to add?
09:27:41 <Nico[m]> Yep, I'm here
09:28:11 <Nico[m]> I can only add, that the answer in the linked TJC seems to describe the problem fairly well
09:28:46 <Nico[m]> (I originally thought this topic would be picked for the next meeting, sorry about the short notice)
09:29:34 <Nico[m]> Effectively it seems like only the software in Sailfish scales the volume, which manifests in a high noise floor, as the hardware always blasts with full power
09:29:43 <abranson> no problem, you got a pretty thorough answer imo:
09:29:51 <abranson> #info Part of the answer is in this tjc reply: https://together.jolla.com/question/169231/poor-audio-quality-sailfish-x-jolla-1/ mainly the part about The root of the problem is that somehow the volume control only scales the waveform in software, while the final amplifier is always at maximum volume. This is "feature" in normal audio use cases, it's just how the audio adaptation is implemented in Android. However, there are
09:29:51 <abranson> some cases (audio offload playback) which utilize hw volume control, however I'm not 100% certain how or how much it would affect audio quality.
09:30:03 <abranson> #info The thing is, we haven't implemented any offload playback, due to it being quite complicated thing to do. Mainly because of so many places it requires work on, first PulseAudio doesn't bend so easily to passthrough playback (there exists already passthrough playback but it's targeted for spdif or like, it was encapsulated with some thingamaboob I don't remeber right now, so something needs to be done to handle wav or
09:30:04 <abranson> mp3 passthrough, haven't checked the latest upstream though), in addition gstreamer would need to know about this passthrough, no idea how easy it would be to have some element that would do this kind of thing. Also some adaptations don't support offloading wav but only compressed formats like mp3 or aac. But in short, complicated.
09:30:13 <abranson> #info Second part of the answer is, right now we use pretty much whatever the adaptation says it has, and we may or may not misuse it slightly as we cannot use the interface 1:1 how audioflinger does. It very well may be that we don't have some ACDB or other switch in correct state as many adaptations have additional parameters which are seemingly not needed but "do things".
09:32:03 <Nico[m]> So is there something that can be done at some point? It's a bit sad, that my new headphones seem to make the audio quality worse (they actually just make it more noticeable)
09:32:33 <Nico[m]> I'm mostly interested in better flac playback, no idea, if that is relevant
09:33:06 <flypig> This is totally outside my comfort zone, but it looks like some of that work could be community-accessible.
09:33:06 <abranson> it does sounds like something that can be messed about with in the open source packages. maybe someone wants to have a go.
09:33:42 <r0kk3rz> yeah its all open, but not that easily approachable
09:33:59 <Nico[m]> Alright, I think I will need to read more into that topic, maybe I can mess with some things, but help would be appreciated of course!
09:34:40 <jusa> if someone wants to try they can ask from me @ #sailfishos-porters for instance, or just dm
09:34:57 <abranson> ^ audio wizard
09:35:00 <Nico[m]> Thanks, very much appreciated!
09:36:06 <Nico[m]> Otherwise I have nothing to add here, so I think this topic is done?
09:36:22 <abranson> bang on ten mins too. well done.
09:36:33 <abranson> #topic General discussion (20 min)
09:36:43 <Nico[m]> Almost like I had a timer running...
09:37:02 <abranson> or some sort of clock
09:37:30 <Nico[m]> So, is the developer forum progressing well?
09:38:20 <ViGe> Nico[m]: the progress is steady but a bit slow
09:38:41 <Nico[m]> I see, better be patient then :3
09:39:23 <M4rtinK> developer forum ? :)
09:39:59 <ViGe> M4rtinK: It was discussed last time I think
09:40:09 <r0kk3rz> patience is always required
09:40:27 <M4rtinK> OK, ill check the logs :)
09:41:17 <vknecht> following Jolla decision not to rebase Xperia X port on aosp8+, would Jolla allow using modern AlienDalvik on such a community port ? What would it require, eg SSU board-mappings/settings ?
09:43:51 <M4rtinK> beign containerized, the new Android emulation layer should indeed be more portable
09:44:58 <M4rtinK> but I assume there could be still many per device/port details to handle & licensing I guess
09:45:14 <Nico[m]> vknecht: It sounds a bit like the jolla devs would need a bit of time, before they could give an official answer to such a question ^_^
09:45:21 <r0kk3rz> id expect no
09:46:16 <vknecht> to explain: I have a aosp8 port, on a registered device, but store app didn't propose modern AD version, and couldn't install AD/Outlook/keyboard prediction
09:46:42 <vknecht> guess it'd be just a setting so that XA2-level apps are proposed by the store
09:47:45 <vknecht> sure need more time :-)
09:47:45 <r0kk3rz> i dont think theres a way the store can know the base adaptation layer
09:47:46 <abranson> i think it's a combination of having a license on the jolla account and having a device model that's in a server-side list of sailfish x
09:48:14 <r0kk3rz> so, it wont be able to tell an aosp6 from an aosp8 xperia x
09:48:46 <abranson> hmm, not sure. ssu has lots of device info to query.
09:48:47 <TheKit[m]> would be good to have AD license buyable separately eventually
09:49:26 <Nico[m]> It should easily be able to tell feom the kernel version or something similar, shouldn't it?
09:49:51 <r0kk3rz> the store doesnt know that either
09:50:19 <Nico[m]> Makes sense, mhm
09:50:38 <abranson> TheKit[m]: I don't think it hurts to keep asking. I think it's mainly a support problem - how do you support a paid AD without getting sucked into supporting the port too? What happens if the port becomes unmaintained?
09:51:32 <Nico[m]> Well, you could make paid apps available in the store for example, and sell AD to unofficial devices or so?
09:51:54 <M4rtinK> don't let perfect be the enemy of the good :)
09:52:12 <r0kk3rz> surely this is not a new problem
09:52:26 <r0kk3rz> surely someone somewhere sold software for os2 or beos or something
09:52:32 <Nico[m]> And I would think that an unmaintained port would just need to stick to an unmaintained alien dalvik version
09:52:38 <vknecht> abranson, would be nice to get confirmation it's technically possible ; for support, well, that's another question for later :-)
09:52:47 <M4rtinK> indeed, there could be issues, but at the same time there are many very good ports, that are left in the cold by this
09:53:26 <vknecht> and there could be a no-suppport clause, probably most people would be happy with that
09:54:22 <M4rtinK> I see this as the same as running steam games you bought on a random custom Linux distro - no one really expects Valve to solve all distro related issues for people
09:54:36 <TheKit[m]> it shouldn't be impossible to separate common AD problems from device specific
09:55:53 <r0kk3rz> it does become something of a QA nightmare though
09:56:17 <Nico[m]> Well, the seperation could simply be, that all support requests from AD running on unofficial ports are ignored.
09:56:34 <r0kk3rz> but lets be honest, if you're running sailfish you're used to a few quirks here and there
09:57:08 <Nico[m]> What? No, I never had issues with Sailfish...
09:57:17 <abranson> it's all lies
09:57:29 <Nico[m]> Still love it though <3
09:57:54 <Nico[m]> The quick switch gesture is also nice, although the animation is far too slow
09:58:47 <abranson> hope everyone noticed that 3.2.1 is out for early access
09:59:09 <Nico[m]> In fact, I didn't
09:59:20 <r0kk3rz> installed it today
10:00:15 <M4rtinK> cool, was not really epxecting another update before christmas :)
10:00:22 <vknecht> another subject, just a nudge about https://bugs.merproject.org/show_bug.cgi?id=1897 (QAbstractVideoFilter support) ;-)
10:00:24 <merbot`> Mer bug 1897 in nemo-qtmultimedia-plugins "QML VideoOutput does not call attached QAbstractVideoFilter" [Normal,New]
10:00:48 <ljo> The 3.2.1 installation on the xz3 outperformed xa2 by minutes ...
10:00:57 <FireFly> abranson: oh huh, neat
10:01:06 <Nico[m]> Downloading...
10:01:23 <vknecht> QAbstractVideoFileter seems required for cool effects on live camera/photo recordings...
10:01:49 <r0kk3rz> piggz o vision is what you need
10:01:56 * FireFly will dl and then upgrade after work probably
10:02:03 <vknecht> no, piggz-o-vision needs it :-)
10:02:38 <vknecht> can apply shaders on viewfinder, but not on recorded stream/photo
10:02:59 <r0kk3rz> thats all done internally
10:03:09 <abranson> https://git.sailfishos.org/mer-core/nemo-qtmultimedia-plugins/merge_requests/2
10:03:54 <abranson> looks like our aussie experts were all over that, but it stalled.
10:03:59 <Kaffeine> vknecht: It's required even to just grab the image. The proposed PR (I helped this work) implements read-only part. We need (needed) that to implement QR code reader.
10:05:01 <vknecht> for image, I could use QVideoProbe, maybe that can somehow replace videofilter for continuous capture, didn't try
10:06:01 <abranson> The QVideoProbe was enabled about a year ago - the gst droid buffers were made mappable. this can cause problems when it exposes a weird qcom colour format, but in lots of cases it's fine.
10:06:26 <vknecht> QVideoProbe usage: https://github.com/piggz/harbour-advanced-camera/pull/76/files
10:06:43 <vknecht> but apparently fails on X10 (or is it X1, don't remember)
10:06:48 <abranson> but you'd think this would be similar to this, was it done in response to the probe work?
10:07:03 <Kaffeine> abranson: It's stalled because the author (minlexx) and reviewers (adenexter) conversation failed :). The author didn't understand the objections nor the required changes.  We had this code run for days without crashes, so we did't see the said sync problem there.
10:07:40 <abranson> well adenexter knows his stuff there very well - he did the mappable buffers.
10:07:55 <Kaffeine> Now when we both (minlexx and me) are ex OMP, we need someone else to bring this up.
10:12:48 <abranson> ok, well i'll see if I can get someone to look at that again, though generally a potential problem still needs fixing even if you don't see it pop up during testing. once something's deployed it can get used in all sort of unusual ways, and concurrency problems are particularly bad for that, and also difficult to track down after the fact.
10:13:02 <abranson> but if everyone's done then I'll move onto the last bit
10:13:20 <abranson> #topic Next meeting time and date (5 min)
10:14:05 <abranson> Suggest Thursday 9th Jan, as the 2nd still might be a bit too holiday
10:14:38 <vknecht> +1
10:15:01 <Venemo> Kaffeine: why are you "ex"?
10:15:58 <M4rtinK> abranson: sounds good :)
10:16:10 <Venemo> if you don't mind my asking
10:18:26 <abranson> #info Next meeting will be held on Thursday 9th January 2020 at 09:00 UTC
10:18:40 <abranson> 2020. lawdy
10:19:16 <abranson> Hope you enjoyed this community meeting today. How did I do? Please tap the appropriate emoticon below:
10:19:16 <abranson> :D  :(  :|  :(  >:(
10:19:16 <abranson> #endmeeting