Re: reporting bugs upstream : nothing on the wiki?
On Mon, 2010-07-12 at 19:44 +, Jóhann B. Guðmundsson wrote: On 07/12/2010 07:24 PM, Adam Williamson wrote: It's a topic that's currently under discussion on -devel. In practice I'd say it varies. Some reporters certainly are willing to make good upstream reports. Some aren't, indeed, but I think Ankur's probably right that we can add value to the ecosystem (urgh, excuse me while I shoot myself for that one) by providing good instructions for those who _are_ willing to go the extra mile. Those instruction for those components should then be written and maintained by the maintainer(s) of that component. This is an interesting idea. I don't think the maintainers themselves would have the time to do this. Can this be passed on to the mentors, to pass on as an activity for new Ambassadors ;) ? They'll learn too in the process, and might end up co-maintaining some packages (which is a good thing!). It would be a good idea to have as many people as possible exposed to the bug reporting process. Starting with new Ambassadors is some what going down to the roots. Comments? That means he/they will need to create step by step a.k.a spoon feeding instruction for. . . ( keep in mind here the this may be an individual that has no technical knowledge what so ever and took the time to file his/her first report. The response to that first report will be the deciding factor if that individual continues to file reports in the future ) How to create an account in upstream bug tracker ( not all upstream bug trackers are mozilla bugzilla ). Generic instructions for this are available everywhere. This is simple and hardly takes a minute. (I don't know how many bugzillas I've joined up already) How to open up a terminal and compile the component from scratch from upstream repository encase upstream rejects the report based on what's package and shipped in Fedora or requires the reporter to recreate the failure using the upstream bits. etc. etc. ect.. Don't we have a policy of staying close to upstream? Are there a lot of differences in the upstream package and what fedora ships? I maintain a few packages, and they're all same as the upstream source. (just curious) This depends on the bug and cannot be generalized. Bugs that are reproducible on all machines will not require this. Upstream will handle those (I'm sure they'll be happy to do it themselves than wait for the reporter to get back to them , if ever). Machine specific bugs have no other solution. If upstream can't reproduce it, it has to rely on the reporter for feedback. The maintainer can't do much too here. Upstreams interested in getting good bug reports do keep a good documentation of how to go about it. If they don't, we can't do much, it's really their loss. What I'm saying is that we encourage users to go all the way to upstream and report bugs rather than stopping at our bugzilla. As Jóhann already mentioned, rather forcefully, this is a difficult to achieve goal. Even partially achieving it would be an improvement IMO. regards, Ankur JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: dynamic configuration of wired network interfaces looks quite broken
On 07/13/2010 11:51 AM, Antonio Olivares wrote:
¸¤z=�¤Í%EøòøLãÐ H
*P¤õlCv=
;HXÝs#ÑRí”U-ÊÎí¹•¨¥º£O:V
¥®�iêà{aÌäåPlºtkY’®¬\'“V5rÍnÈgQç´/§2æ[ÀÐbË
`Ÿ]Ö]íǺSº£ÚŒ†%³0½×•+;Ûpª#†b›+ͪ^ö[Æ6^ò’Ë–ŸúY–¤M
Miichal,
Sorry, but I don't understand this. The message does not appear right.
Which language is it set?
Am I the only one who sees it/saw it this way?
I think you may be the only one seeing it this way. The message was
sent as Content-Type: text/plain; charset=us-ascii.
Check the archives to see how it should look...
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: dynamic configuration of wired network interfaces looks quite broken (looks like solved)
On Tue, Jul 13, 2010 at 08:34:44AM +0300, cornel panceac wrote: mystery remains how my printer got its IP number. It is hanging from the same switch. Really weird ... could be only certain port in the switch. tried another? (like switch between printer's and computer's) At least four different ports on a switch were affected. I know that not from swapping cables but from trying other ends. Now it is too late to check although it is difficult to imagine why troubles would be so selective but maybe. That static IP assignments worked just fine did not help in a diagnosis. I realized eventually that over-the-air packets do not travel through this piece of hardware. Too late now. After a switch reset everything works as expected. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: reporting bugs upstream : nothing on the wiki?
On 07/13/2010 08:42 AM, Michael Schwendt wrote: And we gain absolutely nothing either by having bugzappers close tickets with scripts instead of contributing real triaging. These scripts are there for a reason. Mostly to provide some interaction to new reporters. Lowering their expectation, showing some activity on the report etc. They dont solve the underlying problem of no bug activity but atleast it's better than no feedback to new reporters. If you have means to determine components that get zero to no maintenance and reponse in bugzilla, please use them more wisely instead of ignoring such a problem until dist EOL. We actually can and perhaps do but don't publish it however that's something that infra can answer. ( I suspect making this public would require some discussion in the community as in maintainers might not be willing to show the world their bugzilla stats ) If we are not we kinda must ( amongst other things ), to be able to determine where to effectively allocate QA resources. The Fedora Virtualization community shows an perfect example on how this should be done ( atleast one way of doing it ). By looking at the http://fedoraproject.org/wiki/Virtualization_bugs wiki page we can see varius bugzilla stats on all the components in the Virtualization Group and they do share the script that does it ( on bottom of the page ). It does however not show how long it took from the bug status to go from new to open to assign and if the bug EOL and how long it took for a reporter to answer needinfo request etc. so we could keep stats on how much time the average workflow of a bug takes and inform all parties involved in the workflow what to expect from each other. ( Triaging takes x time. Reporter takes y time. Fix for the bug z. time ). JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Proven tester updates
Hi, everyone! Just a note that I've made a few updates to the proven testers stuff. I updated the Proven_tester page - https://fedoraproject.org/wiki/Proven_tester - with the content of my draft for combining the old version of that page with the mentor and joining-the-group instructions. We voted to use my draft at the last QA meeting, for those who weren't there, see http://fedoraproject.org/wiki/QA/Meetings/20100712 . I made some further changes, too. I added a note about the new --critpath-only parameter that's been added to fedora-easy-karma with the latest update in Rawhide, and updates-testing for F12 and F13. This parameter will cause f-e-k to display only critical path updates which have not yet been approved, so it's handy if you have limited time for testing and just want to give feedback on the most important updates as fast as possible. I also added a note that you should have SELinux enabled and set to Enforcing mode when testing. This was prompted by a mail Dan Walsh sent to the -devel list about an update which caused problems with SELinux stuff; I thought it was probably best to remind everyone that we should make sure updates don't cause SELinux problems, and we need to have SELinux enabled to check that. I turned the JoinProvenTesters page into a redirect to the Proven_testers page, and updated all links from other pages to JoinProvenTesters to be links to Proven_testers instead. Feedback welcome on any problems with the changes - 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
Updated Auto Scripts - Alpha Tested on my KVM Domains
Dear Test Community:
Some time ago I mentioned automatic scripts for starting and
executing commands on a VM. At the time the scripts were geared to
VirtualBox-OSE. Now I switched to using KVM and regeared the scripts
for automatic starting, maintenance and shutdown of a VM on a host.
The attached script works on my F13_x86-64 Host running a KVM
Guest. I tested the script on F12i386 ; F12x8664 ; F13i386 and F13x8664.
The flags on my system are below:
[...@fedoramythbox ~]$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi
flexpriority
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi
flexpriority
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi
flexpriority
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi
flexpriority
Sincerely,
Bob Lightfoot
P.S. - The comments at the start of the script should be self
explanatory. This is an alpha version and not fully bullet-proof. It
needs to run as root for the virsh commands to have authority.
#!/usr/bin/expect -f
#
# This Expect script was hand generated by BobLfoot on Mon Ju1 12 20:53:00 2010
# Expect and autoexpect were both written by Don Libes, NIST.
#
# It's purpose is to connect to and update the Fedora386Outgoing KVM Domain
#
# Establish the Constants for this Script
# vmname is the Domains Name
set vmname SomeDomainName
# domusername is the Domains Standard Users Name
set domusername User
# passuer is the Domains Standard Users Password
set passuser PaSsWoRdHeRe
# passroot is the Domains Root Users Password
set passroot RoOtPaSsWoRdHeRe
# vmip is the Domains Fixed IP address in the DHCP Table
set vmip ip.to.kvm.domain
# vmcmd is the super user level command you want the VM to run
# examples are as follow:
# set vmcmd yum update --enablerepo=updates-testing --skip-broken -y
set vmcmd yum install fedora-easy-karma yum-plugin-filter-data
--enablerepo=updates-testing --skip-broken -y
# set vmcmd ls -laZR /
#set vmcmd yum --filter-groups=core,critical-path-\* update
--enablerepo=updates-testing -y --skip-broken
# Boilerplate from Don Libes for conservative mode
set force_conservative 0 ;# set to 1 to force conservative mode even if
;# script wasn't run conservatively originally
if {$force_conservative} {
set send_slow {1 .1}
proc send {ignore arg} {
sleep .1
exp_send -s -- $arg
}
}
# Real Working Script Starts Here
set timeout -1
spawn $env(SHELL)
sleep .1
# Start target KVM Domain
send -- virsh start $vmname\r
expect #
sleep 15
# SSH to Started VM
send -- ssh $domuserna...@$vmip\r
expect {
password: {
send -- $passuser\r
}
No route to host {
send -- echo Waiting 15 More Seconds for $vmname to Boot\r
sleep 15
send -- ssh $domuserna...@$vmip\r
exp_continue
}
timed out {
send -- echo Waiting 15 More Seconds for $vmname to Boot\r
sleep 15
send -- ssh $domuserna...@$vmip\r
exp_continue
}
refused {
send -- echo Waiting 15 More Seconds for $vmname to Boot\r
sleep 15
send -- ssh $domuserna...@$vmip\r
exp_continue
}
yes/no {
send -- yes\r
sleep .1
exp_continue
}}
sleep .1
expect $
send -- su\r
sleep .1
expect Password:
send -- $passroot\r
sleep 1
expect #
send -- $vmcmd\r
expect #
send -- exit\r
sleep .1
expect $
send -- exit\r
sleep .1
expect #
# Stop the Target KVM Domain
send -- virsh shutdown $vmname\r
sleep 15
expect #
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Fedora QA] #97: Request for a mentor
#97: Request for a mentor --+- Reporter: masami | Owner: adamwill Type: proventester request | Status: assigned Priority: major| Milestone: Component: Proventester Mentor Request | Version: Resolution: |Keywords: --+- Comment (by masami): Hello,[[BR]] I was approved the Proven Testers group. Thank you very much. I'm sorry for late reply. -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/97#comment:2 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Wanted: a Fedora tech guru for POSSE South Africa
Just wanted to point to this blog post from Mel: http://blog.melchua.com/2010/07/13/wanted-a-fedora-tech-guru-for-posse-south-africa/ A good opportunity for anyone who's in Africa (or can get there) to spend an all-expenses-paid week spreading the gospel to university professors! -- 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: [Fedora QA] #66: Request for mentor to join as proven tester
#66: Request for mentor to join as proven tester --+- Reporter: sundaram | Owner: adamwill Type: proventester request | Status: assigned Priority: major| Milestone: Component: Proventester Mentor Request | Version: Resolution: |Keywords: --+- Comment (by sundaram): Yes, I have read that page and I am familiar with bodhi and fedora-easy- karma. -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/66#comment:3 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [urgent] libsndfile security update needs 2 proventesters
On Mon, 12 Jul 2010 08:33:34 -0700 Adam Williamson awill...@redhat.com wrote: Luke, I really think turning on critpath requirements for everything in the world is going to prove to be a problem. I certainly never expected this to hit EPEL, AFAIK Fedora QA and FESCo have no actual power to commit to this policy for EPEL. How hard would it be to just disable this requirement again for EPEL at least? Yeah, it looks like Luke is going to revert this for EPEL very soon... kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Fedora QA] #97: Request for a mentor
#97: Request for a mentor --+- Reporter: masami | Owner: adamwill Type: proventester request | Status: closed Priority: major| Milestone: Component: Proventester Mentor Request | Version: Resolution: fixed|Keywords: --+- Changes (by adamwill): * status: assigned = closed * resolution: = fixed Comment: whoops, I forgot to close the ticket. -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/97#comment:3 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Fedora QA] #106: proventester request - Nick Bebout - nb
#106: proventester request - Nick Bebout - nb --+- Reporter: nb | Owner: Type: proventester request | Status: closed Priority: major| Milestone: Component: Proventester Mentor Request | Version: Resolution: fixed|Keywords: --+- Changes (by adamwill): * status: new = closed * resolution: = fixed Comment: then I hereby dub you a proven tester. thanks very much for volunteering. -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/106#comment:1 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [urgent] libsndfile security update needs 2 proventesters
On Tue, 2010-07-13 at 17:58 -0600, Kevin Fenzi wrote: On Mon, 12 Jul 2010 08:33:34 -0700 Adam Williamson awill...@redhat.com wrote: Luke, I really think turning on critpath requirements for everything in the world is going to prove to be a problem. I certainly never expected this to hit EPEL, AFAIK Fedora QA and FESCo have no actual power to commit to this policy for EPEL. How hard would it be to just disable this requirement again for EPEL at least? Yeah, it looks like Luke is going to revert this for EPEL very soon... yes, we had a private mail chat about it, I think he either has already committed or will very soon commit a fix to turn it off for EPEL. thanks luke! -- 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: [Fedora QA] #66: Request for mentor to join as proven tester
#66: Request for mentor to join as proven tester --+- Reporter: sundaram | Owner: adamwill Type: proventester request | Status: closed Priority: major| Milestone: Component: Proventester Mentor Request | Version: Resolution: fixed|Keywords: --+- Changes (by adamwill): * status: assigned = closed * resolution: = fixed Comment: You are approved as a proven tester, then! I've added you to the FAS group. Go forth and test =) thanks for volunteering. -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/66#comment:4 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: mail text encoding (was: dynamic configuration .... )
--- On Tue, 7/13/10, Michal Jaegermann mic...@harddata.com wrote: From: Michal Jaegermann mic...@harddata.com Subject: Re: mail text encoding (was: dynamic configuration ) To: For testers of Fedora development releases test@lists.fedoraproject.org Date: Tuesday, July 13, 2010, 10:18 AM On Tue, Jul 13, 2010 at 08:34:20AM -0700, Antonio Olivares wrote: Am I the only one who sees it/saw it this way? I think you may be the only one seeing it this way. The message was sent as Content-Type: text/plain; charset=us-ascii. Check the archives to see how it should look... http://lists.fedoraproject.org/pipermail/test/2010-July/092051.html His posts on the archives look fine, but this one ^ looks the same way I saw it. You posted it so it includes all garbled content you have quoted. I did not do it on purpose, that garbled content was what I saw, and I responded/asked is it only me? What could have been the problem? It appears that your mail reader is using some hardwired encoding instead of paying attention to a charset declaration in what was posted. Or maybe some intermediate mail server is kind enough for you to do conversions with some random settings. Regular yahoo mail, using konqueror web browser. BTW - this particular message is sent with an utf-8 encoding. Michał -- I am not using any special mail, just basic yahoo mail. There appears to be no problem with this one. What could it have been? I normally don't see these kinds of messages, but this one came like that. I ask myself what could it have been? Thanks and sorry for asking. Regards, Antonio -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
