**** BEGIN LOGGING AT Wed Nov 02 03:00:00 2016 Nov 02 07:45:26 Good morning. Nov 02 07:46:42 the .sh installer generated with populate_sdk task, is it portable to Windows platform? Nov 02 07:48:03 SDK_OS = "Windows" should work? I just don't find any example about this Nov 02 08:01:18 aV_V: not by default, however with meta-mingw you should be able to build toolchains that can be installed on windows Nov 02 08:03:44 bluelightning: ty, I will take a look Nov 02 08:06:10 good morning Nov 02 08:41:50 aV_V: maybe also a question if you really need a "native" windows compiler ... maybe also an approach like https://github.com/crops/extsdk-container serves your need Nov 02 08:49:13 mdnneo: not sure about this, I'm trying with the "traditional" way Nov 02 09:56:19 https://wiki.yoctoproject.org/wiki/Releases This page was edited before Morty was released. Nov 02 09:56:51 So it's not obvious to me whether Morty is still in "Development" or if it's reached "Stable"? Nov 02 09:58:40 JoiF: https://lists.yoctoproject.org/pipermail/yocto/2016-November/032823.html Nov 02 09:59:32 nrossi: Thanks Nov 02 10:00:41 nrossi: But I knew Morty was released .. but I've yet to see something about the "status" of it.. (and that's probably because I'm new to YP), is a release flagges as "stable" as soon as it's been released? Nov 02 10:02:34 JoiF: Thats the normal practice Nov 02 10:03:04 nrossi: Thanks :) Nov 02 10:04:10 I'm actually probably stuck with krogoth anyway.. I'm taking baby-steps so I'm still depending on the meta-xilinx layer, and they haven't made a morty branch yet :/ Nov 02 10:05:20 JoiF: you mean i haven't made a morty branch yet ;). And yes if you are using BSP layers reving up to the newest yocto/oe release as soon as it is out is not always possible Nov 02 10:06:18 JoiF: for meta-xilinx the goal is to have branched by at the latest 1 month after a yocto/oe release Nov 02 10:06:57 nrossi: Ok, nice :) Nov 02 10:07:11 but i cant speak for other layers, you will need to check the readme, and or query the maintainers :) Nov 02 10:08:44 Ok, thanks Nov 02 10:09:50 hello Nov 02 10:09:59 o/ Nov 02 10:10:19 I'm also looking at the meta-mono layer (yes, I work with weird people...) their last branch is WAY old.. Nov 02 10:13:54 nrossi: But if there's anything I can do to help with the meta-xlilinx layer, I'd be happy to do something Nov 02 10:14:09 nrossi: Like .. testing or whatever Nov 02 10:14:47 JoiF: Are you using one of the board(s) in the layer? or a custom one? Nov 02 10:15:15 nrossi: I have both a ZedBoard and a ZC702 .. and we're working on a custom one Nov 02 10:16:08 nrossi: Unfortunately no MPSoCs Nov 02 10:17:34 JoiF: It would be nice if you could test the default build and booting on those boards (i only test on a zybo and zc706), but wait until the branch is made there are still a bunch of updates in the process. Nov 02 10:18:02 Ok :) Nov 02 10:18:50 JoiF: I assume you are subscribed to the meta-xilinx mailing list? I will post a message there when the "morty" branch is made. Nov 02 11:15:30 nrossi: I am now :p Nov 02 11:31:32 hi! shouldn't tslib's recipe contain something like CFLAGS_prepend = "-I${STAGING_KERNEL_DIR}/include "? For me it apparently sourced the wrong kernel's headers, thus exited because of EV_VERSION mismatch. Nov 02 11:49:35 robsta: \o/ Nov 02 12:00:31 Note to self: Don't try to run a bitbake job with the Green Hills toolchain in your path. They have a "ginstall" executable that has NOTHING to do with the normal "ginstall". Nov 02 12:01:00 Which is kind of weird, because I do have "install" .. but ncurses-native tries to use ginstall instead.. Nov 02 12:01:50 moderately common for some systems to look for g first to find the gnu form instead of non-gnu Nov 02 12:02:11 ie on osx, install is BSD, ginstall can be GNU if you installed it Nov 02 12:02:57 Indeed. Nov 02 12:04:26 I just thought most of those packages were a bit more GNU centric Nov 02 12:05:37 (i.e. they would just assume GNU/Linux as host) Nov 02 12:10:52 people with Green Hills toolchains are not living properly .... Nov 02 12:11:01 haha Nov 02 12:11:39 I do completely agree. Nov 02 12:11:55 Well.. They do have some nice debugging tools Nov 02 12:11:59 The hardware Nov 02 12:13:28 Both the Green Hills probe and the SuperTrace Probe Nov 02 12:14:08 I suppose Nov 02 12:14:16 but morally speaking :) Nov 02 12:14:43 Indeed Nov 02 12:15:38 My company is lucky they hired me as their sw-architect .. Now we're moving over to Linux and gcc Nov 02 12:19:51 :p Nov 02 12:23:52 Lucky company :) Nov 02 12:37:10 Haha, yes. ;) Nov 02 12:37:34 At least that's what I tell myself. ;) Nov 02 12:52:26 3 Nov 02 12:52:41 der Nov 02 13:20:41 can i do BLABLABLA_remove = "option1 option2 option3" or the _remove is only limited to one option ? Nov 02 13:21:29 https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#removing-override-style-syntax Nov 02 13:21:35 (it does what you want) Nov 02 13:32:34 rburton: thanks Nov 02 13:44:00 nrossi: Btw .. You might have a solution to my annoyance.. Do you know how I can run xmd as a non-superuser? Nov 02 13:44:31 nrossi: I'm in the dialout group and the ttyUSB*s are owned by :dialout and have g+rw Nov 02 13:45:08 JoiF: xmd is old, but there are some udev rules i have to put for the usb debug tools, let me get them Nov 02 13:46:13 nrossi: That would be awesome Nov 02 13:46:53 nrossi: But the problem seems to be some reset functionality. If I run xmd as root, do a "connect arm hw" and "exit" .. and then run xmd as a normal user, it works fine. Nov 02 13:47:01 is it safe to base a new distribution upon meta/conf/distros/defaultsetup.conf ? Nov 02 13:47:13 or default setup is too minimalist ? Nov 02 13:47:38 actually look at what poky.conf does and you'll see it's pretty minimal Nov 02 13:47:58 the default setup is fine, you just need a conf file that sets the distro name and tweaks distro features as required Nov 02 13:48:05 JoiF: https://gist.github.com/nathanrossi/a41b2af6538ded6d0f2a458691cd1110 Nov 02 13:48:07 ok, thanks Nov 02 13:49:07 JoiF: Hmm not sure, might have to do with xmd changing the permissions of the usb file Nov 02 13:50:36 JoiF: oh also, you might need to change the usb ids if the device you are using is special :) Nov 02 13:50:40 nrossi: Hmm.. ok. Might need to tell udev to set the OWNER as well Nov 02 13:51:01 nrossi: Currently just using the on-board Digilent interface on the zc702 Nov 02 13:51:40 nrossi: But thanks! :) Nov 02 13:55:09 nrossi: I don't see a device with VID 1443. That might be my problem. Nov 02 13:55:27 nrossi: I do see the FTDI VID but not the other one. Nov 02 13:57:06 nrossi: Works like a charm. Thanks! Nov 02 13:57:17 nrossi: Btw, what do you use instead of xmd? Nov 02 13:57:30 JoiF: :), i guess you found the magic id. I use xsdb Nov 02 14:01:30 nrossi: Nice Nov 02 14:01:41 nrossi: Seems to be somewhat command-compatible Nov 02 14:02:05 JoiF: yep, i believe that was Xilinx's intention Nov 02 14:02:14 nrossi: or.. completely .. needs the extra "targets" step Nov 02 14:02:26 nrossi: But otherwise seems to do the sme business Nov 02 14:02:32 s/sme/same/ Nov 02 14:49:32 nrossi: Sorry about all the questions .. but where do you get the fsbl.elf from? I have one from my Vivado+SDK+PetaLinux project, but none from my Yocto build? Nov 02 14:50:33 that is built with the Xilinxinx tools Nov 02 14:50:48 JoiF: fsbl -> fsbl.elf, u-boot-spl -> u-boot-spl.elf. meta-xilinx does not build fsbl. If you need the elf it is not deployed by default but you can get it from the workdir of u-boot Nov 02 14:50:54 I use SPL from u-bbot, but you need the ps7_iniu.[ch] files for that Nov 02 14:52:58 JoiF: http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/README.booting.md#n58 - is the guide you want to follow if you need to load u-boot spl via jtag Nov 02 14:57:31 when layers are added to the layer index via the web interface, is there like, an approval process or something that takes place or does it just get added? Nov 02 14:59:20 pidge: https://layers.openembedded.org/layerindex/history/ if you see the second entry, a layer has to be marked published. Nov 02 14:59:48 Ah, thanks! Nov 02 15:02:24 pidge: about to send a patch for license.bbclass, I'll cc you for a double check if that's okay Nov 02 15:02:40 rburton: sure, go for it Nov 02 15:09:05 Yay! Nov 02 15:09:46 I can haz running system on my board. :D Nov 02 15:10:00 Thanks, nrossi and Crofton|work :D Nov 02 15:13:27 There's a tiny error in the README, though. Where it says "xsdb% dow -data .dtb 0x2A00000", that should be "uImage-.dtb" Nov 02 15:15:17 Hi, what am I missing when kernel modules are not installed? The only thing I found is using 'MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-module-"' in the image.bbappend Nov 02 15:15:56 There are none deployed in the core-image-minimal tarball Nov 02 15:17:57 nrossi: Same probably applies to line 171 (SD-card section) and 226 (TFTP boot section) Nov 02 15:35:20 I would like to include external debian packages (built with the sdk) into my image, is there some easy way of doing that? Nov 02 16:05:42 is it allowed to have packages containing just a static lib? sure this doesn't make much sense for the target but for the sdk Nov 02 16:06:58 mdnneo: of course, by default it will be in PN-staticdev Nov 02 16:07:56 has someone worked with meta-mingw ? I don't know how to use it and can't find any documentation about Nov 02 16:08:22 does it not have a readme like every other layer? Nov 02 16:08:35 it has, but it says nothing Nov 02 16:08:40 you just need to set SDKMACHINE to one of the options it provides (see conf/machine-sdk/ in the layer) Nov 02 16:08:47 then your sdk builds will target windows rather than linux Nov 02 16:08:55 rburton: then I always run in trouble with default dependencies to the not existing PN package? Nov 02 16:09:17 then remove that dep if it's a problem Nov 02 16:09:26 RDEPENDS_${PN}-staticdev = "" Nov 02 16:09:45 kergoth: ty Nov 02 16:10:22 I removed it via RDEPENDS_${PN}-dev = "${PN}-staticdev" since I want to force the install of the staticdev in the sdk but this makes also trouble Nov 02 16:10:58 the best so far was doing ALLOW_EMPTY_${PN} = "1" Nov 02 16:10:58 'makes also trouble' is not useful information :) Nov 02 16:11:06 that'd work too, yes Nov 02 16:12:09 trouble means it basically silently fails or in the end the sdk build looks good but the -dev or -staticdev package are not part of the SDK Nov 02 16:13:44 forcing it to be part of the SDK via "TOOLCHAIN_TARGET_TASK_append = " libfoo" leads to a "real" fail saying annot install package libfoo Nov 02 16:14:12 so ok then I think we use the allowempty ... just felt wrong somehow Nov 02 16:14:26 mdnneo: put libfoo-staticdev in that assignment instead Nov 02 16:14:34 as libfoo doesn't exist Nov 02 16:15:49 rburton: also for me the forcing feels a bit strange ... I don't want to decide in the image recipe which lib is needed in the SDK ... having it installed if needed looked better to me Nov 02 16:16:26 TOOLCHAIN_TARGET_TASK_append = " libfoo-staticdev" is *exactly* what you need if you want to put a static library in the sdk Nov 02 16:16:37 would it be a big deal to just create the default dependency from PN-dev to PN just if it is not empty? Nov 02 16:16:38 put that in the *image* recipe Nov 02 16:17:23 dependencies are created before we know the package you're mentioning doesn't get created Nov 02 16:17:36 rburton: not with the "hack" of have the dependency from PN-dev to -staticdev ... but yes thats also just a workaround Nov 02 16:18:13 yeah the -dev dependency on -staticdev is a workaround Nov 02 16:20:38 so currently I wonder which is the best workaround ... for us the RDEPENDS_${PN}-dev = "${PN}-staticdev" has been the best since we control in the lib if it is part of the sdk or not ... just seems like we get the dependency to the empty PN package again in somehow Nov 02 16:21:36 why would you want to change the library (and thus rebuild everything that depends on it) to control whether its in the sdk or not, when you can control that in the sdk recipe Nov 02 16:23:29 rburton: is it not a good idea to rebuild since it is statically linked? but I got the point of having a sdk recip Nov 02 16:25:46 so maybe just some improvement the silent fail of basically expect to install the PN-dev package and silently just not install it in the SDK took us some time ... is there a chance to warn about? Nov 02 16:25:47 not a good idea to rebuild because rebuilds are boring :) Nov 02 16:27:26 or to get a diff of whats expected to end up in the sdk and whats not ended up there finally Nov 02 16:47:33 what would be the cleanest way to change behaviour of a recipes depending on type of image built. For example, i have myimage_release and myimage_dev, i want to add user www-data to both but admin to only _dev flavor Nov 02 16:48:01 should i introduce a flag on DISTRO_FEATURES (ie: dev) and test it on my user_add.bb ? Nov 02 17:07:43 binarym: admin as in admin user? Nov 02 17:08:50 can I open a shell in a ROOTFS_POSTPROCESS_COMMAnd? Nov 02 17:11:09 not that i know of... Nov 02 17:11:39 :( Nov 02 17:26:17 mr_science: for example Nov 02 17:27:28 mr_science: but it's "just" an example. Could be "allow root login on _dev flavor only" Nov 02 17:29:21 binarym: with a root postprocess hook Nov 02 17:29:57 binarym: you cannot control what goes into a package depending on the image, because packages are built without the knowledge of what images are being built (if any, or it may be several) Nov 02 17:30:33 so have granular packages so you can eg add a development-users package to the dev image, that creates users and so on Nov 02 17:34:26 rburton: ok, got it. Thx :) Nov 02 17:34:55 nerdboy, doing a reverse shell kind of worked :P Nov 02 18:14:48 is there an easy way to install external packages in my yocto image? Nov 02 18:18:59 binarym: that sounds like you want dbg image for that Nov 02 18:56:16 hello? Nov 02 19:02:00 mr_science: yep, it's totally that Nov 02 19:03:13 mr_science: one for "production" context (aka in the wild, with bad bad attackers all around) and one for "debug/development" purposes (with debug tools, login allowed, etc...). I gonna follow rburton advices and create two different recipes: one for prod, one for debug Nov 02 19:05:38 floob: hello Nov 02 19:11:05 hi folks. I'm a noob. I have configured the yocto build system, gone through the getting started guide, watched several hours of youtube vids. Nov 02 19:12:22 My goal is to create an absolute minimal yocto with only nginx, ifup/ifdown, ssh and the ability to get static HTML and nginx config files into the system via initramfs Nov 02 19:13:08 I've searched a fair bit (still searching) but have not yet found a guide that tells me how to trim things down to this minimum. Can someone suggest either how, where to look, or a good tutorial that shows as such? Nov 02 19:13:10 thanks! Nov 02 19:21:10 floob: what is your target ? Nov 02 19:21:14 x86 ? Nov 02 19:21:29 x86-64 Nov 02 19:21:43 on xen Nov 02 19:21:49 sorry, on kvm I mean Nov 02 19:22:01 i'm noob in yocto too, but i gonna try Nov 02 19:22:01 so Nov 02 19:22:16 for adding ifup/ifdown and all others component Nov 02 19:22:34 find the good meta that will provide u it Nov 02 19:23:28 and then simply add IMAGE_INSTALL += "pkg1 pkg2 pkg3" to your build/conf/local.conf file Nov 02 19:23:51 then build your core-image-minimal, and it should embed your packages Nov 02 19:24:07 for the initramfs stuff, it looks a bit more complicated Nov 02 19:25:21 maybe you should have a look to meta/recipes-core/initrdscripts/initramfs-framework Nov 02 19:25:42 but Nov 02 19:25:47 if i remember well Nov 02 19:26:22 once the pivot_root call is done (switching for / == ramfs to / == actual root) the initramfs is freed Nov 02 19:26:39 so looks like it's the most difficult part of your problem Nov 02 19:27:35 I found this https://layers.openembedded.org/layerindex/branch/master/layer/meta-webserver/ but if I IMAGE_INSTALL += "meta-webserver" then I'll get all the web servers, no? Nov 02 19:27:48 you should keep in mind that (in my understanding) adding IMAGE_INSTALL += "..." to build/conf/local.conf is quite the "quick and dirty" way to do this Nov 02 19:28:09 floob: you confuse meta and recipes Nov 02 19:28:14 a meta is a set of recipes Nov 02 19:28:27 you add a meta to your build system, not to your image Nov 02 19:28:43 just to make your build system (aka bitbake) how to build that or that package Nov 02 19:28:50 but you only add a recipe to your image Nov 02 19:29:14 for example Nov 02 19:29:19 OK, so do I find the nginx recipe and do something like: IMAGE_INSTALL += "nginx" Nov 02 19:29:24 yep Nov 02 19:29:48 binarym@avalon:~/Work/poky/poky-krogoth-15.0.1$ find meta* -type d -name nginx Nov 02 19:29:48 meta-openembedded/meta-webserver/recipes-httpd/nginx Nov 02 19:29:50 for example Nov 02 19:30:32 here you have meta-openembedded that provide (sub??) meta meta-webserver that provides a set of recipes to building and installing various webservers Nov 02 19:30:46 OK I found this https://layers.openembedded.org/layerindex/recipe/46779/ which seems to be the nginx recipe. How do I get that into my build system so I can IMAGE_INSTALL += "nginx" Nov 02 19:31:17 https://layers.openembedded.org/layerindex/branch/master/layer/meta-webserver/ Nov 02 19:31:26 git clone git://git.openembedded.org/meta-openembedded Nov 02 19:31:37 then edit build/conf/bblayers.conf to add the meta Nov 02 19:33:32 thanks binarym sorry for all the questions .... where should I "git clone git://git.openembedded.org/meta-openembedded" - in my /poky directory? Nov 02 19:34:42 floob: that's up to you. as long as you put the correct path in BBLAYERS in build/conf/bblayers.conf, bitbake doesn't care where on your disk you happen to put the thing Nov 02 19:35:47 thanks so much.... trying now... Nov 02 19:36:47 floob: your welcome :) solidarity between noobs :p Nov 02 19:50:03 binarym: it can be the same image, but with different IMAGE_FEATURES enabled Nov 02 19:50:55 depends on what you want need, but i would probably use just one image recipe and change local.conf to get :dev:image Nov 02 19:51:05 "dev" image even Nov 02 19:53:20 add dev/dbg stuff to image_features, if you still need extra packages try CORE_IMAGE_EXTRA_INSTALL += "foo bar" Nov 02 19:55:11 certainly for figuring stuff out tweaking local.conf is easier/faster than messing with extra recipes Nov 02 19:55:52 read the comments in local.conf about EXTRA_IMAGE_FEATURES Nov 02 19:56:20 enabling several of those *will* bloat your image size Nov 02 20:33:52 Anyone had problems with SDK in krogoth? Nov 02 20:34:01 I get this: "Setting it up...ls: cannot access '/opt/poky/2.1.1/environment-setup-*': No such file or directory" Nov 02 20:34:31 I built the SDK for my own image. Nov 02 20:42:55 ftonello: does that file exist? Nov 02 20:55:21 hi Nov 02 20:55:43 is it possible to have recipe that has emptu do_install function? Nov 02 20:56:06 maybe there is an exampe out there? Nov 02 20:57:44 marcin: certainly, but what is the aim of doing so in your case? Nov 02 20:58:23 you would do: do_install() { Nov 02 20:58:27 : Nov 02 20:58:28 } Nov 02 20:58:37 bluelightning: well, a bit shame Nov 02 20:59:03 bluelightning: I need to add a user to image, user wiythout home Nov 02 20:59:16 and I can not use useradd in image Nov 02 20:59:34 bluelightning: I tried that Nov 02 20:59:59 it does not work, opkg install fail with empty install Nov 02 21:00:08 marcin: extrausers is designed exactly for that Nov 02 21:00:10 no recipe needed Nov 02 21:00:15 also tried instal[noexec] = "1" Nov 02 21:00:39 marcin: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-extrausers Nov 02 21:00:57 you can use extrausers from your image recipe Nov 02 21:03:01 bluelightning: ok, thank you for help Nov 02 21:03:07 np Nov 02 21:03:28 bluelightning: it is exactly what I need ;) Nov 02 21:17:58 bluelightning: no it doesn't. But isn't that file supposed to be the environment setup to be sourced? That error is from the SDK installation script. Nov 02 21:18:03 Am I doing anything wrong? Nov 02 21:18:40 I have a custom image, but I don't do anything there, basically add some dependencies and image features. Nov 02 21:18:46 ftonello: I can't tell, but would assume not... the question is how are you ending up with an SDK that does not have that file in it? Nov 02 21:18:49 I've been doing it for years. Nov 02 21:19:01 Exactly, I have no idea. Nov 02 21:19:13 I am building from origin/krogoth from poky. Nov 02 21:19:35 and meta-multimedia Nov 02 21:20:31 bluelightning: is there anything an image recipe needs to do in order to generate a proper SDK? Nov 02 21:20:49 ftonello: no, nothing Nov 02 21:24:15 So, why that file wouldn't be there? Nov 02 21:24:38 I was reading the recipes, and saw that meta-environment generates that file. Nov 02 21:24:45 But nothing really calls that recipe. Nov 02 21:24:52 bluelightning: do you have any idea? Nov 02 21:26:27 rburton: ping I was reading through http://lists.openembedded.org/pipermail/openembedded-core/2016-April/120666.html Nov 02 21:26:33 ftonello: it's pulled in through packagegroup-cross-canadian Nov 02 21:26:55 rpi bcm driver does not provide libgbm so it needs to use this from mesa Nov 02 21:26:59 ftonello: are you setting TOOLCHAIN_HOST_TASK somewhere? Nov 02 21:27:04 otherwise weston doesnt compile Nov 02 21:27:25 I added gbm to mesa-gl PACKAGECONFIG and it worked Nov 02 21:29:33 bluelightning: Yes. I do TOOLCHAIN_HOST_TASK += "nativesdk-projucer" on my image. Nov 02 21:30:09 ftonello: ah, I think that may be the source of the problem, although I appreciate it's not obvious Nov 02 21:30:46 ftonello: basically by doing that += you are probably getting in the way of the ?= where we set the default value Nov 02 21:30:56 move the += after the inherit? Nov 02 21:31:07 or try TOOLCHAIN_HOST_TASK_append = " nativesdk-projucer" instead, one of the two Nov 02 21:55:10 I'll try Nov 02 22:53:45 khem: it links, or it actually uses mesa's libgbm to do buffer management? google have forked libgbm and added a load of drivers, so that's probably a better choice Nov 02 23:36:46 rburton: basically weston's configure pokes for it. and when using bcm graphics driver its not using mesa, and so there should be some pakages providing it Nov 02 23:42:39 Now I am having this pseudo mknod problem. Nov 02 23:43:01 It's not the first time I had this. Each time is a different fix. Nov 03 00:40:14 seebs: ^ Nov 03 00:40:28 are you familiar with that? Nov 03 01:02:45 what's the build environment? Nov 03 01:46:32 Not sure. "this pseudo mknod problem" is pretty unspecific. Nov 03 01:46:43 I know we had some issues that got corrected relatively recently. Nov 03 01:51:40 security frameworks, posix caps, acls, etc... Nov 03 01:52:28 had some issues with qemu running the post-inst stuff on a gentoo hardened build server Nov 03 01:53:10 nothing with pseudo that i can think of Nov 03 01:54:04 January 22, there was a bug with mknod() if it was called with no file type bits, it didn't default to plain file. Nov 03 01:54:08 That was what I was thinking of. **** ENDING LOGGING AT Thu Nov 03 02:59:59 2016