Question: easy way to watch new bugs

Sat Mar 8 16:43:03 UTC 2008

hi,

Not fully awake yet, but I plan to look into what you all have said here,
the way to use "cli" ( what ever that is ) + other tips. 

Right now, I am just chatting a little bit about my own situation:

I have a laptop which I hoped to get working on wireless. (a HP C6715b),
and previously (Pesario V6508EO) - so I have been fighting with this for
more then a half year. My hope has been to figure out how to install the
bcm43xx driver ( now it is b43 ) - but I have not had any success this far.
( this started with Fedora core 6) - which I was able to get running, but not
without difficulties. APIC hardware problems still exist, for example.
( just completed filing some note on it )

Because of all the problems - I have a couple of thousand emails on yahoo from
this list, without an account for downloading. ( need some better scheme )

"Matej Cepl" <mcepl at redhat.com> wrote: 
> b) Sorry, life is tough, but bugs filed here donâ€™t count as such.  
>    There is no duty on developers to read this list and they 
>    would have to file bugs themselves anyway.
>
No, I have come to realize that. 

"Andrew Farris" <lordmorgul at gmail.com>  wrote:
>
>  If you run pirut, or yum, right after each other the info should be the 
>  same AFAIK.
>

Nope, they don't. 
Not sure about the abbrevation AFAIK, but does a program like pirut store 
some internal stuff ??  For example, I don't now how many times I have ticked off language support. I don't understand zulu, swahili, and all those other things. But it damn well include it by default each time you run the program. 
Similar with games, etc.  On packages - I may remove one, while Yumex report
it is still there, and vice versa. ( but I may have to check this a bit better
to make sure when/where/how it happens, that not updates include it, etc. )

>
> I'm unclear what the problem is here.  You want to use the older dvd
> version of xorg drivers but update other stuff?
>

No. There was no driver from xorg initially, so the Fedora DVD doesn't have
a driver. For some time I had to use ATI driver, but recently a working driver
from xorg is working, but not included on the DVD. So any reinstall cause
a lot of extra work. And the update driver don't set up config files correctly.

>
> It would probably be helpful if you report this in bugzilla and see if
> there are some improvements that can be made to get these tools to work more
> closely together.
>

Ahh..well, I understand that I have to spend some time with bugzilla.     

                           ----------------

Some ideas:

How does updates work ?  Are they sent over a separate port ?
Why not have a bug-report tool on a separate port, not using email ?

1. RPM uses a data base for packages, so let say one would encapsulate each
package with tags. My favorite editor in bash, is jmacs. I use it as an
example:

--------------------------------------------------------------------------
Name        : joe                          Relocations: (not relocatable)
Version     : 3.5                               Vendor: Red Hat, Inc.
Release     : 3.fc7                         Build Date: Fri 23 Feb 2007 11:57:51 AM CET
Install Date: Wed 05 Mar 2008 03:40:02 PM CET      Build Host: hs20-bc1-5.build.redhat.com
Group       : Applications/Editors          Source RPM: joe-3.5-3.fc7.src.rpm
Size        : 1015971                          License: GPL
Signature   : DSA/SHA1, Fri 18 May 2007 10:11:54 PM CEST, Key ID b44269d04f2a6fd2
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://sourceforge.net/projects/joe-editor/
Summary     : An easy to use, modeless text editor
Description :
Joe is a powerful, easy to use, modeless text editor.
It uses the same WordStar keybindings used in Borland's development
environment.
/etc/joe
/etc/joe/charmaps
/etc/joe/charmaps/klingon
/etc/joe/ftyperc
/etc/joe/jicerc.ru
/etc/joe/jmacsrc
/etc/joe/joerc
/etc/joe/jpicorc
etc....
------------------------------------------------------------------------------

Now, notice the signature field. Is the Key ID unique ?
If not, a tag may be created. The listed files may be indexed as 1,2,3,4...etc.
Asume that I encounter a problem - let say an error in charmaps/klingon:

A tool, with a simple email window type, where I may include info as you
do to bugzilla is at hand. Communicate directly on a a separate port back to
site. The message will include:

<Key ID b44269d04f2a6fd2>
<file number:3>
<Descriptive problem:"..">
<Linux version: >
<Hardware:      >
<Configuration: >

+ what ever else one may agree upon.

( Notice the Hardware, as this is very important. I just added some report on
an "..MP-BIOS bug: 8254 timer not connected to IO-APIC", something that only appear on my specific hardware. There are endless of problems related to special
hardware and platform ) 

2. At the other end, Bugzilla - the report will be filed under the Key ID, and
so forth. To attempt to make it a bit more clear:  - the suggested application
don't need a separate database, as it exist at both ends. In many cases you
may not need to file much description of the problem. On connect to site,
the info regarding the package will be displayed - but you may go ahead and
send your hardware profile, the package ID, etc. This will clearly identify
how many people encounter the same problem, and the priority to have it fixed.

3. Notice the <Configuration:> field. A user could use the tool to check how
others have set up their specific hardware. It is a damn pain to figure out
a lot of these things. Example, after a long time, you find this info: "SHMConfig" "true" has to be set in xorg.conf
Well, okay - but how/where ?? In this case, I just tag what I want, and import the file. 

4. The above example may include a description of "smart" settings in .bashrc
and a whole exchange of options that other users have solved, or found valuable.
This is actually some of the most difficult things for new users of Linux.
So, this exchange could be of great value for everyone.

5. RedHat, Bugzilla, or anyone else will have a count/rating of uses of programs. Developers may also check how their product is received. It will
be a feedback as to what problems exist, for example - bugs or errors that
none thought of as the program is ported to another platform.

6. At the site end, other fields may be included, as to HOWTO documents, etc.
Plus other options to include, or find out how to use. 

7. It is voluntary, it is transparent, you know what you install, if you want
to participate, etc. Not like Microsoft or others in which you never know
what is exchanged under the hood.

8. If this would cause high demands for a site, configs and other info could
use bitTorrent schemes, etc. While I would think that the application would
be of great value for RedHat and others.

                            -------------------

So what is needed ?  With a little help, I could probably write such a thing
myself, while I am not a programmer, and most likely not anywhere close to
what I suggest. But programs like pirut and Yum exist, and only minor changes
may be needed. 

If you like this idea, please help promote and bring it up for debate and
discussion.

//ARNE

---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20080308/12c1f992/attachment.htm>