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?
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 in the main distro. It is likely that this would be useful to other people who are less willing/able to roll their own packages.
Gordan
On Thu, Jan 13, 2011 at 10:22 AM, Gordan Bobic gordan@bobich.net wrote:
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.
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 in 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.
Peter
Peter Robinson wrote:
On Thu, Jan 13, 2011 at 10:22 AM, Gordan Bobic gordan@bobich.net wrote:
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).
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 in 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?
Gordan
Quoting Gordan Bobic gordan@bobich.net:
Peter Robinson wrote:
On Thu, Jan 13, 2011 at 10:22 AM, Gordan Bobic gordan@bobich.net wrote:
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).
http://fedoraproject.org/wiki/PackagingGuidelines
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 in the main distro. It is likely that this would be useful to other people who are less willing/able to roll their own packages.
Will your packages compile against openssl 1.0.0x?
The policy on new packages is that they have to be in upstream Fedora.
How does one get a package into upstream Fedora?
http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess
At least I think this is what you are looking for.
tor 2011-01-13 klockan 10:22 +0000 skrev Gordan Bobic:
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).
Such compat package of an old library release is generally not allowed in Fedora.
Regards Henrik
On 01/13/2011 02:35 PM, omalleys@msu.edu wrote:
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 in the main distro. It is likely that this would be useful to other people who are less willing/able to roll their own packages.
Will your packages compile against openssl 1.0.0x?
The package in question won't compile at all on F13, it seems:
# rpmbuild --rebuild xorg-x11-server-1.6.1.901-1.fc11.src.rpm ... libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -DDBUS_API_SUBJECT_TO_CHANGE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb "-DVENDOR_NAME="The X.Org Foundation"" "-DVENDOR_RELEASE=(((1) * 10000000) + ((6) * 100000) + ((1) * 1000) + 901)" -O2 -g -march=armv5te -Wstrict-overflow -rdynamic -c dispatch.c -fPIC -DPIC -o .libs/dispatch.o In file included from ../Xext/panoramiX.h:44, from dispatch.c:134: /usr/include/X11/extensions/panoramiXext.h:49: error: expected ')' before '*' token /usr/include/X11/extensions/panoramiXext.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXQueryVersion' /usr/include/X11/extensions/panoramiXext.h:64: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXGetState' /usr/include/X11/extensions/panoramiXext.h:70: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXGetScreenCount' /usr/include/X11/extensions/panoramiXext.h:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXGetScreenSize' make[2]: *** [dispatch.lo] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/xorg-server-1.6.1.901/dix' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/xorg-server-1.6.1.901/dix' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.dnujZU (%build)
Gordan
On 01/13/11 21:45, Somebody in the thread at some point said:
The package in question won't compile at all on F13, it seems:
# rpmbuild --rebuild xorg-x11-server-1.6.1.901-1.fc11.src.rpm
I don't know what the actual problem is from the error, but are all the dependencies in that filesystem also f11-vintage? If everything else down /usr/include is f13-vintage, it's quite possible f11 sources or spec might choke on considerably newer dependent includes.
What're you trying to achieve by recooking f11 xorg server on f13? Maybe there's a different way to come at your overall goal.
-Andy
Andy Green wrote:
On 01/13/11 21:45, Somebody in the thread at some point said:
The package in question won't compile at all on F13, it seems:
# rpmbuild --rebuild xorg-x11-server-1.6.1.901-1.fc11.src.rpm
I don't know what the actual problem is from the error, but are all the dependencies in that filesystem also f11-vintage? If everything else down /usr/include is f13-vintage, it's quite possible f11 sources or spec might choke on considerably newer dependent includes.
Most of the system is the F13 rawhide. It's yum updated from the F12 release since an awful lot in the F13 alpha is still missing or broken (e.g. firefox). So there are still a number of F12 vintage packages that aren't in the koji repository yet.
Interestingly, F11 libxinerama packages that contain the headers where the compile breaks don't even include those header files.
What're you trying to achieve by recooking f11 xorg server on f13? Maybe there's a different way to come at your overall goal.
I very much doubt it. The machine I'm working on is a Toshiba AC100. The only kernel available for it with working keyboard/mouse support is 2.6.29 provided by Toshiba as part of the open source code they wrote for Android (the machine comes pre-loaded with Android). Unfortunately, Toshiba have in their infinite wisdom decided to put the keyboard and mouse behind proprietary interfaces, rather than USB HID (the machine does have full featured master and slave USB, which makes the decision particularly retarded). The drivers haven't yet been ported to later kernels.
Further, the only way to eccelerated graphics on it is using the nvidia closed source tegra xorg driver. Since only 2.6.29 kernel works, only the tegra driver that is compatible with the interface of the kernel module for 2.6.29 works. That driver is sufficiently old that it is based on the xorg ABI from version 1.6.x, i.e. of the F11 vintage.
That means that the only way to get accelerated drivers is using the 2.6.29 kernel and Xorg 1.6. Xorg binaries from F11 require libssl.so.8 which means openssl 0.9.8k. F11 xorg src.rpm won't build on F12/F13, as explained earlier. I put just the three libraries it depends on in the relevant places, and that works fine, but by far the easiest way to solve this problem would be using an openssl098k compatibility package.
Gordan
On Mon, Jan 17, 2011 at 10:45 AM, Gordan Bobic gordan@bobich.net wrote:
Andy Green wrote: > On 01/13/11 21:45, Somebody in the thread at some point said: > >> The package in question won't compile at all on F13, it seems: >> >> # rpmbuild --rebuild xorg-x11-server-1.6.1.901-1.fc11.src.rpm > > I don't know what the actual problem is from the error, but are all the > dependencies in that filesystem also f11-vintage? If everything else > down /usr/include is f13-vintage, it's quite possible f11 sources or > spec might choke on considerably newer dependent includes.
Most of the system is the F13 rawhide. It's yum updated from the F12 release since an awful lot in the F13 alpha is still missing or broken (e.g. firefox). So there are still a number of F12 vintage packages that aren't in the koji repository yet.
Interestingly, F11 libxinerama packages that contain the headers where the compile breaks don't even include those header files.
fbdev works fine for me for the AC100, I don't think its accelerated but it auto detects and just works, not had enough time to play with it further and see what works and what doesn't.
> What're you trying to achieve by recooking f11 xorg server on f13? Maybe > there's a different way to come at your overall goal.
I very much doubt it. The machine I'm working on is a Toshiba AC100. The only kernel available for it with working keyboard/mouse support is 2.6.29 provided by Toshiba as part of the open source code they wrote for Android (the machine comes pre-loaded with Android). Unfortunately, Toshiba have in their infinite wisdom decided to put the keyboard and mouse behind proprietary interfaces, rather than USB HID (the machine does have full featured master and slave USB, which makes the decision particularly retarded). The drivers haven't yet been ported to later kernels.
Interesting, I'm looking at this closer as I have one of these devices myself. The keyboard/mouse reports its attached to the old style ps2 keyboard/mouse interfaces.
Further, the only way to eccelerated graphics on it is using the nvidia closed source tegra xorg driver. Since only 2.6.29 kernel works, only the tegra driver that is compatible with the interface of the kernel module for 2.6.29 works. That driver is sufficiently old that it is based on the xorg ABI from version 1.6.x, i.e. of the F11 vintage.
Works fine with the fbdev on the 2.6.29 kernel using the F-13 and the fbdev X driver. In the 2.6.37 and already pending for the .38 series there's been a lot of tegra drivers make it to the mainline kernel so it will be interesting to see what's missing / remaining / different on the toshiba side of development.
That means that the only way to get accelerated drivers is using the 2.6.29 kernel and Xorg 1.6. Xorg binaries from F11 require libssl.so.8 which means openssl 0.9.8k. F11 xorg src.rpm won't build on F12/F13, as explained earlier. I put just the three libraries it depends on in the relevant places, and that works fine, but by far the easiest way to solve this problem would be using an openssl098k compatibility package.
I suspect until some can fix it you'll need to deal with it yourself. 0.9.8k suffers from numerous vulnerabilities and its not something as a result that would get into mainline fedora. Fedora doesn't promote propriety closed source drivers so its extremely unlikely they'll add an old version of a library to support a closed source binary driver.
Peter
Peter Robinson wrote:
The package in question won't compile at all on F13, it seems:
# rpmbuild --rebuild xorg-x11-server-1.6.1.901-1.fc11.src.rpm
I don't know what the actual problem is from the error, but are all the dependencies in that filesystem also f11-vintage? If everything else down /usr/include is f13-vintage, it's quite possible f11 sources or spec might choke on considerably newer dependent includes.
Most of the system is the F13 rawhide. It's yum updated from the F12 release since an awful lot in the F13 alpha is still missing or broken (e.g. firefox). So there are still a number of F12 vintage packages that aren't in the koji repository yet.
Interestingly, F11 libxinerama packages that contain the headers where the compile breaks don't even include those header files.
fbdev works fine for me for the AC100, I don't think its accelerated but it auto detects and just works, not had enough time to play with it further and see what works and what doesn't.
Indeed, I'm aware that fbdev just works. Ironically, the "accelerated" driver doesn't support most of the useful acceleration APIs (e.g. XV). It only supports GL ES. If I understood what I read in the mailing list archives correctly, Mesa as of recently has support for implementing a full GL API based on GL ES APIs. But as far as I can tell, that version of Mesa isn't in F13.
The accelerated driver also has some interesting dependencies (kernel module and a userspace daemon). It's also not as reliable and can cause a few other quirks (e.g. random case of caps lock being stuck on and the only cure I've found is a reboot).
Plus, text mode console switch no longer works one you get into X.
There was, however, some success recently in getting one of acceleration APIs working with mplayer, based on hardware acceleration of the Tegra.
Are you on the AC100 IRC channel?
What're you trying to achieve by recooking f11 xorg server on f13? Maybe there's a different way to come at your overall goal.
I very much doubt it. The machine I'm working on is a Toshiba AC100. The only kernel available for it with working keyboard/mouse support is 2.6.29 provided by Toshiba as part of the open source code they wrote for Android (the machine comes pre-loaded with Android). Unfortunately, Toshiba have in their infinite wisdom decided to put the keyboard and mouse behind proprietary interfaces, rather than USB HID (the machine does have full featured master and slave USB, which makes the decision particularly retarded). The drivers haven't yet been ported to later kernels.
Interesting, I'm looking at this closer as I have one of these devices myself. The keyboard/mouse reports its attached to the old style ps2 keyboard/mouse interfaces.
AFAIK they are attached to the NvEc interfaces. One of the people on the mailing list was working on getting these to work on a more recent kernel, but with limited success so far - it isn't as trivial as one might hope.
There is some hope that Toshiba will provide Android 2.2 for the AC100 in the near future which should come, in theory, with a 2.6.32.x kernel, which will hopefully make things a little easier for us WRT nvidia driver compatibility, but Toshiba's interest in supporting the AC100 seems to be diminishing by the day.
Further, the only way to eccelerated graphics on it is using the nvidia closed source tegra xorg driver. Since only 2.6.29 kernel works, only the tegra driver that is compatible with the interface of the kernel module for 2.6.29 works. That driver is sufficiently old that it is based on the xorg ABI from version 1.6.x, i.e. of the F11 vintage.
Works fine with the fbdev on the 2.6.29 kernel using the F-13 and the fbdev X driver. In the 2.6.37 and already pending for the .38 series there's been a lot of tegra drivers make it to the mainline kernel so it will be interesting to see what's missing / remaining / different on the toshiba side of development.
As I said, last I checked the keyboard/mouse didn't work with newer kernels at the moment, and carrying an USB mouse/keyboard isn't really an acceptable solution for a netbook.
Gordan
On Mon, Jan 17, 2011 at 11:47 AM, Gordan Bobic gordan@bobich.net wrote:
Peter Robinson wrote:
>> The package in question won't compile at all on F13, it seems: >> >> # rpmbuild --rebuild xorg-x11-server-1.6.1.901-1.fc11.src.rpm > > I don't know what the actual problem is from the error, but are all the > dependencies in that filesystem also f11-vintage? If everything else > down /usr/include is f13-vintage, it's quite possible f11 sources or > spec might choke on considerably newer dependent includes.
Most of the system is the F13 rawhide. It's yum updated from the F12 release since an awful lot in the F13 alpha is still missing or broken (e.g. firefox). So there are still a number of F12 vintage packages that aren't in the koji repository yet.
Interestingly, F11 libxinerama packages that contain the headers where the compile breaks don't even include those header files.
fbdev works fine for me for the AC100, I don't think its accelerated but it auto detects and just works, not had enough time to play with it further and see what works and what doesn't.
Indeed, I'm aware that fbdev just works. Ironically, the "accelerated" driver doesn't support most of the useful acceleration APIs (e.g. XV). It only supports GL ES. If I understood what I read in the mailing list archives correctly, Mesa as of recently has support for implementing a full GL API based on GL ES APIs. But as far as I can tell, that version of Mesa isn't in F13.
Yes, I think the GL ES support is only very recent.
The accelerated driver also has some interesting dependencies (kernel module and a userspace daemon). It's also not as reliable and can cause a few other quirks (e.g. random case of caps lock being stuck on and the only cure I've found is a reboot).
Eww!
Plus, text mode console switch no longer works one you get into X.
There was, however, some success recently in getting one of acceleration APIs working with mplayer, based on hardware acceleration of the Tegra.
Are you on the AC100 IRC channel?
No (not sure what it is) but I am on #fedora-arm and #fedora-mobility
> What're you trying to achieve by recooking f11 xorg server on f13? Maybe > there's a different way to come at your overall goal.
I very much doubt it. The machine I'm working on is a Toshiba AC100. The only kernel available for it with working keyboard/mouse support is 2.6.29 provided by Toshiba as part of the open source code they wrote for Android (the machine comes pre-loaded with Android). Unfortunately, Toshiba have in their infinite wisdom decided to put the keyboard and mouse behind proprietary interfaces, rather than USB HID (the machine does have full featured master and slave USB, which makes the decision particularly retarded). The drivers haven't yet been ported to later kernels.
Interesting, I'm looking at this closer as I have one of these devices myself. The keyboard/mouse reports its attached to the old style ps2 keyboard/mouse interfaces.
AFAIK they are attached to the NvEc interfaces. One of the people on the mailing list was working on getting these to work on a more recent kernel, but with limited success so far - it isn't as trivial as one might hope.
There is some hope that Toshiba will provide Android 2.2 for the AC100 in the near future which should come, in theory, with a 2.6.32.x kernel, which will hopefully make things a little easier for us WRT nvidia driver compatibility, but Toshiba's interest in supporting the AC100 seems to be diminishing by the day.
Well there was an update to the toshiba update utility this week so with luck that's the prep for 2.2, then someone will need to chase them for that code drop.
Further, the only way to eccelerated graphics on it is using the nvidia closed source tegra xorg driver. Since only 2.6.29 kernel works, only the tegra driver that is compatible with the interface of the kernel module for 2.6.29 works. That driver is sufficiently old that it is based on the xorg ABI from version 1.6.x, i.e. of the F11 vintage.
Works fine with the fbdev on the 2.6.29 kernel using the F-13 and the fbdev X driver. In the 2.6.37 and already pending for the .38 series there's been a lot of tegra drivers make it to the mainline kernel so it will be interesting to see what's missing / remaining / different on the toshiba side of development.
As I said, last I checked the keyboard/mouse didn't work with newer kernels at the moment, and carrying an USB mouse/keyboard isn't really an acceptable solution for a netbook.
Nope, and esp with only one usb port.
Peter
Peter Robinson wrote:
Plus, text mode console switch no longer works one you get into X.
There was, however, some success recently in getting one of acceleration APIs working with mplayer, based on hardware acceleration of the Tegra.
Are you on the AC100 IRC channel?
No (not sure what it is) but I am on #fedora-arm and #fedora-mobility
Try #ac100 on freenode. The people there are quite helpful. Just /ignore the occasional Atom troll(s?). ;)
What're you trying to achieve by recooking f11 xorg server on f13? Maybe there's a different way to come at your overall goal.
I very much doubt it. The machine I'm working on is a Toshiba AC100. The only kernel available for it with working keyboard/mouse support is 2.6.29 provided by Toshiba as part of the open source code they wrote for Android (the machine comes pre-loaded with Android). Unfortunately, Toshiba have in their infinite wisdom decided to put the keyboard and mouse behind proprietary interfaces, rather than USB HID (the machine does have full featured master and slave USB, which makes the decision particularly retarded). The drivers haven't yet been ported to later kernels.
Interesting, I'm looking at this closer as I have one of these devices myself. The keyboard/mouse reports its attached to the old style ps2 keyboard/mouse interfaces.
AFAIK they are attached to the NvEc interfaces. One of the people on the mailing list was working on getting these to work on a more recent kernel, but with limited success so far - it isn't as trivial as one might hope.
There is some hope that Toshiba will provide Android 2.2 for the AC100 in the near future which should come, in theory, with a 2.6.32.x kernel, which will hopefully make things a little easier for us WRT nvidia driver compatibility, but Toshiba's interest in supporting the AC100 seems to be diminishing by the day.
Well there was an update to the toshiba update utility this week so with luck that's the prep for 2.2, then someone will need to chase them for that code drop.
In fairness, they were reasonably OK WRT providing the GPL based code so far. I certainly hope the update will be arriving soon - it would make life a lot easier with a few things.
Further, the only way to eccelerated graphics on it is using the nvidia closed source tegra xorg driver. Since only 2.6.29 kernel works, only the tegra driver that is compatible with the interface of the kernel module for 2.6.29 works. That driver is sufficiently old that it is based on the xorg ABI from version 1.6.x, i.e. of the F11 vintage.
Works fine with the fbdev on the 2.6.29 kernel using the F-13 and the fbdev X driver. In the 2.6.37 and already pending for the .38 series there's been a lot of tegra drivers make it to the mainline kernel so it will be interesting to see what's missing / remaining / different on the toshiba side of development.
As I said, last I checked the keyboard/mouse didn't work with newer kernels at the moment, and carrying an USB mouse/keyboard isn't really an acceptable solution for a netbook.
Nope, and esp with only one usb port.
That's really a negligible problem relative to the rest - a number of keyboards come with a built in USB hub with an extra port.
Gordan
-
Andy Green -
Gordan Bobic -
Henrik Nordström -
omalleys＠msu.edu -
Peter Robinson