On Wed, Sep 8, 2010 at 8:25 PM, Rodd Clarkson r...@clarkson.id.au wrote:
I've already tried this kernel and doesn't fix things for me.
I'm now having (what I suspect are) the same suspend issues in both f13 and
f14.
It's being tracked here:
On 09/12/2010 05:00 AM, Adam Williamson wrote:
Actually, I suspect it's a result of this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=630490
until the fix for that gets pushed, in F14, if you use systemd and
'disable' NetworkManager.service, NM will still get started up by bus
On Fri, 2010-09-10 at 23:55 +0530, Rahul Sundaram wrote:
On Fri, Sep 10, 2010 at 10:03 AM, Bruno Wolff III wrote:
On Thu, Sep 09, 2010 at 16:23:12 -0500,
John Morris jmor...@beau.org wrote:
On Thu, 2010-09-09 at 00:14 -0500, Bruno Wolff III wrote:
On
So now I lost the only kernel package where everything worked. And of
course Fedora doesn't have it anymore. You can pick the original
package or the current update. Triple crap! If anyone has a pointer
to kernel-2.6.31.12-174.222.x86_64.rpm I'd really appreciate it!
Google,
On Thu, 2010-09-09 at 00:14 -0500, Bruno Wolff III wrote:
On Wed, Sep 08, 2010 at 23:18:00 -0500,
John Morris jmor...@beau.org wrote:
And of course Network-Manager isn't optional anymore. Oh no, you can't
You can still run the network service. You use chkconfig to turn it on.
If you
On Thu, Sep 09, 2010 at 04:23:12PM -0500, John Morris wrote:
On Thu, 2010-09-09 at 00:14 -0500, Bruno Wolff III wrote:
On Wed, Sep 08, 2010 at 23:18:00 -0500,
John Morris jmor...@beau.org wrote:
And of course Network-Manager isn't optional anymore. Oh no, you can't
You can
On Tue, Sep 7, 2010 at 10:56 PM, Jan Wildeboer jwild...@redhat.com wrote:
On 09/07/2010 02:45 PM, drago01 wrote:
http://koji.fedoraproject.org/koji/buildinfo?buildID=193772
This one addresses some suspend issues so it is worth testing.
Bingo! Suspend/resume now works again. (Still have
On Wed, 2010-09-08 at 23:18 -0500, John Morris wrote:
Sorry everyone, time to vent.
Bah. This is why I just blocked kernel updates in the first place.
Tried updating now things are worse due to a bad combination of
Fedora policy multiplied by my own stupidity. I KNEW you were supposed
On Wed, 08 Sep 2010 23:18:00 -0500
John Morris jmor...@beau.org wrote:
On Mon, 2010-09-06 at 23:05 -0400, Chuck Ebbert wrote:
On Thu, 02 Sep 2010 18:23:01 -0500
John Morris jmor...@beau.org wrote:
In my case I reported #573135 back in March and stopped taking
kernel updates. In
On Tue, Sep 7, 2010 at 1:20 PM, Rodd Clarkson r...@clarkson.id.au wrote:
, there's no way in hell that anything
with ~10,000 unreviewed patches
Err they aren't unreviewed as upstream did review them, it just does
not make sense to review every single patch downstream too (besides
obviously
On Sat, 2010-09-04 at 23:10 -0400, Bill Davidsen wrote:
If they don't have time to look at everything, then maybe they should stop
shipping kernels they haven't looked at! Really, people who needed 2.6.34
could
snip rant
this is not on topic for this list. please participate in the
On Sun, 2010-09-05 at 13:25 -0400, Jan Wildeboer wrote:
In my case (F13, x86_64 on a Lenovo X200) the .34 kernel made suspend fail.
On laptops I think working suspend/resume should be blocker for release. It
It isn't. We can't possibly guarantee suspend/resume will work on all
laptops in
On 09/07/2010 02:32 PM, Adam Williamson wrote:
It isn't. We can't possibly guarantee suspend/resume will work on all
laptops in anything like a reasonable timeframe. if we set this as a
release criterion, we would likely never release. So we don't.
Understood. It is however a royal PITA ;-)
On Tue, Sep 7, 2010 at 2:36 PM, Jan Wildeboer jwild...@redhat.com wrote:
On 09/07/2010 02:32 PM, Adam Williamson wrote:
It isn't. We can't possibly guarantee suspend/resume will work on all
laptops in anything like a reasonable timeframe. if we set this as a
release criterion, we would likely
On Tue, 2010-09-07 at 14:36 +0200, Jan Wildeboer wrote:
On 09/07/2010 02:32 PM, Adam Williamson wrote:
It isn't. We can't possibly guarantee suspend/resume will work on all
laptops in anything like a reasonable timeframe. if we set this as a
release criterion, we would likely never
In my case (F13, x86_64 on a Lenovo X200) the .34 kernel made suspend fail.
On laptops I think working suspend/resume should be blocker for release. It
worked before, hence it is a regression.
F13 was released with a .33 kernel, therefore the question of blocking
the F13 release for this reason
On Thu, 2 Sep 2010 15:19:04 +1000
Rodd Clarkson r...@clarkson.id.au wrote:
Might I ask what great good has come from this?
Here's a list of bugs that were fixed by the 2.6.34 update and not by
any specific fixes added by Fedora:
611123 - 2.6.33.5-124 on Dell E521 does not work with OCZ
On Thu, 02 Sep 2010 18:23:01 -0500
John Morris jmor...@beau.org wrote:
In my case I reported #573135 back in March and stopped taking kernel
updates. In another month or so I'll boot a live USB stick of F14 and
see if the bug was fixed and just didn't get closed. Then it is either
suck it up
On Sat, 04 Sep 2010 23:10:11 -0400
Bill Davidsen david...@tmr.com wrote:
If they don't have time to look at everything, then maybe they should stop
shipping kernels they haven't looked at! Really, people who needed 2.6.34
could
pull it from updates-untested and the rest of us could have
Bill Davidsen david...@tmr.com wrote:
If they don't have time to look at everything, then maybe they should stop
shipping kernels they haven't looked at! Really, people who needed 2.6.34
could
pull it from updates-untested and the rest of us could have working systems.
Back in the FC3-4-5-6
In my case (F13, x86_64 on a Lenovo X200) the .34 kernel made suspend fail.
On laptops I think working suspend/resume should be blocker for release. It
worked before, hence it is a regression.
Note that I am not running rawhide. Just plain F13 with its support promise.
Suspend/Resume failing
Adam Williamson wrote:
On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote:
It is however, perfectly reasonable to expect that having tried a
kernel at the request of a fedora developer on fedora-test-list and
then having filed a bug against said kernel reporting problems, that
someone
- Original Message
From: Bill Davidsen david...@tmr.com
To: For testers of Fedora development releases test@lists.fedoraproject.org
Sent: Sat, September 4, 2010 10:10:11 PM
Subject: Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed
bugs.
Adam Williamson wrote:
On
On 02/09/10 03:58, Adam Williamson wrote:
Because there are always suspend issues, kernel team doesn't consider
suspend problems a blocker for release.
This is really sad; just a few Fedora releases suspended and resumed
fine right of the box on my T43 Thinkpad, F 13 belonged to them.
I really
On Thu, Sep 2, 2010 at 3:55 PM, pbrobin...@gmail.com
pbrobin...@gmail.comwrote:
On Thu, Sep 2, 2010 at 3:12 AM, Rodd Clarkson r...@clarkson.id.au wrote:
My system suspends and resumes fine on f13 with the 2.6.33 kernels, so it
isn't unreasonable to expect this functionality to continue on a
On 02/09/10 08:29, Rodd Clarkson wrote:
Anyhow, what a waste of time all around. I spend a couple of painful hours
booting and rebooting my system to try and isolate this bug and the
developers couldn't take two minutes to mention that they needed to post the
kernel and that they would
On Thu, Sep 2, 2010 at 4:34 PM, Matthias Runge mru...@matthias-runge.dewrote:
Although I think, this is the wrong way, putting
exclude=kernel-*
in your /etc/yum.conf will exclude the kernel from updating.
Thanks Matthias,
I don't like excluding kernels either, but I don't need to be adding
Rodd Clarkson rodd at clarkson.id.au writes:
Ah, and here I guess lies the problem. The email from the fedora engineers
(some weeks ago) quite clearly
stated not to give this kernel karma points so that it didn't get pushed until
they were sure it wouldn't cause issues, so I haven't been
On 09/02/2010 04:18 AM, Adam Williamson wrote:
On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote:
It is however, perfectly reasonable to expect that having tried a
kernel at the request of a fedora developer on fedora-test-list and
then having filed a bug against said kernel reporting
2010/9/2 Dennis J. denni...@conversis.de
On 09/02/2010 04:18 AM, Adam Williamson wrote:
On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote:
It is however, perfectly reasonable to expect that having tried a
kernel at the request of a fedora developer on fedora-test-list and
then
On Thu, Sep 2, 2010 at 8:29 AM, Rodd Clarkson r...@clarkson.id.au wrote:
Anyhow, what a waste of time all around. I spend a couple of painful
hours booting and rebooting my system to try and isolate this bug and the
developers couldn't take two minutes to mention that they needed to post the
On 09/02/2010 09:56 AM, Dennis J. wrote:
I think the question is how regressions are prioritized. For me the issue
is that my Radeon card has been working perfectly on F11 but had a major
performance regression with F12 that makes the system too slow for regular
use. I filed a bug with lots
On 09/02/2010 12:35 PM, Jóhann B. Guðmundsson wrote:
To actually see the extent and identifying problem(s) and regressions (
you could notice reporting trends with components ) and deal with it
accordingly we need to gather and make public bugzilla stats for
components.
Making those stats
On Thu, Sep 2, 2010 at 2:17 PM, Dennis J. denni...@conversis.de wrote:
2. Regressions can be easier to fix because you have a known to work case
you can use as a comparison. If bugs could be flagged as regression then
developers you potentially look at these first right after the regressions
2010/9/2 drago01 drag...@gmail.com
On Thu, Sep 2, 2010 at 2:17 PM, Dennis J. denni...@conversis.de wrote:
2. Regressions can be easier to fix because you have a known to work
case
you can use as a comparison. If bugs could be flagged as regression then
developers you potentially look at
On Thu, Sep 2, 2010 at 2:27 PM, cornel panceac cpanc...@gmail.com wrote:
2010/9/2 drago01 drag...@gmail.com
On Thu, Sep 2, 2010 at 2:17 PM, Dennis J. denni...@conversis.de wrote:
2. Regressions can be easier to fix because you have a known to work
case
you can use as a comparison. If
On 09/02/2010 02:39 PM, drago01 wrote:
On Thu, Sep 2, 2010 at 2:27 PM, cornel panceaccpanc...@gmail.com wrote:
2010/9/2 drago01drag...@gmail.com
On Thu, Sep 2, 2010 at 2:17 PM, Dennis J.denni...@conversis.de wrote:
2. Regressions can be easier to fix because you have a known to work
On 09/02/2010 11:16 AM, Adam Williamson wrote:
There's no guarantee the bug will get closed even if the problem is
fixed, unless someone else has the same hardware as you and is testing.
A fix may come down from upstream without being recognized specifically
as a fix for this particular
On Thu, 2010-09-02 at 12:09 -0700, Scott Doty wrote:
Anyway, I could say more -- but I've probably already shown how bananas
my ideas can be.
It's not bananas, it's just a lot of work that no-one's done yet - well,
actually, it's implemented quite well in Launchpad, but most things
don't use
On Thu, 2010-09-02 at 14:17 +0200, Dennis J. wrote:
What I would like to see is a distinction between regressions and other
bugs. There are a least two reasons why this might be worthwhile:
1. Regressions break functionality that has been known to work previously
and the users already
On 09/01/2010 09:12 PM, Rodd Clarkson wrote:
On Thu, Sep 2, 2010 at 11:58 AM, Adam
Williamson awill...@redhat.com
wrote:
On Thu, 2010-09-02 at 11:00 +1000, Rodd
Clarkson wrote:
Hi all,
On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote:
It is however, perfectly reasonable to expect that having tried a
kernel at the request of a fedora developer on fedora-test-list and
then having filed a bug against said kernel reporting problems, that
someone might actually have a
On Thu, Sep 2, 2010 at 3:12 AM, Rodd Clarkson r...@clarkson.id.au wrote:
On Thu, Sep 2, 2010 at 11:58 AM, Adam Williamson awill...@redhat.com
wrote:
On Thu, 2010-09-02 at 11:00 +1000, Rodd Clarkson wrote:
Hi all,
Why was kernel-2.6.34.x pushed to updates in f13 when three people had
43 matches
Mail list logo
