[Fedora QA] #289: Howto: debug kernel
by fedora-badges
#289: Howto: debug kernel
--------------------+------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 17
Component: Wiki | Version:
Keywords: | Blocked By:
Blocking: |
--------------------+------------------------
I have seen a lot of discussions about kernel with debugging options
enabled in this cycle. The questions repeat itself and I have them
sometimes as well (I tend to forget these information). I think we should
create a wiki page describing:
1. That our current policy is to use debug kernels in all composes prior
to Branched Beta (is that true? maybe just Beta RC1?).
2. The problems that debug kernels may cause (mainly performance
problems).
3. The exceptions in this process (regularly there is a non-debug kernel
built).
4. How to know whether you are currently running a debug kernel (I never
remember this one).
5. How to find latest debug/non-debug kernel in Koji.
6. How to install this kernel from Koji.
Then we can link this page e.g. in our Alpha announcements, so that we
save a lot of question for many people (and maybe a lot of troubles as
well, if they have some troubles and they just don't know about debug
kernels at all).
Good idea? Volunteer?
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/289>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 7 months
Intel Graphics: SNA testing report with xorg-x11-drv-intel >= 2.20
by Pedro Francisco
I'm testing SNA on an Intel Graphics card:
$ sudo rpm -qa xorg-x11-drv-intel*
xorg-x11-drv-intel-2.20.1-1.fc17.i686
$ cat /etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "sna"
EndSection
$ glxinfo |grep "OpenGL renderer string"
OpenGL renderer string: Mesa DRI Intel(R) 965GM
$ grep SNA /var/log/Xorg.0.log
[ 36.273] (II) intel(0): SNA initialized with Broadwater backend
I suppose we could organize a little test fest in order to have
feedback for https://bugzilla.redhat.com/show_bug.cgi?id=820566 ?
(level of commitment: will test unless weird crashes occur)
--
Pedro
11 years, 7 months
[criteria update] Interfaces
by Petr Schindler
Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to change this final criterion [2]:
'The installer must be able to complete an installation using all
supported interfaces '
to
'The installer must be able to complete an installation using all
supported interfaces (graphical and VNC for F18)'
Reason (according to Chris): (Current criterion) again references
multiple interfaces. For F18, it's really only going to be graphical and VNC.
Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.
Petr Schindler
[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
11 years, 8 months
[criteria update] Rescue mode
by Petr Schindler
Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to delete this alpha criterion:
'The rescue mode of the installer must start successfully and be able to
detect and mount an existing default installation'
Reason (according to Chris): There's been no work done on rescue mode
and it is highly unlikely that it does anything at all right now.
Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.
Petr Schindler
[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
11 years, 8 months
[Fedora QA] #284: Create advisory installation validation test cases for VirtualBox
by fedora-badges
#284: Create advisory installation validation test cases for VirtualBox
----------------------+------------------
Reporter: adamwill | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: Wiki | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
Although kernel team (and the rest of the development team) specifically
don't want to commit to supporting VirtualBox, the practical fact is that
a lot of people like to run Fedora in VirtualBox, and we don't at present
have formal testing in place to find out if it's actually working during
release validation.
In practice, we usually find out about any bugs via people trying it and
then posting their results to test@ or the forums, but this is pretty
rough and ready and it's easy to lose the information. If we add formal
VBox testing to the release validation process we'll probably find out
about VBox fails sooner and do a better job of tracking them for possible
fixes or at least documentation at release time.
So, ideally, we should write test cases for deploying Fedora as a VBox
guest (and possibly using it as a VBox host), and add these to the
installation validation matrix as 'advisory' tests (tests not associated
with Alpha, Beta or Final release phases, and without a corresponding
release criterion).
Dan Mashal, who I hope I've added to CC, is interested in this topic and
may choose to be an awesome rock star and contribute the test cases :)
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/284>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 8 months
[Fedora QA] #180: Create Package Specific Test Cases for Design Suite
by fedora-badges
#180: Create Package Specific Test Cases for Design Suite
---------------------------------------------+------------------------------
Reporter: sdz | Owner:
Type: task | Status: new
Priority: minor | Milestone: Fedora 15
Component: Wiki | Version:
Keywords: design suite, package test plan |
---------------------------------------------+------------------------------
The Design Suite has been promoted at SXSW and other conferences. We want
to make sure that the included applications are all working and in a good
state. Adam introduced package specific test cases at FUDCon in Tempe. We
should consider creating test cases for the most important tools, such as
blender, gimp, inkscape and shotwell.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/180>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 8 months
[Fedora QA] #287: Add Bodhi testing guidelines to Bodhi?
by fedora-badges
#287: Add Bodhi testing guidelines to Bodhi?
-------------------------+------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Wiki | Version:
Keywords: | Blocked By:
Blocking: |
-------------------------+------------------
My thinking process:
1. I was about to test
https://admin.fedoraproject.org/updates/NetworkManager-0.9.3.997-0.7.fc17
2. I realized I don't know what karma to post when NM works in general,
but I haven't tested the linked bug fixes
3. I know we have some karma guidelines somewhere on the wiki
4. I couldn't find the page
5. I found the page at
https://fedoraproject.org/wiki/Proven_tester#Feedback_procedures after
some time
6. My use case doesn't seem to be mentioned anyway. But that's not
important. The question is - shouldn't we link these instructions directly
from the bodhi page? No one will find it otherwise.
That wiki page is proven tester specific, but the "Feedback procedures"
chapter is not. I think it would be really worth the effort to create a
new wiki page containing just guidelines for correct karma posting and
then ask Bodhi maintainers to link that page directly from the Bodhi page.
I imagine it could be displayed besides the "Add a comment" text are,
named something like "Karma posting guidelines".
What do you think?
Does anyone feel like volunteering for creating this separate wiki page?
I'll gladly create a ticket for Bodhi afterwards.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/287>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 8 months
[Fedora QA] #235: request: add tests for new grub2 stage2 device types
by fedora-badges
#235: request: add tests for new grub2 stage2 device types
-----------------------------------------+----------------------------------
Reporter: dlehman | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: Proventester Mentor Request | Version:
Keywords: |
-----------------------------------------+----------------------------------
= phenomenon =
GRUB2 supports several new md raid levels (0,4,5,6,10) and also lvm
logical volumes as the /boot device. It would be nice to get some testing
coverage for this, including combinations like root on lvm (no separate
/boot) w/ md raid pvs.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/235>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 8 months
[criteria update] Rescue mode
by Petr Schindler
Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to remove this beta criterion [2]:
'The rescue mode of the installer must be able to detect and mount
(read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and
software) installations'
Reason (according to Chris): There's been no work done on rescue mode
and it is highly unlikely that it does anything at all right now.
Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.
Petr Schindler
[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
11 years, 8 months