**** BEGIN LOGGING AT Wed Jul 23 03:00:01 2014 Jul 23 04:53:16 pidge: how's the milestone coming? Jul 23 05:00:10 halstead: I pushed it out earlier Jul 23 05:01:22 pidge: great! I thought you were planning to ping me when. I'll verify checksums. Jul 23 05:08:00 halstead: yeah, sorry, I got distracted by lawnmowers and weedwackers Jul 23 05:12:32 Hi yocto i am trying to interface camera with my development board with using v4l2-utils how to capture the image and what is command. Jul 23 07:08:00 Hi yocto...please any one help me to download libav 0.9 Jul 23 07:41:32 when adding gstreamer plugins to my BSP in yocto, I can use either "gst-plugins-good-meta" or for each plugin things like "gst-plugins-good-souphttpsrc" Jul 23 07:41:44 where do I get a list of all such plugins like "gst-plugins-good-souphttpsrc" to be used? Jul 23 08:11:05 hi guys...I created a new recipe, but whatever I do, I can't get libraries packed in a packages-split/libsocks folder (my package/recipe is libsocks)...all the files I need are located in libsocks-dev Jul 23 08:12:04 I tried with FILES_${PN} += "${libdir}/*.so" but that didn't help. Jul 23 08:12:54 ivanstojanovic: indeed by default .so files go to -dev. it is intentional. Jul 23 08:13:09 because it is the standard way to build/package libraries in linux. Jul 23 08:14:04 you need to add this to your recipe, if you want the .so in the main package: Jul 23 08:14:04 FILES_SOLIBSDEV = "" Jul 23 08:14:04 FILES_${PN} += "${libdir}/*.so" Jul 23 08:14:19 that's clear, but build doesn't generate .so.x files which would be located in the libsocks Jul 23 08:14:48 ok, let me google what FILES_SOLIBSDEV is used for :) Jul 23 08:15:45 ivanstojanovic: grep it in meta/conf/bitbake.conf Jul 23 08:15:57 it's used to defined the files that go in -dev package by default Jul 23 08:16:19 ok, I will try that, thanks guys! Jul 23 08:16:36 when doing the packaging, bitbake will do the -dev first, and if you don't reset this variable the .so is picked up by -dev. Jul 23 08:18:30 TobSnyder: the gst packaging is done dynamically. each plugin ends up in its own package. so the list of all packages depends on how you've configured gst build. Jul 23 08:18:51 you can get the list after the build by looking at the generated packages, or the build log, or the build history Jul 23 08:43:44 morning all Jul 23 08:53:08 hi there Jul 23 09:00:10 morning, hi :) Jul 23 09:00:49 does _remove work for IMAGE_INSTALL, e.g. does IMAGE_INSTALL_remove make sense? or how to suppress a specific package from an image for testing? Jul 23 09:06:17 that should work, yes Jul 23 09:06:17 rburton: ok... where to set correctly? would an bbappend to the original image recipe suffice, or has it to be globally visible, e.g. in a .conf file? Jul 23 09:06:18 either Jul 23 09:06:18 thanks, will try. Jul 23 09:37:34 Hello. I am trying to build using read-only-rootfs. It seems to work okay, but two recipes fails with the message "ERROR: The following packages could not be configuredoffline and rootfs is read-only: ['101-ntpdate', '100-ca-certificates']". ntpdate doesn't give any errors, but ca-certificates fails in postinst, when i tries to delete files in /etc. It seems that it might not pick up the SYSROOT variable. How can I debug this, and find Jul 23 09:37:34 out why ntpdate fails? Jul 23 09:50:11 rburton: hm. we found that some data_smart.py overwrites all the actions in the end. is there some specific reason behind this? Jul 23 09:50:56 What’s the correct way to print out all PREFERRED_PROVIDER_* variables during a build? Jul 23 09:51:51 kspr: you need to look at what the postinstall script is doing Jul 23 09:52:07 kspr: if it uses system paths without prefixing them with $D then change it so that it does Jul 23 09:53:57 bluelightning, the pkg_postinst_${PN} function in the ca-certificates recipe only does SYSROOT = "${D}" update-ca-certificates Jul 23 09:56:41 bluelightning, ntpdate pkg_postinst_ntpdate writes crontab to /var/spool/cron/root without $D so that might be the problem for this Jul 23 09:57:41 kspr: ${D} or $D ? if the former, I don't think that's correct Jul 23 09:58:51 bluelightning, ok, might be a stupid question, but what is the difference? I see both used seeminly random Jul 23 09:59:06 kspr: well, I wouldn't say it's random Jul 23 09:59:15 ndec: I actually don't understand why I have to use gstreamer1.0-plugins-base-meta instead of gstreamer1.0-plugins-base when adding gstreamer-1.0 plugins, can you explain (and where are those XXX-meta defined?) Jul 23 09:59:32 in the context of do_install and do_package, ${D} is correct - that's ${WORKDIR}/image Jul 23 10:00:28 TobSnyder: gstreamer1.0-plugins-base is 'just' the package for gst-plugins-base component Jul 23 10:00:48 base-meta is a meta package that we create that brings additional binary package Jul 23 10:01:10 kspr: in the context of the postinstall scripts, $D should be used - since it's an environment variable that is set when running the script during building the image, and not set to anything when the script is run on the target system (not applicable in your case since that's not possible if the image is read-only at runtime) Jul 23 10:01:33 bluelightning, ahh, that explains. Trying without {} Jul 23 10:03:09 bluelightning, still fails. I'm not really sure how to get logging to see why it fails.. the do_rootfs log doesn't say much. Jul 23 10:03:32 I think there might be another log where those are saved, let me check Jul 23 10:03:32 Could it be that the $D environment variable is not set? Jul 23 10:03:43 it'll definitely be set during do_rootfs Jul 23 10:04:06 alright. Jul 23 10:04:38 By the way, I am using the default recipes from Yocto 1.6.1. Tried a newer one from OE too. Jul 23 10:05:11 right, it's true that not all recipes have been properly written to support being used in a read-only image Jul 23 10:05:41 alright. I think that there might be a problem with the SYSROOT patches for ca-certificates, not prefixing with $D when it removes temp files. Jul 23 10:05:49 But I haven't been able to fix it. Jul 23 10:29:44 bluelightning, ntpdate is working now, using the correct syntax with $D. ca-certificates now gives me an error: /mnt/dev/yocto-1.6/build/tmp/work/nitrogen6x-poky-linux-gnueabi/my-image/1.0-r0/rootfs///install/tmp/rpm-tmp.95005: 2: /mnt/dev/yocto-1.6/build/tmp/work/nitrogen6x-poky-linux-gnueabi/my-image/1.0-r0/rootfs///install/tmp/rpm-tmp.95005: SYSROOT: not found Jul 23 10:30:00 it is correct that the rpm-tmp file does not exist Jul 23 10:31:01 kspr: that reads more like the script is trying to refer to SYSROOT as a file instead of a variable Jul 23 10:31:30 yea, it seems weird Jul 23 10:37:42 kspr: I think you'd have to look at exactly what's being run in that script Jul 23 10:38:23 bluelightning, yes, I'll probably have to go through it again. Jul 23 10:41:34 bluelightning, I think that I might have a problem with the $D still. If I use "SYSROOT = $D update-ca-certificates", it fails with the error above. If I remove the spaces - "SYSROOT=$D ..." then I get "Updating certificates in /etc/ssl/certs... rm: cannot remove 'ca-certificates.crt': Permission denied". Jul 23 10:42:20 Can you print environment variables during build? Jul 23 10:44:53 kspr: right, the spaces cannot be there - that's standard shell variable setting syntax Jul 23 10:45:22 kspr: for the latter, it sounds like the update-ca-certificates script is simply not using the SYSROOT variable Jul 23 10:46:17 bluelightning, well, if I run the update-ca-certificates in devshell, it seems to be working fine, and using the variable. Jul 23 10:48:11 TheLost: do you mean environment variables or bitbake variables? Jul 23 10:48:51 bitbake variables like D and PREFERRED_PROVIDER_* Jul 23 10:49:35 TheLost: bitbake -e (with optional recipe name as argument if you want to get the values for a specific recipe as opposed to the global configuration level) Jul 23 10:50:16 bluelightning: thanks, I’ll try out! Jul 23 11:12:18 kspr: to be honest I'm not sure why that wouldn't be working then Jul 23 11:12:42 hallo leute Jul 23 11:13:40 bluelightning, me neither. It is building the image now - I added "echo $SYSROOT >sysroot.log", which of course returns true, and makes the function return true. It is of course a hack, but I think the only problem is that it does not remove temp files. I might live with that for a while. Jul 23 11:16:35 I got a question I used "bitbake linux-yocto -c menuconfig" to configure my kernel. I added some drivers for CAN Devices and saved the .config. after that i just "bitbaked core-image-base" and deployed the whole stuff onto my sd card. But when I check for the modules nothing changed, I cannot modprobe the drivers and I can't use my CAN device. Anything else what I can do ? To check or fix the problem Jul 23 11:17:45 The manuals does not tell me anything about changing the local.conf or bblayers.conf when I want change my kernel config should work this way Jul 23 11:25:18 because I thougt if I change the kernelconfig and build the whole project an bitbake an image the kernel should include the modules and drivers I choose Jul 23 12:11:42 motzer: it should yes Jul 23 12:12:26 motzer: does the image include the kernel-modules package? i.e. all modules? if not, any additional modules wouldn't be included Jul 23 12:18:33 we found that some data_smart.py overwrites all the actions in the end. is there some specific reason behind this? Jul 23 12:19:05 LetoThe2nd: sorry, all what actions? Jul 23 12:19:35 data_smart is where BitBake's datastore is implemented Jul 23 12:20:09 bluelightning: like _add, _remove, etc. Jul 23 12:20:41 bluelightning: we see IMAGE_INSTALL changing accordingly, and then *BAM* data_smart and all changes are gone Jul 23 12:20:53 how are you determining this? Jul 23 12:24:23 bluelightning: just bitbake -e onto the image recipe Jul 23 12:26:01 LetoThe2nd: can you perhaps pastebin what you are seeing for IMAGE_INSTALL in the bitbake -e output? Jul 23 12:27:15 sure, second Jul 23 12:37:45 bluelightning: http://pastebin.com/SJa3h53z Jul 23 12:43:51 LetoThe2nd, i think the datasmart stuff is for applying the _remove/_append's. Could you paste your .bbappend too ? Jul 23 12:47:56 LetoThe2nd: finalize is a normal part of the datastore operation, though what I can't tell is why the _removes are not being applied since that is exactly what finalize does if you look at the code Jul 23 12:48:26 LetoThe2nd: with master? Jul 23 12:51:13 RP: should be tracking daisy Jul 23 12:51:20 kroon: moment please Jul 23 12:51:24 LetoThe2nd: there is perhaps a flaw in that finalise code where its looping Jul 23 12:51:47 bluelightning: we are wondering too :P Jul 23 12:51:51 it really needs to process the remove operations last Jul 23 12:51:58 (after all the appends) Jul 23 12:52:05 Hi all. I'm just wondering about meaning of YOCTO? Anybody know that? Why did you decide the project name to "YOCTO PROJECT"? Jul 23 12:52:46 dduri: because ZOCTO didn't sound cool, they picked the next last letter in the alphabet. Jul 23 12:53:35 dduri: https://www.yoctoproject.org/question/how-did-yocto-project-get-its-name Jul 23 12:54:14 :) thanks Jul 23 12:54:38 LetoThe2nd: try something like http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=36c8fc4b9381ec940d578d2c56e7ad207fe95e70 ? Jul 23 12:54:57 LetoThe2nd: just guessing mind.... Jul 23 12:55:19 "A yoctoampere is one electron every two days." That put a smile on my face Jul 23 12:55:33 RP: will do and report back Jul 23 12:56:51 Crofton|work: any good story to that latest strava ride? Jul 23 12:57:40 kroon: recipe + append: http://pastebin.com/xHi9W8bp Jul 23 12:57:57 RP: there is code to filter the value when it is retrieved though, so those should still be applied last in the end... Jul 23 13:02:15 Crofton|work: looks like some good technical bits around there, from a post on twoknobbytires.com Jul 23 13:05:51 RP: coworker reports as not working, sorry. Jul 23 13:14:15 LetoThe2nd, you do _remove "valgrind" and _remove "strace" in the .bbappend according to the log ? Jul 23 13:15:22 kroon: oops, changed during testing. yes, there was another IMAGE_INSTALL_remove = "strace" line when the log was crated Jul 23 13:15:22 oh. but I think I read somewhere in the manual that that is ok Jul 23 13:28:19 bluelightning: true Jul 23 13:28:42 LetoThe2nd: as bluelightning points out there is a second layer too Jul 23 13:30:27 RP: um, what do you mean? Jul 23 13:31:05 LetoThe2nd: when getVar is called, it should filter out any remove items Jul 23 13:32:39 I tested LetoThe2nd recipes with master, and valgrind is indeed properly removed Jul 23 13:33:16 kroon: ok.... Jul 23 13:33:34 trying daisy Jul 23 13:35:18 hmmpf. seems to work as expected there too Jul 23 13:35:54 could distrofeatures affect the output perhaps Jul 23 13:36:26 LetoThe2nd: I tried some reproducers here and I failed to reproduce too Jul 23 13:36:27 ok. is it maybe a problem if bb and bbappend are in separate layers. Jul 23 13:36:31 ? Jul 23 13:41:38 LetoThe2nd, it shouldnt be a problem Jul 23 13:42:20 kroon: ok. Jul 23 13:44:19 someone ever isntalled mono in yocto Jul 23 13:46:41 LetoThe2nd: maybe it is some priority issue Jul 23 13:47:13 (just guessing) Jul 23 13:47:24 TheLost: yeah, will look into it,. Jul 23 13:48:55 LetoThe2nd: I think you may need to try and build a simple test case we can reproduce with Jul 23 13:49:05 LetoThe2nd: then open a bug against that Jul 23 13:49:23 RP: *sigh* yeah probably. will investigate some more and come back then. Jul 23 13:49:28 thanks all for your input. Jul 23 13:50:08 i managed to reproduce it i think.. Jul 23 13:50:22 by moving them to separate layers Jul 23 13:53:44 no, scratch that Jul 23 13:54:02 separate layers isn't doing it here either Jul 23 13:55:17 Can a build with MACHINE=qemuarm be compiled adn run in qemu with armv6 instead of armv5? Jul 23 13:57:18 TheLost: if you tweak a few things, yes Jul 23 13:59:01 RP: which ‘few things’? Setting DEFAULTTUNE to “armv6” should do the compile as armv6 right? Jul 23 14:00:21 TheLost: yes, and then you need to change runqemu to use an armv6 processor Jul 23 14:00:39 TheLost: you'll probably have to include a tune that has v6 support too Jul 23 14:00:50 (default tune isn't enough) Jul 23 14:00:59 this is the first error popping out =) Jul 23 14:08:07 also edit qemuarm.conf adding ‘require include/arm/arch-armv6.inc’ Jul 23 14:10:04 bitbake is compiling with “armv6 vfp”… is vfp the same as “hf” (hard float) ? Jul 23 14:23:15 @bluelightning: I just tried it again and it worked ?! I do not know what was wrong. But one more question, which "clean" command is usefull to secure that i build my kernel and image really fresh, but that it is not neccessary to download and compile all sources Jul 23 14:24:41 I did a bitbake -c clean virtual/kernel befor I bitbaked my image with my configured kernel again and it worked, maybe this is the solution ? Jul 23 14:24:52 motzer: any clean* on the kernel will wipe out whatever customisations you make with -c menuconfig Jul 23 14:25:22 yes i recogonized that and configured it again wit menuconfig Jul 23 14:25:42 and now alle drivers and modules are loaded Jul 23 14:26:11 I am happy but just want to secure that my way I use the toolchain is correct and not just a lucky moment that my image contains stuff I want :) Jul 23 14:26:41 what you did in the beginning should work, I don't know why it didn't Jul 23 14:26:46 it sounds like some kind of bug Jul 23 14:26:57 okay nice Jul 23 14:27:26 if you can reproduce it it would be great if you could file something in our bugzilla Jul 23 14:28:08 yes sure if it pops up again I will try to figure out what the reason is Jul 23 14:29:48 another thing is when I add packages into my local.conf i do it right now with "CORE_IMAGE_EXTRA_INSTALL +="xxxx" , because when I used IMAGE_INSTALL_append =" xxx" (with extra space) there was an error in a python script is that dirty or a good way to add packages ? Jul 23 14:33:42 motzer: what error did you receive exactly? Jul 23 14:36:18 hmm do not know it anymore was two weeks ago and i managed it wir CORE_IMAGE_EXTRA_INSTALL ... that it works right now but I felt a little bit uncomfortable with it because I read something about overwriting such commands Jul 23 14:36:20 http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/22032 Jul 23 14:36:21 here Jul 23 14:37:46 but I did not really understand whats going on, I am really new to yocto and this embedded stuff but right at the beginning of my learning process I want to use right commands in right places =) beacuse such errors are really ugly if something get overwritten sometimes and you do not know where it comes from Jul 23 14:46:00 motzer: ok, understood; but the only way we can really help is if you're able to give us a clear description of the problem you're having, so if there is a bug we can fix it Jul 23 14:52:14 okay I will try to reproduce it and come back :) thanks for your support is really a great community here Jul 23 15:39:56 thank you all =) Jul 23 16:55:00 virtual:native:/foo/poky-dylan-9.0.1/meta/recipes-devtools/bison/bison_2.7.bb, do_configure Jul 23 16:55:03 virtual:native:/foo/poky-dylan-9.0.1/meta/recipes-support/gmp/gmp_5.1.0.bb, do_configure Jul 23 16:55:06 virtual:native:/foo/poky-dylan-9.0.1/meta/recipes-core/ncurses/ncurses_5.9.bb, do_configure Jul 23 16:55:09 hi, how can I see the issues there? ^ Jul 23 16:55:15 I checked the do_configure file, but it is almost empty. :( Jul 23 16:57:59 there should be SOMETHING in the do_configure log that says what configure steps were run, and assuming it was gnu-configure that fialed, a message that says to look at the config.log the config.log is in the 'B' directory for the recipe. Jul 23 17:06:44 nothing :( Jul 23 17:07:47 that is all: Event: TaskStarted Jul 23 17:07:47 Started: 1406131219.33 Jul 23 17:10:45 ah, that is just buildstats, nvm. Jul 23 17:13:30 well, but the log file seems to be incomplete, finishing here: checking sys/mman.h presence... yes Jul 23 17:13:32 checking for sys/mman.h... yes Jul 23 17:13:35 checking sys/param.h usability... yes Jul 23 17:13:37 checking sys/param.h presence... yes Jul 23 17:13:42 should it really stop in the middle of the logging? Jul 23 17:16:30 might it be some memory issue or why would it stop in the middle of the operation? Jul 23 19:33:02 NOTE: Installing the following packages: lib32-packagegroup-core-standalone-sdk-target lib32-packagegroup-core-standalone-sdk-target-dbg Jul 23 19:33:02 NOTE: to be installed: packagegroup-core-standalone-sdk-target@all packagegroup-core-standalone-sdk-target-dbg@all Jul 23 19:33:05 Updating cache... ######################################## [100%] Jul 23 19:33:05 warning: packagegroup-core-standalone-sdk-target-1.0-r8@all is already installed Jul 23 19:33:05 warning: packagegroup-core-standalone-sdk-target-dbg-1.0-r8@all is already installed Jul 23 19:33:20 oops.. sorry Jul 23 19:39:38 Does anyone know how to use a .bbappend file for a .inc file? The .inc file is required in the recipe's .bb file, but I need to adjust the .inc, not the .bb. Jul 23 19:42:48 can't be done Jul 23 19:42:55 appends are by recipe filename only Jul 23 19:45:03 Ok, thanks. That's what I was afraid of. Most of the recipe is in a .inc file which is a bummer for my case. Jul 23 19:48:34 I don't see why Jul 23 19:48:41 Can contents of .bbappend override the .inc file if the .bb file requires the .inc file? Jul 23 19:48:49 that really doesn't make sense Jul 23 19:48:52 the recipe includes the .inc Jul 23 19:48:59 so that metadata is included in the recipe metadata Jul 23 19:49:03 bbappends are applied to the end of that Jul 23 19:49:26 so they can override/append/etc anything that's in the metadata, whether its config metadata, or in the recipe itself, or anything the recipe included Jul 23 19:50:56 Are you saying that my bbappend which adjusts code in the .inc would essentially work? Jul 23 19:51:59 it'd work just fine Jul 23 19:52:16 as long as its named based on the bb filename, not the .inc. again, your'e appenidng ot the recipe, not the .inc Jul 23 19:52:17 Great. Thanks Kergoth! Jul 23 19:52:31 an include is no different from copy/pasting that metadata in Jul 23 19:52:49 so whether there's a .inc or not really doesn't matter from the perspective of someone appending the recipe Jul 23 19:53:33 ok, that helps a ton. I have never used .bbappend, so just getting the correct info. Jul 23 21:18:15 Hey guys. As I'm testing a git/master based SRC_URI, is there a way to get bitbake to force another pull/refresh of that download? Right now I have to delete the download cache to force it... Jul 23 21:21:13 cubicool: set SRCREV to ${AUTOREV}. it makes sure it has a git reopsitory that includes the rev in srcrev. thats how it determines if it's out of date and needs updating Jul 23 21:31:00 kergoth: Hayo, thanks. Jul 23 21:31:25 Although, would that work w/ master? Jul 23 21:31:43 why wouldn't it? Jul 23 22:28:14 generated file: Jul 23 22:28:16 oops Jul 24 00:59:03 bop Jul 24 00:59:09 who's here? Jul 24 01:00:32 aaahhhh wrong chat **** ENDING LOGGING AT Thu Jul 24 03:00:02 2014