**** BEGIN LOGGING AT Mon Feb 06 02:59:58 2012 Feb 06 07:11:33 I'm having a problem compiling gcc using oe. I get: /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lppl_c Feb 06 07:11:36 | /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lppl Feb 06 07:11:39 | /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgmpxx Feb 06 07:11:44 any ideas as to which libraries I'm missing? Feb 06 07:12:35 mertsas: you have ppl installed on your system Feb 06 07:12:43 and oe gcc does not expect that Feb 06 07:13:29 khem: ok, so I have to uninstalled ppl then. Thought it tries to link with ppl, but couldn't find it Feb 06 07:14:23 well or you can do this Feb 06 07:15:10 add --with-ppl=no --with-cloog=no to EXTRA_OECONF_BASE gcc/gcc-4.5.inc Feb 06 07:15:27 btw. are you using classic OE Feb 06 07:15:43 I have already fixed this problem for meta-oe Feb 06 07:16:05 I'm using the one from git, when did you fix this? Haven't pulled since friday Feb 06 07:16:32 well we have new layered OE Feb 06 07:16:37 which is the way to go Feb 06 07:16:48 you can check this out Feb 06 07:16:51 so I shouldn't use the one from git? Feb 06 07:17:13 I would not recommend classic oe Feb 06 07:17:38 ok, where can I find the layered OE then? on github.com/openembedded? Feb 06 07:17:44 http://www.angstrom-distribution.org/building-angstrom Feb 06 07:17:52 try that Feb 06 07:18:02 it will get you the new layer based OE Feb 06 07:18:14 ok Feb 06 07:18:29 what board are you targetin Feb 06 07:18:46 what's the difference between the layered and classic? Feb 06 07:18:49 pandaboard ES Feb 06 07:18:58 a lot Feb 06 07:19:09 ok than angstrom is a good choice for panda Feb 06 07:19:31 in those intructions where it says beagleboard replace that with pandaboard Feb 06 07:20:13 ok, thanks Feb 06 07:20:32 np Feb 06 07:21:08 you can read ml for details on oe layer based and classic difference Feb 06 07:22:20 ok, thanks for the help Feb 06 07:55:30 gm everyone Feb 06 08:13:16 good morning Feb 06 08:56:17 khem: removed rgb from meta-oe causes PV to go backward, will you send PR bump to oe-core or should I add PRINC in shr layer to fix binary feed? Feb 06 08:56:21 khem: ERROR: Package version for package rgb went backwards which would break package feeds from (1:1.0.4-r6 to 1:1.0.4-r5.0) Feb 06 10:17:45 morning all Feb 06 10:17:52 hi florian_kc Feb 06 10:18:17 hi all Feb 06 10:18:21 pb_: hi Feb 06 10:30:44 hi Feb 06 10:50:24 hi mckoan Feb 06 10:59:00 florian: did you have a safe return back? Feb 06 10:59:23 mckoan: yes thanks... Feb 06 10:59:52 florian: good Feb 06 11:00:21 the only people I've not meet is Crofton|work :-( Feb 06 12:28:59 from the github pages, which repos do I need? meta-oe, oe-core, openembedded? is meta-oe the layered openembedded? Feb 06 12:30:38 mertsas: that kind of depends on what you want to compile for; openembedded-core and meta-oe are probably the minimum, nut sure if you would be happy just with oe-core alone Feb 06 12:30:45 but I guess that depends on what packages you are looking for Feb 06 12:33:09 heh, 706M lib/.debug/libwebkitgtk-1.0.so.0.11.2 Feb 06 12:33:20 Jin^eLD: so openembedded-core and meta-oe are both part of layered openembedded? Feb 06 12:33:32 real beauty to gdb it on device with 128MB ram Feb 06 12:34:07 mertsas: well, oe-core is, as the name says "the core", the minimum to start doing anything meaningful I guess, meta-oe has some additional packages, I think quite some stuff that was ported from oe-classic Feb 06 12:35:09 ok, thanks Feb 06 12:36:33 is there any updated howto's using the layered oe? Feb 06 12:36:38 JaMa: heh, I guess this is why we have gdbserver. Feb 06 12:39:32 pb_: yes but still when you do "opkg install midori-gdb" which isn't so big it tries to install all -gdb packages from depends, so you have to think in advance about size of depends :/ Feb 06 13:34:43 after running bitbake virtual/kernel, what is my rootfs, and uImage and stuff? what do I copy to my sd card? Feb 06 13:35:45 or do I have to build something other than virtual/kernel Feb 06 13:35:46 ? Feb 06 13:35:48 see in tmp/deploy, though if you only ran bitbake virtual/kernel you probably do not have a rootfs yet Feb 06 13:36:24 pb_: so what makes the rootfs? what did I get from virtual/kernel then? a uImage? Feb 06 13:36:39 well, a kernel image of some kind Feb 06 13:36:51 whether it's actually a uImage depends on your machine configuration Feb 06 13:37:05 there are separate recipes for the rootfs Feb 06 13:37:10 ok, so to get a rootfs I have to run bitbake console-image or something? Feb 06 13:37:18 right Feb 06 13:37:23 ok, thanks Feb 06 13:37:42 and I can see what is made in machine/pandaboard.conf if that's my machine? Feb 06 21:44:58 Hello ... can someone advice regarding options for a project? I am looking for cheapest possible board (not a custom one) that has rs232 and ethernet (it might be mmu-less, no problem)? Feb 06 21:45:53 I'm researching to see what are the options available that fits on this... any help is more then welcome :-) Feb 06 22:46:39 pb_: ping Feb 06 22:50:24 yo Feb 06 22:50:36 ant_______________: that's quite some tail you have today Feb 06 22:51:25 ho, yes, maybe the cold Feb 06 22:51:46 ah yes, I heard it snowed in Rome the other day Feb 06 22:52:24 here, all the snow is melting today Feb 06 22:52:34 pb_: about /etc/localtime, what are the drawbacks of having a file? the postinst script will update it. Long ago there was a problem when upgrading libc, because the tz was reset Feb 06 22:52:59 I think this is not a problem today Feb 06 22:53:07 well, basically just that it's an extra copy of the same data. Feb 06 22:53:23 if it's on the same filesystem then it could be a hard link, which is essentially free Feb 06 22:53:58 obviously these files are not especially big, but in the world of micro we try to care about every file no matter how small. Feb 06 22:54:29 you're right that there's also a potential issue around updates, though as you say the postinsts can sort that out. Feb 06 22:55:13 the problems (in debian) were originated by libc updates Feb 06 22:55:24 I just found old thgreads Feb 06 22:56:35 pb_: there are countermeasures for libc-mangling in the tzdata recipe Feb 06 22:57:49 yeah Feb 06 22:57:54 pb_: maybe code is necessary but... Feb 06 22:58:54 for the purposes of the discussion on the mailing list (which I guess is what you're thinking of) it sort of doesn't natter much whether there are countermeasures or not. in principle, for micro at least, we don't want to have copies of files where not absolutely necessary. Feb 06 22:59:23 if you want /usr on a separate partition then a copy of /etc/localtime is indeed "absolutely necessary". but, if you don't care about that, it isn't. Feb 06 22:59:46 once we get the var the patch will be straightforward Feb 06 22:59:48 I think it's fairly reasonable to make this an explicit piece of policy via a DISTRO_FEATURE Feb 06 23:00:39 pb_: in any case uclibc doesn't need that timezones, isn't? Feb 06 23:01:11 iirc sets own TZ var Feb 06 23:02:19 yeah, probably Feb 06 23:02:24 pb_: finally, I don't care too much about that. I was just fed up by the fetch error of the 2011_g recipe in meta-oe ;) Feb 06 23:02:31 heh Feb 06 23:03:10 yeah, this is a common problem. I was recently quite fed up by the inability to fetch zlib 1.2.5 :- Feb 06 23:03:15 :-} Feb 06 23:03:38 missed it ...I must have it somehow cached.. :] Feb 06 23:03:56 so did I, until I tried to set up a new build host. Feb 06 23:03:58 heh Feb 06 23:04:13 ouch, rude Feb 06 23:04:24 I do it every 6 months Feb 06 23:04:45 kernel is spreading way too fast Feb 06 23:04:47 but yeah, as far as the timezone stuff goes, I guess it is up to the oe-core überhackers what they want to do about that. Feb 06 23:05:30 yes, I hope I did not horribly break the recipe editing the Gentoo's one .. we'll see on next upgrade ;) Feb 06 23:06:15 now I'm targeting guns on udev.... Feb 06 23:07:01 this 'first-boot-device-cache' is a problem with RO on boot (which I find normal and useful) Feb 06 23:07:05 ah, udev Feb 06 23:07:21 as far as I am concerned this is a technology from the previous decade :-} Feb 06 23:07:33 * pb_ <3 devtmpfs Feb 06 23:09:03 yes, we need to refresh initscripts and module management Feb 06 23:09:16 as well Feb 06 23:09:30 pb_: right but events cannot be handled without udev or mdev, right? Feb 06 23:10:20 otavio: the device-cache itself as it is in oe-core does work just fine Feb 06 23:10:31 we could just move the whole world to UTC and save a lot of hassle Feb 06 23:10:34 the issues are in the meta-oe implementation, on first boot Feb 06 23:10:39 ant____: i sent a patch to disable it, did you see? Feb 06 23:10:57 yes, but again, it's only the init of meta-oe Feb 06 23:11:08 otavio: right. or a custom hotplug script, which is what we use mostly. Feb 06 23:11:12 ant____: so set udev preferred version to 164 for now Feb 06 23:11:20 anyway, I get Feb 06 23:11:21 Caching udev devnodes Feb 06 23:11:22 Populating dev cachemv: can't rename '/tmp/uname': No such file or directory Feb 06 23:11:35 and before Feb 06 23:11:36 Starting udev Feb 06 23:11:36 /etc/rcS.d/S04udev: line 52: can't create /tmp/uname: Read-only file system Feb 06 23:11:38 ant____: this won't be the case in oe-core Feb 06 23:11:59 ant____: i am finishing 180 update of udev Feb 06 23:12:12 dev cache in classic OE was always broken Feb 06 23:12:14 great, I'll test it asap Feb 06 23:12:26 I used to just inject the file to turn it off Feb 06 23:12:32 made life so much less stressful Feb 06 23:12:38 ant____: and add udev-cache in BAD_RECOMMENDATIONS Feb 06 23:13:10 ant____: or apply my patch (the udev cache one I sent today) Feb 06 23:13:13 otavio: no, I 'm testing defaults with no distro Feb 06 23:13:30 yes, I'll apply the patches Feb 06 23:13:53 ant____: https://github.com/OSSystems/oe-core/commit/6907cafeb8297e1392f36c3c4023fabf1cb9190b Feb 06 23:14:47 otavio, I'm unsure it would solve my problem Feb 06 23:15:17 ant____: it should not use cache by default in this case (but only with 164) Feb 06 23:15:22 the problem is the init ( S04udev) Feb 06 23:15:27 ant____: you'd need to drop meta-oe Feb 06 23:15:27 if [ "$DEVCACHE" != "" ]; then Feb 06 23:15:30 blah Feb 06 23:15:35 * pb_ bedtime now Feb 06 23:15:38 ant____: or set P_V Feb 06 23:15:39 night all Feb 06 23:15:42 pb_: night Feb 06 23:15:43 gn Feb 06 23:15:57 ant____: meta-oe udev is outdated regarding all this Feb 06 23:16:11 ant____: am working on 180 update to oe-core Feb 06 23:16:37 otavio: atm I have to keep meta-oe Feb 06 23:18:46 ant____: then set P_V Feb 06 23:18:55 ant____: for 164 for now Feb 06 23:20:00 ok, thx **** ENDING LOGGING AT Tue Feb 07 02:59:58 2012