| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> So, if I want to create my own gcc package to change SRC_URI, how is this reflected in the distro configuration?
<0> i.e. should I create a package gcc_3.4.3-9x and then specifiy PREFERRED_VERSION_gcc ?= "3.4.3-9x" ? Or am I going about this wrong?
<1> sure
<0> lol, I was hoping for correction
<0> My method seems a bit hacked together
<0> But thank you JustinP I do appreciate the help, hope I don't come off as ungrateful
<0> I do like the toolchain all in all
<0> So far i have just been unable to find a "correct" way through grepping or reading docs
<0> I'll bang on it a bit longer
<0> I suppose what it comes down to, is that I don't precisly understand how PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross" relates to an actual package
<0> Any documentation links you know of would be helpful
<2> JustinP: how bloody stupid is that
<0> Me? I apologize if I was. Where was my error?
<3> NZG: talking to me?
<1> XorA: very
<0> XorA:yes
<1> NZG: no, he was referring to my previous comment to him
<0> JustinP|XorA: O, sorry
<1> ....bb compiled natively for some reason
<0> ah
<3> NZG: we were bemoaning hardware changes made purely to make old remotes unusable
<3> JustinP: although I suppose the remote part will work, just the sound part wont
<3> JustinP: given that resistors dont care which way they are wired
<0> Well, since I'm feeling better about myself now, I'll continue my line of questioning (which am am trying to answer myself but it's taking a while)
<4> yay, having fun here making OE work with linkstations...
<1> XorA: *nod*
<0> grepping around I discovered
<0> TARGET_PREFIX is automatically composed of TARGET_ARCH TARGET_VENDOR and TARGET_OS (documentation.conf)
<0> But what it's used for, I cannot tell, I don't see how it has anything to do with the package selected
<1> you might be able to use it as an override....
<0> Hmmm, ok
<1> I'm not sure, though
<1> my suggestion is just to add your patches right into the bb files that are being built now and make them work, then figure out how to move them out :-/
<5> NZG: arm-angstrom-linux-gcc like?
<5> NZG: TARGET_ARCH TARGET_VENDOR TARGET_OS gcc
<0> what package does that correspond to?
<5> very usefull when you build for same arch as host (i686 -> i686 for example)
<5> 27 00:26 < NZG> TARGET_PREFIX is automatically composed of TARGET_ARCH TARGET_VENDOR and TARGET_OS (documentation.conf)
<5> 27 00:26 < NZG> But what it's used for, I cannot tell, I don't see how it has anything to do with the package selected
<0> correct, still confused about that
<5> NZG: because?
<0> what package builds arm-angstrom-linux-gcc for example?
<5> gcc-cross
<0> right, and yet this is specified by PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
<0> Why is TARGET_PREFIX there?
<5> we have gcc (will run on target), gcc-cross (will run on host to build target binaries) and gcc-cross-kernel
<0> oh wait
<5> NZG: because OE depend on 'virtual/${TARGET_PREFIX}gcc' in many places
<0> so {TARGET_PREFIX}gcc is the target, :gcc-cross is the package, is that it?
<5> NZG: you can use 'virtual/arm-linux-gcc:gcc-cross' for example but it will fail if you change arch
<5> {TARGET_PREFIX}gcc is the target and gcc-cross is recipe which will get built
<0> ah, there it is
<5> you say "I want to get gcc-cross built to satisfy virtual/${TARGET_PREFIX}gcc thing"
<0> thank you, appreciated
<0> I don't think ss"
<0> <0> Why is TARGET_PREFIX there?
<5> np
<0> sorry
<0> accidental paste
<5> happens
<5> ok, bttm again
<5> backtothemovie
<3> NZG: it means for arm-linux-gcc build gcc-cross
<3> NZG: for example
<3> NZG: can also be put as PREFERRED_PROVIDER_${TARGET_PREFIX}gcc = "gcc-cross"
<0> seems logical enough now, I was just looking at it backwards
<3> NZG: :-D
<1> NZG: I suggest making use of an include ;-) include gcc-cross_XX.bb in your bb, then just SRC_URI += "..."
<5> JustinP: s/include gcc/require gcc
<1> yes, require
<3> if its only additions why not SRC_URI_append_9x = "first.patch;patch=1"
<0> JustinP:XorA sounds good! thanks for the tips
<3> just dont forget the space at beginning when using append, I always miss it
<0> XorA:kk
<3> time for me to sleep
<5> JustinP: the demo?
<1> hrw|tv: yep. it built as i686 in bitbake so I cimpiled it natively on my Z
<1> works fine
<1> I'll fix my OE build later
<5> with mikmod support
<5> to get music
<5> btw - does it work good on Z?
<5> bttm
<1> it works perfectly :-) you guys should bring it for FOSDEM
<1> yeah, with sound support
<1> I'll need some more work on the bb to make it all work
<6> hi, all!
<7> hey
<6> It seems that some of last commits that relate to Zire 72 did not hit target, so I added missing patches to bug 1820
<8> slapin_nb, in such cases you should suspect missed push ;-)
<9> slapinid org.oe.dev * re058126... / (1 packages/linux/linux-hackndev-2.6/palmz72/defconfig): linux-hackndev-2.6: Update defconfig for palmz72.
<9> slapinid org.oe.dev * rc2f07abc... / (1 conf/machine/palmz72.conf): palmz72: Minor update.
<6> psokolovsky, thanks!
<8> slapin_nb, sorry about this
<6> psokolovsky, np I just was curious for errors on my side then looked at commits list and found no commit, then concatenated all this and decided to open bug about that having chance to learn about mtn diff functionality :)
<8> slapin_nb, yep, mtn diff rules ;-). you probably want to do "mtn diff ." most of the time (equivalien of "svn diff")
<6> psokolovsky, mtn diff is like git diff, so I used to it already :)
<8> ok ;-)
<6> psokolovsky, how could I see log of revisions and diff from previous? :)
<5> mtn log --diffs helps
<8> slapin_nb, as usual, "mtn log". but it's used to be very slow in older versions. and I'm still on such old version ;-)
<8> hrw|tv, I've updated site for defconfigman - thanks for html
<5> your welcome
<5> mtn log in 0.32 is fast
<5> but also a bit changed..
<6> hrw|tv, btw, how about granting me commit access?
<5> slapin_nb: show us your patches and we will think about it.
<5> slapin_nb: iirc you provided 'just' palms support
<6> hrw|tv, I just want to maintain Palm Zire 72 port
<5> slapin_nb: the rules are same for anyone: show us your patches and we will think about it.
<6> ok
<5> slapin_nb: machine related stuff can be easily updated via sending patches.
<5> but you can choose some of packages in OE and start to maintain them
<5> provide fixes, updates etc.
<5> psokolovsky: do you remember how much time it took until you got commit rights?
<6> hrw|tv, I'll think about it (some maemo stuff probably).
<8> hrw|tv, I already "instructed" slapin_nb regarding this. IIRC, ~1month of sending patches (not only h4000's). all in all, it was really quick comparing to HH.org kernel CVS ;-)
<8> slapin_nb, hint: thumb ;-)
<5> maemo is totally unmaintained and I lack time to properly remove it ;d
<5> for me it took 2.5 months
<5> first small updates and finally first booting image for collie
<6> psokolovsky, yeah, you're right, I'm working on it already - esound-gpe is seems to be broken with thumb, probably I need to build world to see all
<5> slapin_nb: avoid building world unless you are ready for it.
<10> freeciv anyone?
<5> world build can break anything
<5> luke-jr: maintaining or playing?
<10> playing :)
<6> hrw|tv, I know but I will have to check many packages for thumb compatibility
<5> slapin_nb: good choice
<5> luke-jr: not now - just finished starwars 'making of' movie and its 02:09 here so time to go to bed
<10> pfft :p
<5> my website is getting more and more visits each day ;D
<6> psokolovsky, how to force all updated packages to be rebuilt?
<8> slapin_nb, updated by you or from repo?
<6> psokolovsky, from repo
<8> slapin_nb, just build main target and all changed should rebuild
<5> just run 'bitbake those which were updated'
<5> or their main target
<8> slapin_nb, to force-rebuild one pkg, add "-c rebuild"
<6> if i do bitbake blah-image, it just rebuilds image, but I know that at least X server was updated...
<6> blah-image is a bit customized gpe-image...
<5> slapin_nb: then do 'bitbake blah-image' and xserver should be rebuild too if it has PR bumped
<8> slapin_nb, so yes, what controls it is bumping PR. everyone who changes something, should bump PR, unless change is really trivial.
<8> slapin_nb, oh, and if it's *customized* image, maybe you have deps wrong ;-)
<5> if change affect packaging then bump PR
Return to
#oe
or
Go to some related
logs:
mousesports-movies
#math
#qemu
*** No targets. Stop. sendmail
#perl
#physics
reading phobia
#python
nicotin linux
#perl
|
|