Page 2 of 9 FirstFirst 1234 ... LastLast
Results 11 to 20 of 81

Thread: Fedora 19 Officially Released

  1. #11
    Join Date
    Jul 2008
    Posts
    845

    Default

    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

  2. #12

    Default

    Quote 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!

  3. #13
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,900

    Default

    Quote 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

  4. #14

    Default

    Quote 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.


    Quote 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.

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

    Quote 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.

    Quote 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.

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

  5. #15
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,562

    Default

    Quote 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.

    Quote 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).

  6. #16

    Default

    Quote 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.

  7. #17
    Join Date
    Jul 2009
    Location
    São Paulo, Brazil
    Posts
    73

    Default 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!

  8. #18
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,900

    Default

    Quote 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.


    Quote 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

    Quote 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.

    Quote 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; 07-02-2013 at 05:49 PM.

  9. #19
    Join Date
    Jul 2008
    Posts
    845

    Default

    Quote 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?

  10. #20
    Join Date
    Jan 2013
    Posts
    525

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •