IRC log for #oe on 20080808

00:04.42*** join/#oe dijenerate (n=dijenera@69.73.223.106)
00:10.22*** join/#oe alex_l (n=alex_l@nat/cisco/x-a6148e7e03317eef)
00:10.40*** join/#oe dijenerate (n=dijenera@69.73.223.106)
00:33.55*** join/#oe wrobbie (n=rob@203.117.215.163)
00:45.09*** join/#oe dijenerate (n=dijenera@69.73.223.106)
00:50.53joschhah!
00:51.09joschMarcel_M and i got further concerning the _bsddb module in python
00:51.28joschhave a look at this excerp from the compile log:
00:51.30joschhttp://phpfi.com/341175
00:52.23joschthis happend on building python
00:52.30joschand obviosly shouldnt happen
00:52.37joschdoes anyone have a quick fix?
00:52.45joschor is this worth a bugreport?
00:53.27*** join/#oe aloril (n=aloril@dsl-tkubrasgw1-fe25fa00-28.dhcp.inet.fi)
00:54.48joschah i forgot...
00:54.55joschoe.org is still down...
00:54.56josch:/
00:55.04joschso any ideas? :D
01:06.29*** join/#oe osas (n=nnnnnnnn@nslu2-linux/osas)
01:33.53*** join/#oe BenLauDC (n=benlau@221.125.8.105)
01:36.37*** join/#oe dijenerate (n=dijenera@69.73.223.106)
01:42.24*** join/#oe HellDragon (n=jd@Wikipedia/HellDragon)
01:42.52*** join/#oe eno__ (n=eno@adsl-70-137-146-183.dsl.snfc21.sbcglobal.net)
02:07.40*** join/#oe rsalveti (n=salveti@189.70.143.203)
02:15.09*** join/#oe crweb (n=tom@12-210-83-225.client.mchsi.com)
02:20.38*** join/#oe davygravy (n=davygrav@h69-128-156-59.mdtnwi.dsl.dynamic.tds.net)
02:21.57*** join/#oe crweb (n=tom@12-210-83-225.client.mchsi.com)
02:32.12digital-exHello everyone
02:32.34*** join/#oe chouimat|away (n=dieu@kde/developer/chouinard)
02:32.57digital-exDoes anyone have experience with OE on the Sequoia?
02:33.48*** join/#oe jtaji (n=jtaji@unaffiliated/astro76)
02:35.37*** join/#oe xjqian (n=gordon@68-188-71-196.dhcp.stls.mo.charter.com)
03:05.34*** join/#oe bin1010 (n=aars@rrcs-24-227-199-231.sw.biz.rr.com)
03:20.25*** join/#oe dcordes_ (n=dcordes@unaffiliated/dcordes)
03:34.23*** join/#oe eno (n=eno@nslu2-linux/eno)
03:39.53*** join/#oe allyourrejects (n=tom@12-210-83-225.client.mchsi.com)
04:20.27*** join/#oe johncylee (n=john@firewall.tw.openmoko.org)
05:13.16*** join/#oe wick7xx (n=wicknix@74.213.217.246)
05:14.12*** join/#oe bazbell (n=a0192809@nat/ti/x-c0e00dd620e766fd)
05:37.25*** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh)
05:39.17*** join/#oe bin10101 (n=aars@rrcs-24-227-199-231.sw.biz.rr.com)
06:00.19*** join/#oe alex_l (n=alex_l@nat/cisco/x-5937c96c0600ec94)
06:01.35*** join/#oe hvontres|home (n=hvontres@adsl-75-18-119-132.dsl.sndg02.sbcglobal.net)
06:07.05*** join/#oe wozza (n=Wozza@nat-dz2-1.aster.pl)
06:19.20*** join/#oe xjqian (n=gordon@68-184-200-222.dhcp.stls.mo.charter.com)
06:28.09*** join/#oe mbuf (n=shakthim@61.16.248.242)
06:39.23*** join/#oe methril (n=Methril@213.27.233.98)
06:39.40methrilmorning
06:47.20*** join/#oe wozza_ (n=Wozza@nat-dz2-1.aster.pl)
06:49.10*** join/#oe trickie|work (n=trickie@basesoft.xs4all.nl)
06:56.17*** join/#oe kwek (n=kwek@188.Red-213-97-48.staticIP.rima-tde.net)
07:04.38*** join/#oe lafille (n=lafille@212-198-248-33.rev.numericable.fr)
07:07.02*** join/#oe pvanhoof (n=pvanhoof@d54C0C0BA.access.telenet.be)
07:07.20*** join/#oe cyberdeck (n=molter@iss60.vlsi.informatik.tu-darmstadt.de)
07:13.18*** join/#oe zoolooc (n=lucian@nrbg-4dbfc65c.pool.einsundeins.de)
07:23.14*** join/#oe smancke (n=smancke@gate.tarent.de)
07:24.43josch|nsnwell since openembedded.org is still down i hop you dont mind if i ask here: who is maintaining python in oe?
07:24.57josch|nsnmickeyl perhaps?
07:39.21*** join/#oe darkschneider (n=gab@213-140-15-160.fastres.net)
07:39.32*** join/#oe rschuster (n=rob@e178068082.adsl.alicedsl.de)
07:40.59*** join/#oe BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net)
07:41.17stefan_schmidtjosch|nsn: yes
07:41.50hrwmorning
07:42.06josch|nsnstefan_schmidt: thx - then i will message him if he gets back :)
07:42.21josch|nsns/if/when/ :P
07:42.29stefan_schmidtheh
07:42.33stefan_schmidtmorning hrw
07:47.00*** join/#oe lrg (n=liam@79-68-78-64.dynamic.dsl.as9105.com)
07:54.37*** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh)
07:58.57*** join/#oe jekhor_ (n=jek@mm-166-254-57-86.leased.line.mgts.by)
08:05.44*** join/#oe Genesis (n=Ronan@AMontsouris-153-1-20-171.w86-212.abo.wanadoo.fr)
08:07.17Genesisbonjour
08:15.46*** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh)
08:19.27*** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh)
08:23.05*** join/#oe Marajin (n=marajin@87-194-102-189.bethere.co.uk)
08:23.25MarajinSo er... trying to bitbake kdepimpi actually produces the error: "requires the runtime entity 'kdepimpi' but it wasn't found in any PACKAGE or RPROVIDES variable"
08:23.28Marajinclues?
08:27.19*** join/#oe Sleep_Walker (n=Sleep@gprs8.vodafone.cz)
08:29.58hrwkdepimpi? no idea
08:30.19*** join/#oe MarcOChapeau (n=mbarre@bgn92-4-82-238-213-101.fbx.proxad.net)
08:33.26MarajinI find it boggleable that a package depends on itself and can't find itself somehow
08:41.43MarajinOh
08:41.56Marajinoh do I make it compile libqpe-opie with qte-mt ?
08:42.07Marajinit keeps trying to -lqte instead of -lqte-mt
08:42.23MarajinI have PALMTOP_USE_MULTITHREADED_QT="yes"
08:54.19*** join/#oe pleemans (n=peter@host130-161-static.37-88-b.business.telecomitalia.it)
09:01.18*** join/#oe ribbits (n=bob@host86-154-243-88.range86-154.btcentralplus.com)
09:09.42*** join/#oe buri (n=swisscom@26-95.104-92.cust.bluewin.ch)
09:10.22*** join/#oe lrg (n=liam@79-68-78-64.dynamic.dsl.as9105.com)
09:16.15burihello, I try to build an openmoko toolchain for a i686 system using bitbake on a x86_64 machine - tried to edit openembedded/conf/bitbake.conf setting HOST_ARCH = "i686"  but I guess I got a bit confused with TARGET and HOST....
09:19.11buriwell, I see openembedded/classes/sdk.bbclass:HOST_ARCH = "${BUILD_ARCH}" - therefore I think HOST_ARCH would be the right variable to change... what would be the right value?
09:19.54burianybody here who did that before?
09:20.17*** part/#oe Marajin (n=marajin@87-194-102-189.bethere.co.uk)
09:26.02*** part/#oe xjqian (n=gordon@68-184-200-222.dhcp.stls.mo.charter.com)
09:26.45pb__buri: what exactly are you trying to accomplish?
09:26.49*** join/#oe hillct (n=hillct@cpe-024-211-242-232.nc.res.rr.com)
09:27.10pb__do I understand correctly that you are trying to build i686 binaries on your x86-64 host?  if so, TARGET_ARCH is the variable you want to set.
09:28.06pb__if you mean that you are trying to do a canadian cross sdk, I don't think this is something that oe supports very well (or maybe at all).  It might be possible to make it work but I suspect you are on your own. :-}
09:28.33*** join/#oe Sleep-Walker (n=Sleep@gprs6.vodafone.cz)
09:35.53*** join/#oe florian_ (n=fuchs@217.146.132.69)
09:37.49pb__florian_: good morning
09:39.41florian_good morning
09:43.33*** join/#oe thebohemian (n=rschus@p579E1B4F.dip.t-dialin.net)
09:44.57*** join/#oe ao2 (n=u@2001:1418:117:0:0:0:0:1)
09:45.16*** part/#oe ao2 (n=u@2001:1418:117:0:0:0:0:1)
09:51.36*** join/#oe DarthWader (n=sith@gw.vniro.ru)
10:05.21buripb__: I try to build an openmoko toolchain (gcc etc.) on a x86-64 system that should run on a i686 system and produce binaries for the openmoko (arm)
10:05.28*** join/#oe Sleep-Walker (n=Sleep@gprs9.vodafone.cz)
10:10.00buripb__: I think TARGET_ARCH should still be ARM, as the sdk.bbclass takes for HOST_x all the settings from BUILD_x
10:10.20thebohemianburi: I think you will get into trouble with this
10:10.41pb__buri: right, that's a canadian cross.  I don't think it will work with sdk.bbclass out of the box.
10:10.54thebohemianburi: while you can override BUILD_x variables you certainly won't fool the autotools
10:12.30thebohemianburi: because the way the things are now they will call your system's uname and whatnot to find out on what it is running on
10:13.04thebohemianburi: as pb__ said canadian cross (compilation) is not handled right now.
10:13.15thebohemianburi: contributions in this way are very much welcome! :)
10:15.26burithebohemian: canadian cross? never heard of that - I tried to overwrite the HOST_ARCH variable and I get an error: NOTE: Handling BitBake files: \ (0755/5722) [13 %]ERROR: Information not available for target 'i386-linux-gnueabi'
10:17.05*** join/#oe xjqian (n=gordon@68-184-200-222.dhcp.stls.mo.charter.com)
10:17.09thebohemianburi: http://en.wikipedia.org/wiki/Cross_compile#Canadian_Cross
10:18.05thebohemianburi: compilation is for beginners, cross-compilation is for adepts, canadian cross-compilation is for the elite ;)
10:19.21thebohemianburi: AFAIK the autotools are the only build system that can deal with it by design
10:19.32burithebohemian: I guess your right... and I think I'm not the elite type of embedded developer
10:20.21burithebohemian: ... and it probably takes a genius to even but all that into bitbake....
10:20.47thebohemianburi: it boils down to pass the right options to the configure scripts
10:21.01thebohemianburi: the autotools manuals describe this scenario
10:25.17burithebohemian: I'll have a look at it. But to get bitbake to pass the right things on to autotools beats me. I'm not that familiar with the bb-files and classes... In general I feel rather lost with all the variables around...
10:28.44burithebohemian: but thanks for the input. At least I know now what's it called what I'm trying to do. I will first get everything built and tested on the i686 directly before I attempt to leverage our cluster powered by x86_86 cores.
10:30.47*** join/#oe mwester_ (n=mwester@adsl-75-49-209-164.dsl.emhril.sbcglobal.net)
10:31.50*** join/#oe thebohemia1 (n=rschus@p579E18CD.dip.t-dialin.net)
10:37.08thebohemia1florian: I got answer from the district court regarding OE e.V. I have to send money and we need to fix a few minor issues in our statutes
10:37.34thebohemia1florian: I will write a mail about this after work (or tomorrow)
10:38.30florianthebohemia1: ah cool
10:38.47florianthebohemia1: okay, so lets do this :)
10:58.37Crofton|workthebohemia1, thanks
11:05.11*** join/#oe jekhor_ (n=jek@cpmsq.epam.com)
11:05.43Crofton|workwhat is up with amethyst?
11:06.32udovdhanyone awake here?
11:06.52udovdhI have one small question about serial_cs on h2200
11:06.59florianCrofton|work: mickeyl said somethign about network problems at the hosting location.
11:07.17udovdhI built a kernel with serial_cs and dependent modules (Koen gave me a patch to defconfig)
11:07.21udovdhbut I get:
11:07.32udovdh<4>[  253.950000] serial_cs: Unknown symbol serial8250_unregister_port
11:07.33udovdh<4>[  253.950000] serial_cs: Unknown symbol serial8250_resume_port
11:07.33udovdhetc
11:07.40udovdhmodprobe 8250 says device busy
11:08.26florianHe promised to call there today...
11:09.06florianThat's why I prefer renting servers :)
11:09.45ynezzand it's even cheaper :)
11:11.47Crofton|workwe should send in the oe mafia
11:23.42*** join/#oe tcooksey (n=tcooksey@nat/trolltech/x-22b9f904b5f43505)
11:50.06Genesisdoes any project other that openembedded & consors use bitbake ?
11:56.25thebohemia1Genesis: I don't think so
11:57.00thebohemia1Genesis: however its used by openmoko, mamona and poky ;)
11:58.25Genesisso all the tasks are for building distro/packages/...
11:59.17*** join/#oe Sleep_Walker (n=Sleep@gprs9.vodafone.cz)
11:59.19Genesisbitbake is supposed to be a generic task manager , we don't associate bbclass in it because it's distro specific , i'm okay but i was wondering if it's really a good idea
11:59.52Genesiswe could have bbclass by catégory in the bitbake tree
12:00.30*** join/#oe Laibsch (n=Laibsch@ip-62-143-12-162.hsi.ish.de)
12:01.04*** join/#oe mickeyl (n=mickey@openmoko/coreteam/mickey)
12:01.22Genesisi try to make a qemu-launch task but it's a bit different than other tasks i'm wrote
12:02.45*** topic/#oe by mickeyl -> OpenEmbedded Developer Lounge | Web: http://www.openembedded.org | Bugtracker: http://bugs.openembedded.net | Repository: monotone.openembedded.org | This is not a distro or machine support channel | OE.org is down, we work on it. Pull/Push from/to opensource.wolfsonmicro.com in the meantime.
12:07.38josch|nsnmickeyl: you think the bothering about oe.org being down will stop now? :P
12:08.00mickeyli do :D
12:13.35mwesterjosch|nsn:  :D  At least the answers will be shorter!
12:14.18josch|nsnheh
12:16.25*** join/#oe xjqian (n=gordon@mir-nil-pat-118-150.wustl.edu)
12:19.57pb__mickeyl: yo
12:21.35mickeylhi pb__
12:21.51*** join/#oe aloisiojr (n=aloisio@200.184.118.132)
12:23.26Crofton|workmickeyl, do we need to send the OE mafia in to solve the connectivity issue?
12:23.44Crofton|workcurses the openmoko store not having anything to sell
12:25.08hrwCrofton|work: you need jtag hardware?
12:26.20*** join/#oe dijenerate (n=dijenera@69.73.223.106)
12:28.20mickeylCrofton|work: heh, well, the one with access tries to reach the computing centre guys, but it's friday...
12:29.44Crofton|workhrw, no I want a freerunner
12:29.50Crofton|workhmmm
12:30.05Crofton|workneeds to move to a country where you do not work on Friday :)
12:31.48chouimat|awaymorning ....
12:32.18chouimat|awayhides his freerunner from Crofton|work sight ;)
12:32.52*** join/#oe thesing (n=tkunze@BAA14f7.baa.pppool.de)
12:33.15thesingmorning all
12:34.05florianhi thesing
12:44.56hrwCrofton|work: freerunner...
13:19.50*** join/#oe mranostay_work (n=mranosta@cpe-089228.fiber.wadsnet.net)
13:19.54mranostay_workhello
13:20.17mranostay_worki see OE.org is down, any idea for how long?
13:20.45mickeylunfortunately not, it's an unscheduled outage
13:21.01*** join/#oe frikker (n=blaine@107.135.68.216.DED-DSL.fuse.net)
13:21.13mickeylmy guess would be not later than monday
13:23.36mranostay_workis the monotone server still up?
13:24.08mranostay_workor is there a mirror?
13:24.33mwestersee topic
13:26.26mranostay_workah ok
13:36.28*** join/#oe rkirti (n=Kirtika@203.199.213.3)
13:38.00*** join/#oe dijenerate (n=dijenera@69.73.223.106)
13:40.57*** join/#oe chouimat|work (n=dieu@kde/developer/chouinard)
13:45.18mranostay_workwow the server must be getting hammered
13:55.20frikkerso i have compiled octave 3.0.0.  After installing the 10 libraries, and finally the octave ipkg, I get this when I run it: octave: error while loading shared libraries: liboctinterp.so: cannot open shared object file: No such file or directory
13:55.38frikkerI have done this, which did not help: root@gumstix-custom-verdex:~$ find /* | grep liboctinterp.so
13:55.38frikker/usr/lib/octave-3.0.0/liboctinterp.so.3.0.0
13:55.38frikkerroot@gumstix-custom-verdex:~$ export LD_LIBRARY_PATH=/usr/lib/octave-3.0/
13:55.45frikkerany suggestions?
13:56.05frikkeractually that was /usr/lib/octave-3.0.0 (I fixed it)..
14:00.10pb__try making a symlink from liboctinterp.so.3.0.0 -> liboctinterp.so
14:00.35pb__if that fixes it, you need to look into the octave build to see why the binary is getting mis-linked like that
14:04.41*** join/#oe trickie|work (n=trickie@basesoft.xs4all.nl)
14:06.14*** join/#oe crweb (n=tom@12-210-83-225.client.mchsi.com)
14:08.15*** join/#oe Gnutoo (n=gnutoo@ABordeaux-152-1-15-106.w82-125.abo.wanadoo.fr)
14:13.26*** join/#oe rkirti (n=kirtibr@203.199.213.3)
14:24.25*** join/#oe Sleep_Walker (n=Sleep@gprs1.vodafone.cz)
14:27.04*** join/#oe tharvey (n=tharvey@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net)
14:27.52frikkerpb__: thanks, i'll try that
14:29.17frikkerpb__: where do you think i should put that soft link?
14:29.27frikkerroot@gumstix-custom-verdex:/usr/lib/octave-3.0.0$ ls
14:29.27frikkerlibcruft.so.3.0.0      liboctave.so.3.0.0     liboctinterp.so.3.0.0
14:31.48frikkerlol look what i did on accident.... a symbolic link to itself
14:31.50frikkerroot@gumstix-custom-verdex:/usr/lib/octave-3.0.0$ ls -la
14:31.50frikkerdrwxr-xr-x    2 root     root            0 Aug  3 02:34 .
14:31.50frikkerdrwxr-xr-x   11 root     root            0 Jul 29 15:51 ..
14:31.50frikker-rwxr-xr-x    1 root     root      1690052 Jul 29 15:51 libcruft.so.3.0.0
14:31.50frikker-rwxr-xr-x    1 root     root      4971956 Jul 29 15:51 liboctave.so.3.0.0
14:31.51frikkerlrwxrwxrwx    1 root     root           14 Aug  3 02:34 liboctinterp.s -> liboctinterp.s
14:31.53frikkerlrwxrwxrwx    1 root     root           21 Aug  3 02:34 liboctinterp.so -> liboctinterp.so.3.0.0
14:31.55frikker-rwxr-xr-x    1 root     root      7022736 Jul 29 15:51 liboctinterp.so.3.0.0
14:31.57frikkerroot@gumstix-custom-verdex:/usr/lib/octave-3.0.0$ cat liboctinterp.s
14:31.59frikkercat: liboctinterp.s: Too many levels of symbolic links
14:32.01frikkeroops, sorry for the long paste
14:38.32*** join/#oe Sleep-Walker (n=Sleep@gprs2.vodafone.cz)
14:42.40*** join/#oe dijenerate (n=dijenera@69.73.223.106)
14:43.07frikkerif i have a package, like gnuplot, installed on my embedded system - is there an easy way using ipkg to see how much room the package and its dependencies take up?
14:46.24*** join/#oe mickey|shopping (n=mickey@e180143247.adsl.alicedsl.de)
14:48.09pb__no, not really.  you could make a script to do it but there's no builtin facility.
14:49.01pb__obviously there's the complication that you don't want, say, libc6 to get charged against gnuplot even though gnuplot depends on it.  you'd need to make the script check for dependencies that aren't depended on by any other package, I guess.
14:49.24*** join/#oe thebohemian (n=rschus@p579E18CD.dip.t-dialin.net)
14:52.03frikkersure
14:52.04frikkerhmm
14:54.20*** join/#oe vivijim (n=vivijim@unaffiliated/vivijim)
14:56.06*** join/#oe abner (n=birunko@200.184.118.132)
14:57.26frikkeralright, so i have an X server up and running but it loads matchbox, matchbox panel, desktop, etc.  
14:57.35frikkerI can't figure out how to decouple matchbox from it
14:57.47frikkerxinit /etc/X11/Xsession -- /usr/bin/Xfbdev :0 -br -pn -screen 480x272@180
14:58.04frikkercan i just get Xfbdev running and use gtk with that? or do i need matchbox too?
14:58.19frikkerwe just have a single app that will be running
14:58.53tharveyI'm trying to use OE to generate a 'bootstrap' image of a kernel+initramfs, therefore my kernel recipe needs to have the initramfs cpio.gz as a DEPEND, yet if I create an image recipe for my initramfs that inherits task-base it depends on task-boot which depends on kernel - what is suggested?
14:59.35tharveyI see a 'bootstrap-image' recipe but it depends on MACHINE_TASK_PROVIDER which by default is task-base which depends on kernel
15:00.14pb__don't use task-base, I suppose.
15:00.55pb__you can roll your own filesystem from raw materials, and in the case of an initramfs that probably is what you want to do.
15:01.00tharveyya, I was wondering if that would be the suggestion - but it seems like you would loose a lot of nice features by not using task-base, I'm wondering if task-base should really not be depending on kernel?
15:01.11*** join/#oe rsalveti_ (n=salveti@200.184.118.132)
15:01.27*** join/#oe rsalveti (n=salveti@200.184.118.132)
15:01.36pb__what features would you lose?  I don't think there's anything magic in task-base: anything it can do, you can do.
15:02.04tharveypb__, yes, but I do like the concepts of task-base as I need to do this for several machines that have various hardware support - but I suppose I can recreate those aspects of task-base in my initramfs recipe
15:02.18*** join/#oe MarcOChapeau (n=mbarre@bgn92-4-82-238-213-101.fbx.proxad.net)
15:02.26tharveyI'm referring to the matchup of MACHINE_FEATURES and DISTRO_FEATURES
15:03.02pb__tharvey: hm, right, but presumably you don't want most of that stuff in your initramfs anyway.
15:04.37tharveypb__, perhaps not... I just didn't want to deviate from the standard way of doing things if there was a better way that I'm missing
15:05.06pb__but, all that aside, I think probably the right answer to your original question is that the kernel image oughtn't to be depending on the initramfs.cpio.gz anyway.
15:05.32pb__if you do that, it will be impossible to put any modules into the initramfs, which I suspect will defeat its purpose
15:06.09pb__you probably want to have one recipe for the kernel which doesn't depend on anything, another recipe for the initramfs, which can depend on the kernel if it likes, and a third recipe to take the two things and glom them together to make the bootable binary lump.
15:07.14tharveyyes, I thought about that aspect as well
15:07.44tharveycurrently I'm using initramfs via kernel CONFIG_INITRAMFS_SOURCE so in order to build the kernel the cpio.gz has to exist
15:08.12tharveyI think I need to change that to use an initrd (which can be a cpio.gz if I wish, or anything else initrd supports)
15:08.39pb__ah, I see.  well, in that case the third recipe (the one that does the combining) might be a variant of the kernel build.
15:08.53tharveyI wish to build a sing-file image with the kernel+initrd but as you say I could do that outside of the kernel build process and add another recipe that handles that
15:09.14pb__so, in that case, you'd have two separate kernel recipes: one that builds the modules but doesn't include the cpio.gz, and then another one that builds the kernel with the initramfs included.
15:09.31*** part/#oe zoolooc (n=lucian@nrbg-4dbfc65c.pool.einsundeins.de)
15:09.58tharveypb__, ah... yes, you mean actually build the kernel first w/o INITRAMFS_SOURCE so that mods etc are built, then have a 3rd recipe that relinks the kernel or something?
15:11.09pb__right
15:11.19tharveyI'm not sure there is really a huge benefit to using internal intramfs vs a cpio.gz initrd - in the 2nd case the kernel utilizes the initramfs code and doesn't really treat it as an initrd other than the fact the kernel got passed a pointer to it vs it being linked to the kernel directly (AFAIK)
15:11.54pb__yeah, I don't think there is any significant difference between the two methods.
15:12.06pb__if your bootloader knows how to pass an initrd, it is probably just as good to use that mechanism.
15:13.21tharveyya, and in some cases such as powerpc's cuImage you can wrap up kernel+initrd with a bootwrapper that does it for you without the help of the bootloader
15:13.57pb__right
15:16.47*** join/#oe e-ffi (n=cybercom@dslb-088-068-166-115.pools.arcor-ip.net)
15:28.10*** join/#oe Sleep-Walker (n=Sleep@gprs9.vodafone.cz)
15:32.34*** join/#oe DarthWader (n=sith@vorphalack.msk.ru)
15:33.05*** join/#oe memeruiz__ (n=memeruiz@e176227035.adsl.alicedsl.de)
15:37.13*** join/#oe hvontres|work (n=hvontres@hentges.net)
15:40.52*** join/#oe mranostay_work (n=mranosta@cpe-089228.fiber.wadsnet.net)
15:40.58mranostay_workERROR: '['/home/mranostay/easi-oe/projects/rmi_dbau1200/current/openembedded/packages/tasks/task-maemo.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'outo' but it wasn't found in any PACKAGE or RPROVIDES variables
15:40.58mranostay_workNOTE: Runtime target 'outo' is unbuildable, removing...
15:40.58mranostay_workMissing or unbuildable dependency chain was: ['outo']
15:41.07mranostay_workany clue why that outo is missing from OE?
15:44.30thesingpb_: I think we should split the build of the kernel into build modules and build kernel.
15:44.58pb__why?
15:47.06*** join/#oe mrdata (i=unknown@dslb-088-074-188-116.pools.arcor-ip.net)
15:47.54mrdatahi all
15:51.22florianhi mrdata
15:51.35mrdataih florian
15:55.51*** join/#oe CSMan (n=csman@bas1-montreal42-1177928272.dsl.bell.ca)
16:16.17thesingpb_: to solve the problem with initramfs with modules included. the initramfs could depend on package_modules and build_kernel on image:do_rootfs.
16:23.10*** join/#oe valhalla (n=valhalla@81-174-37-232.dynamic.ngi.it)
16:28.57pb__thesing: true, but that is an uncommon case that is already soluble.  it doesn't seem like breaking up the kernel build process for everyone would bring much benefit.
16:29.13*** join/#oe Jay7 (n=jay@89.250.164.201)
16:30.30thesingpb_: if its done right nobody will notice. And the actual solution (having two recipies) is not very elegant.
16:32.09pb__isn't two recipes exactly what you are proposing?
16:32.19pb__maybe I don't quite understand your suggestion.  can you explain it in more concrete terms?
16:32.37*** join/#oe AlGe (n=alge@chello080109231226.4.uni-klu.teleweb.at)
16:35.48AlGehi,
16:35.49AlGeis there an option for the bb git fetcher to specify a specific git branch to fetch?
16:37.56hvontres|workthesing: where do you specify the stic device tables for kexecboot? I think I mostly have it working, but I need to set up the mmc card nodes
16:38.31*** join/#oe jekhor_ (n=jek@mm-166-254-57-86.leased.line.mgts.by)
16:46.11thesinghvontres|work: you need to add device-table-collie.txt to DEVICE_TABLES (or so)
16:46.19*** join/#oe alphaone (n=alphaone@a064.apm.etc.tu-bs.de)
16:46.25thesinghvontres|work: see collie.conf for an example
16:48.49*** join/#oe steliosk (n=Stelios@athedsl-282534.home.otenet.gr)
16:55.17*** join/#oe lrg (n=liam@79-68-78-64.dynamic.dsl.as9105.com)
17:02.59*** join/#oe stephank (n=urk@2002:52c5:cfc7:1:2c0:9fff:feb7:e03f)
17:04.03*** join/#oe diego (n=diego@host-84-222-23-218.cust-adsl.tiscali.it)
17:08.31dcordes_is there some website that informs about the server status
17:09.48hvontres|workdcordes_: check here for updates....
17:10.56dcordes_ok
17:16.18*** join/#oe likewise (n=likewise@82-171-51-231.ip.telfort.nl)
17:22.22*** join/#oe rschuster (n=rob@e178068082.adsl.alicedsl.de)
17:25.02*** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh)
17:32.25*** join/#oe bin1010 (n=aars@rrcs-24-227-199-231.sw.biz.rr.com)
17:45.19*** part/#oe jdav_gone (n=james@d75-157-13-250.bchsia.telus.net)
17:51.05thesingbye
18:00.29*** join/#oe alex_l (n=alex_l@nat/cisco/x-d82bacf8758ad893)
18:04.26*** join/#oe davygravy (n=davygrav@h69-128-156-59.mdtnwi.dsl.dynamic.tds.net)
18:14.32*** join/#oe Crofton|Durham (n=ben@wireless-5213.wireless.ece.vt.edu)
18:22.44*** join/#oe HellDragon (n=jd@Wikipedia/HellDragon)
18:34.39*** join/#oe jekhor (n=jek@mm-166-254-57-86.leased.line.mgts.by)
18:40.17*** part/#oe enigmaedge (n=mbailon@209.191.15.3)
18:42.14*** join/#oe rschuster (n=rob@e178068082.adsl.alicedsl.de)
18:52.01*** join/#oe arun (n=arun@unaffiliated/sindian)
18:57.31*** join/#oe CSMan (n=csman@bas1-montreal42-1177928272.dsl.bell.ca)
19:13.50*** join/#oe mrdata_ (i=unknown@dslb-088-075-227-011.pools.arcor-ip.net)
19:19.22*** join/#oe timtimred (n=meh@82-34-50-106.cable.ubr02.chel.blueyonder.co.uk)
19:19.35*** join/#oe smancke (n=smancke@ip-62-143-107-19.hsi.ish.de)
19:23.18*** part/#oe Crofton|Durham (n=ben@wireless-5213.wireless.ece.vt.edu)
19:26.10*** join/#oe angom (n=angom@201.170.65.143)
19:30.27*** part/#oe angom (n=angom@201.170.65.143)
19:35.13*** part/#oe wmat (n=btraynor@gromit.mixdown.ca)
19:36.07*** join/#oe lpotter (n=ljp@CPE-124-191-144-181.vic.bigpond.net.au)
19:40.55Croftonwhat's the mtn incantation to pull from wolfson?
19:44.42chouimat|workgrrrrrr
19:52.16Croftonanswers his own question by reading his email mtn pull opensource.wolfsonmicro.com org.openembedded.dev
19:56.39*** join/#oe mrdata_ (i=mrdata@dslb-088-074-174-158.pools.arcor-ip.net)
20:00.56chouimat|workkicks openssl-native for not building
20:01.46*** join/#oe frikker (n=blaine@107.135.68.216.DED-DSL.fuse.net)
20:02.49sakomanCrofton:  do you know what the status is on openembeded.org?  seems to have been down for a couple of days now
20:03.20Croftonnot sure
20:03.21Jay7$topic
20:03.26Croftonit is in a data center
20:03.33Croftonand someone needs to kick it
20:03.36sakomansource.mvista.com is down also
20:03.42sakomanit's a conspiracy!
20:03.43Croftonbut, apparently non one works on fridays
20:03.45Croftonyeah
20:03.48Croftonbash.org also
20:03.58Croftonmaybe the internet tubes need cleaning
20:04.04sakomanan all out assault on open source!
20:05.10Crofton|workyes, really annoying
20:06.55*** join/#oe flo_lap (n=fuchs@g227195090.adsl.alicedsl.de)
20:08.43hvontres|workCrofton|work: maybe there is a serious bug in the bind fix....
20:09.13Crofton|workI've been wondering, although it feels more like rounting headaches
20:09.38hvontres|workeither that or the chineese got a bit carried away trying to lock soen the internet
20:10.14hvontres|workerr down that is
20:13.36mwesterAl Gore took it back.
20:14.32hvontres|workat least kernel.org still works :)
20:14.54flo_lapre
20:18.10Crofton|workcrap, builds go really slow when tinderbox is not there to receive results
20:18.20*** join/#oe bluelightning (n=blueligh@pdpc/supporter/active/bluelightning)
20:21.55tharveyeven if I don't add a package manager to an image, the image contains /usr/lib/opkg/* - I believe this is from the image creation step as ipkg is used to create the image - is there something in OE that allows this data to be cleaned out or should I simply add a custom task after do_rootfs to clean it?
20:35.20*** join/#oe hillct (n=hillct@cpe-024-211-242-232.nc.res.rr.com)
20:40.38*** join/#oe ant_ (n=ant@host250-12-dynamic.60-82-r.retail.telecomitalia.it)
20:41.00ant_morning
20:42.26Jay7ant_: really :)
20:43.25ant_hi Jay7
20:45.01ant_sh*t, again a u-boot_git change...basically 4-5 per week...
20:45.17ant_even with wolfsonmicro...
20:45.35ant_somebody can't resist and update it
20:46.31ant_pb__: mercy
20:47.14tharveylooks like ROOTFS_POSTPROCESS_COMMAND would be good for what I'm looking for
20:50.02tharveyROOTFS_POSTPROCESS_COMMAND = "remove_packaging_data_files" - remove_packaging_data_files is defined in rootfs_ipk.bbclass - but its not exported via EXPORT_FUNCTIONS - is EXPORT_FUNCTIONS required to export?
20:51.51ant_Jay7: I have update the u-boot patch to the actual r16 and have bumped it to r17
20:52.09ant_now bugzilla is down I'll post it asap
20:52.26ant_but are trivial chabge
20:52.37ant_you can do by yourself
20:53.09Jay7ant_: send me whole package by email
20:53.18Jay7or patch only
20:53.50ant_ok
20:54.13Jay7I'm not sure about my time at weekend but I'll try to test u-boot + kexecboot + .dev :)
20:54.43ant_about u-boot, I really hope somebody will commit it and let us work on that foundation...
20:55.00ant_kexecboot needs so much test as possible, though
20:55.06Jay7I hope too
20:55.14ant_because will be heavily employed
20:55.39Jay7it's very bad that bugzilla is down.. :\
20:55.56ant_eh
20:58.23ant_Jay7: now I'm conmpiling a new kexecboot kernel..if it's too big I'll just install u-boot and gain that few bastard kilobytes
20:58.34ant_:-)
20:58.38Jay7:)
20:59.46Jay7hm.. may be I start up the build of .dev x11-image tonight..
21:02.09ant_I'm sending you the patch
21:04.21ant_done
21:06.14tharveyis anyone familiar with using the various initramfs- images?  I'm curious what they are doing with the resulting cpio.gz to get it built into a kernel w/o a chicken-and-egg scenario
21:08.48Jay7ant_: got it :)
21:09.23Jay7but I'm unsure about how recent is my local u-boot-zaurus package..
21:09.55ant_Jay7: remember you have to set the UBOOT_ENTRYPOINT="0x80008000" and UBOOT_LOADADDRESS="0x80008000" in akita.conf and CUSTOM_ROOTFS_SIZE and KERNEL_IMAGETYPE = "uImage" in local.conf
21:10.24ant_or just do it by hand...
21:10.58Jay7we really need to push this work to .dev :)
21:11.20ant_Jay7: kernel.bbclass is ready
21:11.23Jay7it's too easy to forget some of this
21:12.14ant_nah, it's only that hack for rootfs-size...the rest should be standard oe for uImage deployment
21:14.54ant_(but some lazy developer is not convinced...)
21:16.48*** join/#oe stephank (n=urk@2002:52c5:cfc7:1:2c0:9fff:feb7:e03f)
21:24.22ant_Jay7: actually you can just improve akita.conf and set all the new vars there...
21:24.34Jay7ant_: what is solution with udev?
21:24.43Jay7comment out udevsettle?
21:24.57ant_comment udevadm settle in /etc/init.d/udev
21:25.06ant_in the last rel
21:25.19ant_seems to work
21:25.34ant_with kernel 2.6.26 you could even strace udevadm settle
21:25.43ant_:-/
21:26.23ant_the delay introduced by strace seems enough to let it work without races
21:26.43ant_but why only on Zaurus? must be some linux-rp problem...
21:27.17ant_the behaviour is inconsisten between 2.6.24 and 2.6.26 (strace makes it work with latter)
21:28.50ant_Jay7: or prefer udev_092
21:29.02ant_or udev_115 from Poky
21:32.55ant_hvontres|work: is udev working ok on poodle?
21:35.54Jay7hehe.. I have open tab in my opera with udev bug from bugzilla :)
21:36.14Jay74 days uptime :)
21:38.03ant_Jay7: zImage-kexecboot-2.6.26-r2-c7x0.bin  ?1303372?Aug  8 23:35
21:38.12ant_uh...too big... ;-]
21:38.56Jay7It's showtime :)
21:39.14ant_now rootfs_size 96mb...
21:39.22ant_just to see
21:39.49ant_need a beer...pause
21:42.05*** join/#oe dyqith (n=dyqith@lattice.cs.ucdavis.edu)
21:42.42Jay7ant_: I have looking into altlinux bugzilla
21:43.07Jay7they have problems with udevsettle in udev 0.96
21:43.20Jay7here is some explanations
21:45.46Jay7quick solution applied - is to create file /dev/.udev/uevent_seqnum
21:45.59Jay7but I'm not sure that it's same problem
21:50.38Jay7ant_: look here when will back: https://bugzilla.altlinux.org/attachment.cgi?id=1583
21:55.30ant_Jay7: I think I already tried that patch...
21:55.36ant_IIRC no go
21:55.58ant_the only initscript working oob are _115 and the old _092
21:56.17ant_but hrw is working on this issue
21:56.25ant_with udev_124
21:56.40ant_http://svn.o-hand.com/view/poky/
22:00.40Jay7ant_: did you try it?
22:01.50ant_not yet, now working on kexec-bootmenu
22:02.25ant_tried a previous version with the hack from u-dev ml
22:02.38ant_the one I posted on bug 4118
22:03.02Jay7ok
22:03.08ant_at least you see which devices are left out
22:03.18ant_if you don't give enough time
22:04.04ant_Jay7: I forgot you have to set UBOOT_MACHINE="akita_config" too
22:04.15Jay7hm..
22:04.30ant_at least I have (c7x0 != corgi)
22:04.45Jay7ant_: where it should be inserted?
22:04.52Jay7local.conf/akita.conf?
22:04.53ant_akita.conf
22:04.56Jay7ok
22:05.08ant_where you like, now I have all in machine.conf
22:06.57*** join/#oe NAiL (i=repvik@nslu2-linux/pdpc.active.NAiL)
22:07.23Jay7can you mail me latest u-boot-zaurus too?
22:07.58Jay7or it is not needed anymore?
22:08.07ant_Jay7: it works ! I have u-boot.bin and u-boot-c7x0-git-r17.bin (the kernel) in my deploy dir
22:08.13ant_no, delete it
22:08.23ant_it's now merged in u-boot_git.bb
22:08.37ant_that's why the frequent updates...
22:10.20ant_Jay7: hmmm I have no uImage...sorry...
22:11.39Jay7ant_: your diff don't provide patches
22:12.08ant_<PROTECTED>
22:12.19ant_# patch "packages/u-boot/u-boot_git.bb"
22:12.20ant_#  from [dd5c9df20b550f8e184483944ba911d7de096d98]
22:12.20ant_#    to [5b959df4c25d00f0207145c9e111401dae0ee696]
22:12.39ant_ah, how are you importing it ?
22:13.01ant_just add the couple of lines...
22:13.21Jay7file://pdaXrom-u-boot.patch;patch=1
22:13.38ant_ouch...you are right...
22:13.41Jay7and next two
22:13.48ant_sorry...
22:13.50ant_1 mom
22:13.53Jay7np
22:14.02ant_(I hate mtn diff)
22:17.55Jay79.8G    tmp/
22:18.10Jay7wow..
22:20.01ant_Jay7: ok, I forgot to 'mtn add' the files after a checkout...
22:22.08ant_mail resent
22:22.21Jay710x :)
22:23.12ant_yes, I remember I had to delete org.openembedded.dev because it was fscked and did not recognize anymore the arch (some crazy messages like defaulting to I686...)
22:23.32ant_si I did a fresh checkout from wolfsonmicro
22:24.21Jay72nd try is bigger at least :)
22:25.02ant_should be all this time...
22:27.22Jay7ehh.. I will to save previous builds against .stable but I have no 10G now..
22:28.21Jay7btw is here some scripts to clean up sources directory?
22:28.29ant_do you use INHERIT += "rm_work" in your local.conf ?
22:28.44Jay7no I did not
22:28.48ant_(like Gentoo)
22:28.55ant_try ;-)
22:28.55Jay7ah
22:29.10Jay7good idea :)
22:29.38ant_would be a good idea if you add your builds to oestats
22:30.09Jay7howto? :)
22:30.10ant_INHERIT += "oestats-client"
22:30.10ant_OESTATS_BUILDER = "Jay?"
22:30.10ant_OESTATS_SERVER = "tinderbox.openembedded.net"
22:30.24ant_but it's down atm...
22:30.30ant_he he
22:30.54Jay7remind me when it will be back :)
22:31.03ant_put it now
22:31.14ant_then if you want to add smthg ##ANGSTROM_EXTRA_INSTALL = "mc gpe-bluetooth gpsd speech-dispatcher flite navit"
22:31.22ant_or similar
22:31.31ant_all above in local.conf
22:32.15*** join/#oe DarthWader (n=sith@vorphalack.msk.ru)
22:32.35ant_I'm not sure anybody is testing akita...
22:34.13Jay7ok, I've added
22:34.20ant_Jay7: if you want to build all the possible dependencies, add BB_DEFAULT_TASK = "buildall" to local.con (similar to emerge -D)
22:37.40Jay7is waiting for rm -rf in work/*/*
22:40.19ant_Jay7: sorry..right ones are UBOOT_LOADADRESS_akita = "0xa0800000"
22:40.20ant_UBOOT_ENTRYPOINT_akita = "0xa0800000"
22:40.37ant_and perhaps UBOOT_MACHINE_akita = "akita_config"
22:41.02ant_then you have to set somewhere CUSTOM_ROOTFS_SIZE_akita ?= "59392k"
22:41.25ant_(default in patched u-boot_git.bb)
22:41.35Jay7ok, fixed
22:41.46ant_http://projects.linuxtogo.org/pipermail/openembedded-issues/2008-February/007432.html
22:41.59ant_google cache is your friend
22:42.53ant_nowI have to see why the mkimage step is skipped...
22:43.26ant_where, why I can guess :-)
22:44.59*** join/#oe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net)
22:48.25*** join/#oe dcordes (n=dcordes@f049170097.adsl.alicedsl.de)
22:48.36*** join/#oe bin1010 (n=aars@rrcs-24-227-199-231.sw.biz.rr.com) [NETSPLIT VICTIM]
22:48.36*** join/#oe HopsNBarley_ (n=hops@pool-71-116-67-183.snfcca.dsl-w.verizon.net)
22:48.36*** join/#oe borg_ (n=olaf@80.149.17.21) [NETSPLIT VICTIM]
22:48.36*** join/#oe Foolean (n=emil@foolean.ros.sgsnet.se) [NETSPLIT VICTIM]
22:48.36*** join/#oe piroko (n=jeremy@pohl.ececs.uc.edu) [NETSPLIT VICTIM]
22:48.36*** join/#oe slapin_nb (n=slapin@saris-243.ip.PeterStar.net) [NETSPLIT VICTIM]
22:48.36*** join/#oe denix (n=denys@nat/ti/x-292ca2ca61732e6c) [NETSPLIT VICTIM]
22:48.36*** join/#oe mewyn (n=mike@elune.tuxnami.net) [NETSPLIT VICTIM]
22:49.04*** join/#oe hvontres|work (n=hvontres@81.169.178.128)
22:49.06*** join/#oe wick7xx (n=wicknix@74.213.217.246)
22:49.58*** join/#oe rsalveti (n=salveti@200.184.118.132)
22:52.10*** join/#oe ml-something (n=no@c-76-105-18-51.hsd1.ca.comcast.net)
23:05.01Jay7ant_: I've started up build of console image
23:05.20Jay7now I go sleep :) resume experiments at morning
23:05.42ant_good night
23:05.59Jay7you too
23:31.59*** join/#oe CIA-24 (n=CIA@208.69.182.149.simpli.biz)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.