**** BEGIN LOGGING AT Thu Aug 08 02:59:57 2019 Aug 08 07:12:07 behanw: ping concerning streams Aug 08 07:12:29 g'morning! What exactly is the difference between "package" and "recipe" in yocto? (How) can one define multiple packages in a single recipe? Aug 08 07:14:36 jmiehe: a single recipe can (and in most cases does) produce a multitude of (hopefully related) packages. Aug 08 07:48:56 hi guys... I have a yocto build. I tried to build the sdk & esdk... well they didn't build without some changes in poky/classes/populate_sdk_ext.bbclass Aug 08 07:49:07 I found patches online Aug 08 07:49:34 but I don't want to update the poky layer at the moment Aug 08 07:49:57 can I somehow patch poky from my custom meta-mylayer? Aug 08 07:50:15 wooosaiii: depends on the form of the "paches" Aug 08 07:51:03 https://patchwork.openembedded.org/patch/155533/ Aug 08 07:51:08 this one for example Aug 08 07:51:35 nope, you can't apply this from another layer Aug 08 07:51:43 bummer :D Aug 08 07:52:25 is there any good practice on such case? Aug 08 07:52:35 wooosaiii: updating poky :) Aug 08 07:52:48 heheh :D Aug 08 07:52:54 ok Aug 08 07:54:29 LetoThe2nd: what about this technique? Aug 08 07:54:29 https://stackoverflow.com/questions/51002891/overwriting-yocto-classes-through-meta-layer Aug 08 07:55:45 wooosaiii: it works, but is highly fragile. and will lead to hard-to-trace errors when somebody tries to reproduce your build. hence, i discourage it. Aug 08 07:56:13 LetoThe2nd: I agree... that this is somehow bad approach... Aug 08 09:19:20 can I enforce a specific version for IMAGE_INSTALL? or for `bitbake `? Aug 08 09:19:51 jmiehe: you can, given the prerequisite that a recipe providing the desired version exists. Aug 08 09:20:12 jmiehe: in that case, PREFERRED_VERSION (as to be found in the manual) Aug 08 09:46:28 hello folks Aug 08 09:47:26 the qt5 recipes install the qmake, moc etc native tools to recipe-sysroot-native . is this the correct way? must recipe-sysroot/usr/bin not contain binaries that are used at build time only? Aug 08 09:48:08 it complicates our make scripts, because we use the QT5PATH variable for both the target-library .so files and headers in recipe-sysroot, and for the builtime-native binaries like qmake and moc Aug 08 09:48:20 nor we require a QT5TOOLSPATH or something for the latter Aug 08 09:49:57 litb: recipe-sysroot only contains target libs/binaries Aug 08 09:50:26 litb: in the general case you can't run target binaries, only native ones Aug 08 10:15:44 litb: having build tools and runtime libraries in different trees is generally going to be a thing with any sane cross-compiling setup, not just with yocto Aug 08 10:27:01 BCMM, hm, i see Aug 08 10:27:42 BCMM, I guess this is the reason why some packages need to be compiled for the build host, when cross compiling Aug 08 10:27:49 assumptions that make perfect sense for native builds but come back and bite you when cross compiling are pretty common in build systems; and this might be one of them Aug 08 10:28:00 to get native binaries for the "foo-config" thingies Aug 08 10:28:25 (actually even assumptions that don't make sense when you're packaging are fairly common) Aug 08 10:29:00 but, I don't understand it completely. the Qt .pc files that are compiled for the build host still need to report paths of the compilation that was done for the target Aug 08 10:29:49 when those two compilations are completely separate, I can't imagine how this works. so, I think this needs some support from the configure/makefiles in order to get a working result? Aug 08 10:46:32 Hello all, someone here could give me some advice to fix this kind of issue (https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-December/004127.html) witch meta-xilinx 2019.1 revision ? I have propably missed something but i don't know what :S Aug 08 10:50:22 did you try adding the line manju mentioned to your local.conf and see if it helped? Aug 08 12:13:47 I have built extensible SDK... now I have installed it and tried to run devtool --help Aug 08 12:13:58 it fails with No such file or directory Aug 08 12:14:06 after investigating a bit further Aug 08 12:14:34 I have checked with "which devtool" where it is located Aug 08 12:14:46 and inspected the python file with vi Aug 08 12:15:19 i changed "#!/usr/bin/env python3" to "#!/usr/bin/python3" Aug 08 12:15:40 and then I can run devtool --help.... Aug 08 12:15:47 is this known bug or? Aug 08 12:16:36 wooosaiii: what distro are you running? Aug 08 12:16:47 wooosaiii: that should work fine on most Aug 08 12:17:17 Ubuntu 18 Aug 08 12:17:31 but I have tried the same with extensible container Aug 08 12:17:35 which is Ubuntu 16 Aug 08 12:17:38 same error Aug 08 12:18:32 You don't get a python prompt if you do this from the command line? /usr/bin/env python3 Aug 08 12:19:01 I do on Arch Linux and Debian. Aug 08 12:19:19 I do get it... Aug 08 12:19:32 this is really strange error Aug 08 12:19:39 yeah. bizarre Aug 08 12:21:12 If you just make a script with: Aug 08 12:21:13 #!/usr/bin/env python3 Aug 08 12:21:17 print("test") Aug 08 12:21:23 Crofton|work Yep but didn't help :S Aug 08 12:21:41 it doesn't work out of the box ? same issue with 2018.3 Aug 08 12:21:50 so it's probably in my configuration Aug 08 12:21:51 wooosaiii: then chmod 755 script.py; ./script.py does it work? Aug 08 12:22:34 ammm Aug 08 12:22:53 but does yocto run my machine native python3 or the one from $OECORE_NATIVE_SYSROOT Aug 08 12:22:55 ? Aug 08 12:23:28 depends :) Aug 08 12:23:53 devtool should run with the python from the machine Aug 08 12:23:59 IFAIK Aug 08 12:27:49 PinkSnake, email the meta-xilinx list with details Aug 08 12:28:18 Crofton|work ok thx ;) Aug 08 13:20:46 RP: Ya, that is unsuprising. I suspect we'll need a more "industrial strength" server to handle that Aug 08 13:26:25 JPEW: you'd kind of have hoped it would have been simple enough to work even for this though :/ Aug 08 13:31:38 RP: Do you happen to know where the bottleneck is? Aug 08 13:34:39 Hello people Aug 08 13:34:45 I'm trying to do some changes at the kernel bbclass file. Aug 08 13:34:52 So far I already have my own layer where I'm placing all the changes for the board where I'm working(bb and bbappend files). Aug 08 13:34:58 I thought that for the bbclass I should proceed on the sme way, but, when I do bitbake my image, it don't use my bbclass file. Aug 08 13:35:05 Is that the rigth way to do that? Aug 08 13:36:45 BobPungartnik: bbclasses cannot be appended, and usually should be version independent. its rather uncommon that you need to touch them for kernel development Aug 08 13:45:42 it's mainly cosmetic, for this board, they want build user, build host, and some other items set for the company reference. Aug 08 13:45:44 my idea was to place all in one layer for this board. Aug 08 13:49:29 is it possible that I can tell bitbake that all DEPENDS and all RDEPENDS of a layer's recipes must be whitelisted somewhere? Aug 08 13:49:55 I want to prevent that our proprietary layer depends on opensource software without having whitelisted them somewhere Aug 08 13:51:48 Have I to create an user to submit a layer to layers.openembedded.org? Aug 08 13:52:09 probably Aug 08 13:55:20 JPEW: I'm not sure. Aug 08 14:04:29 * RP can't reproduce a hash equiv build failure from the autobuilder :( Aug 08 14:20:42 JPEW: an interesting dilemma. bitbake starts, sees valid sstate and tuns those tasks. Other tasks are run, equiv is noticed, the sstate hashes of the tasks which it already pulled from sstate change. What should it do? Aug 08 14:22:25 RP: Ya... the hash equiv database is currently a little more tightly coupled to the sstate cache contents that would be ideal. Aug 08 14:23:16 One option would be to have the server return a list of compatible hashes instead of a single one and bitbake can decide then see the current hash is already valid and do nothing Aug 08 14:23:39 Argh, typing is hard. Need more coffee Aug 08 14:24:48 JPEW: can we assume that since it already had one, that one is still valid? Aug 08 14:25:17 RP: Ya that's also what I was thinking.... only allow setsecene to be run once for any given task Aug 08 14:25:19 or might that not be true. I can't quite decide Aug 08 14:27:10 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/49/builds/907/steps/8/logs/step1b makes interesting reading for the number of times packagegroup-core-lsb reruns Aug 08 14:27:18 or it thinks about it anyway Aug 08 14:34:03 YP bug triage started Aug 08 15:33:05 RP: I suppose I would expect the packagegroup to be updated frequently... each time a dependent package's unihash changed. Aug 08 15:33:23 hmm... trying to run toaster in analysis mode with a python venv Aug 08 15:33:29 Ideally it wouldn't be actually run several times though Aug 08 15:34:06 JPEW: the question is whether its ok after any sstate runs? Aug 08 15:34:06 but when I run toaster with the venv, and in the other terminal start a bitbake build, and then go to http://localhost:8000/toastergui/landing/ , it just says "This is toaster", and doesn't show anything about the build Aug 08 15:34:12 what am I doing wrong? Aug 08 15:35:10 do I have to run bitbake in the same shell that i ran "source toaster start" with? i'm unsure how to do that, because the venv is setup there, and I can't have it active when I run bitbake, I think Aug 08 15:46:13 RP: What if setscene tasks also reported to the hash server and updated unihash? Aug 08 15:47:27 That would unify the hashes even for the case where an sstate object hadn't been seen before.... I suppose the weird part there is what do you do with the sstate file.... rename it? Aug 08 15:56:30 one question: the sstate cache only caches packages, I'm told Aug 08 15:56:37 are .o files also cached and reused? Aug 08 15:57:05 there doesn't seem to be a ccache used Aug 08 15:57:34 litb: It caches more than packages, but in general I don't think .o files would be cached.... More accurately, sstate caches the output from specific tasks Aug 08 16:54:29 hmm, would be nice if the layer index supported search result sorting. sort machines by layer name, or last update, or whatever.. or at the least be able to easily view the latest added layers, to see what's shown up since you were there last Aug 08 16:54:45 ah, can examine the change history. a bit verbose, but it's something Aug 08 16:55:48 JPEW: right, I'm not sure :/ Aug 08 22:08:49 JPEW: I just had a look at netstat on the machine running hashserv. 16,000 connections open Aug 08 22:11:49 JPEW: its handling about 300 queries a second and held about 16,000 open for around 6 minutes Aug 08 22:13:25 although I guess I can't tell how many were timeouts and how many were handled Aug 08 23:16:03 hmm, major bug in the new runqueue code :/ Aug 08 23:16:06 * RP sleeps on it Aug 09 02:04:00 New news from stackoverflow: Change $TMPDIR in yocto **** ENDING LOGGING AT Fri Aug 09 02:59:57 2019