On Thu, Jan 13, 2011 at 12:03 PM, Gordan Bobic <gordan(a)bobich.net> wrote:
Replying off list since you did the same.
Peter Robinson wrote:
> On Thu, Jan 13, 2011 at 11:38 AM, Gordan Bobic <gordan(a)bobich.net> wrote:
>> Peter Robinson wrote:
>>> On Thu, Jan 13, 2011 at 10:22 AM, Gordan Bobic <gordan(a)bobich.net>
>>>> I have a question on policies of how and whether Fedora-ARM patches are
>>>> rolled back into rawhide. The reason I ask is because I see overlap
>>>> between the required ARM specific patches between F11 and F12. What is
>>>> the policy for rolling these patches back into upstream and (more
>>>> importantly in case upstream is slow/reluctant to accept them) rawhide?
>>> In a lot of cases the people dealing with the issues have the ability
>>> to commit the fixes themselves so as to be able to push them directly
>>> upstream where necessary.
>> Is there a formal procedure for that? My concern is that this process
>> doesn't seem to work out in a timely and positive fashion in a
>> significant number of cases (otherwise we wouldn't have that big a
>> required patch overlap between Fedora releases on ARM).
> Not particularly, it depends on the package. In some cases its a
> simple spec fix, in other cases there's issues with the compilation of
> the code on non x86 architectures. F-11 and F-12 is also EOL and in a
> lot of cases the fixes aren't necessary in later releases so again its
> a matter of review.
> The timely part of the process is more a resource issue, there's just
> not that many people and those that are working on it are generally
> doing either part time or in their own spare time.
>>>> Also, what is the policy on new packages? Specifically, I found myself
>>>> in need of openssl098k compatibility package (need to run some binaries
>>>> from F11). This is pretty trivial to come up with (change the package
>>>> name from openssl-0.9.8k to openssl098k-0.9.8k in the spec file and
>>>> re-tar the openssl tar ball to extract to openssl098k-0.9.8k directory
>>>> instead of openssl-0.9.8k directory), but what I wanted to ask if
>>>> whether there is some kind of a policy for including things like this
>>>> the main distro. It is likely that this would be useful to other people
>>>> who are less willing/able to roll their own packages.
>>> The policy on new packages is that they have to be in upstream Fedora.
>> How does one get a package into upstream Fedora?
> In most core cases there's already compatibility packages for things
> like openssl but it varies. Is the package that depends on older
> openssl it proprietary and can't be recompiled.
Of course it can in theory, but that tends to lead to dependency hell
somewhere along the way, especially when the package is updated in a new
version, and the updated package cannot be used.
Specifically - on the Toshiba AC100 the only kernel that works with built-in
keyboard and touchpad is 2.6.29. Later versions haven't had this
functionality ported forward yet.
I have an AC100 as well that I've just got booting a base F-13 image
but using the 2.6.29 kernel too. I'm going to have a go at getting X
etc running on the weekend.
Thus, the only kernel module for the Tegra driver that can be used is
the same one.
The Nvidia Tegra driver that is old enough to have a compatible interface
with the kernel driver only has Xorg ABI 5, which means it won't work on
Fedora versions later than F11.
So, I have to have Xorg and associated drivers from F11 in order to
accelerated graphics working on this machine.
What X driver do you use for accel X?
Xorg binary links against libssl.so.8/libcrypto.so.8, which means it
requires openssl 0.9.8k, so the simplest solution is binaries from F11 for
Xorg with the openssl098k compatibility package.
Yea, I don't think you'll get that into Fedora mainline primarily
because openssl inherently has security issues.
While I'm sure the old Xorg could be compiled up for F13,
building it would
probably lead to dependency hell on a Fedora 2 versions newer. Using the old
binaries seems a lot less intrusive at a glance.
Can you link to where you get the X drivers etc from. I'm going to be
looking at this more closely. With luck the problem of older kernels
should disappear for most of the issues before long as the CE industry
is moving towards standardising on 2.6.35.x for their kernel so nvidia
I suspect will be already in process of upgrading to this as its
what's needed for Honeycomb tablets and the like. As to when the
source is released though is anyones guess.