| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> Grr. It writes some amount of data to ALSA and then gets stuck with EAGAIN.
<0> dmesg shows a lot of lines like "soc: DAI[23:4] failed to match rate"
<0> And finalle "Match OK" and after that "spurious IRQ for DMA channel 0"
<0> mp3blaster doesn't generate that spurious interrupt.
<0> I wonder what I'm doing differently...
<0> Huh. Apparently mp3blaster doesn't use ALSA at all.
<1> In other news, has this Werner Shulte fellow (http://www.uv-ac.de/openembedded ) been invited to contribute to the OE wiki?
<2> yes
<2> he seems to be busy at work, I haven't seen him in ages
<2> ~seen uv1
<2> ~seen uv
<3> uv1 <n=uv@p508929E6.dip0.t-ipconnect.de> was last seen on IRC in channel #oe, d h m s ago, saying: 'RP: Thanks, will try ...'.
<3> uv <~sc@p50924353.dip0.t-ipconnect.de> was last seen on IRC in channel #oe, d h m s ago, saying: 'By'.
<1> whoa
<4> are there other public trees than the OE tree? i.e. third party sources of BBPATH-compatible trees?
<5> zwelch: technically familiar tree is split
<6> zwelch: are you counting the multiple branches in the monotone repo? :P
<6> also, the repo openedhand.com uses is publicly accessible
<4> kergoth: not really ;)
<6> their distro, "poky"
<6> minimal repo for just that
<4> for a real example, i have my tree here: http://svn.minisplat.org/svn/src/trunk/build.d/dist/oe/
<6> zwelch: http://svn.o-hand.com/repos/poky/trunk
<7> ~poky
<3> [poky] http://projects.o-hand.com/poky, or a subset of OpenEmbedded, created by o-hand.com to testdrive some of their technology
<4> by adding it (or a path to an appropriate tagged branch, for releases) to BBPATH, there is really no point to add my files to the main OE tree, right? (social reasons aside... but that's part of this discussion too ;) )
<6> BBPATH doesnt find bb files, its for cl***es/conf. you'd use collections and bbfiles for the packages themselves
<6> but yes, theres no need to maintain everything in one repo
<4> so, i would guess that i am not the first person to suggest splitting the main OE repo into several smaller package repositories
<2> BB Collections can help as well
<6> zwelch: the problem becomes, where do you split?
<4> kergoth: yes, that becomes the "i believe" part of the discussion; there is no "right" answer
<2> zwelch: what we might do one time. Is creating 'views' of the MetaData
<2> zwelch: e.g. using test results to give you a known working copy for a specific task
<6> zwelch: i'd argue that its better to have one repository than to start throwing around completely arbitrary boundaries..
<4> zecke: i am interested in these collection things, but i don't recall reading much about them in the docs
<4> kergoth: i agree for the most part; there are pros and cons of each approach, but intertia has a big play in it too
<2> zwelch: see the BitBake manual.
<2> zwelch: e.g BB Collections help you to ease 'forks'
<6> zwelch: optimally, what i'd want is more of a split than is currently possible with bitbake
<2> zwelch: rewrite bits one by one while allowing you to easily merge
<6> zwelch: i'd want to split all distro specific metadata into a repo for that distro, including the distro specific modifications to each .bb, which is the hard part
<6> heh
<4> kergoth: i agree with you there
<4> thinking about my possible win32 (which i think i am going to shop around to a couple of clients after some more thought), there is no way i would want all that crap in the main repo
<2> back to work...
<4> as much as possible, it should build on top of - but separately from - the main OE repo
<6> its difficult, since you'd need to track the -delta- against the original .bb, so if the original changes, you may need to adapt... itd be like maintaining patches, but managed by bb
<8> i'd still settle for a Core, GPE, Opie, QTE, X11, and Optional repos
<4> yeah, it's definitely non-trivial; however, my initial example that started this was in the context of files that do not exist in any form in the upstream repo
<4> i mean, if partitioning things along logically sane lines is feasible and desirable, it seems like i have established a reasonable means for delivering these files
<4> in the main repo, i'd only want a conf file that could "include <url>" :)
<4> i.e. figure out to download the additional repos automatically
<4> kergoth: does any of that make sense to you?
<8> bitbake isnt that smart yet, we have big hopes for BB-ng from kergoth :P
<4> emte: the kind of split you suggested may seem feasible at first, but i suspect there would be too much overlap and maintenance costs (caused by the kinds of upstream tracking that kergoth mentioned)
<8> if bitbake starts using the sqlite backend then you could walk your intended build to get files and generate graphs
<2> it can generate graphs now as well... :)
<4> well, you don't need sqlite to do that; though, i admit you might need it to do it in a timely manner ;)
<8> zecke, yeah but not the kind needed for it to be smart
<8> as each package generates a branch of more deps and provides, with sql you can join them all back into one stream to build in the correct order
<2> I'm too tired to keep up forking between irc and work
<2> later pals
<8> night Zero_Chaos
<8> lol
<8> tab not fast enough
<8> but yeah i agrre with the package overlap posibility
<8> agree*
<5> wasn't koen's google project about making it better to use?
<5> it=monotone/bb
<8> i doubt OE will get any support from google any time soon
<8> unless someone files for nonprofit status
<5> http://code.google.com/soc/handhelds/appinfo.html?csaid=CED12F0DF30CA6C2
<6> thejapa: no, his project is to make staging packaged and managed
<5> oh
<6> why the heck is it under handhelds.org?
<6> jesus
<5> i guess that was before the openembedded.org
<8> because hh.o is a registered nonprofit organization
<6> thejapa: openembedded.org has been around for years. it happened to be -hosted- by handhelds.org, but thats all
<6> ah well
<8> oe.o also has no administrative body
<5> hmm, it will take lots of time to understand all these things :)
<8> so technically oe.o doesnt exist
<9> you don't need a formal administrative body to do SoC :-)
<9> but OTOH, google doesn't want to sponsor multiple projects in the same area, so there are lots of umbrella-y setups for SoC
<6> they should call that section embedded linux then, and leave it at that
<5> yeah, there are evolution projects in ubuntu
<5> opensync in kde
<7> kergoth: hh.org had the infastructure and people to run a set of SoC projects. I suspect OE on its own would have been overlooked
<6> infrastructure?
<8> not sure on that one myself
<9> nmap the last two years did SoC with 10-15 students and 1 admin/mentor
<9> fyodor is a busy guy :-)
<5> imo, hh.org is the portal for ipaq users, so it gets all popularity, that makes it easier to get chosen by google.
<8> i am not sure that is correct
<9> the actual way google chose projects though is all mysterious and random, so *Shrug*
<6> i disagree, i think oe just hasnt been marketed well.
<8> there are FAR more zaurii devs than ipaq
<5> in brazil you can count the zaurii in one president's hand i guess :)
<5> (our president has 4 fingers)
<7> kergoth: They'd done it before, had people who knew people, had someone to act as an admin, could show more financial backing than we can, are a "proper" organisation etc.
<8> dont most people on each nad?
<8> hand*
<6> RP: njs just contradicted you on that, so..
<9> oh, umm, "done it before" was an automatic qualification this year
<7> kergoth: OE hasn't had the marketing which does put us at a disadvantage for things like this
<7> kergoth: not on every point he didn't
<5> mind if I ask, what happened to last year students? disappeared?
<9> (and last year it was a mad scramble and almost random who got in, so whether a gropu had done it before is also random)
<8> thejapa, gremilin still pops in and does work
<10> kergoth: re splitting "distro specific modification", I have plans for such an architecture for a package manager planned
<6> RP: those might be beneficial, but no means prevented the numerous other project from getting in, and oe would still have had a shot on its own
<6> Luke-Jr: have a wiki page on it somewhere?
<10> kergoth: not really, just notes
<8> i can tell you that enlightenment has had project presented in the last few and always been turned down
<11> kergoth: yah; clearly the main reason that oe didn't get into SoC is that nobody filed an application.
<6> hehe
<10> the idea is based on Portage's USE flags, except making them modular
<7> kergoth: You've also ignored my people point - we don't have the people
<8> Luke-Jr, you aware that the portage-c people were contected at one point?
<10> emte: contacted about?
<8> bitbake i belive, kergoth could probably tell you the outcome
<10> but what about them? I need a verb of some sort =p
<10> kergoth: actually, OE can handle something similar-- it has the ability to insert steps and such
<10> kergoth: project-specific changes could be a new BB built on the vanilla one, but inserting a customize step
<6> i'd still like to see a capable metadata management and recipe execution library with modular parsers/metadata formats, which could be used as the backend for both a new bitbake and other actual package management tools
<10> you mean more-or-less recipe plugins?
<10> eg, a plugin could be created to handle Gentoo's ebuilds?
<6> thatd be the idea, though ebuilds are problematic since they're not directly parsed
<10> why not modularize also the execution of recipes?
<10> so a plugin to use RPM (for example) as a 'receipe'/source might be possible?
<8> bitbake already supports rpm i belive
<10> in which case, a ebuild plugin could probably be a patch or wrapper to Gentoo's Portage programs
<6> it does, bitbake supports src.rpm
<10> emte: as a recipe?
<6> yes, you can use a src.rpm directly
<6> it extracts the metadata and converts it to bitbake's
<6> then it can emit a binary rpm or ipk or whatever
<10> what about a binary RPM? ;)
<10> (yes, it'd be pointless-- but as a test for abstraction)
<6> an rpm is an rpm from the metadata side, it could parse it fine but would have no recipes to execute
<8> that poses problems for obvious reasons
<6> you'd have to have a seperate .bbcl*** to do the legwork of ripping out the binaries for the steps
<10> well, for a binary RPM there'd probably only be an unpack step before package/populate
Return to
#oe
or
Go to some related
logs:
#php
#debian
#suse
usplash black and white amd64
#bash
ls doesn't work for ftp but ls -al does
netfilter state module
#perl
#debian
#gimp
|
|