**** BEGIN LOGGING AT Wed Mar 07 03:00:01 2018
Mar 07 04:48:39 <bshah> Herrie|2: Tofe: I did break the halium manifest by mistake, (libcore sync failure) should be fixed now
Mar 07 05:16:24 <ka6sox> Tofe, Herrie|2 I had to reboot jenkins...try again let's see if it completes.
Mar 07 05:16:49 <ka6sox> so clean up any messes and start builds over.
Mar 07 05:55:10 <Herrie|2> ka6sox: Thnx let me try
Mar 07 05:55:17 <Herrie|2> bshah: weird it worked for me?
Mar 07 05:55:32 <Herrie|2> bshah: I mean earlier when I tested before you merged?
Mar 07 05:59:26 <bshah> Herrie|2: it's because you might have local hal remote as github.com/halium instead of github.com
Mar 07 06:00:06 <Herrie|2> bshah: Ah that could be!
Mar 07 06:00:09 <Herrie|2> TOfe: https://bpaste.net/show/994e59d652ef
Mar 07 06:00:13 <Herrie|2> I haven't seen this before
Mar 07 06:00:39 <Herrie|2> Did you change anything in the halium-luneos-5.1-build script?
Mar 07 07:23:52 <Tofe> ka6sox: all good, thanks!
Mar 07 07:24:12 <Tofe> (well I mean the server is up, I didn't test a build yet)
Mar 07 07:24:46 <Tofe> Herrie|2: yes, I've included system.img in the tgz, that's all
Mar 07 07:27:08 <Tofe> But I didn't touch mako's kernel or anything
Mar 07 07:28:10 <Tofe> "fixdep: error opening config file: /home/jenkins/halium-wop-5.1/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/lib/gcc/arm-eabi/4.8/include/stdarg.h: No such file or directory" that's a bit weird
Mar 07 08:12:23 <Herrie|Laptop> Tofe: Hmmz I might have a clue there
Mar 07 08:12:28 <Herrie|Laptop> I was cleaning up WOP stuff
Mar 07 08:12:32 <Herrie|Laptop> I might have touched something there
Mar 07 08:12:35 <bshah> :P
Mar 07 08:12:36 <Herrie|Laptop> Let me see if that was the case
Mar 07 08:18:37 <Herrie|Laptop> Tofe: Seems that are paths I don't have access to
Mar 07 08:19:11 <Herrie|Laptop> Curious though, I would expect it to look in /home/jenkins/halium-luneos-5.1/ instead of /home/jenkins/halium-wop-5.1/
Mar 07 08:19:19 <Herrie|Laptop> It does do the correct thing for the 7.1 build
Mar 07 08:20:10 <Herrie|Laptop> Just mido fails for another reason (i.e. I need to update patch :P)
Mar 07 08:20:59 <Herrie|Laptop> novaldex|away: ^
Mar 07 08:21:02 <Herrie|Laptop> ka6sox: ^
Mar 07 08:21:59 <Tofe> Herrie|Laptop: could it be the previous build cached some absolute paths ?
Mar 07 08:24:13 <Herrie|Laptop> Tofe: Maybe
Mar 07 08:28:01 <Herrie|Laptop> Tofe: Well it seems to be due to /home/jenkins/halium-luneos-5.1/kernel/google/msm/scripts/Makefile.build:307: recipe for target 'backports/net/bluetooth/hci_event.o' failed
Mar 07 08:28:08 <Herrie|Laptop> Aren't these the WIP BT bits you did?
Mar 07 08:28:18 <Herrie|Laptop> Ah no
Mar 07 08:28:24 <Herrie|Laptop> msm=Mako
Mar 07 08:41:45 <Tofe> Well I bet the kernel doesn't include lots of headers from libc :)
Mar 07 08:46:19 <Herrie|Laptop> Tofe: There doesn't seem to be many changes to kernel repo after we last build: https://github.com/ubports/android_kernel_google_msm/commit/f0c8d957bd1caeef0e4bc5ac293cdc251e602510
Mar 07 08:47:40 <Tofe> Herrie|Laptop: I really looks like a build cache issue
Mar 07 08:47:44 <Tofe> it*
Mar 07 08:47:55 <Herrie|Laptop> So just nuke the whole folder :P ?
Mar 07 08:48:13 <Herrie|Laptop> Just I don't have access to that... Only ka6sox, novaldex|away and JaMa
Mar 07 08:48:21 <Herrie|Laptop> If you have local build files I could upload them
Mar 07 08:48:31 <Herrie|Laptop> Or I could do local build and upload
Mar 07 08:48:34 <Tofe> I've built N4 and N5 yes
Mar 07 08:48:59 <Tofe> but I won't have the ones for mido & other 7.1
Mar 07 08:49:24 <Tofe> I think I have TP as well
Mar 07 08:52:03 <Herrie|Laptop> Tofe: Well for 7.1 I just need to update the mido patch for now
Mar 07 08:52:06 <Herrie|Laptop> Let me do that in a bit
Mar 07 09:35:03 <Herrie|Laptop> Tofe: This should do the trick: https://github.com/webOS-ports/android_luneos_hal/pull/5
Mar 07 09:42:05 <Herrie|Laptop> Tofe: Triggered 7.1 on Jenkins
Mar 07 09:42:21 <Herrie|Laptop> Updated the 7.1 to latest from Halium so we're on 7.1.2r36 now as well :)
Mar 07 09:42:26 <Herrie|Laptop> From 7.1.1r25
Mar 07 10:02:10 <Herrie|Laptop> JaMa: Hi!
Mar 07 10:02:51 <Herrie|Laptop> We have some issues with "halium-luneos-5.1-build"
Mar 07 10:03:34 <Herrie|Laptop> It seems it's using some cached in path for build... I.e. fixdep: error opening config file: /home/jenkins/halium-wop-5.1/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/lib/gcc/arm-eabi/4.8/include/stdarg.h: No such file or directory
Mar 07 10:03:48 <Herrie|Laptop> We would expect it to look in halium-luneos-5.1 instead of halium-wop-5.1
Mar 07 10:09:00 <Tofe> Herrie|Laptop: don't we remove the "out/" directory before each build ?
Mar 07 10:11:18 <Herrie|Laptop> Tofe: You wrote the scripts :P
Mar 07 10:12:05 <Herrie|Laptop> Seems we do at the end
Mar 07 10:12:14 <Herrie|Laptop> So it might not do it in case it fails
Mar 07 10:12:53 <Herrie|Laptop> Ah no we do
Mar 07 10:12:59 <Herrie|Laptop> Just the way the script is written
Mar 07 10:13:12 <Herrie|Laptop> It does after repo sync
Mar 07 10:13:20 <Herrie|Laptop> And applying patches
Mar 07 10:13:25 <Herrie|Laptop> rm -rf ${RESULT_DIR}
Mar 07 10:13:31 <Herrie|Laptop> mkdir -p ${RESULT_DIR}
Mar 07 10:13:36 <Herrie|Laptop> rm -rf ${BUILD_DIR}/out
Mar 07 10:13:40 <Herrie|Laptop> And then builds the devices
Mar 07 10:20:06 <Tofe> in that case, I don't really see where that path comes from
Mar 07 10:27:51 <Herrie|Laptop> Me neither... But JaMa could nuke stuff on that server
Mar 07 10:28:17 <Herrie|Laptop> That's where I don't have access
Mar 07 10:40:41 <Herrie|Laptop> 7.1 still failing, seems it took old patch, testing locally now
Mar 07 10:42:24 <JaMa> what do you need to nuke? :)
Mar 07 10:42:59 <JaMa> you might be able to see workspace of that build through jenkins UI
Mar 07 10:43:36 <Herrie|Laptop> JaMa: Check above, I'm not sure what needs nuking, we just have a weird issue
Mar 07 10:43:46 <Herrie|Laptop> I don't see anything in the workspace
Mar 07 10:51:43 <Herrie|Laptop> Tofe: Ordered a nice new Intel Dual Band AC7260 Mini PCIe for my builder. That should help me reduce the repo-sync times locally :)
Mar 07 10:51:53 <Herrie|Laptop> Should arrive today, so have something to put together tonight
Mar 07 10:56:08 <Herrie|Laptop> Speed was maxing out at 35/20 Mbits and 13ms ping while main pc got 379/39 @ 10ms ;)
Mar 07 10:56:16 <Herrie|Laptop> So a new card might help quite a bit here :)
Mar 07 10:58:08 <Herrie|Laptop> For EUR 25 I thought it was worth to try :)
Mar 07 11:08:00 <Tofe> Herrie|Laptop: I don't have that kind of problem with DSL...
Mar 07 11:08:24 <Herrie|Laptop> Tofe: LOL ;)
Mar 07 11:08:27 <Herrie|Laptop> Happy with my cable ;)
Mar 07 11:08:41 <Herrie|Laptop> Though would prefer symetric fiber but well :)
Mar 07 11:08:48 <Herrie|Laptop> Can't have all
Mar 07 11:09:09 <Herrie|Laptop> Cable is way better compared to my DSL which would max out @ 8-10Mbit/s download ;)
Mar 07 11:19:23 <JaMa> I'm running: jenkins@bonaire:~/halium-luneos-5.1$ grep -R halium-wop-5.1 . 2>/dev/null
Mar 07 11:19:33 <JaMa> lets see where it leaks from
Mar 07 11:25:10 <JaMa> hmm lot of binary files in out sofar
Mar 07 11:33:41 <JaMa> I've removed "out" dir like the jenkins jobs is doing and trying again
Mar 07 11:36:34 <Herrie|Laptop> JaMa: Thnx
Mar 07 11:37:21 <JaMa> hmm nothing, no symlink with halium-wop-5.1 in it as well
Mar 07 11:37:49 <JaMa> does it store some config outside the WORKSPACE? like $HOME?
Mar 07 11:39:52 <JaMa> should I try to rename the directory and restart the build? (should it recreate everything it needs?)
Mar 07 11:40:27 <JaMa> jenkins@bonaire:~/halium-luneos-5.1$ grep -R "\bwop\b" . 2>/dev/null
Mar 07 11:40:32 <JaMa> shows bunch of binaries and
Mar 07 11:40:45 <JaMa> ./.repo/manifests/luneos_targets.xml:  <project path="system/core" name="webOS-ports/android_system_core" groups="pdk" revision="wop-12.1"/>
Mar 07 11:45:35 <Herrie|Laptop> JaMa: That android_system_core one should be fine
Mar 07 11:45:39 <Herrie|Laptop> revision = branch in git
Mar 07 11:45:51 <Herrie|Laptop> That's repo's equivalent in manifest.xml
Mar 07 11:46:22 <JaMa> http://jenkins.nas-admin.org/job/halium-luneos-5.1-build/10/console is now running from scratch
Mar 07 11:46:58 <JaMa> 2.7G    halium-luneos-5.1
Mar 07 11:46:58 <JaMa> 24G     halium-luneos-5.1.old
Mar 07 12:41:57 <Herrie|Laptop> Tofe: 7.1 failing was me forgetting to update 2 repos
Mar 07 12:42:06 <Herrie|Laptop> Seems those don't have the 7.1.2r36 tag
Mar 07 12:42:39 <Herrie|Laptop> So updated the branch now with https://github.com/Halium/android/commit/256eddc0f13bb8c7cd1d60b737fe4461936004c8
Mar 07 12:49:09 <Herrie|Laptop> Tofe: In order to reduce the repo sync size we might want to change the repo init to "repo init --depth=1 -u https://github.com/webos-ports/android.git -b luneos-halium-7.1" and the repo sync to "repo sync -j 16 --force-sync -d -c"
Mar 07 12:49:48 <Tofe> Herrie|Laptop: as you wish, I never looked into these details
Mar 07 12:50:13 <Herrie|Laptop> Let me do a local sync and see how big it gets
Mar 07 12:51:31 <Herrie|Laptop> It basically should only take the current branch instead of all branches in the sync from what I understood
Mar 07 12:51:44 <Herrie|Laptop> So that should save significantly in the AOSP and CM/LOS repos
Mar 07 12:52:00 <Herrie|Laptop> I read guys going back frm 18GB to 2GB for a single target device
Mar 07 12:56:44 <Tofe> ok :)
Mar 07 13:00:35 <Herrie|Laptop> At least that's the theory, so welcome for people on slower connections :)
Mar 07 13:12:36 <Herrie|Laptop> It still syncs 12,3GB here locally for our 5.1 targets but well
Mar 07 13:14:13 <Herrie|Laptop> Let me do a sync without the --depth=1 to see how it compares
Mar 07 14:19:11 <Herrie|Laptop> Hmmz the Jenkins job failed, seems due to fetch error somehow
Mar 07 14:19:15 <Herrie|Laptop> COuld be temporary glitch
Mar 07 14:19:34 <JaMa> should I re-trigger? 14G     halium-luneos-5.1
Mar 07 14:19:36 <Herrie|Laptop> I'll kick it of again to confirm
Mar 07 14:19:44 <Herrie|Laptop> JaMa: Done already ;)
Mar 07 14:19:52 <Herrie|Laptop> Normally repo sync continues where it left off
Mar 07 14:19:56 <Herrie|Laptop> And only syncs the new bits
Mar 07 14:20:18 <Herrie|Laptop> Still don't like it, because it's highly inefficient but well
Mar 07 14:22:03 <Herrie|Laptop> JaMa: Testing locally if the --depth=1 in repo-init makes difference. I think it does at least in terms of time
Mar 07 14:22:10 <Herrie|Laptop> Not sure about size, I'm checking that now
Mar 07 14:23:16 <JaMa> ok
Mar 07 14:33:38 <Herrie|Laptop> Seems to cut it in half almost :)
Mar 07 14:33:43 <Herrie|Laptop> So worth to add, let me do that
Mar 07 14:47:12 <JaMa> ready to nuke it again :)
Mar 07 14:47:41 <Herrie|Laptop> JaMa: well it seems to build now
Mar 07 14:47:44 <Herrie|Laptop> So let it output stuff
Mar 07 14:47:47 <Herrie|Laptop> And then nuke
Mar 07 14:48:12 <Herrie|Laptop> Seems it's almost done already
Mar 07 14:58:17 <Tofe> Herrie|Laptop: during the integration of Halium's init, we'll have quite big tgz; it'll be back at normal size afterwards
Mar 07 14:59:55 <Herrie|Laptop> Tofe: Well it's more the repo sync with --depth=1 that gets a lot smaller
Mar 07 15:00:10 <Herrie|Laptop> And quicker
Mar 07 15:00:18 <Herrie|Laptop> Since it doesn't get all the tags :) Just the ones we need
Mar 07 15:20:05 <Tofe> JaMa: still there?
Mar 07 15:22:10 <Tofe> JaMa: I am thinking about reducing the size of our initramfs, and to do that I'd like to have more static versions of the few binaries we use in our initrd (lvm,systemd-udev,adb,e2fsck). Is there some elegant way to do this with Yocto, or should I simply write the corresponding bbappend and create new packages with the re-linked binaries?
Mar 07 15:33:01 <JaMa> Tofe: here, but not really, need to finish something first before my head blows up
Mar 07 15:38:51 <Tofe> JaMa: sure, don't let your head explode, it seems a bit painful :)
Mar 07 15:56:13 <Herrie|Laptop> Grrr: fixdep: error opening config file: /home/jenkins/halium-wop-5.1/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/lib/gcc/arm-eabi/4.8/include/stdarg.h: No such file or directory
Mar 07 16:30:32 <Herrie|Laptop> Let me run it locally just to make sure :P
Mar 07 19:40:14 <Herrie|2> `locally it's fine
Mar 07 19:40:27 <Tofe> hehe of course :)
Mar 07 19:42:07 <Herrie|2> Well you never know
Mar 07 19:42:11 <Herrie|2> This one is really weird
Mar 07 19:42:35 <Tofe> yes, I don't see what's going on either
Mar 07 19:43:08 <Tofe> ok I've got a TP image to test... let's just hope for the best, I tweaked the init quite a lot
Mar 07 19:43:54 <Herrie|2> OK :D
Mar 07 19:44:54 <Tofe> if something goes wrong, I don't even know how to retrieve the log :p
Mar 07 19:45:05 <Herrie> Tofe: Boot webOS and pull it frm there?
Mar 07 19:45:18 <Herrie> klog or something
Mar 07 19:45:20 <Tofe> It seems there isn't any last_kmsg
Mar 07 19:45:25 <Herrie> nivozn: ^
Mar 07 19:45:41 <Tofe> could be it's just something to activate in defconfig
Mar 07 19:48:32 <Tofe> ah but no wait, I can't modify webOS's kernel :p
Mar 07 19:49:19 <Herrie> I recall klog
Mar 07 19:49:20 <nizovn> yes, klog
Mar 07 19:50:01 <Tofe> ok, well, let's see how it boots first, maybe I will be extra-lucky
Mar 07 19:58:33 <Tofe> I think it's stuck... let's reboot to webOS and see what I can retrieve...
Mar 07 20:05:11 <Tofe> nizovn: klog is supposed to last between reboot?
Mar 07 20:05:58 <nizovn> yes i think
Mar 07 20:06:08 <nizovn> but it can fail sometimes
Mar 07 20:06:15 <Tofe> ok I'll retry
Mar 07 20:07:14 <nizovn> there is also another way (faster) - see logs in bootie
Mar 07 20:08:17 <nizovn> if you are interested: http://www.webos-internals.org/wiki/Bootie
Mar 07 20:08:23 <Tofe> I'm interested :)
Mar 07 20:11:16 <Tofe> ok I'm in there, let's see what I can do
Mar 07 21:44:19 <Herrie> Tofe: That was a quick swap of the WLAN card ;)
Mar 07 21:44:33 <Herrie> Ping down a few ms, download 150-180 Mbit and download 30-35 :)
Mar 07 21:44:42 <Herrie> Will try tomorrow on non-peak hours
Mar 07 21:44:47 <Herrie> But for sure a lot quicker already
Mar 07 21:50:15 <Herrie> upload 30-35 I mean
**** ENDING LOGGING AT Thu Mar 08 03:00:02 2018