08:00:52 <flypig> #startmeeting Sailfish OS, open source, collaboration -- 10th November 2022
08:00:52 <sailbot> Meeting started Thu Nov 10 08:00:52 2022 UTC. The chair is flypig. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:52 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:57 <flypig> We're off :)
08:01:00 <flypig> #info Meeting information and agenda can be found here:
08:01:04 <flypig> #link https://forum.sailfishos.org/t/community-meeting-on-irc-10th-november-2022/13368
08:01:15 <flypig> Thanks everyone for joining. I am the meeting's chairperson today, and will be best doing my to order time and keep.
08:01:24 <flypig> #topic Brief introduction (5 min). Please prefix your name/handle with #info
08:01:31 <ExTechOp> #info Otto Mäkelä, community
08:01:55 <thilo[m]> #info thigg, community dev
08:02:08 <flypig> #info David Llewellyn-Jones, meeting chair and sailor @ jolla
08:02:27 <Thaodan> #info Björn Bidar, Sailor @ Jolla
08:03:47 <rubdos[m]> #info Ruben De Smet, community
08:04:04 <flypig> Ah, just in time. I was about to pick up a fish.
08:04:55 <abr> #info Andrew Branson - sailor
08:04:57 <rubdos[m]> Just too late, I would say. Went to sleep too late and arrived at the office 4 minutes after I intended to!
08:05:14 <ViGe> #info Ville Nummela - Sailor @ Jolla
08:05:38 <flypig> :)
08:06:05 <flypig> Am I counting right: a score draw today?
08:06:49 <rubdos[m]> Should I slap some community members, to get the score tilted towards us? :D
08:07:29 <flypig> Haha. If that's what it takes ;)
08:07:32 <flypig> We didn't receive any specific advance questions, but we did get a PR query, so let's start with that.
08:07:32 <thilo[m]> We just put a few trouts on chair and claim they are community members?
08:07:39 <flypig> :D
08:07:56 <flypig> #topic Open PR discussion (10 mins -- asked by thigg)
08:08:01 <rubdos[m]> thilo[m]: I heard flypig had some to spare!
08:08:01 <flypig> #info <thigg> Any updates on the following PR?
08:08:08 <flypig> #info <thigg> https://github.com/sailfishos/llvm/pull/1
08:08:56 <flypig> rubdos[m], thilo[m], would you mind giving us a summary of the PR?
08:09:18 <rubdos[m]> Well, it's been a while that I worked on it, but I can give it a shot.
08:09:28 <thilo[m]> Go ahead :)
08:10:22 <rubdos[m]> Rust 1.52 is the current version that's in the Sailfish SDK. Rust is moving fast, and specifically for Whisperfish, having Rust 1.61 (or even 1.55) would be very beneficial, take a lot of load from the developers (being @direc85 and me), and remove the need to fork some upstream libraries.
08:10:54 <rubdos[m]> That's why I wanted to try and port 1.61 to Sailfish. 1.61 requires LLVM 12 or higher, which is current on SF on 10.something, iirc.
08:11:00 <flypig> You fork the libraries so you can patch them to build on older rust versions?
08:11:08 <rubdos[m]> exactly
08:11:49 <rubdos[m]> LLVM 14 (why not take the latest, right?) compiles for 99% now, but it does have require me to patch out some strange things regarding an ARM instruction that should not be generated on the meego build target. At least, that's how I remember it.
08:12:11 <Thaodan> From how I see how it is done in Firefox that's the reason why the vendor many of the libraries.
08:12:34 <rubdos[m]> Sadly, the devs of Firefox are legion, and direc85 and me are two :/
08:12:47 <Thaodan> Sure just saying it's kinda the languages fault.
08:13:08 <flypig> rubdos[m], just to be clear, your patch brings it to 100% build success? Your patch doesn't update Rust, it just lays down some groundwork?
08:13:08 <rubdos[m]> Also, libsignal-client (now called libsignal) moves forward, and depends on new stuff. We need to follow libsignal, because otherwise Whisperfish becomes useless.
08:13:12 <Thaodan> Anyway we need to make sure that gecko still builds and potentially update the vendored libraries.
08:13:33 <rubdos[m]> flypig: llvm builds 100%, but it is defunct in some documented way on that PR
08:13:43 <rubdos[m]> Thaodan: I can assure you it will not build with the current LLVM
08:14:14 <Thaodan> You meant it wont build with llvm14?
08:14:17 <rubdos[m]> We will both have the same issue. I think someone from Jolla could step up and get it fixed, because frankly, it goes over my head.
08:14:33 <rubdos[m]> Thaodan: It will not build with my llvm14, without patching out that one thing
08:15:13 <rubdos[m]> https://github.com/sailfishos/llvm/pull/1#issuecomment-1166465898
08:15:18 <flypig> So, LLVM14 will generate ARM instructions that will cause problems. There needs to be a change to address that, and once that is done, gecko *may* build with LLVM14?
08:15:20 <rubdos[m]> out-of-line atomics, that was it
08:15:28 <Thaodan> Ah yeah that's what I thought. But first the rust upgrade has to be done in a PR -> tested, then see what has to be done for gecko.
08:15:41 <thilo[m]> I also had a little rust experiment recently and noticed a little to late that the dependency hell is reallly hot there...
08:15:56 <rubdos[m]> I would bet that Gecko will build with the LLVM14 and Rust 1.61 system if the out-of-line atomics thing is fixed
08:16:06 <Thaodan> Ah now I get it.. rubdos[m]
08:16:14 <Thaodan> We are short of an GCC upgrade..
08:16:36 <rubdos[m]> I'm not entirely sure that a GCC upgrade is necessary, I believe it can be patched out, but I'm not entirely sure.
08:16:44 <Thaodan> I think the time would be well spend but it takes some time.
08:16:53 <rubdos[m]> But I seem to recall the GCC update would fix it too, indeed
08:17:09 <flypig> So there are two potential solutions: remove the out-of-line atomic calls from LLVM, or update GCC to 9.3.1 or higher.
08:17:10 <Thaodan> Maybe not necessary depending on what's cleaner/better.
08:17:14 <rubdos[m]> I was alright getting my hands dirty on LLVM, but GCC sounds like something I'd rather stay away from.
08:17:38 <Thaodan> I spend some work on dealing with gcc upgrades boostrapping and so on.
08:17:41 <rubdos[m]> flypig: I think that's how I recall it, indeed
08:17:47 <flypig> Thanks.
08:18:17 <rubdos[m]> After that, my Rust 1.61 patches should be fine (albeit already out-of-date)
08:18:26 <flypig> rubdos[m], after this goes through, are you also proposing to update Rust, or is this just to make your local Rust update easier?
08:18:59 <rubdos[m]> I would still propose to update Rust for the SDK. I'm quite confident that it should not break the Gecko build, last time I looked at the compatibility matrix of Mozill
08:19:00 <rubdos[m]> a
08:19:01 <Thaodan> I was about to test ccls https://github.com/MaskRay/ccls thought that would need a more recent ccls.
08:19:21 <rubdos[m]> So, 1.61 would be my first proposal, and if that works, I would maybe proactively bump to 1.65.
08:19:31 <Thaodan> It can break it but as said only it's vendored libs which can be upgraded.
08:19:38 <flypig> Thanks for clarifying.
08:19:54 <Thaodan> If we can skip the atomic thingy than it sounds quite possible.
08:20:01 <rubdos[m]> 1.61 is IIRC the first compiler that does Rust 2021, which is a requirement (for some reason...) for some cryptographic libraries.
08:20:28 <Thaodan> Yeah there are some python modules that start to require it.
08:20:58 <rubdos[m]> https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html?rdfrom=https%3A%2F%2Fwiki.mozilla.org%2Findex.php%3Ftitle%3DRust_Update_Policy_for_Firefox%26redirect%3Dno <- useful table
08:20:59 <thilo[m]> Rust 2021 is rust 1.56
08:21:06 <rubdos[m]> thilo[m]: Aha, so I'm even outdated.
08:21:32 <rubdos[m]> So Gecko as of version 105 will require 1.61 at minimum
08:21:44 <flypig> #info Rust update policy for Gecko
08:22:27 <thilo[m]> Yeah,I tried to build a python mudle around a rust library and failed because of that, thus I imagine you might get those problema with python as well, because pyo3 requires it
08:22:57 <thilo[m]> *module, sorry
08:23:10 <ExTechOp> muddle sounds fine
08:23:28 <Thaodan> The thing is with rust that from what I've been told that you need to upgrade from the minimum version to version. You can't just bump up to the most recent. So upgrading in time is important.
08:23:31 <flypig> Just for info, we are over time, but also not in a rush today, so I've added 10 mins to the time.
08:24:16 <rubdos[m]> Thaodan: Because of bootstrapping reasons? I'm not sure I understand.
08:25:29 <Thaodan> rubdos[m]: I think it is because rust requires more recent rust features in rustc faster than other compilers would do
08:26:14 <rubdos[m]> Maybe there's one "big" question that I'd like to ask: can someone from Jolla, or someone with more familiarity with LLVM and GCC take over the out-of-line atomics thing, or at least spend some time on it?
08:27:17 <rubdos[m]> Thaodan: Aha, so it is mostly for bootstrapping reasons then. As far as I understand, the Sailfish Rust compiler is built with itself (coming from the upstream Rust binaries). It's not bootstrapped anymore
08:27:47 <rubdos[m]> Probably depends on the meaning of "bootstrapped" I suppose
08:27:54 <Thaodan> rubdos[m]: Ah ok so building a newer/recent version isn't an issue unless we get really old?
08:28:26 <rubdos[m]> I think it won't be an issue ever, because the RPM ships `rust-$version-i686-unknown-linux-gnu.tar.gz` for building the three compilers of the same $version
08:28:49 <Thaodan> From my pov if you can try to disable the use of out of line atomics that would be best.
08:28:49 <rubdos[m]> I believe the main constraint is Gecko
08:28:58 <flypig> rubdos[m], regarding Jolla picking up the work, that's a good question and reasonable request. Thaodan, ViGe are probably best placed to answer, but at least it probably requires some internal discussion.
08:29:21 <rubdos[m]> I would be delighted to hear some outcome on that 🙏
08:29:36 <flypig> I can create an internal issue for it, at least.
08:29:49 <rubdos[m]> Thaodan: I tried with some patches, as you will see in that Github PR, but I did not succeed. But it should be possible.
08:29:53 <Thaodan> The next would be to test how easy the gcc upgrade is. The package update it self should easy and then see how much breaks (gcc is more picky, finds errors unreported).
08:30:14 <rubdos[m]> I feared so, that GCC would be a bit more tricky
08:30:29 <Thaodan> rubdos[m]:  ok maybe mal had a better success on that.
08:30:39 <Thaodan> I haven't spend time on that :D
08:31:03 <flypig> We should probably move on, but I'd like to summarise for the minutes.
08:31:09 <Thaodan> ok
08:31:13 <rubdos[m]> flypig: if you need any input from me (trying builds etc), feel free to reach out at any time.
08:31:20 <flypig> #info The PR requires a final patch (to remove out-of-line atomic calls), after which it can be tested with gecko and merged if it doesn't cause problems. This work is now on Jolla's table, but will require some time to look into.
08:31:33 <flypig> #info rubdos[m] offered to help with builds, input etc. We just need to ask.
08:31:39 <flypig> Anything else to add?
08:32:02 <rubdos[m]> I think that's it! :-)
08:32:29 <flypig> Great! Thanks for the PR rubdos[m]; thanks for the question thilo[m]; thanks for the nice discussion Thaodan and all :)
08:32:42 <flypig> Moving on...
08:32:42 <flypig> #topic Untracked bug reports (5 mins -- asked by thigg)
08:32:52 <flypig> #info <Jolla> The Community Bug Coordination Team have done a superb job once again this fortnight.
08:32:58 <flypig> #info <Jolla> As a result of their work, we now have:
08:33:02 <flypig> #info <Jolla> 9 new high quality bug reports recorded internally and tagged as "tracked".
08:33:07 <flypig> #info <Jolla> 2 bug reports tagged as "fixed" and closed.
08:33:11 <flypig> #info <Jolla> 1 bug queried for more information.
08:33:46 <flypig> I also wanted to ask if anyone wanted to raise any "papercut" type bugs that have already been tracked? Things that are annoying you, but you think might be easy to fix.
08:36:58 <ExTechOp> The same old same old thing of switching mobile <=> wifi networks (last time you folks said that the development version is better in this respect, so I'm really waiting for the next release)
08:38:29 <ExTechOp> Another one is copy-paste between Sailfish and Android, there are still bugs there, like paste or keyboard focus not going to where the cursor is but some other spot of the text field
08:39:43 <flypig> ExTechOp, thanks, the wifi/mobile issue has been worked on. It's been rather a challenge unfortunately.
08:40:17 <flypig> ExTechOp, could you provide a forum link for the copy-paste issues? That would be really helpful.
08:41:00 <ExTechOp> I haven't seen it mentioned, but it's really obvious when it happens but I keep forgetting to open an issue, anyone else?
08:41:54 <thilo[m]> I might have encountered it but dont know how to reproduce it
08:42:18 <flypig> If anyone is able to reproduce it and submit a bug to the forum, that would be super helpful.
08:42:25 <thilo[m]> If you could create a bug report that would be great :)
08:43:12 <flypig> We have this one tracked, but it looks different: https://forum.sailfishos.org/t/share-copy-paste-not-working-from-aliendalvik-to-sfos/10063
08:44:50 <flypig> I checked and don't see an internal ticket for it either.
08:45:25 <ExTechOp> I'll have to see if I can create a reproducible situation.
08:45:35 <flypig> Thank you ExTechOp, that'd be great.
08:46:29 <ExTechOp> But as you said, it's a kind of a papercut situation, too small to really bother about, but somewhere in the background the idea of a death by thousand cuts
08:47:06 <flypig> Right, these things are more important than they might initially seem.
08:47:07 <flypig> #info "papercut" bugs: switching mobile <=> wifi networks and Android <=> Sailfish clipboard issues.
08:47:28 <flypig> #info ExTechOp offered to try to reproduce the clipboard bugs.
08:47:54 <flypig> If you can reproduce it ExTechOp, I can create the bug report for it.
08:48:04 <ExTechOp> Roger that
08:48:56 <flypig> Thanks ExTechOp for the suggestions, that's really useful. We're already over time (my bad) so let's move to general discussion.
08:48:58 <flypig> #topic General discussion (20 min)
08:49:47 <flypig> thilo[m], I promised to look into updating QEMU as well I think?
08:51:56 <Thaodan> So there are too any things around me now :D
08:51:58 <ExTechOp> It would be really nice if there was a simple app for switching from "day mode" to "night mode" (there used to be, several SFOS upgrades ago), Situations did this but has now run against sailjail limitations and is currently not usable as-is.
08:52:36 <flypig> Sorry Thaodan, I know the feeling!
08:52:50 <Thaodan> I have 3 things so say, first there are some open bugs we forgot to talk about, community repos, and qemu update.
08:53:09 <Thaodan> Yeah.. I've been trying to keep up better with a better org-mode setup.
08:53:20 <Thaodan> so the "easiest" thing.
08:53:23 <flypig> ExTechOp, would that be switching automatically between ambiences?
08:53:44 <Thaodan> Qemu update that has been my thing.
08:54:04 <ExTechOp> flypig That could be it, but isn't there a current bug with the ambience audio settings not switching properly?
08:54:14 <flypig> I was hoping you could say something about it Thaodan. Here's the link, I think, for ref: https://github.com/Thaodan/qemu/tree/sailfishos/6.1
08:54:34 <Thaodan> I have the updated sb2 patches for qemu working on Arch Linux, I've tested them on SailfishOS too but we need to raise the kernel headers version to do that properly.
08:55:00 <Thaodan> that is the most recent update: https://github.com/Thaodan/qemu/tree/sailfishos/7.0.0
08:55:04 <flypig> ExTechOp, I guess you mean this one? We do have this tracked, yes. https://forum.sailfishos.org/t/12565
08:55:08 <thilo[m]> flypig: sorry, yes, you did
08:55:33 <ExTechOp> flyping Yep, that's it
08:55:48 <Thaodan> I'm using the qemu updates on arch here: https://aur.archlinux.org/packages/qemu-scratchbox2-user
08:56:07 <flypig> Thaodan, so there is more work needed to get the QEMU update through, and currently that's not in the immediate pipeline?
08:56:10 <Thaodan> Any questions regarding the qemu update?
08:56:57 <Thaodan> flypig: Not directly. I depends on me getting to it, If I get the call to work on it I'll prioritize it.
08:57:07 <Thaodan> I have to get my todos in order..
08:57:08 <thilo[m]> as i only need the update for the graalvm toolchain, is there any way to work around that for now?
08:57:37 <thilo[m]> otherwise i am just fine with waiting beforebuilding more stuff like that ;)
08:57:48 <Thaodan> Most of that is really legacy technical debt  that we have to pay up.
08:57:55 <flypig> thilo[m], I don't think we looked into any workarounds for that, since the QEMU update apparently fixes it, that seemed like the best approach.
08:58:02 <Thaodan> But yeah if you want to test it go use Arch XD
08:58:20 <thilo[m]> :P
08:58:22 <flypig> Sorry to say thilo[m], as in my view it'd be really nice to have your GraalVM toolchain working.
08:58:28 <Thaodan> The issue is really just the part that runs scratchbox2.
08:58:37 <Thaodan> Which is lucky.
08:59:01 <thilo[m]> I think I'll just wait then ;)
08:59:09 <Thaodan> So anything left with that or can I proceed then?
08:59:36 <Thaodan> I need more energy and more hours in the day ;)
08:59:55 <thilo[m]> ;) have a nice day then
09:00:22 <thilo[m]> my workaround for that is shamelessly dropping tasks ;)
09:00:42 <flypig> Thaodan, I think you can move to the next, if that's okay for you thilo[m]?
09:01:09 <thilo[m]> sure
09:01:10 <Thaodan> Ok to the bugs I've mentioned. We noticed these two issues with appear to have similar causes. https://forum.sailfishos.org/t/trying-the-guest-user-feature-destroyed-all-my-data/2964/3
09:01:40 <Thaodan> #link https://forum.sailfishos.org/t/trying-the-guest-user-feature-destroyed-all-my-data/2964/3
09:01:53 <Thaodan> #link https://forum.sailfishos.org/t/multi-user-android-user-data-get-deleted-and-lost-device-reset/11520
09:03:30 <Thaodan> #info We noticed these two issues with appear to have similar causes.  But we have trouble figuring the root of these. Any information on these such as for example logs, testcases can help. Please inform of if you have any under these threads.
09:04:01 <flypig> It's a bit of a long shot, but has anyone here today experienced either of these?
09:04:21 <dcaliste> Yeh, I did. But didn't dare to reproduce…
09:05:01 <flypig> dcaliste, if there's any info at all you could share, it would be really helpful.
09:05:35 <Thaodan> I tried to reproduce both but they don't reproduce on devices which haven't been upgraded from what I've seen.
09:05:54 <Thaodan> And I don't use AD really on my main device.
09:06:17 <flypig> dcaliste, from your description on the forum, it sounds like something went wrong. The behaviour was unusual.
09:07:22 <flypig> dcaliste, did you have Android App Support installed when it happened?
09:07:36 <dcaliste> Yeh, indeed, but unfortunately, I cannot comment much more since I don't really dare to retry. It took me a long while to recover to a usable state last time :/
09:07:57 <flypig> The fact that it happened on an "almost fresh" install is useful information though.
09:08:05 <dcaliste> Yes, Android support was there, not sure it was running though.
09:08:45 <flypig> Do you recall what you rsynced? Was it just things in /home/defaultuser (including .local/.config files)?
09:09:21 <Thaodan> Hm that might be a hint.
09:09:43 <dcaliste> Yes, I rsynced all /home/defaultuser content.
09:09:52 <Thaodan> (manning .config in git for Sailfish OS might be the thing to try :D)
09:10:42 <dcaliste> (I mean including hidden directories also).
09:12:23 <ExTechOp> The last time, I was distracted by actual work and didn't have the time to ask a question about "binary blobs" supplied by Sony (or Qualcomm, others?):
09:12:23 <ExTechOp> I guess there are several different ones used by SFOS, deployed by different methods (on the phone flash from Android installation, or explicitly added at install time), which ones of these get updated by SFOS to newer releases?
09:14:06 <Thaodan> ExTechOp: binary blobs or more accurate the oem blobs are the blobs from the oem in our case Sony. Sony gets them from Sony, Sony AOSP uses stock Qualcomm blobs with some tuning.
09:14:21 <Thaodan> They don't get updated with SailfishOs releases.
09:14:40 <ExTechOp> er, "Sony gets them from Sony", as in they write them themselves?
09:14:46 <Thaodan> They have to be updated manually if so but they don't update as often and even then it is quite easy.
09:15:04 <dcaliste> flypig: I did the rsync with the UI stopped, loggued via ssh (I stopped the user slice via systemctl as far as I remember and then rsync from a JollaC as root with something like rsync -az jollaC:/home/nemo /home and then rename the nemo dir into defaultuser).
09:15:21 <Thaodan> ExTechOp: Sony builds them based on Qualcomm proprietary source code.
09:15:28 <flypig> dcaliste, so it was: 1) clean install (including AAS during the Welcome process), 2) rsync over /home/defaultuser as you describe, 3) create new guest user, 4) switch back to original user.
09:16:14 <dcaliste> flypig: exact. But as mentioned, I didn't dare to see if the above steps allow to reproduce !
09:16:36 <flypig> I wonder whether the conversion from nemo to defaultuser might also be relevant.
09:16:37 <Thaodan> flypig, dcaliste: I've been doing the same but with just a  tar file. I think method shouldn't matter.
09:16:59 <Thaodan> What would be interesting if AD was used before.
09:17:48 <Thaodan> I think I've tested multi user with my install that was copied of from an install that used nemo (Xperia XZ3 to my current device).
09:18:01 <Thaodan> I've used AD on that device too.
09:18:07 <Thaodan> (that = current)
09:18:17 <dcaliste> Thaodan, as far as I remember, I didn't use AD before doing the rsync, but surely after doing it and before playing with user switch.
09:18:19 <Thaodan> But not on the device before.
09:18:20 <ExTechOp> Thaodan I've been under the impression that (a part of) the original Android flash image containing Qualcomm stuff also is used, is this incorrect?
09:19:26 <Thaodan> ExTechOp:  Firmware, Bootloader, Persistant partition is used but nothing that you can reflash with just fastboot is used.
09:21:00 <ExTechOp> Thaodan This leads to a follow-up question, I believe new Android releases occasionally also update some of these, is there any mechanism to do this under SFOS?
09:22:02 <abr> No, you can only get those through that Emma tool
09:22:16 <flypig> We're way over time, so will need to start wrapping up I'm afraid.
09:22:26 <Thaodan> ExTechOp: Not so far but the newer Android release don't necessarily update these blobs to add new feature but mostly to bring the up to speed the newer android version.
09:22:45 <Thaodan> abr: We are talking about odm blobs.
09:24:25 <flypig> I'm going to add some of this discussion to the minutes. Please bear with me.
09:24:30 <flypig> #info <ExTechOp> It would be really nice if there was a simple app for switching from "day mode" to "night mode" (there used to be, several SFOS upgrades ago), Situations did this but has now run against sailjail limitations and is currently not usable as-is.
09:24:38 <flypig> #info This also depends on a fix for https://forum.sailfishos.org/t/12565
09:24:46 <flypig> #info Thaodan gave an update on upgrading QEMU in the SDK to allow GraalVM to work there.
09:24:51 <flypig> #info <Thaodan> I have the updated sb2 patches for qemu working on Arch Linux, I've tested them on SailfishOS too but we need to raise the kernel headers version to do that properly.
09:24:55 <flypig> #info We're not aware of any other workarounds for GraalVM.
09:24:59 <flypig> #info ExTechOp asked about binary blobs on the phone: "which ones of these get updated by SFOS to newer releases"
09:25:03 <Thaodan> Sounds like something that situations also did.
09:25:03 <flypig> #info <Thaodan> They don't get updated with SailfishOs releases
09:25:12 <flypig> #info <ExTechOp> I believe new Android releases occasionally also update some of these, is there any mechanism to do this under SFOS?
09:25:17 <flypig> #info <abr> No, you can only get those through that Emma tool
09:25:26 <flypig> Sorry, I missed adding many things, there's more...
09:25:30 <flypig> #info Concerning the user date being lost, dcaliste explained his experiences.
09:25:34 <flypig> #info <dcalste>  I did the rsync with the UI stopped, loggued via ssh (I stopped the user slice via systemctl as far as I remember and then rsync from a JollaC as root with something like rsync -az jollaC:/home/nemo /home and then rename the nemo dir into defaultuser).
09:25:37 <flypig> #info The process was 1) clean install (including AAS during the Welcome process), 2) rsync over /home/defaultuser as you describe, 3) create new guest user, 4) switch back to original user.
09:25:41 <flypig> #info <dcaliste> Thaodan, as far as I remember, I didn't use AD before doing the rsync, but surely after doing it and before playing with user switch
09:25:50 <Thaodan> abrs comment was about different blobs I think. It also contradicts with mine.
09:26:05 <flypig> Is there anything else that should be added from the discussion? I'm sure I missed many important comments.
09:26:38 <abr> Thaodan: you mentioned firmware partitions etc, and 'some of these' also includes those
09:27:13 <abr> to be clear - the odm you can update with fastboot, but all the other unchanged partitions can only be upgraded with Emma
09:27:46 <Thaodan> abr: Yeah I've mentioned as used from stock android, which requires  Emma/Sony flashing mode.
09:27:52 <abr> but in general you shouldn't really alter the odm unless moving to a later android base,  which we don't support
09:28:05 <Thaodan> Yes
09:28:15 <Thaodan> that's what I was about to write.
09:28:32 <ExTechOp> All my inquisitive mind questions came around because in some earlier comments Jolla people mentioned having to work around some binary blob issues
09:28:58 <Thaodan> The thing is that the Sony AOSP blobs try to be compatible with a version of the stock firmware.
09:29:08 <abr> Thaodan: there are 'stock' partitions used by AOSP/SFOS too though, right? Modem firmware and config, bluetooth etc
09:30:13 <Thaodan> It is not always clear when they raise the odm partition to be compatible with more recent android versions than the one that the device was initially ported from.
09:30:14 <abr> I think it's an important factor when we think about volte configs etc, which iiuc can only be upgraded by reverting back to stock and reflashing sfos
09:30:35 <Thaodan> abr: Yes all stock partitions that can't be flashed with fastboot are reused.
09:31:01 <Thaodan> That includes firmware partitions such as modem firmware.
09:31:05 <abr> they can be flashed though, right? they're just only available via Emma
09:31:11 <thilo[m]> do i understand anything wrong or is the video crash issue (https://github.com/sonyxperiadev/bug_tracker/issues/761) also only fixable if users reflash?
09:31:50 <Thaodan> They can be flashed without dropping Sailfish OS but not through Emma, only through the (unofficial) XperiaFlashTool
09:32:20 <Thaodan> But modemfirmware rarely changes, from my recent tests they are still the same even on A12.
09:32:43 <abr> yeah, it's not a technical limitation. it's a distribution one.
09:33:01 <Thaodan> thilo[m]:  Sony is working on it, you have to wait.
09:33:27 <thilo[m]> Thadoan: i understand that, but if they fixed that, how would the process be?
09:33:41 <abr> sounds like a missing lib in /odm?
09:33:47 <Thaodan> abr: distribution and the Sony tool not allowing it. Xperia firmware can be downloaded freely through Xperia Flashtool.
09:34:05 <abr> and we certainly wouldn't be allowed to fetch or distribute those
09:34:35 <Thaodan> thilo[m]: You have to flash them manually but I think we have articles on those.
09:34:56 <abr> thilo[m]: if it is only a missing odm lib, then you could just reflash that. i'm not sure if there's any camera stuff in the emma-only bits, are there?
09:34:56 <Thaodan> abr: Yeah we wouldn't any user can do it thou.
09:35:20 <thilo[m]> okay, so this will require users reflashng at least some partitions on their devices? (i dont have a device with those issues ;)
09:35:23 <Thaodan> abr: All the emma only camera stuf isn't used in Sony aosp.
09:35:47 <Thaodan> thilo[m]:  only odm  but that was already mentioned many times.
09:36:05 <thilo[m]> and jolla wouldnt be allowed to fetch those images from sfos and flash them in an over-the-air process?
09:36:37 <Thaodan> Yes we wouldn't be allowed as mentioned earlier..
09:36:50 <Thaodan> We can only make process smother.
09:36:54 <abr> the problem is that it requires the end-user to agree to terms and download it themselves. not allowed to do that automatically.
09:37:10 <abr> that's why the initial flashing isn't more automatic
09:37:10 <thilo[m]> i just wanted to make sure i understand the situation correctly
09:37:36 <thilo[m]> abr: but that doesnt necessarily involves a pc, right?
09:37:46 <thilo[m]> users could do both of that on the phone
09:38:00 <Thaodan> Yeah and putting them into the packaging system is the next thing, we can show the eula/terms but we to know if we can automate that process.
09:38:09 <abr> yeah
09:38:12 <Thaodan> You can flash from the phone itself.
09:38:14 <thilo[m]> download that file please... and if you find a file with the right checksum you can use that for flashing
09:38:25 <abr> would have to be done outside of the packaging
09:38:55 <Thaodan> You can even do that in packaging just the downloading is done through separate ui.
09:38:59 <thilo[m]> hm, interesting, thanks for your insights :)
09:39:24 <Thaodan> You just generate a dummy package on device to  tell the pkg manager which odm version is present.
09:41:11 <flypig> Perhaps this is a good time to wrap up? Is there anything additional to add to the minutes?
09:41:26 <Thaodan> Nope, what's for lunch?:D
09:41:39 <thilo[m]> thai
09:41:48 <flypig> Haha :) Okay. We just one last thing before we finish.
09:41:56 <flypig> #topic Next meeting time and date (5 min)
09:42:00 <flypig> Proposing Thursday 24th November at 08:00am UTC
09:42:07 <flypig> Any objections?
09:42:28 <ExTechOp> Works for me.
09:42:44 <Thaodan> +
09:43:13 <flypig> Alright, great! And silence from everyone else means agreement :)
09:43:18 <flypig> #info Next meeting will be held on Thursday 24th November 2022 at 08:00am UTC: 2022-11-24T0800Z
09:43:35 <flypig> Thank you all, as always, for some excellent and lively discussion.
09:43:39 <flypig> #endmeeting