**** BEGIN LOGGING AT Tue Sep 01 02:59:57 2009 Sep 01 03:00:44 cool, i got an ext3 fs mounted and swap activated Sep 01 03:02:44 what have you got that disk attached to? Sep 01 03:12:02 grg it plugs right into the ide port Sep 01 03:12:03 tiny Sep 01 03:12:21 i had to rig up a molex female-to-female 4pin to hook up to the power cable Sep 01 03:12:35 its advertised as like 70-80mb/s Sep 01 03:12:58 very new tech, the firmware is from 6/01/09 and the serial hints to a 7/01 manufacturing batch Sep 01 03:21:35 http://pastebin.com/d2dd87586 Sep 01 03:21:36 :/ Sep 01 03:21:41 i get 'bad crc' Sep 01 03:23:09 okay well, it just booted off the disk with a tftpboot Sep 01 03:23:12 any idea? Sep 01 04:10:07 hah oh Sep 01 04:10:13 i was booting from 0:1, 0:2 worked Sep 01 04:10:14 strange Sep 01 04:29:53 now it wont recognize the ext3 i just mkfs.ext3 and cpio -idmv on :/ Sep 01 04:30:00 it mounted fine, from the same kernel Sep 01 04:30:24 No filesystem could mount root, tried: ext3 Sep 01 04:56:45 argh, udev hang Sep 01 04:59:00 :( Sep 01 04:59:07 it 'boots' Sep 01 05:00:13 this is base-image / ppc405gp / gcc 4.4.1 / uclibc 9.30.1 btw Sep 01 05:46:38 mornink Sep 01 05:53:10 hi czr_ Sep 01 06:02:28 m4t: bad CRC could be because flash programming did not work Sep 01 06:02:38 http://www.denx.de/wiki/view/DULG/UBootCmdGroupInfo#Section_5.9.1.4. Sep 01 06:03:03 m4t try imi command Sep 01 06:04:06 m4t: Did you get 4.4.1 gcc going in your env Sep 01 06:05:29 khem , yea i am ~sucessfully booting from disk Sep 01 06:05:34 via u-boot 1.2.0 Sep 01 06:05:52 i got that slc flash module today, finally Sep 01 06:05:59 it works good, i need to play with hdparm Sep 01 06:06:11 the one problem i am having is with the initial boot into an image Sep 01 06:06:20 no errors, but udev takes forever Sep 01 06:06:35 then console freezes at 'configuring software packages' Sep 01 06:07:21 http://pastebin.com/d2fac2197 Sep 01 06:07:43 m4t: nice Sep 01 06:07:46 actualy udev isnt creating the device tree it doesnt seem Sep 01 06:08:02 when it tries to remount root, it can't find /dev/hde2 Sep 01 06:08:18 the only thing i changed was /etc/fstab in base-image Sep 01 06:08:35 m4t: do you have tmpfs enabled ? Sep 01 06:08:44 in kernel Sep 01 06:09:07 haha, it would be something to check Sep 01 06:09:15 i think i do... Sep 01 06:09:21 maybe i only have full ramdisk Sep 01 06:10:09 CONFIG_TMPFS=y Sep 01 06:14:31 i could try 'minimalist' as well, it didnt seem too much difference, except for the inclusion of gettext Sep 01 06:30:46 anyone care to comment what is best for a webserver on an embedded system: apache, lighttpd, mini-httpd, thttpd Sep 01 06:30:52 we seem to have recipes for all of these Sep 01 06:31:14 (but I would need support for php (natively or through cgi) Sep 01 06:34:28 * eFfeM is reading http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers Sep 01 06:35:35 php kind of defeats the purpose of having a lightweight web server Sep 01 06:35:51 whatever you use, its instantly heavy Sep 01 06:36:09 true, but there are things where you need it Sep 01 06:36:26 alternative (also possible) is a dedicated cgi script Sep 01 06:36:32 not sure whether that is preferable Sep 01 06:36:50 what do you mean by a dedicated cgi script? Sep 01 06:37:01 php run as a cgi? Sep 01 06:37:05 noooo Sep 01 06:37:32 an c program compiled and run as a cgi? Sep 01 06:37:51 one of the things i need it to give a dir listing as an xml file, for now I just do this with a small php page, but I could also program this as a shell script or even a C prog and invoke through cgi Sep 01 06:38:36 keep it simple Sep 01 06:38:52 i'd love to :-) Sep 01 06:39:10 but ofc I do not want to sacrifice too much on performance and functionality Sep 01 06:39:24 sounds like a couple of lines of shell Sep 01 06:39:33 yes Sep 01 06:39:41 what are your resource limitations? Sep 01 06:39:47 actually that was just an example Sep 01 06:39:50 and how many concurrent users? Sep 01 06:40:32 i'm not too resource constrained, i will have 512 MB of RAM and a hard disk (and an arm cpu), but would want to keep cpu usage low (the thing has to do other things too) Sep 01 06:40:58 typically there will be only one user, but there can be cases where there might be a few Sep 01 06:41:19 idea is to control an embedded device through a set of web pages Sep 01 06:41:42 just use apache Sep 01 06:42:22 well... use whatever you're already most familiar with. apache is a good choice if that does not help Sep 01 06:42:28 eFfeM, don't use thttpd :-) Sep 01 06:42:35 i'm doing that now, thought lighttpd would be a more resource friendly alternative that is fairly compatibile Sep 01 06:42:42 we decided to use it a year ago and are hitting all kinds of wonderful problems with it. Sep 01 06:42:44 czrr_ why not ? Sep 01 06:42:51 ok thanks for the warning Sep 01 06:43:17 let me check for the other new server that might be more suitable Sep 01 06:43:37 http://nginx.net/ <- hearing many good things about this lately Sep 01 06:44:07 it probably has more than you bargained for, but reportedly it's wicked fast at serving regular stuff as well. Sep 01 06:44:12 (fast as in light-weight) Sep 01 06:44:31 czr, what sort of problems are you seeing? Sep 01 06:44:49 well, in our case we have a background process that generates pngs into a cache dir. Sep 01 06:44:54 then we serve the pictures using static thttpd Sep 01 06:45:02 except that once the pictures are stale, they're removed Sep 01 06:45:08 externally to thttpd that is. Sep 01 06:45:31 since thttpd will mmap all files that it serves, it will keep the cache occupied even if the files (names) are removed Sep 01 06:45:53 so in the end on a long-running system we end up where our cache (on tmpfs) is filled up, but ls -la returns no files there.. :-) Sep 01 06:46:16 also, something thttpd just dies when dealing with back-to-back cgi operations and such Sep 01 06:46:27 ok Sep 01 06:46:29 didn't know nginx, looks interesting Sep 01 06:46:31 so, it's not a bug bug per se, more of a design issue. Sep 01 06:47:01 however, the latter cgi thingy might be a real bug, but it's very rare and I can't be bothered to try to replicate it now. happens once per one or two weeks Sep 01 06:47:12 from memory, apache uses sendfile(2). so that should be reasonable Sep 01 06:47:23 yes. Sep 01 06:47:28 but apache uses a lot of memory Sep 01 06:47:38 csr_, thanks for the info, one of the htings I need to so is serve downscaled pics which may be removed Sep 01 06:47:39 that's a good reason to use apache 1.3.x :) Sep 01 06:47:42 per connection, even if the client doesn't do anything. Sep 01 06:48:09 eFfeM, right. then you don't use thttpd :-). Sep 01 06:48:20 or, you do, and then bang your head against the wall after some months ;-) Sep 01 06:48:41 * czr_ blames his boss how wanted a working solution fast never mind the ramifications. Sep 01 06:48:45 noticed nginx also has auth support (which I also need) Sep 01 06:48:48 s/how/who/. Sep 01 06:50:32 will nginx also support multiple web server (might need to run 2 (on different ports ofc) Sep 01 06:50:39 * eFfeM is browsing the nginx doc Sep 01 06:50:41 obviously :-) Sep 01 06:50:58 or rather, I don't know, but I'd guess so. it's designed for heavy loads. Sep 01 06:51:58 eFfeM, anyhow, I never ended up packaging nginx for oe, it has some dependencies that I wasn't ready to solve at that point. Sep 01 06:52:01 found that, but heavy load often means that one server on a system is more than enough Sep 01 06:52:09 it does do virtual hosts Sep 01 06:52:12 and it's slightly too heavy-weight for our needs (we only have 32 MiB RAM) Sep 01 06:52:21 ah ok Sep 01 06:52:30 and what did you use in the end? Sep 01 06:52:49 * czr_ coughs Sep 01 06:52:55 custom httpd server? Sep 01 06:52:58 * czr_ coughs Sep 01 06:53:06 (btw I've also been looking at wt (witty) to remotely control my device Sep 01 06:53:56 interesting, didn't notice that. Sep 01 06:53:58 * eFfeM hands czr_ some sweets to relief the coughing Sep 01 06:54:17 unless they contain large amounts of alcohol, I'll pass, thanks ;-) Sep 01 06:54:25 http://www.webtoolkit.eu/wt Sep 01 06:54:34 good morning Sep 01 06:54:40 hi mckoan Sep 01 06:55:03 mornink Sep 01 06:55:05 czr_ that is why I also peeked at mini -httpd and microhttpd Sep 01 06:55:09 hi all Sep 01 06:55:29 i do have 512 MB but definitely some if it will be used for other purposes Sep 01 06:55:50 eFfeM, you might want to select something that is maintained. Sep 01 06:55:52 and in order to keep the performance I'd like to avoid swapping Sep 01 06:55:58 yes definitely Sep 01 06:56:10 * eFfeM is lazy and dislikes maintenance :-) Sep 01 07:00:51 you'll make your life much easier by just using apache. Its not that bloated. And it can be tuned to use less resources quite easily Sep 01 07:01:07 you have a point Sep 01 07:01:24 except it cannot fix this: http://isc.sans.org/diary.html?storyid=6601 Sep 01 07:01:37 although, not all web servers can. design issue. Sep 01 07:01:47 i'm only doing a prototype now, but would like to reuse as much as possible Sep 01 07:01:50 ensure that your web app is generic enough that it can work with other browsers and change it later iff necessary. Sep 01 07:01:57 (i told you I am lazy) Sep 01 07:02:04 s/other browsers/other servers/ Sep 01 07:02:21 grg that is a plus for apache, some of the web app will be from open source Sep 01 07:02:29 (i'm thinking of a photo gallery) Sep 01 07:02:44 guess my chances are bigger with apache Sep 01 07:03:39 * czr_ shrugs Sep 01 07:04:25 well i'm trying to balance prototype dev effort and later product reuse Sep 01 07:04:33 czr, interesting DoS. But a DoS is not a major issue for an embedded device on a local network with 1-few users. Sep 01 07:04:41 that is why i find nginx ivyer interesting Sep 01 07:05:14 khem : i found several kernel options that i didnt have right Sep 01 07:05:27 in the udev readme: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=README Sep 01 07:05:55 hotplug_helper was set to /sbin/hotplug, i didnt have tmpfs_posix_acl, etc. Sep 01 07:05:56 (actually in the end I will probably allow remote access (e.g. password based), but it is definitely not a mission critical device and DoS-ing a small home system does not seem too likely) Sep 01 07:06:45 eFfeM there are a bunch of nifty small http servers Sep 01 07:07:05 http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers Sep 01 07:07:12 m4t: i know, trying to balance between performance and functionlaity Sep 01 07:07:32 m4t: (08:34:28 AM) ***eFfeM is reading http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers Sep 01 07:07:34 :-) Sep 01 07:09:19 but thanks anyway Sep 01 07:09:29 oh Sep 01 07:09:35 np Sep 01 07:10:20 hah Sep 01 07:10:30 yea i read that a couple weeks ago, nginx caught my eye Sep 01 07:10:54 grg, yes on one hand. on the other hand, if the end product will be installed by regular users, then their network might be open to the internet automatically, and all kinds of problems become real problems. Sep 01 07:11:00 grg, but in general, I do agree with you. Sep 01 07:11:25 as to the "dos", a lot of network service implementations based on TCP have similar issues Sep 01 07:13:29 they can always by modified to drop connections if a full request has not been made in a certain amount of time. Assuming of course that doesn't break any RFC Sep 01 07:14:00 grg, except that until that time they cannot serve new connections since they've exhausted all memory Sep 01 07:14:03 which is the core of the dos. Sep 01 07:14:16 but i digress, who cares.. :-) Sep 01 07:14:41 timeout=10 would be fine i guess. Sep 01 07:14:55 offtopic. yes :) Sep 01 07:15:02 except that would break large file uploads over slow links ;-) Sep 01 07:15:06 yes, definitely OT ;-). Sep 01 07:15:22 the dos is only for sending the headers though... Sep 01 07:15:33 yes, thought of that.. Sep 01 07:15:44 * czr_ shrugs and tries to focus on some real work Sep 01 07:15:58 * grg tries to focus on heading home in 15 mins Sep 01 07:16:04 :D Sep 01 07:16:13 * czr_ works from home today.. Sep 01 07:17:19 * eFfeM is at home too, still morning here Sep 01 07:23:43 even with my kernel looking just like the one from the udev README, still no go Sep 01 07:30:35 need a reboot & coffee, back in a while Sep 01 08:17:00 ooops debian lenny is really badly tested Sep 01 08:22:20 I just received a beagleboard and managed to build and install the console-image. Now I want to extend it a little by adding packages to it (nano, mplayer, whatever). I have tried to find documentation about this and it looks like it's recomended to create a new image by copying an existing rather than editing the an existing. I have only found very little documentation about that and hope anyone can point out some docs that describes this in detail. Sep 01 08:24:49 good morning Sep 01 08:28:56 hi florian Sep 01 08:29:14 03Sebastian Krzyszkowiak  07shr/import * r4bd5a6dbd6 10openembedded.git/recipes/aceofpenguins/ (aceofpenguins-launcher_0.1.bb aceofpenguins-launcher_0.2.bb): recipes/aceofpenguins/aceofpenguins-launcher_0.1.bb Sep 01 08:34:27 Hi there :) I'm new to this forum. To whom or where do I ask about boot issues of the console-image?? Sep 01 08:46:40 hasse just ask Sep 01 08:46:51 ~ask Sep 01 08:46:52 Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. Sep 01 08:46:53 Hasser: 1) it's not a forum; 2) you can just ask and maybe someone will answer you; 3) when asking, don't copy paste large text snippets to the channel, use pastebin Sep 01 08:47:18 mckoan: wow, good command, tnx for info! :) Sep 01 08:47:42 :-D Sep 01 08:48:06 maybe info on pastebin will be usefull too Sep 01 08:48:18 ~pastebin Sep 01 08:48:19 [~pastebin] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste Sep 01 08:48:27 ahahaha, nice job Sep 01 08:49:02 I'm making a crib... :) Sep 01 08:50:37 mckoan: where is ibot interface documented? Sep 01 08:52:04 can users learn ibot new commands? Sep 01 08:54:10 ~ibot Sep 01 08:54:11 It's me Sep 01 08:54:16 Sep 01 08:54:24 ~ibot help Sep 01 08:54:39 ~help Sep 01 08:54:41 eFfeM: you can ask him privately for 'help' Sep 01 08:54:51 but there is no info on ~pastebin etc. Sep 01 08:56:27 i would like to know how to teach new ~ things Sep 01 08:59:03 ~xora Sep 01 08:59:04 it has been said that xora is Graeme Gregory - generic hacker of stuff in OpenEmbedded, or an OpenMoko employee Sep 01 08:59:14 ibot: forget xora Sep 01 08:59:14 i forgot xora, XorA Sep 01 08:59:51 ibot: xora is Graeme Gregory - generic hacker of stuff in OpenEmbedded/Angstrom and a freelancer Sep 01 08:59:52 okay, XorA Sep 01 08:59:57 eFfeM: thats how Sep 01 09:01:04 ~florian Sep 01 09:01:07 wow Sep 01 09:01:44 ibot doesn't seem to like me :) Sep 01 09:02:05 ibot: who is xora? Sep 01 09:02:06 rumour has it, xora is Graeme Gregory - generic hacker of stuff in OpenEmbedded/Angstrom and a freelancer Sep 01 09:05:28 XorA: thanks Sep 01 09:06:17 ibot: florian is dunno, ibot does not like florian :-) Sep 01 09:06:18 okay, eFfeM Sep 01 09:06:20 ~florian Sep 01 09:06:21 it has been said that florian is dunno, ibot does not like florian :-) Sep 01 09:06:34 florian, this better ? Sep 01 09:06:55 ibot: florian is ibot does not like florian :-) Sep 01 09:06:56 hrm Sep 01 09:06:56 ...but florian is already something else... Sep 01 09:06:58 or this better? Sep 01 09:07:10 ibot: forget florian Sep 01 09:07:10 eFfeM: i forgot florian Sep 01 09:07:34 ~botsnack Sep 01 09:07:34 florian: :) Sep 01 09:07:53 ah you're tying to become friends Sep 01 09:08:59 ibot: eFfeM is a hacker from the Netherlands roaming around on freenode at irregular intervals Sep 01 09:09:00 okay, eFfeM Sep 01 09:09:23 ibot: ty Sep 01 09:09:24 rumour has it, ty is thank you, or cobb -- a baseball player Sep 01 09:10:09 let's see if it knows the basic netiquette Sep 01 09:10:11 ~rtfm Sep 01 09:10:12 from memory, rtfm is Read The F*cking Manual (TM). It is a suggestion to do your homework before posting a question. Sometimes used as RTFM $SPECIFIC_MANUAL to refer to a specific source of information. See also http://en.wikipedia.org/wiki/RTFM Sep 01 09:10:32 ah that is going to be useful :-) Sep 01 09:10:47 guess it shows off eFfeM is a little bit bored atm Sep 01 09:12:05 ibot: nickometer xora Sep 01 09:12:06 eFfeM: oh, don't mention this here - what about taking a look at bugs.openembedded.org? ;) Sep 01 09:12:07 'xora' is 0.000% lame, effem Sep 01 09:12:29 florian ;) Sep 01 09:12:52 should do so, but atm on a different project Sep 01 09:15:15 florian, the pages need a redesign? Sep 01 09:15:17 * czr_ hides & runs Sep 01 09:15:39 :-) Sep 01 09:17:16 booxter: thx man, I meant forum as in area... ;) Sep 01 09:28:12 florian: good morning Sep 01 09:28:27 hi pb__ Sep 01 09:30:51 johi pb Sep 01 09:37:07 hi woglinde Sep 01 09:37:33 03Brijesh Singh  07org.openembedded.dev * rec8b2b66c9 10openembedded.git/recipes/ti/ (files/gstreamer-ti-tracker-824.patch gstreamer-ti_svn.bb): gstreamer-ti: merge updated patch from tracker and export CODEC_SERVER dir for the hard-coded server name Sep 01 10:37:35 re Sep 01 12:13:12 hi rjirti Sep 01 12:13:15 ups rkirti Sep 01 12:13:25 hello woglinde Sep 01 12:13:33 good morning everyone Sep 01 12:40:51 Hi Sep 01 12:51:04 morning cbrake Sep 01 13:04:47 morning Sep 01 13:04:52 hi chouimat Sep 01 13:35:58 ho Sep 01 13:59:46 hey oe experts! Sep 01 14:00:11 do you know an easy way to force link with g++? Sep 01 14:00:21 is pkgconfig allowing this? Sep 01 14:00:46 g++ -o output input.o Sep 01 14:00:47 ? Sep 01 14:01:00 g++ will still use the linker for linking though Sep 01 14:01:25 tardyp: no, pkgconfig doesn't exert any influence over which driver is used for linking. what's the actual issue you're trying to address? Sep 01 14:01:43 well my libgles is requiring g++ Sep 01 14:01:56 why? Sep 01 14:02:03 if it is a g++ lib then use -lg++ or so Sep 01 14:02:05 though every program linked with clutter needs stdc++ Sep 01 14:02:38 g++ is supposed to automaticaly add several c++ libs and linker directives Sep 01 14:02:50 it should be getting the libs automatically via DT_NEEDED. Sep 01 14:02:58 what are the linker directives that you need? Sep 01 14:03:05 pb_, the gles implementation is implemented in g++ Sep 01 14:03:06 03Koen Kooi  07org.openembedded.dev * rab3fe804ca 10openembedded.git/recipes/xscreensaver/ (xscreensaver.inc xscreensaver_5.07.bb): xscreensaver: fix packaging and QA Sep 01 14:04:04 tardyp: sure, but the fact that the library is compiled with shouldn't mean that its clients are obliged to link with g++ as well; I think that ought to be transparent. Sep 01 14:04:19 I see. Sep 01 14:04:30 its a binary only proprietary lib Sep 01 14:04:41 probably not linked properly I supposed Sep 01 14:04:54 ah, I see Sep 01 14:05:32 you could make a shim library that contains the right DT_NEEDED things and link with that, or I guess you could put -lstdc++ and whatever else in your .pc's libs section. Sep 01 14:06:53 pb_, sounds good. Sep 01 14:08:47 pb_, you think: "g++ -shared -o libGLESv2 -lgles20" will do the trick ? Sep 01 14:09:28 it should do, yes. Sep 01 14:09:44 you might want to call it "libGLESv2.so", but otherwise I think that's fine Sep 01 14:10:02 yes of course Sep 01 14:10:13 if g++ complains about not having any input files then you can give it a dummy source file that doesn't define anything, though I think it will probably be happy with -lgles20 as its only input. Sep 01 14:10:32 pb__, thanks for your wisdom... will you be at ELCE? Sep 01 14:11:22 tardyp: LD=${CXX}? Sep 01 14:11:38 tardyp: I don't think so. Sep 01 14:11:57 hrw, yes, but then I'll need to change all the clients reciepes Sep 01 14:12:21 tardyp: freescale stuff... Sep 01 14:12:52 hrw, proprietary shit :/ Sep 01 14:13:24 tardyp: is not the one and same? Sep 01 14:13:26 ;D Sep 01 14:14:00 03Sebastian Krzyszkowiak  07shr/import * ra694dcbe71 10openembedded.git/recipes/connman/mokonnect_svn.bb: mokonnect: add connman to RDEPENDS Sep 01 14:14:10 03Sebastian Spaeth  07shr/import * r55874d7661 10openembedded.git/recipes/connman/mokonnect_svn.bb: mokonnect: also bump PR Sep 01 14:19:23 03Sebastian Krzyszkowiak  07shr/import * r7b499b3218 10openembedded.git/ (2 files in 2 dirs): shr-today: new recipe Sep 01 14:19:24 03Sebastian Krzyszkowiak  07shr/import * rc048447e6b 10openembedded.git/recipes/tasks/task-shr-feed.bb: task-shr-feed: add shr-today Sep 01 14:28:36 I'm looking for a web browser that runs in framebuffer (ångström/beagleboard).. Been googleing for hours now without really finding anything. Any suggestions? Sep 01 14:30:13 jovox: maybe Links (http://links.twibright.com/features.php) Sep 01 14:30:55 mario-goulart: I just found that actually :-) Thanks! Sep 01 14:32:00 jovox: you're welcome. :-) Sep 01 14:46:00 Hi, I run bitbake meta-toolchain-qte and I get nothing provides 'meta-toolchain-qte', what do you think the problem is? Sep 01 14:47:00 I checked the content of `recipes/meta´ folder, there's no bb file for meta-toolchain-qte. Sep 01 14:47:43 munzur think about it Sep 01 14:48:22 if there is no bb, how then bitbake can build your bb Sep 01 14:49:14 I know, I though this bb file should be there by default, since there are other meta-toolchain bb files. Sep 01 14:50:38 In openembedded user manual, under Creating and Using a QT Embedded SDK title, it suggests to run this command directly. Sep 01 14:51:00 hm then it seems the usermanual is worng Sep 01 14:51:10 or you have a not the right branch Sep 01 14:51:20 munzur are you using stable branch? Sep 01 14:52:35 Yes Sep 01 14:53:40 munzur ah okay the meta-toolchain for qt was only introduced for .dev branch Sep 01 14:55:05 woglinde: So how can I switch the branch? (if easy to answer) Sep 01 14:55:56 pb_, FYI, this doesn't work :-( g++ is probably doing some more clever things than just adding -lstdc++... Sep 01 14:56:41 woglinde: Ok, I found the related section in user manual. Thanks a lot. Sep 01 14:58:08 http://pastie.org/601714 Sep 01 15:00:15 g'day kergoth Sep 01 15:00:34 hey Sep 01 15:01:03 jo kergoth Sep 01 15:01:11 tardyp you are trying gles stuff? Sep 01 15:01:26 ~lart intel iegd driver Sep 01 15:01:26 * ibot hereby declares intel iegd driver a troll Sep 01 15:02:30 woglinde, absolutely Sep 01 15:03:07 tardyp hm Sep 01 15:03:18 for beagleboard? Sep 01 15:03:28 for fsl mx51 Sep 01 15:05:19 tardyp: how much for cheapest mx51 board? Sep 01 15:05:32 tardyp: qvga/vga screen or vga/dvi out Sep 01 15:07:23 hrw, http://www.akihabaranews.com/en/news_details.php?id=18763 Sep 01 15:07:37 then the devkit is qround $1500 Sep 01 15:08:33 but fsl is giving out devkits to community if you promise to do awsome stuff with it. Sep 01 15:08:58 tardyp: no! never ever another sharp! Sep 01 15:09:35 the return of the zaurus :) Sep 01 15:10:19 indeed Sep 01 15:10:26 and zaurus was nightmare Sep 01 15:11:02 wel... zaurus was pxa based ;) Sep 01 15:13:23 florian: that was very big bonus Sep 01 15:13:29 pxa == open Sep 01 15:13:33 i.mx === closed Sep 01 15:14:18 hrw: yes... i have been working with pxa quite a lot and they have quite some benefits. Sep 01 15:14:41 documentation is one... Sep 01 15:14:58 with pxa I feel like 'get base support and then just connect existing drivers' Sep 01 15:15:12 where base support == board.c file Sep 01 15:15:31 i have i.mx25, 27 and 37 here and the linux stuff freescale provides sucks for all of them. Sep 01 15:15:43 florian: I have i.mx31 Sep 01 15:17:09 I just built an image and toolchain for a TX27 board - works pretty well. I'm quite happy with the performance... but not with the drivers. Sep 01 15:19:47 gm Sep 01 15:19:48 florian, I can confirm that the linux stuff freescale provides sucks. Sep 01 15:19:59 Then you have OE. Sep 01 15:20:20 hi khem Sep 01 15:21:12 tardyp: can you paste output of readelf -d /home/ptar01/poky/build/tmp/staging/armv7a-poky-linux-gnueabi/usr/lib/libgles20.so Sep 01 15:21:21 tardyp: ltib is one, kernel is second Sep 01 15:21:22 tardyp: in fact they seem to produce a lot of code but its a good example that in-house development and random releases is not useful Sep 01 15:21:35 * florian has OE Sep 01 15:22:10 hrw, pxa == open? since when? Sep 01 15:22:20 I've been feeling the reverse since marvell bought the stuff. Sep 01 15:22:36 czr_: pxa25/26/27 Sep 01 15:22:37 I still prefer reading the intel original datasheets compared to the "marvell" ones. Sep 01 15:22:38 czr_: it was fairly open when it belonged to intel, which was the era of the zaurus. Sep 01 15:22:46 yes, with that I agree. Sep 01 15:22:51 but the marvell thing was bad imho. Sep 01 15:22:56 czr_: and when you search you will even find docs still Sep 01 15:22:59 florian, they are more targetting big fishs, and give them the code directly Sep 01 15:23:00 pxa270 is our current target. Sep 01 15:23:03 hrw, yes, I know :-) Sep 01 15:23:06 pxa3xx is disaster Sep 01 15:23:16 yup Sep 01 15:23:30 pxa3xx was one of the alternatives for our next hw-platform Sep 01 15:23:35 * khem remember intel days Sep 01 15:23:37 but atmel sam9 looks much better now. Sep 01 15:23:48 czr_: o yes. Sep 01 15:24:00 czr_: atmel even provides schematics for boards Sep 01 15:24:04 i.MX25 :) Sep 01 15:24:06 yeah, marvell's track record is not very good in terms of either openness or cpu quality. Sep 01 15:24:15 yes, and the CPU looks much nicer and sane in many respects too Sep 01 15:24:33 pxa270 has oodles of yuckyness in it, which gets raised by power of two in pxa3xx. Sep 01 15:24:48 czr_: and when you need openess power then you can go for omap3 Sep 01 15:24:52 tardyp: that's called "old fashioned" ;) Sep 01 15:24:57 s/power/and power/ Sep 01 15:24:58 are omaps open nowadays? Sep 01 15:25:03 I always thought that they were quite closed. Sep 01 15:25:11 czr_: kernel is open Sep 01 15:25:23 what about documentation and devkit schemas and stuff? Sep 01 15:25:38 czr_: 3d acceleration is closed (omap3) or totally unavailable closed (omap2) Sep 01 15:25:50 czr_: beagleboard scheme is open Sep 01 15:26:07 ah yes, I chatted with one person who was working with the linux drivers for the 3D. powervr it was. Sep 01 15:26:19 powervr... please do not curse Sep 01 15:26:23 * tardyp wonders if there is a market supporting fashionable distribution for old fashionned cpu vendors... Sep 01 15:26:27 he told me that it's mostly because of the weird licensing model between ti and powervr or smt. Sep 01 15:26:31 and was unlikely to open ever. Sep 01 15:26:46 powervr is a problem Sep 01 15:26:50 czr_: look at intel gma500 - over year on market, still no driver Sep 01 15:26:54 that TI has little control over Sep 01 15:26:55 open driver Sep 01 15:27:11 hopefully, they move away from them in the future ... Sep 01 15:27:23 hrw, intel has a track record of being slow anyway Sep 01 15:27:33 I remember waiting for the first gen GMA specs to come out for bloody two years Sep 01 15:27:43 and then.. oooh and aah, 2D pipeline only. gah. Sep 01 15:27:50 * czr_ spits in the general direction of large multinationals Sep 01 15:28:10 * czr_ composes himself and gets back to coding Sep 01 15:28:42 years back, I was working in radeon (the original RV100/200 series) Sep 01 15:28:58 that was when I learned that even when you have the documentation, if it's completely bogus, it won't help you much. Sep 01 15:31:16 maybe atmel can change that. I've been positively surprised with AVRs at least Sep 01 15:31:29 (in terms of documentation that is) Sep 01 15:31:59 pb__: whats your opinion on the revised patch about TARGET_OS thing Sep 01 15:36:59 khem: I didn't quite understand how DISTRO_FEATURES was meant to get factored into the settings of ARM_ABI and TARGET_OS. Sep 01 15:37:20 from an initial inspection it seemed that they derive solely from MACHINE_FEATURES, which doesn't seem right. Sep 01 15:37:42 and, given that you went to the trouble of adding eabi to DISTRO_FEATURES, it doesn't seem like what you intended either. Sep 01 15:40:21 pb__: I will add the check to test it in both MACHINE_FEATURES and DISTRO_FEATURES Sep 01 15:40:36 and it will only take it if defined in both Sep 01 15:40:58 For machine we are sure it is supported Sep 01 15:41:05 and distro will have the choice to make Sep 01 15:41:16 however this is ok for arm eabi Sep 01 15:41:45 for spe there is no choice Sep 01 15:41:53 by nature of it Sep 01 15:42:03 I think it should probably be an error if DISTRO_FEATURES requests something that MACHINE_FEATURES doesn't support. Sep 01 15:42:27 Yeah better Sep 01 15:43:33 adding it to distro feature is needed to enable it Sep 01 15:44:12 so far the check only does it for MACHINE_FEATURE in the patch Sep 01 15:44:26 but I will also add similar check for DISTRO feature Sep 01 15:49:16 * kergoth yawns Sep 01 15:49:40 should probably review the features usage in general. i've already added some things to combined features which aren't just "is it in machine and distro features", so combined_features is more like just FEATURES, now.. heh Sep 01 15:49:44 meh, caffeine time Sep 01 15:51:09 khem: for the eabi thing, even better than having it in MACHINE_FEATURES would be to declare the actual arm architecture level in the machine config file, and then have the TARGET_OS auto-munging thing just assert that the architecture is sufficient for the selected abi. Sep 01 15:51:39 so, for eabi you would require v4T or newer; for eabi without interworking v4 would suffice Sep 01 15:55:40 pb__: you mean basic arm arch name like armv5.6.7 etc Sep 01 15:56:33 pb__: something like BASE_PACKAGE_ARCH Sep 01 15:59:55 something like that, yeah, though BASE_PACKAGE_ARCH does contain a few bogons like "armv6-novfp" and I think some distros clobber it. Sep 01 16:01:18 pb__: for any reason distro wants oabi on a machine that supports eabi, should this case work Sep 01 16:02:14 pb__: I think MACHINE_FEATURES seems appropriate too Sep 01 16:02:54 yes, there's no reason you shouldn't be able to select oabi on any arm machine. Sep 01 16:03:46 right so I think we should let this be in MACHINE_FEATURES Sep 01 16:03:47 ~curse hal Sep 01 16:03:48 May the fleas of a thousand camels infest your most sensitive regions, hal ! Sep 01 16:04:13 hi all, i'm trying to build subversion from oe-dev and i'm running into a problem with apr-util_1.3.4 (a dependency)... http://pastebin.com/d40684bed Sep 01 16:04:19 any suggestions? Sep 01 16:07:37 khem: it's not obvious to me what you gain by putting oabi in MACHINE_FEATURES. seems like that's just an opportunity for machine maintainers to get it wrong. Sep 01 16:08:07 if it's supported on all arm architectures, which appears to be the situation, I think you should probably just implement it on that basis. Sep 01 16:08:17 oabi in MACHINE_FEATURES is nonsense I think Sep 01 16:08:34 I've really been thinking that maybe our configuration should be more explicit, less flexible, give them types, maybe even error on access of undefined configuration variables, or something... need to make it more obvious what vars exist and what you can set them to Sep 01 16:08:54 kergoth: yeah, agreed. Sep 01 16:09:06 not entirely sure *how* to make that better, but something should be done Sep 01 16:10:36 kergoth: I'm still not whole-heartedly in favour of this approach of synthesizing TARGET_OS based on a grab-bag of little variables, rather than the reverse, but it seems like something worth exploring. Sep 01 16:11:11 for the wider issue, in the medium term I think we need some kind of "namespacing" or high-level typing for variables, to distinguish configuration from recipe stuff from implementation-internals. Sep 01 16:12:26 that would be a good start, indeed. i wonder how best to do that in a piecemeal fashion, without pissing everybody off :) Sep 01 16:13:57 one way to start would be to teach bitbake to support aliases for variables, so that you could give old things new names (with new properties) without breaking existing code. Sep 01 16:13:58 pb__: ok I will revert to using BASE_PACKAGE_ARCH but then we can not control from DISTRO_FEATURES Sep 01 16:14:31 that's a good point Sep 01 16:14:33 khem: er, why is DISTRO_FEATURES incompatible with using BASE_PACKAGE_ARCH? Sep 01 16:14:55 perhaps we could start allowing '.' in variable names, and use it as a separator, even though it wouldn't *actually* be broken up into namespaces, itd at least be named in that way Sep 01 16:15:02 autotools.acpaths Sep 01 16:15:05 right, that's just what I was thinking Sep 01 16:15:11 I think that'd be a good step Sep 01 16:15:52 pb__: so DISTRO_FEATURES will then have new entry for eabi and spe and for machine bits we will deduce it from BASE_PACKAGE_ARCH? Sep 01 16:15:58 is that ok approarch Sep 01 16:16:13 khem: right, that's what I was thinking. Sep 01 16:16:21 hmm sounds ok to me Sep 01 16:16:29 so, just to be clear, if eabi is not in DISTRO_FEATURES then you use oabi unconditionally, doesn't matter what the machine says. Sep 01 16:16:38 if eabi is in DISTRO_FEATURES and arch >= v4t, use eabi Sep 01 16:16:44 right Sep 01 16:16:47 if eabi is in DISTRO_FEATURES and arch < v4t, that's an error Sep 01 16:17:16 ok let me do something on these lines Sep 01 16:17:48 for spe it might make sense to use MACHINE_FEATURES since I don't think the ppc architectures have quite such a linear structure as the arm ones. Sep 01 16:18:32 pb__: I think I will be consistent and just use BASE_PACKAGE_ARCH Sep 01 16:19:29 ok, that sounds fine Sep 01 16:20:59 hm dont we have now support for eabi on armv4? Sep 01 16:21:31 now yes but then you need to use latest and greatest gcc Sep 01 16:22:01 hi all: I seem to be missing X11/extensions/XShm.h has anyone ran into this issue? Sep 01 16:22:42 03acid-burn  07org.openembedded.dreambox * r3c2c19913c 10openembedded.git/packages/zope/zope-interface_3.3.0.bb: zope-interface_3.3.0.bb: split out .debug, tests and txt files from zope-interface into separate sub-packages to save some space. Sep 01 16:22:44 03acid-burn  07org.openembedded.dreambox * rf059202a45 10openembedded.git/packages/enigma2/enigma2.bb: Sep 01 16:22:44 enigma2.bb: add missing python-email to crashlogsubmitter rdepends. Sep 01 16:22:44 Bump SRCDATE to match recent openembedded changes. Sep 01 16:22:48 03acid-burn  07org.openembedded.dreambox * r00e5c22551 10openembedded.git/packages/python/ (python-imaging_1.1.5.bb python-imaging_1.1.6.bb): python-imaging: update to version 1.1.6 and split out .debug and docs into separate sub-packages to save space. Sep 01 16:22:49 03acid-burn  07org.openembedded.dreambox * r858f2bf742 10openembedded.git/conf/machine/dm7025.conf: Sep 01 16:22:51 khem whats wrong eith this? Sep 01 16:22:54 dm7025.conf: move /usr/lib/*gst* out of squasfs into jffs2. Sep 01 16:22:56 This hopefully fixes the image upgrade problem on low flash as long python is not updated. Sep 01 16:22:58 Sorry but its necessary to reflash your dm7025 to benefit from this change and the following ones. Sep 01 16:23:00 03acid-burn  07org.openembedded.dreambox * r7c65ce3cb5 10openembedded.git/packages/enigma2/enigma2-plugins.bb: enigma2-plugins.bb: Bump SRCDATE to include newest webif and match recent openembedded changes. Sep 01 16:23:05 why invent something thats obsolete in 2 weeks Sep 01 16:23:06 03acid-burn  07org.openembedded.dreambox * ra5364c9155 10openembedded.git/packages/python/ (python-crypto_1.9a6.bb python-crypto_2.0.1.bb): python-crypto: update to version 2.0.1 and and split out .dbg and tests into separate sub-packages to save space. Sep 01 16:23:12 03acid-burn  07org.openembedded.dreambox * rb6129d962c 10openembedded.git/packages/python/ (python-pyopenssl_0.6.bb python-pyopenssl_0.8.bb): python-pyopenssl: update to version 0.80 and split out .dbg and tests into separate sub-packages to save space. Sep 01 16:23:18 03acid-burn  07org.openembedded.dreambox * r88085a0fa7 10openembedded.git/packages/twisted/ (twisted-native_8.2.0.bb twisted_8.2.0.bb): twisted_8.2.0.bb: split out .debug, tests, scripts into separate sub-packages to save space and bump PR. Sep 01 16:23:22 03acid-burn  07org.openembedded.dreambox * r1ee435b18d 10openembedded.git/packages/images/dreambox-image.bb: dreambox-image.bb: remove twisted-web2 as its deprecated till twisted-8.2.0. Sep 01 16:23:25 acid burn? seriously? Sep 01 16:23:27 03acid-burn  07org.openembedded.dreambox * rb0df2dfdf9 10openembedded.git/packages/twisted/ (15 files): packages/twisted: remove old and unused twisted bb files Sep 01 16:23:30 * kergoth shakes head Sep 01 16:23:32 03acid-burn  07org.openembedded.dreambox * rc6a4dbd321 10openembedded.git/packages/python/ (python-2.5.1-manifest.inc python_2.5.1.bb): python-2.5.1: Split out .debug, tests and scripts into separate sub-packages to save space and bump PR on these packages. Sep 01 16:24:51 how many armv4 users we have? Sep 01 16:24:59 I can count them on my fingers Sep 01 16:26:46 khem I am one of them Sep 01 16:26:47 haha Sep 01 16:39:59 03Steffen Sledz  07org.openembedded.dev * r8aeac1fd6f 10openembedded.git/conf/checksums.ini: checksums.ini: some missing checksums added Sep 01 17:06:14 jeaneus: hello all: I am running into this issue X11/extensions/XShm.h No such file or directory. I am trying to build the .dev branch of oe with a distro=angstrom and I am just wondering if any one else has dealt with this issue. let me know if you have some time.... Sep 01 17:12:11 hi mickey|sofa Sep 01 17:13:05 hey Sep 01 17:30:29 hey all Sep 01 17:31:05 khem: still fiddling with the gnuspe stuff right? I admire your perseverence! (sp?) Sep 01 17:32:01 what spe stuff? Sep 01 17:32:07 Often I think OE tries too hard to be smart, I rather liked the old way of just setting variables, period. Sep 01 17:32:22 Tartarus: powerpc spe tripplet support Sep 01 17:32:27 yes, what about it? Sep 01 17:32:44 getting code out that's really spe? Sep 01 17:32:47 or packaging unfun? Sep 01 17:33:24 Setting TARGET_OS. See the mailing list and search for "gnuspe" in the topics Sep 01 17:33:37 packaging unfun then, heh Sep 01 17:34:00 i replied to one of khems patches last week i think wrt TARGET_OS Sep 01 17:34:55 imho, we need to be doing more things in tune files Sep 01 17:35:05 and say if you don't include the right tune, that's your bug Sep 01 17:35:09 Tartarus: I totally agree Sep 01 17:35:32 (ie ?= TARGETT_OS="linux" and in the eabi arm ones, do -gnueabi, in the ppc e500 -gnuspe it, etc) Sep 01 17:35:48 Tartarus: By trying to be smart, we are hiding the details, making harder for people to recognize and fix them in the future. Sep 01 17:36:08 Although the last approach Marcin proposed is good middle ground... Sep 01 17:36:19 I should try and read oedevel again Sep 01 17:36:27 But, being smart just gives pita to read code Sep 01 17:36:47 inline python just makes me to "Why ,d,1 again? oh, right..." Sep 01 17:41:43 heh, we should really make our inline python more of a DSL Sep 01 17:42:34 We should do less of it, too Sep 01 17:47:29 Tartarus: i was thinking the other day... why not just let it resolve datastore elements directly? give it a dict of d as locals() ;) foo = "${@PN + '-foo'}" Sep 01 17:51:57 I was thinking let's ditch python for a second, then I realized no alternative came up in the next second :-) Sep 01 17:52:23 why ,d,1, again ? Sep 01 17:53:20 inline python junk Sep 01 17:58:11 it's the crappy bb.data api Sep 01 18:10:26 re Sep 01 18:12:32 likewise_: lua would be a good choice for that sort of scripting environment, but it's silly to not leverage python when that's what bitbake and our classes are all written in Sep 01 18:13:20 does anyone recall why per-subpackage -dbg packages was shot down in the past? Sep 01 18:23:54 @khem or cbrake I think; I'm attemtping to build an angstrom/at91sam9261ek/uclibc and I seen you fixed the udev(141)/ppoll error for beagleboard/omap. I'm running into the same error, is it an easy fix? Would you be able to direct me on how to correct this if it isn't too much trouble? Thanks Sep 01 18:24:38 OpenEmbedded requires python 2.4 right now, right? Sep 01 18:26:00 kergoth: bitbake currently reqires python 2.6 Sep 01 18:26:49 did i say bitbake? Sep 01 18:26:53 no, i didn't. Sep 01 18:30:51 guess that snippet of information was completely useless, then. Sep 01 18:30:55 * pH5 out of context Sep 01 18:31:25 i know that bitbake master uses 2.6, i work on it :) the question was what OpenEmbedded is up to. pretty sure OE requires bitbake 1.8.x, which is limited to 2.4 Sep 01 18:31:33 * kergoth shrugs Sep 01 18:34:03 NvrBst: you can apply cbrake's patch http://patchwork.openembedded.org/patch/1008/ to kernel and linux-libc-headers recipe that you are using Sep 01 18:34:35 hi all Sep 01 18:35:04 likewise_: many times they go wronf Sep 01 18:35:09 wrong Sep 01 18:35:21 so I thought of fixing it once for all :) Sep 01 18:35:35 problem is divided opinions Sep 01 18:35:49 I believe in disagree and commit :) Sep 01 18:36:47 kergoth: I know. I just thought bitbake 1.8.x is suggested, not mandatory? Sep 01 18:37:19 I always used (or tried to use) bitbake trunk. Sep 01 18:39:58 hey khem Sep 01 18:40:20 m4t: howdy Sep 01 18:40:55 i just made some really strong coffee, i am having trouble this morning Sep 01 18:41:03 this afternoon i guess Sep 01 18:41:08 khem: thank you, i'll look at it :) Sep 01 18:41:22 m4t: hmm Sep 01 18:49:58 i am going tospend some more time tonight, and hopefully figure out why udev doesnt seem to be working Sep 01 18:50:27 use old versions which used to work Sep 01 18:51:58 there isn't any way to get debug output from an image is there? Sep 01 18:52:19 besides adding echo's to the init scripts myself i guess Sep 01 18:53:41 init=/bin/sh works fine, and if i do 'root=/dev/hde2 rw' the filesystem is fully accessible Sep 01 18:53:47 i didnt try mounting a tmpfs though Sep 01 19:10:04 * * OE Bug 5316 has been created by quickx(AT)hotmail.com Sep 01 19:10:06 * * opie-image-16mb / gpephone-image build errors Sep 01 19:10:08 * * http://bugs.openembedded.org/show_bug.cgi?id=5316 Sep 01 19:11:15 hmmm PACKAGE_EXTRA_ARCHS what does it signify Sep 01 19:11:45 does it mean that this machine can run packages intended for the arches mentioned in PACKAGE_EXTRA_ARCHS Sep 01 19:49:45 re Sep 01 19:53:32 re effem Sep 01 19:54:32 hey woglinde Sep 01 19:54:51 jo kergoth Sep 01 19:55:30 have some system issues so bumping in and out :-) Sep 01 19:56:13 effem???? Sep 01 20:05:20 http://www.linuxfordevices.com/c/a/News/MontaVista-Linux-6/ :) finally Sep 01 20:05:42 hehe Sep 01 20:06:07 kergoth will you give us a demonstration at oedem? Sep 01 20:06:20 that would imply actually being able to go to oedem :) Sep 01 20:06:39 yeah but I hope this will happen Sep 01 20:39:14 is gmail busted Sep 01 20:39:41 khem: appears to be for moe Sep 01 20:39:49 same Sep 01 20:40:02 he.. Sep 01 20:40:06 502 Sep 01 20:40:18 S.O.S. Sep 01 20:40:19 lol Sep 01 20:40:49 the power must be out at the secret government server farm .... Sep 01 20:41:14 http://gawker.com/5350474/gmail-fail-google-is-working-on-fixing-it Sep 01 20:41:41 where's my SLA? Sep 01 20:41:56 hi kgilmer Sep 01 20:42:13 gmail web interface busted. imap/pop/smtp works Sep 01 20:42:24 hi woglinde, long time :) Sep 01 20:43:36 kgilmer, hi! Sep 01 20:43:54 hey Crofton Sep 01 20:43:59 03Koen Kooi  07org.openembedded.dev * rc874adcc0a 10openembedded.git/recipes/mozilla/ (fennec_hg.bb firefox.inc): Sep 01 20:43:59 fennec: update to latest tip Sep 01 20:43:59 * fix up buildsystem contamination bug in firefox.inc while I'm at it as well Sep 01 20:44:01 Crofton|work rather Sep 01 20:46:37 I haven't been here in awhile. how are things in OE land? Sep 01 20:48:01 what is oedem? Sep 01 20:48:21 kgilmer our dev meeting Sep 01 20:48:27 like plumber or guadec Sep 01 20:48:49 ah ic. it's private? not listed on the oe site. Sep 01 20:48:55 at least not on the front page Sep 01 20:51:22 the web page is always behind the list Sep 01 20:51:31 Cambridge in early Nov Sep 01 20:51:38 email pb_ if you are interested Sep 01 20:52:15 ok cool Crofton|work, thanks. Sep 01 20:52:52 kgilmer you are free to come over and discuss with us Sep 01 20:53:19 maybee you could make a presentation about the eclipse stuff Sep 01 20:53:23 I would like to do that woglinde. I need to find the right words for my boss. :) Sep 01 20:53:26 kgilmer, that is the quick answer :) Sep 01 20:53:50 kgilmer are since last year money isnt easy at the moment Sep 01 20:54:00 args s/are/ah Sep 01 20:54:18 yeah this year i have to work harder to justify travel Sep 01 20:54:25 probably the same for everyone Sep 01 20:55:05 also I had a baby a few months back so I've not been able to do much travel. Sep 01 20:55:16 ah Sep 01 20:55:17 hehe Sep 01 20:55:25 well, not me personally. my wife rather . :) Sep 01 21:00:23 kgilmer: sure if it was you we would have heard thru TV news channels :) Sep 01 21:01:08 that would be bad khem :) this kind of celebrity nobody needs. Sep 01 21:01:56 *g* Sep 01 21:02:19 I hope you are having nice time with the baby Sep 01 21:02:31 arg, stupid debian package renaming stuff Sep 01 21:02:53 kergoth why stupid? Sep 01 21:03:18 his library versioning stuff might not be working because of it Sep 01 21:03:23 not stupid exactly, just ugly the way we had to do it, and causing problems with what I'm working on Sep 01 21:03:26 I am khem, thanks. also I recently joined hacker space in NYC. If you guys are ever in the city you should stop by. http://www.nycresistor.com/ Sep 01 21:03:38 nah, working on per-subpackage -dbg packages at the moment Sep 01 21:08:14 kergoth: is machine.conf read before distro.conf ? Sep 01 21:08:28 dunno off the top of my head, would have to check bitbake.conf Sep 01 21:09:58 yes machine is read before distro Sep 01 21:10:08 conf/bitbake.conf tells me Sep 01 21:10:13 :) Sep 01 21:11:05 hmmm then why it does not evaluate BASE_PACKAGE_ARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}" Sep 01 21:11:26 looking at conf/machine/include/tune-xscale.inc Sep 01 21:11:56 if I am adding something in distro.conf it should have already defined BASE_PACKAGE_ARCH IIUC Sep 01 21:12:46 bitbake -l Parsing -l Parsing -l Parsing, look at the CONF and BB lines to see what exactly its parsing in what order Sep 01 21:20:03 hm ltg is on strike again? Sep 01 21:37:46 03Michael Smith  07org.openembedded.dev * ra5c9970599 10openembedded.git/classes/ (package.bbclass package_deb.bbclass): (log message trimmed) Sep 01 21:37:46 package_deb: create md5sums control files Sep 01 21:37:46 These are created with the package and get installed in Sep 01 21:37:46 /var/dpkg/info. Afterward it's a great way to find modified files Sep 01 21:37:46 for backup with a little shell script magic. Sep 01 21:37:50 It feels a bit weird to still use MD5, but that seems to be the Sep 01 21:37:52 convention in the Debian world. Sep 01 21:40:40 msmith_: Mostly for historical reasons and because the MD5 together with the size means there's realtively little reason to switch; it's hardly secure anyway. Sep 01 21:43:49 jo guillaum Sep 01 21:51:41 broonie: yeah i wish there were a file that stored file sizes & times, too. Sep 01 21:51:49 but at least having the md5sum is better than nothing. Sep 01 21:51:53 tripwire it ain't but it works in a pinch Sep 01 21:58:48 arg Sep 01 21:59:34 kergoth: the problem is recursion Sep 01 22:00:14 d.getVar(var,exp) Sep 01 22:00:24 ah ha! got it. my debug image now has the files from a subpackage's -dbg package Sep 01 22:00:49 forgot to run a runtime_mapping_rename on the PACKAGE_INSTALL I'm using for the -dbg image Sep 01 22:01:45 khem: not sure what you're referring to Sep 01 22:02:07 03Michael Smith  07org.openembedded.dev * raf431dbe67 10openembedded.git/recipes/openssl/ (10 files): Sep 01 22:02:07 openssl.inc: fix packaging on x86_64; use INC_PR Sep 01 22:02:07 openssl's makefile always installs to ${prefix}/lib, even if Sep 01 22:02:07 libdir is ${prefix}/lib64. Move some files around to make it fit. Sep 01 22:02:07 Signed-off-by: Michael Smith Sep 01 22:02:32 kergoth: my problem about machine and distro conf Sep 01 22:02:45 ahh Sep 01 22:03:34 machine conf has BASE_PACKAGE_ARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}" Sep 01 22:04:12 which I am trying to use BASE_PACKAGE_ARCH in another python function in distro conf Sep 01 22:04:46 why's that a problem? Sep 01 22:06:02 no idea Sep 01 22:06:10 it goes into recursion Sep 01 22:06:18 and then dies of infiniteness Sep 01 22:06:42 if I set BASE_PACKAGE_ARCH = "armv5teb" in above machine file all is ok Sep 01 22:08:27 hms why nobody did update libx11 Sep 01 22:08:43 args Sep 01 22:08:48 now I see the problem Sep 01 22:08:52 libx11-native Sep 01 22:15:23 kergoth: http://pastey.net/124497 if you can see something wrong Sep 01 22:15:47 hm what is TARGET_PREFIX after inherit native Sep 01 22:16:14 khem: yech, we really need to audit the bitbake exception handling Sep 01 22:16:19 the user should never see a full traceback unless they ask for it Sep 01 22:16:22 http://pastey.net/124498 Sep 01 22:16:26 is my code Sep 01 22:16:52 hm intressting it is not set Sep 01 22:17:11 hmm Sep 01 22:17:16 it fails around line 21 Sep 01 22:17:37 hm hm why this dont works Sep 01 22:17:42 from native Sep 01 22:17:43 TARGET_PREFIX = "${BUILD_PREFIX}" Sep 01 22:18:38 khem: don't see anything obvious.. is BASE_PACKAGE_ARCH referring to TARGET_OS somewhere? hmm Sep 01 22:18:45 woglinde: don't see anything wrong with that.. Sep 01 22:19:22 its empty Sep 01 22:19:23 kergoth: I dont think so Sep 01 22:19:31 in case of libx11-native Sep 01 22:19:49 weird. Sep 01 22:19:51 in both cases. Sep 01 22:19:54 :) Sep 01 22:20:36 kergoth: this is tune-xscale.conf file Sep 01 22:20:48 http://pastey.net/124499 Sep 01 22:21:12 it tries to set BASE_PACKAGE_ARCH smartly using python voodoo Sep 01 22:25:08 hms Sep 01 22:26:20 hm build prefix is set empty in bitbake.conf Sep 01 22:26:33 UILD_PREFIX = "" Sep 01 22:27:20 hm seems I have to fake it Sep 01 22:34:19 * kergoth rethinks the possibilities for improving build determinism Sep 01 22:37:52 weird when I assign it to local it works Sep 01 22:38:25 * khem will live with it Sep 01 22:41:48 has anyone here built konqueror-embedded lately? Sep 01 22:42:50 jotheberlock nope Sep 01 22:43:15 ah. Woe is me. I managed to get it starting to build with lots of unpleasantness, but for some reason it can't find the standard c++ headers Sep 01 22:43:28 should I just switch to X11 or something? Sep 01 22:59:09 jotheberlock: how are you building it? on your local machine? Sep 01 22:59:14 yes Sep 01 22:59:18 without OE? Sep 01 22:59:25 bitbake konqueror-embedded with openembedded Sep 01 22:59:33 ah ok Sep 01 22:59:55 it barfed on a wrong libtool version at first but I got past that by copying in my system one. But now it fails to find things like #include Sep 01 23:00:01 haven't tried it in a while but I have been meaning to get around to fixing up the build for the latest version Sep 01 23:00:32 hmm, doesn't sound good... not sure what could cause that Sep 01 23:00:34 am I barking up the wrong tree here? I like Qt (I used to work for Trolltech on Qt/Embedded actually), but if all the action is GPE/X11 there may not be much point in persisting with Opie Sep 01 23:01:08 to be fair, I couldn't figure out where libstdc++ was actually being put - I presumed that bitbake would automatically pull it in if konqueror needed it but I could be wrong Sep 01 23:01:42 jotheberlock do you need something small= Sep 01 23:01:43 ? Sep 01 23:01:52 I guess you are better off with fennec Sep 01 23:02:02 not super-small. I'm using an iPaq - 64 megs ram, loads of SD/CF Sep 01 23:02:17 jotheberlock: it will automatically pull it of course, since the recipe says it should... the paths are probably screwed up is all Sep 01 23:02:21 dont know the midori status Sep 01 23:02:28 I basically went with Opie for nostalgia reasons (fun fact, the second embedded platform ever to run Qt/Embedded was an iPaq) Sep 01 23:02:28 browser bases on webkit Sep 01 23:02:48 hehe opie rockz Sep 01 23:02:58 I am using it at my simdpad Sep 01 23:03:02 args simpad Sep 01 23:03:09 jotheberlock: FYI I'm the guy who mostly maintains Opie these days :) Sep 01 23:03:38 sweet, glad someone is :) Sep 01 23:04:01 I hope to have a new release out by the end of the year Sep 01 23:04:13 bluelightning hehe Sep 01 23:05:06 still now I have a netbook I manage to make a few code changes on the train each day, so I'm making progress :) Sep 01 23:05:18 cool Sep 01 23:05:34 how long do oyu have to travel with the train everyday? Sep 01 23:06:12 only 45 mins, not that long really Sep 01 23:11:21 hm khem/hergoth wouldnt it be easy to put something in native.class which automagicly rewrites the DEPENDS lines to the nativ ones Sep 01 23:12:01 hmmm I would not want that Sep 01 23:12:12 woglinde: richard's BBEXTENDCLASS stuff for native/cross/sdk does that Sep 01 23:12:23 with BBEXTENDCLASS, you can remove the -native/-cross/-sdk recipes entirely Sep 01 23:12:26 kergoth hm Sep 01 23:12:45 have we this in oe now? Sep 01 23:12:46 I'd like to see a slightly more flexible way of producing variants like that, but its an improvement Sep 01 23:12:52 or only poky Sep 01 23:13:05 i don't think OE uses it, but it's in the bitbake repo on both trunk and 1.8 branches. not sure if its in a 1.8 release off hand Sep 01 23:13:25 bitbake change is used to produce the multiple recipes from the original + each class in BBEXTENDCLASS Sep 01 23:14:15 http://git.pokylinux.org/cgit.cgi/poky/log/?h=experimental-virtualnative Sep 01 23:14:21 was the original stuff for it Sep 01 23:14:43 http://git.pokylinux.org/cgit.cgi/poky/commit/?h=experimental-virtualnative&id=7f3769423fa81163be97c744e3ee274a8cf45aa1 adds the magic DEPENDS bits to the classes Sep 01 23:14:44 I would like this feature Sep 01 23:15:31 yeah, its nice. the only thing I'd like to see above this would be a way to produce new variants without having to use classes for it, so you could automate variants based on particular sets of autoconf arguments, for example Sep 01 23:15:47 right now its one variant per bbclasx Sep 01 23:15:48 s Sep 01 23:31:48 hm Sep 01 23:31:57 some one awake? Sep 01 23:32:32 what about merge commits should they be avoided? Sep 01 23:33:00 usually they should be IMP Sep 01 23:33:04 IMO Sep 01 23:33:29 ah rebase doing it for me Sep 01 23:34:33 03Henning Heinold  07org.openembedded.dev * r4b8b9ba87d 10openembedded.git/recipes/efl1/evas-native_svn.bb: Sep 01 23:34:33 evas-native: add libxext-native as dependency Sep 01 23:34:33 * seems evas-native used libxext from host Sep 01 23:34:33 * bump PR Sep 01 23:34:34 03Henning Heinold  07org.openembedded.dev * rf784dd2d78 10openembedded.git/recipes/xorg-lib/libx11-native_1.2.bb: libx11-native: provide native recipe for versiob 1.2 Sep 01 23:34:38 03Henning Heinold  07org.openembedded.dev * r8cc857fcbc 10openembedded.git/recipes/xorg-lib/libxext-native_1.0.5.bb: Sep 01 23:34:41 libxext-native: provide native recipe for libxext Sep 01 23:34:43 * recipe is needed for evas-native Sep 02 00:25:17 hmm Sep 02 00:28:58 * kergoth thinks about the next step in the parser rework Sep 02 00:44:49 hm debian pbuilder is cool Sep 02 00:46:08 hmm, if you have class A and class B, and you can produce a B from an A, should A have a method that returns the B, or should B have a constructor that accepts an A? Sep 02 00:46:29 uh Sep 02 00:47:19 :) I = OO noob Sep 02 00:47:25 hm in normal oo paradigma I would choose first method Sep 02 00:47:43 lol Sep 02 00:47:49 you used python so long Sep 02 00:48:14 hehe, well, in python you can pretty much pick your paradigm of choice Sep 02 00:48:37 getting a handle on functional ways of doing things, but need to brush up on the OO side Sep 02 00:50:56 03Angus Ainslie  07shr/import * rb527be0769 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs : update paroli git rev Sep 02 00:50:56 03Angus Ainslie  07shr/import * r17ffe51af5 10openembedded.git/recipes/openmoko-projects/paroli_git.bb: paroli : use correct dbus paths Sep 02 00:50:58 03Angus Ainslie  07shr/import * r465ed372e8 10openembedded.git/: Merge branch 'shr/import' of git@git.openembedded.org:openembedded into shr/import Sep 02 00:50:59 03Angus Ainslie  07shr/import * rcdbbd9d905 10openembedded.git/ (2 files in 2 dirs): bt-configure : add new recipe for bluez4 scanning and pairing Sep 02 00:55:09 kergoth, i think B having a constructor that accepts an A sounds cleaner. Sep 02 00:55:49 probably depends on the particular A and B though Sep 02 00:56:17 hmmmm Sep 02 00:59:02 kergoth: inheritence Sep 02 00:59:49 produce B from A does that mean B is base class of A or vice versa Sep 02 00:59:53 that's only a clean answer if A is a B, or B is an A Sep 02 01:00:34 or they could both inherit from a common parent Sep 02 01:00:48 e.g. A and B are both CapitalLetters Sep 02 01:01:18 grg then A is not as B Sep 02 01:01:50 i don't follow. Sep 02 01:01:58 its getting too abstract fo rme :) Sep 02 01:06:16 CaptialLetters can be parent of A and B Sep 02 01:06:45 then A can have a func which returns Captialletters Sep 02 01:07:00 and similarily B can also have Sep 02 01:07:27 i was mulling over something pretty straightforward. right now, in bb, parsing a file is... bb.parse.handle(fn) -> datastore. zecke enhanced it by adding production of a syntax tree as an intermediate step, however there's now no bb.parse. to dispatch the creation of the syntax tree, which seems bad. so i started thinking about creation of, say, an Ast object from the fn, and a DataStore object from the Ast, or whatever.. Sep 02 01:09:20 kergoth datastore contains AST? Sep 02 01:09:21 otavio: that response doesn't make sense. I don't understand "remote has been changed". If a task runs before do_fetch, the PV of that task will be the value without your autopv, so, say, do_setscene stamp will have the old PV, and subsequent stamps will have the new PV. Sep 02 01:09:47 khem: not necessarily, though it probably should, just so it can re-evaluate the ast to update the datastore if it changes Sep 02 01:13:49 just pass the AST to the DataStore's constructor Sep 02 01:14:24 wow Sep 02 01:14:30 my springpython-deb works Sep 02 01:14:31 cool Sep 02 01:14:51 hm seems I should make a oe package out of it too Sep 02 01:16:34 you can always have a redundant AST method that returns a newly created DataStor as well Sep 02 01:16:53 * grg shrugs. whatever looks cleaner i guess Sep 02 01:22:46 grg: yea, i was leaning toward the constructor way too, does seem cleaner, was just curious about best practices :) Sep 02 01:22:49 that works Sep 02 01:32:44 kergoth: you need to change the recipe, as you do for AUTOSRC, to use it. e.g.: PV = "${AUTOPV}" Sep 02 01:41:21 kergoth: gotcha? Sep 02 01:57:32 otavio: no, that still doesn't explain it. prior to the fetch, the version will be different, since there's no git repo to get the version from Sep 02 02:08:05 kergoth: do you mind to test it? Sep 02 02:08:06 :-) Sep 02 02:08:43 i can, but it sounds like you're abusing the system, ending up with stamps with differing versions is asking for trouble Sep 02 02:08:54 i'll mess with it later, just found out we have to find another place to live. stupid rentals Sep 02 02:12:14 kergoth: oh crap Sep 02 02:12:46 kergoth: well; at least here it works fine. It in theory works as same way as AUTOSRV Sep 02 02:13:07 there have been email threads about the danger of using AUTOREV in PV, as far as i know. Sep 02 02:13:19 kergoth: obviously it is slower a bit since it needs to fetch and check if it has been change Sep 02 02:13:25 kergoth: yes, autorev, sorry Sep 02 02:13:48 kergoth: but it works fine for us and we've been using it for a while Sep 02 02:14:10 well, i'll take a look. I still think it's probably not a very good idea, but I could be mistaken. Will see Sep 02 02:14:44 kergoth: if you can think in a better way of doing it I'd love to hear it from you Sep 02 02:15:29 there isn't a better way of doing it. PV based on fetched sources means PV changes from task to task Sep 02 02:15:34 just the nature of it Sep 02 02:18:32 kergoth: in this case, maybe, your gitver class could use this change in bitbake to provide it in a more "integrated way" Sep 02 02:18:39 kergoth: what do you think? Sep 02 02:19:47 yeah, perhaps Sep 02 02:22:18 i'll play around with it this week some time and let you know. either way, its not a bad idea to have it in OE as a transition, at least until we bump the minimum required bitbake version for OpenEmbedded Sep 02 02:22:25 adding functionality to bitbake is a pain in that way :) Sep 02 02:25:47 kergoth: heh Sep 02 02:25:55 kergoth: what about a new bitbake release? Sep 02 02:26:16 kergoth: it makes a lot of sense for me specially since it has improved quite a bit since 1.8.12 Sep 02 02:27:01 well, there's some question about the 1.8 branch. i guess we should probably keep zecke's parse rework on the trunk due to the invasiveness of the change Sep 02 02:30:17 he originally wrote it against 1.8, but rebasing it onto master was easy enough, there's a branch for it now Sep 02 02:30:27 * kergoth 'll take a look at a shortlog from the last release to the tip of 1.8 Sep 02 02:30:38 i think zecke's been doing the releases lately Sep 02 02:38:33 kergoth: :-) thx Sep 02 02:38:41 np **** ENDING LOGGING AT Wed Sep 02 02:59:58 2009