Re: bizarre yum

[Robert G. (Doc) Savage]

On Thu, 2010-08-12 at 11:51 -0600, Michal Jaegermann wrote:
> It appears that alchemist is gone in F14.  It was installed by
> default previously and it depends on python 2.6 and seemingly noting
> "obsoletes" it or provides something to satisfy dependencies and/or
> force a replacement.  Most likely more people doing updates of that
> sort will bump into the issue.

Michal,

That rings a bell. A fix to system-config-http in May might have removed
the last requirement for alchemist. See
https://bugzilla.redhat.com/show_bug.cgi?id=528638#c12

--Doc Savage
  Fairview Heights, IL

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

[Test-Announce] Fedora 14 Alpha RC4 Available Now!

[Andre Robatino]

Fedora 14 Alpha RC4 is now available [1].  Please refer to the following
pages for download links and testing instructions.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha priority test cases for installation [2] and desktop
[3] should pass in order to meet the Alpha Release Criteria [4].  Help
is available on #fedora-qa on irc.freenode.net [5], or on the test list [6].

[1] http://poelstra.fedorapeople.org/schedules/f-14/f-14-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[4] https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria
[5] irc://irc.freenode.net/fedora-qa
[6] https://admin.fedoraproject.org/mailman/listinfo/test



signature.asc
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!

[Bruno Wolff III]

On Wed, Aug 11, 2010 at 09:46:41 -0700,
  Adam Williamson  wrote:
> On Wed, 2010-08-11 at 14:21 +0100, Tommy He wrote:
> 
> > > I just tried x86_64 live build, but it's unable to boot, system fell to
> > > totally black screen where grub manual was supposed to be shown.[1]
> 
> > Same problem here with i686 LiveCD. Tested on VirtualBox and real machine.
> 
> Turns out a bug relating to live CD composing was fixed in F14 but not
> F13, and these images were built with F13 :(. Dennis is currently
> re-generating the live images after fixing that bug, the fixed images
> will be uploaded soon. We'll send an announce when they're available.

There should be a backport of the patch that handles the new locations
of some of the images in a way that will also work with the old locations.
Probably after the next patch rollup is applied to F14 livecd-tools and
gets some testing, we'll just bring the whole thing back to F13.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Patrick Lists]

On 08/13/2010 12:09 AM, Adam Williamson wrote:
> On Thu, 2010-08-12 at 23:59 +0200, Patrick Lists wrote:
>> On 08/12/2010 10:43 PM, Adam Williamson wrote:
>>> On Thu, 2010-08-12 at 22:35 +0200, François Cami wrote:
>>>
 OK here on RV410 (Radeon X700 Pro, R400 family), using KMS.
 I will be testing older cards (Radeon 7500, FireGL 8800) as time permits.
>>>
>>> Thanks, Francois! Jerome mentioned he has a reproducer now, a specific
>>> monitor, but the testing is still useful to help us figure out how wide
>>> the impact of this is.
>>
>> Just tested the boot.iso you mentioned earlier on an Acer laptop
>> (TM6465WLMi) with an ATI X1300 videocard and it fails miserably when X
>> is started. The screen becomes totally greenish it first fading to
>> something more white. Looks quite scary so I quickly took a photo and
>> switched of the laptop. Picture here:
>> http://www.xs4all.nl/~pjl/tmp/F14_screen_with_X_started.jpg
>
> Interesting. Seems somewhat different from the reported bug, though.
> Could you test one of the RC3.1 live images and see if they do the same?
> Thanks!

Acer laptop TM6465WMLi with X1300:

The RC3.1 x86_64 live image boots fine into KMS mode. I can see the 
Fedora logo getting whiter in steps from bottom left towards the top 
right. I used a cd that was too small for the image (used overburn) so 
didn't get to the actual desktop. If that's important let me know and 
I'll burn it on a dvd.

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

Fedora 14 Blocker Bug Review Meeting 2010-08-13 @ 16:00 UTC (12 PM EST)

[John Poelstra]

Subject: Fedora 14 Blocker Bug Review Meeting 2010-08-13 @ 16:00 UTC (12 
PM EST)

When: Friday, 2010-08-13 @ 16:00 UTC (12 PM EST)
Where: #fedora-bugzappers on irc.freenode.net

Here are the current bugs listed as blocking the Alpha release. We'll be 
discussing all of these to determine if they meet the criteria, should 
stay on the list, and are getting the attention they need:

596985 :: NEW :: xorg-x11-drv-ati :: Jerome Glisse :: hang at start of 
X11 on fresh install from DVD :: 
https://bugzilla.redhat.com/show_bug.cgi?id=596985

We will also start looking at the Beta blocker bugs as we change our 
mindframe to start focusing on the criteria for the beta:

623126 :: NEW :: anaconda :: Anaconda Maintenance Team :: F14 Alpha RC3 
CD install fails :: https://bugzilla.redhat.com/show_bug.cgi?id=623126
618504 :: NEW :: xmlrpc-c :: Enrico Scholz :: Can not submit abrt bugs 
:: https://bugzilla.redhat.com/show_bug.cgi?id=618504
621027 :: NEW :: fedora-logos :: Tom "spot" Callaway :: Graphical screen 
in anaconda shows F-13 :: https://bugzilla.redhat.com/show_bug.cgi?id=621027
615386 :: ASSIGNED :: autofs :: Ian Kent :: automount[3035]: 
open_lookup:90: cannot open lookup module ldap 
(/usr/lib64/autofs/lookup_ldap.so: undefined symbol: 
krb5_get_init_creds_keytab) :: 
https://bugzilla.redhat.com/show_bug.cgi?id=615386
623257 :: ASSIGNED :: polkit-gnome :: David Zeuthen :: Authentication 
agent does not work :: https://bugzilla.redhat.com/show_bug.cgi?id=623257
621685 :: MODIFIED :: anaconda :: Brian C. Lane :: TypeError: sequence 
item 0: expected string, NoneType found :: 
https://bugzilla.redhat.com/show_bug.cgi?id=621685

If you are the owner of any of these bugs, kindly update the comments 
with your feedback as to whether you believe it is a blocker and what 
your plans for fixing the bug are.

Do you have an issue you believe should be fixed before the Fedora 14 
Beta ships?  Please consider the following criteria when escalating an 
issue: https://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria

Hope to see everyone tomorrow.

John

The command used to generate the list of bugs above is:

$ bugzilla query --blocked=611991 \
 
--bug_status=NEW,ASSIGNED,NEEDINFO,ON_DEV,MODIFIED,POST,ON_QA,FAILS_QA,PASSES_QA,REOPENED,VERIFIED,RELEASE_PENDING
 
\
 --outputformat="%{bug_id} :: %{bug_status} :: %{component} :: 
%{assigned_to} :: %{summary} :: %{url}"
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[François Cami]

On Fri, Aug 13, 2010 at 12:25 AM, Patrick Lists
 wrote:
> On 08/13/2010 12:23 AM, Clyde E. Kunkel wrote:
> [snip]
>> Using nomodeset allows x to start on a:
>>
>> $ lspci | grep VGA
>> 01:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD
>> 2600 Series]
>
> Is nomodeset different from radeon.modeset=0? In other words should I
> test this too besides radeon.modeset=0?

Either one is fine.

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

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Patrick Lists]

On 08/13/2010 12:23 AM, Clyde E. Kunkel wrote:
[snip]
> Using nomodeset allows x to start on a:
>
> $ lspci | grep VGA
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD
> 2600 Series]

Is nomodeset different from radeon.modeset=0? In other words should I 
test this too besides radeon.modeset=0?

Regards,
Patrick

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

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Patrick Lists]

On 08/13/2010 12:04 AM, François Cami wrote:
> On Thu, Aug 12, 2010 at 11:59 PM, Patrick Lists
>   wrote:
>> On 08/12/2010 10:43 PM, Adam Williamson wrote:
>>> On Thu, 2010-08-12 at 22:35 +0200, François Cami wrote:
>>>
 OK here on RV410 (Radeon X700 Pro, R400 family), using KMS.
 I will be testing older cards (Radeon 7500, FireGL 8800) as time permits.
>>>
>>> Thanks, Francois! Jerome mentioned he has a reproducer now, a specific
>>> monitor, but the testing is still useful to help us figure out how wide
>>> the impact of this is.
>>
>> Just tested the boot.iso you mentioned earlier on an Acer laptop
>> (TM6465WLMi) with an ATI X1300 videocard and it fails miserably when X
>> is started. The screen becomes totally greenish it first fading to
>> something more white.
>
> What happens when you add radeon.modeset=0 on the CD command line?

I see this twice. Don't know if that's relevant but just in case:
Detecting hardware
Waiting for hardware to initialize
Detecting hardware
Waiting for hardware to initialize

Then it wants to start X, screen goes black, flickers a couple of times 
and then the kernel crashes.

Pictures here:

http://www.xs4all.nl/~pjl/tmp/20100813_001.jpg
http://www.xs4all.nl/~pjl/tmp/20100813_002.jpg
http://www.xs4all.nl/~pjl/tmp/20100813_003.jpg
http://www.xs4all.nl/~pjl/tmp/20100813_004.jpg

Regards,
Patrick




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

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Clyde E. Kunkel]

On 08/12/2010 01:59 PM, Adam Williamson wrote:
> Hi, everyone. So, we have one bug remaining for Fedora 14 whose blocker
> status is unclear:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=596985
>
> Two reporters in the bug - John Reiser and Mike Chambers - and one
> reporter from the list - Rui He,
> http://lists.fedoraproject.org/pipermail/test/2010-August/092583.html -
> report that the screen is blanked when the installer starts X on various
> Radeon adapters when booted with default options. The system is still
> running and you can switch to a virtual console to get logs - see
> https://bugzilla.redhat.com/show_bug.cgi?id=596985#c36 - but the screen
> is permanently blank until reboot. When booted with 'basic video driver'
> - which, due to an anaconda bug, actually results in the use of the
> radeon driver, but with kernel modesetting disabled - the installer is
> able to run X normally, for all three. One further reporter, Chuck
> Forsberg -
> http://lists.fedoraproject.org/pipermail/test/2010-August/092581.html -
> had problems with both default and 'basic video mode' (radeon+UMS).
>
> Jerome Glisse reports that he was able to start X and see the display in
> the installer with one or some of his own test cards.
>
> What we need here is more data. So it would be really useful if everyone
> on this list with a Radeon video adapter could test this. It's fairly
> quick and easy and doesn't require you to actually complete an install.
> Just get the boot.iso for RC3 (currently) or RC4 (later today, likely) -
> the boot.iso for RC3 is at
> http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC3/Fedora/x86_64/os/images/boot.iso
>  or 
> http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC3/Fedora/i386/os/images/boot.iso
>  - boot it, and see if you can make it to the graphical stage of the 
> installation process. Please reply here, and if you observe the same problem 
> as the reporters, add your details to the bug report (also test the 'basic 
> graphics driver' choice, and report whether you used rc3 or rc4, and x86-64 
> or i386). Thanks!

Using nomodeset allows x to start on a:

$ lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 
2600 Series]

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

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Patrick Lists]

On 08/13/2010 12:12 AM, Patrick Lists wrote:
> On 08/12/2010 10:43 PM, Adam Williamson wrote:
>> On Thu, 2010-08-12 at 22:35 +0200, François Cami wrote:
>>
>>> OK here on RV410 (Radeon X700 Pro, R400 family), using KMS.
>>> I will be testing older cards (Radeon 7500, FireGL 8800) as time permits.
>>
>> Thanks, Francois! Jerome mentioned he has a reproducer now, a specific
>> monitor, but the testing is still useful to help us figure out how wide
>> the impact of this is.
>
> Also tested a box with a Gigabyte X58 board and an ATI HD 5970 PCI-E
> card and when X starts the screen goes black then I see a popup from the
> monitor that no signal was detected. Then nothing. The screen stays
> black and the led on the monitor goes orange which is basically saying
> it's got nothing to do. The monitor is an Iiyama Prolite B2409 HDS
> connected via a DVI cable.

Maybe the output of lspci -v of the card is of use:

09:00.0 Display controller: ATI Technologies Inc Device 689c
Subsystem: ATI Technologies Inc Device 2042
Flags: bus master, fast devsel, latency 0, IRQ 55
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at fb6e (64-bit, non-prefetchable) [size=128K]
I/O ports at 8e00 [size=256]
Expansion ROM at fb60 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 

Capabilities: [150] Advanced Error Reporting
Kernel driver in use: radeon
Kernel modules: radeon

Will also try radeon.modeset=0 and report back.

Regards,
Patrick


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

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Patrick Lists]

On 08/12/2010 10:43 PM, Adam Williamson wrote:
> On Thu, 2010-08-12 at 22:35 +0200, François Cami wrote:
>
>> OK here on RV410 (Radeon X700 Pro, R400 family), using KMS.
>> I will be testing older cards (Radeon 7500, FireGL 8800) as time permits.
>
> Thanks, Francois! Jerome mentioned he has a reproducer now, a specific
> monitor, but the testing is still useful to help us figure out how wide
> the impact of this is.

Also tested a box with a Gigabyte X58 board and an ATI HD 5970 PCI-E 
card and when X starts the screen goes black then I see a popup from the 
monitor that no signal was detected. Then nothing. The screen stays 
black and the led on the monitor goes orange which is basically saying 
it's got nothing to do. The monitor is an Iiyama Prolite B2409 HDS 
connected via a DVI cable.

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

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Adam Williamson]

On Thu, 2010-08-12 at 23:59 +0200, Patrick Lists wrote:
> On 08/12/2010 10:43 PM, Adam Williamson wrote:
> > On Thu, 2010-08-12 at 22:35 +0200, François Cami wrote:
> >
> >> OK here on RV410 (Radeon X700 Pro, R400 family), using KMS.
> >> I will be testing older cards (Radeon 7500, FireGL 8800) as time permits.
> >
> > Thanks, Francois! Jerome mentioned he has a reproducer now, a specific
> > monitor, but the testing is still useful to help us figure out how wide
> > the impact of this is.
> 
> Just tested the boot.iso you mentioned earlier on an Acer laptop 
> (TM6465WLMi) with an ATI X1300 videocard and it fails miserably when X 
> is started. The screen becomes totally greenish it first fading to 
> something more white. Looks quite scary so I quickly took a photo and 
> switched of the laptop. Picture here:
> http://www.xs4all.nl/~pjl/tmp/F14_screen_with_X_started.jpg

Interesting. Seems somewhat different from the reported bug, though.
Could you test one of the RC3.1 live images and see if they do the same?
Thanks!
-- 
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: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[François Cami]

On Thu, Aug 12, 2010 at 11:59 PM, Patrick Lists
 wrote:
> On 08/12/2010 10:43 PM, Adam Williamson wrote:
>> On Thu, 2010-08-12 at 22:35 +0200, François Cami wrote:
>>
>>> OK here on RV410 (Radeon X700 Pro, R400 family), using KMS.
>>> I will be testing older cards (Radeon 7500, FireGL 8800) as time permits.
>>
>> Thanks, Francois! Jerome mentioned he has a reproducer now, a specific
>> monitor, but the testing is still useful to help us figure out how wide
>> the impact of this is.
>
> Just tested the boot.iso you mentioned earlier on an Acer laptop
> (TM6465WLMi) with an ATI X1300 videocard and it fails miserably when X
> is started. The screen becomes totally greenish it first fading to
> something more white.

What happens when you add radeon.modeset=0 on the CD command line?

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

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Patrick Lists]

On 08/12/2010 10:43 PM, Adam Williamson wrote:
> On Thu, 2010-08-12 at 22:35 +0200, François Cami wrote:
>
>> OK here on RV410 (Radeon X700 Pro, R400 family), using KMS.
>> I will be testing older cards (Radeon 7500, FireGL 8800) as time permits.
>
> Thanks, Francois! Jerome mentioned he has a reproducer now, a specific
> monitor, but the testing is still useful to help us figure out how wide
> the impact of this is.

Just tested the boot.iso you mentioned earlier on an Acer laptop 
(TM6465WLMi) with an ATI X1300 videocard and it fails miserably when X 
is started. The screen becomes totally greenish it first fading to 
something more white. Looks quite scary so I quickly took a photo and 
switched of the laptop. Picture here:
http://www.xs4all.nl/~pjl/tmp/F14_screen_with_X_started.jpg

Regards,
Patrick

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

Broken dependencies with Fedora 14 + updates-testing - 2010-08-12

[Michael Schwendt]

==
The results in this summary consider Test Updates!
==

Fixed packages compared with F-14 Branched report:

LuxRender
avogadro
bastet
easystroke
fuse-encfs
glom
gnomeradio
kdeedu
mkvtoolnix
perl-Pugs-Compiler-Rule
pulsecaster
python-docs
python-eventlet
qgis
sugar-paint
wesnoth


Still broken compared with F-14 Branched report:

51 builds


Additional broken packages (by src.rpm name):

devhelp
gcc
libguestfs
nautilus-sendto
nautilus-sound-converter
pidgin
python-webdav-library




==
Broken packages in fedora-14-development-x86_64:

gcc-gfortran-4.5.0-3.fc14.i686  requires  libgfortran = 0:4.5.0-3.fc14
gcc-gfortran-4.5.0-3.fc14.i686  requires  gcc = 0:4.5.0-3.fc14


==
Broken packages in fedora-updates-testing-14-i386:

1:devhelp-devel-2.31.6-2.fc14.i686  requires  gtk-devel >= 0:2.20
1:libguestfs-1.5.2-5.fc14.i686  requires  /lib/libxtables.so.4
1:nautilus-sendto-2.31.6-3.fc14.i686  requires  libcamel-1.2.so.19
nautilus-sound-converter-1.0.5-5.fc14.i686  requires  
libgnome-media-profiles-3.0.so.0
pidgin-evolution-2.7.3-1.fc14.i686  requires  libcamel-1.2.so.19
pidgin-evolution-2.7.3-1.fc14.i686  requires  libedata-book-1.2.so.8
python-webdav-library-0.2.0-1.fc14.noarch  requires  python-icalendar


==
Broken packages in fedora-updates-testing-14-x86_64:

1:devhelp-devel-2.31.6-2.fc14.i686  requires  gtk-devel >= 0:2.20
1:devhelp-devel-2.31.6-2.fc14.x86_64  requires  gtk-devel >= 0:2.20
1:libguestfs-1.5.2-5.fc14.i686  requires  /lib/libxtables.so.4
1:libguestfs-1.5.2-5.fc14.x86_64  requires  /lib64/libxtables.so.4
1:nautilus-sendto-2.31.6-3.fc14.x86_64  requires  
libcamel-1.2.so.19()(64bit)
nautilus-sound-converter-1.0.5-5.fc14.x86_64  requires  
libgnome-media-profiles-3.0.so.0()(64bit)
pidgin-evolution-2.7.3-1.fc14.x86_64  requires  libcamel-1.2.so.19()(64bit)
pidgin-evolution-2.7.3-1.fc14.x86_64  requires  
libedata-book-1.2.so.8()(64bit)
python-webdav-library-0.2.0-1.fc14.noarch  requires  python-icalendar
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Adam Williamson]

On Thu, 2010-08-12 at 22:35 +0200, François Cami wrote:

> OK here on RV410 (Radeon X700 Pro, R400 family), using KMS.
> I will be testing older cards (Radeon 7500, FireGL 8800) as time permits.

Thanks, Francois! Jerome mentioned he has a reproducer now, a specific
monitor, but the testing is still useful to help us figure out how wide
the impact of this is.
-- 
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: Need updated desktop-backgrounds-compat

[Martin Sourada]

On Wed, 2010-08-04 at 11:04 -0700, Steven I Usdansky wrote: 
> ~$ rpm -e --test goddard-backgrounds-single
> error: Failed dependencies:
> goddard-backgrounds-single is needed by (installed) 
> desktop-backgrounds-compat-9.0.0-14.noarch
> ~$ rpm -e --test goddard-backgrounds-single desktop-backgrounds-compat
> error: Failed dependencies:
> desktop-backgrounds-compat is needed by (installed) 
> lxdm-0.2.0-4.fc14.x86_64
> desktop-backgrounds-compat is needed by (installed) 
> lxde-common-0.5.4-2.fc14.noarch
> 
> ~$ rpm -q --requires desktop-backgrounds-compat
> goddard-backgrounds-single  

Hey, can you try out:
http://admin.fedoraproject.org/updates/desktop-backgrounds-9.0.0-15.fc14

Martin



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: [Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[François Cami]

On Thu, Aug 12, 2010 at 7:59 PM, Adam Williamson  wrote:
> Hi, everyone. So, we have one bug remaining for Fedora 14 whose blocker
> status is unclear:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=596985
>
> Two reporters in the bug - John Reiser and Mike Chambers - and one
> reporter from the list - Rui He,
> http://lists.fedoraproject.org/pipermail/test/2010-August/092583.html -
> report that the screen is blanked when the installer starts X on various
> Radeon adapters when booted with default options. The system is still
> running and you can switch to a virtual console to get logs - see
> https://bugzilla.redhat.com/show_bug.cgi?id=596985#c36 - but the screen
> is permanently blank until reboot. When booted with 'basic video driver'
> - which, due to an anaconda bug, actually results in the use of the
> radeon driver, but with kernel modesetting disabled - the installer is
> able to run X normally, for all three. One further reporter, Chuck
> Forsberg -
> http://lists.fedoraproject.org/pipermail/test/2010-August/092581.html -
> had problems with both default and 'basic video mode' (radeon+UMS).
>
> Jerome Glisse reports that he was able to start X and see the display in
> the installer with one or some of his own test cards.
>
> What we need here is more data. So it would be really useful if everyone
> on this list with a Radeon video adapter could test this. It's fairly
> quick and easy and doesn't require you to actually complete an install.
> Just get the boot.iso for RC3 (currently) or RC4 (later today, likely) -
> the boot.iso for RC3 is at
> http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC3/Fedora/x86_64/os/images/boot.iso
>  or 
> http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC3/Fedora/i386/os/images/boot.iso
>  - boot it, and see if you can make it to the graphical stage of the 
> installation process. Please reply here, and if you observe the same problem 
> as the reporters, add your details to the bug report (also test the 'basic 
> graphics driver' choice, and report whether you used rc3 or rc4, and x86-64 
> or i386). Thanks!

OK here on RV410 (Radeon X700 Pro, R400 family), using KMS.
I will be testing older cards (Radeon 7500, FireGL 8800) as time permits.

Cheers

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

Re: F14 LXDE alpha rc3.1 Live USB

[Christoph Wickert]

Am Donnerstag, den 12.08.2010, 07:27 -0700 schrieb Adam Williamson:
> On Thu, 2010-08-12 at 05:05 -0700, Steven I Usdansky wrote:
> > It boots. The browser works. Updates work. But...
> > When X starts,  pcmanfm --desktop  is not autostarted; the background
> > consists of text from the boot process, and dragging a window around 
> > on the screen leaves an ugly trail.  Running  pcmanfm --desktop  for
> > the first time brings a solid black desktop rather than the default
> > background image.

Uh, this was due to the pcmanfm2 -> pcmanfm renaming.

> Yeah, I noticed the same. LXDE folks take note! Thanks :)

Fixed in
http://git.fedorahosted.org/git?p=spin-kickstarts.git;a=commit;h=c977a972ff5b0c27361ab414bd320960a5afecd6

Thanks for the heads up,
Christoph

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

[Test-Announce] Call for testing: F14 Alpha RC3/RC4 with Radeon graphics adapters

[Adam Williamson]

Hi, everyone. So, we have one bug remaining for Fedora 14 whose blocker
status is unclear:

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

Two reporters in the bug - John Reiser and Mike Chambers - and one
reporter from the list - Rui He,
http://lists.fedoraproject.org/pipermail/test/2010-August/092583.html -
report that the screen is blanked when the installer starts X on various
Radeon adapters when booted with default options. The system is still
running and you can switch to a virtual console to get logs - see
https://bugzilla.redhat.com/show_bug.cgi?id=596985#c36 - but the screen
is permanently blank until reboot. When booted with 'basic video driver'
- which, due to an anaconda bug, actually results in the use of the
radeon driver, but with kernel modesetting disabled - the installer is
able to run X normally, for all three. One further reporter, Chuck
Forsberg -
http://lists.fedoraproject.org/pipermail/test/2010-August/092581.html -
had problems with both default and 'basic video mode' (radeon+UMS).

Jerome Glisse reports that he was able to start X and see the display in
the installer with one or some of his own test cards.

What we need here is more data. So it would be really useful if everyone
on this list with a Radeon video adapter could test this. It's fairly
quick and easy and doesn't require you to actually complete an install.
Just get the boot.iso for RC3 (currently) or RC4 (later today, likely) -
the boot.iso for RC3 is at
http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC3/Fedora/x86_64/os/images/boot.iso
 or 
http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Alpha.RC3/Fedora/i386/os/images/boot.iso
 - boot it, and see if you can make it to the graphical stage of the 
installation process. Please reply here, and if you observe the same problem as 
the reporters, add your details to the bug report (also test the 'basic 
graphics driver' choice, and report whether you used rc3 or rc4, and x86-64 or 
i386). Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: bizarre yum

[Michal Jaegermann]

On Thu, Aug 12, 2010 at 08:28:02AM +0100, M A Young wrote:
> On Wed, 11 Aug 2010, Felix Miata wrote:
> >
> > Result:
> > 119 packages installed, among them freetype, kde, fontconfig-devel, akonadi,
> > qt-webkit, libXinerama-devel, libchamplain-gtk, amarok, qt-webkit, BackupPC,
> > compat-gdbm
> 
> The change from python 2.6 to python 2.7 may be holding you up if you have 
> packages installed that haven't been recompiled for python 2.7 in F14 
> yet, or if you have other packages that use python that aren't in F14.

It appears that alchemist is gone in F14.  It was installed by
default previously and it depends on python 2.6 and seemingly noting
"obsoletes" it or provides something to satisfy dependencies and/or
force a replacement.  Most likely more people doing updates of that
sort will bump into the issue.

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

testing, karma love for gnupg2-2.0.13-2.fc12

[Rex Dieter]

Test it out, give some karma, you know you want to!

https://admin.fedoraproject.org/updates/gnupg2-2.0.13-2.fc12

-- Rex

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

AFK for couple of days..

[Jóhann B. Guðmundsson]

 I will be wandering woods shooting what ever crosses my path and 
feasting myself on wild boars in a archery tournament in Sweden the 
coming day's hence I will be more or less off line from tomorrow 13 to 
18 August.


Keep up the good work while I'm gone..

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

Re: Radeon HD5670: Aug 11 Live CD Works, Install DVD Doesn't

[Adam Williamson]

On Thu, 2010-08-12 at 10:03 -0700, Chuck Forsberg WA7KGX N2469R wrote:
> The August 11 386 live image boots and runs on my
> office machine consisisting of a Core Duo E8500,
> 8 GB RAM, Gigabyte GA-EP45-UD3P, Radeon HD5670.
> The graphic install to HD was successful, and the
> resultant disk image booted (albeit verry slowly)
> and came up in X.  No 3d but 2d beats dead screen.
> This is the first time I've tried a Fedora 14 Live CD.
> 
> I then downloaded the Aug 11 386 install DVD.  It
> took two tries as the first download failed the
> checksum.   The incompatibility
> with the HD5670 is unchanged, only now it takes a
> long time to get to that point.

with RC4, 'basic video driver' at least ought to work. We're going to
try and get more data about the Radeon problem (how many adapters it
affects).
-- 
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: why, oh why (do gtk2 pkgs depend on gtk3 pkgs)?

[Adam Williamson]

On Thu, 2010-08-12 at 12:12 -0400, Bill Nottingham wrote:
> Steven I Usdansky (usdans...@rocketmail.com) said: 
> > Trying to eliminate gtk3 packages from my F14 alpha rc 3.1 LXDE spin, I see:
> 
> It's in the process of being fixed.

...but won't be fixed for Alpha, due to the freeze; you'll have to wait
till post-Alpha. (Or adjust your kickstart to pull from updates-testing,
where the fixes should land a bit sooner).
-- 
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

Radeon HD5670: Aug 11 Live CD Works, Install DVD Doesn't

[Chuck Forsberg WA7KGX N2469R]

  The August 11 386 live image boots and runs on my
office machine consisisting of a Core Duo E8500,
8 GB RAM, Gigabyte GA-EP45-UD3P, Radeon HD5670.
The graphic install to HD was successful, and the
resultant disk image booted (albeit verry slowly)
and came up in X.  No 3d but 2d beats dead screen.
This is the first time I've tried a Fedora 14 Live CD.

I then downloaded the Aug 11 386 install DVD.  It
took two tries as the first download failed the
checksum.   The incompatibility
with the HD5670 is unchanged, only now it takes a
long time to get to that point.

-- 
Chuck Forsberg WA7KGX N2469R c...@omen.com   www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
   Omen Technology Inc  "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430

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

Bugzilla Broken

[Felix Miata]

Cannot change columns or select different sort key on search results page,
always (in black on red):

"You may not search, or create saved searches, without any search terms."
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: big gnome update

[Matthias Clasen]

On Thu, 2010-08-12 at 15:38 +0100, pbrobin...@gmail.com wrote:
> On Thu, Aug 12, 2010 at 2:59 PM, Matthias Clasen  wrote:
> > Hey,
> >
> > I've spent most of yesterday rebuilding things against gtk2, and
> > downgrading packages that needed it, so there is now a big update that
> > brings the gnome in f14 onto the 2.32 track. This update should fix most
> > of the 'mixed gtk2/gtk3' and dconf problems that have been plaguing f14
> > recently. The one thing still missing is empathy, where the 2.31 version
> > needs a new package that is still under review.
> 
> Was gnome-python2-evince added back into the fold as part of this work?

No, I haven't done that. But it is a good idea.

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

Re: why, oh why (do gtk2 pkgs depend on gtk3 pkgs)?

[Bill Nottingham]

Steven I Usdansky (usdans...@rocketmail.com) said: 
> Trying to eliminate gtk3 packages from my F14 alpha rc 3.1 LXDE spin, I see:

It's in the process of being fixed.

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

PTO Tomorrow Morning -> Aug 14

[He Rui]

Greeting,

I have an urgent thing to deal with tomorrow morning, will be back at noon.

Thanks,
Hurry

-- 
  Contacts

  FAS name: Rhe
  IRC nick: rhe #fedora-qa
  Email: r...@redhat.com


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

why, oh why (do gtk2 pkgs depend on gtk3 pkgs)?

[Steven I Usdansky]

Trying to eliminate gtk3 packages from my F14 alpha rc 3.1 LXDE spin, I see:

gnome-bluetooth-libs-2.90.0-4.fc14.i686 has missing requires of 
libgdk-x11-3.0.so.0
gnome-bluetooth-libs-2.90.0-4.fc14.i686 has missing requires of 
libgtk-x11-3.0.so.0
gnome-themes-2.31.6-1.fc14.noarch has missing requires of gtk3-engines
libcanberra-gtk2-0.25-2.fc14.i686 has missing requires of libcanberra-gtk3

Why do gtk2 packages require gtk3 packages?



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

F-14 Branched report: 20100812 changes

[Branched Report]

Compose started at Thu Aug 12 13:15:13 UTC 2010

Broken deps for x86_64
--
CGAL-3.6.1-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
CGAL-3.6.1-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_system-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_program_options-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_regex-mt.so.1.41.0()(64bit)
LuxRender-0.6.1-3.fc14.x86_64 requires 
libboost_iostreams-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_system-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_program_options-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_iostreams-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
LuxRender-core-0.6.1-3.fc14.x86_64 requires 
libboost_regex-mt.so.1.41.0()(64bit)
Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6
Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so
PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so
PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit)
PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit)
QuantLib-test-1.0.1-3.fc14.x86_64 requires 
libboost_unit_test_framework.so.1.41.0()(64bit)
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2
1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
avogadro-1.0.1-2.fc14.x86_64 requires 
libboost_python-mt.so.1.41.0()(64bit)
avogadro-libs-1.0.1-2.fc14.i686 requires libboost_python-mt.so.1.41.0
avogadro-libs-1.0.1-2.fc14.x86_64 requires 
libboost_python-mt.so.1.41.0()(64bit)
bastet-0.43-7.fc13.x86_64 requires 
libboost_program_options.so.1.41.0()(64bit)
cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10
cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
easystroke-0.5.3-1.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires 
libpython2.6.so.1.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libedata-book-1.2.so.2()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-1.2.so.17()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libgtkhtml-editor.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libebook-1.2.so.9()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-provider-1.2.so.17()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit)
fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10
fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit)
frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
fuse-encfs-1.5-12.fc14.i686 requires libboost_filesystem-mt.so.1.41.0
fuse-encfs-1.5-12.fc14.i686 requires libboost_serialization-mt.so.1.41.0
fuse-encfs-1.5-12.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
fuse-encfs-1.5-12.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_system-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_program_options-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.

Re: big gnome update

[pbrobin...@gmail.com]

On Thu, Aug 12, 2010 at 2:59 PM, Matthias Clasen  wrote:
> Hey,
>
> I've spent most of yesterday rebuilding things against gtk2, and
> downgrading packages that needed it, so there is now a big update that
> brings the gnome in f14 onto the 2.32 track. This update should fix most
> of the 'mixed gtk2/gtk3' and dconf problems that have been plaguing f14
> recently. The one thing still missing is empathy, where the 2.31 version
> needs a new package that is still under review.

Was gnome-python2-evince added back into the fold as part of this work?

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

Re: Release criteria proposal: basic graphics mode boot

[Adam Williamson]

On Thu, 2010-08-12 at 10:09 -0400, Adam Jackson wrote:
> On Wed, 2010-08-11 at 19:35 -0700, Adam Williamson wrote:
> > Another proposed release criterion. This stems from
> > https://bugzilla.redhat.com/show_bug.cgi?id=623129 ; we agreed that it
> > really ought to always be possible to workaround a broken X driver for
> > install.
> > 
> > Alpha: "The graphical boot menu for all installation images should
> > include an entry which causes both installation and the installed system
> > to use a generic, highly compatible video driver (such as 'vesa'). This
> > mechanism should work as described."
> 
> Rrrgh.  I've seen vesa break in too many ways to describe it as anything
> other than a best-effort solution.  So I guess my question is what the
> threshold is here.  Do we expect that vesa works on the plurality of
> hardware we test it on, or do we expect that it works on everything?

'Work as described' is intended to mean 'it should *actually* use vesa'.
It's just to cover the case of the current breakage (where the entry is
present but doesn't actually cause vesa to be used).

If you can think of clearer wording, that'd be great =)

> As an anecdote, we had one bit of hardware that won't be supported in
> RHEL 6.0 with a native driver because the upstream support isn't
> completed yet.  Naturally once we made this decision we discovered that
> vesa _also_ didn't work, because we were making some pretty fundamental
> assumptions about the vm86 memory map that the BIOS violated.  We fixed
> it, but if I hadn't had the machine in my cube it probably wouldn't have
> been done in time.

If you want to add another to your collection, try installing F14 into a
kvm vm and set vesa as the X driver and start X...for me, it blank
screens. Only the 'native' cirrus driver works.
-- 
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: F14 LXDE alpha rc3.1 Live USB

[Adam Williamson]

On Thu, 2010-08-12 at 05:05 -0700, Steven I Usdansky wrote:
> It boots. The browser works. Updates work. But...
> When X starts,  pcmanfm --desktop  is not autostarted; the background
> consists of text from the boot process, and dragging a window around 
> on the screen leaves an ugly trail.  Running  pcmanfm --desktop  for
> the first time brings a solid black desktop rather than the default
> background image.

Yeah, I noticed the same. LXDE folks take note! Thanks :)
-- 
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: Release criteria proposal: boot to console

[John Dulaney]

I vote yes to both Beta and Alpha proposals.

> Subject: Release criteria proposal: boot to console
> From: awill...@redhat.com
> To: test@lists.fedoraproject.org
> Date: Wed, 11 Aug 2010 19:19:30 -0700
> 
> Hi, folks. Quite a lot of release criteria proposals came out of today's
> go/no-go meeting. I'll propose them formally for discussion and addition
> to the official criteria here.
> 
> First off, we are missing criteria for booting to *console* rather than
> graphical desktop. This is important for e.g. minimal installs.
> 
> Proposal: two criteria. Alpha:
> 
> "When booting a system installed without a graphical environment, or
> when using a correct configuration setting to cause an installed system
> to boot in non-graphical mode, the system should boot to a state where
> it is possible to log in through at least one of the default virtual
> consoles."
> 
> Beta:
> 
> "When booting a system installed without a graphical environment, or
> when using a correct configuration setting to cause an installed system
> to boot in non-graphical mode, the system should provide a working login
> prompt without any user intervention (aside from the firstboot utility)
> when boot is complete, and all virtual consoles intended to provide a
> working login prompt should do so."
> 
> These read a bit icky to me, clarification / rephrasing would be
> welcome. The key point here is that it was quite widely agreed at the
> go/no-go meeting that we should *not* block an Alpha release if tty1
> doesn't work, as long as one of the other ttys works fine so you can log
> in properly just by doing ctrl-alt-f2 or whatever.
> -- 
> 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: Release criteria proposal: basic graphics mode boot

[John Dulaney]

I agree to both.  In some instances, if you boot the liveCD and you don't
have vesa available, then you won't be able to get to the install bit, as
I well know

John Dulaney

> Subject: Release criteria proposal: basic graphics mode boot
> From: awill...@redhat.com
> To: test@lists.fedoraproject.org
> Date: Wed, 11 Aug 2010 19:35:30 -0700
> 
> Another proposed release criterion. This stems from
> https://bugzilla.redhat.com/show_bug.cgi?id=623129 ; we agreed that it
> really ought to always be possible to workaround a broken X driver for
> install.
> 
> Alpha: "The graphical boot menu for all installation images should
> include an entry which causes both installation and the installed system
> to use a generic, highly compatible video driver (such as 'vesa'). This
> mechanism should work as described."
> 
> (I'd actually say live boot menu should have the same option, but
> currently it doesn't and we can't change the world with release
> criteria :> I'll try and work up a patch for that to propose).
> -- 
> 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: Release criteria proposal: basic graphics mode boot

[Adam Jackson]

On Wed, 2010-08-11 at 19:35 -0700, Adam Williamson wrote:
> Another proposed release criterion. This stems from
> https://bugzilla.redhat.com/show_bug.cgi?id=623129 ; we agreed that it
> really ought to always be possible to workaround a broken X driver for
> install.
> 
> Alpha: "The graphical boot menu for all installation images should
> include an entry which causes both installation and the installed system
> to use a generic, highly compatible video driver (such as 'vesa'). This
> mechanism should work as described."

Rrrgh.  I've seen vesa break in too many ways to describe it as anything
other than a best-effort solution.  So I guess my question is what the
threshold is here.  Do we expect that vesa works on the plurality of
hardware we test it on, or do we expect that it works on everything?

As an anecdote, we had one bit of hardware that won't be supported in
RHEL 6.0 with a native driver because the upstream support isn't
completed yet.  Naturally once we made this decision we discovered that
vesa _also_ didn't work, because we were making some pretty fundamental
assumptions about the vm86 memory map that the BIOS violated.  We fixed
it, but if I hadn't had the machine in my cube it probably wouldn't have
been done in time.

- ajax


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

big gnome update

[Matthias Clasen]

Hey,

I've spent most of yesterday rebuilding things against gtk2, and
downgrading packages that needed it, so there is now a big update that
brings the gnome in f14 onto the 2.32 track. This update should fix most
of the 'mixed gtk2/gtk3' and dconf problems that have been plaguing f14
recently. The one thing still missing is empathy, where the 2.31 version
needs a new package that is still under review.

I'd appreciate if people could give it a try.


Matthias

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

Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!

[Masami Ichikawa]

on 08/12/2010 04:00 AM, Vaclav Misek wrote:
>  On 08/11/2010 06:49 AM, Andre Robatino wrote:
> RC3 is definitely much better. Systemd problems were fixed and firstboot
> is run on my kvm virtual machine.
> I can't see any apparent problems during DVD install and first run.
I could install F14 by Live CD and DVD on kvm by virt-manager. I didn't see any 
critical problems during install and first run.
However, there are bit difference that I can see. That is when I login to F14 
which was installed by DVD iso, eth0 isn't acitve. so I need to activate it but 
the other F14 which was installed by Live CD system doesn't have same issue.

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

F14 LXDE alpha rc3.1 Live USB

[Steven I Usdansky]

It boots. The browser works. Updates work. But...
When X starts,  pcmanfm --desktop  is not autostarted; the background
consists of text from the boot process, and dragging a window around 
on the screen leaves an ugly trail.  Running  pcmanfm --desktop  for
the first time brings a solid black desktop rather than the default
background image.



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

rawhide report: 20100812 changes

[Rawhide Report]

Compose started at Thu Aug 12 08:15:16 UTC 2010

Broken deps for x86_64
--
Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6
Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so
PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so
PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit)
PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit)
QuantLib-test-1.0.1-3.fc14.x86_64 requires 
libboost_unit_test_framework.so.1.41.0()(64bit)
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2
1:anjuta-2.30.0.0-2.fc14.i686 requires libvala.so.0
1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libvala.so.0()(64bit)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10
cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
clusterssh-3.28-1.fc15.noarch requires xorg-x11-fonts\*
cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libedata-book-1.2.so.2()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-1.2.so.17()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libgtkhtml-editor.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libebook-1.2.so.9()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-provider-1.2.so.17()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit)
fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10
fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit)
frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_system-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_program_options-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_iostreams-mt.so.1.41.0()(64bit)
fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires 
libboost_serialization-mt.so.1.41.0()(64bit)
gedit-vala-0.6.1-1.fc13.x86_64 requires libvala.so.0()(64bit)
glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10
glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit)
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples
libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10
libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit)
libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10
libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10
libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10
libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit)
libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0
libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
libopenvrml-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
libopenvrml-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
libopenvrml-gl-0.18.6-1.fc14.i686 requires 
libboost_filesystem-mt.so.1.41.0
libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
libopenvrml-gl-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
libopenvrml-gl-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10
libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit)
matahari

Re: gnome-terminal + mc = crash

[cornel panceac]

>
>> Also, does ABRT catch the crash? If so, then consider submitting a bug
>> report using ABRT (System Tools > Automatic Bug Reporting Tool).
>> --
>>
>
> it doesn't. thank you
>


oh,  and i can't report bugs with abrt at workplace because i'm behind a
proxy.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: gnome-terminal + mc = crash

[cornel panceac]

2010/8/12 Michael Schwendt 

> On Thu, 12 Aug 2010 13:51:54 +0300, cornel wrote:
>
> > most of the time on instaled f14 rc3 and updated, if i press  or 
> > while in mc to edit or view a text file, gnome-terminal dissapears,
> taking
> > mc with it. is this an known bug?
>
> see http://bugz.fedoraproject.org/gnome-terminal
>
> Also, does ABRT catch the crash? If so, then consider submitting a bug
> report using ABRT (System Tools > Automatic Bug Reporting Tool).
> --
>

it doesn't. thank you
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: gnome-terminal + mc = crash

[Michael Schwendt]

On Thu, 12 Aug 2010 13:51:54 +0300, cornel wrote:

> most of the time on instaled f14 rc3 and updated, if i press  or 
> while in mc to edit or view a text file, gnome-terminal dissapears, taking
> mc with it. is this an known bug?

see http://bugz.fedoraproject.org/gnome-terminal

Also, does ABRT catch the crash? If so, then consider submitting a bug
report using ABRT (System Tools > Automatic Bug Reporting Tool).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

gnome-terminal + mc = crash

[cornel panceac]

most of the time on instaled f14 rc3 and updated, if i press  or 
while in mc to edit or view a text file, gnome-terminal dissapears, taking
mc with it. is this an known bug?

to test more, i've opened four terminals, and in one of them i've started
mc, then  on a text file, then all four terminals dissapeared.

but, it's not happening always.

-- 
Among the maxims on Lord Naoshige's wall, there was this one: "Matters of
great concern should be treated lightly." Master Ittei commented, "Matters
of small concern should be treated seriously."
(Ghost Dog : The Way of The Samurai)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #116: Clarify https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts to say that explicit Conflicts: are acceptable

[Fedora QA]

#116: Clarify https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts
to say that explicit Conflicts: are acceptable
---+
  Reporter:  adamwill  |   Owner:  rhe   
  Type:  defect|  Status:  closed
  Priority:  major |   Milestone:
 Component:  Wiki  | Version:
Resolution:  fixed |Keywords:
---+
Changes (by rhe):

  * status:  assigned => closed
  * resolution:  => fixed

-- 
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] #116: Clarify https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts to say that explicit Conflicts: are acceptable

[Fedora QA]

#116: Clarify https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts
to say that explicit Conflicts: are acceptable
---+
  Reporter:  adamwill  |   Owner:  rhe 
  Type:  defect|  Status:  assigned
  Priority:  major |   Milestone:  
 Component:  Wiki  | Version:  
Resolution:|Keywords:  
---+
Changes (by rhe):

  * status:  new => assigned

Comment:

 Replying to [ticket:116 adamwill]:
 > = bug description =
 >
 > Please update the
 https://fedoraproject.org/wiki/QA:Testcase_Mediakit_FileConflicts test
 case to clarify that explicit Conflicts: tags are okay.
 >
 > = bug analysis =
 >
 > The relevant release criterion is "No file conflicts or unresolved
 package dependencies during a media-based (CD/DVD) install". The term
 "file conflicts" here is important. I believe it's intended to mean that
 only cases where the files in two packages conflict, but there is no
 explicit Conflicts: tag in the packages. Where the conflict is properly
 marked in the packages with Conflicts: tags, this should not be considered
 an infringement of the criterion.
 >
 > = fix recommendation =
 >
 > Change expected results:
 >
 > 2. No file conflicts were detected for packages included in the media
 kit, unless the conflicting packages also have explicit Conflicts: tags

 That makes sense, I've updated the case. Thanks, Adam.

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

Re: what checksum?

[Ed Greshko]

 On 08/12/2010 05:59 PM, Frank Murphy wrote:
> On 12/08/10 10:46, Ed Greshko wrote:
>> Yes, but it shouldn't it be mentioned since there will always be new
>> users that would not have seen the announcement?  And, if it becomes
>> necessary for those new users to search or ask they may consider parts
>> of Fedora to be not so user friendly.
>>
> Yes, but new "testers" should.
> What we are talking about if not a finished product,
> I mean on the front page, I would concur,
> but on testing no.
>
> I hope no person unfamiliar to Fedora,
> would go for this over "get-fedora"
>
While I see your point...I would defer to the sentiment "Expect the
Un-expected".  :-)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: what checksum?

[cornel panceac]

>
> Sigh.  Well, at leas it doesn't have the big SHA1 sum above the GPG to
> confuse people.  No, you shouldn't have to google for that--EVERY other
> distribution seems to be capable of saying, either in the directory
> holding a checksum or right above the checksum itself.
>
> It's just sloppiness.
>

i'm sure it was because the live cd's had to be rebuilded in a hurry, not a
malicious intent :) and i asked because as we all know, the checksum changed
before.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: what checksum?

[Frank Murphy]

On 12/08/10 10:46, Ed Greshko wrote:
>>
> Yes, but it shouldn't it be mentioned since there will always be new
> users that would not have seen the announcement?  And, if it becomes
> necessary for those new users to search or ask they may consider parts
> of Fedora to be not so user friendly.
>

Yes, but new "testers" should.
What we are talking about if not a finished product,
I mean on the front page, I would concur,
but on testing no.

I hope no person unfamiliar to Fedora,
would go for this over "get-fedora"


-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Alpha RC3 1 live

[Frank Murphy]

Ok, this one has worked for me in Virt-Man kvm,
Booted, installed, firstboot, rebooted.

The systemd 7.1 being there.

-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: what checksum?

[Ed Greshko]

 On 08/12/2010 02:58 PM, Frank Murphy wrote:
> On 12/08/10 07:38, cornel panceac wrote:
>> 2010/8/12 Adam Miller > >
>>
>> Should be sha256
>>
>> indeed, it is. it's better to say it, like here:
>>
> It has been well announced for the paste number of releases that Fedora 
> is sha256.
>
> A quick Google: what checksum does fedora use
> http://www.google.com/search?q=what+checksum+does+fedora+use&as_rights=
>
>
Yes, but it shouldn't it be mentioned since there will always be new
users that would not have seen the announcement?  And, if it becomes
necessary for those new users to search or ask they may consider parts
of Fedora to be not so user friendly. 


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

Re: what checksum?

[Scott Robbins]

On Thu, Aug 12, 2010 at 07:58:50AM +0100, Frank Murphy wrote:
> On 12/08/10 07:38, cornel panceac wrote:
> > 2010/8/12 Adam Miller  > >
> >
> > Should be sha256
> >
> > indeed, it is. it's better to say it, like here:
> >
> 
> It has been well announced for the paste number of releases that Fedora 
> is sha256.
> 
> A quick Google: what checksum does fedora use
> http://www.google.com/search?q=what+checksum+does+fedora+use&as_rights=

Sigh.  Well, at leas it doesn't have the big SHA1 sum above the GPG to
confuse people.  No, you shouldn't have to google for that--EVERY other
distribution seems to be capable of saying, either in the directory
holding a checksum or right above the checksum itself.  

It's just sloppiness.  

It's been well announced--yes, and with each release, until Fedora
finally managed to to put, in the same place, that it was an SHA256
checksum, one would see on the forums how people downloaded, tried sha1
(because of the large SHA1 checksum, referring to the gpg, in the same
place) figure they had it wrong, and download again.  

Not everyone has broadband, and even those who do, in many places, pay
for extra bandwidth.  Stop blaming it on the user--something so basic
shouldn't require googling, especially when it seems that only Fedora
has been incapable of making it plain.  

-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Buffy: Do we really need weapons for this? 
Spike: I just like them. They make me feel all manly. 

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

Re: QA:Testcase_Mediakit_ISO_Size for Netinst

[Andre Robatino]

Kamil Paral  redhat.com> writes:

> 
> - "Andre Robatino"  fedoraproject.org> wrote:
> 
> > I removed the specific examples (which also has the advantage of one
> > less thing
> > to have to update periodically).
> 
> When I look at it know, I must say the examples were quite handy. I would
> put there at least one example. Probably right under bullet 1 in How to
> test. It simplifies thinking a bit :)

Since netinst is now listed as one of the CD-size media, I would have to add it
to the first example. But the old examples referred to 13 Beta, and the Alpha
and Beta images were recently deleted, so I don't know what the netinst size
was. I was unhappy with the examples anyway, due to the possibility that
displaying anything other than byte sizes might lead to rounding/truncation
errors, and the fact that one had to be careful about when to use or not use the
--si option.

> > I'd also like to put in exact byte
> > size numbers
> > for the lower limits as well, for consistency. As I understand it, the
> > exact
> > values aren't critical. Should it say 2 MB = 2,000,000 bytes, or 2 MiB
> > =
> > 2,097,152 bytes?
> 
> Depends on the example, but I would maybe stick to the default output
> of ls -s, therefore IEC units. If all the numbers are in IEC units then
> one example is enough.

But most newer media (with the notable exception of CDs, which will be obsolete
eventually) uses SI units, and their sizes in bytes are easier to remember than
the sizes in 1024-byte blocks. Even when the media uses IEC units, the sizes in
blocks aren't necessarily easier to remember.

CD: 734003200 bytes or 716800 blocks
1 GB Live: 10 bytes or 976563 blocks
DVD: 47 bytes or 4589844 blocks

> > Should the upper size limit for all the Live media be 1 GB, or should
> > it be
> > CD-size for some of them, and 1 GB for the rest?
> 
> AFAIK we have only one live image media, right? And that is supposed
> to be sized under 1 GB.

I thought the live images were expected to be CD-sized for KDE and 1 GB for
Gnome, or something like that.




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

Re: QA:Testcase Memtest86

[He Rui]

On Thu, 2010-08-12 at 04:42 -0400, Kamil Paral wrote:
> - "He Rui"  wrote:
> > I don't intend to cover all the memtest features, but think we should
> > at
> > least check if there's a test result shown to reflect the test,
> > that's
> > the main goal to run a memtest. 
> > 
> 
> Ok, I have waited for the whole test cycle to complete (10 minutes on my
> machine). It really prints "Pass complete, no errors, press Esc to exit"
> message. But - there is no report per se, the counter is just updated
> (Pass +1). And it doesn't mean your RAM is ok. I have used memtest for
> years and checked a lot of faulty hardware with it. From my experience
> you need at least 2 hours of memtest checking to be quite reasonable sure
> your RAM is ok. 4 - 8 hours are better. That's also the reason why it
> continues over and over again.
> 
> Also, if some error is found, you don't have to wait to the end of the
> test cycle. It is printed right away.
> 
> The message printed after one pass is complete is really not a test result.
> It's just a message how to exit the test. The test results are updated
> continuously - the screen is blue, you're good, the screen is red, you're
> not good. The longer you wait (measured in hours) the more trust you have 
> in your hardware. So maybe that's the main misconception between us?

Yes. I thought whether the memory test was passed or not depended on the
report "Pass complete, no errors,..." and I never met any failed one. So
if the error is printed right away, then this result is not that
important and running a few moments is reasonable. Thanks for clarifying
this. 

Hurry

-- 
Contacts

Hurry
FAS Name: Rhe 
Timezone: UTC+8
TEL: 86-010-62608141
IRC nick: rhe #fedora-qa #fedora-zh

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

Re: QA:Testcase Memtest86

[Kamil Paral]

- "He Rui"  wrote:
> I don't intend to cover all the memtest features, but think we should
> at
> least check if there's a test result shown to reflect the test,
> that's
> the main goal to run a memtest. 
> 

Ok, I have waited for the whole test cycle to complete (10 minutes on my
machine). It really prints "Pass complete, no errors, press Esc to exit"
message. But - there is no report per se, the counter is just updated
(Pass +1). And it doesn't mean your RAM is ok. I have used memtest for
years and checked a lot of faulty hardware with it. From my experience
you need at least 2 hours of memtest checking to be quite reasonable sure
your RAM is ok. 4 - 8 hours are better. That's also the reason why it
continues over and over again.

Also, if some error is found, you don't have to wait to the end of the
test cycle. It is printed right away.

The message printed after one pass is complete is really not a test result.
It's just a message how to exit the test. The test results are updated
continuously - the screen is blue, you're good, the screen is red, you're
not good. The longer you wait (measured in hours) the more trust you have 
in your hardware. So maybe that's the main misconception between us?

So, from my QA point of view:
1. We just need to check that memtest is available and it "works" (10
seconds passed or a single test finished is enough to check).
2. There's a very little probability that memtest would fail/crash on
some of its tests because of some bug - it will probably work ok or
won't work at all.
3. We don't want to check for RAM failures.

Of course I don't want to force my opinion to anyone. It's just my 
personal idea how this test case could be improved.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #100: mentor request

[Fedora QA]

#100: mentor request
--+-
  Reporter:  mrunge   |   Owner:  jlaska  
  Type:  proventester request |  Status:  assigned
  Priority:  major|   Milestone:  
 Component:  Proventester Mentor Request  | Version:  
Resolution:   |Keywords:  
--+-
Comment (by mrunge):

 Hi James,

 thank you for sponsering me.

 I have read the instructions and intent to follow them when testing. I'm
 pulling updates from updates testing and am familiar to give feedback via
 those two methods.

 Matthias

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

Re: QA:Testcase Memtest86

[He Rui]

On Thu, 2010-08-12 at 03:18 -0400, Kamil Paral wrote:
> - "He Rui"  wrote:
> > > 
> > > >   2. Test report is shown once a test is completed.
> > > 
> > > The test is never completed, it runs infinitely over and over
> > again.
> > > It takes quite some time too.
> > > Also, no report is ever shown, just statistics are continuously
> > updated
> > > in the lower part of the screen.
> > > Very confusing.
> > 
> > If a test cycle is completed(From test#1 to test#8, About 5 mins for
> > 512M memory), A test result will be shown at the bottom:
> > 
> >  Pass Complete, no errors, press ESC to exit 
> > 
> > 
> > I haven't met the failure status, but a relative result is supposed
> > to
> > be provided after one cycle is finished as well. 
> 
> Ah, I never waited long enough to finish the whole test cycle :) But
> the instructions also says I should change the configuration, so I 
> changed configuration to do just test #2, and it did it like 20 times
> over with no end at all, just repeating itself. So it depends on user
> choice (and whether he knows this stuff).
> 
> > > 
> > > I think this test case is needlessly overcomplicated. We just need
> > > to test that Memory Test available on installation media "just
> > works",
> > > right? So what about something like:
> > > 
> > > How to test:
> > >1. Insert installation media and display its boot prompt
> > >2. Select option Memory Test
> > >3. Have the test running for a few moments
> > 
> > 'A few moments' should be more accurate, at least test#1 - test#8 is
> > finished.  
> > 
> > > 
> > > Expected results:
> > >1. Memory test runs a tests your memory, it seems to work
> > correctly.
> > >2. You can use configuration to change test settings, e.g. select
> > just
> > >   one single test out of the test set to be tested.
> > > 
> > > 
> > > Sounds better?
> > 
> > Also add this one to verify the test result:
> > 
> > 3. Test Report(Or test result) is shown once a test
> > cycle(test#1-test#8)
> > is done. 
> > 
> 
> I still think we shouldn't do this. Quick check whether memtest
> starts and runs ok is sufficient imho. Full RAM testing is:
> 1. time consuming
> 2. you never know how to handle potential error. it may be memtest
> issue, hardware issue, KVM issue, ...
> 
> I understand you want to test full memtest featureset (all tests work
> etc), but we don't do that even for more important programs, it's just
> not efficient. Smoke testing is all I would do here (and that's exactly
> what I tried to capture in sentences "wait a few moments, memtest seems
> to work correctly").
I don't intend to cover all the memtest features, but think we should at
least check if there's a test result shown to reflect the test, that's
the main goal to run a memtest. 

-- 
Contacts

Hurry
FAS Name: Rhe 
Timezone: UTC+8
TEL: 86-010-62608141
IRC nick: rhe #fedora-qa #fedora-zh

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

Re: QA:Testcase_Mediakit_ISO_Size for Netinst

[Kamil Paral]

- "Andre Robatino"  wrote:

> I removed the specific examples (which also has the advantage of one
> less thing
> to have to update periodically).

When I look at it know, I must say the examples were quite handy. I would
put there at least one example. Probably right under bullet 1 in How to
test. It simplifies thinking a bit :)

> I'd also like to put in exact byte
> size numbers
> for the lower limits as well, for consistency. As I understand it, the
> exact
> values aren't critical. Should it say 2 MB = 2,000,000 bytes, or 2 MiB
> =
> 2,097,152 bytes?

Depends on the example, but I would maybe stick to the default output
of ls -s, therefore IEC units. If all the numbers are in IEC units then
one example is enough.

> 
> Ideally, I don't think there should be a lower size limit at all, but
> a separate
> test to detect directly whatever fault would cause such small images.

I also think the lower size limit is quite artificial and doesn't have
to be specified. If the image is broken and too small, it fail some 
other test (probably boot test). I would remove lower size limit check
completely, another step for simpler test cases.

> 
> Should the upper size limit for all the Live media be 1 GB, or should
> it be
> CD-size for some of them, and 1 GB for the rest?

AFAIK we have only one live image media, right? And that is supposed
to be sized under 1 GB.

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

Re: bizarre yum

[M A Young]

On Wed, 11 Aug 2010, Felix Miata wrote:

> 1-updated F13/KDE system this AM.
>
> 2-cloned the F13 partition to another partition
>
> 3-changed the clone's UUID
>
> 4-adjusted the clone's grub.conf & fstab, then booted it
>
> 5-rpm -Uvh fedora-release-14-0.7.noarch.rpm
>
> 6-yum update yum rpm (fails)
>
> 7-yum update yum rpm --nogpgcheck --skip-broken
>
> Result:
> 119 packages installed, among them freetype, kde, fontconfig-devel, akonadi,
> qt-webkit, libXinerama-devel, libchamplain-gtk, amarok, qt-webkit, BackupPC,
> compat-gdbm

The change from python 2.6 to python 2.7 may be holding you up if you have 
packages installed that haven't been recompiled for python 2.7 in F14 
yet, or if you have other packages that use python that aren't in F14. The 
output from yum update will tell you what dependencies are holding you 
back.

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

Re: QA:Testcase_Mediakit_ISO_Size for Netinst

[Andre Robatino]

I removed the specific examples (which also has the advantage of one less thing
to have to update periodically). I'd also like to put in exact byte size numbers
for the lower limits as well, for consistency. As I understand it, the exact
values aren't critical. Should it say 2 MB = 2,000,000 bytes, or 2 MiB =
2,097,152 bytes?

Ideally, I don't think there should be a lower size limit at all, but a separate
test to detect directly whatever fault would cause such small images.

Should the upper size limit for all the Live media be 1 GB, or should it be
CD-size for some of them, and 1 GB for the rest?

https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size



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

Re: QA:Testcase Memtest86

[Kamil Paral]

- "He Rui"  wrote:
> > 
> > >   2. Test report is shown once a test is completed.
> > 
> > The test is never completed, it runs infinitely over and over
> again.
> > It takes quite some time too.
> > Also, no report is ever shown, just statistics are continuously
> updated
> > in the lower part of the screen.
> > Very confusing.
> 
> If a test cycle is completed(From test#1 to test#8, About 5 mins for
> 512M memory), A test result will be shown at the bottom:
> 
>  Pass Complete, no errors, press ESC to exit 
> 
> 
> I haven't met the failure status, but a relative result is supposed
> to
> be provided after one cycle is finished as well. 

Ah, I never waited long enough to finish the whole test cycle :) But
the instructions also says I should change the configuration, so I 
changed configuration to do just test #2, and it did it like 20 times
over with no end at all, just repeating itself. So it depends on user
choice (and whether he knows this stuff).

> > 
> > I think this test case is needlessly overcomplicated. We just need
> > to test that Memory Test available on installation media "just
> works",
> > right? So what about something like:
> > 
> > How to test:
> >1. Insert installation media and display its boot prompt
> >2. Select option Memory Test
> >3. Have the test running for a few moments
> 
> 'A few moments' should be more accurate, at least test#1 - test#8 is
> finished.  
> 
> > 
> > Expected results:
> >1. Memory test runs a tests your memory, it seems to work
> correctly.
> >2. You can use configuration to change test settings, e.g. select
> just
> >   one single test out of the test set to be tested.
> > 
> > 
> > Sounds better?
> 
> Also add this one to verify the test result:
> 
> 3. Test Report(Or test result) is shown once a test
> cycle(test#1-test#8)
> is done. 
> 

I still think we shouldn't do this. Quick check whether memtest
starts and runs ok is sufficient imho. Full RAM testing is:
1. time consuming
2. you never know how to handle potential error. it may be memtest
issue, hardware issue, KVM issue, ...

I understand you want to test full memtest featureset (all tests work
etc), but we don't do that even for more important programs, it's just
not efficient. Smoke testing is all I would do here (and that's exactly
what I tried to capture in sentences "wait a few moments, memtest seems
to work correctly").
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: QA:Testcase_Mediakit_ISO_Size for Netinst

[He Rui]

On Thu, 2010-08-12 at 02:30 -0400, Kamil Paral wrote:
> - "Andre Robatino"  wrote:
> 
> > James Laska  redhat.com> writes:
> > 
> > > I believe the {netinst,boot}.iso are intended to fit on a 700M cdr.
> > 
> > I edited
> > 
> > https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size
> > 
> > to indicate that netinst should be CD-sized.  I'd like to delete the
> > examples,
> > which all use "ls -sh", due to the possibility for confusion between
> > IEC values
> > (which are displayed by default) and SI values (which require the --si
> > option).
> >  The upper size limits are already given as exact numbers of bytes, so
> > people
> > can just use "ls -l" (which is easier to remember and not subject to
> > rounding/truncation errors).  Is this okay?
> 
> I'm not sure which way it is easier to compare it :) But go ahead and try
> it and we will see.
> 
> Quite interestingly, 'ls -s --si' (without -h) prints rounded numbers 
> (like 400M) instead of precise numbers, at least for me. That's really 
> not ideal.

--si is likewise -h, just use powers of 1000 not 1024(see 'ls' manual).

-- 
Contacts

Hurry
FAS Name: Rhe 
Timezone: UTC+8
TEL: 86-010-62608141
IRC nick: rhe #fedora-qa #fedora-zh

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

Re: QA:Testcase Memtest86

[He Rui]

Hi Kamil,

On Wed, 2010-08-11 at 06:27 -0400, Kamil Paral wrote:
> I want to discuss the QA:Testcase Memtest86 [1] from our F14 installation
> matrix.
> 
> The test case is a little weird to me and took me quite some time to 
> understand what to test and when to report outcome.
> 
> > How to test:
> >   1.  Boot the installer using any available means
> 
> We don't want to boot the installer (anaconda), just show the main
> boot menu (grub).

Ah, right.

> >   2. At the bootloader prompt, select the option labeled Memory Test
> >   3. Make some changes to the configurations and other settings 
> 
> > Expected Results:
> >   1.  Memory test works successfully
> 
> Meaning the program works or there are not RAM failures? The latter is
> hardware issue. Let's rephrase that.
> 
> >   2. Test report is shown once a test is completed.
> 
> The test is never completed, it runs infinitely over and over again.
> It takes quite some time too.
> Also, no report is ever shown, just statistics are continuously updated
> in the lower part of the screen.
> Very confusing.

If a test cycle is completed(From test#1 to test#8, About 5 mins for
512M memory), A test result will be shown at the bottom:

 Pass Complete, no errors, press ESC to exit  

I haven't met the failure status, but a relative result is supposed to
be provided after one cycle is finished as well. 

> 
> >   3. The configurations are able to be set and changed. 
> 
> Yep, but according to what you set, you may wait ages until some
> test passes at least once.

This is meant to test the configurations and make sure they are
functional.

> 
> I think this test case is needlessly overcomplicated. We just need
> to test that Memory Test available on installation media "just works",
> right? So what about something like:
> 
> How to test:
>1. Insert installation media and display its boot prompt
>2. Select option Memory Test
>3. Have the test running for a few moments

'A few moments' should be more accurate, at least test#1 - test#8 is
finished.  

> 
> Expected results:
>1. Memory test runs a tests your memory, it seems to work correctly.
>2. You can use configuration to change test settings, e.g. select just
>   one single test out of the test set to be tested.
> 
> 
> Sounds better?

Also add this one to verify the test result:

3. Test Report(Or test result) is shown once a test cycle(test#1-test#8)
is done. 



Thanks,
Hurry

-- 
Contacts

Hurry
FAS Name: Rhe 
Timezone: UTC+8
TEL: 86-010-62608141
IRC nick: rhe #fedora-qa #fedora-zh

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