Latest updates for F11 x86_64 change video settings drastically
by stan
Hi,
After updating to the latest from updates testing, there were drastic
changes required to my monitor settings.
Initially, it used settings that were below possible resolution,
and capped the selection there. After I ran the gui setup, it allowed
higher resolutions. But neither the nouveau or nv driver looked good
at any setting they allowed. I used the monitors adjustments to fix
this. I haven't had to do that for 3 or 4 Fedora releases.
It must have been the X updates that caused this.
Perhaps there is something I could have done to fix this less
drastically?
14 years, 9 months
dracut-0.5: initrd file is big
by Steven I Usdansky
Command lines:
1. none (initrd generated when kernel installed)
2. dracut -a debug /boot/test-$(uname -r) $(uname -r)
3. dracut /boot/test2-$(uname -r) $(uname -r)
4. dracut -H /boot/test3-$(uname -r) $(uname -r)
File sizes:
1. 3096635 initrd-2.6.31-0.67.rc2.git9.fc12.i586.img
2. 14855892 test-2.6.31-0.67.rc2.git9.fc12.i586
3. 14266231 test2-2.6.31-0.67.rc2.git9.fc12.i586
4. 4743758 test3-2.6.31-0.67.rc2.git9.fc12.i586
test3 is 53% larger than initrd. Any way to shrink it?
14 years, 9 months
Re: Bugzilla semantics: marking bugs as triaged
by Allen Kistler
Adam Williamson wrote:
> On Fri, 2009-07-17 at 10:53 -0500, Allen Kistler wrote:
>> I believe the way Bugzilla works now, ASSIGNED = "Actively being worked"
>> ("Open Issues: In Progress Reported by You. You reported the bug, the
>> developer accepted the bug and is hopefully working on it."). At least,
>> it's supposed to be that way. "My Front Page" recently changed and no
>> longer shows Open bugs I've reported, but I believe that's a gaping bug
>> in the new My Front Page implementation. (Bugzilla on Bugzilla in
>> progress...)
>
> As noted in earlier discussion in this thread, no, that's not how it
> works currently. ASSIGNED is set by the triager, not the maintainer, so
> it doesn't indicate anything about the maintainer's intentions, strictly
> speaking.
I think you misunderstood. I wasn't talking about how Fedora personnel
set the fields. I was talking about how Bugzilla, the software,
interprets and represents the fields, based mostly, I'm sure, on how RH
uses them for RHEL.
The challenge is that if Fedora is going to start using them too
differently from RHEL, then perhaps Bugzilla needs a "My Fedora Front
Page" in addition to "My Front Page."
14 years, 9 months
Preupgrade Hacking
by Frank Murphy
Can preupgrade be hacked to work with smart (instead of yum)
for testing purposes.
Regards,
Frank
--
jabber | msn | skype: frankly3d
http://www.frankly3d.com
Away at Springsteen Weekend 12th July
14 years, 9 months
Status column in admin interface
by Christopher Beland
So in a listing like this one:
https://admin.fedoraproject.org/pkgdb/packages/bugs/rhythmbox
I think it would be handy to enhance the "Status" column to show
NEEDINFO and perhaps other flags. This would be helpful when doing
triage.
It seems that if we move to using the "Triaged" keyword instead of the
"ASSIGNED" state, this interface would become less convenient for triage
unless that keyword also shows up.
What do other people think? If this is a good idea, where should I file
the change request?
Thanks,
Beland
14 years, 9 months
Re: Bugzilla semantics: marking bugs as triaged
by Allen Kistler
Adam Williamson wrote:
>
> [snip]
>
> We were thinking about the NEW / ASSIGNED dichotomy, and Andy and I came
> to the conclusion that it doesn't really make a lot of sense.
>
> [snip]
>
> We sort of came to the conclusion that it'd probably make the most sense
> to have a 'Triaged' keyword that's used to affirm that a bug's been
> triaged (in fact there already is one, but it's not officially used in
> our current process), and abandon the distinction between NEW and
> ASSIGNED. Ideally, the ASSIGNED state would just be removed, but we
> could keep it and just note in our workflow / policy that it's not
> really used to mean anything in particular.
>
> This could, I think, be implemented quite quickly if desired; I think we
> could rig something up to set all bugs in ASSIGNED state (except
> anaconda ones) to have the 'Triaged' keyword, that shouldn't be
> impossible.
>
> We'd be interested in thoughts - negative, positive, whatever - on the
> idea. Thanks!
I believe the way Bugzilla works now, ASSIGNED = "Actively being worked"
("Open Issues: In Progress Reported by You. You reported the bug, the
developer accepted the bug and is hopefully working on it."). At least,
it's supposed to be that way. "My Front Page" recently changed and no
longer shows Open bugs I've reported, but I believe that's a gaping bug
in the new My Front Page implementation. (Bugzilla on Bugzilla in
progress...)
14 years, 9 months
Anaconda triage project progress
by Adam Williamson
Hi, all. Just a quick general update on the progress with bringing
Anaconda a bit more into the Bugzappers umbrella.
First a big thanks to Andy (Lindeberg, the current main anaconda
triager) for coming along to meetings, hanging out in the IRC channel
and being receptive to questions / suggestions and so on, that's been
great.
Really, I think we're most of the way there with this now. As pretty
much everyone agreed at the meetings, there's nothing really about how
Andy does anaconda triage that's fundamentally incompatible with the
regular Bugzappers process.
Andy has written a Wiki page explaining the Anaconda bug work flow:
https://fedoraproject.org/wiki/Anaconda/AnacondaBugWorkflow
which kinda supports this, because most of what's in there is much like
the regular Bugzappers workflow, with the previously noted exceptions
(principally that anaconda bugs always have to be assigned to the
correct single developer as part of the triage process).
So for now I've just edited Components and Triagers to link to the above
Wiki page in the 'Special' column, and to say 'yes' for 'help needed',
as we're now reasonably confident we can accommodate any enthusiastic
volunteers who want to help with Anaconda triage. I'm wondering if we
should rename that column, though, as it's a bit of an odd name - it
makes it sound more like "This component is drowning in bugs, please
help!" rather than just "Open to additional triagers".
Andy is covering anaconda triage very well for now, so it's probably not
our first choice for new members to work on, but now we can consider
Andy a part of the group and we can accommodate anyone who really really
wants to work on Anaconda triage too. So thanks a lot to everyone for
that.
We also discussed a few other interesting points which I'll address in
another mail, forthcoming.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
14 years, 9 months
Alpha Blocker Bug Meeting: Friday 2009-07-17
by John Poelstra
What: F12Alpha Blocker bug meeting
(https://bugzilla.redhat.com/show_bug.cgi?id=f12alpha)
When: Friday, 2009-07-17 @ 17:00 UTC (1 PM EDT)
Where: #fedora-bugzappers
It is hard to believe, but it is already time to start getting prepared
for the Alpha!
For Fedora 12 we are making a concerted effort to pro-actively review
the blocker bug lists on a more consistent basis.
Right now the blocker bug for Fedora 12 alpha is "bug free." Either this
is going to be a really solid release that requires little effort...
or we need to start focusing on rawhide and marking blockers as we find
them :)
Hope to see you on Friday.
Thanks,
John
14 years, 9 months
Rawhide laptop died yesterday. fils system errors after crash.
by Birger Monsen
It may be just my laptop, but I want to warn anyway...
Yesterday, I updated, including a new kernel. Rebooted, used the system for
a little while, and then left it. As usual when I leave it long enough it
was stuck when I got back. Powered off and on again, and it doesn't boot.
Messages about journal errors, block errors, ATA reset errors of some kind,
etc. This is on a 80GB Solid State Drive. Doesn't even boot to single-user,
so I'll have to get a rawhide recovery environment on USB or CD.
I have tried the older kernels on the system as well, and it's just the
same. Seems like my file system is foobar.
So, a few questions:
- Where do I find a relatively current rawhide bootable recovery environment
(Live image or whatever). I have seen on this list there have been some
problems building live images lately...
- Does anyone want me to follow certain procedures before I start trying to
fix this myself? Gather forensic data for the file system guys or something?
--
birger
14 years, 9 months