On Thu, 02 Aug 2007 19:15:04 -0700 Manas Saksena <msaksena@xxxxxxxxxxx> wrote: > There are patches that we need to apply to packages that enables them > to build on ARM. Most of these are trivial. And, they have been > sitting in bugzilla for a while. See the ARM tracker bug for pointers > to these. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245418 > > If we can get these patches applied, we can move onto building > packages for ARM per the secondary arch proposal. This simplifies our > life, as we then have to only worry about failures (after a package > initially builds). A few of us were discussing this lately. We think we could pretty reasonably get the cvs access side of the secondary arch stuff in place relatively soon. This would allow you to have commit access to apply these changes yourself. > > There are a couple that are more difficult. They are worthy of a more > open discussion. For e.g., GCJ does not work on ARM today. We have a > patch that disables that and goes on with life. When gcj on arm works > on upstream, we can enable it again, and move on with life. Or, glibc > upstream has a glibc-ports tarball that carries support for ARM, and > some other architectures. We have a patch that adds the port tarball > to glibc to build for ARM and it has been refused by the maintainer. > > See: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246800 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246801 > > A slightly more friendly attitude their would be most welcome :-) Yes, that is a problem and we should kindly speak to these maintainers and express to them what we're trying to accomplish in Fedora. It's often easy for maintainers to not "notice" new initiatives in Fedora and not be aware that we're trying for new things. Although upon closer look it seems like you have a reasonable path for the second one, and the first one just needs some expectations set for how long gcj would be disabled on arm. > > > I > > speak for myself but I know the feelings of many, and > > we /absolutely/ wish to see derivatives made of Fedora. More than > > just "I cut up the packages this way!". Actual changes. Cases we > > haven't thought of before, things we've been too afraid to try. > > We're doing things to make this easier, like a new campaign to make > > it even easier to swap out our Fedora branding for more generic > > ones or your own. > > Good to know :-) > > > What else > > can we do to foster this desire to play with the bits and make your > > own distribution? > > A few things come to mind as things evolve in the future... > > 1. The VCS discussion should explicitly recognize this use-case. So, > it should be possible for someone to clone the fedora src repo, > and create derivatives from there, while staying synced up to the > fedora repository. Yes, that is one of our forefront goals. Make it easier for derivative development. > 2. As the compose tools evolve, hopefully they will not carry too much > of an x86/PC class system bias. For e.g., revisor/wevisor are > based on kickstart. I havent looked closely at it, but at first > glance it seems to have too much of that bias. I dont know whether > these are fixable or not. It would be useful, if using the same set > of tools (with appropriate modifications) I can create, for e.g., > jffs2 file system images. I have to ask how you think a kickstart file is bias? We have an external parser in pykickstart. The choice of using kickstart files is so that all things take that as an input. livecd-tools, eventually pungi, anaconda itself, etc... If the same config syntax and parser is used everywhere then we gain the value of code sharing and lower complexity for people creating new configs. I have to wonder though how this would be a bias against arm... > > 3. It is useful to have Fedora packages stay close to upstream. And, > if there is a need to put a desktop or server bias to them (by > modifying them significantly from upstream sources) then maybe these > should be considered in the same way -- i.e., as derivative distros > of a base Fedora distro. That is one of the stated goals of Fedora itself, to stay as close to upstream as possible. And yes, to start out with it would be nice to hand the desktop team the infrastructure needed for them to play with system level changes across the board while trying to create the Desktop derivative. Eventually those changes may be able to make it into upstream, or we can find creative ways to make them for Desktop spins. -- Jesse Keating Release Engineer: Fedora
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
