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 Larabel
    http://www.michaellarabel.com/

  • #2
    Sounds like an excellent idea.

    Comment


    • #3
      It can't hurt, it can only do good so I say go for it.

      Comment


      • #4
        It would be enough already to just post updated scripts on the forums like Phoronix, you've posted the new Ubuntu/Debian scripts somewhere in here, but I mean you don't find it if you don't know where it is.

        My opinion.

        Comment


        • #5
          So who would like to see a public git repo for the fglrx scripts?
          wrong question - everybody would.

          So who would like to help create install scripts for submission to a public git repo for the fglrx scripts?
          good question

          Comment


          • #6
            I would welcome a public repository.

            Comment


            • #7
              bump for great idea

              Comment


              • #8
                yes, please. I would love a repository. I have not been able to create packages for 8.41 and 8.42 on Mandriva because the scripts that exist don't work. I am basically stuck at 8.40, which isn't necessarily bad, but I want to use new drivers.

                Chris

                Comment


                • #9
                  Originally posted by Michael View Post
                  So who would like to see a public git repo for the fglrx scripts?
                  /me raises his hand...

                  Comment


                  • #10
                    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


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

                      Comment


                      • #12
                        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


                        • #13
                          Originally posted by Kano View Post
                          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.
                          Michael Larabel
                          http://www.michaellarabel.com/

                          Comment


                          • #14
                            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; 10-26-2007, 06:07 PM.

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X