**** BEGIN LOGGING AT Tue Mar 19 02:59:57 2019 Mar 19 07:49:20 JaMa: testing looks quite fine so far, I'm optimistic we'll be able to do a release pretty soon Mar 19 07:50:02 I've started a thud build for tissot on my machine this morning, to tackle the Qt crash Mar 19 07:50:20 It's probably just a minor fix Mar 19 08:09:37 Morning Mar 19 08:24:56 Morning! Mar 19 08:56:20 morning Mar 19 08:56:33 I've started unstable builds, but jenkins seems to be dead now Mar 19 08:56:55 novaldex|away: can you please check nginx on jenkins? Gives 502 Bad Gateway now Mar 19 08:57:17 novaldex|away: I can ssh to kaylee though Mar 19 09:00:05 Tofe: I got few failures with warrior on hammerhead, but otherwise looks ok Mar 19 09:01:35 Tofe: do you need svga gallium mesa driver? mesa-18.3.4/src/gallium/drivers/svga/svga_msg.c:86:4: error: impossible constraint in 'asm' Mar 19 09:06:19 svga ? no no :) that still exists ?... Mar 19 09:06:44 JaMa: you'll probably get a little build error for qtwayland's patch Mar 19 09:07:21 know that I already PR'ed the 5.12 version here: https://codereview.qt-project.org/256191 Mar 19 09:08:02 i.e. https://codereview.qt-project.org/gitweb?p=qt/qtwayland.git;a=patch;h=78b3c19a23c8db51289d10fb3e240191141f6161 Mar 19 09:08:31 novaldex|away: I've started jenkins on kaylee, now it seems to work Mar 19 09:09:00 Tofe: thud nor warrior don't use 5.12 yet (only jansa/master branches) Mar 19 09:09:14 but good to know, I'll update jansa/master with this Mar 19 09:09:18 oh, ok, I thought warrior was. Nevermind then Mar 19 09:09:54 with a bit of luck, it'll be upstream before we even need it Mar 19 09:11:51 meta-qt5/warrior will be 5.12 once meta-qt5/master switches to 5.13, but for LuneOS warrior I plan to keep qt from thud until we upgrade Mar 19 09:16:40 ok Mar 19 09:37:48 GALLIUMDRIVERS="swrast,r300,svga,nouveau,virgl,freedreno" Mar 19 09:37:49 GALLIUMDRIVERS_LLVM="r300,svga,nouveau" Mar 19 09:47:29 JaMa: I'm not sure I understand, isn't llvm always used in Gallium? Mar 19 09:49:54 there is separate knob to enable llvm support --enable-llvm --enable-llvm-shared-libs independently on gallium PACKAGECONFIG which adds only --with-gallium-drivers Mar 19 09:50:22 and when gallium-llvm PACKAGECONFIG is enabled the GALLIUMDRIVERS_LLVM are appended to GALLIUMDRIVERS Mar 19 09:51:01 so this current value doesn't make much sense and in the end freedreno is added in --with-gallium-drivers (with or without llvm enabled) Mar 19 09:51:24 if it makes any sense to try to configure mesa like this I cannot say Mar 19 09:52:46 ah Mar 19 09:52:47 dnl Gallium LLVM Mar 19 09:52:47 dnl Deprecated: kept for backwards compatibility Mar 19 09:53:04 AC_MSG_WARN([The --enable-gallium-llvm option has been deprecated. Use --enable-llvm instead.]) Mar 19 09:53:11 nevermind Mar 19 09:53:22 I should check how meson configures it in mesa-19* Mar 19 09:55:03 it look like some gallium drivers can work without llvm, some can switch between llvmpipe and softpipe Mar 19 10:08:31 ok, all this is quite new for me :) Mar 19 10:12:07 it's still a bit messy, after changing bbappend to: Mar 19 10:12:08 GALLIUMDRIVERS_hammerhead = "freedreno" Mar 19 10:12:08 GALLIUMDRIVERS_LLVM_hammerhead = "" Mar 19 10:12:41 we still get virgl (new in warrior) and extra , from empty GALLIUMDRIVERS_LLVM :/ Mar 19 10:12:43 env.mesa3:PACKAGECONFIG_CONFARGS=" --enable-dri --with-dri-drivers= --disable-dri3 --enable-egl --with-gallium-drivers=freedreno,,virgl --enable-llvm --enable-llvm-shared-libs --enable-gbm --enable-gles1 --enable-gles2 --enable-opengl --disable-gallium-osmesa --disable-libunwind --without-vulkan-drivers --disable-glx --disable-xa --disable-xvmc" Mar 19 10:16:41 I guess you haven't seen qemu segfaults in your hammerhead build, right? https://paste.ubuntu.com/p/skBhFygC2D/ Mar 19 10:18:57 nope Mar 19 10:19:07 but I'm on sumo Mar 19 10:25:04 ok Mar 19 10:51:02 "exiv2-0.25-r0 do_fetch: Failed to fetch URL http://exiv2.dyndns.org/releases/exiv2-0.25.tar.gz" on thud, wasn't Herrie's commit picked ? Mar 19 11:10:36 Tofe: The dyndns should work normall Mar 19 11:10:38 +y Mar 19 11:11:09 Seems they're back to exiv2.org :S Mar 19 11:22:16 But GitHub still points to dyndns Mar 19 11:22:19 Bit of a mess Mar 19 11:22:37 Could also just mirror the releases ourselves for now until they sort their stuff :P Mar 19 11:32:34 Or switch to 0.26/0.27 and point to their GitHub release archives Mar 19 11:55:02 Herrie|Laptop: let's point to github, it should be more reliable Mar 19 11:57:24 or can we define alternative mirrors in the recipe ? Mar 19 12:00:27 http://www.embeddedlinux.org.cn/OEManual/src_uri_variable.html looks like it's possible with MIRRORS_append Mar 19 12:50:53 Tofe: Seems that on GH only from 0.26 Mar 19 12:50:56 0.25 not there Mar 19 12:51:00 0.26 and 0.27 are Mar 19 12:54:36 Herrie|Laptop: and why don't we take 0.26 or 0.27 ? Mar 19 12:54:43 Issue with 0.26 and 0.27 is that it doesn't seem to like our do_install_append Mar 19 12:55:04 If I remove it build goes OK, but not sure that's the desired result ;) Mar 19 12:56:57 ah ok :) Mar 19 12:58:37 Let me build 0.25 without the do_install_append and see what I get Mar 19 13:01:25 Seems we had warning in 0.25 that's why you added it ;) Mar 19 13:01:37 So I guess when we remove it and no warning in 0.26/0.27 we should be good ;) Mar 19 13:05:21 Tofe: Seems OK with 0.27 Mar 19 13:05:26 Do we know what INSANE_SKIP_${PN} = "useless-rpaths" does? Mar 19 13:15:43 If I remove it I get no warnings, so I guess it's safe to remove ? Mar 19 13:22:47 Tofe: is that fatal error for you? even when not using sstate from jenkins builder, you should use it as premirror Mar 19 13:23:47 Herrie|Laptop: it might be triggered only on some archs, but if it doesn't for you lets remove it and see if it returns Mar 19 13:23:56 it should be easy to resolve correctly anyway Mar 19 13:24:19 JaMa: Let me try mido, qemux86, tried hammerhead now Mar 19 13:24:25 If all are OK we should be fine I'd say Mar 19 13:24:52 qemux86-64 would be interesting as well as it matches host arch Mar 19 13:25:25 OK Mar 19 13:27:03 I'm removing following jenkins jobs: rm -rf luneos-stable_build luneos-testing_build luneos-unstable_build Mar 19 13:27:34 they were using old BuildFlow plugin and didn't even show up in the UI Mar 19 13:27:40 and the log shows why: Mar 19 13:27:41 Failed Loading item luneos-unstable_build Mar 19 13:27:42 com.thoughtworks.xstream.mapper.CannotResolveClassException: com.cloudbees.plugins.flow.BuildFlow Mar 19 13:28:03 doesn't explain why jenkins crashed last night, but 3 less long exceptions in the log are always welcome Mar 19 13:32:06 I've also created new folder on jenkins for LuneOS jobs: http://jenkins.nas-admin.org/job/LuneOS/ once it's all finished I'll move all our jobs there to remove some noise, any objections (old links to jobs won't work, that's probably the main disadvantage) Mar 19 13:32:40 JaMa: I see no problems there really Mar 19 13:33:01 We have a few links in WiKi in https://webos-ports.org/wiki/Pre_and_Post_Release_To_Do mainly Mar 19 13:33:04 I can update those Mar 19 13:49:54 JaMa: https://github.com/webOS-ports/meta-webos-ports/pull/320 Mar 19 13:49:58 Should be cherry picked to others Mar 19 13:56:25 Herrie|Laptop: don't use archives from github, they are regenerated from time to time with different checksums Mar 19 13:57:21 use git fetcher with SRCREV matching the tag Mar 19 13:57:30 JaMa: OK let me update Mar 19 13:58:13 sorry was away a bit Mar 19 14:05:52 morning, sorry a late time for me to join today Mar 19 14:06:06 JaMa: thanks for restarting Jenkins, will see if something happened to it Mar 19 14:06:30 novaldex: I'll restart it once more after moving our jobs to separate folder Mar 19 14:06:43 I've also installed few plugins updates while doing the previous restart Mar 19 14:07:14 we were a bit wary of some of the plugins, those with warnings we didn't want to break anything else Mar 19 14:09:30 we're using only very basic features of pipeline plugin and everything looks fine Mar 19 14:11:32 that's good to know, thanks Mar 19 14:18:15 jenkins failed about 0610 today with: *** Error in `/usr/bin/java': double free or corruption (out): 0x00007f0ad459b100 *** Mar 19 14:18:56 ah :/ Mar 19 14:19:06 is there a plan to upgrade kaylee to 18.04 as well? Mar 19 14:19:16 JaMa: https://github.com/webOS-ports/meta-webos-ports/pull/320/files Mar 19 14:19:20 the same for milla Mar 19 14:19:43 not at present, our focus was on the builders first Mar 19 14:20:02 Herrie|Laptop: lgtm Mar 19 14:20:24 not to say that it's not possible to do, just not on our radar Mar 19 14:20:34 ok Mar 19 14:23:29 Herrie|Laptop: merged to sumo Mar 19 14:23:50 rebasing other branches Mar 19 14:50:13 JaMa: Thnx Mar 19 16:08:07 ok, my thud tissot image is ready for testing Mar 19 17:17:59 jobs moved and new unstable builds running, I'll test the thud tissot image from jenkins later today as well, but I don't trust my local builds anymore (to many local changes applied on other changes I've forgotten about) :) Mar 19 21:47:54 JaMa: my local build for thud tissot doesn't even seem to boot Mar 19 21:48:28 there isn't anything in /sys/fs/pstore, so it must be failing pretty early Mar 19 21:49:11 oooops ! sorry, I was just too impatient ! nevermind ! Mar 19 22:02:08 now I have a callstack: https://paste2.org/X6NvxMca Mar 19 22:15:09 could the cause be an upgrade of wayland ? That would be strange... Mar 20 01:52:20 Tofe: my guess is that it's caused because we're using different wayland drivers, let me find the commit Mar 20 01:56:28 Tofe: https://github.com/webOS-ports/meta-webos-ports/commit/54d09efe4e0eba402e96b2a2611d4bfe1b4e848f Mar 20 01:57:32 Tofe: and more importantly this first part https://github.com/webOS-ports/meta-webos-ports/commit/dcb0b166bf5daaed2d56e9cafca4c68df19a901c Mar 20 01:59:16 as first test we should probably try to reverse this, to use libwayland-egl from libhybris and remove the one from wayland (for MACHINEs using libhybris), I've removed it originally from libhybris, because it was consistent for MACHINEs using libhybris as well as mesa **** ENDING LOGGING AT Wed Mar 20 02:59:57 2019