Any hope for system-config-services ?

[Chuck Forsberg WA7KGX N2469R]

Since F15 this does not seem able to enable httpd or
anything as far as I can tell.  "enable" and "disable"
are greyed out.

How is one expected to manage Fedora as a server
if services can not be enabled?

-- 
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

Google Earth

[Chuck Forsberg WA7KGX N2469R]

The 32 bit redhat-lsb does the trick.

Shouldn't there be a "32 bit support" group that pulls
in these files??

-- 
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

Re: Google Earth

[John5342]

On Wed, Jul 20, 2011 at 00:16, Ed Greshko  wrote:
> On 07/20/2011 07:11 AM, Peter Reed wrote:
>> This will not resolve the dependency problem.  It requires all the i686
>> packages not the x86_64 packages I do not think it is a true x86_64 based
>> package.  I would have to run it each time to see what the next depency it
>> would fail on and install that i686 package until I finnally got it to run.
>> Friggin' pain in the butt.
>
> Well, for various reasons, I'm back on 32bitbut when I was on 64bit
> 2 months ago I'm somewhat certain that "yum localinstall" brought in the
> redhat-lsb package.

When i last installed it yum install did bring in the dependencies
(pretty sure install and localinstall do the same in that respect).
Unfortunately it brought in the x86_64 version of various libraries.

Unfortunately Google provide x86_64 rpms for most of their stuff but a
lot of it is actually x86_32. I can only assume they package them as
x86_64 only for appearances or easy upgrading if they decide to
provide actual x86_64 in the future. Most likely both.

-- 
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Google Earth

[Ed Greshko]

On 07/20/2011 07:11 AM, Peter Reed wrote:
> This will not resolve the dependency problem.  It requires all the i686 
> packages not the x86_64 packages I do not think it is a true x86_64 based 
> package.  I would have to run it each time to see what the next depency it 
> would fail on and install that i686 package until I finnally got it to run.  
> Friggin' pain in the butt.

Well, for various reasons, I'm back on 32bitbut when I was on 64bit
2 months ago I'm somewhat certain that "yum localinstall" brought in the
redhat-lsb package.

Memory could be faulty however.

-- 
Even if you do learn to speak correct English, whom are you going to
speak it to? -- Clarence Darrow
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Google Earth

[Peter Reed]

On Tuesday, July 19, 2011 03:28:09 PM Ed Greshko wrote:
> On 07/20/2011 01:06 AM, Chuck Forsberg WA7KGX N2469R wrote:
> > I downloaded the 64 bit rpm flavor of Google Earth.
> > It installs and runs on 64 bit Scientific Linux.  Neither
> > Fedora 14 or Fedora 15 would run it:
> > 
> > /usr/bin/google-earth: ./googleearth-bin: /lib/ld-lsb.so.3: bad ELF
> > interpreter: No such file or directory
> > 
> > Is there a trick to get this to run?
> 
> How did you install it?
> 
> If you did "rpm -Uvh googleearth.rpm" you easily could run into
> difficulties.
> 
> The "better" way to install is "yum localinstall googleearth.rpm" which
> resolves dependencies.
> 
> Are you doing these installs/tests on a "rawhide" system?  You mention
> Fedora 14 and 15, which are in "production".  So, wondering why you
> didn't post on the "users" mailing list.
This will not resolve the dependency problem.  It requires all the i686 
packages not the x86_64 packages I do not think it is a true x86_64 based 
package.  I would have to run it each time to see what the next depency it 
would fail on and install that i686 package until I finnally got it to run.  
Friggin' pain in the butt.
PEter
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Thunderbird F15 Update

[Michael Cronenworth]

Michael Cronenworth on 07/19/2011 04:36 PM wrote:
> I haven't discovered any conversations beside the one comment on the TB
> 5.0 bodhi update.

Nevermind. After looking at *closed* tickets, I found it.

https://fedorahosted.org/rel-eng/ticket/4828
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Thunderbird F15 Update

[Michael Cronenworth]

Is anyone aware of the duplicate TB update for F15?

Both 3.0.11 and 5.0 got pushed to stable at the same time with 3.0.11 
winning out.

The thunderbird-lightning package was also pushed, which is for 5.0 only.

I haven't discovered any conversations beside the one comment on the TB 
5.0 bodhi update.

Side note:
Seems like a possible bug/enhancement to bodhi regarding multiple 
updates of one package.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Google Earth

[Ed Greshko]

On 07/20/2011 01:06 AM, Chuck Forsberg WA7KGX N2469R wrote:
> I downloaded the 64 bit rpm flavor of Google Earth.
> It installs and runs on 64 bit Scientific Linux.  Neither
> Fedora 14 or Fedora 15 would run it:
>
> /usr/bin/google-earth: ./googleearth-bin: /lib/ld-lsb.so.3: bad ELF 
> interpreter: No such file or directory
>
> Is there a trick to get this to run?
>

How did you install it?

If you did "rpm -Uvh googleearth.rpm" you easily could run into
difficulties.

The "better" way to install is "yum localinstall googleearth.rpm" which
resolves dependencies.

Are you doing these installs/tests on a "rawhide" system?  You mention
Fedora 14 and 15, which are in "production".  So, wondering why you
didn't post on the "users" mailing list.

-- 
Even if you do learn to speak correct English, whom are you going to
speak it to? -- Clarence Darrow
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Instalatron: Anaconda testing framework

[Sergio Rubio]

On Tuesday, July 19, 2011, Eric Blake  wrote:
>
> If that's the only reason, then we should really try to use kvm instead, 
> since qemu-kvm recently learned how to inject arbitrary scancodes, and 
> libvirt 0.9.4 is gaining support for exposing that capability from command 
> line.  Fedora gains all around if we exercise our own open virt stack instead 
> of a proprietary one.
>

Very reasonable. Thanks for pointing out. Haven't been following
libvirt/KVM developments lately...

Abstracting the hypervisor related stuff will be kind of easy I guess.

Rgds.


> --
> Eric Blake   ebl...@redhat.com    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Instalatron: Anaconda testing framework

[Eric Blake]

On 07/19/2011 12:50 PM, Sergio Rubio wrote:
> Hey,
>
> Thank you guys for the quick reply. Comments inline.
>
> On Tue, Jul 19, 2011 at 6:48 PM, Tim Flink  wrote:
>>
>> Cool, we're always looking for ways to do better testing. As James said,
>> honqing and twu are more actively working on the installer automation
>> but I have a couple of design questions.
>>
>> Why virtualbox?
>>   - I was under the impression that VB didn't always play nice with the
>>fedora kernels and was a reason to use KVM/qemu instead
>>   - Then there's the whole licensing issue ...
>
>
> The main reason is that I found the "VBoxManage controlvm
> keyboardputscancode" stuff in another OSS project and since anaconda
> installs can be driven by the keyboard I thought wrapping it would be
> fast and easy.

If that's the only reason, then we should really try to use kvm instead, 
since qemu-kvm recently learned how to inject arbitrary scancodes, and 
libvirt 0.9.4 is gaining support for exposing that capability from 
command line.  Fedora gains all around if we exercise our own open virt 
stack instead of a proprietary one.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Instalatron: Anaconda testing framework

[Sergio Rubio]

Hey,

Thank you guys for the quick reply. Comments inline.

On Tue, Jul 19, 2011 at 6:48 PM, Tim Flink  wrote:
>
> Cool, we're always looking for ways to do better testing. As James said,
> honqing and twu are more actively working on the installer automation
> but I have a couple of design questions.
>
> Why virtualbox?
>  - I was under the impression that VB didn't always play nice with the
>   fedora kernels and was a reason to use KVM/qemu instead
>  - Then there's the whole licensing issue ...


The main reason is that I found the "VBoxManage controlvm
keyboardputscancode" stuff in another OSS project and since anaconda
installs can be driven by the keyboard I thought wrapping it would be
fast and easy.

Besides that, we test RHEL5/6 and Fedora VMs in VirtualBox everyday
and never had an issue (at least for testing purposes).

About the licensing issue, we don't need the propietary extensions in
VB 4 so don't care too much.


>
> How well does it adapt to small changes in visual layout?
>  - The scripting looks very rigid to me which is fine for things that
>   don't change very often
>  - Do the scripts have to be completely re-done for small visual
>   changes or is it possible to just change a portion?


You can adjust the "sentitivity". I'm using compare from ImageMagick
that allows this kind of stuff. There's a threshold you can adjust,
but right now it's hardcoded. Things like mouse movements and string
changes are Ok.


>
> How often are you seeing false positives/negatives?
>  - ImageMagick's 'compare' seems awfully sensitive to me, have you seen
>   many problems with the image comparison logic?


We've changed strings, selected and highlighted widgets and the mouse
cursor and the test is not affected. It's farm from ideal but it works
right now :).


>  - If I'm reading the code correctly, it seems to be looking for an
>   exact match

Right, with the exceptions mentioned above.

>
> How are you defining pass/fail?
>  - From my very quick scan of the code, it looks like
>   PASS -> no crash during installation
>   FAIL -> image comparison failures, unexpected events, crash
>  - Is there any verification that the VM boots after install?


I still need to implement this stuff, but I believe we can do it easily.
Right now instalatron-play hangs if the next screen (or crash) is not expected.


>
> How do you handle crashes?
>  - Are you collecting anaconda stack traces on crash?
>  - Otherwise, is the VM in a state that allows for data collection if a
>   crash occurs?

Not handled right now. I'm planing research libguestfs usage to access
vm disk... Not sure yet.

>
> Another thing that you may be interested in is OpenSuSE's openqa project
> [1] and specifically, os-autoinst [2].

Greatly appreciated!

Lovely feedback, thank you.

>
> Thanks,
>
> Tim
>
> [1] http://openqa.opensuse.org/
> [2] http://www.os-autoinst.org/
>
>
> --
> 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: Rawhide Acceptance Test for F16 summary

[James Laska]

- Original Message -
> On Tue, 2011-07-19 at 06:05 -0400, Tao Wu wrote:
> > Greetings folks,
> >
> > Just wanted to summarize how testing held up for the rawhide
> > acceptance test run of Fedora 16. Thanks for your attention. It is
> > unfortunately that the rawhide installation version has not passed
> > the major test, please refer to the bug 723144. Let's expect the
> > exciting coming out of next version!
> >
> > If you have spare time and want to contribute by verify this
> > version, the test cases and results can be found on the following
> > URL:
> > https://fedoraproject.org/wiki/Test_Results:Fedora_16_Rawhide_Acceptance_Test_1#Test_Matrix
> >
> > Thanks a lot!
> 
> Thanks Tao! I don't have anything to add to your results since I don't
> yet have a rawhide/F16 system to test with. I'm seeing the same bug
> (bug#723144) you reported on a baremetal system. Please consider
> escalating this issue as a F16 Alpha release blocker since I suspect
> this impacts the following Alpha release criteria [1] ...
> 
> The installer must be able to complete an installation using the
> entire disk, existing free space, or existing Linux partitions
> methods, with or without encryption enabled
> 
> If anyone is already running rawhide, there are a few post-install
> tests
> linked on the above test matrix that could use some feedback.
> 
> Thanks,
> James
> 
> [1] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria

I'm trying other ways of installing while working around the problem you found, 
and I uncovered another issue.  In classic form, Chris Lumens fixed it in 
anaconda.git [1].  Until a newer anaconda is available, I have an updates.img 
[2] that works with anaconda-16.12-1.  The updates.img does not yet resolve 
bug#723144, but it seems that installing *without* LVM allows the install to 
proceed and workaround the bug you found.  This should allow some test coverage 
on remaining test cases.

If anyone is interested, the process for creating installer updates.img is 
pretty painless, thanks to some clever documentation+script support. [3]

Thanks,
James

[1] http://git.fedorahosted.org/git/?p=anaconda.git;a=shortlog
[2] http://jlaska.fedorapeople.org/updates/f16-alpha.imgshortlog
[3] 
http://fedoraproject.org/wiki/Anaconda/Updates#How_to_Create_an_Anaconda_Updates_Image
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

[Fedora QA] #225: Request for F16 Power Management test day

[Fedora QA]

#225: Request for F16 Power Management test day
-+--
 Reporter:  jskarvad |   Owner: 
 Type:  task |  Status:  new
 Priority:  major|   Milestone: 
Component:  Proventester Mentor Request  | Version: 
 Keywords:   |  
-+--
 We would like to hold the F16 Power Management test day. We expect it to
 be similar to our previous F15 Power Management test day. We will also try
 to prepare the Live CD for this event (as for F15). We suggest 2011-09-29
 but anything except the first half of September would fit to us.

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

Re: Google Earth

[Jon Ciesla]

Dennis Gilmore wrote:
> On Tuesday, July 19, 2011 12:06:31 PM Chuck Forsberg WA7KGX N2469R wrote:
>   
>> I downloaded the 64 bit rpm flavor of Google Earth.
>> It installs and runs on 64 bit Scientific Linux.  Neither
>> Fedora 14 or Fedora 15 would run it:
>>
>> /usr/bin/google-earth: ./googleearth-bin: /lib/ld-lsb.so.3: bad ELF
>> interpreter: No such file or directory
>>
>> Is there a trick to get this to run?
>> 
> other than the advice others have given, that indicates that its actually a 
> 32 
> bit binary. if it was installed via rpms then its been packaged poorly
>
> Dennis
>   
A poorly made 3rd-party proprietary RPM?  That's unpossible!

-J

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie

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

Re: Google Earth

[Adam Williamson]

On Tue, 2011-07-19 at 12:51 -0500, Dennis Gilmore wrote:
> On Tuesday, July 19, 2011 12:06:31 PM Chuck Forsberg WA7KGX N2469R wrote:
> > I downloaded the 64 bit rpm flavor of Google Earth.
> > It installs and runs on 64 bit Scientific Linux.  Neither
> > Fedora 14 or Fedora 15 would run it:
> > 
> > /usr/bin/google-earth: ./googleearth-bin: /lib/ld-lsb.so.3: bad ELF
> > interpreter: No such file or directory
> > 
> > Is there a trick to get this to run?
> other than the advice others have given, that indicates that its actually a 
> 32 
> bit binary. if it was installed via rpms then its been packaged poorly

oh, yes, point. you'd need the *i686* redhat-lsb package.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
http://www.happyassassin.net

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

Re: Google Earth

[Dennis Gilmore]

On Tuesday, July 19, 2011 12:06:31 PM Chuck Forsberg WA7KGX N2469R wrote:
> I downloaded the 64 bit rpm flavor of Google Earth.
> It installs and runs on 64 bit Scientific Linux.  Neither
> Fedora 14 or Fedora 15 would run it:
> 
> /usr/bin/google-earth: ./googleearth-bin: /lib/ld-lsb.so.3: bad ELF
> interpreter: No such file or directory
> 
> Is there a trick to get this to run?
other than the advice others have given, that indicates that its actually a 32 
bit binary. if it was installed via rpms then its been packaged poorly

Dennis


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

[Test-Announce] Call for Test Days for Fedora 16

[Adam Williamson]

Hi, folks. The Test Day cycle for Fedora 16 will open shortly, and we're
putting out the call for anyone who has an idea for a Test Day. There
are many open slots on the schedule -
https://fedoraproject.org/wiki/QA/Fedora_16_test_days - and if they all
fill up or you would like to run a set of Test Days on related topics,
we can organize events outside of the scheduled Thursday windows too.

It's often a good idea to have a Test Day for a major change or new
feature you're introducing to the distribution, but we can run a Test
Day on just about any topic. There is a full guide to organizing Test
Days available -
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management - and the QA
team is happy both to help you run a Test Day and to butt out and let
you run it yourself, whichever you prefer! If you're interested in
running a Test Day, please contact QA via the test mailing list, file a
ticket in QA trac - https://fedorahosted.org/fedora-qa - and/or pencil
in your event on the schedule, create a Wiki page based on the template
(see the SOP for details), and get down to work. Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
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: Google Earth

[Adam Williamson]

On Tue, 2011-07-19 at 11:14 -0600, Kevin DeKorte wrote:
> On 07/19/2011 11:11 AM, Adam Williamson wrote:
> 
> > 
> > Conclusion: try 'yum install redhat-lsb'.
> 
> 
> Adam,
> 
> yum provides /lib/ld-lsb.so.3
> 
> Is another way to find the package.

I have a philosophical objection to file-based dependencies, so I refuse
to use it on principle ;)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
http://www.happyassassin.net

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

Re: Google Earth

[Kevin DeKorte]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/19/2011 11:11 AM, Adam Williamson wrote:

> 
> Conclusion: try 'yum install redhat-lsb'.


Adam,

yum provides /lib/ld-lsb.so.3

Is another way to find the package.

Kevin

- -- 
Get my public GnuPG key from
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4lu1oACgkQ6w2kMH0L1dFNdACaArko4+lIzGA2wkP7o1JGBSVb
9HsAn00TvB/H9l/KBSkB9AQzmkI+kwmK
=1PP7
-END PGP SIGNATURE-
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Google Earth

[Kevin DeKorte]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/19/2011 11:06 AM, Chuck Forsberg WA7KGX N2469R wrote:
> I downloaded the 64 bit rpm flavor of Google Earth. It installs and
> runs on 64 bit Scientific Linux.  Neither Fedora 14 or Fedora 15
> would run it:
> 
> /usr/bin/google-earth: ./googleearth-bin: /lib/ld-lsb.so.3: bad ELF 
> interpreter: No such file or directory
> 
> Is there a trick to get this to run?
> 

Chuck,

Do you have redhat-lsb installed? That is the package that provides that
file.

Kevin

- -- 
Get my public GnuPG key from
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4luvsACgkQ6w2kMH0L1dGUvQCfUmxhMAOwoGd6A1Lf3lUtcP90
lPMAn0O2rCUNwZsIoAw8hA7ajwyiBCoe
=nnOT
-END PGP SIGNATURE-
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Google Earth

[Adam Williamson]

On Tue, 2011-07-19 at 10:06 -0700, Chuck Forsberg WA7KGX N2469R wrote:
> I downloaded the 64 bit rpm flavor of Google Earth.
> It installs and runs on 64 bit Scientific Linux.  Neither
> Fedora 14 or Fedora 15 would run it:
> 
> /usr/bin/google-earth: ./googleearth-bin: /lib/ld-lsb.so.3: bad ELF 
> interpreter: No such file or directory
> 
> Is there a trick to get this to run?

[root@adam adamw]# yum search lsb
Loaded plugins: auto-update-debuginfo, langpacks, presto,
refresh-packagekit
=== N/S Matched: lsb
===
redhat-lsb.i686 : LSB base libraries support for Red Hat Enterprise
Linux
redhat-lsb.x86_64 : LSB base libraries support for Red Hat Enterprise
Linux
redhat-lsb-debuginfo.x86_64 : Debug information for package redhat-lsb
redhat-lsb-graphics.i686 : LSB graphics libraries support for Red Hat
Enterprise
 : Linux
redhat-lsb-graphics.x86_64 : LSB graphics libraries support for Red Hat
   : Enterprise Linux
redhat-lsb-printing.i686 : LSB printing libraries support for Red Hat
Enterprise
 : Linux
redhat-lsb-printing.x86_64 : LSB printing libraries support for Red Hat
   : Enterprise Linux
perl-List-UtilsBy.noarch : Higher-order list utility functions

  Name and summary matches only, use "search all" for everything.
[root@adam adamw]# repoquery -l redhat-lsb
/bin/redhat_lsb_init
/etc/lsb-release.d
/etc/lsb-release.d/core-4.0-ia32
/etc/lsb-release.d/core-4.0-noarch
/etc/redhat-lsb
/etc/redhat-lsb/lsb_killproc
/etc/redhat-lsb/lsb_log_message
/etc/redhat-lsb/lsb_pidofproc
/etc/redhat-lsb/lsb_start_daemon
/lib/ld-lsb.so.3
/lib/lsb
/lib/lsb/init-functions
/usr/bin/lsb_release
/usr/lib/lsb
/usr/lib/lsb/install_initd
/usr/lib/lsb/remove_initd
/usr/sbin/redhat_lsb_trigger.i686
/usr/share/man/man1/lsb_release.1.gz
/bin/redhat_lsb_init
/etc/lsb-release.d
/etc/lsb-release.d/core-4.0-amd64
/etc/lsb-release.d/core-4.0-noarch
/etc/redhat-lsb
/etc/redhat-lsb/lsb_killproc
/etc/redhat-lsb/lsb_log_message
/etc/redhat-lsb/lsb_pidofproc
/etc/redhat-lsb/lsb_start_daemon
/lib/lsb
/lib/lsb/init-functions
/lib64/ld-lsb-x86-64.so.3
/usr/bin/lsb_release
/usr/lib/lsb
/usr/lib/lsb/install_initd
/usr/lib/lsb/remove_initd
/usr/sbin/redhat_lsb_trigger.x86_64
/usr/share/man/man1/lsb_release.1.gz
[root@adam adamw]# repoquery -l redhat-lsb | grep ld-
/lib/ld-lsb.so.3
/lib64/ld-lsb-x86-64.so.3

Conclusion: try 'yum install redhat-lsb'.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
http://www.happyassassin.net

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

Google Earth

[Chuck Forsberg WA7KGX N2469R]

I downloaded the 64 bit rpm flavor of Google Earth.
It installs and runs on 64 bit Scientific Linux.  Neither
Fedora 14 or Fedora 15 would run it:

/usr/bin/google-earth: ./googleearth-bin: /lib/ld-lsb.so.3: bad ELF 
interpreter: No such file or directory

Is there a trick to get this to run?

-- 
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

Re: Instalatron: Anaconda testing framework

[Tim Flink]

On 07/19/2011 09:49 AM, Sergio Rubio wrote:
> Greetings!
> 
> Posted this to the wrong mailing list (David Cantrell suggested using
> this one instead).
> 
> Linking to avoid re-typing :), my apologies:
> 
> https://www.redhat.com/archives/anaconda-devel-list/2011-July/msg00090.html
> 
> In a nutshell, we are looking for better ways to test our Anaconda
> based installer and I thought that speaking to the real guys and
> sharing would be a good way to start.
> 
> Any feedback is greatly appreciated.

Cool, we're always looking for ways to do better testing. As James said,
honqing and twu are more actively working on the installer automation
but I have a couple of design questions.

Why virtualbox?
 - I was under the impression that VB didn't always play nice with the
   fedora kernels and was a reason to use KVM/qemu instead
 - Then there's the whole licensing issue ...

How well does it adapt to small changes in visual layout?
 - The scripting looks very rigid to me which is fine for things that
   don't change very often
 - Do the scripts have to be completely re-done for small visual
   changes or is it possible to just change a portion?

How often are you seeing false positives/negatives?
 - ImageMagick's 'compare' seems awfully sensitive to me, have you seen
   many problems with the image comparison logic?
 - If I'm reading the code correctly, it seems to be looking for an
   exact match

How are you defining pass/fail?
 - From my very quick scan of the code, it looks like
   PASS -> no crash during installation
   FAIL -> image comparison failures, unexpected events, crash
 - Is there any verification that the VM boots after install?

How do you handle crashes?
 - Are you collecting anaconda stack traces on crash?
 - Otherwise, is the VM in a state that allows for data collection if a
   crash occurs?

Another thing that you may be interested in is OpenSuSE's openqa project
[1] and specifically, os-autoinst [2].

Thanks,

Tim

[1] http://openqa.opensuse.org/
[2] http://www.os-autoinst.org/



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

Testing Fedora 16

[Chuck Forsberg WA7KGX N2469R]

The 7/18 64 bit electronic-lab live dvd fails hard disk
install with an unhandled exception.

Gnome 3 fails to load.  System is an Nvidia GTX 460 SE
on Intel i5 with 8 GB ram.

On restart, the live Linux should eject the disc,
or at least unlock the eject button.

-- 
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

Re: Instalatron: Anaconda testing framework

[James Laska]

On Tue, 2011-07-19 at 17:49 +0200, Sergio Rubio wrote:
> Greetings!
> 
> Posted this to the wrong mailing list (David Cantrell suggested using
> this one instead).
> 
> Linking to avoid re-typing :), my apologies:
> 
> https://www.redhat.com/archives/anaconda-devel-list/2011-July/msg00090.html
> 
> In a nutshell, we are looking for better ways to test our Anaconda
> based installer and I thought that speaking to the real guys and
> sharing would be a good way to start.

Thanks for reaching out to Fedora QA.  We are definitely looking for
ways to make this better too! :)

> Any feedback is greatly appreciated.

Hongqing Yang and Tao Wu are working on a series of virt-based automated
installation tests designed to exercise tests in our test matrix [1].
Their work is included in a branch (or two) of the autoqa project.  I
know they have progressed with creating test drivers (python scripts)
for URL, DVD-ISO and HD-ISO installs.  

The wiki roadmap [2] is a bit busy, so it's hard to get a sense of
progress from that, but I'm sure Hongqing or Tao can give a more
accurate progress update (and maybe a virtual-demo).

Thanks,
James

[1] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[2] https://fedoraproject.org/wiki/Is_anaconda_broken_roadmap


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

Instalatron: Anaconda testing framework

[Sergio Rubio]

Greetings!

Posted this to the wrong mailing list (David Cantrell suggested using
this one instead).

Linking to avoid re-typing :), my apologies:

https://www.redhat.com/archives/anaconda-devel-list/2011-July/msg00090.html

In a nutshell, we are looking for better ways to test our Anaconda
based installer and I thought that speaking to the real guys and
sharing would be a good way to start.

Any feedback is greatly appreciated.

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

Re: [Fedora QA] #224: Joining proventesters request

[Fedora QA]

#224: Joining proventesters request
--+-
  Reporter:  mkrizek  |   Owner:  jlaska
  Type:  proventester request |  Status:  closed
  Priority:  minor|   Milestone:
 Component:  Proventester Mentor Request  | Version:
Resolution:  fixed|Keywords:
--+-
Changes (by jlaska):

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

Comment:

 Replying to [comment:2 mkrizek]:
 > Thank you James, I have read and understood the proventester
 instructions and have already applied for group membership.

 Sponsored!  Welcome to proventesters and happy testing!

-- 
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] #224: Joining proventesters request

[Fedora QA]

#224: Joining proventesters request
--+-
  Reporter:  mkrizek  |   Owner:  jlaska  
  Type:  proventester request |  Status:  assigned
  Priority:  minor|   Milestone:  
 Component:  Proventester Mentor Request  | Version:  
Resolution:   |Keywords:  
--+-
Comment (by mkrizek):

 Thank you James, I have read and understood the proventester instructions
 and have already applied for group membership.

 Thanks,
 Martin

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

Re: Rawhide Acceptance Test for F16 summary

[James Laska]

On Tue, 2011-07-19 at 06:05 -0400, Tao Wu wrote:
> Greetings folks,
> 
> Just wanted to summarize how testing held up for the rawhide acceptance test 
> run of Fedora 16.  Thanks for your attention.  It is unfortunately that the 
> rawhide installation version has not passed the major test, please refer to 
> the bug 723144.  Let's expect the exciting coming out of next version!
> 
> If you have spare time and want to contribute by verify this version, the 
> test cases and results can be found on the following URL:
> https://fedoraproject.org/wiki/Test_Results:Fedora_16_Rawhide_Acceptance_Test_1#Test_Matrix
> 
> Thanks a lot!

Thanks Tao!  I don't have anything to add to your results since I don't
yet have a rawhide/F16 system to test with.  I'm seeing the same bug
(bug#723144) you reported on a baremetal system.  Please consider
escalating this issue as a F16 Alpha release blocker since I suspect
this impacts the following Alpha release criteria [1] ...

The installer must be able to complete an installation using the
entire disk, existing free space, or existing Linux partitions
methods, with or without encryption enabled 

If anyone is already running rawhide, there are a few post-install tests
linked on the above test matrix that could use some feedback.

Thanks,
James

[1] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria


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: [Fedora QA] #224: Joining proventesters request

[Fedora QA]

#224: Joining proventesters request
--+-
  Reporter:  mkrizek  |   Owner:  jlaska  
  Type:  proventester request |  Status:  assigned
  Priority:  minor|   Milestone:  
 Component:  Proventester Mentor Request  | Version:  
Resolution:   |Keywords:  
--+-
Changes (by jlaska):

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

Comment:

 Hi Martin,

 I'm happy to sponsor your proventester request.  Please take a moment to
 read through the proventester instructions at
 http://fedoraproject.org/wiki/Proven_tester. After reading, please confirm
 that you ...

 1. have read and understand the instructions, and will follow the
 instructions when testing Fedora critical path updates.
 2. understand how to enable the update-testing repository
 3. are familiar with providing test feedback using either the Bodhi web
 interface, or the fedora-easy-karma utility

 After confirming the above items, please apply for group membership using
 the Fedora Account System (FAS) by visiting
 https://admin.fedoraproject.org/accounts/group/view/proventesters

 Once the above steps are completed, I will approve your membership into
 'proventesters' and unleash you into the world of proventester bodhi
 karma!  Don't hesitate to ask questions if anything is unclear.

 Thanks!
 James

-- 
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] #224: Joining proventesters request

[Fedora QA]

#224: Joining proventesters request
-+--
 Reporter:  mkrizek  |   Owner: 
 Type:  proventester request |  Status:  new
 Priority:  minor|   Milestone: 
Component:  Proventester Mentor Request  | Version: 
 Keywords:   |  
-+--
 Hi, I would like to join proventesters. Thank you.

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

rawhide report: 20110719 changes

[Rawhide Report]

Compose started at Tue Jul 19 08:15:24 UTC 2011

Broken deps for x86_64
--
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit)
almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit)
1:anerley-0.2.14-7.fc16.i686 requires libcamel-1.2.so.26
1:anerley-0.2.14-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit)
apvlv-0.0.9.8-4.fc16.x86_64 requires libpoppler.so.13()(64bit)
apvlv-0.0.9.8-4.fc16.x86_64 requires libpoppler-glib.so.6()(64bit)
bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit)
camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit)
cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet
deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
ekiga-3.3.0-10.fc16.x86_64 requires libopal.so.3.8.3()(64bit)
ekiga-3.3.0-10.fc16.x86_64 requires libpt.so.2.8.3()(64bit)
ekiga-3.3.0-10.fc16.x86_64 requires libcamel-1.2.so.26()(64bit)
em8300-0.18.0-3.fc15.x86_64 requires /etc/security/console.perms.d
evolution-couchdb-0.5.90-2.fc16.x86_64 requires 
libcamel-provider-1.2.so.26()(64bit)
evolution-couchdb-0.5.90-2.fc16.x86_64 requires 
libcamel-1.2.so.26()(64bit)
evolution-sharp-0.21.1-14.fc16.x86_64 requires 
libcamel-1.2.so.26()(64bit)
exaile-0.3.2.1-1.fc16.noarch requires hal
fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4
fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4
fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libgeos-3.2.1.so()(64bit)
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit)
fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit)
fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit)
freedink-engine-1.08.20101114-2.fc15.x86_64 requires 
libSDL_gfx.so.0()(64bit)
gambas2-gb-pdf-2.23.1-1.fc16.x86_64 requires libpoppler.so.13()(64bit)
garden-1.0.8-3.fc15.x86_64 requires liballeg.so.4.2()(64bit)
gdcm-2.0.17-3.fc16.i686 requires libpoppler.so.13
gdcm-2.0.17-3.fc16.x86_64 requires libpoppler.so.13()(64bit)
gedit-valencia-0.3.0-6.20110701git808152718e3ab.fc16.x86_64 requires 
libvala-0.12.so.0()(64bit)
ghc-hinotify-0.3.1-9.fc16.i686 requires libHSarray-0.3.0.2-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.i686 requires 
libHSdirectory-1.1.0.0-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.i686 requires 
libHSghc-prim-0.2.0.0-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.i686 requires 
libHSold-time-1.0.0.6-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.i686 requires 
libHSold-locale-1.0.0.2-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.i686 requires libHSunix-2.4.2.0-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.i686 requires 
libHSfilepath-1.2.0.0-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.i686 requires libHSbase-4.3.1.0-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.i686 requires 
libHSinteger-gmp-0.2.0.3-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.i686 requires 
libHScontainers-0.4.0.0-ghc7.0.2.so
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHSghc-prim-0.2.0.0-ghc7.0.2.so()(64bit)
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHSold-time-1.0.0.6-ghc7.0.2.so()(64bit)
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHSbase-4.3.1.0-ghc7.0.2.so()(64bit)
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHSinteger-gmp-0.2.0.3-ghc7.0.2.so()(64bit)
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHSold-locale-1.0.0.2-ghc7.0.2.so()(64bit)
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHSfilepath-1.2.0.0-ghc7.0.2.so()(64bit)
ghc-hinotify-0.3.1-9.fc16.x86_64 requires ghc(base-4.3.1.0) = 
0:c33a1741503ded8a0170884e8a2e4fa2
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHScontainers-0.4.0.0-ghc7.0.2.so()(64bit)
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHSarray-0.3.0.2-ghc7.0.2.so()(64bit)
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHSunix-2.4.2.0-ghc7.0.2.so()(64bit)
ghc-hinotify-0.3.1-9.fc16.x86_64 requires 
libHSdirectory-1.1.0.0-ghc7.0.2.so()(64bit)
ghc-hinotify-devel-0.3.1-9.fc16.i686 requires ghc = 0:7.0.2
ghc-hinotify-devel-0.3.1-9.fc16.i686 requires ghc = 0:7.0.2

Re: New BugZapper Introduction

[Matej Cepl]

Dne 18.7.2011 07:51, Sudhir Dharanendraiah napsal(a):
> My name is Sudhir and I'm from India (GMT +5:30). Being in the Quality 
> team for over 5 years, dealing with bugs has become part of my IT career 
> life. I was associated with data center support in the early part of my 
> career. I have vast experience in the space of Identity management, 
> cloud, RHQ.


Feel free to ping me on #fedora-bugzappers anytime (I am usually around
CET business hours and in the evening).

We also maintain (well, more or less maintain)
https://fedoraproject.org/wiki/BugZappers with all information we have
for budding bug zappers (particularly
https://fedoraproject.org/wiki/BugZappers/Joining is meant to be a good
start page).

Welcome on board!

Matěj

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

Rawhide Acceptance Test for F16 summary

[Tao Wu]

Greetings folks,

Just wanted to summarize how testing held up for the rawhide acceptance test 
run of Fedora 16.  Thanks for your attention.  It is unfortunately that the 
rawhide installation version has not passed the major test, please refer to the 
bug 723144.  Let's expect the exciting coming out of next version!

If you have spare time and want to contribute by verify this version, the test 
cases and results can be found on the following URL:
https://fedoraproject.org/wiki/Test_Results:Fedora_16_Rawhide_Acceptance_Test_1#Test_Matrix

Thanks a lot!


Good Luck,
Tao Wu
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

re-introduction

[Martin Krizek]

Hi all,

I would like to just shortly re-introduce myself. Last week I rejoined Fedora 
QA team after 5 months spent as an exchange student in Denmark. In upcoming 
months I will be busy with rpm packaging, notably autotest, and helping with 
developing AutoQA. I am looking forward to working with you all once again.

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

Re: [Fedora QA] #222: L10N Test Day

[Fedora QA]

#222: L10N Test Day
---+
  Reporter:  noriko|   Owner:   
  Type:  task  |  Status:  new  
  Priority:  major |   Milestone:  Fedora 16
 Component:  Test Day  | Version:   
Resolution:|Keywords:   
---+
Comment (by rhe):

 Replying to [comment:11 igor]:
 > I have created the draft test days wiki pages as suggested by Rui. Feel
 free to add your names and improve the pages. I'll add the links for
 downloading the images when we have them.

 Thanks Igor! I've added my name to the pages, and also created the F16
 test days category. We can also add the common bugs as a ''Nice to test''
 section below the test cases if in need.

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