#sailfishos-meeting: Sailfish OS, open source, collaboration -- 16th February 2023

Meeting started by ViGe at 08:00:06 UTC (full logs).

Meeting summary

    1. Meeting information and agenda can be found here: (ViGe, 08:00:11)
    2. https://forum.sailfishos.org/t/community-meeting-on-irc-16th-february-2023/14326/ (ViGe, 08:00:15)

  2. Brief introduction (5 mins). Please prefix your name/handle with #info (ViGe, 08:00:47)
    1. Ville Nummela - Sailor @ Jolla, chairperson today (ViGe, 08:00:56)
    2. lolek - Just a regular user (lolek, 08:01:11)
    3. pherjung, community (pherjung[m], 08:01:17)
    4. Vlad G., community (b100dian, 08:01:45)
    5. Crabster - Just a regular lurker (Crabster, 08:05:13)

  3. Decouple encryption password from phone password (5 mins -- asked by lolek) (ViGe, 08:05:41)
    1. <lolek> ok we finally have encryption that allow us to use alphanumeric values which is step forward in good direction. (ViGe, 08:05:46)
    2. <lolek> Now the only problem is that the same pw is needed twice to start up the phone. (ViGe, 08:05:49)
    3. <lolek> Imho this shouldn’t be required and some decoupling is required. (ViGe, 08:05:53)
    4. <lolek> I’d like to get information what’s exactly needed for this and if community can help with this? (ViGe, 08:05:57)
    5. <Jolla> This is a broad topic carrying many details in multiple layers. Your humble opinion is about right. (ViGe, 08:06:07)
    6. <Jolla> Thank you for your feedback and input. Let’s see what we can do. (ViGe, 08:06:11)
    7. Otto Mäkelä, community (ExTechOp, 08:07:37)
    8. rainemak - Sailor @ Jolla (rainemak, 08:07:43)

  4. Bootloader relock (5 mins -- asked by lolek) (ViGe, 08:10:40)
    1. <lolek> This is something that came out on the previous meeting. (ViGe, 08:10:46)
    2. <lolek> Thaodan said: if the bootloader supports user signatures you can relock it with your own key to accept only kernels e.g. from Jolla but Sony phones don’t support that so far. (ViGe, 08:10:50)
    3. <lolek> My question is: What Jolla can do to change this, and how community can help achieve this? (ViGe, 08:10:55)
    4. <Jolla> There is nothing Jolla can do about this, as this is something that Sony has to provide. (ViGe, 08:11:05)
    5. Björn Bidar - Sailor @ Jolla (Thaodan, 08:12:44)

  5. Providing a better mechanism in the OS for installing additional authentication methods and letting users choose what they prefer. (10 mins -- asked by lolek) (ViGe, 08:16:04)
    1. <lolek> this is a continuation of: https://forum.sailfishos.org/t/community-meeting-on-irc-31st-march-2022/10714/4 (ViGe, 08:16:11)
    2. <lolek> Also I asked there if Jolla can’t just license BB picture password since BB is gone. (ViGe, 08:16:17)
    3. <lolek> And for this part I’d like to also get an answer and I’m willing to wait for this one as it would probably require contacting with BB. (ViGe, 08:16:21)
    4. <Jolla> Additional authentication methods could go quite nicely hand in hand with the first “Decouple encryption password from phone password”. (ViGe, 08:16:32)
    5. <Jolla> There are no immediate plans to implement better mechanisms for installing additional authentication methods. (ViGe, 08:16:38)

  6. Enabling VoLTE on community ports (20 mins -- asked by piggz) (ViGe, 08:23:48)
    1. <piggz> With 4.5 SFOS released, I wonder what is the state with VoLTE support. Sounds like Jolla’s implementation is closed source. Any plans to release it? Earlier, we were told that it is too early and no definite answer could be given. Maybe it is the time? (ViGe, 08:23:54)
    2. <piggz> I believe unofficially ported devices could benefit from looking into Jolla’s approach. Right now, I personally, even have no idea where to start digging. And, in principle, time used for duplicating efforts is not very efficiently spent. (ViGe, 08:23:59)
    3. <piggz> In addition, does keeping VoLTE closed give Jolla an advantage over competitors? most other mobile linux distros are using ModemManager, so this seems unlikely, opening up VoLTE would be a great boost to sailfish ports. (ViGe, 08:24:03)
    4. <piggz> If its not possible to open the code, could the compiled packages atleast be put into the adaptation-common repos so that porters can experiment? If there are other device-specific hacks required to enable volte, could these be documented to help porters understand what needs to be written? Would any sony specific packages also be useful on other sony ports? (ViGe, 08:24:07)
    5. <Jolla> As we communicated earlier, there are device-specific parts of the implementation that we may not be able to share publicly. (ViGe, 08:24:16)
    6. <Jolla> Thank you for your input. We’ll consider and think what we could do to help on the VoLTE front. (ViGe, 08:24:21)

  7. Qt Upgrade (30 mins -- asked by piggz) (ViGe, 08:40:00)
    1. <piggz> The time has come again to ask about the potential for a Qt Upgrade in Sailfiish. (ViGe, 08:40:06)
    2. <piggz> Qt 5.6 was released almost 7 years ago, and security support ended in 2019 (ViGe, 08:40:10)
    3. <piggz> Newer Qt versions not only add useful feature, but bring improved compiler support and support for newer c++ features. (ViGe, 08:40:14)
    4. <Jolla> Qt Upgrade is not on our plans for the near future. (ViGe, 08:40:22)

  8. ability to buy/enable Android AppSupport for community ports (10 mins -- asked by vlagged[m] (ViGe, 08:47:43)
    1. <vlagged[m]> Compared to the alternatives (anbox of old or waydroid now) Jolla’s AAS is specifically more integrated with SailfishOS and makes “selling” the idea to switch to Sailfish more easy for anyone. (ViGe, 08:47:48)
    2. <vlagged[m]> Adding the ability to pick any device that has a community port can help with people’s different hardware needs and expectations while still giving a great experience for Android apps. This would also mean that the work for the tight integration with Sailifish OS pays off even more. (ViGe, 08:47:53)
    3. <vlagged[m]> Since this is not something that any user could make an assessment of, I would suggest having a similar step to the one that is already in place for enabling Jolla Store access, which is that the porter confirms that the device is working with AAS. What is enabled then is the ability to buy the license that would activate the download for the user that bought it. (ViGe, 08:47:59)
    4. <vlagged[m]> For the porter to be able to make this assessment a minimum requirement document would be needed, specifying the e.g. min kernel version, kernel params etc. Waydroid could be used as a similar in spirit “proof of work” for the porter. (ViGe, 08:48:05)
    5. <vlagged[m]> Since adding this support may or may not succeed, it would probably mean that the porter would have to have access to give it a try (assuming ‘proof of work’) without costs other than having a set-by-Jolla minimal feature parity (e.g. audio should work, you name it) for the port. (ViGe, 08:48:09)
    6. <vlagged[m]> To be able to add this kind of access a possibility would be, when adding the store support for a ported device, to request a “porting enabling” license for the specific device the porter uses for testing so that he can also use the store to install Android AppSupport and debug it. (ViGe, 08:48:14)
    7. <vlagged[m]> For debugging, the same level of support as of today for community ports should be enough. If the porting fails, it would be nothing (but time) lost. (ViGe, 08:48:19)
    8. <vlagged[m]> If it succeeds, there could be a bunch of new customers for SailfishOS as a platform and for the AppSupport product for each port. And we get more friends to move over here:) (ViGe, 08:48:22)
    9. <Jolla> Thank you for your feedback and thinking. As earlier stated, we have been looking at the possibility of stand-alone AppSupport for community ports (ViGe, 08:48:31)
    10. https://forum.sailfishos.org/t/community-meeting-on-irc-9th-june-2022/11704/20 (ViGe, 08:48:40)
    11. <Jolla> It's worth reminding that AppSupport for community ports is more than just providing the relevant packages. (ViGe, 08:48:47)
    12. <Jolla> We'd also need processes for verifying that everything works, ensuring the right apps are made available in the Store, ensuring that ports are kept up-to-date and also implementing technical changes to the repository backend. (ViGe, 08:48:54)

  9. : Moving away from GitHub (10 mins -- asked by lolek) (ViGe, 08:59:45)
    1. <lolek> Since Microsoft took over GitHub they started to use OSS projects to train their CoPilot product on others code and is making money out of it. (ViGe, 08:59:55)
    2. <lolek> The Software Freedom Conservancy organization calls OSS projects to move away from GitHub. (ViGe, 08:59:58)
    3. <lolek> I’d like to know if Jolla is aware of this and are there any plans in the future to move away from that platform to somewhere else? (ViGe, 09:00:01)
    4. https://en.deepweb.net/blog/open-source-developers-urged-to-move-away-from-github-after-copilot-launch (ViGe, 09:00:04)
    5. <Jolla> Jolla is aware of this, however we don’t have plans for moving away from GitHub. (ViGe, 09:00:10)

  10. Open PR discussion (5 mins -- asked by jolla) (ViGe, 09:16:36)
    1. <jolla> Any open PRs to discuss? (ViGe, 09:16:41)

  11. Untracked bug reports (5 mins -- asked by pherjung) (ViGe, 09:21:51)
    1. <pherjung> Untracked bug reports... (see the forum) (ViGe, 09:21:57)
    2. <Jolla> Thank you again for all of your work in checking and collating bug reports. (ViGe, 09:22:03)
    3. <Jolla> Here are the results: (ViGe, 09:22:07)
    4. <Jolla> - 6 high quality bug reports now recorded internally and tagged as "tracked". (ViGe, 09:22:11)
    5. <Jolla> - 1 duplicate bug report closed (ViGe, 09:22:14)

  12. General discussion (10 min) (ViGe, 09:26:43)
  13. Next meeting time and date (5 min) (ViGe, 09:36:31)
    1. Next meeting will be held on Thursday 9th March, 8:00 UTC (ViGe, 09:40:24)


Meeting ended at 09:41:54 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. ViGe (119)
  2. lolek (43)
  3. Thaodan (21)
  4. b100dian (14)
  5. ExTechOp (11)
  6. pherjung[m] (3)
  7. rainemak (3)
  8. piggz[m] (3)
  9. sailbot (2)
  10. rinigus (2)
  11. Crabster (1)
  12. b100dian[m] (1)


Generated by MeetBot 0.1.4.