Announcement

Collapse
No announcement yet.

Fedora 40 Cleared To Ship AMD ROCm 6, Packages May Reintroduce KDE X11 Support

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

  • #11
    Originally posted by ahrs View Post

    It makes perfect sense to me too. If there's an able and willing maintainer then it makes sense to me that it's allowed in the main repositories, as long as it's that maintainer that's responsible for it and not the KDE SIG (which has already decided on going all-in on Wayland). From the careful wording here it seems to me that that's the case.
    I don't agree with that assessment. If Fedora Actual and Fedora SIGs want to do things that one way but someone else wants to maintain something that does things in the opposite of Fedora's goals, then that person should maintain their stuff outside of the main repositories. Perhaps they even need to create a Legacy X11 COPR because the X11 issue will affect more than just people wanting to use KDE X11 sessions.

    mrg666
    In the near future when KDE and other DEs implement new features or fixes, they will start neglecting X11 eventually since some of those implementations will not be feasible in X11 as X11 is a dead platform. Then, there will be a technical reason to drop X11 once for all.
    What you said is exactly why they shouldn't put KDE's X11 session into the repositories. Eventually it won't be very feasible to maintain both (Wayland and X11) together so it would make the most sense to start on Legacy COPRs now instead of later.

    Comment


    • #12
      Originally posted by slagiewka View Post
      This is ridiculous. The push for X11 reintroduction has made the KDE SIG members really annoyed, to say the least.

      If Fedora KDE stops being a great KDE flagship, that it indubitably is, I will point to this moment as the beginning.
      They're doing this because it makes the Fedora KDE edition a great flagship distribution. KDE Wayland is the future of KDE. It's real, and it's spectacular.

      Comment


      • #13
        Arch Linux already provide ROCm 6, why they need to release Fedora 40 to release ROCm 6? Over years I slowly less and less understand to Fedora distro. They can just build ROCm 6 and push into the repository and done.

        ROCm 6 is already stable, AMD released at 15.12.2023 https://github.com/ROCm/ROCm/releases/tag/rocm-6.0.0 so what more they need to hear? They don't believe to statement "stable"?

        Where is the problem? I can't see problem, could anyone show me where they have problem?

        Comment


        • #14
          Originally posted by slagiewka View Post
          This is ridiculous. The push for X11 reintroduction has made the KDE SIG members really annoyed, to say the least.

          If Fedora KDE stops being a great KDE flagship, that it indubitably is, I will point to this moment as the beginning.
          i don't think it gonna chage to much, it isn't even intalled by default

          Comment


          • #15
            Originally posted by SoongVilda View Post
            Arch Linux already provide ROCm 6, why they need to release Fedora 40 to release ROCm 6? Over years I slowly less and less understand to Fedora distro. They can just build ROCm 6 and push into the repository and done.
            Thats the difference between a rolling distro (Arch/Gentoo) and normal distros (nearly everything else). Normal distros only ship security updates. The only exclusion is the Browser.

            Also, wasn't ROCm6 not 100% backwards compatible? At least yesterday I read on the ZLuda documentation it wasn't compatible with ROCm 6. Thats why stable distros don't ship major updates...

            Comment


            • #16
              Originally posted by Mathias View Post
              I wonder how that pytorch package works. Does it come with CUDA acceleration (default) or CPU only? Or can I even install it with Rocm? I wasted hours getting pytorch-Rocm working on Fedora with my Navi1 card and it still doesn't work... Would be awesome if DNF could solve that for me. But given that pytorch only supports ROCm 5.7 and F40 will package 6.0, I won't hold my breath.
              It's Python, you should be thankful wasting mere hours for dependency issues and crap like that. You should be worried when it becomes weeks.

              Comment


              • #17
                BTW I love this comment from the issue tracker:
                I find it a bit uneasy that we tend to rationalize the removals with "nobody wants to maintain this" and when there is somebody who wants to do exactly that, we don't let them.
                BECAUSE IT'S SO TRUE, same with "patches welcome" but they in fact get rejected because they refuse.

                It's just a scapegoat argument from clowns.

                Comment


                • #18
                  Originally posted by SoongVilda View Post
                  Arch Linux already provide ROCm 6, why they need to release Fedora 40 to release ROCm 6? Over years I slowly less and less understand to Fedora distro. They can just build ROCm 6 and push into the repository and done.

                  ROCm 6 is already stable, AMD released at 15.12.2023 https://github.com/ROCm/ROCm/releases/tag/rocm-6.0.0 so what more they need to hear? They don't believe to statement "stable"?

                  Where is the problem? I can't see problem, could anyone show me where they have problem?
                  You are greatly underestimating the effort required to properly package it. Fedora unlike Arch requires packages to be built in a clean chroot with no network access ie) everything must be self contained and specify the full build time dependencies cleanly. It must follow the strict licensing requirements. Ideally it should be support all the architectures they support (not just x86_64) and it must play well with other things within the distribution (actually distributions since they are packaging it for EPEL as well). This is hardly a trivial job.

                  https://fedoraproject.org/wiki/SIGs/...Cm_(OpenCL/HIP) gives some indications as to what's going on. I see closed source items, non portable code, forks of existing software, specific versioned dependencies on LLVM etc in that list. You can throw together something from upstream easily within a few minutes but that's not what a distribution should do. Doing it correctly takes time.

                  Comment


                  • #19
                    This is just stupid. KDE guys want to get rid of X, desperately. Now they get hijacked by "volunteers" who want to patch X back in.

                    This is so bad, especially for KDE as bugs in the X part now land on KDEs desks, despite them wanting to have no affilication with X stuff anymore.

                    The only clean solution I see is have those volunteers fork KDE, name it whatever different and sail in their own direction so KDE can rip out the remnants of X.

                    Comment


                    • #20
                      Originally posted by reba View Post
                      This is just stupid. KDE guys want to get rid of X, desperately. Now they get hijacked by "volunteers" who want to patch X back in.

                      This is so bad, especially for KDE as bugs in the X part now land on KDEs desks, despite them wanting to have no affilication with X stuff anymore.

                      The only clean solution I see is have those volunteers fork KDE, name it whatever different and sail in their own direction so KDE can rip out the remnants of X.
                      Or depreciate X11 on Plasma 6 and let it live on in the last Plasma 5 LTS release. As is, there's enough of a feature difference between X11 and Wayland with Plasma 6 that there really shouldn't be an X11 option period.

                      Comment

                      Working...
                      X