**** BEGIN LOGGING AT Mon Feb 23 02:59:59 2015 Feb 23 08:22:02 does x86 yocto run on i586, i386, or i686 platform? Feb 23 08:25:00 chankit: not sure about i386 but i586/686 i believe so Feb 23 08:34:14 zeddii: some new issues with linux-yocto and patch handling in metadata :/ Feb 23 08:34:45 zeddii: I'll send you an email later with logs Feb 23 09:07:08 morning all Feb 23 09:09:53 Hi. Does anyone have openswan 2.6.41 recipe? I cannot find and im not that good in writting recipes. Feb 23 09:13:02 nrossi: ok thanks Feb 23 10:16:17 hi, I'm building an module for yocto-linux kernel. copied the "hello-mod". defined a .scc and .cfg file and included it in SRC_URI. When i append the .cfg in kernels KERNEL_FEATURES variable. bitbake does not find the .scc Feb 23 10:16:37 KERNEL_FEATURES_append = "bcmdhd.scc" >> WARNING: addon feature "bcmdhd" was not found Feb 23 10:21:23 this is the structure of the recipe: http://pastebin.com/tKUFxiRF is there anything wrong? Feb 23 10:22:38 jhieber: I don't think you add the .scc file to KERNEL_FEATURES, you add the feature name Feb 23 10:23:14 also, _append does not add a leading space, so you should put one in the value you are appending Feb 23 10:23:34 hmm AFAIk this was changed some time ago. and in the linux-yocto recipe the other features are also with full path and .scc Feb 23 10:24:03 the warning message indicates that that should be no problem, bitbake converts the bcmdhd.scc thing to the feature name Feb 23 10:24:32 oh ok, perhaps I am mistaken then Feb 23 10:25:46 bitbake should scan my recipe and find the .scc files in SRC_URI so the kernel can include it, but this does not work Feb 23 10:49:21 jhieber: do the scc and cfg file get copied to the workdir for the recipe? Feb 23 10:58:44 bluelightning: jep, when i build bcmdhd the files are copied directly to workdir. then bitbake builds the kernel and fails with: addon feature "bcmdhd" was not found Feb 23 10:59:17 its the do_patch step where it fails Feb 23 11:00:22 according to the documentation it should be enough to add the cfg and scc files to SRC_URI for "recipe space" features Feb 23 11:01:28 ok, this is outside of my area of expertise I'm afraid - this is getting into the build scripts for the kernel Feb 23 11:02:32 ok, thanks anyway for your help. i'll try google something with recipe-space metadata and find out how it is done Feb 23 11:03:37 which branch/version of the build system are you using btw? Feb 23 11:05:35 its "Legato Yocto 15.01" from Sierra Wireless, dont know what version it is, how can i find out? Feb 23 11:06:19 do they not give some kind of indication in the accompanying documentation? Feb 23 11:07:22 when i look in poky folder with git, it looks like master branch Feb 23 11:07:34 this is the last commit bda51ee7821de9120f6f536fcabe592f2a0c8a37 Feb 23 11:08:05 from Thu Oct 9 14:25:15 2014 Feb 23 11:08:28 that would be daisy by the look of it Feb 23 11:08:37 so 1.6 Feb 23 11:08:44 yeah, dizzy was later Feb 23 13:24:26 bluelightning: i figured out that the kernel doesn't know the recipe-space location of the .cfg and .scc files: http://pastebin.com/0fNw6iP4 I added FILESEXTRAPATHS_prepend in the custom module recipe, but that does not help Feb 23 13:35:25 maybe what i'm doing here is not supported. maybe *.scc and *.cfg are only supported in the kernel-recipe, i'll add it to kernels .cfg file Feb 23 13:36:36 bluelightning: there seems to be indeed an issue with kern-tools Feb 23 13:37:02 zeddii would probably be the best person to speak to about that Feb 23 13:37:19 yes, now I can't help from here as well Feb 23 13:37:58 ok, thanks Feb 23 13:38:11 I have hard times in meta-hh with linux_yocto_3.19 and the heap of common patches in SRC_URI Feb 23 13:38:18 is zeddii online here sometimes? Feb 23 13:38:28 same structure was ok since 3.14 Feb 23 13:39:56 hello-mod skeleton should be extended with a scc and cfg file, as most kernel modules depend on config options Feb 23 13:54:50 Hi Feb 23 13:59:42 I acquired an imx28evk board recently and I bitbaked a core-image-sato-sdk and installed Eclipse following the Yocto Application developpers guide. The Hello world ANSI project is compiling but when I try to use any function (for example : ddi_bc_hwGetBatteryVoltage() ) I can't configure eclipse properly... Error --> Undefined reference to ddi_bc_hwGetBatteryVoltage(). I included the paths to those environment variables : CFLAGS, LD Feb 23 14:00:00 Any help would be greatly appreciated, thank you all ;) Feb 23 14:01:14 isn't ddi_bc_hwGetBatteryVoltage a kernel function ? Feb 23 14:01:21 how do you call that from userspace ? :) Feb 23 14:01:51 Hi abelloni Feb 23 14:02:35 Hmm you're telling me there's no way to write an app to configure the battery charger ? Feb 23 14:05:24 Pierre_: it is exported to userspace in /sys Feb 23 14:05:28 I'm pretty new to all those linux stuff and I was thinking i need to include for the same example using ddi_bc_hwGetBatteryVoltage(), the following #include "ddi_bc.h" and #include "ddi_bc_hw.h" and then configure eclipse providing the right paths so the link can be done some way Feb 23 14:05:47 you can't doo that Feb 23 14:06:02 oki that's why I'm getting so much trouble doing that Feb 23 14:06:44 you should have something in /sys/class/power/ Feb 23 14:06:57 one of those is the i.mx28 battery charger Feb 23 14:07:50 yes I got that on my target only but not on the build system Feb 23 14:08:11 how could I use it to lets say modify the charging maximum current ? Feb 23 14:08:51 hi Feb 23 14:08:59 hi Feb 23 14:09:47 it doesn't seem to be implemented Feb 23 14:09:49 is there someone who can tell me how to convince the cross compiler to find the kernel includes? i want to build a kernel module but can't even find linux/module.h Feb 23 14:09:56 get is but set isn't Feb 23 14:10:21 Pierre_: anyway, I wouldn't advise using the battery charger from the i.mx28 Feb 23 14:10:34 it is poorly documented Feb 23 14:10:47 and I guess even Freescale doesn't know where is the datasheet Feb 23 14:10:51 but how can I develop on my computer a soft for the target when I can't access those files on my build system ? Feb 23 14:11:12 lol ^^ Feb 23 14:11:19 Pierre_: you simply call one on the file's path Feb 23 14:11:24 open Feb 23 14:11:50 hmm oki Feb 23 14:12:46 thank you very much for your help abelloni, but that means that there's no way to configure the battery charger and it will prolly be the same thing with other functinalities of this board Feb 23 14:12:54 humm.. Feb 23 14:13:01 fd = open("/sys/class/power/...", O_RDONLY); Feb 23 14:13:24 Pierre_: no, I'd say that the battery charger is the only poorly supported thing on that SoC Feb 23 14:13:54 pretty much everything else is supported in the linux mainline Feb 23 14:14:22 I would also advise trying to use a recent kernel for that SoC instead of the ancient 2.6.35 Feb 23 14:14:51 I spent so much time with readelf and objdump to try to locate a lib with the keyword ddi_bc_hw in it and to try to link it desperately to my eclipse project Feb 23 14:15:40 but that is definately not the right way to develop a baattery charger app for sure ? Feb 23 14:16:09 Oki i'll update my kernel i'm working on 2.6.35 right now Feb 23 14:19:40 anyways abelloni thank you very much to have taken the time to answer me, I was completely stuck Feb 23 14:19:51 have a nice day ;) Feb 23 14:23:22 Pierre_: I'd say that you can contact us (Free Electrons) if you need further support on your BSP but I don't know if I can do that kind of advertisment here ;) Feb 23 14:32:51 noone an idea? Feb 23 14:37:18 I had the same question than you got, sorry, I can't help you Feb 23 15:26:28 can we delete tasks like do_configure by deltask within our recipes? Feb 23 16:27:50 man, trying to find a moment when you can actually use all the upstream layers master branches and they aren't de-synced from oe-core is like playing the lottery Feb 23 16:28:07 but i hate to deal with forking it, so.. Feb 23 16:34:51 Hey! I'm trying to get Poky working for a Congatec QA3 board with an J1900 processor. I've succesfully compiled the core-image-base for a generic x86_64 machine. It boots, but I can't see my network interface (eth0) nor the internal mmc (/dev/mmcblk0). I do see the ethernet controller with 'lspci', not sure where I should find if I can see the mmc. Where should I go from here? I'm afraid I'm quite new to developing in general Feb 23 16:36:26 They both worked on the most recent Debian distro, but I'm afraid someone destroyed the mmc it was on :P Hope to get that running again tomorrow Feb 23 16:39:47 Guest93015, get the old system booted and look at "lsmod" to see what drivers are loaded. The "lspci -k" also does something similar. Feb 23 16:40:16 then you'll have to ensure your kernel build has those related Kconfig options turned on, so that those drivers are built in. Feb 23 16:40:44 nothing really specific to yocto about this aside to how you'd insert the Kconfig options you want once you've tracked them down. Feb 23 16:48:31 Okay. The most clean thing to do would be to make an BSP for yocto then I suppose. I've created an BSP with the script, so I've got the file /meta-QA3/recipies-kernel/linux-yocto_3.14.bbappend. How should I put kernel options here? I remember with other tools we had a .config file with lines like "CONFIG_MTD_DOC2000=m" in them. Is this the same stuff? Feb 23 17:06:06 hmm, pulseaudio defaults to a systemd user service upstream? that's a problem for us, particularly when pam isn't enabled, since the user bits won't be run Feb 23 17:08:32 hi kergoth Feb 23 17:08:34 hmm, rburton isn't here Feb 23 17:09:27 hey Feb 23 17:12:02 someone said systemd and user sessions? Feb 23 17:12:20 [17:06] hmm, pulseaudio defaults to a systemd user service upstream? that's a problem for us, particularly when pam isn't enabled, since the user bits won't be run Feb 23 17:12:25 Hi rburton Feb 23 17:13:03 kergoth: yes, they migrated to a user service. after years of moaning that you shouldn't run PA as root i guess they decided to discourage that more. Feb 23 17:13:36 kergoth: adding back the system unit should be trivial, i doubt they actually changed the code. Feb 23 17:13:39 hey ulf` Feb 23 17:14:27 rburton: yeah, the unit looks like it's fine either way, and they have a --with-systemduserunitdir= option (btw, we have to set it, right now it's installing it to ${libdir}/systemd, not ${systemd_unitdir}), so one could easily override that to system if we make it a variable in the recipe Feb 23 17:14:40 * kergoth is updating the meta-mentor bbappends for the 6.0 update Feb 23 17:15:12 kergoth: well patches welcome :) Feb 23 17:15:19 yep, working on it now :) Feb 23 17:15:43 we've been carrying around a systemd unit file and init.d script for a little while, figured its about time to deal with that Feb 23 17:19:11 kergoth: whilst i'm editing base-files, any opinion on doing hostname ?= ${MACHINE}? Feb 23 17:19:16 (instead of =, as it is now) Feb 23 17:19:50 seems reasonable, makes it easier to set from config metadata. my only possible concern would be the un-namespaced variable name, but i highly doubt anyone is using 'hostname' anywhere, so should be fine Feb 23 17:20:12 totally agreed Feb 23 17:20:13 * rburton does it Feb 23 17:20:59 the only minor thing is the lowercase name, which doesn't really hold with our conventions where only the target path vars are lowercase, but there's no real reason for it do be done that way anyway.. Feb 23 17:21:54 hm Feb 23 17:22:22 maybe i'll keep it as = for the scopeness and document using hostname_pn-base-files Feb 23 17:22:32 instead of using ?= and it becoming a global variable Feb 23 17:24:10 alternatively, introduce a new config metadata variable which it obeys Feb 23 17:24:18 * kergoth doesn't feel strongly about any of this really :) Feb 23 17:24:23 no me neither Feb 23 17:24:34 minimal impact - i'll clean up the logic and add the docs Feb 23 17:24:39 at least nothing breaks for anyone then Feb 23 17:24:56 * kergoth nods Feb 23 17:30:09 rburton: hmm, you notice pulseaudio.inc is consistent in the use of ${PN} in the package variables? e.g. FILES_${PN}-server and SYSTEMD_SERVICE_${PN}-server, but RDEPENDS_pulseaudio-server, CONFFILES_pulseaudio-server Feb 23 17:31:49 kergoth: i didn't notice that. can you fix whilst you're there :) Feb 23 17:31:54 * kergoth nods Feb 23 17:32:12 er, obviously meant inconsistent :) Feb 23 18:38:45 humm.. okay.. i just want to build a simple kernel module for my already built rootfs. what do i have to do now? Feb 23 18:39:02 couldn't compile due to missing kernel headers... Feb 23 18:39:45 build in what context? are you making a recipe, or trying to do something manually out of tree? and are you building on target, or the build machine? Feb 23 18:44:53 can anyone here help with with writing a .bb recipe for screen? I have gotten past the licensing part but now need to write a do_configure () and can't find good documentation on it Feb 23 18:45:20 I'm trying to follow the linux from scratch installation for screen 4.2.1 http://www.linuxfromscratch.org/blfs/view/svn/general/screen.html Feb 23 18:45:38 why are you writing a recipe for something that's already in oe-core? Feb 23 18:45:42 http://layers.openembedded.org/layerindex/recipe/124/ Feb 23 18:47:09 I guess it could be a learning exercise? Feb 23 18:47:23 partly that Feb 23 18:47:35 I also searched for it and couldn't find it Feb 23 18:48:12 I'm using the edison which linked to opkg packages tested and installed and screen wasn't there Feb 23 18:48:27 the layer index is always the best bet to locate a recipe Feb 23 18:48:38 tested and installed is rather different criteria than "buildable" :) Feb 23 18:48:50 ok Feb 23 18:49:11 well I'd still like to build a recipe for 4.2.1 for screen as a learning exercise Feb 23 18:50:28 which could be a poor choice because the source files don't have a makefile.ac or a cmake Feb 23 18:50:33 most likely the existing recipe would work just fine. but i'd suggest reading the existing recipe Feb 23 18:51:12 screen is an autotools based buildsystem, so inherit autotools takes care of most of everything Feb 23 18:51:27 yeah I'm looking at it now. It inherits autotools which I didn't think was applicable for screen Feb 23 18:51:39 ok Feb 23 18:52:06 http://git.savannah.gnu.org/cgit/screen.git/tree/src/configure.in Feb 23 18:52:11 http://git.savannah.gnu.org/cgit/screen.git/tree/src/Makefile.in Feb 23 18:52:13 looks autoconf to me. Feb 23 18:52:33 old autoconf, admittedly, since its configure.in rather than configure.ac, but still autoconf Feb 23 18:54:04 oh Feb 23 18:54:17 well that explains it a little further Feb 23 18:54:37 so configure.in will still work with autotools then alright Feb 23 18:55:03 which makes it seem as though I do not need to do_configure file Feb 23 18:55:27 could I build it without using autotools? or would you say it's required? Feb 23 18:55:46 You won't have any makefiles if you don't use autotools Feb 23 18:55:57 They get generated Feb 23 18:56:57 if you mean without using the class, and writing hte tasks yourself, you'll be in for a world of pain Feb 23 18:57:05 cross-copmilation is non-trivial, and our classes handle it for you for common cases Feb 23 18:57:40 ok Feb 23 18:58:43 http://git.savannah.gnu.org/cgit/screen.git/tree/src/INSTALL gives you all the details as well if you haven't looked at that yet Feb 23 19:00:03 yes I've read that installation file in the source code. Feb 23 19:02:55 so in linux from scratch it lists pam as being optional so can I remove those dependencies from the .bb if I wanted? Feb 23 19:03:40 yes. again, if you read the existing recipe, it handles that. there's a package configuration option that lets you eanble or disable pam for it Feb 23 19:03:54 see the docs about PACKAGECONFIG and DISTRO_FEATURES for details Feb 23 19:04:51 ok well thanks for the link I'll poke around the link some more and see if I can create my own recipe Feb 23 19:20:45 kergoth, i just started using yocto for an embedded board and wanted to program a simple kernel module for it. since i don't have any idea how to use those recipes i thought, i may just compile my code like any other program using simple gcc call.. but it couldn't find any kernel headers in the built /usr/include Feb 23 19:21:14 yocto is self contained, and cross-compiles to a different architecture Feb 23 19:21:27 it doesn't use your build machine's gcc to build for the target at all, and it certainly doesn't touch /usr/include Feb 23 19:21:37 if you want to build a kernel module manually, you'll need to build an sdk with yocto and use that Feb 23 19:26:11 well, my local.conf has dev-pkgs activated and it also builds a cross compiler i can use Feb 23 19:26:31 i also built some simple applications with this cross image Feb 23 19:26:40 but i can't compile kernel modules.. Feb 23 19:27:32 however.. seems i have to learn how to build a receipe for my module.. but i didn't really find out how to do this yet.. Feb 23 19:28:40 https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules Feb 23 19:28:41 the cross compiler it builds is buried in tmp/sysroots/ Feb 23 19:28:49 its not for you to use, and it soudnds like you probably aren't anyway Feb 23 19:29:00 again, you'll need to build a yocto sdk and use that, or create ar ecipe Feb 23 19:29:56 at least, i have some toolchain layer. i don't use clean yocto but something that has been built on yocto by a swiss company for its computers Feb 23 19:30:45 okay.. it isn't that i don't want to build a receipe.. i just don't know where to start.. didn't understand the example yet ^^ Feb 23 19:33:24 maybe i just have to read more.. Feb 23 19:37:51 okay, don't know how but i managed to build the hello plugin Feb 23 20:40:12 kergoth: ping - do you know about PRSERV_HOST ? I tried to setup a networked PRSERV. But setting PRSERV_HOST in conf/local.conf does not connect to the bitbake-prserv on the remote machine. Any pointers ? Feb 24 02:44:10 where can i see the definition of do_patch? **** ENDING LOGGING AT Tue Feb 24 02:59:58 2015