Am 03.08.2012 16:02, schrieb Michael Schwendt:
On Fri, 03 Aug 2012 12:46:41 +0200, Reindl Harald wrote:
Am 03.08.2012 12:38, schrieb Michael Schwendt:
On Fri, 3 Aug 2012 12:26:43 +0200, Suvayu Ali wrote:
That said, maybe the Fedora repos can keep more than one (say 2-3) versions of the kernel in case some users need to downgrade and don't have it in their cache?
IMO, the community would be served better if they tried packages from updates-testing early and more often.
this does not help anything if there are fatal bugs reported which stops boot like https://bugzilla.redhat.com/show_bug.cgi?id=843826 and ignored in a way that since yesterday kernel 3.5 is in stable repos for F17
- Ticket history reveals that there has been a very quick response
by davej: https://bugzilla.redhat.com/show_activity.cgi?id=843826 So, your bug report has not been ignored, albeit reassigned to a different component without any comment. Hot potatoe...
yes, but xorg-x11-drv-intel-2.20.1-1.fc17.x86_64 works fine with kernels before 3.5 and the hardware i use in the bugreport is not exotic
In retrospect, I cannot tell whether davej should not have submitted 3.5.0-2.fc17 as a test update three days later, knowing that 3.5.0-1.fc17 causes problems. It looks like there is disagreement about the problem you've reported.
but the problem is there
i have TWO of this machines, both doe snot boot until "nomodeset" as kernel-param with 3.5 which results in something like 800x600 resultion on a 25" LED what makes it impossible for me to do anything after some medical operations on my eyes, even no debug
This particular kernel is also an example of a "karma fight" within bodhi, with several testers ignoring the guidelines, unfortunately:
http://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Previously_repor...
They voted +1, compensating previous -1 votes. :-(
and this is unacceptable behavior
if every koji build would give a link to the karma page it would be easier to give bad carma, but as long this is not easy possible it has to be enough that i test a koji-build long before it reaches updates-testing and report a bug to prevent make it to stable
holy hell it is even not possible to give "bad karma" with fedoa-easy-karma in the state i reported the bug
_______________________________________
i had installed on both of my machines any kernel-update since F14 partly ones which never did reach stable from koji
after that having one which does not bot at atll, report it and become the yum-response below shot time after is a bad joke
3.4 is not EOL proven by the 3.4.7 update for F16 in updates-testing i even rolled out to production machines last night after internal tests because it has a security-flag
so the way to go after get a report 3.5.x F17 does not boot on standard intel-hardware the way to go is hold back 3.5 for F167 stable and update F17 to 3.4.7 for now
========================================================================================================================= Package Arch Version Repository Größe ========================================================================================================================= Installieren: kernel x86_64 3.5.0-2.fc17 updates 26 M kernel-devel x86_64 3.5.0-2.fc17 updates 7.5 M Aktualisieren: kernel-headers x86_64 3.5.0-2.fc17 updates 846 k
Vorgangsübersicht ========================================================================================================================= Installieren 2 Packages Upgrade 1 Package
Gesamte Downloadgröße: 34 M Ist dies in Ordnung? [j/N] :n