**** BEGIN LOGGING AT Wed Mar 16 02:59:58 2016 Mar 16 07:59:49 Hey, folks Mar 16 08:00:36 I have some noobish kernel compilation issues. Who want to get some Stackoverflow points? http://stackoverflow.com/questions/36019223/arm-poky-linux-gnueabi-ld-bfd-no-machine-record-defined-when-compiling-new-kern Mar 16 08:06:42 Kakadu: in short: the old kernelconfig isnt' compatible. you're forwarding over about 45 version,s you knwo? Mar 16 08:07:20 Yeah, I agree that there were a lot of changes Mar 16 08:07:22 Kakadu: my advice would be, manually make the kernel compile with your toolchain again, using oldconfig and then iterating. Mar 16 08:08:01 Kakadu: the error message generally points into the arm machine config, which has changed massively during the 3.0-3.10 era (board files towards dt) Mar 16 08:08:16 so you're in for a real lot of work anyways. Mar 16 08:09:11 > manually make the kernel compile with your toolchain again, using oldconfig and then iterating. Mar 16 08:09:17 Can you rephrase? Mar 16 08:09:42 Do you mean that I need to try to compiler kernel with old 2.6.39 config without bitbake and stuff? Mar 16 08:09:47 Kakadu: explanation prior to DT, any board had an individual, unique number to identify it, which the bootloader passed to the kernel. then, based on that number, the kernel selected the appropriate board config file. this is strongly discouraged now, and probably also doesn't work anymore properly. Mar 16 08:10:23 Kakadu: so if you want to do things right, you need not only to come up with a new kernel, but also a fitting DTB Mar 16 08:10:59 Kakadu: yes, basically i mean that. take your compiler, and try to manually, without bb and oe build a working configuration. then reintegrate that back Mar 16 08:11:11 DTB==Device tree block? Mar 16 08:11:21 device tree blob Mar 16 08:11:28 ah, I mean t that Mar 16 08:11:32 spelling. Mar 16 08:11:38 OK, thanks! Mar 16 08:12:00 good luck. Mar 16 09:52:53 Hi, do you know if there is a channel dedicated to meta-raspberry ? I see that 6 days ago, the rpi3 support has been added into the master branch but the generated image failed to start on a rpi3 (stucked on the screen displaying 3 raspberrys). Mar 16 12:03:25 hi folks, on the same build machine (ubuntu 14.04.4, gcc 4.8.4) I've cloned 2 git repos: one for my yocto project and the latter is the u-boot repo, so I bitbake the sdk, install it and source it, but I can't compile u-boot due to an error related to a missing tool Mar 16 12:03:32 arm-poky-linux-gnueabi-ld: cannot find -lgcc Mar 16 12:03:40 but I can't understand why the same u-boot source code compile with no problems using yocto recipes, while when I try to compile "manually" u-boot I get this error Mar 16 12:03:49 anyone have any clue about this? Mar 16 12:16:11 zero_note: maybe it's missing in your sdk? Mar 16 12:18:54 zero_note: also try installing gcc-multilib on your host Mar 16 12:39:57 i have a recipe that dynamically extends PACKAGES in do_package_prepend() with d.prependVar("PACKAGES", "{} ".format(pkg)) inside a loop. i tried disabling the 'build-deps' QA check for each new package by adding d.appendVar("INSANE_SKIP_{}".format(pkg), "build-deps"), but it seems to have no effect. any idea why? Mar 16 12:41:15 putting INSANE_SKIP_ = "build-deps" for each package at the top level works, but is no longer dynamic Mar 16 12:41:39 maybe there could be sstate-related issues later too, but i want to figure out this step first Mar 16 13:06:22 Ulfalizer: have you set http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PACKAGES_DYNAMIC ? Mar 16 13:16:30 Anticom: yup, it's set Mar 16 13:22:24 Anticom: my sdk is ok, I use it to compile the kernel with no problems, why are you think about gcc-multilib? Mar 16 13:22:42 zero_note: just read it somewhere on SO Mar 16 13:22:47 sec Mar 16 13:24:15 zero_note: http://stackoverflow.com/questions/22157391/how-to-deal-with-linker-error-error-cannot-find-lgcc 1st comment Mar 16 13:28:27 Anticom: thanks, I'll try (actually I can't apt-get install on my build-machine due to restricted permissions), next time I'll googling more deeply ;-) Mar 16 13:54:25 Anticom: gcc-multilib does not seems to fix the problem, I suppose that is not a so much unexpected thing, because as I said before, the same source compile with no problem using yocto recipes Mar 16 13:55:23 zero_note: maybe checking, what 'bitbake -e | less' yields might give you any clues on some environment stuff you're missing in your build Mar 16 14:07:28 Anticom: LD and LDFLAGS seem quite different in u-boot run.do_compile and in my build env Mar 16 14:08:45 zero_note: there you go :) Mar 16 14:08:56 Anticom: I expected that sourcing the sdk would give me the same env Mar 16 14:09:25 dunno. never used a bb populated sdk yet. I'm fairly new to yocto myself Mar 16 14:09:44 me too :) Mar 16 15:27:37 Hello. I am new to Yocto and see great value in its use. I have read all of the documentation over and over but have a few beginner questions and I was wondering if this is the place I can maybe get some help. Mar 16 15:28:07 it sure is Mar 16 15:28:15 Great! Mar 16 15:28:15 riz__: yes, that's probably the place, but this is IRC so the answer might take some time to come Mar 16 15:28:28 Not a problem. I understand Mar 16 15:30:06 To begin, I am having trouble understanding the process of getting started. I am using the minnowboard and would like to get my feet wet by building a yocto image to load on the board. I have done it successfully with both core-image minimal and sato, but the process was not fully understood. I just followed documentation and it worked. Now I am trying to understand it. Mar 16 15:31:09 riz__: so what steps exactly don't you understand? the concepts & terms like layers or recipes take some time to really settle. Took me like 3 weeks or so :> Mar 16 15:31:35 My question is the following. Is Poky build system (located at git://git.yoctoproject.org/poky.git, poky-jethro-14.0.1.tar.bz2) going to be thwe base to every project? Mar 16 15:31:42 no Mar 16 15:31:52 poky is an example, and what we use for QA purposes Mar 16 15:32:11 This is where I get really confused. Mar 16 15:32:15 you can use poky as a base, or just use bitbake + oe-core + meta-intel Mar 16 15:32:42 poky basically is a refference distro to get you jump started Mar 16 15:32:44 poky is just bitbake + oe-core + meta-yocto, squashed into a single repo Mar 16 15:32:50 if i'm not mistaken :P Mar 16 15:33:20 rburton: am i? Mar 16 15:33:30 you can use it to get jump started if you wish Mar 16 15:33:30 riz__: using Toaster, the web UI, might help understanding the bits that come into play. Might… not guaranteed ;) Mar 16 15:33:43 So, you are saying that bitbake + oe-core + meta-intel is the bare minimum needed for any x86 build? Mar 16 15:33:50 no, toaster is a UI Mar 16 15:33:54 entirely optional Mar 16 15:34:07 oe-core + bitbake is the core you'll always use Mar 16 15:34:20 if you're using minnowboard you'll need meta-intel too Mar 16 15:34:23 yes, and meta-intel is for my specific platform Mar 16 15:34:28 exactly Mar 16 15:34:38 right Mar 16 15:34:42 Now, what are those considered? layers? Mar 16 15:34:43 that's where the understanding of layers is important Mar 16 15:34:49 haha Mar 16 15:34:51 lol Mar 16 15:34:58 so the layers just encapsulate certain abstraction levels Mar 16 15:35:15 yes Mar 16 15:35:27 at the core there are the bsp (board support layers) layers, basically defining the hardware you're compiling for Mar 16 15:35:38 and then you start 'layering' functionality / abstractions on top Mar 16 15:35:49 Is the combination of bitbake + oe-core + meta-intel called my "build system"? Mar 16 15:36:11 bitbake is the build system. It parses the recipes and figures out what has to be build how and in what order Mar 16 15:36:22 oe-core is just a big collection of recipes that are commonly used Mar 16 15:36:38 Ahhh, BSP's. That is my next point of confusion. Mar 16 15:37:18 e.g. the recipe base-files is (more or less) just creating folders like for example /tmp in your rootfs Mar 16 15:37:20 I am seeing Intel-corei7-64. Does that have to be included in the build? Mar 16 15:37:51 dunno about x86 recipes. we're using arm :) Mar 16 15:37:53 referring to intel-corei7-64-4.0-jethro-2.0.tar.bz2 Mar 16 15:38:12 Well, ingeneral, do I have to include some sort of BSP? Mar 16 15:39:15 well if you're buid successfuly runs on your target then it's included somewhere on the way. You can run 'bitbake -e | less' and inspect what's going on there. Also 'bitbake -u depexp -g ' is useful to find out what depends on what Mar 16 15:40:06 Moreover one of the most valuable tools to me, to figuring stuff out is http://layers.openembedded.org/layerindex/branch/master/layers/ Mar 16 15:40:10 Well, now I am going to start from scratch and build a light image for my specific use Mar 16 15:40:17 there you can search for layers, recipes and machines Mar 16 15:40:23 and get useful information about things Mar 16 15:40:25 So, I am wondering if I need to download one of the BSPs on yocto's site Mar 16 15:40:45 OK. Ill check that out too Mar 16 15:41:00 riz__: You could start with core-image-minimal, add your own layer and start adding the stuff you need in your image Mar 16 15:41:55 OK. Sounds like a good plan. Is core-image-minimal included in bitbake? Mar 16 15:42:08 OR do I need to download the poky reference buyild system? Mar 16 15:42:14 core-image-minimal is part of oe-core Mar 16 15:42:16 not entirely sure but i think it's part of poky Mar 16 15:42:20 ah Mar 16 15:42:21 OK great Mar 16 15:42:24 therefore its in poky Mar 16 15:43:03 So I will start bith just building bitbake + oe-core + meta-intel and seeing if I can boot that. Mar 16 15:43:49 with* Mar 16 15:44:21 core-image-minimal provides just a command line, correct? No GUI? Mar 16 15:44:25 rburton: different topic: I've removed alsa from DISTRO_FEATURES but i still see alsa-utils being build. bitbake -e however didn't mention alsa-utils **anywhere**. Also i can't find it in the final running system. I suppose it's still being build but not installed in the rootfs. Any clues why it's still being build then? Mar 16 15:45:40 Anticom: spurious dependency somewhere. if you use distro_features_check you can make it forcibly refuse to build without the alsa feature and that will give you a dependency chain Mar 16 15:46:04 okay thanks Mar 16 15:47:13 riz__: yes Mar 16 15:47:41 at least i can't see any graphical stuff there Mar 16 15:47:54 Anticom: bitbake -g -u depexp might help Mar 16 15:48:04 Now that I will not use Poky, do I just creat a folder called "MinnowboardTest" for example and include bitbake + oe-core + meta-intel in there? Mar 16 15:51:51 alsa-utils shows up in depexp. However i can't dig straight down from our image target. -g does populate 'regular' dot-files right? Which one do i need to render an image that contains the alsa-utils package? Mar 16 15:52:06 is it pn-depends.dot? Mar 16 15:52:24 i woudln't advise rendering them at all Mar 16 15:52:28 they end up so massive you can't find anything Mar 16 15:52:30 grep them Mar 16 15:52:40 or as boucman_work says, use depexp Mar 16 15:53:23 kergoth: directly went to grepping Mar 16 15:53:47 yeah, I use them as text files, never as images :P Mar 16 15:54:08 (I think there is another deps explorer called goggle, but i'm not sure. havn't tested it) Mar 16 15:54:10 I like pretty drawings tho ;) Mar 16 15:54:23 boucman_work: nah, goggle is for building Mar 16 15:54:31 you'd better like heavy zooming and following very long lines :P Mar 16 15:54:58 "enlarge, enhance... enlarge, enhance... enlarge, enhance" :D Mar 16 15:55:05 Or does the file structure of my project not matter? Mar 16 15:55:25 riz__: somewhat Mar 16 15:55:41 e.g. having the layer folders being named meta-* is just a convention afaik Mar 16 15:55:56 however even conventions are made for sticking to them Mar 16 15:56:24 so I just make a project folder and all the layers go inside that? Mar 16 15:56:54 riz__: we just have our layer in a repo Mar 16 15:57:03 dunno whether that's the usual way of doing it Mar 16 15:57:19 OK. Mar 16 15:57:36 So where does the build folder go? Mar 16 15:58:14 And where does the final image end up? Mar 16 15:58:34 we got a little shell script, that clones oe-core and adds our layer to set up the development environment. I'm fairly new to yocto aswell and as i said i'm not really sure what the best way of doing things actually is Mar 16 15:58:36 riz__: if you're just starting out i'd recommend poky + meta-intel tarball releases, then you save some of the hassle of setup Mar 16 15:58:59 riz__: it's all in the manual ;) Mar 16 15:59:05 you said you've read it :p Mar 16 15:59:31 Yeah, I see it for poky, but i'm wondering if the structure remains the same for a custom system Mar 16 15:59:48 rburton: hm, strange... cat pn-depends.dot | grep -F -- '-> "alsa-utils"' is only giving me "alsa-utils" -> "alsa-utils" [style=dashed] Mar 16 15:59:49 Again, the manuals are quite large and remembering everything is a challeng Mar 16 15:59:59 or am i looking the wrong way arround? Mar 16 16:00:14 riz__: correct Mar 16 16:00:37 ok Mar 16 16:00:38 it's in tmp/deploy/image/[MACHINE]/ Mar 16 16:00:49 thanks Mar 16 16:00:53 yw Mar 16 16:03:08 Also that's a question i've asked myself a couple of times now... Why do packages depend on themselves? Mar 16 16:03:11 Anticom: make it break and see what happens Mar 16 16:03:31 that's possibly it showing the relationship between binary and source? Mar 16 16:03:54 I've seen that for quite some packages now Mar 16 16:04:11 My next concern is I want to be able to devlop a Qt GUI to use on my board. Is this done by simply including meta-q5 as a layer as I did with meta-intel? Mar 16 16:04:13 afaik pn-depends is pretty naive. if it's going by packages, then packages within a recipe dep on one another, and if it's going by task, the same is true Mar 16 16:04:27 should probably clean it up Mar 16 16:08:15 seebs: do you happen to know of a good way to process input linewise in shell without using 'read', since it tends to mangle the spaces? Mar 16 16:08:26 maybe i should just use python for this script :) Mar 16 16:08:37 kergoth: #bash :p Mar 16 16:08:53 yeah, i'm pestering seebs shamelessly cause he wrote a book on portable shell scripting :P Mar 16 16:08:59 hahaha Mar 16 16:09:19 i just know about while read -r line...done < <(xyz) Mar 16 16:09:23 Mar 16 16:09:46 yeah, thats what i usually do too. -r fixes the line continuation stuff, but it can still swallow leading/trailing spaces and whatnot Mar 16 16:10:44 kergoth: maybe ... done < <(xyz | ack my.ack) to sanatize what xyz is spitting out? Mar 16 16:10:47 oh, i'll just avoid being portable, use bash, and set IFS to newline with a for loop Mar 16 16:11:25 aside: http://www.dwheeler.com/essays/filenames-in-shell.html is quite interesting and cringe-worthy Mar 16 16:11:52 or rewrite your script in brainfuck to really annoy some people would be another nice alternative lol Mar 16 16:13:17 I see that meta-intel layer says it is compatible with yocto version 1.5 on the website. What are they referring to when saying yocto version 1.5? Mar 16 16:14:34 https://wiki.yoctoproject.org/wiki/Releases Mar 16 16:14:41 they're probably refering to bb, http://git.openembedded.org/bitbake/refs/tags Mar 16 16:14:59 no, not bitbake at all Mar 16 16:15:07 oh, never knew that Mar 16 16:15:08 bitbake is 1.29 or something now Mar 16 16:15:24 just for extra confusion, poky has different release numbers to oe-core Mar 16 16:15:33 so yocto version is just a combo of poky and bb versions? Mar 16 16:15:33 (what with poky predating oe-core) Mar 16 16:15:54 poky is a combination of oe-core and bitbake, and gets its own version Mar 16 16:16:02 version-ception Mar 16 16:16:09 current oe-core release is 2.0 aka jethro Mar 16 16:16:37 1.5 would be aka dora, and is pretty old now Mar 16 16:16:42 (one release every six months) Mar 16 16:16:59 we're on jethro Mar 16 16:17:00 * Anticom proud Mar 16 16:17:18 * rburton ignores that 1.9 was skipped Mar 16 16:17:36 :O Mar 16 16:17:43 how come i never notice such things Mar 16 16:17:49 IF I am not using poky then what does that matter? Mar 16 16:17:51 I am confused Mar 16 16:17:54 it doesn't :) Mar 16 16:18:08 so which meta-intel do I use? Mar 16 16:18:10 literally nobody really cares about the poky release number Mar 16 16:18:14 Just the latest release? Mar 16 16:18:15 yes Mar 16 16:18:52 Awesome Mar 16 16:19:19 What about meta-qt5? Is that all I need to develop Qt applications on yocto? Mar 16 16:19:22 yes Mar 16 16:19:57 So, I then just take my Qt5 application that is developed on my host and install it in the root of the target bosrd and it should run? Mar 16 16:20:01 http://downloads.yoctoproject.org/releases/yocto/yocto-2.0/machines/intel-corei7-64/intel-corei7-64-4.0-jethro-2.0.tar.bz2?bsp=cherry_hill_bsp_braswell should be the right bsp release for minnowboard Mar 16 16:20:14 * rburton just uses git clones and finds it a lot easier Mar 16 16:20:23 Or do I still need to include all the Qt libraries? Mar 16 16:20:38 riz__: you'll need to include the libraries - adding a layer doesn't magically make the image contain the binaries Mar 16 16:20:43 Thanks. That is the one I was going to use Mar 16 16:20:51 write a recipe for your application to build it, and then put the resulting package in your image Mar 16 16:21:09 that will pull in the right libraries automatically Mar 16 16:21:23 OK. Mar 16 16:22:01 So where does the mata-toolchain-qt5 come into play? Mar 16 16:22:05 ignore that Mar 16 16:22:16 That confused the hell out of me Mar 16 16:22:20 'So then what is that? Mar 16 16:22:21 anything that says meta-toolchain is obsolete Mar 16 16:22:25 ok Mar 16 16:22:44 if you want to develop for the target on your host, then you can build a custom SDK Mar 16 16:22:53 meta-toolchain was the precursor to that Mar 16 16:23:13 by develop i mean build binaries and so on but without using bitbake or oe directly Mar 16 16:23:24 So onvce I inculude the meta-q5 layer and build yocto I should be able to use QtCreator to setup a kit to point to the required compilers and debuggers that were made from my yocto build? Mar 16 16:24:14 I do want to develop on my host. Then I just want to deploy it on the board with my yocto image Mar 16 16:24:29 I feel that is easiest Mar 16 16:28:02 you want to write a recipe so you can build from your sources inside bitbake Mar 16 16:28:23 its certainly easy to do development inside an ide but you want to have a recipe too Mar 16 16:28:31 That is the part I dont understand. Mar 16 16:28:47 If I am developing in Qt Creator, how to UI build from the source inside of bitbake? Mar 16 16:29:03 how do I build* Mar 16 16:31:00 you point your recipe at the sources, wherever they are Mar 16 16:31:10 And if I build my GUI from QtCreator, is it still necessary to inslude meta-qt5 in by yocto build? Mar 16 16:31:27 riz__: to put it into a simple perspective: Image consists of layers. Layers contain recipes. A recipe usually pulls from a source repository and builds/provides 1 or more packages that then get installed to your image when you add them to IMAGE_INSTALL of your image Mar 16 16:31:46 if you're doing serious development then you might find it easier to start by adding all the qt libraries to your image, and then using qtcreator to build stuff and copy it over. Mar 16 16:31:47 or did i get something fataly wrong there ross? Mar 16 16:32:18 when you're a bit more stable you can have a recipe that pulls from your git repo or whatever and builds it to make proper packages Mar 16 16:32:38 I see Mar 16 16:32:55 For some reason I assumed meta-qt5 included the libraries Mar 16 16:33:05 And that was its purpose Mar 16 16:33:57 So regardless of my method, I need meta-q5 recipe in my yocto build, correct? Mar 16 16:34:16 a layer just provides a source of packages, it doesn't build anything simply by adding it Mar 16 16:34:17 not quite. You need your own layer and recipes inside them Mar 16 16:34:17 kergoth: I don't really know of anything. read is the closest there is, and yeah, it has issues. Mar 16 16:35:54 seebs: k, figured that might be the case, just wanted to see if you knew of anything obvious off the top of your head :) Mar 16 16:35:55 thanks Mar 16 16:36:08 And the most basic recipe is just a local.conf and bblayers.conf file correct? Mar 16 16:36:29 Basically, is that what is meant by a recipe? Mar 16 16:36:39 local.conf and bblayers.conf are configuration for your build directory, that's not a recipe in any way shape or form Mar 16 16:36:46 recipes are .bb files in layers Mar 16 16:36:50 riz__: no, .conf are configuration files Mar 16 16:37:15 Oh yes, sorry Mar 16 16:37:19 Thanks Mar 16 16:38:46 mkdir meta-mylayer; cd poky; source oe-init-build-env; bitbake-layers add-layer "path/to/meta-mylayer" Mar 16 16:38:49 ^^^ riz__ Mar 16 16:38:53 So to develop in QtCreator, I need to make an SDK in my yocto build? Mar 16 16:39:31 Thanks Mar 16 16:39:56 dunno about graphical stuff but i guess it's best to test the visual stuff in quemu hence i'd build it using bitbake and do the qemu thing Mar 16 16:40:10 OK Mar 16 16:40:50 When I built core-image-sato-sdk I saw a folder in my host root directory "opt/poky". I was wondering what that was. Mar 16 16:41:24 opt/poky/1.6.3 to be more specific Mar 16 16:42:16 thats where the sdk ends up, /opt/poky/1.6.3/ Mar 16 16:42:23 well you COULD use the sdk but IMHO it's easier to let bitbake handle the environment setup and stuff. Moreover you should be able to simply run runquemu quemux86 after building and get your development in an emulator Mar 16 16:43:02 using emulators only gets impractical if you need to interface with some hardware Mar 16 16:43:09 1.6.3 is pretty old, please use 2.0 if you can Mar 16 16:43:15 at least i wasn't able to find a proper solution to that yet Mar 16 16:44:50 What do you mean by "let bitbake handle the environment"? That is where I get really confused. Mar 16 16:45:23 riz__: after all you're cross-compiling. This requires a lot of environment setup if you're doing anything more complex than a hello world Mar 16 16:45:25 The SDK allows me to point to the required compilers and debuggers in opt/poky. HJow else would you do it? Mar 16 16:46:17 let bitbake compile your source Mar 16 16:47:20 from how i understood it the SDK is meant to be shipped to 3rd party devs but not for your actual development Mar 16 16:48:17 Is the SDK built from meta-qt5 being included? Mar 16 16:48:46 again: meta-qt5 is just a layer Mar 16 16:50:09 So what do I need for the sdk? Mar 16 16:54:40 riz__: you can populate an sdk using bitbake -c populate_sdk Mar 16 16:55:00 but YOU don't neccesarily need it for development. Mar 16 16:56:57 So how would I develop in QtCreator without the SDK? Mar 16 16:57:46 Just develop for gereric linux using the default kit? Mar 16 16:58:31 riz__: use QTCreator as source file editor and bitbake as compiler Mar 16 16:58:35 to put it this way Mar 16 16:59:07 as i said, i never did graphics stuff with yocto. that's just how i would do it. dunno whether there's a better way Mar 16 17:00:23 So I cna bitbake individual components without bitbaking the entire yocto build? Mar 16 17:00:39 yes Mar 16 17:00:44 Ahhh Mar 16 17:00:50 bitbake -e $Package Mar 16 17:00:54 usually bitbake is smart enough to figure out, what has changed and only rebuild the neccessary stuff Mar 16 17:01:07 *only Mar 16 17:01:23 so you don't have to wait hours and hours every time Mar 16 17:01:28 And this way the application is built into my image, correct? Mar 16 17:01:56 In other words, I would not have to transfer the application over to my board? Mar 16 17:02:06 as long as you're having a recipe that tells bitbake how to actually build your source and tell it to install it into your image, then yes Mar 16 17:02:42 atm i'm just copying the final image bitbake spits out to an sd card, put that into my target and boot it Mar 16 17:02:46 OK. Are there any examples of this I can study? Mar 16 17:02:53 poky Mar 16 17:03:00 OK great Mar 16 17:03:41 Thanks. I have a lot of work to do. I will go play around and try to wrap my head around everything I learned today. Thanks guys. This was gold! Mar 16 17:04:04 riz__: http://lmgtfy.com/?q=yocto+qt+example Mar 16 17:05:17 riz__: after getting some information about the basics from my personal experience it's best to tinker arround. Nothing teaches you more. If you've got some specific questions on some topic, you can always come back here Mar 16 17:05:28 I have read all those, but there are many components and different ways of doing the same thing so I wasnt sure the proper direction Mar 16 17:05:32 This helped clear things up Mar 16 17:05:53 Thanks Anticom! Mar 16 17:06:07 you're welcome riz__ Mar 16 17:22:07 grrrr i don't get it. I've explicitly installed connman (with plugin-loopback and plugin-ethernet) and put a config to /etc/systemd/network/foo.network Mar 16 17:22:42 But still systemd won't automatically start sshd.service (- sshd.socket is fine -) and my interface won't configure Mar 16 17:22:52 Any ideas how to track down the problem? Mar 16 17:23:23 adding foo.network won't do anything unless you enable systemd-networkd, afaik Mar 16 17:23:30 connman doesn't use that at all, you configure that with connmanctl Mar 16 17:24:03 kergoth: i thought i either needed connman **or** networkd Mar 16 17:24:09 you do Mar 16 17:24:19 but you installed connman and then added a config file for networkd :P Mar 16 17:24:36 kergoth: so is there a way to live with connman alone? Mar 16 17:24:41 yes, configure connman Mar 16 17:24:43 google how to do so Mar 16 17:25:00 kergoth: i'm always just getting main.conf when i google for how to configure connman Mar 16 17:25:16 configure connman is almost an oxymoron Mar 16 17:25:24 if it finds wired ethernet it brings it up Mar 16 17:25:25 lol Mar 16 17:25:30 https://wiki.archlinux.org/index.php/Connman#Usage Mar 16 17:25:46 my current connman settings just got [global]OfflineMode=false and [Wired] Enable=true and Tethering=false Mar 16 17:25:54 wifi you need to configure once to associate, obviously Mar 16 17:26:45 kergoth: wiki says about wired connections: "ConnMan will automatically handle wired connections." Mar 16 17:26:49 indeed. or if you want to use static rather than dhcp, or presumably if you want to use usb cdc networking Mar 16 17:27:12 kergoth: and this can only be achived via connmanctl? like how would i incorporate this in my build process Mar 16 17:27:14 i had to configure connman with connmanctl when i wanted to use usb networking with my boneblack Mar 16 17:27:18 it's the same static ip for every device shipped Mar 16 17:27:23 Anticom: as the wiki says, the settings end up in /var/lib/connman Mar 16 17:27:51 kergoth: I've got a 'settings' file laying arround there with the content i've mentioned Mar 16 17:28:09 i wasn't able to find a synopsis of how to configure a static ip for connman in that file Mar 16 17:28:20 they're all just talking about connmanctl Mar 16 17:28:30 even this doesn't tell it: http://git.kernel.org/cgit/network/connman/connman.git/tree/src/main.conf Mar 16 17:28:45 yes, you'd use connmanctl to configure a static ip as well, and it writes files into /var/lib/connman Mar 16 17:28:50 so presumably you'd just ship those Mar 16 17:29:05 not that difficult, just very different from how you configure other networking tools Mar 16 17:29:11 might be easier to just enable networkd ;) Mar 16 17:29:28 * kergoth isn't a big fan of connman, really.. sometimes useful, but a pain to set up for non-common-cases Mar 16 17:29:28 kergoth: could you paste a valid config file configuring a static ip please? Mar 16 17:29:38 you can't take 5 minutes to run connmanctl yourself and look? Mar 16 17:29:41 i don't havea board handy Mar 16 17:29:53 and i just took connman-client out of my bulid again haha Mar 16 17:29:58 cheers anyway Mar 16 17:30:02 ah. haha Mar 16 17:30:04 oops Mar 16 17:30:05 so are there any drawbacks of using networkd? Mar 16 17:30:22 not sure, i haven't used it enough to say, maybe someone else in here knows Mar 16 17:30:27 and networkd replaces connman right? Mar 16 17:31:34 it's its own thing, yeah. no need for both, afaik Mar 16 17:33:07 where is that damn networkd recipe again? Mar 16 17:33:11 i just can't find it Mar 16 17:34:57 there is no recipe, it's part of systemd Mar 16 17:35:01 just enable the packageconfig for it Mar 16 17:35:24 106:PACKAGECONFIG[networkd] = "--enable-networkd,--disable-networkd" Mar 16 17:37:54 kergoth: would i do that in a systemd_%.bbappend? Mar 16 17:38:05 or would i write a custom config_network.bb ? Mar 16 17:38:06 easier to do it from your distro .conf or local.conf if temporary Mar 16 17:38:12 PACKAGECONFIG_append_pn-systemd = " networkd" Mar 16 17:38:31 btw why do i need the _pn there? Mar 16 17:38:40 because thats what the override is Mar 16 17:38:44 okay Mar 16 17:38:46 systemd is the PN of the recipe Mar 16 17:38:52 so tl;dr; is 'because' Mar 16 17:38:53 see the OVERRIDES variable Mar 16 17:38:54 pn-${PN} is in there Mar 16 17:39:02 okay Mar 16 17:39:25 no, it's because that's what's in OVERRIDES. _append_ is applied when is in OVERRIDES Mar 16 17:39:37 kergoth: And where would i put a config to /etc/systemd/network/ then if i only enable it in my local.conf? Mar 16 17:39:38 in this case we prepend pn- to avoid conflicts in the namespace Mar 16 17:39:44 i.e. 'linux' can be both a recipe and a target os Mar 16 17:39:47 ah, i see Mar 16 17:39:56 this *did* bite us in the past :) Mar 16 17:40:16 you'd need to add it to a recipe, either to systemd itself or create a new recipe to ship the configuration Mar 16 17:40:21 the latter being cleaner Mar 16 17:40:48 kergoth: and if i had a new recipe anyway i could also do the packageconfig there i guess Mar 16 17:41:28 no Mar 16 17:41:31 one recipe can't change another Mar 16 17:41:38 your new recipe cant' change how systemd builds Mar 16 17:42:32 create a distro, optionally including another, in the distro you add your configuration to your images by adding it to DISTRO_EXTRA_RRECOMMENDS and change the systemd config Mar 16 17:42:45 IMO that's the best approach, but as with everything else in yocto, there are many ways to do it Mar 16 17:43:34 kergoth: btw wouldn't += be more appropriate even for PACKAGECONFIG_append ? Mar 16 17:43:43 no Mar 16 17:44:00 what if someone want's to append some other config? Mar 16 17:44:06 i don't understand the question Mar 16 17:44:10 wouldn't that discard the first one Mar 16 17:44:16 _append is an operator Mar 16 17:44:21 like += and .=, only lazy Mar 16 17:44:22 it's cumulative Mar 16 17:44:24 PACKAGECONFIG_append_pn-systemd = " networkd" >>>>>> PACKAGECONFIG_append_pn-systemd += " networkd" Mar 16 17:44:25 every _append is applied Mar 16 17:44:42 are you sure? Mar 16 17:44:45 the only difference between those two lines is the += added your space for you Mar 16 17:44:59 Given I wrote bitbake's recipe parser when we started the project, yes, i'm pretty sure Mar 16 17:45:01 i thought PACKAGECONFIG_append_pn-systemd was a "regular" variable Mar 16 17:45:05 no Mar 16 17:45:18 rburton: can you please confirm this? Mar 16 17:45:25 are you kidding? Mar 16 17:45:37 kergoth: someone just told me the other way arround Mar 16 17:45:42 not that i wouldn't trust you, sorry Mar 16 17:45:45 again, i was one of the founders of the project, and co-wrote the bitbake user manual Mar 16 17:45:49 https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html Mar 16 17:46:16 https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#appending-and-prepending-override-style-syntax Mar 16 17:46:17 kergoth: is this maybe different for other _append vars? Mar 16 17:46:22 no, it's not Mar 16 17:46:39 dunno who told me += was better. I'd have to check the irc logs Mar 16 17:46:53 using += and _append together is pointless and redundant. Mar 16 17:46:54 but thank's for pointing that out Mar 16 17:47:10 using += *instead* of _append when appropriate makes a lot of sense, as there's no point using the lazy operation if you don't need it Mar 16 17:47:26 but it's the only way to use an override to append conditionally, so it's your only option in this case Mar 16 17:47:28 kergoth: i thought the XYZ_append vars where regular vars untill the point XYZ was actually evaluated Mar 16 17:47:40