**** BEGIN LOGGING AT Thu Apr 08 02:59:57 2021 Apr 08 06:15:13 Morning! Apr 08 06:15:21 JaMa: For when you're awake: http://jenkins.nas-admin.org/job/LuneOS/job/halium-luneos-9.0-build/lastBuild/console Apr 08 06:16:35 Seems that somehow "repo" is missing and build gets done in /home/jenkins/workspace/halium-luneos-7.1-build instead of /home/jenkins/workspace/halium-luneos-9.0-build. Could be the folder simply needs creating. The jenkins.job.sh looks OK to me? Apr 08 07:02:08 will have a look Apr 08 07:02:46 ok to merge https://github.com/webOS-ports/meta-webos-ports/pull/453 ? tenderloin build is failing http://jenkins.nas-admin.org/job/LuneOS/view/testing/job/luneos-testing_tenderloin/692/console Apr 08 07:05:14 workspace/halium-luneos-7.1-build was set in the jenkins job configuration (not the jenkins-job.sh script), I've updated it to 9.0 Apr 08 07:08:30 JaMa: Ah OK Apr 08 07:08:40 That I missed probably when I copied the job Apr 08 07:11:28 JaMa: Getting repo installed on 20.04 is a bit tricky at times Apr 08 07:11:34 Let me know in case you get stuck Apr 08 07:13:54 ok, FWIW I think we should mark the manually uploaded images somehow, so it's clear that it wasn't built by jenkins job Apr 08 07:33:40 JaMa: OK Apr 08 07:33:51 In general we don't really do it Apr 08 07:33:55 Just when we have WIP stuff Apr 08 07:35:36 Once WIP stuff is merged we use Jenkins job to generate the same Apr 08 07:51:06 ok, I was just wondering next time I'll be deleting some older images to save disk space to prevent removing some which cannot be easily recreated by jenkins Apr 08 07:52:50 the build workspace for 5.1 and 7.1 is still needed? Apr 08 07:52:55 19G halium-luneos-5.1-build Apr 08 07:52:55 50G halium-luneos-7.1-build Apr 08 07:53:31 will drop the 9.0 from 7.1 Apr 08 07:53:56 34G halium-luneos-7.1-build/halium-luneos-7.1/out/ Apr 08 09:17:39 JaMa: What is running on builders nowadays? 20.04 as well? Apr 08 09:21:11 JaMa: For Halium build and setting up repo there are some steps in Halium docs: https://docs.halium.org/en/latest/porting/first-steps.html#ubuntu-20-04-or-newer Apr 08 09:21:22 After "Install the required dependencies" Apr 08 09:25:28 yes 20.04 Apr 08 09:27:01 how was repo installed in 7.1 builds? Apr 08 09:28:51 was it manually installed on bonaire before and then somehow lost during the upgrade to 20.04? Apr 08 09:29:22 JaMa: 20.04 doesn't provide it anymore via regular setup steps Apr 08 09:29:24 18.04 did Apr 08 09:29:33 So for 20.04 you need to manually install repo Apr 08 09:29:34 -rwxr-xr-x 1 jenkins jenkins 24K Jan 18 2014 /home/jenkins/bin/repo Apr 08 09:29:35 Bit of a pain Apr 08 09:33:01 Morning ! Apr 08 09:33:26 I'm back with znc bouncer and all :) Apr 08 09:43:11 interesting, the shell command triggered from jenkins doesn't respect jenkins's user .bashrc nor .bash_profile, in the end I've adjusted PATH before starting jenkins-job.sh Apr 08 09:43:18 Herrie: http://jenkins.nas-admin.org/job/LuneOS/view/halium/job/halium-luneos-9.0-build/7/console Apr 08 09:46:27 Tofe: Nice! Apr 08 09:47:32 fatal: include [/home/jenkins/workspace/halium-luneos-9.0-build/halium-luneos-9.0/.repo/manifests/]snippets/lineage.xml doesn't exist or isn't a file Apr 08 09:47:38 JaMa: Ah could be we didn't create a halium-9.0 branch yet in android repo Apr 08 09:47:40 Let me check Apr 08 09:47:57 is the ] some special syntax or where did it came from? I don't see it in https://github.com/webOS-ports/android/compare/luneos-halium-7.1...webOS-ports:luneos-halium-9.0 Apr 08 09:49:18 and yes, there is only luneos-halium-90 and tofe/halium-9.0 branch Apr 08 09:50:14 I've created it from tofe/halium-9.0 now (through github UI - didn't know it allows that) Apr 08 09:50:46 but still http://jenkins.nas-admin.org/job/LuneOS/view/halium/job/halium-luneos-9.0-build/8/console Apr 08 09:50:53 will start luneos builds now Apr 08 09:57:01 JaMa: Also not sure Apr 08 10:02:40 Where this ] comes from.... Apr 08 10:03:01 ok, meeting ended, let me see that ] Apr 08 10:05:23 JaMa: it could be just a repo output syntax Apr 08 10:05:37 we include the snippet from the main xml manifest Apr 08 10:07:50 https://github.com/webOS-ports/android/blob/luneos-halium-9.0/halium/default.xml#L868 ok I think I understand Apr 08 10:08:27 the include is related to the root of the manifest folder, i.e. .repo/manifests Apr 08 10:08:48 so we need to create a symlink .repo/manifests/snippets -> .repo/manifests/halium/snippets Apr 08 10:09:44 we probably did that just once for 7.1, and forgot to include it in the build script Apr 08 10:11:04 like in run_halium , after the "mkdir -p .repo/local_manifests/" line Apr 08 10:12:00 or even better, here https://github.com/webOS-ports/jenkins-jobs/blob/master/jenkins-job.sh#L600 Apr 08 11:52:21 hello, is it possible to have mouse/cursor in LuneOS emulated in qemu? Apr 08 12:05:23 Tofe: I did that manually but still doesn't seem to work Apr 08 12:05:27 jenkins@bonaire:~/workspace/halium-luneos-9.0-build/halium-luneos-9.0/.repo/manifests$ ls halium/snippets/ Apr 08 12:05:30 lineage.xml Apr 08 12:05:32 jenkins@bonaire:~/workspace/halium-luneos-9.0-build/halium-luneos-9.0/.repo/manifests$ ln -snf halium/snippets/ . Apr 08 12:05:35 jenkins@bonaire:~/workspace/halium-luneos-9.0-build/halium-luneos-9.0/.repo/manifests$ git pull Apr 08 12:05:38 Already up to date. Apr 08 12:05:41 jenkins@bonaire:~/workspace/halium-luneos-9.0-build/halium-luneos-9.0/.repo/manifests$ cd ../../ Apr 08 12:05:44 jenkins@bonaire:~/workspace/halium-luneos-9.0-build/halium-luneos-9.0$ repo sync -j16 --force-sync -d -c Apr 08 12:05:47 remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 Apr 08 12:05:49 fatal: error parsing manifest /home/jenkins/workspace/halium-luneos-9.0-build/halium-luneos-9.0/.repo/manifest.xml: [Errno 2] No such file or directory: '/home/jenkins/workspace/halium-luneos-9.0-build/halium-luneos-9.0/.repo/manifest.xml' Apr 08 12:06:59 Jonek: mouse should work in qemu Apr 08 12:07:40 unfortunately it doesnt on LuneOS :( on completely other images built with yocto it worked, but here no success. keyboard works though Apr 08 12:08:06 Jonek: are you using virtualbox or qemu to run it? Apr 08 12:08:09 qemu Apr 08 12:08:21 JaMa: that's weird, now it's about "manifest.xml"... Apr 08 12:08:44 Tofe: trying to reinit it in new directory in case it got somehow broken because of that missing branch Apr 08 12:09:21 Jonek: we only use virtualbox and some of the support is virtualbox specific, so it's possible that it just doesn't work in qemu Apr 08 12:09:31 damn okay Apr 08 12:09:54 is LuneOS actually live? or is it dead project? last stable builds point to end of 2019 Apr 08 12:10:29 Tofe: can we create that simlink in the repo? it fails in the "repo init" already Apr 08 12:10:38 test$ repo init --depth=1 -u https://github.com/webos-ports/android.git -b luneos-halium-9.0 Apr 08 12:10:41 remote: Enumerating objects: 9, done. Apr 08 12:10:43 remote: Counting objects: 100% (9/9), done. Apr 08 12:10:46 remote: Compressing objects: 100% (8/8), done. Apr 08 12:10:48 remote: Total 9 (delta 1), reused 4 (delta 0), pack-reused 0 Apr 08 12:10:51 Unpacking objects: 100% (9/9), 11.88 KiB | 760.00 KiB/s, done. Apr 08 12:10:53 fatal: manifest 'default.xml' not available Apr 08 12:10:56 fatal: include [/home/jenkins/workspace/halium-luneos-9.0-build/.repo/manifests/]snippets/lineage.xml doesn't exist or isn't a file Apr 08 12:11:40 or change the include to be ? Apr 08 12:12:21 Jonek: we don't do stable releases, but last testing build is just couple minutes old Apr 08 12:13:29 ok thanks. do you habe any tutorial how to run yocto output image in virtualbox? Apr 08 12:15:35 JaMa: not sure if symlinks are supported by git... Apr 08 12:16:34 JaMa: maybe the latter then. I wanted to try to reuse the subtree as-is, but maybe it's just not possible Apr 08 12:20:13 Jonek: we build emulator appliance which is a zip file with VM description as well as rootfs image, so you just unzip it and use Import Machine in vbox Apr 08 12:20:36 JaMa: https://github.com/webOS-ports/android/pull/6 would that work ?... Apr 08 12:20:50 Tofe: I'm 80% sure symlinks do work, but the later seems cleaner Apr 08 12:20:59 or why not move the snippets directory? Apr 08 12:21:03 will try after lunch Apr 08 12:21:25 seems to work locally at least Apr 08 12:22:36 JaMa: but I want to build the image myself - and I found the yocto repo which is very promising Apr 08 12:23:47 Jonek: https://webos-ports.org/wiki/Build_for_qemux86 Apr 08 12:24:07 Good Morning Apr 08 12:24:23 Instead of "$ MACHINE=qemux86 bitbake -k luneos-dev-emulator-appliance" you can use "$ MACHINE=qemux86-64 bitbake -k luneos-dev-emulator-appliance" Apr 08 12:24:26 ka6sox: Morning! Apr 08 12:24:57 Jonek: We'll push out some stable release again at some point, just there were so many things moving at the same time that we needed to get to a somewhat stable base again. Apr 08 12:25:03 We're getting closer to that Apr 08 12:25:33 great! maybe one day I will be able to help you Apr 08 12:25:51 do you have backlog or timeline? Apr 08 12:30:11 Thank you all, the mouse works on virtualbox! Apr 08 12:30:58 Jonek: Well there are many things, just issue is our bugtracker is down at the moment ;) Apr 08 12:31:00 I prefer qemu though, do you have any ideas where to look? where might be the issue that mouse doesnt work on qemu? Apr 08 12:31:11 Anything you specialize in? Apr 08 12:31:17 Might help to give some pointers ;) Apr 08 12:33:06 well I worked 5 yrs in crypto devices for military (private company, but clients mostly gouvermental/army), but Im pretty new in mobiles Apr 08 12:33:42 so Im getting to know all the android stuff, not a big fan of it Apr 08 12:34:09 A lot of people arent ;) Apr 08 12:34:25 now Im trying to build a phone with linux on it, but the complexity scares me a bit Apr 08 12:34:31 Unfortunately there isn't a lot of choice outside of Android Apr 08 12:34:38 Pinephone is a good target to start with Apr 08 12:34:39 Jonek: https://github.com/webOS-ports/qt5-plugin-generic-vboxtouch is what we use Apr 08 12:34:52 Doesn't break the bank and has mainline kernel support Apr 08 12:34:56 And Android free ;) Apr 08 12:35:18 and LuneOS seems to be a good start - stable (and clear!) yocto build and working emulation Apr 08 12:35:19 All our other targets use a minimal Android as base because the drivers are binary blobs Apr 08 12:35:38 yep, thats something I might need too Apr 08 12:35:46 Well Qemu doesn't use Android, but all other hardware devices do Apr 08 12:35:49 Jonek: removing that plugin and using event device directly from qemu might work Apr 08 12:36:15 whatever hw I will choose I will get some binary blob from manufacturer... Apr 08 12:36:28 JaMa: Thanks, Im gonna check it right away Apr 08 12:36:39 Tofe: will merge the PR for easier test :) Apr 08 12:38:12 one more question - why did you decide to use "wrapper" repo `webos-ports-setup` with envsetup scripts instead of pure yocto repo with submodules or i.e. `kas` tool? Apr 08 12:40:15 Jonek: the webos-ports-setup is just helping us put in place the yocto repos and tools Apr 08 12:40:34 Tofe: was it in correct branch? shouldn't it be in https://github.com/webOS-ports/android/tree/luneos-halium-9.0 ? Apr 08 12:43:03 JaMa: I hope so, let me check again Apr 08 12:43:26 luneos-halium-9.0 branch is the one we repo init Apr 08 12:44:34 yes it's correct Apr 08 12:46:01 hmm it wasn't using latest halium-9.0 commit Apr 08 12:46:19 jenkins@bonaire:~/workspace/halium-luneos-9.0-build/.repo/manifests/halium$ git diff --stat origin/halium-9.0 default.xml | 7 +++---- snippets | 1 - 2 files changed, 3 insertions(+), 5 deletions(-) Apr 08 12:50:47 ok, after one more coffee I realized I didn't merge in correct branch Apr 08 12:51:00 I'll rewrite the halium-9.0 history to erase the last merge Apr 08 12:51:08 ok Apr 08 12:51:37 let me know when it's worth re-trying on jenkins Apr 08 12:52:03 you can retry Apr 08 12:52:40 ok, repo init passed now Apr 08 13:12:22 is there any reason we use kernel 5.8, not 5.4 or 5.9 (LTS)? Apr 08 13:12:43 Jonek: It's the one coming from the Yocto release normally I would say Apr 08 13:12:57 oh really, gatesgarth uses 5.8 natively? ;o Apr 08 13:13:25 Probably, JaMa takes care of most of the Yocto upgrades, he knows more Apr 08 13:15:44 Seems Gatesgarth provides both 5.4 and 5.8: https://github.com/openembedded/openembedded-core/tree/gatesgarth/meta/recipes-kernel/linux Apr 08 13:15:57 I guess JaMa just picked the latest & greatest Apr 08 13:19:17 or just the default one :) Apr 08 13:19:56 I think for zeus I had to backport newer to fix accelerated gpu in vbox, but since then I don't really care about the version in emulator Apr 08 13:20:13 ok thanks Apr 08 13:20:30 JaMa: Also removing vboxtouch didnt help with mouse on qemu :( Apr 08 13:21:04 Jonek: Any old Android device you have laying around is usually not that hard to port LuneOS to ;) Apr 08 13:21:14 At least when it has a LineageOS build Apr 08 13:21:59 well it long before zeus even, and it was 5.0 backported from warrior (probably into thud) and with zeus we switched to default 5.2 https://github.com/webOS-ports/meta-webos-ports/commit/04c22d60ba473a43b2f0d4dd0caf2a305ea260d6 Apr 08 13:22:05 not really, all my old phones lost battery so i had to throw them away :( Apr 08 13:22:42 maybe I should buy pinephone for developement Apr 08 13:22:54 but qemu would be perfect for other devs actually Apr 08 13:23:04 Pinephone isn't that great in terms of specs, but it's the most open in general for now Apr 08 13:25:28 JaMa: any other ideas? other places you might have fiddle with events? Apr 08 13:35:07 Jonek: did you just uninstall the plugin or did you update luna-next configuration as well? (mostly LUNA_NEXT_OPTIONS and QT_QPA_EVDEV_MOUSE_PARAMETERS) Apr 08 13:38:55 i removed the plugin from QEMU_RDEPENDS in `meta-webos-ports/meta-luneos/recipes-core/packagegroups/packagegroup-luneos-extended.bb` Apr 08 14:18:43 update: setting QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/mouse2 results in possibility to press mouse button, and upper right  menu gets clicked but no cursor visible and mouse seems to be frozen in that top right place Apr 08 14:57:40 you also need to update LUNA_NEXT_OPTIONS to enable evdev Apr 08 15:12:01 bluebinder needs small fix with COMPATIBLE_MACHINE http://jenkins.nas-admin.org/job/LuneOS/view/testing/job/luneos-testing_workspace-compare-signatures/219/console will fix Apr 08 17:11:09 JaMa: Could you please be more specific about what should I update? Unfortunately I have no experience in such stuf Apr 08 17:14:18 Jonek: I'll probably be able to help there, one moment Apr 08 17:14:51 much appreciated! thank you ;) Apr 08 17:15:17 Jonek: so, we're talking about /etc/luna-next/environment.conf Apr 08 17:15:25 yes, exactly Apr 08 17:15:42 currently you have LUNA_NEXT_OPTIONS=-plugin VBoxTouch:/dev/input/event3:/dev/input/event4:/dev/input/event5 there Apr 08 17:15:44 I can update it on device for test purposed, right? Apr 08 17:15:49 sure Apr 08 17:16:39 the VBoxTouch module does a merge of the events from the various sources we give him Apr 08 17:17:07 so if you simply add :/dev/input/mouse2 at the end, it should be fine Apr 08 17:17:43 hmm ok, i tried plain "/dev/input/mouse0" and "/dev/input/mouse1" Apr 08 17:18:06 Jonek: git grep LUNA_NEXT_OPTIONS in meta-webos-ports shows some examples Apr 08 17:18:11 but that means I should have vboxtouch plugin compiled in, right? Apr 08 17:18:14 it's been quite some time since I last touched that file for qemu, I hope I don't say anything wrong Apr 08 17:19:20 ooh still catching up with the discussion, sorry Apr 08 17:20:11 should I summarize the problem? ;) Apr 08 17:20:17 yes please :) Apr 08 17:20:22 -plugin evdevtouch and -plugin evdevkeyboard should IMHO work with qemu if you point them to the right event devices exposed for qemu and for the cursor there is IIRC qemu parameter you can pass for it to render the cursor Apr 08 17:20:49 Tofe: he doesn't want to use virtualbox to run it Apr 08 17:21:20 ok, I see now Apr 08 17:21:45 well I will use virtualbox if qemu path will fail, but I would like to understand the problem  ;) Apr 08 17:21:59 then you'll need something like "LUNA_NEXT_OPTIONS=-plugin evdevtouch:/dev/input/mouse2" Apr 08 17:22:05 I think I had input working with QEmu back then in thud based builds when we were stuck with older mesa and were figuring out how to unblock upgrade to warrior Apr 08 17:23:19 and -show-cursor in runqemu Apr 08 17:23:30 JaMa: thanks, was looking for that part Apr 08 17:24:04 oe-core/scripts/runqemu adds that by default when sdl/gtk/egl_headless is enabled Apr 08 17:25:06 webOS OSE emulator used qemu for virtio, but it wasn't any better than what we have with vbox Apr 08 17:26:00 and building own qemu with virgl enabled or using prebuilt qemu from LGE was a bit annoying, but nowadays more distros ship qemu with virgl enabled OOTB Apr 08 17:26:46 Yes, that part is now more common, hopefully Apr 08 17:29:01 looks like ubuntu enabled support in 19.04 Apr 08 17:31:06 https://i.imgur.com/J9WNCst.png Apr 08 17:31:10 my configuration atm Apr 08 17:31:15 does not work Apr 08 17:31:37 unfortunately I have no idea what is the difference between event/mouse in input Apr 08 17:32:06 but my qemu mouse from /proc/bus/input/devices has mouse0 and events2 Apr 08 17:35:07 It just depends on how udev names it; by default it's eventX, but if a mouse is recognized somehow the name might change, or it could choose to create a symlink Apr 08 17:35:20 I didn't look at the udev rules for this, so not sure Apr 08 17:38:29 Jonek: to be sure, you can simply do "cat /dev/input/mouse0" and move the mouse, see if you see hieroglyphs on the screen Apr 08 17:39:32 +Tofe: youre right, thanks. event2 and mouse0 shows oputput Apr 08 17:40:19 ok good; mouse0 is a symlink to events2 maybe? Apr 08 17:41:08 Jonek: what is the QEmu command line you're using? Apr 08 17:41:39 ``` Apr 08 17:41:40 qemu-system-x86_64 \ Apr 08 17:41:40     -net nic -net user \ Apr 08 17:41:41     -object rng-random,filename=/dev/urandom,id=rng0 \ Apr 08 17:41:41     -device virtio-rng-pci,rng=rng0 \ Apr 08 17:41:42     -drive file=/home/pjonski/workspace/webos-ports-setup/webos-ports/tmp-glibc/deploy/images/qemux86-64/luneos-dev-image-qemux86-64-0-0.rootfs.ext4,if=virtio,format=raw \ Apr 08 17:41:42     -cpu core2duo \ Apr 08 17:41:43     -enable-kvm \ Apr 08 17:41:44     -m 1024 \ Apr 08 17:41:44     -kernel /home/pjonski/workspace/webos-ports-setup/webos-ports/tmp-glibc/deploy/images/qemux86-64/bzImage \ Apr 08 17:41:44     -append 'root=/dev/vda rw  mem=1024M oprofile.timer=1 ' \ Apr 08 17:41:45     -display gtk,gl=on \ Apr 08 17:41:45     -device usb-tablet \ Apr 08 17:41:46     -usb \ Apr 08 17:41:47     -show-cursor Apr 08 17:41:47 ``` Apr 08 17:41:54 sorries, spammed a bit Apr 08 17:42:14 np, thanks Apr 08 17:42:25 +Tofe: might be, but the output differs a lot between those two files: event2 and mouse0 Apr 08 17:42:48 no its not symlink Apr 08 17:44:15 have you tried to use vmdk for the drive? that's what I did now, but unfortunately then you cannot use if=virtio as the rootfs will still be /dev/sda1 as included in the image Apr 08 17:44:48 no I havent, would that make any difference here? Apr 08 17:46:23 not really, I was going to use vmdk just because that's what I already have as we build it for virtualbox Apr 08 18:06:19 I'll just download the image and try Apr 08 18:37:14 Btw I have a question - who is developing LuneOS now? Are you somehow connected in one company or you are just enthusiasts doing it in free time? Apr 08 18:37:47 the latter :) Apr 08 18:38:16 great respect for all of you then Apr 08 18:38:23 Though we try to integrate the interesting progress made by LG on webos-OSE Apr 08 18:39:51 thanks - the counterpart is that we're a small team, so things are slow. But for me the goal is to keep learning various stuff, and working on a whole OS is a great way to do that :p Apr 08 18:41:05 JaMa: when started with a vmdk, the initial boot keeps trying running fsck on the root partition, which seems to fail in timeout... do you have a specific "-drive" option there? Apr 08 18:41:56 Im trying to figure out how much effort it would take to use MediaTek processor (MediaTek will provide sources to OS based on OASP) and run LuneOS on it. You guys must have ported android code to LuneOS before, right? Apr 08 18:46:34 We've only done qualcomm devices so far; mediatek devices tend to have various obscure deviations (kernel, drivers, blobs) that make it hard to hack it Apr 08 18:47:34 For the reuse of Android driver, a project has been put in place, named Halium: the goal is to provide a reusable set of Android drivers for a glibc-based OS on mobile devices Apr 08 18:47:53 maybe there are some Mediatek devices done for Halium Apr 08 18:53:06 ok great, so if there is some device using proc I like in halium, it should be possible to "easy" port LuneOS to it? Apr 08 18:55:37 The main work is actually getting a Halium build to work, the rest is easy Apr 08 18:56:53 can you elaborate or send some links to learn? I dont know halium :( Apr 08 19:02:41 there's https://halium.org/ Apr 08 19:03:32 and usually, people discuss on #halium or https://t.me/halium Apr 08 19:04:52 Before Halium, each distro (Ubuntu Touch, Plasma Mobile, LuneOS, Sailfishos-ports...) did their own effort to get Android drivers running alongside the main distro Apr 08 19:05:13 Now it more or less the same guys, but doing the work only once :) Apr 08 19:05:21 :D great Apr 08 19:05:35 ok so with halium I build what? drivers only? drivers as modules? full kernel? Apr 08 19:06:47 You basically build a minimalistic Android, without any java,UI,apk... but with the services that initialize the hardware and get it running Apr 08 19:07:06 In LuneOS we start that inside a LXC container Apr 08 19:07:49 the kernel is a hybrid: it's the Android kernel, but with some more options to have it running well on a glibc-based distro Apr 08 19:09:00 but LuneOS build its own pure-linux kernel right? do we use two kernels at the same time? Apr 08 19:09:33 "it depends" :) Apr 08 19:09:52 We can only use a pure-linux kernel where the hardware is correctly supported Apr 08 19:10:11 I mean I built Lune only for Pinephone and qemu so no android was needed, but when I would like to build it ie for Nexus - I would have to build minimalistic android outside of yocto? Apr 08 19:10:45 Pinephone is a special case, where the constructor is trying to get all the drivers upstream Apr 08 19:10:50 same for Purism Apr 08 19:11:15 but for usual Android devices, it's far from this ideal case Apr 08 19:11:38 yep, but my point is that I didnt use halium (or i didnt know that) Apr 08 19:12:05 they develop their driver on the kernel they know (3.18, 4.4, rarely newer ...) and then drop everything in a github repo and that's all Apr 08 19:12:26 do you have halium build integrated in yocto flow or you need to supply pre-built halium to yocto? Apr 08 19:12:53 It was too much work integrating the whole Android toolchain; so Halium is built separately Apr 08 19:13:09 ok thats what I thought Apr 08 19:13:39 We still build the Android kernel with yocto, though Apr 08 19:14:05 (sometimes with tons of patches to have it compile with gcc 10) Apr 08 19:14:16 hmm thats the part I dont understand Apr 08 19:14:25 the kernel ? Apr 08 19:14:31 you build halium (it has android kernel, right?) and then build android kernel in yocto? Apr 08 19:15:06 well... yes; we just drop the kernel image we get out of the halium build Apr 08 19:15:39 we possibly could tell the android toolchain to avoid building the kernel, but that's not really a big deal Apr 08 19:15:45 oh ok. So what do you take from halium? modules? Apr 08 19:15:56 system.img and vendor.img Apr 08 19:16:23 system.img is just rootfs? Apr 08 19:16:37 starting from Android 9, yes Apr 08 19:16:54 well wait Apr 08 19:17:08 it's rootfs in the sense that it's the root of the android filesystem Apr 08 19:17:21 it has all the binaries and stuff, apart from /vendor Apr 08 19:17:31 yes, thats what I meant Apr 08 19:17:59 and then you build kernel with yocto and additional apps and put it into that system.img? Apr 08 19:19:17 no additional apps; only the minimal hardware-related stuff is built and included in system.img. Kernel, also, is a separate image Apr 08 19:19:37 once system.img and vendor.img are built, yocto doesn't touch it anymore Apr 08 19:19:48 we mount it during boot, and use it inside lxc Apr 08 19:20:39 We built boot.img with yocto entirely Apr 08 19:20:39 So we basically run linux that runs android in a container? Apr 08 19:20:48 yes Apr 08 19:21:22 I start to understand! Apr 08 19:23:15 It all started years ago when the "libhybris" library was born: someone hacked the android linker, and made it possible to reuse an Android driver (based on bionic libc) on a standard linux OS (based on glibc). At the beginning, only the display drivers were targetted... then it broadened. Apr 08 19:25:27 If you want to try a Halium port, I can help, Herrie too, we've done it a couple of times already Apr 08 19:26:27 https://wiki.merproject.org/wiki/Adaptations/libhybris this can give a hint as to what has been tried to far Apr 08 19:27:36 Well Vollaphone has MediaTek Apr 08 19:27:44 And that works Apr 08 19:27:58 Im thinking about it, we are thinking about creating a bit different phone from whats found on the market and we would like to base OS on linux and keep it opensource, but its really hard to do that, all manufacturers supply only android soft Apr 08 19:28:10 Herrie: oh right ! totally forgot about it Apr 08 19:31:40 that works mean you ported LuneOS for it? Apr 08 19:32:08 or there is just halium Apr 08 19:33:37 https://github.com/shr-distribution/meta-smartphone/tree/master/meta-volla it works - I don't recall the lastest status, but it wasn't bad Apr 08 19:34:44 oh wow! Apr 08 19:36:02 I didn't participate much on that one - Herrie helped most of the way Apr 08 19:36:31 It works more or less Apr 08 19:36:37 Boots UI Apr 08 19:36:43 Other things need work Apr 08 19:36:50 Like wifi, bt etc Apr 08 19:37:12 ah ok, I thought is was a bit more. Well, still, it's a good start Apr 08 19:37:21 Well maybe rotation Apr 08 19:37:48 Some things worked for sure Apr 08 19:38:03 Jonek: I did this without device Apr 08 19:38:05 ok, thats something Apr 08 19:38:21 how did you do it without device? Apr 08 19:38:31 Remote user Apr 08 19:38:37 I build stuff Apr 08 19:38:57 He likes to hack around blindfolded :p Apr 08 19:39:25 ok but you had to try it on the device eventually Apr 08 19:39:37 Yeah remote user did Apr 08 19:39:50 I still don't have this device Apr 08 19:40:03 ok I get it Apr 08 19:40:47 So it's both great and not great, depends if that remote user remains interested in this port Apr 08 19:41:23 well Vollaphone runs on MediaTek P23, Im thinking A20, is it a big difference? Apr 08 19:42:56 sorry for interrupting - but if you want to build a Linux phone, avoid Mediatek by all means Apr 08 19:43:23 oh really? thank you for that interruption then! do you have some more insight? Apr 08 19:46:59 brb 20mins Apr 08 19:47:17 Mediatek SoCs(especially recent ones) have little or no support in mainline kernel, and no work is being done on making them run upstream kernel. The situation with custom/libre bootloaders is similar, there are almost none for MTK. Also, usually the stock kernel is very broken, volla was lucky, I guess. The only good thing I can say about MTK is that their leaked code/SoC documentation/datasheets are everywhere. Code Apr 08 19:47:17 is usually poor quality and even contains `#define BACKDOOR` (true story, lol). So I definitely wouldn't suggest Mediatek platforms. Apr 08 19:48:42 oh damn. how about android releases, are they any better? Apr 08 19:53:26 well, I bet Android releases run same kernel as Linux ones, but Android releases might have even more quirks Apr 08 19:59:06 Sorry was on a call, more here now ;) Apr 08 20:02:06 qualcomm's BSP is also quite terrible, it's difficult to compare what's worse Apr 08 20:03:37 Tofe: with vmdk it's a bit annoying, because with if=virtio you get /dev/vda, but in syslinux we hardcode root=/dev/sda2 and because the kernel is in vmdk you cannot use -append to pass different root=, I don't remember how I was resolving this (other than mounting the vmdk and changing the syslinux before booting it with qemu) Apr 08 20:04:46 and OSE's virtualbox config uses ide drive, so the syslinux there hardcodes root=/dev/hda2 Apr 08 20:05:08 bbl Apr 08 20:07:08 at least most of Qualcomm's SoCs are supported by mainline Linux, and support is being added constantly by enthusiasts and Linaro Apr 08 20:09:00 true I was thinking about the other bits and pieces than kernel from meta-qti Apr 08 20:09:46 dinner isn't ready yet, so back a bit sooner than expected :) Apr 08 20:11:54 Jonek: for halium image you can fetch one from http://build.webos-ports.org/halium-luneos-9.0/ to look at it and if it wasn't clear from Tofe's message, the build of this image isn't using Yocto (it's completely separate jenkins job), but this image is then fetched by OE recipe and integrated into the OE image automatically, so in the end you have one package to install on phone which has all necessary Apr 08 20:12:00 parts baked by bitbake Apr 08 20:12:59 https://github.com/shr-distribution/meta-smartphone/blob/master/meta-volla/recipes-core/android-system-image/android-system-image-yggdrasil.bb Apr 08 20:13:02 https://github.com/shr-distribution/meta-smartphone/blob/master/meta-android/recipes-core/android-system-image/android-system-image.inc Apr 08 20:14:55 Halium image is basically a very minimal Android build that can be used in combination with libhybris to access the hardware Apr 08 20:15:03 Kernel is still Android kernel with modified defconfig. Apr 08 20:15:33 We got it to work with as old as 3.4, but systemd requires quite some patches to the kernel on such old versions Apr 08 20:15:43 The 4.x kernels require a lot less patching Apr 08 20:22:10 FWIW we share similar defconfig with Mer/SFOS. UBPorts/UBTouch uses quite some different features. Apr 08 20:29:55 first of all - thank you all for the explaination. that is not the knowledge easy to be found on the net Apr 08 20:30:31 +Herrie: the kernel you mentined now in last messeges is halium kernel, which we drop anyway and build new one in yocto, correct? Apr 08 20:31:11 Jonek: We build Halium/Android kernel inside of Yocto with newer GCC yes Apr 08 20:31:16 Jonek: https://github.com/shr-distribution/meta-smartphone/blob/master/meta-volla/recipes-kernel/linux/linux-volla-yggdrasil_git.bb Apr 08 20:32:21 the recipe is in BSP, but builds from slightly modified android sources Apr 08 20:32:44 while e.g. qemux86 builds use linux-yocto kernels which are much closer to vanilla Apr 08 20:33:49 yep, so thats the great difference - I built for qemux86_64 and was happy that I got fresh kernel 5.8... while building for any phone will be for some old 3.x or 4.x android kernel Apr 08 20:33:53 and pinephone has own sources which aren't android, but aren't vanilla as well from https://github.com/webOS-ports/meta-pine64-luneos/blob/master/recipes-kernel/linux/linux-pinephone_5.8.bb Apr 08 20:34:24 Jonek: We basically take LineageOS kernel and modify the defconfig + apply any patches to keep GCC happy. SO usually 3.x or 4.x kernel Apr 08 20:34:37 Most newer devices come with 4.x at least Apr 08 20:34:59 using the same kernel for all supported MACHINEs is just a wet-dream :/ Apr 08 20:35:57 even linux-yocto needs quite a few quirks to support those few qemu* MACHINEs and few other on the same base version Apr 08 20:36:19 completely different devices with no support from their vendor is completely different challenge for small (or even big) team Apr 08 20:37:34 great, thanks! Apr 08 20:38:32 I have tried to at least callect them in the same repo shr-distribution/linux so that each MACHINE has just a different branch, but even that is deteriorating as I have less time now and others do most of the work (and I also kind of intentionally ignore all android/halium stuff) Apr 08 22:41:59 one more fix needed for bluebinder http://jenkins.nas-admin.org/job/LuneOS/view/halium/job/luneos-testing_workspace-compare-signatures/220/console Apr 08 23:46:48 Tofe: Herrie: http://jenkins.nas-admin.org/job/LuneOS/view/halium/job/halium-luneos-9.0-build/10/console now fails to find Easter Eggs :) Apr 08 23:46:51 ninja: error: '/home/jenkins/workspace/halium-luneos-9.0-build/halium-luneos-9.0/out/soong/host/linux-x86/bin/d8', needed by '/home/jenkins/workspace/halium-luneos-9.0-build/halium-luneos-9.0/out/soong/.intermediates/frameworks/base/packages/EasterEgg/EasterEgg/android_common/dex/EasterEgg.jar', missing and no known rule to make it Apr 08 23:47:28 or rather vice versa **** ENDING LOGGING AT Fri Apr 09 03:00:09 2021