| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> hey...
<0> quick one..
<1> try
<0> any way to stop bitbake uncompressing a .gz file from the local file fetcher?
<1> tkp: it is base.bbcl*** that is doing the uncompress
<1> tkp: you can provide your own do_fetch implementation not doing uncompress
<2> zecke: on that note, i was throwing around random ideas: http://kergoth.com/patchsyntaxpossibilities.inc
<1> kergoth: well, I would fail miserably with that version :}
<1> hmm my svk binary lacks the possibiliy to specify a hostname :`
<3> zecke123 * r bitbake_qa/ (11 files in 6 dirs): (log message trimmed)
<3> r476@umba: ich | 2006-07-30 22:05:57 +0200
<3> Copy for hacking
<3> r477@umba: ich | 2006-07-30 22:12:09 +0200
<3> bitbake_qa/cl***es/base.bbcl***: Update to the OE .dev copy of this file
<3> r478@umba: ich | 2006-07-30 22:13:30 +0200
<3> bitbake_qa/cl***es/base.bbcl***: Use less mirrors again
<1> nite guys
<4> g'day kergoth
<4> mickey|bbl: thanks :-) it was excellent.
<2> hey
<5> he pb
<4> hi woglinde
<6> that was great!!!!
<7> quit
<8> Good morning. Recent builds have suddenly started to leave behind ".dbg" files whenever files are stripped; the RUNSTRIP code seems to be responsible... what's the recommended way to not have this happen? (Yes, I can write code into the .bb files to find and delete all *.dbg files, but I hoped there was a better way to resolve this! :) )
<3> mwester org.oe.dev * rca63e8db... / (1 packages/images/unslung-image.bb): Unslung image: clean up .dbg files left by changed RUNSTRIP functionality
<3> mwester org.oe.dev * re55bcf63... / (3 files in 3 dirs):
<3> Unslung: slingbox: added built-in fdisk support, but without the /bin/fdisk link
<3> so as not to overwrite the Linksys fdisk utility.
<3> mwester org.oe.dev * rc8fccf3... / (1 packages/busybox/slingbox-1.1.3/defconfig): Unslung: slingbox defconfig added advanced fdisk options
<3> koen org.oe.packaged-staging * rd7c49ce6... / (1 cl***es/packaged-staging.bbcl***):
<3> cl***es/packaged-staging.bbcl***:
<3> * special case glibc-intermediate till we solve the shlib problem
<3> * use ipkg with a package name instead of a file
<3> * rebuild the package-index each time
<3> * make filename checks less strict
<3> koen org.oe.packaged-staging * rd073ff1e... / (1 cl***es/packaged-staging.bbcl***): cl***es/packaged-staging.bbcl***: introduce STAGING_BASEDIR and make use of it, per zecke's suggestion
<9> bonjour
<10> hey Genesis
<9> yop koen
<11> Does somebody know a reason why libgcc_s, libstdc++ and libg2c are not copied into a image?
<11> I use gcc-cross 3.3.4
<10> Cobelius: only stuff that's explicitly specified and dependencies of that endup in the image
<11> okay, but the packages for these libraries don't get created. They directory are prepared but they are empty
<11> Hmn I took a look inside the gcc-cross 3.3.4 .bb File. It's different to the other one. Could it be that this version habe a bug or that mit .bb files are too old?
<3> koen org.oe.dev * rccf2323... / (4 files in 2 dirs): gcc: make fortran switches behave like the java switches to battle the 'g++ disappeared' symptoms
<11> okay I found the problems my copies of the .bb files are too old
<12> morning
<10> hey XorA
<10> crap
<10> do_clean is a python method
<12> :-)
<12> those damn python people get code in everywhere
<10> which means I have to port my shell code to python
<3> koen org.oe.packaged-staging * rc0b5cc5b... / (1 cl***es/packaged-staging.bbcl***): cl***es/packaged-staging.bbcl***: add todo and invert some logic
<10> hey hrw|work
<13> morning after vacations
<10> "crap, my inbox is flooded with email"-day after vacations
<13> koen: :D
<12> hey hrw|work
<13> koen: when will ewi get monotone 0.28?
<10> koen@bitbake:~/OE/build$ mtn --version
<10> monotone 0.28 (base revision: 8c6ce7cb2ccd21290b435e042c2be4554ec6a048)
<10> last week :)
<13> koen: heh.. forgot about monotone -> mtn change...
<13> at home I got monotone == mtn
<13> ~lart APT pdiff support
<10> fixed
<10> koen@bitbake:~/OE/build$ monotone --version
<10> monotone 0.28 (base revision: 8c6ce7cb2ccd21290b435e042c2be4554ec6a048)
<13> gracias
<13> during week I will finish my migration
<11> where can I post changes I have made on standarf packages?
<13> Cobelius: bugtracker?
<10> Cobelius: bugs.openembedded.org
<11> thank you
<13> 291M debian updates
<13> ~curse linux for creating zombies
<14> May you be reincarnated as a Windows XP administrator, linux for creating zombies !
<13> ~kill kdepim
<10> brains.......
<13> 1. start kdepim 2. kdepim goes into zombie mode 3. reboot to run kdepim
<15> good morning
<12> hey florian_kc
<1> hrw|work: welcome back!
<12> hrw|work: Linux in new XXXX of the Dead film :-)
<10> hey zecke
<16> morning all
<10> hey Dirk
<16> hi koen
<3> koen org.oe.packaged-staging * rd975b1... / (1 cl***es/packaged-staging.bbcl***): cl***es/packaged-staging.bbcl***: fix 'too many arguments' error
<10> zecke: 'bitbake tslib' now work with packaged-staging :)
<10> works*
<13> hi dirk
<16> hey Marcin
<16> well relaxed?
<1> koen: okay :)
<1> hmm anoncvs port is still firewalled :}
<13> do13_: yes
<3> koen org.oe.packaged-staging * rf7fefaa... / (1 cl***es/packaged-staging.bbcl***): cl***es/packaged-staging.bbcl***: use -force-depends till OE metadata gets fixed
<1> koen: hehe, why not fix the metadata :}
<10> zecke: I have no detect_stylus.bb in my tree
<10> zecke: and it seems bitbake is broken :(
<1> sure, but in which way?
<10> zecke: it doesn't build the RDEPENDS in tslib
<10> ah
<1> do you have BUILD_ALL_DEPS set?
<10> 'bitbake nano' sort of works as well
<10> zecke: yes
<1> that looks wrong
<1> do you p*** a wrong dir to ipkg?
<10> zecke: i suspect a more subtle bug
<10> like a BUILD_CC that picks a cross gcc
<2> zecke: needs cleanup, but check out http://svn.o-hand.com/repos/poky/branches/ticket8/patch.bbcl***
<1> kergoth: documentation could help :)
<2> aye, its a first p***
<2> doing testing + cleanup + docu now
<10> kergoth: that SRC_OPTS thing you mentioned looks nice as well
<2> yea just playing around, i never liked how ${S} was the implicit patch application point. SRC_OPTS would be more explicit
<10> kergoth: btw, bugs.o-hand.com errors out
<1> SRC_OPTS looks hard to understand
<10> zecke: http://kergoth.com/patchsyntaxpossibilities.inc
<10> in case you missed it
<1> kergoth: I think I like it (patch.bbcl***)
<1> koen: well too many '|' for my taste
<2> well, its just a seperator that isnt likely to be used by something else
<2> feel free to pick another
<2> the idea is whats important, the explicit rules for unpack/patch
<10> zecke: still no .la and .pc troubles :)
<2> zecke: the resolver cl*** needs work, but it should open up more possibilities for more intelligent responses to patch application failure
<10> (readline, flex)
<1> koen: hmm. take a look at the .la files
<1> koen: do they have installed = yes in them?
<10> yes
<1> that is a bug :)
<1> (well you installed them, but....)
<10> it's easy enough to sed it out :)
<1> kergoth: BTW. I have looked at your Buildsystem page
<2> you found it?
<1> kergoth: and I'm in the process of finding someone to migrate the pages...
<2> where was it, in the old wiki files somewhere?
<1> kergoth: in 'our' backup of the moin wiki
<10> zecke: I have a perl script that does the gruntwork
<2> cool
<10> zecke: mm2mw.pl in ~/
Return to
#oe
or
Go to some related
logs:
#math
gentoo kuickshow broken
nIRC +howto
mac address ban
#ai
horse sheath
my fluid solver
Apache BrokenPipe
#linux
zavalko.com
|
|