**** BEGIN LOGGING AT Tue Nov 17 02:59:56 2009 **** ENDING LOGGING AT Tue Nov 17 04:48:21 2009 **** BEGIN LOGGING AT Tue Nov 17 04:48:49 2009 Nov 17 07:10:09 RP: ping Nov 17 07:18:11 JaMa: morning. I'm still on the g_file_storage path. mind taking a look at http://pastebin.com/d56d962e1? Nov 17 07:20:27 JaMa: now the ipk seems to be built correctly, but g_file_storage doesn't autoload Nov 17 07:30:53 RP: for locking LOCALCOUNT I would add def localcount_internal_helper(ud, d): checking for that "(LOCALCOUNT_pn-somepackage = "12")" and using that instead of count from persistent cache Nov 17 07:31:00 does someone know what's wrong here? http://dpaste.com/121448/ Nov 17 07:32:58 tasslehoff: just guess... is module.dep ok on your target? (depmod called?) Nov 17 07:35:42 JaMa: not sure. this is the first time I really work with modules :) Nov 17 07:42:43 tasslehoff: modprobe g_file_storage works? Nov 17 07:43:13 JaMa: yes Nov 17 07:44:33 tasslehoff: and what is in that .conf file? Nov 17 07:44:56 does modprobe work even if you append content of that file? Nov 17 07:46:25 JaMa: ehm. now this is embarassing. I have actually written "file=/dev/foo" in the conf file :D Nov 17 07:48:22 embarrassing even, I'll change the config and try again Nov 17 07:50:41 JaMa: modprobe: WARNING: /etc/modprobe.d/g_file_storage.conf line 1: ignoring bad line starting with 'file=/dev/mmcblk0p4' **** BEGIN LOGGING AT Tue Nov 17 07:58:56 2009 Nov 17 08:06:01 obviously /dev/mmcblk0p4 is the 4th partition on the 1st MMC , yes? if so, why would you need to define that in module options? Nov 17 08:06:45 * enouf joined late - so ignore me ..if applicable ;-) Nov 17 08:08:25 enouf: I only want that partition to be exposed as mass storage, so I will partly ignore you ;) Nov 17 08:08:44 heh ... Nov 17 08:13:37 btw, there's only one s or one r in embarrasing, IIRC ... i'll look it up now ;-)... ew .. wrong again :-O .. there;s TWO of each :-P Nov 17 08:14:20 * enouf feels embarrassed :-P Nov 17 08:15:18 hehe. even better that you used two r's to tell me that there is only one ;-) **** ENDING LOGGING AT Tue Nov 17 08:25:28 2009 **** BEGIN LOGGING AT Tue Nov 17 08:25:49 2009 Nov 17 08:45:58 good morning Nov 17 09:13:42 JaMa: modprobe gives the same warning about bad line. I have this in my machine-conf: module_conf_g_file_storage = "file=/dev/mmcblk0p4 removable=1" **** BEGIN LOGGING AT Tue Nov 17 09:31:49 2009 Nov 17 09:36:05 anyone else got an idea what goes wrong in my module loading? http://pastebin.com/d499036c3. Nov 17 09:38:21 tasslehoff: what does /etc/modprobe.d/g_file_storage.conf look like ;-) Nov 17 09:39:10 DJW|Home: file=/dev/mmcblk0p4 removable=1 Nov 17 09:39:49 hmmm. should it be prefixed with options? Nov 17 09:40:11 03Martin Jansa  07org.openembedded.dev * r6ca479d37a 10openembedded.git/recipes/ (5 files in 4 dirs): Nov 17 09:40:11 svn recipes: change svn${SVNREV} to svnr${SRCPV} Nov 17 09:40:11 * Only formal change Nov 17 09:40:11 * Should be safe as version svnr[1234567890]* > svn[1234567890]* Nov 17 09:40:11 Signed-off-by: Martin Jansa Nov 17 09:40:12 03Martin Jansa  07org.openembedded.dev * r0a9b8d7b6a 10openembedded.git/recipes/openscada/openscada_svn.bb: Nov 17 09:40:17 openscada: add svnr${SRCPV} to PV Nov 17 09:40:19 Signed-off-by: Martin Jansa Nov 17 09:40:21 03Martin Jansa  07org.openembedded.dev * r1c70f21392 10openembedded.git/recipes/ (244 files in 96 dirs): Nov 17 09:40:24 svn recipes: change +svnr${SRCREV} +svnr${SRCPV} Nov 17 09:40:26 * Just formal change Nov 17 09:40:28 * No need to bump PE or PR Nov 17 09:40:30 Signed-off-by: Martin Jansa Nov 17 09:40:32 03Martin Jansa  07org.openembedded.dev * ra748d266a1 10openembedded.git/recipes/freesmartphone/fsoraw_svn.bb: Nov 17 09:40:37 fsoraw: add svnr${SRCPV} to PV Nov 17 09:40:39 Signed-off-by: Martin Jansa Nov 17 09:44:52 morning all Nov 17 09:44:59 good morning Nov 17 09:47:25 Hi all. I am having the same error during build as on http://projects.linuxtogo.org/pipermail/openembedded-devel/2009-April/009802.html (problems with klibc). What is the best solution for that? Nov 17 09:48:14 There is an advice in the thread to use older kernel, but how I can specify the version of it? Nov 17 09:48:50 florian: good morning Nov 17 10:12:29 after adding "options" to my /etc/modprobe.d/g_file_storage.conf I now longer get an error. but now g_file_storage is first loaded without any options, and a while later I see "Unloading [g_file_storage]" Nov 17 10:14:27 RP: thanks for comments to that bitbake localcount patch.. I'll send new one in few mins.. but that last part is imho still needed.. as should want to store your (not incremented) localcount in persistence db for cases when LOCALCOUNT override is removed later... Nov 17 10:17:33 RP: and "Just check getVar("LOCALCOUNT_" + ud.parm['name'], d, 1)" seems a bit inconsistent with SRCREV where I started with that localcount helper Nov 17 10:17:48 JaMa: The "if localcount is None" bit being the last bit? Nov 17 10:17:58 JaMa: SRCREV is wrong to do that :/ Nov 17 10:18:31 JaMa: SRCREV shouldn't be assuming knowledge of overrides :( Nov 17 10:21:25 JaMa: ah, I see what you mean about the non-incremented value Nov 17 10:22:16 RP: ok I'll send updated patch.. Nov 17 10:23:02 RP: btw bb.data.getVar("BB_LOCALCOUNT_OVERRIDE", d, True) or False is "free" or is it worth saving for whole Fetcher? Nov 17 10:23:36 JaMa: Its "free" compared to other stuff you're doing there Nov 17 10:23:50 RP: thats why i prepared that function where it could be saved in init() but I'm not python programer so I wasn't sure how it should be done.. Nov 17 10:26:20 JaMa: I'm more worried about readability with that section of code than performance :/ Nov 17 10:28:06 RP: and that last bit "if localcount is None" I can move a bit later just before that increment.. that way you would get count == 0 even when you're using override and haven't specified localcount.. Nov 17 10:30:52 RP: http://pastebin.ca/1674651 ? Nov 17 10:36:53 somebody knows something about this ERROR: while parsing /media/disk/marmita/openembedded/recipes/matchbox2/matchbox-panel-2-icon-themes_0.0.1.bb Nov 17 10:37:06 ? Nov 17 10:37:37 JaMa: sounds better Nov 17 10:38:27 tilarids: ti my knowledge klibc_1.5.15 and kexec-tools-klibc-static_2.0.0 both build fine for arm. They even happen to work as expected...:) Nov 17 10:38:28 ceyusa: my fault.. Nov 17 10:38:35 JaMa: Just one more thing - you need to do a str(int(count)) in that last bit Nov 17 10:38:45 the PV thing is choking bitbake :D Nov 17 10:38:46 ceyusa: forget to push second patch.. Nov 17 10:39:11 JaMa: so use an if, elif, else Nov 17 10:39:31 tilardis: probably old klibc_1.5 was not updated wrt new kernels Nov 17 10:39:39 JaMa: a str(count) anyway, just to be 100% sure it stays as a string Nov 17 10:39:47 JaMa: Oki :) Nov 17 10:40:29 03Martin Jansa  07org.openembedded.dev * r98485cecad 10openembedded.git/recipes/matchbox2/matchbox-panel-2-icon-themes_0.0.1.bb: Nov 17 10:40:29 matchbox-panel-2-icon-themes: add SRCREV_FORMAT as there is more svn urls Nov 17 10:40:29 Signed-off-by: Martin Jansa Nov 17 10:42:02 RP: str(count) for uselocalcount? and str(int(count) + 1) can stay for non uselocalcount? Nov 17 10:43:05 JaMa: yes Nov 17 10:43:12 RP: should I add some check that localcount in helper is int? or will python handle str(int(count) + 1) somehow when someone put LOCALCOUNT = "bar" ? Nov 17 10:43:35 JaMa: It will throw an exception Nov 17 10:48:24 ceyusa: fixed? Nov 17 10:48:35 yep Nov 17 10:48:48 well... just let me start over again.. Nov 17 10:48:55 hello Nov 17 10:49:03 ceyusa: sorry for that... Nov 17 10:49:09 noprob Nov 17 10:50:47 JaMa: bitbake now doesn't complain at all .. thanks! Nov 17 10:52:35 I have some trouble compiling the gcc-cross-initial package, maybe someone over here got the same issue. Nov 17 10:52:43 it basically failed here Nov 17 10:52:46 checking for i686-angstrom-linux-gcc... /home/xcb_t_jeang/build-scripts/build/iovm/build/build/work/i686core2-angstrom-linux/gcc-cross-initial-4.3.3-r7.1/gcc-4.3.3/build.i686-linux.i686-angstrom-linux/./gcc/xgcc -B/home/xcb_t_jeang/build-scripts/build/iovm/build/build/work/i686core2-angstrom-linux/gcc-cross-initial-4.3.3-r7.1/gcc-4.3.3/build.i686-linux.i686-angstrom-linux/./gcc/ -march=core2 -isystem/home/xcb_t_jeang/build-scripts/buil Nov 17 10:53:31 when I got a bit deper it turns out that /home/xcb_t_jeang/build-scripts/build/iovm/build/build/work/i686core2-angstrom-linux/gcc-cross-initial-4.3.3-r7.1/gcc-4.3.3/build.i686-linux.i686-angstrom-linux/./gcc/as: line 77: exec: : not found Nov 17 10:53:56 as failed because ORIGINAL_AS_FOR_TARGET is empty Nov 17 10:54:03 in the .gcc/as script Nov 17 11:00:08 JaMa: nice work Nov 17 11:00:25 I manage to load g_file_storage but have two problems. 1: it seems to be autoloaded without the options from /etc/modprobe.d/g_file_storage.conf 2: it gets unloaded and replaced by g_cdc late in the boot process. Nov 17 11:00:39 XorA: thanks Nov 17 11:01:28 XorA: let's hope that remaining issues are resolved soon enough for that branch to merge.. (lots of conflicts otherwise.. :/) Nov 17 11:03:05 JaMa: I never like the PR appearing twice in PV its just asthetically annoying Nov 17 11:04:11 morning Nov 17 11:04:35 hrw: do you need something in xorg-7.5 branch for successfull test on bug? I've added newer mesa, but I'm not sure if all OE devices can use mesa-dri, so I haven't set PREFERRED_PROVIDER_virtual/libgl for all Nov 17 11:05:04 shit.. I forgot about that and scratched that builddir Nov 17 11:05:53 XorA, RP: agreed.. what do you think about moving ${SRCPV} to PR as suggested somewhere in SRCPV migration thread? and using constant PV for easy preferred version setting? Nov 17 11:06:52 it would be easy to do now with all PE bumped.. Nov 17 11:06:57 JaMa: it all gets complex, we are the only set of distros actually putting the git hash inside the PV Nov 17 11:07:04 everyone else seems to just use a build number Nov 17 11:08:20 XorA: kernels built with kernel-package from Debian use git hash Nov 17 11:08:38 linux-image-2.6.32-rc5-00402-gb6727b1 Nov 17 11:09:05 hrw: but I see they stick a build number in there, and thats also not official kernels is it Nov 17 11:10:11 XorA: thay care a lot about build number irc.. there was some topic about that in kernel traffic Nov 17 11:11:54 how can I blacklist a kernel module? Nov 17 11:12:07 I think its an issue we will never find a "perfect" solution for as OE is rare in that is is the same meta data for multiple quite different Distros Nov 17 11:13:18 otavio: ping Nov 17 11:14:09 ~botsnax Nov 17 11:18:30 XorA: That's not a Debian-generated build number. Nov 17 11:18:43 XorA: That's generated automatically by git describe Nov 17 11:19:02 git describe can only do that if you've got a tag, though. Nov 17 11:31:43 hrw: hello Nov 17 11:32:43 otavio: have a minute to discuss geode stuff? Nov 17 11:41:55 otavio: I will write it as a mail to ML Nov 17 11:43:17 I tried adding ' module_conf_g_cdc = "blacklist g_cdc" ' to my machine conf, but it didn't work. Nov 17 11:45:39 hrw: sure Nov 17 11:45:45 hrw: please go ahead Nov 17 12:26:26 koen: why is the default USB_MODE="composite" if the g_cdc module is not available? Nov 17 12:33:04 tasslehoff: er, koen is not in this channel Nov 17 12:33:47 can someone explain the SRCPV stuff and why someone is complainging about the gnuradio recipe? Nov 17 12:33:56 pb_: good point :). Nov 17 12:34:04 from the list chatter, it was not clear to me the stuff was ready for dev .... Nov 17 12:34:37 the gnuradio git recipe has the rev in the recipe itself, to avoid merge headaches Nov 17 12:35:02 quite frankly, the srcpv stuff seemed to be for the benefit of people using OE to do sw dev Nov 17 12:36:21 Crofton: SRCPV doesnt change where the rev can/cant be defined Nov 17 12:36:37 Crofton: it makes the PV compatibile if you use a fixed rev or a dynamic rev Nov 17 12:36:44 Crofton: which they are not currently Nov 17 12:36:47 I didn't get what SRCPV is heh Nov 17 12:37:11 simple put SRCPV makes all git revs be gitXX+DEADBEEF Nov 17 12:37:15 well, I wake up and a recipe I care about is in some guys list of broken stuff Nov 17 12:37:24 * Crofton|work notes it is 0737 here Nov 17 12:37:28 where before they were gitDEADBEEF or gitXX+DEADBEEF which didnt mix Nov 17 12:37:47 * Crofton|work has to cook DEADBEEF for dinner Nov 17 12:38:05 with JaMa's latest patch it is now certainly a lot cleaner than PR appearing twice in the version Nov 17 12:38:16 I'll try and look at this, nutty day though Nov 17 12:38:35 and I can't build images because opkg sucks Nov 17 12:39:46 One thing I started to worry me is a migration path from stable/2009 to stable/2010. Currently things are done in dev and stable is never merged back into dev. So the merging of current developed stable/2010 will be quite difficult Nov 17 12:40:31 I do not think it is possible for stable branches to stay synced with dev Nov 17 12:40:36 due to invasive changes in dev Nov 17 12:41:09 otavio: stable/2009 do not have changes which are not in .dev Nov 17 12:41:51 Crofton|work: thats because with BB_GIT_CLONE_FOR_SRCREV it cannot parse gnuradio.. I'll recheck why.. Nov 17 12:42:10 ok Nov 17 12:42:12 hrw: so give a try to merge it and see how it goes Nov 17 12:42:16 hrw: I did Nov 17 12:42:25 Crofton|work: some packages are failing because nonexistent SRCREV.. some are failing because of not accessible repository.. Nov 17 12:42:25 hrw: and it is not "easy" Nov 17 12:42:50 Crofton|work: but that list is from shr.. where its enabled and srcpv branch is already merged there.. Nov 17 12:43:12 hrw: I think we should merge stable/xxxx into dev from time to time Nov 17 12:43:13 ah Nov 17 12:43:21 like I said, it is early here Nov 17 12:43:25 hrw: this allow for easy migration of users to next stable Nov 17 12:43:31 hrw: otherwise it will be a nightmare Nov 17 12:44:09 otavio: looks like another thing to todolist Nov 17 12:44:20 hrw: do you see my point? Nov 17 12:44:39 hrw: if we merge "upstream stable" the only missing things will be the "in house" changes Nov 17 12:44:57 hrw: so it will be easier; otherwise, quite difficult Nov 17 12:45:00 hrw: BUT Nov 17 12:45:27 hrw: I think it should be done now then later; since a lot of invasive changes are going to happen inside of dev and this will make it even harder. Nov 17 12:45:58 hrw: what you wanted to talk about geode? Nov 17 12:47:50 otavio: read my oeml mail Nov 17 12:47:57 some updates for platform Nov 17 12:49:49 hrw: I read it now Nov 17 12:50:09 hrw: it looks like newer glibc do not support --with-cpu=geode anymore Nov 17 12:50:37 hrw: and IIRC who said to us to use i486 was CosmicPenguin Nov 17 12:51:07 CosmicPenguin: can you please confirm that i486 is faster then i586 for geode lx? Nov 17 12:51:37 hrw: but what I think we could do is drop gx and lx machines and try to use a single one Nov 17 12:52:08 hrw: kernel is mostly the same nowadays and even if we lose a bit of possible optimization it is worth IMO Nov 17 12:52:29 pb_: ping? Nov 17 12:52:35 ant_work: hello Nov 17 12:52:40 hey Nov 17 12:53:04 can you imagine cpufreq breaking kernels with pxa250 but not pxa255? Nov 17 12:54:28 it's certainly possible, yes Nov 17 12:54:36 XorA: did you look our patch to bitbake to AUTOPV support? Nov 17 12:54:47 XorA: it does mostly what people are calling SRCPV Nov 17 12:54:50 iirc, the clock systems are a little bit different on the two: it's not at all impossible that one might be broken but the other still work Nov 17 12:54:58 pb_: it seems an issue with governors Nov 17 12:55:09 unfortunately I don't have that hw Nov 17 12:55:21 otavio: no Nov 17 12:55:27 XorA: https://projetos.ossystems.com.br/git/?p=users/otavio/bitbake.git;a=commitdiff;h=62935bd1699b580eaadf5e4a68fc35e53b477685;hp=793e7e61762caf88127e6f5d521d03668f8a9f3a Nov 17 12:55:34 XorA: I think it is worth looking Nov 17 12:55:47 XorA: we have been using it for few mounths already Nov 17 12:56:20 pb_: ok, thx, we'll just disable cpufreq for the moment then Nov 17 12:57:21 otavio: isnt the problem there git describe is kinda tied to certain meta data inside the repo? Nov 17 12:57:40 XorA: it depends how you use it Nov 17 12:57:53 XorA: if you use it as --always it outputs a count as you did ;P Nov 17 12:58:00 XorA: in case it has no tag Nov 17 12:58:05 XorA: otherwise it uses the tag Nov 17 12:58:39 XorA: so you get nice versions as: 1.0-5-gxxxxxxx Nov 17 12:58:43 XorA: and next commit Nov 17 12:58:50 XorA: 1.0-6-gxxxxxxx Nov 17 12:59:11 XorA: in case it has no 1.0 tag it does: 0.0-5-gxxxxxx Nov 17 12:59:18 otavio: doesnt it also suffer the chicken and egg problem? you can describe a git repo you havent fetched yet and therefore cant use it in PV Nov 17 12:59:46 XorA: you can't count rev-list of a repo you haven't fetched yet Nov 17 12:59:57 XorA: therefore you can't use it for PV anyway Nov 17 12:59:59 ant_work: can you make it a module? Nov 17 13:00:03 otavio: I think your talking about something not SRCPV Nov 17 13:00:20 otavio: SRCPV is a simple change to PV format Nov 17 13:00:35 XorA: the LOCALCOUNT change that are going together with it Nov 17 13:01:19 otavio: making git fetches on parsing has always been rejected, its a totally seperate issue to SRCPV change Nov 17 13:01:37 hrw: we have a single c7x0 machine :/ Nov 17 13:01:45 otavio: stop winding back time, its taken me 2 years to seperate those issues Nov 17 13:02:27 XorA: mind to explain? Nov 17 13:03:05 otavio: SRCPV change is a simple change in format, how LOCALCOUNT is generated is a totally seperate issue Nov 17 13:03:18 XorA: ahhhhhhhhhhhhhhhhhh Nov 17 13:03:30 XorA: so the localcount thing that is realted right? Nov 17 13:03:35 otavio: once you mention git you create war Nov 17 13:03:36 XorA: related, I meant Nov 17 13:03:42 hah Nov 17 13:03:43 lol Nov 17 13:03:48 XorA: I like GIT :P Nov 17 13:04:06 otavio: related, but SRCPV generates them itself, there are otherways to do it Nov 17 13:04:21 e.g. throw dices Nov 17 13:04:22 I must say git is nice as a patch tracker, as an SCM its pretty dire Nov 17 13:04:36 fails pretty much all reasons for having an SCM Nov 17 13:04:47 What's it missing? Nov 17 13:05:00 XorA: it is up to the user to 'break history' or not Nov 17 13:05:01 broonie: you can re-write history, makes it pretty useless Nov 17 13:05:19 XorA: this is one of features i do like on it Nov 17 13:05:28 XorA: you can do that with pretty much anything if you feel like it. Nov 17 13:05:28 broonie: if you need to go for audits, that feature means an auto fail Nov 17 13:05:28 ant_work: and if pxa25x cpufreq can be made modular... then no problem. but I am afraid that arm cpufreq stuff cannot be module Nov 17 13:05:40 XorA: You can enforce fast forward only server side with a central repo. Nov 17 13:05:42 maybe I spent too long working on security audited code Nov 17 13:05:46 hrw: I'll check, thx for the hint Nov 17 13:05:53 XorA: you can have clean history without all your mistakes during the hack sessions when merging the branch Nov 17 13:06:10 XorA: Which is probably what you need for that situation (and is not any different to anything else, really). Nov 17 13:06:47 Obviously if someone has admin access to the repo you loose. Nov 17 13:07:29 RP: do you mind to take a look in the code we did to git fetching code of bitbake? It looks like what you are looking for to git revcount? Nov 17 13:07:39 (though signing tags helps a lot since the commit id includes all parent information too so it's rewriting history behind a signed tag would break the signature) Nov 17 13:07:42 hrw: CPU_FREQ* is bool :/ Nov 17 13:09:56 hrw: wait, now is tristate ...hmm Nov 17 13:11:07 ant_work: 2.6.26 still? Nov 17 13:11:28 yes..2.6.3x doesn't boot from nand, yet Nov 17 13:11:40 is ok from removable, though Nov 17 13:14:10 hrw: read the PCI ID's at the end of this page, you'll see why Cyrix gave problems and headhaches :-} http://cateee.net/lkddb/web-lkddb/CPU_FREQ.html Nov 17 13:16:32 otavio: As others have already said, it means fetching when parsing which I really dislike Nov 17 13:17:07 RP: this is the OE change only; the bitbake side not Nov 17 13:17:15 otavio: I don't mind adding it as another optional way of getting SRCREV info but it doesn't actually solve most of the problems Nov 17 13:17:34 otavio: I'm failing to parse that :/ Nov 17 13:18:06 RP: what are the problems it doesn't solve? Nov 17 13:21:13 SRCDATE, SRCREV, SRCPV... argh Nov 17 13:21:34 otavio: a) It requires fetching during parsing b) it only works on repos with a certain tag format c) It doesn't allow manual override/lockdown (see the SRCPV discussion) d) git-describe fails with branching Nov 17 13:21:35 srcdate and srcrev are at least easy to understand Nov 17 13:21:35 * XorA add SRCRND which statistically should be better in 50% of cases Nov 17 13:21:56 hrw: srcpv is just a varient of srcrev with some bugs fixed Nov 17 13:22:23 RP: when I read mails on OEML I have feeling that it also adds new ones Nov 17 13:22:28 having the PV and the REV directly couple is wrong anyway, means you can operate on the REV properly Nov 17 13:23:07 hrw: yes and no - I've agreed that angstrom needs to be able to do deterministic things with it Nov 17 13:23:10 XorA: exactly Nov 17 13:23:14 SRCPV = "munge(SRCREV)" is not possible Nov 17 13:23:22 now possible Nov 17 13:23:38 * otavio is too dumb to get it Nov 17 13:23:58 otavio: I also wait for it to be 'just done and finished' Nov 17 13:24:16 * XorA is amused a one line change causes so much confusion Nov 17 13:24:34 XorA: Koen does have a valid point Nov 17 13:24:49 RP: I know, I like JaMa solution Nov 17 13:25:00 RP: Ive always hated PR being misused Nov 17 13:25:32 hrw: heh Nov 17 13:25:35 XorA: SRCREV was lovely for svn. its just a shame git is such a problematic beast :( Nov 17 13:26:25 Most DVCSs have similar issues. Nov 17 13:26:34 broonie: well, yes Nov 17 13:26:37 broonie: I'd say _all_? Nov 17 13:26:43 RP: easy solution then, reprgram all git fans :-) Nov 17 13:26:51 otavio: bitkeeper? Nov 17 13:26:58 * RP isn't sure about that one Nov 17 13:27:01 otavio: providing you don't completely rewrite the history bzr maintains forward-only numbering. Nov 17 13:27:03 RP: neither do I Nov 17 13:27:22 but this means that revision numbers vary between multiple repos which has other issues. Nov 17 13:27:23 broonie: dunno if it works for sorting Nov 17 13:27:33 broonie: exactly Nov 17 13:27:38 It does providing you always look at a single repository. Nov 17 13:27:44 s/repository/branch/ Nov 17 13:27:47 broonie: your rev isn't the same of your co-worker Nov 17 13:27:48 RP: I've found bug in BB_GIT_CLONE_FOR_SRCREV do you have a min? Nov 17 13:28:00 Unless you use a shared server. Nov 17 13:28:14 JaMa: in an hour Nov 17 13:28:20 JaMa: need food Nov 17 13:28:27 RP is weak :) Nov 17 13:28:40 * RP is down to 90 recipes in poky using legacy staging Nov 17 13:29:01 RP: ok.. I'll send patch maybe before.. becase I'll leave then.. Nov 17 13:29:09 mainly we need to persuade people that releasing versions is good Nov 17 13:29:18 Give that was 200+ yesterday I'm quite pleased with that Nov 17 13:39:15 * XorA has broken into google wave and wonders actually what the fuss is about Nov 17 13:44:26 The fuss was all prior to people having access to it. Nov 17 13:49:49 JaMa: still there? Nov 17 13:49:52 there are much better whiteboard capable xmpp clients Nov 17 13:52:22 RP: yes.. Nov 17 13:53:01 RP: http://pastebin.ca/1674843 Nov 17 13:53:46 RP: first there is level used in "bb.msg.error(1" which creates really ugly output as domain is expected.. Nov 17 13:54:18 RP: than it should fail before changing that dir to non-existent one (ugly error again) Nov 17 13:54:48 RP: and if its not accessible it should be better to skip that package instead of parsing error for whole tree I guess Nov 17 13:55:15 RP: and there is still something wrong there i think.. Nov 17 13:55:28 JaMa: Can we not drop that error entirely? Don't we have checks elsewhere that check for an invalid SRCREV now? Nov 17 13:56:37 JaMa: Whether to skip or fail is a tricky question Nov 17 13:56:56 RP: this one is checked during parsing.. that's probably why with SRCPV we get parse errors Nov 17 13:57:59 RP: as workaround I tried to use BLACKLIST from angstrom.. because as you've seen list of "broken" recipes with CLONE+SRCPV is quite long.. Nov 17 13:58:40 RP: but with BLACKLIST I'm removing whole package now (not just git version) and also it doesn't work :) (because blacklisting is used AFTER parsing ;/) Nov 17 13:59:13 JaMa: right, its too late for that to help Nov 17 13:59:44 JaMa: Are you finding packages with SRCREV = "1" ? Nov 17 13:59:54 JaMa: If so we should sync something from poky Nov 17 14:00:46 RP: not sure if ie this one is with SRCREV = "1" http://pastebin.ca/1674852 Nov 17 14:01:02 RP: but maybe its from that imho wrong return "0+1" Nov 17 14:02:17 JaMa: returning 0+1 is wrong, I agree Nov 17 14:02:26 JaMa: Either we raise a skippackage Nov 17 14:02:30 RP: but yes.. seems like disko has SRCREV only in recipe.. Nov 17 14:02:45 or we do a bb.fatal Nov 17 14:02:56 RP: if I uncomment that raises it continues and fails terribly later.. Nov 17 14:03:22 JaMa: Lets change SRCREV = "1" in bitbake.conf in OE to SRCREV = "INVALID" Nov 17 14:03:22 RP: so I expected that skippackage is ignored somewhere in parse phase.. Nov 17 14:04:01 JaMa: Hmm, it shouldn't fail terribly later, thats bad and we should fix that Nov 17 14:04:33 RP: I think that calling self.go is somehow broken in that phase.. Nov 17 14:04:55 RP: ie ignoring SRCREV in recipe, because recipe isn't fully parsed in that time or something like that.. Nov 17 14:05:07 RP: with INVALID its the same.. Nov 17 14:05:22 RP: I'll try to move SRCREV from disco to sane-srcrevs.inc Nov 17 14:05:35 JaMa: ah, right. Ick Nov 17 14:06:26 JaMa: Can you get a backtrace and find out where the first PV lookup comes from? Nov 17 14:06:48 which is presumably where we get our first call from Nov 17 14:06:50 sure Nov 17 14:08:25 RP: http://pastebin.ca/1674865 I hade better BT before.. Nov 17 14:10:14 JaMa: hmm. I really need to dedicate some time to poking around this :/ Nov 17 14:11:09 JaMa: There are several parts to the problem though: a) bitbake.conf should have SRCREV="INVALID" and any errors resulting from that need to be fixed. b) We need to work out why SRCREV in recipes isn't working c) We need to fix SkipPackage from that context Nov 17 14:13:15 RP: yes.. , btw: slightly another issue.. API of self._sortable_revision(url, ud, d) could be change to return tuple of (build, rev)? this way we can cache those 2 in the same way as localcount and rev is used.. Nov 17 14:14:02 RP: only first call for latest_revision would be outside _sortable_revision and if not changed then cached values from persistence db used.. Nov 17 14:16:28 JaMa: I don't understand. What are "build, rev" ? Nov 17 14:16:42 RP: maybe best way would be to call _sortable_buildnumber(url, ud, d, rev); Nov 17 14:17:14 RP: in git.py there is def _sortable_revision(self, url, ud, d): Nov 17 14:17:50 RP: used instead sortable_revision in Fetcher if enabled by BB_GIT_CLONE_FOR_SRCREV Nov 17 14:18:00 JaMa: ah, and you want it to return the two parts separately? Nov 17 14:18:13 RP: yes and then cache it Nov 17 14:18:24 JaMa: That sounds reasonable Nov 17 14:18:32 RP: or even better call it only to get localcount (from known revision) Nov 17 14:19:29 JaMa: You can't pass it a known revision, that breaks the abstraction layer Nov 17 14:19:41 RP: this way we don't need to fix downloading git repo in _sortable_revision, because it works on in sortable_revision and call "git list-rev $rev | wc -l" should be ok then in _sortable_buildnumber Nov 17 14:20:12 JaMa: You've lost me again :/ Nov 17 14:20:34 RP: if you're considering this change.. let me show you the patch.. Nov 17 14:20:52 RP: it would be easy for me, then describing it :) Nov 17 14:20:57 JaMa: ok Nov 17 14:32:29 RP: something like this http://pastebin.ca/1674905 Nov 17 14:32:42 RP: not tested.. but I have no exception/error now Nov 17 14:35:19 RP: could be even more simple... caching can be removed from _sortable_buildnumber, directory checking problably too Nov 17 14:46:11 * mwester reads the backlog Nov 17 14:46:34 * mwester is horrified that someone is proposing to re-introduce a horrible bug that was solved some time ago Nov 17 14:47:01 * mwester shouts: No fetching while parsing!!!! Nov 17 14:47:23 mwester: its not fixed imho.. Nov 17 14:47:40 mwester: its still horrible and still there.. but disabled by default.. Nov 17 14:48:52 As long as nothing requires a network connection in order to parse, I don't care if it's disabled or removed. :) Nov 17 14:49:03 mwester: agreed Nov 17 14:49:16 mwester: The default must be no network needed Nov 17 14:49:33 is it generally recommended to track OE from git? are there no stable official releases? Nov 17 14:49:57 * JaMa agree (if mwester thinks that I'm proposing to change that :)) Nov 17 14:50:08 i keep having problems where git is broken for a few days, and i just wait for a fix - it'd be nice to have a stable branch or formal releases Nov 17 14:50:23 irotas_: everythign is in git, but there are multiple branches. more or less stable Nov 17 14:50:49 There's a stable branch in OE for exactly that purpose, irotas_ Nov 17 14:51:04 formal releases are coming as well Nov 17 14:51:11 florian: is 'stable/2009' the best choice for a conservative user? Nov 17 14:51:14 (in form of branches) Nov 17 14:51:22 A great deal of effort is expended to ensure that only known good and non-disruptive things happen on that branch. :) Nov 17 14:51:53 * RP mutters darkly about the uclibc recipes Nov 17 14:52:04 Do we have a maintainer for uclibc these days? Nov 17 14:52:13 irotas_: yes right - this would be a good choice Nov 17 14:52:39 florian: thanks Nov 17 14:52:52 florian: P.S. this would be an excellent thing to mention on the 'Getting started' page :) Nov 17 14:53:18 RP: hmm, i actually was planning on using uclibc - is it not generally well supported? Nov 17 14:53:39 * irotas_ thinks i should have come to this channel sooner Nov 17 14:53:44 irotas_: yes that's a good idea indeed. Nov 17 14:54:14 irotas_: its fine, I'm just trying to make some general improvements and its recipe is a little insane Nov 17 14:54:45 * mwester thinks that there are no major distros with autobuilders that use uclibc; SlugOS stopped doing so when OpenWRT began supporting the NSLU2 hardware which effectively killed ucSlugOS. Nov 17 14:55:27 Does "minimal" use uclibc? Nov 17 14:55:55 * mwester has a day of spare time, perhaps he should set up an autobuilder for something that can build uclibc Nov 17 14:56:08 RP: what about that patch? we cannot build images without those changes.. :/ Nov 17 14:56:29 JaMa: which patch? Nov 17 14:57:23 RP: something like this http://pastebin.ca/1674905 Nov 17 14:57:38 mwester: It did build ok in poky a while back. Its just my staging removal push it running into difficulties with its recipes Nov 17 15:03:39 JaMa: Yes, thats probably not a bad move Nov 17 15:04:12 RP: ok.. there was typo.. I'll post better one.. Nov 17 15:04:22 Heinervdm is testing it for shr-image Nov 17 15:04:48 JaMa: global name 'key' is not defined while evaluating: Nov 17 15:06:29 Heinervdm: yes.. Nov 17 15:06:34 Heinervdm: update patch there.. Nov 17 15:06:41 Heinervdm: or remove that line from git.py Nov 17 15:06:55 i'm terribly sorry for being a git novice - is this the correct command to obtain the stable/2009 branch: git clone -o stable/2009 git://git.openembedded.org/openembedded Nov 17 15:07:14 RP: http://jama.homelinux.org/org.openembedded.shr/bitbake/0002-BB_GIT_CLONE_FOR_SRCREV-using-only-_sortable_buildnu.patch Nov 17 15:07:54 is there a summary of what SRCPV solves, problem wise, anywhere? read the thread, but not entirely clear Nov 17 15:08:54 kergoth: with autorev you get gitNNNN+Hash with is > or < than gitHash which you get for fixed revision Nov 17 15:09:10 kergoth: SRCPV creates always gitNNNN+Hash format Nov 17 15:09:49 kergoth: for both cases, so you can switch between autorev and fixed revision without loosing upgradeable path Nov 17 15:10:41 kergoth: but NNNN is not global number.. so angstrom had problem with inconsistency between builders which can be fixed with patches I sent.. Nov 17 15:11:17 ahh, i see, thanks, that makes it clearer Nov 17 15:14:20 kergoth: so no need to bump PR included in PV (where it shouldn't be) with SRCREV change, NNNN would be incremented automaticaly or you need to bump LOCALCOUNT_pn-recipe if you're using BB_LOCALCOUNT_OVERRIDE (as multiple builders for same feeds probably will) Nov 17 15:20:07 question - how does angstrom-2008.1-legacy.conf build a 2.4 kernel? there's nothing in the .conf file Nov 17 15:20:17 is that just a placeholder? Nov 17 15:21:20 I think 2.4 kernels are no longer supported in OE, IIRC Nov 17 15:21:47 thats what i was guessing - thanks Nov 17 15:21:57 03Martin Jansa  07org.openembedded.dev * r424ea26ab4 10openembedded.git/recipes/gtk-webcore/midori_git.bb: Nov 17 15:21:57 midori: fix git repository url Nov 17 15:21:57 Signed-off-by: Martin Jansa Nov 17 15:22:07 03Martin Jansa  07org.openembedded.dev * r9eb9ca0fa6 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs.inc: add SRCREV for wesnoth, its in obsolete bud still parsed and with SRCREV = INVALID it fails Nov 17 15:23:21 otavio: no, 586 was faster Nov 17 15:24:01 hmm Nov 17 15:24:52 damn ipython is awesome. i wish i played with it before now Nov 17 15:30:18 morning kergoth Nov 17 15:30:23 hey pb_ Nov 17 15:30:46 man, i just ran into a fun little opkg behavior.. well, really a packaging bug, but there's an opkg behavior involved too Nov 17 15:31:28 if you have a symlink to a directory in one package, and the actual directory in that spot in another package, it just removes the symlink, replacing it with the directory.. i see why, but i could also argue that it should yell, or even give a fatal error about it, since its obviously a packaging issue Nov 17 15:31:52 * kergoth 's granular debug packaging bits were inadvertently traversing symlinks Nov 17 15:32:05 note to self: os.path.is* use stat, not lstat ;) Nov 17 15:33:35 heh Nov 17 15:33:43 yeah, that does sound like an opkg bug Nov 17 15:34:14 seems like it should only be removing the symlink under --force-overwrite. Nov 17 15:34:25 in this case, it broke perl. /usr/lib/perl/5.8.8 is where the files really are, but /usr/lib/perl/5.8 is what's in the perl lib search path.. if /usr/lib/perl/5.8 is no longer a symlink to /usr/lib/perl/5.8.8, none of the standard modules are available Nov 17 15:34:32 indeed Nov 17 15:34:35 that's a good point Nov 17 15:36:05 kergoth: It'd be good to document these issues as we find them somewhere Nov 17 15:36:10 CosmicPenguin: is gx compatible with 586 as well? Nov 17 15:36:31 RP: aye.. does opkg have a bts? I'd hate to clutter up ours with it Nov 17 15:36:34 no Nov 17 15:36:34 heh Nov 17 15:36:55 CosmicPenguin: so for gx we ought to use i486 and lx i586? Nov 17 15:37:06 I guess - you can do whatever you want Nov 17 15:37:29 CosmicPenguin: sure sure; but it would give us the better performance I mean Nov 17 15:37:46 hrw: ^ Nov 17 15:37:58 the core 586 code holds no performance advantage over the 486 code, I think Nov 17 15:37:58 kergoth: it's on google code, I think they have an issue tracker of some kind Nov 17 15:38:06 so it doesn't really matter which instrution set you use Nov 17 15:38:08 ah, right Nov 17 15:38:17 hi CosmicPenguin Nov 17 15:38:37 CosmicPenguin: so you'd use i486 for both? Nov 17 15:38:46 [13:23] < CosmicPenguin> otavio: no, 586 was faster Nov 17 15:38:49 ^ Nov 17 15:38:50 irotas_: basically 2.4 kernels should work in OE but most of our devs forgot that such ones exists Nov 17 15:39:14 otavio: in case you haven't picked up right now - I could care three figs about Geode - you should choose whatever you think is better Nov 17 15:39:40 * hrw just got Sim.One board #0006 Nov 17 15:39:46 CosmicPenguin: I and hrw are intending to work together in improving geode state in OE Nov 17 15:40:03 CosmicPenguin: and currently our geode definition uses i486 Nov 17 15:40:34 CosmicPenguin: however we were pondering about moving it to i586 but then we started to discuss if it would be worth and give us performance boost or not Nov 17 15:40:45 It won't likely give you a performance boost Nov 17 15:40:49 CosmicPenguin: and you're the best person that I know to discuss it Nov 17 15:40:57 but the hardware is officially a 586 instruction set Nov 17 15:41:30 Let me rephrase my previous statement - unless there are 586 specific enhancements in the compiler / glibc, moving to 586 is not likely to give you a performance boost Nov 17 15:41:42 But it is a correct instruction set Nov 17 15:41:45 Do not use 686 Nov 17 15:41:48 Thats the only real restriction Nov 17 15:41:58 it lacks few instructions to be 686 Nov 17 15:42:10 yes it does Nov 17 15:42:18 there was a thread about it on lkml Nov 17 15:44:00 CosmicPenguin: so you'd use i486 for both (GX and LX)? Nov 17 15:44:07 I would use 586 Nov 17 15:44:17 CosmicPenguin: and GX would run with it? Nov 17 15:44:26 CosmicPenguin: not GX1, I'd say GX2 Nov 17 15:45:08 Yes, GX should run with 586... I think Nov 17 15:45:17 CosmicPenguin: good :-) Nov 17 15:45:22 thx CosmicPenguin Nov 17 15:45:33 hrw: in this case I'd say to us to merge it and use i586 for both Nov 17 15:45:42 If there are any GXs left in the world? Nov 17 15:45:53 hrw: do you want me to work on that or are you going to do it? Nov 17 15:45:56 CosmicPenguin: yes; Nov 17 15:45:57 hrw: thanks - it's better if i just move forward with 2.6 anyway - just a little extra work :) Nov 17 15:46:04 CosmicPenguin: OE got new GX added recently Nov 17 15:46:15 CosmicPenguin: here we have some clients that still sells GX2 for Thinclient market Nov 17 15:46:15 otavio: I do - I have nice patchset Nov 17 15:46:23 hrw: ok Nov 17 15:46:48 hrw: if you can, please check if it works (or at least part of it) for stable as well Nov 17 15:47:08 Well, go for 586 for GX and if it breaks, then no harm in going back to 486 Nov 17 15:47:20 Remember that for LX there is also the geode architecture in recent gccs Nov 17 15:47:36 CosmicPenguin: but it is slowly moving to LX Nov 17 15:47:44 CosmicPenguin: -march=geode do not support GX? Nov 17 15:47:47 CosmicPenguin: and geode arch is not compatible with GX? Nov 17 15:48:07 it might not work Nov 17 15:48:07 CosmicPenguin: I'd guess it does otherwise it would be called geodelx? Nov 17 15:48:29 The cores are reasonably close enough that the timings are probably right Nov 17 15:48:47 And its not like the modifications in gcc were greatly tuned for LX Nov 17 15:48:58 so it will probably be okay, but you might see a performance hit Nov 17 15:49:27 CosmicPenguin: you mean at GX? Nov 17 15:49:28 there certainly are some i586-specific optimisations in glibc, but I think they are optimised for the pentium family specifically rather than the i586 instruction set generically. you would probably need to benchmark them to figure out whether that code is a net win or loss on geode. Nov 17 15:50:58 pb_: yes; it looks like geode specific optimizations has been droped from glibc in last releases Nov 17 15:51:10 pb_: it still exists in glibc 2.6 but doesn't in 2.9 Nov 17 15:51:21 pb_: dunno why Nov 17 15:51:39 I guess because nobody was interested in maintaining it. you could always put it back if you wanted. Nov 17 15:51:42 nobody to fight for them, I guess Nov 17 15:51:46 otavio: it got removed for i486 at least Nov 17 15:51:58 from a quick look at the i586 code in glibc, it seems to be optimised to take advantage of the dual integer pipeline in p5. Nov 17 15:51:59 IIRC, the memcpy routines were a win, mostly Nov 17 15:52:09 For geode that is Nov 17 15:52:23 I don't know what the geode microarchitecture is like, but if it doesn't have dual pipelines then the i586 code is likely to be a loss Nov 17 15:52:33 single pipeline Nov 17 15:52:50 pb_: so it would be better to use i486 for glibc in this case Nov 17 15:52:57 right, in that case you probably would be better with the i486 routines Nov 17 15:53:03 And there is a enormous penalty for two floating point operations in a row Nov 17 15:53:04 pb_: good Nov 17 15:53:17 CosmicPenguin: in 586 or 486? Nov 17 15:53:21 in Geode Nov 17 15:53:23 both GX and LX Nov 17 15:55:04 so 486 for them Nov 17 15:57:25 I've never been super sad with what OE spit out for Geode, but I've just been developing and never really worried about performance Nov 17 15:58:12 Of course, I left lots of patches to OE back at AMD - oh, well... Nov 17 15:58:27 CosmicPenguin: after we prepare the patchset could you take a look and see if you could suggest improvements? Nov 17 15:58:40 thanks for the help guys - i'm sure i'll be back Nov 17 15:58:40 http://marcin.juszkiewicz.com.pl/download/diffs/0001-Geode-GX-LX-cleanup-merged-into-geode-generic-moved-.patch Nov 17 15:58:40 CosmicPenguin: :-( that is the sadest part of it Nov 17 15:59:01 otavio, CosmicPenguin: take a look Nov 17 15:59:10 Well, its not like Geode had (has) a future Nov 17 15:59:27 ah.. one more cosmetic change Nov 17 15:59:32 CosmicPenguin: +FEED_ARCH_geode-generic = "i486" Nov 17 15:59:35 oops Nov 17 15:59:36 hrw: +FEED_ARCH_geode-generic = "i486" Nov 17 15:59:39 hrw: wrong Nov 17 15:59:55 Why such an old kernel? Nov 17 15:59:57 ah.. geode right Nov 17 16:00:02 CosmicPenguin: 2.6.31 is old? Nov 17 16:00:16 oh, sorry Nov 17 16:00:22 didn't see the -s Nov 17 16:00:48 hrw: I didn't see changes for geode in kernel lately Nov 17 16:01:13 There will be soon, andres has been busy Nov 17 16:01:26 CosmicPenguin: delinger? Nov 17 16:01:37 dilinger yes Nov 17 16:01:43 CosmicPenguin: right :-) Nov 17 16:01:45 CosmicPenguin: good Nov 17 16:01:51 He is the defacto mr geode these days Nov 17 16:01:53 the poor bastard Nov 17 16:02:03 CosmicPenguin: heh Nov 17 16:02:17 CosmicPenguin: he is nice :-) Nov 17 16:02:29 CosmicPenguin: at least I enjoyed to work with him at Debian :-) Nov 17 16:02:59 hrw: I'd split the patch a little bit. So you could port it to Stable branch Nov 17 16:03:10 hrw: the removal part could be done in another patch Nov 17 16:04:02 otavio: refreshed patch Nov 17 16:04:04 hrw: I'd be interested in it to be in stable as well Nov 17 16:04:22 sure Nov 17 16:04:27 hrw: move it bellow Nov 17 16:04:29 RP: something is wrong.. maybe because of my bitbake patches.. eina-2_0.0.2.060+svnr0+43437-r0 Nov 17 16:04:52 hrw: geode is a 586 machine, not 486 (+++ b/conf/distro/include/sane-feed.inc) Nov 17 16:04:53 RP: any idea how 0+rev gets to svn recipe? Nov 17 16:05:04 ok Nov 17 16:05:15 http://www.twam.info/hardware/chost-i586-vs-i486-on-amd-geode-lx <= nice comparing Nov 17 16:06:01 JaMa|Away: You made all scms require a local revision? Nov 17 16:06:41 RP: no.. Nov 17 16:06:53 RP: at least not intentionally Nov 17 16:06:59 Heh - look at the string sort... Nov 17 16:07:18 hrw: look at the options the guy suggests at the comment Nov 17 16:07:34 CosmicPenguin: heh yes Nov 17 16:07:52 CosmicPenguin: string sorting is the biggest difference Nov 17 16:08:32 otavio: ncie blog post Nov 17 16:08:32 RP: ahh.. now I see.. Nov 17 16:09:33 otavio: none of parts of my patch apply to stable/2009 Nov 17 16:09:52 otavio: you would first need to backport your geode changes there Nov 17 16:10:36 03Xerxes Rånby  07org.openembedded.dev * r3b4c9f8d74 10openembedded.git/recipes/llvm/ (5 files in 3 dirs): Nov 17 16:10:36 llvm2.6: Added BX_to_BLX.patch inorder to stabilize LLVM JIT on ARM Nov 17 16:10:36 llvm2.7: Updated to newer SVN snapshot Nov 17 16:10:36 Added BX_to_BLX.patch inorder to stabilize LLVM JIT on ARM Nov 17 16:11:50 Yay, I faught uclibc and won :) Nov 17 16:11:54 fought Nov 17 16:12:47 hi EsbenH Nov 17 16:14:15 hi Nov 17 16:14:20 morning Nov 17 16:14:37 RP: congratulations Nov 17 16:18:28 03Xerxes Rånby  07org.openembedded.dev * rab1792dbec 10openembedded.git/conf/checksums.ini: checksum.ini: add sums for cacao-0.99.4.tar.gz used by openjdk-6-cacao from jalimo overlay Nov 17 16:19:53 hrw: no problem to me. I'm using them at it Nov 17 16:20:05 hrw: are you using stable? Nov 17 16:21:43 otavio: on a BUG Nov 17 16:22:31 hrw: so would be willing to port it? Nov 17 16:22:38 hrw: if so I can test it here as well Nov 17 16:23:37 RP: fixed patch set to ML Nov 17 16:25:02 otavio: I prefer to not spending more time on it Nov 17 16:25:39 hrw: :-( ok; I'll try to port them then Nov 17 16:25:46 jo Nov 17 16:26:03 hi woglinde Nov 17 16:26:21 hrw whats with wrap board and geode? Nov 17 16:30:44 woglinde: WRAP used SC1100 cpu Nov 17 16:31:00 Geode GX1 Nov 17 16:31:18 okay Nov 17 16:31:28 "National Semiconductor/AMD SC1100 is based on the Cyrix GX1 core and the CS5530 support chip." Nov 17 16:32:22 ok, have to go Nov 17 16:32:31 nice I just got my Overo Fire Nov 17 16:32:36 hrw|gone: bye Nov 17 16:32:44 otavio: build is going for geode-generic Nov 17 16:33:01 hrw|gone: good and thx Nov 17 16:33:03 ah cool Nov 17 16:33:07 disko 1.6 is released Nov 17 16:34:07 woglinde: disko? Nov 17 16:34:28 http://www.diskohq.org/ Nov 17 16:34:44 currently looking at it Nov 17 16:35:55 interesting Nov 17 16:35:58 JaMa: ok, I'll take a look later Nov 17 16:36:04 hi woglinde Nov 17 16:36:13 woglinde: Do I remember rightly that you use uclibc in OE? Nov 17 16:36:19 rp right Nov 17 16:36:31 woglinde: I have some improvements to the uclibc recipes in poky Nov 17 16:36:43 I have some patches in the queue for beagle demo board image Nov 17 16:36:46 woglinde: Part of my removal of do_stage Nov 17 16:36:49 zecke: gosh, you are up early Nov 17 16:36:53 mostly build patches Nov 17 16:37:18 pb_: haeh? I'm in iceland :) Nov 17 16:37:18 woglinde: I was wondering if you fancied testing my changes to it? Nov 17 16:37:32 pb_: but yeah... I was awake at 6am local time Nov 17 16:37:43 zecke: ah, heh, I thought you were still in taipei Nov 17 16:38:03 pb_: no, visiting On-Waves here in iceland... and I tried to get a visa for india... :( Nov 17 16:38:22 rp surew Nov 17 16:38:26 send me the patch Nov 17 16:38:32 woglinde: will do, thanks Nov 17 16:38:36 or give the url to download it Nov 17 16:38:41 rp ypu can send it khem too Nov 17 16:39:27 jo zecke Nov 17 16:39:30 woglinde: will do Nov 17 16:41:33 zecke: oh right, very good Nov 17 16:43:14 zecke: enjoy your trip ... Nov 17 16:45:32 hm which git recpie is in new fromat? Nov 17 16:45:35 ups format Nov 17 16:47:41 hm ah inherit git_version Nov 17 16:47:48 Is xkbd problematic with touchscreens? Nov 17 16:47:50 args gitver Nov 17 16:48:04 hm Nov 17 16:48:05 I've been trying to fix xf86-input-tslib for the whole day Nov 17 16:48:34 xev only reports one ButtonPress and one ButtonRelease event Nov 17 16:48:49 With MotionEvent(s) in between Nov 17 16:49:02 Is that about right? Nov 17 16:49:15 B_Lizzard, mmm what version? the last one 0.6.0 ? Nov 17 16:49:30 xf86-input-tslib? Nov 17 16:49:36 It's at version 0.0.6 Nov 17 16:49:52 ah sorry I remember badly Nov 17 16:50:06 B_Lizzard, is it because of that that you can't calibrate with Xorg? Nov 17 16:50:14 See, when I type with xkbd (which seems to be the default on GPE), it outputs 2 or more chars Nov 17 16:50:21 s/is it because of that/did you also had the problem Nov 17 16:50:31 Only with the slightest and fastest touch it doesn't. Nov 17 16:50:32 mmm Nov 17 16:51:05 But xev works properly. Nov 17 16:51:07 :/ Nov 17 16:51:43 gnutoo: You had the same problem? Nov 17 16:52:08 B_Lizzard, doubble-touch instead of one? Nov 17 16:52:17 Yeah Nov 17 16:52:35 B_Lizzard, I had the problem with kdrive....I fixed it in the kernel... Nov 17 16:52:52 B_Lizzard, so maybe my fix was wrong then Nov 17 16:52:52 kdrive crashes for me, xorg works well... Nov 17 16:53:00 B_Lizzard, machine = htcdream Nov 17 16:53:31 I have no idea, my idea is that xkbd is retarded Nov 17 16:55:36 B_Lizzard, I had the issue with every program...like the SHR/illume calculator for instance Nov 17 16:57:01 I'll test and see... tslib works well in OPIE and ts_test, so it's not the kernel or tslib Nov 17 16:57:27 It's either X, xf86-input-tslib or xkbd itself Nov 17 16:59:32 B_Lizzard, do you have a calculator? Nov 17 16:59:43 to try another software than xkbd Nov 17 16:59:47 I'll test with gcalculator Nov 17 16:59:56 B_Lizzard, ok Nov 17 16:59:59 Although I didn't have any problems navigating through GPE Nov 17 17:00:52 B_Lizzard, in htc-linux someone(leviathan) didn't even notice a doubble-click problem with the touchscreen because all the apps he used were ok if you double-clicked Nov 17 17:01:09 so it may be the same here Nov 17 17:01:18 Could be Nov 17 17:01:59 But since xev reports only one ButtonPress, I am inclined to believe that xkbd is retarded Nov 17 17:05:12 hm ah disko people where at elc too Nov 17 17:15:06 i love you, git-filter-branch Nov 17 17:15:23 bbl Nov 17 17:15:26 filter? Nov 17 17:15:56 awesome tool for rewriting history. can modify messages, filter out commits, changes parents, remove files from the history, pretty much anything you want Nov 17 17:16:19 a plain 'git filter-branch' with a .git/info/grafts will rewrite the commits to apply the grafts permanently Nov 17 17:16:23 ♥ Nov 17 17:19:03 hm oh Nov 17 17:19:22 Agh, unicode, my eeeyes! Nov 17 17:19:29 * kergoth cackles Nov 17 17:35:22 so Nov 17 17:35:26 disko runs again Nov 17 17:35:35 unicode for the best Nov 17 17:36:26 arg, stupid oddball md5 issue.. no idea whats causing it Nov 17 17:37:26 kergoth: heh, did you check for rootkits already? Nov 17 17:37:51 it sounds like your customers got 0wn3d by the nsa Nov 17 17:39:30 heh :\ Nov 17 17:40:40 what exactly are the symptoms of that problem, is it that you get the wrong md5sum but the right sha256sum for some/all files? Nov 17 17:41:13 hm SDL-mixer? Nov 17 17:41:25 processor bug? Nov 17 17:41:27 rambug? Nov 17 17:41:52 sdl-mixer?! never heard of that causing md5sum failures before, though I guess anything is possible. Nov 17 17:42:28 this guys mandriva box's md5sum binary is giving him 4f65a28c5e51760fb5fc4549d8a6d1a7 for cpio-2.8.tar.gz, but the bb.utils.md5_file on that same box gives 0caa356e69e149fb49b76bacc64615a1 for that file Nov 17 17:42:39 on my machine, debian, i get 0caa356e69e149fb49b76bacc64615a1 for coreutils md5sum, textutils md5sum, and bb.utils.md5_file Nov 17 17:42:49 fun stuff, eh? Nov 17 17:43:19 yeah Nov 17 17:43:33 kergoth can you check SDL-mixer too Nov 17 18:04:31 RP: I'm talking a look at the latest core changes that went at OE, to be able to build mamona with latest oe changes Nov 17 18:04:46 using bitbake 1.8.18 Nov 17 18:05:13 at the beginning of the build I saw and invalid copy when building quilt-native and went to look at the code Nov 17 18:05:58 I saw that's calling sysroot_stage_dirs ${D} ${SYSROOT_DESTDIR} Nov 17 18:06:41 but here the SYSROOT_DESTDIR is the full path of the quilt-native sysroot-destdir directory Nov 17 18:07:42 when calling the stage_dirs, it'll append STAGING_INCDIR into the destination folder Nov 17 18:08:10 but then my final path is an invalid one, as it'll be a huge path, and not what it should be Nov 17 18:09:11 an example: /home/rsalveti/projects/oe/build/mamona-ov-test/tmp/beagleboard/default/work/x86_64-linux/quilt-native-0.48-r0/sysroot-destdir//home/rsalveti/projects/oe/build/mamona-ov-test/tmp/beagleboard/default/staging/x86_64-linux/usr/bin Nov 17 18:09:21 this is just the destination directory Nov 17 18:09:51 is STAGING_INCDIR valid here? or am I doing something wrong with my env? Nov 17 18:11:46 will continue looking into this Nov 17 19:15:42 re Nov 17 19:22:14 florian: wb Nov 17 19:27:53 ugh, the mismatched cpio-2.8 tarball seems to be due to upstream Nov 17 19:28:18 they re-created the tarball with the same content, but different gzip name/timestamp info. ungzipping both versions of the tarball and re-gzipping with gzip -n results in identical md5sums Nov 17 19:28:28 so was just a dumbass upstream problem, thankfully Nov 17 19:28:43 if we ever bring together fetch/unpack, it may be worth md5summing the tar content, ignoring the gzip around it Nov 17 19:29:53 alternatively, could store the md5sum of the unpacked tarball in a cache to be used for subsequent builds, instead of operating against the original fetched bits Nov 17 19:30:01 but that too would be a long term possibility to consider Nov 17 19:30:04 not now :) Nov 17 19:32:27 kergoth: oh, right. how come you got the right checksum when using bb.utils.md5_file on the offending box then? Nov 17 19:33:14 didn't, it just turned out that we had a bunch of different download dirs on a variety of boxes floating around, and people with different builds, some using md5_file, some not Nov 17 19:33:22 ah, I see Nov 17 19:33:23 * kergoth should have caught this sooner, went in the wrong direction with it Nov 17 19:33:23 heh Nov 17 19:33:36 of course itd be something stupid and obvious like upstream being idiots Nov 17 19:33:39 :) Nov 17 19:33:53 checksumming the tarball after uncompressing is an interesting idea, might have some merit. but then, you still might find that it gets repacked with a different tar. Nov 17 19:34:08 not quite sure where you'd draw the line with that approach Nov 17 19:35:00 i could see checksumming the tree it creates, more along the lines of what i was mulling over about moving fetch/unpack around or up into a project tool, tracking the states of the tree with git Nov 17 19:35:23 but nothing worth messing with anytime soon Nov 17 19:35:37 yeah Nov 17 19:36:01 ah well Nov 17 19:36:03 * kergoth gets food Nov 17 20:05:14 ok Nov 17 20:05:23 sorry, wrong window :) Nov 17 20:35:08 03Henning Heinold  07org.openembedded.dev * rcbe3df9e56 10openembedded.git/recipes/python/python-pygtk_2.10.4.bb: Nov 17 20:35:08 python-pygtk: fix staging for codegen with right prefix Nov 17 20:35:08 * bump PR Nov 17 20:35:09 03Henning Heinold  07org.openembedded.dev * r15a4fcd359 10openembedded.git/conf/distro/micro.conf: micro.conf: use prefix_native and prefix_exec_native Nov 17 20:35:10 03Henning Heinold  07org.openembedded.dev * rf001d149f3 10openembedded.git/recipes/gnome/ (goffice/c99math.patch goffice_0.7.14.bb): Nov 17 20:35:13 goffice: make buildable for uclibc Nov 17 20:35:15 * libgoffice uses isfinite for uclibc this stdc99 so let autotools check it Nov 17 20:35:17 * bump PR Nov 17 20:35:19 03Henning Heinold  07org.openembedded.dev * rc1a048acf3 10openembedded.git/conf/distro/micro.conf: micro.conf: let gtk+ provide gail Nov 17 20:35:22 03Henning Heinold  07org.openembedded.dev * rd177641f44 10openembedded.git/ (6 files in 4 dirs): Nov 17 20:35:25 disko: update git and make recipe for version 1.6.0 Nov 17 20:35:27 * remove linkpath.patch not needed anymore Nov 17 20:35:29 * convert disko_git to new style and add sanesrcvrev into the right file Nov 17 20:35:31 * license now LGPL Nov 17 20:35:33 03Henning Heinold  07org.openembedded.dev * rcaba33c088 10openembedded.git/recipes/pam/libpam_1.0.2.bb: libpam: fix building for uclibc Nov 17 20:35:41 03Henning Heinold  07org.openembedded.dev * r4205bee61e 10openembedded.git/conf/distro/micro.conf: micro.conf: use latest preferred xorg version Nov 17 20:35:43 03Henning Heinold  07org.openembedded.dev * r406cd0fee1 10openembedded.git/recipes/efl1/ (4 files in 2 dirs): ecore: fix building for uClibc Nov 17 20:41:44 RP still there? Nov 17 20:41:49 Henning Heinold: ping? Nov 17 20:42:02 jama yes Nov 17 20:42:21 some problems? Nov 17 20:42:22 woglinde: SRCPV should have gitr prefix Nov 17 20:42:30 args Nov 17 20:42:37 did I overlook it again Nov 17 20:42:39 hms Nov 17 20:42:44 sorry Nov 17 20:42:48 will fix it asap Nov 17 20:43:02 woglinde: and shouldn't be used before bitbake changes imho.. Nov 17 20:43:13 woglinde: or you make koen angry... :) Nov 17 20:43:13 PV = "1.6.1+gitr${SRCPV}" Nov 17 20:43:22 jama lol Nov 17 20:43:26 woglinde: stay with SRCREV.. Nov 17 20:43:27 I made koen this much angry Nov 17 20:43:46 ah okay Nov 17 20:43:57 woglinde: SRCPV change for disko is in prepared in srcpv branch as well for other recipes.. Nov 17 20:44:02 PV = "1.6.1+gitr${SRCREV}" than Nov 17 20:44:11 woglinde: one less conflict for me later :) Nov 17 20:44:19 right? Nov 17 20:44:32 right Nov 17 20:46:18 03Henning Heinold  07org.openembedded.dev * r0b1f9398d0 10openembedded.git/recipes/disko/disko_git.bb: disko-git: fix package name, was to early for the change Nov 17 20:55:26 heh, maybe we should follow the example of the glibc wiki and add a "do not taunt koen" warning to the oe documentation Nov 17 20:56:06 pb__ whats it on glibc drepper? Nov 17 21:06:39 woglinde: yeah, you can google for "happy fun drepper" Nov 17 21:06:44 is there someone from jalimo project? or at least someone with good java overview in OE? Nov 17 21:06:56 jama your lucky day Nov 17 21:06:58 ask me Nov 17 21:07:40 re kergoth Nov 17 21:09:21 pb__: It wasn't tounting.. I used his name just as pointer to this e-mail.. http://thread.gmane.org/gmane.comp.handhelds.openembedded/27671/focus=27698 Nov 17 21:10:16 jama so what you want to know about java Nov 17 21:10:21 JaMa: yeah, don't worry, I was just referring to woglinde saying that he "made koen this much angry" Nov 17 21:19:06 woglinde: hi Nov 17 21:20:10 rsalveti: That path my be huge but its correct Nov 17 21:22:05 rsalveti: Remember its a native binary so it installs to "/" and has a long path. Combine that with the DESTDIR path and you have what you pasted Nov 17 21:22:06 RP: hm, ok, but why do you need the full path again inside the sysroot-destdir directory? Nov 17 21:23:00 oh, ok, basically because of the native stuff Nov 17 21:23:29 rsalveti: yes, look at what prefix is for native recipes Nov 17 21:23:31 yeah, saw that the autotools_stage_all calls it giving a empty var Nov 17 21:23:44 guess I got the idea Nov 17 21:23:58 rsalveti: I appreciate its a change from what we used to do Nov 17 21:24:05 rp for the uclibc why you changed the the runtimpath for inital? Nov 17 21:24:27 RUNTIME_PREFIX=/ instead of RUNTIME_PREFIX=${UCLIBC_STAGE_PREFIX}/ Nov 17 21:25:09 woglinde: I changed it since we're using a sysroot and our runtime is / Nov 17 21:25:18 hm ah okay Nov 17 21:25:38 wasnt aware that sysroot reacts like chroot Nov 17 21:25:40 woglinde: I copied do_install from uclibc.inc Nov 17 21:25:51 woglinde: and then checked everything did what I expected which it seemed to Nov 17 21:25:57 yeah okay Nov 17 21:26:32 woglinde: I could be wrong though :) Nov 17 21:26:42 did you test something? Nov 17 21:26:52 hoi robert Nov 17 21:27:09 woglinde: I tested some simple apps built Nov 17 21:27:21 woglinde: (and the toolchain) Nov 17 21:27:51 RP: yeah, got it, that's why the TMPDIR is actually empty Nov 17 21:27:56 RP: thanks, sorry for the noise Nov 17 21:28:17 rsalveti: np Nov 17 21:28:20 it's just because I saw a couple of invalid cp commands during the build Nov 17 21:28:38 but guess that's ok because the image directory is empty Nov 17 21:31:56 rsalveti: We should really silence that Nov 17 21:32:11 rsalveti: but it should be harmless Nov 17 21:33:13 RP: yep Nov 17 21:40:20 hmm Nov 17 21:40:28 the helloworld example is a litlte out of date Nov 17 21:40:43 you should update it then ;) Nov 17 21:40:44 user_collection/recipes is the place now, not packages Nov 17 21:40:49 kergoth: I will, once I figure it out :) Nov 17 21:40:57 excellent. Nov 17 21:41:02 but it wants to unpack, and hteres' no need to Nov 17 21:41:27 what do you mean? Nov 17 21:41:33 it will "unpack" everything in SRC_URI Nov 17 21:41:37 for file:// uris, it just copies it into workdir Nov 17 21:42:24 ahh, I had something wrong in there Nov 17 21:42:38 :) Nov 17 21:44:05 so should I Have my sources in user.collection/packages/mypackagename/ or recipes? Nov 17 21:44:42 bitbake and oe don't care where it is, technically, its just convention. recipes/ is used rather than packages/ to better reflect its contents, and avoid source vs binary confusion Nov 17 21:45:40 okay Nov 17 21:46:10 and is there something magical I can use with non-packaged stuff (i.e. just file:// urls so that when I modify the code in recipes/mypackage/foo.c (for example) it will copy it over to the work dir again? Nov 17 21:46:20 I changed it and reran bitbake but it didn't notice Nov 17 21:46:30 and used the old very in the work dir Nov 17 21:46:33 no, bitbake uses stamps to deal with whether tasks need to be run, it doesn't look at content Nov 17 21:46:43 you can force the re-unpack with bitbake -c unpack -f foo Nov 17 21:46:50 then the subsequent tasks will re-run if you bitbake foo after that Nov 17 21:47:01 -f == force Nov 17 21:47:09 hmm okay, gotta learn this stuff :-) Nov 17 21:47:26 pretty sure the bitbake manual shows -f, not sure about the OE manual offhand Nov 17 21:47:37 the timestamp should have changed though Nov 17 21:47:47 what do you mean? Nov 17 21:48:04 vi user.collection/recipies/myfoo/foo.c Nov 17 21:48:09 bitbake uses stamp *files*, again, it doesn't care about the content. when a task completes, it creates a file indicating that task is done Nov 17 21:48:10 then rerun bitbake myfoo Nov 17 21:48:17 oh stamp files, not timestamps Nov 17 21:48:19 yep Nov 17 21:48:24 duh me Nov 17 21:48:27 ok. thanks :-) Nov 17 21:48:33 its like make, only the task names don't automatically map to filenames, the two are separated Nov 17 21:49:00 handling individual files can be painful, it requires in depth knowledge of the underlying buildsystem Nov 17 21:49:20 bitbake doesn't replace make or other buildsystems like that, it sits above them, so lacks the intimate details of what they're doing Nov 17 21:51:00 *nods* Nov 17 21:51:29 i am trying to build x11-image for zoom2 using openembedded. I did basic build and it worked fine. Now i am trying to add some packages to it and trying to rebuil the new image. I added name of packages to x11-image.bb file in receipes/image and restarted the build process using bitbake x11-image commang. But I am getting some sort of parsing error. http://pastebin.com/m3e66ca8d Nov 17 21:52:18 tzanger: i kind of regret that behavior, because knowing those details would really improve traceability, but the complexity would be crazy :) Nov 17 21:53:05 Down to 39 recipes using legacy staging in core poky now. This is where the pain starts :/ Nov 17 21:53:14 * RP has ignored perl and python so far Nov 17 21:53:19 yikes Nov 17 21:53:20 good luck Nov 17 21:53:22 :) Nov 17 21:54:13 kergoth: The stagemanager-native recipe is also a puzzle :} Nov 17 21:54:42 kergoth: It installs into staging from its do_install which its kind of allowed to do :/ Nov 17 22:08:41 ok, another dumb question... I see it's creating ipk files for me... is there some way short of ar x and tar -xzvf'ing the ipk to get the one file I want? Nov 17 22:09:27 yes, use MC Nov 17 22:11:20 # ar library Nov 17 22:11:20 regex/\.(s?a|ipk|opk)$ Nov 17 22:11:20 <------>Open=%cd %p#uar Nov 17 22:11:20 <------>#Open=%view{ascii} ar tv %f Nov 17 22:11:20 <------>View=%view{ascii} file %f && nm %f Nov 17 22:11:35 in mc/bindings Nov 17 22:11:43 (thx zecke for the hint :) Nov 17 22:12:11 heh yes I guess I could use mc as well, but is there a way to tell bitbake not to get rid of the build/staging directory when it's done? Nov 17 22:12:47 hm..not that I'm aware. you can rm_work, though Nov 17 22:14:32 amitshah08, it is parsing for me ok Nov 17 22:19:56 RP: heh. I think I'd just move it to do_install, but zero out PACKAGES, so it does the usual staging bits now, but doesn''t emit target packages either Nov 17 22:21:07 * kergoth ponders Nov 17 22:25:08 sRP: just a quick update about BB_DEFAULT_TASK = "buildall". Still doing same things as before ? Nov 17 22:25:18 RP:^^ Nov 17 22:35:26 goddamn, i forgot how long the parse time is with all of OE Nov 17 22:40:32 * pb__ hands kergoth a better computer Nov 17 22:40:41 heh :) Nov 17 22:41:40 though yeah, it is a bit of a pain: whenever I have to touch local.conf I generally go and get a coffee while it re-parses. Nov 17 22:43:04 this was one of the issues that motivated mickey's "splitting the tree" session at oedem, although we didn't really arrive at any concrete conclusion with that. Nov 17 22:43:34 that'll be a good thing, definitely a start Nov 17 22:44:13 yeah. iirc, the way we left that discussion was that we needed to do a bit of study on how many files would be removed by different categories of splitting, and then try and come up with a list of plausible candidates. Nov 17 22:45:27 for example, there seem to be 721 opie-*.bb files which I could happily do without. that's about 10% of the total already. Nov 17 22:45:37 yow, i had no idea there were that many Nov 17 22:46:07 yah, and presumably there are at least a few "stealth" opie files whose names don't actually start with "opie" Nov 17 22:46:29 i did a bitbake glibc -c clean and now can't rebuild glibc... :( is there another package or two i can clean in order to rebuild things successfully, or do i need to rebuild my whole tree? Nov 17 22:47:01 (this is on a working tree, upstream changes haven't broken it) Nov 17 22:47:08 grg: what's the error you are seeing? Nov 17 22:47:11 grg: glibc-initial Nov 17 22:47:33 i get told that the compiler can' Nov 17 22:47:40 t create executables Nov 17 22:47:53 JaMae, cheers, thats probably it Nov 17 22:47:55 that is rather funky. I guess that must be a packaging bug. Nov 17 22:48:07 cleaning glibc certainly shouldn't cause that effect. Nov 17 22:49:18 pb__: it happens every time for me.. the same for gcc chain of initial/cross/target Nov 17 22:49:52 yeah, there is a known defect with gcc-* which makes selective rebuilds rather difficult. Nov 17 22:50:24 but, I haven't previously heard of anything being wrong with glibc in that respect. Nov 17 22:50:28 what does config.log say? Nov 17 22:50:48 sorry, too late. its gone Nov 17 22:50:53 I have seen this before... Nov 17 22:51:48 pb__: I do not remember exactly... but I tkink it fails to find some essential header. Nov 17 22:52:18 that would make sense Nov 17 22:52:23 This happened for both glibc and eglibc and goes away if you clean the rest of the toolchain Nov 17 22:52:32 configure: error: C preprocessor "mipsel-angstrom-linux-gcc -E" fails sanity check Nov 17 22:53:01 and it happens with arm too Nov 17 22:54:03 no, wait. i do still have the config.log... Nov 17 22:54:42 http://pastebin.com/m656e8b6d Nov 17 22:55:40 crt1.o is missing too... that could cause issues Nov 17 23:06:01 oh, are you using packaged-staging? Nov 17 23:06:09 I guess this would certainly happen if you have that enabled. Nov 17 23:06:31 errr, maybe... what's packaged-staging? Nov 17 23:07:06 it's a class. you can INHERIT it manually, or your DISTRO might do that for you. Nov 17 23:07:37 do you see bitbake printing messages like "Removing staging package ..."? Nov 17 23:08:25 yep, angstrom is pulling that in and i do see those messages Nov 17 23:08:35 ah right, that would explain it then Nov 17 23:08:59 in that case, yeah, you probably have to rebuild glibc-initial first. Nov 17 23:09:31 nah, i need to rebuild the whole toolchain. glibc-initial wont build either Nov 17 23:09:56 ah, probably best to just wipe TMPDIR and start over in that case. Nov 17 23:10:01 i've cleaned gcc-cross* and binutils too... hoping that will work Nov 17 23:10:29 but doing a whole build will not finish on this machine until.... this time tomorrow Nov 17 23:11:07 crumbs. what are you building? Nov 17 23:11:40 its based upon gpe-image, plus or minus a few packages Nov 17 23:11:55 takes 18-20 hours Nov 17 23:12:22 but if i'm working on the machine all day, it'll be longer Nov 17 23:12:28 gosh, gpe-image must have gotten big since I tried it last. I thought it was closer to 6 hours to build that. Nov 17 23:12:46 well that depends on your build hardware Nov 17 23:13:15 pb__: gpe-mini-browser2 pulls in webkit and this takes ages to build. Nov 17 23:13:26 florian: oh, right. that would probably explain it. Nov 17 23:13:28 yes, webkit is nasty Nov 17 23:13:37 x11-gpe-image is smaller ans faster to build Nov 17 23:13:46 it gets linked 3 times for some reason Nov 17 23:13:51 * florian needs to clean this up some time Nov 17 23:14:05 but first some sleep Nov 17 23:14:08 each time using 75% of my 1gb ram Nov 17 23:14:13 good night! Nov 17 23:14:19 bye Nov 17 23:21:46 just setting things up... "bitbake nano" => "ERROR: Nothing PROVIDES 'nano'" ; what did I do wrong? Nov 17 23:28:12 sounds like BBPATH is wrong Nov 17 23:28:38 ant__: There should have been no change Nov 17 23:29:43 ok, thx. I have it in my local.conf Nov 17 23:29:56 iirc I added it to have all deps in my feeds Nov 17 23:30:03 was that the purpose? Nov 17 23:30:23 or am I misusing it? Nov 17 23:41:27 Does "inherit native" mean any existing DEPENDS will get rewritten to get -native? Nov 17 23:42:26 DEPENDS="zlib"; inherit native means DEPENDS="zlib-native" ?? Nov 17 23:55:46 ant__: no sure... Nov 17 23:56:11 likewise: no, that code only happens if you use BBCLASSEXTEND = "native" Nov 17 23:56:18 ant__: not sure Nov 18 00:02:27 406cd0fee12ad99ba6d6f7d55f743cc4c6697955 is breaking ecore compile on eglibc ld: cannot find -liconv Nov 18 00:46:16 Hmm, 18 perl/python references, kernel.bbclass and 7 "other" Nov 18 00:48:29 * kergoth thinks that variable expansion based python-native check should die in a fire Nov 18 00:50:30 kergoth: ? Nov 18 00:50:59 good nite all Nov 18 00:51:22 pls ack my patches before sun rise. Thank you all :-) Nov 18 00:51:23 there's a variable that points to a path in staging that only exists if python-native was built, and it freaks out and errors if it hasn't been at the time of its expansion Nov 18 00:51:28 hack, at best Nov 18 00:51:47 kergoth: ah, I think I've come accross that before Nov 18 00:53:08 its too implicit, and assumes that there's never a reason to expand that variable that isn't a build.. which can be a flawed assumption in the case of the execution of other tasks than parts of the compilation process.. Nov 18 00:53:55 kergoth: Its interesting to try expanding some of these in the parser Nov 18 00:54:12 kergoth: bitbake -e just ignores expceptions but if it didn't... Nov 18 00:54:19 * kergoth nods Nov 18 00:54:45 speaking of which, we should really add an option to emit user requested variables only Nov 18 00:54:51 i often have to advise people to bitbake -e | grep ... Nov 18 00:55:21 JaMa: Same problem here. ld cannot find -liconv Nov 18 00:55:24 kergoth: Should they be using a build system if they can't use grep? :) Nov 18 00:55:39 the point is, the grep isn't likely to be correct Nov 18 00:55:46 grep FOO= will often catch segments of functions Nov 18 00:55:53 grep ^FOO= fails for 'export'ed variables Nov 18 00:55:57 kergoth: and then there is export= Nov 18 00:56:00 right Nov 18 00:56:16 kergoth: It'd be nice to add something, I agree Nov 18 01:00:31 hmm, Is there a command to summarise a diff into number of files added/deleted? Nov 18 01:00:39 (and changed) Nov 18 01:00:59 git format-patch? Nov 18 01:01:25 git's diff-tree/log accept --stat, --shortstat, etc. regular patch, there's diffstat, iirc Nov 18 01:01:35 quilt can be configured to automatically add it when refreshing, also Nov 18 01:01:45 yeah, its diffstat Nov 18 01:01:56 cat foo.patch | diffstat, diffstat foo bar Nov 18 01:02:30 * kergoth has 'QUILT_REFRESH_ARGS="--no-timestamps --no-index --backup --diffstat"' in his ~/.quiltrc Nov 18 01:02:57 kergoth: That doesn't actually give a summary of the file counts though :/ Nov 18 01:02:57 kergoth: I'll just do that manually I guess Nov 18 01:03:08 oh, right, hmm Nov 18 01:03:23 * ant__ gets k.o. by a BLKGESIZE: Not a typewriter ...better to retire...nite Nov 18 01:04:14 * RP is trying to quantify how much code was removed from poky with the staging changes Nov 18 01:04:29 RP: git show/log/diff-tree --dirstat-by-file looks promising Nov 18 01:05:04 i guess outside of git would have to be manual, afaict Nov 18 01:05:20 kergoth: Thankfully its in git :) Nov 18 01:05:31 interesting, dirstat-by-file shows % modified Nov 18 01:05:47 wonder what it shows for removals Nov 18 01:06:14 oh, damn, that doesn't help Nov 18 01:06:15 hrmph Nov 18 01:06:16 * kergoth gives up Nov 18 01:07:16 kergoth: I think my git version is out of date too :} Nov 18 01:08:05 Anyhow, 72 .bb/.in files removed, mostly -native and -sdk Nov 18 01:08:31 I can't get the stats on how many lines I deleted as I moved patch directories around during this :/ Nov 18 01:08:55 :\ Nov 18 01:09:18 git log --summary shows deletions/additions, but not modifications Nov 18 01:09:23 shows 'delete' and 'create' lines for each file Nov 18 01:10:06 cute, summary'll show renames too, if it knows about them, anyway. rename {.sh => .zsh}/dontdiff (98%) Nov 18 01:10:14 learn something new about git every week, i swear Nov 18 01:10:17 ah, but I need the -M option to git diff Nov 18 01:10:37 So I changed about 4,000 lines and removed 50% of them Nov 18 01:10:53 sheesh Nov 18 01:13:54 Too much noise in these numbers but that is about right... Nov 18 01:15:05 Anyhow, time for sleep **** ENDING LOGGING AT Wed Nov 18 03:00:03 2009