**** BEGIN LOGGING AT Mon Mar 05 03:00:03 2018
Mar 05 08:36:28 <Herrie|Laptop> Morning!
Mar 05 09:00:09 <Tofe> Morning!
Mar 05 09:28:22 <Herrie|Pre3> Tofe: Still having various issues on mido but working through them 1 by 1.
Mar 05 09:28:36 <Herrie|Pre3> Seems that some are false leads in logcat which doesn't help :P
Mar 05 09:30:01 <Herrie|Pre3> Most important issues besides sensors & connectivity are currently screen that turns off all the time & battery charging indicator that doesn't work properly. Any suggestions where to look for those?
Mar 05 09:30:15 <Herrie|Pre3> I suspect that's on our side with nyx or something?
Mar 05 09:42:12 <JaMa> Herrie|Pre3: Tofe: I've merged small pyro upgrade of upstream layers yesterday and forgot to trigger the builds, triggering them now
Mar 05 09:42:47 <Herrie|Pre3> JaMa: OK. Anything shocking that changed and might impact us?
Mar 05 09:43:09 <JaMa> not yet
Mar 05 09:43:27 <JaMa> there will probably be upgrade to gcc 6.4 later, which currently have some issues
Mar 05 09:43:39 <JaMa> but those issues should be resolved before it's merged from pyro-next to pyro
Mar 05 09:44:34 <Herrie|Pre3> JaMa: OK
Mar 05 09:44:47 <Herrie|Pre3> If there's anything that needs attention let us know
Mar 05 09:44:59 <Herrie|Pre3> Tofe: Had any clues to your boot issues?
Mar 05 09:46:07 <Tofe> Herrie|Pre3: not yet, but I was home yesterday (not will I tonight), so I'll continue my debug tomorrow
Mar 05 09:46:43 <Herrie|Pre3> Tofe: No worries was just wondering :)
Mar 05 09:47:11 <Tofe> must be something stupid really
Mar 05 09:48:32 <Tofe> JaMa: I'd be interested in your opinion on my new recipe for generating our boot.img image, which is also deployed: https://github.com/Tofee/meta-smartphone-1/commit/bae1501b7c5f1bd13c4d2a89321242389c9dc440
Mar 05 09:51:19 <Tofe> JaMa: the functions' content come directly from kernel_android.bbclass, so that wasn't an issue. But having the recipe deployed was more problematic for me; I hope my solution isn't too hacky?
Mar 05 09:59:51 <Herrie|Pre3> JaMa: The purpose is that we want to use Haliums initrd so we don't need to reinvent the wheel for that at our side. Just as background info.
Mar 05 10:00:25 <Herrie|Pre3> Their init scripts are pretty stable already and support 50+ targets currently.
Mar 05 10:00:45 <Herrie|Pre3> Therefore the need to change things around a bit at our end.
Mar 05 10:24:56 <JaMa> Tofe: the do_deploy itself doesn't look wrong, but the reason for this recipe feels a bit strange still
Mar 05 10:25:21 <JaMa> the recipes depending on the kernel shouldn't depend on kernel's do_deploy inly do_populate-sysroot or similar
Mar 05 10:35:35 <Tofe> JaMa: well here we simply reuse the zImage created by the kernel; we don't need the latter to be actually deployed, that's true. But I'm not sure how to retrieve that zImage from kernel's package; is it a fixed name, can I simply use KERNEL_IMAGETYPE ?
Mar 05 10:37:08 <Tofe> JaMa: actually it's the kernel we don't need to be deployed. What we need to be deployed is the final fastboot image, that we can boot and/or flash on device
Mar 05 10:45:53 <JaMa> I meant the other dependency from e.g. lvm to kernel recipe
Mar 05 10:46:14 <JaMa> but the initramfs dependency is added to kernel do_compile task already IIRC, so it won't help
Mar 05 10:47:34 <JaMa> hmm still something is strange
Mar 05 10:48:05 <JaMa> if we call abootimg in kernel's do_deploy and add dependency on do_deploy[depends] += "initramfs-android-image:do_image_complete"
Mar 05 10:48:16 <JaMa> then it should still IMHO work without extra recipe
Mar 05 10:48:32 <JaMa> lvm.do_configure will depend on virtual/kernel.do_populate_sysroot
Mar 05 10:49:19 <JaMa> and do_deploy will run after virtual/kernel.do_populate_sysroot and after lvm.do_package_write and initramfs-android-image:do_image_complete
Mar 05 10:49:35 <JaMa> unless there is a bug somewhere or I'm missing some other dependency
Mar 05 11:33:40 <Tofe> JaMa: in this case it was not precisly lvm but udev (i.e. systemd) which caused the issue; but it's probably the same loop
Mar 05 11:35:35 <Tofe> JaMa: also, we need to have boot.img in the resulting ipk, so it has to be in the build task
Mar 05 11:42:15 <Tofe> But more generally, I'm not sure what's weird with having a dedicated recipe for building boot.img; it's not a kernel, nor an initramfs, so for me it feels quite natural to do have it separately
Mar 05 11:58:52 <JaMa> true
Mar 05 13:33:29 <Herrie|Laptop> vanyasem[m]: webOS was way ahead of it's time in 2009 with everything webbased and gestures
Mar 05 13:33:51 <Herrie|Laptop> iOS and Android copied a lot from it in recent years (especially Apple pretending it's first :P)
Mar 05 13:34:23 <Herrie|Laptop> There are a lot of similarities with Maemo/Meego/Mer/SFOS/Jolla in general, but also differences
Mar 05 14:04:38 <Herrie|Laptop> Tofe: My LunaSysService is crashing with: Feb 12 08:56:17 mido LunaSysService[721]: LunaSysService: malloc.c:2369: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Mar 05 14:44:36 <Herrie|Laptop> Tofe: I guess that might be more of a JaMa question...
Mar 05 15:03:47 <Herrie|Laptop> Tofe: Does it look like this is something that might solve this issue? https://github.com/clearlinux-pkgs/glibc/commit/c06f38ea1954912fe0d318ebf266e81ae99e39a0
Mar 05 15:03:55 <Tofe> Herrie|Laptop: that's a pretty extensive assert :)
Mar 05 15:05:02 <Herrie|Laptop> Seems malloc.c comes from glibc so I guess we should be careful with anything there :P ?
Mar 05 15:12:10 <Herrie|Laptop> Seems there are quite some upstream changes to malloc.c in since 2.25 release.... https://github.com/bminor/glibc/commits/master/malloc/malloc.c
Mar 05 15:34:41 <Herrie|Laptop> Though seems the lines references didn't change :S
Mar 05 15:38:33 <Tofe> Herrie|Laptop: a malloc failure probably means that the requested number of bytes is incorrect (could be a non-initialized variable)
Mar 05 15:38:53 <Herrie|Laptop> Is valgrind of any help here?
Mar 05 15:39:05 <Tofe> yes, looks like the right tool here
Mar 05 15:40:47 <Herrie|Laptop> https://bpaste.net/show/45c996e3e8a4
Mar 05 15:41:02 <Herrie|Laptop> LunaSysService is quite critical, without this cannot do much on OS :P
Mar 05 15:41:55 <Herrie|Laptop> And https://bpaste.net/show/814398730d45
Mar 05 15:42:14 <Tofe> it didn't crash?
Mar 05 15:42:55 <Tofe> leaks are not fatal; "points to uninitialised byte" might be the cause of the crash though
Mar 05 15:43:05 <Herrie|Laptop> Tofe: it crashes
Mar 05 15:43:09 <Tofe> you'll need to get the crash happening inside gdb, to have a stack
Mar 05 15:44:14 <Herrie|Laptop> And a strace if that's of any help: https://bpaste.net/show/4b104437d6ef
Mar 05 15:54:36 <Herrie|Laptop> Tofe: Hmmz need to figure out how to get the debug symbols working again?
Mar 05 15:54:38 <Herrie|Laptop> And gdb :P
Mar 05 15:54:43 <Herrie|Laptop> Not really my territory
Mar 05 16:27:17 <Herrie|Laptop> Tofe: OK loaded the debug IPK
Mar 05 16:27:24 <Herrie|Laptop> What I do next again. gdb LunaSysService
Mar 05 16:27:25 <Herrie|Laptop> And then?
Mar 05 16:31:10 <Herrie|Laptop> Ok here we go: https://bpaste.net/show/0a5d50277be6
Mar 05 16:33:04 <nizovn> Herrie|Laptop: you need "bt"
Mar 05 16:33:34 <Herrie|Laptop> bt ?
Mar 05 16:33:41 <Herrie|Laptop> instead of run?
Mar 05 16:33:50 <Herrie|Laptop> Tells me "no stack"
Mar 05 16:34:05 <nizovn> after run and crash
Mar 05 16:35:01 <Herrie|Laptop> OK doesn't seem to be happy with Timezones somehow :S
Mar 05 16:35:11 <Herrie|Laptop> https://bpaste.net/show/9b743cc480e0
Mar 05 16:44:41 <Herrie|Laptop> Could be my upgrade to https://github.com/webOS-ports/meta-webos-ports/commit/9a050e15f0dbe82fc88a8d228f77d848e241faed
Mar 05 16:45:28 <Herrie|Laptop> Or JaMa's upgrade: https://github.com/webOS-ports/luna-sysservice/commit/f4327332e00597c767ccc7610d8f23b98eaaa606
Mar 05 16:58:19 <Herrie|Laptop> Hmmz /usr/share/zoneinfo/ has 1845 files :P
Mar 05 16:59:03 <nizovn> Herrie|Laptop: we can also try to check gmTime for NULL before dereferencing it
Mar 05 17:00:30 <nizovn> e.g. trans.year        = (gmTime?gmTime->tm_year:0) + 1900;
Mar 05 17:00:52 <nizovn> here: https://github.com/webOS-ports/luna-sysservice/blob/webOS-ports/master/Src/TzParser.cpp#L439
Mar 05 17:07:09 <Herrie|Laptop> Let me try that
**** ENDING LOGGING AT Tue Mar 06 03:00:02 2018