Announcement

Collapse
No announcement yet.

Public Git Repository For ATI Driver Packaging Scripts?

Collapse
This topic is closed.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Public Git Repository For ATI Driver Packaging Scripts?

    Hello,

    I am trying to gauge the interest of having a publicly accessible git repository for the ATI/AMD fglrx packaging scripts (these are the scripts that allow you to build distribution-specific packages through the --buildpkg command).

    What this means is that you could more easily access new packaging scripts that may not be available at the time the driver ships. For instance, with 8.42 and the Ubuntu packaging script bug that's causing havoc for x86_64 users. Through a public git repo you could easily fetch the new scripts. It would also make it easier for you to fetch kernel patches if they appear with a script after the fact. You could also get updates for packaging scripts in older drivers by checking out of the respective branch.

    By writing a simple script, you could also create a pretty seamless experience to use these updated packages. It could also potentially get more distributions to create and submit fglrx packaging scripts.

    The ATI packaging script maintainers would be committing their new scripts to this repository and in turn its where AMD would be pulling from for their new releases. However, this won't be done if there is no end-user interest.

    So who would like to see a public git repo for the fglrx scripts?

  • Michael
    replied
    Meet Phorogit: http://www.phoronix.com/forums/showt...8552#post18552

    Leave a comment:


  • Michael
    replied
    As of tonight/this morning, this git repository is now a reality... It will be rolled out to the public with new utilities/resources in the near future.

    Leave a comment:


  • Michael
    replied
    Bump, coming soon.

    Leave a comment:


  • Michael
    replied
    Originally posted by Bigon View Post
    any url for the repository?

    It hasn't yet been established.

    Leave a comment:


  • Bigon
    replied
    any url for the repository?

    Leave a comment:


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

    Leave a comment:


  • Porter
    replied
    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.

    Leave a comment:


  • Uchikoma
    replied
    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?

    Leave a comment:


  • givemesugarr
    replied
    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.

    Leave a comment:

Working...
X