*** zbenjamin is now known as Guest28444 | 02:13 | |
*** zbenjamin_ is now known as zbenjamin | 02:13 | |
*** frinring_ is now known as frinring | 05:05 | |
ruskie | is there some way to be able to debug why a specific android app isn't working with android support(sailfish x on an xperia 10)? it'll launch then complain about trouble with Google Play services - it's a banking app | 09:57 |
---|---|---|
r0kk3rz | probably | 09:59 |
r0kk3rz | but banking apps usually dont like alien-dalvik | 09:59 |
ruskie | yeah, assuming as much | 10:00 |
quicquid | i always found it an advantage that i could tell me bank that their app doesnt work on my phone | 10:00 |
ruskie | :) | 10:00 |
quicquid | but i guess you dont always have a choice | 10:00 |
ruskie | ehh there is a web interface - but it stopped working on my jolla 1 - haven't tried it on the xperia 10 yet(need to install the client side cert) | 10:01 |
ruskie | if that works(for now until they get rid of the certs) then should be fine | 10:01 |
r0kk3rz | quicquid: can you imagine trying to tell a front line bank support staff about sailfish, and the error with alien-dalvik? | 10:01 |
quicquid | r0kk3rz: i just told them i have neither android nor ios, i need a different solution | 10:02 |
r0kk3rz | yeah, make a website | 10:02 |
quicquid | usually gets me the keypads for authentification | 10:02 |
ruskie | atm still on client cert | 10:02 |
ruskie | but yeah will have to switch to OTP once it runs out - and they have a provision for an OTP token instead of their app | 10:03 |
ruskie | but that's still a year and a half away - so no rush :) | 10:03 |
quicquid | urgs | 10:06 |
ruskie | tbh not bothered much anyway :) | 10:07 |
* quicquid crosses fingers you get the app working in the meantime | 10:07 | |
ruskie | nah | 10:07 |
ruskie | don't need it tbh | 10:07 |
ruskie | as said I'll be able to get a physical OTP token instead of the app one | 10:08 |
ruskie | had a discussion with them about this a year or so ago | 10:08 |
ruskie | cause honestly having both the token and access on the same device - doesn't really sound like a smart thing anyway | 10:08 |
quicquid | nope - "two" factors :) | 10:09 |
ruskie | likely same reason I dislike having a fingerprint reader to unlock a device | 10:09 |
ruskie | tbh I wish I could just make the fingerprint reader a button to activate the screen | 10:09 |
ruskie | instead of having it unlock it | 10:09 |
*** schm0lle1 is now known as schm0lle_ | 12:40 | |
*** schm0lle_ is now known as schm0lle | 12:42 | |
schm0lle | Good Morning, I am in trouble with installing the Application SDK under Kubuntu 19.10. "Common Sailfish OS Emulator Integration Bits for Sailfish IDE" seems to raise the errors. Here is the last part of the log: https://paste.ubuntu.com/p/t62f3bpDqx/. Maybe someone has an idea? | 12:52 |
Dakon | does it work? maybe this can just be ignored | 14:59 |
schm0lle | I can launch the SDK, but compilation fails | 15:23 |
mal | how does it fail? | 15:26 |
Herrie | mal: For Halium I'm looking into getting Android 8.1/9.0 ported so it can serve as a basis for LuneOS/UBPorts/Plasma etc. I was able to cherry pick quite a bit from mer-hybris and get things into a reasonable state, however now a bit stuck. It seems logcat doesn't work. "logcat read failure" Any ideas how to solve this? | 15:28 |
mal | that usually means android side is not running | 15:31 |
mal | Herrie: did you notice the difference how hybris-16.0 was done | 15:31 |
Herrie | mal: I didn't look too much into that one yet | 15:33 |
Herrie | One at a time | 15:33 |
Herrie | mal: Ah seems LXC container doesn't start... | 15:34 |
Herrie | That explains Android not working on LuneOS side ;) | 15:34 |
Herrie | "lxc-wait: monitor.c: lxc_monitor_open: 237 Failed to connect to monitor socket. Retrying in 100 ms: Connection refused" | 15:34 |
Herrie | Let me debug that one first | 15:35 |
Herrie | mal: You mean hybris-patches approach? | 15:39 |
Herrie | For 16.0 ? | 15:39 |
mal | yes | 15:40 |
Herrie | Not a big fan of applying patches to stuff repo touches (not very fail safe, unless you hard code revisions etc), but understand why you do it ;) | 15:41 |
Herrie | Forking & patching Android repos is not a whole lot of fun either ;) | 15:42 |
mal | Herrie: the problem was that we couldn't push hybris-16.0 branch of was it system/core to github because it complained it had too big commits, there was some upstream commit in there which was more than 100 MB because they accidentially pushed unstripped debug binaries once | 15:46 |
mal | not sure how lineageos did that | 15:47 |
mal | they have the same commit in there | 15:47 |
Herrie | mal: Ah OK | 15:50 |
Herrie | That explains | 15:50 |
Dakon | drop the github repo, clone from lineage, push your branches again, delete the fork status (optionally) | 17:34 |
Dakon | mal ^ | 17:35 |
mal | you mean for again from lineage? | 17:39 |
mal | *fork | 17:39 |
mal | but how does that help when we still have to push then new custom branch? | 17:40 |
Herrie | mal: If you create a branch from existing branch this shouldn't be an issuse because you would only push the new changes? | 17:44 |
mal | Herrie: hmm, good point, but quite annoying if we would have to remove the repo always when adding new android base version | 17:55 |
mal | why can't there be a feature to fork a branch | 17:56 |
Herrie | mal: ah I see what you mean now | 17:58 |
Herrie | Yeah if you need to add a branch from another fork then it would add the whole branch incl history | 17:59 |
Herrie | I'm sure there's a workaround for it but yeah | 17:59 |
Herrie | Wonders of git sometime | 17:59 |
Herrie | LG decided to put all their new webOS work on a new GH account instead of previous one, so all our LuneOS forks were pointing to "wrong" upstream :( | 18:00 |
mal | Herrie: so we would need to add a branch based in lineage-16.0 branch but we don't have that lineage-16.0 in our mer-hybris fork | 18:02 |
Herrie | mal: Yeah I see the problem. You're sure it was the system/core one? Will have some try at my end to see if I can come up with something | 18:04 |
mal | Herrie: also one problem is that the android repo were forked from cyanogenmod a long time ago so simple fork magic would not be easy | 18:04 |
mal | Herrie: I can check which one it was | 18:04 |
Herrie | mal: Yeah I'm aware of that, same issue we have with Open webOS and webOS OSE now ;) We forked the former, changes are in the latter. Not too dissimilar from CM->LOS mess ;) | 18:05 |
mal | Herrie: I think this commit removed the huge files https://android.googlesource.com/platform/system/core/+/5f5cb238f01e2f9327ec517c1487b19f946876de | 18:11 |
mal | Herrie: here you can see the sizes https://github.com/aosp-mirror/platform_system_core/commit/5f5cb238f01e2f9327ec517c1487b19f946876de "BIN -219 MB libunwindstack/tests/files/offline/jit_debug_x86_32/libartd.so" | 18:12 |
mal | :D | 18:12 |
Herrie | mal: Ah ok, I'll have a look. Have some ideas, just need to test | 18:22 |
schm0lle | mal: it tries to cd into a directory called /home/src1/whatever, but this doesn't exist | 18:25 |
Herrie | mal: Success :) I used BFG as per https://rtyley.github.io/bfg-repo-cleaner/#download and now have a clean branch at: https://github.com/Herrie82/android_system_core-1/tree/lineage-16.0 | 21:03 |
Herrie | It basically stripped the large file from the history | 21:03 |
Herrie | I pretty much followed the instructions 1:1 that were listed there, so pretty straight forward | 21:03 |
mal | so that rewrites the history? | 21:09 |
Herrie | It seems so, but just removing the large file | 21:14 |
Herrie | But yeah seems all commit id's are changed. Not ideal | 21:15 |
mal | Herrie: also that would make merging changes from upstream a bit more difficult maybe | 21:18 |
Herrie | mal: Well it seems I can cherry pick stuff | 21:18 |
Herrie | I.e. I hard-resetted to a previous commit and cherry picked the latest commit from upstream, seems OK | 21:19 |
Herrie | So it seems to recognize it's from the same source | 21:20 |
Herrie | It doesn't complain about different history like it would do in case of issues | 21:20 |
mal | ok | 21:23 |
Herrie | Feel free to pick it from my link ;) | 21:23 |
mal | how would it behave if you remove some commit or commits and then try merge from lineage repo | 21:24 |
Herrie | Well I did that with the last commit | 21:25 |
Dakon | mal: one would need to do the clone trickery only once if no new huge commits are introduced | 22:34 |
Dakon | if you remove things the git commit ids do not match anymore | 22:34 |
Dakon | of course one could go and do git filter-branch to entirely remove the file from history, but upstream would have to do that, too, otherwise one can't merge from them easily | 22:35 |
Herrie | Well the main issue is that the branch is in another repo from original | 22:36 |
Herrie | Another option would be to fork LOS and migrate the branches from the current CM-form to the new LOS based fork | 22:36 |
Herrie | That will solve the headache | 22:36 |
Herrie | Getting the CM based branches into the LOS-based fork should be easy enough | 22:36 |
Herrie | Dakon: The android_system_core was forked from CM, the lineage-16.0 branch is in LOS repo. So you cannot easily add the branch without taking the whole history. | 22:38 |
Dakon | you could try creating just a merge request that merges the upstream branch into your repo, that could also work | 22:40 |
Dakon | since the commits are already at github | 22:41 |
Herrie | Dakon: Yes but the fork doesn't share the same commit history, That's the problem mainly | 22:41 |
Dakon | so if the history is different anyway, what's the problem? or otherwise, shouldn't that be fixed | 22:42 |
Dakon | I must confess I have no clue about the repo and what is needed as merge/branch/release policy in them in any of the related projects | 22:43 |
Herrie | Dakon: It can't be fixed because they have a different origin. At least it seems so | 22:46 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!