Announcement

Collapse
No announcement yet.

Mesa, llvm & kernel after pontostroy

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by debianxfce View Post
    See kernel bugzilla, most of the amdgpu driver bugs are for a stock kernel. Only very few for this:
    https://cgit.freedesktop.org/~agd5f/...-next-4.12-wip
    Bugs for these are on freenode IRC network channel #radeon or maybe on amd-gfx maillist...

    No one file nor should file regular bugs against that

    Comment


    • #22
      Originally posted by debianxfce View Post

      you are not interested of latest software and hardware.
      Neither is average Joe, he is also not always up to speed

      Neither is OP of this thread who have r600 class hardware and don't want or need latest everything, he already said that to you but your ignorance is so high that you don't even see neither questions nor answers nor even what OS he use, purely nothing

      You can only help people if your brain is working and not just with copy>paste same links all the time even without particular reason
      Last edited by dungeon; 02 March 2017, 03:29 AM.

      Comment


      • #23
        This post went a little out of hand...
        I'll to submit a bug report, but I think it's going to look like a bit vague.

        Comment


        • #24
          Originally posted by debianxfce View Post

          Average Linux Joes do follow new hardware development. This site is a proof and many of them buy new hardware and uses latest drivers. Mesa, amdgpu and radeon kernel drivers develops all the time and bugs are fixed fast. So it is better to use latest software even with old hardware and you are wrong as always.
          I am not wrong, people should be on bugzilla in case of problem it is that simple. Where compiling, patching, bisecting, debugging, making traces, etc... are usual basic knowledge requirement to go anywhere, regardless what versions they were use normally.

          Problem is average user Joe does not usually do "compiling, patching, bisecting, debugging, making traces, etc..." it is easy to find bugs and regression if you can do these, but that is not easy to learn for average user Joe, not not say for average newbie Joe, most are just not ready to do that, blah. blah

          Also it is wrong to push people they must do that and learn everything you might know, you might ask if he can then fine, if he can't than again fine
          Last edited by dungeon; 02 March 2017, 09:44 PM.

          Comment


          • #25
            Originally posted by debianxfce View Post
            When you are using rolling release software, you automatically do bisecting.
            How is that even possible Rolling Relase is distro model as oppose to Fixed Release, both models mostly uses releases of software. Bisecting is something else, tipically used to found regression bugs (old work and new doesn't scenario)... that can be in release of software or in development tree. Also developers do that, but sometimes some users. Could be mostly automatic, but might not be might be better to say semi-automatic or manual or even guessed by eye if you are experienced

            But you just can't push nor expect *any* user to do that especially those who does not even compile anything in the first place - majority have no idea about that and that is fine - if they don't show knowledge or interests to learn, you just don't pushing things
            Last edited by dungeon; 03 March 2017, 04:20 AM.

            Comment


            • #26
              Originally posted by debianxfce View Post
              Temporary breakage does not matter, you have previous working kernel in the Grub menu. More disappointed you will be when your distribution kernel does not work.
              I think this is the key distinction - temporary breakage does not matter for *you* (or for anyone with similar experience/knowledge working with Linux) because you can recognize it based on previous experience and move back to a working kernel, but it can matter a lot for someone who is trying to get their system working for the first time. Having them pick up a random point on a development tree can make things worse for them not better.

              Nobody is disagreeing with you about most of the cases where you point people to staging branches - but a few of them (particularly people new to Linux) do seem inappropriate to most of the folks here.
              Test signature

              Comment


              • #27
                Originally posted by bridgman View Post
                Nobody is disagreeing with you about most of the cases where you point people to staging branches -
                This is always wrong when using this trees for itself on stable systems. It's ok using this trees on testing systems, cause it will test THIS code. It's mostly ok using the code from this trees together with stable trees on stable systems if you want the newest driver code and you're really knowing what you do. But it's never ok using these unmaintained snapshots on any other than pure test systems.

                Comment


                • #28
                  Originally posted by boffo View Post
                  This post went a little out of hand...
                  I'll to submit a bug report, but I think it's going to look like a bit vague.
                  Back to topic, as long as you answer the following questions of the maintainers, even a bugreport that's a bit vague first will help.

                  Comment


                  • #29
                    Originally posted by boffo View Post

                    I'm using the R600 driver. I don't need the latest software. The stable version is fine. It's that the official OpenSuse Mesa is not stable in gaming and it's slow. I don't know why but the I didn't have this issues with the Mesa compiled by Pontostroy, unfortunately Pontostroy doesn't compile new versions anymore.
                    not stable? Are you on Tumbleweed or Leap?
                    And where was the announcement that pontostroy stops his repo? It is still there, but I see that it was not updated since february 11th.

                    EDIT: I just found the anouncement: http://www.gearsongallium.com/
                    NO MORE my LIVECD or pontostroy:X11 updates
                    Posted by pontostroy on 2017/02/15 7 comments | 676 views
                    Now I live far away from my country, i uploded my configs, git repos to this VPS, and hoped to do all work from VPS, but few days ago my hoster lost all the files for the last two months.
                    P.S. Thanks to everyone who supported me
                    P.P.S Do not use dmehosting.com

                    Last edited by tomtomme; 07 March 2017, 02:56 AM.

                    Comment


                    • #30
                      Originally posted by dungeon View Post

                      If pontostroy repo was more stable and faster, look at his packages what/if he does so specific and inspect difference:



                      Easiest answer from me i guess, but that is the only way i guess
                      the difference is gallium-nine and git. tumbleweed rides stable releases (currently mesa 17 llvm 3.9)

                      Comment

                      Working...
                      X