**** BEGIN LOGGING AT Thu May 12 02:59:58 2011 May 12 07:05:15 morning all May 12 07:49:09 florian: how goes LT? May 12 07:50:48 hi hrw May 12 07:51:16 hrw: so far not too bad - the first day was comparably quiet as always May 12 07:51:33 but not that quiet that we could feel bored :) May 12 07:52:13 ;D May 12 07:52:18 florian: does wrt54gs works? May 12 07:59:58 hrw: we didn't try it so far :-} we have an official ap ~1m from our table May 12 08:00:23 nice May 12 08:01:51 wow - checked when I bought that router... 6 years ago: http://marcin.juszkiewicz.com.pl/2005/06/07/i-got-wrt54gs/ May 12 08:01:59 :-) May 12 08:02:16 is there some oe based image installed? :) May 12 08:02:33 nope May 12 08:02:42 never got time to experiment with such May 12 08:05:39 good morning May 12 08:15:03 hi mckoan May 12 09:23:15 hi zecke, florian, all May 12 09:52:42 hi pb_ May 12 11:02:48 hi all , in temp folder m getting error tht no space left on device.. how can i solve this? May 12 11:03:14 get a bigger hard disk? May 12 11:03:18 or delete some files, perhaps May 12 11:04:05 pb_, frm temp only? May 12 11:04:38 well, it depends how you have your system set up. it might be sharing a device with other files, or it might not. May 12 11:05:27 pb_, ok May 12 11:15:21 hi mickey May 12 11:57:35 hi, I've the following do_rootfs errors: http://pastie.org/1892780 May 12 11:57:52 distro: angstrom2010 under org.openembedded.dev May 12 11:58:23 for dnsmasq I'll look May 12 12:04:11 note that it worked before May 12 12:04:15 I've old images May 12 12:04:23 All my do_postinst does not work on the first boot. May 12 12:05:57 that's not the first boot May 12 12:06:00 that's do_rootfs May 12 12:06:07 (for my problem) May 12 12:06:50 GNUtoo: dnsmasq-dbus is now in connman rdepends May 12 12:07:06 I just joined, don't know your problem May 12 12:07:18 yes I just saw it with bigbke -g May 12 12:07:22 *bitbake May 12 12:07:29 JaMa, I'm mostly wondered about the rest May 12 12:07:35 so something in task-bug-network pulls conflicting dnsmasq May 12 12:08:04 I know that May 12 12:08:09 I've fixed already May 12 12:08:16 it's connman indeed May 12 12:08:23 ok May 12 12:08:28 but there are other errors such as: May 12 12:08:37 * extract_archive: Cannot create symlink from ./var/run to 'volatile/run': File exists. May 12 12:08:43 * file_md5sum_alloc: Failed to open file /home/gnutoo/embedded/oe/oetmps/angstrom2010/rootfs/bug-image-production/etc/opkg/*.conf: No such file or directory. May 12 12:10:06 * resolve_conffiles: Existing conffile .../rootfs/bug-image-production/etc/device_table is different from the conffile in the new package. The new conffile will be placed at .../rootfs/bug-image-production/etc/device_table-opkg. May 12 12:30:18 which package would be the best as example for command execution on the first boot? May 12 12:36:35 JaMa, sorry it fix the other errors too.... May 12 12:36:41 *fixed May 12 12:36:53 it's just that do_rootfs take a huge time on my laptop May 12 12:42:47 Okay, I can't get it to run my commands on the first boot May 12 12:42:56 Here is how postinst looks like: http://pastebin.com/Naa787ic May 12 12:43:05 Any hints why it's not working? May 12 12:44:43 davidlt: as as starter I would add an else to the if test with an echo, also i would redirect the echo to e.g. /tmp/mylog May 12 12:45:09 so you know if you get into the then or into the else May 12 12:45:57 In the real recipe I have part of code which is executed on rootfs and the rest, few lines should be on first boot. May 12 12:46:13 The lines on rootfs is executed. May 12 13:20:45 eFfeM_work: "x$D" != x -> on do_rootfs. So it executes 'esle' part on rootfs, but 'then' part on first boot is not executed. May 12 13:21:36 I don't see file in /tmp May 12 13:27:56 davidlt: your "before" version from the pastebin looks more likely to work. the postinst will only run on the device if it did not "succeed" during image construction. May 12 13:29:06 So if I have else and then May 12 13:29:29 If on then I do part of the stuff and it exits with 0, else part on boot would never be executed? May 12 13:29:59 It would already report that it was okay. May 12 13:30:35 correct May 12 13:30:57 pb_: thanks, almost forgot about that (I think it was written on Poky Handbook) May 12 13:31:10 if you inspect rootfs_ipk.bbclass and look for "postinst" you should be able to find the code that does this. May 12 13:34:35 Okay, one question, upgate-rc.d and crontab, will they work on do_rootfs? May 12 13:35:21 update-rc.d should do, it has special code to arrange that May 12 13:35:25 I don't know about crontab offhand May 12 13:35:56 from syslog-ng: May 12 13:35:58 32 if test "x$D" != "x"; then May 12 13:35:58 33 OPT="-r $D" May 12 13:36:43 But I can't find any info about -r arg. May 12 13:37:04 ah yes, bletch. we should really sort that out. May 12 13:37:35 Should I set it or execute just plain update-rc.d as normally I would do? May 12 13:37:45 right now I think you have to set it. May 12 13:38:00 but, there's no reason update-rc.d couldn't (and shouldn't) figure that out for itself. May 12 13:38:10 if you wanted to send a patch for that then it would be even better. May 12 13:39:30 I have some recipes which are not submitted to OE, never had enough time to read all the rules and requirements to do that. But I should do it one day. May 12 14:09:09 morning kergoth May 12 14:11:16 he pb May 12 14:11:20 hi woglinde May 12 14:25:09 morning pb_ May 12 14:25:16 morning woglinde May 12 14:25:17 hi ka6sox-away May 12 14:26:45 hi ka6sox May 12 14:30:24 pb_, I just updated the redmine ticket. May 12 14:33:38 ka6sox-away: I think it will always show your own username in that link. Nobody else will be seeing your username there. May 12 14:33:51 okay that was my concern May 12 14:34:17 Try logging out and then revisiting the page. I think you should find that it doesn't mention you anymore. May 12 14:40:44 so, today's random oe-core curiosity question: what is recipes-sato, and why is it "core"? May 12 14:41:00 sato is an environment based on matchbox May 12 14:41:18 I can make screenshots if you want May 12 14:41:51 or maybe it's a matchbox theme May 12 14:41:52 not sure May 12 14:41:56 Simon Tatham's Portable Puzzle Collection is no doubt a fine thing but I'm not totally convinced it meets my personal definition of core functionality :-} May 12 14:42:02 but it's something graphical that has to do with matchbox May 12 14:42:10 GNUtoo: thanks May 12 14:43:24 maybe it's there because of legacy things May 12 14:43:35 it was the poky default environment May 12 14:51:45 Hello ... May 12 14:52:21 I want some guidance about what RP meant with the patch details ... May 12 14:52:27 RP__: ?? around? May 12 14:52:55 Is someone using linux-yocto? I am in doubt how I do to get a configuration done there May 12 14:54:58 otavio if you are referring to patch/commit message guidelines.. I'm delinquent.. life kicked in. I'm working on hopefully the final revision right now.. May 12 14:55:23 fray: you're Saul? May 12 14:55:25 I can send you the document I have if you are interested.. it will be going to the oe-devel, oe-core, and yocto mailing lists.. May 12 14:55:26 no May 12 14:55:30 ah ok May 12 14:55:54 Saul is working primarly on the yocto side of things.. but I've incorporated his comments into the document.. they just need further explanation May 12 14:56:06 * jconnolly is interested in that document May 12 14:56:37 I'm happy to send the 4th revision to anyone.. I just didn't send it out to the lists because I got a bunch of immediate feedback, causing me to want to do a 5th before sending it.. May 12 14:56:47 msg me an email address and I'll forward it ASAP May 12 14:57:21 (or wait, and I'll have 5th rev done in a few hours.. I hope) May 12 15:24:55 otavio: hi. Concerning QT4 trnaslations : I think this also doesn't work with 4.6.3 : can you confirm ? May 12 15:25:54 ericben: I am using it but from an old snapshot of oe May 12 15:26:12 ericben: our product is being ported to new oe and this has been found due that May 12 15:26:50 otavio: ok because there is the same sed in 4.6.3 May 12 15:26:58 otavio: I'm working on a global fix May 12 15:27:17 ericben: that would be great May 12 15:27:18 otavio: but I'm only testing on 4.7 for now May 12 15:27:22 ericben: this is a blocker for me. May 12 15:27:52 otavio: actually this is a blocker for the CPU of my build server qt is quite long to build :-) May 12 15:27:56 ericben: one thing you might look is also about doing the same on oe-core. The diff between oe-core and meta-oe is really small (basically database backend support) May 12 15:28:33 otavio: I'can't look at oe-core until 2 or 3 month but the fix may be easily ported to oe-core by people using it actually May 12 15:28:57 ericben: OK; I can look at doing that May 12 15:29:16 ericben: I also want to port the qt4-native change since it is another issue I want fixed. May 12 15:30:42 otavio: well, I did make quite a lot of cleanups in the qt4 recipes in oe-core May 12 15:30:50 am currently testing update to 4.7.3 here May 12 15:30:59 bluelightning: excellent, please keep us posted May 12 15:31:24 I saw Tom's message about other arches so I'm trying with MACHINE=qemumips atm May 12 15:31:53 for x86-64, the x11 and embedded variants of 4.7.3 both built just fine May 12 15:32:29 mickey|office: will yoi be in berlin tomorrow? May 12 15:32:52 hi all.. i've seen some discussion bitbake return codes being weird based on QA issues, etc… is there any easy way to determine the status of the build? like 'bitbake status' would return something like pass, build error, qa issue, etc? May 12 15:33:01 bluelightning: you might port the qt4-native fixes too May 12 15:33:10 bluelightning: this is quite important and trivial IMO May 12 15:33:19 otavio: I saw those but have not yet investigated May 12 15:33:28 am curious about this libs/tools split... May 12 15:34:21 bluelightning: currently tools are build but those mostly depends on the libraries to be build before so basically has no build-time change. But the patch does stage them allowing for native tools to be build against them (one thing I need0 May 12 15:34:25 ) May 12 15:34:33 zecke: i'm not 100% sure yet, it depends on whether i finish some code i'm working on atm. May 12 15:34:45 otavio: ok, sounds good May 12 15:34:55 added to todo list :) May 12 15:35:57 bluelightning: another thing to look at is to put the database cflags into oe-core so the meta-oe could just append the depends and get the recipes basically on sync with oe-core May 12 15:36:02 he zcke May 12 15:36:13 otavio: yes, I promised koen I would do that but haven't yet May 12 15:36:25 bluelightning: good :-) May 12 15:36:35 bluelightning: and thanks by looking at it May 12 15:36:45 bluelightning: btw, what is your name? :P May 12 15:36:52 otavio: Paul Eggleton May 12 15:37:12 no problem :) May 12 15:37:21 bluelightning: pleased to meet you :-) May 12 15:37:32 * otavio is Otavio Salvador May 12 15:37:34 :-) May 12 15:37:43 otavio: likewise :) May 12 15:38:43 otavio: you are using qt4 for a project I take it? May 12 15:39:17 bluelightning: yes; our embedded OS use it a lot May 12 15:39:44 bluelightning: but it has been using an old OE snapshot and we're porting them to oe-core currently May 12 15:40:00 cool, it's good to have someone using these recipes for real stuff... that's the only way we find out about any problems :) May 12 15:40:03 bluelightning: and then we have been working at fix the stuff that we have done locally before May 12 15:40:23 bluelightning: you might have noticed the fixes for qmake and cmake done by us too :-) May 12 15:40:40 * otavio just sent another one ;-) May 12 15:41:39 * bluelightning just saw it :) May 12 15:43:02 hi, why is dbus package depending on glib2? May 12 15:43:13 I know someone who's having problems with that May 12 15:43:19 as glib needs libdbus May 12 15:43:37 he tried removing glib2 dependency in dbus recipe and could build it. May 12 15:44:52 introspetion May 12 15:45:06 otavio BTW the patch header in the email you just sent to oe-core is correct.. :) May 12 15:45:12 introspection support I guess May 12 15:45:18 (at least that is what is intended) ;) May 12 15:45:52 woglinde, the thing is... afaik glib depends on dbus right? May 12 15:46:05 fray: good; I hoped :-d May 12 15:46:39 pespin hm I didnt looked so deep this much May 12 15:46:55 mickeyl mentioned newe glibs has a own dbusd impl May 12 15:47:05 we've had some back and forth on this dbus/glib dependency loop before IIRC May 12 15:47:10 which you could run instead May 12 15:47:30 bluelightinh hm ah and you know more? May 12 15:47:39 yeah, gdbus May 12 15:47:51 well not really, but I have seen some patches already May 12 15:47:58 I'll dig in my archives May 12 15:48:16 mickey|office: trains are mostly the same as an office ;) May 12 15:48:33 but it looks like gdbus depends on libdbus too? gdbus-serialization.c:28:23: fatal error: dbus/dbus.h: No such file or directory May 12 15:48:43 *g* May 12 15:48:50 no only headers May 12 15:49:05 so you dont havea diffrent api May 12 15:49:22 ? May 12 15:50:00 gdbus api is different from that of libdbus afaik May 12 15:50:18 what? May 12 15:51:04 pespin hm but they need to share something May 12 15:51:25 kergoth, I'm getting some 'database locked' errors from bitbake while parsing recipes (possibly while caching) when I invoke bitbake concurrently on mutliple project dirs - some shared database? May 12 15:51:56 woglinde, like what? I thought libgdbus was a full rewrite. May 12 15:54:51 sure but for types to serializable and so on May 12 15:55:09 woglinde / pespin: in oe-core we dropped dbus's dependency on glib-2.0 May 12 15:55:09 its better to use the header which dbus provides May 12 15:55:27 bluelightning hm okay May 12 15:55:43 pespin so make a patch for dev May 12 15:55:51 if your pain is this much May 12 15:56:12 woglinde, just remove glib-2.0 in dbus.inc reight? May 12 15:56:15 *right May 12 15:56:45 hm yes and you could diff the config.logs and compile.logs May 12 15:56:50 to see what differs May 12 16:02:57 an rgrep doesn't reveal anything May 12 16:03:08 (glib2 in dbus) May 12 16:03:17 *g* May 12 17:02:22 Tartarus, ping May 12 17:02:58 pong May 12 17:03:53 can you push koen's request for maintenence May 12 17:04:08 I beleive 24 hours has elapsed :) May 12 17:04:26 Hm May 12 17:04:33 I thought I did May 12 17:04:45 yeah May 12 17:04:48 To git@git.openembedded.net:openembedded May 12 17:04:49 d22e4dc..6040951 2011.03-maintenance -> 2011.03-maintenance May 12 17:06:10 hmm May 12 17:06:14 I'll check May 12 17:06:25 I thought you pushed one, but were waiting on koen's May 12 17:07:03 must have in the last hour :) May 12 17:07:06 thanks May 12 17:41:43 anyone know of a web based collaborative drawing website? May 12 17:42:10 crofton, goto anapnea.net May 12 17:42:16 the owner has sub site projects May 12 17:42:22 i beleive 1 is what u want May 12 17:43:35 I need to make a drawing while someone else watches May 12 17:43:37 scheamtic May 12 17:44:48 Crofton|work: http://gigaom.com/collaboration/25-apps-for-the-virtual-workers-toolkit/ The section on Desktop sharing may be helpful. May 12 17:45:25 Might be a little over kill though. May 12 17:58:12 hmm, for recipes, can I do FILES_${PN}_machine ? May 12 17:58:42 so that the files deployed for a given recipe are a subset of those provided by default? May 12 17:59:06 of course. there's nothing special about FILES_${PN}, it's just another variable May 12 18:35:38 kergoth_, I'm getting 'database locked' errors while bitbake is parsing/cacheing if I kick off multiple bitbakes in different project dirs at the same time May 12 18:35:49 is there a shared sqlite database somewhere? May 12 18:57:21 tharvey: not shared, no, but it's possible you're putting so much load on the disk that it's taking too long to do the database operations May 12 18:57:37 jo kergoth May 12 18:58:05 hmmm... how long are the database operations retried for? May 12 18:59:39 would have to check the code. see lib/bb/persist_data.py May 12 19:07:48 is that normal: May 12 19:07:50 XSERVER_COMMON ?= "xserver-kdrive-common" May 12 19:07:54 that is to say May 12 19:08:03 angstrom wants to use xserver-kdrive-common? May 12 19:26:07 kergoth_: I have that too (locked database) quite often on virtualized host, never seen them on my faster box May 12 19:29:35 I naver saw it May 12 19:29:37 yet May 12 19:29:51 we really need to fix the assume provided handling May 12 19:30:27 can't even bitbake -e foo if foo is in ASSUME_PROVDIDED May 12 19:30:28 PROVIDED May 12 19:30:39 traceback, actually.. May 12 19:30:43 * kergoth_ mutters May 12 19:31:00 also, assume provided should only affect things pulled in via deps May 12 19:31:08 if i say bitbake foo and foo was in assume provided, build the fucking thing May 12 19:31:12 i told you to build it, build it May 12 19:32:27 hm new versions gstreamer plugins May 12 19:32:29 +of May 12 19:32:55 some days bitbake annoys me so much i feel like throwing it out of a damn window and starting over :| May 12 19:33:10 in ruby? May 12 19:34:40 just in general May 12 19:34:44 its not the language tahts the problem :) May 12 19:34:50 hm May 12 19:34:52 yeah May 12 19:35:35 are there any good instructions on using bbppend to add a new config file to base-files and sysvinint? May 12 19:36:08 crofton have a look at systemd May 12 19:36:14 new, not existing? just append to do_install to install it and add to SRC_URI May 12 19:36:21 dont want to make that big a change May 12 19:36:31 ugh, quilt-native rdepends on things that aren't even in our repository May 12 19:36:32 just need to deal with the inittab tty name change on omap May 12 19:36:37 patch-native, diffstat-native, .. May 12 19:36:42 * kergoth_ mutters May 12 19:37:08 kergoth hm yes May 12 19:37:11 if it's an existing config file, you'd want to add the bbappend dir to FILESPATHBASE and override it that way May 12 19:38:06 ah serial console I can handle from the machine file May 12 19:38:54 and now the dependency loop identifier code in bitbake just puked with a bunch of tracebacks May 12 19:38:55 lovely May 12 19:42:45 otavio: do you have one minute concerning qt translations ? May 12 19:44:52 ericben: sure May 12 19:46:12 otavio: can you confirm that the result is a qt4-embedded-translation-qt_4.7.3-r29.1.9_armv5te.ipk packakge containing all .qm files in /usr/share/qtopia/translations/ ? May 12 19:46:21 the expected result May 12 19:48:22 btw I think we should drop the qtopia name and come back to qt which is a more actual name for the lib May 12 19:49:04 ieehks qtopia is dead, dead and dead May 12 19:56:12 ericben: sure; paste it somewhere May 12 19:58:37 otavio: otavio http://pastebin.com/CrFrCb5i May 12 20:00:06 ericben: yes, seems perfect :-D yey! May 12 20:00:16 otavio: ok last test and I'll post the patches May 12 20:00:45 ericben: NICE May 12 20:01:03 otavio: a few hacks to get the right bin at the right place and a strange hack in translations.pro which seems to be caused by the shell here May 12 20:01:34 bye May 12 20:01:36 ericben: send the patch and I take a look on it too May 12 20:01:38 ericben: thanks a lot May 12 20:14:19 * pb_ stabs ccache May 12 20:14:37 spent 20 minutes debugging an autoconf error only to find that it was due to my old enemy. May 12 20:16:41 uhu May 12 20:19:27 in other news, though, I nearly have some semblance of a working micro layer on top of oe-core. May 12 20:21:11 pb_: that's good news indeed May 12 20:21:44 seems there is enough momentum behind oe-core, good to see May 12 20:22:21 well, I wouldn't count myself as wholeheartedly enthusiastic about oe-core yet, but it seems worth at least experimenting with. May 12 20:22:38 likewise tsc still has not present a plan May 12 20:23:00 pb_: what is your biggest concern? (Mine is that we have too many diversion in repos, trees, branches) May 12 20:23:12 woglinde_: plan for what? May 12 20:23:28 likewise oe-core, meta-oe May 12 20:23:51 transition May 12 20:24:16 woglinde_: you mean whether or not to move to core? May 12 20:24:30 move is clear May 12 20:24:41 not to move is stupidity May 12 20:24:50 I have been playing around with wpa-supplicant and found a glitch in the recipe. It has logic in the wpa-supplicant-0.7.inc file to detect if DBUS is enabled in the .config file May 12 20:24:56 it does not seem to enter that block May 12 20:25:07 woglinde_: please elaborate then what the TSC must plan? May 12 20:25:12 so none of the config files for dbus ever get placed in /etc/dbus-1/system.d May 12 20:25:20 likewise policy? May 12 20:25:26 it looks like the line above the logic changes the reference directory May 12 20:25:26 or policies May 12 20:25:39 for now koen and jama made there own policy for meta-oe May 12 20:25:48 so if the grep tests are modified from .config to ${S}/.config, dbus config files are correctly placed May 12 20:26:09 martinmeba send a patch to the list May 12 20:26:26 will-do May 12 20:32:44 likewise: yeah, it does seem a bit fragmentary, though I think there are probably good reasons for that. Some of the particular splits seem a bit weird though, eg this sato stuff in "core". May 12 20:33:06 I'm not sure if that is just some legacy thing and will go away, or whether it is the intent that it should stay there. May 12 20:33:22 pb_: this was brought up in an email very recently May 12 20:33:41 pb_: no clear outcome yet though May 12 20:42:30 question about FEED_ARCH and TARGET_CC_ARCH: if your building images for two diff machines that have diff TARGET_CC_ARCH, the packages will both get mixed into same FEED_ARCH - is that really what you want? seems if your going to the trouble to tune gcc flags for a machine you would want it to segregate its packages? May 12 20:51:08 I'm also finding some of oe-core's build machinery a little bit fiddly to get to grips with. It seems to want you to use all of its own little scripts, which is probably fine but it's slightly alien compared to regular oe. May 12 20:53:04 pb_, so I'm not the only one who thinks that....good May 12 20:53:16 and, finally (I think) it is slightly disheartening that some of the classes appear to have been forked from quite old versions compared to what's in regular oe. obviously that can be fixed but it's a bit tiresome doing the same work again. May 12 20:55:54 * florian agrees May 12 20:56:37 pb_: I did some sync for cmake and qmake_base classes last week but does indeed seem to have many bug fixes missing on oe-core May 12 20:56:46 pb_: Yeah, layers requires a little bit of re-thinking and setup May 12 20:56:50 | NOTE: QA checking staging May 12 20:56:50 | NOTE: QA checking staging May 12 20:56:50 | ERROR: Package already staged (/home/otavio/hacking/el/tmp/sstate-control/manifest-x86_64-perl-native.populate-sysroot)?! May 12 20:56:53 | ERROR: Function 'sstate_task_postfunc' failed May 12 20:56:55 NOTE: package perl-native-5.12.3-r2: task do_populate_sysroot: Failed May 12 20:56:59 someone has seen it on today's oe-core? May 12 20:57:12 And yes, the re-sync of classes still needs help with folks that use the classes in question May 12 20:57:19 in fact I did not look at the differences of the classes yet but the situation for setting up the build system seems to become worse May 12 21:11:34 i'm not sure i see how setting up the build system is any more difficult with oe-core than the current state. there are more layers, but its trivial to add them, and there are plenty of tools to manage fetching them May 12 21:14:12 not to forget May 12 21:14:23 the intel guys not working on oe master May 12 21:18:27 kergoth: well, for example, there seems to be some new requirement for a BUILDDIR environment variable May 12 21:18:39 and this bitbake wrapper script May 12 21:19:17 if I forget to set BUILDDIR then I get obscure errors like: May 12 21:19:26 ../oe-core/scripts/bitbake: line 45: /pseudodone: Permission denied May 12 21:19:27 cat: /pseudodone: No such file or directory May 12 21:20:07 the layers aren't a problem, I understand what to do with that. May 12 21:21:45 BUILDDIR is set by the oe-init-build-env script.. there are a hand full of items set May 12 21:22:58 values being configured are BB_ENV_EXTRAWHILE, BUILDDIR, and PATH May 12 21:23:06 'er.. BB_ENV_EXTRAWHITE May 12 21:23:24 ah, right May 12 21:23:56 so yeah, that is an example of something that wasn't neede d with "classic" oe but apparently is needed with oe-core. May 12 21:24:38 yes.. builddir is setup because of the need of the wrapper script.. and the wrapper script is needed because of pseudo.. pseudo is needed to resolve the bug of "fakeroot" style control in python functions May 12 21:28:27 yeah. I don't doubt that there are good reasons for this stuff, but it is a little bit of a shame that the amount of external mechanism required is going up again. May 12 21:29:01 I will say that every time a change like this has occured, there is a lot of discussion around it, and if it's reasonable.. May 12 21:29:07 with classic oe, we had almost reached the point where you didn't need to have any obscure stuff in your env prior to running bitbake, and now oe-core seems to have moved some distance away from that again. May 12 21:29:11 thats why there are "only" three items touched.. May 12 21:29:55 the builddir might be able to be removed.. the BB_ENV_EXTRAWHITE isn't needed in a lot of configurations.. and the PATH ensures you are running the wrapper script, not the actual bitbake binry May 12 21:30:56 is there any chance we can get whatever magic is currently in the wrapper folded into bitbake itself? May 12 21:31:03 I haven't looked to see what it is actually doing. May 12 21:31:24 we've been discussing that.. at this time, we can't do it.. May 12 21:31:46 the wrapper is doing two things.. the primary thing is simply selling LD_PRELOAD=...pseudo May 12 21:32:10 this way pseudo is always in memory when bitbake or it's sub processes run.. (pseudo, unlike fakeroot) is disabled by default.. and is enabled via an environment variable on fork and/or exec May 12 21:32:38 but the issue is, you can't reasonably set the LD_PRELOAD, without having pseudo built.. so the wrapper also does a "stage1" build.. the purpose of which is to simply build pseudo-native.. May 12 21:32:43 stage2 is the "regular" build.. May 12 21:33:18 there have been some discussions on creating a multi-stage build process that can restart bitbake and such.. but right now the best answer anyone has come up with is a wrapper script, similar to whats there.. (just more extensible) May 12 21:34:30 there was some early talk about making bitbake be able to setup values adn re-exec itself.. but at least initially that was frowned upon for being overly complex -- compared to a simple shell wrapper May 12 21:36:12 * ReaperOfSouls wonders how doing the exact thing you would do inside on the outside is a reduction in complexity. :) May 12 21:36:27 oh, right, I see. so you want bitbake itself to be running with pseudo preloaded. May 12 21:37:45 yup May 12 21:37:56 * Jay7 forgot again why that wrapper around bitbake was needed.. May 12 21:38:18 ReaperOfSouls it's to reduce the complexity of bitbake itself May 12 21:39:09 fray: *shrug* you can do all the tasks as metadata include. May 12 21:39:25 there was concern that bitbake is used outside of OE.. and making those changes could affect the other projects and/or the overall maintenance complexity within bitbake.. May 12 21:39:28 fray: leave bitbake naked. May 12 21:39:31 thus moving it external was the next choice May 12 21:40:03 is it really used outside oe? May 12 21:40:16 the LD_PRELOAD and such has to be loaded prior to bitbake itself.. because the python based tasks are run directly.. so it would require a way for bitbake to re-exec itself, after adding LD_PRELOAD to the environment May 12 21:40:39 plus, there is no current concept within bitbake of a staged build.. i.e. build up to point X.. then do Y.. then continue building... May 12 21:40:53 export vars, fork + exec $0 May 12 21:40:57 Crofton|work, I was told it is.. May 12 21:40:59 fray: Its pretty straight forward to impliment. When I was playing with it early, I added all that to our collections.inc which already re-execs, and it just worked. May 12 21:41:34 then I'd certainly suggest people point patches for an enhancement and remove the need for the wrapper.. May 12 21:41:39 It was just a POC, but its is not impossible to do. May 12 21:41:48 or may be some .bbclass May 12 21:41:51 the wrapper is there purely for the stage 1 & stage 2 builds.. and to setup LD_PRELOAD prior to the python tasks from running May 12 21:41:53 stage1.bbclass May 12 21:41:59 stageX.bbclass May 12 21:42:34 but I'm unsure how it is possible because of lack internals knowledge May 12 21:42:46 (it also sets BBFETCH2=True so that oe-core can run the fetch2 version.. but thats a minor tweek compred to the others) May 12 21:43:14 anyway, re-exec'ing itself is wide used afaik May 12 21:43:25 but not within bitbake, that we could tell.. May 12 21:43:35 RP RP__: was there anymore movement on the layer tooling rfc? May 12 21:43:40 patches are welcome, I know :) May 12 21:44:04 actually I thought there was an issue in re-execing within a .bbclass item.. because the python chunk is run as a task, so you are not running in the bitbake context.. that would leave two bitbakes running.. May 12 21:44:07 collections.inc made bitbake re-exec itself a long time ago. not pretty, but it got the job done May 12 21:44:47 aside: anyone seen a really strange sha256sum mismatch when the md5sum doesn't mismatch? May 12 21:44:47 ReaperOfSouls: There is some movement on the wiki pages about it I think May 12 21:44:52 i just had apr fail this way, somehow May 12 21:44:54 makes no sense May 12 21:45:04 kergoth_: that sounds very odd May 12 21:45:18 yeah, i'm confused May 12 21:45:21 i think it's one of those days May 12 21:45:21 kergoth_: it's possible in theory.. but I haven't seen that May 12 21:46:07 good nite May 12 21:46:12 i mean, yeah, i realize its theoretically possible to get an md5sum collision, but it has to be really really really unlikely May 12 21:46:14 Just to shorted what bitbake (shell wrapper does).. sets BBFETCH2=True, adds PSEUDO_BUILD & PSEUDO_DISABLED to BB_ENV_EXTRAWHITE.. It runs bitbake pseudo-native -c populate_sysroot.. then runs "mkdir -p PSEUDOBINDIR/../../var/speudo ; PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo bitbake " May 12 21:47:20 RP__: So I got approval to open up our content tools. There are some trivial changes to make them work with layering(actually I already have them working internally).. They might be a good starting point for a component if your interested. May 12 21:48:42 seems pseudo should be better integrated to bitbake May 12 21:49:08 kergoth_: with a 256 bit hash shouldn't it be centuries before you collide? May 12 21:49:32 At least statisically. May 12 21:49:46 ReaperOfSouls: that is why it mismatch when md5sum is matched :) May 12 21:49:47 yeah, would expect so. i'm thinking this has to be a fluke, or something hokey in the checksumming code May 12 21:50:02 ReaperOfSouls: Certainly I'm interested to see what you have May 12 21:50:27 ReaperOfSouls: This probably needs to be a mailing list discussion (and cool on the approval!) :) May 12 21:50:36 speaking of which, i was thinking the other day, i wonder if itd be worthwhile to unwrap the .gz/.bz2 portion of files and checksum the content, since gzips at least can hold timestamps which have nothing to do with what you actually get May 12 21:50:57 we already have to read the entire file, would just be a matter of doing it via a gzopen or whatever May 12 21:51:29 RP__: Okay l am gonna go through the process of a little bit of de-branding. And Ill try and get them all up early next week. May 12 21:51:36 usually if the archive has been tampered with, I'd rather not trust the contents.. May 12 21:51:53 if the tarfile checksum matches, i don't see why you woudln't trust the content May 12 21:51:54 ReaperOfSouls: I'll ping bluelightning and make him aware this is going to happen May 12 21:52:02 so simply md5/sha the compressed file should be good enough May 12 21:52:17 one could consider gz/bz2 an artifact of the delivery mechanism, not an aspect of the content May 12 21:52:32 kergoth_ in the past there have been security issues with zlib and such.. if the archive has changed, someone might be trying to exploit it May 12 21:52:41 maybe it's not worthwhile, just popped into my head the other day May 12 21:52:47 kergoth_: It sounds like it would complicate things without any useful benefit May 12 21:53:00 i've seen upstreams rearchive and change our checksum without changing the content on multiple occasions May 12 21:53:04 the only reason I could see for osmeone to do that is if they want to change the amount of compression, compared to upstream May 12 21:53:16 almost always due to the gzip timestamp (which can be disabled, bu tmost people don't know about it) May 12 21:54:16 probably not worth the added complexity, indeed, at a minimum you'd need something else attached to the unpack code in fetch2 to remove the outer layer May 12 21:55:04 We need more time and less things to fix :) May 12 21:55:35 fray: about possible other projects using bitbake May 12 21:55:52 fray: using pseudo should be feature, not blocker May 12 21:56:06 so I see no problem to mainline that behaviour May 12 21:56:09 ya.. pseudo is not required by bitbake.. you can still ue fakeroot May 12 21:56:13 just make it configurable May 12 21:56:19 it is configurable May 12 21:56:28 which is why master works with oe-core and oe May 12 21:56:35 nice May 12 21:58:22 so we only need [switcheable] exporting LD_PRELOAD with right path and fork+exec $0 May 12 21:58:55 well.. a bit more.. May 12 21:58:56 * RP__ has been considering having bitbake exit with a specific code once its built pseudo-native May 12 21:59:28 RP__: https://github.com/kergoth/bitbake/compare/master...exceptions - seem reasonable to you? two pieces, one improves output for a number of parse error cases, and the other shifts the traceback formatting into the UI/formatter, rather than pre-formatting in the server May 12 21:59:49 if there is no pseudo root was populated then populate it before May 12 22:00:48 * otavio went to University May 12 22:00:50 cya May 12 22:00:57 meh, this week needs to be over already May 12 22:03:26 yeah... May 12 22:03:43 * Jay7 should join oe-core development and testing.. May 12 22:05:06 kergoth_: looks reasonable to me May 12 22:05:31 there's still a fair bit of work to be done on the exception madness, but its yet another step forward i think May 12 22:05:38 heh May 12 22:08:01 * kergoth_ gets caffeine May 12 22:16:10 sorry back.... for the pseudo stuff.. if pseudo is not there, certain things will fail.. like rootfs construction, some package building... etc.. May 12 22:16:49 as for the workaround.. LD_PRELOAD of the pseudo libraries will work.. but call the pseudo binary as a wrapper to bitbake (if we re-exec for instance) is better because that ensures all of the environment variables that pseudo uses are configured and preserved May 12 22:24:49 fray: as I understand, bitbake may build pseudo-native before May 12 22:25:03 so I see no problems about missing pseudo May 12 22:26:13 pseudo should be just enabled in some bitbake config file May 12 22:27:21 pseudo must be loaded into memory before the bitbake process to build ANY target packages May 12 22:27:29 pseudo is not used for cross and native packages May 12 22:28:52 so, if pseudo usage is enabled, then build pseudo-native, populate pseudo root, setup LD_PRELOAD and re-exec itself May 12 22:29:16 yes.. thats a minimum.. better to exec pseudo itself with $0 as the argument May 12 22:29:25 but LD_PRELOAD + other PSEUDO environment variables will work May 12 22:29:31 yes, or so May 12 22:30:16 build through pseudo-native -- including populate the sysroot. have bitbake process exec pseudo $0 $@ May 12 22:30:20 that will do it.. May 12 22:30:31 alternative if a "re-exec" is easier is the LD_PRELOAD=...pseudo May 12 22:30:40 (LD_PRELOAD is more complicated and required more logic) May 12 22:30:43 it's the same May 12 22:30:48 no it's not May 12 22:30:51 fork + exec May 12 22:31:00 difference is what to exec there May 12 22:31:09 LD_PRELOAD requires the path setup properly.. calling "pseudo" (the binary) sets up the path for you May 12 22:31:30 and it's not fork + exec.. it's simply exec from the bitbake context.. _or_ fork + exec -- then on the fork side exit May 12 22:32:17 (and if we support non Linux hosts, then LD_PRELOAD itself won't work.. pseudo has the logic for other OS preloads as well built in) May 12 22:33:44 hm.. yes, just exec may be used here.. May 12 22:33:54 but the normal way that tasks get executed in bitbake (correct be if I'm wrong please) is "bitbake runs -- does work", fork(), task executed (either directly in python or via exec) May 12 22:33:59 we don't need to wait for completion May 12 22:34:23 the problem if we do this re-exec of bitbake within a task (i.e. no changed to bitbake) then the original bitbake process is still running.. I'm not sure if that will work or not May 12 22:34:47 a trigger to kill off the parent process would be fine, but somehow you have to preserve "control" so that anything from the child gets passed back to any scrips or anything calling the original bitbake.. May 12 22:34:51 thus the exec w/o a fork May 12 22:34:55 (preserve the pid) May 12 22:35:41 yes, no fork is needed here May 12 22:36:02 (or desired).. I'm simply not sure if bitbake (as it's implemented) can do an exec w/o a fork.. May 12 22:36:08 just exec pseudo with $* May 12 22:36:12 if we enhance bitbake to give us that capability then it should work fine May 12 22:36:40 ah.. we have client-server model.. May 12 22:36:44 at the time, this is one of the sticking points.. it was discussed and decided to not be worth it.. I'm very much open to changing that and getting rid of the wrapper.. but the wrapper was easier to implement May 12 22:37:08 and server may be at other host May 12 22:37:18 not sure... May 12 22:37:27 (in future) May 12 22:37:46 I know there is a UI component, which is seperate from the task executor.. but I'm not familiar with the details of it May 12 22:37:48 so, re-execing or execing pseudo may affect client connection May 12 22:38:00 it's the task executer that has to be run under pseudo control.. May 12 22:38:01 i.e. UI May 12 22:38:08 yes, I would think so.. May 12 22:39:18 hm.. anyway, wrapper have same possible problem May 12 22:40:17 I don't know.. other then an external controlling script still sees the output of the single PID that it executed.. May 12 22:40:24 when that PID dies, the build is over May 12 22:47:19 how do I use make -j in oe's bitbake May 12 22:52:49 trelane`: PARALLEL_MAKE = "-j5" or whatever, in local.conf May 12 22:54:33 cool May 12 23:07:37 03Richard Purdie  07master * r036cf3cd11 10bitbake.git/lib/bb/codeparser.py: May 12 23:07:38 codeparser.py: Ignore incomplete cache files May 12 23:07:38 Signed-off-by: Richard Purdie May 13 01:17:58 does anyone use OE on a Ubuntu 11.04 build system? May 13 01:18:39 i'm experiencing a -lpthread error when building perl-native as part of meta-toolchain. May 13 01:34:40 cverges: yes, there are a couple patches floating around on the mailing list May 13 01:34:46 I had to apply those before I could continue May 13 01:35:15 liamMT: sweet, thanks for the heads up. i've been going nuts trying to figure out why my system hates pthreads. :-) May 13 01:35:45 liamMT: any insight into specific ones? i'll do the legwork if not and/or you don't want to look it up :-) May 13 01:36:17 eh, I think my note taking failed me, sadly May 13 01:36:36 liamMT: no worries, thanks so much! May 13 01:36:41 good luck! May 13 01:45:32 http://comments.gmane.org/gmane.comp.handhelds.openembedded/45032 i think this is the patch, in case anyone finds this IRC log later **** ENDING LOGGING AT Fri May 13 02:59:58 2011