**** BEGIN LOGGING AT Thu Oct 23 03:00:00 2014 Oct 23 06:30:01 it is possible that OE servers might be unavailable from 30minutes from now 0700UTC till 1300UTC due to emergency Network maintenance (bad fibre) Oct 23 06:35:17 * koen hands ka6sox some raisin bran cereal Oct 23 06:36:41 mmmm…delish Oct 23 06:37:03 and full of Fibre (however the wrong kind) Oct 23 06:44:40 koen: ++ Oct 23 06:46:07 gm LetoThe2nd Oct 23 06:47:38 woglinde: howdy there! Oct 23 08:45:18 morning all Oct 23 09:12:52 hi bluelightning Oct 23 09:28:31 hi woglinde Oct 23 13:03:49 how can i verify that my oe build is using the sstate & download mirrors i've setup & populated? Oct 23 13:46:29 mago_: http://git.openembedded.org/openembedded-core/tree/meta/classes/buildstats-summary.bbclass use this to get nice overview after the build Oct 23 13:47:04 mago_: for premirror you can just disable network connections Oct 23 14:38:48 bluelightning, should we move python-pyqt to meta-pythong, and can we report bugs on the recipe in bugzilla? Oct 23 15:09:57 according to https://wiki.yoctoproject.org/wiki/Enable_sstate_cache, I should see setscene tasks if the sstate cache is working. Is this true even if I don't have a local sstate cache directory, and only provide a SSTATE_MIRRORS? So basically, a fresh build. Will a sstate cache help in this case? Oct 23 15:10:08 cause i'm not seeing any setscene stuff at all Oct 23 15:11:39 i think you should see setscene even if using the SSTATE_MIRROR. the main difference with mirror is that it would fetch the sstate data from mirror into your local sstate_dir first, then it would use it. Oct 23 15:11:41 yes. the sstates are fetched from the mirrors up front, and if that succeeded, by the time the setscenes will run, the sstate archives are local Oct 23 15:12:06 so it sounds like either you have e.g. the mirror set wrong, or something has changed that invalidated your cache Oct 23 15:12:07 the mirror is used to populate your local sstate_dir, you should be able to see that. Oct 23 15:12:14 and I will see tasks that fetch sstates from my mirror, or does this happen in the background? Oct 23 15:12:56 its not visible. it happens before runqueue generation before tasks are run Oct 23 15:13:09 iirc anyway. there'll just be a pause as it fetches Oct 23 15:13:16 ideally we'd have some sort of progress indication there, but we don't today Oct 23 15:13:29 does it fetch the entire sstate mirror? cause mine is like 4.5 GB Oct 23 15:13:31 yes, there's a bug open for that Oct 23 15:13:32 you can likely crank up debugging and find the messages Oct 23 15:13:36 -DDDv Oct 23 15:13:41 as in, yes we should show more status Oct 23 15:13:49 mago_: no, it just fetches what is needed Oct 23 15:13:49 mago_: no, it fetches particular sstate archives for the checksums in question Oct 23 15:14:55 okay, thanks Oct 23 15:15:50 or, I thought there was a bug open... Oct 23 15:15:51 it seems to work better now, i removed tmp-eglibc, sstate-cache and cache dir and restarted my build. now i see about 900 tasks of "setscene", and then it continued to process my normal tasks (about 2000 of them). Lets see how much faster this goes :) Oct 23 15:16:39 bluelightning, you see my meta-python question? Oct 23 15:17:27 Crofton|work: in theory yes (if nothing in meta-oe depends upon it) and not yet, respectively Oct 23 15:17:52 I'll check Oct 23 15:18:00 I've also got some wip from a friend Oct 23 15:18:06 it builds, but doesn't work Oct 23 15:18:13 I kind of suspect nothing depends on it Oct 23 15:18:35 unfortunately sip-native and anki depend upon it, which explains why it wasn't already moved Oct 23 15:19:14 I see anki needing it Oct 23 15:19:24 and the recipe needing sip-native Oct 23 15:19:33 oh sip-native is just a comment Oct 23 15:19:58 right Oct 23 15:20:08 does m-p depend on meta-oe? Oct 23 15:20:40 yes Oct 23 15:20:46 I believe so anyway Oct 23 15:20:50 so no need to move sip Oct 23 15:21:05 and anki could move to m-p Oct 23 15:21:15 well, sip probably ought to move if it's python related Oct 23 15:21:34 yeah Oct 23 15:22:00 https://github.com/dae/anki Oct 23 15:22:02 to be honest though I am hesitant to start moving python-using application recipes to meta-python, because that could end in insanity Oct 23 15:22:09 ok Oct 23 15:22:23 I'm justing trying to figure what needs doing Oct 23 15:22:30 as we try to make pyqt really work :) Oct 23 15:22:39 the problem is as always meta-oe has way too much stuff in it Oct 23 15:23:12 well, as you try to move stuff out, you end up with crazy layer depends :) Oct 23 15:25:15 Crofton|work: I'm not sure if it's a binary situation Oct 23 15:25:23 not as much as that, anyway Oct 23 15:26:24 you should have called it meta-python-core :) Oct 23 15:27:40 Could use opinions on https://gist.github.com/kergoth/11f89fd365d78429e528 if folks have a moment. Do these things seem upstream-appropriate, and if so, does the approach seem reasonable? Oct 23 15:30:56 kergoth: certainly looks like something worth having... I have been thinking we need to do something about improving the initial setup process Oct 23 15:32:00 I have a prototype that uses the bb python package to parse bblayers.conf, and gets the BBLAYERS line numbers from the variable tracking support, and uses that to replace those lines with the new version. should be less brittle than sed :) Oct 23 15:32:30 how do layers declare their dependencies and how does the script know where to satisfy them from? Oct 23 15:32:47 LAYERDEPENDS_, standard layer.conf feature that bitbake obeys Oct 23 15:32:52 but it just errors if any are missing Oct 23 15:33:26 currently it has a basic "determine what layers are available" mechanism, right now it's globs, not ideal, but gets the job done. *:*/*:/*:/*/* Oct 23 15:33:54 ok Oct 23 15:33:55 also limits the scope more than a find, keeps it quick. there's an argument to change that behavior, and of course all the explicit arguments can accept layer paths, not just names Oct 23 15:34:24 * kergoth ponders Oct 23 15:34:54 moin Oct 23 15:35:02 I'd say start a thread on the mailing list Oct 23 15:35:14 morning nerdboy Oct 23 15:35:16 k, will do Oct 23 15:35:37 * nerdboy busy with abstracts and whatnot Oct 23 15:35:45 at least if bblayers is a separate tool, worst case it doesn't get called by oe-init-build-env, but a user could run it explicitly after that, for those features Oct 23 15:36:28 but i have a working PiTFT display with 3.15.8+ adafruit kernel now... Oct 23 15:36:45 kergoth: bblayers = bitbake-layers? or a separate tool? Oct 23 15:37:15 the thought was that it'd be a separate tool for configuring an existing bblayers.conf, but it could just as easily be a subcommand Oct 23 15:37:17 nerdboy: adafruit have their own kernel versions? Oct 23 15:37:36 * nerdboy about to chide his son about his stupid eclipse homework Oct 23 15:37:52 bblayers —add openembedded-layer —remove networking-layer —add ./meta-foo/ or whatnot Oct 23 15:38:06 they have patches for touchscreen/other plus a whole repo full of fb drivers Oct 23 15:38:26 look on github under adafruit... Oct 23 15:38:39 kergoth: I don't understand "Automatic set of MACHINE based on the installed MEL BSP". What does that mean? Oct 23 15:39:11 that's mentor specific. when a customer installs mentor embedded linux, it autodetects the machine based on what bsp they have installed, so they dont' have to specify it Oct 23 15:39:12 MEL is Mentor Embedded Linux Oct 23 15:39:25 Oh, I see. Oct 23 15:39:37 yeah, thats why its under not-upstream-appropriate. i was just deliniating the differentiating factors between our scripts and oe-init-build-env Oct 23 15:39:46 to figure out what to push and what not to Oct 23 15:40:17 kergoth is trying to figure out how much if his code we can test :) Oct 23 15:40:20 kergoth: FWIW I'd be happy to rename/alias bitbake-layers to bblayers, but I think having one tool would make sense Oct 23 15:41:11 nerdboy: ah, I see Oct 23 15:42:09 kergoth: do you have any plan on how to implement "support for per-layer hooks and local.conf snippets"? Here at O.S. Systems we use a custom setup-environment that implements that, but we use Python for that. Oct 23 15:42:34 default branch is 3.10 and Raspbian has a one-off 3.12.something Oct 23 15:42:46 * nerdboy wasn't happy until 3.15 worked Oct 23 15:43:40 kergoth: I mean, the hook scripts are in Python. We offer a sort of API for hook scripts. Oct 23 15:44:27 mario-goulart: Currently, our scripts source any existing 'post-setup-environment' shell script in any of the configured layers, with BUILDDIR and MACHINE set, and now also automatically pulls in 'conf/local.conf.append' and 'conf/local.conf.append.$MACHINE' for those layers as well. Quite simple, but seems to cover the cases we needed to cover. It brackets the included lconf segments with headers/footers for removal of existing appends when reconfiguring Oct 23 15:44:27 ane xisting build directory. See https://github.com/MentorEmbedded/meta-mentor/pull/364 for that. I'm certainly open to changing it when pushing it upstream, this is just what's worked for us so far. Oct 23 15:44:41 Then layers that want to hook something in can place scripts under conf/setup-environment.d. Oct 23 15:45:30 using a .d seems quite reasonable to me, good call Oct 23 15:45:56 Those scripts are evaluated according to layers' priority Oct 23 15:46:13 yeah, we do the same, we load them in reverse priority order Oct 23 15:46:35 Oh, yeah, reverse. :-) Oct 23 15:46:47 * mario-goulart is always confused about BBFILE_PRIORITY Oct 23 15:48:59 kergoth: in MEL's setup-environment, one uses the bitbake syntax for hooks? Oct 23 16:20:09 kergoth: mario-goulart is putting our document public; he is going to share it soon Oct 23 16:20:16 cool Oct 23 16:23:18 kergoth: one thing we liked about ours is the use of python for hooks Oct 23 16:23:25 kergoth: and general setup Oct 23 16:23:40 kergoth: it gives a nice freedom and easy to read Oct 23 16:26:16 sounds interesting, perhaps we can align on a single plan of attack for improving the upstream setup script capabilities Oct 23 16:27:13 kergoth: I am very supportative for it Oct 23 16:27:48 kergoth: I am sure our current script is not the way to go; but it has some nice things. Yours also seems to offer nice things as well Oct 23 16:28:10 same with ours, yeah. i'm not particularly happy with our currnet implementation, but the features have value Oct 23 16:29:07 I am sad about the iot-devkit layer putted in git.y.o; it merges several layers in a single one and for no good reason. Even worse, it is called with 'meta-' prefix which imply being a layer but in fact it includes all build system Oct 23 16:30:15 otavio: we are going to fix that, FWIW Oct 23 16:30:36 it's not something I have been very comfortable with either, especially since my name is on it Oct 23 16:30:57 bluelightning: this shouldn't have been included that way. I am curious to know why this got accepted if it is way outside of our standard. Oct 23 16:31:00 :( Oct 23 16:31:16 otavio: there is no standard for repos being added to git.yoctoproject.org though Oct 23 16:31:41 bluelightning: well; something with 'meta' in name and is not a layer shouldn't be there Oct 23 16:31:48 bluelightning: if there is not, we need one. Oct 23 16:31:55 :( Oct 23 16:32:04 otavio: it does have layers in it though, containing metadata Oct 23 16:32:09 bluelightning: this is being marketized already :( Oct 23 16:32:12 bluelightning: yes Oct 23 16:32:20 let's rename poky to meta-poky than Oct 23 16:32:29 no, let's not Oct 23 16:32:41 bluelightning: it has bitbake and all repos Oct 23 16:32:44 :( Oct 23 16:32:52 yes, I know... like I said, we are going to fix it Oct 23 16:33:26 part of what is really missing in order to do that is to have a setup process that avoids having to have all that in the same repo Oct 23 16:33:50 by that I mean a process/tool that we can all share rather than everyone writing it from scratch as we have been Oct 23 16:34:58 bluelightning: well ... this is not an excuse sorry. Oct 23 16:35:41 well, I'm not sure what I can do beyond promising to do better... Oct 23 16:35:48 bluelightning: we have several tools for it. You could have used the setup-scripts used in fsl-community-bsp or mel or whatevery :( Oct 23 16:36:11 bluelightning: I am not blaming you Oct 23 16:36:37 bluelightning: I am blaming YP by not enforcing some quality standards for the repos under the official branding Oct 23 16:36:45 but that is the thing Oct 23 16:37:00 there is no official branding at all with respect to having a repo on git.yoctoproject.org Oct 23 16:37:12 anyone can have one if it's yocto project / OE related Oct 23 16:37:15 bluelightning: for everyone outside YP it does Oct 23 16:37:31 bluelightning: it feels like official Oct 23 16:37:36 bluelightning: it feels like endorsed Oct 23 16:37:47 well maybe the perception is what needs changing, because we cannot consider all of what is on there as being official Oct 23 16:38:02 it is largely unrestricted and should remain that way Oct 23 16:40:43 I guess the question is do we want to collect stuff on hit.yp.org Oct 23 16:40:50 git :) Oct 23 16:41:02 or do we filter for good examples Oct 23 16:41:08 it's less critical than it used to be, now that we have the layer index Oct 23 16:41:11 kergoth: Here you can find the document otavio is talking about: https://docs.google.com/document/d/1J6Bv3ZJ91B_y7T6CBBIr3eoZaFgI9Il-WNdQuscrTJs Please, see the "setup-environment hooks" section. Oct 23 16:41:15 its at least possible to finda ll the yocto layers no matter where they are Oct 23 16:41:36 it seems the concern is people making claims that because it is on git.yp.org, it is somehow better Oct 23 16:41:46 kergoth, right Oct 23 16:41:51 Crofton|work: yes Oct 23 16:42:06 but we are talking perceptions here Oct 23 16:42:09 kergoth: that's one of the reasons I set up the layer index, to avoid people choosing location based purely upon some idea of visibility Oct 23 16:42:12 Crofton|work: people thinks it is better and officialy supported/tested and like Oct 23 16:42:19 there are alot of perceptions about things Oct 23 16:42:24 right Oct 23 16:42:51 AT dev day there was a slide about why not use openemebdded ove the yocto project Oct 23 16:43:00 and I was like "stf?" Oct 23 16:43:04 and I was like "wtf?" Oct 23 16:43:19 :( Oct 23 16:43:22 that certainly doesn't sound right Oct 23 16:43:35 no Oct 23 16:43:38 it isn't Oct 23 16:43:39 yikes Oct 23 16:43:47 it is like saying why not use WRL Oct 23 16:44:01 Crofton|work: that's part of why you're on the AB, you should poke whoever's slide that was Oct 23 16:44:02 again as I said before the git.y.o needs to have some standard and process to get things there; it shouldn't be auto-granded Oct 23 16:44:05 yeah Oct 23 16:44:23 otavio: you can't police a moving repo though Oct 23 16:44:31 bluelightning: uh? Oct 23 16:44:40 police what Oct 23 16:44:45 in other words, the repo could become non-compliant when you aren't looking :) Oct 23 16:44:59 otavio: someone looks at my repo now, it might be OK... then later I add some awful structure in it - how does that get picked up? Oct 23 16:45:04 but usually people that start out on the right track do not screw up badly :) Oct 23 16:45:17 mario-goulart: thanks, taking a look at that Oct 23 16:45:44 Cool Oct 23 16:46:02 mario-goulart: i like the EULA feature :) Oct 23 16:46:07 bluelightning: sure; agreed. But something like a 'all repos included' which duplicates a lot of stuff and makes the layering concept voided does not would be accepted. Oct 23 16:46:15 kergoth: this is indeed nice Oct 23 16:46:43 bluelightning: it can be 'made bad' after accepted Oct 23 16:46:52 otavio: let me explain why it was done that way, because ultimately it was my decision Oct 23 16:47:10 bluelightning: but we'd also use and complain Oct 23 16:47:51 otavio: when we did the first release we did heavy patching to bitbake and the core, and added additional metadata, and we had a very limited time to do it in Oct 23 16:48:06 bluelightning: oh my. I thought it was done by someone not involved :-( Oct 23 16:48:12 patches did get sent for merging back into the appropriate repos, I made sure of that Oct 23 16:48:19 bluelightning: you could have putted it in github.com/Intel Oct 23 16:48:29 possibly should have, yes Oct 23 16:48:32 hindsight is 20/20 Oct 23 16:48:33 but ... Oct 23 16:49:19 well it is not my call but it does remind me all the Puselbo and GMA500 which Intel did and backfired to them. Oct 23 16:49:22 :( Oct 23 16:49:30 ok; not my call Oct 23 16:49:42 well; let me go back to work Oct 23 16:49:50 I don't think that is a particularly fair comparison FWIW Oct 23 16:51:09 It sounds like either git.y.o is official/compliant only, in which case it needs more control (which doesn't seem to be the case), or it's not, in which case we need more/better verbiage to that effect. Oct 23 16:51:39 kergoth: right, that's the question, I think we need the latter for the avoidance of any misunderstanding Oct 23 16:52:58 All that short on time things in yp is pissing me off. I had a very hard time fixing Qt which was broken a 2 weeks before release; packagedata is also broken and still failing for me in 2 weeks ago QA test change; now this new 'layer/build system' Oct 23 16:53:02 :( Oct 23 16:53:50 so, how do we fix that? Oct 23 16:54:08 FWIW, the devkit repo isn't new... Oct 23 16:54:09 bluelightning: well, we need to not try to fix all things 3 weeks before release Oct 23 16:54:46 kergoth: overall I am not totally satisfied with our approach for setup-environment. In the end it is a pile of hacks that turn out to be quite useful, but the implementation is very ugly. Too bad I didn't know how to use bitbake's libs when we started that. We have a hand-rolled parser that pretty much duplicates (badly, probably) what bitbake does. OTOH, in terms of features it does the trick for our needs. Oct 23 16:54:46 bluelightning: and this also invove talking to AB for new yp additions in my opinion Oct 23 16:55:12 what constitutes a "new yp addition" though? Oct 23 16:55:35 bluelightning: for git repositories and things which are included in the official infrastructure Oct 23 16:55:51 again, the perception there is the problem Oct 23 16:56:03 bluelightning: the kinda same process of YP Compatible Oct 23 16:56:24 bluelightning: no; I would have voted no for a addition which does not enforces the use of layers Oct 23 16:56:57 bluelightning: specially because this is a key feature which we strongly support Oct 23 16:57:05 well, you are free to raise that with the AB Oct 23 16:57:50 this is a good topic for the AB Oct 23 16:58:00 I will say I did not like doing things the way they were done in that repo but I felt like I didn't have a choice given the requirements and the time available Oct 23 16:58:02 we nee to clear up some of these misconceptions Oct 23 16:58:13 and that's all I have to say about that for the moment Oct 23 16:58:29 bluelightning: I think the YP brannding needs to be careful used and anything which does not support same principals of YP should not be, in any way, related to it Oct 23 16:58:51 bluelightning: so next time use github for this Oct 23 16:58:59 bluelightning: not official infra Oct 23 16:59:04 bluelightning: :( Oct 23 16:59:24 this is very disappointing :( Oct 23 17:00:44 otavio: On the subject of bugs late in the release, I'm struggling to find people willing to spend time on bug fixing Oct 23 17:01:18 otavio: on the subject of git.yp.org, its always had layers that were work in progress and did not have compatible status Oct 23 17:01:43 some of the repositories there predate that compatible status Oct 23 17:02:04 I disagree strongly with forcing things off onto github, I do agree we should have some way of indication status though Oct 23 17:02:56 tlwoerner: do you happen to know the status of the linaro cairo patches? Oct 23 17:03:15 otavio: its basically a case of continuous improvement. Its unlikely everything will be perfect tomorrow but we can improve things Oct 23 17:03:28 https://patches.linaro.org/project/cairo/ <= this stuff Oct 23 17:03:39 and we can improve how repos are marked or categorised Oct 23 17:04:29 RP, I do thinnk this is a good AB topic Oct 23 17:04:57 Crofton|work: we should discuss it however I do want people to think *really* carefully before suggesting only yp compatible layers be there Oct 23 17:05:03 sure Oct 23 17:05:12 but we need to be aware of messaging Oct 23 17:05:15 I do not think that will work in the project's favour, quite the opposite Oct 23 17:05:27 especially given the probelms we have getting everyone to say the same things Oct 23 17:11:54 kergoth: in case you didn't have any meal recently, the code is here: http://code.ossystems.com.br/gitweb?p=ossystems-yocto-base-scripts.git;a=tree Oct 23 17:12:07 hehe Oct 23 17:12:08 thanks Oct 23 17:18:34 RP: about the bugs late in the release ... I got noone working on the packagadata fix and it is still broken. You supported me somehow but we still need to fix the bug. In no way it should have been done so late in the cycle. Oct 23 17:18:59 RP: work in progrss layers fine. Bad designed ones ... not really Oct 23 17:19:51 RP: and something which voids the layering concept is unacceptable IMO Oct 23 18:11:30 RP: Daisy is broken: Oct 23 18:11:32 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=daisy&id=27a877becf76a1410aa96c02a25bb885bfbddf04 Oct 23 18:11:44 didn't include the new patches Oct 23 18:11:51 and gives file not found Oct 23 18:12:25 ERROR: Function failed: Fetcher failure for URL: 'file://Makefiles-ptest.patch'. Unable to fetch URL from any source. Oct 23 18:12:47 Have someone build it /before/ pushing? I don't think so. Oct 23 18:31:05 otavio: "I don't always test my code... But when I do, I test it in production..." Oct 23 18:34:09 nerdboy: heh :) Oct 23 18:43:02 couldn't find it so i made one... Oct 23 18:43:05 http://www.quickmeme.com/p/3w0cp8 Oct 23 18:46:13 nerdboy: :) Oct 23 18:47:37 If it compiles, it is good. If it boots, it is perfect. Oct 23 18:47:48 unfortunatelly we haven't reached level0 in this case :) Oct 23 18:51:38 BD Level 10? Oct 23 19:39:19 if I have a do_install_append i the main bb file and the bbappend, do they both get used? Oct 23 19:40:22 yes Oct 23 19:40:33 _append isn't part of the variable name, it's an operator like +=, so yeah, cumulative Oct 23 20:29:40 otavio: that code was supposed to have gone through a successful autobuilder run :( Oct 23 20:32:45 otavio: I was told it had, I did look at a green build and thought it was ok. I will try and figure out how that therefore got in :/ Oct 23 20:42:11 heh, i just noticed bitbake-layers show-appends returns an exit code of 1 for both real failures and warnings about appends only of non-preferred versions Oct 23 20:42:16 no way to distinguish short of grepping the output for the message Oct 23 20:46:10 kergoth: that sounds like something that could be improved... Oct 23 21:08:18 hi Oct 23 21:10:43 something weird is going on here with bitbake, I am trying to run menuconfig task but it doesn't show up the nurses menu it just goes from started to succeeded Oct 23 21:11:08 most likely something wrong with the terminal it's trying to spawn. the log for the menuconfig task isn't informative? Oct 23 21:11:14 you can always try explicitly setting OE_TERMINAL Oct 23 21:17:08 with -vvv I don't see anything extra Oct 23 21:18:40 it's just -v, it's not a counter Oct 23 21:18:46 to see more, use -DDDv Oct 23 21:20:27 nothing just started and right away succeeded Oct 23 21:20:52 running on a xterm I see a window popping but closes immediately Oct 23 21:20:55 weird weird Oct 23 21:20:59 never happened before Oct 23 21:22:54 and if I run it from a ssh session I get this Oct 23 21:23:04 NOTE: package linux-camr00x0-2.6.37-r10: task do_menuconfig: Started Oct 23 21:23:04 WARNING: Screen started. Please connect in another terminal with "screen -r devshell" Oct 23 21:23:05 NOTE: package linux-camr00x0-2.6.37-r10: task do_menuconfig: Succeeded Oct 23 21:23:14 and there is no screen session Oct 23 21:26:52 ok fixed Oct 23 21:26:53 thx kergoth Oct 23 21:27:13 * kergoth walks home from the coffee shop Oct 23 21:42:06 RP: seems like your force-push fixed the openssl issues ;) **** ENDING LOGGING AT Fri Oct 24 03:00:00 2014