**** BEGIN LOGGING AT Thu Feb 07 02:59:57 2019 Feb 07 05:04:26 Why would a .bb file suddenly generate an error "unable to parse"? Feb 07 05:04:51 I verify it's unmodified Feb 07 05:07:26 *verified ... I had line-continuation slash on a comment in a .bbappend but it fingers the source .bb not the append for the error. Feb 07 06:34:06 hi! i'm trying to run systemtap on my devboard, but i'm getting an error that "/lib/modules/4.14.71-rt44/build/.config" is missing. which package do i need to add to my image? TIA Feb 07 07:35:50 How can be a package prevented from being built by "btibake meta-toolchain-qt5"? Feb 07 07:48:39 Just wanna to strip off qtwebkit Feb 07 07:48:58 Which seems that can't be build inside a VM Feb 07 08:00:36 Morning Guys, I'm trying to build this recipe (https://github.com/b2open/simpleDemoQt5Quick) for a raspi3 board but i'm stuck with this OpenGL error : https://pastebin.com/rpxCGLi8 any idea ? thx. Feb 07 08:01:21 malanecora: maybe inherit a new image recipe no ? Feb 07 08:03:30 malanecora: it depends on how it emerges. May be it's some kind of dependency, that you can't remove at all Feb 07 08:03:45 PinkSnake: What do you mean with that? :p Feb 07 08:03:49 is it an image recipe? Feb 07 08:04:54 acrap_: It seems like a package Feb 07 08:05:22 https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/meta/meta-toolchain-qt5.bb Feb 07 08:07:35 malanecora: create a new recipe, add this : IMAGE_INSTALL += "meta-toolchain-qt5" and build :) Feb 07 08:10:00 PinkSnake: In that case I'd build the complete SDK along with my own image, wouldn't I? Feb 07 08:10:55 malanecora: yes, but what do you want avoid the sdk generation ? Feb 07 08:11:04 why* Feb 07 08:11:21 PinkSnake: Because qtwebkit can't be built at all Feb 07 08:11:39 PinkSnake: It just eats all my RAM and stucks at 38% Feb 07 08:11:43 Forever Feb 07 08:11:49 :( Feb 07 08:12:16 So that I just want to prevent qtwebkit from being built Feb 07 08:12:30 But I do want the SDK Feb 07 08:15:26 malanecora: Arf, you can also remove sdk called isn't it ? Feb 07 08:17:21 malanecora: maybe removing "packagegroup-qt5-toolchain-target" from qt5-creator_git.bb Feb 07 08:21:59 PinkSnake: I've checked out packagegroup-qt5-toolchain-target.bb but it doesn't include qtwebkit, so I can't remove it haha Feb 07 08:22:14 May be it is not possible Feb 07 08:22:28 Since other packages depends on it Feb 07 08:22:38 depdne* Feb 07 08:22:41 depend* Feb 07 08:29:14 malanecora: :( Feb 07 08:32:38 malanecora: last chance, qt5.inc called example compilation and examples depends on qtwebkit Feb 07 08:43:19 PinkSnake: Ty dude! Feb 07 08:43:39 I'm taking a look over qttools_git.bb Feb 07 08:44:05 There's a PACKAGECONFIG for qtwebkit Feb 07 08:44:16 Though it is pretty weird Feb 07 08:53:27 New news from stackoverflow: How to create a Yocto recipe for cmake with separate -dev package of header files? Feb 07 09:06:35 Mmm...If I run out of RAM, Yocto would warn, wouldn't it? Feb 07 09:13:59 If so, the qtwebkit problem is not induced by a lack of RAM Feb 07 09:15:18 malanecora: do you have a log ? Feb 07 09:15:50 PinkSnake: I do, but it doesn't tell much Feb 07 09:16:04 In fact, I don't know if it is even a "complete" log Feb 07 09:16:15 malanecora: OK no prob. Feb 07 09:16:20 Since the build doesn't fail but stucks Feb 07 09:17:12 It's a quite strange thing to say the least Feb 07 09:18:37 Nevertheless, it can (and sure partially does) be VM's performance related issues Feb 07 09:20:44 malanecora: bitbake is at the mercy of the underlying build tools (make, gcc, binutils) so warning about OOM is hard Feb 07 09:24:11 RP: Yah, I understand, but isn't it strange that 8GB RAM + 4GB Swap for a pacakage to compile could be not enough (Yocto scope)? Feb 07 09:27:19 malanecora: when its webkit, that isn't that surprising, its huge Feb 07 09:27:44 malanecora: you could perhaps turn of debug symbols to help Feb 07 09:28:03 RP: Haha LetoThe2nd told me the same Feb 07 09:28:22 RP: Ya, I'll try to Feb 07 09:31:07 Last bullet before moving the whole environment to a machine with hots-OS Feb 07 09:31:10 host* Feb 07 09:32:15 Actually I meant native Feb 07 10:26:37 RP: seems like python3 passed this time? Feb 07 10:52:28 malanecora: for context the memory footprint of the webkit library during link is ~5gb Feb 07 10:52:55 we know that because people who try to build it on 32-bit hosts can't link it... Feb 07 10:58:24 rburton: So, I guess I have enough memory, right? Feb 07 10:59:01 no i'm suggesting that *just* the link of webkit it eating about 2/3rd of your ram Feb 07 10:59:21 turn off debugging for that recipe and build just qtwebkit on its own, you might be lucky Feb 07 10:59:37 there's a reason people who build webkit often have lots of ram Feb 07 11:00:04 hmmm...got it Feb 07 11:00:13 I'm working on it Feb 07 11:00:18 Thank you man Feb 07 11:10:49 kanavin: it did! Feb 07 11:11:20 RP: actually I just want to know if there's some other reason it didn't make it to master yet :) Feb 07 11:11:29 other bits of master-next did Feb 07 11:11:36 kanavin: I wanted to actually read through the patches ;-) Feb 07 11:11:40 oh Feb 07 11:36:10 kanavin: patches look good to me, seems to have cleaned out a few! Feb 07 11:36:48 RP: thanks, I took them in on as-needed basis, just like perl Feb 07 11:37:22 kanavin: did you glance through the remainder to check if there was anything subtle we may need? Feb 07 11:38:05 RP: I didn't actually Feb 07 11:40:04 kanavin: its things like float-endian I worry about Feb 07 11:41:53 The proper way to disable debug symbols is patching the whatever.cmake, right? Feb 07 11:43:35 malanecora: We pass it in as part of CFLAGS Feb 07 11:44:06 RP: inside the Yocto recipe? Feb 07 11:44:20 malanecora: in the recipe you can set DEBUG_BUILD = "0" Feb 07 11:44:39 or DEBUG_BUILD_pn-XXXX in local.conf where XXXX is the PN of the recipe in question Feb 07 11:45:06 RP: Oh, quite useful. Thank you again! Feb 07 11:45:32 RP: right, that one in particular will be in 3.8, but is not in 3.7 Feb 07 11:47:03 kanavin: hence my concern :/ Feb 07 11:47:27 RP: let me quickly look through them then Feb 07 12:54:47 Hi, I have a problem regarding a yocto recipe. The recipe just downloads a file and installs it directly. Changing the version by renaming the file, leads to a rebuild of the ipk and the ipk is updated. But the image, that includes this recipe, does not rebuild and uses the old recipe. Other recipes do not have the problem. It seems the sstate is not cleared correctly by just changing the version. Can someone help me? Feb 07 12:58:29 evotion: Have you 2 (or more) recipes of the same pkg but different verison? Feb 07 12:58:33 version* Feb 07 13:00:16 malanecora: There is always only one version of the package as a recipe. Feb 07 13:00:53 So, how is it using the old recipe instead of the actual current one? Feb 07 13:01:21 Have you performed an "btibake -c cleansstate my_pkg" before build with the new one? Feb 07 13:01:31 well thats just working around the problem Feb 07 13:01:51 you're definitely actually asking bitbake to rebuild the image right Feb 07 13:02:02 bitbake myrecipe won't rebuild the image Feb 07 13:02:29 Yes Feb 07 13:03:30 Even if I build the package and afterwards the image, the image is not using the correct image. It just works if I do a cleansstate. Feb 07 13:03:40 and the recipe is like foo_1.bb and you use PV in the recipe? Feb 07 13:03:46 *package Feb 07 13:03:47 can you pastebin the recipe Feb 07 13:06:54 BTW, disabling debug symbols for qtwebkit by adding DEBUG_BUILD = "0" to a bbappend didn't did the trick Feb 07 13:07:16 It stills consume the whole system memory Feb 07 13:08:11 And all the Yocto related tasks go Disk Sleep Feb 07 13:08:33 PV is used to determine the the actual file, that needs to be installed Feb 07 13:10:06 pastebin the recipe as rburton suggested Feb 07 13:10:26 Greetings! While trying to add the meta-networking layer, I got the error "depends on openembedded-layer ", but I couldn't find it in the meta-openembedded repository. I added the meta-oe by sheer guessing, and it does seem to parse recipes up to a point Feb 07 13:10:33 However, it fails with "meta-openembedded/meta-oe/recipes-dbs/postgresql/postgresql_11.1.bb: Exception during build_dependencies for PERL_ARCHLIB" Feb 07 13:10:33 * AndersD has quit (Ping timeout: 268 seconds) Feb 07 13:10:36 I think we're misunderstanding each other Feb 07 13:10:50 ^ copied from #oe, my bad : P Feb 07 13:11:36 sk_tandt_: yes openembedded-layer is meta-oe Feb 07 13:12:00 looks like your meta-oe branch and your oe-core branch don't match? Feb 07 13:18:27 Mh, I am compiling with tag 2.6.1 for yocto: which branch should I choose? Feb 07 13:19:38 RP: I added three patches which were the more obvious ones, for the rest we'll have to rely on community testing I suppose Feb 07 13:19:50 Is there a single possibility of suceed if I double the swap? (desperate mode off) Feb 07 13:20:01 sk_tandt_: tHUD i GUESS Feb 07 13:20:09 Dat caps Feb 07 13:22:05 Here is a minimal package example https://pastebin.com/4rxX0Fhq Feb 07 13:22:42 The recipe does not work, its a not accessable svn server, where the file is fetched from Feb 07 13:23:35 malanecora, it was thud indeed, thanks! Feb 07 13:23:52 I also checked, the do_deploy and do_install task are rerun if I trigger a build without cleansstate and the package contains the correct version, just the image does not update Feb 07 13:23:53 rburton, it was indeed a version mismatch! Out of curiosity, how did you figure it out? Feb 07 13:24:13 sk_tandt_: because it didn't work Feb 07 13:24:25 New news from stackoverflow: How to compile linux-raspberrypi kernel in yocto? Feb 07 13:24:31 if it doesn't even parse its probably a mismatch Feb 07 13:25:13 note that current oe will warn if the layers are known to not work, so either 1) you have a fairly old OE, or 2) meta-oe master needs to say that it is only compatible with master Feb 07 13:25:27 what version are you using? Feb 07 13:30:16 rburton, yocto 2.6.1 . Btw, I notice you mention oe-core, which I assume is a base layer upon which the others are integrated? Feb 07 13:30:32 sk_tandt_: you may know it as poky Feb 07 13:30:39 but poky is just oe-core + bitbake + some other bits Feb 07 13:32:48 I see! Now, the last commit from for the poky repo has the following message: "build-appliance-image: Update to thud head revision". Hindsight is 20/20, so now I reckon it does spell out the correct oe version to fetch, but are there other ways to know it? Feb 07 13:33:33 not sure what you're asking but is https://wiki.yoctoproject.org/wiki/Releases useful? Feb 07 13:37:40 kanavin: ok, thanks. I wish we had better test cases... Feb 07 13:37:49 kanavin: I wonder if the ptest results would show anything? Feb 07 13:38:54 RP: I can try to see if there are any regressions there? Feb 07 13:40:01 kanavin: that would be a good test, I think rburton had most of the tests passing Feb 07 13:40:16 the python ptest was ~100%, two tests failed Feb 07 13:40:25 one because setuptools was a bit broken on target Feb 07 13:40:31 and the other, i can't remember Feb 07 13:40:53 just python3 -mtest works Feb 07 13:41:03 (after installing python3-test) Feb 07 13:49:07 rburton: Do you have an idea, why the pastebin recipe is not updateing the image? Feb 07 13:54:44 rburton, it's perfect, thanks! Feb 07 14:10:07 So there's no way to extract the Qt5 SDK without passing by qtwebkit Feb 07 14:19:35 btw, I can't find people warning (or complaining) about this in among the net Feb 07 14:57:13 Where can I find the steps for replacing busybox with the coreutils? Feb 07 14:57:34 I tried adding it to my image but that produces a mess of host contamination warnings. Feb 07 14:57:45 It replaced a few utilities, like dd, but not all. Feb 07 15:09:22 RP, rburton both 3.5 and 3.7 python ptest errors out early due to missing libgcc_s.so needed for pthread_cancel to work (or so it says) Feb 07 15:09:32 let's see if I can easily improve that... Feb 07 15:10:16 kanavin: add the RDEPENDS to python3-ptest ? Feb 07 15:10:26 yep :) Feb 07 15:36:47 Hi guys Feb 07 15:37:06 finally I've managed to build the **** qtwebkit Feb 07 15:37:26 It took 12 GB of RAM plus ~2 GB of Swap Feb 07 15:37:39 And about an hour of compilation time Feb 07 15:37:53 FYI Feb 07 15:38:16 (and DEBUG_BUILD = "0") Feb 07 15:39:11 that's way worse than i remember. congrats Feb 07 15:39:52 malanecora: good job! Feb 07 15:46:04 malanecora, gg! How did you achieve it? Feb 07 15:58:58 I managed to get extra RAM and expanded the swap Feb 07 15:59:14 Cleaned and rebuilt it Feb 07 15:59:43 Though now it failed populating the SDK because the VM ran out of Disk Space Feb 07 16:00:08 I had over 40GB of free space before that Feb 07 16:00:11 :P Feb 07 16:05:12 malanecora: inherit rm_work Feb 07 16:06:29 RP: If I do, would I have to re-fetch all the sources the next time I wan to build the SDK? Feb 07 16:07:41 (my connection is capped, 300KB/s for each connection) Feb 07 16:09:05 no, rm_work removes the workdir, not downloads or sstate or even packages Feb 07 16:09:51 kergoth: Oh nice! That's a good tip RP, thank you both Feb 07 16:34:45 adelcast: 3/3 of your opkg series didn't appear to reach the list Feb 07 16:56:16 rburton, I see the 3/3 here on gmail Feb 07 17:06:01 RP: with a couple of tweaks, python ptest passes 100% :) Feb 07 17:06:06 patch on the list Feb 07 17:06:22 a few tests are skipped though due to missing modules or otherwise Feb 07 17:07:14 kanavin: cool, thanks for that. I'll test the result together and then likely merge :) Feb 07 17:07:51 RP: don't forget the other patch that forward-ports three patches Feb 07 17:09:40 kanavin: Yes, I was going to grab both :) Feb 07 17:11:28 kanavin: running on the AB now Feb 07 17:13:14 RP: cool, then we'll get rid of the one major out of date problem Feb 07 17:13:21 kanavin: yes :) Feb 07 17:13:30 the rest is basically okay in oe-core, for now Feb 07 17:13:50 kanavin: I'd like to sort out a few more of the minor version upgrades but yes Feb 07 17:14:09 RP: did you get any other responses to the email (directed to you privately perhaps)? Feb 07 17:14:25 kanavin: a couple you wouldn't see Feb 07 17:14:37 yep, I only saw armin's Feb 07 17:18:19 kanavin: people don't have time :( Feb 07 17:20:20 everyone is too busy on actual product Feb 07 17:26:10 Crofton: so how do we support the foundations these products are built upon? Feb 07 17:27:23 bluelightning: During devtool reset or devtool finish command, the source code in the workspace is not removed. The user has to manually clean the source code. Is it a good idea to provide a flag for the devtool reset command that allows the user to specify if the source within workspace should be removed or not ? For example: devtool reset -r will reset the workspace as well as remove the source dir in workspace. Feb 07 17:28:04 RP, the eternal problem Feb 07 17:28:29 * Crofton is in a rush to get something for a customer to test with :) Feb 07 17:28:40 chandana73: FWIW that would seem like a reasonable thing to have an option for Feb 07 17:29:20 chandana73, yep, this has been a minor annoyance for me for a long time. I kinda thought this is 'by design' but maybe we should challenge it :) Feb 07 18:56:39 kanavin: its by design but having the option would be good Feb 07 18:56:55 kanavin: by default would be dangerous Feb 07 20:23:13 RP: kanavin: thank you for the feedback. Feb 07 22:23:03 where does the source for hciconfig come from? Feb 07 22:23:22 the bluetooth configuration utility Feb 07 22:30:56 bluez5 Feb 07 22:31:10 $ oe-pkgdata-util find-path /usr/bin/hciconfig Feb 07 22:31:10 bluez5: /usr/bin/hciconfig Feb 07 23:00:20 Is there a way to make wgtpkg-pack use multiple cores? Does it use a particular compression tool internally so I could set env. vars to do it? e.g. XZ_DEFAULTS? Feb 07 23:07:16 whats wgtpkg-pack? Feb 07 23:08:22 oh some AGL thing Feb 07 23:08:25 ask the AGL people :) Feb 07 23:16:09 kanavin: Hey Alex, is there a reason why youre moving the python3 recipe to python-santiy? Feb 07 23:17:20 aehs29: I was just talking about that! Feb 07 23:17:51 * RP is contemplating squashing in a patch moving it back Feb 07 23:24:53 RP: I can imagine it was just to keep the upgrade "sane" but I thought I'd ask Feb 08 02:42:00 RP: i sent out a patch based on the discussion from morning regarding devtool reset -r option **** ENDING LOGGING AT Fri Feb 08 02:59:56 2019