Jesse Keating wrote:
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.
That would be helpful.
> 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.
Fedora is a large project -- it is important that people march in the
same direction roughly. I think there is a gap between where some in the
Fedora leadership want to do and the thinking of a significant number of
maintainers.
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 will live with the compromise. I say compromise since the glibc stuff
will be 95% duplicate --- I dont see how that can be perceived to be
good. And, as for gcj -- I havent seen any need for it for what I see
as the user-base for me. So, I have no incentive to spend the time and
energy to get that fixed.
Hopefully, openjdk will come along and replace the need for gcj.
> 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.
Great.
> 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...
I dunno. I havent looked at it close enough yet. I like the goal, and
if we can leverage the shared code-base, then that would be wonderful.
It depends on how easy it will be to extend with new commands etc.
> 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.
Glad to see that we are on the same page. I dont know how much of the
rest of fedora community, maintainers, and leadership is on the same page.
For me, the attractions of Fedora are:
-- closely synchronized to upstream
-- secondary arch policy
-- opening up of infrastructure, processes, etc.
-- used by developers (especially in corporate settings)
-- separation of build and compose tools
-- a rich, well-maintained package repository
-- many developers active in upstream projects
-- regular 6m release schedule
The biggest problems that I see and get complaints from others are
-- server bias to serve RH's core business
-- desktop weakness compared to ubuntu
The above are both real and perceived. And, I think directly related
to Fedora's brand (cf the fedora brand discussion).
Regards,
Manas
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
