Re: Perl test case suggestions?

[Ralf Corsepius]

On 04/06/2011 05:08 PM, James Laska wrote:
> On Wed, 2011-04-06 at 09:48 -0500, Bruno Wolff III wrote:
>> On Wed, Apr 06, 2011 at 10:45:16 -0400,
>>James Laska  wrote:
>>> Greetings folks,
>>>
>>> I'm not a perl user, and it's been *some* time since I last knowingly
>>> opened up a perl script.  While providing some karma feedback for a
>>> recent perl update, it occurred that it might be nice to have a few
>>> sample perl test cases linked from the bodhi update request.
>>>
>>> Does anyone have any perl test case suggestions that we can add to
>>> https://fedoraproject.org/wiki/Category:Package_perl_test_cases ?
>>
>> It is fairly normal for perl modules to come with test cases. I am not
>> sure of what you need to do to run them as they are installed, but it is
>> normal to run them when building them from source.
>
> Is that something a tester should validate from the koji build logs?
It's convention for all fedora perl packages to run these test
in %check.

I.e. usually (i.e. there are exceptions), a perl-package which fails its 
testsuite will fail building.

> Meaning, check whether %check ran, and passed?
So far, this has been considered responsibility of the Fedora package 
maintainer as well as has making sure %check runs a perl package's 
testsuite and produces reasonable results, always been been part of the 
Fedora package reviews.

> Anything else to consider?
I am not sure what you are aim at.

The current number one issue with perl packages in Fedora are package 
dependencies (perl module dependencies) and the impact of changes in 
rpm's perl dependency-generator between different versions of rpm.

Bugs in functionality usually are much covered by perl packages' 
upstreams than they are by Fedora users or Fedora package maintainers. 
In other words, the usual situation with perl packages is upstreams 
releasing updates, which fix bugs no Fedora user had reported nor the 
Fedora maintainer has tripped over.

Ralf

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Adam Williamson]

On Wed, 2011-04-06 at 15:06 -0700, Michael Knepher wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=690648
> The issue with my laptop is that it appears to suspend properly, but
> the screen will not power back on when trying to resume. Everything
> else seems to work OK (had headphones plugged in, and banshee resumed
> the track it had been playing when it suspended). I filed it under
> pm-utils because I was testing it out around the time of the test day,
> but didn't have time to run a full test suite. Is there a better
> component for it? Hibernation is a whole other kettle of fish, and I
> have not had time to do a bug report on it yet.

It's likely in the kernel or the graphics driver (which may actually
mean also the kernel, but different developers). I'd switch it to kernel
or xorg-x11-drv-(whatever'sappropriateforyourgraphicscard).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Adam Williamson]

On Wed, 2011-04-06 at 16:29 -0500, Steven Stern wrote:

> I'd like to see all available options when I press ALT instead of just
> shifting from "suspend" to "shutdown".

Power Off gives you Restart as an option, now, but Hibernate isn't
exposed anyway.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: since last update system does not boot any more

[Brendan Jones]

On 07/04/11 01:06, Adam Pribyl wrote:

> You are right. The problem with systemd is that those arguments are
> filenames, but you can not use "tab" for autocompletition. ATM systemd can
> translate "3" to multi-user.target which is OK, but in the future who
> knows. Acctualy if I understand the concept right, maybe it is possible to
> make symlink 3 ->  multi-user.target, and it may work...
>
You can use tab completion. Just install the bash-completion package and 
modify /etc/bash_completion.d/systemctl-bash-completion.sh as per the 
patch here  https://bugzilla.redhat.com/show_bug.cgi?id=694321



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Michael Knepher]

2011/4/6 "Jóhann B. Guðmundsson" :
> On 04/06/2011 10:56 PM, Michael Knepher wrote:
>> 2011/4/6 "Jóhann B. Guðmundsson":
>>> 
>>>
>>> All suspend resume bugs should be fixed hence if it fails for you or
>>> anyother reporter for that matter you should report it so please file a
>>> bug and attach /var/log/messages
>>> ,/var/log/pm-suspend.log and the file from su -c
>>> 'pm-utils-bugreport-info.sh>  pm-utils-bugreport.txt'
>>>
>>> You can test suspend from the graphical.target and multi-user.target by
>>> running
>>>
>>> su -c 'pm-suspend'
>>>
>>> and
>>>
>>> su -c 'echo mem>  /sys/power/state'
>> Am I supposed to run both or either of these commands? I ran the
>> first, with the same results (no screen), and after restarting the
>> system, attached the requested files to
>> https://bugzilla.redhat.com/show_bug.cgi?id=690648
>
> What happens if you add pci=noacpi to the kernel command line and try to
> suspend/resume?

After a normal boot, and logging in, and waiting for 5 minutes, I just
had the background and a cursor and a network connection (I have
synergy autostarting in my session). No top panel, no overlay. I
killed the session with ctrl+alt+backspace and logged into a clean
test user, which brought up the overlay after about 20 seconds, but
nothing sensitive to user interaction other than cursor movement, and
no user name in the user menu, and no network connection. So I was
never able to get to a point within a user session at which I could
suspend. I restarted with pci=noacpi and tried running suspend from
gdm. Same apparent outcome.

>
> you should also add the output from dmesg to that bug report ( su -c
> 'dmesg > dmesg.txt' )  given that this mostlikely is a kernel bug

Done. Would dmesg output following a boot with pci=noacpi appended be
useful as well?

>
> JBG
> --
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
>
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Jóhann B. Guðmundsson]

On 04/06/2011 10:56 PM, Michael Knepher wrote:
> 2011/4/6 "Jóhann B. Guðmundsson":
>> 
>>
>> All suspend resume bugs should be fixed hence if it fails for you or
>> anyother reporter for that matter you should report it so please file a
>> bug and attach /var/log/messages
>> ,/var/log/pm-suspend.log and the file from su -c
>> 'pm-utils-bugreport-info.sh>  pm-utils-bugreport.txt'
>>
>> You can test suspend from the graphical.target and multi-user.target by
>> running
>>
>> su -c 'pm-suspend'
>>
>> and
>>
>> su -c 'echo mem>  /sys/power/state'
> Am I supposed to run both or either of these commands? I ran the
> first, with the same results (no screen), and after restarting the
> system, attached the requested files to
> https://bugzilla.redhat.com/show_bug.cgi?id=690648

What happens if you add pci=noacpi to the kernel command line and try to 
suspend/resume?

you should also add the output from dmesg to that bug report ( su -c 
'dmesg > dmesg.txt' )  given that this mostlikely is a kernel bug

JBG
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Michael Knepher]

2011/4/6 "Jóhann B. Guðmundsson" :
> 
>
> All suspend resume bugs should be fixed hence if it fails for you or
> anyother reporter for that matter you should report it so please file a
> bug and attach /var/log/messages
> ,/var/log/pm-suspend.log and the file from su -c
> 'pm-utils-bugreport-info.sh > pm-utils-bugreport.txt'
>
> You can test suspend from the graphical.target and multi-user.target by
> running
>
> su -c 'pm-suspend'
>
> and
>
> su -c 'echo mem > /sys/power/state'

Am I supposed to run both or either of these commands? I ran the
first, with the same results (no screen), and after restarting the
system, attached the requested files to
https://bugzilla.redhat.com/show_bug.cgi?id=690648

>
> If the above fails in multi-user.target it's most likely is a kernel bug
> thus needs more advanced debugging.
>
> JBG
> --
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
>
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Fedora 13 updates-testing report

[updates]

The following Fedora 13 Security updates need testing:

https://admin.fedoraproject.org/updates/dbus-1.2.24-2.fc13
https://admin.fedoraproject.org/updates/openldap-2.4.21-12.fc13
https://admin.fedoraproject.org/updates/tor-0.2.1.29-1300.fc13
https://admin.fedoraproject.org/updates/libxml2-2.7.7-2.fc13
https://admin.fedoraproject.org/updates/rsync-3.0.8-1.fc13
https://admin.fedoraproject.org/updates/nss-3.12.9-9.fc13
https://admin.fedoraproject.org/updates/gdm-2.30.2-2.fc13
https://admin.fedoraproject.org/updates/feh-1.10.1-1.fc13
https://admin.fedoraproject.org/updates/perl-5.10.1-123.fc13
https://admin.fedoraproject.org/updates/libtiff-3.9.4-4.fc13
https://admin.fedoraproject.org/updates/quagga-0.99.18-1.fc13
https://admin.fedoraproject.org/updates/libcgroup-0.35.1-5.fc13
https://admin.fedoraproject.org/updates/python-feedparser-5.0.1-1.fc13
https://admin.fedoraproject.org/updates/libvirt-0.8.2-6.fc13
https://admin.fedoraproject.org/updates/xorg-x11-server-utils-7.4-17.fc13


The following Fedora 13 Critical Path updates have yet to be approved:

https://admin.fedoraproject.org/updates/xorg-x11-server-utils-7.4-17.fc13
https://admin.fedoraproject.org/updates/dosfstools-3.0.9-5.fc13
https://admin.fedoraproject.org/updates/perl-5.10.1-123.fc13
https://admin.fedoraproject.org/updates/tzdata-2011d-3.fc13
https://admin.fedoraproject.org/updates/policycoreutils-2.0.83-33.8.fc13
https://admin.fedoraproject.org/updates/gdm-2.30.2-2.fc13
https://admin.fedoraproject.org/updates/nss-3.12.9-9.fc13
https://admin.fedoraproject.org/updates/libimobiledevice-1.0.6-1.fc13
https://admin.fedoraproject.org/updates/PackageKit-0.6.6-3.fc13
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.998-2.fc13
https://admin.fedoraproject.org/updates/usbmuxd-1.0.7-1.fc13
https://admin.fedoraproject.org/updates/libtiff-3.9.4-4.fc13
https://admin.fedoraproject.org/updates/libnl-1.1-14.fc13
https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-101.fc13
https://admin.fedoraproject.org/updates/libxml2-2.7.7-2.fc13
https://admin.fedoraproject.org/updates/fuse-2.8.5-5.fc13
https://admin.fedoraproject.org/updates/libcgroup-0.35.1-5.fc13
https://admin.fedoraproject.org/updates/openldap-2.4.21-12.fc13
https://admin.fedoraproject.org/updates/livecd-tools-13.2-1.fc13
https://admin.fedoraproject.org/updates/lua-5.1.4-7.fc13
https://admin.fedoraproject.org/updates/librsvg2-2.26.3-3.fc13

https://admin.fedoraproject.org/updates/mobile-broadband-provider-info-1.20110218-1.fc13
https://admin.fedoraproject.org/updates/file-5.04-7.fc13
https://admin.fedoraproject.org/updates/system-config-users-1.2.107-1.fc13
https://admin.fedoraproject.org/updates/python-ethtool-0.6-1.fc13
https://admin.fedoraproject.org/updates/libical-0.46-2.fc13
https://admin.fedoraproject.org/updates/mash-0.5.20-1.fc13
https://admin.fedoraproject.org/updates/libfprint-0.3.0-1.fc13

https://admin.fedoraproject.org/updates/xorg-x11-drv-openchrome-0.2.904-7.fc13
https://admin.fedoraproject.org/updates/lldpad-0.9.26-2.fc13


The following builds have been pushed to Fedora 13 updates-testing

389-ds-base-1.2.8.0-1.fc13
EekBoek-2.00.03-1.fc13
dosfstools-3.0.9-5.fc13
erlang-mochiweb-1.4.1-5.fc13
fpdns-0.9.3-1.fc13
gegl-0.1.2-5.fc13
libvirt-0.8.2-6.fc13
openttd-1.1.0-2.fc13
openttd-opengfx-0.3.3-1.fc13
perl-5.10.1-123.fc13
perl-Test-HasVersion-0.012-1.fc13
pure-0.47-1.fc13
python-feedparser-5.0.1-1.fc13
python-zmq-2.1.4-1.fc13
system-config-printer-1.2.8-1.fc13
wine-1.3.17-2.fc13
xorg-x11-server-utils-7.4-17.fc13
zarafa-6.40.7-1.fc13
zeromq-2.1.4-1.fc13

Details about builds:



 389-ds-base-1.2.8.0-1.fc13 (FEDORA-2011-4873)
 389 Directory Server (base)

Update Information:

This is the 389-ds-base-1.2.8.0 release - some bug fixes for winsync
and matching rules and schema
The 389-ds-base-1.2.8.rc5 release - Fix a bug in settting up GSSAPI replication
This is the 1.2.8 release candidate 4 release
This is 389-ds-base-1.2.8 RC 2 - this fixes several bugs found in alpha and RC 
1 testing
This is the 389-ds-base-1.2.8 release candidate 1 build
Split off 389-ds-base-libs to solve multilib issues
1.2.8.a3 release - git tag 389-ds-base-1.2.8.a3
see bugs for a list of bugs fixed
This is the 1.2.8 alpha 2 release - many bug fixes
389-ds-base 1.2.8 alpha 1
contains many bug fixes

ChangeLog:

* Tue Apr  5 2011 Rich Megginson  - 1.2.8.0-1
- 389-ds-base-1.2.8.0
- Bug 693473 - rhds82 rfe - windows_tot_run to log Sizelimit exceeded instead 
of LDAP error - -1
- Bug 692991 - rhds82 - windows_tot_run: fail

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Jóhann B. Guðmundsson]

All suspend resume bugs should be fixed hence if it fails for you or 
anyother reporter for that matter you should report it so please file a 
bug and attach /var/log/messages
,/var/log/pm-suspend.log and the file from su -c 
'pm-utils-bugreport-info.sh > pm-utils-bugreport.txt'

You can test suspend from the graphical.target and multi-user.target by 
running

su -c 'pm-suspend'

and

su -c 'echo mem > /sys/power/state'

If the above fails in multi-user.target it's most likely is a kernel bug 
thus needs more advanced debugging.

JBG
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Michael Knepher]

On Wed, Apr 6, 2011 at 1:52 PM, Adam Williamson  wrote:
> On Wed, 2011-04-06 at 11:41 -0700, Michael Knepher wrote:
>> I've tried following the debate over the change to suspend as the
>> visible and default way of managing power, but have not been able to
>> find any resolution of whether the default is expected to remain so on
>> systems that do not either suspend or resume properly or if this is up
>> to the distributions to handle.
>
> Neither, really: it's the default, and if it doesn't work, the idea is
> that we fix that (the failure to suspend). Both GNOME and Fedora are not
> big fans of giant manually-updated blacklists due to previous
> experience.

I can certainly understand that.

>> My understanding is that gnome 3 default is to suspend, then hibernate
>> after a certain period of time.
>
> I don't think it does this (hybrid suspend), it just suspends.

A bit more googling, and all I found was a blog post referring to a
#gnome-shell IRC conversation from late February, reporting that devs
wanted to suspend, then wake up after 30 minutes and suspend-to-disk.
Can't find any other references.

> AFAIK no, that would require a big ugly blacklist and manpower to
> maintain it. Is there a bug filed on the failure to suspend correctly?

https://bugzilla.redhat.com/show_bug.cgi?id=690648
The issue with my laptop is that it appears to suspend properly, but
the screen will not power back on when trying to resume. Everything
else seems to work OK (had headphones plugged in, and banshee resumed
the track it had been playing when it suspended). I filed it under
pm-utils because I was testing it out around the time of the test day,
but didn't have time to run a full test suite. Is there a better
component for it? Hibernation is a whole other kettle of fish, and I
have not had time to do a bug report on it yet.

>
>> And/or is there a way (through gsettings I
>> guess it would be?) for users to change this so we don't have to press
>> Alt every time?
>
> Not sure about this...
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
>
> --
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
>
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Steven Stern]

On 04/06/2011 04:22 PM, Bill Nottingham wrote:
> Fabian A. Scherschel (f...@sixgun.org) said: 
>>> I don't think it does this (hybrid suspend), it just suspends.
>>
>> So we are knowingly risking people's laptops just running out of battery in
>> a bag somewhere and their systems dying with possible data loss? As the
>> default?
> 
> Hybrid suspend has never really been supported. You certainly can choose
> to hibernate instead of suspend-to-RAM.
> 
> Bill
My worry with hybrid suspend is that the disks will spin up at exactly
the wrong time, when I'm banging my bag around, and damage the hardware.
 I generally think about suspending vs. hibernation vs. power off before
putting the computer away.

I'd like to see all available options when I press ALT instead of just
shifting from "suspend" to "shutdown".

-- 
-- Steve
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Bill Nottingham]

Fabian A. Scherschel (f...@sixgun.org) said: 
> > I don't think it does this (hybrid suspend), it just suspends.
> 
> So we are knowingly risking people's laptops just running out of battery in
> a bag somewhere and their systems dying with possible data loss? As the
> default?

Hybrid suspend has never really been supported. You certainly can choose
to hibernate instead of suspend-to-RAM.

Bill
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Fabian A. Scherschel]

On Wed, Apr 6, 2011 at 10:52 PM, Adam Williamson wrote:

>
> I don't think it does this (hybrid suspend), it just suspends.
>

So we are knowingly risking people's laptops just running out of battery in
a bag somewhere and their systems dying with possible data loss? As the
default?

Fab
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Adam Williamson]

On Wed, 2011-04-06 at 11:41 -0700, Michael Knepher wrote:
> I've tried following the debate over the change to suspend as the
> visible and default way of managing power, but have not been able to
> find any resolution of whether the default is expected to remain so on
> systems that do not either suspend or resume properly or if this is up
> to the distributions to handle. 

Neither, really: it's the default, and if it doesn't work, the idea is
that we fix that (the failure to suspend). Both GNOME and Fedora are not
big fans of giant manually-updated blacklists due to previous
experience.

> My understanding is that gnome 3 default is to suspend, then hibernate
> after a certain period of time.

I don't think it does this (hybrid suspend), it just suspends.

>  While I don't think this is necessarily
> the wrong choice, it currently does not work on my laptop, which does
> not fully resume after a suspend, and for which hibernate is completely
> broken. Now, with gnome-tweak-tool, I can at least change the settings
> for closing the lid, but when I want to power off from the user menu, I
> still need to press Alt to get that option. 
> 
> Will Fedora 15 attempt to recognize systems that are known not to
> support the default behavior? 

AFAIK no, that would require a big ugly blacklist and manpower to
maintain it. Is there a bug filed on the failure to suspend correctly?

> And/or is there a way (through gsettings I
> guess it would be?) for users to change this so we don't have to press
> Alt every time?

Not sure about this...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] 2011-04-08 @ 17:00 UTC - F-15-Beta blocker bug review #5

[James Laska]

# F15-Beta Blocker Review meeting #5
# Date: 2011-04-08
# Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST)
# Location: #fedora-bugzappers on irc.freenode.net

Mark your calendars, the fifth (and hopefully last) Beta blocker review
meeting will be this Friday at 17:00 UTC in #fedora-bugzappers.  We'll
review proposed and accepted F-15-Beta blocker bugs.  

NOTE: The F-15-Beta RC1 compose, scheduled [2] for Thursday April 7th
(TOMORROW), *cannot* proceed until all approved blockers are resolved.

An updated list of blocker bugs is available at
https://fedoraproject.org/wiki/Current_Release_Blockers.  The list of
bugs is also attached to this mail.  We'll be reviewing the bugs to
determine ...
 1. whether they meet the Beta release criteria [2] and should stay
on the list
 2. are getting the attention they need

For guidance on Blocker and Nice-to-have (NTH) bugs, checkout ...
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and
https://fedoraproject.org/wiki/QA:SOP_nth_bug_process

== Suggested Meeting Preparation ==

Maintainers ...
  * If your bug is *not* MODIFIED ... this issue is at risk of
slipping the F15 Beta release date
  * If your bug is in MODIFIED ... please make sure a build with the
fix exists, and is available as a bodhi update.

Testers ...
  * If you REPORT a bug ... please be responsive to any requests for
additional information.
  * If a bug is in ON_QA ... please take a moment to apply the
update, and post karma feedback

[1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto
[2]
http://rbergero.fedorapeople.org/schedules/f-15/f-15-releng-tasks.html
[3] https://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria

Thanks,
James

== Approved Blockers ==
The following list of bugs are approved blockers that must be resolved.  There
are 6 bug(s) affecting 4 component(s).

=== NetworkManager ===
* https://bugzilla.redhat.com/678553 (ON_QA) - NetworkManager doesn't start 
successfully on bootup after upgrade from F14 -> F15
* https://bugzilla.redhat.com/691139 (NEW) - NetworkManager 0.8.997  doesn't 
connect to hidden wireless network

=== gnome-icon-theme ===
* https://bugzilla.redhat.com/692029 (MODIFIED) - package conflict between 
fedora-logos and gnome-logos on 15 Beta TC1 DVD
* https://bugzilla.redhat.com/692103 (MODIFIED) - No such file or directory: 
'.../boot/grub/splash.xpm.gz'

=== preupgrade ===
* https://bugzilla.redhat.com/646843 (ON_QA) - images/install.img will no 
longer exist in F-15 and newer

=== xorg-x11-xauth ===
* https://bugzilla.redhat.com/679486 (ASSIGNED) - Unable to start graphical 
installer on RC1 KDE live image

== Proposed Blockers ==
The following list of bugs are not yet approved to block the release.  There
are 5 bug(s) affecting 5 component(s).  For guidance on reviewing the following
bugs, refer to [[QA:SOP_blocker_bug_process]].

=== gdm ===
* https://bugzilla.redhat.com/678236 (NEW) - User list sometimes not visible on 
greeter

=== gnome-shell ===
* https://bugzilla.redhat.com/693588 (MODIFIED) - NetworkManager applet cannot 
scroll the list of wireless networks

=== libselinux ===
* https://bugzilla.redhat.com/692573 (ON_QA) - SELINUX=disabled in 
/etc/selinux/config causes failure to boot; libselinux lies to systemd about 
SELinux state

=== selinux-policy ===
* https://bugzilla.redhat.com/694239 (NEW) - Live image built with latest 
systemd/selinux-policy etc fails to boot with selinux enabled

=== systemd ===
* https://bugzilla.redhat.com/694079 (POST) - GDM starts while firstboot is 
still running

== Approved NICE-TO-HAVE ==
The following list of bugs are approved nths that must be resolved.  There are
7 bug(s) affecting 7 component(s).

=== anaconda ===
* https://bugzilla.redhat.com/629311 (ASSIGNED) - install allows use of 
preexisting root filesystem without reformat

=== gnome-settings-daemon ===
* https://bugzilla.redhat.com/688305 (NEW) - Update notification period should 
be shorter for pre-releases

=== gnome-user-share ===
* https://bugzilla.redhat.com/679814 (NEW) - [abrt] 
gnome-user-share-2.30.2-4.fc15: do_pre_parse_initialization: Process 
/usr/libexec/gnome-user-share was killed by signal 6 (SIGABRT)

=== isomd5sum ===
* https://bugzilla.redhat.com/692135 (NEW) - Image failed media check

=== libmtp ===
* https://bugzilla.redhat.com/684214 (MODIFIED) - [abrt] 
libmtp-examples-1.0.5-2.fc15: op_reset_device: Process /usr/bin/mtp-detect was 
killed by signal 11 (SIGSEGV)

=== mesa ===
* https://bugzilla.redhat.com/691461 (MODIFIED) - nouveau: bug with shader used 
in gnome-shell applications view

=== nautilus ===
* https://bugzilla.redhat.com/689260 (NEW) - [abrt] nautilus-2.91.91-1.fc15: 
gtk_action_group_add_action: Process /usr/bin/nautilus was killed by signal 11 
(SIGSEGV)

== Proposed NICE-TO-HAVE ==
The following list of bugs are not yet approved to block the release.  There
are 3 bug(s) affecting 3 component(s).  For guidance on reviewing the fo

Re: [Fedora QA] #184: Request to join the ProvenTesters Group

[Fedora QA]

#184: Request to join the ProvenTesters Group
--+-
  Reporter:  henryhuang   |   Owner:
  Type:  proventester request |  Status:  closed
  Priority:  major|   Milestone:
 Component:  Proventester Mentor Request  | Version:
Resolution:  duplicate|Keywords:
--+-
Changes (by mcloaked):

  * status:  new => closed
  * resolution:  => duplicate

Comment:

 This is a duplicate request so I will reply on ticket #185 and close this
 one.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #185: Request to join the ProvenTesters Group

[Fedora QA]

#185: Request to join the ProvenTesters Group
--+-
  Reporter:  henryhuang   |   Owner:  mcloaked
  Type:  proventester request |  Status:  assigned
  Priority:  major|   Milestone:  
 Component:  Proventester Mentor Request  | Version:  
Resolution:   |Keywords:  
--+-
Changes (by mcloaked):

  * owner:  => mcloaked
  * status:  new => assigned

Comment:

 'll be happy to sponsor you into the proventesters group once you have
 completed a few requirements. Please take a moment to read through the
 proventester instructions at:

 http://fedoraproject.org/wiki/Proven_tester

 Once you have read through the instructions, can you please confirm that
 you ...:

 have read and understand the instructions, and will follow the
 instructions when testing Fedora critical path updates.

 understand how to enable the update-testing repository

 are familiar with providing test feedback using either the Bodhi web
 interface, or the fedora-easy-karma utility

 Once you confirm these three from the list above, then I will be happy to
 sponsor your membership in the proventester group, after you apply for
 membership of that group in FAS.

 Please let me know if you have any questions or concerns.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Suspend/hibernate on systems that don't suspend/resume or hibernate properly

[Michael Knepher]

I've tried following the debate over the change to suspend as the
visible and default way of managing power, but have not been able to
find any resolution of whether the default is expected to remain so on
systems that do not either suspend or resume properly or if this is up
to the distributions to handle. 

My understanding is that gnome 3 default is to suspend, then hibernate
after a certain period of time. While I don't think this is necessarily
the wrong choice, it currently does not work on my laptop, which does
not fully resume after a suspend, and for which hibernate is completely
broken. Now, with gnome-tweak-tool, I can at least change the settings
for closing the lid, but when I want to power off from the user menu, I
still need to press Alt to get that option. 

Will Fedora 15 attempt to recognize systems that are known not to
support the default behavior? And/or is there a way (through gsettings I
guess it would be?) for users to change this so we don't have to press
Alt every time?

Michael Knepher

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

[Fedora QA] #185: Request to join the ProvenTesters Group

[Fedora QA]

#185: Request to join the ProvenTesters Group
-+--
 Reporter:  henryhuang   |   Owner: 
 Type:  proventester request |  Status:  new
 Priority:  major|   Milestone: 
Component:  Proventester Mentor Request  | Version: 
 Keywords:   |  
-+--
 Hello Proventester Mentor Team,

 I have one-year experience as a QA engineer in a security company, working
 on RHEL 5.x testing. I would like to help making Fedora more stable with
 testing updates and new versions with my experience and passion.
 I am requesting a mentor to guide me.

 If you need more information just email me.
 Best wishes,
 Henry Huang

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

[Fedora QA] #184: Request to join the ProvenTesters Group

[Fedora QA]

#184: Request to join the ProvenTesters Group
-+--
 Reporter:  henryhuang   |   Owner: 
 Type:  proventester request |  Status:  new
 Priority:  major|   Milestone: 
Component:  Proventester Mentor Request  | Version: 
 Keywords:   |  
-+--
 Hello Proventester Mentor Team,

 I have one-year experience as a QA engineer in a security company, working
 on RHEL 5.x testing. I would like to help making Fedora more stable with
 testing updates and new versions with my experience and passion.
 I am requesting a mentor to guide me.

 If you need more informations just email me.
 Best wishes,
 Henry Huang

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: since last update system does not boot any more

[Adam Williamson]

On Wed, 2011-04-06 at 17:06 +0200, Adam Pribyl wrote:
> On Tue, 5 Apr 2011, Adam Williamson wrote:
> 
> > On Tue, 2011-04-05 at 15:21 -0400, Richard Ryniker wrote:
> >
> >> I should think "3" presents very little problem for internationalization,
> >> whereas "multi-user.target" demands translation before it "explains
> >> itself" to non-English-speaking users.  Because these are descriptive
> >> file names, not just message text, and they are used fairly early in the
> >> boot process, I doubt translation is easy.  Feasible, certainly, but
> >> messy and therefore unlikely to happen.
> >
> > This is hardly an issue unique to systemd. Just about everything names
> > its files in English.
> 
> You are right. The problem with systemd is that those arguments are 
> filenames, but you can not use "tab" for autocompletition. ATM systemd can 
> translate "3" to multi-user.target which is OK, but in the future who 
> knows. Acctualy if I understand the concept right, maybe it is possible to 
> make symlink 3 -> multi-user.target, and it may work...

that's more or less what it does already.

[root@adam Download]# ls /lib/systemd/system/runlevel3.target -l
lrwxrwxrwx. 1 root root 17 Apr  5
09:58 /lib/systemd/system/runlevel3.target -> multi-user.target
[root@adam Download]#

i dunno exactly where it handles 'runlevel3', but...yeah.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Perl test case suggestions?

[Bruno Wolff III]

On Wed, Apr 06, 2011 at 11:08:08 -0400,
  James Laska  wrote:
> 
> Is that something a tester should validate from the koji build logs?
> Meaning, check whether %check ran, and passed?

I don't know if anyone runs %check for perl modules now, but it sounds like a
good idea to start doing that where it won't cause problems. Some of the
tests may do things that we don't want to do while doing automated building,
but I expect it would be fine for most perl modules.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Perl test case suggestions?

[James Laska]

On Wed, 2011-04-06 at 09:48 -0500, Bruno Wolff III wrote:
> On Wed, Apr 06, 2011 at 10:45:16 -0400,
>   James Laska  wrote:
> > Greetings folks,
> > 
> > I'm not a perl user, and it's been *some* time since I last knowingly
> > opened up a perl script.  While providing some karma feedback for a
> > recent perl update, it occurred that it might be nice to have a few
> > sample perl test cases linked from the bodhi update request.
> > 
> > Does anyone have any perl test case suggestions that we can add to
> > https://fedoraproject.org/wiki/Category:Package_perl_test_cases ?
> 
> It is fairly normal for perl modules to come with test cases. I am not
> sure of what you need to do to run them as they are installed, but it is
> normal to run them when building them from source.

Is that something a tester should validate from the koji build logs?
Meaning, check whether %check ran, and passed?

Anything else to consider?

Thanks,
James


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: since last update system does not boot any more

[Adam Pribyl]

On Tue, 5 Apr 2011, Adam Williamson wrote:

> On Tue, 2011-04-05 at 15:21 -0400, Richard Ryniker wrote:
>
>> I should think "3" presents very little problem for internationalization,
>> whereas "multi-user.target" demands translation before it "explains
>> itself" to non-English-speaking users.  Because these are descriptive
>> file names, not just message text, and they are used fairly early in the
>> boot process, I doubt translation is easy.  Feasible, certainly, but
>> messy and therefore unlikely to happen.
>
> This is hardly an issue unique to systemd. Just about everything names
> its files in English.

You are right. The problem with systemd is that those arguments are 
filenames, but you can not use "tab" for autocompletition. ATM systemd can 
translate "3" to multi-user.target which is OK, but in the future who 
knows. Acctualy if I understand the concept right, maybe it is possible to 
make symlink 3 -> multi-user.target, and it may work...

> -- 
> Adam Williamson

Adam Pribyl
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Gnome shell corruption

[Adam Pribyl]

Does anybody know about any setup option (gnome/gtk/radeon driver) that 
may cause corruptions as shown in this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=679579

PNG: https://bugzilla.redhat.com/attachment.cgi?id=480275

I tried to use various video modes, color depths etc, but there is no 
difference.


Thanks for any hint.

Adam Pribyl
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Perl test case suggestions?

[Bruno Wolff III]

On Wed, Apr 06, 2011 at 10:45:16 -0400,
  James Laska  wrote:
> Greetings folks,
> 
> I'm not a perl user, and it's been *some* time since I last knowingly
> opened up a perl script.  While providing some karma feedback for a
> recent perl update, it occurred that it might be nice to have a few
> sample perl test cases linked from the bodhi update request.
> 
> Does anyone have any perl test case suggestions that we can add to
> https://fedoraproject.org/wiki/Category:Package_perl_test_cases ?

It is fairly normal for perl modules to come with test cases. I am not
sure of what you need to do to run them as they are installed, but it is
normal to run them when building them from source.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Perl test case suggestions?

[James Laska]

Greetings folks,

I'm not a perl user, and it's been *some* time since I last knowingly
opened up a perl script.  While providing some karma feedback for a
recent perl update, it occurred that it might be nice to have a few
sample perl test cases linked from the bodhi update request.

Does anyone have any perl test case suggestions that we can add to
https://fedoraproject.org/wiki/Category:Package_perl_test_cases ?

Thanks,
James


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: fallback from gnome-shell to the old desktop not satisfying since some days

[Jason D. Clinton]

On Wed, Apr 6, 2011 at 01:05, Joachim Backes
 wrote:
> Hi Michael, I'm sorry, but there is no user menu at the right side of the
> panel. Only Applications and Places menu at the panel's left side.

This will fix it:
gconftool-2 --recursive-unset /apps/panel
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Karma feedback needed for anaconda-15.26-1, systemd-23-1.fc15 and filesystem-2.4.40-1.fc15

[James Laska]

On Wed, 2011-04-06 at 07:36 -0400, James Laska wrote:
> On Wed, 2011-04-06 at 03:45 -0400, Kamil Paral wrote:
> > > > > 2. The system won't boot without selinux=0.
> > > > > 3. With selinux=0 the system boots, but firstboot crashes on last
> > > > > page ("send hardware profile") and thus restarts on every boot.
> > > >
> > > > Looks like we'll need a bug against firstboot. Is there a firstboot
> > > > traceback file in /tmp ?
> > > 
> > > Interesting. I'm not seeing a crash, but systemd does seem to take
> > > over
> > > and start GDM while firstboot is still running. If I change tty's, I
> > > can find that firstboot is still up at the hardware profile step.
> > 
> > Ah, yes, that's exactly my issue too. I thought it was a crash, but I 
> > didn't find any logs. Now I know why.
> > 
> > Should I file BZ or is it already reported?
> 
> Let's get a bug reported for this one.  I'm not seeing this issue
> already reported against systemd (or firstboot).  I suspect we'll need
> to run with systemd.log_level=debug to capture the details.  I'm trying
> this myself at the moment ... will report back if I have any luck.

https://bugzilla.redhat.com/show_bug.cgi?id=694079

Thanks,
James


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Karma feedback needed for anaconda-15.26-1, systemd-23-1.fc15 and filesystem-2.4.40-1.fc15

[James Laska]

On Wed, 2011-04-06 at 03:45 -0400, Kamil Paral wrote:
> > > > 2. The system won't boot without selinux=0.
> > > > 3. With selinux=0 the system boots, but firstboot crashes on last
> > > > page ("send hardware profile") and thus restarts on every boot.
> > >
> > > Looks like we'll need a bug against firstboot. Is there a firstboot
> > > traceback file in /tmp ?
> > 
> > Interesting. I'm not seeing a crash, but systemd does seem to take
> > over
> > and start GDM while firstboot is still running. If I change tty's, I
> > can find that firstboot is still up at the hardware profile step.
> 
> Ah, yes, that's exactly my issue too. I thought it was a crash, but I didn't 
> find any logs. Now I know why.
> 
> Should I file BZ or is it already reported?

Let's get a bug reported for this one.  I'm not seeing this issue
already reported against systemd (or firstboot).  I suspect we'll need
to run with systemd.log_level=debug to capture the details.  I'm trying
this myself at the moment ... will report back if I have any luck.

Thanks,
james



signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Karma feedback needed for anaconda-15.26-1, systemd-23-1.fc15 and filesystem-2.4.40-1.fc15

[Kamil Paral]

> > > 2. The system won't boot without selinux=0.
> > > 3. With selinux=0 the system boots, but firstboot crashes on last
> > > page ("send hardware profile") and thus restarts on every boot.
> >
> > Looks like we'll need a bug against firstboot. Is there a firstboot
> > traceback file in /tmp ?
> 
> Interesting. I'm not seeing a crash, but systemd does seem to take
> over
> and start GDM while firstboot is still running. If I change tty's, I
> can find that firstboot is still up at the hardware profile step.

Ah, yes, that's exactly my issue too. I thought it was a crash, but I didn't 
find any logs. Now I know why.

Should I file BZ or is it already reported?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test