| |
| |
| |
|
Page: 1 2 3 4 5 6
Comments:
<0> mornin
<1> JustinP: i have removed the task-opie-extra-apps from the meta-opie.bb, did bitbake -c clean meta-opie, bitbake meta-opie, bitbake opie-image
<1> ERROR: Cannot satisfy the following dependencies for task-opie-extra-apps:
<1> | ${task-opie-extra-apps}
<1> JustinP: thanks for all you help on this, but i must call it a day... head hurts :-(
<1> goodnight all
<2> Greg2: ${ }???
<2> that's what's wrong!
<3> looks like an uninitilalized var
<4> rosterifyng the 8.777 nodes now
<3> yay!
<5> nite
<3> zecke: ping me if you have a rosterified .db, and I'll have a look at updating the cronjobs and viewmtn
<4> koen: have you downloaded Luke's patched viewmtn?
<3> no, I didn't know it even existed
<3> anyway
<0> is dev. closed for commits?
<4> Kristoffer: check www.openembedded.org
<0> Ah, doh just rememberd
<4> Kristoffer: we have sent 6 announcements, two stories :)
<0> yeah :D just abit slow today
<4> and you are the first that asks :)
<0> Been, working nights and left my head in bed
<4> hehe
<4> nite
<0> zecke, nite man
<0> koen|away, got a link to the Package sorting script?
<6> hi
<0> CoreDump|home, hey :D
<0> Im feeling lost when committing is offline :)
<6> it is annoying at times, yes
<7> CosmicPenguin: you there dude?
<8> I hope so
<7> hey !
<7> been a while :) been hoping to catch you
<8> I have been done caught - whats up?
<7> so
<7> imgloader doesnt seem to like imaging running systems
<7> whch you said might be the case
<7> so i wanted to quiz you on how you might setup a firmware update thing with that in mind...
<7> im guessing some kind of ramdisk is needed?
<8> well, in the stupidest case, yes
<8> but that ***umes that you have free ram as big as your flash
<7> should have
<7> its painful the way we have to update atm
<7> would love to get something working
<8> all updates are painful - its a fact of life
<8> if you have the ramdisk memory available, then its an easy operation
<7> but the ramdisk image would need to have the new img in it right?
<8> sync down your filesystems, remount them as read-only (or better yet, unmap them)
<8> and then image them
<7> oh ok, so build a ramdisk on the fly?
<7> chroot into it? and then do what you said?
<8> probably - the problem is ensuing that you have everything you need in memory
<8> where everything you need is 1) the binary and 2) the .img
<7> the binary needs to be static then
<8> Now, you could probably work around 2) if you were clever - you could figure out where the .img was on the block device, and read the blocks into memory before you blow them away
<7> could you not just have a script to do this on a live system?
<7> create a ramdisk, copy in image and porgram
<8> Like I said several days ago, I would just do it from a initramfs
<7> right, but what do you put in that and how do you construct it?
<8> Well, where does the .img come from?
<7> youre ona live system, you download the image, create a ramdisk, copy in, mount from ram to a mount
<7> hmmm
<8> So, if you're in an initrd - you do the same thing
<7> mount it somehow, then chroot, unmount disk and image?
<7> right...so you would make the update consist to the ram disk image
<7> then reboot into that, do the update from an init script?
<7> and reboot again
<8> Have you considered that a whole scale firmware update really isn't the way to go?
<8> how about doing it piecemeal with ipkg?
<7> how can you get a differential dpkg?
<7> is that possible?
<7> s/dpkg/ipkg
<8> well, you wouldn't get a differential, but do you really care?
<8> you're planning on blowing away the whole image too - so write life obivously isn't a concern of yours
<7> it would be cleaner the other way id have thought
<7> no, its a hard disk
<7> flash disk
<8> Can you force a
<8> forget that
<7> i think we had some troubles getting the boot partition to work anyway, ie - what it built was broken
<7> but i think id have to get back to you on that
<7> would you need anything except imgloader and your image in such a ramdisk then?
<7> ***uming static imgloader
<1> JustinP: you still here?
<2> Greg2: yup
<1> NOTE: package opie-image-1.0: completed
<1> NOTE: build 200607171755: completed
<1> JustinP: i edited my meta-opie.bb and reduced the initrd.bin size from 21.6 to 20.6mb
<1> JustinP: it's flashed to my poodle and working, thanks again for your help with bitbake
<1> for the record a poodle initrd.bin should 'not' be over 20mb
<6> Greg2: heh
<9> Greg2: maybe CoreDump can push an updated poodle.conf when the database is back up
<10> Isn't poodle two 32MB partitions?
<6> well / is abou 20M
<1> hey CoreDump|home
<9> Actually, poodle is ~9mb + 22 mb + 32 mb (three partitions)
<10> Hmmm. Maybe'm thinking of shepherd
<0> Argh, so frustrating not getting past that libopie cvs issue when building opie-image
<9> but that is spread over 2 32Mb chips :)
<9> Kristoffer: what libopie issue?
<11> hovntres|poodle, checkout bug 1151
<11> Basicly, Im using 1.2.2+cvs for opie image
<11> but even though the necessary packages are built, they are removed (and set to 1.2.2) and it can no longer fill the deps
<6> Ken|JLime: you could hard-wire opie to use 1.2.1
<11> CoreDump|home, but im interested in 1.2.2+cvsdate. Cause that one works perfect
<11> it seems like all libopie*-cvsdate is removed when package-index is done
<11> and then it cannot fill the deps
<11> its like it thinks that 1.2.2 > 1.2.2+cvsdate
<2> Ken|JLime: perhaps you need to fix ipkg-make-index
<11> Will take a look at it,
<2> Ken|JLime: or move away the 1.2.2 ipkg :;-]
<11> JustinP, hehe :P
<11> JustinP, where can i find ipkg-make-index, package, meta, cl***?
<2> part of an ipkg package, not sure which one
<2> Ken|JLime: ipkg-utils it looks like
<11> oki, but looks like it will require patching the sourcecode then
<11> will check it out
<2> yep
<11> JustinP, I **** at reading python
<1> CoreDump|home: when OE is writable again would you change the /machine/poodle.conf
<1> ROOT_FLASH_SIZE = ?32? changed to-> ?22? or ?20??
<1> or would you rather i put this in bugzilla?
<6> the latter, so it will not be forgotten
<1> CoreDump|home: ok, will do in the morning with notes
<1> goodnight all
<12> i'm trying to build a custom OZ image to put on a SD card and i want to include all the dev packages (headers and such). how do i configure OE to place all these on the image automatically without manualy adding each one?
<13> manually edit the distro file
<12> what do i do exactly?
<13> but your probably better off just to copy the whole feed to your SD
<13> would result in less typing
<12> i don't want to parse all the dev files and risk missing anything or adding things i don't need
<13> not sure how OZ specifically is setup to handle it
<13> look in it's distro and include files
<12> already did, nothing obvious
<13> which image are you trying to build?
<12> gpe
<12> gpe for c7x0
<13> distro/preferred-gpe-versions-2.7.inc
<13> or something simular
<13> i think
<12> that just lists preferred version of packages, nothing to do with include files and such
<13> last i remeber it dictated what gets installed in the image
<13> might have changed now ofcourse
<12> i found it. it's in conf/bitbake.conf
<12> it's a global setting, above and beyond the distro settings
<13> that doesnt make sense
<12> everything just selects general packages, bitbake itself chops it up into dev and regular
Return to
#oe
or
Go to some related
logs:
Cannot determine the version of the linux kernel source
#fedora
grub arm9
#ubuntu
#ubuntu
#linux
#perl
linux bbfile
wx fileexit
mighty mouse debian xorg
|
|