Public Git Repository For ATI Driver Packaging Scripts?

[peol]

I agree. A public git would be awesome and simplify for alot of people.

[Kano]

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.

[Michael]

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.

Actually, the NDA packaging maintainers would be comitting their changes as they occur, for the next package, to mainline and once the driver is publicly released it would then be branched. So people in the community would actually know up front once the NDA maintainers are comitting changes, what is being changed.

[Kano]

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...

[givemesugarr]

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?

i think that this is a bad idea. if you continue to catch out bugs (you'll surely have to) the driver would always be released on the 30 or 31 of the month. so it's better to just fix the main bugs that make the driver unusable and try to restrict in some way the minor bugs to correct them in the following releases. you surely know that a lot of people report duplicate bugs corrected or bugs that aren't bugs but misconfigurations and the small dev group would have to read a lot of futile stuff while they can correct the important one. maybe the option would be: release of a public beta on the 1st monday of the month, 7 days of moderated bug reporting (for example there should be one or 2 people who read the bug reports and forward the ones they think important to ati devs), then 7-10 days of important bug-fixing and then the release in the second half of the month. this would concentrate the ati devs on the writing of the driver but would need some people to do the community filtering.

[Uchikoma]

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?

[Porter]

This is a great idea. An even better idea would be for ATI to make available separate .rpm and .deb files as part of their driver release for each version.

[louisvd]

What a fantastic idea! Anything that could make installing these drivers easier gets my vote 100%. (My success rate has been abysmal thus far!)

[Bigon]

any url for the repository?

[Michael]

any url for the repository?

It hasn't yet been established.