**** BEGIN LOGGING AT Thu Feb 28 02:59:57 2019 Feb 28 06:57:20 Tofe: I've switched unstable branch to sumo last night, qemux86 is already built, tissot now in progress should finish in 6 hours or so, then will switch it to rocko and regenerate these 2 as well Feb 28 06:57:35 just in case you want to compare behavior with the local build Feb 28 07:31:12 good thing is that rocko build for tissot from jenkins seems to be working fine Feb 28 07:32:34 anyone willing to test rocko on some other devices? images are in http://build.webos-ports.org/luneos-unstable-rocko Feb 28 08:20:26 Morning! Feb 28 08:21:13 JaMa: I have a Hammerhead ready for testing here Feb 28 08:21:50 novaldex|away: Seems we're missing repo on our builder? /tmp/jenkins3492798055279654027.sh: line 45: repo: command not found Feb 28 08:21:56 http://jenkins.nas-admin.org/job/halium-luneos-5.1-build/lastBuild/console Feb 28 08:27:33 were the builders upgraded to 18.04 recently? Feb 28 08:27:40 Herrie|Laptop: great Feb 28 08:28:03 JaMa: Yes. Novaldex did this last week. Why? Feb 28 08:29:13 Should be no issues right? At least my local builder on 18.04 behaves well ;) Feb 28 08:30:05 just noticed that sstate wasn't reused and now it builds native parts for 18.04 Feb 28 08:30:17 everybody who is using sstate from jenkins should upgrade to 18.04 as well Feb 28 08:33:47 JaMa: Not sure who is currently? You're not using Ubuntu, Tofe also not? Feb 28 08:33:50 Seems just me? Feb 28 08:34:04 Maybe elvispre as well Feb 28 08:34:05 Herrie|Laptop: maybe just you Feb 28 08:34:22 my connection isn't good enough to make it worth it Feb 28 08:34:24 Anyway sstate cache for me isn't a necessity that much ;) Feb 28 08:34:57 I might max out on bandwidth on the server, never checked Feb 28 08:35:08 Tofe: Well soon yours should be better right? Feb 28 08:36:16 Herrie|Laptop: I'm using ubuntu 18.04 for a while now, but not the sstate from jenkins because of local changes Feb 28 08:36:43 JaMa: Ah ok, I thought you were on Gentoo? Feb 28 08:36:49 Herrie|Laptop: but maybe it's somewhere in the documentation or the default setup Feb 28 08:37:08 then we should drop the default, to save some http requests to fileserver Feb 28 08:37:53 I was using Gentoo chroot for SHR/LuneOS builds and ubuntu for LGE builds until about a year ago, but then unified them both for ubuntu Feb 28 08:38:17 Ah ok :) Feb 28 08:38:48 https://github.com/webOS-ports/webos-ports-setup/blob/master/conf/local.conf#L61 Feb 28 08:40:00 https://www.webos-ports.org/wiki/Getting_Started_With_Development still says 12.04 oh well Feb 28 08:41:48 will regenerate pyro builds on 18.04 after unstable/rocko is done Feb 28 08:43:12 JaMa: OK Feb 28 08:44:03 I'll update the documentation to say it works with Ubuntu from 12.04 but that 18.04 is recommended Feb 28 08:46:05 12.04 might not work anymore because of host gcc Feb 28 08:46:13 I've updated it to say 18.04 already Feb 28 08:46:17 OK Feb 28 08:46:48 I think we need at least gcc-6 for some of the native builds and 12.04 is iirc on gcc5 Feb 28 08:47:14 and it's EoL anyway, so nobody should use it Feb 28 08:48:07 14.04 has only 2 months of support left, so the same Feb 28 08:49:00 I've deleted sstate cache on file server to regenerate it properly later Feb 28 08:49:59 Herrie|Laptop: I still have been contacted by my ISP, and they say it's them that will contact me to trigger the installation Feb 28 08:50:04 haven't* Feb 28 08:52:32 JaMa: I'm currently switching back to pyro to debug again the keyboard issue on xiaomi devices, but I'll gladly test your rocko/sumo builds too Feb 28 08:53:27 Tofe: Well they usually take their time with these things Feb 28 08:53:57 Tofe: I've seen VKB issue on other targets as well, just less prominent Feb 28 08:54:03 So could very well be related Feb 28 08:57:28 Tofe: good, yesterday I've seen VKB issue on pyro build and today not on rocko, but that probably doesn't mean anything, IIRC you said that it happens randomly Feb 28 09:05:30 Herrie|Laptop: I was thinking, it might be related to the nyx touchpanel merge we did for OSE Feb 28 09:06:02 Morning! Feb 28 09:06:17 Tofe: To be honest I doubt that, I've seen issues before OSE merge as well on various targets Feb 28 09:06:21 Herrie|Laptop: i'm not familiar with the repo command & can't find a reference to it yet, sure that's not a typo? Feb 28 09:06:26 mmh true Feb 28 09:06:30 But could be a combination of things Feb 28 09:07:18 novaldex: See https://docs.halium.org/en/latest/porting/first-steps.html Feb 28 09:07:21 correction, i've found a reference, but it's an Android command.. Feb 28 09:07:28 And the "Install the required dependencies:" section ;) Feb 28 09:07:42 It's Google's git-like system Feb 28 09:07:54 They use for building Android (and we for Halium) Feb 28 09:08:05 typical! why use what everyone else has already.. okay, i'll look into it Feb 28 09:08:23 Need to add this one to our documentation ;-) Feb 28 09:08:29 novaldex: Yeah typical Google, they think they know better. Sometimes do, sometimes don't ;) Feb 28 09:09:08 novaldex: While you're at it, you can check the whole list Feb 28 09:09:16 Might be a few more that we need after the 18.04 upgrade Feb 28 09:10:26 sure, do you have the link to our list again please? Feb 28 09:11:19 or did you mean the Halium dependencies list? Feb 28 09:11:28 novaldex: Yeah the halium dependencies one Feb 28 09:11:44 make sure that python3-distutils is included in the docs as well Feb 28 09:11:52 as in https://github.com/webosose/build-webos/commit/8ebd42d5656f5f822fff8fd9cbaf53652be56a63#diff-d6c5855a62cf32a4dadbc2831f0f295f Feb 28 09:12:17 it's usually installed in default *ubuntu installs, but e.g. in small docker images it's often missing Feb 28 09:22:25 apt is reporting the following from the Halium list need installing as new: Feb 28 09:22:27 liblz4-tool libreadline-dev:i386 libreadline7:i386 lzop mingw-w64-common mingw-w64-i686-dev python-kerberos repo Feb 28 09:22:53 there's other updates i'll take care of just now too Feb 28 09:23:12 i'll verify python3-distutils in a moment Feb 28 09:23:53 python3-distutils is there Feb 28 09:24:58 Tofe: Herrie|Laptop: for rocko builds on other android MACHINEs we'll probably need kernel fix like tissot got in https://github.com/shr-distribution/meta-smartphone/commit/6424fb3835625d954d8947a85c1a7fd0e56947ac Feb 28 09:36:05 novaldex: repo is a sort of meta git: it handles a list of git repos, and facilitates the simultaneous management of all these repos Feb 28 09:36:30 Thanks Tofe! Feb 28 09:37:06 bonaire is now up to date Feb 28 09:39:56 novaldex: it's like git submodules but a bit less annoying Feb 28 09:40:23 git is enough to wrap your head around at times I find! Feb 28 09:46:38 JaMa: thinking of which, did you ever consider using repo for webos-ports-setup ? Feb 28 09:47:18 Though it could be we need a more flexible way of switching between branches Feb 28 09:50:58 Tofe: I did long time ago when converting SHR setup repo from calling git update directly in Makefile to using layerman (orignally from Angstrom) and then again when fixing MCF in LG to support the work flows I use and I'm still quite happy with layerman (less happy with MCF) but I can be persuaded otherwise if people find repo more useful (or generally much more common nowadays) Feb 28 09:51:39 I hate combo-layer tool and git submodules, because they prevent you from using the individual git repositories as every other repository Feb 28 09:52:17 e.g. sending git pull request from poky just for bitbake repository included there you need to first "export" it to separate bitbake repo and then send from there Feb 28 09:52:54 also the .git/config is shared by multiple "subprojects" etc, so you cannot set different emails where to send patches etc Feb 28 09:53:38 layerman/MCF doesn't get in way so much, you can still update separately or do anything you want with the repos Feb 28 09:54:09 and use layerman/MCF only from time to time to update to exactly whatever is set by the DISTRO Feb 28 09:57:00 for CI it gets a bit more messy, in MCF we now have support for checking right refspecs from gerrit based on jenkins trigger and support for GPVB which can set different refspecs for different subprojects as well in one go Feb 28 09:57:56 in repo it's a bit more complicated, but there were some improvements recently which allows jenkins trigger to get some kind of repo change list and then test multiple subprojects changes together in CI Feb 28 09:58:05 but I haven't tested that yet Feb 28 09:58:27 I've only seen the reviews for repo/jenkins, but never even checked if they were actually merged in that form Feb 28 09:59:48 I never really tried either; frankly, today the only thing I'm missing is a "repo status" and "repo diff" equivalent for what we have Feb 28 10:02:10 agreed, status/diff would be useful, let me check if layerman supports that Feb 28 10:04:54 there is the changelog command which can compare against previous tags which could be used (if you create local tags for various stages locally), but that's not very useful and assumes you always commit everything :/ Feb 28 10:05:02 it should be relatively easy to add Feb 28 10:07:38 fwiw angstrom doesn't use oebb/layerman anymore and switched to repo https://github.com/Angstrom-distribution/angstrom-manifest Feb 28 10:08:10 yoe-distro is using submodules https://github.com/YoeDistro/yoe-distro/tree/master/sources Feb 28 10:08:15 poky uses combo-layer Feb 28 10:17:12 Morning! Feb 28 10:18:26 morning Feb 28 10:21:31 Did I pick up that Ubuntu 18.01 is now the recommended choice? Feb 28 10:37:41 elvispre|cloud: it's what most of us use today, so I'd say yes Feb 28 10:40:29 Suits me. My VM under Windows is there already. JaMa said something about the sstate server I think. Feb 28 10:54:18 novaldex: Thanks, scheduled a new build Feb 28 11:35:30 elvispre|cloud: yes 18.04 is needed since last week to use sstate from jenkins Feb 28 11:36:27 Herrie|Laptop: can I delay your job for a bit until sumo unstable is finished? shouldn't take long, just rsync and cleanup Feb 28 12:16:03 JaMa: Sure Feb 28 12:16:13 Nothing too urgent, just wanted to check stuff works on 18.04 Feb 28 12:16:59 Halium guys merged PR that fixed the 18.04 issues: https://github.com/Halium/android_system_core/pull/6/files Feb 28 13:04:59 Herrie|Laptop: http://jenkins.nas-admin.org/view/luneos-unstable/job/halium-luneos-5.1-build/21/console Feb 28 13:05:07 there are some other issues now Feb 28 13:05:18 do you want me to manually clean the workspace of it? Feb 28 13:05:36 otherwise I'll kick rocko builds (2x 6 hours) Feb 28 13:13:11 Herrie|Laptop: https://paste.ubuntu.com/p/MzfMxpxm5s/ Feb 28 13:13:33 should I undo these and let it fetch clean? Feb 28 13:18:19 it also warns that we should upgrade repo Feb 28 13:18:21 ... A new repo command ( 1.25) is available. Feb 28 13:18:44 ... You should upgrade soon: Feb 28 13:18:44 cp /home/jenkins/halium-luneos-5.1/.repo/repo/repo /usr/bin/repo Feb 28 13:25:22 I've moved the diff from hammerhead to ~/halium-luneos-5.1.hammerhead.diff now the repo sync can progress a bit more: Deleting obsolete path /home/jenkins/halium-luneos-5.1/device/lge/hammerhead Feb 28 13:25:35 Deleting obsolete path /home/jenkins/halium-luneos-5.1/kernel/lge/hammerhead Feb 28 13:25:38 error: Cannot remove project "vendor/lge": uncommitted changes are present commit changes, then run sync again Feb 28 13:29:45 is it skipping them, because they aren't listed in the manifest? Feb 28 13:42:26 JaMa: That repo obsolescence warning is due to the version provided by Ubuntu, isn't it? Feb 28 13:43:08 elvispre|cloud: yes Feb 28 13:43:40 Herrie|Laptop: running repo forall -vc "git reset --hard" also at the end of build_device() should help, right? unless the build also fails in the middle Feb 28 13:44:41 Herrie|Laptop: don't you want to move halium jobs to jenkins-job.sh? It might be easier to see what's going on than http://jenkins.nas-admin.org/view/luneos-unstable/job/halium-luneos-5.1-build/jobConfigHistory/ Feb 28 13:47:08 http://jenkins.nas-admin.org/view/luneos-unstable/job/halium-luneos-5.1-build/jobConfigHistory/showDiffFiles?timestamp1=2019-02-28_08-23-31×tamp2=2019-02-28_13-46-51 Feb 28 13:47:12 will trigger new build Feb 28 14:00:57 JaMa: I noticed a slight difference before between 5.1 and 7.1 script. This was the git reset --hard.I think I recently added it to 5.1 Feb 28 14:01:03 Or was planning to do so Feb 28 14:02:23 it's at the beginning of build_device() for both 5.1 and 7.1 but that's not enough Feb 28 14:03:02 JaMa: Ah OK, yeah in case it fails that might be an issue somehow Feb 28 14:03:29 not only when it fails, currently it's an issue between each 2 builds Feb 28 14:03:42 with my fix it will be an issue only when the build fails Feb 28 14:03:44 It was introduced to solve that ;) Feb 28 14:03:54 By Tofe at some point a while ago Feb 28 14:04:32 still it didn't work, because there was no git reset between last device build and repo sync in the next jenkins job Feb 28 14:05:27 and repo sync (at least in current version of repo now used) refused to remove e.g. vendor/lge with local modifications when doing repo sync in next build Feb 28 14:06:30 JaMa: Ah OK Feb 28 14:06:58 and doing it before repo sync didn't work as well, because the modified repos were skipped Feb 28 14:07:09 The Halium build originates from original morphis builds to build the Android bits. I don't think we have an objection to include them in jenkins-jobs.sh Feb 28 14:49:00 Just historically it was done that way. Feb 28 20:26:19 I might have found the solution for the vkb issue Feb 28 20:27:03 in /etc/luna-next/environment.conf, just get rid of "-plugin evdevkeyboard", which seem to conflict with /dev/input/event1 touchscreen Feb 28 20:27:42 it's not perfect tough, it seems we lose the other keys as well (vol+/-, power...) Feb 28 20:28:12 so just excluding the touchscreen input would be nice, but I'm not sure how this can be done syntaxically Feb 28 20:36:21 Tofe: Nice find though. Feb 28 20:37:20 I think I just found the syntax to only opt-in some input devices Feb 28 20:37:45 but as it is a random issue, it might also be that my analysis is incorrect... Feb 28 20:38:07 still, it works pretty well so far, and I got the keys back :p Feb 28 20:38:26 I'll propose a PR, you'll tell me how this works out for you Feb 28 20:42:53 https://github.com/webOS-ports/meta-webos-ports/pull/312 my proposal, I hope it'll work ! Feb 28 21:30:20 oh no... it doesn't solve the issue on rosy :( Feb 28 21:30:20 Tofe: is it event0 and event6 on all supported MACHINEs? or does this apply only for tissot and each MACHINE will need a fix like this? Feb 28 21:30:58 JaMa: only tissot; rosy, for instance, is event0 and event4. I'm even surprise that these numbers are stable upon reboots... Feb 28 21:31:28 Tofe: halium-luneos-5.1-build job failed again (even after I've cleaned it locally and tested that repo sync works on bonaire builder.. strange, but there is PR for you to review :) Feb 28 21:32:18 what PR ? I didn't get any mail about it Feb 28 21:32:19 https://github.com/webOS-ports/jenkins-jobs/pull/5 Feb 28 21:32:24 thanks Feb 28 21:33:17 got it Feb 28 21:35:01 will test it manually on bonaire now trying to fix 5.1 checkout Feb 28 21:38:02 the PR looks good at first sight (see my little comment, to simply it a tiny little bit) Feb 28 21:39:56 I see "error: Cannot remove project "device/lge/hammerhead": uncommitted changes are present commit changes, then run sync again" ... strange, it should be handled by the script... Feb 28 21:40:39 see my earlier discussion with Herrie or just http://jenkins.nas-admin.org/view/luneos-unstable/job/halium-luneos-5.1-build/jobConfigHistory/showDiffFiles?timestamp1=2019-02-28_08-23-31×tamp2=2019-02-28_13-46-51 but strangly it's still not enough Feb 28 21:41:10 thanks for comment this is exactly the thing I wanted to simplify later (after first successful build through jenkins-job.sh) Feb 28 21:42:48 without knowing the history it's difficult for me to see if some differences like this were intentional or just introduced in only one of them and someone forgot to apply in the other one Feb 28 21:43:06 JaMa: it might be that the current source code is in a bad state, and there is no ' repo forall -vc "git reset --hard" ' at the very beginning of run_halium Feb 28 21:43:46 but I should read the rest of the log... Feb 28 21:44:00 true, but I think the problem is that the "repo forall" skips the repos not currently in the manifest Feb 28 21:44:13 that could very well be Feb 28 21:45:22 you'll a cleanup step, just this one time Feb 28 21:45:30 +need Feb 28 21:45:30 so the modifications from "some other device" aren't reset and then when it calls repo sync it fails (because it refuses to delete local checkout of e.g. device/lge vendor/lge) Feb 28 21:45:48 cleanup as "repo forall -vc "git reset --hard"" or something deeper? Feb 28 21:46:48 I've executed it manually now and it seems to work now (from jenkins-job.sh) Feb 28 21:46:59 I would do something more radical, like "for i in *; do (cd $i; git reset --hard ); done" Feb 28 21:47:20 ah good Feb 28 21:47:54 then it could be a good idea to insert it just before the "repo sync" line in run_halium Feb 28 21:48:59 ok, but should do it for every directory with .git in it (as some aren't on the top level) Feb 28 21:49:24 I mean, you just did repo forall by hand, isn't it ? Feb 28 21:49:34 and it clean hammerhead as well it seems Feb 28 21:49:39 cleaned* Feb 28 21:51:18 So my proposal for the "for i in * ...." is useless, if "repo forall" works well Feb 28 22:03:23 sorry, was AFK, kid duty Feb 28 22:04:06 no pb I'll have sleep duty soon anyway :) Feb 28 22:04:43 I mean I've executed jenkins-job.sh manually on the jenkins builder to see if my modifications from PR work and it finished repo sync OK, but now looking at the log https://paste.ubuntu.com/p/mVSJcTFYJ8/ I see that it started building onlyx in halium-build-5.1 directory, so there is some bug in my jenkins-job.sh changes and that might be the reason why it didn't fail exactly the same as the real jenkins Feb 28 22:04:48 job before Feb 28 22:05:01 http://jenkins.nas-admin.org/view/halium/job/halium-luneos-5.1-build/22/console Feb 28 22:06:24 ^ this one was executed after my changes to the job script (to call repo forall also after each MACHINE build) and _after_ me running git reset --hard in device/lge/hammerhead and vendor/lge manually and testing that repo sync worked (that's why it really shouldn't fail with error: Cannot remove project "device/lge/hammerhead": uncommitted changes are present Feb 28 22:06:40 unless there is some strange interaction between 5.1 and 7.1 jobs Feb 28 22:09:02 no, onyx hammerhead all this is 5.1; so we should be able to explain it only with 5.1 Feb 28 22:10:19 a detail: we should create .repo/local_manifests if it doesn't exist already Feb 28 22:10:22 but in jenkins-job found (the original script was already using BUILD_VERSION Feb 28 22:10:41 yup I've seen that one as well Feb 28 22:14:33 I quite don't have a clue... and I begin to fall asleep :) So I'll sleep over it, and see if I can better help tomorrow Feb 28 22:19:07 np, I've added 2 commits which should hopefully fix that, gnite Feb 28 23:06:00 Tofe: (For when you wake up,) I have built and flashed a dev image based on your meta-webos-ports branch Feb 28 23:07:42 Tofe: Unfortunately, for me, the keyboard was still not usable during First Use. Feb 28 23:08:26 Tofe: It is not working after a restart either. I am unable to enter my Wi-Fi password. Feb 28 23:09:26 Tofe: I see no difference in behaviour. (Talking about tissot, to be clear.) Feb 28 23:09:56 Herrie: do you have some pending changes for halium-5.1 build on 18.04? Feb 28 23:10:00 system/core/liblog/fake_log_device.c:463:13: error: argument 1 value ‘4294967288’ exceeds maximum object size 2147483647 [-Werror=alloc-size-larger-than=] vec = (struct iovec*)malloc(sizeof(struct iovec)*numVecs); ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Feb 28 23:13:44 Tofe: But on the third boot, the keyboard did work properly. Mar 01 00:22:21 bonaire has some strange issue with node-gyp-native: | npm ERR! request to https://registry.npmjs.org/core-util-is/-/core-util-is-1.0.2.tgz failed, reason: getaddrinfo EAI_AGAIN registry.npmjs.org:443 Mar 01 00:23:57 3rd time charm, now it installed ok **** ENDING LOGGING AT Fri Mar 01 02:59:57 2019