**** BEGIN LOGGING AT Thu Jul 23 02:59:59 2015 Jul 23 08:32:14 morning all Jul 23 08:52:17 does someone face issues with git.yoctoproject.org today ? Jul 23 08:53:18 sometimes i get : git.yoctoproject.org[0: 140.211.169.56]: errno=Connection timed out Jul 23 09:51:49 bluelightning, I think we missunderstood eachother yesterday :( What I'm trying to do is to build a rootfs tar.gz, and then place that file into a directory in another rootfs. Atm we have two recipes to do this, but I need to run bitbake on the first recipe first and then run bitbake on the other; our current recipe code can be found at http://paste.ubuntu.com/11924438/ Jul 23 09:52:50 AzaToth_: so at the bare minimum the do_rootfs task of one needs to depend upon the other, which would be do_rootfs[depends] += "otherimagerecipe:do_rootfs" Jul 23 09:53:01 ok Jul 23 10:01:43 bluelightning, seems to work; thanks :) Jul 23 10:02:12 np Jul 23 10:24:23 bluelightning: is there any plan for a YP dev day at elce ? Jul 23 10:24:49 abelloni: I believe so, but you'd need to ask Jefro or Crofton|work for details Jul 23 11:19:20 hey.. i am missing javac in my yocto sdk. how to add this? i can find it in the host sysroot in tmp/ Jul 23 11:46:59 abelloni, see my email to the list Jul 23 11:47:18 YP dev day after ELCE and OEDEM Friday Jul 23 12:19:53 hey, i'm trying to run a program on my poky distribution, but when i start it, the library icui18n is missing, altough it is in the dependencies and in build/tmp-glibc/sysroots/qemuzynq/usr/lib Jul 23 12:20:12 altough i cant find it in the ditribution Jul 23 12:20:27 shouldnt the library be installed automatically? Jul 23 12:24:53 kanucu: if its dlopen()ed then no, we can't detect that Jul 23 12:25:17 we can have explicitly stated dependencies when we find those though Jul 23 12:26:56 somehow RDEPENDS_${PN} += "libicui18n" doesnt give back an error Jul 23 12:27:00 also bitbake icu does work Jul 23 12:27:02 but still Jul 23 12:27:09 the .so is missing Jul 23 12:28:22 kanucu: where did you set that? Jul 23 12:29:42 recipe Jul 23 12:30:31 http://pastebin.com/ayfpmxgr Jul 23 12:31:52 hello Jul 23 12:31:56 I have built sato image for beaglebone using yocto. I'm trying to find the image to load on the sdcard for flashing a new image. Do I use the poky/build/tmp/deply/images/core-image-sato-beaglebone.tar.bz2? This seems like just a rootfs and not everything I need. Jul 23 12:32:44 davis: you should use wic to generate the sdcard image Jul 23 12:32:55 wic? Jul 23 12:33:23 we do have instructions on how to flash images for beaglebone in README.hardware Jul 23 12:34:01 one constraint I have, is that on my linux yocto build host, I dont have a sdcard writer. I was using a windows laptop with a sd card slot to write my previous images. Jul 23 12:34:28 bluelightning: README.hardware in yocto documentation dir? Jul 23 12:34:43 davis: it's in the root of the poky checkout Jul 23 12:35:30 yeah, that part assumes I have a card reader/writer for linux. unfortunately I don't. Jul 23 12:35:56 i was using the win32diskimager to write the image on a windows laptop. :-( Jul 23 12:36:12 i thought the build might make a compatible image for that tool. Jul 23 12:37:45 wic might be able to build such an image Jul 23 12:38:02 you'd have to find some instructions on how to use it specifically for beaglebone though Jul 23 12:39:37 davis: you'll probably find a discussion between me and bboozzoo with instructions for the BBB on the ML Jul 23 12:39:50 thanks I'll look Jul 23 12:40:07 i just got lucky and found a collegue with a removeable one. Jul 23 12:40:19 ill try it. many thanks folks, I appreciate your help. Jul 23 12:40:23 kanucu: based on what you've told me I can't immediately see what the issue would be Jul 23 12:41:09 kanucu: most of those explicit dependencies you've added are probably unnecessary though Jul 23 12:41:38 ye might be, but shouldn't create problems right? Jul 23 12:42:12 davis: yup, wic will be the easiest to get you started, you'll get an image that you dd to sdcard, you skip all the manual fdisk/mkfs crutf that's listed on the web page ;) Jul 23 12:43:15 i just started a new clean build, it seems meta-toolchain-qt also wont work out of the box... Jul 23 12:46:23 bboozzoo: its cool. i'm doing the manual method now, but for future reference where is this wic tool mentioned? Jul 23 12:48:52 kanucu: what does "won't work" mean? Jul 23 12:49:35 davis: mostly here https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-partitioned-images I had not update README.hardware manual with input on wic Jul 23 12:50:44 fwiw, when I move the sd card to the beagle, do I hold down the boot button and it will turn on all leds when its done with its flashing? Jul 23 12:51:41 "satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-qt-toolchain-target: * libqtphonon4-dev " Jul 23 12:52:00 altough it should be in qt-x11-free Jul 23 12:52:13 heh, bboozzoo when i went to add your reply to my notes, I noticed I had already added some notes from you. Jul 23 12:52:17 many thanks again Jul 23 12:52:23 uhm, no, it will just boot from the sd card Jul 23 12:53:30 so no holding down the button when I turn it on? Jul 23 12:56:08 I'd say only on the first power on Jul 23 12:56:19 not on the subsequent resets Jul 23 12:56:33 Hi Jul 23 12:57:45 I created a custom recipe that is simply copying a folder containing files and subfolders in the /root directory of the target rootfs. But the do_rootfs always fails because the package_split is empty :/ Do you have any idea why ? Jul 23 12:58:15 hmm. well just putting the sdcard in and turning on, seemed to run the previous image. Jul 23 12:58:51 kanucu: right, I think someone has forgotten to remove that reference Jul 23 12:58:51 if I hold down the boot button while I insert power, it does not flash any leds so it appears not to be trying to load the newly built image Jul 23 12:59:43 bluelightning: so libqtphonon4-dev is not needed anymore? Jul 23 13:02:26 kanucu: we recently disabled phonon by default, thus it should not be mentioned in the inc file used by meta-toolchain-qt Jul 23 13:02:33 davis: you need to connect the serial cable to actually see something useful Jul 23 13:02:59 hmm. yes i have one of those on order. Jul 23 13:03:42 so i guess without serial cable, I can't complete the image install? Jul 23 13:04:04 since you're using the stock linux-yocto kernel, you're missing all the bells and whistles like blinking leds and so on Jul 23 13:04:53 bluelightning: /openembedded-core/meta/recipes-qt/packagegroups/packagegroup-qt-toolchain-target.inc Jul 23 13:04:58 i think? Jul 23 13:05:01 so you're basically already running the image, it's just that there is not visual feedback, but if you connected a serial console, you'd see it boot Jul 23 13:05:02 kanucu: yes Jul 23 13:06:08 fwiw, i have a lcd cape attached. when i finish booting to X (as it used to) I see the file manager and it shows the boot and root partitions in the file manager. Jul 23 13:06:47 bluelightning: ok thank you Jul 23 13:06:52 i'll try again Jul 23 13:06:59 I will send a fix for that Jul 23 13:07:09 the boot has MLO and u-boot.img and the root has what looks like a unix fs Jul 23 13:08:19 but it looks like its running the stock debian/X after I did the upgrade procedure Jul 23 13:10:31 if it shows a X/openbox/beaglebone.org desktop on the lcd, its not booting what I built with yocto sato-img right? Jul 23 13:28:04 hi guys Jul 23 13:28:09 hi Jul 23 13:32:13 I'm trying to use yocto-autobuilder to build, and after a couple of builds, some files ends up with multiple .md5sum, for example core-image-minimal-initramfs-genebt05-20150723105004.rootfs.tar.gz.md5sum.md5sum Jul 23 13:34:39 I assume it's because the tmp dir isn't cleared after a build Jul 23 13:34:50 is it something I'm supposed to do manually? Jul 23 13:36:04 has anyone got this from sanity check ? Jul 23 13:36:04 OE-core's config sanity checker detected a potential misconfiguration. Jul 23 13:36:18 Please use a umask which allows a+rx and u+rwx Jul 23 13:36:27 I did a "find . -type f -exec chmod a+rx,u+rwx {} \;" but it's not working Jul 23 13:40:47 pidge: ^^ Jul 23 13:41:56 drou: the issue is your umask, not you current permissions Jul 23 13:42:07 AzaToth_, the build dir should be getting cleared out, unless you have tmp somewhere else other than build dir? Jul 23 13:51:14 pidge, have set TMP_DIR = "/home/buildbot/yocto-autobuilder/tmp" (and all others are rooted into /home/buildbot/yocto-autobuilder instead of under /tmp) Jul 23 13:51:51 ahhhhh Jul 23 13:52:53 AzaToth_: hrmm. do you want the md5sums? Jul 23 13:53:09 it's not important Jul 23 13:53:30 but I notice now it doesn't really cleanout at all Jul 23 13:54:26 all old builds are still in ~/yocto-autobuilder/tmp/deploy/images/genebt05 Jul 23 13:57:09 abelloni: ah, so i should use umask instead of chmod, thx Jul 23 14:09:40 pidge, which part of the system should delete stuff from tmp? Jul 23 14:09:56 well, normally Jul 23 14:10:28 at the start of every build we wipe yocto-autobuilder/yocto-worker//build Jul 23 14:10:38 yea Jul 23 14:10:50 putting SSTATE_DIR and DL_DIR somewhere else so they don't get wiped Jul 23 14:11:17 so that generally deletes tmp since we generally don't relocate it Jul 23 14:11:25 ok Jul 23 14:11:35 so I should disable TMP_DIR again Jul 23 14:12:04 I would. Let me look at making this a bit nicer. I would like to know if you see any performance impact of that. Jul 23 14:12:09 and if so what it looks like Jul 23 14:13:22 well, I saw now that TMP_DIR was commented out in the example; I moved everything off /tmp is it was a tmpfs and hadn't enough space Jul 23 14:13:37 I muse have in my hurry removed the # from TMP_DIR Jul 23 14:16:03 pidge, on an other note, I noticed latest commit to lib/python2.7/site-packages/autobuilder/buildsteps/CreateCurrentLink.py introduced a sntax error; where do I report/send patches if needed? Jul 23 14:16:13 ±spelling Jul 23 14:16:37 AzaToth_, : yocto@yoctoproject.org cc: elizabeth.flanagan@intel.com Jul 23 14:16:44 k Jul 23 14:16:45 AzaToth_, : ty! Jul 23 14:23:12 bluelightning: i tracked my missing library down to meta/recipes-support/icu/icu.inc Jul 23 14:23:24 kanucu: oh? Jul 23 14:23:42 as far as i can see, the library is there whiole compiling, but isn't copyed to rootfs right Jul 23 14:23:43 http://pastebin.com/iyvX5ayf Jul 23 14:23:54 libicui18n.so Jul 23 14:24:14 cp -r ${B}/lib ${D}/${STAGING_ICU_DIR_NATIVE} Jul 23 14:24:24 shouldn't that command do that? Jul 23 14:24:56 is libicui18n.so a symlink? Jul 23 14:28:20 there is libicui18n.so.55.1 as library and libicuio.so.55 andlibicuio.so as syslink i think Jul 23 14:28:36 but onyl in build/tmp-glibc/sysroots/qemuzynq/usr/lib Jul 23 14:28:44 not on the target image Jul 23 14:29:33 kanucu: right, so the symlink .so not being part of the main package is deliberate Jul 23 14:30:30 it's only supposed to be used for development - binaries that link against libraries are supposed to link against the major-versioned symlink (or major/minor-versioned binary) Jul 23 14:30:43 thus the .so symlink goes into the -dev package Jul 23 14:34:28 k, but then so.55.1 should exist? Jul 23 14:34:56 yes Jul 23 14:36:22 * paulg_ is seeing odd multilib fallout on the build appliance Jul 23 14:36:30 bluelightnin: but it isn't Jul 23 14:36:41 also added in local.conf IMAGE_INSTALL_append = " icu" Jul 23 14:36:45 nothing changed Jul 23 14:37:30 the deployed builder has all the libs in /lib64 but when that build tries to build itself, the native bins in the sysroot go looking in /lib (not lib64) and of course won't run. Jul 23 14:37:57 anyone recall some changes relating to multilib in say the last month or so? Jul 23 14:40:10 bboozzoo: I have a serial port connected now Jul 23 14:40:40 sadly it seems to go by so fast i can not stop it and it starts booting frm emmc Jul 23 14:41:06 nvm, hit any key to stop boot Jul 23 14:41:13 so i am in uboot Jul 23 14:42:33 kanucu: well I'm not sure what to tell you, if I build icu here and look inside the libicu18n package, it contains /usr/lib/libicui18n.so.55 and /usr/lib/libicui18n.so.55.1 Jul 23 14:43:25 "look inside the libicu18n package" Jul 23 14:43:29 you mean the target image? Jul 23 14:45:59 i might just found something Jul 23 14:46:05 when i run bitbake icu Jul 23 14:46:13 it run icu_native Jul 23 14:46:21 which seems to refer to x86_64 Jul 23 14:46:29 which is actually not the target system Jul 23 14:46:36 na Jul 23 14:46:36 thats what 'native' means Jul 23 14:46:37 nvm Jul 23 14:46:47 got icu -55 now.. Jul 23 14:49:15 I added "install -m 0755 ${libdir}/libicui18n.so.* ${D}/usr/lib/" in do_install() now Jul 23 14:49:18 compiling.. Jul 23 14:51:14 Hello Guys, I am still trying to copy a lib from the sysroot to the images. I did some try with the FILE.. var but I need to learn more reading the doc. I have basic question about my last reading... When the sysroot folder is it populated ? Jul 23 14:52:29 kanucu: that shouldn't make any difference Jul 23 14:52:32 im trying to build my own image using yocto. I have copied the images to the sdcard using the README.hardware and I've booted with a debug serial port cable. Jul 23 14:52:48 kanucu: if you're at that level you should be looking in the icu workdir to see what's actually happening Jul 23 14:52:53 when I boot, I see the first message after the uboot banner is spl_load_image_fat_os: error reading image args, err - -1 Jul 23 14:53:03 i take that as my image is not built correctly Jul 23 14:54:20 bluelightning: i'll debug with -v now, the work directory/lib contains the necesarry file Jul 23 14:54:30 *necessary Jul 23 14:57:44 vincenet: you really shouldn't be doing that. the sysroots area is specifically for use by bitbake to share content between recipes to satisfy dependencies, not for the user to poke at directly. If you want something from your build, pull it from the binary packages Jul 23 15:03:48 kergoth : in my target mod_cgi.so is missing and I try to add in my recipe : FILES_lighttpd += "${prefix}/${BASELIB}/mod_cgi.so" but many question left. Is it correct syntax, is it really binary from lighttpd, and more widely how to print value of a var from recipe. What do you mean from the binary packages ? Should I explore lighttpd recipe ? Jul 23 15:04:46 when you build a recipe in bitbake, binary packages are created (ipk, deb, or rpm) in tmp/deploy/. those packages are then used to build images. fairly sure this is covered by the documentation, as is the use of FILES Jul 23 15:05:11 what is the ${} variable for the target sysroot? Jul 23 15:05:53 bitbake -e is how you examine bitbake variables, this is also in the documentation Jul 23 15:06:06 kanucu: see meta/conf/bitbake.conf for the main variables, specifically see the STAGING variables Jul 23 15:06:29 kanucu: FYI, if you're looking at poking stuff in there directly, don't do that Jul 23 15:09:18 * kergoth re-runs oe-selftest to sanity test v3 of his bbpath plugin loading bits Jul 23 15:09:41 hmm, i missed this. At the start of README.hardware for the beaglebone it says to mmc dev 1 and then mmc erase 0 512 to force the device to boot from sdcard. Jul 23 15:10:20 when I boot the target and get to a bash prompt, i try that mmc command but the debian image does not have mmc. Jul 23 15:11:01 So, sstate lockdown lets us make the build fail if something is changed that's locked down, but is there a way to force continuing use of the old sstate despite the changed checksums, rather than fatally erroring? Or, alternatively, to allow something to rebuild but not require that recipes that depend on it rebuild? I'm specifically concerned about the case where a release has gone out, and a bugfix update needs to be done, and we know the bugfix doesn't Jul 23 15:11:01 affect that recipe's ABI, and we don't wnat to have to redistribute half the dependency graph in binaries with the update Jul 23 15:11:20 apt-cache search mmc does not show anything which sounds like the mmc the doc is referring to Jul 23 15:11:44 RP? I'm thinking I might need what we talked about as #2 (iirc) in that signatures bug, which we don't yet have Jul 23 15:11:58 kergoth: it was supposed to work like that originally, I think that the final changes before it merged broke that Jul 23 15:12:09 davis: I'm curious about why you're asking about a debian distro in a channel for a tool that builds distros that aren't debian. Jul 23 15:12:19 kergoth: it's one thing I've been meaning to follow up Jul 23 15:12:34 bluelightning: ah. yeah, i seem to recall originally it was the intent to be able to lock down e..g the external toolchain in this way Jul 23 15:12:38 i'm trying to get this stock beaglebone to boot the yocto image I built. Jul 23 15:13:51 kergoth: i built the sato image and did the steps in the yocto README.hardware to load to a sd card, but when I boot the beagle it boots debian and not yocto on the sdcard Jul 23 15:14:18 kergoth: does that make sense? Jul 23 15:15:24 davis: #beagle might be the best bet for that Jul 23 15:15:42 kergoth: ok many thanks Jul 23 15:16:16 np Jul 23 15:18:35 kergoth: It certainly was intended that you could force the signatures regardless of the actual value Jul 23 15:18:53 kergoth: I'm not remembering the #2 :/ Jul 23 15:19:18 ah, not 2, it was 3 at https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970 Jul 23 15:19:20 Bug 5970: enhancement, Medium, 1.9, richard.purdie, RESOLVED FIXED, sstate signature generator issues Jul 23 15:19:24 hmm Jul 23 15:20:19 kergoth: From the siggen code you can just force the value iirc Jul 23 15:21:28 k, will take a look Jul 23 15:21:28 bluelightning: you said you have the .so in the work directory, do you mean in the temp folder or sysroot(tareget) Jul 23 15:21:29 thanks Jul 23 15:22:27 kanucu: at the end of do_install it should be under image/ ; after do_package you should see it in packages-split/ under the appropriate package subdirectory Jul 23 15:23:40 so in the yocto README.hardware for beaglebone it says "step 4. If using core-image-base, .. skip to step 8" does that mean if you are trying to load image-base/sato or the board already has the images and you are trying to load any image skip? Jul 23 15:24:33 ie does using in this sentence mean the target already boots this type of image or does it mean if you are trying to load this type of image? Jul 23 15:26:20 bluelightening: i can confirm that Jul 23 15:26:34 bitbake core-image-minimal Jul 23 15:26:41 and then it shoudl be in usr/lib ? Jul 23 15:31:15 kanucu: only if it's actually included in the image, either via a dependency or explicitly Jul 23 15:31:43 IMAGE_INSTALL_append = " icu" Jul 23 15:32:13 or has there to be somethin like icui18n Jul 23 15:32:14 ? Jul 23 15:32:34 the actual package name Jul 23 15:32:56 i.e. libicui18n Jul 23 16:05:58 bluelightning: worked Jul 23 16:06:07 it was really something that simple Jul 23 16:06:09 again -.- Jul 23 16:07:46 Guys, to obtain mod_cgi.so in the image I finaly just add lighttpd-module-cgi in IMAGE_INSTALL. I was inspired when I was looking for lighttpd package in tmp/deploy/ but finaly I am still wonder if FILES could do the job dealing with ./build/tmp(...)/sysroots/eukrea-cpuimx25/usr/lib/mod_cgi.so Jul 23 16:13:16 ah, nice, the tinfoil shutdown command patch i see Jul 23 16:46:27 kergoth: I would like to install a symlink to a dir in nativesdk sysroot but barring all my efforts its not letting me do that Jul 23 16:46:34 any ideas Jul 23 16:49:45 morning, is it possible to remove a package from an image for a specific machine? e.g. removing u-boot-fw-utils from qemuarm builds Jul 23 16:53:50 mansandersson: track down first the place where its added Jul 23 16:54:22 khem`: can you elaborate? where do you want the symlink, and what is it pointing to? Jul 23 16:54:24 khem`: yes, that's easy Jul 23 16:55:18 (at least in this case since it's I who have added it) Jul 23 17:00:06 kanucu: I'm still a bit confused - didn't you add libicui18n to RDEPENDS_${PN} in a package what was in IMAGE_INSTALL ? Jul 23 17:00:49 oi Jul 23 17:02:51 kergoth: I am trying to create a symlink to usr/lib dir which is inside nativesdk sysroot couple of directories above the original sysroot Jul 23 17:02:52 bluelightning: ye, actually i did Jul 23 17:02:53 no idea Jul 23 17:03:17 seems like a error onb my site Jul 23 17:03:55 mansandersson: then whereever you have added use overrides to not do so for machine you wish Jul 23 17:04:59 kergoth: its a crosssdk recipe where I am doing it Jul 23 17:07:20 kergoth: https://gist.github.com/kraj/d904819d32fb286ee4f2 Jul 23 17:08:23 khem`: so something like IMAGE_INSTALL_remove_qemuarm = " u-boot-fw-utils" would work? Thought I'd tested that .. Jul 23 17:08:49 or IMAGE_INSTALL_append_othermachine = " u-boot-fw-utils" maybe Jul 23 17:09:36 bluelightning: I'm off now... thanks for your help! Jul 23 17:11:20 mansandersson: remove shoudl Jul 23 17:12:12 thanks, then I'll try that once again Jul 23 17:14:27 kergoth: i see that sysroot_stage_all puts it in components sysroot-destdir Jul 23 17:14:35 but then it doesnt appear in final sysroot Jul 23 18:23:22 With a recent poky update my rust-cross-arm package is now for some reason seen as rust-cross :( Was something changed about how PN_class-cross = "rust-cross-${TARGET_ARCH}" works? Jul 23 18:24:08 gdb & gcc appear somehow unaffected Jul 23 18:24:48 Ah, looks like there were some BBCLASSEXTEND changes... might be the issue Jul 23 18:36:06 Hrm, reverted a bunch but still was seeing rust-cross instead of rust-cross-arm. Issue cropped up somewhere between Jul 23 18:39:06 * fishey1 has now gone back to his old branch and is still seeing the wrong PN Jul 23 18:50:49 :( Jul 23 19:01:32 Looks fairly easy to reproduce: https://gist.github.com/anonymous/55681e42750b45581ac0 . Can someone tell me if I'm doing something horribly wrong there? Jul 23 19:02:39 fishey1: try PN_append_class-cross = "-${TARGET_ARCH}" Jul 23 19:02:42 see if that changes the behavior Jul 23 19:02:53 you may be running into an ordering issue with how cross.bbclass adds -cross to PN Jul 23 19:03:31 kergoth: nope, gives the same failure Jul 23 19:04:12 RP would be the one to ask, most likely it's related to the recent changes that dropped update_data from the metadata Jul 23 19:04:13 kergoth: I looked, and it doesn't appear cross.bbclass is adding -cross (at least, not explicitly) Jul 23 19:04:38 I presume it's some inner class machinery that's doing the PN munging Jul 23 19:05:39 ah, yes, forgot about that Jul 23 19:06:35 Frankly, all of the cross packages seem to want PN_append = "-cross-${TARGET_ARCH}", it might make sense to add it to cross.bbclass :) Jul 23 19:07:01 Or rather: that's what gcc & gdb do, so I'm imitating them Jul 23 19:07:21 (not any other examples of cross.bbclass users I could find) Jul 23 19:20:49 fishey1: cross.bbclass simply isn't setup to deal with BBCLASSEXTEND Jul 23 19:23:19 fishey1: looking at the code, when the class extend sets PN, it clobbers your override now Jul 23 19:24:13 fishey1: I'd guess that - d.setVar("PN", "%s-%s" % (pn, name)) Jul 23 19:24:13 + d.setVar("PN", "%s-%s" % (pn, name), parsing=True) Jul 23 19:24:13 on ast.py would 'fix' that Jul 23 19:24:28 whether that is the right way to fix it is another question Jul 23 19:25:55 RP: Ok, then: 1) why wouldn't it be the right way to fix it? 2) what things are bbclasses required to do to support BBCLASSEXTEND? Jul 23 19:27:17 fishey1: perhaps you could confirm I'm guessing right before we cross to those things Jul 23 19:27:26 Ok, I'll try it out Jul 23 19:27:48 * RP is sadly overwhelmed with things right now :( Jul 23 19:43:58 RP: interestingly, that works (both PN_append_class-cross and PN_class-cross), but the first time required that I `rm -rf tmp` (otherwise it kept the old PN without that). Jul 23 19:44:28 fishey1: I suspect an rm tmp/cache would have been enough Jul 23 19:44:39 (it just needed a reparse) Jul 23 19:45:29 touch would also work Jul 23 19:46:28 I see. So given that adding `parsing=True` seems to give the behavior I'm after, I think the 2 queries from earlier are relevent again :) Jul 23 20:01:39 Hmm, what's the process for adding selftests, do we need to add tests to testopia before adding the tests to the code? Jul 23 20:03:01 no Jul 23 20:03:09 (well, i don't think so) Jul 23 20:03:16 so the test case numbers are optional in that case, i assume? Jul 23 20:03:39 filing testopia things means they'll be tracked a lot better though Jul 23 20:04:33 * kergoth is not a qa guy, so unit tests are about the most he ever bothers with :) Jul 23 20:05:05 usually, ditto Jul 23 20:07:49 * kergoth goes ahead and emails the patches to add the tests and will see how it goes Jul 23 20:09:01 kergoth: did you see my snippet ? Jul 23 20:09:23 I'm getting .debug folders on my packages-split/$PN folder, and QA tests are complaining about it Jul 23 20:09:32 does anyone have any idea why that might be happening? Jul 23 20:10:00 packaging deficiency Jul 23 20:10:23 you need to add them to FILES_${PN}-debug = "../.debug" Jul 23 20:10:44 khem`: ohh make sense Jul 23 20:10:47 makes* Jul 23 20:10:51 thanks khem`: Jul 23 20:11:12 it should be FILES_${PN}-dbg Jul 23 20:12:17 khem`: haha yeah Jul 23 20:26:54 Hmm, has anyone looked into optional use of —single-branch or equivalent fetching for our git clones to reduce the git mirror tarball size? admittedly the tarball would then be a bit more specific, since it'd only have the branches for the recipes which had their branches fetched, but in the case of gigantic git repositories it'd be of use Jul 23 20:32:24 probably not going to help a lot with the kernel. Are there other large repos we use that are polluted silly with dead end branches not merged into master? Jul 23 20:33:35 hmm, that's a good point Jul 23 20:33:42 not sure Jul 23 20:34:02 shallow would be potentially of more use, but also possibly more complex for the fetcher to deal with Jul 23 20:38:20 i just checked 3.19 and zeddii has already ensured there are no stray stable branches or tags there that we don't explicitly need, so all their content should be gc'd away. Jul 23 20:44:25 paulg: ah, thanks, good to know Jul 23 21:12:15 kergoth: shallow clones ? Jul 23 21:12:58 it works in principle Jul 23 21:13:18 but its not useful when you do development Jul 23 21:13:25 its ok for build ops Jul 23 21:15:55 agreed. but quite often folks aren't doing active development with oe anyway, or if they are, they use externalsrc Jul 23 21:21:17 hmm, pflask works pretty well as a systemd-nspawn alternative Jul 23 21:21:55 bitbake -e hangs for me for some days now Jul 23 21:22:00 anyone seeing Jul 23 21:22:06 kergoth I tend to agree Jul 23 21:22:12 with shallow clones Jul 23 21:22:20 hmm, think i've mostly seen -p hangs rather than -e so far Jul 23 21:24:04 of course, shallow clones tend to be relative to a branch afaik, so unless we know the distance from the branch= value to the SRCREV, we won't know how shallow to go, unless we can fetch up to that commit rather than a branch, haven't tried. will have to poke at it Jul 23 21:24:59 bitbake -DDD -e gdb Jul 23 21:25:08 and its stuck there with no messages Jul 23 21:29:15 ah, that's probably siimlar to what i've been seeing, random, haven't been able to repro it reliably Jul 23 21:29:22 and folks like rp don't seem to have seen it at all Jul 23 21:31:49 I do try and fix the ones I run into or can reproduce... Jul 23 21:32:03 not complaining, just hate it when that happens :) Jul 23 21:32:04 kergoth: testopia entries are optional, we just link them where we have defined test cases Jul 23 21:32:08 tough to fix when people can't reproduce it Jul 23 21:32:12 RP: ah, k, thanks Jul 23 21:32:47 its quite consistent for me on master Jul 23 21:33:03 and I have ubuntu 15.04/64bit stock Jul 23 21:33:50 khem`: I also run that... Jul 23 21:33:51 it started to happen few weeks back Jul 23 21:34:12 khem`: The most suspect things are the shutdown lock knotty changes Jul 23 21:34:58 kergoth: FWIW there is a shallow clone bug open. The issue is it will mean using a different mirror tarball name Jul 23 21:35:07 and more codepaths through the fetcher Jul 23 21:35:17 https://gist.github.com/kraj/b599b568e6ba30323480 Jul 23 21:35:26 is what happens on Ctrl+C Jul 23 21:35:27 hmmm Jul 23 21:36:24 kergoth: just that recipe or all recipes? Jul 23 21:38:28 khem`: nothing too suspect in that backtrace Jul 23 21:38:40 its always same bt Jul 23 21:38:59 khem`: so its hanging in varhistory() ? Jul 23 21:39:13 khem`: what does strace say its doing? Jul 23 21:46:00 strace keeps scrolling Jul 23 21:46:55 fishey1: basically cross.bbclass has none of the automated variable mapping that native/nativesdk/multilib have for BBCLASSEXTEND. Its assumed that cross recipes basically do most of the mapping themselves. Is the parsing=True a real fix? I'm torn. Its an ugly way to make what you're doing work. There are some cases where it would need to wipe out overrides when applying the new PN valye Jul 23 21:48:49 its trying to open bbclass files and .conf files which are not there Jul 23 21:51:46 so its in some sort of stat() mode forever Jul 23 21:55:45 yeah and its going in circles Jul 23 22:00:31 nicely spotted Jul 23 22:05:45 it just may be that it has become too slow Jul 23 22:07:50 RP: you might be having less layers in your mix I guess Jul 23 22:08:20 khem`: quite likely Jul 23 22:08:34 but it has worked well Jul 23 22:08:41 khem`: -e should never be that slow, its likely locked itself into some kind of a loop Jul 23 22:08:48 it would take 2 mins max to do a fresh parse of angstrom layers Jul 23 22:09:19 khem`: have you latest bitbake? There was a performance regression and I did push a fix today Jul 23 22:09:25 I just disabled all extra layers and it became fast Jul 23 22:09:36 today ? Jul 23 22:10:16 I am on commit 5196bfa9639eed2b1e6452f45775551203f8eeb4 Jul 23 22:10:16 Author: Richard Purdie Jul 23 22:10:17 Date: Wed Jul 22 23:30:15 2015 +0100 Jul 23 22:10:17 bitbake-selftest: Add -v option for verbosity Jul 23 22:10:18 Also document BB_SKIP_NETTESTS=yes parameter in --help output. Jul 23 22:10:18 Signed-off-by: Richard Purdie Jul 23 22:10:30 khem`: right, it was in fact 24 hours about Jul 23 22:11:57 24 hours ago Jul 23 22:11:57 I am on top of tree Jul 23 22:12:00 khem`: ok, you have the performance fix then Jul 23 22:12:03 RP its easy to reproduce Jul 23 22:12:04 pick like 20 layers and put them into you bblayers Jul 23 22:12:04 and you will see the hit Jul 23 22:13:08 khem`: well, obviously parsing will slow down with more layers Jul 23 22:13:30 khem`: you're saying -e is slow in particular? Jul 23 22:13:31 yes expected Jul 23 22:13:44 but do you think watin for bitbake -e for 15 mins is acceptable ? Jul 23 22:13:55 khem`: no, I didn't say that Jul 23 22:14:15 yes -e is slow Jul 23 22:14:16 khem`: that is the first time you've put a number on it though Jul 23 22:14:41 khem`: sadly I am maxed out. I really don't need something like this to debug right now :( Jul 23 22:14:45 RP: its optimistic number Jul 23 22:14:51 since I have left it running for more Jul 23 22:14:56 and it never finished Jul 23 22:15:12 and it was working fine few weeks ago Jul 23 22:15:16 khem`: have you that strace handy? Jul 23 22:15:24 khem`: can it be shared? Jul 23 22:15:26 1.8 works ok Jul 23 22:15:43 I can save it Jul 23 22:15:45 and send it Jul 23 22:15:49 khem`: there have been a lot of recent changes includeing the data store rework Jul 23 22:16:08 I still suspect infinite looping is more likely though Jul 23 22:16:43 maybe with some of the path resolution changes Jul 23 22:16:48 and that is probably from a single layer.conf with some kind of problem in it Jul 23 22:18:03 strace goes fast at beginning and slows down as time goes Jul 23 22:18:18 I wonder if its eating up all memory Jul 23 22:19:16 khem`: that backtrace was in the dependency tracking code so that seems likely Jul 23 22:19:20 and is consistent with the infinite loop theory Jul 23 22:19:50 the backtrace is less consistent with that mind Jul 23 22:21:37 whats difference between -e and with out ? Jul 23 22:21:43 since it works ok with out -e Jul 23 22:22:18 parsing takes about 30 seconds and it goes into building stuff Jul 23 22:27:24 RP: here http://paste.ubuntu.com/11927627/ Jul 23 22:27:26 its still running Jul 23 22:27:53 but I uploaded the run so far has been 4 mins or so Jul 23 22:35:37 khem`: I just need a piece of the log hopefully Jul 23 22:38:08 khem`: variable history tracking is enabled with -e Jul 23 22:38:19 hmm Jul 23 22:38:27 khem`: notice how it keeps reloading data_smart.py. That is very odd Jul 23 22:38:53 yes I am observing Jul 23 22:38:56 khem`: sounds like a stray import Jul 23 22:40:41 import in some bbclass you mean ? Jul 23 22:42:00 khem`: I think it must be the import in BBHandler.py Jul 23 22:42:15 (the import data which then triggers an import data_smart) Jul 23 22:42:36 khem`: other puzzling thing is why it finds /mnt/home/kraj/work/angstrom/sources/openembedded-core/meta/conf/documentation.conf yet keeps looking for a documentation.conf Jul 23 22:44:40 thats true for some other confs Jul 23 22:44:53 30% parsing done Jul 23 22:50:41 khem`: Even with OE-Core, if I do "rm tmp/cache -rf; time bitbake -p" I see 4m52, if I do "rm tmp/cache -rf; time bitbake -e bash" I see 16m54 Jul 23 22:51:10 khem`: I think we've somehow slowed down the variable tracking code and -e parses with it enabled Jul 23 22:51:40 looks so Jul 23 22:51:41 khem`: whether this is a regression or you've got lucky with a hot cache in the past... Jul 23 22:52:48 khem`: I see the data_smart even when its going quickly. Its something to look into to improve things though Jul 23 22:53:09 * RP throws the profiler at this, see where the time is being eatne Jul 23 22:56:03 khem`: . Looking at the profile its almost certainly the datastore changes that have done this :/ Jul 23 22:59:23 khem`: If you put a "continue" in the "for event in" loop in _setvar_update_overrides() it certainly makes things faster Jul 23 22:59:34 (bypassing the record() call) Jul 23 23:00:31 khem`: I'll sleep on it but this is fixable, we just need a better way of recording overrides in the logs Jul 24 00:14:29 Hi there Jul 24 00:14:57 is any buddy online ? Jul 24 00:19:03 otavio: you may want the other fixes from https://github.com/MentorEmbedded/meta-mentor/pull/494 for your copy Jul 24 01:52:20 im new to yocto. i finally got my beagle to boot linux from the sato build I installed on the sdcard Jul 24 01:52:41 but before with the other debian build, I had my sdcard mounted in /media Jul 24 01:53:16 how do i mount the sdcard partition 1 which is the partition which has the uEnv.txt file in it? Jul 24 01:53:38 partition 2 is the rootfs and i'm assuming that is what I am using for a rootfs Jul 24 01:54:22 also is there any way similar to buildroot to config what programs I will have installed on my rootfs using yocto? Jul 24 02:00:56 there is, see the documentation at yoctoproject.org. Jul 24 02:02:13 i'm actually reading the wiki from the site now Jul 24 02:05:24 hmm. no yum or apt-get? Jul 24 02:05:51 Well, there is rpm/dpkg/opkg Jul 24 02:05:56 you just need to enable it Jul 24 02:06:21 Or use something like angstrom images which use opkg by default Jul 24 02:15:04 khem`: I'm still trying to figure out how I enable it. Jul 24 02:15:43 add package-management to DISTRO_FEATURES or IMAGE_FEATURES I forget which one Jul 24 02:16:21 unfortunately I don't where ot add that. i'm tired. I'll save that comment and grep the meta manual tomorrow. Many thanks Jul 24 02:16:51 the same place you add just about everything else, conf/local.conf in your build directory. add EXTRA_IMAGE_FEATURES += "package-management" Jul 24 02:18:00 there we go Jul 24 02:18:03 thanks kergoth Jul 24 02:18:38 kergoth: I am still at loss how nativesdk packages make into populating sysroot Jul 24 02:19:18 it's populated with the same mechanism as an image. see populate_sdk*.bbclass Jul 24 02:19:30 hmm Jul 24 02:26:32 I mean the staging sysroot Jul 24 02:26:43 for nativesdk packages Jul 24 02:27:02 this sysroot is used by gcc-crossdk to build and populate the nativesdk packages Jul 24 02:27:13 much like cross build Jul 24 02:27:18 for target Jul 24 02:28:43 see http://pastebin.com/nPr0v3QK Jul 24 02:29:17 items there which go into native sysroot sysroots/x86_64-linux make it in Jul 24 02:29:40 but the items that go into nativesdk sysroot sysroots/x86_64-nativesdk-angstromsdk-linux Jul 24 02:29:42 dont Jul 24 02:29:48 so I wonder Jul 24 02:30:05 but these are being populated from a crossdk recipe Jul 24 02:30:12 I dont know if thats the problem Jul 24 02:30:30 only difference is its not inheriting nativesdk Jul 24 02:30:34 but crosssdk class Jul 24 02:34:28 do you know who picks the stuff up from sysroot-destdir and shoves it into staging sysroots ? Jul 24 02:35:28 I dont see sysroot_stage_all doing it Jul 24 02:36:01 its only putting from stuff from ${D} into local sysroot-destdir which is specific to package Jul 24 02:36:23 unless thats somehow automatically hardlinked into final sysroots Jul 24 02:36:42 I am not able to find who copies them there Jul 24 02:36:48 which task if at all Jul 24 02:38:03 sysroot_stage_all() { Jul 24 02:38:03 sysroot_stage_dirs ${D} ${SYSROOT_DESTDIR} Jul 24 02:38:05 } Jul 24 02:51:23 ok so there is populate_sysroot_setscene task which does it Jul 24 02:52:35 which calles sstate_setscene and drags me into sstate :( **** ENDING LOGGING AT Fri Jul 24 02:59:59 2015