**** BEGIN LOGGING AT Fri Jan 08 02:59:57 2010 Jan 08 03:01:41 after this error occurred, I add "INHERIT += rm_work" in local.conf, but this is not helpful. I think I need to remove all tmp dir, and build again. it will take a long time to do that. Jan 08 03:02:43 yes, that would be best Jan 08 03:04:57 Hmmm Jan 08 03:05:14 If cross/ had to die, and staging/ had host native bins, would people scream? Jan 08 03:05:35 And would that be more or less screaming than cross/ having symlinks back to staging// Jan 08 03:05:40 I have a suggestion for this, maybe it's helpful to who want to release some disk space like me. Could bitbake provide a command like "bitbake -c rm_work" like this to delete things like "INHERIT += rm_work" do? Jan 08 03:06:22 favor: it does, actually. bitbake -c rm_work_all will run it against that and all of its dependencies Jan 08 03:07:06 Tartarus: i always disliked the necessity of a "cross" at all. it would be nice if any truly cross stuff was target prefixed Jan 08 03:07:06 heh Jan 08 03:12:24 thanks kergoth. I move downloaded sources directory to another disk, and use "bitbake -c rm_work_all", it works. this command does what things? does it remove all the work releated directories? Jan 08 03:13:19 yes, but only after they've been built, when those aren't needed anymore Jan 08 03:13:22 so its not really harmful Jan 08 03:13:34 can just leave it inherited as you build, itll clean up as it goes Jan 08 03:14:36 NOTE: package postfix-native-2.2.12-r0: task do_install: started Jan 08 03:14:36 ERROR: function do_install failed Jan 08 03:14:37 ERROR: log data follows (/home/clarson/oe/projects/sync/tmp/work/i686-linux/postfix-native-2.2.12-r0/temp/log.do_install.7324) Jan 08 03:14:37 ./postfix-install: Error: no /home/clarson/oe/projects/sync/tmp/staging/i686-linux/usr/bin/postconf file. Did you forget to run "make"? Jan 08 03:14:38 * kergoth sighs Jan 08 03:18:05 at least, I don't need to delete all the tmp dir, in which some packages (such as cross compiler) are built. Jan 08 05:15:03 anyone around Jan 08 05:15:04 ? Jan 08 05:15:09 trying to modprobe dsplinkk.ko Jan 08 05:15:27 but it keeps sayiug "dsplinkk.ko not found" Jan 08 05:15:35 even though its there in the drivers/dsp directory Jan 08 05:28:42 drpo the .ko Jan 08 05:28:46 modprove foomod Jan 08 05:28:50 *modprobe Jan 08 05:28:58 or, insmod /path/to/foomod.ko Jan 08 05:29:35 depmod -a Jan 08 05:29:38 is what I needed to do Jan 08 06:17:37 good morning Jan 08 07:20:00 goodmorning Jan 08 07:32:55 gm Jan 08 07:35:34 hello to all. i have a question about the git repo. for some reason everytime i execute "git pull" i get hundreds of files with the comment Jan 08 07:35:35 "needs update" and after some while it breaks also everytime the updating process of the tree with "error: Entry not uptodate. Cannot merge." Jan 08 07:35:37 is this normal ? this looks very strange to me ! Jan 08 07:36:08 xperia: you touched/changed a lot of files in your git tree Jan 08 07:38:34 hmmm that is very strange. i didnt do anything to the files. my plan was just to clone the repo and keep it up to date. changes will be go later to a separate branch. Jan 08 07:47:46 xperia: try git remote update ... or, finally, git clone from scratch Jan 08 07:48:38 oohhh gir clone again will take hours again till everything is downloaded and created on my disk. still thanks for the tip Jan 08 08:15:24 xperia: git reset --hard Jan 08 08:16:15 recalcati: git reset --hard helps when your tree is screwed up and you want to bring it in sync with the remote repo. Jan 08 08:16:17 btw. the git repo from open embedded is heavy unsecure and it looks like ddosed as allways timeouts Jan 08 08:16:18 maybe some git clone identifiactions could help to avoid this ddos attacks Jan 08 08:16:19 git.openembedded.org[0: 140.211.169.165]: errno=Connection timed out Jan 08 08:16:21 fatal: unable to connect a socket (Connection timed out) Jan 08 08:16:55 ynezz: thanks for help ! Jan 08 08:17:30 maybe you've bad link to openembedded.org, it's working for me fine Jan 08 08:18:56 hmmm the heavy strange thing is that i have only about 10% of the adsl speed that i should get. my connection drives me crazy. this stupid isp that i have changed to last year makes me heavy mad. Jan 08 08:38:16 does anybody know somethig about the weired out of memory problem that i have. i am not able to build oe on any mashines Jan 08 08:38:18 have cloned now the repo of oe on different machines and started to build it but i gat allways the same error Out of Memory message Jan 08 09:00:18 hey people how much ram do you have on the machine that you build oe ? Jan 08 09:01:13 3gb and 4gb Jan 08 09:04:52 hmmm does it really need such a lot ? didnt thinked it. other people told me also to try it on a machine with 4 GB Jan 08 09:06:38 03Sebastian Spaeth  07org.openembedded.dev * r81cbab0207 10openembedded.git/recipes/navit/navit_svn.bb: Jan 08 09:06:38 navit: don't RRECOMMEND 2 text2speech apps in svn, but only RSUGGESTS them. Jan 08 09:06:38 * Distros can always pick one by default if they want one by default Jan 08 09:06:38 Signed-off-by: Sebastian Spaeth Jan 08 09:15:09 eFfeM: have a question about the build system of open embedded. i have seen in the conf/machine directory that there is conf file for htcblackstone device Jan 08 09:16:05 does this device exist in the prebuilded images of open embedded ? Jan 08 09:17:21 xperia: there are no prebuild images of openembedded, there are prebuild images of distro's using openembedded Jan 08 09:17:44 and if you want to know whether it is on your distro (presumably angstrom), well just browse the feed Jan 08 09:18:41 xperia: and wrt the 4G mem: not sure what is really needed, used to have a 2G system, but mem is cheap nowadays so decided to upgrade to 4G. Jan 08 09:19:13 but your Q was what I had, not what was needed :-) Jan 08 09:20:23 well if you know what is then needed at minimum would be more than good if you could tell it me :-) Jan 08 09:20:57 it is all a matter of how fast you want things to build, i guess my old 486 with 512M would also work Jan 08 09:22:15 if you have sufficient swap space even 64M or less might do, but it will take some time though :-) Jan 08 09:23:13 hmmm but then the problem that i have is not related to my build host becouse have tryed now to build oe on a system with 1GB ram and i got the error message Out of Memmory Jan 08 09:23:39 add more swap space! Jan 08 09:24:08 if you have small memory you need plenty of swap Jan 08 09:24:24 although I would expect 1G to be ok, unless you are running lots of other things Jan 08 09:24:34 where did it fail ? Jan 08 09:25:24 running task 1 of 2542 (id: 15, .../recipes/shasum/shasum-native.bb, do setscene) Jan 08 09:25:26 running task 2 of 2542 (id: 75, .../recipes/coreutils/coreutils-native_7.2.bb,do setscene) Jan 08 09:25:27 Out of Memory: Kill Process 11335 (python) Jan 08 09:25:29 ERROR: Task 15 shasum-native.bb do setscene failed Jan 08 09:25:56 it looks like coreutils give him the shot Jan 08 09:26:18 hm cool, that is quite quick, expected it to fail much later (e.g. when building gcc) Jan 08 09:26:30 how much swap do you have Jan 08 09:27:39 512 MB Jan 08 09:29:24 eFfeM: something is weird need to check more will come back later Jan 08 09:29:26 morning Jan 08 09:29:29 hm, i would increase that Jan 08 09:29:35 XorA hi Jan 08 09:29:39 okay will do that Jan 08 09:29:48 xperia: system I am at now has 8G swap Jan 08 09:29:57 woooowww Jan 08 09:29:59 and consider buying some more mem, it is cheap Jan 08 09:30:27 8 G swap is not that much nowadays. (unless you have a 10G disk) Jan 08 09:30:43 a 1TB disk is eur 70 or so and 8G is only 1 % of it :-) Jan 08 09:31:44 problem is that the machines are laptops all but will look what i can do. Jan 08 09:31:45 ahh come on we have plenty of old hardware and the software is getting fat with every day. Jan 08 09:31:47 how should we get a os to run on a pocket pc when we can not build it on a system with 1 GB ram and 512 MB swap space Jan 08 09:32:02 but I think my 4GB ram system @ home runs wo swap Jan 08 09:32:32 well, the amount of memory that you require at run time for the target system has nothing to do with the amount of memory you need to compile it in the first place. Jan 08 09:32:41 guess python is the memory hog, I've build openslug on a 486 or 586 Jan 08 09:32:57 pb__ right Jan 08 09:33:03 it is a bit surprising that oe won't build in 1.5G, though I could believe it. you could try restricting the set of recipes that it parses in order to reduce bitbake's memory footprint. Jan 08 09:33:04 yes it has to be python Jan 08 09:33:33 pb__ it also depends on what other things he is running Jan 08 09:33:41 obviously it also depends on what else you are running on the same machine. if you have, say, evolution and firefox running then they will consume a large chunk of that 1.5G for themselves leaving bitbake with only a few megs. Jan 08 09:33:45 right, yeah Jan 08 09:34:16 xperia: try again after stopping all sw that is not absolutely necessary Jan 08 09:34:38 yeah exactly this is problem. will try to reboot the system in console only and test if it will work again Jan 08 09:35:00 I do run firefox and evolution on the same machine that I use for oe builds, but I have 8G of RAM and 20G of swap. Jan 08 09:35:17 maybe python can be told not to use all of the mem also Jan 08 09:35:37 looks like the kernel is shuting it down becouse of other tasks Jan 08 09:36:52 xperia: if thre is not enough memory an oom killer will kick in and kill a random (?) task Jan 08 09:37:23 or the app that requests mem and does not get it detects it itself and will stop Jan 08 09:39:59 yeah this is the problem. too much things that use too much ram. oe need some more intelegent build that looks also at the ram usage. starting prcesses without proving if ram is enoght is not very intelegent. especially if you build it hours and then it stops only for such a problem Jan 08 09:46:38 http://evanjones.ca/python-memory.html Jan 08 09:46:40 It is not unusual to see my Python process eating up a gigabyte of RAM. Jan 08 09:46:42 need for sure about 2GB swap space Jan 08 09:49:11 JaMa, mickey: libfsobasics fails do_compile: http://tinderbox.openembedded.org/packages/libfsobasics/ Jan 08 09:52:17 xperia: in the default configuration (without BB_NUMBER_THREADS), bitbake will only start a single process at a time. I don't think there's much scope for making it more "intelligent" about deciding when to do that. Jan 08 09:52:40 if there isn't enough RAM to start a process that it needs to start, there isn't much it can do at that point other than stop (which is effectively what happens anyway) Jan 08 09:54:02 pb: okay in this case python is the root of the problem. will try to solve it with more swap space Jan 08 09:54:55 yeah, that sounds like your best option Jan 08 09:55:11 or, as I say, try to reduce python's footprint by restricting your BBFILES Jan 08 09:56:17 pb_: i am totally new to oe. Jan 08 09:56:19 where can i reduce this bbfiles that are builded in oe so python dont need to parse such a lot. Jan 08 09:56:44 * Laibsch1 sighs Jan 08 09:56:52 xperia: you are running out of RAM during the initial parsing? Jan 08 09:57:03 Is OE back to being a memory hog? Jan 08 09:57:36 no, he isn't actually running out of RAM during parsing, but he doesn't seem to have enough left afterwards to actually build anything. Jan 08 09:57:51 OK Jan 08 09:57:55 So what happens? Jan 08 09:58:17 I'd like to try and reproduce on my tried and tested 600MHz, 640MB RAM build host ;-) Jan 08 09:58:20 running task 1 of 2542 (id: 15, .../recipes/shasum/shasum-native.bb, do setscene) Jan 08 09:58:20 running task 2 of 2542 (id: 75, .../recipes/coreutils/coreutils-native_7.2.bb,do setscene) Jan 08 09:58:20 Out of Memory: Kill Process 11335 (python) Jan 08 09:58:29 I see Jan 08 09:58:45 I'll try "bitbake coreutils-native", then Jan 08 09:58:53 xperia: anyway, regarding the files: see the definitions of BBFILES and BBMASK in your local.conf Jan 08 09:58:58 wooow Laibsch :-) Jan 08 09:59:18 pb_: okay will do that Jan 08 09:59:36 xperia: what host OS? Jan 08 09:59:43 ubuntu server Jan 08 09:59:53 basically, bitbake will parse everything that's named in BBFILES, except those things which are excluded by BBMASK. so, if for example you know that you don't want to build opie, you can exclude all of those recipes from parsing which will make bitbake run faster and use less ram. Jan 08 10:01:29 Laibsch: have also tryed it to build it on Debian Lenny with 1 GB Ram and 512 MB Swap. Debian was full booted as Desktop withsome opened Application like Iceweasel, terminals and so on .. Jan 08 10:01:47 have trayed to build the opie.image task Jan 08 10:01:59 opie-image Jan 08 10:02:12 xperia: I run Ubuntu hardy. Maybe you are interested in http://blog.leggewie.org/?p=39 for setting up your system. Jan 08 10:04:04 Laibsch: woow that is a very easy howto. wish this instructions were on the wiki page. would save me a lot of time and pain Jan 08 10:04:33 It is ;-) Jan 08 10:05:58 Hm Jan 08 10:06:01 Maybe not anymore Jan 08 10:06:26 really i have found only the get starting page. give me a moment to prove that Jan 08 10:06:51 http://wiki.openembedded.org/index.php/OEandYourDistro links to it Jan 08 10:07:11 and GettingStarted should link to OEandYourDistro Jan 08 10:07:40 Laibsch I removed OEAndYourDistro from getting started as its badly wrong and I dont have time to fix it Jan 08 10:08:03 after the 100th person tried to run OE with distro packaged bitbake it got very boring explaning it was wrong Jan 08 10:08:41 Laibsch have found it but it is heavy hidden behind very cryptic links Jan 08 10:08:43 http://wiki.openembedded.net/index.php/AptGetableOE Jan 08 10:11:28 XorA: Debian unstable has the latest packages now, but of course, there sometimes is a lag and then there are the stable releases. Maybe OE should provide bitbake packages. As you know, I always try to stay with packaged software Jan 08 10:14:10 I guess no OE devs actually care enough about packaging bitbake for all 1000 distros Jan 08 10:14:47 Debian/Ubuntu would be a start Jan 08 10:15:02 and I guess they could even share the actual package Jan 08 10:15:07 so, right now, we are fine Jan 08 10:35:44 I still got some quite serious problems. I asked about this before Christmas but still haven't solved it. The problem is that I'm not able to boot my machine because I get the "interrupt lost" after "leaving" my initramfs. It hangs for 30 seconds or so, goes a bit further in the boot sequence and then prints "lost interrupt" again.. When it finally manages to boot it's completely useless because it's so slow. The rootfs is installed on a CF card. I plugged in a Jan 08 10:35:44 USB-CD and installed Ubuntu on the machine to see if that would work and it did. Ubuntu runs without any problems. So, does anyone have any suggestions on this? Jan 08 10:36:22 Laibsch: I know we used to supply debian/ubuntu packages Jan 08 10:36:47 Laibsch: I could probably even knock up an rpm for fedora in a few weeks time when workload is less Jan 08 10:39:08 jovox: that sounds like it must be a kernel or driver problem; I guess you should take it up with either the kernel people or your chipset supplier. I don't think it is really anything to do with OE. Jan 08 10:40:49 jovox: check /proc/config.gz and compare it to the one you used for OE kernel, there could be a CONFIG_HACKYCHIPSET_FIX difference, there are quite a few of those for IDE chipsets in the kernel Jan 08 10:41:25 XorA: That would be nice. As far as a deb is concerned, I added a link to my PPA in the wiki. The Debian package from unstable requires some newer packages. A rebuild solved that problem and my package should be installable for everyone, I guess. Jan 08 10:42:00 Laibsch: that would be nicer, a lot of people stay away from debian unstable as when it breaks it tends to smash things big time Jan 08 10:42:09 yes Jan 08 10:42:19 Laibsch: if I remeber a ppa can generate packages for all sane recent releases? Jan 08 10:42:25 I've been using that package for a while now on Debian lenny and Ubuntu hardy Jan 08 10:42:33 XorA: yes Jan 08 10:42:44 I did not try dapper which I think is still supported Jan 08 10:42:54 Laibsch: definately sounds like a plan then Jan 08 10:43:11 Laibsch: easier that teaching people about apt pinning Jan 08 10:43:13 bitbake is just python Jan 08 10:43:15 not compiled Jan 08 10:43:44 if you mention that, maybe I should set up a separate ppa for OE Jan 08 10:44:10 Because my hardy PPA has some other stuff that if installed on a Debian lenny system may tend to create problems Jan 08 10:44:56 Laibsch: I only have one debian system so Ill leave the small details to you, all my home machines are Fedora Jan 08 10:54:35 dapper is still supported, yes. Jan 08 10:56:46 One thing that might be useful would be an oe-build-essential metapackage. Jan 08 10:56:53 www.debian-archeology.com :-D Jan 08 10:57:00 Which would depend on all the stuff needed on the host. Jan 08 10:57:03 XorA: That's ubuntu. Jan 08 10:57:03 hrw used to make an oe-build-essential Jan 08 10:57:28 Though these days it won't build as standard anyway due to /bin/sh being dash,. Jan 08 10:57:50 you can blame gnome for that Jan 08 10:57:54 pb__: around? Jan 08 10:58:01 RP: at your service Jan 08 10:58:10 but with my shorter tail :-) Jan 08 10:58:26 pb_: I would like to raise the issue of wildcards in PREFERRED_VERSION again Jan 08 10:58:39 pb_: This is about to cause me major pain :( Jan 08 10:59:10 pb_: I have two recipes, a floating git one and a release. How do I select the git version? Jan 08 11:00:18 pb_: I'm picking on you since you objected to the patch that was proposed last time ;-) Jan 08 11:00:22 pb_: ahah, a perfect time for you to advertise your packaging version munging Jan 08 11:00:30 RP: heh Jan 08 11:00:53 RP: I don't remember the previous patch, though I can imagine I would have objected to something like that on principle. Can you point me to the patch in question? Jan 08 11:01:06 broonie: my apt-getable OE does that (and more) Jan 08 11:01:19 RP: as for the general issue, I guess this hinges on what we consider should be our policy for ${PV} in floating recipes. Jan 08 11:02:15 Laibsch: apt-getable OE makes me cringe though Jan 08 11:02:28 you don't need to use it ;-) Jan 08 11:02:29 my inclination at the moment is to say that floating recipes should have PV set to some fairly static string, say "0.0+git", without encoding a concrete revision in there. That makes it easy to nominate them as the preferred version, and also avoids the eye-burn that you tend to suffer with a full SHA hash in PV. Jan 08 11:02:40 XorA: what is it that makes you cringe? Jan 08 11:02:41 pb_: http://lists.linuxtogo.org/pipermail/openembedded-devel/2009-September/013615.html Jan 08 11:02:53 Laibsch: the idea of downloading OE in a postinst Jan 08 11:03:05 pb_: That isn't the way the autorevisioning stuff works Jan 08 11:03:20 the only real downside to having a static string in PV is that it stops being completely floating, i.e. rerunning bitbake without cleaning will not automatically pick up the new version. It's sort of debatable whether this is a good or a bad thing. Jan 08 11:03:24 pb_: The autorevisioning stuff has to change PV Jan 08 11:03:55 RP: to make automatic rebuilds work, you mean? Jan 08 11:04:05 pb_: yes Jan 08 11:04:18 pb_: It all currently works rather nicely. Apart from this glitch :/ Jan 08 11:04:31 its actually only the X int gitrX+HASH that is the problem for defining PREF_VER Jan 08 11:04:50 XorA: no, its the HASH as well Jan 08 11:05:10 * broonie tends to agree with XorA re apt-getable OE - the source I want in my homedir anyway. Jan 08 11:05:14 RP: ah you talking about selecting an AUTREV version otherwise HASH is known Jan 08 11:05:36 XorA: I want the version where SRCREV = ${AUTOREV} Jan 08 11:05:37 XorA, broonie: I think you are not up to date with the latest (git-enabled) version Jan 08 11:06:07 Laibsch: very likely not as I stopped running debian based distros a while back Jan 08 11:06:40 mtn needed some "special" handling due to the time it consumed Jan 08 11:06:43 RP: trust you to make the perfect chicken and egg scenario Jan 08 11:06:45 hi all ! Jan 08 11:06:56 at least that is the reason for the choices I made IIRC Jan 08 11:08:05 RP: okay, fair enough. if it's going to be the policy that floating recipes must truly float, and automatic rebuilds need to work like that, then I agree we probably do need to keep the hash in PV. I still hate that wildcard patch on principle though. Jan 08 11:08:13 broonie: you asked about a meta-package with the necessary dependencies. You can use openembedded-common just for that if you don't like the rest. Jan 08 11:09:03 pb_: I'm not exactly keen Jan 08 11:09:22 RP: in the general case, the wildcard patch still doesn't help you since there might be multiple git versions in the repository. Jan 08 11:09:22 pb_: but I can't see another solution either Jan 08 11:09:38 at least, assuming I am understanding the use-case correctly. I'm guessing that you want to set P_V to "1.0+git%" or some such. Jan 08 11:09:42 pb_: right but probably not two floating ones Jan 08 11:09:52 pb_: yes Jan 08 11:11:12 pb_: Basically, I can live with that limitation since two fixed git revisions are probably from the same recipe anyway with fixed SRCREVs Jan 08 11:15:06 okay, fair enough. There are rather too many "probably"s in that for me to feel entirely comfortable relying on it, but I suspect you are right that it will not be too much of an issue in practice. Jan 08 11:15:22 (sorry for the delay there, I was on the phone for a moment) Jan 08 11:19:02 pb_: probably means "can always be arranged" in this case Jan 08 11:19:29 RP: how about, rather than encoding the actual git hash in ${PV}, going back to what we used to do with CVS and just encoding a timestamp there? That way you could always predict what it was going to be for the floating recipe. Jan 08 11:20:19 You'd still get auto-rebuilds, since the timestamp would be different on subsequent bitbake runs. Jan 08 11:21:57 To make it work reliably you'd probably need a bit of help from bitbake, in the form of a ${bb.get_start_time()} kind of function, but since the wildcard patch requires bitbake changes anyway that doesn't seem like too much of a hardship. Jan 08 11:30:16 pb_: You don't want rebuilds every time, just when the git hash changes Jan 08 11:34:08 RP: mm, right, that's true. I wonder whether that would be better achieved by some other mechanism, though: for example, you could arrange for the floating packages to check the current head rev prior to do_fetch(), and raise some suitable "BuildNotRequired" exception if it's the same as what was built previously. Jan 08 11:36:54 Or, going back to the original problem, another way of solving it would be to provide a way to specify that ${SRCREV} should be left unexpanded when comparing PV and P_V. I'm not sure how much surgery to bitbake internals would be required to keep the unexpanded one around long enough, though, so that might not be practical. Jan 08 11:47:06 03Koen Kooi  07org.openembedded.dev * r4fde7c59bf 10openembedded.git/recipes/xorg-driver/xf86-input-tslib_0.0.6.bb: Jan 08 11:47:06 xf86-input-tslib 0.0.6: remove patch and bump PR Jan 08 11:47:06 * the patch seems to cause more problems than it solves Jan 08 11:47:16 03Koen Kooi  07org.openembedded.dev * r3a9b352acb 10openembedded.git/recipes/xorg-xserver/xserver-xorg_1.7.3.bb: Jan 08 11:47:16 xserver-xorg 1.7.3: fix regression where hal was disabled Jan 08 11:47:16 * this fixes the "my touchscreen isn't working anymore" bug Jan 08 11:57:39 Laibsch: I think we should scratch gitweb -- keep things simple! Jan 08 11:57:56 Laibsch: (gitweb.oe.org) Jan 08 11:58:49 OK Jan 08 11:58:54 I will disable it, then Jan 08 11:59:00 What was it supposed to do? Jan 08 11:59:14 Provide some kind of backwards-compatible URLs? Jan 08 11:59:22 Laibsch: backwards compatibility when we switched to cgit Jan 08 11:59:31 I see Jan 08 11:59:33 that's been a while Jan 08 11:59:39 Laibsch: yes Jan 08 12:00:51 although, disabling the vhost doesn't really change the situation ;-) Jan 08 12:01:04 how to make some part of recipe conditional when normal overrides seems not enough? Like conditional inherit for u-a in .inc file from http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=2df4f2cfe72f40fb92c696674f2b3118ae386fab ? Jan 08 12:01:12 now it's the apache default definition serving that address Jan 08 12:01:26 JaMa: depending on what? Jan 08 12:01:37 Laibsch: some distro preference Jan 08 12:01:51 I still don't understand Jan 08 12:01:59 what do you want to change and depending on what Jan 08 12:02:21 XorA, Do you mean check compare the oe with the ubuntu /proc/config.gz ? Jan 08 12:02:29 JaMa: INHERIT = ""; INHERIT_shr = "u-a"; inherit ${INHERIT} Jan 08 12:02:43 Laibsch: ie if distro == shr, I would like to inherit the u-a and use u-a only for shr Jan 08 12:02:55 pb_: ah, thanks .. Jan 08 12:03:33 I'm not actually certain whether that will work, but I think that is as close as it gets. Jan 08 12:03:52 , Jan 08 12:04:22 , Jan 08 12:04:27 sorry Jan 08 12:04:29 03Koen Kooi  07org.openembedded.dev * r78ddfea284 10openembedded.git/recipes/linux/ (3 files in 2 dirs): linux-omap-zoomsync: add 2.6.32 recipe, fix dss-doc packaging Jan 08 12:04:32 03Koen Kooi  07org.openembedded.dev * r61f4bbb477 10openembedded.git/recipes/pulseaudio/libcanberra_0.17.bb: libcanberra 0.17: bump PR Jan 08 12:04:41 pb_: I'll try Jan 08 12:12:38 unfortunately there is no /proc/config.gz either in the ubuntu installation or in the oe Jan 08 12:15:00 JaMa: In case it does not work I have another idea Jan 08 12:15:08 but the override is much easier Jan 08 12:25:41 03Koen Kooi  07org.openembedded.dev * rbd69ee7dac 10openembedded.git/recipes/linux/linux-omap-zoomsync/omapzoom2/defconfig: linux-omap-zoomsync 2.6.31: enable cpufreq, cpuidle, powertop options and fix XV Jan 08 12:26:02 pb_: Keeping unexpanded variables around already happens I think Jan 08 12:26:08 * RP ponders Jan 08 12:26:42 03Koen Kooi  07org.openembedded.dev * r26672294a0 10openembedded.git/conf/machine/include/omap3.inc: omap3 machines: bump MACHINE_KERNEL_PR Jan 08 12:27:44 there is even BIGGER problem with u-a scripts :/ Jan 08 12:28:17 old u-a-cworth installs alternatives to /usr/lib/ipkg/alternatives/init and opkg to /usr/lib/opkg/alternatives/init Jan 08 12:28:49 so if we kill u-a-cworth in our images and users remove it from their already installed systems Jan 08 12:29:06 then it can end like this http://pastebin.com/d4daa32a4 Jan 08 12:29:43 well, yes, if you are migrating from one u-a to another then you need to take the appropriate precautions. Jan 08 12:30:00 and with busybox upgrade old symlinks like /sbin/init.sysvinit with higher priority is replaced with one to busybox Jan 08 12:30:34 pb_: but u-a-cworth is imho installed by default in all images with task-boot Jan 08 12:30:49 pb_: as well as new opkg which has u-a script too Jan 08 12:31:08 pb_: one is in /usr/bin 2nd in /usr/sbin Jan 08 12:31:12 ah. well, that sounds like it is just a bug in task-boot. Jan 08 12:31:25 so its quite easy to break stuff Jan 08 12:32:01 and fixing that (shipping only u-a with opkg) can make things worse on installed devices.. Jan 08 12:33:12 yeah, it is a shame that task-boot has gotten into that state. still, as I say, if you (with your DISTRO hat on) are doing something that will cause a different u-a to start being used, it's up to you to put in place some appropriate measures to prevent it being a problem. Jan 08 12:34:06 Is there any documentation on how to configure the kernel in OE? Jan 08 12:34:25 hrw|gone: you asked about u-a yesterday.. so maybe this ^^^ will be interesting for you Jan 08 12:35:25 jovox: bitbake -c menuconfig virtual/kernel Jan 08 12:35:34 standard linux menuconfig Jan 08 12:38:18 eFfeM, that needs X? Jan 08 12:40:01 jovox: no, only ncurses Jan 08 12:40:26 thinking of it, it may launch an xterm Jan 08 12:40:27 eFfeM: It could need X for the terminal Jan 08 12:40:34 yeah Jan 08 12:40:57 jovox: you can specify different terminal for that.. ie screen in bitbake.conf Jan 08 12:40:59 if you do not want that go to the work dir for the kernel and do Jan 08 12:41:10 ARCH=arm make menuconfig Jan 08 12:41:22 ofc substitute for arm what your arch is Jan 08 12:41:43 pb_: ERROR: Could not inherit file classes/.bbclass while parsing /home/projects/OE/dev/recipes/gpe-icons/gpe-icons_0.25.bb Jan 08 12:42:00 JaMa: ah, drat. Jan 08 12:42:10 pb_: so it needs some dummy bbclass for empty INHERIT but its weird Jan 08 12:42:34 you say "work dir". is that openembedded/recipes/linux/linux-{version} ? Jan 08 12:42:57 pb_: I can use INHERIT = "gpe" INHERIT_shr = "gpe u-a" ... Jan 08 12:47:00 there are quite a few defconfigs for diffrent machines. I'm building for x86 and it's not quite clear to me which what is being used Jan 08 12:47:49 openembedded/recipes/linux/x86/defconfig ? Jan 08 12:50:14 pb_: just a note.. PREFERRED_PROVIDER_virtual/update-alternatives-native setting in sane-feed-ipk.inc needs to be in sync with u-a script installed with image.. with is not now.. Jan 08 12:50:37 pb_: I've broken it with compatibility-providers.conf probably :( Jan 08 12:57:07 hm, not fully oe, but probably drop it here; the bitbake-dev archive stops at dec 2009 :-( wanted to see if there was a reply thre on my email Jan 08 13:03:49 good morning Jan 08 13:06:07 morning mckoan Jan 08 13:07:17 JFTR, OE still runs fine with about half a gig of RAM. I would have been really saddened if everybody had to have a beefy machine like pb. Jan 08 13:07:35 very good Jan 08 13:07:59 I dare to guess it would even run with 256MB of real RAM Jan 08 13:08:02 single-process Jan 08 13:12:49 JaMa, where in bitbake.conf is the terminal specified? Jan 08 13:16:52 JaMa: any idea about libfsobasics? Jan 08 13:18:53 Laibsch: mickey said yesterday that newer vala release which I bumped as fix to fsonetworkd, broken gsmd and that he already has patch for that and will deploy new vala relase soon, maybe its related to libfsobasics (because it built ok just before that vala bump - I haven't rebuild whole fso* fater bumping vala.. just that fsonetworkd..:/) Jan 08 13:21:15 JaMa: looking at tinderbox it seems you were building a specific version and not head Jan 08 13:22:05 although the commit-string looks identical Jan 08 13:22:29 but for me it was r70 while it was r19 for you. whatever that means Jan 08 13:23:40 03Koen Kooi  07org.openembedded.dev * rff17a06fbd 10openembedded.git/recipes/e17/e-wm_svn.bb: e-wm: package illume-home config in ${PN} for the time being Jan 08 13:25:21 Laibsch: that's the same revision as you have.. Jan 08 13:25:28 OK Jan 08 13:25:29 Laibsch: but I'm using SRCPV.. Jan 08 13:25:33 I'll have to wait, then Jan 08 14:01:32 kergoth: good morning Jan 08 14:02:19 hey pb_ Jan 08 14:08:10 pb_: hi, about xtscal, I noticed that the last config where it worked were based on xserver-kdrive Jan 08 14:08:31 pb_: for example the last one was xserver-kdrive-1.4.0.90 Jan 08 14:09:28 pb_: in xserver-xorg_1.7.3.bb there is not libxcalibrate neither enable-xcalibrate.patch Jan 08 14:09:50 pb_: do you think would be a good idea to add them in xserver-xorg_1.7.3.bb ? Jan 08 14:09:54 you wouldn't expect to find libxcalibrate in the server Jan 08 14:10:01 that library is only used by the client (i.e. xtscal) Jan 08 14:10:29 I don't know offhand what enable-xcalibrate.patch does, but it sounds like it would be a good idea to at least investigate adding it to the new server. Jan 08 14:10:44 pb_: fine thx Jan 08 14:13:08 pb_: what is the suggested way to work on an existing package in OE, for example I want to modify some files in xorg-server/mi/miinitext.c or maybe adding some printf in xtscal-0.6.3 Jan 08 14:13:29 pb_: should I work in staging dir ? Jan 08 14:13:56 yeah, that's what i would do. see devshell for example. Jan 08 14:14:18 pb_: yep Jan 08 14:21:36 The kernel that is built is 2.6.25.20, how can I make it build newer version? Jan 08 14:22:34 mckoan: I worked yesterday on same stuff Jan 08 14:22:41 morning Jan 08 14:23:36 mckoan: I gave up and I am not first one :( Jan 08 14:27:55 has anyone worked with cameras and the beagleboard? Jan 08 14:32:54 mickey|office: good afternoon Jan 08 14:33:14 good afternoon pb_ Jan 08 14:35:36 http://pastebin.com/md1cb852 -- error I get when I plug in my lifecam Jan 08 14:35:42 anyone have any ideas? Jan 08 14:40:15 * jovox sighs Jan 08 14:44:41 No matter how much googeling I do I still can't find out how to specify the kernel version :( Jan 08 14:54:55 bye Jan 08 14:59:48 jovox: what distro, what machine? Jan 08 15:00:35 angstrom/x86 Jan 08 15:02:08 Have you looked in the machine definition inside conf/machine/? Jan 08 15:02:18 Or it may be specified in the kenel recipes itself Jan 08 15:02:21 I'm not sure Jan 08 15:02:29 Those are the two places I would look first Jan 08 15:02:53 DEFAULT_PREFERENCE_x86 in the kernel recipe you want built may be all you need Jan 08 15:03:03 hrw|gone: I can't give up Jan 08 15:03:03 "DEFAULT_PREFERENCE_x86 = 1" in the kernel recipe you want built may be all you need Jan 08 15:03:30 hrw|gone: would be useful to know what you did in order to avoid to do the same twice Jan 08 15:04:37 Laibsch, I looked in the conf/machine/x86.conf and there is OLDEST_KERNEL var. Jan 08 15:04:59 I think that is something else Jan 08 15:05:02 it points out 2.6.17 which isn't the one that is being built Jan 08 15:05:03 ok Jan 08 15:05:09 That defines the mimimum Jan 08 15:05:12 ok Jan 08 15:06:30 you say I should add DEFAULT_PREFERENCE_x86 = 1 to "any" kernel recipe I want to build? Jan 08 15:07:22 ie linux_2.6.29.bb Jan 08 15:09:05 Laibsch, But what makes it pick 2.6.25.20? Jan 08 15:09:06 mckoan: check files/enable-calibrate.diff used by xserver-xorg 1.4.2 - you need to have "#define XCALIBRATE 1" in include/xorg-config.h after configure step (need to edit include/xorg-config.h.in before) Jan 08 15:12:00 hrw|gone: thx, I'm alredy on miinitext.c stuff Jan 08 15:12:20 jovox: that is probably the highest version without -1 Jan 08 15:12:23 Just try it Jan 08 15:12:34 hmm ok I will Jan 08 15:28:41 Laibsch: hello! Jan 08 15:35:39 jeremy_laine: Hi Jan 08 15:35:41 Ca va? Jan 08 15:38:15 Laibsch: oui tres bien merci :) bonne année! Jan 08 15:38:47 a toi aussi. Thank you very much for the recent fixes to the tinderbox code in django-oestats Jan 08 15:38:52 Laibsch: I am trying to close some tinderbox bugs, so I'm making my way down the list Jan 08 15:39:01 Yes, I noticed Jan 08 15:39:03 ;-) Jan 08 15:39:20 Laibsch: for the build ID, I have never been happy with the current solution Jan 08 15:39:59 Laibsch: the idea of adding the PID to the filename would help, but I'm not sure how to clean up the PID after a build if the name keeps changing Jan 08 15:40:23 maybe we need an "oestats" directory in tmp/ to avoid cluttering up tmp? Jan 08 15:43:33 hello Jan 08 15:44:56 i have a question about bitbake Jan 08 15:45:05 am i on the right chan ? Jan 08 15:49:05 bitbake gives me the error ERROR: Please set the 'PERSISTENT_DIR' or 'CACHE' variable. Jan 08 15:49:28 i tried setting it in local.conf or in my env Jan 08 15:49:34 but still the same Jan 08 15:49:44 am i missing a place to set this ? Jan 08 15:53:20 your BBPATH isn't set correctly. Jan 08 15:53:36 it's falling back to the conf/bitbake.conf included with bitbake rather than the one it should be using, in the OE directory Jan 08 16:00:34 thanks kergoth Jan 08 16:02:29 np Jan 08 17:09:51 the qemuarm machine definition does not have the XSERVER variable set and that is creating problems. What would be an appropriate setting here? Jan 08 17:24:13 how can I rebuild an image from scratch without deleting tmp? -cclean an then -cbuild ? Jan 08 17:24:34 what do you mean? Jan 08 17:24:42 images are always rebuilt Jan 08 17:24:59 if you want to rebuild everything that *goes into an image*, that's different. clean cleans *one* recipe, the one you request only, not its dependencies Jan 08 17:25:07 if you want to clean something with its deps, use -c cleanall Jan 08 17:26:09 looks like I did something wrong in angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/xserver-xorg-2_1.7.3-r3 Jan 08 17:27:00 and looks that if I do bitbake -cclean x11-image && bitbake x11-image I get always the old image Jan 08 17:27:23 in tis case I usually delete tmp Jan 08 17:27:36 but I dont want to do that now Jan 08 17:28:12 no, the image rootfs dir is *always* wiped Jan 08 17:28:17 and repopulated Jan 08 17:31:10 Laibsch: either xserver-kdrive-fbdev or xserver-xorg, I guess. Jan 08 17:31:48 kergoth: where is the the image rootfs dir ? Jan 08 17:31:59 bitbake -e x11-image|grep \^IMAGE_ROOTFS= Jan 08 17:32:26 pb_: kdrive does not compile for me and the reason I want to have it explicitly set Jan 08 17:34:03 Laibsch: er, why did you ask the question then? if you don't want to use kdrive, I don't think there are any other choices apart from xorg. Jan 08 17:35:06 I'm wondering about the exact correct setting for XSERVER var. Take a look at spitz for example. It does not seem to be either xserver-kdrive or xserver-xorg only Jan 08 17:35:24 I'm not familiar so I better ask, I guess Jan 08 17:36:03 it's xorg and the xorg modules you need for that hardware Jan 08 17:36:26 Laibsch: I would use xorg too Jan 08 17:36:42 thanks all for your support, have a nice rest of the day Jan 08 17:37:30 kergoth: do you happen to know if there are any modules needed? Jan 08 17:38:57 Any setting for PREFERRED_PROVIDER_virtual/libgl? Jan 08 17:55:44 03Michael 'Mickey' Lauer  07org.openembedded.dev * r8e2871088d 10openembedded.git/ (3 files in 2 dirs): vala: bump to 0.7.9.5 which fixes a regression in type comparison Jan 08 18:00:28 Laibsch: not very familiar with that machine, or the particulars of what hardware qemu emulates Jan 08 18:02:53 isn't kdrive going away? Jan 08 18:03:01 iirc, from some comment in an angstrom conf Jan 08 18:11:35 Tartarus: it's basically unmaintained upstream, but it does still have some attractions compared to xorg and I doubt it will disappear altogether. Jan 08 18:14:23 if you're talking about kdrive I've a question Jan 08 18:14:43 can xorg with xf86-video-fbdev handle xrandr -o 1? Jan 08 18:19:55 Is OE suitable for building an image for an x86-based device on an x86 host OS? i.e. no real cross-compile Jan 08 18:21:13 MattCampbell: yes, you can do that Jan 08 18:23:11 MattCampbell, I did that for an eeepc 701 target Jan 08 18:24:00 GNUtoo|oeee: Cool, my target is also Atom-based. Jan 08 18:24:06 ok Jan 08 18:24:55 I should fnish my kernel config tough...so I could commit the machine config Jan 08 18:25:16 Note that it will still act like a cross compile Jan 08 18:25:21 it won't use /usr/bin/gcc & co Jan 08 18:26:00 Understood. Jan 08 18:26:35 I've worked with OE before, with an ARM-based PDA as the target. Jan 08 18:26:53 But most of that work was a few years ago. Jan 08 18:27:41 Is there anything special I have to do so OE doesn't get confused between packages for the target and "native" packages (those that are installed in staging)? Jan 08 18:27:50 Nope Jan 08 18:27:55 it all just works Jan 08 18:28:13 i think there's even an atom machine conf file or two around Jan 08 18:28:44 I'm sure the toolchain will still take forever to compile. Jan 08 18:28:56 But I like the level of customizability OE provides. Jan 08 18:29:10 it's all relative, but yeah, gcc & such from scratch Jan 08 18:29:18 Are there any current distro configs that use Upstart instead of SysVinit? Jan 08 18:29:59 not sure, but, wrt build time, did you use threads / parallel make before? Jan 08 18:30:07 and do you have a faster box this time around? :) Jan 08 18:30:24 Much faster Jan 08 18:30:30 Well, more cores anyway Jan 08 18:30:48 Make sure you set BB_NUMBER_THREADS / PARALLEL_MAKE Jan 08 18:31:04 I do threads = number cpus, make = number cpus * 1.5 Jan 08 18:31:09 and then try and not be interactive on that box Jan 08 18:31:18 thanks Jan 08 18:31:45 Well I'm stuck with Windows as the host system on this box (job requirements), so the build system will actually be a VM Jan 08 18:33:14 Don't feel like uplifting the cygwin patches? :) Jan 08 18:36:24 what about colinux? Jan 08 18:36:32 I got a deadline, man. :) Jan 08 18:36:38 But not for a few days Jan 08 18:36:46 k Jan 08 18:36:50 As long as I've got a first image tonight I'll be fine Jan 08 18:37:06 Colinux? My host system is x86-64 Jan 08 18:37:13 ok Jan 08 18:37:16 Nah, I already have an Ubuntu VM running Jan 08 18:37:48 Ubuntu server, no GUI Jan 08 18:38:03 ok Jan 08 18:38:33 the GUI is not started either on my build system Jan 08 18:39:49 BTW, it occurred to me that OE would probably be a better base for Google Chrome OS than Ubuntu Jan 08 18:40:13 Currently they start with Ubuntu, replace some base packages with their own versions, and have a collection of shell scripts for building the packages and image. Jan 08 18:41:06 * * OE Bug 5333 has been RESOLVED (FIXED) by quickx(AT)hotmail.com Jan 08 18:41:08 * * at91sam9261ek Build Fails at sqlite3 Jan 08 18:41:08 mmm Jan 08 18:41:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5333 Jan 08 18:41:37 For my own project, I want to handle the root FS and the software update process like Chrome OS does. That is, the root FS will be read-only and completely replaced with a new image when an update is installed. Jan 08 18:41:54 I dont't know chrome but...I wonder how they reproduce their build if the host is different Jan 08 18:42:36 Never mind, I'm going to get to work. Jan 08 18:43:08 ok Jan 08 18:43:14 GNUtoo|oeee: You mentioned a custom kernel. Do you think this kernel would be suitable for any Atom-based machine? Jan 08 18:43:38 MattCampbell, if you want I can try to finish mine this night Jan 08 18:44:12 and I mentionned a custom *defconfig* Jan 08 18:44:27 ah Jan 08 18:44:36 that is .config Jan 08 18:44:56 Stock source tree then? Jan 08 18:44:57 for the kernel I used 2.6.32 Jan 08 18:45:00 yes Jan 08 18:45:03 vanilla Jan 08 18:45:27 I'd like to see your .config, but my requirements may be different. Jan 08 18:45:35 ok Jan 08 18:45:55 Laibsch: mickey's vala bump fixed libfsobasics.. http://tinderbox.openembedded.net/packages/libfsobasics/ Jan 08 18:45:58 My target machine will be headless. Basically a network appliance. Jan 08 18:47:12 basically I removed what can't work,for instance if I have no pci cards slot I wont include support for a particular pci card that is not embedded inside the hardware Jan 08 18:48:05 makes sense Jan 08 18:48:10 Then I'll probably just do my own config Jan 08 18:48:24 ok Jan 08 18:48:34 so do you need my config? Jan 08 18:49:02 note that the networking section has not been done yet Jan 08 18:49:03 No Jan 08 18:49:26 One more question though: Where can I find the optimal GCC flags for the Atom? Jan 08 18:49:30 ok Jan 08 18:49:35 in the man Jan 08 18:49:39 but... Jan 08 18:49:43 don't do that Jan 08 18:49:47 use i686 Jan 08 18:49:55 it'll be more compatible Jan 08 18:49:55 OK Jan 08 18:50:05 do that only for the kernel Jan 08 18:50:18 because i686 is meant to be shared amongst machines Jan 08 18:50:37 not eee701 directory which contains the kernel etc... Jan 08 18:51:11 OK, thanks for the help. Jan 08 18:51:35 maybe I should verify what it does if you include too much specific things tough Jan 08 19:00:11 JaMa: Thank you for confirming. I was already on my way confirming myself. Jan 08 19:00:24 But I restarted from scratch and it will take a little while. Jan 08 19:01:38 :) I just cleaned all freesmartphone/*.bb Jan 08 19:07:47 there's no harm in selecting atom-specific optimisations if the atom is the only cpu that you care about. Jan 08 19:08:21 building for generic i686 makes sense if you plan to install your binaries on multiple machines, but there is no advantage in doing that if you are just targetting a single platform. Jan 08 19:08:40 I would suggest to add a new machine conf for atom Jan 08 19:09:06 * * OE Bug 5367 has been RESOLVED (FIXED) by Jan 08 19:09:08 * * libfsoframework fails to build Jan 08 19:09:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5367 Jan 08 19:09:57 gm all Jan 08 19:10:09 JaMa: I was experiencing some strange build issues and decided it was easier to just restart from scratch. not related to libfso at all in this case. Jan 08 19:10:17 khem: good night, how are you doing? Jan 08 19:10:47 Laibsch: I am good. Good night to you Jan 08 19:12:43 pb__: I do intend to target only one platform. Is it not normal to optimize an OE-built image for a particular machine? Jan 08 19:13:28 MattCampbell: yes, it is quite normal to optimize an image for one machine. Jan 08 19:15:05 apropos cflags, it looks like your best choice would be to use a gcc-4.5 snapshot (if we have a suitable one in oe) which supports "-mtune=atom". Jan 08 19:16:05 OK, I don't care that much about a super-optimized build. Jan 08 19:16:12 I'll use whatever toolchain is best-tested for x86 targets. Jan 08 19:18:26 btw no-one knows how to have xrandr -o 1 under xf86-video-fbdev? Jan 08 19:19:18 hey kergoth? Jan 08 19:19:51 GNUtoo: I think you made a typo when joining the channel. this is #oe, not #xorg Jan 08 19:20:05 * * OE Bug 5337 has been RESOLVED (INVALID) by Jan 08 19:20:07 * * Error unpacking ../../openembedded/recipes/linux/linux-omap-2.6-2.6.9-omap1/defconfig Jan 08 19:20:09 * * http://bugs.openembedded.net/show_bug.cgi?id=5337 Jan 08 19:22:11 you were talking about kdrive Jan 08 19:22:17 ok I'll ask in xorg again Jan 08 19:22:29 hoping that there is someone Jan 08 19:22:38 that will respond Jan 08 19:23:06 sorry for asking btw Jan 08 19:23:45 basically it was for htcdream and bug device machines Jan 08 19:23:50 you don't need to apologise for asking, but I don't think it will help to keep asking repeatedly. Jan 08 19:24:29 if anybody had known the answer, they probably would have answered the first time you asked. Jan 08 19:24:56 ok thanks Jan 08 19:26:50 GNUtoo|oeee: I'd like to test your Atom targeted image Jan 08 19:27:23 Does anyone know if TOOLCHAIN_OPTIONS is used by something external to OE? Jan 08 19:27:57 I'm using it atm to pass in --sysroot= to all the tools that need it (so we can use sysroot happy gcc-cross and reuse it all when TMPDIR changes) Jan 08 19:29:30 Tartarus: pong Jan 08 19:30:08 mckoan,eeepc701 is not atom Jan 08 19:30:09 kergoth, looking at an email you sent back in sept where you mention conf/amend-recipe.inc, but I don't see that in the metadata anywhere Jan 08 19:30:15 Or is that just magically handled somehow? Jan 08 19:30:29 hmm, might not have pushed it :) i have a huge backlog Jan 08 19:30:36 mckoan, it's celeron M based Jan 08 19:30:38 oh, i remember what the issue was Jan 08 19:30:57 mckoan, and I'll try to finish to push all resting fixes Jan 08 19:31:04 Tartarus: the issue was the cache. with the original version, adding a new amend.inc for a recipe didn't invalidate the recipe's cache, so you'd have to touch the recipe to get it to parse and include the amended changes Jan 08 19:31:33 Ah Jan 08 19:31:40 Tartarus: i altered it to inject all possible amend.incs into the bitbake __depends list, but you need a bitbake which has a fix, otherwise that add to __depends results in a full reparse every bitbake execution Jan 08 19:31:47 Tartarus: some recipes ffmpeg mythtv seems to use it Jan 08 19:31:50 GNUtoo|oeee: I misunderstood the CPU type but I'd like to test it Jan 08 19:31:56 Tartarus: but I think it should be harmless Jan 08 19:32:00 given OE requires a recent 1.8 now, it could be thats a nonissue now, would have to check Jan 08 19:32:30 ok Jan 08 19:32:50 GNUtoo|oeee: could you please tell me details about distro/machine/mage to use once you push it? Jan 08 19:32:52 mckoan, kernel config is incomplete for now Jan 08 19:33:06 mckoan, machine.conf is in the ml Jan 08 19:33:58 mckoan, distro: angstrom-2008.1 image: xfce46-image Jan 08 19:34:05 * * OE Bug 5330 has been RESOLVED (INVALID) by Jan 08 19:34:06 * * Problem with building kernel image Jan 08 19:34:08 * * http://bugs.openembedded.net/show_bug.cgi?id=5330 Jan 08 19:34:12 mckoan, result : about 300M Jan 08 19:34:26 kergoth, what i'm really trying to do is for example not copy every part of gcc into my overlay, just the inc file I'm modifying, for example Jan 08 19:34:36 and I think, from the email example anyhow, that could work Jan 08 19:34:37 that is to say http://scap.linuxtogo.org/files/94eda4fdaa0c38aa4c5a6f8f9f7a503d.png Jan 08 19:34:58 ah, yeah, thats the kind of thing its made for Jan 08 19:35:20 mvl6 actually uses amend.inc for every one of our changes against OE, so the recipes match OE as of the last sync.. makes it easier to update, just copy over the new bits Jan 08 19:35:36 khem: Can you take another look at Jan 08 19:35:39 !oebug 5332 Jan 08 19:35:41 * * Bug 5332, Status: UNCONFIRMED, Created: 2009-11-05 11:51 Jan 08 19:35:42 * * ospite(AT)studenti.unina.it: building ncurses triggers an internal compiler error Jan 08 19:35:43 * * http://bugs.openembedded.org/show_bug.cgi?id=5332 Jan 08 19:35:44 GNUtoo|oeee: which thread in ML? Jan 08 19:35:44 ? Jan 08 19:35:51 mckoan, I'll look Jan 08 19:39:42 Laibsch: yeah I think I should CC myself on the bugs where I ask for info Jan 08 19:39:43 mckoan, [oe] ro/rw boot order Jan 08 19:39:46 I just replied Jan 08 19:41:05 thanks, khem. Just set them to NEEDSINFO and somebody will pick them up. I have a saved search in bugzilla that sort them with the ones longest not touched sorted at the top. I go through them ever once in a while. Jan 08 19:41:53 Laibsch: nice Jan 08 19:42:21 Laibsch: but I got different libfsobasics error now.. after rebuilding all freesmartphone recipes .. http://tinderbox.openembedded.net/packages/411399/ Jan 08 19:42:28 khem: http://tinyurl.com/yho7786 in case you are interested Jan 08 19:46:06 * * OE Bug 5362 has been RESOLVED (FIXED) by raj.khem(AT)gmail.com Jan 08 19:46:08 * * compilation of gcc-cross-intermediate-4.4.2 failed due to lack of fenv.h Jan 08 19:46:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5362 Jan 08 19:46:18 * * OE Bug 5288 has been RESOLVED (INVALID) by Jan 08 19:46:20 * * md5/sha256 checksum mismatch for alsa-utils-1.0.20 Jan 08 19:46:22 * * http://bugs.openembedded.net/show_bug.cgi?id=5288 Jan 08 19:47:11 GNUtoo: thx, I'll try ASAP Jan 08 19:47:19 ok Jan 08 19:47:30 Laibsch: thx I saved your query as well its handy :) Jan 08 19:47:33 if you want more infos such as kenrel config or fixes just ask Jan 08 19:47:39 but kernel config is machine specific Jan 08 19:47:49 GNUtoo: no prob Jan 08 19:49:13 kergoth: I did bitbake -e x11-image|grep \^IMAGE_ROOTFS= Jan 08 19:49:30 IMAGE_ROOTFS="/home/koan/devel/build/angstrom/tmp/rootfs/x11-image" Jan 08 19:49:39 /home/koan/devel/build/angstrom/tmp/rootfs/x11-image: No such file or directory Jan 08 19:50:05 * * OE Bug 4388 has been RESOLVED (FIXED) by raj.khem(AT)gmail.com Jan 08 19:50:07 * * -march=k6-2: fnstsw broken in binutils 2.18.50.0.7 (triggered by glibc-intermediate 2.6.1) Jan 08 19:50:09 * * http://bugs.openembedded.net/show_bug.cgi?id=4388 Jan 08 19:51:35 mckoan: yes.. and? Jan 08 19:52:04 kergoth: where is the the image rootfs dir ? Jan 08 19:52:13 what are you talking about? Jan 08 19:52:13 kergoth: :-) Jan 08 19:52:19 the image class uses that dir to build the image Jan 08 19:52:26 i didn't say it would live there forever Jan 08 19:52:33 i don't see why you'd want it to Jan 08 19:52:36 kergoth: looks like there is nothing Jan 08 19:52:41 and? Jan 08 19:52:48 who cares? Jan 08 19:52:58 again, its used to build the image, thats all. Jan 08 19:53:34 kergoth: I'd like to see a place where the target fs exist before creating jffs2 Jan 08 19:53:41 03Martin Jansa  07org.openembedded.dev * r0f5fd96b66 10openembedded.git/conf/distro/shr.conf: Jan 08 19:53:41 shr.conf: switch to release DISTRO_TYPE Jan 08 19:53:41 Signed-off-by: Martin Jansa Jan 08 19:53:44 03Martin Jansa  07org.openembedded.dev * r1f191e529e 10openembedded.git/recipes/gpe-icons/ (gpe-icons.inc gpe-icons_0.25.bb): Jan 08 19:53:44 gpe-icons: use u-a and postinst merger for gpe-icons only for SHR Jan 08 19:53:46 Signed-off-by: Martin Jansa Jan 08 19:53:48 03Martin Jansa  07org.openembedded.dev * rca36362ebd 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Jan 08 19:53:51 shr-theme: bump srcrev for navitD icon Jan 08 19:53:53 mckoan: why? that dir isn't usable as a filesystem anyway, its built with fakeroot Jan 08 19:53:53 Signed-off-by: Martin Jansa Jan 08 19:53:54 kergoth: I thought you knew where it is Jan 08 19:53:55 03Martin Jansa  07org.openembedded.dev * rb24aa1e191 10openembedded.git/recipes/linux/linux-openmoko-2.6.32_git.bb: Jan 08 19:53:58 linux-openmoko-2.6.32: update to 2.6.32.3 Jan 08 19:54:00 Signed-off-by: Martin Jansa Jan 08 19:54:00 mckoan: just add tar.gz to IMAGE_FSTYPES and unpack it Jan 08 19:54:13 kergoth: I understand, thx Jan 08 19:54:19 mckoan: i do know where it is, and i'm telling you it doesn't have to keep it around, it wipes it every time it builds an image Jan 08 19:54:41 which is what i was telling you earlier, you dont have to -c clean, every time you build an image it starts fresh and repopulates the filesystem Jan 08 19:55:13 kergoth: thx Chris :-) Jan 08 19:55:16 np Jan 08 19:55:32 it used to be that dir was removed at the beginning of the process, not the end, but it could be it does so both now Jan 08 19:56:58 np Jan 08 19:57:03 erm, wrong window Jan 08 20:18:12 03Martin Jansa  07org.openembedded.dev * rf0ff8d706c 10openembedded.git/recipes/gpe-icons/gpe-icons.inc: gpe-icons.inc: readd gpe inherit for shr Jan 08 20:23:23 re Jan 08 20:36:52 03Koen Kooi  07org.openembedded.dev * r68be910ff1 10openembedded.git/recipes/u-boot/ (9 files in 2 dirs): u-boot git: update beagleboard uboot for rev C4 Jan 08 20:40:25 re Jan 08 20:41:23 hi hrw Jan 08 22:21:00 03Khem Raj  07org.openembedded.dev * r4952f80b09 10openembedded.git/site/mips-linux-uclibc: Jan 08 22:21:00 mips-linux-uclibc: Add mips linux siteinfo for ucliibc. Jan 08 22:21:00 Signed-off-by: Khem Raj Jan 08 22:21:01 03Khem Raj  07org.openembedded.dev * rdecb589caa 10openembedded.git/recipes/gcc/gcc-svn.inc: Jan 08 22:21:03 gcc-svn.inc: Bump SRCREV now it can build and run qemux86 image Jan 08 22:21:05 Signed-off-by: Khem Raj Jan 08 22:21:07 03Khem Raj  07org.openembedded.dev * rc38a0f150a 10openembedded.git/recipes/uclibc/uclibc-nptl/ (qemumips/uClibc.machine qemux86/uClibc.machine): Jan 08 22:21:10 uclibc-nptl: Add machine config parts for mips,x86 qemu. Jan 08 22:21:12 Signed-off-by: Khem Raj Jan 08 22:21:14 03Philip Black  07org.openembedded.dev * r70ff05efe0 10openembedded.git/conf/machine/dm365-evm.conf: Jan 08 22:21:19 dm365-evm.conf: Call UBOOT_MACHINE davinci_dm365_evm_config on DM365 DVM Jan 08 22:21:21 * The machine conf for the davinci dm365 EVM board was wrong. Jan 08 22:21:23 This patch fixes it. Jan 08 22:21:25 Signed-off-by: Khem Raj Jan 08 22:21:27 03Khem Raj  07org.openembedded.dev * r3f4cd310ac 10openembedded.git/recipes/proxy-libintl/proxy-libintl_20080418.bb: Jan 08 22:21:30 proxy-libintl_20080418.bb: Add -fPIC to CFLAGS for mips. Jan 08 22:21:32 Signed-off-by: Khem Raj Jan 08 22:36:42 03Klaus Kurzmann  07org.openembedded.dev * r220405a055 10openembedded.git/recipes/freesmartphone/ (3 files in 3 dirs): Jan 08 22:36:42 fsousaged: add a general config file and one for om-gta02 machine Jan 08 22:36:42 Signed-off-by: Klaus Kurzmann Jan 08 22:36:45 03Klaus Kurzmann  07org.openembedded.dev * r6af085bc26 10openembedded.git/recipes/freesmartphone/ (3 files in 3 dirs): Jan 08 22:36:45 fsodeviced: add a general config file and one for om-gta02 machine Jan 08 22:36:47 Signed-off-by: Klaus Kurzmann Jan 08 22:36:49 03Klaus Kurzmann  07org.openembedded.dev * r8ae6638c4e 10openembedded.git/recipes/freesmartphone/ (fsonetworkd/fsonetworkd.conf fsonetworkd_git.bb): Jan 08 22:36:52 fsonetworkd: add a config file Jan 08 22:36:54 Signed-off-by: Klaus Kurzmann Jan 08 22:44:12 jo Jan 08 22:49:10 ~awake Jan 08 22:49:11 It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shakes, the shakes become a warning. It is by caffeine alone I set my mind in motion. Jan 08 23:00:46 woglinde:wie gehtss Jan 08 23:01:36 khem I am now testing Jan 08 23:01:42 http://git.pokylinux.org/cgit.cgi/poky/plain/meta/packages/gettext/gettext_0.17.bb Jan 08 23:01:59 some one should start rp's good work Jan 08 23:02:09 good Jan 08 23:02:30 firs I will convert it to BBCLASSEXTEND Jan 08 23:02:32 I am trying to see mips/uclibc-nptl Jan 08 23:02:36 jupp Jan 08 23:02:43 and its horribly broken atm Jan 08 23:02:45 I saw this on commits and uclibc ml Jan 08 23:03:07 second step diff size btw. proxy-libintl Jan 08 23:03:12 and gettext libintl Jan 08 23:03:34 but atleast I have a console-image that compiles with uclibc-nptl for mips Jan 08 23:04:12 hm okay Jan 08 23:04:22 proxy-libintl is 5432 Jan 08 23:04:24 bytes Jan 08 23:04:28 on uclibc Jan 08 23:04:59 in next life I would not want to be debug uclibc Jan 08 23:05:16 but I had a package which didnt work with proxy-libintl Jan 08 23:05:32 didnt remember what it was Jan 08 23:06:06 woglinde: hmm make notes Jan 08 23:06:51 sure Jan 08 23:09:16 * khem hugs qemu Jan 08 23:09:22 *g* Jan 08 23:22:47 hm libintl from has 30k Jan 08 23:22:51 ups gettext Jan 08 23:23:56 woglinde: difference of about 20kb Jan 08 23:24:53 jupp :( Jan 08 23:28:00 hmm I would keep using proxy Jan 08 23:28:11 and fix it for the apps that dont build against it Jan 08 23:28:19 I could build console-image ok Jan 08 23:33:21 03Klaus Kurzmann  07org.openembedded.dev * r83bbeb2722 10openembedded.git/recipes/freesmartphone/ (fsodeviced/fsodeviced.conf fsodeviced_git.bb): Jan 08 23:33:21 fsodeviced: fix parsing error and disable accel and rfkill Jan 08 23:33:21 in om-gta02 config as fsodeviced segfaults with one of Jan 08 23:33:21 those two enabled. Jan 08 23:33:21 Signed-off-by: Klaus Kurzmann Jan 09 00:30:50 cbrake, mickeyl: I managed to get the wiki dump working on melo: http://oe-wiki.leggewie.org/ There are still a few rough edges in the layout. cbrake, I think you are more knowledgeable about that, aren't you? Jan 09 00:32:12 Hm, well I rejoiced too soon. It looks like anything but the start page is still broken Jan 09 01:41:18 03Martin Jansa  07org.openembedded.dev * r814f07a935 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Jan 09 01:41:18 shr: temporary disable libsdl-ttf_2.0.9 Jan 09 01:41:18 Signed-off-by: Martin Jansa Jan 09 01:41:20 03Martin Jansa  07org.openembedded.dev * re663af41b4 10openembedded.git/ (3 files in 2 dirs): Jan 09 01:41:20 vala: bump 0.7.9.6, fixes libfsoframework build Jan 09 01:41:22 Signed-off-by: Martin Jansa Jan 09 01:41:24 03Martin Jansa  07org.openembedded.dev * r72946befb2 10openembedded.git/ (3 files in 3 dirs): Jan 09 01:41:27 fsodeviced: bump revision for fsodevice.accelerometer fix, reenable in config Jan 09 01:41:29 Signed-off-by: Martin Jansa Jan 09 02:01:01 ok, wow, bitbake -n takes way the hell longer than I would think **** ENDING LOGGING AT Sat Jan 09 02:59:57 2010