Re: Updated Auto Scripts - Alpha Tested on my KVM Domains

[He Rui]

Hi Bob,

Well done! I've tested this Alpha version, it works nicely on my
system. :) You can put it on your space for others to refer to.


Cheers,
Hurry


On Tue, 2010-07-13 at 18:13 -0400, Bob Lightfoot wrote:
> 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.
> 
> -- 
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe: 
> https://admin.fedoraproject.org/mailman/listinfo/test

-- 
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: mail text encoding (was: dynamic configuration .... )

[Antonio Olivares]

--- On Tue, 7/13/10, Michal Jaegermann  wrote:

> From: Michal Jaegermann 
> Subject: Re: mail text encoding (was: dynamic configuration  )
> To: "For testers of Fedora development releases" 
> 
> 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

Re: [Fedora QA] #66: Request for mentor to join as proven tester

[Fedora QA]

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

[Adam Williamson]

On Tue, 2010-07-13 at 17:58 -0600, Kevin Fenzi wrote:
> On Mon, 12 Jul 2010 08:33:34 -0700
> Adam Williamson  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] #106: proventester request - Nick Bebout - nb

[Fedora QA]

#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: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #97: Request for a mentor

[Fedora QA]

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

[Kevin Fenzi]

On Mon, 12 Jul 2010 08:33:34 -0700
Adam Williamson  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] #66: Request for mentor to join as proven tester

[Fedora QA]

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

[Adam Williamson]

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: Proven tester updates

[Adam Williamson]

On Wed, 2010-07-14 at 02:57 +0530, Rahul Sundaram wrote:
> On 07/14/2010 02:52 AM, Adam Williamson wrote:
> > 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 have a question.  I applied to be a proventester and was told to wait
> by a mentor.  Now what do I do to move ahead? 

Check your ticket. I replied to it on June 30th :)
-- 
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

[Fedora QA] #106: proventester request - Nick Bebout - nb

[Fedora QA]

#106: proventester request - Nick Bebout - nb
-+--
 Reporter:  nb   |   Owner: 
 Type:  proventester request |  Status:  new
 Priority:  major|   Milestone: 
Component:  Proventester Mentor Request  | Version: 
 Keywords:   |  
-+--
 I'm requesting membership in the proventester group.  I've had experience
 with packaging and testing packages and am a member of packager and
 provenpackager (and a packager group sponsor).

 I've read the proven tester instructions at
 https://fedoraproject.org/wiki/Proven_tester and understand them and will
 do my testing in accordance with them.

 I know how to enable the updates-testing repository and how to use the
 bodhi web interface (and fedora-easy-karma) to provide karma for them.

-- 
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] #97: Request for a mentor

[Fedora QA]

#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: 
Fedora QA 
Fedora Quality Assurance
-- 
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

[Bob Lightfoot]

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: Proven tester updates

[Rahul Sundaram]

On 07/14/2010 02:52 AM, Adam Williamson wrote:
> 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 have a question.  I applied to be a proventester and was told to wait
by a mentor.  Now what do I do to move ahead? 

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

Proven tester updates

[Adam Williamson]

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

Fedora 12 updates-testing report

[updates]

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

CriticalMass-1.0.2-8.fc12
awstats-7.0-1.fc12
dspam-3.9.0-7.fc12
perl-Data-Serializer-0.49-2.fc12
ppp-2.4.5-9.fc12
tortoisehg-1.1.1-1.fc12
xsane-0.997-10.fc12

Details about builds:



 CriticalMass-1.0.2-8.fc12 (FEDORA-2010-11074)
 SDL/OpenGL space shoot'em up game also known as critter

Update Information:

- Fix crash when trying to change resolution to a resolution too big for the
monitor (#566533)  - Fix miss-detection of available resolutions (they were all
given the width of the highest resolution)

ChangeLog:

* Mon Jul 12 2010 Hans de Goede  1.0.2-8
- Fix crash when trying to change resolution to a resolution too big for
  the monitor (#566533)
- Fix misdetection of available resolutions (they were all given the width
  of the highest resolution)

References:

  [ 1 ] Bug #566533 - [abrt] crash in CriticalMass-1.0.2-7.fc12
https://bugzilla.redhat.com/show_bug.cgi?id=566533




 awstats-7.0-1.fc12 (FEDORA-2010-11083)
 Advanced Web Statistics

Update Information:

New release: 7.0

ChangeLog:

* Tue Jul 13 2010 Aurelien Bompard  -  7.0-1
- version 7.0




 dspam-3.9.0-7.fc12 (FEDORA-2010-11072)
 A library and Mail Delivery Agent for Bayesian SPAM filtering

Update Information:

Fixes an issue where /var/lib/dspam/data isn't writeable by mail.

ChangeLog:

* Tue Jul 13 2010 Nathanael Noblet  - 3.9.0-7
- Fix dspam data dir permissions to be writeable by mail (Reported by Jonas 
Pasche)




 perl-Data-Serializer-0.49-2.fc12 (FEDORA-2010-11079)
 Modules that serialize data structures

References:

  [ 1 ] Bug #608447 - Review Request: perl-Data-Serializer - Modules that 
serialize data structures
https://bugzilla.redhat.com/show_bug.cgi?id=608447




 ppp-2.4.5-9.fc12 (FEDORA-2010-11080)
 The PPP (Point-to-Point Protocol) daemon.

ChangeLog:

* Tue Jul 13 2010 Jiri Skala  2.4.5-9
- fixes #613717




 tortoisehg-1.1.1-1.fc12 (FEDORA-2010-11085)
 Mercurial GUI command line tool hgtk

Update Information:

See http://bitbucket.org/tortoisehg/stable/wiki/ReleaseNotes#tortoisehg-111

ChangeLog:

* Tue Jul 13 2010 Mads Kiilerich  - 1.1.1-1
- tortoisehg-1.1.1 with minor bugfixes
- requires mercurial-1.6

References:

  [ 1 ] Bug #613941 - tortoisehg-1.1.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=613941
  [ 2 ] Bug #607519 - [abrt] crash in tortoisehg-1.0.4-1.fc13: 
thgconfig.py:1244:get_ini_config:TypeError: 'Undefined' object is 
unsubscriptable
https://bugzilla.redhat.com/show_bug.cgi?id=607519




 xsane-0.997-10.fc12 (FEDORA-2010-11086)
 X Window System front-end for the SANE scanner interface

ChangeLog:

* Tue Jul 13 2010 Nils Philippsen  - 0.997-10
- don't crash if no files are selected, take two
* Mon Jul 12 2010 Nils Philippsen  - 0.997-9
- distribute license and other documentation with xsane-common
--

Fedora 13 updates-testing report

[updates]

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

CriticalMass-1.0.2-8.fc13
awstats-7.0-1.fc13
dspam-3.9.0-7.fc13
flex-2.5.35-10.fc13
perl-Data-Serializer-0.49-2.fc13
perl-HTML-Parser-3.66-1.fc13
ppp-2.4.5-9.fc13
tortoisehg-1.1.1-1.fc13
xsane-0.997-10.fc13

Details about builds:



 CriticalMass-1.0.2-8.fc13 (FEDORA-2010-11078)
 SDL/OpenGL space shoot'em up game also known as critter

Update Information:

- Fix crash when trying to change resolution to a resolution too big for the
monitor (#566533)  - Fix miss-detection of available resolutions (they were all
given the width of the highest resolution)

ChangeLog:

* Mon Jul 12 2010 Hans de Goede  1.0.2-8
- Fix crash when trying to change resolution to a resolution too big for
  the monitor (#566533)
- Fix misdetection of available resolutions (they were all given the width
  of the highest resolution)

References:

  [ 1 ] Bug #566533 - [abrt] crash in CriticalMass-1.0.2-7.fc12
https://bugzilla.redhat.com/show_bug.cgi?id=566533




 awstats-7.0-1.fc13 (FEDORA-2010-11076)
 Advanced Web Statistics

Update Information:

New release: 7.0

ChangeLog:

* Tue Jul 13 2010 Aurelien Bompard  -  7.0-1
- version 7.0

References:

  [ 1 ] Bug #531952 - awstats-7.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=531952




 dspam-3.9.0-7.fc13 (FEDORA-2010-11077)
 A library and Mail Delivery Agent for Bayesian SPAM filtering

Update Information:

Fixes an issue where /var/lib/dspam/data isn't writeable by mail.

ChangeLog:

* Tue Jul 13 2010 Nathanael Noblet  - 3.9.0-7
- Fix dspam data dir permissions to be writeable by mail (Reported by Jonas 
Pasche)




 flex-2.5.35-10.fc13 (FEDORA-2010-11075)
 A tool for creating scanners (text pattern recognizers)

ChangeLog:

* Tue Jul 13 2010 Petr Machata  - 2.5.35-10
- Declare yyget_column and yyset_column in reentrant mode.
- Resolves: #612465

References:

  [ 1 ] Bug #612465 - No prototypes generated with reentrant
https://bugzilla.redhat.com/show_bug.cgi?id=612465




 perl-Data-Serializer-0.49-2.fc13 (FEDORA-2010-11084)
 Modules that serialize data structures

References:

  [ 1 ] Bug #608447 - Review Request: perl-Data-Serializer - Modules that 
serialize data structures
https://bugzilla.redhat.com/show_bug.cgi?id=608447




 perl-HTML-Parser-3.66-1.fc13 (FEDORA-2010-11030)
 Perl module for parsing HTML

Update Information:

http://cpansearch.perl.org/src/GAAS/HTML-Parser-3.65/Changes

ChangeLog:

* Mon Jul 12 2010 Marcela Mašláňová  3.66-1
- update
* Fri Jul  9 2010 Marcela Mašláňová  3.65-1
- update by Fedora::App::MaintainerTools 0.006
- updating to latest GA CPAN version (3.65)
- added a new br on perl(ExtUtils::MakeMaker) (version 0)
- altered br on perl(HTML::Tagset) (3.03, => 3)
- added a new br on perl(Test::More) (version 0)
- added a new br on perl(XSLoader) (version 0)
- altered req on perl(HTML::Tagset) (3.03 => 3)
- added a new req on perl(XSLoader) (version 0)
---

Re: mail text encoding (was: dynamic configuration .... )

[Michal Jaegermann]

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.

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

BTW - this particular message is sent with an utf-8 encoding.

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

Re: reporting bugs upstream : nothing on the wiki?

[Jóhann B. Guðmundsson]

  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

Re: dynamic configuration of wired network interfaces looks quite broken

[Antonio Olivares]

> > 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.  What could have been the problem?

Thanks,

Antonio


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

Re: reporting bugs upstream : nothing on the wiki?

[Jóhann B. Guðmundsson]

  On 07/13/2010 01:16 PM, Jonathan Kamens wrote:
>> "One shows level of competence and the other one not."
> Again, you are using unnecessarily hostile and demeaning language to get your 
> point across.
>
> I actually agree almost entirely with what you are saying. But the way you 
> are saying it is offensive and insulting. If you want to actually persuade 
> people to adopt your point of view, this is not the best way to do it.

You and the rest that are not the first that suggest that I should be 
more subtle in my speak it's a bit of a character flaw I have

I'm not so sure how I could have rephrased that without it having a 
negative impact of some sort.

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

Re: reporting bugs upstream : nothing on the wiki?

[Rahul Sundaram]

On 07/13/2010 07:09 PM, "Jóhann B. Guðmundsson" wrote:
>   On 07/13/2010 01:15 PM, Rahul Sundaram wrote:
>   
>> Again, not so black and white.  If a reporter is knowledgeable,  he or
>> she might just prefer working directly with upstream and there is
>> nothing wrong with that either.
>> 
> Neither did I say it was.
>
> But without any interaction with the reporter the maintainer has no way 
> of finding out if the reporter is knowledgeable enough.
>   

You are confused.  Ankur Sinha was talking about potential reporters
themselves choosing to report bugs upstream directly and documenting the
process to help them with that.  

Rahul

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

Re: reporting bugs upstream : nothing on the wiki?

[Jóhann B. Guðmundsson]

  On 07/13/2010 01:15 PM, Rahul Sundaram wrote:
> Again, not so black and white.  If a reporter is knowledgeable,  he or
> she might just prefer working directly with upstream and there is
> nothing wrong with that either.

Neither did I say it was.

But without any interaction with the reporter the maintainer has no way 
of finding out if the reporter is knowledgeable enough.

Many components in bugzilla show little to no interaction with reporters 
and in many cases packagers/maintainers look at reporter(s) more of a 
nuance than an actual useful resource at their disposal to help improve 
the component they are responsible for and ship with Fedora and thus 
improve the overall quality of the distribution.

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

RE: reporting bugs upstream : nothing on the wiki?

[Jonathan Kamens]

>"One shows level of competence and the other one not."

Again, you are using unnecessarily hostile and demeaning language to get your 
point across.

I actually agree almost entirely with what you are saying. But the way you are 
saying it is offensive and insulting. If you want to actually persuade people 
to adopt your point of view, this is not the best way to do it.

  Jik


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

Re: reporting bugs upstream : nothing on the wiki?

[Rahul Sundaram]

On 07/13/2010 06:41 PM, "Jóhann B. Guðmundsson" wrote:
> No it does not, nor was I speaking of cases were maintainer/packager 
> responds and works with a reporter and directs him upstream after 
> working with him trying to track down the problem.
>
> There is a very big difference working with a reporter then redirecting 
> him upstream vs directly directing him upstream with no guidance at all.
>
> One shows level of competence and the other one not.
>   

Again, not so black and white.  If a reporter is knowledgeable,  he or
she might just prefer working directly with upstream and there is
nothing wrong with that either.  Documenting such a process within
Fedora is helpful.   Ankur,  I would suggest you propose a draft rather
than have this free form discussion where everyone would feel compelled
to voice their opinions and lead it in a dozen different directions.


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

Re: reporting bugs upstream : nothing on the wiki?

[Jóhann B. Guðmundsson]

  On 07/13/2010 12:31 PM, Rahul Sundaram wrote:
> On 07/13/2010 05:57 PM, "Jóhann B. Guðmundsson" wrote:
>> Here again you continue to suggest we should pass the job of what falls
>> under the packager duty to someone else in the community because they
>> are to incompetent to accept the responsibility and full fill their role
>> as a packager/maintainer.
>>
> You are using unnecessarily hostile language to communicate your view
> points.  If you have played the role of a package maintainer, you would
> know that reality is not so black and white.  In some cases,  reporters
> directly working with upstream leads to a faster resolution and I have
> suggested that on occasions.  I don't think that makes me incompetent.


No it does not, nor was I speaking of cases were maintainer/packager 
responds and works with a reporter and directs him upstream after 
working with him trying to track down the problem.

There is a very big difference working with a reporter then redirecting 
him upstream vs directly directing him upstream with no guidance at all.

One shows level of competence and the other one not.

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

rawhide report: 20100713 changes

[Rawhide Report]

Compose started at Tue Jul 13 08:15:08 UTC 2010

Broken deps for x86_64
--
BackupPC-3.1.0-14.1.fc14.noarch requires perl-suidperl
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 libgnat-4.4.so()(64bit)
PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(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.x86_64 requires libgladeui-1.so.9()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(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)
claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires 
libchamplain-0.4.so.0()(64bit)
dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit)
deskbar-applet-2.30.0-1.1.fc14.x86_64 requires 
libedataserver-1.2.so.12()(64bit)
emerillon-0.1.1-2.fc13.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
emerillon-0.1.1-2.fc13.x86_64 requires libchamplain-0.4.so.0()(64bit)
emerillon-devel-0.1.1-2.fc13.i686 requires pkgconfig(champlain-0.4)
emerillon-devel-0.1.1-2.fc13.x86_64 requires pkgconfig(champlain-0.4)
entangle-0.1.0-4.fc14.x86_64 requires libgirepository-1.0.so.0()(64bit)
epiphany-2.31.3-2.fc14.x86_64 requires libgirepository-1.0.so.0()(64bit)
evolution-rss-0.1.9-7.20100525git.fc14.x86_64 requires 
libwebkit-1.0.so.2()(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)
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)
gnome-phone-manager-0.65-6.fc14.x86_64 requires 
libgnome-bluetooth.so.7()(64bit)
gnome-shell-2.31.2-3.fc14.x86_64 requires 
libgirepository-1.0.so.0()(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)
lekhonee-gnome-0.11-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit)
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)
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)
manedit-1.2.1-3.fc12.x86_64 requires man
mine_detector-6.0-3.fc13.x86_64 requires libgnat-4.4.so()(64bit)
mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires 
mingw32(libpng-3.dll)
moblin-panel-status-0.1.21-3.fc14.x86_64 requires 
libchamplain-0.4.so.0()(64bit)
mutter-mbl-2.29.1_0.4-1.fc14.i686 requires libgirepository-1.0.so.0
mutter-mbl-2.29.1_0.4-1.fc14.x86_64 requires 
libgirepository-1.0.so.0()(64bit)
mutter-mbl-devel-2.29.1_0.4-1.fc14.i686 requires 
libgirepository-1.0.so.0
mutter-mbl-devel-2.29.1_0.4-1.fc14.x86_64 requires 
libgirepository-1.0.so.0()(64bit)
perl-DBI-Dumper-2.01-8.fc12.x86_64 requires perl(:MODULE_COMPAT_5.10.0)
perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1)
perl-Mail-Box-2.095-1.fc14.noarch requires perl(File::FcntlLock)
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires 
perl(:MODULE_COMPAT_5.10.1)
perl-Test-AutoBuild-1.2.2-9.fc12.x86_64 requires 
perl(:MODULE_COMPAT_5.10.0)

plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch 
requires jakarta-commons-logging-javadoc
plplot-ada-5.9.6-1.fc14.i686 requires libgnat-4.4.so
plplot-ada-5.9.6-1.fc14.x86_64 requires libgnat-4.4.so()(64bit)
python3-beaker-1.5.3-4.fc14.noarch requires python3-paste
qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
seed-2.31.1-2.fc14.i686 requires libgirepository-1.0.so.0
seed-2.31.1-2.fc14.x86_64 requires libg

Re: reporting bugs upstream : nothing on the wiki?

[Rahul Sundaram]

On 07/13/2010 05:57 PM, "Jóhann B. Guðmundsson" wrote:
>
> Here again you continue to suggest we should pass the job of what falls 
> under the packager duty to someone else in the community because they 
> are to incompetent to accept the responsibility and full fill their role 
> as a packager/maintainer.
>   

You are using unnecessarily hostile language to communicate your view
points.  If you have played the role of a package maintainer, you would
know that reality is not so black and white.  In some cases,  reporters
directly working with upstream leads to a faster resolution and I have
suggested that on occasions.  I don't think that makes me incompetent. 

Rahul

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

Re: reporting bugs upstream : nothing on the wiki?

[Jóhann B. Guðmundsson]

  On 07/13/2010 08:36 AM, Ankur Sinha wrote:
> 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?
Here again you continue to suggest we should pass the job of what falls 
under the packager duty to someone else in the community because they 
are to incompetent to accept the responsibility and full fill their role 
as a packager/maintainer.

It falls under packagers responsibility to be the bridge between 
upstream and Fedora.

Packagers/maintainers already have upstream bugzilla account and are 
subscripted to various mailing list related to the component they ship.

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

Dont make the assumption that every reporter has the same time, skills 
and patience as you.

We need to nurture the newcomers not the experience once.

The new reporter gradually will get the experience and even start to 
work directly with upstream if the first step is as little as possible.

If it takes him several hours to file a single bug report then that step 
is to steep and we lose a potential report from our community.

Redirecting that reporter upstream seriously complicates that first step.

> 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

This is a goal we should not waste time and resource trying to achieve.

Reporters themselves will find their way upstream if they care enough 
about the component in question and when they are ready to do so.

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 (looks like solved)

[cornel panceac]

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

-- 
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: dynamic configuration of wired network interfaces looks quite broken (looks like solved)

[Michal Jaegermann]

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: dynamic configuration of wired network interfaces looks quite broken

[Ed Greshko]

 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æ[ÀÐ> `Ÿ]Ö]íǺ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: reporting bugs upstream : nothing on the wiki?

[Michael Schwendt]

On Mon, 12 Jul 2010 20:15:39 +, Jóhann wrote:

>   On 07/12/2010 07:32 PM, Ankur Sinha wrote:
> > Why is it "simply ludicrous"? It only needs following simple
> > instructions. You don't really need to learn anything for this. I'm not
> > asking $grandma to do it
> 
> How are you going to determine that's it's was not '$grandma' was not 
> actually the one that filed the report in the first place?
> 
> > That's no where to a solution. Please, constructive ideas would help.
> > You'll have to explain "unnecessary confusion, burden and what not on
> > the whole QA community". I got no clue what that refers to.
> >
> 
> Have you really never filled a bug upstream that got rejected because of 
> the component that was shipped with $distro ?
> Standard procedure in some of them is simply to start with what they 
> have in git.
> 
> Let's start playing that ping pong game with new reporters shall we..
> 
> > It isn't always possible to do. I've seen the amount of bugs that
> > packages receive, bridging all of them to upstream isn't really possible
> > at times.
> 
> If the maintainer does not have the time to maintain his own component 
> he should ask for ( more ) co maintainer ship or do the community and 
> the distro a favour and drop the component from Fedora or allow some one 
> who does have the time and the skills necessary to take over the component.

Earlier in your mail you've raised some valid questions. But please stop
there. Don't extend it into hostility. Fedora is open enough for anyone
with time, skills, and *interest* to contribute something. If you think
something sucks, step forward and contribute. It is not necessary for an
existing packager to orphan a package before somebody else could help.
Such a person would need to submit patches to the upstream project anyway
and only touch the Fedora packages when nobody else would apply the
patches. Further, you should know that for some types of bugs, not even
upstream knows all the code well enough to find the solution quickly.
For example, it is common for some types of programming bugs (such as
heap/stack corruption, concurrency, race conditions) to result in
stacktraces which are only about side-effects. With a tool like ABRT it is
normal to see a flood of reports until the real problem is fixed [possibly
in a dependency].

> We gain absolutely nothing other than bad reputation and frustration 
> amongst end user by shipping components that get zero to no maintenance 
> and response in bugzilla, an extra loads to triagers who triaged the bug 
> ( if they did that is ) frustration of reporters that had over 
> expectation on the result of his first report and added loads on forums 
> and #fedora to either come up with workaround or simply interect with 
> all end users that are using that broken ill maintained ( even sometimes 
> dead upstream ) component.

And we gain absolutely nothing either by having bugzappers close tickets 
with scripts instead of contributing real triaging.

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.
 
> Please take the time to do the math of how many upstream bugzilla 
> reporters and triagers should be subscribed to of all the components 
> let's simply start with critical path and amount of documentation of the 
> interaction on procedure on all of those upstream bugzilla instances 
> need to be in place. ( you can move on to Full blown shipped spin if 
> that does not make you realize that it's dead end )
> 
> JBG
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: reporting bugs upstream : nothing on the wiki?

[Ankur Sinha]

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