| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> Getting "Udev requires hotplug, not started"
<1> to answer my earlier question about this error message: "qemu: uncaught target signal 4 (Illegal instruction) - exiting"
<1> apparently qemu doesn't like "include conf/machine/include/tune-iwmmxt.conf" in conf/machine/ipaq-pxa270.conf. Maybe it chokes on iwmmxt extensions.
<1> I commented it out and replaced with "include conf/machine/include/tune-xscale.conf" and now glibc locales are being generated without that sig 4 error
<2> kristoffer org.oe.dev * re5d3d6... / (2 files in 2 dirs):
<2> linux/linux-jlime-jornada6xx-2.6.17/defconfig_jlime: Changes
<2> * Rebuild firmware
<2> * Set all wifi as modules
<2> kristoffer org.oe.dev * re78d559... / (1 conf/distro/jlime-donkey.conf):
<2> conf/distro/jlime-donkey.conf : Add wget to rdpends
<2> * Due to busybox wget having issues with p***ive ftp, we want
<2> full wget version.
<2> kristoffer org.oe.dev * r64e63... / (1 conf/distro/jlime-donkey.conf):
<2> conf/distro/jlime-donkey.conf : Removal of some RDEPENDS
<2> * Remove pcmciautils, orinoco-conf, hotplug-ng
<3> mr_nice_slacker1: verify done
<3> now lets see
<4> CoreDump|home: Have you had any luck looking into the issues altboot seems to be having with loop-images lately ?
<3> anyone a hint for what could be wrong if i cant get past the FABDATA message whilst booting my simpad?
<5> Hello? Anyone here?
<6> hi sadarax - most of the folks in this channel are on eu time and are asleep now - they start coming back online here in about another 6 hrs
<7> 'morning
<8> good morning
<9> florian_kc: I got upto gdb-cross when building task-sdk
<9> umm, meta-sdk that is
<10> http://www.linuxdevices.com/news/NS8030785497.html
<10> lol
<11> morning
<12> morning all
<11> RP : Morning. Found some free time and i am truing to sync owmnr to the latest OE
<11> RP: If nothing major comes up i will post the patches today and tommorow
<12> Ifaistos: Sounds good! :)
<11> guys i am thinking of seting up a "cluster" of 10-15 machines to increase compile speed at the office. I am trying to think if there is a way to make it availiable to OE developers also. Any ideas/thoughts ?
<8> zecke: ehh... the most obvious thing is that they must have spent a huge amount of money in this architecture graphic. that one is in *every* qt/e related article...
<7> Ifaistos: even without making it available to the OE developers, such a cluster can be of great help to ensure a better OE quality, I mean spotting build regression - i.e. performing tests and doing clobber and 'from scratch' build of OE packages and distributions and to report the builds and tests status to tinderbox
<7> unless someone think of a better use of such power ...
<11> i was thinking of setting up a Xen machine with accounts for the developers and from there they could have access to the build system
<10> florian_kc: yes
<10> florian_kc: but is it Qtopia(Core) not QtE
<11> i will be upgrading the dsl line to dsl2+ (24Mbits/3Mbits) so i think the bw will be there also
<8> zecke: well...
<7> Ifaistos: ok. so I guess a simple ssh access + rights to send report to tinderbox is enough :)
<11> cyrilRomain: Yes something in this context. I am thinking of using 2.5Ghz Celerons with 1Gig Ram on each box. Any idea what distro would be better suited for such a task ?
<2> florian org.oe.oz354x * r78a75... / (3 files in 2 dirs): gpe-conf: add 0.2.2
<7> Ifaistos: any distro can be used as soon as you can easily install the OE required software. I would use Debian or Gentoo though.
<7> Ifaistos: or if you feel it, you could create a Knoppix-based OE liveCD, so that you just have to burn 1 cd per machine (no install required) :)
<7> i.e. a Knoppix liveCD with OE required software
<13> morning all
<11> i was thinking for making the machines netboot but it seems that it will effect the throuput if no local hd is present, and if you end up with a HD on every machine then no need to have a cd also
<11> morning
<14> hi lrg
<8> hey lrg
<12> hi Liam
<12> lrg: I'ev not got around to doing the ASoC testing yet, sorry
<13> RP: np
<13> RP: I think we may have to set pop_time = 0 for corgi due to the board noise :(
<12> lrg: I think that's looking like the likely result :-/
<13> RP: at least they fixed it in spitz :)
<12> lrg: yes :)
<13> RP: Dell still cant fix board noise. Even my new PC is noisy when I move the mouse :(
<10> mickey|thesis: ping
<10> mickey|thesis: The greenphone is funny
<14> hail zecke
<10> mickey|thesis: TT advertises Qtopia with its Openness
<12> lrg: Built in sound cards never seem to work well for me :-/
<10> ljp: Ship me a greenphone and I do not mean the PSD's :)
<15> is there any web repository for oe?
<12> katossi: See links on openembedded.org
<11> zecke: Do you have any example of using the icecream.cl*** ?
<10> echo 'INHERIT += "icecc"' >> conf/local.conf
<10> but I think it will fail to pack the toolchain together
<12> Scary thought for the day - if we have a set of identical machines, the multithreading code could run the tasks on different machines. There's some scary possibilities there
<10> RP: Think of Xen
<10> RP: then we all would have the same machine!
<12> zecke: With a rootfs built by OE to build within? :)
<10> and the next generation of man-kind will ask
<10> "How did they solve the Chicken-Egg problem. One needs bitbake to create bitbake?"
<12> zecke: and can it not go faster? :)
<10> hehe
<10> RP: bastard ;)
<15> zecke: thanks for the tip. I just came back from vacations and I'm blind
<2> pb org.oe.dev * ra6f628... / (1 packages/gcc/gcc-cross-initial_3.3.4.bb): gcc-cross-initial 3.3.4: clobber PACKAGES to avoid shlibs imbroglio
<11> RP: I am trying to build bash-3.0 and it failed, while trying to figure out what is wrong i noticed that the bash-3.0-fixes patches where not applied because the bash-3-0/lib/intl source files are unpacked as read only...
<11> RP : -r--r--r-- 1 stelios stelios 1856 Dec 9 2003 dcgettext.c
<11> is there any other site except pastebin.com ? its TOO slow the last few days
<11> RP : http://pastebin.com/768873
<7> Ifaistos: you can use http://rafb.net/paste/
<11> RP: I unpacked the tar file manualy and it seems that the problem is there. the lib/intl dir files are all set to readonly
<12> Ifaistos: You could add a task between unpack and patch which makes them all writeable?
<11> RP: Not sure how i should do it :( post_unpack () ?
<12> Ifaistos: Add a do_make_writeable() { chmod a+w somepath/* }, then "addtask mark_writeable before do_patch after do_unpack"
<12> s/mark/make/
<16> mornng
<13> hey Graeme
<16> hey lrg
<12> hi XorA
<11> RP: I think the problem with the bash-3.0 is the way the patches were grouped together after my initial patch.
<11> RP: The initial "fixes" for bash-3.0 had a pnum=2
<11> RP: While the other patch that causes the build failure has no pnum...
<11> RP: and these were grouped together
<12> Ifaistos: pnum should have no effect on whether the files are writeable?
<11> RP: I know but the funny thing is that the dir was not writable also before... but the patch worked...
<12> Ifaistos: You weren't running as root were you?
<11> RP: Nop i am using Ubuntu... so no root here ;)
<12> Ifaistos: Presumably quilt is clever enough to make the file writeable to apply the patch then?
<11> RP: Not sure i will try it again, using the original patches and see if it works or not
<17> RP: pretty sure it is clever enough indeed. sets it writable, then puts it back after applying the change
<18> hi kergoth
<17> hey
<12> kergoth: I've seen quilt shoot itself in the foot before with file modes. Can't remember exactly what and I think a later version fixed it...
<17> heh, wouldnt surprise me, that area of it never seemed entirely polished
<19> Hello.
<12> hi sirfred
<19> RP: Hello.
<12> sirfred: Did you have any further success with the alpha blending?
<3> mr_nice_slacker1: with the bostmodified 2.4.x bootldr i could check my ram right?
<19> RP: Yes, I have it working.
<19> RP: At least with an 4BPP alpha plane.
<19> RP: And also with a global alpha value.
<19> RP: I'm now trying to do a StretchBlt of a surface in host memory, in YUV format to an overlay showing card surface.
<12> sirfred: excellent :)
<19> RP: Still some problems, because StretchBlt only support RGB surfaces.
<19> RP: But it seems that it can be done using two StretchBlt operations, one for the Y channel and other one for the UV channels.
<19> RP: Each one using 8BPP.
<12> sirfred: Interesting. That could start to give a good speed improvement for video playback :)
<19> RP: I want to setup an overlay + scale for YUV using the new library.
<3> which library?
<19> x29a: I new one I'm developing.
<3> im looking for a fast image processing library, not for oe tho
<19> x29a: A new one I'm developing.
<3> sirfred: any publications yet?
<12> sirfred: You have the overlay working already? or you're using stretchbt to implement it?
<19> x29a: Still not, I'm thinking about it.
<19> RP: Overlay working. With RGB and YUV
<19> RP: Well, I've tested it with YUV422 and works fine.
<19> RP: Also with RGB565
<12> so we can accelerate video playback :)
<19> RP: But there're some strange things.
<19> RP: When using RGB surfaces, overlay honours the video_portrait bit in VIDEO_CTRL
<19> RP: But I was not able to put it to work using YUV. So, we cannot rotate the surface using hardware.
<12> sirfred: You really seem to have an understanding of how the chip works now :)
<19> RP: Well, I've learned a little. :)
<19> RP: I'm thinking about giving the current library public access.
<19> RP: It's not using any microcode, neither any part directly copied from the reverse engineered work.
<12> sirfred: Sounds like it might be possible to release it then
<19> RP: Still a lot of work to do, of course. But perhaps some other people gets involved.
<12> Other interest would be good
Return to
#oe
or
Go to some related
logs:
os-interface rlim
#suse
#perl
egonis
#perl
ubuntu modprobe.d loop
cannot open /dev/root on debian
#asm
#debian
#perl
|
|