**** BEGIN LOGGING AT Wed Mar 26 02:59:59 2014 Mar 26 07:44:43 good morning Mar 26 07:57:54 volker-, ping Mar 26 08:04:12 nvm, wrong tab and tab-tab Mar 26 08:49:52 Hi guys. I see receipes in http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/python for python-autobahn and python-twisted are pretty outdated. Can I try updating to latest releases and submit patches, or is upgrading python receipes part of some bigger "monolitical" upgrade policy? Mar 26 09:10:03 hi everybody Mar 26 09:10:18 I am experiencing some build error at do_rootfs Mar 26 09:10:22 UnboundLocalError: local variable 'new_arch' referenced before assignment Mar 26 09:10:36 I see it also here http://patchwork.openembedded.org/patch/68057/ Mar 26 09:10:51 any body else getting this? Mar 26 09:23:19 hello Mar 26 09:36:39 Hi yocto. I am facing a problem http://paste.ubuntu.com/7155750/ when packing the final rootfs. Any ideas? Mar 26 09:41:23 vicky_: maybe your recipe exposes more then one package and you need to offer to rootfs all of them. Have a look at: https://community.freescale.com/thread/314920 Mar 26 10:49:43 sorry. I am confused. So with dora one should not change PR? But neither changing CONFFILES_${PN} nor EXTRA_OECONF appears to re-build my application? Mar 26 10:52:43 I am facing a problem with libiconv while bitbaking. the log at http://paste.ubuntu.com/7156040/ Mar 26 11:02:24 khem: is there a reason we opted for systemd v211+ rather than systemd v210-stable? Mar 26 11:34:06 zecke: there's some way to tell bitbake that your recipe needs to be rebuilt if a certain variable changes, I just can't recall how Mar 26 11:40:29 Hi all, is Richard P. or Paul E. around and is available for discussion? Thanks. Mar 26 11:42:55 zecke: do you have something like BB_SIGNATURE_HANDLER = "OEBasic" Mar 26 11:43:07 zecke: somewhere in your config (local, distro, ..)? Mar 26 12:06:39 JaMa: it doesn't look like it. Should all PRs already be r0.0? Or when is the .X added to the PR? I have now added INHERIT += buildstats and I am rebuilding. Mar 26 12:08:21 JaMa: BB_SIGNATURE_HANDLER="OEBasicHash", and it is with dora (i am not using master yet) Mar 26 12:12:02 zecke: OEBasicHash is correct and you should see different signature for do_configure after changing EXTRA_OECONF (so it should rebuild for you) Mar 26 12:12:17 zecke: buildstats are independent from this Mar 26 12:12:43 zecke: .X is added to PR by PRSERV (maybe you already have it, unless you see r0.0 in recipe with INC_PR) Mar 26 12:13:27 https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCsQFjAA&url=https%3A%2F%2Fwiki.yoctoproject.org%2Fwiki%2FPR_Service&ei=WMQyU4GyHYrpywO8pICoBw&usg=AFQjCNHx4MBM-uDUxEyRiUUoM3P4T-2yaw&sig2=9Md6Ptl8qFpM_7Ime496yQ&bvm=bv.63738703,d.ZG4 Mar 26 12:13:32 https://wiki.yoctoproject.org/wiki/PR_Service Mar 26 12:13:34 ups Mar 26 12:19:46 JaMa: yes, I read that wiki article. I added the PRHOST variable to my build. I see that the bitbake-prserv is started. Looking at the prserv sqlite3 db I see entries for the software I built. But still the final PKGR remains set to r0. :} Mar 26 12:20:04 JaMa: I have no idea idea how I can inspect/check PKAUTO or increase debugging Mar 26 12:20:53 JaMa: NOTE: Started PRServer with DBfile: /home/ich/source/openembedded/poky/build/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 47201, PID: 10503 and 0: qtbase-5.2.1-r0 do_populate_sysroot_setscene (pid 10612) Mar 26 12:21:04 so I assume it should already be r0.0? Mar 26 12:21:54 zecke: initial PRAUTO should be .0 you should see .1 only after rebuilding it with different signature Mar 26 12:23:35 JaMa: yes but in the above case it is -r0 and not r0.0? is this already wrong? Mar 26 12:25:52 JaMa: http://paste.lisp.org/display/141784 is my entire config. It is dora building "poky" as distro. PRs don't appear to be "locked" Mar 26 12:34:31 zecke: it's not shown in build log, check created .ipk file if it has -r0.0 or just -r0 Mar 26 12:36:09 JaMa: okay. I cleaned my build dir and started from scratch. My laptop is not the fastest so it will take a bit... Mar 26 12:39:15 heh I thought that laptops are good only to connect to some more powerfull machines to do builds there :) Mar 26 12:39:50 well I use mine only as VPN gateway :) Mar 26 12:41:40 JaMa: it is lazyness and to some degree to have a build tree even without internet. Mar 26 13:49:47 I get a problem when I use hob Mar 26 13:50:32 I got a problem when I use hob to build my image Mar 26 13:51:10 it always crashed with information like Nothing RPROVIDES libgstinterfaces-0.10 Mar 26 13:51:26 Does anyone knows how to fix it? Mar 26 13:52:56 Guest96311, i think that indicates that the image you are trying to build depends on libgstinterfaces during runtime, but bitbake/hob was unable to find such recipe Mar 26 13:53:26 it perhaps even requires v0.10 of that recipe Mar 26 13:53:54 but I'm ok building my image with bitbake command Mar 26 13:54:47 do you know how to fix it? Mar 26 13:54:56 i do not, sorry Mar 26 14:43:46 hi, I have problem when I start . ./yocto-autobuilder-setup. I get this error: http://pastebin.com/jqiHYcVp Mar 26 14:43:55 can someone help me? Mar 26 15:06:28 magde, you need to install some host package Mar 26 15:06:31 I guess it's python-zope Mar 26 15:07:31 rpm -qa | grep zope Mar 26 15:07:31 python-zope-event-4.0.2-2.fc20.noarch Mar 26 15:07:31 python-zope-interface-4.0.5-2.fc20.x86_64 Mar 26 15:08:20 hello Mar 26 15:08:42 i would like to install .mount systemd service in yocto, is there a hack for that ? Mar 26 15:33:26 blitz00: thanks. that helped Mar 26 15:52:30 yow, forgot how long it takes to fetch poky-contrib :) Mar 26 15:52:34 * kergoth taps foot Mar 26 16:35:05 erbo, hi, just read your email about the meta-qt5, its really helped to bring hdmi working for me, thanks a lot! Mar 26 16:37:10 erbo, according your email I know that you built it for nitrogen6x machine, what image did you use? Mar 26 17:09:54 kergoth: you can join me in the semi-annual "clean up your dead branches" rant! Mar 26 17:10:04 hehe Mar 26 17:10:07 sounds like a plan Mar 26 17:10:45 kergoth: I'll probably go through after 1.6 and archive a bunch of stuff if people don't pull it out. Mar 26 17:26:02 zeddii: ping Mar 26 17:34:35 JaMa: okay. packages end with .X now. What is the easiest way to see why the AUTOPR has not been bumped? Can I easily list the checksum for my recipe? Mar 26 17:35:45 halstead, ping Mar 26 17:35:50 zecke: bitbake -S Mar 26 17:35:58 zecke: and compare it with entries in sqlite Mar 26 17:36:02 Crofton, pong. Mar 26 17:36:11 did you see the email I copied you on? Mar 26 17:36:27 mickeyl still seems to get admin messages Mar 26 17:36:31 I thought we fixed that Mar 26 17:36:43 Crofton, I just opened it. Hrm.. Mar 26 17:37:04 and can you approve the email on the meta-xilinx, I need to re-cache the pw :) Mar 26 17:37:08 hello every one Mar 26 17:37:46 Crofton, It's odd because I deleted oe-announce. Those mails must be coming from else where. I'm double checking. Mar 26 17:38:10 I am wondering if there is a listed hosted somewhere else he forgot about Mar 26 17:38:29 Crofton, And oe-issues only has you and listmaster as owners/mods. Mar 26 17:39:33 I am going to ask for an exmaple with headers Mar 26 17:39:49 Crofton That would be very helpful. Send them along if you can. Mar 26 17:40:19 Done, Mar 26 17:40:26 thanks for your help Mar 26 20:32:31 "bitbake-layers show-recipes" lists me recipes. Now I can't find them in any meta* folder of poky HEAD. Where can I find the code of them? Mar 26 20:32:53 sorry, i left my crystal ball at home Mar 26 20:33:02 we don't know what layers you have configured in your bblayers.conf Mar 26 20:33:10 so there's not much we can do to tell you where something is on your hard drive Mar 26 20:33:27 kergoth: poky HEAD, so the default ones Mar 26 20:33:49 kergoth: I am more confused how this recipe is found when a grep through meta* only finds it in a packagegroup Mar 26 20:33:53 that really doesn't make sense. the fact tha tyoure using poky master doesn't mean you haven't added 42 bsp to your configuration Mar 26 20:34:05 s/bsp/bsp layers/ Mar 26 20:34:12 I didn't add anything to it, plain git clone Mar 26 20:34:12 what exactly are you looking for? Mar 26 20:34:28 I am looking for the code/recipe of the *shadow* packages Mar 26 20:34:30 again, the fact that you cloned doesn't mean anything. every layer is cloned Mar 26 20:34:50 from a quick find command, see oky/meta/recipes-extended/shadow Mar 26 20:34:56 s/oky/poky/ Mar 26 20:35:06 grep is going to search the contents of files, not the filenames Mar 26 20:35:53 kergoth: yes, but find meta* -name "*nativesdk-shadow*" wasn't successful either Mar 26 20:36:14 it wouldn't be Mar 26 20:36:24 the shadow recipe provides it Mar 26 20:36:26 see BBCLASSEXTEND Mar 26 20:36:36 My understanding is that every available recipe is available as ".bb" Mar 26 20:36:48 that understanding is incomplete. Mar 26 20:37:13 Via BBCLASSEXTEND, a single recipe can emit target, native, nativesdk variants Mar 26 20:37:49 hm, confusing Mar 26 20:38:18 it greatly simplifies matters, no need to duplicate metadata across a number of differnet recipe files when they're 99.9% identical Mar 26 20:38:28 makes it then difficult to find the configuration of a recipe Mar 26 20:38:36 not when you know what you're dealing with Mar 26 20:38:52 not that i've told you this, you know to look for *shadow*, not *nativesdk-shadow* Mar 26 20:38:56 s/not that/now that/ Mar 26 20:50:02 so how does "bitbake-layers show-recipes|grep shadow" not showing "shadow" but shadow-securetty and shadow-sysroot? Mar 26 21:30:28 JaMa: I am about to sleep. I just got a build breakage on tufao. Somehow my qtbase while DEPENDS on openssl it didn't include SSL in QtNetwork. :} Mar 26 21:31:53 zecke: see meta-qt5/master branch, there were some fixes in this area Mar 26 21:32:35 I really need to wrap my head around both qt5 and gl stuff nowadays. how the proprietary drivers get used is pretty much voodoo to me at this point Mar 26 21:32:38 one of these days Mar 26 21:32:45 s/stuff/stuff in yocto/ Mar 26 21:34:11 JaMa: and my tufao1/libsystemd-qt patches lack proper DEPENDS Mar 26 21:34:38 Is there an option to always wipe sysroot before building a package? Mar 26 21:34:53 kergoth: entering the egl business? it is a mess. :) Mar 26 21:35:07 afaik if something changes, it'll automatically uninstall the current bits from the sysroot and then install the new ones, if that's what oyu mean Mar 26 21:35:13 heh, so i hear Mar 26 21:35:36 at the moment our omap5-evm machine is buildin gboth libgbm-glsdk and mesa and stepping all over one another Mar 26 21:35:58 kergoth: libegl == Vendor x Technology Mar 26 21:36:27 kergoth: I meant. totally emtpies the sysroot and populates it based on all the DEPENEDS. E.g. to find missing DEEPENDS more easily. Mar 26 21:36:31 ah Mar 26 21:36:33 anyway. It is night and I am tired. :) Mar 26 21:36:38 iirc we do have some scripts to test that Mar 26 21:36:53 also other related things, like building everything, then rebuilding everything one by one to check for greedy deps (the opposite problem) Mar 26 21:37:00 kergoth: technology (X11, wayland, directfb, pure framebuffer, kms) Mar 26 21:37:07 there's something along these lines in oe-core/contrib Mar 26 21:37:12 i have some scripts for such things too Mar 26 21:37:17 * kergoth nods Mar 26 21:37:30 thanks! have a nice day guys! Mar 26 21:37:33 wayland is something else i need to brush up on, one of these years Mar 26 21:37:35 night Mar 26 21:37:58 kergoth: i think the boys will lose interest in wayland before it is anywhere near being completed Mar 26 21:37:59 Haven't seen zecke on here in a while :) Mar 26 21:38:04 zecke|away: haha Mar 26 21:38:38 zecke|away: there is test-dependencies.sh script which does that Mar 26 21:38:50 JaMa: thanks Mar 26 21:39:11 kergoth: yeah, I am mostly doing GSM stuff. Maybe I will get myself a consumer electronics project this year again. :} Mar 26 21:39:36 JaMa: ah, thanks, i thought there was something :) Mar 26 21:39:38 zecke|away: ah Mar 26 21:41:08 * kergoth continues sstate reuse testing madness Mar 26 21:41:46 kergoth: maybe you could be interested in https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970 Mar 26 21:41:47 Bug 5970: enhancement, Medium, 1.7, richard.purdie, NEW , sstate signature generator issues Mar 26 21:41:54 kergoth: I would be interested in your input for sure :) Mar 26 21:44:41 JaMa: ugh, 2) makes me sad Mar 26 21:44:57 * kergoth continues reading Mar 26 21:48:33 JaMa: damn, there are even more corner cases in this stuff than i thought, i'll re-read and add my $0.02 Mar 26 21:48:36 JaMa: heh Mar 26 21:49:06 JaMa: what bugs me most about the currnet signature handling is that it cares too much about the intermediate state rather than the end result, in some cases Mar 26 21:49:16 * kergoth ponders Mar 26 22:01:27 RP: what does -S printdiff require, from the previous build? SSTATE_DIR? STAMPS_DIR? both? Mar 26 22:02:08 * kergoth pokes at it Mar 26 22:06:26 kergoth: including -native deps in general or just the 32bit/64bit difference we currently have? Mar 26 22:10:18 a bit of both, honestly :) Mar 26 22:10:23 but the latter is most unpleasant Mar 26 22:10:28 bloats up our sstate we need to ship Mar 26 22:23:15 I hope that we'll be able to fix 2nd part Mar 26 22:24:04 sigh, I'm not getting 100% reuse between two build environments with identical metadata, and the local.conf/bblayers.conf hard linked over, so thats identical too. all thats different is SSTATE_DIR/SSTATE_MIRRORS, so one of them writes, and one of them reads what the other wrote, sstate wise Mar 26 22:24:23 but including them is still imho good thing, because without them I cannot really persuade people that sstate is "reliable" and that we don't need clean builds Mar 26 22:24:31 true Mar 26 22:24:42 I just hate how sensitive it is Mar 26 22:24:53 especially with some home-made -native tools we have and someone says, I've fixed our -native tool for localization generator Mar 26 22:24:53 look at it funny and everything rebuilds from scratch, including quilt-native, it seems like :) Mar 26 22:25:02 ahh, yes, that's a good point Mar 26 22:25:07 and in built image I still see broken localization in target packages Mar 26 22:26:18 can you do sstate-diff-machine.sh in both dirs and compare sstate-diff/*/list.M files? Mar 26 22:26:26 I see reasonable reuse here Mar 26 22:28:37 zeddii, zeddii_home you around? Mar 26 22:29:02 sstate-diff-machine goes by STAMPS_DIR i assume, as bitbake-whatchanged does? Mar 26 22:30:18 kergoth: it even hard codes ${tmpdir}/stamps :/ Mar 26 22:30:28 * JaMa blames himself Mar 26 22:31:03 ah, right. in the case i'm testing, COREBASE/TOPDIR/TMPDIR are all different, but machine+distro is the same Mar 26 22:31:39 but if you still have stamps directory somewhere then you can set tmpdir to parent dir and sstate-diff-machine will probably work OK Mar 26 22:31:39 * kergoth checks bitbake-whatcahnged -v Mar 26 22:31:48 k Mar 26 22:31:56 it just calls bitbake -S to create stamps and uses tmpdir/stamps only to find them Mar 26 22:33:01 ah. bitbake-whatchanged pulls STAMPS_DIR, either from the env or bitbake, and then writes to ${STAMPS_DIR}.bbs, and compares that vs ${STAMPS_DIR} Mar 26 22:33:46 gah. whatchanged says everything changed ,just about, but says no variabels changed, just tasks. what? how can no variables have changed? Mar 26 22:33:49 my head hurts Mar 26 22:34:34 kergoth: printdiff relies on SSTATE_DIR Mar 26 22:34:49 JaMa: btw the 32/64 bit difference should be fixed in master Mar 26 22:34:51 RP: k Mar 26 22:35:28 JaMa: I did run some deeper investigation and fixed the issues found, the aclocal changes had regressed things but that is fixed now Mar 26 22:36:40 RP: wow thanks, I'll check that Mar 26 22:37:07 kergoth: the printdiff thing is still a bit experimental, I have some other "strategies" for printing good results in odd branches. If I get some time I may be able to get them into the release, at least having the option to -S should help and allow us to experiment more easily Mar 26 22:38:09 I wish it showed the detail whatchanged shows, we'll have to think about dding the equivalent of whatchanged -v, to show actual changed variables Mar 26 22:38:38 kergoth: I thought the second part of the code did Mar 26 22:39:01 hmm, maybe this particular example is just hokey, i'll try again later Mar 26 22:39:24 I seem to be getting most everything rebuilt, but no variables changed according to whatchanged and -S printdiff Mar 26 22:39:31 * kergoth may give up on today :) Mar 26 22:40:36 yeah, in this case -S printdiff is dumping recipe/tasks, but no variables at all. huh Mar 26 22:40:43 kergoth: http://pastebin.com/WDq0Cp4K is just some random output I just printed Mar 26 22:41:14 kergoth: so it found the end of the chain, then printed the differences there Mar 26 22:42:59 The biggest "fuzz" is what constitutes a "closest matching task", delta size, time or something else... Mar 26 22:43:13 huh Mar 26 22:43:14 RP: https://gist.github.com/kergoth/9795300 Mar 26 22:43:48 kergoth: At a guess that means it found no overlap :/ Mar 26 22:43:58 kergoth: mismatched do_fetch is always a bad sign Mar 26 22:44:32 these two build dirs use identical metadata, just two poky clones. one writes sstate, the other reads from the first's SSTATE_DIR with SSTATE_MIRRORS and writes to its own SSTATE_DIR Mar 26 22:45:14 wanted to test the case where COREBASE and other layer paths differed Mar 26 22:45:17 kergoth: what does bitbake-diffsigs show if you run it between the do_fetch sigdata file from each build ? Mar 26 22:45:21 * kergoth scratches head Mar 26 22:45:37 (for quilt-native say) Mar 26 22:47:14 JaMa: FWIW I also checked that the target sstate signature doesn't depend on the nativelsb string of the system its running on. So target packages from any build should be reused on different OS systems Mar 26 22:47:18 the siginfo files are identical, same checksum. yet if i change the second to point STAMPS_DIR at the first directly rather than through SSTATE_MIRRORS, and run bitbake -S printdiff, thats the gist i posted Mar 26 22:47:40 * kergoth is rather confused Mar 26 22:48:20 kergoth: bitbake -S printdiff cares about SSTATE_DIR, not STAMPS_DIR Mar 26 22:48:35 thats what i meant Mar 26 22:48:39 ah, ok Mar 26 22:48:55 fingers typed the worng one, due to moving back and forth between whatchanged and -S :) Mar 26 22:49:33 I want to teach that code how to interrogate an http mirror but one step at a time... Mar 26 22:49:43 heh, indeed Mar 26 22:50:45 kergoth: is one of these in a chroot with a different LSBNATIVESTRING? Mar 26 22:50:56 both using the same chroot Mar 26 22:51:15 the build configuration summary is identical Mar 26 22:51:30 kergoth: It should work :/ Mar 26 22:52:11 The external toolchain is one part I wouldn't know much about in this context but for your tests I can't see how that would differ Mar 26 22:53:35 RP: I don't know how I could miss such changes in git log :) Mar 26 22:53:47 the strangest thing is the first and second both run the identical # of setscene tasks. then the second re-runs fetch/unpack/etc anyway, but the first doesn't, afaict Mar 26 22:54:02 JaMa: I just had to fix aclocal in autools.bbclass and it started working properly Mar 26 22:54:10 ah :) Mar 26 22:54:35 autotools: Exclude variables from autotools_copy_aclocals Mar 26 22:54:37 yet there were no errors from the setscenes Mar 26 22:54:41 that's the one, right? Mar 26 22:54:46 JaMa: yes Mar 26 22:55:45 kergoth: it sounds very odd :/ Mar 26 22:56:00 btw in one of last experiments I've removed all .siginfo files in my sstate-cache and all setscene tasks were failing to "fetch" them (trying whole FILESPATH to find them) Mar 26 22:56:19 It's probably OK, but a bit surprissing that it's using FILESPATH here Mar 26 22:56:54 JaMa: kergoth and I keep meaning to fix that Mar 26 22:57:02 (unset FILESPATH in the sstate code) Mar 26 22:57:11 yeah, there's an open bug to address that preferably in a cleaner way than the hack i'm using in meta-mentor Mar 26 22:57:16 iirc anyway Mar 26 22:57:42 cool Mar 26 22:58:45 btw: does someone remember if the issues why we made libav-9.10 D_P -1 are resolved already? Mar 26 22:59:07 do we still need INR_PR? Mar 26 22:59:13 newer mplayer2 which is compatible with current live555 needs libav-9* but libav-8 is still default version Mar 26 23:03:43 Crofton: no, its being killed off Mar 26 23:03:57 thought so Mar 26 23:04:19 JaMa: not offhand Mar 26 23:04:19 I may send in a stupid patch for swig to help with a silly gnuradio cmake issue Mar 26 23:04:36 but I can use this to kill PR in the recipe Mar 26 23:04:37 hmmm Mar 26 23:04:49 will that annoy pr server Mar 26 23:05:41 Crofton|work: we're killing off PR values when PV changes Mar 26 23:06:11 * RP -> Zzzz Mar 26 23:06:30 * kergoth switches his test to the internal toolchain to try to simplify his testing even further Mar 26 23:07:23 thats right Mar 26 23:07:24 ok **** ENDING LOGGING AT Thu Mar 27 02:59:58 2014