**** BEGIN LOGGING AT Mon Apr 25 02:59:58 2016 Apr 25 04:02:11 ka6sox: Hmmz will ask JaMa when he's around Apr 25 04:02:15 He might know better Apr 25 04:07:40 okay Apr 25 04:09:32 I have no clue about OE and SSTATE etc ;) So don't want to mess up things Apr 25 04:09:36 Andolamin: You around? Apr 25 04:25:20 Herrie, makes sense Apr 25 07:13:06 morning Apr 25 07:18:57 Morning Apr 25 07:31:34 Tofe: Seems Mer guys aren't too keen on having LuneOS checks in the Fingerterm code. They suggested to add some extra QMake params. Which I'm happy to do, however a little stuck. Maybe you know a thing or 2? It seems I cannot pass the QT and PKGCONFIG in Apr 25 07:31:34 EXTRA_QMAKEVARS_PRE? Apr 25 07:42:31 Herrie|Pre3: yes, something like that Apr 25 07:44:26 Tofe: When I pass PKGCONFIG-=nemonotifications-qtf and QT-=feedback I get the msg during build that these aren't available Apr 25 07:44:36 s/qtf/qt5 Apr 25 07:44:59 So it seems to ignore them when they're in EXTRA_QMAKEVARS_PRE Apr 25 07:45:05 Other bits like font work fine Apr 25 07:46:22 wait a bit, let me see again the MR Apr 25 07:47:47 Herrie|Pre3: I think that what they mean is to remove the contains(DISTRO_VERSION,luneos) block Apr 25 07:48:01 Tofe: MR isn't updated for this yet. But basically they requested to drop the contains (MEEGO_EDITION,harmattan) and contains(DISTRO_VERSION,luneos) and pass it as qmake params instead Apr 25 07:49:28 I got it working except for the QT-=feedback and the PKGCONFIG-=nemonotifications-qt5 Apr 25 07:49:49 I could of course remove them from the .pro and pass them as qmake params in their .spec :P Apr 25 07:50:09 Sl t Apr 25 07:50:22 So we wouldn't have to remove them in our recipe :P Apr 25 07:52:41 Herrie|Pre3: I guess the good way would be something like this, yes: don't include feedback and nemonotifications by default, as it is platform specific, and have it depend on a define Apr 25 07:53:32 Tofe: OK. I'm not too familiar with their .spec format but seems it simple has a qmake line in there so can just add them there I guess. Apr 25 07:54:41 I don't know anything about .spec Apr 25 08:01:36 Tofe: I'll just PR as I see fit. They said they would test it at their end :) Apr 25 08:04:41 Will clean & wrap it up tonight after I test a bit more. Apr 25 08:04:55 Tofe: Did you see my comments re kernel yesterday? Apr 25 08:17:48 JaMa: morning Apr 25 08:19:53 Herrie|Pre3: yes yes, I saw your comments Apr 25 08:28:22 Tofe: Though it seems most other kernels are CM11 compatible and not CM10.1 it seems :s Apr 25 08:28:35 morning all Apr 25 08:28:41 So we get a bit of chicked & egg problem it seems :P Apr 25 08:28:44 JaMa: morning Apr 25 08:29:39 Got 2 things... 1. bonaire seems to be out of space. workspace_cleanup doesn't seem to help much. Any ideas? Apr 25 08:30:14 2. Do you have any concerns about using meta-nodejs layer? We could probably get node-sqlite3 and keymanager to work with that. Apr 25 08:45:57 Herrie|Pre3: checking both Apr 25 08:59:15 I've deleted sstate-cache for stable and testing builds, so next builds will take a bit longer Apr 25 08:59:30 they should fetch needed parts from file server Apr 25 09:00:19 JaMa: OK, how much space we have free now? Apr 25 09:00:35 We had 5GB y'day after workspace-cleanup Apr 25 09:00:41 24G luneos-stable/webos-ports/sstate-cache Apr 25 09:00:41 90G luneos-testing/webos-ports/sstate-cache Apr 25 09:00:55 OK :U thnx Apr 25 09:01:02 15G cm-wop-10.1 Apr 25 09:01:02 27G cm-wop-11.0 Apr 25 09:01:07 can we drop 10.1? Apr 25 09:01:19 Nope still used for Mako Apr 25 09:01:25 ok Apr 25 09:01:38 Though the systemd issue we're facing might be somehow kernel related. Apr 25 09:01:39 it's possible that around 100G will be used by sstate again later Apr 25 09:01:51 so the reserve is thin Apr 25 09:02:33 We'll eventually want to move to CM11 for Mako, but we'd still have Maguro on CM10.1 I guess. Apr 25 09:06:44 2. this meta-nodejs? https://github.com/imyller/meta-nodejs Apr 25 09:08:48 I don't have anything against it (except that I haven't tested this before), so you think that latest node-sqlite3 will be compatible with nodejs 5*? Apr 25 09:09:09 JaMa: Yes it seems to support multiple nodejs versions. I was able to build node-sqlite3 with it and therefore also keymanager, however I had some issues with some of our other recipes. Not sure how to specify which nodejs version to use Apr 25 09:09:59 Like node-gyp-native, which is critical. Pinged Andolamin but he wasn't around. Apr 25 09:10:02 PREFERRED_VERSION_nodejs = "5%" Apr 25 09:10:53 JaMa: Ah I can just add that to the node-gyp recipes to force another version? Apr 25 09:10:59 no Apr 25 09:11:06 to DISTRO configuration Apr 25 09:11:30 you can build just one nodejs version for everything Apr 25 09:11:44 we used to have separate nodejs4 recipe in meta-oe Apr 25 09:12:20 JaMa: OK. I'll have a look tonight and play around a bit to see if I can get everything working. Seems node-sqlite3 is fine with nodejs5 Apr 25 09:12:44 ok, thanks Apr 25 09:12:45 Just node-gyp was complaining about repository or something Apr 25 09:13:15 the node-gyp recipes we have have couple of issues Apr 25 09:13:29 npm doesn't respect bitbake fetcher and premirror Apr 25 09:13:35 so they cannot be built without network Apr 25 09:14:00 so as workaround you need to generate whole npm repo in SRC_URI Apr 25 09:14:41 which locks all versions, so probably to became compatible with nodejs5 you would need to refresh this static "cache" list in SRC_URI Apr 25 09:15:22 ./meta-luneos/recipes-upstreamable/nodejs/node-gyp-packages-native.inc Apr 25 09:17:39 commit 77aecd631daf41a0f5a562ddcacfcd5d61ca45e2 Apr 25 09:17:40 Author: Andrii Motsok Apr 25 09:17:40 Date: Sun Apr 20 10:53:37 2014 +0300 Apr 25 09:17:40 native: Add node-gyp-{packages,registry}-native=v0.10.4 Apr 25 09:17:54 unfortunately it doesn't include the script to refresh the repository Apr 25 09:25:40 JaMa: Thnx for the info. Apr 25 09:25:46 I'll have a look Apr 25 09:35:04 JaMa: Can you check Tofe's bpaste? https://bpaste.net/show/1e68d4ccaa4f Apr 25 09:35:28 This is for systemd on Mako. Does it ring a bell somehow? Apr 25 11:31:51 Doesn't ring a bell, but quick google shows https://github.com/systemd/systemd/commit/1411b09467c90ae358656d14165311090a2e175e maybe worth checking with this commit reverted Apr 25 11:33:45 My latest hints point to fd_is_mount_point, and the various fstat tests Apr 25 12:14:31 HaDAk: I updated our WOP-11.0 branch for Android a bit to drop that 1 cyngn repo. I didn't test it yet however. Apr 25 12:14:50 nice. Apr 25 12:14:54 i can try Apr 25 12:15:26 Could be there are more that need updating but this was the most obvious one it seems Apr 25 12:15:48 I saw one of our sister projects dropped it as well :P Apr 25 12:19:34 it's syncing now Apr 25 12:26:40 fatal: unable to access 'https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.7/': Could not resolve host: android.googlesource.com Apr 25 12:27:02 there are a few others that are failing too Apr 25 12:27:17 once it's all done, i'll export the logs. hopefully my buffer goes back that far Apr 25 12:28:50 oh, yeah. there are a few 404'ing Apr 25 12:30:12 It could be. The sister project I checked had a lot different repo's in the xml. I'm not sure which ones we'll really need. Would be good to get that cleaned up sometime :s Apr 25 12:30:32 what sister project? Apr 25 12:31:09 also, for security reasons, we should be trying to keep up to date with the latest android source Apr 25 12:31:36 http://github.com/mer-hybris/android. Their hybris-11.0 branch Apr 25 12:32:12 oh, cyanogen? Apr 25 12:32:47 man. so many things failing. Apr 25 12:32:49 :\ Apr 25 12:33:06 I think their hybris 11.0 branch is a fork of cyanogen11 just like our wop 11.0 Apr 25 12:34:00 That's why I say ours probably needs some cleaning up Apr 25 12:52:39 i think it downloaded all it's going to Apr 25 13:08:58 Herrie|Pre3: just for future reference, will i need to pull radio firmware or anything from my nexus 5 to get LTE working? Apr 25 13:09:08 do we even support LTE? Apr 25 13:10:18 HaDAk: We don't flash this. We take these firmwares from the Android version on the device basically. So when you have Android 4.4.x on your device it will use the radios from there. Apr 25 13:10:27 ok. Apr 25 13:10:34 LTE should be OK in general. oFono takes care of all that. Apr 25 13:10:52 but if i wanted to switch APNs, i'd be shit out of luck? Apr 25 13:11:11 or if i wanted to prevent roaming data or something? Apr 25 13:11:15 not that i would, but just curious Apr 25 13:11:53 HaDAk: You can disable roaming in Settings normally (it's a bit buggy, elvispre is looking into that). Apr 25 13:12:03 cool. Apr 25 13:12:04 The toggle seems to behave a bit weird. Apr 25 13:12:21 You can always simply send a command to connman or oFono to force it. Apr 25 13:12:27 Same with APN :P Apr 25 13:12:39 neat Apr 25 13:12:42 We're still polishing some of this stuff. Apr 25 13:13:04 well, i'm legitimately excited to get it going on this phone. Apr 25 13:13:18 although, something tells me i'll be disappointed with the lack of google voice support ;) Apr 25 13:13:24 all my calls go through GV Apr 25 13:13:38 we talked once about integrating support, but i would be shocked if that ever happened Apr 25 13:13:59 We're pretty much on latest & greatest from upstream with connection components. The Ubuntu & Jolla guys have quite some userbase and are actively fixing stuff so we don't have to :P Apr 25 13:14:22 hey, the repo might have actually synced Apr 25 13:14:29 let me see about building for the N5 then... Apr 25 13:15:08 ...where's the default.xml file in this mess? Apr 25 13:17:54 found it. Apr 25 13:19:32 Feel free to add stuff to the guide to clarify Apr 25 13:19:41 morphis wrote it quickly sometime :P Apr 25 13:19:56 Can need some clarity for n00bs like us :P Apr 25 13:21:11 right Apr 25 13:21:14 ok, so Apr 25 13:21:17 the brunch command Apr 25 13:21:26 cm_-userdebug Apr 25 13:21:35 what should be? Apr 25 13:21:48 i want to build hammerhead. i added it to defaults.xml. it doesn't like hammerhead. Apr 25 13:21:58 ls: cannot access device/*/hammerhead/cm.mk: No such file or directory Apr 25 13:22:19 machine should be hammerhead imho Apr 25 13:22:25 agreed Apr 25 13:22:45 ** Do you have the right repo manifest? Apr 25 13:22:50 ** Don't have a product spec for: 'cm_hammerhead' Apr 25 13:23:47 ahh, found something Apr 25 13:24:23 You probably need to point it to cyanogenmod/android_device_lge_hammerhead Apr 25 13:24:33 i did Apr 25 13:25:47 ok, there's no hammerhead directory in devices Apr 25 13:25:52 that's the real problem Apr 25 13:26:50 https://github.com/CyanogenMod/android_device_lge_hammerhead Apr 25 13:26:55 https://github.com/CyanogenMod/android_kernel_lge_hammerhead Apr 25 13:27:00 do those need to be added somewhere? Apr 25 13:27:57 Yeah to default.xml Apr 25 13:28:08 Search for tuna and add similar for hammerhead Apr 25 13:28:20 I guess you'd need to sync those 2 then too :s Apr 25 13:28:32 Apr 25 13:28:36 Apr 25 13:28:38 that's what i put in Apr 25 13:28:48 yeah, i probably do...how do i do that properly? Apr 25 13:29:37 You might want to add revision="cm-11.0" at the end of both for the correct branch Apr 25 13:30:48 ok, done. Apr 25 13:30:53 now, how do i get those files? Apr 25 13:32:21 Do the repo sync again I think :s Apr 25 13:32:27 Just the sync Apr 25 13:32:32 ok Apr 25 13:32:55 Because you already have the xml, so you don't need the init imho Apr 25 13:33:04 yeah, that didn't grab the files Apr 25 13:35:30 oh, maybe the revision is wrong Apr 25 13:41:27 HaDAk: Sent you DM on Twitter, not really suitable for us, but might give some pointers. Seems pretty detailed. Apr 25 13:41:35 yeah, i am looking at it now Apr 25 13:41:41 it specifically uses hammerhead as an example Apr 25 13:42:20 i'll be goddamned if i didn't find another default.xml Apr 25 13:42:28 and this one DOESN'T have hammerhead in it Apr 25 13:42:38 LOL :P Apr 25 13:42:43 Surprise surprise Apr 25 13:42:52 Our guide needs some updating I'm sure Apr 25 13:43:05 I hope to have some time shortly to look into it myself. Apr 25 13:44:13 ok, THAT works Apr 25 13:44:28 the *correct* default.xml file appears to be in .repo/manifest Apr 25 13:45:13 i don't even know if i have write access to this wiki. Apr 25 13:45:29 If not I can give it to you :P Apr 25 13:46:56 apparently i do Apr 25 13:47:35 so far so good Apr 25 13:48:51 looks like it's building shit now Apr 25 13:49:01 i assume this will take a while Apr 25 13:49:01 Since you're doing this CM11 build based you'll need to have Android 4.4.x on your device. Apr 25 13:49:06 Yeah probably Apr 25 13:49:10 uhh Apr 25 13:49:14 this phone has android 6. Apr 25 13:49:22 is it possible to use CM-13? Apr 25 13:49:26 Maybe :P Apr 25 13:49:33 Not sure Apr 25 13:49:43 so, two questions: Apr 25 13:49:52 You could ask the guys in #sailfishos-porters which might have tried. Apr 25 13:49:55 1) what would it fuck up to start with android 6 on this phone? Apr 25 13:50:08 2) what would it fuck up to try using CM13 instead of CM11? Apr 25 13:50:12 They did quite some work on Hammerhead for Jolla port :P Apr 25 13:50:48 HaDAk: it's mainly firmware, so things like radio & wifi might not work. But could fail to boot altogether Apr 25 13:50:55 actually Apr 25 13:51:01 it looks like CM13 is android M Apr 25 13:51:08 Since gap between 4.4 and 6 is pretty big :P Apr 25 13:51:09 so i'd be more interested in CM12 Apr 25 13:51:27 CM 12.1 likely to work Apr 25 13:52:16 actually, let me verify all this information Apr 25 13:52:47 Marshmellow = Android 6.0 Apr 25 13:52:51 5.0 = Lollipop Apr 25 13:53:02 A6.0 = CM13 Apr 25 13:53:23 aha, ok Apr 25 13:53:25 and i just checked Apr 25 13:53:28 this phone is on 6.0.1 Apr 25 13:53:33 A5.0=CM12.1 Apr 25 13:53:33 so, it WOULD be cm13 Apr 25 13:53:51 Well A5.1.x=CM12 Apr 25 13:54:53 i'm grabbing CM11 for this phone Apr 25 13:54:55 i can just flash it Apr 25 13:55:15 HaDAk: You can just take the Google ons Apr 25 13:55:23 That's what we use usually Apr 25 13:55:27 And run the flashall Apr 25 13:55:46 Seems the SailfishOS guys only did CM11 for the Hammerhead Apr 25 13:56:12 A quick check in the sailfishos-porters channel won't hurt Apr 25 13:56:27 Could be they tried CM12/13 but met issues Apr 25 13:56:43 i can still do that later. for now, i'll flash factory 4.4 Apr 25 13:56:50 is 4.4.4 the correct one? Apr 25 13:57:18 Any 4.4 should do, but yeah 4.4.4 I would go for. Apr 25 14:02:10 do i need to run through initial setup in android? Apr 25 14:03:30 Nope shouldn't be needed Apr 25 14:03:38 ok. it's flashing now. Apr 25 14:06:08 guh. how long does this compile take? :( Apr 25 14:08:45 HaDAk: Not sure you're doing on native *nix or VBox? Apr 25 14:08:54 Depends on your system too I guess Apr 25 14:09:13 Tofe: You have any ideas how long kernel build takes? Apr 25 14:09:24 i'm doing it in vmware Apr 25 14:09:45 but i've got Vx-T enabled, so that should help Apr 25 14:10:31 i'm tempted to repurpose a box at work to do this magic Apr 25 14:10:41 we have some insanely fast boxes that just sit idle Apr 25 14:11:20 Herrie|Pre3: for me it's a matter of minutes Apr 25 14:11:57 Tofe: OK :) Apr 25 14:12:12 HaDAk: Is trying a N5 port :D Apr 25 14:12:27 i'm guessing you've got a lot of shit already compiled, Tofe Apr 25 14:12:35 so it doesn't have to do everything from scratch every time Apr 25 14:13:30 external/sonivox/arm-wt-22k/lib_src/eas_wtengine.c:454: error: undefined reference to 'android_errorWriteLog' Apr 25 14:13:37 build/core/shared_library.mk:81: recipe for target '/home/hans/webos/out/target/product/hammerhead/obj/SHARED_LIBRARIES/libsonivox_intermediates/LINKED/libsonivox.so' failed Apr 25 14:13:45 make: *** [/home/hans/webos/out/target/product/hammerhead/obj/SHARED_LIBRARIES/libsonivox_intermediates/LINKED/libsonivox.so] Error 1 Apr 25 14:14:07 Ah well that seems like there's an issue with sonivox Apr 25 14:14:14 I recall reading something about that Apr 25 14:14:19 Let me check Apr 25 14:19:51 OK seems there's been some changes in that Apr 25 14:20:20 quick and easy fix? Apr 25 14:20:32 Original CyanogenMod sonivox was taken down. We switched to AOSP in default.xml however seems CyanogenMod one is back Apr 25 14:20:42 Just update the .xml again Apr 25 14:20:48 I'll DM you the values from PC Apr 25 14:20:51 ok Apr 25 14:22:06 hum. doesn't seem to be any different. Apr 25 14:22:35 The path is. Apr 25 14:22:38 Project path Apr 25 14:23:08 Ah no just different order :s Apr 25 14:23:39 You could try adding revision="cm-11.0" Apr 25 14:24:01 i edited the file. what was the original line? >_< Apr 25 14:24:40 thanks Apr 25 14:25:19 I have these on desktop pc, hence C&P to Twitter is faster :P Apr 25 14:25:56 it's no worry Apr 25 14:26:25 fatal: unable to access 'https://github.com/CyanogenMod/android_external_tremolo/': transfer closed with outstanding read data remaining Apr 25 14:26:31 fatal: unable to access 'https://github.com/CyanogenMod/android_external_libgsm/': transfer closed with outstanding read data remaining Apr 25 14:26:35 ^X@sc^X@scfatal: unable to access 'https://github.com/CyanogenMod/android_external_libtar/': transfer closed with outstanding read data remaining Apr 25 14:26:45 ^X@scfatal: unable to access 'https://github.com/CyanogenMod/android_hardware_qcom_sensors/': transfer closed with outstanding read data remaining Apr 25 14:27:12 fatal: unable to access 'https://github.com/CyanogenMod/android_external_tremolo/': transfer closed with outstanding read data remaining Apr 25 14:27:15 so, it hates those. Apr 25 14:28:12 Strange they do seem to exist Apr 25 14:29:16 it could just be the branch or something Apr 25 14:29:29 cm11 branches are there Apr 25 14:30:32 Andolamin: last rpi build fails in luneos-dev-image.bb, do_rootfs http://jenkins.nas-admin.org/view/luneos-testing/job/luneos-testing_raspberrypi2/lastBuild/console Apr 25 14:30:50 i'm trying a thing. Apr 25 14:31:11 no, that didn't work. hum. Apr 25 14:31:58 JaMa: Already pinged Andolamin about it, he's looking into it. Apr 25 14:31:59 yeah, it's hanging up on these Apr 25 14:32:06 ah ok Apr 25 14:36:20 weird. tremolo already appears to be synced... Apr 25 14:41:27 Could be somehow it synced half? Apr 25 14:41:33 maybe Apr 25 14:41:38 I.e. failed somewhere during sync Apr 25 14:41:58 it wasn't failing earlier though Apr 25 14:42:08 i just did a make clean and make target-files-package Apr 25 14:42:17 i'm going to see what it hangs up on next Apr 25 14:42:25 maybe i get past this libsonivox issue Apr 25 14:42:33 i doubt it, but who knows. Apr 25 14:42:52 if repo sync never completed because of these errors, sonivox wouldn't have pulled down the new files Apr 25 14:44:54 puked at the same place. Apr 25 14:45:02 how annoying Apr 25 14:49:57 i'm just taking OUT all the things that repo sync is bitching about now. Apr 25 14:50:15 pulling down all the new files, as necessary, and trying again Apr 25 14:50:28 Rinse, repeat :P Apr 25 14:50:58 ok, no errors syncing Apr 25 14:51:01 old files removed Apr 25 14:51:22 added in the broken stuff Apr 25 14:51:26 and it's still complaining Apr 25 14:58:52 Let me try something quickly for you Apr 25 15:02:32 ah HAH Apr 25 15:02:34 it's not *me* Apr 25 15:02:35 it's them Apr 25 15:02:43 $ git clone https://github.com/CyanogenMod/android_external_expat.git Apr 25 15:02:43 Cloning into 'android_external_expat'... Apr 25 15:02:43 fatal: unable to access 'https://github.com/CyanogenMod/android_external_expat.git/': transfer closed with outstanding read data remaining Apr 25 15:03:32 https://codeload.github.com/CyanogenMod/android_external_expat/zip/cm-11.0 Apr 25 15:03:36 i get a 502 on that Apr 25 15:04:31 GH sometimes is flaky Apr 25 15:05:23 no, these repos legitimately won't let me clone them. Apr 25 15:08:56 adding this one to the list Apr 25 15:08:56 https://github.com/CyanogenMod/android_external_expat.git Apr 25 15:23:05 HaDAk: I'm not convinced we still need all of the custom repo's in WebOS Ports github. I think we might be able to use some from mer-hybris instead. Apr 25 15:23:33 ok Apr 25 15:24:08 morphis: ping Apr 25 15:25:24 _morphis: ping that should be. Apr 25 15:49:43 Herrie|Pre3: i'm upgrading my ubuntu install to the latest release. after it's done, i'll revisit the manifest issue. Apr 25 15:49:53 Herrie: if you've got the relevant links, i'm all ears Apr 25 15:54:01 HaDAk: I'm not really sure why we have forks for some stuff Apr 25 15:54:31 Seems to only disable CLANG in some cases. Just not sure why. Maybe it doesn't work properly with our build system somehow. Apr 25 15:54:50 english? Apr 25 15:57:06 For some repo's the only difference between our fork and upstream is that we disable Clang (compiler). Apr 25 16:00:57 ah. Apr 25 16:01:17 i thought clang was one of the teenage mutant ninja turtles' enemies Apr 25 16:06:04 ok, my machine is updated. repo sync throws the same shit (not surprised) Apr 25 16:06:11 so, i'm going to take lunch Apr 25 16:06:18 when i get back, we'll talk about upstream Apr 25 16:57:00 HaDAk: Home now, dinner soon Apr 25 17:11:37 Herrie, I think that 13GB isn't going to last long... Apr 25 17:16:56 Herrie: i'm back now too Apr 25 17:21:08 ka6sox: I guess the extra target (RaspberryPi2) is eating up more space? Apr 25 17:22:03 not 225Gigabytes worth... Apr 25 17:22:28 hey ka6sox, how familiar are you with the build process in whole? Apr 25 17:23:48 ka6sox: JaMa deleted the sstate-cache but this will be refetched/build Apr 25 17:25:19 okay Apr 25 17:27:43 Not sure what's taking up so much space tbh Apr 25 17:28:04 Could be qtwebengine eating a lot more space * 3 or 4 different archs Apr 25 17:29:06 okay..lets see after the rebuild Apr 25 17:30:43 Herrie: huh. syncing again after lunch worked without any issues. i'm trying to build again, too Apr 25 17:35:25 HaDAk: GitHub has occasional glitches Apr 25 17:35:34 github is dumb Apr 25 17:35:51 i think it's still too early to tell if this build will fail or not Apr 25 17:40:23 ok, there we go Apr 25 17:40:33 it failed on sonivox same as before. Apr 25 17:40:51 so, Herrie, your solution is to try the upstream provider? Apr 25 17:51:49 :S Apr 25 17:52:00 HaDAk: Well there's no difference between them it seems :S Apr 25 17:52:42 here are the errors i'm getting Apr 25 17:52:43 target SharedLib: libsonivox (/home/hans/webos/out/target/product/hammerhead/obj/SHARED_LIBRARIES/libsonivox_intermediates/LINKED/libsonivox.so) Apr 25 17:52:44 external/sonivox/arm-wt-22k/lib_src/eas_wtengine.c:454: error: undefined reference to 'android_errorWriteLog' Apr 25 17:52:44 external/sonivox/arm-wt-22k/lib_src/eas_wtsynth.c:475: error: undefined reference to 'android_errorWriteLog' Apr 25 17:52:45 collect2: error: ld returned 1 exit status Apr 25 17:52:45 build/core/shared_library.mk:81: recipe for target '/home/hans/webos/out/target/product/hammerhead/obj/SHARED_LIBRARIES/libsonivox_intermediates/LINKED/libsonivox.so' failed Apr 25 17:52:46 make: *** [/home/hans/webos/out/target/product/hammerhead/obj/SHARED_LIBRARIES/libsonivox_intermediates/LINKED/libsonivox.so] Error 1 Apr 25 17:52:59 error: undefined reference to 'android_errorWriteLog' Apr 25 17:53:03 clearly that's the interesting bit Apr 25 17:56:05 Not sure how this ever worked... Apr 25 17:56:16 http://review.cyanogenmod.org/#/c/126595/1/include/log/log.h Apr 25 17:56:39 We don't seem to have the #define android_errorWriteLog in our version Apr 25 17:56:45 uh Apr 25 17:56:47 ok. Apr 25 17:56:54 we need a new version? or what? Apr 25 17:57:08 do i manually add those lines in? Apr 25 17:57:23 I guess you could manually add them for now Apr 25 17:57:31 But there are probably going to be others :S Apr 25 17:58:12 fuu Apr 25 18:05:28 HaDAk: Seems we miss a few lines only: https://github.com/CyanogenMod/android_system_core/commit/b0cb2ce83615277e84f6bf729b869dc3252fd134 Apr 25 18:06:18 Herrie: ok, i'll try to manually mudge them back in Apr 25 18:06:58 granted, i don't know where this file IS Apr 25 18:08:00 HaDAk: It should be in your build dir somewhere Apr 25 18:08:11 i found it. Apr 25 18:08:49 If that works, I'll just cherry pick this upstream commit Apr 25 18:14:52 Or maybe merge all from upstream Apr 25 18:14:58 Changes don't seem too shocking Apr 25 18:24:17 Herrie: it's not working. Apr 25 18:24:20 one sec, brb Apr 25 18:25:23 or not. boss is nowhere to be found. Apr 25 18:25:24 anyway Apr 25 18:30:39 interesting. there are a TON of log.h files. maybe it's platform specific? or has to be edited in multiple places? Apr 25 18:31:17 maybe system/core/include/log? Apr 25 18:33:55 Herrie: i'd like you to look into this with me further, when you get a minute. there are too many liblog files. Apr 25 18:35:03 Yeah Apr 25 18:35:22 Yeah /system/core/include/log/log.h seems right Apr 25 18:35:31 that's what i edited. Apr 25 18:36:10 OK Apr 25 18:38:00 Herrie: you got teamviewer? Apr 25 18:38:06 No but could install I guess Apr 25 18:38:20 if you wanna share my session, i'll add you to it Apr 25 18:38:24 you can poke at this with me Apr 25 18:39:22 Installing Apr 25 18:39:26 k Apr 25 18:39:34 i'll need your partner id Apr 25 18:39:51 or email Apr 25 19:47:45 Tofe, _morphis: ping Apr 25 19:52:57 Tofe, _morphis: http://pastebin.com/F367SM2H Apr 25 20:44:36 well, i have some ideas. i still need to talk to either Tofe or _morphis though. Apr 25 20:44:46 so, when one (or both) of you are available, ping me Apr 25 20:45:28 Herrie: yes rpi is taking around 1/5 of disk space for itself Apr 25 20:45:42 Herrie: because it's different TUNE_PKGARCH than any other MACHINEs Apr 25 20:46:00 /dev/xvdb1 246G 128G 106G 55% /home Apr 25 20:50:21 JaMa, Herrie: The rpi build failures are because of those Image files that were deleted. They're not being recreated automatically. Some component likely needs a cleanall to force rebuild, but not sure which one. Haven't had a chance to try tracking it down. Apr 25 20:51:34 I've run into the same issue on my local builds before, but just nuked tmp-glibc instead of tracking it down because I'm lazy Apr 25 20:53:09