| 00:08.39 | *** join/#oe waite (n=bwaite@c-24-91-81-44.hsd1.ma.comcast.net) |
| 00:13.40 | *** join/#oe cedric (n=cedric@enlightenment/developer/cedric) |
| 00:15.04 | m4t | my ide slc dom arrived today |
| 00:15.07 | m4t | quite small |
| 00:15.29 | m4t | innodisk edc 8000 2gb |
| 00:30.53 | *** join/#oe kergoth (n=kergoth@ip68-108-193-231.ph.ph.cox.net) |
| 01:10.59 | *** join/#oe rsalveti (n=rsalveti@189.70.48.107) |
| 01:23.50 | *** join/#oe archae0pteryx1 (n=snewman@207.47.42.130.static.nextweb.net) |
| 01:37.44 | *** join/#oe DuckFault (n=DuckFaul@rrcs-71-43-24-33.se.biz.rr.com) |
| 01:50.29 | *** join/#oe BenLauDC (n=benlau@221.125.8.105) |
| 01:54.59 | *** join/#oe mekius (n=mekius@enlightenment/developer/mekius) |
| 02:02.15 | *** join/#oe fraxinath (n=quassel@p54AA6BC9.dip.t-dialin.net) |
| 02:19.13 | *** join/#oe hufnus_cicq (n=hufnus_c@69-12-177-67.dsl.static.sonic.net) |
| 02:20.58 | *** join/#oe aloisiojr (n=aloisio@189.81.118.1) |
| 02:32.23 | *** join/#oe ctusar (n=ctusar@c-71-58-119-148.hsd1.pa.comcast.net) |
| 02:33.47 | *** part/#oe sabrod (n=sabrod@mic92-8-82-234-143-184.fbx.proxad.net) |
| 02:36.06 | *** join/#oe pb_ (n=pb@212-139-92-236.dynamic.dsl.as9105.com) [NETSPLIT VICTIM] |
| 02:36.06 | *** join/#oe simon42 (n=simon@89.238.65.10) [NETSPLIT VICTIM] |
| 02:44.47 | m4t | is there a way i can populate /dev with udev/mdev after initial boot? |
| 02:49.59 | grg | m4t, as opposed to? |
| 02:50.41 | grg | you could create a static /dev and run udev/mdev at any point after boot. |
| 02:50.51 | m4t | erm, okay well all i can fit into this initramfs is micro-image |
| 02:51.05 | grg | you want a static /dev |
| 02:51.06 | m4t | i am limited to transferring files via netcat currently |
| 02:51.12 | grg | :) |
| 02:51.17 | m4t | okay, is there a good way to populate it? |
| 02:51.32 | m4t | my disk-on-module is showing up as hde and i'm not feeling right, to do some major/minor math |
| 02:51.57 | grg | openembedded/files/device_table-minimal.txt |
| 02:52.19 | m4t | oh cool |
| 02:52.20 | m4t | thanks |
| 02:52.25 | m4t | hde: InnoDisk Corp. - EDC8000 2GB, ATA DISK drive |
| 02:52.26 | m4t | btw :) |
| 02:52.32 | m4t | finally get to try to bootstrap this |
| 02:53.23 | m4t | <PROTECTED> |
| 02:53.26 | m4t | is what i needed |
| 02:53.34 | grg | image.bblcass looks at IMAGE_DEVICE_TABLES to find the right device table. I assume for a micro-image it would try to use the minimal table. |
| 02:54.11 | grg | just make your own device table file and put it in an overlay, then point IMAGE_DEVICE_TABLES at your newly created file. |
| 02:54.17 | m4t | alright |
| 02:54.24 | m4t | actually thats sde, i need hde |
| 02:56.05 | m4t | that is good to know though |
| 02:56.11 | m4t | i think this system will be running udev |
| 02:57.15 | grg | having a usable static /dev is useful if you want to defer starting udev until after your GUI loads too. |
| 02:57.34 | grg | on my system starting udev takes ~15seconds |
| 02:57.47 | grg | no idea why its so slow |
| 03:00.44 | m4t | cool, i got an ext3 fs mounted and swap activated |
| 03:02.44 | grg | what have you got that disk attached to? |
| 03:11.00 | *** join/#oe Laibsch1 (n=Laibsch@p5B3B1D10.dip.t-dialin.net) |
| 03:12.02 | m4t | grg it plugs right into the ide port |
| 03:12.03 | m4t | tiny |
| 03:12.21 | m4t | i had to rig up a molex female-to-female 4pin to hook up to the power cable |
| 03:12.35 | m4t | its advertised as like 70-80mb/s |
| 03:12.58 | m4t | very new tech, the firmware is from 6/01/09 and the serial hints to a 7/01 manufacturing batch |
| 03:21.35 | m4t | http://pastebin.com/d2dd87586 |
| 03:21.36 | m4t | :/ |
| 03:21.41 | m4t | i get 'bad crc' |
| 03:22.26 | *** join/#oe toi (n=toi@d515304E5.static.telenet.be) |
| 03:23.09 | m4t | okay well, it just booted off the disk with a tftpboot |
| 03:23.12 | m4t | any idea? |
| 03:33.47 | *** join/#oe thaytan_ (n=jan@78.16.104.61) |
| 04:10.19 | m4t | hah oh |
| 04:10.19 | m4t | i was booting from 0:1, 0:2 worked |
| 04:10.19 | m4t | strange |
| 04:29.53 | m4t | now it wont recognize the ext3 i just mkfs.ext3 and cpio -idmv on :/ |
| 04:30.00 | m4t | it mounted fine, from the same kernel |
| 04:30.24 | m4t | No filesystem could mount root, tried: ext3 |
| 04:39.22 | *** join/#oe eFfeM (n=frans@j192117.upc-j.chello.nl) |
| 04:56.45 | m4t | argh, udev hang |
| 04:59.00 | m4t | :( |
| 04:59.07 | m4t | it 'boots' |
| 05:00.13 | m4t | this is base-image / ppc405gp / gcc 4.4.1 / uclibc 9.30.1 btw |
| 05:06.40 | *** join/#oe MostAwes1meDude (n=simpson@c-67-170-132-127.hsd1.or.comcast.net) |
| 05:08.48 | *** join/#oe mrmoku|away (n=mrmoku@ppp-62-216-212-159.dynamic.mnet-online.de) |
| 05:13.46 | *** join/#oe MostAwesomeDude (n=simpson@c-67-170-132-127.hsd1.or.comcast.net) |
| 05:15.20 | *** join/#oe MostAwesomeDude (n=simpson@c-67-170-132-127.hsd1.or.comcast.net) |
| 05:22.23 | *** join/#oe MostAwesomeDude (n=simpson@c-67-170-132-127.hsd1.or.comcast.net) |
| 05:34.28 | *** join/#oe AvengerMoJo (n=alex@61.14.130.200) |
| 05:42.17 | *** join/#oe rddDavid51 (n=roudoudo@78.234.93.192) |
| 05:46.38 | czr_ | mornink |
| 05:53.10 | m4t | hi czr_ |
| 05:53.57 | *** join/#oe mrc3__ (n=ddiaz@189.157.108.164) |
| 06:02.29 | khem | m4t: bad CRC could be because flash programming did not work |
| 06:02.38 | khem | http://www.denx.de/wiki/view/DULG/UBootCmdGroupInfo#Section_5.9.1.4. |
| 06:03.03 | khem | m4t try imi command |
| 06:04.06 | khem | m4t: Did you get 4.4.1 gcc going in your env |
| 06:05.29 | m4t | khem , yea i am ~sucessfully booting from disk |
| 06:05.34 | m4t | via u-boot 1.2.0 |
| 06:05.52 | m4t | i got that slc flash module today, finally |
| 06:05.59 | m4t | it works good, i need to play with hdparm |
| 06:06.11 | m4t | the one problem i am having is with the initial boot into an image |
| 06:06.20 | m4t | no errors, but udev takes forever |
| 06:06.35 | m4t | then console freezes at 'configuring software packages' |
| 06:07.21 | m4t | http://pastebin.com/d2fac2197 |
| 06:07.43 | khem | m4t: nice |
| 06:07.46 | m4t | actualy udev isnt creating the device tree it doesnt seem |
| 06:08.02 | m4t | when it tries to remount root, it can't find /dev/hde2 |
| 06:08.18 | m4t | the only thing i changed was /etc/fstab in base-image |
| 06:08.35 | khem | m4t: do you have tmpfs enabled ? |
| 06:08.44 | khem | in kernel |
| 06:09.07 | m4t | haha, it would be something to check |
| 06:09.15 | m4t | i think i do... |
| 06:09.21 | m4t | maybe i only have full ramdisk |
| 06:10.09 | m4t | CONFIG_TMPFS=y |
| 06:10.33 | *** join/#oe dos1 (n=dos@unaffiliated/dos1) |
| 06:14.25 | *** join/#oe tsjsieb (n=tsjsieb@dejongbeheer.nl) |
| 06:14.31 | m4t | i could try 'minimalist' as well, it didnt seem too much difference, except for the inclusion of gettext |
| 06:20.01 | *** join/#oe mithro (n=tim@unaffiliated/mithro) |
| 06:20.53 | *** join/#oe thebohemian (n=rschus@p5DDC7F57.dip.t-dialin.net) |
| 06:24.21 | *** join/#oe hillct (n=hillct@cpe-069-134-049-165.nc.res.rr.com) |
| 06:25.16 | *** join/#oe hillct (n=hillct@cpe-069-134-049-165.nc.res.rr.com) |
| 06:26.40 | *** join/#oe jeremy_laine (n=sharky@mna75-4-81-56-56-40.fbx.proxad.net) |
| 06:28.23 | *** join/#oe fpga (n=s@92.62.56.51) |
| 06:29.32 | *** join/#oe ZaPPaS (n=moritz@buero2.pi5.physik.uni-stuttgart.de) |
| 06:30.46 | eFfeM | anyone care to comment what is best for a webserver on an embedded system: apache, lighttpd, mini-httpd, thttpd |
| 06:30.52 | eFfeM | we seem to have recipes for all of these |
| 06:31.14 | eFfeM | (but I would need support for php (natively or through cgi) |
| 06:34.28 | eFfeM | is reading http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers |
| 06:35.35 | grg | php kind of defeats the purpose of having a lightweight web server |
| 06:35.51 | grg | whatever you use, its instantly heavy |
| 06:36.08 | eFfeM | true, but there are things where you need it |
| 06:36.26 | eFfeM | alternative (also possible) is a dedicated cgi script |
| 06:36.32 | eFfeM | not sure whether that is preferable |
| 06:36.50 | grg | what do you mean by a dedicated cgi script? |
| 06:37.01 | grg | php run as a cgi? |
| 06:37.05 | eFfeM | noooo |
| 06:37.32 | grg | an c program compiled and run as a cgi? |
| 06:37.51 | eFfeM | 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 |
| 06:38.36 | grg | keep it simple |
| 06:38.52 | eFfeM | i'd love to :-) |
| 06:39.10 | eFfeM | but ofc I do not want to sacrifice too much on performance and functionality |
| 06:39.24 | grg | sounds like a couple of lines of shell |
| 06:39.33 | eFfeM | yes |
| 06:39.41 | grg | what are your resource limitations? |
| 06:39.47 | eFfeM | actually that was just an example |
| 06:39.50 | grg | and how many concurrent users? |
| 06:40.32 | eFfeM | 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) |
| 06:40.58 | eFfeM | typically there will be only one user, but there can be cases where there might be a few |
| 06:40.59 | *** join/#oe sgh (n=quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 06:41.19 | eFfeM | idea is to control an embedded device through a set of web pages |
| 06:41.42 | grg | just use apache |
| 06:42.22 | grg | well... use whatever you're already most familiar with. apache is a good choice if that does not help |
| 06:42.28 | czr_ | eFfeM, don't use thttpd :-) |
| 06:42.35 | eFfeM | i'm doing that now, thought lighttpd would be a more resource friendly alternative that is fairly compatibile |
| 06:42.42 | czr_ | we decided to use it a year ago and are hitting all kinds of wonderful problems with it. |
| 06:42.44 | eFfeM | czrr_ why not ? |
| 06:42.51 | eFfeM | ok thanks for the warning |
| 06:43.17 | czr_ | let me check for the other new server that might be more suitable |
| 06:43.37 | czr_ | http://nginx.net/ <- hearing many good things about this lately |
| 06:44.07 | czr_ | it probably has more than you bargained for, but reportedly it's wicked fast at serving regular stuff as well. |
| 06:44.12 | czr_ | (fast as in light-weight) |
| 06:44.31 | grg | czr, what sort of problems are you seeing? |
| 06:44.49 | czr_ | well, in our case we have a background process that generates pngs into a cache dir. |
| 06:44.54 | czr_ | then we serve the pictures using static thttpd |
| 06:45.02 | czr_ | except that once the pictures are stale, they're removed |
| 06:45.08 | czr_ | externally to thttpd that is. |
| 06:45.31 | czr_ | since thttpd will mmap all files that it serves, it will keep the cache occupied even if the files (names) are removed |
| 06:45.53 | czr_ | 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.. :-) |
| 06:46.16 | czr_ | also, something thttpd just dies when dealing with back-to-back cgi operations and such |
| 06:46.27 | grg | ok |
| 06:46.29 | eFfeM | didn't know nginx, looks interesting |
| 06:46.31 | czr_ | so, it's not a bug bug per se, more of a design issue. |
| 06:47.01 | czr_ | 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 |
| 06:47.12 | grg | from memory, apache uses sendfile(2). so that should be reasonable |
| 06:47.23 | czr_ | yes. |
| 06:47.28 | czr_ | but apache uses a lot of memory |
| 06:47.38 | eFfeM | csr_, thanks for the info, one of the htings I need to so is serve downscaled pics which may be removed |
| 06:47.39 | grg | that's a good reason to use apache 1.3.x :) |
| 06:47.42 | czr_ | per connection, even if the client doesn't do anything. |
| 06:48.09 | czr_ | eFfeM, right. then you don't use thttpd :-). |
| 06:48.20 | czr_ | or, you do, and then bang your head against the wall after some months ;-) |
| 06:48.41 | czr_ | blames his boss how wanted a working solution fast never mind the ramifications. |
| 06:48.45 | eFfeM | noticed nginx also has auth support (which I also need) |
| 06:48.48 | czr_ | s/how/who/. |
| 06:49.36 | *** join/#oe benlau2 (n=benlau@221.125.8.70) |
| 06:50.32 | eFfeM | will nginx also support multiple web server (might need to run 2 (on different ports ofc) |
| 06:50.39 | eFfeM | is browsing the nginx doc |
| 06:50.41 | czr_ | obviously :-) |
| 06:50.58 | czr_ | or rather, I don't know, but I'd guess so. it's designed for heavy loads. |
| 06:51.58 | czr_ | eFfeM, anyhow, I never ended up packaging nginx for oe, it has some dependencies that I wasn't ready to solve at that point. |
| 06:52.01 | eFfeM | found that, but heavy load often means that one server on a system is more than enough |
| 06:52.09 | eFfeM | it does do virtual hosts |
| 06:52.12 | czr_ | and it's slightly too heavy-weight for our needs (we only have 32 MiB RAM) |
| 06:52.21 | eFfeM | ah ok |
| 06:52.30 | eFfeM | and what did you use in the end? |
| 06:52.49 | czr_ | coughs |
| 06:52.55 | czr_ | custom httpd server? |
| 06:52.58 | czr_ | coughs |
| 06:53.06 | eFfeM | (btw I've also been looking at wt (witty) to remotely control my device |
| 06:53.56 | czr_ | interesting, didn't notice that. |
| 06:53.58 | eFfeM | hands czr_ some sweets to relief the coughing |
| 06:54.17 | czr_ | unless they contain large amounts of alcohol, I'll pass, thanks ;-) |
| 06:54.25 | eFfeM | http://www.webtoolkit.eu/wt |
| 06:54.34 | mckoan | good morning |
| 06:54.40 | eFfeM | hi mckoan |
| 06:55.03 | czr_ | mornink |
| 06:55.05 | eFfeM | czr_ that is why I also peeked at mini -httpd and microhttpd |
| 06:55.09 | mckoan | hi all |
| 06:55.29 | eFfeM | i do have 512 MB but definitely some if it will be used for other purposes |
| 06:55.50 | czr_ | eFfeM, you might want to select something that is maintained. |
| 06:55.52 | eFfeM | and in order to keep the performance I'd like to avoid swapping |
| 06:55.58 | eFfeM | yes definitely |
| 06:56.10 | eFfeM | is lazy and dislikes maintenance :-) |
| 06:59.59 | *** join/#oe Longfield (n=valentin@128.178.145.53) |
| 07:00.51 | grg | 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 |
| 07:01.07 | eFfeM | you have a point |
| 07:01.24 | czr_ | except it cannot fix this: http://isc.sans.org/diary.html?storyid=6601 |
| 07:01.37 | czr_ | although, not all web servers can. design issue. |
| 07:01.47 | eFfeM | i'm only doing a prototype now, but would like to reuse as much as possible |
| 07:01.50 | grg | ensure that your web app is generic enough that it can work with other browsers and change it later iff necessary. |
| 07:01.57 | eFfeM | (i told you I am lazy) |
| 07:02.04 | grg | s/other browsers/other servers/ |
| 07:02.21 | eFfeM | grg that is a plus for apache, some of the web app will be from open source |
| 07:02.29 | eFfeM | (i'm thinking of a photo gallery) |
| 07:02.44 | eFfeM | guess my chances are bigger with apache |
| 07:03.39 | czr_ | shrugs |
| 07:04.25 | eFfeM | well i'm trying to balance prototype dev effort and later product reuse |
| 07:04.33 | grg | czr, interesting DoS. But a DoS is not a major issue for an embedded device on a local network with 1-few users. |
| 07:04.41 | eFfeM | that is why i find nginx ivyer interesting |
| 07:05.14 | m4t | khem : i found several kernel options that i didnt have right |
| 07:05.27 | m4t | in the udev readme: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=README |
| 07:05.55 | m4t | hotplug_helper was set to /sbin/hotplug, i didnt have tmpfs_posix_acl, etc. |
| 07:05.56 | eFfeM | (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) |
| 07:06.45 | m4t | eFfeM there are a bunch of nifty small http servers |
| 07:07.05 | m4t | http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers |
| 07:07.12 | eFfeM | m4t: i know, trying to balance between performance and functionlaity |
| 07:07.14 | *** join/#oe noglitch (n=Miranda@mail.atmel.fr) |
| 07:07.32 | eFfeM | m4t: (08:34:28 AM) ***eFfeM is reading http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers |
| 07:07.34 | eFfeM | :-) |
| 07:09.11 | *** join/#oe xjqian (n=gordon@128.252.118.150) |
| 07:09.19 | eFfeM | but thanks anyway |
| 07:09.29 | m4t | oh |
| 07:09.35 | eFfeM | np |
| 07:10.20 | m4t | hah |
| 07:10.30 | m4t | yea i read that a couple weeks ago, nginx caught my eye |
| 07:10.54 | czr_ | 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. |
| 07:11.00 | czr_ | grg, but in general, I do agree with you. |
| 07:11.25 | czr_ | as to the "dos", a lot of network service implementations based on TCP have similar issues |
| 07:13.29 | grg | 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 |
| 07:14.00 | czr_ | grg, except that until that time they cannot serve new connections since they've exhausted all memory |
| 07:14.03 | czr_ | which is the core of the dos. |
| 07:14.16 | czr_ | but i digress, who cares.. :-) |
| 07:14.41 | grg | timeout=10 would be fine i guess. |
| 07:14.54 | grg | offtopic. yes :) |
| 07:15.02 | czr_ | except that would break large file uploads over slow links ;-) |
| 07:15.06 | czr_ | yes, definitely OT ;-). |
| 07:15.22 | grg | the dos is only for sending the headers though... |
| 07:15.33 | czr_ | yes, thought of that.. |
| 07:15.44 | czr_ | shrugs and tries to focus on some real work |
| 07:15.58 | grg | tries to focus on heading home in 15 mins |
| 07:16.04 | grg | :D |
| 07:16.13 | czr_ | works from home today.. |
| 07:17.19 | eFfeM | is at home too, still morning here |
| 07:22.35 | *** join/#oe cyberdeck (n=cyberdec@iss66.vlsi.informatik.tu-darmstadt.de) |
| 07:23.43 | m4t | even with my kernel looking just like the one from the udev README, still no go |
| 07:25.58 | *** join/#oe Hasse_ (n=quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 07:30.35 | eFfeM | need a reboot & coffee, back in a while |
| 07:31.30 | *** join/#oe MWelchUK (n=welchma@65.91.2.71) |
| 07:32.57 | *** join/#oe eFfeM (n=frans@j192117.upc-j.chello.nl) |
| 07:35.01 | *** join/#oe Pr0t0N (n=lcintrat@fe2adsl-2.wyplay.net) |
| 07:36.46 | *** join/#oe noglitch (n=Miranda@mail.atmel.fr) |
| 07:41.27 | *** join/#oe kristoffer (n=kristoff@95.209.11.125.bredband.tre.se) |
| 07:42.45 | *** join/#oe lrg (n=lrg@host81-136-218-57.in-addr.btopenworld.com) |
| 07:50.27 | *** join/#oe DuckFault (n=DuckFaul@rrcs-71-43-24-33.se.biz.rr.com) |
| 07:58.29 | *** join/#oe jest (n=jest@150.254.6.123) |
| 08:00.40 | *** join/#oe stefan_schmidt (n=stefan@p5B035231.dip.t-dialin.net) |
| 08:02.09 | *** join/#oe stefan_schmidt_ (n=stefan@p5B035231.dip.t-dialin.net) |
| 08:02.17 | *** join/#oe stefan_schmidt (n=stefan@p5B035231.dip.t-dialin.net) |
| 08:05.20 | *** join/#oe pvanhoof (n=pvanhoof@d54C0C0BA.access.telenet.be) |
| 08:10.11 | *** join/#oe mpr (n=mpr@aggr.com) |
| 08:17.00 | XorA|gone | ooops debian lenny is really badly tested |
| 08:18.05 | *** join/#oe jovox (n=jovox@fw1.q-matic.se) |
| 08:20.12 | *** join/#oe florian_kc (n=fuchs@port-217-146-132-69.static.qsc.de) |
| 08:22.20 | jovox | 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. |
| 08:24.51 | florian | good morning |
| 08:25.11 | *** join/#oe dos1|school (n=dos@unaffiliated/dos1) |
| 08:28.56 | mckoan | hi florian |
| 08:29.14 | CIA-1 | 03Sebastian Krzyszkowiak <seba.dos1@gmail.com> 07shr/import * r4bd5a6dbd6 10openembedded.git/recipes/aceofpenguins/ (aceofpenguins-launcher_0.1.bb aceofpenguins-launcher_0.2.bb): recipes/aceofpenguins/aceofpenguins-launcher_0.1.bb |
| 08:29.19 | *** join/#oe booxter (n=booxter@cpmsq.epam.com) |
| 08:29.23 | *** join/#oe markos_ (n=markos@79.131.253.223) |
| 08:33.36 | *** join/#oe woglinde (n=henning@p5DDC7F57.dip.t-dialin.net) |
| 08:34.27 | Hasse_ | Hi there :) I'm new to this forum. To whom or where do I ask about boot issues of the console-image?? |
| 08:34.53 | *** join/#oe ArteK (n=Artur@81.15.241.96) |
| 08:46.40 | woglinde | hasse just ask |
| 08:46.51 | mckoan | ~ask |
| 08:46.52 | ibot | 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. |
| 08:46.52 | booxter | 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 |
| 08:47.18 | booxter | mckoan: wow, good command, tnx for info! :) |
| 08:47.42 | mckoan | :-D |
| 08:48.06 | booxter | maybe info on pastebin will be usefull too |
| 08:48.18 | mckoan | ~pastebin |
| 08:48.19 | ibot | [~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 |
| 08:48.27 | booxter | ahahaha, nice job |
| 08:49.04 | booxter | I'm making a crib... :) |
| 08:50.37 | booxter | mckoan: where is ibot interface documented? |
| 08:52.04 | eFfeM | can users learn ibot new commands? |
| 08:52.07 | *** part/#oe ArteK (n=Artur@81.15.241.96) |
| 08:52.40 | *** join/#oe ArteK (n=Artur@81.15.241.96) |
| 08:54.10 | eFfeM | ~ibot |
| 08:54.11 | ibot | It's me |
| 08:54.16 | eFfeM | <grin> |
| 08:54.24 | eFfeM | ~ibot help |
| 08:54.39 | eFfeM | ~help |
| 08:54.41 | booxter | eFfeM: you can ask him privately for 'help' |
| 08:54.51 | booxter | but there is no info on ~pastebin etc. |
| 08:56.17 | *** join/#oe cedric (n=cedric@enlightenment/developer/cedric) |
| 08:56.27 | eFfeM | i would like to know how to teach new ~ things |
| 08:59.03 | XorA | ~xora |
| 08:59.04 | ibot | it has been said that xora is Graeme Gregory - generic hacker of stuff in OpenEmbedded, or an OpenMoko employee |
| 08:59.14 | XorA | ibot: forget xora |
| 08:59.14 | ibot | i forgot xora, XorA |
| 08:59.51 | XorA | ibot: xora is Graeme Gregory - generic hacker of stuff in OpenEmbedded/Angstrom and a freelancer |
| 08:59.52 | ibot | okay, XorA |
| 08:59.57 | XorA | eFfeM: thats how |
| 09:01.04 | florian | ~florian |
| 09:01.07 | booxter | wow |
| 09:01.44 | florian | ibot doesn't seem to like me :) |
| 09:02.04 | booxter | ibot: who is xora? |
| 09:02.05 | ibot | rumour has it, xora is Graeme Gregory - generic hacker of stuff in OpenEmbedded/Angstrom and a freelancer |
| 09:05.28 | eFfeM | XorA: thanks |
| 09:06.17 | eFfeM | ibot: florian is dunno, ibot does not like florian :-) |
| 09:06.17 | ibot | okay, eFfeM |
| 09:06.20 | eFfeM | ~florian |
| 09:06.20 | ibot | it has been said that florian is dunno, ibot does not like florian :-) |
| 09:06.34 | eFfeM | florian, this better ? |
| 09:06.55 | eFfeM | ibot: florian is ibot does not like florian :-) |
| 09:06.55 | ibot | ...but florian is already something else... |
| 09:06.56 | florian | hrm |
| 09:06.58 | eFfeM | or this better? |
| 09:07.10 | eFfeM | ibot: forget florian |
| 09:07.10 | ibot | eFfeM: i forgot florian |
| 09:07.34 | florian | ~botsnack |
| 09:07.34 | ibot | florian: :) |
| 09:07.53 | eFfeM | ah you're tying to become friends |
| 09:08.59 | eFfeM | ibot: eFfeM is a hacker from the Netherlands roaming around on freenode at irregular intervals |
| 09:09.00 | ibot | okay, eFfeM |
| 09:09.23 | eFfeM | ibot: ty |
| 09:09.24 | ibot | rumour has it, ty is thank you, or cobb -- a baseball player |
| 09:10.09 | eFfeM | let's see if it knows the basic netiquette |
| 09:10.11 | eFfeM | ~rtfm |
| 09:10.12 | ibot | 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 |
| 09:10.32 | eFfeM | ah that is going to be useful :-) |
| 09:10.47 | eFfeM | guess it shows off eFfeM is a little bit bored atm |
| 09:10.56 | *** join/#oe fpga (n=s@92.62.56.51) |
| 09:12.05 | eFfeM | ibot: nickometer xora |
| 09:12.06 | florian | eFfeM: oh, don't mention this here - what about taking a look at bugs.openembedded.org? ;) |
| 09:12.29 | eFfeM | florian ;) |
| 09:12.52 | eFfeM | should do so, but atm on a different project |
| 09:15.15 | czr_ | florian, the pages need a redesign? |
| 09:15.17 | czr_ | hides & runs |
| 09:15.39 | florian | :-) |
| 09:17.16 | Hasser | booxter: thx man, I meant forum as in area... ;) |
| 09:22.50 | *** part/#oe jovox (n=jovox@fw1.q-matic.se) |
| 09:28.12 | pb__ | florian: good morning |
| 09:28.27 | florian | hi pb__ |
| 09:30.51 | woglinde | johi pb |
| 09:35.59 | *** join/#oe Pr0t0N (n=lcintrat@fe2adsl-2.wyplay.net) |
| 09:37.07 | pb__ | hi woglinde |
| 09:37.33 | CIA-1 | 03Brijesh Singh <a0270506@incredibles.(none)> 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 |
| 09:57.13 | *** join/#oe stephank (n=traveler@2001:1af8:fe5f:0:21c:c4ff:fece:ea94) |
| 10:04.42 | *** join/#oe fpga (n=s@92.62.56.51) |
| 10:09.10 | *** join/#oe patrice (n=Miranda@mail.atmel.fr) |
| 10:14.17 | *** join/#oe Sleep_Walker (n=Sleep@gprs8.vodafone.cz) |
| 10:19.00 | *** join/#oe dth_ehb (i=59b61d3b@gateway/web/freenode/x-dlhpzltciccayyqg) |
| 10:20.34 | *** join/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de) |
| 10:26.44 | *** join/#oe tmbinc_ (i=abcd@83.141.3.59) |
| 10:28.18 | *** join/#oe rsv (i=7aa62e54@gateway/web/freenode/x-grlsvqoracnvkexu) |
| 10:29.45 | *** join/#oe ptitjes (n=didier@93.2.7.143) |
| 10:33.50 | *** join/#oe hrw (n=hrw@chello089078170228.chello.pl) |
| 10:35.38 | *** join/#oe booxter (n=booxter@cpmsq.epam.com) |
| 10:36.41 | *** join/#oe booxter (n=booxter@cpmsq.epam.com) |
| 10:37.35 | hrw | re |
| 10:39.31 | *** join/#oe booxter (n=booxter@217.21.56.2) |
| 10:40.07 | *** join/#oe Spyro (n=ian@benden.mnementh.co.uk) |
| 10:40.48 | *** join/#oe raster (n=raster@enlightenment/developer/raster) |
| 10:41.45 | *** join/#oe booxter (n=booxter@217.21.56.2) |
| 10:44.27 | *** join/#oe booxter (n=booxter@cpmsq.epam.com) |
| 10:44.37 | *** join/#oe Sleep-Walker (n=Sleep@nat/novell/x-rnotywtbovvjsxjx) |
| 10:45.01 | *** join/#oe booxter (n=booxter@cpmsq.epam.com) |
| 10:48.23 | *** join/#oe rob_w_ (n=bill@p549BBE96.dip.t-dialin.net) |
| 10:48.31 | *** join/#oe pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 11:00.03 | *** join/#oe thaytan_ (n=jan@192.18.8.1) |
| 11:26.50 | *** join/#oe fpga1 (n=s@92.62.56.51) |
| 11:41.45 | *** join/#oe ArteK (n=Artur@81.15.241.96) |
| 11:42.56 | *** join/#oe mario-goulart (n=user@201.40.162.47) |
| 12:04.50 | *** join/#oe waite (n=bwaite@206.83.81.178) |
| 12:06.19 | *** join/#oe woglinde (n=henning@p5DDC7F57.dip.t-dialin.net) |
| 12:08.26 | *** join/#oe otavio (n=otavio@debian/developer/otavio) |
| 12:12.27 | *** join/#oe BenLauDC (n=benlau@221.125.8.105) |
| 12:12.58 | *** join/#oe rkirti (n=oespirit@203.199.213.3) |
| 12:13.12 | woglinde | hi rjirti |
| 12:13.15 | woglinde | ups rkirti |
| 12:13.25 | rkirti | hello woglinde |
| 12:13.33 | rkirti | good morning everyone |
| 12:18.01 | *** part/#oe ArteK (n=Artur@81.15.241.96) |
| 12:22.31 | *** join/#oe ArteK (n=Artur@81.15.241.96) |
| 12:34.13 | *** join/#oe shoragan (n=shoragan@debian/developer/shoragan) |
| 12:40.51 | patrice | Hi |
| 12:43.42 | *** join/#oe aloisiojr (n=aloisio@200.184.118.130) |
| 12:45.17 | *** join/#oe benlau2 (n=benlau@221.125.8.104) |
| 12:51.04 | pb__ | morning cbrake |
| 12:53.19 | *** join/#oe manav (n=manav@59.160.172.220) |
| 12:55.43 | *** join/#oe kristoffer (n=kristoff@79.138.156.80.bredband.tre.se) |
| 12:55.58 | *** join/#oe vo5 (n=vo@bd21096b.virtua.com.br) |
| 13:00.12 | *** join/#oe ctusar (n=ctusar@router2.videon-central.net) |
| 13:04.47 | chouimat | morning |
| 13:04.52 | woglinde | hi chouimat |
| 13:07.36 | *** join/#oe cminyard (n=cminyard@pool-173-57-157-176.dllstx.fios.verizon.net) |
| 13:08.06 | *** join/#oe rkirti_ (i=cbc7d5e3@gateway/web/freenode/x-caufetqxnfaqduzq) |
| 13:11.22 | *** part/#oe ArteK (n=Artur@81.15.241.96) |
| 13:12.37 | *** join/#oe boris_OmegA (i=boris@lns-bzn-52-82-65-124-19.adsl.proxad.net) |
| 13:15.26 | *** join/#oe dth_ (i=59b61d3b@gateway/web/freenode/x-udomffzxdtmyigtx) |
| 13:16.28 | *** part/#oe dth_ (i=59b61d3b@gateway/web/freenode/x-udomffzxdtmyigtx) |
| 13:16.48 | *** join/#oe dth_ (i=59b61d3b@gateway/web/freenode/x-kwrpgnwocoafordd) |
| 13:17.36 | *** join/#oe munzur (n=caner@85.101.57.225) |
| 13:21.45 | *** join/#oe sgh (n=quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 13:28.39 | *** join/#oe stefan_schmidt_ (n=stefan@p5B03408B.dip.t-dialin.net) |
| 13:35.58 | hrw | ho |
| 13:53.38 | *** part/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de) |
| 13:54.47 | *** join/#oe eFfeM (n=nly91006@ip-145-93-232-32.fontys.nl) |
| 13:58.40 | *** part/#oe thebohemian (n=rschus@p5DDC7F57.dip.t-dialin.net) |
| 13:59.46 | tardyp | hey oe experts! |
| 14:00.11 | tardyp | do you know an easy way to force link with g++? |
| 14:00.21 | tardyp | is pkgconfig allowing this? |
| 14:00.46 | eFfeM | g++ -o output input.o |
| 14:00.47 | eFfeM | ? |
| 14:01.00 | eFfeM | g++ will still use the linker for linking though |
| 14:01.25 | pb__ | 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? |
| 14:01.43 | tardyp | well my libgles is requiring g++ |
| 14:01.55 | pb__ | why? |
| 14:02.03 | eFfeM | if it is a g++ lib then use -lg++ or so |
| 14:02.05 | tardyp | though every program linked with clutter needs stdc++ |
| 14:02.38 | tardyp | g++ is supposed to automaticaly add several c++ libs and linker directives |
| 14:02.50 | pb__ | it should be getting the libs automatically via DT_NEEDED. |
| 14:02.58 | pb__ | what are the linker directives that you need? |
| 14:03.05 | tardyp | pb_, the gles implementation is implemented in g++ |
| 14:03.06 | CIA-1 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rab3fe804ca 10openembedded.git/recipes/xscreensaver/ (xscreensaver.inc xscreensaver_5.07.bb): xscreensaver: fix packaging and QA |
| 14:04.04 | pb__ | 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. |
| 14:04.19 | tardyp | I see. |
| 14:04.30 | tardyp | its a binary only proprietary lib |
| 14:04.41 | tardyp | probably not linked properly I supposed |
| 14:04.54 | pb__ | ah, I see |
| 14:05.32 | pb__ | 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. |
| 14:06.53 | tardyp | pb_, sounds good. |
| 14:08.47 | tardyp | pb_, you think: "g++ -shared -o libGLESv2 -lgles20" will do the trick ? |
| 14:09.28 | pb__ | it should do, yes. |
| 14:09.44 | pb__ | you might want to call it "libGLESv2.so", but otherwise I think that's fine |
| 14:10.02 | tardyp | yes of course |
| 14:10.13 | pb__ | 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. |
| 14:10.32 | tardyp | pb__, thanks for your wisdom... will you be at ELCE? |
| 14:11.22 | hrw | tardyp: LD=${CXX}? |
| 14:11.45 | pb__ | tardyp: I don't think so. |
| 14:11.57 | tardyp | hrw, yes, but then I'll need to change all the clients reciepes |
| 14:12.21 | hrw | tardyp: freescale stuff... |
| 14:12.52 | tardyp | hrw, proprietary shit :/ |
| 14:13.24 | hrw | tardyp: is not the one and same? |
| 14:13.26 | hrw | ;D |
| 14:14.00 | CIA-1 | 03Sebastian Krzyszkowiak <seba.dos1@gmail.com> 07shr/import * ra694dcbe71 10openembedded.git/recipes/connman/mokonnect_svn.bb: mokonnect: add connman to RDEPENDS |
| 14:14.10 | CIA-1 | 03Sebastian Spaeth <Sebastian@SSpaeth.de> 07shr/import * r55874d7661 10openembedded.git/recipes/connman/mokonnect_svn.bb: mokonnect: also bump PR |
| 14:19.23 | CIA-1 | 03Sebastian Krzyszkowiak <seba.dos1@gmail.com> 07shr/import * r7b499b3218 10openembedded.git/ (2 files in 2 dirs): shr-today: new recipe |
| 14:19.24 | CIA-1 | 03Sebastian Krzyszkowiak <seba.dos1@gmail.com> 07shr/import * rc048447e6b 10openembedded.git/recipes/tasks/task-shr-feed.bb: task-shr-feed: add shr-today |
| 14:25.00 | *** join/#oe jovox (n=jovox@fw1.q-matic.se) |
| 14:28.36 | jovox | 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? |
| 14:30.13 | mario-goulart | jovox: maybe Links (http://links.twibright.com/features.php) |
| 14:30.55 | jovox | mario-goulart: I just found that actually :-) Thanks! |
| 14:32.00 | mario-goulart | jovox: you're welcome. :-) |
| 14:39.26 | *** join/#oe DuckFault (n=DuckFaul@rrcs-71-43-24-33.se.biz.rr.com) |
| 14:46.00 | munzur | Hi, I run bitbake meta-toolchain-qte and I get nothing provides 'meta-toolchain-qte', what do you think the problem is? |
| 14:47.00 | munzur | I checked the content of `recipes/meta´ folder, there's no bb file for meta-toolchain-qte. |
| 14:47.43 | woglinde | munzur think about it |
| 14:48.22 | woglinde | if there is no bb, how then bitbake can build your bb |
| 14:49.14 | munzur | I know, I though this bb file should be there by default, since there are other meta-toolchain bb files. |
| 14:50.08 | *** join/#oe fpga (n=s@92.62.56.51) |
| 14:50.38 | munzur | In openembedded user manual, under Creating and Using a QT Embedded SDK title, it suggests to run this command directly. |
| 14:51.00 | woglinde | hm then it seems the usermanual is worng |
| 14:51.10 | woglinde | or you have a not the right branch |
| 14:51.20 | woglinde | munzur are you using stable branch? |
| 14:51.49 | *** join/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de) |
| 14:52.35 | munzur | Yes |
| 14:53.30 | *** join/#oe user2 (n=3MX@125.24.185.131.adsl.dynamic.totbb.net) |
| 14:53.40 | woglinde | munzur ah okay the meta-toolchain for qt was only introduced for .dev branch |
| 14:55.05 | munzur | woglinde: So how can I switch the branch? (if easy to answer) |
| 14:55.56 | tardyp | pb_, FYI, this doesn't work :-( g++ is probably doing some more clever things than just adding -lstdc++... |
| 14:56.40 | munzur | woglinde: Ok, I found the related section in user manual. Thanks a lot. |
| 14:58.08 | tardyp | http://pastie.org/601714 |
| 14:58.35 | *** join/#oe kergoth (n=kergoth@65.200.49.156) |
| 15:00.15 | pb__ | g'day kergoth |
| 15:00.33 | *** join/#oe jconnolly (n=jconnoll@firebug.buglabs.net) |
| 15:00.34 | kergoth | hey |
| 15:01.03 | woglinde | jo kergoth |
| 15:01.11 | woglinde | tardyp you are trying gles stuff? |
| 15:01.26 | woglinde | ~lart intel iegd driver |
| 15:01.26 | ibot | hereby declares intel iegd driver a troll |
| 15:02.30 | tardyp | woglinde, absolutely |
| 15:03.07 | woglinde | tardyp hm |
| 15:03.18 | woglinde | for beagleboard? |
| 15:03.28 | tardyp | for fsl mx51 |
| 15:05.19 | hrw | tardyp: how much for cheapest mx51 board? |
| 15:05.32 | hrw | tardyp: qvga/vga screen or vga/dvi out |
| 15:06.49 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:07.23 | tardyp | hrw, http://www.akihabaranews.com/en/news_details.php?id=18763 |
| 15:07.37 | tardyp | then the devkit is qround $1500 |
| 15:08.33 | tardyp | but fsl is giving out devkits to community if you promise to do awsome stuff with it. |
| 15:08.58 | hrw | tardyp: no! never ever another sharp! |
| 15:09.35 | tardyp | the return of the zaurus :) |
| 15:10.26 | hrw | indeed |
| 15:10.26 | hrw | and zaurus was nightmare |
| 15:11.02 | florian | wel... zaurus was pxa based ;) |
| 15:11.39 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:13.23 | hrw | florian: that was very big bonus |
| 15:13.29 | hrw | pxa == open |
| 15:13.33 | hrw | i.mx === closed |
| 15:14.18 | florian | hrw: yes... i have been working with pxa quite a lot and they have quite some benefits. |
| 15:14.41 | florian | documentation is one... |
| 15:14.58 | hrw | with pxa I feel like 'get base support and then just connect existing drivers' |
| 15:15.12 | hrw | where base support == board.c file |
| 15:15.31 | florian | i have i.mx25, 27 and 37 here and the linux stuff freescale provides sucks for all of them. |
| 15:15.43 | hrw | florian: I have i.mx31 |
| 15:16.50 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:17.09 | florian | 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. |
| 15:18.50 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:19.45 | *** join/#oe Gnutoo (n=gnutoo@ABordeaux-152-1-40-189.w83-193.abo.wanadoo.fr) |
| 15:19.47 | khem | gm |
| 15:19.48 | tardyp | florian, I can confirm that the linux stuff freescale provides sucks. |
| 15:19.59 | tardyp | Then you have OE. |
| 15:20.20 | florian | hi khem |
| 15:20.48 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:21.12 | khem | tardyp: can you paste output of readelf -d /home/ptar01/poky/build/tmp/staging/armv7a-poky-linux-gnueabi/usr/lib/libgles20.so |
| 15:21.21 | hrw | tardyp: ltib is one, kernel is second |
| 15:21.22 | florian | 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 |
| 15:21.34 | florian | has OE |
| 15:22.10 | czr_ | hrw, pxa == open? since when? |
| 15:22.20 | czr_ | I've been feeling the reverse since marvell bought the stuff. |
| 15:22.36 | hrw | czr_: pxa25/26/27 |
| 15:22.37 | czr_ | I still prefer reading the intel original datasheets compared to the "marvell" ones. |
| 15:22.38 | pb__ | czr_: it was fairly open when it belonged to intel, which was the era of the zaurus. |
| 15:22.46 | czr_ | yes, with that I agree. |
| 15:22.51 | czr_ | but the marvell thing was bad imho. |
| 15:22.56 | hrw | czr_: and when you search you will even find docs still |
| 15:22.59 | tardyp | florian, they are more targetting big fishs, and give them the code directly |
| 15:23.00 | czr_ | pxa270 is our current target. |
| 15:23.03 | czr_ | hrw, yes, I know :-) |
| 15:23.06 | hrw | pxa3xx is disaster |
| 15:23.16 | czr_ | yup |
| 15:23.30 | czr_ | pxa3xx was one of the alternatives for our next hw-platform |
| 15:23.35 | khem | remember intel days |
| 15:23.37 | czr_ | but atmel sam9 looks much better now. |
| 15:23.48 | hrw | czr_: o yes. |
| 15:24.00 | hrw | czr_: atmel even provides schematics for boards |
| 15:24.04 | florian | i.MX25 :) |
| 15:24.06 | pb__ | yeah, marvell's track record is not very good in terms of either openness or cpu quality. |
| 15:24.15 | czr_ | yes, and the CPU looks much nicer and sane in many respects too |
| 15:24.32 | czr_ | pxa270 has oodles of yuckyness in it, which gets raised by power of two in pxa3xx. |
| 15:24.48 | hrw | czr_: and when you need openess power then you can go for omap3 |
| 15:24.52 | florian | tardyp: that's called "old fashioned" ;) |
| 15:24.57 | hrw | s/power/and power/ |
| 15:24.58 | czr_ | are omaps open nowadays? |
| 15:25.03 | czr_ | I always thought that they were quite closed. |
| 15:25.11 | hrw | czr_: kernel is open |
| 15:25.23 | czr_ | what about documentation and devkit schemas and stuff? |
| 15:25.38 | hrw | czr_: 3d acceleration is closed (omap3) or totally unavailable closed (omap2) |
| 15:25.42 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:25.50 | hrw | czr_: beagleboard scheme is open |
| 15:26.07 | czr_ | ah yes, I chatted with one person who was working with the linux drivers for the 3D. powervr it was. |
| 15:26.19 | hrw | powervr... please do not curse |
| 15:26.23 | tardyp | wonders if there is a market supporting fashionable distribution for old fashionned cpu vendors... |
| 15:26.27 | czr_ | he told me that it's mostly because of the weird licensing model between ti and powervr or smt. |
| 15:26.31 | czr_ | and was unlikely to open ever. |
| 15:26.46 | Crofton|work | powervr is a problem |
| 15:26.50 | hrw | czr_: look at intel gma500 - over year on market, still no driver |
| 15:26.54 | Crofton|work | that TI has little control over |
| 15:26.55 | hrw | open driver |
| 15:27.11 | Crofton|work | hopefully, they move away from them in the future ... |
| 15:27.23 | czr_ | hrw, intel has a track record of being slow anyway |
| 15:27.33 | czr_ | I remember waiting for the first gen GMA specs to come out for bloody two years |
| 15:27.43 | czr_ | and then.. oooh and aah, 2D pipeline only. gah. |
| 15:27.50 | czr_ | spits in the general direction of large multinationals |
| 15:27.58 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:28.10 | czr_ | composes himself and gets back to coding |
| 15:28.23 | *** join/#oe rob_w (n=bill@p549BCD75.dip.t-dialin.net) |
| 15:28.39 | *** join/#oe rkirti (n=oespirit@203.199.213.3) |
| 15:28.42 | czr_ | years back, I was working in radeon (the original RV100/200 series) |
| 15:28.58 | czr_ | that was when I learned that even when you have the documentation, if it's completely bogus, it won't help you much. |
| 15:31.16 | czr_ | maybe atmel can change that. I've been positively surprised with AVRs at least |
| 15:31.29 | czr_ | (in terms of documentation that is) |
| 15:31.59 | khem | pb__: whats your opinion on the revised patch about TARGET_OS thing |
| 15:35.45 | *** join/#oe eFfeM (n=nly91006@ip-145-93-232-32.fontys.nl) |
| 15:36.59 | pb__ | khem: I didn't quite understand how DISTRO_FEATURES was meant to get factored into the settings of ARM_ABI and TARGET_OS. |
| 15:37.20 | pb__ | from an initial inspection it seemed that they derive solely from MACHINE_FEATURES, which doesn't seem right. |
| 15:37.42 | pb__ | and, given that you went to the trouble of adding eabi to DISTRO_FEATURES, it doesn't seem like what you intended either. |
| 15:40.21 | khem | pb__: I will add the check to test it in both MACHINE_FEATURES and DISTRO_FEATURES |
| 15:40.36 | khem | and it will only take it if defined in both |
| 15:40.58 | khem | For machine we are sure it is supported |
| 15:41.05 | khem | and distro will have the choice to make |
| 15:41.16 | khem | however this is ok for arm eabi |
| 15:41.45 | khem | for spe there is no choice |
| 15:41.53 | khem | by nature of it |
| 15:42.03 | pb__ | I think it should probably be an error if DISTRO_FEATURES requests something that MACHINE_FEATURES doesn't support. |
| 15:42.27 | khem | Yeah better |
| 15:43.33 | khem | adding it to distro feature is needed to enable it |
| 15:44.12 | khem | so far the check only does it for MACHINE_FEATURE in the patch |
| 15:44.26 | khem | but I will also add similar check for DISTRO feature |
| 15:49.16 | kergoth | yawns |
| 15:49.40 | kergoth | 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 |
| 15:49.44 | kergoth | meh, caffeine time |
| 15:51.09 | pb__ | 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. |
| 15:51.39 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:51.39 | pb__ | so, for eabi you would require v4T or newer; for eabi without interworking v4 would suffice |
| 15:53.11 | *** part/#oe munzur (n=caner@85.101.57.225) |
| 15:55.40 | khem | pb__: you mean basic arm arch name like armv5.6.7 etc |
| 15:56.12 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:56.33 | khem | pb__: something like BASE_PACKAGE_ARCH |
| 15:57.17 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:59.30 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 15:59.55 | pb__ | something like that, yeah, though BASE_PACKAGE_ARCH does contain a few bogons like "armv6-novfp" and I think some distros clobber it. |
| 16:01.01 | *** join/#oe dth-oops (n=Dieter@p4FDEC555.dip.t-dialin.net) |
| 16:01.12 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 16:01.18 | khem | pb__: for any reason distro wants oabi on a machine that supports eabi, should this case work |
| 16:02.13 | khem | pb__: I think MACHINE_FEATURES seems appropriate too |
| 16:02.54 | pb__ | yes, there's no reason you shouldn't be able to select oabi on any arm machine. |
| 16:03.12 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 16:03.22 | *** join/#oe jconnolly (n=jconnoll@firebug.buglabs.net) |
| 16:03.46 | khem | right so I think we should let this be in MACHINE_FEATURES |
| 16:03.46 | hrw | ~curse hal |
| 16:03.47 | ibot | May the fleas of a thousand camels infest your most sensitive regions, hal ! |
| 16:04.13 | jconnolly | 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 |
| 16:04.18 | jconnolly | any suggestions? |
| 16:07.25 | *** join/#oe dth-oops (n=Dieter@p4FDEC555.dip.t-dialin.net) |
| 16:07.33 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 16:07.37 | pb__ | 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. |
| 16:08.07 | pb__ | 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. |
| 16:08.17 | hrw | oabi in MACHINE_FEATURES is nonsense I think |
| 16:08.34 | kergoth | 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 |
| 16:08.54 | pb__ | kergoth: yeah, agreed. |
| 16:09.06 | kergoth | not entirely sure *how* to make that better, but something should be done |
| 16:10.36 | pb__ | 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. |
| 16:11.11 | pb__ | 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. |
| 16:12.26 | kergoth | that would be a good start, indeed. i wonder how best to do that in a piecemeal fashion, without pissing everybody off :) |
| 16:13.57 | pb__ | 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. |
| 16:13.58 | khem | pb__: ok I will revert to using BASE_PACKAGE_ARCH but then we can not control from DISTRO_FEATURES |
| 16:14.31 | kergoth | that's a good point |
| 16:14.33 | pb__ | khem: er, why is DISTRO_FEATURES incompatible with using BASE_PACKAGE_ARCH? |
| 16:14.55 | kergoth | 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 |
| 16:15.01 | kergoth | autotools.acpaths |
| 16:15.05 | pb__ | right, that's just what I was thinking |
| 16:15.11 | pb__ | I think that'd be a good step |
| 16:15.52 | khem | 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? |
| 16:15.58 | khem | is that ok approarch |
| 16:16.13 | pb__ | khem: right, that's what I was thinking. |
| 16:16.21 | khem | hmm sounds ok to me |
| 16:16.29 | pb__ | so, just to be clear, if eabi is not in DISTRO_FEATURES then you use oabi unconditionally, doesn't matter what the machine says. |
| 16:16.38 | pb__ | if eabi is in DISTRO_FEATURES and arch >= v4t, use eabi |
| 16:16.44 | khem | right |
| 16:16.45 | *** join/#oe mnabil (n=mnabil@196.202.20.11) |
| 16:16.47 | pb__ | if eabi is in DISTRO_FEATURES and arch < v4t, that's an error |
| 16:16.55 | *** join/#oe likewise_ (n=chatzill@82-171-51-231.ip.telfort.nl) |
| 16:17.16 | khem | ok let me do something on these lines |
| 16:17.48 | pb__ | 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. |
| 16:18.32 | khem | pb__: I think I will be consistent and just use BASE_PACKAGE_ARCH |
| 16:19.29 | pb__ | ok, that sounds fine |
| 16:20.59 | woglinde | hm dont we have now support for eabi on armv4? |
| 16:21.18 | *** join/#oe jeaneus (n=orb@pool-173-71-43-116.dllstx.fios.verizon.net) |
| 16:21.31 | khem | now yes but then you need to use latest and greatest gcc |
| 16:22.04 | jeaneus | hi all: I seem to be missing X11/extensions/XShm.h has anyone ran into this issue? |
| 16:22.41 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 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. |
| 16:22.42 | *** join/#oe rsalveti (n=rsalveti@200.184.118.130) |
| 16:22.44 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 07org.openembedded.dreambox * rf059202a45 10openembedded.git/packages/enigma2/enigma2.bb: |
| 16:22.44 | CIA-1 | enigma2.bb: add missing python-email to crashlogsubmitter rdepends. |
| 16:22.44 | CIA-1 | Bump SRCDATE to match recent openembedded changes. |
| 16:22.48 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 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. |
| 16:22.49 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 07org.openembedded.dreambox * r858f2bf742 10openembedded.git/conf/machine/dm7025.conf: |
| 16:22.51 | woglinde | khem whats wrong eith this? |
| 16:22.54 | CIA-1 | dm7025.conf: move /usr/lib/*gst* out of squasfs into jffs2. |
| 16:22.56 | CIA-1 | This hopefully fixes the image upgrade problem on low flash as long python is not updated. |
| 16:22.58 | CIA-1 | Sorry but its necessary to reflash your dm7025 to benefit from this change and the following ones. |
| 16:23.00 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 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. |
| 16:23.05 | woglinde | why invent something thats obsolete in 2 weeks |
| 16:23.06 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 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. |
| 16:23.12 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 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. |
| 16:23.18 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 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. |
| 16:23.22 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 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. |
| 16:23.25 | kergoth | acid burn? seriously? |
| 16:23.27 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 07org.openembedded.dreambox * rb0df2dfdf9 10openembedded.git/packages/twisted/ (15 files): packages/twisted: remove old and unused twisted bb files |
| 16:23.30 | kergoth | shakes head |
| 16:23.31 | CIA-1 | 03acid-burn <acidburn@opendreambox.org> 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. |
| 16:24.51 | woglinde | how many armv4 users we have? |
| 16:24.59 | woglinde | I can count them on my fingers |
| 16:25.56 | *** join/#oe ArteK (n=Artur@81.15.241.96) |
| 16:25.59 | *** join/#oe darkschneider (n=gab@93-32-57-83.ip32.fastwebnet.it) |
| 16:26.46 | woglinde | khem I am one of them |
| 16:26.48 | woglinde | haha |
| 16:28.28 | *** join/#oe vivijim (n=vivijim@unaffiliated/vivijim) |
| 16:37.14 | *** join/#oe toi (n=toi@d54C2AAB7.access.telenet.be) |
| 16:39.59 | CIA-1 | 03Steffen Sledz <sledz@dresearch.de> 07org.openembedded.dev * r8aeac1fd6f 10openembedded.git/conf/checksums.ini: checksums.ini: some missing checksums added |
| 16:42.19 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 16:42.54 | *** join/#oe AvengerGear (n=cc@124.126.182.62) |
| 17:06.14 | jeaneus | 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.... |
| 17:11.21 | *** join/#oe stephank (n=traveler@2002:52c5:cf78:7:21c:c4ff:fece:ea94) |
| 17:11.54 | *** join/#oe mickey|sofa (n=M@e180177121.adsl.alicedsl.de) |
| 17:12.11 | pb__ | hi mickey|sofa |
| 17:13.05 | mickey|sofa | hey |
| 17:25.46 | *** join/#oe brolin_ (n=brolin@200.24.16.89) |
| 17:30.29 | likewise_ | hey all |
| 17:31.05 | likewise_ | khem: still fiddling with the gnuspe stuff right? I admire your perseverence! (sp?) |
| 17:31.26 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 17:32.01 | Tartarus | what spe stuff? |
| 17:32.07 | likewise_ | Often I think OE tries too hard to be smart, I rather liked the old way of just setting variables, period. |
| 17:32.22 | likewise_ | Tartarus: powerpc spe tripplet support |
| 17:32.27 | Tartarus | yes, what about it? |
| 17:32.44 | Tartarus | getting code out that's really spe? |
| 17:32.47 | Tartarus | or packaging unfun? |
| 17:33.24 | likewise_ | Setting TARGET_OS. See the mailing list and search for "gnuspe" in the topics |
| 17:33.37 | Tartarus | packaging unfun then, heh |
| 17:34.00 | Tartarus | i replied to one of khems patches last week i think wrt TARGET_OS |
| 17:34.55 | Tartarus | imho, we need to be doing more things in tune files |
| 17:35.05 | Tartarus | and say if you don't include the right tune, that's your bug |
| 17:35.09 | likewise_ | Tartarus: I totally agree |
| 17:35.32 | Tartarus | (ie ?= TARGETT_OS="linux" and in the eabi arm ones, do -gnueabi, in the ppc e500 -gnuspe it, etc) |
| 17:35.48 | likewise_ | Tartarus: By trying to be smart, we are hiding the details, making harder for people to recognize and fix them in the future. |
| 17:36.07 | likewise_ | Although the last approach Marcin proposed is good middle ground... |
| 17:36.19 | Tartarus | I should try and read oedevel again |
| 17:36.27 | Tartarus | But, being smart just gives pita to read code |
| 17:36.47 | Tartarus | inline python just makes me to "Why ,d,1 again? oh, right..." |
| 17:38.57 | *** join/#oe sgh (n=quassel@0x4dd5bf76.adsl.cybercity.dk) |
| 17:41.43 | kergoth | heh, we should really make our inline python more of a DSL |
| 17:42.33 | Tartarus | We should do less of it, too |
| 17:43.43 | *** join/#oe thaytan (n=jan@78.16.104.61) |
| 17:46.36 | *** join/#oe Martin-B (n=Martin@pool-155-67-198-89.dbd-ipconnect.net) |
| 17:47.29 | kergoth | 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'}" |
| 17:51.03 | *** join/#oe sabrod (n=sabrod@mic92-8-82-234-143-184.fbx.proxad.net) |
| 17:51.57 | likewise_ | I was thinking let's ditch python for a second, then I realized no alternative came up in the next second :-) |
| 17:52.23 | likewise_ | why ,d,1, again ? |
| 17:52.43 | *** join/#oe xjqian (n=gordon@mscitspubwlgw.wustl.edu) |
| 17:53.20 | Tartarus | inline python junk |
| 17:58.11 | kergoth | it's the crappy bb.data api |
| 18:05.37 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 18:05.57 | *** join/#oe florian (n=fuchs@g228138207.adsl.alicedsl.de) |
| 18:07.18 | *** join/#oe dijenerate (n=dijenera@64.210.44.91) |
| 18:10.26 | florian | re |
| 18:12.32 | kergoth | 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 |
| 18:13.19 | kergoth | does anyone recall why per-subpackage -dbg packages was shot down in the past? |
| 18:20.17 | *** join/#oe pH5 (n=ph5@e178221161.adsl.alicedsl.de) |
| 18:21.25 | *** join/#oe marex (n=marex@thor.hackndev.com) |
| 18:23.54 | NvrBst | @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 |
| 18:24.38 | kergoth | OpenEmbedded requires python 2.4 right now, right? |
| 18:26.00 | pH5 | kergoth: bitbake currently reqires python 2.6 |
| 18:26.49 | kergoth | did i say bitbake? |
| 18:26.53 | *** join/#oe toi (n=toi@d54C2AAB7.access.telenet.be) |
| 18:26.53 | kergoth | no, i didn't. |
| 18:30.51 | pH5 | guess that snippet of information was completely useless, then. |
| 18:30.55 | pH5 | out of context |
| 18:31.25 | kergoth | 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 |
| 18:31.33 | kergoth | shrugs |
| 18:32.02 | *** join/#oe gremlin[it] (n=gremlin@host130-66-dynamic.0-87-r.retail.telecomitalia.it) |
| 18:33.27 | *** join/#oe kgilmer (n=kgilmer@firebug.buglabs.net) |
| 18:34.02 | *** join/#oe marcosmamorim (n=marcos@bd21096b.virtua.com.br) |
| 18:34.03 | khem | NvrBst: you can apply cbrake's patch http://patchwork.openembedded.org/patch/1008/ to kernel and linux-libc-headers recipe that you are using |
| 18:34.35 | gremlin[it] | hi all |
| 18:35.04 | khem | likewise_: many times they go wronf |
| 18:35.09 | khem | wrong |
| 18:35.21 | khem | so I thought of fixing it once for all :) |
| 18:35.35 | khem | problem is divided opinions |
| 18:35.49 | khem | I believe in disagree and commit :) |
| 18:36.47 | pH5 | kergoth: I know. I just thought bitbake 1.8.x is suggested, not mandatory? |
| 18:37.19 | pH5 | I always used (or tried to use) bitbake trunk. |
| 18:37.59 | *** join/#oe vo5 (n=vo@bd21096b.virtua.com.br) |
| 18:38.11 | *** join/#oe archae0pteryx (n=snewman@207.47.42.130.static.nextweb.net) |
| 18:39.58 | m4t | hey khem |
| 18:40.20 | khem | m4t: howdy |
| 18:40.55 | m4t | i just made some really strong coffee, i am having trouble this morning |
| 18:41.03 | m4t | this afternoon i guess |
| 18:41.08 | NvrBst | khem: thank you, i'll look at it :) |
| 18:41.22 | khem | m4t: hmm |
| 18:49.13 | *** join/#oe timtimred (n=meh@79-75-235-221.dynamic.dsl.as9105.com) |
| 18:49.58 | m4t | i am going tospend some more time tonight, and hopefully figure out why udev doesnt seem to be working |
| 18:50.27 | khem | use old versions which used to work |
| 18:51.58 | m4t | there isn't any way to get debug output from an image is there? |
| 18:52.19 | m4t | besides adding echo's to the init scripts myself i guess |
| 18:53.41 | m4t | init=/bin/sh works fine, and if i do 'root=/dev/hde2 rw' the filesystem is fully accessible |
| 18:53.47 | m4t | i didnt try mounting a tmpfs though |
| 19:00.26 | *** part/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de) |
| 19:01.14 | *** join/#oe oneshel (n=jim@c-98-216-198-0.hsd1.nh.comcast.net) |
| 19:05.39 | *** part/#oe jest (n=jest@150.254.6.123) |
| 19:08.30 | *** join/#oe bluelightning (n=blueligh@pdpc/supporter/active/bluelightning) |
| 19:10.03 | cdbot2 | * * OE Bug 5316 has been created by quickx(AT)hotmail.com |
| 19:10.06 | cdbot2 | * * opie-image-16mb / gpephone-image build errors |
| 19:10.08 | cdbot2 | * * http://bugs.openembedded.org/show_bug.cgi?id=5316 |
| 19:11.15 | khem | hmmm PACKAGE_EXTRA_ARCHS what does it signify |
| 19:11.45 | khem | does it mean that this machine can run packages intended for the arches mentioned in PACKAGE_EXTRA_ARCHS |
| 19:14.44 | *** join/#oe booxter (n=booxter@212.98.182.22) |
| 19:23.22 | *** join/#oe vivijim (n=vivijim@unaffiliated/vivijim) |
| 19:23.44 | *** join/#oe eFfeM (n=Frans@j192117.upc-j.chello.nl) |
| 19:28.27 | *** join/#oe marcosmamorim (n=marcos@bd21096b.virtua.com.br) |
| 19:30.03 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 19:46.07 | *** join/#oe booxter (n=booxter@212.98.182.22) |
| 19:47.44 | *** join/#oe thaytan (n=jan@78.16.106.59) |
| 19:49.40 | *** join/#oe woglinde (i=woglinde@g225147254.adsl.alicedsl.de) |
| 19:49.45 | woglinde | re |
| 19:52.15 | *** join/#oe eFfeM (n=Frans@j192117.upc-j.chello.nl) |
| 19:53.32 | woglinde | re effem |
| 19:54.02 | *** join/#oe marcosmamorim (n=marcos@bd21096b.virtua.com.br) |
| 19:54.32 | kergoth | hey woglinde |
| 19:54.52 | woglinde | jo kergoth |
| 19:55.30 | eFfeM | have some system issues so bumping in and out :-) |
| 19:56.14 | woglinde | effem???? |
| 19:59.46 | *** join/#oe archae0pteryx1 (n=snewman@207.47.42.130.static.nextweb.net) |
| 20:04.27 | *** join/#oe lrg (n=lrg@host81-136-218-57.in-addr.btopenworld.com) |
| 20:04.40 | *** join/#oe rddDavid51 (n=roudoudo@78.234.93.192) |
| 20:04.52 | *** join/#oe jeaneus (n=orb@pool-173-71-43-116.dllstx.fios.verizon.net) |
| 20:05.20 | kergoth | http://www.linuxfordevices.com/c/a/News/MontaVista-Linux-6/ :) finally |
| 20:05.42 | woglinde | hehe |
| 20:06.07 | woglinde | kergoth will you give us a demonstration at oedem? |
| 20:06.20 | kergoth | that would imply actually being able to go to oedem :) |
| 20:06.39 | woglinde | yeah but I hope this will happen |
| 20:14.52 | *** join/#oe marcosmamorim (n=marcos@bd21096b.virtua.com.br) |
| 20:18.11 | *** join/#oe Martin_B (n=Martin@pool-151-65-198-89.dbd-ipconnect.net) |
| 20:18.38 | *** join/#oe marcosmamorim (n=marcos@bd21096b.virtua.com.br) |
| 20:27.36 | *** join/#oe booxter (n=booxter@212.98.182.22) |
| 20:32.56 | *** join/#oe ant__ (n=andrea@host31-251-dynamic.8-87-r.retail.telecomitalia.it) |
| 20:39.14 | khem | is gmail busted |
| 20:39.41 | cbrake | khem: appears to be for moe |
| 20:39.49 | jconnolly | same |
| 20:40.02 | ant__ | he.. |
| 20:40.06 | ant__ | 502 |
| 20:40.18 | ant__ | S.O.S. |
| 20:40.19 | ant__ | lol |
| 20:40.49 | Crofton|work | the power must be out at the secret government server farm .... |
| 20:41.13 | jconnolly | http://gawker.com/5350474/gmail-fail-google-is-working-on-fixing-it |
| 20:41.41 | kgilmer | where's my SLA? |
| 20:41.56 | woglinde | hi kgilmer |
| 20:42.13 | booxter | gmail web interface busted. imap/pop/smtp works |
| 20:42.24 | kgilmer | hi woglinde, long time :) |
| 20:43.36 | Crofton|work | kgilmer, hi! |
| 20:43.54 | kgilmer | hey Crofton |
| 20:43.59 | CIA-1 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rc874adcc0a 10openembedded.git/recipes/mozilla/ (fennec_hg.bb firefox.inc): |
| 20:43.59 | CIA-1 | fennec: update to latest tip |
| 20:43.59 | CIA-1 | * fix up buildsystem contamination bug in firefox.inc while I'm at it as well |
| 20:44.01 | kgilmer | Crofton|work rather |
| 20:46.37 | kgilmer | I haven't been here in awhile. how are things in OE land? |
| 20:48.01 | kgilmer | what is oedem? |
| 20:48.21 | woglinde | kgilmer our dev meeting |
| 20:48.27 | woglinde | like plumber or guadec |
| 20:48.49 | kgilmer | ah ic. it's private? not listed on the oe site. |
| 20:48.55 | kgilmer | at least not on the front page |
| 20:51.22 | Crofton|work | the web page is always behind the list |
| 20:51.31 | Crofton|work | Cambridge in early Nov |
| 20:51.38 | Crofton|work | email pb_ if you are interested |
| 20:52.15 | kgilmer | ok cool Crofton|work, thanks. |
| 20:52.52 | woglinde | kgilmer you are free to come over and discuss with us |
| 20:53.19 | woglinde | maybee you could make a presentation about the eclipse stuff |
| 20:53.23 | kgilmer | I would like to do that woglinde. I need to find the right words for my boss. :) |
| 20:53.26 | Crofton|work | kgilmer, that is the quick answer :) |
| 20:53.50 | woglinde | kgilmer are since last year money isnt easy at the moment |
| 20:54.00 | woglinde | args s/are/ah |
| 20:54.18 | kgilmer | yeah this year i have to work harder to justify travel |
| 20:54.25 | kgilmer | probably the same for everyone |
| 20:55.05 | kgilmer | also I had a baby a few months back so I've not been able to do much travel. |
| 20:55.16 | woglinde | ah |
| 20:55.17 | woglinde | hehe |
| 20:55.25 | kgilmer | well, not me personally. my wife rather . :) |
| 21:00.23 | khem | kgilmer: sure if it was you we would have heard thru TV news channels :) |
| 21:01.08 | kgilmer | that would be bad khem :) this kind of celebrity nobody needs. |
| 21:01.56 | woglinde | *g* |
| 21:02.19 | khem | I hope you are having nice time with the baby |
| 21:02.31 | kergoth | arg, stupid debian package renaming stuff |
| 21:02.53 | woglinde | kergoth why stupid? |
| 21:03.18 | khem | his library versioning stuff might not be working because of it |
| 21:03.23 | kergoth | not stupid exactly, just ugly the way we had to do it, and causing problems with what I'm working on |
| 21:03.26 | kgilmer | <PROTECTED> |
| 21:03.38 | kergoth | nah, working on per-subpackage -dbg packages at the moment |
| 21:05.35 | *** join/#oe Wiedi (n=wiedi@2a01:138:a015:6:217:f2ff:fe51:7099) |
| 21:08.14 | khem | kergoth: is machine.conf read before distro.conf ? |
| 21:08.28 | kergoth | dunno off the top of my head, would have to check bitbake.conf |
| 21:09.58 | khem | yes machine is read before distro |
| 21:10.08 | khem | conf/bitbake.conf tells me |
| 21:10.13 | kergoth | :) |
| 21:10.51 | *** join/#oe mithro (n=tim@unaffiliated/mithro) |
| 21:11.05 | khem | hmmm then why it does not evaluate BASE_PACKAGE_ARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}" |
| 21:11.26 | khem | looking at conf/machine/include/tune-xscale.inc |
| 21:11.56 | khem | if I am adding something in distro.conf it should have already defined BASE_PACKAGE_ARCH IIUC |
| 21:12.46 | kergoth | bitbake -l Parsing -l Parsing -l Parsing, look at the CONF and BB lines to see what exactly its parsing in what order |
| 21:13.25 | *** join/#oe aloisiojr (n=aloisio@200.184.118.130) |
| 21:20.03 | woglinde | hm ltg is on strike again? |
| 21:26.40 | *** join/#oe DuckFault1 (n=DuckFaul@rrcs-71-43-24-33.se.biz.rr.com) |
| 21:37.46 | CIA-1 | 03Michael Smith <msmith@cbnco.com> 07org.openembedded.dev * ra5c9970599 10openembedded.git/classes/ (package.bbclass package_deb.bbclass): (log message trimmed) |
| 21:37.46 | CIA-1 | package_deb: create md5sums control files |
| 21:37.46 | CIA-1 | These are created with the package and get installed in |
| 21:37.46 | CIA-1 | /var/dpkg/info. Afterward it's a great way to find modified files |
| 21:37.46 | CIA-1 | for backup with a little shell script magic. |
| 21:37.50 | CIA-1 | It feels a bit weird to still use MD5, but that seems to be the |
| 21:37.52 | CIA-1 | convention in the Debian world. |
| 21:40.40 | broonie | 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. |
| 21:41.08 | *** join/#oe guillaum1 (n=gl@AMontsouris-153-1-24-76.w86-212.abo.wanadoo.fr) |
| 21:43.50 | woglinde | jo guillaum |
| 21:51.41 | msmith_ | broonie: yeah i wish there were a file that stored file sizes & times, too. |
| 21:51.49 | msmith_ | but at least having the md5sum is better than nothing. |
| 21:51.53 | msmith_ | tripwire it ain't but it works in a pinch |
| 21:58.48 | kergoth | arg |
| 21:59.34 | khem | kergoth: the problem is recursion |
| 22:00.14 | khem | d.getVar(var,exp) |
| 22:00.23 | kergoth | ah ha! got it. my debug image now has the files from a subpackage's -dbg package |
| 22:00.49 | kergoth | forgot to run a runtime_mapping_rename on the PACKAGE_INSTALL I'm using for the -dbg image |
| 22:01.45 | kergoth | khem: not sure what you're referring to |
| 22:02.07 | CIA-1 | 03Michael Smith <msmith@cbnco.com> 07org.openembedded.dev * raf431dbe67 10openembedded.git/recipes/openssl/ (10 files): |
| 22:02.07 | CIA-1 | openssl.inc: fix packaging on x86_64; use INC_PR |
| 22:02.07 | CIA-1 | openssl's makefile always installs to ${prefix}/lib, even if |
| 22:02.07 | CIA-1 | libdir is ${prefix}/lib64. Move some files around to make it fit. |
| 22:02.07 | CIA-1 | Signed-off-by: Michael Smith <msmith@cbnco.com> |
| 22:02.32 | khem | kergoth: my problem about machine and distro conf |
| 22:02.45 | kergoth | ahh |
| 22:03.34 | khem | machine conf has BASE_PACKAGE_ARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}" |
| 22:04.12 | khem | which I am trying to use BASE_PACKAGE_ARCH in another python function in distro conf |
| 22:04.46 | kergoth | why's that a problem? |
| 22:06.01 | khem | no idea |
| 22:06.10 | khem | it goes into recursion |
| 22:06.18 | khem | and then dies of infiniteness |
| 22:06.42 | khem | if I set BASE_PACKAGE_ARCH = "armv5teb" in above machine file all is ok |
| 22:08.27 | woglinde | hms why nobody did update libx11 |
| 22:08.43 | woglinde | args |
| 22:08.49 | woglinde | now I see the problem |
| 22:08.53 | woglinde | libx11-native |
| 22:15.23 | khem | kergoth: http://pastey.net/124497 if you can see something wrong |
| 22:15.47 | woglinde | hm what is TARGET_PREFIX after inherit native |
| 22:16.14 | kergoth | khem: yech, we really need to audit the bitbake exception handling |
| 22:16.19 | kergoth | the user should never see a full traceback unless they ask for it |
| 22:16.22 | khem | http://pastey.net/124498 |
| 22:16.26 | khem | is my code |
| 22:16.52 | woglinde | hm intressting it is not set |
| 22:17.11 | kergoth | hmm |
| 22:17.16 | khem | it fails around line 21 |
| 22:17.37 | woglinde | hm hm why this dont works |
| 22:17.42 | woglinde | from native |
| 22:17.43 | woglinde | TARGET_PREFIX = "${BUILD_PREFIX}" |
| 22:18.38 | kergoth | khem: don't see anything obvious.. is BASE_PACKAGE_ARCH referring to TARGET_OS somewhere? hmm |
| 22:18.45 | kergoth | woglinde: don't see anything wrong with that.. |
| 22:19.22 | woglinde | its empty |
| 22:19.23 | khem | kergoth: I dont think so |
| 22:19.31 | woglinde | in case of libx11-native |
| 22:19.49 | kergoth | weird. |
| 22:19.51 | kergoth | in both cases. |
| 22:19.54 | kergoth | :) |
| 22:20.36 | khem | kergoth: this is tune-xscale.conf file |
| 22:20.48 | khem | http://pastey.net/124499 |
| 22:21.12 | khem | it tries to set BASE_PACKAGE_ARCH smartly using python voodoo |
| 22:25.08 | woglinde | hms |
| 22:26.20 | woglinde | hm build prefix is set empty in bitbake.conf |
| 22:26.33 | woglinde | UILD_PREFIX = "" |
| 22:27.20 | woglinde | hm seems I have to fake it |
| 22:30.52 | *** join/#oe Gin-geR (i=hacker@pD9539628.dip0.t-ipconnect.de) |
| 22:31.16 | *** join/#oe waite (n=bwaite@c-24-91-81-44.hsd1.ma.comcast.net) |
| 22:34.19 | kergoth | rethinks the possibilities for improving build determinism |
| 22:34.26 | *** join/#oe Sleep_Walker (n=Sleep@193.179.96.131) |
| 22:37.52 | khem | weird when I assign it to local it works |
| 22:38.25 | khem | will live with it |
| 22:41.33 | *** join/#oe jotheberlock (n=jotheber@c-68-40-120-138.hsd1.mi.comcast.net) |
| 22:41.48 | jotheberlock | has anyone here built konqueror-embedded lately? |
| 22:42.50 | woglinde | jotheberlock nope |
| 22:43.15 | jotheberlock | 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 |
| 22:43.28 | jotheberlock | should I just switch to X11 or something? |
| 22:49.34 | *** join/#oe DuckFault (n=DuckFaul@rrcs-71-43-24-33.se.biz.rr.com) |
| 22:59.09 | bluelightning | jotheberlock: how are you building it? on your local machine? |
| 22:59.14 | jotheberlock | yes |
| 22:59.18 | bluelightning | without OE? |
| 22:59.25 | jotheberlock | bitbake konqueror-embedded with openembedded |
| 22:59.33 | bluelightning | ah ok |
| 22:59.55 | jotheberlock | 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 <iostream> |
| 23:00.01 | bluelightning | haven't tried it in a while but I have been meaning to get around to fixing up the build for the latest version |
| 23:00.32 | bluelightning | hmm, doesn't sound good... not sure what could cause that |
| 23:00.34 | jotheberlock | 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 |
| 23:01.08 | jotheberlock | 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 |
| 23:01.42 | woglinde | jotheberlock do you need something small= |
| 23:01.44 | woglinde | ? |
| 23:01.52 | woglinde | I guess you are better off with fennec |
| 23:02.02 | jotheberlock | not super-small. I'm using an iPaq - 64 megs ram, loads of SD/CF |
| 23:02.17 | bluelightning | jotheberlock: it will automatically pull it of course, since the recipe says it should... the paths are probably screwed up is all |
| 23:02.21 | woglinde | dont know the midori status |
| 23:02.28 | jotheberlock | I basically went with Opie for nostalgia reasons (fun fact, the second embedded platform ever to run Qt/Embedded was an iPaq) |
| 23:02.28 | woglinde | browser bases on webkit |
| 23:02.48 | woglinde | hehe opie rockz |
| 23:02.58 | woglinde | I am using it at my simdpad |
| 23:03.02 | woglinde | args simpad |
| 23:03.09 | bluelightning | jotheberlock: FYI I'm the guy who mostly maintains Opie these days :) |
| 23:03.17 | *** join/#oe mrmoku|a` (n=mrmoku@ppp-93-104-58-38.dynamic.mnet-online.de) |
| 23:03.38 | jotheberlock | sweet, glad someone is :) |
| 23:04.01 | bluelightning | I hope to have a new release out by the end of the year |
| 23:04.13 | woglinde | bluelightning hehe |
| 23:05.06 | bluelightning | still now I have a netbook I manage to make a few code changes on the train each day, so I'm making progress :) |
| 23:05.18 | woglinde | cool |
| 23:05.34 | woglinde | how long do oyu have to travel with the train everyday? |
| 23:06.12 | bluelightning | only 45 mins, not that long really |
| 23:10.27 | *** join/#oe mithro (n=tim@unaffiliated/mithro) |
| 23:11.21 | woglinde | hm khem/hergoth wouldnt it be easy to put something in native.class which automagicly rewrites the DEPENDS lines to the nativ ones |
| 23:12.01 | khem | hmmm I would not want that |
| 23:12.12 | kergoth | woglinde: richard's BBEXTENDCLASS stuff for native/cross/sdk does that |
| 23:12.23 | kergoth | with BBEXTENDCLASS, you can remove the -native/-cross/-sdk recipes entirely |
| 23:12.26 | woglinde | kergoth hm |
| 23:12.45 | woglinde | have we this in oe now? |
| 23:12.46 | kergoth | I'd like to see a slightly more flexible way of producing variants like that, but its an improvement |
| 23:12.52 | woglinde | or only poky |
| 23:13.05 | kergoth | 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 |
| 23:13.25 | kergoth | bitbake change is used to produce the multiple recipes from the original + each class in BBEXTENDCLASS |
| 23:14.15 | kergoth | http://git.pokylinux.org/cgit.cgi/poky/log/?h=experimental-virtualnative |
| 23:14.21 | kergoth | was the original stuff for it |
| 23:14.43 | kergoth | http://git.pokylinux.org/cgit.cgi/poky/commit/?h=experimental-virtualnative&id=7f3769423fa81163be97c744e3ee274a8cf45aa1 adds the magic DEPENDS bits to the classes |
| 23:14.44 | woglinde | I would like this feature |
| 23:15.31 | kergoth | 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 |
| 23:15.47 | kergoth | right now its one variant per bbclasx |
| 23:15.48 | kergoth | s |
| 23:17.48 | *** join/#oe grg (n=grg@eth7090.sa.adsl.internode.on.net) |
| 23:31.48 | woglinde | hm |
| 23:31.57 | woglinde | some one awake? |
| 23:32.33 | woglinde | what about merge commits should they be avoided? |
| 23:33.00 | khem | usually they should be IMP |
| 23:33.04 | khem | IMO |
| 23:33.29 | woglinde | ah rebase doing it for me |
| 23:34.33 | CIA-1 | 03Henning Heinold <heinold@inf.fu-berlin.de> 07org.openembedded.dev * r4b8b9ba87d 10openembedded.git/recipes/efl1/evas-native_svn.bb: |
| 23:34.33 | CIA-1 | evas-native: add libxext-native as dependency |
| 23:34.33 | CIA-1 | * seems evas-native used libxext from host |
| 23:34.33 | CIA-1 | * bump PR |
| 23:34.34 | CIA-1 | 03Henning Heinold <heinold@inf.fu-berlin.de> 07org.openembedded.dev * rf784dd2d78 10openembedded.git/recipes/xorg-lib/libx11-native_1.2.bb: libx11-native: provide native recipe for versiob 1.2 |
| 23:34.38 | CIA-1 | 03Henning Heinold <heinold@inf.fu-berlin.de> 07org.openembedded.dev * r8cc857fcbc 10openembedded.git/recipes/xorg-lib/libxext-native_1.0.5.bb: |
| 23:34.41 | CIA-1 | libxext-native: provide native recipe for libxext |
| 23:34.43 | CIA-1 | * recipe is needed for evas-native |
| 23:41.40 | *** join/#oe tharvey_ (n=tharvey@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net) |
| 23:49.38 | *** join/#oe mnabil (n=mnabil@41.234.70.36) |