From: Lorenzo <lo...@gn...> - 2005-09-10 23:40:54
|
El s=C3=A1b, 10-09-2005 a las 15:52 -0700, Craig Hughes escribi=C3=B3: > Yes -- I haven't looked in detail at how much the mainline buildroot =20 > groups stuff into feature sets, etc -- but Kconfig provides a nice =20 > simple way of doing these higher-level groupings. Also means you =20 > don't mess up any dependencies, etc. I'm not sure if/how well it'll =20 > solve the "You're building madplay, therefore I should enable audio =20 > support in the kernel, and add pxa-ac97 to /etc/modules" concept, but =20 > it probably would get things a lot closer to that than we are now. Yes, it definitely would rock. > Yup -- moving to the newer buildroot layout makes this easier in two =20 > ways: >=20 > 1. Easier to stay in sync with mainline buildroot, piggyback on their =20 > patches, and send out fixes upstream > 2. Can manage everything with quilt, so it'd be a lot easier to =20 > integrate in 3rd party patches or manage our in mixed in with =20 > upstream stuff. I'll check it out tomorrow (or today, but a few hours later. I'm on CEST timezone ;) ) and see how can we handle the "profiles" and other stuff. > This is more or less what happens now. With each package in a =20 > separate directory though, it's much easier to manage the stacks of =20 > patches. Yeah, all the patches messed in sources/ is not good when you start having a couple of them. > > It could rock to have a truly clean buildroot which doesn't have =20 > > patches > > or alike inside, but has needed configuration files allowing us to > > specify patchballs (tarballs with stacked patches: 01-mypatch, > > 02-myotherpatch...) for each package/makefile rules: > > > > http://${HOST}/patchballs/${PACKAGE}/${VERSION}.tar.bz2 >=20 > Not sure I'm following. Those tarballs are basically more or less =20 > exactly what the buildroot provides... Just not in a tarball so it's =20 > somewhat easier to view diffs, make changes, and such. Well, I mean having a patches repository to get the patches dynamically. The idea is to have a very basic skeleton in the buildroot, and when the user enables a feature, the stuff related to it and it's dependencies gets downloaded from the repository. No tarballs are stored inside the buildroot by default, nor patches nor anything apart KConfig, the core Makeifles and the Rules. But of course we can live with the current way of putting the patches on buildroot, just with a more organized schema as you propose (split up and the like). > > OK, I'll be around to help, although I start school this week and will > > have limited time. >=20 > Got IM coordinates? I'm: >=20 > hugh3scr on AIM > cr...@st... on MSN > cr...@ru... on Jabber > hughescr on Yahoo > 1130120 on ICQ Yeah, I'm lo...@ou... for Jabber, trulux on IRC (OFTC and Freenode networks). I've also MSN account. I've added you in both Jabber and MSN ;). > binutils looks pretty easy, since upstream buildroot has already got =20 > it going. I've just compiled successfully with 2.16.1 -- I'll see in =20 > a moment if things run or not. I'm working on branches/projects/=20 > buildroot-2.6.13 because that's what I already had checked out... G R E A T=09 If the 2.16.1 of upstream buildroot has all the ARM fixes (I'll check that and report any doubts), then we are done and ready to make the uClibc upgrade with all the security features enabled. The .text relocations thing should be solved with the upgraded toolchain. Really good news :). > Let me know if there's something that's needed which wasn't in the =20 > upstream byuildroot patchset. OK, I'll check and report everything I find to you. > That should be pretty easy -- zcip is a pretty small patch :) Yeah, another thing out of the TODO list. I'm adding tasks to: http://bugs.tuxedo-es.org/index.php?tasks=3Dall&project=3D3 Feel free to check and do whatever you want there. Lemme know if you want a privileged account and I'll open it for you. Cheers, take care. PS: I'm off for today. --=20 Lorenzo Hern=C3=A1ndez Garc=C3=ADa-Hierro <lo...@gn...>=20 [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] |