| |
| |
| |
|
Page: 1 2 3 4 5 6
Comments:
<0> ~summon schurig IMMIEDATELLY
<1> apt takes out 20 clean, identical-looking phones, some extra hands, and pretends to be a telemarketer for a large corporation, so he gets delivered a phonelist containing schurig IMMIEDATELLY's coordinates
<2> hrw: Oh, thanks a lot for the offer.
<2> hrw: I will take it into acount if I eventually decide to put my hands on that.
<2> Worse problem is lack of time, I need to win lottery to get time for my hobbies.
<0> http://quatech.com/ - someone know them?
<3> hrw: congratulations on your new job!
<0> mreimer: thx
<4> hrw: nope, never heard of them
<5> sirfred: only black :-(
<4> hey mreimer & sirfred
<3> hey koen
<2> koen: Hello
<0> koen: lot of 802.11 hardware
<2> XorA|gone: Oh, I was thinking that if you only got greytones, perhaps you was not configuring properly UV planes.
<2> But if you only get black...
<5> sirfred: yeah, I want random garbage, then I try and write the real stuff
<5> sirfred: anyway I have to go eat dinner
<6> hrw: yeah, quatech is about 30 minutes from here
<6> hrw: I know several people who used to work there, but company has been sold since.
<0> cbrake: I got contact from them
<6> hrw: neat -- small world :-)
<7> koen: got time to discuss MACHINE_ENDIAN?
<4> sure
<4> I still think it's a bad idea :)
<7> :-)
<4> I still feel like throwing stuff out of the window if I look at ixp4xx.conf and all it's python magic
<7> koen: one of the things I intend doing today is making ixp4xx.conf use the tune-xscale file
<0> rwhitby: +1 from me but ixp4xxle/ixp4xxbe configs are nice too
<7> hrw: ixp4xxle would set MACHINE_ENDIAN then call ixp4xx
<0> rwhitby: exactly
<0> hi Lorn
<7> hrw: if you set MACHINE=ixp4xxle, would you expect any _ixp4xx common overrides to be in effect?
<4> I bet I can convince bitbake to set MACHINE_ENDIAN to le and use MACHINE=ixp4xxbe
<0> rwhitby: rather not
<7> hrw: so anywhere where there is currently a _ixp4xx override in the metadata, you would expect now for there to be all three of _ixp4xx, _ixp4xxle, and _ixp4xxbe ?
<7> (for things that are not related to endianness)
<0> http://neatorama.cachefly.net/images/2007-01/mcgyver-paperclip.jpg
<8> hrw: where do you find these gems?
<0> rwhitby: ixp4xx.conf can add 'ixp4xx' into overrides so no need for ixp4xxle/be by most of time
<4> hvontres|poodle: my boss had part 5 of the wheel of time :)
<0> hvontres|poodle: misc places
<4> so my week has been saved :)
<9> Are you guys going to be at the Roy d'Espagne or is there some other #oe event Friday evening?
<7> hrw: that's what I meant. setting MACHINE to ixp4xxle would add ${MACHINE} and "ixp4xx" to the OVERRIDES.
<7> (that's what it does today)
<7> (but I want to find a better way to do that too, cause the way it is done in ixp4xx.conf today is a real hack.
<10> beer!
<0> rwhitby: MACHINE_* namespace is MUCH better then mistic ARCH_BYTE_*** var
<7> koen: saw your email on two machines and parallel building. Adding ixp4xxle which just sets MACHINE_ENDIAN and then calls ixp4xx.conf will not affect your ability to use either machine in parallel builds.
<4> hrw: but is it machine related or policy?
<0> endian is machine related
<4> rwhitby: if you already have seperate machines, why do you need a magic flag?
<7> the question is more about how to denote that machine endian choice throughout the rest of the OE metadata - by switching on machine overrides, or by examining MACHINE_ENDIAN
<4> rwhitby: http://www.openembedded.org/user-manual&dpage=chapter_reference#id2561814
<0> rwhitby: there is a function to check endian already
<4> "The following from the net-snmp recipe shows an example of using the existing site file entries for endianess to p*** the required endianess option to the configure script:"
<7> koen, hrw: (note that I am not religiously tied to one solution or the other - I'm willing to change based on what the best solution is identified to be)
<8> hrw: check out the "McGruber" clips at NBC.com...if they'll let you :)
<0> bbiab
<7> koen: so is it better to call that function once, and set (say) IXP4XX_MACHINE_ENDIAN and use that throughout, or to call that function in the 13 different bb files that currently use MACHINE_ENDIAN?
<4> use that function in the bbfiles I guess
<4> I would hate having to set 2 things to get be to work
<7> here are the different ways MACHINE_ENDIAN is currently used (so we can refer to the different situations in our discussion here): http://pastebin.ca/324956
<4> PACKAGE_ARCH_kernel-image-nslu2 = "nslu2${MACHINE_ENDIAN}" highlight why you want to have seperate machines
<7> koen: is your objection about needing to set MACHINE_ENDIAN in your local.conf (or auto.conf or wherever), or is your objection about using an internal (say) IXP4XX_MACHINE_ENDIAN variable throughout the metadata to denote a decision which has been made in the ixp4xx.conf machine file, or is it both?
<4> both
<4> I still think it's a lot clearer and simpler to have seperate machine.confs
<7> koen: actually, that file produces five different kernel files, that is not a machine override.
<7> koen: I don't disagree on having separate machine confs.
<4> if you have seperate confs, the autofoo stuff I linked to should be enough, right?
<7> enough to set an IXP4XX_MACHINE_ENDIAN variable that I use in other files, yes.
<7> (rather than duplicate the autofoo stuff everywhere that endianness needs to be known)
<4> but do you *need* a IXP4XX_MACHINE_ENDIAN flag?
<4> or is it just convinience?
<7> that is the question at hand, yes.
<7> as you can see from the pastebin, there are various different ways that MACHINE_ENDIAN is currently used.
<7> (i.e. some are easy to do with _ixp4xxle/be,_nslu2le/be machine overrides)
<7> others would require duplicating the autofoo stuff in each .bb file, or testing on (${MACHINE}=ixp4xxle, or nslu2le, ...)
<7> in some files the autofoo stuff would need to be done in multiple places, or else you use an IXP4XX_KERNEL_IXP4XX_MACHINE_ENDIAN variable that is local to just that .bb file.
<4> about testing for ixp, are those ixp specific, or is ixp the only machines that currently uses those?
<7> for all of them except apex, ixp4xx (or nslu2) would be the only compatible machines, yes.
<4> ok
<7> does that indicate a better way to do this?
<4> I think my main point is: autofoo works always, MACHINE_ENDIAN requires people to add it to their machines
<7> (oh, madwifi is another one that is not ixp4xx-specific)
<7> (but that patch in madwifi is not done properly anyway and needs to be changed)
<7> koen: I agree with you on reducing the number of variables people have to set to get things to work properly.
<7> how about if I call it IXP4XX_MACHINE_ENDIAN, use it throughout, and make sure that anywhere I use it also most have a COMPATIBLE_MACHINES set to ixp4xx (or derivatives)?
<7> s/most/must/
<7> then I set it in ixp4xx.conf, and then no-one can accidentally forget to set it.
<7> (and in any file which is not specific to ixp4xx, I use the autofoo stuff instead)
<4> that would be acceptable, although still on the convinience side of things
<7> (or a machine override)
<11> is this an autoconf version error? "error: possibly undefined macro: AC_DEFINE"
<4> JustinP: it's hard to distinguish between b0rkage and version mismatch with autofoo :(
<0> catholic god himself invented autotools just for amusement
<0> first there was the great flood, then the plague, now autotools
<12> lol
<0> kergoth: its from #oe
<0> ok. time to watch Sean talk
<7> koen: ok, I will change ARCH_BYTE_*** to IXP4XX_MACHINE_ENDIAN throughout, set that in ixp4xx.conf (which is included by all of ixp4xxle, ixp4xxbe, nslu2le, nslu2be), add compatible machine tests anywhere that I use IXP4XX_MACHINE_ENDIAN, and use autofoo elsewhere. deal?
<4> rwhitby: almost :)
<7> koen: :-) ok, what's the delta?
<4> rwhitby: set IXP4XX_MACHINE_ENDIAN in ixple.conf and ixpbe.conf and remove python magic from include/ixp
<7> koen: I agree with the intent - I may need help on the implementation of that last bit.
<7> the reason why I wanted to move almost everything into ixp4xx.conf is that people add stuff to ixp4xxle.conf, but forget to add the corresponding lines to ixp4xxbe.conf - causing maintenance problems (this has already happened with tune-xscale for instance, which is directly applicable without changes to the ixp4xxbe machine too)
<7> putting it all in a common ixp4xx.conf (switched on IXP4XX_MACHINE_ENDIAN) means that people are forced to consider how it applies to the other endian case (if it does), or at worst, they put it in unconditionally and someone else fixes it for the other endianness
<4> right, but that's a matter of policy
<4> I still haven't figured out how include/ixp works
<4> after spending some *hours* on it
<7> you mean all the thumb stuff?
<4> how everything fits together
<7> (I want to move all that stuff out and use tune-thumb)
<4> why there are overrides that are never used, etc
<7> koen: I agree, and I'm intending on cleaning that up as I go (i.e. there are slugos specific variables which simply mirror existing global variables for no reason)
<4> it's the trade of between making easy changes to 2 files (ixp{le,be} or one very hard change to the include
<7> (e.g. slugos_image*** should be removed, as should ixp4xx_suffix)
<11> koen: yeah, I figured....well, mpd 0.12.1 is failing with that error....guess I'll dig deeper
<4> I've stopped working on my loft temporarely since I don't want to spend half an hour 'porting' a change I made to h2200.conf to include/ixp
<7> koen: ok, how about I work solidly on include/ixp4xx to fix that?
<4> that would be cool
<4> I really think ixp maintenance would be easier of someone syncs up ixple.conf to ixpbe.conf once a month
<7> (as I have the same problem. John Bowler wrote most of include/ixp4xx, and made it very general, but its too general, and doesn't use enough of the standard OE practices (like tune-xscale and tune-thumb)
<4> rwhitby: it's too general for ixp4xx
<13> JustinP: for which machine or you building mpd? I think I compiled it for powerpc recently without error. Not sure if it was 0.12.0 or 0.12.1
<7> koen: looking at http://pastebin.ca/324956, are lines like line 5 acceptably non-complex?
<4> in the sense of "world famous in your own village" (dutch proverb)
<11> likewise: building it from OE for my Z. happens in .dev and .oz354x (note: 0.12.x is not in OE as yet). Build in gentoo also works fine...
<7> koen: I fully agree that the things like ARM_ARCHITECTURES and PACKAGE_EXTRA_ARCHS and PACKAGE_EXTRA_ARCHS is way over the top for ixp4xx, and I intend on simplifying or removing all of that.
<4> rwhitby: personally, I'd just put EXTRA_IMAGECMD_jffs2 = "--<foo>-endian" in both ixp configs
<11> likewise: although I'm not sure if gentoo is autoreconf-ing
<7> koen: ok, let me look at those and tend towards clarity rather than generality
<7> koen: thanks for the discussion - I will implement this today.
<4> rwhitby: the dillemma I had was that fixing it properly requires a few iterations and discussion, which would mean slugos is essentially broken for a few weeks
<7> (gotta get ready for work now)
<7> koen: I will make sure that slugos stays working throughout.
<7> and will consult closely with yourself and the other OE core team members as I make the changes.
<4> I wasn't sure if I could garantee that
<7> koen: I think this is a good outcome, and I'm happy with it.
<4> cool
<7> (i will follow up the RFC to document the decision)
<7> RP, hrw, mickeyl are you guys all cool with the result?
<14> koen: PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross" could this be the problem?
<14> is there a new sample.conf?
<4> _law_: http://rafb.net/p/e36Dqb45.html
<14> koen: so no more virtual/gcc in local.conf?
<4> nope
<14> koen: ok so this could be the problem
<4> could be
<13> koen: interesting for you? http://tree.celinuxforum.org/CelfPubWiki/ELC2007CallForPresentations
Return to
#oe
or
Go to some related
logs:
install madwifi using yum
javascript associate a function with an element
gproftpd step-by-step
reiki sudo
Command failed: Block device required
#suse
gnome-mount pendrive
serial scsi debian installer
#dns
#php
|
|
