**** BEGIN LOGGING AT Tue Mar 13 03:00:03 2018 Mar 13 08:13:26 Morning! Mar 13 08:24:01 Morning! Mar 13 10:08:05 Tofe: No cigar on the oFono part still Mar 13 10:08:52 for ofono, you would have to fix pm-service and rmt_storage first btw Mar 13 10:09:48 bshah: I don't seem to have issues with pm-service on my new build with LineageOS device repo instead of Piggz Mer one Mar 13 10:09:56 ah Mar 13 10:09:57 bshah: Sent some PR's yesterday :P Mar 13 10:10:07 At least no log flooding anymore Mar 13 10:10:44 yeah I am aware of your PRs, just bit occupied with $work to look at it Mar 13 10:10:55 Herrie|Laptop: the issue is still a build issue? Mar 13 10:11:17 Tofe: Yup Mar 13 10:11:30 bshah: No rush, more will follow :P Mar 13 10:11:52 Herrie|Laptop: also, btw do you want to put your device tree and kernel repo on halium organization? Mar 13 10:11:53 Trying to sanitize the useless repo forking a bit by sorting stuff in the setup script for device ;) Mar 13 10:12:04 bshah: That's why I'm cleaning these up Mar 13 10:12:07 okay Mar 13 10:12:48 I'll then PR our WIP targets and also cleanup our android repo Mar 13 10:12:50 Herrie|Laptop: also.. one thing I would love is, a documentation for making kernel compile with newer gcc... with some common errors and some patches Mar 13 10:13:05 Since we're basically duplicating your Android repo - boot ;) Mar 13 10:13:21 And doing a seperate file with our devices. Better to use Halium-devices for that Mar 13 10:13:26 Saves overhead on repo-sync Mar 13 10:13:43 bshah: Yeah will try to see if I can get a whole LuneOS porting guide added :P Mar 13 10:14:00 in theory you don't need LuneOS porting guide :P Mar 13 10:14:09 but I get what you mean ;0 Mar 13 10:14:45 bshah: We do ;) Mar 13 10:14:50 Since we build our own rootfs :P Mar 13 10:15:02 Which is still device specific Mar 13 10:15:07 Not arch specific like you do Mar 13 10:15:17 right :) Mar 13 10:15:45 Though the Halium bits are the tricky part, rest is pretty much copy & paste into various files :P Mar 13 10:40:54 bshah: Seems 3.10 and 3.18 are pretty much OK without GCC hacks. It's mainly 3.4 that are the issue Mar 13 16:11:04 nizovn: This LunaSysService bug is weird. It crashes my LunaSysService in FirstUse. However on subsequent boots it seems to behave better Mar 13 16:11:26 However pkill-ing LunaSysService and restarting it with gdb attached it doesn't crash Mar 13 16:12:33 nizovn: Ah OK now I got it to break Mar 13 16:12:45 Seems that when I pkill with FirstUse open it doesn't break Mar 13 16:12:50 But when I relaunch firstUse it does Mar 13 16:13:09 https://bpaste.net/show/4e54f25bc760 Mar 13 16:28:53 Herrie|Laptop: does it crash on some certain page in FirstUse? Mar 13 16:29:17 Select your language Mar 13 16:29:25 Doesn't populate the list Mar 13 16:29:42 So you'd almost think that it doesn't have the data available Mar 13 16:29:51 I guess I could do a simple luna-send with the same query Mar 13 16:30:03 yes Mar 13 16:35:50 No reply Mar 13 16:48:18 you can try to edit systemd service file to enable verbose logging: ExecStart=/usr/sbin/LunaSysService --logger=debug Mar 13 16:48:37 it's in /lib/systemd/system/luna-sysservice.service Mar 13 17:26:40 nizovn: Relevant bit: https://bpaste.net/show/0dc80cff9698 Mar 13 17:30:52 looks ok i think Mar 13 18:52:50 I suspect it MIGHT have somethign to do with https://github.com/webOS-ports/luna-sysservice/commit/33fcf787cb4c5ab8bb5e51c23d0bae33da2d1d61 but know too little to say anything useful Mar 13 19:13:17 Herrie: theoretically using C++11 shouldn't change the time API or behavior Mar 13 19:15:10 Tofe: Well this is the other most likely culprit then? https://github.com/webOS-ports/luna-sysservice/commit/f4327332e00597c767ccc7610d8f23b98eaaa606 Mar 13 19:20:02 What bothers me is that it's not consistent, sometimes I get lists populated, most times not Mar 13 21:04:20 Tofe: On the libglibutil: Seem that mer guys have some .spec file in their repo: https://git.merproject.org/mer-core/libglibutil/blob/master/rpm/libglibutil.spec#L28 Mar 13 21:04:49 KEEP_SYMBOLS=1 seems to get rid of the already-stripped error Mar 13 21:05:42 I have a number of IPKs Mar 13 21:06:31 libglibutil-dev_1.0.28+gitr0+b535e47e5c-r0_aarch64.ipk seems to have the .h files in /usr/include/gutil Mar 13 21:07:06 And a /usr/lib/libglibutil.so Mar 13 21:08:06 libglibutil1_1.0.28+gitr0+b535e47e5c-r0_aarch64.ipk seems to have /usr/lib/libglibutil.so.1, libglibutil.so.1.0 and libglibutil.so.1.0.28 Mar 13 21:17:47 Herrie: OE does the stripping Mar 13 21:18:09 I didn't get any error with the recipe I gave you Mar 13 21:18:40 Well warning, not error Mar 13 21:18:52 ah, ok, that I didn't check Mar 13 21:19:24 but, yes, the files are where they're meant to be Mar 13 22:00:42 Well you'd say so, however if I copy the .h like I did in original recipe I posted, I get another error Mar 13 22:00:47 At least it finds the .h files Mar 13 22:01:42 it doesn't find the .h files without copying the headers ? Mar 13 22:02:01 Nope doesn't seem so Mar 13 22:02:05 It's a bit weird Mar 13 22:02:14 that's unfortunate Mar 13 22:02:41 So probably should move the .so in the proper place too Mar 13 22:04:40 the .so is a bit weird yes Mar 13 22:05:54 I'll go get some sleep I think, bit tired here :p Mar 13 22:06:01 Same here Mar 13 22:06:30 Seems ofono expects them in /usr/include but they're in /usr/include/glib Mar 13 22:08:36 gn8 **** ENDING LOGGING AT Wed Mar 14 03:00:01 2018