**** BEGIN LOGGING AT Fri May 01 02:59:57 2009 May 01 06:43:14 03Jan Lübbe  07fso/milestone5.5 * r255588b65a 10openembedded.git/recipes/webkit/webkit-gtk_svn.bb: webkit-gtk: bump PR for dependancy change May 01 07:51:31 good morning May 01 07:52:28 hi gremlin[it] May 01 07:53:13 hi mckoan ! May 01 07:54:08 gremlin[it]: have you finished your monthly tasks? May 01 07:55:12 no ... this weekend is/will be my last rush ... May 01 07:55:45 gremlin[it]: oh, what a pity :-( May 01 07:56:07 mckoan, need any help ? May 01 07:56:43 gremlin[it]: no thanks, I let you to your business :-) May 01 07:57:18 mckoan, ok, we will see next week so :) May 01 07:57:50 gremlin[it]: although I should work to solve a bug with kaeilos, the new splash design is getting me crazy May 01 07:58:26 ah ok ... May 01 07:58:30 and broke my distro build May 01 07:58:44 now it works only with stable May 01 08:00:22 gremlin[it]: see ya :-D May 01 08:00:43 * mckoan -> out for jogging May 01 08:02:43 goo dworkout ! May 01 08:40:26 03Andrea Adami  07org.openembedded.dev * rddc9b82bb2 10openembedded.git/recipes/ipaq-sleep/files/install-fix.patch: May 01 08:40:26 ipaq-sleep: don't strip during install May 01 08:40:26 - using coreutils this now breaks (strip: unable to recognise the May 01 08:40:26 format of the input file) May 01 09:16:17 03Andrea Adami  07org.openembedded.dev * rd6a164ef00 10openembedded.git/recipes/gpe-nmf/gpe-nmf-0.17/fix_makefiles.patch: May 01 09:16:17 gpe-nmf: don't strip during install May 01 09:16:17 - this breaks now with new install May 01 09:16:17 - strip is done in packaging May 01 09:16:18 03Andrea Adami  07org.openembedded.dev * r5d467834c5 10openembedded.git/recipes/gpe-othello/gpe-othello-0.2-1/fix-makefiles.patch: May 01 09:16:21 gpe-othello: don't strip during install May 01 09:16:23 - this breaks now with new install May 01 09:16:25 - strip is done in packaging May 01 09:16:27 03Andrea Adami  07org.openembedded.dev * r730e37bc82 10openembedded.git/recipes/gpe-lights/ (2 files in 2 dirs): May 01 09:16:30 gpe-lights: don't strip during install May 01 09:16:32 - this breaks now with new install May 01 09:16:34 - strip is done in packaging May 01 09:16:36 03Andrea Adami  07org.openembedded.dev * r19089f52d0 10openembedded.git/recipes/gpe-go/gpe-go-0.05/fix-make.patch: May 01 09:16:39 gpe-go: don't strip during install May 01 09:16:41 - this breaks now with new install May 01 09:16:43 - strip is done in packaging May 01 09:16:45 03Andrea Adami  07org.openembedded.dev * r2dbd0204e5 10openembedded.git/recipes/gpe-question/files/makefile-fix.patch: May 01 09:16:48 gpe-question: don't strip during install May 01 09:16:50 - this breaks now with new install May 01 09:16:54 - strip is done in packaging May 01 09:16:56 03Andrea Adami  07org.openembedded.dev * rdfb12be65f 10openembedded.git/recipes/gpe-calculator/gpe-calculator-0.2/fix_makefile.patch: May 01 09:16:59 gpe-calculator: don't strip during install May 01 09:17:01 - this breaks now with new install May 01 09:17:03 - strip is done in packaging May 01 09:17:05 03Andrea Adami  07org.openembedded.dev * r3b908e8548 10openembedded.git/recipes/gpe-soundbite/files/makefile-fix.patch: May 01 09:17:10 gpe-soundbite: don't strip during install May 01 09:17:12 - this breaks now with new install May 01 09:17:14 - strip is done in packaging May 01 09:29:59 morning May 01 09:31:05 moving away from install-native did break oe_libinsyall -so May 01 09:31:21 e.g. http://tinderbox.openembedded.net/public/logs/4868232.txt May 01 09:32:07 I could fix some recipes evilish doing 'install -s' but what about oe_libinstall? May 01 09:32:19 bbl May 01 09:33:52 hi ant__ May 01 09:34:26 ant__: you should fix the broken coreutils install to respect $(STRIP), just like install-native does May 01 09:34:43 re May 01 09:34:46 hi pb_ May 01 09:35:05 don't we break dbg packages stripping in do_install? May 01 09:35:44 have to go, bbl May 01 09:36:16 oh, yeah, I guess so May 01 09:36:31 in that case I guess fixing the makefiles probably is the right long term solution May 01 09:36:39 what's the issue with oe_libinstall? May 01 09:44:52 does exist patchwork for stable too? May 01 09:49:57 seems yes :-) May 01 09:50:40 I need this patchwork.openembedded.org/patch/429 , anybody could push it please? May 01 09:55:47 mckoan: only stable developers are allowed to ACK it May 01 10:03:25 XorA: it's already ack'ed it needs only a push May 01 10:04:15 XorA: maybe you meant that only stable developers are allowed to puch it? May 01 10:04:29 I think the rule applies doubly May 01 10:04:56 hehe, looks like it :-) May 01 10:05:18 thx anyway for your answer May 01 13:02:11 ok, trying to build micro-image with Angstrom to see what happens May 01 13:03:11 hi mickeyl May 01 13:03:35 pb_: oe_libinstall has nothing...I was reading 2 lines above :/ May 01 13:03:43 ant__: heh May 01 13:03:44 fixing now a Makefile May 01 13:03:45 okay, very good May 01 13:03:46 :-) May 01 13:04:32 btw, PR should not be bumped for install-fixes, isn't? May 01 13:04:39 runtime did not change May 01 13:05:04 technically I guess the runtime might have changed in this instance, due to -dbg having been broken before and now (presumably) fixed May 01 13:05:11 heh May 01 13:05:17 but pragmatically speaking I doubt anybody will care, so personally I would not bump PR for that May 01 13:05:28 ;) May 01 13:06:20 and, in the more general case, yeah, there is no need to bump PR if you're just fixing a build-time error and the output is unchanged May 01 13:06:58 yeah, we had enough gcc rebuilds lately... May 01 13:07:21 right. the whole PR issue remains fairly unsatisfactory in many respects. May 01 13:07:58 I become more and more convinced that a global (as in, cross-distro) PR setting for each package is just a bad idea and that we should give up on it. May 01 13:08:06 DISTRO_PR helps a bit with that but it doesn't solve everything. May 01 13:08:46 pb_, you should talk to kergoth about oe-ng :) May 01 13:10:59 yeah, indeed. May 01 13:11:49 03Andrea Adami  07org.openembedded.dev * r0fce2a2207 10openembedded.git/recipes/libdisplaymigration/ (3 files in 2 dirs): libdisplaymigration: Makefile fix - don't strip on install May 01 13:12:07 it's a shame we didn't think about this more carefully back in 2004 or whenever it was, but still. oh well. May 01 13:12:34 if this is the worst problem OE has, good job :) May 01 13:13:21 morning pb_ May 01 13:13:51 heh. well, I certainly don't think it's the worst problem OE has, but it's probably one of the most obvious flaws in the way the packaging system is designed. May 01 13:49:22 pb_: I'd really like to see better tracking of input & output to/from tasks and builds. if we knew what fed into a given task.. what vars are used by it.. then we'd know which vars, when changed, require rebuilds and/or packaging version changes May 01 13:49:39 * kergoth yawns, goes to get ready for work May 01 13:51:46 kergoth: yah, that'd be a significant improvement. obviously, with the level of exporting that goes on right now, the number of vars that are potentially visible to a package's own build scripts is pretty massive, but one could imagine making that more restrictive in the future. May 01 13:53:23 03Andrea Adami  07org.openembedded.dev * r256ed158c7 10openembedded.git/recipes/gpe-confd/ (files/makefile-fix.patch gpe-confd_0.16.bb): gpe-confd: Makefile fix - don't strip on install May 01 13:53:24 03Andrea Adami  07org.openembedded.dev * r90a6009678 10openembedded.git/recipes/xst/ (files/makefile-fix.patch xst_0.15.bb): xst: Makefile fix - don't strip on install May 01 13:55:01 03Angus Ainslie  07fso/milestone5.5 * r19b22f15b1 10openembedded.git/recipes/e17/e-wm/enlightenment_start.oe: May 01 13:55:01 e-wm : make enlightment_start.oe check for user defaults. May 01 13:55:01 If there are no user defaults then use the system default profile May 01 13:55:02 03Angus Ainslie  07fso/milestone5.5 * r1435b8ec0e 10openembedded.git/recipes/openmoko-projects/paroli_git.bb: paroli : set paroli as the system default theme when paroli-theme is installed May 01 13:55:04 03Angus Ainslie  07fso/milestone5.5 * r9996c0617e 10openembedded.git/: Merge branch 'fso/milestone5.5' of git@git.openembedded.net:openembedded into fso/milestone5.5 May 01 13:55:37 kergoth: the other thing I was thinking of was replacing PR with a generated, opaque build signature (conceptually, something like an md5 hash of either all the input to a package build) and then leaving it up to the DISTRO to maintain (in a semi-manual kind of way) a mapping between these revisions and the actual user-visible PRs. of course, DISTROs who don't want to distribute individual package binaries (i.e. their only output is a whole-flash image or someth May 01 13:55:37 ing similar) could just not care about that. May 01 13:56:18 this'd avoid the somewhat aggravating thing that happens at the moment where, for example, everybody ends up having to upgrade their installed glibc because angstrom bumped PR for some change that nobody else really cares about. May 01 14:05:02 yeah, thats the sort of thing i was thinking of too. unfortunately as things stand today a configuration signature would include a billion things it probably wouldn't need to, and since we lack variable reference tracking, trying to blacklist things like DATE/TIME/etc from causing rebuilds would be a fair bit of hassle. need bitbake changes to facilitate something like this May 01 14:06:00 right May 01 14:06:09 Crofton|work, I've asked in #boost how to pass LDFLAGS...and I've put linkflags='${LDFLAGS}' in BJAM_TOOLS and it worked May 01 14:06:18 great May 01 14:06:19 (it passed the GNU-hash check) May 01 14:06:25 thanks for looking after boost May 01 14:06:33 ok May 01 14:06:48 it's because I need it(wesnoth) May 01 14:06:48 pb_, why not make a preferred_PR file? May 01 14:06:52 heh May 01 14:07:19 pb_: one interesting possibility is using a signature to control rebuilds based on metadata changes, and then controlling distro package PR by bumping it at each official build cycle by their tinderbox, when the signature changes, or something, rather than manually maintaining it, heh May 01 14:08:19 * kergoth heads into the office May 01 14:10:09 ~botmail for kergoth: yeah, that's more or less what I was thinking of with "semi-manual". the idea would be that you'd only bump PR if, at the point where you wanted to release a new package, the output md5sum was different to the last one you shipped. May 01 14:22:43 03Andrea Adami  07org.openembedded.dev * r17c1e6796e 10openembedded.git/recipes/gpe-su/ (files/makefile-fix.patch gpe-su.inc): gpe-su: Makefile fix - don't strip on install May 01 14:37:08 * mwester despises hashes for any versioning information; if these numbers are used by or seen by human beings, they must be integers, increasing over time. May 01 14:46:05 hi,how do I find the module of a svn repo? May 01 14:48:27 03Andrea Adami  07org.openembedded.dev * raed989bee8 10openembedded.git/recipes/minilite/ (8 files in 2 dirs): minilite: Makefile fix - don't strip on install May 01 14:53:21 mwester: right, the point would be that the opaque hashes never would be used by humans. May 01 14:53:33 it clearly would suck to have the hash string be visible as part of the end-user package management. May 01 14:54:48 even the distro maintainer wouldn't have to interact with the hashes directly, it'd just be a case of running a script to capture "today's" set of hashes and assign them to appropriate PR numbers. May 01 14:56:30 * kergoth yawns May 01 14:56:41 kergoth: wb May 01 15:00:46 pb_: lately I've been mulling over the possibility of splitting up some aspects of the metadata. things like package.bbclass neednt feed into the recipe's metadata at all. all a recipe *really* needs to know how to do is produce binaries from source (or prepare scripts ,whatever), and deploy that into the expected structure it wants to run in (aka install). if input & output artifacts were truly tracked across those two operations, then all the packaging, e May 01 15:03:56 sleeeepy May 01 15:04:08 yeah, that'd make a lot of sense too. right now we have what you might call a vertically integrated description structure, where the single recipe file controls all aspects of the package lifecycle. but that does increasingly seem like a stress point: aside from obvious things like whether or not you want debian.bbclass, different distros have quite different ideas about what files should go in what output package. May 01 15:04:32 indeed May 01 15:04:34 having a load of FILES_blahblah_DISTRO-override kind of stuff in the .bb files is a weak solution since it doesn't scale and would just end up in a nightmare of merge conflicts May 01 15:05:39 aye, if we move it out of the recipe, it would be a lot cleaner. the distro could then write a set of rules to manipulate packaging in these post-recipe operations instead May 01 15:06:04 and, by the same token, configuration policy perhaps doesn't belong in the .bb files either. This mantra of "no USE flags in oe" which seems to have popped up from somewhere is all very well as a statement of policy in a vacuum, but nobody has yet proposed a better way of solving that class of problem. May 01 15:06:08 my thought is a recipe only needs to contain whats truly unique for that recipe. how is *this* package built, given its buildsystem, and what descriptive metadata do we have on it. May 01 15:06:20 right, I'd agree with that. May 01 15:07:18 the currently fashionable strategy seems to be to make a variant .bb file for each different permutation of policy options, but again I don't think this is satisfactory: it doesn't scale, as before, and it leads to a worse user experience since all your packages now have crazy names. May 01 15:07:32 configuration should be something separate that the recipe can poke into. I'm not entirely sure how best a new configuration value should be declared, though. I'm sure it should be *declared* though, so you know the exact valid arguments, and have documentation, for use iwth a configuration frontend May 01 15:07:40 right May 01 15:08:10 pb_: richard did do that patch to facilitate package variants via loading extra classes, which he used to ditch native in poky, which is nifty, but obviously doesn't solve the other problems we've discussed May 01 15:08:59 yeah, I never really looked at that patch in detail but it seemed quite clever. as you say, though, it doesn't really solve the big-picture issues. May 01 15:09:48 whether the -native stuff is implicit or explicit is, in some sense, just presentational sugar; I don't think it makes a lot of difference to the underlying workflow. May 01 15:13:10 another thing along similar lines to that patch which I've been looking at recently is allowing you to have a kind of "template recipe" which isn't buildable by itself but contains placeholders for other bits of metadata to be substituted in. May 01 15:13:54 most particularly, I want to be able to define a kind of abstract .bb file for a package without needing to nail down the version number, and then for "bitbake foo-1234" to substitute the right PV into the package recipe (and hence into SRC_URI or whatever) and do the business. May 01 15:14:19 that sounds promising, something slightly more structured than tons of recipes and .inc files May 01 15:15:29 yeah. annoyingly it's somewhat awkward to implement with the current bitbake codebase because it uses the leafname of the .bb file as the primary key for thinking about recipes. May 01 15:16:27 I think probably what I'm going to end up doing in the short term is fiddling it so that recipes with substitutions end up being internally named something like "fish.bb?PV=1234". kind of ugly but I haven't found any better solution. May 01 15:17:16 on the primary key thing, I've always thought relying on pn/pv/whatever for that was silly. I'd like to be able to request a native version of a package without it having to manipulate pn to accomplish it. instead stay, i depend on someone that provides this, that variant. or even, i want the package that provides ncurses and native, perhaps.. May 01 15:18:14 heh, well, whatever works. i assume you have a pressing need for this thing to accomplish something specific for work, or are you just toying around with a long time annoyance? May 01 15:19:03 yeah, I basically need this to make bitbake usable for our own firmware releases at work. our R&D won't tolerate having to create a new .bb file every time they release one of the components. May 01 15:20:04 pb_, beatings won't work? May 01 15:20:15 if I can't get bitbake to do the right thing then, obviously, the fallback position is just to write a script that mechanises the creation of the .bb file, but that would be pretty ugly too. May 01 15:20:40 some of our packages get released multiple times per day, so we'd quickly end up with thousands and thousands of trivial bb files May 01 15:20:46 yikes May 01 15:21:03 well I'm sure you'll get it there, even if the implementation isn't optimal, at least itll work May 01 15:21:53 last time I looked we had about 2500 actual firmware builds in the deployment directory, and the component packages often change several times between firmware builds so that's a lot of versions. May 01 15:22:13 yeah, it's clearly soluble one way or another, just a case of finding the version that sucks least May 01 15:23:05 seen ~mckoan May 01 15:23:06 wow, that's a lot of versions indeed May 01 15:23:16 ~seen mckoan May 01 15:23:21 mckoan was last seen on IRC in channel #oe, 5h 18m 2s ago, saying: 'thx anyway for your answer'. May 01 15:35:27 ugh. I followed the wiki to the letter and on every linux distro I use, bitbake refuses to do anything with ERROR: no files to build, and something about AttributeError: 'NoneType' object has no attribute 'split' May 01 15:35:43 I tried 1.8.12 and svn, ubuntu, suse, debian 5... May 01 15:36:26 hardy, jaunty, 11.0, 11.1... :( May 01 15:36:55 anyone got any ideas why this would be? right now I'm running suse 11.0 since it's the most stable, python 2.5.2 and psyco svn, although without psyco it breaks just as easily, just slower May 01 15:38:27 what machine? May 01 15:38:40 virtualbox May 01 15:38:56 oh you mean for oe May 01 15:38:58 beagleboard May 01 15:39:07 but once I get it working I'm porting it to the i.MX515 May 01 15:39:18 03Angus Ainslie  07fso/milestone5.5 * ree0fb9e38c 10openembedded.git/recipes/images/fso-paroli-image.bb: fso-paroli-image : ship paroli-sounds May 01 15:40:09 Hmm May 01 15:40:33 And you haven't modified anything yet, right? May 01 15:42:04 Tartarus, not except setting MACHINE=beagleboard and DISTRO=angstrom-2008.1 and removing the line at the end of local.conf.sample May 01 15:42:21 I mean I only got to the end of the wiki and "bitbake nano" just explodes at me May 01 15:43:53 pb_: heh, we have all these fuzzy ideas floating around for major things that would be good to change.. but i honestly have no idea where to begin in the real world. we haven't really nailed down enough details on any of these ideas to actually implement them.. just need to keep discussing possibilities i guess, until theres some sort of consensus, and then see what can be done to transition, not replace, the current stuff.. though with the core team drama, m May 01 15:43:54 * kergoth shrugs May 01 15:44:02 That's just very odd May 01 15:44:13 Can you put the whole error on pastebin? May 01 15:44:14 ~pastebin May 01 15:44:15 [~pastebin] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste May 01 15:45:12 yus ;] May 01 15:45:12 how about May 01 15:45:12 you just do me May 01 15:45:12 22 times May 01 15:45:15 gah May 01 15:45:17 not intended May 01 15:45:22 mmmk May 01 15:45:23 kergoth: yeah, right. this kind of thing is one reason that I find the existing core team situation to be frustrating; there isn't really anything that you could really consider a "technical committee" making decisions about these sorts of things. May 01 15:45:32 fucking virtualbox paste doesn't work May 01 15:45:49 http://pastebin.com/m3543b736 May 01 15:46:51 pb_: you could do a component.bb which contains PV = "${COMPONENT_PV} and a config file which defines those variables May 01 15:47:08 anyone? how do I find the module of a svn repo? May 01 15:47:09 pb_: heh, yeah.. due to the lack of technical and architectural guidance, its tempting to just try to start hacking something together independent of the core team and show it to them when its functional :) May 01 15:47:19 Gnutoo: what do you mean? May 01 15:48:01 kergoth, http://docs.openembedded.org/usermanual/usermanual.html#id434863 => there is a mandatory module parameter May 01 15:48:11 Gnutoo: module = blah where blah is the last directory in the svn path May 01 15:48:31 heh, pretty silly since svn has no real concept of a module, but yeah, its the last dir May 01 15:48:32 Gnutoo: unfortuneately it was badly defined and end up being trunk more often than not May 01 15:48:36 remanents of the way cvs was handled May 01 15:49:09 XorA, thanks a lot May 01 15:53:25 XorA: right, but then I end up having to have ten thousand of the config files. that isn't a whole lot more appealing. May 01 15:54:07 plus, in that model, "bitbake fish-1234 fish-5678" doesn't work. May 01 15:57:17 COMPONENT_PV=1234 bitbake fish would though May 01 15:57:53 yeah, I don't think that's really good enough for my purposes. May 01 15:59:09 the main problem, actually, is that it doesn't cascade: if fish-1234 has, say, "RDEPENDS=blah-5678", then I need to make sure that the right version of blah gets built without having to specify BLAH_PV on the command line. May 01 16:02:00 I see May 01 16:03:15 I guess I could make a preprocessor to parse the dependencies and construct the right set of variables, but then I almost might as well not be using bitbake at all. :-} May 01 16:03:56 kergoth: yeah, it is tempting, though I would prefer to get a consensus on the right thing to do before just going ahead with it. May 01 16:03:57 pb_: trying to follow discussion -- can you keep your components in version control, and just have recipe pull the latest? May 01 16:04:57 pb_: that is what I do for custom components that change a lot, but I'm likely missing something here May 01 16:05:49 cbrake: the problem is that we often don't just want the "latest" version, we need to be able to specify arbitrary tagged versions of different components. May 01 16:06:27 cbrake: essentially, we have a top-level .bb file for our firmware image, any given revision of which will nail down the specific versions of all the packages that go into that release of firmware. May 01 16:06:28 pb_: IC May 01 16:07:20 what we need to be able to do is say "bitbake firmware-image-1.2.3.4" and have it build the correct versions of all the appropriate components and then make the rootfs with those versions. May 01 16:08:02 we have a fairly heavily-branched source control environment and we also need to rebuild older tagged versions (sometimes with different options) from time to time. May 01 16:09:15 pb_ that should work if you build from a clean temp dir for each image May 01 16:10:09 in particular, we fairly frequently need to create branches after the fact: i.e. a customer will say "I have old firmware version 4.1 from last year and I love it, but I need you to change this one little thing". in that case we need to be able to create a new branch at 4.1 and start working on it with confidence that the images we're building now will really be the same as the ones that the customer had originally. May 01 16:10:32 nytowl: well, yes, but that would mean that our builds took forever. rebuilding everything from scratch every time isn't really an option. May 01 16:11:32 pb_: I do like your idea, would cut out a large number of copy n paste recipes May 01 16:11:45 +1 Ack from core team :-) May 01 16:12:23 heh May 01 16:12:56 XorA: yeah, and hopefully that in turn would avoid the business of anguishing over when to delete old versions. May 01 16:13:03 anyway, going home now May 01 16:13:04 later all May 01 16:13:04 pb_: yeah May 01 16:13:08 pb_: have fun May 01 16:42:22 yeah... meta-toolchain builds without QA issues! May 01 16:47:25 some recent commits to dev branch are to not strip during install - why would you want to not strip a standard package? May 01 16:49:40 debug info is separated from the main binaries into the -dbg packages. if you stripped it out during install, that wouldnt be possible. itd already be gone by the itme you got to packaging May 01 16:50:03 install -s is bad. May 01 16:50:35 ah... ok makes sense May 01 16:51:29 that actually begs a question I had the other day - for std packages vs -dbg in all cases they both act on the same build right - -dbg is just non stripped, not built with diff gcc flags right? May 01 16:51:41 ? May 01 16:51:48 the -dbg package isnt the binaries May 01 16:51:52 its the debug data that goes with the binaries May 01 16:52:00 just the debug info May 01 16:52:01 thats it May 01 16:52:04 same in the case of libs... just the debug info? ok May 01 16:52:05 in places like /usr/bin/.debug/ May 01 16:54:17 I ran into a related issue recently using gdb b/c libpthread in default package was stripped - found I had to install glibc-dbg for it to work and was curious a) why it was stripped when desktop distros don't strip that lib (but do strip all others) b) if there was any diff between the ver -dbg installed (which you just answered) May 01 16:55:23 desktop distros are always going to be less granular than we are when it comes to packaging. just the nature of the beast, embedded needs more flexibility to shrink things down May 01 16:57:05 tharvey, mainly for installed size :) May 01 16:57:20 We really need to pull the feature stuff from poky in, to make it easier to make debug-enabled images May 01 16:57:52 .debug stuff in your .tar image you keep on the host for gdb (and gdbserver from the target) is great :) May 01 17:00:52 I also noticed that for example libpthreads is in the 'libc_*' package yet the debug for it is in glibc-deb* - thought that was a little strange May 01 17:01:44 not sure if debug info is renamed by debian.bbclass, offhand May 01 17:01:53 All the .debug dirs are in the -dbg package, iirc May 01 17:01:54 always May 01 17:02:23 i think he was asking more about the naming difference than the location of the debug files May 01 17:02:24 but /shrug May 01 17:02:30 Right May 01 17:02:33 yes... all the .debug dirs are there, its just the libc vs glibc May 01 17:02:46 It's also, almost always ${PN}-dbg, ie not renamed May 01 17:03:05 tharvey: see debian.bbclass, its what renames library packages based on their soname May 01 17:03:48 libc vs glibc-dbg is the only package I've seen that has this naming discontinuity May 01 17:18:23 03Stanislav Brabec  07xora/angstrom-srcpv * r87fbf88f7e 10openembedded.git/recipes/subversion/ (files/libtool.patch subversion_1.4.5.bb): subversion: Build with the latest libtool. May 01 17:18:24 03Mike Westerhof  07xora/angstrom-srcpv * r861dedd490 10openembedded.git/conf/distro/include/preferred-slugos-versions.inc: SlugOS: preferred-slugos-versions - get rid of overrides for openssh, fixed upstream. May 01 17:18:25 03Mike Westerhof  07xora/angstrom-srcpv * r9823dcf3aa 10openembedded.git/conf/distro/include/slugos.inc: May 01 17:18:26 SlugOS: slugos.inc - ensure that the rootfs is mounted with the noatime option May 01 17:18:28 (this is for documentation purposes, and to future-proof, since the real May 01 17:18:30 command line is set in the apex recipe.) May 01 17:18:32 03Mike Westerhof  07xora/angstrom-srcpv * r74efae1b1a 10openembedded.git/recipes/ (images/slugos-image.bb initscripts/initscripts-slugos_1.0.bb): May 01 17:18:35 SlugOS: slugos-image.bb, initscripts-slugos_1.0.bb - remove devfs support May 01 17:18:37 Remove devfs startup scripts, and revert to the standard OE means to May 01 17:18:39 initially populate the /dev directory. This has the side-effect of May 01 17:18:41 fixing the empty /dev dir problem when extracting the tar.gz image. May 01 17:18:43 03Mike Westerhof  07xora/angstrom-srcpv * re40bd5bec5 10openembedded.git/recipes/ (5 files in 2 dirs): SlugOS: refactor slugos images and tasks to support a standard and extended image. May 01 17:18:46 03Andrea Adami  07xora/angstrom-srcpv * rebfefe4f9a 10openembedded.git/recipes/nandlogical/nandlogical-static_1.0.0.bb: nandlogical-static: remove bogus PR May 01 17:18:57 03Andrea Adami  07xora/angstrom-srcpv * re34ffc1bf7 10openembedded.git/conf/machine/include/zaurus-2.6.inc: May 01 17:19:00 zaurus-2.6.inc: force creation of jffs2 images May 01 17:19:02 - tar.gz is (weak) assigned in bitbake.conf May 01 17:19:04 03Rod Whitby  07xora/angstrom-srcpv * rc82032fe18 10openembedded.git/contrib/oe-stylize.py: oe-stylize: Remove Unslung distro reference May 01 17:19:09 03Andrea Adami  07xora/angstrom-srcpv * rddc9b82bb2 10openembedded.git/recipes/ipaq-sleep/files/install-fix.patch: May 01 17:19:12 ipaq-sleep: don't strip during install May 01 17:19:14 - using coreutils this now breaks (strip: unable to recognise the May 01 17:19:16 format of the input file) May 01 17:19:18 03Andrea Adami  07xora/angstrom-srcpv * rd6a164ef00 10openembedded.git/recipes/gpe-nmf/gpe-nmf-0.17/fix_makefiles.patch: May 01 17:19:25 gpe-nmf: don't strip during install May 01 17:19:27 - this breaks now with new install May 01 17:19:29 - strip is done in packaging May 01 17:19:31 03Rod Whitby  07xora/angstrom-srcpv * re8410422c0 10openembedded.git/ (103 files in 18 dirs): Unslung: Removed all trace of the unslung distro from OE May 01 17:19:34 03Andrea Adami  07xora/angstrom-srcpv * r19089f52d0 10openembedded.git/recipes/gpe-go/gpe-go-0.05/fix-make.patch: May 01 17:19:39 gpe-go: don't strip during install May 01 17:19:41 - this breaks now with new install May 01 17:19:43 - strip is done in packaging May 01 17:19:45 03Graeme Gregory  07xora/angstrom-srcpv * rbf2dbf4008 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv May 01 17:19:48 03Andrea Adami  07xora/angstrom-srcpv * raed989bee8 10openembedded.git/recipes/minilite/ (8 files in 2 dirs): minilite: Makefile fix - don't strip on install May 01 17:19:53 03Andrea Adami  07xora/angstrom-srcpv * r3b908e8548 10openembedded.git/recipes/gpe-soundbite/files/makefile-fix.patch: May 01 17:19:56 gpe-soundbite: don't strip during install May 01 17:19:58 (26 lines omitted) May 01 17:25:06 anyone know why I would always get 'fatal: The remote end hung up unexpectedly' the first time I do a 'git pull' or other fetch? May 01 17:26:49 firewall? May 01 17:26:56 I dunno but I got it a couple times May 01 17:26:59 it goes away eventually May 01 17:27:07 tharvey: the OpenEmbedded git server seems to have issues May 01 17:27:10 i think we've all seen those May 01 17:27:14 it happens every time Ihaven't run it in a while... repeat the cmd and it goes fine May 01 17:56:39 hello all May 01 18:14:31 hey likewise May 01 18:16:16 03Angus Ainslie  07fso/milestone5.5 * r88049b2357 10openembedded.git/recipes/e17/e-wm_svn.bb: e-wm : bump PR for dependency change May 01 18:41:01 hi,I've ERROR: Multiple .bb files are due to be built which each provide boost May 01 18:41:23 what is the correct syntax for a svn preferred provider, I tried: May 01 18:41:27 "svn" May 01 18:41:38 "1.38.0+svnr..." May 01 18:42:18 PREFERRED_VERSION_BOOST = "1.38.0+svnr52699" to be more exact May 01 18:43:51 in the boost recipe (boost_svn.inc) I have: PV = "1.38.0+svnr52699" May 01 18:45:57 boost not BOOST May 01 19:23:15 03Graeme Gregory  07org.openembedded.dev * r7c5721fde0 10openembedded.git/recipes/mozilla/fennec_hg.bb: fennec_hg.bb : add sqlite3 dependency that is needed by fennec May 01 19:23:16 03Graeme Gregory  07org.openembedded.dev * rc9c54dff22 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into org.openembedded.dev May 01 19:24:08 03Graeme Gregory  07xora/angstrom-srcpv * r1f0f371cf3 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv May 01 19:24:09 03Graeme Gregory  07xora/angstrom-srcpv * r7c5721fde0 10openembedded.git/recipes/mozilla/fennec_hg.bb: fennec_hg.bb : add sqlite3 dependency that is needed by fennec May 01 19:24:10 03Graeme Gregory  07xora/angstrom-srcpv * rc9c54dff22 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into org.openembedded.dev May 01 19:27:23 ah ok sorry and thanks a lot May 01 19:49:13 hi florian May 01 19:49:52 re May 01 19:50:03 florian: what about install -s in the gpe-Makefiles? I'm writing a lot of patches ... May 01 19:50:24 is no-strip acceptable as behaviour 'upstrean' ? May 01 19:51:49 florian: 2nd question..there are 6vers + _svn = 7 versions of gpe-su. Normal? May 01 19:51:54 e.g. May 01 19:52:14 ant__: yes that would be ok May 01 19:52:48 ant__: sounds like we need to fix some versions :) May 01 19:53:14 florian: luckily the same patch applies to the Makefile :-) May 01 19:54:12 I'm fixing x11-image 'as it comes' but I suspect *all* gpe packages share 'install -s' May 01 19:54:26 will check later on... :/ May 01 19:54:39 now keylaunch... May 01 19:55:57 :-) that's mth epreferred kind of patches... delete 2 chars :-) May 01 19:58:37 03Andrea Adami  07org.openembedded.dev * r832bb43152 10openembedded.git/recipes/keylaunch/files/makefile-fix.patch: keylaunch: Makefile fix - don't strip on install May 01 20:10:33 03Andrea Adami  07org.openembedded.dev * r598d627e73 10openembedded.git/recipes/gpe-taskmanager/ (5 files in 2 dirs): gpe-taskmanager: Makefile fix - don't strip on install May 01 20:11:36 ant__: big work today :) May 01 20:11:47 x11-image breaks :( May 01 20:11:49 I see some commit messages :) May 01 20:12:06 now we have to face that strip issue: there was a workaround iirc May 01 20:12:34 I prefer to fix the Makefiles May 01 20:13:14 Jay7: as you know, I'm used to repatch patches :-) Most difficult was u-boot, wasn't ? May 01 20:14:02 I still have to understand that git issue with whitespaces... May 01 20:14:19 I was solving it with git am -3 --withespace=fix May 01 20:15:10 btw, May 01 20:15:20 does current x11-image boot/ May 01 20:15:32 my build doesn't booting in qemu May 01 20:15:51 a couple of days ago was booting on c7x0 May 01 20:20:08 * Jay7 has updated his distro and should check that all is working :) May 01 20:23:01 03Andrea Adami  07org.openembedded.dev * r44c9446696 10openembedded.git/recipes/teleport/ (files/makefile-fix.patch teleport_0.33.bb teleport_0.34.bb): teleport: Makefile fix - don't strip on install May 01 20:35:50 03Andrea Adami  07org.openembedded.dev * r9edaaef28d 10openembedded.git/recipes/gpe-autostarter/ (6 files in 2 dirs): gpe-autostarter: Makefile fix - don't strip on install May 01 20:47:23 03Andrea Adami  07org.openembedded.dev * r622cc4bf49 10openembedded.git/recipes/gpe-soundserver/ (files/makefile-fix.patch gpe-soundserver_0.4-1.bb): gpe-soundserver: Makefile fix - don't strip on install May 01 20:48:22 ant__: dude you are the commit demon :-) May 01 20:48:46 XorA: sh@t!..build breaks every 2 packages :/ May 01 20:49:25 ant__: thats the way it seems to go May 01 20:49:42 ant__: just keeping me busy syncing with you May 01 20:50:37 dunno why strip fails now...I fear the wrong strip is called...'strip: Unable to recognise the format of the input file' May 01 20:50:38 * Jay7 stops trying to be in sync ;) May 01 20:50:56 does not matter, I'll fix those May 01 20:51:02 ant__: sounds like host strip May 01 20:51:17 I prefer the actual behaviour with sane 'install' May 01 20:51:24 'sane' ? May 01 20:51:36 hmm May 01 20:51:52 XorA: I'm pretty sure the same issue was band-aided by Khem months ago... May 01 20:52:11 now after Roman coreutils/install changes... May 01 20:52:44 Just look at my build history...white-red, white-red like invoice-paper :-) May 01 20:56:04 sh@t, konversation stil failing sometimes.. May 01 20:56:39 Yes! Yes! x11-image completed :) May 01 20:57:15 now the remaining gpe-apps .... May 01 20:57:43 ah, just realised I didnt do a build from clean is why I succeed May 01 20:57:54 he May 01 21:07:49 Freaking lockfile thing May 01 21:09:24 glibc gcc-canadian-sdk doesn't have it, uclibc gcc-canadian-sdk does May 01 21:33:54 Anyone able to point me to instructions on how to use multimachine to build for two targets in oe? May 01 21:35:23 * Jay7 added ALT Linux section to OEandYourDistro wiki page May 01 21:35:31 shadowland: should be as easy as doing: May 01 21:35:34 shadowland, what do you mean? May 01 21:35:50 I've been building for at91sam9263ek May 01 21:36:00 MACHINE = "blah" bitbake x-image; MACHINE = "foo" bitbake bar May 01 21:36:02 but I want to try to build the same package for mpc8313 May 01 21:36:23 btw, what gcc version is preffered on host to build OE? May 01 21:36:26 Oh, can I just temporarily override it on the commandline like that? May 01 21:36:34 or just change MACHINE in local.conf May 01 21:36:38 shadowland, yes, if you have that in BB_ENV_EXTRAWHITE May 01 21:36:43 otherwise you have to edit the conf file May 01 21:36:46 I have 4.1.2 and 4.3.2 packaged May 01 21:36:52 ah, yes, see Angstrom instructions May 01 21:36:54 Jay7, any of those should work May 01 21:37:09 Can I build it in the same "tmp" directory as my other stuff without hurting it? May 01 21:37:17 Tartarus: afaik there was some troubles with 4.3 and thumb.. May 01 21:37:18 shadowland, yes May 01 21:37:23 XorA: ping? May 01 21:37:25 Jay7, that's target stuff May 01 21:37:49 Jay7: gnop May 01 21:38:00 ah, so it was issued by gcc that is built inside OE? May 01 21:38:35 right May 01 21:38:43 XorA: I'm just about your gcc4.3 and thumb tests May 01 21:38:49 03Andrea Adami  07org.openembedded.dev * rc8f96452b9 10openembedded.git/recipes/gpe-aerial/ (4 files in 2 dirs): gpe-aerial: fix Makefiles - don't strip on install May 01 21:38:57 but Tartarus already clarified all to me :) May 01 21:39:04 Jay7: all the tests I do seem to prove that thumb just doesnt work in any gcc :-( May 01 21:40:21 I would also have to add "multimachine" to my inherit line in my local.conf, right? May 01 21:42:22 Tartarus: I'm not quite sure what you mean needs to go "in" BB_ENV_EXTRAWHITE. I have OEBASE there now. do I add something else? May 01 21:42:46 shadowland, if you want to pass MACHINE on the command line, yes May 01 21:43:05 bb, kid time May 01 21:59:03 Is there any way to dump the toolchain to show which versions of gcc and glibc, etc that are being used to compile a particular recipe? May 01 21:59:26 bitbake -g recipe May 01 21:59:39 These are set by the distro May 01 21:59:41 bitbake -s may be useful also May 01 22:02:40 hm... one more responce about unbootable x11-image on akita May 01 22:02:45 Awesome. Thank you both. May 01 22:02:55 in angstrom-devel.. May 01 22:19:23 03Stanislav Brabec  07org.openembedded.dev * rca2039c147 10openembedded.git/ (conf/checksums.ini recipes/bluez/bluez-gnome_0.26.bb): bluez-gnome: Update to version 1.8. May 01 22:19:33 03Stanislav Brabec  07org.openembedded.dev * rc89a7e84dd 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev May 01 22:23:53 Jay7, "one more responce about unbootable x11-image on akita", have there been more infor about problems? Does somebody already have an idea? May 01 22:24:29 ESI: my last build does not boot in qemu May 01 22:24:41 build for akita May 01 22:25:22 I'll left tonight building and check tomorrow May 01 22:25:50 That sounds interesting. I did not try qemu yet. May 01 22:26:25 but I was not sure about source of bug May 01 22:26:36 qemu can affect this May 01 22:27:56 Hopefully it is the same effect I am seeing, would make the debugging easier. May 01 22:29:43 03Andrea Adami  07org.openembedded.dev * rd8c394638b 10openembedded.git/recipes/teleport/files/ (4 files): teleport: reorder patches for old version 0.33 (still breaks compiling) May 01 22:29:45 03Andrea Adami  07org.openembedded.dev * r2dc6e0a959 10openembedded.git/recipes/gpe-autostarter/gpe-autostarter_svn.bb: gpe-autostarter_svn: remove 'no strip patch' and hope they fix upstream May 01 23:08:46 * Jay7 -> sleep May 02 01:17:10 hey May 02 01:17:28 who of you wrote the receipt for ? :) May 02 01:22:09 * raster points at Ainulindale May 02 01:23:03 otavio, you can rule out the dl'd file being bad and such? May 02 01:25:03 Ainulindale: ping :) May 02 01:25:21 raster: thanks May 02 01:25:25 Tartarus: yes; since one of the packages involved is the udev and I have other 7 images that built fine heh May 02 01:25:31 Tartarus: before and later of it May 02 01:25:38 Tartarus: and without downloading it again May 02 01:25:39 mirko: i was just kidding :) May 02 01:28:02 otavio, how about running memtest on the box? May 02 01:28:38 raster: i'll pay this person a drink some day - reading the recipe really made my day ;) May 02 01:28:52 the comments are awesome ;) May 02 01:30:17 Tartarus: machine is quite stable; I doubt bzip/gzip would be the only thing failing May 02 01:30:48 otavio@neumann [bg:1] { ~ }$ uptime 22:30:45 up 6 days, 7:51, 4 users, load average: 6.73, 9.92, 12.37 May 02 01:31:14 Tartarus: don't you think it is quite difficult to happen only with those? May 02 01:32:30 not at all May 02 01:32:39 how much memory is in that? May 02 01:33:13 otavio, I'd seriously consider letting memtest run over the weekend May 02 01:39:31 Tartarus: 4g May 02 01:42:40 Tartarus: from 25 images, I had it in 3 only May 02 01:42:56 Tartarus: it looks more like a locking issue or something for me May 02 01:43:04 Tartarus: couldn't be it? May 02 01:44:17 Shouldn't be, no May 02 01:44:42 Couldn't, even, now that I think about it May 02 01:46:11 Tartarus: so you do belive it is a memory issue? May 02 01:49:32 yeah May 02 01:52:39 Tartarus: well; I can let it doing a memtest then May 02 01:52:47 Tartarus: let's see how it goes **** ENDING LOGGING AT Sat May 02 02:59:57 2009