Announcement

Collapse
No announcement yet.

Fedora 28 Is Now Available For Download

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

  • Fedora 28 Is Now Available For Download

    Phoronix: Fedora 28 Is Now Available For Download

    Fedora 28 is now officially out, the first on-time release in many years. This is a great update with GNOME 3.28 on Wayland on the desktop side while also a lot to get excited about on the server-side too...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    For the first time, we’re making it easy for users to enable certain third-party software sources, including proprietary Nvidia drivers.
    I guess next step would be to make them default

    Comment


    • #3
      Originally posted by phoronix View Post
      Fedora 28 is now officially out, the first on-time release in many years.
      Don't get me wrong. I really like Fedora, since it's my main System that I use for many years.

      I'm not wondering that this is a on-time release, because right after the Fedora 28 Beta got released, many hundrets of packages had still *-fc27-* labeled on them (means, they have still been based on Fedora 27). Even essential core packages that the base system depends on.

      I was quite irritated whether I was testing a Fedora 28 Beta or an extended Fedora 27. Most of these packages got re-build and re-based for Fedora 28 around 1-2 weeks ago (from today).

      It would have been nice, if all packages got re-based and re-build before releasing Fedora 28 Beta. So these newly build and re-based packages could have been tested.

      I consider this release of Fedora 28 (from today) what - by my terminology - should have been the real Beta of Fedora 28.

      Comment


      • #4
        Not every package needs rebuilding, if there were no changes to the packages or underlying dependencies, there is no need for a rebuild.

        Comment


        • #5
          Originally posted by srakitnican View Post
          Not every package needs rebuilding, if there were no changes to the packages or underlying dependencies, there is no need for a rebuild.
          My information is based on own observation of the case.

          Of course you are right in saying what you said. But then. This is the very first time that I remember (maybe I never paid close attention to it before) that I had a Fedora Beta Release that had so many "old" packages. You might understand, that querying the rpm database on my installations caught me in the situation that I really believed that something broke on my system during updating to the Fedora Beta Release. I counted quite an amount of packages that were build for Fedora 27. This was around 1-2 Weeks after Fedora 28 Beta got released.

          I observed the files on a local Fedora mirror and confirmed that the files were still for Fedora 27 but used for Fedora 28. I even observed a bunch of changelogs on Fedora's own websites to verify the mass rebuild tags that got applied on them (from February this year). This usually means that the packages should already have been rebuild - but yet missing.

          Later on I read that page:


          801 failed to build packages after the Fedora 28 Beta release


          I recall that above list was longer and updated meanwhile (while the date was still kept old).

          4484 packages to be build for the Fedora 28 Beta release from mid February


          Even if the API has not changed, but other things might (even if it's just using a newer compiler), different library, orphaned stuff etc. Everything that may affect the resulting final binary. That should all have been solved before a Beta announcement.

          I remember that some packages had older versions in the repos, while the changelogs had a mass rebuild flag on them (for never versions) but these packages never made it into the Beta.

          So what we were testing was Fedora 27 packages (with older software (not just a version bump)) on Fedora 28 Beta. The right packages have shown up few weeks later and now made it into the final Fedora 28 Release. So basicly we were not really able to test the right packages within the Beta phase, to report issues and bugs for exactly these packages. Infact we were testing packages for Fedora 27.

          Example:

          Midnight Commander was still at 4.8.19-7 within the repos for Fedora 28 (but named fc27).

          In the Changelogs of this site:

          The branch for the mass rebuild happened 3 months before (for the 4.8.20 release).


          Within the repos, still Midnight Commander 4.8.19-7 fc27!

          mc-4.8.19-7.fc27.x86_64.rpm

          This is just one example of a few that I found on my small Fedora Workstation!

          Even if it's just a small version jump (4.8.19 to 4.8.20) but it was tagged for mass rebuild. 4.8.20 had a bunch of updated that I really liked to test within the Fedora 28 Beta phase (and report issues for it in case it's necessary) but I had to test a package for Fedora 27. This observation is also valid for various other packages, that I made.

          Isn't the reason for a Beta Release to test the thing as whole for that packages that are tagged for it ? So people can test if command line arguments have changed, or that the particular - intended to be included - version operates as expected ? So in case of errors that they can be reported and fixed *before* the final Release steps out of the door ?

          I hope I can help with my thoughts here, so these *ideas* may be considered for upcoming versions of Fedora.

          But nonetheless. Thanks again for Fedora and all the participants that made this version came out. I am more than satisfied.

          Comment


          • #6
            Well, games still stutter on Gnome Wayland, one more release to use with Gnome w/ x.org.

            Update process worked flawlessly.

            Comment


            • #7
              doesn't accept passwd. changed but no luck, why?
              also nvidia install look prehistoric. nobody to create a install script?

              Comment


              • #8
                Originally posted by srakitnican View Post
                Not every package needs rebuilding, if there were no changes to the packages or underlying dependencies, there is no need for a rebuild.
                Edzachary. I'm on F27 and use a bunch of 3rd party repos for other stuff. On some of these repos, the F27 path is just a symlink to the ../F26 folder. Makes sense when all the dependencies are at the same version, no need for a rebuild. Everything works perfectly so no complaints here. I imagine the need for a rebuild will arise once F26 support stops, and F27 continues to get upgrades.
                Last edited by torsionbar28; 01 May 2018, 02:38 PM.

                Comment


                • #9
                  Originally posted by torsionbar28 View Post
                  Makes sense when all the dependencies are at the same version, no need for a rebuild. Everything works perfectly so no complaints here.
                  That's not the point! You and srakitnican are missing my point!

                  Fedora uses autmatic scripts and services to provide automatic updates for packages. This is (from my observations) also valid for automate mass rebuilding, branching and tagging of packages.

                  When I observe the following thing:

                  For example "mc--4.8.20-2" that got tagged for mass rebuild for Fedora 28 release, then I would expect an automated process start building and delivering the package. At least the change the changelog by proving a version increment and information that this package has been signaled for building within Fedora 28.

                  But the package did not show up. All this happened during the transition phase where Fedora received some infrastructure changes. So branching, taging and auto-updating etc. overlapped with the infrastructure change.

                  This lead to the point, that a not coutable amount of packages got not updated for Fedora 28. Please feel free to correct me if I am wrong.

                  The point here is, that a lot of packages received the "mass rebuild" change entry in the changelogs of the packages, where the packages have never shown up in the Repositories.

                  It doesn't matter whether there is a real need for an update or not. Whether this is a 3rd party repo or not. At least from my observations, this has never been an issue for Fedora and their automate processes.

                  So basicly: From the changelog entries of the mass rebuild, Midnight Commander 4.8.20 should already have been build for Fedora 28 and placed in the repos. Unfortunately we are still dealing with 4.8.19 from Fedora 27. There is a version jump from 4.8.19 to 4.8.20 with a huge amount of fixes and changes, that didn't made it into the Fedora 28 Beta and now with Fedora 28 Release. so we were not able to test a package, that has been marked for Fedora 28. Neither for the Beta nor for the final Release.

                  If you (from todays update):

                  cd /var/cache/dnf/fedora-f21308f6293b3270/repodata/
                  zcat *filelists.xml.gz | grep "<version.*fc27" | wc -l

                  You get 3481 (Fedora 27 related packages) reported back.

                  rpm -qa | grep "fc27" | wc -l

                  Reports 8 Packages on my system:

                  rpm -qa | grep "fc27" | sort
                  libappindicator-gtk3-12.10.0-16.fc27.x86_64
                  libwnck-2.31.0-9.fc27.x86_64
                  libwnck-devel-2.31.0-9.fc27.x86_64
                  mdadm-4.0-5.fc27.x86_64
                  ocaml-srpm-macros-5-2.fc27.noarch
                  openblas-srpm-macros-2-2.fc27.noarch
                  openjade-1.3.2-55.fc27.x86_64
                  pv-1.6.6-3.fc27.x86_64

                  Looking at llibwnck-2.31.0-9.fc27.x86_64, ibwnck-devel-2.31.0-9.fc27.x86_64 for example:



                  Then there should be a libwnck-2.31.0-10.fc28.x86_64 and libwnck-2.31.0-10.fc28.x86_64 Package. At least that's what I am lead to believe... Otherwise the entire entry, change and changelog entry within the *.spec file doesn't make any sense. Same applies for openjade etc.. Even if - in this context - it's just a "release" tag bump. So no particular change within the Package.

                  Although I still would have expected to compile my stuff against an *fc28* Package rather than an *fc27* Package.

                  I hope I was able to make myself more clear. In case I am missing something or lack understanding of the release and mass rebuild process, then please feel free and correct me.

                  Comment


                  • #10
                    It seems an excellent release.

                    Comment

                    Working...
                    X