**** BEGIN LOGGING AT Sat Apr 09 02:59:58 2011 Apr 09 09:23:37 hej, can anyone here can tell me why files included via directories in SRC_URI end up in the working root of the package? I am trying to revive my old Verdex ;) Apr 09 09:23:57 (not official OE repo, but a fork from Gumstix though - maybe there was a change in some class file) Apr 09 09:40:43 nvm. I found the changes in base.bbclass Apr 09 10:31:42 morning all Apr 09 11:52:45 hi ll Apr 09 11:52:47 hi all Apr 09 15:35:02 hi, Apr 09 15:35:18 I've cloned the following repos: Apr 09 15:35:20 meta-angstrom meta-openembedded meta-shr meta-texasinstruments openembedded-core Apr 09 15:35:34 and I want to do a manual angstrom+SHR setup Apr 09 15:35:41 the main problem is that I don't know: Apr 09 15:35:51 *which repo does what Apr 09 15:35:59 *what's the precedence of each repos Apr 09 15:40:34 ah I was responded for SHR Apr 09 15:40:38 but rest angstrom Apr 09 15:41:51 look atht e angstrom oe-bb script Apr 09 15:41:59 It should give you some clues Apr 09 15:45:32 it didn't but I'll setup SHR first Apr 09 15:45:35 and then look Apr 09 15:45:36 again Apr 09 15:46:24 I need to setup angstrom from oe-core when I get home Apr 09 15:47:45 ok Apr 09 16:02:06 what's the migration path? Apr 09 16:02:12 many recipes are lacking Apr 09 16:04:36 I'll ask JaMa Apr 09 16:41:08 GNUtoo, he should know Apr 09 16:41:23 my understanding is move recipes in to the meta-oe layer Apr 09 16:50:00 ok Apr 09 16:50:27 so it's not ready yet but we can start to work on it? Apr 09 16:50:50 yes Apr 09 16:51:06 if your playing with oe-core and bitbake master you need to put FAKEROOT="" in local.conf Apr 09 16:51:19 I think in the next couple of weeks, we will start encouraging more people to migrate Apr 09 16:52:00 I believe there are a couple of issues that need working out before the TSC is ready to encourage a mass migration Apr 09 16:52:14 but it is good to get started, sooner rather than later :) Apr 09 16:52:38 * Crofton is stuck in dev until he has a solution for PyQt and PyQwt Apr 09 17:06:36 ok Apr 09 18:10:13 so the easiest way to start with the oe-core is the setup script from the angstrom? Apr 09 18:11:53 when it's actually decided, that oe as we know it today is dead? Apr 09 18:13:14 or it will continue in paralel with oe-core? looks like that all(majority) of new development is happening in oe-core Apr 09 18:48:55 ynezz: re getting started, yes, the setup script for angstrom Apr 09 18:49:10 Not sure if SHR is also using that and you just edit build/conf/local.conf or if they've got their own Apr 09 18:49:40 and I don't know if poky has something setup for other than using their merged in version, will bug RP tomorrow when I see him :) Apr 09 18:50:18 ynezz: And the plan is that the next openembedded.master stable release (03 + 4 = 07, which is July) will be the last done there Apr 09 18:50:38 But of course that depends on there being enough critical mass behind oe-core/meta-oe/distros Apr 09 18:51:17 (And part of the plan is that post ELC, the TSC makes sure there's a good initial out of box experience and recommends folks that are on the fence come on over) Apr 09 19:00:27 I am checking oe-core and noticed that udev is still 164; any reason? Apr 09 19:02:53 otavio, ask on the oe-core list Apr 09 19:04:12 looking at oe-core and meta-oe it seems many fixes done on OE weren't pushed into oe-core/meta-oe Apr 09 19:05:02 I think there is a phase in the schedule for fixing that :) Apr 09 19:05:21 the basic organzation needs finishing though Apr 09 19:13:01 * XorA|gone posted a patch for angstrom setup scripts to angstrom-devel which will remove a little confusion Apr 09 19:19:38 otavio: There's an on-going effort to sync oe into oe-core/meta-oe Apr 09 19:19:42 more hands are always welcome! Apr 09 19:20:36 Tartarus, prepare for the masses :) Apr 09 19:20:38 Tartarus: yes; I will finish moving our products to current OE/layer and then after that I can join the effort to move to oe-core Apr 09 19:20:59 I'll switch if someone adds PyQt and PyQwt :) Apr 09 19:24:49 Crofton: PyQwt? Apr 09 19:26:09 Crofton: your a dirty man with all this python :-) Apr 09 19:26:46 NOTE: package console-image-1.0-r0: task do_rm_work_all: Succeeded Apr 09 19:26:46 NOTE: Tasks Summary: Attempted 3171 tasks of which 771 didn't need to be rerun and 0 failed. Apr 09 19:26:49 finally :-) Apr 09 19:27:32 python bindings for qwt Apr 09 19:27:50 I have it running after building native, but I really want working recipes Apr 09 19:27:58 so I can automate the entire image Apr 09 19:28:30 currently being a tourist in SFO and looking for a usd card so I can make a copy for the customer to fool with Apr 09 22:01:28 hey. I have created a bitbake recipe that should fetch the source code from SVN. however, it tries to mangle the SVN url somehow and download a tar.gz from http://www.angstrom-distribution.org/unstable/sources Apr 09 22:01:44 any info on how to make bitbake actually run subversion? Apr 09 22:05:42 I'd like to build and install some package _before_ starting to build the other. Apr 09 22:06:09 DEPENDS seems not working with parallel building Apr 09 22:07:22 Tartarus: ah, ok, thanks for the info Apr 09 22:16:08 dv: of course it does. we use parallel building every day Apr 09 22:16:23 CMoH: it will run subversion if it doesn't get it off the mirror. Apr 09 22:18:07 kergoth_, thanks, but off the mirror it gets a 404 and next it uses an empty dir as the workdir (which of course, fails the build at a later stage) Apr 09 22:18:27 well, it works for everyone else Apr 09 22:18:31 don't know what to tell you Apr 09 22:19:02 i also get this: DeprecationWarning: Call to deprecated function bb.mkdirhier: Please use bb.utils.mkdirhier instead. Apr 09 22:19:05 i can tell you the fetch from angstrom-distribution.org is completely irrelevent to inability to etch from svn. Apr 09 22:19:14 as i said, its just the mirroring mechanisms, which work fine Apr 09 22:19:21 harmless Apr 09 22:21:52 CMoH: what's your SRC_URI? Apr 09 22:22:00 http://pastebin.com/9p63hSDN Apr 09 22:22:14 you didn't set SRCREV in the recipe Apr 09 22:22:20 it checked out revision 1 of svn, which is empty Apr 09 22:22:23 no, i want the trunk Apr 09 22:22:24 you can see right in the log messages there Apr 09 22:22:29 trunk has nothing to do with revision. Apr 09 22:22:29 the head i mean Apr 09 22:22:32 trunk is a branch. Apr 09 22:22:38 then set SRCREV = "${AUTOREV}" Apr 09 22:22:43 either way, it must be set if you want something sane Apr 09 22:22:52 aha Apr 09 22:23:04 (stupid, i know, i didn't implement any of this..) Apr 09 22:24:43 trying now with the new SRCREV Apr 09 22:24:45 yaya Apr 09 22:25:47 ty kergoth_ - it did the proper job Apr 09 22:25:54 np Apr 09 22:27:00 kergoth_: thanks for the hints yesterday, got an oe-core build to complete this afternoon Apr 09 22:27:05 nice Apr 09 22:27:06 grats Apr 09 22:34:53 good nite Apr 09 22:57:35 kergoth_: any easy way to cause the bitbake NOTE and ERROR messages to include task numbers -- I wish to post-process the log file so I can match up tasks when using > 1 bb thread more easily, and it's really hard to do that. Apr 09 22:58:32 E.G. BITBAKE_NOTE_FMT_STRING = "NOTE: (%%task) %%message" Apr 09 23:01:36 well, we use the python logging module specifically to make that easier, but right now there's no easy way to exert control over it. you can modify lib/bb/ui/knotty.py, the format string is there. i think the logging module provides a process id, if so that'll work, since we spawn a separate process per task Apr 09 23:02:01 Ok, I'll take a look at that. Apr 09 23:02:41 Is there a general solution for extending or providing an alternative to the current logging mechanism under consideration at all? Apr 09 23:03:02 i'm not sure what you're referring to. we just replaced our entire logging scheme to use the python logging module to make this easier Apr 09 23:03:08 all we need is a way to *configure* it Apr 09 23:06:13 my "blue-sky" idea right now is to record the build record into something more akin to a database, so I can review (for example), all the messages associated with a given recipe over time. Apr 09 23:07:18 But even short term, parsing the stdout is difficult when I can't easily match lines to tasks. Apr 09 23:10:17 right, and the logging module gives you all that. it has built in support for parsing a user supplied config file to send whatever messages you want wherever you want, with whatever format string you want.. Apr 09 23:10:25 all we need a commandline argument to pass in that config file Apr 09 23:49:13 mwester-laptop: ideally, our tasks would inject their id into the log messages they emit, rather than relying on process id. relying on the pid makes assumptions about bitbake's implementation details. probably would be pretty trivial to add it to the log records Apr 09 23:49:27 logging has a notion of logging adapters which are used to inject information like that **** ENDING LOGGING AT Sun Apr 10 02:59:57 2011