**** BEGIN LOGGING AT Thu Jun 30 02:59:57 2011 Jun 30 06:32:54 khem ping? Jun 30 06:34:29 is the wiki slow for anyone else? or just me? Jun 30 06:43:33 ka6sox-work: yes, it is Jun 30 06:44:12 Jay7, thanks....unk as to why....everything looks good. Jun 30 06:44:25 oh well...look a bit laters...tired Jun 30 06:44:31 too big delay before responce Jun 30 06:45:25 no reason I can find....I'm asking the DBA to look. Jun 30 06:46:34 I could always try the Windows Server way of fixing...reboot. Jun 30 07:19:44 gm florian Jun 30 07:54:02 hello Jun 30 07:56:55 hi sanket Jun 30 07:57:54 I had done with changing screen resolution with fbdev..... but the problem is now when I change the resolution the color difference changes .... why is it so? and also when I pass RgbPath in XF86Config file ... I m getting ... Ignoring obsolete keyword "RgbPath". Jun 30 07:58:18 hi woglinde Jun 30 07:58:49 sanket_ than the xserver you have dont support it Jun 30 07:58:52 or the driver Jun 30 07:59:12 when does the color changes in xorg or in fb? Jun 30 08:01:27 woglinde, in xorg... this is my XF86Config file http://pastebin.mozilla.org/1261226 Jun 30 11:33:40 Aside from examining log.do_rootfs for the recipe (in my case core-image-minimal), is there any way to see what packages actually got installed to satisfy dependencies? Jun 30 13:15:11 can any one tell me how can i change this setting : xres = 800, yres = 480 ,I am using tslib Jun 30 13:47:50 To use an override to append to a variable (e.g. EXTRA_OECONF), is the correct syntax EXTRA_OECONF_pn-foobar += "myconfig" ; or EXTRA_OECONF_append_pn-foobar = "myconfig" ? Jun 30 13:52:48 thhp: the latter Jun 30 13:52:57 the former will replace, not append Jun 30 13:53:06 hi kergoth____ Jun 30 13:54:56 heh, hey pb_ Jun 30 13:55:23 pb_: thanks :-) Jun 30 14:01:09 thhp: with the former, the += adds to the EXTRA_OECONF_pn-foobar variable, which then *replaces* the EXTRA_OECONF variable, so its no longer really an append, the original contents of EXTRA_OECONF would be lost Jun 30 14:01:38 the key to remember is that append, prepend, and overrides are evaluated at the end of parse process, while +=, =+, .=, and =. are immediate Jun 30 14:01:49 Warning: contentious comment ahead :-) I'm getting the feeling that oe-core lacks some features that might be helpful in building custom distributions. It seems like lots of packages have hard dependencies on what could be optional features. For example, gst-plugins-base depends on theora. Surely that dependency should only be in place if you configure gst-plugins to build the theora plugin? I'm hoping that I've just missed the right Jun 30 14:02:14 Is there a mechanism which allows autoconf params to be mapped to a dependency? Jun 30 14:02:18 celston: you're probably right. patches welcome. Jun 30 14:02:28 kergoth_: ah... that makes a lot more sense, thanks for the clarification. Understanding how and when things are parsed really helps predict what bb is going to do... Jun 30 14:02:31 kergoth: I thought you might say that :D Jun 30 14:02:43 thhp: yeah, its unfortunate that so much depends upon processing order :\ Jun 30 14:03:15 I don't want to seem ungrateful for the work that's gone in so far, oe clearly wins on lots of fronts. Jun 30 14:03:22 kergoth_: it's the same thing one trips over in make: until you grok how it parses input files, you don't really have a chance Jun 30 14:03:42 celston: there isn't any such mapping mechanism. of course, you can set DEPENDS and EXTRA_OECONF from your distro config, so you do get the opportunity to do the customising, but it's a bit clunky. Jun 30 14:03:44 thhp: .SECONDEXPANSION anyone ;) Jun 30 14:03:48 celston: :) there's no direct equivalent to gentoo USE or anything, generally we implement equivalent features ourselves using different variables depending on the purpose. in this case, i could see adding something like a gstreamer plugins variable Jun 30 14:04:12 thhp: heh, well, bitbake is conceptually based on make. that's why our expansions are lazy, and := forces immediate, pulled directly from make Jun 30 14:04:17 so not too surprising Jun 30 14:04:36 guess its a love child of portage and make, or something ;) Jun 30 14:04:38 celston: unfortunately, there is something of an ingrained antipathy in certain quarters to anything that looks or smells like a USE flag. I think most of the objections to that are misconceived, but still. Jun 30 14:04:48 kergoth_: I've been approaching it as a make++, in some respects Jun 30 14:05:23 Originally, I disliked it due to the single flat namespace. I was never opposed to the concept so much as their implementation of it.. but others have stronger feelings :) Jun 30 14:05:32 pb_: without wanting to fan any flames, what is the argument against a USE flag style of approach? Jun 30 14:05:34 It seems like recipes aren't very configurable, whilst packages generally are. A recipe presents only one way to build something, with a fixed set of dependencies. Jun 30 14:06:24 tthp: there's been various discussion of it on the mailing lists, but the general argument seems to revolve around the idea that the output of a recipe will somehow become nondeterministic if you allow it to be tailored in that way, and that this would be a nightmare for people wanting to build feeds. Jun 30 14:06:28 celston: that is true. there are multiple issues with adding more variables to manipulate more recipes. in one case, i could see koen having strong objections due to the fact that a given package will no longer have known deterministic contents Jun 30 14:06:31 kergoth_: I see namespacing as a big win for bitbake -- it's too easy to trip over your own toes in a big make-based project Jun 30 14:06:32 pb_: :) Jun 30 14:06:54 the other thing i worry about is the proliferation / expansion of the configuration namespace. its already a pain in the ass to discover what a user can set Jun 30 14:06:55 now, I think this is a nonsense because those folks who want to build feeds can just nail down the USE flags in whatever way they want, and there are already a myriad ways to break binary compatibility of packages without having USE flags at your disposal. Jun 30 14:07:08 we need a way for a recipe to advertise "i have these configuration variables available, they work in this way" Jun 30 14:07:37 kergoth: right, that is a valid concern. I hope that oe-core will be a bit less awful in that respect than oe.dev has become. Jun 30 14:07:49 most packages are not deterministic anyway as configure typically picks up dependencies based on whatever you build before Jun 30 14:08:05 It's certainly difficult as a newbie to figure out the right lever to pull to get the required effect. Jun 30 14:08:09 eFfeM_work: we *always* want to force the configure scripts to do one or the other Jun 30 14:08:15 eFfeM_work: any case where its left automatic should be fixed Jun 30 14:08:28 eFfeM_work: well, yeah, but that is (in most cases) just a bug. Jun 30 14:08:49 celston: heh. it is not always straightforward to figure that out even as a (relative) non-newbie. Jun 30 14:08:53 kergoth_ I fully agree, but few people actually peek at configure scripts and options Jun 30 14:09:01 pb_: one thing i've always rather disliked is its not entirely clear what variables are intended to be user changable, vs those that are set just as internals / implementation details. like all the target sys / prefix / etc Jun 30 14:09:07 yeah, exactly Jun 30 14:09:16 that whole area is full of suck Jun 30 14:09:46 probably all recipes doing a configure should have an OE_RUNCONF or so definition that enables and disables what is needed, but most don't Jun 30 14:09:49 like, to take an example from recent discussions, BASE_PACKAGE_ARCH. I still don't really understand who is meant to set that and when. Jun 30 14:10:04 most rely on having all they really need in their DEPENDS Jun 30 14:10:05 and, judging from some of the patches that I have seen, I am not the only one in this position :-} Jun 30 14:10:06 eFfeM_work: yeah, but they need to stop that. we're never going to get stable deterministic builds until people do Jun 30 14:10:17 kergoth_: or until we have per recipe sysroots, heh Jun 30 14:10:20 heh, indeed Jun 30 14:10:28 s/we have per recipe sysroots/hell freezes over/ Jun 30 14:10:36 pb_ indeed, that was what I wanted to say Jun 30 14:10:44 teh per recipe sysroots Jun 30 14:10:47 What does a per-recipe sysroot give us? Jun 30 14:10:55 pb_: have to say, i'm somewhat tempted to either try another bitbake rewrite, or join the oe-lite camp, some days.. Jun 30 14:10:58 no idea why people are so against having per recipe sysroots Jun 30 14:11:06 celston: it means what the recipe finds in the sysroot won't change as other things are built Jun 30 14:11:10 it'll only have the things it depends upon Jun 30 14:11:12 oe-lite has this Jun 30 14:11:13 eFfeM_work: who is against it? Jun 30 14:11:19 eFfeM_work: i dont know of anyone who's against it Jun 30 14:11:22 I can't think of anybody who is actually opposed to the idea Jun 30 14:11:27 its just no one has figured out how to get the thing implemented cleanly Jun 30 14:11:31 kergoth_: is DEPENDS not the correct way to specify what a package needs to build? Jun 30 14:11:37 thhp: it is Jun 30 14:11:55 celston: exactly what we want, and nothing more Jun 30 14:12:13 I think esben tried to initiate some discussion in the past on this, but got little encouragement Jun 30 14:12:32 and afaik oe-lite has this Jun 30 14:12:37 RP has agreed that we need it, and thinks the sstate stuff will help in that direction Jun 30 14:13:11 i don't know of any strong opposition to the concept, just the implementation may draw fire. oe-lite takes a different approach, different enough that oe isn't going to be following them anytime soon Jun 30 14:13:16 heh Jun 30 14:13:21 * kergoth_ gets caffeine Jun 30 14:14:52 kergoth_ I'm not sure if the oe-lite direction is worse, sometime change has to be radical Jun 30 14:17:24 eFfeM_work: i like the consolidation of the dependencies, I think its quite a bit less confusing for people Jun 30 14:17:55 From my point of view, trying to build an embedded product on oe-core would be difficult at this stage because of having to reach into recipes to remove things which the recipe author wants, but my product doesn't. And until the mechanism to do that is present in oe-core, my hacks to do that will be fragile and a maintenance issue. Jun 30 14:18:11 celston: well, you can use bbappends to override anything via a local layer Jun 30 14:18:12 it definitely is Jun 30 14:18:15 thats a general mechanism Jun 30 14:18:25 not always pretty, but.. :) Jun 30 14:19:03 yeah. and, of course, there is DISTRO_FEATURES for global things. Jun 30 14:19:30 I understand layers, I don't understand bbappends yet. /me needs to do some more reading :) Jun 30 14:19:35 I suppose the worry would be that anything one overrides in a local layer would be subject to bitrot wrt oe-core mainline Jun 30 14:19:47 Somewhat like trying to maintain a kernel module out of tree Jun 30 14:20:17 Whereas if recipes really did advertise their configuration switches, you could tell when a switch you used went away. Jun 30 14:20:35 or rather, automatically detect the absense of a switch your layer is flipping. Jun 30 14:20:42 celston: .bbappend is parsed and merged with the metadata from . its that simple. its like concatenating them. so you can do anything there you could do at the end of the recipe. filter things out, override vars, etc Jun 30 14:21:23 Then again afaik it is not obvious how to tweak a recipe to take into account different machine characteristics, you can tell that you have no audio but do have bluetooth but most likely the bluetooth recipe will still have a DEPENDS on the audio stuff Jun 30 14:21:28 kergoth`: cool, thanks. Jun 30 14:21:57 so you'd .bbappend to filter the bluetooth recipe's DEPENDS ? Jun 30 14:22:13 yeah. or in the specific case of audio, that would be a sensible thing to use a DISTRO_FEATURE for. Jun 30 14:23:25 eFfeM_work: thats what machine and distro features are for, and specifically, combined features. Jun 30 14:23:48 a feature is in COMBINED_FEATURES only if its in both machien and distro, meaning its both a capability of the hardware and supported by the distro Jun 30 14:25:13 kergoth` I know but for instance blue4 has a hard coded DPENEDS on libsndfile1 Jun 30 14:25:39 and bluez4.inc says: DEPENDS = "gst-plugins-base alsa-lib virtual/libusb0 dbus-glib" Jun 30 14:25:47 fix it :) Jun 30 14:25:51 that's just a bug. Jun 30 14:25:55 that drags in a lot of stuff Jun 30 14:25:56 presumably blue4 should append to DEPENDS based on something in COMBINED_FEATURES...? Jun 30 14:25:57 more generally, the whole bluez packaging is a bug. Jun 30 14:26:38 thhp: well, in an ideal world the monolithic bluez recipe just wouldn't exist. Jun 30 14:26:49 but yeah, as long as it does, it probably should indeed do what you say Jun 30 14:27:05 bluez packaging could indeed improve Jun 30 14:28:31 yeah. volunteers welcome I guess. Jun 30 14:28:40 in fact, kergoth` did some work on that a while back if I remember correctly Jun 30 14:28:48 not quite sure what became of those efforts Jun 30 14:32:46 well as it stands I'm currently not using bluez, actually I was just giving it as an example Jun 30 14:33:08 openssh_5.6p1.bb is a good example of adding a feature based on DISTRO_FEATURES, even does the right thing with DEPENDS. Jun 30 14:33:51 right Jun 30 14:34:04 I guess you could make it a teensy bit neater with a function which you tell the OECONF string, and the dependency that it adds, and it modifies the OECONF and DEPENDS for you. Jun 30 14:34:25 yes, that would be cute Jun 30 14:35:16 celston: true, nice example Jun 30 14:37:59 personally I would like it to be a little bit simpler, so no base-contains or so, but something like DISTRO_FEATURES('pam', '--with-pam', '--without-pam') or so Jun 30 14:41:19 eFfeM_work: well, you'd have to pass 'd' in too, but otherwise no reason you couldn't define that in utils.bbclass Jun 30 14:42:49 thhp: re bitrotting, over time we want to try to improve layer tooling to a point where you can more easily see when you need to rework some overridden item in your layer because something underneath changed Jun 30 14:43:09 kergoth` well I am not too good in python; also it would be nice to get rid of the ,d too; I can explain the example I gave in if/then/else terms, but can't really explain the d too well; it is something from teh implementation that surfaces through at the user level (but ideally shoudl not) Jun 30 14:43:17 thhp: I don't think it's going to be able to catch everything but it will help a lot I think Jun 30 14:43:48 eFfeM_work: well, fyi, if you're using recent bitbake Jun 30 14:43:55 eFfeM_work: you can access variables without using d Jun 30 14:44:02 Something like: def oe_distro_feature(feature, switch_on, switch_off, dependencies, d) ? Jun 30 14:44:15 eFfeM_work: FOO = "${@BAR + 'meh'}" Jun 30 14:44:19 celston: yep Jun 30 14:44:28 and one for machine_feature and combined_feature. Jun 30 14:44:40 eFfeM_work: it makes the variables available in the python namespace Jun 30 14:44:59 eFfeM_work: not sure if itd work in functions too, though. and of course, they're all strings Jun 30 14:45:31 ${@'--with-foo' if 'something' in DISTRO_FEATURES.split() else '--without-foo'} -- perhaps? Jun 30 14:45:37 is that any clearer? Jun 30 14:45:48 pretty sure python does support that syntax, i never use it though Jun 30 14:46:37 the favourite idiom in oe seems to be ['--without-foo', '--with-foo']['something' in DISTRO_FEATURES.split()] Jun 30 14:47:08 dunno if that, again, is actually any clearer or not Jun 30 14:47:13 i dont think the if/else syntax even existed when we started :) thiink that was probably the only choice Jun 30 14:47:17 * kergoth` doesn't know either Jun 30 14:48:05 I find the if/else thing a bit too close to perl for comfort. Jun 30 14:49:45 I guess the next version of python will add the "oh but unless" keyword :-} Jun 30 14:50:02 hehe Jun 30 14:50:03 agreed Jun 30 14:50:10 thats why i avoid it generally Jun 30 14:50:20 is there an easy way to /remove/ a string from a variable? For example, util-linux has --enable-partx ; but I'd like to disable partx for uclibc builds Jun 30 14:50:30 i still think lua would have been a better choice for the inline snippets Jun 30 14:50:33 you can use ${@oe.filter_out} Jun 30 14:50:37 oe_filter_out Jun 30 14:50:40 thhp: not directly. there's no -=, but as pb_ says, you can use oe_filter_out Jun 30 14:50:46 oh yah, with the underscore Jun 30 14:51:21 Is there a fn to append a var in python, aside from getVar/setVar ? Jun 30 14:51:35 funnily enough I could have sworn there used to be a _remove override, the opposite of _append, but when I looked at the code the other day I couldn't find any evidence that it ever existed Jun 30 14:51:36 heh Jun 30 14:52:26 celston: sadly no. the whole get, modify, set idiom is rather annoying, but thats the way it is Jun 30 14:52:35 celston: mm, dunno. obviously you can use kergoth's eleet vars-in-python notation to access the old value, but I gues they are probably not mutable Jun 30 14:52:45 hmm, i dont remember if they are or not Jun 30 14:52:46 * kergoth_ checks Jun 30 14:53:15 yeah, not mutable at the moment Jun 30 14:54:06 https://gist.github.com/745456 Jun 30 14:54:17 i haven't touched this in a while, bu t started experimenting with a more usable wrapper for data smart Jun 30 14:54:32 with that one, since accessing by key is expanded rather than unexpanded which is the case iwth the main one Jun 30 14:54:39 you could do newd["FOO"] += " bar" Jun 30 14:54:50 though, that would force an immediate expansion Jun 30 14:54:50 Was just looking in data_smart.py :) Jun 30 14:54:50 hmm Jun 30 14:54:55 * kergoth_ ponders Jun 30 14:57:55 Is there a way to get a python shell with the same config and namespace as a recipe, for prototyping? Jun 30 14:58:07 like devshell, but python :) Jun 30 14:58:47 hmm, not easily. you could inject a pdb.set_trace() somewhere, but i doubt itd be of much use since the server process kills its stdin/stdout/stderr, iirc Jun 30 15:00:15 celston: maybe you can add a hook to your recipe to evaluate python code from a file. Jun 30 15:00:42 if you just want to run python code at parse time, use an anonymous python function or event handler Jun 30 15:00:46 Not exactly a shell, though... Jun 30 15:03:19 was afk and need to run, but interesting discussion, will read back later Jun 30 15:21:16 How about a set of PACKAGE_FEATURE_${PN} variables? Each package would define a default features, distributions could then filter/add to that variable, then the recipe uses it to tweak the OECONF and DEPENDS. Jun 30 15:21:27 e.g.: PACKAGE_FEATURE_gstreamer += ogg Jun 30 15:22:05 This would keep the 'we want a defined set of working config' happy (i.e.: the default), but allow others to configure as they see fit. Jun 30 15:32:47 I don't much like the idea of an array of PACKAGE_FEATURE_foo variables being set in a central config file. But I could probably support the idea of each recipe defining its own PACKAGE_FEATURES and letting distros override it if they wanted. Jun 30 15:35:34 pb_: I wasn't imagining a central config, I thought of it like you described. Jun 30 15:36:55 ah, okay Jun 30 15:36:58 sounds like a sensible plan to me Jun 30 15:37:12 I guess you could go ahead and suggest that on the mailing list. Jun 30 15:37:21 I have this working now: Jun 30 15:37:23 python __anonymous () { oe_feature_switch("DISTRO_FEATURES", "libogg", "--enable-ogg", "--disable-ogg", "libogg", d) } Jun 30 15:37:49 So it's just a small step to make it PACKAGE_FEATURES_${PN} instead. I'll code it up and post something for discussion. Jun 30 15:38:21 righto, very good Jun 30 15:38:39 be prepared for flamage and "NAK, no USE flags in OE!" kind of responses though :-} Jun 30 15:38:44 I think it would be easy to warn about feature switches which the package doesn't parse too - i.e.: detect bitrot. Jun 30 15:38:56 pb_: will do :) Jun 30 15:39:08 celston: i'd say don't make it PACKAGE_FEATURES_${PN}. just make it PACKAGE_FEATURES. recipe defines it with ?=, distro can use teh pn-${PN} override to set it on a per-recipe -basis Jun 30 15:39:45 * pb_ rebooting Jun 30 15:39:48 bbiab (I hope) Jun 30 15:40:08 well, rebooting my computer, I guess I should be more careful about intransitive verbs Jun 30 15:44:34 kergoth`: daft question, I don't understand the reference you made to pn-${PN} :| Jun 30 15:44:46 not familiar with overrides? Jun 30 15:45:02 Clearly I *should* be. Jun 30 15:45:05 :D Jun 30 15:45:46 celston: eg. PACKAGE_FEATURES_pn-util-linux += "foobar" Jun 30 15:46:14 cool, thanks thhp Jun 30 15:50:25 instead of exposing recipes to python constructs to access PACKAGE_FEATURES, you could move this to some common python code, which set's up variables according to PACKAGE_FEATURES and configuration of those. This is the way it is done in OE-lite, and makes recipes more "clean" IMHO. Jun 30 15:50:52 Warning: examples will include the profane world "USE".... Jun 30 15:51:05 a recipe sets RECIPE_FLAGS="foo bar" Jun 30 15:51:20 machine sets MACHINE_USE_foo = "1" Jun 30 15:51:40 recipe can acess USE_foo, and it will be set to "1" or that particular machine. Jun 30 15:51:56 no fancy python constructs needed in recipes. Jun 30 15:53:34 an extra benefit of this, is that the recipe can be determined to be machine specific based on it's MACHINE_USE_* variables, and the recipe's RECIPE_FLAGS. Jun 30 15:57:35 esbenh_home: I understand, but this isn't a machine flag. Do you have something similar for distro? Jun 30 15:59:11 Equally this is something we need, so if I can get it in oe-core without the word U-S-E in there, then all to the good :) Jun 30 15:59:27 Do we have any idea what the objections are to use flags? Jun 30 15:59:55 There is "only" recipe "features", but they can get their values from machine, distro, local.conf, or recipe pinning. Jun 30 16:00:14 if the value is set in distro, you can see it as a distro feature Jun 30 16:00:26 if you set it in machine, it is a machine feature, but the recipe really doesn't care. Jun 30 16:00:37 it just need to know it's value, so it can build accordingly Jun 30 16:01:09 Ah right. so USE_foo = "1" in a layer is as valid as MACHINE_USE_foo Jun 30 16:01:36 It seems long winded compared to PACKAGE_FEATURES-pn_pkgname = "foo bar baz" Jun 30 16:01:46 And you can also filter out features from the default list, this way. Jun 30 16:02:01 you'd have to do: Jun 30 16:02:07 USE_foo = "1" Jun 30 16:02:11 USE_bar = "1" Jun 30 16:02:15 USE_baz = "1" Jun 30 16:02:15 no? Jun 30 16:02:34 you set MACHINE_USE_foo in machine configs, DISTRO_USE_foo in distro configs, and in same way LOCAL_USE, RECIPE_USE, DEFAULT_USE. Jun 30 16:02:43 celston: yes, that is more cumbersome. Jun 30 16:02:54 the reason is that USE flags in OE-lite is not limited to boolean values. Jun 30 16:02:59 as noted, at the cost of some python in the recipe. Jun 30 16:03:09 Fx. MACHINE_USE_kernel_defconfig = "foobar_defconfig" Jun 30 16:03:23 but for boolean values, a more convenient syntax could be added Jun 30 16:03:31 ie. MACHINE_USE="foo bar baz" Jun 30 16:03:38 for setting them to 1. Jun 30 16:03:59 you don't need python in recipe to do that. Jun 30 16:05:23 esbenh_home: sorry, I meant in my method, it needs python. Well, it might not, but the way I've implemented it has. Jun 30 16:06:23 It just so happens that a function is a nice way to conditionally append to both DEPENDS and EXTRA_OECONF. Jun 30 16:07:43 i've been thinking the whole ${@} is a bit unnecessary. instead we could have FOO = 5 * 4 and set FOO[python] = "1" or something, and let the expansion code deal with it. would mean slightly more intermediate variables, but not many, cause 99% of the time the variable is set to a "${@}" alone, nothing outside the braces Jun 30 16:07:57 would at least reduce some of the ugliness Jun 30 16:08:00 heh Jun 30 16:08:11 Here's what I have, comments appreciated: http://pastie.org/2145446 Jun 30 16:08:21 I think the python is clunky, personally. Jun 30 16:08:41 kergoth`: great idea Jun 30 16:09:00 it also makes it possible to use any Python construct Jun 30 16:09:07 how would you know when to set FOO[python] ? Jun 30 16:09:21 if the variable's contents are python code, then you'd set teh flag so it gets evaluated as such Jun 30 16:09:25 based on the rvalue. Jun 30 16:09:34 FOO = some_function(1,2, {}) + "a string" Jun 30 16:09:56 does that complicate the non-python case? Jun 30 16:10:04 From a user point of view, it sounds great! Jun 30 16:10:19 from a "bitbake" point of view, it is also great :-) Jun 30 16:11:08 esbenh_home: heh, thats the first thing i thought of when i saw how you're handling strings in the new parser. could in theory make it all python, only issue with that would be performance. but if you use a flag to make it explicit, the perf isn't an issue Jun 30 16:11:16 * kergoth` gets food Jun 30 16:11:24 What happens in the case VAR = "blah" ? Jun 30 16:11:25 it is not nice to parse something like: FOO = "${BAR}xxx${@function(42,{},"}")}yyy${bar}" Jun 30 16:12:45 kergoth`: yes, the explicit python flag is only for needed for performance, but I fear the price of not having it is extremely high. Jun 30 16:14:25 re Jun 30 16:14:54 esbenh_home: could always make it implicit -- if its unquoted, treat it as a python construct. but the older i get, the more i worry about such 'magic' and implicit behaviors rather than just saying it Jun 30 16:14:55 heh Jun 30 16:15:00 re pb Jun 30 16:15:47 kergoth`: i thought about tying it to unquoted also Jun 30 16:15:52 might not be that magic after all. Jun 30 16:15:59 FOO = "bar" Jun 30 16:16:03 is clearly a string Jun 30 16:16:07 FOO = bar Jun 30 16:16:17 well, that was a bit more painful than I expected Jun 30 16:16:20 * pb_ stabs ubuntu Jun 30 16:16:31 anyway, working again now :-) just in time to go home. Jun 30 16:16:39 FOO = bar(hello) Jun 30 16:16:58 both looks like real python constructs Jun 30 16:17:02 true Jun 30 16:17:08 it'd be an optimization, really Jun 30 16:17:13 we know this is a string, skip compilation Jun 30 16:17:26 only issue, is that current OE developers/users might be used to using unquoted strings Jun 30 16:17:40 FOO = bar Jun 30 16:17:44 I've assumed that strings *had* to be quoted. Jun 30 16:17:47 esbenh_home: i suspect there are few to no unquoted strings in oe or oe-core today, but we're stuck supporting it for compatbility reasons Jun 30 16:17:53 nice thing about oe-lite, not constrained Jun 30 16:17:55 * zecke stabs cmake for the lack of a config.log Jun 30 16:17:57 should not be treated as the string "bar", but rather the variable bar. Jun 30 16:18:07 but in upstream oe we could just make it more explicit, use the python flag Jun 30 16:18:12 kergoth`: I had to fix a few, but not that many. Jun 30 16:18:13 oe-lite could make it nice and implicit Jun 30 16:18:16 * kergoth` nods Jun 30 16:18:48 I really like this idea, let's just do it :-) Jun 30 16:19:16 esbenh_home: one possibility would be to have an intermediate bitbake version that disables support for unquoted strings entirely, then resurrects it as python constructs in the following minor version. that'd force them to go away during the transitions Jun 30 16:20:19 * esbenh_home leaves for cooking and eating Jun 30 16:20:33 i've noticed that a lot of things in the current bitbake data/parser are basically reverse maps of flags, to avoid having to iterate over all keys at parse completion time Jun 30 16:20:40 maybe setVarFlag should just keep a reverse mapping Jun 30 16:20:43 * kergoth` ponders Jun 30 16:21:43 * kergoth` looks at datasmart to test having getvar/expand resolve python if the python flag is set Jun 30 16:22:13 kergoth`: any comments on http://pastie.org/2145446 ? I'd like to submit it to the ML, but I'd rather get a second opinion first. If there really is a lot of resistance to something like use flags, I'd rather it be as neat as possible... Jun 30 16:22:33 first thing, __anonymous is a relic Jun 30 16:22:36 python () { Jun 30 16:22:37 } Jun 30 16:23:11 other than that, it looks reasonable to me Jun 30 16:24:01 Thanks, and there isn't a cleaner way to do oe_feature_switch ? Jun 30 16:24:18 given its already pretty special purpose, i could see an argument to just shift the variable piece over, make it assume PACKAGE_FEATURES Jun 30 16:24:29 well, you end up getting the value of PACKAGE_FEATURES multiple times in a single oe_feature_switch exec Jun 30 16:24:38 youc ould get it once, split it, and don't use base_contains Jun 30 16:24:57 yep, that occurred to me. It can also be used for DISTRO_FEATURES this way though. Jun 30 16:25:15 value = d.getVar(variable, True).split(); if feature in value: ... Jun 30 16:26:01 cheers kergoth` Jun 30 16:26:21 true, but you could also just implement a translation between distro features and package features, as well. do a base_contains() in the PACKAGE_FEATURES definition to pull over the distro bits, then let oe_feature_switch() use package features, as one possibility Jun 30 16:26:26 just something to think about, not sure which is best Jun 30 16:26:39 or even PACKAGE_FEATURES ?= "${DISTRO_FEATURES}" Jun 30 16:26:44 oe_feature_switch("ogg", ....) Jun 30 16:27:13 so i think there isn't really a need to pass the variable in, given that Jun 30 16:27:20 but you could mention that in the email, ask which is better Jun 30 16:28:04 aside: everyone in here should check out gist.github.com if they don't know about it. really nice. basically a pastie/pastebin, but its a git repository you can clone and modify the files and stuff Jun 30 16:28:56 whats nice is you can use it as a sandbox to play with a new idea, then you can end up productizing it, and just then push the git repo up to a real github repository or whatever. no loss of history between the two Jun 30 16:29:03 kergoth`: re. reverse mapping, the metadata class in OE-lite does this for (select) flags Jun 30 16:29:13 esbenh_home: ah, cool Jun 30 16:29:27 it just seems like there are quite a few cases where there's code duplication, implementing the same pattern Jun 30 16:29:32 collaborative hacking, nice. Jun 30 16:29:51 for e.g. event handler registration, etc.. all to avoid the key iteration at parse completion Jun 30 16:29:56 irks me a bit :) Jun 30 16:30:40 https://gist.github.com/914343 - somewhat unrelated, but was experimenting with lua scripting in a variable rather than python :) can call d.getVar() from it Jun 30 16:38:26 kergoth`: I've read it over and over and I don't get the idea of translating between package and distro features. The reason I wanted to keep the package feature switches out of the distro features is that you might want to enable a feature in one package but not another, so they wouldn't be distro-wide. Jun 30 16:39:16 celston: well, you said you pass the variable in case you might want to use it with DISTRO_FEATURES. when exactly would you want to do that? Jun 30 16:39:32 celston: package features are contained in recipe Jun 30 16:39:35 i'm saying if something is conditional on a distro feature that would want to use it that way, you can pull the distro feature into package features instead Jun 30 16:39:40 so they are well contained Jun 30 16:40:05 it's already very special purpose, setting EXTRA_OECONF and DEPENDS, not a generally useful function Jun 30 16:40:18 True. Jun 30 16:40:19 so i'm saying its of limited usefulness to try to make it that generic, unless you have a particular use case in mind for it Jun 30 16:40:26 ack. Jun 30 16:40:44 I'll make it specific, it can always be made generic and wrapped later. Jun 30 16:41:08 * kergoth_ nods Jun 30 16:41:59 khem: which package features are you referring to? Jun 30 16:42:06 this may well be a YAGNI case :) Jun 30 16:42:34 did anyone see the thing i posted yesterday as an alternative way of implementing the git fetcher? any thoughts? Jun 30 16:42:53 kergoth: I did not Jun 30 16:43:01 kergoth: did u send it to ml Jun 30 16:43:05 not yet Jun 30 16:43:24 my thought is that DL_DIR is essentially a cache. you want files from upstream to WORKDIR, the DL_DIR is just a way to avoid doing that every time Jun 30 16:43:45 given that, and thinking of ./git-cache in the gist as DL_DIR, take a look at https://gist.github.com/1054808 Jun 30 16:44:17 ah yes we kind of discussed it some time ago Jun 30 16:44:24 yeah it would be cool Jun 30 16:44:31 note that the final cloned repo points at upstream, not the cache Jun 30 16:44:35 would avoid lot of fetching headaches Jun 30 16:44:36 so you never actually push tot he cache, no indirection Jun 30 16:44:49 it just avoids refetching things, and means that if upstream is down it still successfully gives you a clone pointing at upstream Jun 30 16:45:18 i added a 'mirror' command to the git-cache script which emits a bare repository with just the bits from the one particular upstream, meaning you can use it to produce a mirror repository you could fetch from Jun 30 16:45:44 currently multiple upstreams can live in a single cache repo, it hashes the upstream url Jun 30 16:45:55 the alternative was to name the cache repo by the URL, but that's awfully ugly Jun 30 16:46:02 and means less sharing of git objects Jun 30 16:46:09 this way all bitbake repositories share the same object store Jun 30 16:46:25 also, the whole 'git' dir name is fucking stupid Jun 30 16:46:33 we should go by the basename of the url by default Jun 30 16:47:12 so if recipe x fetches from a cvs repo Jun 30 16:47:16 how will that be handled Jun 30 16:47:20 or a simple tar Jun 30 16:48:33 thus far i've only done the git stuff with this method. ideally, i'd like to see the entire fetch api work conceptually this way, treating it as a cache Jun 30 16:51:35 * kergoth_ jots down some concept code on possible fetch apis Jun 30 16:51:38 If I understand, this is a feature a few of us have talked about here as a 'must have'. DL_DIR as a cache. Jun 30 16:51:57 The idea that it would be shareable between machines? Jun 30 16:52:42 its sharable between machines now Jun 30 16:52:51 its not so much an implementation difference as a conceptual difference, i think Jun 30 16:55:15 It is shareable, but what about concurrent access? Jun 30 16:56:28 hi again Jun 30 16:57:07 khem: https://gist.github.com/1056651 Jun 30 16:57:23 celston: file locks are used in some cases, but not sure its guaranteed safe for everything right now Jun 30 16:58:52 I think we'd be looking to share DL_DIR as widely as possible across our organisation. Developers are quite sensitive to build times :) Jun 30 16:59:17 We debated a fetcher cache, i.e.: a machine which intercepted all fetch requests. Jun 30 16:59:25 celston: you can certainly deploy a prepopulated DL_DIR into a shared place, then use PREMIRRORS to redirect all fetches to it. Jun 30 16:59:40 the only piece thats missing, really, is automatically *adding* things to that from individual engineers Jun 30 16:59:46 but its quite common to set up a local fetch mirror in companies Jun 30 17:00:00 Yes, cache-miss should trigger an upload to the cache. Jun 30 17:00:06 right Jun 30 17:00:22 hmm, probably wouldnt' be hard to add a hook for that Jun 30 17:00:34 add your own command to run at that point Jun 30 17:00:39 add it to do_fetch or something Jun 30 17:01:53 celston: another possibility would be to do something like i'm thinking about, and provide a custom class implementing the cache Jun 30 17:01:58 with add/remove methods Jun 30 17:02:08 and implement one that talks to a remote site via the protocol of choice Jun 30 17:20:02 time to go, thanks for all the help guys. Jun 30 18:16:02 I'm not sure if this is an OE issue or an Angstrom issue, but the Angstrom 2011.x I built from the 2011.3-maintenance ref doesn't give me a serial console on the BeagleBoard. Jun 30 18:26:43 hmmm. Jun 30 18:28:35 jawil06: is your serial port set correctly Jun 30 18:28:50 its changed to ttyOx Jun 30 18:28:58 starting 2.6.38 Jun 30 18:29:17 khem: Ahh, so I should pass console=tty0x? Jun 30 18:29:25 hmm Jun 30 18:29:49 jawil06: It certainly wont hurt to try it Jun 30 18:30:03 ttyO0 Jun 30 18:30:13 or ttyO1 Jun 30 18:31:04 btw, what's the proper way to do that? uEnv.txt, boot.scr? Jun 30 18:34:45 jawil06, it should be ttyO2 since .32 kernel release if I am not mistaken; you can set that paramter directly in u-boot Jun 30 18:42:17 ok so I set console=tty02,115200n8 and I get much more output on HMDI, but still nothing over serial Jun 30 18:44:59 AHA! that's an O the letter not an 0 the number. Working now! Thanks so much! Jun 30 18:45:11 ;) Jun 30 18:46:14 except for now boot is stalling... Jun 30 18:47:42 that's letter O as in OMAP :) Jun 30 18:48:41 oh, makes sense Jun 30 18:49:43 the change in recent kernels was from ttySx (as in Serial, generic) to ttyOx for OMAP-specific serial... Jun 30 18:50:27 kergoth: do you remember the details of the amend.inc class implementation and limitations? Jun 30 18:50:53 gotchya, ok so now I get kernel output, but I still don't have access to login via serial... Jun 30 18:51:14 check your /etc/inittab for the same Jun 30 18:51:42 on the beagle rootfs, not your host... Jun 30 18:51:49 yeah Jun 30 18:52:09 how come it used to set it up automatically, and not anymore? Jun 30 18:57:28 denix0: i wrote it, so i'd certainly hope so. whats up? Jun 30 18:58:52 Hi Jun 30 18:59:05 I'm newbie using OE to do some QT work. I need a bit of help. Jun 30 19:00:09 I'm building QT app and compiler can't find QWT libraries. Jun 30 19:01:24 Should I add qwt dependency to my app recipe? Jun 30 19:10:25 kergoth`: that's why I'm asking you :) what's the deal with SRCREV? seems it cannot be amended... Jun 30 19:11:01 denix0: i wouldn't think there'd be an issue, but possibly its anonfunc evaluation order? Jun 30 19:11:13 remember that amend.inc is implemented as an anonfunc, so some other anonfuncs run before it, others after it Jun 30 19:11:31 wow, i'm testing a reimplementation of bitbake encodeurl/decodeurl using the urlparse module Jun 30 19:11:48 svn://svn.enlightenment.org/svn/e/trunk;module=E-MODULES-EXTRA/elfe;scmdata=keep;proto=http: old=[2.8338546752929688], new=[0.0485076904296875] Jun 30 19:12:11 quite the difference in time there. course i had to scale it up by 1000 by running it that many times Jun 30 19:12:19 but even so.. Jun 30 19:13:52 kergoth`: that's what I thought. either way nothing I tried worked - neither SRCREV="" in amend.inc, nor SRCREV_pn-recipe=""... Jun 30 19:17:37 denix0: check -e to check sanity Jun 30 19:18:11 it shows the new SRCREV in -e... Jun 30 19:18:29 but it doesn't fetch the new SRCREV Jun 30 19:19:06 i'd start adding some prints to bitbake, go to the code which pulls SRCREV and see what its set to there Jun 30 19:19:47 sounds like a plan, once I get some time... :) Jun 30 19:20:18 hehe Jun 30 19:20:23 anyway, use bbappend ;) Jun 30 19:22:19 I know, I know :) very soon... I keep being dragged to the old stuff, which is Classic OE based Jun 30 19:22:41 you can use bbappend with classic oe, as long as bitbake is recent enough Jun 30 19:22:44 e.g. 1.12 Jun 30 19:22:57 but fair enough :) Jun 30 19:23:53 yeah, we are at 1.10 for that work... Jun 30 19:24:17 ah Jun 30 20:11:19 khem: ping Jun 30 20:13:13 khem: did you get solution to : ERROR: Function 'localedef returned an error' failed for glibc 2.14 ? Jun 30 20:32:05 03Chase Maupin  07master * r30775f90f3 10openembedded.git/recipes/udhcp/ (4 files in 4 dirs): (log message trimmed) Jun 30 20:32:05 softap-udhcpd-config: add recipe for udhcpd config files Jun 30 20:32:05 * Install udhcpd.conf file for setting up networking for Soft AP. Jun 30 20:32:05 * Allow machine specific versions of the configuration file. Jun 30 20:32:05 * Default configuration file is from the samples/udhcp.conf file Jun 30 20:32:05 in the base udhcpd package. Jun 30 20:32:06 Signed-off-by: Chase Maupin Jun 30 20:33:42 03Jeff Lance  07master * r52f5e93453 10openembedded.git/recipes/ti/am-benchmarks_1.3.bb: (log message trimmed) Jun 30 20:33:42 am-benchmarks: Remove platform dependencies Jun 30 20:33:42 * Remove platform dependencies and use architecture dependencies instead Jun 30 20:33:42 * Use OE BASE_PACKAGE_ARCH to determine architecture Jun 30 20:33:42 * Update the SRCREV to revision 66 Jun 30 20:33:43 * Update the recipe revision to 1.3 Jun 30 20:33:43 * Removed INSANE_SKIP **** ENDING LOGGING AT Fri Jul 01 02:59:57 2011