Announcement

Collapse
No announcement yet.

Fedora 19 Officially Released

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

  • #11
    nice that its done finally

    2 points:

    1.

    first I run into a bug or better my dad run into it ^^ some pdfs look ok in evience but if you print preview or print there is a blue layer over the document if you print it with a black-white printer it prints a black page... think thats because they updated to a very new cups version?

    Does somebody else have such problems (its not on every pdf like that but some) and I dont think I can upload this pdf files because sensible data is on it.

    yes I know I should report that bug, if I have some time I do it ^^

    2.

    what do you need if you want radeon-vdpau working?

    mesa 9.2 is in fedora so that should be ok.
    I also installed a kernel 3.10 version:

    Code:
    sudo yum install fedora-release-rawhide
    sudo yum update kernel --enablerepo=rawhide
    sudo yum install libva-vdpau-driver libva-utils
    maybe set this env variable:

    Code:
    export VDPAU_DRIVER=r600
    set in a player vdpau as driver did I miss something? havent tested yet ^^

    I post that a bit as question and a bit as manual or start point for others who want that get working

    Comment


    • #12
      Originally posted by BitRot View Post
      Yep, Fedora 19 is really great. I'm so happy I switched to Fedora when it was at 17, never want to go back :-D.

      To everyone at Fedora: Thanks! You are great :-).

      And Gnome Shell is shaping up really great, except gpk-application. That's the sole thing they really could make better.
      It just stalls to much "waiting in queue" without any apparent reason, that's a bit frustating.
      And the search function could be improved. Currently you need to know the name of a package, otherwise you won't find it.

      Though I expect this is going to be better with the hawkeye/libresolv stuff.

      But yeah, Fedora is really cool, and everyone should try it out :-)
      Yeah, we know for sure there are some issues with PK. I believe there's work ongoing to reduce the necessity of exclusive locks as much as possible, and there are a few different plans for providing a better UI for 'installing software' (as opposed to a 'package management' UI, which is more or less what gpk is). Thanks for the feedback!

      Comment


      • #13
        Originally posted by AdamW View Post
        Yeah, we know for sure there are some issues with PK. I believe there's work ongoing to reduce the necessity of exclusive locks as much as possible, and there are a few different plans for providing a better UI for 'installing software' (as opposed to a 'package management' UI, which is more or less what gpk is). Thanks for the feedback!

        Isn't the 0.9.8 branch of package kit all about reducing locks?


        back on topic of the release... "fedup --network 19" ran as expected, minus that it uninstalls the grub theme for some reason, but otherwise a seem less update.


        fresh install also ran as expected, no hiccups. That being said, why no grub theme? I no its not a big deal, just seems odd that 18 had one and 19 is just a black and white menu. Also, as of 2 days ago, encryption on ssd's is still broken but thats a systemd / dracut problem not an installer problem.


        Otherwise a great release, good job fedora team
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #14
          Originally posted by Ericg View Post
          Isn't the 0.9.8 branch of package kit all about reducing locks?
          I don't recall specific versions, but I'm pretty sure there's still fresh work planned.


          Originally posted by Ericg View Post
          back on topic of the release... "fedup --network 19" ran as expected, minus that it uninstalls the grub theme for some reason
          That would be https://bugzilla.redhat.com/show_bug.cgi?id=975800 , we are fixing it right now (it was supposed to be fixed already, but the fix was faulty). 'yum install grub2-starfield-theme' will get the theme back if you want it.

          Originally posted by Ericg View Post
          but otherwise a seem less update.
          Yay!

          Originally posted by Ericg View Post
          fresh install also ran as expected, no hiccups. That being said, why no grub theme? I no its not a big deal, just seems odd that 18 had one and 19 is just a black and white menu.
          So, the fact it gets lost on upgrade is just a bug (see above). But fresh F19 installs do actually use an un-themed, console mode grub2. There's a few reasons for this. Themed graphical grub2 seems to be very slow on some systems, for one thing. We ran into various problems with the modesetting and theming stuff for the releases we were using it; pjones and I and others are now of the general opinion that just using console mode is likely the safest thing to do for the foreseeable future. And theming grub turned out just not to look that great if you take a step back and look at the whole boot process - we had this vision a few releases back that we'd try to keep the entire boot process very visually consistent, with grub, bootsplash and gdm all using the same background and minimizing mode switches, but that's just not all in place at present, so it actually looks more jarring to do a modeswitch / theme for grub2 then suddenly jump back to console mode briefly while plymouth comes up, then modeset again and show an entirely different image (the 'plain blue background with a Fedora logo' bootsplash) than it does to simply use console mode for grub.

          Originally posted by Ericg View Post
          Also, as of 2 days ago, encryption on ssd's is still broken but thats a systemd / dracut problem not an installer problem.
          How do you mean 'broken'? I'm running F19 on my laptop with encrypted LVM and it works fine so far as I can see.

          Originally posted by Ericg View Post
          Otherwise a great release, good job fedora team
          Thanks! Glad you're enjoying it.

          Comment


          • #15
            Originally posted by blackiwid View Post
            what do you need if you want radeon-vdpau working?
            Depends on which VDPAU you want. radeon has both shader-based VDPAU and UVD. If you want the latter, make sure the correct firmware is loaded.

            Originally posted by AdamW View Post
            Yeah, we know for sure there are some issues with PK. I believe there's work ongoing to reduce the necessity of exclusive locks as much as possible, and there are a few different plans for providing a better UI for 'installing software' (as opposed to a 'package management' UI, which is more or less what gpk is). Thanks for the feedback!
            openSUSE has been there, done that. Apparently 12.2 was really bad with PackageKit locks (at the time I just outright uninstalled Apper, so I don't actually have firsthand experience with it), and 12.3 solved that. There's a prompt asking you whether you want to attempt to tell PackageKit to go away if it just so happens to be trying to run when you start YaST. And they also have plans for some "app store", although I couldn't care less (YaST Qt software manager is pretty much already as good as it gets).

            Comment


            • #16
              Originally posted by GreatEmerald View Post
              openSUSE has been there, done that. Apparently 12.2 was really bad with PackageKit locks (at the time I just outright uninstalled Apper, so I don't actually have firsthand experience with it), and 12.3 solved that. There's a prompt asking you whether you want to attempt to tell PackageKit to go away if it just so happens to be trying to run when you start YaST. And they also have plans for some "app store", although I couldn't care less (YaST Qt software manager is pretty much already as good as it gets).
              That is a rather ugly workaround, not a fix. If some other operation has the rpm or yum database locked, then you can 'ask that operation to go away', but it is not always going to be in a cancel-able state, and it's probably more dangerous to go around offering to let people cancel packaging operations willy-nilly just so another packaging operation will start faster.

              Proper fixes would involve making locking less necessary and adjusting tools to need to use it less often and for less time.

              Comment


              • #17
                Great release!!!

                GREAT RELEASE!!!

                I've already tryed it on 2 different laptops and it's looking great with AMD C-60 (Bobcat+R600) and Intel i3 (Sandy Bridge+HD3000). Everything just works! As soon as I get my new laptop I'll install Fedora 19 and hopefully never look back to Ubuntu again! Ubuntu with Gnome just doesn't cut it anymore.

                Thank you devs! You're awesome!

                Comment


                • #18
                  Originally posted by AdamW View Post
                  I don't recall specific versions, but I'm pretty sure there's still fresh work planned.
                  It was a version greater than 0.7.6 (0.8.9 is mainline) because thats the version thats still in Arch's repos and pacman + packagekit still locks all the time (as of 2 months ago when I last used arch) and they couldn't update it because of pacman not supporting the new packagekit API's or something like that.


                  Originally posted by AdamW View Post
                  That would be https://bugzilla.redhat.com/show_bug.cgi?id=975800 , we are fixing it right now (it was supposed to be fixed already, but the fix was faulty). 'yum install grub2-starfield-theme' will get the theme back if you want it.
                  Yeah I knew it was known bug and I had to reinstall the theme when I did a test upgrade like a week ago, I was just mentioning it for anyone else reading

                  Originally posted by AdamW View Post
                  So, the fact it gets lost on upgrade is just a bug (see above). But fresh F19 installs do actually use an un-themed, console mode grub2. There's a few reasons for this. Themed graphical grub2 seems to be very slow on some systems, for one thing. We ran into various problems with the modesetting and theming stuff for the releases we were using it; pjones and I and others are now of the general opinion that just using console mode is likely the safest thing to do for the foreseeable future. And theming grub turned out just not to look that great if you take a step back and look at the whole boot process - we had this vision a few releases back that we'd try to keep the entire boot process very visually consistent, with grub, bootsplash and gdm all using the same background and minimizing mode switches, but that's just not all in place at present, so it actually looks more jarring to do a modeswitch / theme for grub2 then suddenly jump back to console mode briefly while plymouth comes up, then modeset again and show an entirely different image (the 'plain blue background with a Fedora logo' bootsplash) than it does to simply use console mode for grub.
                  Thanks for the clarification Adam I did notice just now that there is a modeswitch on KDE VERY late in the boot-- like way later than should be necessary. Fedora 19 KDE x64, boot looks great, minimal jarring all the way to the login prompt for KDM. Login to KDM, and when KDM switches over to the splash screen (to fade into the desktop) it looks like there's a modeswitch during the KDM -> Splash handoff. Why? For clarification: I say there's a modeswitch happening because its quite obvious and visible that the background of the login screen, and the background of the KDE Splash are at minimum different resolution images because the patterned background visibly jumps and changes its positioning so either the background images aren't the same resolution, oooor there's a modeswitch.

                  Originally posted by AdamW View Post
                  How do you mean 'broken'? I'm running F19 on my laptop with encrypted LVM and it works fine so far as I can see.
                  The last time I checked the bug reports was about a week ago and it was still marked as unsolved, the last time i tried it was like 2 or 3 days ago so MAYBE its been fixed with an update since then.... search "red hat bugzilla dracut crypttab" and you should get some bug reports back. Basically dracut wasn't including /etc/crypttab in the initramfs, LUKS defaults to disallowing discard ( TRIM ) commands, so initramfs was loading, and disallowing discard because there was nothing there telling it otherwise. Initramfs hands off to real root and real root accepts the same boot environment that initramfs had-- disallowing discards and completely ignoring whether or not you had "allow-discards" in /etc/crypttab. You had to manually specify /etc/crypttab to dracut everytime initramfs was generated, OR force LUKS to check real-root for its configuration (loading /etc/crypttab in the process) by removing kernel parameters in grub.

                  Again this was ONLY an issue for LUKS encryption + SSD, if you have a real hard drive you'd never know otherwise. And if you have an SSD you'd never know something was wrong unless you actually started playing around with things-- THEN you'd realize that "TRIM" wans't being passed off to the device, regardless of what /etc/crypttab had. If its been fixed, awesome-- because then I need to reinstal haha, but I can't seem to find the exact same bug report that I followed a link to a few weeks ago, I know LP and some other devs were trying to decide whose fault it was-- systemd, dracut, or LUKS in the comments of the bug report

                  EDIT: Adam, do you know if Fedora 19 is now using the Intel Pstate driver? I noticed that on Fedora 18 even if you had a 3.9.x kernel, Fedora didn't use the Intel P-state driver and instead stuck to OnDemand
                  Last edited by Ericg; 02 July 2013, 05:49 PM.
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #19
                    Originally posted by GreatEmerald View Post
                    Depends on which VDPAU you want. radeon has both shader-based VDPAU and UVD. If you want the latter, make sure the correct firmware is loaded.
                    uvd of course ^^ does shader based even give you anithing that helps at all? ^^ I thought thats nothing usefull.

                    But back to the point... is the right firmware not included int he kernel-3.10-package?

                    Comment


                    • #20
                      Getting bad lockups when using the global search function in Gnome Shell.
                      They last about five seconds, but the entire UI freezes for this time, not just the Activities screen.
                      So I've given this release a miss, for now.

                      Comment

                      Working...
                      X