I agree. A public git would be awesome and simplify for alot of people.
Announcement
Collapse
No announcement yet.
Public Git Repository For ATI Driver Packaging Scripts?
Collapse
This topic is closed.
X
X
-
As you need adopted scripts for the NEXT package a current git would be useless - maybe for hotfixes. But to check the scripts against the NEXT driver you need this one first - I would vote for public beta drivers to find those errors faster. Usually the scripts break if something unexpected changes what only ATI knows, but the maintainers don't know. Just like the latest 64 bit packageing change which came unexpected as 32 bit was working. I guess 64 bit was not tested well enough as the same error is in the Fedora script for example.
Comment
-
Originally posted by Kano View PostAs you need adopted scripts for the NEXT package a current git would be useless - maybe for hotfixes. But to check the scripts against the NEXT driver you need this one first - I would vote for public beta drivers to find those errors faster. Usually the scripts break if something unexpected changes what only ATI knows, but the maintainers don't know. Just like the latest 64 bit packageing change which came unexpected as 32 bit was working. I guess 64 bit was not tested well enough as the same error is in the Fedora script for example.Michael Larabel
https://www.michaellarabel.com/
Comment
-
Well that does not fix the real issue. That's usally always a too late fix. I patched for example Xserver 1.4 support in the Ubuntu scripts (same detection in the Debian ones) and these worked with old driver package. Basically I had even a 1 line fix for the check.sh, but ATI likes to do it more complicated
check.sh (against 8.41.7):
- x_ver_num=`${x_bin} -version 2>&1 | grep 'X Window System Version [0-9]\.' | sed -e 's/^.*X Window System Version //' | cut -d' ' -f1`
+ x_ver_num=`${x_bin} -version 2>&1 | grep -E '(X Window System Version|X.Org X Server) [0-9]\.' | sed -e 's/^.*X Window System Version //;s/^.*X.Org X Server //' | cut -d' ' -f1`
And for the Ubuntu/Debian ones (as reported to Septor) - can be used for 8.41.7 - you just need still -ignoreABI with older drivers:
sed -i 's#"^(XFree86|X Window System) Version " | sed -e "s/^X Window System /X.Org /"#"^(XFree86|X Window System|X.Org X) (Version|Server) " | sed -e "s/^X Window System /X.Org /;s/Server //"#' packages/Ubuntu/module/rules packages/Ubuntu/dists/*/rules packages/Debian/dists/*/rule
That's at least used now. To fix ati errors seems to be just one rule: fix it yourself or nobody else does...Last edited by Kano; 26 October 2007, 06:07 PM.
Comment
-
the idea is not bad. but still, the fglrx is still closed and it is difficult to manitain a closed source blob. the best thing should be instead an agreement of distro developers with ati for a greater packaging support. in this way you can be as much as possible certain that the driver would in some way build and install when it's out. so, in my opinion the solution is a wider collaboration with ati itself and with xorg and kernel devs. that should make the fglrx better. and, in my opinion, now that the driver has an initial support for a variety of features, now ati should concentrate on one thing: stability and bugfixing. i wouldn't want new features, but i'd want to fix the issues that are still there (and for what i've read here there are still a lot of 'em). the speed is now comparable with nvidia's one and so the driver, in my opinion, has concluded its first phase. from now on ati should look at xorg dev's schedule, at kernel.org ones and try to adjust its schedule on that releases. so if the new xorg would be programmed for december (i don't know if the dates are these since i didn't take a look at the schedule and i use the dates as examples) according to its dev cycle should start implementing its drivers for december to leave open the introduction of the support or to release the dec driver before the new xorg, so that in january the support could be added. the same works with the kernel. as these projects don't change the bases from one day to another it can be said that it wouldn't be very difficult to start writing the driver on that basis and do some updates when it's necessary. and working on a closer collaboration with xorg and kernel devs should help in this optics.
but again, this is only a suggestion from am average linux user that would like to see this happen.
as for
Michael, that's great idea.
Btw. could you ask AMD/ATI if they could release for public beta releases if their drivers for public to catch most bugs before they will release final builds?
Comment
-
I'm hold the train of thought that: the more bug fixes caught and fixed, the better. Even if it is at the end of the month.
I also support the idea of having a public repo for packing scripts.
Finally, look at it this way givemesugarr. If they release on the last day of the month consistently, it'll even out so we wait exactly one month.
a) Predictability in the release cycle
b) It's still 1 month
c) Did I mention, hopefully more bugs caught and fixed? Like the SLUB + fglrx = broken suspend issue?
Comment
Comment