**** BEGIN LOGGING AT Tue Mar 19 02:59:57 2019 Mar 19 03:32:28 learningc: the build tools build the cross-compiation toolchain as part of the build process. there's no separate prebuilt tools to use Mar 19 03:35:49 kergoth, I see. that's what I thought. Where is it located normally in the build tree? Mar 19 04:02:50 Is there any good easy to follow tutorial for yocto on how to create custom recipe, add layer, add patches, etc? Mar 19 05:18:17 how can i force to reread the bblayer.conf ? Mar 19 05:19:03 looks like devtool is not finding any new layer that i add with bitbake-layers add-layer Mar 19 08:30:19 What Authors would you recommend for learning Yocto? I have found Alex Gonzalez, Rudolf j Streif and Texier, Mabacker and few books they wrote Mar 19 08:31:16 willie2: Streif, probably. Mar 19 08:31:48 willie2: yet the really best way is to have a personal introduction, like the YPDD beginner track offers. Mar 19 08:32:08 "Embedded Linux Systems with the Yocto Project" something you would recommend? Mar 19 08:32:20 willie2: many concepts are pretty hard to write down, but if you see them explained and teached in person, they become quite obvious. Mar 19 08:33:14 Whats is YPDD track offers? and yea thats what I'm starting to realize, its hard to learn by trial and error :) Mar 19 08:33:37 willie2: well 2016 makes it obviously a bit dated, but it has been recommended quite a few times, and streif knows this stuff. Mar 19 08:34:02 willie2: the "yocto project developer day", usually colocated with the embedded linux conferences. Mar 19 08:34:49 willie2: there are other offers too of course, and if you are doing this for professional reasons taking a course for a couple of bucks is certainly more than worth it. Mar 19 08:36:34 LetoThe2nd: I'm ok with it beeing a bit dated, i just want to understand the core concept of it all. Mar 19 08:37:25 LetoThe2nd: That sounds really interesting, I will have to look that up! Mar 19 08:37:26 then the streif book probably is a good start. Mar 19 08:37:56 bootlin certainly has offers too, just as any decent embedded linux consultancy. Mar 19 08:42:55 willie2: the best buy is Rudolf j Streif Mar 19 08:43:30 willie2: if you need training I do that: http://koansoftware.com/en/content/yocto-project-course Mar 19 08:44:16 willie2: see :) Mar 19 08:44:20 cool! Mar 19 08:44:28 in Italy? Mar 19 08:45:12 willie2: Italy and worldwide Mar 19 08:46:27 willie2: http://www.koansoftware.com/it/content/calendario-corsi-training-calendar Mar 19 08:46:34 mckoan: nice, maybe i can convince my company to send me Mar 19 08:47:33 willie2: tell them that it will save them money within 3 weeks. Mar 19 08:48:48 because assuming that you want to be paid for the time wasted in try-and-error, thats what you can roughly expect :) Mar 19 08:49:10 LetoThe2nd: exactly my toughts Mar 19 08:49:49 mckoan: I will look for dates that suits me! When will you update it for late April/May? Mar 19 09:15:29 New news from stackoverflow: I can't build any machine with the new yocto release for IMX8 Mar 19 10:02:03 anyone seeing g-ir-scanner-qemuwrapper failures in gobject-introspection with latest master? qemu segfaults Mar 19 10:02:58 like https://paste.ubuntu.com/p/skBhFygC2D/ Mar 19 10:15:39 New news from stackoverflow: How to clean, free space? Mar 19 10:29:51 anybody have an example of a wks which includes an extra filesystem, with a bunch of files injected into it? Mar 19 10:30:16 or, the machinery for getting such an end result Mar 19 10:30:55 guessing something similar to the bootimg-partition.py wic plugin Mar 19 10:31:06 just curious if someone else has done similar legwork I can leverage Mar 19 10:42:48 hmmm, looks like I might be able to leverage sources/poky/scripts/lib/wic/canned-wks/directdisk-multi-rootfs.wks Mar 19 10:44:37 armpit: is there a reason why http://lists.openembedded.org/pipermail/openembedded-core/2019-March/279999.html wasn't included in sumo pull? Mar 19 10:49:21 I have a makefile that wants to use the git command. So I wote my recipe with SRC_URI = "git://somewhere...;bareclone=1;destsuffix=myloc". That seems to work as intended, I can see the raw git repo. However, the do_config fails because it cannot find git. I added DEPENDS = "git-native" but that did not change anything. From the enviroment I see that git-native is in ASSUME_PROVIDED. So how can I get git into the path during the build? Mar 19 10:51:17 s/raw git repo/bare git repo/ Mar 19 11:14:09 I believe this is some copy&pasta: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/xorg-proto/xorgproto_2018.4.bb#n3 Mar 19 12:00:58 on the poky version that I'm using devtool is not finding any new layer that i add with bitbake-layers add-layer Mar 19 12:01:21 so I cannot modify any layer packages Mar 19 12:28:47 Hi, I have a question related to Yocto Sumo version 2.5. I'm trying to upgrade my project build environemnt from 2.2 (Morty) to 2.5 (Sumo), and I'm facing many problems for every recipe trying to add new users or groups to the system. Even when I try to build the "useradd-example.bb" which is provided in "meta-skeleton" it's also failing to finish with this error: "do_install: useradd-example: groupadd command did not succeed". Mar 19 12:28:53 Inside the logs I got two main error, ".....useradd-example/1.0-r1/recipe-sysroot/etc/group: No such file or directory" and this means that "base-passwd" pkg was not populated as part of the "recipe-sysroot", the other error is "....../0.1-r0/recipe-sysroot-native/usr/bin/pseudo: No such file or directory" and this means "pseudo-native" pkg was not populated as part of the "recipe-sysroot-native". Mar 19 12:28:59 The only solution I have is to update dependency with (DEPENDS += "base-passwd pseudo-native") in each recipe, even in "useradd-example.bb" to make it work with my project environment. Any idea why this is happenning or what should I change to make it work like the original pure poky 2.5?! Mar 19 12:29:05 FYI, it's building fine if I use pure poky 2.5 version outside my project environment, and no errors reported, and I'm aware of the new change which was introduced in 2.5 to remove "build/tmp/sysroots/" and now each recipe has his own sysroots (hardlinked from build/tmp/sysroots-components/) ref: https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#structure-build-tmp-sysroots-components Mar 19 12:46:07 New news from stackoverflow: Both libc.so.6 and libc.so exist in roofs Mar 19 12:51:32 rburton: why am i getting this package qa error? https://paste.fedoraproject.org/paste/X3zRAOZ-34AzWwmOAVOVTQ Mar 19 12:52:09 funny thing is, if i back out the change to the wx recipe, i still get it. i don't remember this happening several weeks ago when i last built it Mar 19 12:54:09 yates: becyse dev package contains a non-symlink .so file Mar 19 12:54:22 that .so isn't a library, its a module Mar 19 12:54:30 so it should be in PN or something Mar 19 12:56:11 does the message mean some .so, or does it literally mean ".so"? Mar 19 12:57:20 nm Mar 19 12:57:23 it's webkit2_extu-3.0. Mar 19 12:57:25 so Mar 19 12:58:48 you mean it should be in in FILES_${PN}? Mar 19 12:59:52 i already have FILES_${PN}-dev += "${libdir}/wx" Mar 19 13:00:00 which is where this file is Mar 19 13:00:32 alicef: did you add your layer to bblayers.conf ? Mar 19 13:01:17 right? Mar 19 13:01:42 mckoan: yes Mar 19 13:01:59 but it dosen't show it on bitbake-layer show-layers Mar 19 13:04:01 alicef: let's recap, how did you create and add your layer? Mar 19 13:11:09 rburton: ? Mar 19 13:12:49 does the syntax FILES_${PN}-dev += "${libdir}/wx" specify ${libdir}/wx AND ALL SUBFOLDERS/FILES? Mar 19 13:16:13 New news from stackoverflow: i.MX6 Qt5.7 EGLFS: Could not set DRM mode Mar 19 13:22:26 hello? Mar 19 13:24:32 yates: see my reply from yesterday Mar 19 13:28:28 JaMa: thanks - i had not seen it! Mar 19 13:29:30 yates: yes Mar 19 13:29:49 yates: what else would it do? you said "put this directory in PN-dev" Mar 19 13:29:59 if you mean a subst of files, say so Mar 19 13:31:27 * yates needs more coffee Mar 19 13:32:22 so is the problem that webkit2_extu-3.0.so is NOT SUPPOSED to be in the FILES for this package? Mar 19 13:33:02 it's supposed to be in FILES_${PN} only Mar 19 13:33:16 NOT the -dev? Mar 19 13:33:51 ok, so what is the syntax to specify JUST the directory lib/wx and NOT its subdirectories? Mar 19 13:34:14 i.e., the directory lib/wx and all its files in it, but not subdirectories? Mar 19 13:34:22 is this bash rules/syntax? Mar 19 13:34:37 i get confused on what's python, what's bash, and what's somethign else Mar 19 13:35:17 actually, i think all i need is wx-config Mar 19 13:35:32 yates: was going to say, i'd be surprised if everything in there was for -dev Mar 19 13:36:15 another funny thing: why does this only happen when i switch to gtk+3? if i revert back to gtk+ (2) this error goes away.. Mar 19 13:36:45 that file doesn't exist in gtk2 builds? Mar 19 13:36:55 brilliant! Mar 19 13:37:14 rburton.iq++ Mar 19 13:37:22 :) Mar 19 13:37:33 ok, thanks - lemme fix this and see if i can move on Mar 19 13:37:45 thanks rburton and JaMa Mar 19 13:55:36 at do_install() time, which path variable specifies the built /usr/lib ? Mar 19 13:56:37 is it ${libdir}? Mar 19 13:57:59 or ${WORKDIR}/${libdir}? or what? Mar 19 13:58:41 RP: I sent a v4 of openssl patch which removes perlnative need and also upgrades it to 1.1.1b Mar 19 13:58:53 yates: you'll be copying to ${D}/${libdir} Mar 19 13:59:06 yes, but what about the from? Mar 19 13:59:18 yates: wherever under ${B} the file is Mar 19 14:01:17 so like ${B}/usr/lib/... ? Mar 19 14:02:59 in do_install you're copying files from the build tree (B) to a file system structure under D. usually this just involves 'make install', telling the rules to install under D Mar 19 14:03:46 (autotools does make install DESTDIR=${D} Mar 19 14:12:15 http://codepad.org/1fvwD8BH is an example script Mar 19 14:13:54 how do copy or incorporate files from a directory into a package made from a recipe Mar 19 14:48:48 otavio: ok, thanks Mar 19 14:55:38 I'm wondering if someone can help be in the adduser issue, related to populating the recipe-sysroots new concept introduced in sumo 2.5 ! Mar 19 14:56:31 Inside the logs I got two main error, ".....useradd-example/1.0-r1/recipe-sysroot/etc/group: No such file or directory" and this means that "base-passwd" pkg was not populated as part of the "recipe-sysroot", the other error is "....../0.1-r0/recipe-sysroot-native/usr/bin/pseudo: No such file or directory" and this means "pseudo-native" pkg was not populated as part of the "recipe-sysroot-native". Mar 19 14:57:30 and this is by using the original useradd-example.bb recipe from poky Mar 19 15:03:54 How can I learn why a package has been included in a image? -g generates a file too large for my xdot, and -u depexp is no longer available it seems Mar 19 15:04:07 Are there any other tools for this? Mar 19 15:04:19 sveinse: just don't use xdot, but vim :) Mar 19 15:04:26 or less, or grep, or whatever Mar 19 15:04:49 vim? As in text? oh... ok. let me try Mar 19 15:06:08 sveinse: oe-depends-dot script operates against the .dot files Mar 19 15:06:08 sveinse: a .dot file is literally just a text file with very very many lines. Mar 19 15:06:13 but yes, you can directly examine it Mar 19 15:06:44 https://github.com/openembedded/openembedded-core/blob/master/scripts/oe-depends-dot#L25 Mar 19 15:07:19 but oe-depends-dot -w is probably what you want Mar 19 15:07:22 interesting. I've attempted to decode manually other dot files, but this one was surprisingly simple to read. Learned something here, so thanks LetoThe2nd Mar 19 15:08:13 sveinse: have fun Mar 19 15:08:49 jonmason: if you have a minute we should catch up on where this arm server is at Mar 19 15:09:03 halstead: you may also find this relevant Mar 19 15:09:28 RP: sure, I'm free now Mar 19 15:09:47 basically there are two sets of problems, one is how to enable kvm there, the second is that esdk won't work in the bringup config on aarch64 simply due to the way it uses uninative Mar 19 15:09:50 The encoding in the dot file is "a" -> "b", meaning a depends on b, right? Not the other way round? Mar 19 15:10:28 yes Mar 19 15:11:13 jonmason, halstead: this means the bringup test won't really work properly on arm64. I'm thinking we should go ahead and move that worker to the ptest-arm target and then fix that configuration there Mar 19 15:12:17 Is the bigger problem kvm or the bringup? Mar 19 15:12:47 jonmason: kvm. Moving out of bringup will avoid the other Mar 19 15:14:18 RP: okay, I'll look into that. This is running Ubuntu (or is anything that works fine at this point), correct? Mar 19 15:15:26 jonmason, It's Ubuntu 18.04.2 LTS at the moment but can be changed if needed. Mar 19 15:16:21 halstead: okay, I should have a local system running that that I can use. If its a deadend, I'll look at using something else that has it working Mar 19 15:16:53 jonmason, Do you have a preferred distribution that works best? Mar 19 15:17:44 halstead: My feeling is that should be fine, its just a question of getting the enablement in our builds Mar 19 15:17:49 halstead: I'm under the impression it should work, but I'll need to do some investigation and maybe asking around internally Mar 19 15:25:15 halstead: I just added what I hope is the right bit to publish the aarch64 uninative. Can we rerun that build (may as well use the same hash as before)? Mar 19 15:25:31 RP, Sure. I'll queue it. Mar 19 15:25:49 halstead: hopefully its fast and we can have a look at the output in a few minutes Mar 19 15:27:24 RP, Should be 5 to 10 minutes. Mar 19 15:28:01 * RP notes armpit beat him to another build :/ Mar 19 15:30:18 RP: looking at the testresult.json, which git tree is beeing used on these test? 9b0f29919d58f8859b2077568e11d1b959ca55aa is not on git://git.openembedded.org/openembedded-core and the git commit count do not fit with master-next... Mar 19 15:30:41 RP, you can kill it... is this for M3 ? Mar 19 15:30:59 I want to build the image to check what exactly is going on Mar 19 15:31:03 halstead: looks like you decided to use master and the current revision? Mar 19 15:31:15 psrcode: its a poky revision Mar 19 15:31:28 psrcode: poky ~= oe-core+bitbake Mar 19 15:31:37 http://git.yoctoproject.org/cgit.cgi/poky/log/ Mar 19 15:31:50 thanks Mar 19 15:31:50 armpit: Its ok, I can wait on uninative Mar 19 15:31:53 RP, I used the rebuild button not understanding what would happen. I'll make it right. Mar 19 15:32:19 halstead: just leave it as if you change it we'll queue behind armins build Mar 19 15:32:50 halstead: it built "HEAD" last time so I suspect it rebuilt with that Mar 19 15:33:46 * armpit haven't seen my name referenced so much since I was a kid getting into trouble Mar 19 15:34:14 RP, Yes. I'll know for next time. Mar 19 15:34:54 armpit: heh :) Mar 19 15:36:26 halstead: build completed :) Mar 19 15:37:47 RP: 9b0f29919d58f8859b2077568e11d1b959ca55aa is not part of http://git.yoctoproject.org/cgit.cgi/poky/log/ .... Mar 19 15:37:47 RP, Looks like it worked, https://autobuilder.yocto.io/pub/non-release/20190319-10/toolchain/aarch64/ Mar 19 15:38:35 halstead: yes. Can we get those into the right place and I'll fire a test build? Mar 19 15:38:39 RP, Shall I replace https://autobuilder.yocto.io/pub/non-release/20190319-10/toolchain/aarch64/ ? Mar 19 15:38:51 RP, Yes. I'll delete what's at http://downloads.yoctoproject.org/releases/uninative/2.4/ Mar 19 15:39:00 halstead: yes Mar 19 15:39:04 RP: anyway i'll just buid latest master-next, will get back to you regarding the hanging tests Mar 19 15:39:22 psrcode: I suspect it was a poky master-next. Oddly I can't find that rev locally either Mar 19 15:39:39 psrcode: master-next will reproduce Mar 19 15:39:47 RP: good Mar 19 15:39:55 psrcode: or master at this point, we don't have much delta Mar 19 15:40:04 ok Mar 19 15:40:28 psrcode: it is a master-next poky revision, I can find it locally Mar 19 15:41:58 psrcode: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/lttng-reproduce Mar 19 15:42:02 RP, http://downloads.yoctoproject.org/releases/uninative/2.4/ is all set. Mar 19 15:42:20 halstead: thanks. Lets see if this works... Mar 19 15:42:42 RP: thanks Mar 19 15:48:43 halstead, armpit: master-next fired. Thanks for the help halstead! Mar 19 15:49:15 Thank you RP. Did you want to sync up 1:1? Mar 19 15:52:37 halstead: sure Mar 19 16:02:44 RP. k Mar 19 16:04:59 RP, do we know if the lttng ptests need to be backport to thud & sumo Mar 19 16:19:02 Is it a bad thing if after spending considerable time writing a bug report with test case and all, realizing that that its your own fault? :D I mean, its a good thing for the community, but man, you kinda want to press submit after investing so much time in documenting and arguing. And like that, its all gone... Mar 19 16:21:34 sveinse: happens, that. Mar 19 16:22:11 probably best to say "don't take it personal" :) Mar 19 16:22:29 LetoThe2nd: yeah, true. One experience richer :D Mar 19 16:22:49 its a similar experience to successful rubber duck debugging. Mar 19 16:23:12 LetoThe2nd: whats that? Mar 19 16:24:32 ask the search engine of your least distrust. or wikipedia :) Mar 19 16:27:41 wxwidgets build works now with transparencies. Mar 19 16:27:42 ah, right, yeah. In Norwegian we call this something like "talking to ourselves" (out loud) and not limited to programming Mar 19 16:27:58 thanks again everyone for the help, especially rburton Mar 19 16:35:04 yates: are you working on upgrading existing wxwidgets recipe in meta-ros? Mar 19 16:36:43 armpit: lets get master working with those first Mar 19 16:36:54 armpit: looks like we've taken steps forward and back right now Mar 19 16:37:24 JaMa: no not yet. is meta-ros the right layer? Mar 19 16:37:54 i thought there was an old recipe in meta-oe too Mar 19 16:38:14 rp. k Mar 19 16:38:53 * RP keeps wondering why rburton is in a layer Mar 19 16:54:18 to make ipks is to make a recipe file essentially correct? Mar 19 17:08:29 yates: 2.9.5 version is already in meta-ros, see: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=wxwidgets Mar 19 17:08:46 yates: that doesn't mean that it's the right layer Mar 19 17:09:39 possibly imported from 2.9.0 version which was in oe-classic: https://layers.openembedded.org/layerindex/comparison/recipes/oe-classic/?q=wxwidgets&category=&selectedlayers=&has_patches=&cover_status=&cover_verified=&needs_attention=&excludeclasses= Mar 19 17:10:09 wow, nice that this search also says "Direct match exists in meta-ros" in the status Mar 19 17:15:12 or let me say this "WARNING: xxx do_package_qa: QA Issue: Symlink /etc/default.yml in xxxx points to TMPDIR [symlink-to-sysroot]" Mar 19 17:17:13 sounds like you should fix the s ymlink Mar 19 17:17:36 armpit: since master used lttng-tools 2.10 and thud/sumo uses lttng-tools 2.9 the ptest work is not the same, I can take a look at fixing any ptest weirdness on thud/sumo after fixing master if you want, if you can guaranteed that if work is done it will most probably merge I'll spend time on it Mar 19 17:18:00 *probably be merged Mar 19 17:18:08 a .bb makes a package Mar 19 17:18:12 correct Mar 19 17:18:21 and installable package Mar 19 17:18:55 psrcode, I have to double check thud/sumo lttng ptest Mar 19 17:19:02 I will let you know.. thanks Mar 19 17:20:12 black_13: a recipe emits multiple binary packages in whatever format is configured when built Mar 19 17:20:15 so yes Mar 19 17:27:48 armpit: you can probably reuse the added dependencies but it will mostly end there I think Mar 19 17:30:57 JaMa (deceased): yeah, i needed 3.0.4 Mar 19 17:31:30 so can i create a package that 1. creates a symbolic link and 2. runs a script at install Mar 19 17:32:18 k Mar 19 18:43:54 RP: hmm something is fishy... on eo-core core-image-mininal (master-next) the notification test (lttng-tools) run smooth but on poky core-image-sato-sdk-ptest master-next the dynamic linker behave differently and make the test hang since lttng-sessiond never actually start Mar 19 18:45:20 RP: the linker complain about missing symbol, we had a similar problem when running on musl since the linker does not lazy bind, we do have a fix for this. Mar 19 18:45:53 I'm finishing testing on core-image-sato-sdk-ptest and will send it to you and for upstream merging. Mar 19 18:46:22 You will probably have to carry the patch until our next tag release if it is okai with you Mar 19 19:34:12 hi, what is the fastest way to switch poky branch to "thus"? Mar 19 19:34:39 I just tried to clone it and replace "poky" directory, but there are issues with the recipes Mar 19 19:34:55 what is the correct way to do it please? Mar 19 19:35:42 to "thud" *** sorry Mar 19 19:37:14 is there way to force rebuild of a recipe Mar 19 19:40:58 black_13, what I have done is force a reconfigure like : bitbake -f -c configure {pkg} Mar 19 19:42:09 ok Mar 19 19:42:37 is there way to make have an ipk package create symbolic links Mar 19 19:45:28 armpit: or to cleanup a build Mar 19 19:45:49 black_13: what do you mean? Mar 19 19:45:58 a package can contain whatever you put it in, including links Mar 19 19:46:08 just create them in do_install as you would anything else in a bitbake recipe Mar 19 19:46:24 an ipk is just an ar archive with a couple tar files inside Mar 19 19:48:05 can you give an example Mar 19 19:48:37 nearly every recipe in oe-core Mar 19 19:48:39 go read one Mar 19 19:48:53 ok Mar 19 19:56:02 ERROR: Layer updater-raspberrypi is not compatible with the core layer which only supports these series: rocko (layer is compatible with thud) Mar 19 19:56:09 what should I do please??? Mar 19 20:46:35 is dependency on "openssl10-native" supposed to work in thud? I get a conflict with openssl-native in do_prepare_recipe_sysroot, even though it's not supposed to get pulled on its own... Mar 19 20:47:40 New news from stackoverflow: How can I install OpenCV on Yocto Linux version? Mar 19 20:48:01 naknick: don't use mismatched branches, or use a layer that supports the newer release Mar 19 20:50:41 denix, I would think so. Surprised we are not seeing this in the AB Mar 19 20:55:50 denix, does master have the issue? Mar 19 20:56:27 Hello, is the meta-raspberry depricated? last commit 2016 :( Mar 19 20:59:15 armpit: why would AB fail? I don't think there's a single package that specifically depends on "openssl10-native" Mar 19 20:59:50 denix, (e)SDK ? Mar 19 21:04:35 Disconnected, did anyone replay to me?:p Mar 19 21:07:07 willie2, see http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/ Mar 19 21:08:57 lol i have been using an really old branch Mar 19 21:08:59 xD Mar 19 21:24:11 denix, you are more than welcome to open a bug for thud Mar 19 21:39:14 denix: I noticed that meta-ti has references to a Hewlett-Packard license that seems to be Mar 19 21:39:20 missing? Mar 19 21:42:00 smurray: it was going away anyway - http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=dde59d16ec5969ff69c41c2ca2c11f1ebb3bc983 Mar 19 21:43:09 denix: okay, I’ve been testing with the rc2 of the thud branch against AGL Mar 19 21:45:48 smurray: but yeah, I believe there are couple licenses mentioned that don't have corresponding license files... need to follow up on that Mar 19 21:50:31 denix: okay, no worries Mar 19 21:51:32 smurray: that's a warning now, right? Mar 19 21:51:33 psrcode: sounds good to me. I'm very interested to learn why -sato-sdk fails yet minimal works Mar 19 21:52:10 RP: tbh not sure, but in any case we need this fix for musl ... Mar 19 21:52:39 RP: i'll investigate furher once I get everything to work (musl included) Mar 19 21:53:05 psrcode: fair enough. Carrying a patch isn't a problem, particularly if we know its upstream :) Mar 19 21:53:33 RP: count on me it will be in a form or another :) Mar 19 21:54:08 otavio: strange as it sounds, it appears the mesa upgrade causes https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/418 Mar 19 21:54:23 otavio: I don't know why mesa would break a qemu musl image Mar 19 21:54:50 psrcode: cool. We have a lot of patches but there is a strong desire to reduce this, we're slowly making progress Mar 19 21:58:32 denix: yeah Mar 19 22:22:00 RP: I am trying to understand the log ... Mar 19 22:25:48 * armpit for $14.99 you can get RP's book on reading AB output Mar 19 22:26:37 * armpit its in Queens English so 1/2 the words I don't understand Mar 19 22:44:21 haha Mar 19 22:47:29 * RP just saw this, the autobuilder isn't that obtuse is it? Mar 19 22:47:37 or perhaps I'm that obtuse :/ Mar 19 23:04:42 armpit: indeed; as I am brazilian, 2/3 of the words I don't understand ;-) Mar 19 23:07:21 hehe Mar 19 23:08:38 RP: am I right? Mar 19 23:08:40 AssertionError: 2 != 0 : Log: /home/pokybuild/yocto-worker/musl-qemux86-64/build/build/tmp/work/qemux86_64-poky-linux-musl/core-image-sato-sdk/1.0-r0/target_logs/Xorg.0.log Mar 19 23:08:44 ----------------------- Mar 19 23:08:46 Central error: [ 10.684] (EE) Server terminated with error (1). Closing log file. Mar 19 23:08:49 *********************** Mar 19 23:08:52 [ 10.682] (EE) Mar 19 23:08:54 Fatal server error: Mar 19 23:08:57 [ 10.683] (EE) Caught signal 11 (Segmentation fault). Server aborting Mar 19 23:08:59 [ 10.683] (EE) Mar 19 23:09:02 [ 10.683] (EE) Mar 19 23:09:04 Please consult the The X.Org Foundation support Mar 19 23:09:07 at http://wiki.x.org Mar 19 23:09:09 for help. Mar 19 23:09:12 [ 10.683] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. Mar 19 23:09:15 [ 10.683] (EE) Mar 19 23:09:17 [ 10.684] (EE) Server terminated with error (1). Closing log file. Mar 19 23:09:20 It failed on the test ? Mar 19 23:13:26 otavio, the xorg test just checks to see if the server is up and running. nothing fancy Mar 19 23:14:38 otavio: so the xserver is segfaulting rather than starting up and the error log parsing is then catching the failure Mar 19 23:14:56 otavio, if you also look in the stdio, there should be a like to the error.yp.org Mar 19 23:15:02 https://errors.yoctoproject.org/Errors/Build/78813/ Mar 19 23:18:00 s/like/link Mar 19 23:25:46 otavio: second mesa issue: https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/419 :/ Mar 19 23:26:16 halstead: tests on uninative look god, we can publish Mar 19 23:37:39 Subprocess output: Mar 19 23:37:40 gpg: signing failed: Cannot allocate memory Mar 19 23:37:40 gpg: signing failed: Cannot allocate memory Mar 19 23:37:40 error: gpg exec failed (2) Mar 19 23:37:40 /home/pokybuild/yocto-worker/bringup/build/build-st-36679/tmp/work/core2-64-poky-linux/xtrans/1_1.3.5-r0/deploy-rpms/core2_64/xtrans-dbg-1.3.5-r0.0.core2_64.rpm: Mar 19 23:37:44 strange Mar 19 23:38:33 RP, Excellent. I' Mar 19 23:38:47 RP, I'll tag and push. Mar 19 23:39:41 RP, I'm looking at https://autobuilder.yoctoproject.org/typhoon/#/builders/66/builds/24 and seeing gpg signing errors that remind me of bad limits from back in December however all the limits look correct. Mar 19 23:41:46 otavio: was the mesa configure failure in step8b I was referring to. Looks like enabling llvm has an issue Mar 19 23:42:08 halstead: we keep seeing it, was that opensuse again? Mar 19 23:42:26 halstead: its running out of something and its suse specifc, don't know what :( Mar 19 23:42:29 RP, Both of opensuse150 and Fedora29. Mar 19 23:43:13 halstead: wonder if that is gpg from the host or our native version Mar 19 23:43:31 RP: I will check if there is any know issue Mar 19 23:43:47 otavio: specifically https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/419/steps/7/logs/step8b Mar 19 23:43:59 RP. we now have god looking at things? Mar 19 23:44:18 otavio: I need to build M3, don't think mesa is ready :/ Mar 19 23:44:27 RP: neither do I Mar 19 23:44:39 armpit: ? Mar 19 23:44:50 There was no gpg binary on the path for the Fedora 29 workers it only had gpg2. So in that case it was it certainly native? Mar 19 23:44:56 look above... you misspelled good Mar 19 23:44:58 RP: go for it; if we find a solution we can try again later Mar 19 23:45:02 RP, I mean not native. Mar 19 23:45:10 halstead: ok, that means its the same on all the workers so removes another variable Mar 19 23:45:34 otavio: well, M3 is feature freeze, I don't want to change mesa later, we need to stabilise what we have Mar 19 23:45:36 RP, In that case these are probably worth risking in the general pool. Mar 19 23:45:47 armpit: stop trolling people when they are hard at debugging! :) Mar 19 23:45:51 halstead: I'm ok with that Mar 19 23:45:56 RP: fine; so lets keep with what we have Mar 19 23:46:16 maybe god is a YP member ? Mar 19 23:46:45 armpit: ah :) Mar 19 23:48:13 * armpit hmm, xfinity is snooping my home network Mar 19 23:48:27 * RP is jetlagged and I'm not sure going out with the cycling club was a good move tonight Mar 19 23:48:54 if you didn't crash, its a good thing Mar 19 23:49:43 denix, don't you have some homework to get done today ? Mar 19 23:49:48 armpit: road cycling so yes, I'd prefer to avoid that Mar 19 23:50:41 RP, I've paused everything to prep for a controller restart. Mar 19 23:51:11 halstead: is this for the worker changes? Have you tried the dynamic reconfig? Mar 19 23:51:43 RP, No. I'm doing that instead. Thank you. Mar 19 23:52:04 halstead: it doesn't update everything but is usually quite effective when I've tried it Mar 19 23:52:44 RP: would a 18.3.5 update be accepted? Mar 19 23:52:54 it is the latest 18.3 release Mar 19 23:53:01 if so, we can work on it tomorrow Mar 19 23:53:03 otavio: depends whats in it and what the risk is Mar 19 23:53:30 RP, Now just need a build to come in. :) Mar 19 23:53:42 halstead: M3 is imminent Mar 19 23:55:28 RP: it is a bugfix only release. We are at 18.3.4 now Mar 19 23:55:52 otavio: it may be an option. Haven't we seen mesa stable series break things? Mar 19 23:57:09 RP: honestly, no Mar 19 23:57:50 RP: surprisely, Arch Linux upgraded mesa to 19.0.0 today Mar 19 23:58:36 otavio: We've tried to get it in but with two sets of bugs to figure out I think we're out of time :( Mar 19 23:58:56 we can discuss 18.3.5, that may be an option in M4 Mar 19 23:59:10 * RP has fired the M3 build Mar 19 23:59:51 http://git.yoctoproject.org/cgit.cgi/poky/tag/?h=uninative-2.4 and https://git.openembedded.org/openembedded-core/tag/?h=uninative-2.4 Mar 19 23:59:55 * RP feels a bit happier with that done Mar 20 00:00:05 halstead: thanks! Mar 20 00:01:48 otavio: FWIW I think it still makes sense to resolve the mesa 19.x issues since we will have to anyway sooner or later Mar 20 00:02:57 there is always the possibility this build won't work out for some reason (I'm trying to ignore that) Mar 20 00:03:07 meson.build:1239:6: ERROR: Problem encountered: The Nouveau driver requires rtti. You either need to turn off nouveau or use an LLVM built with LLVM_ENABLE_RTTI. Mar 20 00:03:48 RP, I hope these new workers don't mess up the M3. Seems like kind of an important moment to introduce them. Mar 20 00:03:59 meson: Error out if building nouveau and using LLVM without rtti Mar 20 00:04:36 halstead: I was just wondering about that. I guess we'll see Mar 20 00:05:10 I'll check back in on the build before bed. Mar 20 00:06:54 RP: I wonder how it works for some and fail other Mar 20 00:07:07 maybe musl builds LLVM without LLVM_ENABLE_RTTI ? Mar 20 00:10:55 otavio: I think that build is a "graphics with llvm" test Mar 20 00:10:56 RP: this is a regression with meson Mar 20 00:11:01 commit c5a97d658ec19cc02719d7f86c1b0715e3d9ffc4 Mar 20 00:11:01 Author: Dylan Baker Mar 20 00:11:01 Date: Mon Apr 16 14:47:58 2018 -0700 Mar 20 00:11:01 meson: fix builds against LLVM built without rtti Mar 20 00:11:01 Building without rtti is a frought with peril, but it's something that autotools supports so we need to support it too. Mar 20 00:11:04 Since we've moved to version 0.44 as a whole we can use the meson functionality for accessing random llvm-config options we can check for rtti and add -fno-rtti to all C++ code accordingly. Mar 20 00:11:08 Signed-off-by: Dylan Baker Mar 20 00:11:09 otavio: so two issues, one is musl segfaulting and the other is llvm Mar 20 00:11:10 autoconf supports it Mar 20 00:11:43 would you be open to build using autotools and see if it really "works" ? Mar 20 00:12:14 otavio: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json#n777 is the config for that build Mar 20 00:12:23 PACKAGECONFIG_append_x86-64_pn-mesa = ' gallium-llvm gallium r600' Mar 20 00:13:03 RP: fine, but nauveou is what needs it and it is enabled Mar 20 00:13:41 otavio: I'm not sure what you're asking me Mar 20 00:21:31 * RP should really sleep Mar 20 01:53:51 anybody got ideas how to debug an image build with "busybox.postinst returned 1, marking as unpacked only, configuration required on target." ? the do_rootfs logfile doesn't say anything useful apart from the quoted text Mar 20 02:01:58 seems like busybox's applet links are fine in the initramfs, but not in the final root filesystem Mar 20 02:33:24 never mind; good old "set -x", looks like busybox was conflicting with an actual package that provided the same binaries **** ENDING LOGGING AT Wed Mar 20 02:59:57 2019