**** BEGIN LOGGING AT Wed May 24 03:00:05 2017 May 24 05:54:57 morning all May 24 06:37:48 Morning. Is it possible to execute commands like "mysql -u root -p password < create_tables.sql" in a post build script or something like that? May 24 06:57:55 Good morning ! May 24 07:00:51 Hello! How can I make my own custom module to load automatically at boot ? I've add it in KERNEL_MODULE_AUTOLOAD, but it's not working. Thanks for the help! May 24 07:38:24 Starting with this: https://github.com/rossburton/customdistro, I have added this line to meta-custom/recipes-example/images/customimage.bb So, why doesn't it show up in the full distro image ? May 24 07:41:57 Hello, I want to add a step in my recipe before configure May 24 07:42:21 the command was do_configure_before(){ .... } or? And where i can find the documentation for the recipes? May 24 07:44:54 Never mind. The application is being built as "helloworld" not "example" May 24 07:45:59 What package do I need to install rpms on target? May 24 07:48:59 Smitty_ : Don't you get an error? May 24 07:49:14 I didn't see any error May 24 07:49:15 Smitty_ : Like "example" couldn't be parsed or whatever May 24 07:50:02 Smitty_ : Ok have you tried with IMAGE_INSTALL_append = May 24 07:51:25 Well, it's installing the binary with the name helloworld. I was expecting to find a binary named example. It turns out I didn't need to add the EXTRA_IMAGE_INSTALL. When I remove it, the binary is installed anyway May 24 07:52:58 @Smitty example_0.1.bb --> install -m 0755 helloworld ${D}${bindir} May 24 07:53:17 I don't see anyting which indicates that the helloworld app *should* be installed. I guess it's automagic May 24 07:53:46 @Smitty take a look to the recipe in install function May 24 07:54:38 Still *extremely* fussy over which file is used for which type of information. Seems like random info scattered across at least 4 files just for my trivial example May 24 07:56:29 So, that file says: if this particular binary target is supposed to be installed, install it like this. BUT, that doesn't control whether the binary target gets installed May 24 07:56:48 So, how do I control whether - *not* how May 24 07:59:28 Smitty_ : Look to the recipe May 24 07:59:33 Smitty_ : And see where it is installed May 24 07:59:41 @Smitty nothing is supposed, you have a just a look to the recipe May 24 08:00:24 I am supposed to be able to control *if* as well as *how* the target binary gets installed. Where do I do that ? May 24 08:00:47 @Smitty in install function May 24 08:01:18 @Smitty i don't understand what are you looking for, https://github.com/rossburton/customdistro/blob/master/meta-custom/recipes-example/example/example_0.1.bb May 24 08:01:55 @Smitty you a compile function to build the binary and an install function to deploy it in the system May 24 08:02:00 The binary target recipe describes *how* to build the binary target, *how* to install it, *how* to do things. But, the other aspect of the problem is *whether* the target binary *should* be installed or not May 24 08:02:47 Smitty_ : install -m 0755 helloworld ${D}${bindir} May 24 08:02:53 Smitty_ : Have you checked there? May 24 08:03:05 That describes *how* not *if* May 24 08:04:06 Smitty_ : ? May 24 08:04:14 Smitty_ : Have you checked in /usr/bin/ May 24 08:04:29 Yes, and the helloworld binary is present May 24 08:04:37 Smitty_ : So no problem May 24 08:04:38 Now, what if I don't want it to be there May 24 08:04:43 Smitty_ : You change the recipe May 24 08:05:21 Smitty_ : The best way is to do a .bbappend May 24 08:05:27 Defintiely not, I would possibly not include the recipe in the layer, or maybe not include the layer in the distro, but the recipe is totally correct May 24 08:05:46 Smitty_ : So if the recipe is totally correct you let in /usr/bin May 24 08:05:56 Smitty_ : because the recipe is " i would like to compile a code and put in /usr/bin " May 24 08:06:04 Smitty_ : If you are okay with that, so nothing to change May 24 08:06:13 Smitty_ : If you're not happyt with /usr/bin May 24 08:06:42 Smitty_ : You have to change the recipe, but not directly. May 24 08:08:04 I want to control whether or not that particular binary target (a sub-component of the layer) gets installed. Example, instead of being a executable "hello world" it's actually a static library which some other component in my layer depends upon. So, it has to be built, but not installed, or maybe it only gets installed in the SDK and the the OS May 24 08:08:21 not the OS May 24 08:08:40 Smitty_ : Ok so your unhappy with the recipe. May 24 08:08:45 No May 24 08:08:50 Smitty_ : You can suspect changes. May 24 08:09:24 The recipe contains all the instructions for *HOW* to build, install, whatever, but it does not control *IF* May 24 08:09:43 Smitty_ : If you parse the recipe, it will install May 24 08:09:53 This is absolutely fundamental to how Yocto is designed May 24 08:10:17 Smitty_ : Because the recipe is : " I would like to compile it, and install into the target in /usr/bin " May 24 08:10:52 Smitty_ : the ${D} means the target directory if i remember May 24 08:12:37 but each of those "actions" compile, install, whatever are essentially optional. Just including a layer that includes a recipe to build a binary target does not necessarily mean I want that binary target installed in the OS, the SDK, whatever. Something is controlling the circumstances under which that binary targets' do_install gets called May 24 08:13:36 Smitty_ : right May 24 08:13:59 And that someting is what ? May 24 08:14:34 How would I say, for example, build the binary target, but only install it in the SDK, not in the OS May 24 08:15:31 Smitty_ : the SDK guide maybe May 24 08:18:16 Smitty_ : You would like to add files in the native sysroots for example May 24 08:18:30 yep May 24 08:19:24 or, maybe, for whatever reason, suppress one file from the SDK but let that file show up in the OS image, or vice-versa May 24 08:19:33 Smitty_ : I'm not at ease with it, as i'm new in yocto, you should consider looking to BBCLASSEXTEND May 24 08:20:56 Smitty_ : http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html May 24 08:21:07 Smitty_ : 7.77. May 24 08:21:37 Smitty_ : Look to 7.78 also May 24 08:24:48 If you consider changing your job, let me know. I could be happy to be hired. Ahahah May 24 08:25:14 How i can add a custom job before do_configure May 24 08:25:23 i know the function do_configure_append May 24 08:25:34 it is possible to write do_configure_before May 24 08:26:38 I'm not at ease with it at all - becuase looking at all the different places for configuration, whether it be a single recipe for a hello world app which very strangely also includes a directory "images" which contains customimage.bb which does nothing but inherit from core-image, the layer configuration including a "distro" folder which doesn't appear to do anythgin at all, etc, etc, there's just too many places to look at to unders May 24 08:27:06 Smitty_ : ok. May 24 08:29:53 Hunk : In a bbappend file, you can tell that you would like to do another task May 24 08:30:21 Hunk : like addtask your_task after the_task_you_want before the_task_you_want May 24 08:31:49 Hunk : 3.5.1. Promoting a Function to a Task https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html May 24 08:32:44 I'll ask again: is there some guidance as to which configuration items are placed in which .conf files ? Right now, I'm not seeing a pattern May 24 08:33:04 Smitty_ : The best is to check the guides May 24 08:33:14 Smitty_ : there is one guide very nice that tell you what everything does May 24 08:34:03 yep, that's exactly my question - where in the "guide" is there "guidance" for this issue ? Because I've searched, and can't find it May 24 08:34:46 Smitty_ : Ok i will cherch for you May 24 08:36:24 Smitty_ : In that guide : http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#extendpoky May 24 08:36:30 Smitty_ : you have 5 - Common Tasks May 24 08:36:48 Smitty_ : it will help you of doing simple tasks May 24 08:37:51 Smitty_ : In chapter 4 May 24 08:37:57 Smitty_ : You have the development models May 24 08:38:06 ok thank you May 24 08:38:13 i want to write some output message as log files May 24 08:38:17 as output May 24 08:38:24 bb.plain isn't working May 24 08:38:29 what is the best way for do this May 24 08:38:43 Hunk : you mean in the host? May 24 08:39:33 Hunk : What did you expect as output message as log files? May 24 08:40:36 Hunk : I don't really know what you want but maybe you shuold consider doing some python functions witch print some messages. I'm not familiar if there is a "pre-buuilt" way of doing some log files. May 24 08:42:03 i did May 24 08:42:17 do_configure_prepend May 24 08:42:20 () { May 24 08:42:32 and i wanted to add there a print that i can see it inside the build process May 24 08:44:31 Hunk : and bb.plain doesn't work right? May 24 08:44:51 yes May 24 08:44:56 Hunk : I've checked that you can log with python. My bad i didn't understand initially when you say bb.plain May 24 08:44:56 it doesn't work May 24 08:46:02 sry i didn't write my problem well May 24 08:46:27 Hunk : No it's because i'm not familiar with that May 24 08:47:42 Hunk : can you pastebin your recipe? May 24 08:47:47 Hunk : and .bbappend May 24 08:47:58 Heya. Is it possible to execute commands like "mysql -u root -p password < create_tables.sql" in a post build script or something like that? May 24 08:50:24 Hunk : you can even try the bash way May 24 09:04:35 @rj_ ROOTFS_POSTPROCESS_COMMAND += " *shell_command*;" at the end of an image recipe. May 24 09:08:40 ChrsyD May 24 09:08:44 I found it May 24 09:08:46 bb.warn May 24 09:08:48 PinkSnake: So in my example that would be "ROOTFS_POSTPROCESS_COMMAND += " mysql -u root -p < create_tables.sql;" ? May 24 09:08:50 bb.error May 24 09:08:52 bb.fatal May 24 09:08:55 bb.plain May 24 09:09:02 bb.note not plain May 24 09:12:53 rj_ i think you have to write a shell function, i will past an example ;) May 24 09:13:35 PinkSnake: That would be nice ^^ May 24 09:15:44 Hunk : yeah here : http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#recipe-logging-mechanisms May 24 09:16:23 rj_ https://pastebin.com/r5PMDBrB May 24 09:16:48 rj_ it's an example paste in my-image.bb to set root as sshusers May 24 09:17:03 Hunk : it tried it,it works May 24 09:17:08 Hunk : have put a bb.plain May 24 09:17:38 PinkSnake: I see, alright thanks! I'll try it out for my case ^^ May 24 09:18:29 Hunk : I have a append on a .bbappend May 24 09:18:36 Hunk : i put as a first line bb.plain May 24 09:18:51 rj_ with pleasure ;) May 24 09:19:01 Hunk : python do_env_append_mx6() { bb.plain("test") } May 24 09:43:06 Is there a way to make yocto keep the configured kernel source? May 24 09:44:25 rj_ yep May 24 09:44:34 rj_ i going to paste ;) May 24 09:47:26 rj_ it's maybe not a proper solution but it works -> https://pastebin.com/dkJBieFD May 24 09:47:26 PinkSnake: For what i need it for thats all it has to do, work ^^ May 24 09:47:51 PinkSnake: Will that make the kernel source available when i use the image? May 24 09:48:17 rj_ what ? what ? i didn't understand May 24 09:48:23 PinkSnake: Because from what i see, the kernel source should be somewhere in /lib/modules/(uname -r)/kernel right? May 24 09:48:50 rj_ ha ok you want to sav all your sources ? May 24 09:49:03 rj_ and not .config file, sry my mistake May 24 09:49:20 @rj_ why don't save only the .config file ? May 24 09:49:32 PinkSnake: Yea, i need them to compile a package after installing the image in my virtual machine May 24 09:50:44 rj_ you mean a kernel module ? May 24 09:51:36 PinkSnake: I'm not sure tbh, all it says is: "configure: error: Failed to find Linux sources. Use --with-linux-dir!" May 24 09:51:53 rj_ : have you the recipe? May 24 09:52:24 ChrysD: It's not really a recipe this time, im compiling it after building, when i install the image in a virtual machine May 24 09:52:54 ChrysD: But it seems the Linux sources are not installed in the image May 24 09:53:44 rj_ : But did you realize it "once" you have added something in your project or have you all the time get that problem? May 24 09:53:58 Why is bitbake build so many new components when I build the SDK image for my config. I have already build the OS image. Why would it need to do anything other than package up what it already built when it did that ? May 24 09:54:17 @rj_ you can also build kernel modules http://www.yoctoproject.org/docs/2.3/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules May 24 09:54:22 ChrysD: What do you mean by that exactly? May 24 09:54:34 rj_ : I mean, did you get that message all the time? May 24 09:54:42 ChrysD: yep May 24 09:54:48 @Smitty i think yocot needs to build several package to create the toolchain May 24 09:55:16 ChrysD: Everytime i run the configure script it gives this error May 24 09:55:17 The toolchain is built before the rest of the components in my OS IMage, otherwise it couldn't build them May 24 09:55:32 Smitty_: SDK has a canadian cross compiler May 24 09:55:46 rj_ : which? May 24 09:57:04 ChrysD: the configure script provided by the package May 24 09:57:26 By default ? How many people need that ? May 24 09:58:39 @rj_ could you share the package ? May 24 09:58:42 ChrysD: The script looks for /lib/modules/$(version)/build May 24 09:59:10 PinkSnake: should be this one: http://etherlab.org/download/ethercat/ethercat-1.5.2.tar.bz2 May 24 09:59:22 Smitty_: depends, there are lots of cases where the SDK platform is very different from the build host. e.g. 64bit/32bit May 24 09:59:42 What's the target for that cross compiler ? The target OS ? May 24 10:00:00 @rj i mean the recipe :) May 24 10:00:10 @rj_ i mean the recipe :) May 24 10:00:23 PinkSnake: As stated before, i'm not using a recipe May 24 10:00:43 Smitty_: well it will build a HOST->SDK compiler and a SDK->TARGET compiler which is shipped in the SDK May 24 10:00:44 @rj_ ok i will take look, but after lunch :D May 24 10:00:50 rj_ : Me too ahah May 24 10:00:52 PinkSnake: I build a yocto image, installed that in my virtualbox, and im installing it by hand May 24 10:01:14 PinkSnake: Because i can't seem to get that package working with a recipe in any way May 24 10:01:17 Smitty_: sorry, for clarity in my previous message the HOST->SDK compiler is not shipped May 24 10:01:17 rj_ : have you checked for example in the sysroots of your target that you have everything? May 24 10:01:20 @rj_ ok but you can also create the recipe to download the package, build it and depoy no ? May 24 10:01:33 PinkSnake: If only it would be that easy ;-; May 24 10:02:02 PinkSnake: I've been trying to get that package to work for the last 3 months May 24 10:02:13 rj_ : it could be so nice to see which package is requesting the missing file. May 24 10:02:25 rj_ : and also "which" missing file May 24 10:03:18 ChrysD: i know what files are missing tho, they are located in "/home/viro/poky/build/tmp/work-shared/genericx86-64/kernel-build-artifacts" May 24 10:03:34 rj_ : i mean, in the sysroots May 24 10:03:41 rj_ : not in the workdir May 24 10:03:57 rj_ : I have to go sorry May 24 10:04:04 ChrysD: Np ^^ May 24 10:04:33 @rj_ https://pastebin.com/HwTSvG1R May 24 10:05:50 When I build my target OS (without SDK) bitbake will first (probably always?) construct a HOST->TARGET toolchain. Now, when I want an SDK, I might want a HOST->TARGET and/or a TARGET->TARGET (or potentially a TARGET->OTHER_TARGET). The Target->Target is the Canadian Cross ?? How do I suppress that being built ? May 24 10:06:44 PinkSnake: Yea i tried installing it by recipe, with this: https://pastebin.com/sSj0Ftn1 May 24 10:07:35 @rj_ do you have an error log ? May 24 10:07:38 PinkSnake: But it keeps giving errors, either libtool cant find some folder calle ".libs" or the header "stdlib.h" can't be found May 24 10:10:11 Smitty_: you are probably not after the SDK, you should first determine if that is what you need (see http://www.yoctoproject.org/docs/2.3/sdk-manual/sdk-manual.html#sdk-extensible-sdk-intro) May 24 10:10:16 PinkSnake: This is the latest log: https://pastebin.com/S6KhSXaJ May 24 10:11:44 Smitty_: regards the compilers for the SDK, the canadian cross is the HOST building a compiler that runs on SDK which compiles for the TARGET. TARGET->TARGET is different again May 24 10:12:36 I already know I want to build an SDK, but I don't think I will need or want a TARGET->ANYTHING toolchain for any value of ANYTHING. May 24 10:13:23 Smitty_: thats not what the SDK builds though May 24 10:14:12 What ? doesn't bitbake have to construct the HOST->TARGET toolchain before it does anything else related to constructing the target OS ? May 24 10:15:01 Smitty_: now your just confusing yourself. You said you didn't want a TARGET->* compiler... that is not the same as a HOST->TARGET compiler... May 24 10:16:03 I want to ship a toolchian which allows other developers to construct applications which can run on TARGET. And, that toolchain will only run on HOST (which happens to be the machine I am build on) May 24 10:16:22 That's the SDK - isn't it ? May 24 10:16:39 yes May 24 10:16:51 bitbake myimage -c populate_sdk, will generate the SDK for whatever is in myimage May 24 10:17:18 So, why would building the SDK, also construct a Canadian Cross wwhich would then allow TARGET->SOMETHING ? May 24 10:17:50 most likely because building gcc is "fun" and "interesting" May 24 10:18:04 and always involves more steps than you'd like May 24 10:18:31 How do I suppress that TARGET->ANYTHING toolchain ? I don't want that shipping out anywhere May 24 10:18:43 Smitty_: you didn't read my original message... it builds a compiler that runs on the "SDK" system which is essentially the same as your build host by default. It does not make a compiler that runs on your target May 24 10:23:02 Smitty_: the image wont contain a compiler unless you put it in, and the sdk will only contain a cross for your target May 24 10:25:47 rburton: Is there any way to get "/lib/modules/(uname -r)/build" linux sources installed on a yocto build? May 24 10:26:48 rj_: iirc, the package is kernel-sources. May 24 10:28:27 rburton: Should i add that to my image.bb? Cause nothing seems to provide that package May 24 10:31:04 a five second grep tells me that kernel-devsrc contains the kernel sources, if that's what you want May 24 10:49:34 rj_ : Something new? May 24 10:52:41 @rj_ May 24 10:52:42 ../x86_64-pc-linux-gnu-libtool: line 7549: cd: .libs: No such file or directory May 24 10:53:28 @rj_ maybe you can try to bluid sdk and compile inside no ? May 24 11:03:30 rburton: I found the same thing yea, build is just done May 24 11:03:47 PinkSnake: The thing is, that .libs directory exists... May 24 11:07:47 @rj_ arf :S maybe you can try with -c devshell option to take a look insid... May 24 11:19:28 @rj_ in my opinion you should maybe to try --> inherit autotools + remove do_compile() & do_install() in .bb May 24 11:42:55 PinkSnake: Tried that, doesn't work sadly :( May 24 11:55:54 Back from lunch - continuing the conversation about SDK May 24 11:59:10 So, my question is: I have already built the OS image. Doing so requires building of a HOST->TARGET toolchain and also ends up retrieving and building what could be considered the sysroots (let's call the toolchain and sysroots combination SDK). Now, since the OS iimage required build the SDK, why would then issuing "bitbake -c populate_SDK customimage" have to do any more than just packaging of the already bult components that ma May 24 12:05:45 Smitty_: because it builds another cross toolchain that runs on the SDK machine, see SDKMACHINE -> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-SDKMACHINE. And the dependency for that is set here: http://git.openembedded.org/openembedded-core/tree/meta/classes/populate_sdk_base.bbclass#n35 May 24 12:06:30 But, by default the SDKMACHINE is the build host that produced the OS Image May 24 12:07:00 or, is it not ? May 24 12:07:08 Smitty_: SDKMACHINE may be the same architecture but it is not the same as the build host. This is for a number of reasons most due to the need for a portable toolchain May 24 12:08:43 not following how that works. How would the SDKMACHINE be the same arch. of the host, but not be the same as the build host ? May 24 12:10:33 Smitty_: think host dependencies, also consider that SDKMACHINE can be set to targets other than the host e.g. windows May 24 12:10:40 Smitty_: Your host could be x86_64, your SDKMACHINE could be i386, your target could be ARM May 24 12:10:50 hi, what is the best approach to remove a package if a new one is installed? May 24 12:11:04 RREPLACE or something like that instead of manual rms in a postinst function? May 24 12:11:25 That's less common now that everybody has x86_64 development machines, but it used to be a thing. May 24 12:12:05 lpapp: RREPLACE and RCONFLICTS maybe? Or, having the same name. May 24 12:12:45 neverpanic: yep, the mega manual says so as well after reading RREPLACE May 24 12:13:23 hopefully, the new package will install fine even if the "old" is no longer installed May 24 12:13:40 i.e. opkg will not warn me about a replace/conflict if it is not there, but it removes it if it is there. May 24 12:13:57 That's the only sane way of implementing this, so I would assume that's the case. May 24 12:15:29 I wonder whether I also need rprovides... probably not as the new one is not replacing any files from the old one? May 24 12:15:58 @rj_ save issue ? .libs ? May 24 12:16:45 So, the default behavior is to build a toolchain that is different (actual different binary components) than what was used to build the components of the OS image ? May 24 12:26:44 * kanavin has parallelized rpm generation - glibc-locale rpm making goes down to 25 seconds from over 200 May 24 12:27:44 kanavin : time to get a ride in italy ahahah May 24 12:27:51 kanavin, now the other package managers... May 24 12:28:29 ant_work : ahah, i guess he is so happy to have done that, and now instead of letting him happy of achieving that, you tell him that it was only the beggining ahahah May 24 12:28:56 fair, isn't? :) May 24 12:29:15 hi folks, why would bitbake hang on an idle system? stuck at 99% after trying "bitbake rpi-test-image" May 24 12:29:21 ant_work: RP is doing those :) May 24 12:30:17 surely many have hopes for opkg May 24 12:34:29 Smitty_: Yes, because your host toolchain may just not work in your SDK May 24 12:34:53 How can that be ? May 24 12:36:25 Smitty_: Again, your build machine may be x86_64, the target architecture of your SDK may be i686 May 24 12:36:49 So of course, your x86_64 -> arm toolchain will not work on an i686 machine May 24 12:37:24 neverpanic : is that what we call canadian cross compilation? May 24 12:37:30 Let's be clear. The first step to build an OS Image is to build a toolchain. Let's call that toolchainA. Now toolchainA is used to build the rest of what makes up the OS Image. When I instruct bitbake to create an SDK, it had better (by default) bundle up toolchainA and headers and libd (sysroots) for the OS Image I just built, or the default doesn't make sense May 24 12:38:04 Smitty_: No, it doesn't. That assumes that your build machine architecture is the same as the architecture you want to run your SDK on May 24 12:38:11 ChrysD: Yes May 24 12:38:17 By Default - May 24 12:38:29 Why would I expect the SDK to run on somehting different ? May 24 12:39:04 And btw, even if your host architecture equals the SDK architecture, libraries might be built with different feature sets for build machine and SDK May 24 12:39:35 Right, that's the toolchain and sysroots used for building the OS Image May 24 12:39:41 E.g., your SDK might contain an svn binary that supports storing passwords in system keychains, while your host svn binary used by bitbake doesn't May 24 12:52:43 ant_work: rpm was the last one left, RP did opkg/dpkg already May 24 12:52:54 kanavin: *awesome* improvement May 24 12:53:03 great, thanks May 24 12:54:30 rburton: thanks, but I have bad(ish) news, it's racy over shared data, so that needs to be sorted May 24 12:54:46 Smitty_: a SDK is packaged and configured differently to the cross tooling used directly. details, dont worry about it. May 24 12:55:10 rburton: glibc-locale works perfectly each time, but gettext crashes (or not) May 24 13:20:59 That's not a simple detail to ignore. But, OK. I'm learning to ignore almost everything May 24 13:21:08 Hello May 24 13:22:05 I am working with repo manifest and I'd like to include some repos or others depending on an external variable, would that be possible to do in the manifest xml? May 24 13:22:42 I do not think xml allows conditionals May 24 13:22:51 or do you have better way to do that? May 24 13:23:23 Smitty_: You're getting a toolchain that will work with your target system if you create an SDK. May 24 13:23:30 nos__ : XSLT ? May 24 13:23:39 I think you *can* actually ignore that it's not the exact same toolchain your host used. May 24 13:24:31 ChrysD: sorry I am not too fond on documentation parsers, I'll look into that, thanks May 24 13:24:38 I thought I was getting a toolchain that could produce binaries for my target system, but ran on the same machine that I build the target system on. May 24 13:25:46 nos__ : Have done that to school, i even don't know if it could help you but I know that i could do some kind of conditionals May 24 13:25:52 Smitty_: feel free to compare cross.bbclass with nativesdk.bbclass, and the relocation logic, and the various gcc/binutils recipes. or just admit that you want to keep your sanity :) May 24 13:28:54 I guess I'm not used to having to consider such things. I've cross compiled before, of course, and built up a toolchian (like in Linux From Scratch). But, to put together a build environment that gives such incredible versatility that it can build a OS that can run a toolchain targeting another OS is mental ! May 24 13:30:43 Smitty_ : and needed in certain case May 24 13:38:12 rburton: looks like the libgcrypt vs pkgconfig debacle rears its head again :( May 24 13:38:49 yeah May 24 13:39:07 i do want to change binconfig-disabled so it destroys the scripts in the sysroot but writes the proper scripts to the packages for on-target use May 24 13:39:30 just wish upstream wouldnt be so annoying about pkgconfig May 24 13:40:39 what is bigbuckbunny-480p and why does bitbake tell me I need it? May 24 13:41:02 berndhs: its a video file for testing and you only need it if you tried to build a recipe that ships it May 24 13:41:03 berndhs : a video May 24 13:41:11 rburton: could always just replace the scripts with scripts that just run pkgconfig under the hood... no one will notice im sure ;) May 24 13:41:15 there's a recipe in meta-multimedia i believe May 24 13:41:25 nrossi: yeah almost done that before May 24 13:42:09 berndhs i have it on : /meta-openembedded/meta-multimedia/recipes-multimedia/sample-content$ May 24 13:42:12 hmm so I don't really really need it, its just to verify that other stuff is working, it seems May 24 13:48:37 berndhs : maybe with bitbake -e you could check which package RDEPENDS on it. May 24 14:08:48 khem: you around? May 24 14:46:25 lamego: yes May 24 14:53:32 Hello May 24 14:53:37 khem: Hi. I prepared a patch for bug 8673, dealing with distutils3 packages being installed through an .egg file. As I understand, --single-version-externally-managed does handle this, but was removed some time ago. Do you know what was the reason for this? May 24 14:53:38 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=8673 enhancement, Medium+, 2.4 M1, jose.a.lamego, IN PROGRESS IMPLEMENTATION , distutils3 packages installed via an egg file cannot be imported by the python3 interpreter May 24 14:54:44 khem: * removed from setuptools May 24 14:54:48 I'm building a yocto sdk. It worked fine before, I made a bbappend to one recipe, then it wouldn't install anymore. I reverted to stock, same error. May 24 14:54:49 Setting it up...ls: cannot access '/opt/poky/2.2.1/environment-setup-*': No such file or directory May 24 14:55:13 it writes the files fine, but doesn't seem to write the env setup script May 24 14:55:29 google doesn't have many answers for this May 24 14:56:29 hi, i cloned git://git.yoctoproject.org/poky.git , then i changed into poky dir and cloned git://git.yoctoproject.org/meta-raspberrypi , then i did "source oe-init-build-env", changed into /build, set MACHINE=raspberrypi in conf/local.conf , then run "bitbake rpi-hwup-image", now it returns alot of errors? what do i wrong May 24 14:57:12 vm_ did you edit bblayers.conf to include meta-raspberrypi? May 24 14:58:47 yes, i did, bitbake-layers add-layer ../meta-raspberrypi May 24 14:59:06 Impossible to guess without logs May 24 14:59:40 where is the rpi-hwup-image recipe May 24 15:00:38 found it May 24 15:01:54 anyone know about my issue installing the sdk? May 24 15:02:04 Setting it up...ls: cannot access '/opt/poky/2.2.1/environment-setup-*': No such file or directory May 24 15:06:14 do i need to setup all vars in conf/local.conf by myself? KERNEL_IMAGETYPE, IMAGE_FSTYPES and so on? May 24 15:07:09 or is there anywhere a pre-configured raspberry local.conf? May 24 15:07:46 rpi-hwup-image should have all the preconfigured stuff to run May 24 15:08:59 the rpi-hwup-image.bb only uses git://git.yoctoproject.org/meta-raspberrypi May 24 15:09:18 sorry ,wrong copy/paste May 24 15:09:38 but it only includes core-image-minimal.bb May 24 15:14:18 pastebin.com/HYMjFpRT is the error output May 24 15:14:30 it seemed to miss var values May 24 15:16:46 is meta-raspberrypi on morty branch? May 24 15:18:12 thats it, thanks alot May 24 15:18:31 you're welcome May 24 15:46:37 i can look at the filenames in meta-raspberrypi/conf/machines to get a value for MACHINE , and in meta-raspberrypi/recipes-core/images/ i can see a value for bitbake to build a image, but is there a command to get these values? i have seen other bsp layers where these files are stored anywhere else May 24 15:49:35 vm_: they're two completely different things. recipes can be listed with bitbake -s, and images are just recipes like any other. or just use the layer index May 24 15:49:40 http://layers.openembedded.org/layerindex/ May 24 15:50:19 they are different, but the two most values someone needs for building May 24 15:50:35 kergoth: have you seen this issue with the sdk installation? For some reason it is having trouble with the env file May 24 15:51:04 Setting it up...ls: cannot access '/opt/poky/2.2.1/environment-setup-*': No such file or directory May 24 15:51:45 vm_: what machines you have available completely depends on what layers you have enabled. same with the recipes. bitbake can't list machines, as a machine is just a config file, it has no special awareness of it. machine is a variable and a config file that bitbake.conf happens to parse, that's all from its perspective May 24 15:54:18 Crofton|work: getting mailer daemons on meta-xilinx list for "mir@lynx-technik.com", you can help sort that out maybe? :) May 24 15:57:13 I can't install the yocto generated SDK :( May 24 15:57:26 no matter what directory I use May 24 15:59:46 i need to make knee joints with available materials May 24 16:00:15 so the knee will carry maybe 3 kg of weight, better 5 May 24 16:46:22 khem: Any thoughts on my previous question? May 24 16:48:49 I have a problem with my quilt-native May 24 16:48:52 i get an error May 24 16:49:04 /build/tmp/sysroots/x86_64-linux/etc/ | The specified directory does not exist. May 24 16:49:12 but the dir is existing May 24 17:01:57 nrossi, I'll look May 24 17:39:48 got it, its also in the manual, ls meta*/recip*/images/*.bb shows all available images you need to setup when running bitbake May 24 17:47:13 exit off May 24 18:26:05 have a vendor meta example tree that I've successfully built. I changed a single bbconfig file to add some features to a package and it broke it. I modified again and reran bitbake iot2000-example-image and it starts back at 63% done. Did it not do those before? My impression watching the build was that it hit 100% with 1 broken package (error popped up then a lot more building happened after before final report: attempted 3691 May 24 18:26:05 tasks of which 1647 didn't need to be rerun and 1 failed). Is there a way to test build just the modified package? (poky/meta/recipes-devtools/tcf-agent, btw) May 24 18:26:51 you can run bitbake on single packages May 24 18:27:34 that would be recipes-devtools? or recipes-devtools/tcf-agent? or just tcf-agent? May 24 18:27:52 tcf-agent I'd say May 24 18:30:20 hello, I'm having some issues running a bitbake image, where I know that there's a recipe for gtk+ in one of my layers, however it isn't built with the image. To enable that package, what should I modify? May 24 18:35:00 twall: Did you add the package to IMAGE_INSTALL? May 24 18:36:01 I've been trying to find where that is, should that just be a line in bblayers.conf or local.conf? May 24 18:36:50 twall: You should be able to do IMAGE_INSTALL += "" in local.conf May 24 18:37:42 twall: Oh, sorry, use IMAGE_INSTALL_append May 24 18:37:52 http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-IMAGE_INSTALL May 24 18:39:38 JPEWhacker: I'll give that a shot, thank you May 24 18:59:57 lamego: you add it to DISTUTILS_INSTALL_ARGS May 24 19:03:54 I removed it back then since we were moving to distutils from setuptools and distutils did not support it May 24 19:12:55 pkay, so build give me a .rootfs.wic, a .hddimg, a .iso, and a rootfs.ext4, all ~1GB. I'm only using the .wic file, where do I suppress building of others? May 24 19:13:22 khem: got it. This helps. Thanks! May 24 19:14:18 ketemphor : You should change the local.conf May 24 19:14:57 ketemphor : You have a variable which named IMAGE_FSTYPES May 24 19:15:43 crap, didn't see it in there, maybe in referenced file? May 24 19:16:12 ketemphor : In your build/conf/local.conf? May 24 19:16:14 templateconf.cfg -> meta-poky/conf May 24 19:16:30 yeah, not there May 24 19:17:24 ketemphor : did you get the software from a company? May 24 19:17:31 yes May 24 19:19:29 ketemphor : when you said " didn't see it in there " you mean the file or the variable? May 24 19:19:41 variable May 24 19:20:31 ketemphor : Why not trying bitbake -e and looking for the IMAGE_FSTYPES May 24 19:24:12 definitely in there - need to go digging for where, 1MB text file doing bitbake -e imagename > file - set to " live wic" May 24 19:24:36 oh, then live looks like it expands to iso, hddimg May 24 19:26:04 if base_contains("IMAGE_FSTYPES", "live", "live", "0", d) == "0": # live is not set but hob might set iso or hddimg > > - d.setVar('NOISO', base_contains('IMAGE_FSTYPES', "iso", "0", "1", d)) > > - d.setVar('NOHDD', base_contains('IMAGE_FSTYPES', "hddimg", "0", "1", d)) May 24 19:26:17 ketemphor : So yeah i guess May 24 19:27:00 ketemphor : take off live and the work is done May 24 19:28:53 ketemphor : Can you confirm after you tried? May 24 19:29:15 trying to figure out where that's sourced from May 24 19:29:35 the -e just shows a bunch of config info, haven't been able to trace back source of those lines yet May 24 19:31:09 try with grep May 24 19:32:24 like grep --include=*.conf -rnw -e 'IMAGE_FSTYPES' May 24 19:32:26 that's how I found them in the output, not seeing any clues as to where those configuration lines being displayed by -e are read from file May 24 19:33:08 You go to your source directory and try what I said May 24 19:33:31 trying May 24 19:34:18 It will check for only .conf file and I suspect it being in a ".conf" but as i'm a newbine in Yocto, you will need to wait more for expert helps May 24 19:34:48 pastebin after it the result May 24 19:35:11 like recursively? haven't used grep without a pipe before... use in source tree, not build tree May 24 19:35:23 no pipe May 24 19:35:41 just only what i said May 24 19:35:41 no need May 24 19:35:41 directly into your source directory May 24 19:35:41 grep --include=*.conf -rnw -e 'IMAGE_FSTYPES' May 24 19:36:26 and you should also try into your build dir as it used to be May 24 19:36:43 yeah the best is to be on the top of both source and build dir :p May 24 19:36:50 damn, that was fast ... alright, let me figure out pastebin real quick May 24 19:37:30 https://pastebin.com/eTsA0LaH May 24 19:38:16 build is going to be slow, that directory tree is huge May 24 19:39:15 yeah we should add --exclude-dir to excluse some of them like the wrk directory ahahah May 24 19:41:33 nothing in build May 24 19:41:52 Wuuut May 24 19:41:59 52GB build directory - never had a clue what it took to build a 1GB distro May 24 19:42:20 I restarted it with --exclude-dir=tmp/work May 24 19:43:44 i've had a build directory that's exceeded 100GB before May 24 19:43:47 ketemphor : I don't know if it work but maybe considering 'IMAGE_FSTYPES*" May 24 19:44:34 same thing, it found the ones in the source directory alright, none of those look like likely candidates? May 24 19:45:02 none of those say live ... May 24 19:46:03 ah well, more of an annoyance than anything, especiall when they're duplicated in the tmp/deploy and tmp/work May 24 19:47:21 damn, need to run. thanks for your help ChrysD May 24 19:47:59 twall : Do you remove the bitbakes oytu have done before? May 24 19:55:01 Does any one know if it would be bad form to have DISTRO_FEATURES be based on MACHINE_FEATURES? (e.g. DISTRO_FEATURES = "${@bb.utils.contians("MACHINE_FEATURES", "screen", "wayland", "", d)}" May 24 19:56:11 JPEWhacker : If there is two words, it seems that somethings is conceptually different. May 24 19:56:25 JPEWhacker : Stupid answer i guess May 24 19:57:02 JPEWhacker : Maybe in the guide there is an explanation of the philosophy on what should be distro and machine May 24 19:57:16 JPEWhacker: yeah you wouldn't do that really May 24 19:57:34 JPEWhacker: recipes can check both machine and distro features if required May 24 19:58:04 rbuton: Ok, thanks. May 24 19:58:05 JPEWhacker : I would say that the MACHINE_FEATURES should be " machine specific " May 24 19:58:15 JPEWhacker : such as package/drivers for the wifi May 24 19:58:50 JPEWhacker : also some kind of packages for touchscreen and so on May 24 19:59:05 Ya, I guess my thinking was "if the machine has a screen ("screen" in MACHINE_FEATURES), this distro wants to use Wayland ("wayland" DISTRO_FEATURE) May 24 19:59:28 But if the machine doesn't have a screen, don't bother May 24 19:59:45 but then you're breaking the axiom that distro features doesnt' change in a distro May 24 20:00:01 rburton: Makes sense May 24 20:00:23 rburton: whats holding up gcc7 ? May 24 20:00:39 khem: nothing now the 4.1 fix has been resubmitted May 24 20:00:47 khem: got a clean branch i can throw at the ab now? May 24 20:04:41 rburton: you can cherry-pick http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=807a6b9c92ab5a868e8a723f40d9fa5ca1a3b9a0 May 24 20:05:37 its a single patch May 24 20:05:49 cool May 24 20:06:14 btw. I switched to using gcc7 on my archlinux-testing May 24 20:06:30 and it seems uninative will have issues May 24 20:06:45 it will need to consider the c++11 ABI for libstdc++ with gcc7 May 24 20:07:01 for now easy fix was to stop using uninative May 24 20:07:23 I wonder if we should just cut the crap and build own gcc May 24 20:07:34 and gcc-runtime for build host May 24 20:07:47 a gcc to build gcc? May 24 20:07:55 i mean, build gcc-native first May 24 20:08:01 yeah May 24 20:08:37 so we can have gcc-native gcc-nativesdk gcc-cross-initial gcc-cross and gcc-crosssdk and gcc May 24 20:08:51 just gccfy your life May 24 20:16:59 khem: https://autobuilder.yoctoproject.org/main/tgrid May 24 20:18:40 hm doing a stop all builds on the new AB makes it hang (halstead, I think i broke ab.yocto.io) May 24 20:19:36 oh there it goes, back again May 24 20:19:37 rburton, It hasn't in the past. Anything special about this time? May 24 20:19:52 all http connections just hung for about 30 seconds May 24 20:20:09 working fine now May 24 20:20:50 rburton, I have seen the web interface stall when stopping lots of builds. May 24 20:21:20 I'm not sure what the bottleneck is. May 24 20:21:47 It's not load on the controller. May 24 20:23:43 rburton: ok cool May 24 21:25:46 hello, I've been running into an issue building gtk+3 from the oe-core layer, where mesa-gl is "trying to install files into a shared area where theose files already exist." The error messages advise clearing out build/tmp and the sstate cache, then rebuilding. This still fails. So is it a configuration issue in the .bb file, or maybe my machine? The error mentions DISTRO_FEATURES could be the culprit if May 24 21:25:52 I changed that variable recently, but I've never touched it May 24 21:28:52 twall: the message is a little vague because it can't automatically determine what the cause is May 24 21:29:03 twall: which files is it complaining about? May 24 21:29:20 (use pastebin if it's more than a few) May 24 21:32:36 https://pastebin.com/9sHGxW1p May 24 21:32:49 bluelightning: it's not super helpful, but here's the log May 24 21:34:06 it looks like it's dying while trying to install libgbm after installing libgbm-dev May 24 21:34:53 well, it kind of looks like there is a recipe called am57xx-evm-libgbm (presumably from TI) which provides libgbm and that's what it's clashing with May 24 21:37:01 perhaps mesa is being built incorrectly? i.e. maybe it's not supposed to be producing this library May 24 21:37:17 denix: any ideas? May 24 21:39:03 in one of the ti layers (meta-processor-sdk) there is a libgbm recipe May 24 21:39:20 *append recipe May 24 21:40:04 bluelightning: yes, we discussed it with rburton before. there's a need to decouple libgbm from mesa May 24 21:40:33 the append has a patch to add linkable libs for Qt, yeah May 24 21:40:33 denix: ok, in the mean time is there a workaround that twall can use? May 24 21:40:41 twall: libgbm is in meta-ti May 24 21:43:03 denix: is there a way i can decouple it from mesa while still keeping the meta-ti layer? May 24 21:43:18 bluelightning: in the meantime we avoid pulling in mesa when using sgx blob. basically mesa is replaced by sgx+libgbm. and for recipes that pull mesa directly we have bbappends to modify that dependsncy May 24 21:44:03 denix: hmm, presumably twall is hitting something that still has such an explicit dependency which isn't covered May 24 21:45:20 twall: if you actually need to pull mesa, then no. if it's pulled accidentally, then find what causes it and see if we have a solution in meta-ti/meta-arago May 24 21:46:28 sounds good. I don't think I have anything that requires mesa. Where would be a good start to finding what pulls it in? May 24 21:49:00 twall: bitbake -g will produce some graph files (which you should search with less or your favourite editor rather than a graph viewer as they are too large for most viewers) May 24 21:49:20 twall: ^^^ yes, -g helps May 24 21:49:22 graphs showing the dependency relationships, that is May 24 21:51:30 bluelightning: mesa and mesa-gl provide own libgbm unconditionally. previous discussion was about maybe making it a PACKAGECONFIG, but I'm not that familiar with Mesa and so far didn't have time to look into it May 24 21:51:48 denix: ah ok May 24 21:51:53 * bluelightning is not very familiar with mesa either May 24 21:52:31 the package dependency chart is saying that libgbm is dependent on mesa from the oe-core layer May 24 21:54:11 then a bunch of sgx packages in the meta-ti layer are made with it May 24 21:55:14 both libgbm and libgbm-dev are made with mesa from the oe-core layer May 24 21:56:07 twall: meta-ti provides separate libgbm. you need to see what depends and pulls entire mesa May 24 21:56:25 right, it's what depends on mesa that needs to be tracked down May 24 21:59:03 sorry if this seems rather noobish, but what would i be looking for? May 24 22:00:49 -> mesa or something similar I would think May 24 22:02:25 bluelightning: I have "libgl-mesa" -> "mesa-megadriver" [style=dotted] and "mesa-gl-staticdev" -> "mesa-gl-dev" [style=dashed] May 24 22:03:15 the second one isn't significant May 24 22:03:20 so what depends on libgl-mesa? May 24 22:03:59 nothing, it would seem May 24 22:04:20 really? I wouldn't expect it'd be in the graph if that's the case... May 24 22:04:59 well, actually that's not necessarily a requirement May 24 22:05:32 twall: I'd recommend looking at task-depends.dot rather than the other files unless you are on pyro or master May 24 22:08:27 I'm on krogoth, so i'll check the task-depends May 24 22:11:54 bluelightning: the mesa-gl.do_packagedata task is only required by another mesa-gl task, and gtk+3.do_package May 24 22:16:37 so the only mention of mesa in the gtk+3 recipe in krogoth relates to wayland May 24 22:17:08 if you don't need wayland support perhaps you should disable that if it's enabled (which I think it may be by default) May 24 22:18:12 (by removing wayland from DISTRO_FEATURES) May 24 22:18:17 and on that its bed time May 24 22:18:34 indeed, thanks rburton May 24 22:18:42 bluelightning: CCd you on a bug mail regarding selftest and recipetool, your thoughts would be appreciated May 24 22:19:02 rburton: right it's on my todo for today May 24 22:19:13 also if anyone wants to make their first contribution to oe-core then https://bugzilla.yoctoproject.org/show_bug.cgi?id=11575 would be trivial and satisfying May 24 22:19:13 Bug 11575: normal, Undecided, 2.4 M1, ross.burton, ACCEPTED , ERROR: cryptodev-tests-1.8-r0 do_checkuri: Fetcher failure for URL: 'http://download.gna.org/cryptodev-linux/cryptodev-linux-1.8.tar.gz' May 24 22:19:25 just thought i'd mention that on the off chance :) May 24 22:19:34 bluelightning: thanks. g'night :) May 24 22:19:58 that's unfortunate, since I'd like to have wayland. Mainly because I'm going to be doing quite a lot of gstreamer stuff and the light weight of wayland is nice May 24 22:20:56 if i wanted to keep wayland, should I move to a newer branch? May 24 22:22:37 that's a good question May 24 22:22:43 denix any recommendations? May 24 22:22:59 (I think there's an element of this that is BSP specific) May 24 22:23:08 makes sense May 25 00:31:13 bluelightning, twall: why would gtk+ depend directly on mesa? we don't use gtk+, but we use wayland May 25 01:06:05 denix: very good question, don't know the answer to that I'm afraid **** ENDING LOGGING AT Thu May 25 03:00:02 2017