| 00:07.41 | *** join/#oe dvhart_ (~dvhart@134.134.139.76) |
| 01:22.36 | *** join/#oe DJW|Home (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 01:32.55 | *** join/#oe ccube (ccube@nx.mindrunner.de) |
| 02:35.38 | *** join/#oe s3v3n62mm2 (~s3v3n62mm@p5DDC29E9.dip0.t-ipconnect.de) |
| 03:20.21 | *** join/#oe pompomJuice (~pompomJui@41.0.38.138) |
| 03:47.16 | *** join/#oe S_A (3df6bac6@gateway/web/freenode/ip.61.246.186.198) |
| 03:50.43 | S_A | Hi |
| 03:51.00 | S_A | I am trying to buildoe-core first time |
| 03:51.11 | S_A | getting error "chown: changing ownership of `/home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image/home/test/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/include/db_cxx.h': Operation not permitted |
| 03:51.23 | S_A | and afterwards so man chown errors |
| 03:51.31 | S_A | any suggestions what might have gone wrong |
| 03:51.32 | S_A | ? |
| 03:56.07 | *** join/#oe S_A (3df6bac6@gateway/web/freenode/ip.61.246.186.198) |
| 04:39.43 | *** join/#oe belen (~Adium@190.227.187.81.in-addr.arpa) |
| 05:27.21 | *** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 05:48.42 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 06:02.09 | *** join/#oe likewise (~likewise@h230004.upc-h.chello.nl) |
| 06:03.25 | *** join/#oe likewise (~likewise@h230004.upc-h.chello.nl) |
| 06:04.29 | *** join/#oe clio (~andrej@85.159.109.222) |
| 06:33.52 | *** join/#oe tgall_foo (~tgall@68.69.84.18) |
| 06:33.52 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 06:42.58 | *** join/#oe kroon (~kroon@fw.mikrodidakt.se) |
| 06:52.16 | *** join/#oe kroon (~kroon@fw.mikrodidakt.se) |
| 07:04.53 | *** join/#oe woglinde (~henning@fb-n15-11.unbelievable-machine.net) |
| 07:09.17 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-xipthmmwnueujcfe) |
| 07:13.32 | *** join/#oe ant_work (~ant__@host54-128-static.10-188-b.business.telecomitalia.it) |
| 07:21.39 | *** join/#oe hexsane (~quassel@ip174-71-72-34.om.om.cox.net) |
| 07:25.15 | *** join/#oe stefan__ (~chatzilla@5.28.68.25) |
| 07:27.32 | *** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
| 07:33.49 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:38.03 | *** join/#oe nullpuppy (~dustin@freematrix/staff/nullpuppy) |
| 07:52.17 | mago_ | what is the purpose of DEPENDS_class-native? |
| 07:52.26 | mago_ | is there a package called "class-native"? |
| 07:53.08 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 07:53.51 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 07:54.28 | ndec | mago_: it's to specify a DEPENDS when the recipe is built for 'native' |
| 07:54.52 | ndec | e.g. some recipes are used on the target, some are used on the host too. |
| 07:54.56 | *** join/#oe dlan (~dennis@116.228.88.131) |
| 07:54.56 | *** join/#oe dlan (~dennis@gentoo/developer/dlan) |
| 07:55.31 | *** join/#oe Rick (5a509091@gateway/web/freenode/ip.90.80.144.145) |
| 07:55.57 | mago_ | ndec, so if I've added BBCLASSEXTEND = "native" (enabling my recipe to be built as both myrecipe and myrecipe-native), will it ignore RDEPENDS when building for -native, and instead use RDEPENDS_class-native ? |
| 07:56.39 | Guest83683 | trying to build libav9.13 for arm (colibri-t20) im getting ERROR: ERROR: objcopy failed with exit code 1 (cmd was 'arm-angstrom-linux-gnueabi-objcopy' --only-keep-debug '/home/rick/oe-core/build/out-eglibc/work/armv7ahf-vfp-angstrom-linux-gnueabi/libavdep/9.13-r0/package/usr/lib/libavformat.so.54.20.4' '/home/rick/oe-core/build/out-eglibc/work/armv7ahf-vfp-angstrom-linux-gnueabi/libavdep/9.13-r0/package/usr/lib/.debug/libavformat.so. |
| 07:56.50 | Guest83683 | can someone help me fix this pls? |
| 07:57.06 | ndec | mago_: probably. though this is a good question... not sure how DEPENDS and DEPENDS-class_native are combined together. |
| 07:57.31 | ndec | mago_: i would recommend doing a quick test to try out..and confirm. |
| 08:02.01 | ant_work | https://lists.yoctoproject.org/pipermail/yocto/2013-September/016302.html |
| 08:02.06 | ant_work | mago_: ^ |
| 08:02.47 | ant_work | the overrides are processed later so th emain variable is reset |
| 08:03.32 | ant_work | RDEPENDS_class* is not a good idea |
| 08:05.26 | ant_work | RDEPENDS -> RDEPENDS_${PN} |
| 08:13.23 | mago_ | ant_work, i see. so this _class-native-thing is just a way to add additional (or override) the dependencies, IF building for native instead of target? |
| 08:13.56 | ant_work | you need that in case of BBCLASSEXTEND typically |
| 08:14.32 | mago_ | i thought that if I do BBCLASSEXTEND, it will automatically change the dependencies so that it depends on -native version of all dependencies? |
| 08:15.36 | ant_work | hm, no, it's not so easy |
| 08:15.45 | ant_work | check code in native.bbclass |
| 08:16.00 | ant_work | python native_virtclass_handler () { |
| 08:19.50 | mago_ | hm. map_dependencies() seems to do what I meant? |
| 08:20.05 | ant_work | it does in most cases, yes |
| 08:20.24 | ant_work | just grep the metadata to find the exceptions |
| 08:21.13 | ant_work | but th eprinciple is valid for other extensins, i.e. your custom class |
| 08:22.53 | ant_work | (sorry the typos, this wireless kb is ugly) |
| 08:24.14 | mago_ | my problem is with a python module recipe called pyserial (http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/python/python-pyserial_2.4.bb). It RDEPENDS python-fcntl. If I customize the pyserial recipe with BBCLASSEXTEND = "native" (using a python-pyserial_%.bbappend-file), it complains that python-fcntl-native is not available. What would be the appropriate way to build python-pyserial natively? python-fcntl is provided |
| 08:24.14 | mago_ | by python (as a package split), so would the appropriate solution here be to also add RDEPENDS_${PN}_class-native = "python-native" ? |
| 08:25.11 | mago_ | (what im trying to do is to build a recipe that needs pyserial-native, in case that was not clear from above) |
| 08:27.58 | ant_work | I think this is a similar example http://lists.openembedded.org/pipermail/openembedded-core/2013-May/078668.html |
| 08:30.20 | mago_ | should not all python modules have a RDEPENDS on python? |
| 08:30.30 | mago_ | (not just the appropriate modules) |
| 08:30.51 | mago_ | i think that would solve my problem, since the python RDEP would then be translated to python-native by map_dependencies() |
| 08:32.05 | ant_work | I'd say, check the python recipes in oe-core |
| 08:32.53 | *** join/#oe roric (~roric@89-160-176-89.du.xdsl.is) |
| 08:35.51 | mago_ | thanks |
| 08:38.05 | Guest83683 | anyone knows why "split and trip files" could fail? |
| 08:42.00 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 08:42.18 | *** join/#oe nslu2-log (~nslu2-log@140.211.169.184) |
| 08:44.10 | *** join/#oe anarsoul (~anarsoul@178.124.194.242) |
| 08:44.17 | ant_work | Guest83683: you should really check the logs carefully |
| 08:44.36 | ant_work | quick google gave some matches about the possible reasons |
| 08:44.43 | ant_work | anyway, to silence it, try include INHIBIT_PACKAGE_STRIP = "1" |
| 08:44.54 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 08:45.04 | ant_work | s/include/add/ |
| 08:45.23 | Guest83683 | ant_work: already tried INHIBIT_PACKAGE_STRIP |
| 08:45.41 | ant_work | then you have to inspect the workdir |
| 08:45.43 | Guest83683 | gives me QA issues architecture did not match |
| 08:45.48 | ant_work | and the .run files |
| 08:46.29 | ant_work | I'm sorry I don't build for armv7ahf |
| 08:47.12 | ant_work | still, arch mismatch should be really easy to spot |
| 08:47.26 | ant_work | (very strange I'd say) |
| 08:49.54 | mago_ | ant_work, doesn't the map_dependencies() kind of break if a recipe depends on package splits? lets say A provides packages A-a, A-b and A-c. My package B depends on A-a and A-b. map_dependencies() translates that into A-a-native and A-b-native, but does not know that the dependency it really needs to add is A-native ? |
| 08:50.39 | *** join/#oe belen (~Adium@192.198.151.43) |
| 08:50.44 | mago_ | because A will not PROVIDES A-a-native unless you try to build A-native, I guess? |
| 08:53.11 | ant_work | sorry, phone call |
| 08:53.32 | ant_work | the DEPENDS are on the recipe, not on the providede package |
| 08:53.50 | ant_work | you RDEPEND on package |
| 08:54.05 | ant_work | so B DEPENDS on A |
| 08:54.17 | ant_work | at buildtime |
| 08:54.47 | ant_work | different is at runtime |
| 08:54.56 | mago_ | what is the difference between a package and a recipe? |
| 08:55.56 | *** join/#oe anarsoul (~anarsoul@178.124.194.242) |
| 08:56.33 | ant_work | the recipe A PACKAGES foo, bar, baz |
| 08:59.24 | mago_ | so if RDEPEND refers to the packages, why will not python-fcntl-native be available in my native build, when it is available for a target (non-native) build? |
| 08:59.43 | ant_work | found the thread.. |
| 08:59.45 | ant_work | https://www.mail-archive.com/yocto@yoctoproject.org/msg15184.html |
| 09:01.27 | Guest83683 | ant_work: dont be sorry, im really new to this so im trying stuff |
| 09:03.30 | ant_work | Guest83683: you are using Angstrom and armv7ahf, I really can't help here |
| 09:04.23 | ant_work | have you tried to clean and rebuild? |
| 09:04.45 | *** join/#oe belen (~Adium@192.198.151.43) |
| 09:09.39 | ant_work | Guest83683: in oe-core libav was updated 2 months ago |
| 09:10.39 | ant_work | maybe Angstrom is needing the old version? Wild guess |
| 09:11.45 | mago_ | ant_work, thanks for the link, really useful. However, I still don't understand why I cannot RDEPEND on python-fcntl-native without also doing RDEPEND_${PN}_class-native = "python-native" ? how come Bitbake cannot figure out that there is a package called python-fcntl-native? |
| 09:14.37 | mago_ | i assume bitbake parses every recipe and know which packages are available, and which ones are also available as native variants |
| 09:14.42 | Guest83683 | ant_work: I tried to do some cheating by using the 0.8 version recipe and just modifying the license, URI etc.. and it didnt fail, ill see if it actually works |
| 09:19.32 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 09:24.11 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 09:29.57 | *** join/#oe stefan__ (~chatzilla@5.28.68.25) |
| 09:31.51 | ant_work | mago_: with python and perl there is sort of chicke-egg problem |
| 09:32.12 | ant_work | mago_: check out the python-native_2.7.3.bb recipe |
| 09:33.49 | mago_ | i see, so they do two completely different recipes for python and python-native? |
| 09:34.39 | ant_work | yes |
| 09:34.56 | ant_work | check i.e. PROVIDES vs. RPROVIDES |
| 09:35.43 | *** join/#oe g1zer0 (~gizero@host168-65-static.12-87-b.business.telecomitalia.it) |
| 09:37.55 | *** join/#oe dlan (~dennis@gentoo/developer/dlan) |
| 09:39.23 | mago_ | btw, ant_work, the link you have me indicates that a RDEPENDS adds a dependency on otherpackage.do_write_package() for do_build(). When I do RDEPENDS on my python modules and then build the -native variant, the modules are not processed (although it seems to verify that they exist). The result is that my recipe is built, but none of the required python modules are available in the site-packages of my python-native. There is no error. If I manually |
| 09:39.23 | mago_ | build the required modules, e.g. bitbake python-mymodule-native, it becomes available in site-packages. I also checked, the python module recipes do not have a do_write_package task, could this be related? Is it not correct to assume that a RDEPENDS is suppose to be installed? |
| 09:39.27 | mago_ | (into the sysroot) |
| 09:41.33 | ant_work | hm, no, RDEPENDS just means it will be BUILT |
| 09:43.35 | mago_ | in that case, how am I suppose to get a working system with any python module? every python module in meta-openembedded only RDEPENDS on other modules. Do I have to go through them all and manually calculate the dependency tree and add it to my DEPENDS? |
| 09:46.19 | *** join/#oe belen (Adium@nat/intel/x-ykolabzxduesporv) |
| 09:46.28 | mago_ | ant_work, im not even getting a work-dir for the python modules in my RDEPENDS. It's like it's not even bothering with unpacking them? |
| 09:47.12 | ant_work | are you talking about target or buildhost now? |
| 09:47.46 | mago_ | native. but is the behavior of RDEPENDS different depending on if building for target or native? |
| 09:49.29 | ant_work | the mechanism is the same |
| 09:51.10 | mago_ | i'm pretty sure the modules are automatically installed onto the target rootfs if I do a target build, even if the recipes only use RDEPENDS |
| 09:53.53 | ant_work | sure, if you add package A to your image and it RDEPENDS on B, B will be added to target image. Or afterwards if you install i.e. A.opkg then B.opkg will be installed |
| 09:54.34 | mago_ | so adding stuff to your image adds special treatment to your RDEPENDS? |
| 09:54.53 | ant_work | depends, shlibs are automatically detected |
| 09:54.54 | mago_ | i guess this is handled by the image recipe, ie going through the RDEPENDS list and install it? |
| 09:55.39 | ant_work | bitbake does that |
| 09:56.19 | ant_work | you should really read the manual about these vars |
| 09:56.29 | ant_work | and remember that python is a special case ;) |
| 09:56.42 | mago_ | yeah, i feel confused :) i'll do that! thanks, now it's lunchtime! |
| 09:57.30 | ant_work | you can inspect the dependency tree. obviously it is possible that there is some bug |
| 09:58.01 | mago_ | one last question though: if you wanted a package to be built for native, and end up in the deployment directory, where would you put the dependency? i'd like this to happen for a specific image |
| 09:58.24 | mago_ | i.e if you build core-image-minimal for machine X, it builds package Y for host aswell |
| 09:58.39 | ant_work | mago_: the packages are for the target |
| 09:59.01 | ant_work | remember natives are only used to build the toolchain |
| 10:00.03 | ant_work | http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html#ref-classes-native |
| 10:27.58 | *** join/#oe hexsane (~quassel@ip174-71-72-34.om.om.cox.net) |
| 10:30.51 | *** join/#oe AlexVaduva (c1ca1642@gateway/web/freenode/ip.193.202.22.66) |
| 10:41.35 | mago_ | ant_work, okay, so you're saying that if i want to create a tool that is available inside the buildtree, i should not create a package for it? |
| 10:49.11 | *** join/#oe dlan (~dennis@gentoo/developer/dlan) |
| 10:52.32 | mago_ | sorry, when i said i want to package something for native, i just meant to provide a bitbake package.. it does not need to package into a file (such as a ipk) or anything |
| 10:55.06 | *** join/#oe dlan (~dennis@116.228.88.131) |
| 10:55.06 | *** join/#oe dlan (~dennis@gentoo/developer/dlan) |
| 10:59.46 | woglinde | mago right |
| 11:00.07 | woglinde | perhaps you need to provide it for native-sdk |
| 11:02.18 | mago_ | woglinde, the script im trying to integrate is a deployment script. Ideally, i'd like the user to be able to run it without installing any python modules in his or hers system, instead the OE tree should provide the python modules (and also python itself). The user can then run the script from the deployment directory to deploy the generated binaries to a device. Is this something I can achieve with OE? is it a "supported" use-case? The script itse |
| 11:02.18 | mago_ | lf is only there as a convenience, there is nothing else depending on it. |
| 11:03.46 | woglinde | ? |
| 11:04.24 | woglinde | hm |
| 11:04.32 | woglinde | thats not a normal usecase |
| 11:04.47 | mago_ | i'm starting to realize this :) is it a bad use-case? |
| 11:04.54 | woglinde | and if inherit rm_work is set there bill not binaries in the end |
| 11:05.04 | woglinde | ups there will be no |
| 11:05.32 | mago_ | so maybe i should keep this script outside the OE build tree? |
| 11:05.36 | woglinde | provide an image with all included or set up a package feed |
| 11:05.55 | woglinde | where uses can easily do opkg update install |
| 11:06.04 | woglinde | mago yes |
| 11:07.08 | mago_ | perhaps it is better to provide a .deb-file for the users to install on their system, rather than messing around with OE |
| 11:07.41 | mago_ | can opkg also be used for native packages? |
| 11:10.53 | woglinde | mago again what is your usecase? |
| 11:11.04 | woglinde | I can not see a clear one |
| 11:13.05 | mago_ | i want to provide a convenient script for the users that allows deploying OE generated binaries (uImage, rootfs etc) to a device. This (python) script depends on a few other python modules, which are not installed by default on an Ubuntu system. So I thought I could instead provide this script through my build tree, so when a user has built his binaries, there will also be a copy of the deployment script, and all the required modules are installed |
| 11:13.05 | mago_ | and ready to use using the OE provided python version |
| 11:13.46 | mago_ | so once the build has finished for a user, one can just run a command such as: cd tmp-eglibc/deploy/images/asdf/ && ./deploy_stuff.py -i 192.168.1.5 |
| 11:14.50 | mago_ | the only reason to why i want to keep my script inside the OE buildtree is because I was hoping it would allow the user to run it without having to install anything |
| 11:14.57 | mago_ | so it basically becomes linux agnostic |
| 11:22.34 | ant_work | mago_: sry, ws away |
| 11:22.45 | ant_work | mago_: normally it is the other way |
| 11:23.12 | ant_work | your script is pushing (ssh or ftp ?) 'files' on target |
| 11:23.32 | ant_work | normal case is, the package manager on target §(opkg i.e.) pulls the packages from a feed |
| 11:24.23 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 11:25.13 | ant_work | the packages and the eventual dependencies |
| 11:27.36 | ant_work | any native |
| 11:28.25 | ant_work | native are typically of different ARCH |
| 11:28.51 | mago_ | ant_work, this script deploys boot loader on empty devices so running the package manager on target is not an option |
| 11:29.06 | mago_ | it deploys boot loader and the inital system (linux+rootfs+dtb) |
| 11:30.05 | mago_ | so this script transfers the SPL bootloader using x-modem, then sends the full u-boot over Y-modem and finally launches a TFTP server and transfers the rest over network, which is finally written to NAND |
| 11:30.36 | ant_work | ok, I see |
| 11:31.54 | mago_ | but the more I think of it, keeping this outside the OE tree makes sense. I'm basically asking for a way to make the buildsystem generate a script which is not needed by the build process itself, and it is not included in the target filesystem, and it shall be built for the host. It doesn't make sense from the buildsystem perspective, I guess |
| 11:32.32 | ant_work | we are all in similar circumstances: the built kernel/rootfs must be somehow flashed |
| 11:33.40 | ant_work | it all depends on your bootloader |
| 11:33.53 | mago_ | i just vaguely recall that some part of Yocto is capable of generating virtual machine images "build appliances". If i understand these correctly, it is just a virtual machine that users can boot to run OpenEmbedded. They should fall under the same category of tasks, its something being built for the users as a convenience, not so much because the build system needs it |
| 11:34.06 | ant_work | some devices can be switched in 'usb' mode and get flashed with custom tools |
| 11:34.13 | *** join/#oe marek_ (~marek@81.89.61.168.vnet.sk) |
| 11:34.18 | ant_work | other devices expect a pre-formatted SD card |
| 11:34.29 | ant_work | routers have/had just tftp |
| 11:34.33 | mago_ | ant_work, yes, but regardless of how your boot loader works, you will need tools available on the machine to do it. I'm just looking for a way to get those tools into place |
| 11:34.38 | ant_work | so there is a vaste panorama |
| 11:34.54 | marek_ | hi, I've asked on #yocto but no reply so sorry for double asking: is it possible to use update-rc class to remove package specific S*files and keep only script in /etc/init.d? |
| 11:35.11 | mago_ | if its a usb bootloader, you need dfu, if your device runs a tftp client, you need a tftp server etc |
| 11:36.34 | ant_work | often you can use mtd-utils and flash from shell |
| 11:36.49 | ant_work | it all depends on device/bootloader |
| 11:37.16 | ant_work | you might think about an autoinstaller |
| 11:37.29 | mago_ | ant_work, sure, but you still need mtd-utils on your host? would you add that as a ASSUME_PROVIDED, or would you have OE build it for you? |
| 11:37.41 | ant_work | i,.e. a kernel embedding an initramfs wjth flasher+images |
| 11:38.31 | ant_work | mago_: some natives are installed jut choosing the jffs2/ubifs imagetypes |
| 11:39.24 | ant_work | you can add i.e. flashcp or ubiformat in your cpio |
| 11:39.30 | mago_ | ant_work, still talking about completely empty devices. we only have the bootrom level bootloaders to talk to; i agree that once you have u-boot in place, you have a lot more options in how to transfer the rest. That's not the problem, it's how to get the initial bootloader onto the device |
| 11:40.03 | mago_ | our only option is to send programs over x-modem, and in order to do that we need a x-modem tool on the host |
| 11:40.09 | ant_work | I don't work in a factory but suppose they have some jtag multi-flashers |
| 11:40.16 | ant_work | how many devices? |
| 11:40.57 | mago_ | ant_work, well, our production uses serial. we're talking thousands of units |
| 11:41.04 | ant_work | argh |
| 11:41.09 | ant_work | I see |
| 11:42.06 | ant_work | it all remembers my old Zyxel router |
| 11:42.13 | mago_ | and we are quite happy with serial/x-modem, my problem is still that i need to make a x-modem tool available on the host,, and it'd be really nice if OpenEmbedded could do that for me |
| 11:42.43 | *** join/#oe ldnunes (~ldnunes_@177.35.70.10) |
| 11:43.00 | mago_ | well your zyxel router probably also had only very few boot options when the flash was empty. Once U-boot is up, you can flash it using any method you want, tftp, usb, serial, even HTTP |
| 11:43.56 | mago_ | another use-case is if the device is bricked, this deployment script is capable of unbricking any device since it does not rely on _any_ software in the device. It only relies on the bootrom code which is hardcoded into the ASIC |
| 11:44.10 | ant_work | mago_: that code can boot a linux kernel? |
| 11:44.45 | ant_work | or can only chainload to a bootloader? |
| 11:45.13 | mago_ | ant_work, it can run a 64kb program, with 32 kb of RAM. What you do is boot the u-boot SPL (a tiny version of uboot). It will setup the DDR and everything. You then transfer the full U-boot, which is capable of writing to NAND, tftp and everything else. From there you can boot Linux |
| 11:45.30 | mago_ | the bootrom code will never use the DDR, so you are limited to on-chip memory |
| 11:46.39 | ant_work | is it a mips32? |
| 11:46.51 | mago_ | no :) |
| 11:47.04 | mago_ | this is how 99% of all SoCs work |
| 11:47.14 | ant_work | I have recently seen smthg similar but specific |
| 11:47.33 | ant_work | to jz4770 |
| 11:47.56 | ant_work | they developed a small 2nd stage bootloader |
| 11:48.07 | ant_work | mininit |
| 11:48.20 | ant_work | anyway |
| 11:48.33 | ant_work | who wil lupdate the device? the users? |
| 11:49.39 | mago_ | yeah, mostly the developers who get brand new hardware. the production facility will run the same script, but will of course not use OE. So the use-case is looking to solve is for developers |
| 11:50.01 | mago_ | flashing bootloader to virgin devices, or unbricking devices |
| 12:04.57 | marek_ | anybody? |
| 12:08.09 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 12:17.15 | woglinde | mago_ provide a native-sdk which has the stuff inside |
| 12:17.34 | woglinde | thats the closest I can think of |
| 12:17.41 | woglinde | to achieve it |
| 12:18.06 | woglinde | but there are some corner cases getting the image out of the deployment dir and so on |
| 12:18.13 | mago_ | so i will get a installer shellscript in deploy/sdk? or how does a native-sdk work? |
| 12:18.36 | woglinde | read the yocto documentation |
| 12:40.04 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
| 12:44.52 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 12:57.16 | Crofton | koen, ping |
| 12:57.23 | koen | pong |
| 12:57.43 | Crofton | hey, I'm fixing a commit messgae for the postgress autfoo to usse pkgconfig |
| 12:57.56 | Crofton | and you wanted to know more about the pg* stuff |
| 12:58.09 | koen | right |
| 12:58.19 | Crofton | about all I can figure is they are filtering for some things from the output of xml-config |
| 12:58.36 | koen | right again |
| 12:58.41 | Crofton | or do you know somethign clever they are doing? |
| 12:58.47 | koen | I still say the filtering is stupid and misguided |
| 12:58.56 | koen | it will drop -isystem |
| 12:58.57 | Crofton | the pg processing? |
| 12:59.04 | koen | yes |
| 12:59.14 | Crofton | I just dropped it and used output of pkgconfig |
| 12:59.52 | Crofton | so pretty much say the filtering was overly complicated and stop worrying about it :) |
| 13:00.58 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 13:01.04 | *** join/#oe msm (~msm@cpe-72-182-100-192.austin.res.rr.com) |
| 13:01.13 | koen | as long as you mention it in the commit message :) |
| 13:09.24 | *** join/#oe trondeau (~trondeau@c-174-62-214-216.hsd1.vt.comcast.net) |
| 13:09.49 | *** join/#oe kroon (~kroon@fw.mikrodidakt.se) |
| 13:15.03 | *** join/#oe fusman (~fahad@39.42.132.182) |
| 13:15.45 | *** join/#oe falk0n (~falk0n@a85-138-89-15.cpe.netcabo.pt) |
| 13:18.09 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 13:21.33 | *** join/#oe fusman (~fahad@39.42.132.182) |
| 13:23.02 | *** join/#oe fusman (~fahad@39.42.132.182) |
| 13:26.40 | *** join/#oe s3v3n62mm (~s3v3n62mm@p5DDC29E9.dip0.t-ipconnect.de) |
| 13:28.16 | *** join/#oe thaytan (~thaytan@113.94.233.220.static.exetel.com.au) |
| 13:40.28 | *** join/#oe mario-go` (~user@email.parenteses.org) |
| 13:41.40 | *** join/#oe diego_ (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 13:43.04 | *** join/#oe EsbenH_ (~esben@hugin.dotsrc.org) |
| 13:43.15 | *** join/#oe uwe_mobile (~uwe@static.88-198-8-117.clients.your-server.de) |
| 13:44.07 | *** join/#oe rtollert_ (~rtollert@130.164.62.31) |
| 13:44.29 | *** join/#oe dany1 (~Thunderbi@sestofw01.enea.se) |
| 13:46.57 | *** join/#oe sr105|aw` (~sr105@65349hfc19.tampabay.res.rr.com) |
| 13:47.16 | *** join/#oe Rootert_ (~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl) |
| 13:47.17 | *** join/#oe XorA_ (~XorA@www.xora.org.uk) |
| 13:47.53 | *** join/#oe dlan (~dennis@116.228.88.131) |
| 13:47.53 | *** join/#oe dlan (~dennis@gentoo/developer/dlan) |
| 13:48.35 | RIcko | how do I use ASSUMED_PROVIDED to add native depends to a recipe? |
| 13:48.48 | *** join/#oe pdp7 (~pdp7@asciipr0n.com) |
| 13:50.23 | *** join/#oe contempt (~contempt@unaffiliated/contempt) |
| 13:50.31 | *** join/#oe nullpuppy (~dustin@freematrix/staff/nullpuppy) |
| 13:53.21 | *** join/#oe dlan (~dennis@116.228.88.131) |
| 13:53.21 | *** join/#oe dlan (~dennis@gentoo/developer/dlan) |
| 13:54.51 | *** join/#oe anarsoul|2 (~anarsoul@46.28.103.46) |
| 13:54.51 | *** join/#oe aloril_ (~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) |
| 13:54.59 | *** join/#oe darkschneider (~gab@93-32-34-252.ip31.fastwebnet.it) |
| 13:55.07 | *** join/#oe denix (~denix@pool-71-191-205-189.washdc.fios.verizon.net) |
| 13:56.47 | *** join/#oe kscherer (~kscherer@128.224.252.2) |
| 13:57.06 | *** join/#oe SorenHolm (~quassel@5634f347.rev.stofanet.dk) |
| 13:57.53 | *** join/#oe uwe_ (~uwe_@ipservice-092-211-041-018.pools.arcor-ip.net) |
| 13:58.10 | *** join/#oe Daemon404 (~who_knows@cpc21-newt31-2-0-cust123.newt.cable.virginm.net) |
| 13:58.34 | *** join/#oe bencoh (~bencoh@nautica.notk.org) |
| 13:58.38 | RIcko | where and how do i specify the path to local dependencies? |
| 13:58.55 | woglinde | normaly you dont |
| 13:59.19 | woglinde | when bitbake is running the PATH will be altered to use the sysroot |
| 13:59.24 | woglinde | before host |
| 14:01.13 | *** join/#oe Anarky (~Anarky@136.217.123.78.rev.sfr.net) |
| 14:05.36 | *** join/#oe bencoh (~bencoh@unaffiliated/bencoh/x-184637) |
| 14:06.21 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
| 14:09.06 | *** join/#oe iwamatsu (~iwamatsu@www1015ue.sakura.ne.jp) |
| 14:09.08 | *** join/#oe blindvt_ (~brf@91-119-109-133.dynamic.xdsl-line.inode.at) |
| 14:10.50 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
| 14:13.07 | *** join/#oe dlan (~dennis@116.228.88.131) |
| 14:13.07 | *** join/#oe dlan (~dennis@gentoo/developer/dlan) |
| 14:21.43 | *** join/#oe blitz00 (~stefans@unaffiliated/blitz00) |
| 14:23.47 | *** join/#oe _ao2 (~ao2@host125-192-dynamic.3-87-r.retail.telecomitalia.it) |
| 14:27.40 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 14:29.36 | *** join/#oe belen1 (~Adium@192.198.151.43) |
| 14:42.13 | *** join/#oe staylor (~staylor@mail.au-zone.com) |
| 14:49.52 | *** join/#oe fusman (~fahad@39.42.132.182) |
| 14:53.30 | *** join/#oe ant_home (~andrea@95.236.252.199) |
| 15:01.07 | *** join/#oe dvhart_ (dvhart@nat/intel/x-mfctpuqvtnbhgjvc) |
| 15:03.28 | *** join/#oe adelcast (~adelcast@130.164.62.224) |
| 15:05.28 | *** join/#oe roric (~roric@89-160-176-89.du.xdsl.is) |
| 15:05.57 | *** join/#oe ladu (~pi@h52n6-fk-a12.ias.bredband.telia.com) |
| 15:08.38 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 15:10.11 | kroon | woglinde, hey, just fyi, it seems at least on daisy, "perf" still has a rdependency on perl. looks like cpan-base.bbclass adds it to RDEPENDS_${PN} |
| 15:10.57 | woglinde | kroon uhm |
| 15:11.41 | woglinde | kroon I was sure I could install perf with perl |
| 15:11.45 | woglinde | but I will test it again |
| 15:11.52 | woglinde | till later |
| 15:16.24 | kroon | I started looking into it, maybe something like s/+=/= in the RDEPENDS of the perf recipe |
| 15:23.21 | *** join/#oe Daemon404 (~who_knows@pdpc/supporter/student/Daemon404) |
| 15:36.41 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
| 15:50.50 | *** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net) |
| 15:53.23 | mago_ | are there any tools to integrate software coming from .deb files (with proprietary software) into a OE build? |
| 16:01.25 | *** join/#oe dvhart_ (dvhart@nat/intel/x-mnerletvdhavbayx) |
| 16:04.38 | *** join/#oe belen (~Adium@192.198.151.43) |
| 16:12.14 | *** join/#oe awozniak (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 16:32.20 | *** join/#oe ao2__ (~ao2@host125-192-dynamic.3-87-r.retail.telecomitalia.it) |
| 16:35.19 | *** join/#oe dvhart_ (~dvhart@134.134.137.71) |
| 16:48.30 | *** part/#oe WarheadsSE (~WarheadsS@50.164.115.22) |
| 17:02.04 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 17:24.28 | *** join/#oe lct_ (ae2d78d1@gateway/web/freenode/ip.174.45.120.209) |
| 17:26.21 | lct_ | Can anyone help me with an openembedded recipe build? I am getting a "QA Issue: Architecture did not match (3 to 62)", not sure if this is the right place to go for this... |
| 17:32.12 | kergoth | it's telling you the problem |
| 17:32.19 | kergoth | the binaries you built weren't for what you're targeting |
| 17:32.25 | kergoth | e.g. it built x86 binaries which wont run on your arm target |
| 17:32.33 | kergoth | so the build didn't obey our variables (CC, CFLAGS, etc) |
| 17:34.52 | lct_ | Sorry, I'm failry inexperienced, I'm an intern learning this on my own, is there any way you can help me decide how to correct it so that it will build it for the right machine architecture? |
| 17:36.50 | lct_ | My recipe is located at https://github.com/wolfSSL/meta-wolfssl/tree/master/recipes-wolfssl/benchmark |
| 17:37.12 | kergoth | lct_: there's nowhere near sufficient information. how we make a buildsystem obey our variables is completely dependent on the type of buildsystem and the particular implementation. its a case by case thing, it varies from one piece of software to the next. |
| 17:37.39 | kergoth | oh, that's obvious then. you're manually using a compiler command instead of using our variables |
| 17:37.50 | kergoth | don't call clang, call ${CC}, and pass ${CFLAGS} and ${LDFLAGS} |
| 17:38.20 | kergoth | also, you don't have cyassl in your DEPENDS, so it wont be available to link against for hte target anyway |
| 17:39.02 | kergoth | the best bet is to just call out to the buildsystem of the softwar ein question rather than writing your compile commands in do_compile |
| 17:39.12 | kergoth | e.g. if it uses a makefile, bitbake will automatically call out to make |
| 17:39.33 | kergoth | oh, i see, the source is just the .c file |
| 17:39.48 | kergoth | yeah, in that case just run ${CC} directly with the correct arguments |
| 17:51.50 | lct_ | Thanks <kergoth>, I have changed my compile line but sadly, to no effect. |
| 17:52.02 | kergoth | then you didn't do so correctly, i'd say |
| 17:53.37 | lct_ | <PROTECTED> |
| 17:55.48 | lct_ | Perhaps I should not be using the location on my own machine for my .c file? |
| 17:56.56 | sr105 | Is there a faster way to test image_type classes? Also, it seems like bitbake is caching my class and not seeing changes. |
| 17:57.19 | kergoth | lct_: that would be a start, using the correct path. ${WORKDIR}/benchmark.c |
| 17:57.25 | kergoth | but i doubt thats cuasing your failure |
| 17:58.17 | kergoth | sr105: what are you changing, and what bitbake command are you running to vierfy the change? and did you examine the contents of the metadata as bitbake sees it to make sure it sees your change? (e.g. make sure no higher piroirty layer is overriding your class) |
| 17:58.21 | kergoth | sr105: see bitbake -e |
| 17:58.44 | kergoth | whenever something seems inexplicable, first step is to check our assumptions, and the first step with that when using bitbake is to make sure vars are set the way we think they are |
| 17:58.49 | kergoth | this is invaluable when debugging |
| 18:00.22 | sr105 | kergoth: I added my own image_types_mine.bbclass which is based on one from meta-fsl-arm. Their's builds an "sdcard" image file. I made one that generates a script in DEPLOY_IMAGE_DIR that will do the same to a card |
| 18:01.17 | sr105 | I created the class, so there shouldn't be any other IMAGE_CMD_sdcard-script vars to overrride mine. And I can tell from the generated output that it's running that it's not picking up changes |
| 18:01.25 | sr105 | I'll try -e |
| 18:01.28 | kergoth | okay, step one, make sure its set the way you think it is, and that its being inherited |
| 18:02.02 | kergoth | step two, make sure the do_rootfs task is being re-run, that is, make sure bitbake recognizes that a change to that variable means it needs to re-run do_rootfs task |
| 18:02.08 | sr105 | the inherit is in the MACHINE conf and it gives me a warning about running my image function |
| 18:02.22 | kergoth | okay, thats a good sign |
| 18:02.23 | sr105 | I tried -C rootfs to force that |
| 18:02.56 | sr105 | then tried -c cleansstate in case the image creation function is being cached |
| 18:02.57 | kergoth | if forcing a re-run of the task doesn't help, then you have something bigger going on |
| 18:03.03 | sr105 | k |
| 18:03.07 | kergoth | cleansstate doesn't matter for images, images aren't archived as sstate |
| 18:03.23 | sr105 | I didn't think so, but I thought it couldn't hurt. :) |
| 18:03.25 | kergoth | nods |
| 18:03.28 | kergoth | that's fair enough |
| 18:04.00 | kergoth | i was going to suggest that you could examine the run. script in ${WORKDIR}/temp/ for do_rootfs, but most of the do_rootfs work is in python in the python module now, so not sure how useful it is |
| 18:04.01 | sr105 | I'll dig a bit more. Having you tell me about sstate helps me cull that branch of investigation |
| 18:04.04 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 18:04.10 | kergoth | but in general its useful, since thats equivalent to what bitbake runs for the task |
| 18:04.13 | kergoth | nods |
| 18:04.47 | sr105 | I have the python libs and classes open in emacs right now. I used them to see what environment the functions run in and what vars would be available to me |
| 18:04.51 | kergoth | you could also add echo commands and examine the do_rootfs log |
| 18:05.01 | kergoth | to see if those lines are being run at all, to make sure it is indeed using the currnet version of your function |
| 18:05.11 | kergoth | nods |
| 18:05.31 | sr105 | Well, for now, bitbake generates a standalone script based on my function and is giving me a path to it in the warning |
| 18:05.56 | kergoth | ah, right, it's using exec_func for it. good |
| 18:06.22 | kergoth | is still somewhat used to how the image creation used to work, before the rework to the python module :) |
| 18:06.23 | sr105 | That's how I can tell it's not updating because I removed 90% of the function to try and narrow down on the error and 100% is in the output |
| 18:06.41 | sr105 | yeah. It's much cleaner now it seems |
| 18:07.33 | kergoth | bitbake only caches metadata in the up front full parse used for dependency analysis for runqueue generation |
| 18:07.41 | kergoth | when it runs the tasks, it re-parses the recipe anyway |
| 18:07.47 | kergoth | for config files, it goes by the timestamp on the file |
| 18:08.02 | kergoth | (by config, that also includes classes listed in INHERIT, as they end up in the config metadata to act globally) |
| 18:08.47 | kergoth | it's unlikely that its failing to reparse the class when it should, so bitbake -e should show the correct content |
| 18:08.54 | *** join/#oe nitink (~nitink@134.134.139.72) |
| 18:09.01 | kergoth | i'm guessing something is going wrong farther down the line, past the parsing and parse cache |
| 18:09.11 | kergoth | hey nitink |
| 18:15.19 | *** join/#oe Jafura (~Jean-Fran@2a02:2788:114:11ce:8571:5e51:e702:687c) |
| 18:18.17 | sr105 | I think bitbake -e was the trick. I forget about using that. It was a layer problem. There was a backup copy of the class. Ugh. Thank you. |
| 18:19.37 | nitink | Hi kergoth |
| 18:20.06 | kergoth | sr105: :) np |
| 18:20.15 | kergoth | sr105: bitbake-layers can be useful for diagnosing those sort of problems too |
| 18:25.16 | *** join/#oe dvhart (~dvhart@134.134.139.72) |
| 18:40.12 | sr105 | Note to self: create an empty image recipe for testing image classes. |
| 18:41.28 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 18:42.16 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 18:50.23 | *** join/#oe woglinde (~henning@f052225189.adsl.alicedsl.de) |
| 19:01.47 | *** join/#oe woglinde (~henning@f052225189.adsl.alicedsl.de) |
| 19:05.04 | *** join/#oe woglinde (~henning@f052225189.adsl.alicedsl.de) |
| 19:06.00 | *** join/#oe likewise (~likewise@h230004.upc-h.chello.nl) |
| 19:06.00 | *** join/#oe signal11 (esteban@abq.quaddro.net) |
| 19:06.18 | *** join/#oe woglinde (~henning@f052225189.adsl.alicedsl.de) |
| 19:14.07 | *** join/#oe jackmitchell (~Thunderbi@cbnluk-gw0.cambridgebroadband.com) |
| 19:17.45 | sr105 | Is there any way to put ${VAR} inside a function and not have bitbake expand it *before* running the script (including in script comments)? |
| 19:19.46 | *** join/#oe woglinde_ (~henning@g225128083.adsl.alicedsl.de) |
| 19:21.56 | *** join/#oe jackmitchell (~Thunderbi@cbnluk-gw0.cambridgebroadband.com) |
| 19:56.39 | *** join/#oe jackmitchell (~Thunderbi@cbnluk-gw0.cambridgebroadband.com) |
| 19:59.00 | *** join/#oe mago_ (~mago@c193-14-123-186.cust.tele2.se) |
| 19:59.57 | *** join/#oe mago_ (~mago@c193-14-123-186.cust.tele2.se) |
| 20:01.46 | *** join/#oe mago_ (~mago@c193-14-123-186.cust.tele2.se) |
| 20:12.44 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
| 20:16.08 | kergoth | sr105: nope. there's no escaping for bitbake variables |
| 20:16.19 | kergoth | sr105: if you're wanting to expand the shell variable, you can use $VAR, but otherwise your options are limited |
| 20:17.43 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 20:27.45 | *** join/#oe Crofton (~balister@pool-71-171-36-96.ronkva.east.verizon.net) |
| 20:28.53 | *** join/#oe Crofton|work (~balister@pool-71-171-36-96.ronkva.east.verizon.net) |
| 20:32.22 | sr105 | I ended up swicthing all my vars to $VAR unless it was one I knew was from bitbake. |
| 20:32.54 | kergoth | that's for the best, yeah |
| 20:32.54 | sr105 | hindsight is 20/20. I wish bitbake had used $(VAR) like make for it's own substitutions |
| 20:33.07 | kergoth | agreed, or % like rpm specfiles, or anything else really |
| 20:33.21 | kergoth | we wanted it to be something people were used to, and just caused confusion about what happens when instead |
| 20:33.25 | kergoth | :) |
| 20:33.28 | sr105 | :) |
| 20:34.01 | kergoth | its one of the most common sources of confusion, knowing the order of operations becomes important, even though ideally it shouldn't be something people have to be aware of |
| 20:34.38 | kergoth | course, you have to be aware of it even in makefiles, hence the need for := |
| 20:35.19 | kergoth | much of bitbake's format is make inspired. := and lazy expansion especially |
| 20:35.21 | sr105 | It made my here-docs easier to code. I didn't have to use backslash escapes since bitbake substitutes everywhere. |
| 20:36.35 | sr105 | I used a here-doc to generate my make_sdcard.sh script. I've been trying to figure out how to do it in such a way that it is easy for others to grok and mess with. |
| 20:48.26 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-qipkgfrgjwvfcqdb) |
| 20:50.12 | *** join/#oe likewise (~likewise@h230004.upc-h.chello.nl) |
| 20:55.42 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
| 21:33.28 | *** join/#oe dvhart_ (~dvhart@134.134.139.74) |
| 21:56.15 | *** join/#oe nitink1 (~nitink@134.134.139.76) |
| 22:02.50 | *** join/#oe dvhart_ (dvhart@nat/intel/x-qkzmczhhxcteekqf) |
| 22:18.53 | *** join/#oe likewise (~likewise@h230004.upc-h.chello.nl) |
| 22:27.58 | *** join/#oe nitink (nitink@nat/intel/x-oyisjjhxjozjvjpc) |
| 22:40.38 | *** join/#oe GusBricker (~GusBricke@cre1513898.lnk.telstra.net) |
| 23:17.42 | *** join/#oe jackmitchell (~Thunderbi@cbnluk-gw0.cambridgebroadband.com) |
| 23:48.17 | *** join/#oe dvhart_ (~dvhart@134.134.139.70) |