**** BEGIN LOGGING AT Wed Sep 05 02:59:56 2007 Sep 05 06:36:43 I need some help getting started with oe to work on multiple configuration and switch between them. Sep 05 07:00:01 morning Sep 05 07:14:53 berbs: what means ' multiple configuration '? Sep 05 07:15:25 ho all Sep 05 07:16:44 a couple of days ago i try to build a angstrom-2007.1-legacy image but it came out with a 2.6 kernel ... why ??? Sep 05 07:26:01 because legacy is not done Sep 05 07:26:13 it was idea to have such one but no one work on it Sep 05 07:28:44 ohhh :( ... really bad ... mainly i need to build an image with a 2.4 kernel , there is any way ? Sep 05 07:29:43 I set MACHINE_KERNEL_VERSION = "2.4" but seem to be ignored ... :( Sep 05 07:30:40 MACHINE_KERNEL_VERSION was used only by few machines Sep 05 07:30:54 now I do not know does any use it (oter then collie) Sep 05 07:31:02 ohhhh :( . Sep 05 07:32:26 can i try to override PREFERRED_VERSION_kernel or PREFERRED_PROVIDERS = "virtual/kernel:kernel-2.4something" ? Sep 05 07:34:03 you can - in machine config Sep 05 07:34:19 not il local.conf ? Sep 05 07:34:33 machine config will overwrite it Sep 05 07:34:36 hi Dirk Sep 05 07:34:37 morning all Sep 05 07:34:42 hi marcin Sep 05 07:34:44 ahh ok thanks hrw ! Sep 05 07:38:25 np Sep 05 07:43:22 argh.. how much ram I need to have to really use desktop when bitbake builds.. Sep 05 07:45:14 Use seperate machines :) Sep 05 07:46:22 at home with 3Gbyte i don't suffer (gnome desktop) :D Sep 05 07:48:39 anyone know how to do what I want to happen when I type "mtn update --dry-run"? Sep 05 07:48:57 ie I want to see what's about to break before it breaks when I mtn update Sep 05 07:50:23 do13: my laptop is other machine as is busy wit other build Sep 05 07:50:52 hughescr: I used two trees for it ;) Sep 05 07:51:35 hrw: set your /proc/sys/vm/swappiness way high, then ionice your bitbake to super-low priority Sep 05 07:52:02 hrw: I'd use two trees if each tree wasn't 200MB! Sep 05 07:52:14 200MB is nothing :p Sep 05 07:52:19 there's seriously no "-n" or "--dry-run" option? Sep 05 07:52:52 200MB here, 200MB there, pretty soon you're talking about real storage Sep 05 07:53:04 what have such '--dry-run" option? Sep 05 07:54:06 maybe you can create 2 branches, mtn update to one and then merge both Sep 05 07:56:50 reading docs, it could be possible using diff command Sep 05 07:59:12 I don't want to see the full diffs, just what's going to get updated, what's going to have conflicts Sep 05 08:00:30 ie what "cvs update -n" or "svn status -u" gives Sep 05 08:00:55 Looking under "mtn list" looks like it's not there either Sep 05 08:06:23 03rpurdie * r970 10/ (6 files in 4 dirs): fetch: Add bzr fetcher Sep 05 08:19:19 morning Sep 05 08:19:37 hi XorA Sep 05 08:19:59 hey do13 Sep 05 08:21:04 Already in your new job? Sep 05 08:22:07 do13: not yet Sep 05 08:22:17 do13: I leave Wolf end of this month Sep 05 08:22:28 ok Sep 05 08:29:06 good morning Sep 05 08:32:49 aha mtn show_conflicts looks likely Sep 05 08:36:04 RP: koen there is a bug in do_install in generate rm -rf ${D} is inserted between do_install_prepend and do_install Sep 05 08:36:17 making do_install_prepend a useless op, but is used a lot in meta data Sep 05 08:37:00 hughescr: thx for hint Sep 05 08:38:21 XorA: ick :/ Sep 05 08:38:48 gm Sep 05 08:38:53 RP: seems to be new since you guys merged poky stuff Sep 05 08:39:14 XorA: Yes, it solved a number of issues when rerunning install in poky Sep 05 08:39:32 RP: needs to be in front of do_install_prepend though :-) Sep 05 08:39:56 XorA: How do we arrange that though? :/ Sep 05 08:40:04 RP: a quick recipe that shows the problem is pspash Sep 05 08:40:10 psplash Sep 05 08:41:56 I wonder if we should add a cleandirs flag for tasks? Sep 05 08:42:48 Im afraid my brain isnt working beyond finding the bug yet, must be time for tea Sep 05 08:43:54 hello Sep 05 08:49:16 03rpurdie 07org.oe.dev * r020488f3... 10/ (1 classes/image.bbclass conf/bitbake.conf): bitbake.conf/image.bbclass: Set IMAGE_BASENAME to a better default and export correctly, add BZR fetcher config (from poky) Sep 05 08:49:23 03xora 07org.oe.dev * r1ffb54e7... 10/ (1 packages/xorg-xserver/xserver-kdrive-imageon_1.2.0.bb): Sep 05 08:49:23 xorg-xserver/xserver-kdrive-imageon_1.2.0.bb : build Ximageon Sep 05 08:49:23 Is a good idea when we go to all the hassle of patching in Ximageon to Sep 05 08:49:23 actually send --enable-imageon to configure :-) Sep 05 08:52:38 RP: the .bb do_install_prepend just needs to be added after the one in base.bbclass not before? Sep 05 08:53:19 XorA: It won't help Sep 05 08:53:55 XorA: Anyhow, you can't do things before base.bbclass... Sep 05 08:54:40 RP: currently there are 30 broken recipes Sep 05 08:55:16 XorA: Remove the entry from base.bbclass and replace it with do_install[cleandirs] = "${D}" Sep 05 08:55:34 XorA: Future bitbake versions will implement that Sep 05 08:57:08 XorA: (or I'll do it shortly) Sep 05 09:00:15 RP: replace the do_install_prepend? Sep 05 09:00:48 XorA: yes Sep 05 09:00:54 RP: ok, doing now Sep 05 09:01:38 03rpurdie * r971 10/ (4 files in 4 dirs): build.py: Add support for cleaning directories before a task in the form: do_taskname[cleandirs] = 'dir' Sep 05 09:06:05 moin Sep 05 09:06:13 hi zecke Sep 05 09:06:17 hey Sep 05 09:06:28 the day starts very well... Sep 05 09:08:37 WTF, why did akita build no hostap Sep 05 09:09:00 XorA: I just checked the change into poky too Sep 05 09:10:27 RP: before mallum complains his shiney spash doesnt work :-) Sep 05 09:18:21 * Bernardo is away: Ausente por agora. Sep 05 09:23:22 03xora 07org.oe.dev * r13890ee4... 10/ (1 classes/base.bbclass): Sep 05 09:23:22 classes/base.bbclass : change to make sure ${D} gets removed before Sep 05 09:23:22 do_install_prepend. Will activate in a future bitbake version. Sep 05 09:23:22 do_install_prepend became do_install[cleandirs] = "${D}" Sep 05 09:29:53 XorA: ;-) Sep 05 09:30:24 NOTE: package webkit-gtk-0.0+svnrwebcore-rwebkit: started Sep 05 09:30:26 koen: ? Sep 05 09:32:09 stefan_schmidt: got a second as well? Sep 05 09:32:26 hrw: oh Sep 05 09:32:43 zecke: yeah, what's up? Sep 05 09:34:47 SRCREV_FORMAT = "webcore-rwebkit" Sep 05 09:36:20 thats wy Sep 05 09:40:43 hi florian Sep 05 09:41:34 so reading more in the monotone info pages.... looks like monotone's suggestion is "you should never update in a workspace with local modifications. You should always commit first, then merge, then update Sep 05 09:42:17 hughescr: local modifications can break update if updated metadata touch same files Sep 05 09:42:38 hrw: ? Sep 05 09:43:31 hughescr: you added packages/umbaumba/umbaumba_17.5.bb locally. I added it too and pushed into server. you do pull/update and monotone will not update because you have that file already Sep 05 09:43:50 hughescr: you will have to rename file, do update, compare with my version Sep 05 09:44:41 hrw: does that problem vanish if I can mtn sync instead of submitting patches through the bug tracker? ie just submit my mtn server's address, and an mtn revision ID? Sep 05 09:45:17 hughescr: we do not support such way Sep 05 09:45:19 or not sync, but if you can mtn pull from me Sep 05 09:46:15 hughescr: we do not support non-OE servers Sep 05 09:47:56 hughescr: investigate OVERLAYS, they work well for this situation as you dont do dev in main tree Sep 05 09:48:22 not overlays but collections ;D Sep 05 09:48:35 hrw: bloody terminology :-) Sep 05 09:49:48 overlays/collections: is that what mtn is calling "branches" in its infodoc? Sep 05 09:50:02 ie I branch then propagate from org.oe.dev to my branch? Sep 05 09:50:12 no Sep 05 09:50:19 hughescr: its bitbake thing Sep 05 09:50:54 hughescr: http://pastebin.com/df6ea5ad Sep 05 09:52:11 hrw: ah, akin to portage overlays?oi Sep 05 09:52:22 argh stupid IRC client not deleting my line Sep 05 09:52:33 oi -- that looks like a nightmare Sep 05 09:53:32 hrw: "we do not support non-OE servers" means what -- that the OE mtn server won't allow pushes to it? How do OE devs get their changes into the DB? Sep 05 09:54:01 hughescr: we use mtn push/mtn sync from our databases to one of OE approved servers Sep 05 09:54:09 hughescr: yes, collections are a bit like portage overlays. Sep 05 09:54:11 ten those servers sync each others Sep 05 09:55:33 I wonder what happens if each overl^H^H^H^H^Hcollection has the same priority? Sep 05 09:55:49 random? Sep 05 09:56:16 I mean, aren't collections always intended to be stacked (overlaid?) based on their priority? Sep 05 09:56:39 likewise: If its the same priority it would fall to the order in BBFILES Sep 05 09:56:52 (i.e. parsing order) Sep 05 09:57:08 hrw: so individual developers could mtn pull from me if they wanted to? Sep 05 09:57:20 03hrw 07org.oe.dev * rf3c601a7... 10/ (1 packages/openmoko2/openmoko-common2_svn.bb): openmoko-common2: switch to SRCREV Sep 05 09:57:25 hughescr: sure Sep 05 09:57:28 and then in turn mtn push/sync to the main DB Sep 05 09:57:45 hughescr: The main DB will only accept keys it trusts Sep 05 09:57:55 RP: ok, clear Sep 05 09:58:23 RP: Ah, and there's no way for a trusted key to sign some commit that an untrusted key made in the first place? Sep 05 09:58:40 hughescr: There could be, I don't know monotone well enough to comment Sep 05 09:59:36 Seems like monotone is set up to basically want to be able to deal with people setting up their own replicated (possibly divergent) DBs at will and then sync as and when needed; though I guess I haven't seen anything which says "sync these bits but not those" Sep 05 10:00:04 hughescr: you send us patches, we check them, approve and one day you send us your public monotone key and will be able to push into our servers Sep 05 10:00:36 hrw: Yeah, but then that just pushes the problem for me of managing my 7,000 users and their patches onto me :) Sep 05 10:01:17 hrw: having it be a pain in the butt for people to submit patches because it breaks their next mtn update is a real dis-incentive to having people send you their patches :) Sep 05 10:02:15 hughescr: mtn commit supports --author option. OpenMoko has one key for company and use (atleast should) --author to give information who wrote such patch Sep 05 10:03:08 hughescr: so you can have gumstix@openembedded.org or openembedded@gumstix.com key whic your selected devs will use to commit patches into OE (wit --author switch) Sep 05 10:03:58 hughescr: of those 7000 user, if 70 send you patches, do you intend to review them yourself? Sep 05 10:04:03 s/user/users Sep 05 10:04:26 hrw: Right, I get that. But say joe-customer@somefoo.com has got his OE setup out there, and he creates some gumstix-relevant patch and sends it to me. I approve it and check it in as gumstix@oe.org then next time he does mtn pull;mtn update, his workspace breaks Sep 05 10:04:50 which sucks for him; so after he does it a couple times, he's likely to hold back on sending me his patches Sep 05 10:05:07 hughescr: why would it break? Sep 05 10:05:12 hughescr: How often are you going to commit things from your customers exactly as they send them to you? Sep 05 10:05:47 likewise: 70 is probably about right Sep 05 10:06:12 RP: I'll generally tweak them slightly. But that'll break things even worse for them when they next mtn pull;mtn update Sep 05 10:06:22 RP: Ideally my tweaks would be children of their patches Sep 05 10:06:37 RP: then mtn pull;mtn update will just magically work right Sep 05 10:06:45 hughescr: I think if the changes are kept identical then monotone might handle that ok. If you change them at all it will be tricker Sep 05 10:06:46 or maybe with an mtn merge in there somewhere Sep 05 10:06:47 hughescr: now wit buildroot they have merge conflicts Sep 05 10:06:58 hughescr: I don't think you can avoid this tbh Sep 05 10:07:06 hrw: svn seems to deal with it a lot nicer though Sep 05 10:07:28 RP: unless you just let everyone be able to write to the main DB :) Sep 05 10:07:51 RP: which is what I do with the gumstix svn server. Anyone can get a userid there with write perms to a branch of the tree Sep 05 10:08:01 I can then merge from their tree to the trunk Sep 05 10:08:20 and SVN does all the revision tracking so when they next merge from trunk back to their tree, it just works Sep 05 10:08:28 hughescr: you can run gumstix mtn server with branches Sep 05 10:08:33 hughescr: So setup a monotone server with an OE branch on it which you give customers write access to, You then act as a gateway propogating changes Sep 05 10:08:49 org.openembedded.gumstix Sep 05 10:09:04 hughescr: mtn has nice cherrypicker Sep 05 10:09:13 RP: and my propagations then count as new commits, essentially by me Sep 05 10:09:41 hughescr: But you resolve that onto the public branch of gumstix Sep 05 10:09:52 hughescr: you can use --author when you commit so contributors will be noted Sep 05 10:09:57 hughescr: So your customers shouldn't see any conflict Sep 05 10:10:50 gotcha Sep 05 10:10:59 sounds like a plan which could work Sep 05 10:11:36 hughescr: monotone is pretty powerful but takes a bit of getting used to if you've just used svn Sep 05 10:11:53 hughescr: The monotone guys are quite helpful too Sep 05 10:12:39 I prefer git, anyway ;-) Sep 05 10:12:49 gm Sep 05 10:13:06 monotone's commandline is much nicer. Sep 05 10:13:19 monotone messages are MUCH nicer Sep 05 10:13:21 no, it's not. It is purely a matter of taste. Sep 05 10:13:38 Sep 05 10:13:44 haven't ever had problems with git's messages either, but I still think it's a matter of preference. Sep 05 10:14:10 ynezz, what kind of flame can we have? We aren't supposed to share the same taste ;-) Sep 05 10:14:16 btw i like git more also Sep 05 10:14:17 and we do share the same monotone, anyway ;) Sep 05 10:14:17 :) Sep 05 10:15:18 polyonymous: I recently removed whole git tree and cloned it from scratch because no one (from local git experts) was not able to recover it after one git pull Sep 05 10:15:20 hrw: monotone messages are much nicer? yikes Sep 05 10:16:06 the first time my update failed due to my local changes being the same as the mtn pull'd update, I couldn't have possibly guessed what the error meant Sep 05 10:16:09 hughescr: one day I will start making notes of git crappy messages Sep 05 10:16:25 other than "just delete everything then manually try and figure out why the update failed" Sep 05 10:16:35 is bzr any better? Sep 05 10:16:48 hrw, well, I haven't had such problems with git, but I can't claim it won't happen tomorrow. Neither I'm sure it will never hapen to mnt, but I'm pretty sure if that happens recovery will be much more difficult. Sep 05 10:17:03 hrw: also something about sha1 hashes which is hard to mentally grok, as opposed to eg svn revision numbers Sep 05 10:17:30 hughescr, yeah, right, when you have untracked file in place of file being updated you have to guess it. Sep 05 10:17:34 hughescr: git also use unreadable revs Sep 05 10:17:47 at a glance, I can tell svn revision 123 happened after r122; hard to tell if ccef09b625c63012c586c9be1b8f8ec14df21fc0 or 495f2bdba3df97a68891268291064fd2d70a8563 came first Sep 05 10:18:10 i think, that one can't compare with svn, it's not 'distributed' Sep 05 10:18:10 hughescr: thats the problem with distributed SCMs Sep 05 10:18:12 hughescr, at a glance, yes, but there's no probem finding that out. Sep 05 10:18:23 ynezz: true Sep 05 10:18:27 that's not the problem, that's the difference. Sep 05 10:18:35 ynezz: I don't recall how svk deals with it Sep 05 10:19:02 hughescr: which rev is newer? 10:05 in your database (just pulled) or 10:06 in my database (not yet pushed)? Sep 05 10:19:09 monotone seems to be only semi-distributed though; in the end you still need a master somewhere to sync against Sep 05 10:19:09 being unable to track merges is really a pain, so I'd sacrifice revision numbers for it. Sep 05 10:19:26 hrw, 10:06 not yet pushed :) Sep 05 10:19:30 hughescr: we use OE as semi distributed Sep 05 10:19:42 polyonymous: what if I wont push it at all? Sep 05 10:19:50 hrw, it will still remain newer :) Sep 05 10:20:01 hughescr: didn't knew about svk Sep 05 10:20:09 hrw, that's just to answer your question ;-) Sep 05 10:20:10 hughescr: its easier to us to have public servers then pulling/syncing with each other Sep 05 10:20:28 hrw: understood Sep 05 10:20:35 well, having public servers can be combined with intersyncing if desired. Sep 05 10:20:42 polyonymous: what if I rm OE.mtn? then 10:05 will be newer... Sep 05 10:20:56 hrw, then you have nothing to compare 10:06 with Sep 05 10:21:06 10:05, I mean Sep 05 10:22:59 Is 'Intel Core2 Duo T5600' 64-bit? I don't see anything 64bit about it, but many sites claim it is. Is it me or is it 32bit? Sep 05 10:23:32 * polyonymous is almost clueless about modern hardware Sep 05 10:25:01 hughescr, my kernels are slightly larger after applying your patch for kernel construction ... Sep 05 10:25:02 hughescr: monotone is fully distributed, each checkout could run as a server Sep 05 10:25:22 hughescr: Also, having meld or kdiff3 installed makes monotone much more usable Sep 05 10:26:51 polyonymous: core2 is 64bit Sep 05 10:27:09 polyonymous: core duo is 32bit, core2 duo is 64bit Sep 05 10:27:20 hrw, aha, thanks. Sep 05 10:27:39 hrw, is it ia64? Sep 05 10:27:49 polyonymous: x86_64 Sep 05 10:27:55 hrw any thought on 994233 Sep 4 17:59 uImage-2.6.21-r7-gumstix-verdex-20070904212032.bin Sep 05 10:27:55 930845 Sep 4 17:11 uImage-2.6.21-r7-gumstix-connex-20070904203402.bin Sep 05 10:27:55 after: Sep 05 10:27:55 1007116 Sep 4 22:25 uImage-2.6.21-r7-gumstix-verdex-20070905020144.bin Sep 05 10:27:55 943728 Sep 4 21:56 uImage-2.6.21-r7-gumstix-connex-20070905013534.bin Sep 05 10:27:57 ack Sep 05 10:28:03 XorA, flame me, but I'm speaking about gentoo .iso's Sep 05 10:28:06 x86-64/x86_64/x64/amd64 Sep 05 10:28:07 I mean http://bugs.openembedded.org/show_bug.cgi?id=2926 Sep 05 10:28:14 XorA, they have i686,ia64 and amd64 Sep 05 10:28:18 Is it amd4? Sep 05 10:28:20 polyonymous: amd64 Sep 05 10:28:25 Ah ok, thanks. Sep 05 10:28:29 ia64 is Itanium isnt it? Sep 05 10:28:34 polyonymous: ia64 is itanium Sep 05 10:28:50 XorA, hrw, I thought so, it's just that having amd for intel sounds funny :) Sep 05 10:29:07 polyonymous: x86-64 is AMD product Sep 05 10:29:11 polyonymous: bad naming on their part, should be x86_64 Sep 05 10:29:18 Crofton: I expected the uImage to become slightly larger too (since it adds the linux decompression header), but when I built, it came out smaller. I have no idea why. Sep 05 10:29:25 XorA: no - x86-64/x86_64/x64/amd64 are correct Sep 05 10:29:32 XorA, hrw got it, thanks. Sep 05 10:29:48 I failed to boot amd64 cd on it, but it may be a cd problem as well. Sep 05 10:29:51 hrw: AFAIK linux guys settled on x86_64 Sep 05 10:29:55 I shoulr reburn it. Sep 05 10:30:10 RP: re meld/kdiff -- I'm looking into that now; actually I'd like to use OSX's FileMerge which I read somewhere should be doable but can't find now... Sep 05 10:30:12 polyonymous: it took some time for intel to be compatible wit amd in 64bit Sep 05 10:30:26 XorA: and ms windows ones on x64 Sep 05 10:30:30 XorA, yeah, they did. It's just that gentoo guys didn't rename their archs. Sep 05 10:30:40 hughescr, I would have expected slightly larger to Sep 05 10:31:04 hrw: I care little what MS call their broken OS :-) Sep 05 10:31:09 Crofton|home: angstrom-console-image built for fic-gta01 without problems Sep 05 10:31:18 XorA: so do I Sep 05 10:31:28 hrw, this is minimal image Sep 05 10:31:34 and it must be a clean build Sep 05 10:32:12 shit. I lack buildtime to reproduce it ;( Sep 05 10:35:43 let me know if there is anything I can look into for you Sep 05 10:36:07 I am generating deptree now for such build Sep 05 10:36:21 I'd like to avoid the answer, build omap5912osk first :) Sep 05 10:39:59 hi mallum Sep 05 10:40:16 hey hrw Sep 05 10:41:18 Crofton|home: I think that I see what you can look at Sep 05 10:42:17 Crofton|home: does your 'bitbake angstrom-minimal-image' build started update-modules do_install/do_package tasks? Sep 05 10:43:36 how should I check? Sep 05 10:43:50 tmp/stamps Sep 05 10:44:42 where does it put them> Sep 05 10:45:32 I can't find that it built update-modules Sep 05 10:47:21 find tmp/stamps -name update-modules* Sep 05 10:47:26 nothing Sep 05 10:48:01 asmola has built updater-modules, then runs into other issues Sep 05 10:48:37 ah.. so it does not even tried... Sep 05 10:48:55 Crofton|home: thats for gumstix-verdex? Sep 05 10:49:09 right Sep 05 10:49:22 for alix it build update-modules Sep 05 10:50:03 angstrom-minimal-image? Sep 05 10:50:33 yes - atleast in "-g" run Sep 05 10:51:11 hi all Sep 05 10:52:18 I'll have another build machine later today Sep 05 10:59:33 03xora 07org.oe.dev * r3adf6640... 10/ (4 files in 3 dirs): Sep 05 10:59:33 linux/linux-rp_2.6.22.bb : fix bitrot in c7x0 and akita defconfig where Sep 05 10:59:33 hostap and other 802.11 drivers are not built. Sep 05 11:03:23 heh defconfigs.. Sep 05 11:06:47 hrw: Poky could probably use that ;-) Sep 05 11:08:21 really? :D Sep 05 11:08:31 polyonymous: you plan to work on x64_64/amd64 targets? I did a proposal for OE on the ML. Sep 05 11:08:55 I thought poky could emulate 802.11 using LCD interference Sep 05 11:09:07 likewise, no, I think not, only build machine (I'm using amd64 as a buildhost now anyway) Sep 05 11:09:22 likewise, And I've read about your proposal too :) Sep 05 11:09:38 polyonymous: ok, amd64 host here too, but now I start to target similar servers as OE target as well :-) Sep 05 11:09:54 hrw: I wonder something similar has broken qemuarm... Sep 05 11:11:30 RP: pushed r3adf6640... into poky Sep 05 11:12:21 someone played with 1.8" hdds? Sep 05 11:12:56 hrw: thanks Sep 05 11:18:10 night night all Sep 05 11:18:15 time to pass out Sep 05 11:18:24 thx for all the help understanding monotone Sep 05 11:20:48 I can get 20GB 1.8" hdd with normal 2.5" hdd interface Sep 05 11:28:08 hrw, after asmola built update-modules, he ran into another dependency issue Sep 05 11:28:34 I am going to try a clean build of the OSK, but I need to create another build machine first Sep 05 11:56:30 hello there Sep 05 12:00:03 could anyone on x86 test the build of esmart ? it segfaults here on my x86_64... Sep 05 12:00:05 http://pastebin.ca/682172 Sep 05 12:00:14 hmm, bruno met his end near where my wife's parents met Sep 05 12:00:47 the actual failure is with edje_cc... the CVS version pulled is pretty old, maybe it's fixed upstream. Sep 05 12:00:51 noclouds, sorry no ideas here Sep 05 12:01:19 did you mean nodens ? ^ ^ Sep 05 12:01:27 yes :) Sep 05 12:01:33 stupid nick completetion Sep 05 12:01:56 your irc client is not smart enough ;) Sep 05 12:02:13 yeah it does what I type, not what I mean .... Sep 05 12:02:39 or it could complete first with the last nick that where speaking... Sep 05 12:02:49 but nevermind. Sep 05 12:05:56 I'll try to change e classes to get a more recent snapshot. Sep 05 12:06:12 nodens, you can update yours with mtn pull Sep 05 12:06:31 done :) Sep 05 12:06:42 mtn pull + mtn update Sep 05 12:07:44 let's see if anything has changed between this night and now... one can still hope :) Sep 05 12:09:54 no luck this time. Sep 05 12:10:08 I'll go for changing PV Sep 05 12:15:06 hi Cliff Sep 05 12:21:56 * * OE Bug 2898 has been RESOLVED (FIXED) by dp(AT)xora.org.uk Sep 05 12:21:58 * *  broken keymap in spitz image 20070828 Sep 05 12:22:00 * * http://bugs.openembedded.org/show_bug.cgi?id=2898 Sep 05 12:25:56 speaking of keymaps on spitz, there is a circular bug between #2767 and #2326 Sep 05 12:26:15 the fix for #2326 causes #2767 Sep 05 12:26:44 nodens: Is there a "also see" in place on the bugs? Sep 05 12:26:52 yep. Sep 05 12:27:09 and depends / blocks as well. Sep 05 12:29:00 an easy fix would be to patch keylaunch to take into account the fix for the Xmodmap, but then it would be necessary to change modmap for each machine having a "fn" key. Sep 05 12:29:18 maybe a bit intrusive. Sep 05 12:29:50 fixing gecko seems a best course of action for me :) Sep 05 12:30:24 nodens: prep a patch and revers 2326 Sep 05 12:31:24 mmmk Sep 05 12:33:26 I applied the keymap patch as at the time it didnt seem to break anything else Sep 05 12:33:31 I dont really use keylaunch Sep 05 12:34:57 keylaunch is evil Sep 05 12:35:16 hrw, agreed, but necessary evil :) Sep 05 12:35:33 nodens: really necessary? do not think so Sep 05 12:35:40 nodens: not really I think all that gumph could be done in matchbox-wm Sep 05 12:36:55 I didn't really looked into it... but indeed if kdrive has key mapping for these, the wm should be able to trap them. Sep 05 12:37:17 ("these" would be Function keys) Sep 05 12:37:20 /etc/matchbox/kbdconfig Sep 05 12:37:48 of course that is currently broken on the spitz I have Sep 05 12:37:53 * XorA looks at hrw Sep 05 12:38:16 and how would brightness be changed while on gpe-dm login screen ? Sep 05 12:38:50 (thats a real question) Sep 05 12:39:09 the real question is why are people so obsessed with changing brightness on login screen :-D Sep 05 12:39:51 well... I am not, but when suspend is broken and set brightness to 0... :) Sep 05 12:40:19 nodens: what machine? Sep 05 12:40:25 spitz Sep 05 12:40:34 only whenb auto-dim is set Sep 05 12:40:37 nodens: that seems to be fixed, try the image I just uploaded Sep 05 12:40:53 ah. that would be good news. Sep 05 12:41:29 new kernel ? Sep 05 12:41:36 2.6.22 Sep 05 12:41:59 ok, I'll need to build my own later to include axnet_cs, then... Sep 05 12:42:05 good to know ;) Sep 05 12:42:17 (own kernel, not own image) Sep 05 12:42:32 03stefan 07org.oe.dev * r4b363cb1... 10/ (3 files in 3 dirs): Sep 05 12:42:32 matchbox-keyboard-inputmethod: Add patch for a matchbox-panel-2 keyboard toogle Sep 05 12:42:32 applet, until it goes upstream. Sep 05 12:42:38 03stefan 07org.oe.dev * r7181fd7d... 10/ (3 files in 3 dirs): openmoko-session2: Use the new matchbox-keyboard applet. Sep 05 12:43:17 RP: ping Sep 05 12:44:56 meta-toolchain doesn't compile here on a fresh system (i.e. no packages built yet). Are all dependencies correct? I'm getting checking for suffix of executables... configure: error: cannot compute suffix of executables: cannot compile and link Sep 05 12:45:31 in gdb-cross-sdk_6.6.bb Sep 05 12:46:30 mickeyl: Poky one builds Sep 05 12:46:44 aha, so that means we have introduced a regression Sep 05 12:46:48 or the merge was incomplete Sep 05 12:47:16 mickeyl: OH autobuilder builds meta-toolchain each night from scratch Sep 05 12:49:50 hmm, the error is: gcc: conftest.c: No such file or directory Sep 05 12:52:42 is the OH autobuilder building meta-toolchain on a empty system (i.e. rm -rf tmp) or as part of a large build? Sep 05 12:52:50 XorA, done, Sep 05 12:52:50 XorA, done, Revert patch to xmodmap for SL-cxx00 as it breaks keylaunch (see #2767) Sep 05 12:52:50 Attached patche reverse previous patch to prevent keylaunch breakage. Sep 05 12:52:54 mickeyl: OH autobuilder builds meta-toolchain each night from scratch Sep 05 12:53:11 grrr... fuck gnome. Sep 05 12:53:28 and its copy/paste buffer different from the X11 one. Sep 05 12:53:48 I meant http://bugs.openembedded.org/show_bug.cgi?id=2767 Sep 05 12:55:07 hrw: ok, cool. unfortunately this doesn't help me that much Sep 05 12:55:26 is there a way to ask a dependancy tree to bitbake ? Sep 05 12:55:39 bitbake -g something-to-build Sep 05 12:55:46 grat, thanks. Sep 05 12:55:56 s/grat/great/ Sep 05 12:56:06 my typing sucks today Sep 05 13:00:59 RP, zecke : I guess you missed my yesterday quite late paste - http://rafb.net/p/bi0zOc32.html Sep 05 13:01:35 mickeyl: BTW any further thoughts on OEDEM hotels? Sep 05 13:02:03 XorA: didn't get to do anything more yesterday night. let me ask zecke again Sep 05 13:02:10 * hrw -> out now ;( Sep 05 13:02:20 * XorA wishes he could manage in German Sep 05 13:03:12 Hotel Amelie seems not to be so far away Sep 05 13:03:21 bah, do not forsake the lowest common denominator ... Sep 05 13:03:21 zecke: you probably don't know any hotels in that area, right? Sep 05 13:03:43 mickeyl: also, which is better, Lufthansa via frankfurt, or klm via Amsterdam? Sep 05 13:04:57 * * OE Bug 2927 has been created by zengaja(AT)gmx.de Sep 05 13:04:59 * * directfb-0.9.25.1-r1 on OE 1.4 for Dreambox fails Sep 05 13:05:01 * * http://bugs.openembedded.org/show_bug.cgi?id=2927 Sep 05 13:05:41 XorA: i'd prefer Lufthansa, but that's more a gut feeling Sep 05 13:06:36 mickeyl also prefers airbus to boeing :) Sep 05 13:06:47 heh, you remember? :) Sep 05 13:06:52 fun Sep 05 13:06:53 yep Sep 05 13:07:22 i also prefer C++ to C, and trust me, that's more than just a gut feeling :D Sep 05 13:07:27 * mickeyl whistels Sep 05 13:07:36 XorA: hey Sep 05 13:07:50 XorA: honigmond is too expensive? Sep 05 13:08:15 honigmond? Sep 05 13:08:19 ok, I ma going to create a new build machine back in a flash Sep 05 13:10:21 mickeyl: I couldnt find English booking Sep 05 13:10:38 for which? Sep 05 13:11:20 mickeyl: for Hongmond Sep 05 13:11:39 XorA: ah. well, i could reserve for you, if you want. you will be there for the full 6th to 10th ? Sep 05 13:11:53 mickeyl: yes I assume arrive on 5th and leave on 11th Sep 05 13:14:48 mickeyl: actually that form looks simple enough Sep 05 13:14:56 XorA, I was looking at that same website, thinking the same thing Sep 05 13:15:00 XorA: heh, ok Sep 05 13:15:19 if you get through, then we'll make this the official oedem hotel Sep 05 13:15:32 keep me posted, i want to book tomorrow as well Sep 05 13:15:43 mickeyl: looking at prices, single room is not En-Suite? Sep 05 13:16:30 right Sep 05 13:16:35 only double room is en-suite Sep 05 13:16:47 mickeyl: XorA : talk to me ;) Sep 05 13:17:03 or talk to me while I'm allowed to talk with you :} Sep 05 13:17:07 heh Sep 05 13:17:15 i'm fine with any hotel actually, I only will be there for two nights Sep 05 13:17:15 zecke: we were just discussing which hotel to make the official OEDEM one Sep 05 13:17:43 * XorA doesnt care about en-suite, just making sure I understood the thing Sep 05 13:17:47 XorA: vivijim will stay in the honigmond and from what I know it is quite good Sep 05 13:18:12 * XorA shall fill in booking form and see what happens Sep 05 13:18:15 hehe Sep 05 13:18:16 go for it Sep 05 13:21:22 hi zecke, hi XorA: actually I don't know yet if I'll stay in the honigmond or in the garden hotel... it depends on my company choice... Sep 05 13:21:48 polyonymous: Can you write a summary of the problem so I can understand the need for that change please? Sep 05 13:22:17 vivijim: arent they just all part of the same complex? Sep 05 13:22:55 XorA: no, two Sep 05 13:22:58 XorA: actually I don't have idea... Sep 05 13:23:06 XorA: but both are close by Sep 05 13:23:23 RP, ah, sorry, I thought you were around yesterday. Zecke moved do_configure to qmake-base.bbclass and it turns out you can't export functions with dash in the name, hence we decided to replace '-' with '_' Sep 05 13:23:24 what does Zimmerwahl mean? Sep 05 13:23:28 let me check which one I'll stay Sep 05 13:23:51 binutils-cross 2.18 is showing show breakage :-( Sep 05 13:24:16 XorA: vivijim: http://maps.google.com/maps?f=q&hl=en&geocode=&q=Novalisstra%C3%9Fe,+10115+Mitte,+Berlin,+Germany&sll=37.0625,-95.677068&sspn=32.197599,78.310547&ie=UTF8&ll=52.529825,13.3886&spn=0.012062,0.038238&z=15&om=1 Sep 05 13:24:39 Garden hotel is at the "Invalidenstrasse" and the other one at the crossing of "Tieckstrasse/Borsigstrasse" Sep 05 13:24:41 polyonymous: Ah, right, That makes sense Sep 05 13:25:56 RP, the patch is pretty trivial, but only tested it with libqpe-opie that was giving me headache and had no time to do a fresh OE build - I got my new notebook and I'm setting it up now, that will take a while, so I just pass the fix. Sep 05 13:26:00 XorA: Zimmerwahl = chose apartment Sep 05 13:26:17 mickeyl: cool, its not in the online Dictionary :-) Sep 05 13:26:34 yeah, that's one of those composed expressions Sep 05 13:26:43 polyonymous: zecke knows that area of the code better than me so I'll let him apply it I think ;-) Sep 05 13:26:56 * XorA bangs head on desk as memory comes back Sep 05 13:27:01 RP, no objections on my part :) Sep 05 13:27:32 I had no idea about this part of code (and I'm still very much bitbake-code-agnostic) at all until yesterday :) Sep 05 13:29:42 binutils 2.18 shows 64bit breakage :-( Sep 05 13:30:58 XorA: Worse than 2.17.X? Sep 05 13:31:16 RP: well whats in OE doesnt get through staging Sep 05 13:31:28 RP: binutils-cross fails Sep 05 13:34:36 XorA: :-( Sep 05 13:34:36 zecke: It is really close... I believe that I'll stay in the garden one.... Now I need to leard how to pronounce these street names hehehe Sep 05 13:35:34 RP: I shall have to work out exactly what kills it later Sep 05 13:36:37 so garden one is the OEDEM hotel of choice? Sep 05 13:37:57 good for me Sep 05 13:38:06 garden/honigmond Sep 05 13:38:12 * XorA sends the form Sep 05 13:38:33 RP: binutils-cross-2.18 works for me on 32-bit debian etch and xubuntu 7.04 - for another data point. Sep 05 13:38:59 It works on 32 bit slackware and ubuntu feisty :) Sep 05 13:40:13 RP: I think some directories are getting x86_64 appended to name Sep 05 13:40:21 RP: for unknown reasons, need to investigate more Sep 05 13:45:57 morning Sep 05 13:46:07 RP: in fact it fails on rmdir ${CROSS_DIR}/${libdir}/gcc-lib || : Sep 05 13:46:07 rmdir ${CROSS_DIR}/${libdir} || : Sep 05 13:46:19 RP: in the .bb is this more poky merge problems Sep 05 13:46:37 XorA: Which .bb is that? Sep 05 13:46:46 binutils-cross.inc Sep 05 13:47:00 That was hrw I think - hrw? Sep 05 13:48:13 XorA: I don't think it was anything from poky Sep 05 13:48:44 RP: Ill let you off hook then :-D Sep 05 13:49:01 XorA: ;-) Sep 05 13:49:16 We just added 2.18, the .inc was unchanged Sep 05 13:49:44 ${CROSS_DIR}/lib/libiberty.a is actually cross/lb64/libiberty.a for me Sep 05 13:53:41 XorA: That makes sense but could be a nice headache :/ Sep 05 13:54:08 RP: Ill have to look when x86_64 machine is local to me Sep 05 14:14:19 Hi, can anyone help me out. I'm trying to add a package to my build which fetches from my CVS repository. I've added a line to my .bb (SRC_URL = "cvs://tjaffey@cvs.hypertag.com/home/cvsroot;module=ht5;method=ext") (my CVSROOT shell var is 'tjaffey@cvs.hypertag.com:/home/cvsroot'), but "task do_fetch" seems to neither check out the code nor fail. Any ideas? Sep 05 14:15:09 Whoops, seeing it written down... I should have SRC_URI and it works. Whoops. Sep 05 14:15:53 re Sep 05 14:16:32 * hrw builds with binutils-cross 2.18 on amd64 in 64bit Sep 05 14:16:41 Poky for arm and Angstrom for arm Sep 05 14:19:43 have I mentioned I hate meetings Sep 05 14:20:00 Crofton|laptop: i dont recall you ever saying that :-) Sep 05 14:20:03 well, meetings with these guys Sep 05 14:20:19 let me guess long and useless? Sep 05 14:20:20 you guys are at least willing to actually work ... Sep 05 14:25:47 monotone build is broken - cross binary started Sep 05 14:33:48 local.conf.sample sux Sep 05 14:33:50 I think Sep 05 14:36:40 Crofton|laptop: OE one? Sep 05 14:37:40 yeah Sep 05 14:38:13 does it need the preferred provider stuff Sep 05 14:38:31 we almost need one for people getting started, and an advanced one Sep 05 14:38:50 Crofton|laptop: I agree Sep 05 14:38:50 like to prevent people starting with distro Sep 05 14:38:55 = generic Sep 05 14:39:11 * chouimat is looking at python 3.0 alpha 1 Sep 05 14:39:13 the wiki has been updated to tell people to make that change ... Sep 05 14:39:15 Crofton|laptop: Improving the entry to OE for newcomers would be good... Sep 05 14:39:18 at least Sep 05 14:45:31 How should SRCREV_FORMAT be used? u-boot have git and svn. The only example I found was webkit that seems broken due to exactly this atm Sep 05 14:55:44 hi koen Sep 05 15:00:45 on the good side, I can get OE up and running on a fedora 7 box really easily Sep 05 15:01:06 it helps that I already have gone through local.conf several times Sep 05 15:07:00 bbl. cya ppl. Sep 05 15:14:52 bye Sep 05 15:22:56 stefan_schmidt: You tag each item in the url with a name and then set SRCREV with a string which search and replace is made on by bitbake Sep 05 15:23:58 RP: Yeah, I figured this out from your posts on bitbake-dev now. Still the problem for git revs stays Sep 05 15:24:13 stefan_schmidt: Which problem with them? Sep 05 15:24:27 RP: Any var I can use to have the git rev for putting them into the later file name? Sep 05 15:25:12 RP: I like to have something like uboot-gir$REV-sv$REV in the end. With a bb fetching always newest git and svn patchset Sep 05 15:25:32 stefan_schmidt: That will break package upgrades which is why bitbake doesn't let you do it Sep 05 15:25:38 RP: Would be nice to have an indication what upstream and patchset version is used in this ubot Sep 05 15:26:08 RP: hmm, uboot does not get updated via ipkg ;) Sep 05 15:26:21 stefan_schmidt: Its the general principle Sep 05 15:26:21 RP: So for git I'm forced to use SRCDATE? Sep 05 15:27:11 RP: ok Sep 05 15:27:12 stefan_schmidt: No, that would be bad. It needs careful thought Sep 05 15:27:51 stefan_schmidt: If needbe we can improve the bitbake code to expose the git revisions but you can imagine how people will abuse them in general :-( Sep 05 15:28:27 RP: I can. Once it is out it will be used for everything and we have no chance to make it sane again. Sep 05 15:28:41 RP: So I stay with the svn rev alone for now. Sep 05 15:29:58 stefan_schmidt: I'll try and remember to revisist git urls now the svn setup seems to be working for people Sep 05 15:30:35 RP: Thanks. Make sure you have still some spare time for yourself. Sep 05 15:31:28 Alp Toker webkit/GTK+ talk slides: http://www.atoker.com/blog/2007/09/05/webkitgtk-at-linuxconf-europe-2007/ Sep 05 15:32:22 XorA|gone, bug reported Sep 05 15:32:54 re Sep 05 15:33:57 * * OE Bug 2928 has been created by philip(AT)balister.org Sep 05 15:33:59 * * binutils-cross fails to build on x86_64 Sep 05 15:34:01 * * http://bugs.openembedded.org/show_bug.cgi?id=2928 Sep 05 15:48:12 I am a bit puzzled about the new SRCREV thing Sep 05 15:49:14 if there is a package foo-svn.bb defining PV = "0.5.0+svnr${SRCREV}" and DEFAULT_PREFERENCE = "-1". to what should I set PREFERRED_VERSION_foo in order to build the svn version Sep 05 15:51:20 if there is a package foo_svn.bb defining PV = "0.5.0+svnr${SRCREV}" and DEFAULT_PREFERENCE = "-1". to what should I set PREFERRED_VERSION_foo in order to build the latest SVN version? Sep 05 15:58:23 wow receiving hundres of messages from dirc killed my phone for a while Sep 05 15:59:46 03stefan 07org.oe.dev * rab6f93c0... 10/ (1 packages/uboot/uboot-openmoko_svn.bb): uboot-openmoko_svn.bb: Use SRCREV. Sep 05 15:59:52 03stefan 07org.oe.dev * rdc20496e... 10/ (1 packages/tasks/task-openmoko.bb): task-openmoko.bb: Add matchbox-keyboard-applet to the default image. Sep 05 16:01:27 rschuster: PREFERRED_VERSION needs to be unset since bitbake can't evautate SRCREV at config parsing time Sep 05 16:04:14 RP: leaving PREFERRED_VERSION_foo unset will cause bitbake to chose foo_svn.bb which has DEFAULT_PREFERENCE = "-1" ?? Sep 05 16:04:37 rschuster: Change the default preference then Sep 05 16:05:32 rschuster: I realise its a bit ugly but there is simply no way bitbake can evaluate SRCREV at config parsing time (which is when it needs PREFERRED_VERSION) Sep 05 16:06:28 rschuster: You can do DEFAULT_PREFERENCE_pn-foo = "1" in a distro btw Sep 05 16:12:29 RP: I reopened #2897 as we seems to be misunderstanding eachother Sep 05 16:12:34 (but first: food) Sep 05 16:23:20 koen: I just can't see how we can possible expect to fix that in bitbake. I've replied in the bugzilla Sep 05 16:43:46 http://pastebin.ca/682562 anyone seeing this error Sep 05 16:45:17 not here Sep 05 16:45:22 what are you trying to build? Sep 05 16:45:56 osk angstrom-console-image Sep 05 16:46:42 Crofton|work: it was working ok couple of days back . Sep 05 16:48:23 I just built angstrom-console-image at home Sep 05 16:49:02 Crofton|laptop: hmmm which binutils did it use I am using 2008.1 btw Sep 05 16:49:14 ah Sep 05 16:49:20 2007.1 Sep 05 16:50:53 yeah you might be using different binutils there then Sep 05 17:00:33 03stefan 07org.oe.dev * r5e39aeb6... 10/ (1 packages/tasks/task-openmoko.bb): task-openmoko.bb: Bump PR Sep 05 17:00:38 03stefan 07org.oe.dev * rfc79ebc9... 10/ (1 packages/openmoko2/openmoko-session2/etc/matchbox/session): openmoko-session2: Enable systray again as some people still use inputmgr Sep 05 17:00:43 03stefan 07org.oe.dev * r60181dbe... 10/ (1 conf/distro/openmoko.conf): openmoko.conf: We have september now Sep 05 17:01:27 XorA|gone: I just realised, we can bump the PR of a do_install task on a specific package. PR_do_install := "${PR}-1" :) Sep 05 17:01:47 I've not tested that but its perhaps mad enough to work :) Sep 05 17:01:49 Crofton|work: How do I check the latest commits in mtn Sep 05 17:03:08 RP: Hi ! Not sure if you have seen my message yesterday. We have problems with the recent bitbake and nfs mounted dirs for source files Sep 05 17:03:28 steliosk: I did see it. Is your NFS locking server working properly/ Sep 05 17:03:29 ? Sep 05 17:03:51 steliosk: FWIW I run my sources dir on nfs and it works for me Sep 05 17:04:06 RP: I updated my bzr fetcher patch. going forward and backward with "bzr pull" works now (http://bugs.openembedded.org/show_bug.cgi?id=2913) Sep 05 17:04:11 I think hrw does too and had locking issues at first but it worked once he fixed them Sep 05 17:04:47 RP : The server machine runs debian etch with stock kernels and softraid Sep 05 17:05:08 RP : we did not have any problems before Sep 05 17:05:12 steliosk: and what about the client? Sep 05 17:05:18 ubuntu Sep 05 17:05:22 and debian Sep 05 17:05:50 I'm using ubuntu as a client here and it works fine :/ Sep 05 17:05:55 its really weird Sep 05 17:06:14 steliosk: I'm afraid you'll have to debug it further. bitbake is only using standard system calls Sep 05 17:06:45 RP : What could effect the number of availiable locks to a system ? Sep 05 17:07:17 steliosk: I don't know Sep 05 17:07:30 RP : the problem happens when bitbake fetches a new file and tries to write to the nfs share Sep 05 17:08:12 steliosk: What was the pastebin again? Sep 05 17:08:23 rschuster: It looks promising, I'll have a look shortly :) Sep 05 17:08:37 it seems we have 2 heads in the repo Sep 05 17:08:54 multiple update candidates: Sep 05 17:08:54 mtn: 110c6ec488c63036fe1cb9a1e304bfb935b57bca oe@openembedded.org xora@openembedded.org 2007-09-05T12:41:18 2007-09-05T12:43:38 Sep 05 17:08:54 mtn: 60181dbea7f819472034ab00db51dac31fd65723 stefan@openembedded.org 2007-09-05T16:50:16 Sep 05 17:09:20 the automerger will take care of that Sep 05 17:09:48 * cbrake is also running into AMD64 binutils building problems -- same as #2928 Sep 05 17:10:07 RP : i have reboot the machine, lost it :( But this was a really weird one. The most common is "no locks availiable" or something like that Sep 05 17:10:34 steliosk: I'm fairly sure it will be some kind of config issue on the nfs server then Sep 05 17:21:09 cbrake, build console image, then minimal image :) Sep 05 17:21:34 asmola__, ping Sep 05 17:22:26 Crofton|laptop: that fixes binutils build??? Sep 05 17:22:42 hmm, wait wrong bug Sep 05 17:22:44 sorry Sep 05 17:23:18 my brain is the wrong gear Sep 05 17:28:39 03ifaistos 07org.oe.dev * r75a18357... 10/ (3 files in 3 dirs): conf/machine/i586-generic.conf: Add pentium optimization for i586-generic machine Sep 05 17:28:45 03ifaistos 07org.oe.dev * rece1b92a... 10/ (3 files in 3 dirs): conf/machine/i686-generic.conf: Add pentium pro optimization for i686-generic machine Sep 05 17:39:05 * Crofton|laptop wonders how fast UPS updates their delivery page Sep 05 17:40:39 Crofton|laptop: almost instantaniously Sep 05 17:41:05 I can read my signature online after returing to my desk from the front door Sep 05 17:41:45 I am waiting for the wall wart and serial cable Sep 05 17:42:07 I really curious about the kernel uncompressor issue for gumstix Sep 05 17:45:13 Crofton|work: Re bug 2928 Sep 05 17:45:31 Crofton: looks like it's on the truck on its way to be delivered to you :) Sep 05 17:45:38 yeah Sep 05 17:45:48 Crofton|work: I think the problem is related /lib and /lib64 Sep 05 17:45:52 overnight still impresses me Sep 05 17:45:57 Truck must be taking the slow road since it left the depot at 8am... Sep 05 17:46:02 Can you try a hack to check? Sep 05 17:46:08 Crofton: yeah, international overnight blows me away Sep 05 17:46:32 I can get packages to my parents in London faster than I can get there myself Sep 05 17:47:15 KhemWork, for binutils, probably Sep 05 17:47:27 Crofton|laptop: yes Sep 05 17:47:33 KhemWork, ok Sep 05 17:47:46 hughescr, my parents are originally from London ... Sep 05 17:47:54 its a hack only to check if it fixes the problem Sep 05 17:48:01 will building the openmoko-devel-image recipe with distro = "openmoko" get me an up to date image with the new openmoko ui or is that building the old stuff? Sep 05 17:48:07 ok Sep 05 17:48:20 as long as I don't make a mess of the machine ... Sep 05 17:49:31 * steliosk is reading "OE distro wars" in bugzilla Sep 05 17:49:48 steliosk: interesting? Sep 05 17:49:52 yeah Sep 05 17:50:02 we need to figure out what the real issues are Sep 05 17:50:26 what people really need to do for "derived" distros Sep 05 17:50:45 chouimat : yeah, new bugzilla feature Sep 05 17:50:45 and derived images Sep 05 17:50:55 Crofton|laptop: try this http://pastebin.ca/682661 Sep 05 17:51:20 Crofton|laptop : The thing to answer is whether OE is a "framework" or a distro itself Sep 05 17:51:29 Crofton|laptop: as you can see it has hardcoded stuff but its only to verify the problem Sep 05 17:51:33 steliosk: url? Sep 05 17:51:38 KhemWork, ok Sep 05 17:51:47 * chouimat too lazy and tired to search for it Sep 05 17:52:17 Crofton|laptop : once this is answered we can talk details :) Sep 05 17:52:34 chouimat : check bug 2919 Sep 05 17:53:22 ohhh this one ... I hate long thread Sep 05 17:54:00 KhemWork, patch failed? Sep 05 17:54:12 ok same error ? Sep 05 17:55:16 no, the patch did not apply, doing by hand Sep 05 17:56:05 Crofton|work: ah ok I created it inside package/binutils Sep 05 17:56:10 may be that's why Sep 05 17:56:32 easy enough to do by hand Sep 05 17:56:49 right Sep 05 17:59:06 KhemWork, I built binutils-cross, working on minimal-image again Sep 05 17:59:24 steliosk, I think people are raising good points in the thread Sep 05 17:59:46 Crofton|work: I agree Sep 05 18:00:17 Crofton|work: but i said we need to define what OE is. Sep 05 18:00:22 steliosk: I love being called "special", especially with quotes around it :) Sep 05 18:00:56 special :) Sep 05 18:01:09 hughescr : What do you mean ? Sep 05 18:01:17 in the sense that you have the ability to introduce thousands of people to OE Sep 05 18:01:59 steliosk: not sure what your native idiom is. "special" in quotes means something specific in US english Sep 05 18:02:48 Crofton: yeah I was just composing a response based on the 7k new users thought, but I suspect with OE instead of buildroot, a lot of people will just not be building, but using .ipkgs instead Sep 05 18:03:02 ...which means that those ipkgs need to actually work for them and not be based on the wrong libc, etc Sep 05 18:03:15 hughescr : I could say it looks "Greek to me" but that would not be true :) btw i have a feeling you have misunderstood what i wrote Sep 05 18:03:37 I also have no idea how the existing OE infrastucture would hold up under a few thousand more people suddenly doing mtn pulls every so ofetn Sep 05 18:03:46 hughescr : I had the same discussion with koen some months back Sep 05 18:03:50 Anyone know how many pulls per day the system deals with now? Sep 05 18:04:09 steliosk: no, don't worry -- I'm just kidding Sep 05 18:04:28 asmola_work, try building angstrom-console-image, then minimal-image Sep 05 18:04:57 steliosk: wait a sec -- which are you? Richard? Koen? Sep 05 18:05:12 i used your cheat and built for the osk then the gumstix (both for minimal) Sep 05 18:05:17 hughescr : aka ifaistos Sep 05 18:05:21 heh Sep 05 18:05:40 steliosk: ah ok, wrote here not on the bug Sep 05 18:06:11 i will give it a shot with the console image though then the minimal Sep 05 18:06:39 yeah, basically I am trying to get enough info to hrw and hope he sees the problem Sep 05 18:06:46 Crofton: is this bug likely related to the "angstrom-minimal-image doesn't update /lib/modules/2.6.21/* properly?" Sep 05 18:07:00 or, I can see the problem by comparing minimal and console recipes Sep 05 18:07:09 ie you need to depmod -a on first boot to get module dependencies working right Sep 05 18:07:11 maybe .... Sep 05 18:07:12 no Sep 05 18:07:23 we have a bad dependency when building minimal Sep 05 18:07:25 seems like in both cases, update-modules isn't running right Sep 05 18:07:38 but we can work around it by building something else Sep 05 18:13:31 cbrake, ping Sep 05 18:13:34 i just kicked off the angstrom-console-build on the angstrom-minimal-image build that died on update-modules, i will let you know how it goes Sep 05 18:13:43 I bet it works Sep 05 18:13:51 Crofton|work: hello Sep 05 18:14:08 cbrake, khem pastebin a patch that got me building again Sep 05 18:14:14 I added it to the bug Sep 05 18:14:20 2928 Sep 05 18:16:13 Crofton|laptop: yes, that looks like it would work for AMD64. Now, how to make it work for both 32 and 64 bit workstations ... Sep 05 18:16:27 we need a new variable Sep 05 18:17:52 so why is hrw not running into this problem? Sep 05 18:19:00 Crofton|laptop, that's the other thing I was afraid of, the current minimal image created via the osk->gumstix work aroudn doesn't boot :( Sep 05 18:20:25 gcc -print-multi-directory must be returning lib on his machine, even though it is 64bit Sep 05 18:22:13 ahh, I but hrw does have multilibs installed ... I added another comment to the bug ... Sep 05 18:23:33 crofton, angstrom-console-image failed when building from the "broken" minimal image build, i am going to start a clean build Sep 05 18:23:34 asmola_work, I should be able to start looking at this later today Sep 05 18:24:33 when booting it hangs after this line: "hwclock: Could not access RTC: No such file or directory" Sep 05 18:24:44 wait a long time Sep 05 18:24:47 :) Sep 05 18:25:03 first boots can take a long time Sep 05 18:25:17 i tried that last time, ill give it another shot, i never saw any issue like this prior to last week or so Sep 05 18:26:25 how long does the kernel uncompress take? Sep 05 18:27:24 FWIW, you can make uboot decompression faster by using the linux kernel memcpy asm Sep 05 18:27:41 the kernel has optimized ones for armv4 and armv5 Sep 05 18:27:43 koen: yeah, but you also need to set up the caches, etc Sep 05 18:27:48 8s or so Sep 05 18:28:15 it runs about 3.5 seconds on the OSK Sep 05 18:28:35 hughescr: it took me a while to convince the openmoko people that uboot was being slow as molasses, not the kernel Sep 05 18:28:35 koen: much easier to just disable gunzip in uboot and use the linux arch/arm/boot/compressed/vmlinux which does the decompression in linux after turning everything on Sep 05 18:28:43 indeed Sep 05 18:28:50 koen: you want to get out of u-boot as fast as possible Sep 05 18:29:08 koen: even loading from flash to RAM in u-boot is molasses Sep 05 18:29:26 yes Sep 05 18:29:29 it loves doing all flash reads 1 byte at a time even if you could burst a lot faster Sep 05 18:29:36 I can't remember won on LAKML pointed that out Sep 05 18:30:47 so it sounds like there is some consensus we should change linux.inc to use kernel decompressor? Sep 05 18:31:09 yes Sep 05 18:31:27 Hopefully and can test hughescr patch later today and push Sep 05 18:31:36 but wrapped in an if test -e compressed guard Sep 05 18:32:08 'make uImage' is severely non-standard in kernel land (and vendor patches!) Sep 05 18:32:20 I don't know how much of a difference there'd be between u-boot vs linux decompression on archs other than xscale/iwmmxt, but there's a lot of special-case code in the linux decompressor for different archs, so I assume the answer is "still noticeable" Sep 05 18:32:44 koen: yup, the -e test makes sense Sep 05 18:33:48 and I imagine that on archs with bigger caches then PXA255/PXA270 it'd make even more difference since gzip decompression is nicely cacheable Sep 05 18:34:46 * koen is flipping a coin on wether or not to make a uclibc-nptl_svn recipe Sep 05 18:35:15 uclibc development is a farce currently Sep 05 18:35:17 hey florian Sep 05 18:42:15 Crofton|laptop, this thing definitely isn't going to boot :( Sep 05 18:43:03 hmm Sep 05 18:43:04 rer Sep 05 18:43:12 can you pastebin the boot log? Sep 05 18:43:45 http://pastebin.com/m554c87bb Sep 05 18:44:30 koen: NPTL I would like to have it in provided I get time from work Sep 05 18:45:48 interesting Sep 05 18:46:00 feels like something fishy on udev land Sep 05 18:53:33 ramfs: Bad mount option size Sep 05 18:54:00 that needs iirc a patch to util-linux Sep 05 18:54:26 bah, I am going home and seeing if the cable had arrived .... Sep 05 18:56:13 hugescr, yeah, but it used to boot even when i think i got that error before, i was trying to get a basic minimal image to boot and then start plugging in your patches Sep 05 18:56:26 if you don Sep 05 18:56:35 don't get tmpfs working right, then udev won't work right Sep 05 18:56:41 iirc Sep 05 18:57:01 has the udev version chnaged recenlty? Sep 05 18:57:46 there are a bunch of patches from hughescr I need to process Sep 05 18:58:08 I have been reluctant to process most without access to testing hw Sep 05 18:58:18 anyway, I am going home to wait for UPS Sep 05 18:58:27 yeah, i was going to patch them in myself and start playing aroudn with stuff (particularly networking :) Sep 05 18:58:42 Crofton|work, ok, talk to you in a bit Sep 05 18:58:46 actually, I think the change is in udev Sep 05 18:58:54 in udev-version/init Sep 05 18:59:03 It's fixed in my udev-115 Sep 05 18:59:10 broken in udev-092 but easily fixed there too Sep 05 19:00:22 I need to head to a meeting, but after meeting+lunch I'll be creating a branch in my OE DB which will be available for pulling against for my latest gumstix stuff Sep 05 19:00:45 ie the stuff I've got in existing bugs, plus whatever work-in-progress I feel like working in progress on :) Sep 05 19:00:52 bbiab Sep 05 19:12:10 I have the apckage' Sep 05 19:12:56 :) Sep 05 19:15:07 which of the three serialports is teh console? Sep 05 19:15:23 middle Sep 05 19:18:32 the power thing is on the console board or network, or both? Sep 05 19:18:41 you can use either Sep 05 19:19:55 booting Sep 05 19:20:01 nice Sep 05 19:21:09 i can walk you through the reflash process when\if you want Sep 05 19:21:16 ok Sep 05 19:21:23 give me a minute Sep 05 19:21:30 hmm, need to connect to network Sep 05 19:21:39 what is root pw Sep 05 19:21:42 gumstix Sep 05 19:26:49 | Cannot find package task-sdk-host. Sep 05 19:26:49 | Check the spelling or perhaps run 'ipkg update' Sep 05 19:27:38 we should provide a default value for TASK_SDK_HOST Sep 05 19:27:54 TOOLCHAIN_HOST_TASK, actually Sep 05 19:31:36 ah, that just seems to be missing Sep 05 19:31:38 * mickeyl copies from poky Sep 05 19:32:50 ok, actually it's not missing but not getting built Sep 05 19:33:30 *sigh* ok, it's there but not getting found Sep 05 19:39:23 i686-armv4t-sdk seems to be not as valid source in ipkg-sdk.conf Sep 05 19:52:58 mickeyl: I was arount to say, I could swear I added it... Sep 05 20:37:10 RP: ping Sep 05 20:37:24 RP: what is motivation behind http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-September/008459.html Sep 05 20:39:15 KhemWork: It was needed to make the toolchain work standalone outside OE iirc Sep 05 20:39:32 KhemWork: Without it something was going wrong with paths, I can't remember what exactly Sep 05 20:39:44 KhemWork: why? Sep 05 20:39:47 RP: hmmm Sep 05 20:40:09 RP: I am getting an error while compiling binutils-cross-2.17.50.0.12 Sep 05 20:40:36 KhemWork: That change is just in cross-sdk Sep 05 20:40:59 right however I was thinking of this change Sep 05 20:41:03 and wanted to ask Sep 05 20:41:54 btw. Do you know of any issues for binutils-cross-2.17.50.0.12 Sep 05 20:41:57 KhemWork: The SDK is designed to run outside OE in /usr/local/somewhere so references to CROSS_DIR are invariably wrong.. Sep 05 20:42:13 I am getting this error http://pastebin.ca/682562 Sep 05 20:42:15 KhemWork: It worked well in poky... Sep 05 20:42:58 KhemWork: That is a weird error, I've not seen it before... Sep 05 20:43:07 2.18 works ok for me Sep 05 20:44:11 KhemWork: strange Sep 05 20:46:18 RP: flex -lm I don't know how it is getting that Sep 05 20:46:35 KhemWork: It does seem strange Sep 05 20:47:14 can you try to build this recipe? Sep 05 20:48:05 KhemWork: Most of my builds are poky based atm but I can try Sep 05 20:48:22 try on poky too it might fail there too Sep 05 20:48:30 binutils-cross-2.17.50.0.12 Sep 05 20:48:49 KhemWork: works fine in poky, I know that Sep 05 20:48:54 I just want to make sure that its related to my env or fedora 7 host that I am using Sep 05 20:49:01 hmmm Sep 05 20:49:07 KhemWork: It was part of our standard toolchain until I aded 2.18 Sep 05 20:52:37 RP: hmmm so it should have built ok for me 3 days ago Sep 05 20:52:45 did something change in flex Sep 05 20:54:41 KhemWork: binutils-cross 2.17.0.50.12 just built fine in OE.dev for me Sep 05 20:55:18 RP: what host do you use Sep 05 20:55:30 RP: can you let me see your local.conf Sep 05 20:55:34 KhemWork: you mean the machine or the distro? Sep 05 20:55:47 distro Sep 05 20:56:12 KhemWork: The machine I tested on is slackware. I know it works on ubuntu too Sep 05 20:56:26 KhemWork: There is nothing special in the local.conf Sep 05 20:56:31 koen changed the binutils to 2.18 on angstrom but it still is building 2.17.50 I wonder why Sep 05 20:57:10 I am doing a clean build btw so there should be no residui Sep 05 20:57:20 s/resdui/residue Sep 05 20:58:59 03rpurdie * r972 10/ (4 files in 4 dirs): bzr.py: bzr fetcher tweaks from Robert Schuster (#2913) Sep 05 20:59:22 RP: I have this LD_LIBRARY_PATH=$OEDIR/build/tmp/staging/i686-linux/lib Sep 05 20:59:32 in my build_source Sep 05 20:59:39 Is it still needed Sep 05 21:00:35 KhemWork: Yes, I can understand why. It should perhaps be added to native.bbclass Sep 05 21:01:14 so I still need it right ? Sep 05 21:01:35 KhemWork: I have no idea if it was added to OE or not offhand Sep 05 21:01:44 I'd guess not Sep 05 21:01:55 (so yes, you still probably need it) Sep 05 21:02:04 ok Sep 05 21:02:44 Do you know how I can find who is pulling 2.17.50 despite angstrom-2008.1 saying to have 2.18? Sep 05 21:04:28 KhemWork: bitbake foo -g Sep 05 21:04:56 KhemWork: Do you have a working angstrom eglibc build? Mine fails on a configure, where grep fails (I suspect argument buffer overflow due to my long pwd path name). Sep 05 21:05:46 likewise: there is a fix for that you should touch all configure files so that they are not regenerated Sep 05 21:05:55 I thought koen committed that fix Sep 05 21:06:20 KhemWork: where was that patch committed? bugtracker? Sep 05 21:06:59 nope I think when we were mucking with eglibc Sep 05 21:08:21 likewise: check do_confiure() in eglibc_svn.bb Sep 05 21:08:56 03rpurdie * r973 10/ (6 files in 4 dirs): fetch/: Add mercurial (hg) fetcher from Robert Schuster (#2913) Sep 05 21:10:02 likewise: We need same touch command for eglibc-initial_svn.bb eglibc-intermediate_svn.bb Sep 05 21:10:07 as well Sep 05 21:10:18 KhemWork: ok Sep 05 21:10:34 likewise: can you prepare the patch for those two ? Sep 05 21:10:42 KhemWork: sure Sep 05 21:10:45 will do Sep 05 21:10:48 and test it and commit it Sep 05 21:10:50 :) Sep 05 21:11:08 RP: ERROR: No providers of build target binutils-cross_2.17.50.0.12.bb (for []) Sep 05 21:11:18 I did a glibc_fpu to eglibc_fpu fix there recently. Sep 05 21:11:59 KhemWork: What was the command? Sep 05 21:13:02 KhemWork: Could you describe why exactly we need to touch the configure scripts? I would like to doc those workarounds in the toolchain scripts while I am at it. Sep 05 21:13:24 it's package or BB specific? http://rafb.net/p/I9lyjw25.html Sep 05 21:15:16 likewise: because otherwise it regenerates some of configure scripts Sep 05 21:15:32 mtn log --brief --last 5 packages/util-linux/util-linux_2.12r.bb is running for like 2 mins. now and no response yet, is mtn so slow? Sep 05 21:15:45 and if the autoconf on your host is not the one which generated it then it creates all sort of problems Sep 05 21:16:19 KhemWork: ok, is this needed in glibc also? Sep 05 21:16:30 yes it should be Sep 05 21:16:52 though I haven't looked into glibc recipes Sep 05 21:17:12 RP: bitbake binutils-cross_2.17.50.0.12.bb -g Sep 05 21:17:25 KhemWork: no touches to be found there. Sep 05 21:17:34 KhemWork: bitbake doesn't take full filenames though, does it? ;-) Sep 05 21:18:41 RP: hmmm it does for building Sep 05 21:18:55 KhemWork: it does? Sep 05 21:19:22 bitbake -b ../org.openembedded.dev/packages/binutils/binutils-cross_2.17.50.0.12.bb -c rebuild Sep 05 21:19:33 KhemWork: That is the -b option Sep 05 21:19:46 ah OK Sep 05 21:19:53 pardon my bb knowledge Sep 05 21:20:12 running now bitbake binutils-cross -g Sep 05 21:21:39 RP: it generated two files Sep 05 21:21:55 KhemWork: right, have a look at the task-depends.dot Sep 05 21:22:46 ok Sep 05 21:22:51 KhemWork: sorry, I think I have this confused, you want to know why a given version is bing built? Sep 05 21:22:59 RP: yes Sep 05 21:23:06 though I choose 2.18 Sep 05 21:23:24 KhemWork: Sorry, I'm telling you totally the wrong thing :-( Sep 05 21:23:33 Too many things at once... Sep 05 21:23:42 * KhemWork smacks the desk Sep 05 21:23:50 KhemWork: bitbake binutils-cross -DDD is probably your best bet, sorry Sep 05 21:24:54 KhemWork: Somewhere in that output it will detail why its choosing what version. It is admittedly hard to read though Sep 05 21:25:18 ok let vi open it first :) Sep 05 21:26:12 DEBUG: selecting /local/sandbox/openembedded/org.openembedded.dev/packages/binutils/binutils-cross_2.17.50.0.12.bb as PREFERRED_VERSION 2.17.50.0.12 of package binutils-cross (for item binutils-cross) Sep 05 21:26:57 KhemWork: if you run bitbake -e | grep PREFERRED_VERSION | grep binutils does it show anything? Sep 05 21:27:21 KhemWork: FYI, http://bugs.openembedded.org/show_bug.cgi?id=2929 Sep 05 21:27:23 yes it does Sep 05 21:27:51 when I search this kind of information, grep -rF is my friend :) Sep 05 21:28:17 KhemWork: From what you've pasted it sounds like the PREFERRED_VERSION for binutils-cross is set to 2.17.50.0.12 somewhere... Sep 05 21:28:24 RP: all of them are 2.17.50.0.12 Sep 05 21:28:52 KhemWork: ok, so you're not setting them to 2.18, whatever you're doing isn't working Sep 05 21:30:44 RP: yeah I see so here is what is wrong Sep 05 21:30:58 conf/distro/angstrom-2007.1.conf sets it to 2.18 Sep 05 21:31:12 but then conf/distro/angstrom-2008.1.conf includes conf/distro/angstrom-2007.1.conf Sep 05 21:31:22 however later down it overwrites Sep 05 21:31:34 PREFERRED_VERSION_binutils = "2.17.50.0.12" Sep 05 21:32:16 KhemWork: See koen then ;-) Sep 05 21:32:42 RP: yeah I will create a bug and post the patch there Sep 05 21:32:52 * KhemWork pingpong time Sep 05 21:33:10 KhemWork: So the newer angstrom conf takes an older binutils? That needs a ping pong for sure. Sep 05 21:33:57 * * OE Bug 2929 has been created by likewise(AT)gmx.net Sep 05 21:33:59 * * eglibc should not regenerate configure scripts Sep 05 21:34:01 * * http://bugs.openembedded.org/show_bug.cgi?id=2929 Sep 05 21:43:31 403 for http://www.openembedded.org/user-manual&dpage=recipes_initscripts Sep 05 21:47:48 there are multiple OE revisions available Sep 05 21:48:57 which one to chose? Sep 05 21:49:02 xora or stefan Sep 05 21:49:24 Just pick one Sep 05 21:56:18 Is maemo already in the Angstrom feed? If yes, how the packages are named, I see only maemo-mapper there. Sep 05 21:57:49 zap: Its not Sep 05 21:57:58 Aha, any plans for it? Sep 05 21:58:00 (that I know of anyway) Sep 05 21:58:11 zap: koen has experimented with it a bit Sep 05 21:58:28 and it's ultimately broken? :) Sep 05 21:59:01 I got the impression it was less so that it used to be... Sep 05 21:59:08 I heard they forked gtk Sep 05 21:59:21 wonder if it's at least renamed Sep 05 21:59:39 Yes, although they're trying to merge or make those bits conditional in maemo apps now Sep 05 21:59:59 03rpurdie 07org.oe.dev * r6d5274a1... 10/ (1 classes/package_ipk.bbclass): package_ipk.bbclass: Add sdk Packages files and fix ipkf-sdk.conf (fixing meta-toolchain) (from poky) Sep 05 22:01:39 RP: thanks! Sep 05 22:01:40 mickeyl: This should fix the meta-toolchain issue you were seeing. As it happens our autobuilder hit it tonight as well (we switched to split ipk deploy today) Sep 05 22:01:50 03rpurdie 07org.oe.dev * r6a2d2b93... 10/ (1 classes/package_ipk.bbclass): package_ipk.bbclass: Improve directory existance check (from poky) Sep 05 22:04:01 * mickeyl mtpull Sep 05 22:20:57 * * OE Bug 2930 has been created by raj.khem(AT)gmail.com Sep 05 22:20:59 * * angstrom-2008. 1 overwrites the PREFERRED_VERSION for binutils Sep 05 22:21:01 * * http://bugs.openembedded.org/show_bug.cgi?id=2930 Sep 05 22:31:45 how can I find my host machine while building a recipe Sep 05 22:32:04 I want to know if I am running on 32 bit OS or 64 bit OS Sep 05 22:33:05 `uname -m` Sep 05 22:33:32 is one way but I just want to know if it is 32 or 64 I don't care if it is ppc or x86 sparc or whatever Sep 05 22:36:25 hmm Sep 05 22:36:28 git ls-remote git://www.denx.de/git/u-boot.git/ failed with signal 127, output: Sep 05 22:37:44 worked for me Sep 05 22:37:55 ya, it's not installed on my machine Sep 05 22:38:02 i just wonder why sanity.bbclass didn't pick that up Sep 05 22:38:05 (installed a new buildmachine) Sep 05 22:39:46 mickeyl: because we... Sep 05 22:39:59 mickeyl: well DEPEND on git-native but that is too late for bitbake? Sep 05 22:40:00 tell me Sep 05 22:40:07 aah Sep 05 22:40:21 yes, that's probably too late for the svngetrev Sep 05 22:40:31 so we should add it to the list of required software Sep 05 22:40:32 svn or git? ;) Sep 05 22:40:41 $SCM get rev ;) Sep 05 22:40:51 g'night guys! Sep 05 22:40:54 g'night Cyberdeck Sep 05 22:46:44 Hmm. Thats a tricky one, I was hoping we could rely on our own git-native package :/ Sep 05 22:47:10 'night all Sep 05 22:48:38 RP: gn Sep 05 22:55:16 hmm why do i get heaps of fetcher errors Sep 05 22:55:59 ERROR: Fetch command export PATH=/home/pkg/oe/fic-gta01/tmp/staging/i686-linux/bin/arm-angstrom-linux-gnueabi:/home/pkg/oe/fic-gta01/tmp/staging/i686-linux/bin:/home/pkg/oe/fic-gta01/tmp/cross/bin:/local/pkg/oe/bitbake-1.8.4/bin:/local/pkg/oe/bitbake-1.8.4/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/bin:/bin:/usr/X11R6/bin:/usr/local/bin:/local/pkg/oe/bitbake/bin:/usr/local/arm/2.95.3/bin:/local/pkg/monotone/bin:.:/home/mickey/bin; LANG=C LC_ALL=C /usr/bin/en Sep 05 22:55:59 v svn info http://svn.openmoko.org/trunk/src/target/OM-2007.2/libraries/libmokoui2/ failed with signal 1, output: Sep 05 22:56:12 odd Sep 05 22:56:34 Crofton: building you an smc911x u-boot now... Sep 05 22:57:06 ah never mind Sep 05 23:11:21 hughescr, thanks! Sep 05 23:14:52 almost there Sep 05 23:15:08 I should probably test it first before bricking your gumstix ;) Sep 05 23:35:34 Crofton: had a minor bug in my patch which needed fixing and rebuilding... Sep 05 23:35:40 testing u-boot with smc911x now Sep 05 23:40:40 Looking good so far... Sep 05 23:43:35 Crofton: http://rungie.com/~craig/trunk/u-boot.bin Sep 05 23:43:45 md5sum: d277fb726a8ee625b4dcfc6027ed5b11 u-boot.bin Sep 05 23:43:56 ok Sep 05 23:44:09 I assume I need to use kermit with this? Sep 05 23:44:17 crc32: 2a381381 Sep 05 23:44:23 yeah Sep 05 23:44:35 actually, you can use ymodem too iirc Sep 05 23:44:40 "loady" instead of "loadb" Sep 05 23:45:11 does minicom do native ymodem? Sep 05 23:45:19 yeah, I am being lazy ... Sep 05 23:45:33 I hate minicom, personally :) Sep 05 23:45:36 I just use ckermit Sep 05 23:46:32 I've never been able to satisfactorily figure out how minicom calls out or not to other processes for sending/receiving Sep 05 23:46:55 and I prefer the scrollback buffer in my terminal program to whatever windowing minicom does Sep 05 23:47:45 I will now ask a stupid question Sep 05 23:47:57 how do you get ckermit for fdora 7? Sep 05 23:48:46 urpmi ckermit? Sep 05 23:48:55 dunno, been years since I used a redhat-family distro Sep 05 23:49:04 * Crofton is annoyed it is not really free Sep 05 23:49:35 yum install ckermit ? Sep 05 23:50:03 hmm Sep 05 23:50:15 yum search kermit failed Sep 05 23:50:31 I think they have a screwy license .... Sep 05 23:51:12 Crofton: did you refresh yum sources? I can't remember if yum does it automagicially Sep 05 23:51:16 yeah screwed up license Sep 05 23:51:27 http://www.columbia.edu/kermit/ck80.html#license Sep 05 23:52:56 Free Unix Distributions: C-Kermit may be included in "free Unix" distributions such as GNU/Linux, FreeBSD, NetBSD, and OpenBSD. See the license for details. Sep 05 23:53:19 "non-standard" but shouldn't be a problem if you're using it on a "free" OS Sep 05 23:54:13 Well, I suspect their definition of free is not compatible with open source Sep 05 23:54:24 working on building from source now Sep 05 23:54:38 anyone here a firefly fan? Sep 05 23:55:09 Their definition of free might not be compatible with some open source weirdos, but if all you want to do is use it (rather than modify it or redistribute it, or use it on windows) then you're basically free to do so Sep 05 23:55:42 * Crofton just wants to yum install it Sep 05 23:55:44 remember the program's been around since 1985, produced in an academic environment, and with the copyright held by some bozos in the legal affairs office of a university Sep 05 23:55:51 Crofton: firefly si Sep 05 23:56:22 ok, there is a special place in hell for university lawyers Sep 05 23:56:25 ok? Sep 05 23:57:20 * Crofton is seriously cranky tonight Sep 05 23:58:55 back "in the day" it was fashionable to build everything from source :) Sep 06 00:01:14 Crofton actually lawyers are sent from hell to earth to give us a preview of what hell is ;) Sep 06 00:02:20 stop talking about my sister that way :) Sep 06 00:02:32 Crofton I didn't know Sep 06 00:02:48 :) Sep 06 00:03:11 http://www.hunton.com/bios/bio.aspx?id=17235 Sep 06 00:03:25 http://www.wulffmorgenthaler.com/top10.aspx Sep 06 00:03:56 hughescr, do you have web page on replacing uboot via kemit? Sep 06 00:04:38 Crofton: hang on Sep 06 00:05:14 I have bricked the OSK a few times Sep 06 00:05:20 http://docwiki.gumstix.com/U-Boot#Loading_new_stuff_to_flash Sep 06 00:05:39 I finally worked out how to unbrick without speaking to the guys that get "JTAG" Sep 06 00:05:50 also http://docwiki.gumstix.com/Connecting_via_Serial_-_Linux Sep 06 00:06:36 that latter page is more focussed on connecting and logging in once linux has booted Sep 06 00:06:40 but the kermrc is useful Sep 06 00:06:54 ah Sep 06 00:06:55 http://docwiki.gumstix.com/Tutorial Sep 06 00:07:04 has a step by step on how to replace u-boot using kermit Sep 06 00:07:51 brb gotta reboot a router here Sep 06 01:26:56 n8 Sep 06 01:45:48 Crofton, you get the new u-boot in there? Sep 06 02:04:57 * * OE Bug 2931 has been created by  Sep 06 02:04:59 * * libgcc-related SO link errors after recent changes to gcc. bb Sep 06 02:05:01 * * http://bugs.openembedded.org/show_bug.cgi?id=2931 **** ENDING LOGGING AT Thu Sep 06 02:59:56 2007