| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> hello; I'm trying to start compiling few things from OpenEmbedded, but compilation always fails on qemu - there is a patch (mouse_fix-r0.patch) which FAILs
<1> hey pH5
<2> hi
<1> RP: can you switch OE to use a release version of qemu? or wouldn't that work?
<0> koen: hmm, I can try...
<3> hi ph5
<0> koen: sorry for stupid question; I can't google how to force spefic version of qemu to use
<4> koen: With 8.1 it would probably work and OE doesn't need the system emulation anyway I guess
<1> RP: we've seen multiple using halting on qemu-cvs' non-applying patches
<4> koen: Weren't you the one saying floating CVS dates were good?
<1> s/using/users/
<1> RP: it had a more nuanced opinion
<1> s/it/I/
<5> koen org.oe.dev * rf2c59ac2... /packages/qemu/qemu-qop-nogfx-native_svn.bb: qemu-qop: remove nodocs patch
<4> koen: FWIW, poky gets on well with its locked down dates approach - its one reason users find it easier to build - its reproducible
<1> RP: I have few problems with angstrom, since I locked down a global date
<1> but a external file to lock down srcdates is bad, you'd better make snapshot .bbs
<1> like mickeyl did with tslib
<4> koen: I've noticed. I stopped using Angstrom due to it as the fixed date broke my own packages :-(
<4> There is no point to snapshot .bbs
<1> there is
<4> They just duplicate metadata for no reason, expecially now we have patch date control
<1> if the scm based packages have patches
<4> and we can control patches by date now
<1> so why aren't the qemu patches date controlled?
<4> because nobody has added an enddate to stop the patch applying?
<1> because everybody was waiting for you to fix it?
<4> This is the first I've heard about it...
<4> So that could have been a long wait :-/
<1> I tend to not notice those reports since I use ***UME_PROVIDED on qemu
<4> and I use poky which has the date locked down...
<1> so upload your lock file and make angstrom use it :)
<1> that makes both of us happy
<5> koen org.oe.dev * ree677... /packages/qemu/qemu-native_0.8.1.bb: qemu: add -native counterpart for 0.8.1
<4> koen: The lockdown is in: http://svn.o-hand.com/view/poky/trunk/openembedded/conf/distro/poky.conf?rev=509&view=markup. I'm not sure how much of that will conflict with what Angstrom wants?
<4> (ignoring the poky distro bits)
<1> we can sort out breakage if we bump into it
<4> koen: Are you using anything xorg R7 ?
<1> although I'd like such a lockfile being outside $DISTRO.conf
<1> RP: I want to use 7.1 if possible
<4> koen: For OE, it would be. In poky, it makes sense
<4> koen: It might be better to create a new file based on a snapshot of the dates of you current most stable build then as this has a load of X srcdates from 2005
<4> xorg R7 is on the todo list...
<6> REdOG: Monotone migration to 0.27 ...
<6> s/REdOG:/Re:/
<6> I will be on holidays from 11th to 21st, so monotone.nslu2-linux.org will simply go off-the-air (accepting no connections) from whenever the schedule says that the actual migration begins until I get back and we update at our end.
<6> Hmm - looking at the schedule on http://www.openembedded.org/wiki/OpenEmbeddedMigration I can't actually tell when we should down our server ...
<6> koen: What is the date when no new 0.25 revisions are accepted?
<1> it's mentioned a bit cryptic in '2006-07-13 Announce that we will go read only on monday'
<6> (i.e. when is the freeze date exactly?)
<1> so 20060717
<6> 0:00 GMT?
<6> Perhaps make the freeze date 20060715 or something.
<5> koen org.oe.dev * rec5b2be6... /conf/distro/angstrom-2006.9.conf:
<5> angstrom-2006.9: pinch some preferred providers from Poky*
<5> * this commit message wasn't sponsored by o-hand.com ;)
<6> And then please contact one of the nslu2-linux admins (ka6sox, dyoung, NAiL) so they can shutdown monotone.nslu2-linux.org at that time.
<1> you'd have to take that up with migration master zecke
<6> ok, so nslu2-linux will shut down sometime on 20060715/16 then.
<4> rwhitby: 20060717 is the freezedate. Ifyou shutdown say 12 hours before that having made sure all your changes went to the master, it should be fine
<6> RP: yep, that's our plan.
<6> then we will not need to do anything other than update our monotone version, blow away our local database, and sync back from OE again.
<4> rwhitby: Sounds about right, fingers crossed :)
<6> Hmm - I guess we will need to db upgrade our org.nslu2-linux.dev branch, but that is independent of OE
<6> and our org.nslu2-linux.bitbake branch, again independent.
<6> Or can we ask OE to migrate them for us?
<6> (Hmm - I don't know if you guys sync them from us at the moment anyway)
<4> They're local to your servers, aren't they?
<6> yeah, I think so.
<4> rwhitby: You'd best ask zecke about that...
<6> OK, so on the 22nd when I return from holidays we will contact zecke and find out the way to upgrade our local database and then pull the already updated OE branch.
<4> rwhitby: I'd drop zecke an email and ask whether he could pull those branches into te conversion database as it would make your life easier and probably not complicate his too much :)
<6> The org.nslu2-linux.* branches are tiny anyway.
<7> koen: abiword people leaving comment in my blog :-)
<1> XorA|gone: :)
<4> rwhitby: The other thing you need to ensure is any nslu2 developers who have committed changes have pushed to the nslu2 server before that switch off time
<5> koen org.oe.dev * ra10fc861... /conf/distro/include/sane-srcdates.conf: sane-srcdates.conf: add a file which contains sane srcdates for floating packages. Taken from http://svn.o-hand.com/view/poky/trunk/openembedded/conf/distro/poky.conf
<1> RP: there you go
<6> RP: yes, we will make sure that is done by the 13th.
<6> and then switch off on the 15th.
<6> I've dropped zecke an email.
<4> koen: Excellent :). I'll fix the qemu patches as well at some point but probably not until this evening
<1> RP: i'm tempted to add an insane-srcdates.conf :)
<4> koen: To go with the insanity checker? :)
<1> yep
<5> koen org.oe.dev * rc6eb41e... /conf/distro/angstrom-2006.9.conf: angstrom 2006.9: switch to using sane-srcdates.conf
<1> later all
<1> djeez
<1> reenoo is sending hatemail again
<1> I guess forking wasn't enough
<4> hi Liam
<8> hey Richard
<3> hi lrg
<8> hey Phil
<9> Anyone know the answer to the "cannot computer suffix of object files" when trying to compile toolchain for arm(v4?)
<10> any of you lot any good with python?
<11> when creating an image (via image_ipk), the final image filename is appended with the machine name and a datestamp
<3> jkp__: mickey|fifa2006 is the embodiment of all python knowledge
<11> Is there some way I can find out the full filename of the final image file?
<3> tkp: find out from what context?
<11> well, I'm trying to use this image file with Imgloader
<11> but since the name of changes everytime.
<11> from a kind of top level bb file that will pull all our components together and use mkimg to give us a .img file
<11> so this pakage R/DEPENDS on stv-bootimage (which creates a .ext2 file and a .bin file), and should take those two image files and wrap them up in a .img file
<11> but I need to know the names of the files
<11> is it exported into some variable perhaps?
<3> only within do_rootfs.
<11> hmm, and it not available after that has been run
<12> morning
<3> no, but you could store it to some well-known location from inside that task.
<3> i.e. "echo ${IMAGE_NAME} > staging/stv-image-name" or some such
<11> pb_: oh ok, I thinking `export ${IMAGE_NAME}` ... although I'm a little unclear on what export is actually for
<3> export just makes the variable available in the environment for shell tasks.
<11> ah ok
<1> RP: it looks like a lot of your work went into 2.6.18.rc1
<9> koen, doh :) I was sure I had that one included, so I didnt even bother to check
<9> koen, but cant find the multimachine.inc file anywhere. I got multimachine on inherit though
<13> RP: what is your opinion on klibc and kinit?
<3> zecke: crumbs, kde has its own libc now?
<3> I guess they must have misunderstood the "g" in glibc
<13> pb_: hehe
<13> pb_: KIO, KLIBC
<13> pb_: the first is KDE specific, klibc is a kernel thing though :)
<13> hmm maybe one should put KDE into the Kernel... hmm
<13> pb_: klibc, is a libc created by hpa. The plot is to move all userspace initialisation into userspace
<13> e.g. initialisation of disks, swaps, resume, mounting, nfsroot
<1> zecke: do you have a working .bb for a recent klibc?
<1> zecke: the one in OE doesn't compile for me
<13> koen: not yet :)
<13> koen: I try to read up on the plans of klibc
<3> zecke: ah, I see
<3> later all
<13> pb_: take care
<14> your office doesnt count
<1> heh
<1> it was in the graduation works of the art school
<9> koen, where Can I find multimachine.inc, I got it set in inherit but no where else
<1> grep -rn multimachine conf/distro
<1> that shows you lots of inherits, which should hint you to cl***es/ :)
<9> koen, well all those distros have just set multimachine at inherit, which is what I use also.. So why isnt mine working?
<1> Kristoffer: no idea
<9> koen, The only difference is that Im using package_tar and not Debian
<9> koen, multimachine used to be an .inc file before right? will check around in the cl***es and see if i can spot anything obvious
<15> zecke: do you have some time?
<13> no :(
<13> mr_nice_slacker: anyway, shoot
Return to
#oe
or
Go to some related
logs:
#linux
damn small linux vgetty
CD-Bootcode
perl chdir with *
gcc 4.1.1 kernel cflags
#linux
#python
knoppix + fedora core 4 + fsck + ext3-fs error
#lisp
#linux
|
|