Process to become package maintainer stalled?

2010-04-14 Thread Klaus Grue
Hello,

In the process of becomming a package maintainer, the following has 
magically appeared when I log in to my Fedora account:

 To do queue:
 Miscellaneous Tasks
 Download a client-side certificate

I downloaded a certificate April 11, got a reciept by e-mail, and 
used the certificate without problems.

But my to-do queue still tells me to download a certificate.

On April 13, I downloaded two more times so that I now have one 
functioning and two revoked certificates. But the to-do queue still asks 
me to download a certificate.

In addition, I have got a mail April 10 saying:

 Welcome to the Fedora packager group.
 Please continue the process from:
 https://fedoraproject.org/wiki/PackageMaintainers/Join#
   Add_Package_to_CVS_and_Set_Owner

But the instructions there say I should wait for a fedora-cvs flag to 
appear in the Bugzilla report for my package (Bug 523715). I can find no 
such flag.

Am I missing something? Or have I ended up in some zombie state in the 
account system? Or should I just show more patience?

Here are my group memberships:
Signed CLA Group
Fedora CLA Group
Fedora Bugs Group
Fedora Packager CVS Commit Group

Cheers,
Klaus
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Process to become package maintainer stalled?

2010-04-14 Thread Michael Schwendt
On Wed, 14 Apr 2010 09:01:50 +0200 (CEST), Klaus wrote:

 Hello,
 
 In the process of becomming a package maintainer, the following has 
 magically appeared when I log in to my Fedora account:
 
  To do queue:
  Miscellaneous Tasks
  Download a client-side certificate
 
 I downloaded a certificate April 11, got a reciept by e-mail, and 
 used the certificate without problems.
 
 But my to-do queue still tells me to download a certificate.

It _always_ shows that option. It's a permanent option to download a fresh
cert.
 
 On April 13, I downloaded two more times so that I now have one 
 functioning and two revoked certificates. But the to-do queue still asks 
 me to download a certificate.
 
 In addition, I have got a mail April 10 saying:
 
  Welcome to the Fedora packager group.
  Please continue the process from:
  https://fedoraproject.org/wiki/PackageMaintainers/Join#
Add_Package_to_CVS_and_Set_Owner
 
 But the instructions there say I should wait for a fedora-cvs flag to 
 appear in the Bugzilla report for my package (Bug 523715). I can find no 
 such flag.

Things to check:
1) In bugzilla, do you use the same email address as in your account in
the Fedora Account System?
2) In the bugzilla ticket, do you see the Flags: field at the right?
3) If you log in, can you click Edit right of the Flags: field?
4) Then notice the fedora-cvs box and use it according to the guidelines.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


radeon powersaving

2010-04-14 Thread Christoph Höger
Hi all,

I was wondering if I could that last noisy fan on my pc to rest (sitting
on my 4850): Is there any part of radeon powersaving yet in fedora 12
(in what package should it be, kernel, ati or radeon)? 
If so, where can I start testing?

regards

Christoph


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi allows resubmitting an update with different packages?!

2010-04-14 Thread Matt McCutchen
On Sat, 2010-04-10 at 22:30 -0700, Adam Williamson wrote:
 On Fri, 2010-04-09 at 20:05 -0400, Matt McCutchen wrote:
  How hard is it to use Bodhi properly?

 To be clear, there's nothing 'improper' about editing updates, it's
 common practice. You can suggest ways that the practice could be
 improved, but telling other people they're not using Bodhi properly
 really isn't appropriate in this case.

You are right.  I apologize for the remark.

I thought Dan was suggesting that the confusion caused by seeing old
feedback on an edited update page was not a big deal (though I could be
wrong about that too), and I was reacting to that suggestion.

-- 
Matt

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Process to become package maintainer stalled?

2010-04-14 Thread Klaus Grue
 ... the instructions there say I should wait for a fedora-cvs flag
 ... I can find no such flag
 ... Am I missing something? ...

 Things to check:
 ...
 2) In the bugzilla ticket, do you see the Flags: field at the right?
 3) If you log in, can you click Edit right of the Flags: field?
 4) Then notice the fedora-cvs box and use it according to the guidelines.

Thanks. It works.

Cheers,
Klaus
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: potentially unmaintained packages

2010-04-14 Thread Felix Kaechele
Hi Michael,

On 14.04.2010 09:19, Michael Schwendt wrote:

 Why would it need to be rebuilt manually?

You don't need to. If a package is working perfectly fine and no update 
is available there's no need to rebuild.

 Hey, this pkg hasn't been built, even in rawhide, in a while, maybe you
 should 1. check that out and 2. if the pkg is dead or unmaintained
 consider retiring it.

 It's stable, works, and is still being used by dependencies. Would I
 rebuild just for fun (and possibly introduce bugs related to temporary
 issues with compilation, RPM, or other build deps)?

Again, there really is no need to. And Seth didn't say that there is a 
need to do so. I think he really tried hard to make his point of the 
list not having any implications.
For my part I found this list quite useful because I almost forgot that 
I took over rubyripper some time ago.
I had some issues with it lately and I almost filed a bug for it. I can 
just imagine the hilarity if that bug would have been assigned to myself 
directly ;)

So just see this list as a service that you _can_ use. But you aren't 
required to use this service.

Thanks Seth.

Felix



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: devkit-power-daemon broken?

2010-04-14 Thread Ankur Sinha
On Tue, 2010-04-13 at 14:24 +0100, Peter Robinson wrote:
 On Tue, Apr 13, 2010 at 1:46 PM, Ankur Sinha sanjay.an...@gmail.com wrote:
  hey,
 
  I've had this issue for quite a while now.
 
  I have a HP pavilion laptop that runs a Fedora 12 (up to date) and vista
  (the original that came with the laptop). I'm using GNOME as of now.
 
  When a power cut occurs, the power applet continues to show the adapter
  plugged in,and battery at 100%. This restrains my system from
  hibernating etc correctly, or even dimming display when ac power is
  removed.
 
  I've already filed a bug here.
 
  https://bugzilla.redhat.com/show_bug.cgi?id=554363
 
  To confirm that there is indeed a bug, I've checked using acpi-tool,
  htop all of which give correct values of battery and that there is no ac
  power attached.
 
  As the bugreport says, killing /usr/libexec/devkit-power-daemon and re
  running it corrects the status, however it's irritating to have to do
  this every time a power cut occurs (if im around that is).
 
  Can someone think of a fix or at least a work around for the time
  being?
 
 I can confirm I see the same on a Dell Latitude D630C on F-12 as well.
 
 Peter


There appear to be bugs on this issue[1][2] with lengthy discussions
already having taken place. The bug has been reported in 9/2009, which
is 6 months back. Can the concerned maintainers please prioritize this
bug and squash it asap? Proper functioning of power manager on a laptop
is really important. :)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=521874
[2] https://bugzilla.redhat.com/show_bug.cgi?id=499948

Thanks !


-- 
regards,
Ankur 
- FAS : ankursinha ; franciscod @ Freenode
- gpg --keyserver pgp.mit.edu --recv-keys 5E9BF638



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: potentially unmaintained packages

2010-04-14 Thread Michael Schwendt
On Wed, 14 Apr 2010 12:20:05 +0200, Felix wrote:

  Hey, this pkg hasn't been built, even in rawhide, in a while, maybe you
  should 1. check that out and 2. if the pkg is dead or unmaintained
  consider retiring it.
 
  It's stable, works, and is still being used by dependencies. Would I
  rebuild just for fun (and possibly introduce bugs related to temporary
  issues with compilation, RPM, or other build deps)?
 
 Again, there really is no need to. And Seth didn't say that there is a 
 need to do so. I think he really tried hard to make his point of the 
 list not having any implications.

Too many words in his message, too many sentences that imply something.
The last sentence of the message would have been enough, IMO.

 For my part I found this list quite useful because I almost forgot that 
 I took over rubyripper some time ago.

Then you might find the following web interface helpful:
https://admin.fedoraproject.org/pkgdb/users/packages/heffer

 I had some issues with it lately and I almost filed a bug for it. I can 
 just imagine the hilarity if that bug would have been assigned to myself 
 directly ;)
 
 So just see this list as a service that you _can_ use. But you aren't 
 required to use this service.

Sure it's useful somehow. I didn't mean to say it wouldn't be useful.
All the extra comments in the message just made me wonder.

 Thanks Seth.
 
 Felix

The list doesn't cover packages that have been (re)built, but suffer
from many issues as covered by ageing bugzilla tickets which have not been
commented on by the package maintainer.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: potentially unmaintained packages

2010-04-14 Thread Seth Vidal


On Wed, 14 Apr 2010, Michael Schwendt wrote:

 On Tue, 13 Apr 2010 17:03:55 -0400 (EDT), Seth wrote:

 Hi,
   I worked on a script back in January which produced a list of packages
 that needed to be looked at. The reason was that the pkg had not been
 built by koji into dist-rawhide by a non-automated process in more than 6
 months.

 Why would it need to be rebuilt manually?

I never said it would. I just said it hadn't been rebuilt by a 
non-automated process.


 It's stable, works, and is still being used by dependencies. Would I
 rebuild just for fun (and possibly introduce bugs related to temporary
 issues with compilation, RPM, or other build deps)?

I never said you had to rebuild it. I think I tried very hard to make it 
clear that this list was just to give folks a heads up.

-sv

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Heads-up: Configuration language changes in new varnish version

2010-04-14 Thread Ingvar Hagelund
varnish is a high performance http accellerator.

I'm just to tag and build the new upstream version 2.1.0 of varnish.
This new version has a change in the vcl configuration language that may
need changes to existing vcl code.

If you are using varnish, please read the release notes carefully.,
http://varnish-cache.org/wiki/changelog_2.0.6-2.1.0

Ingvar

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: radeon powersaving

2010-04-14 Thread Matthew Garrett
On Wed, Apr 14, 2010 at 09:36:54AM +0200, Christoph Höger wrote:
 Hi all,
 
 I was wondering if I could that last noisy fan on my pc to rest (sitting
 on my 4850): Is there any part of radeon powersaving yet in fedora 12
 (in what package should it be, kernel, ati or radeon)? 
 If so, where can I start testing?

No. It's being worked on.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Heads-up: Configuration language changes in new varnish version

2010-04-14 Thread Matthew Garrett
On Wed, Apr 14, 2010 at 02:31:42PM +0200, Ingvar Hagelund wrote:
 varnish is a high performance http accellerator.
 
 I'm just to tag and build the new upstream version 2.1.0 of varnish.
 This new version has a change in the vcl configuration language that may
 need changes to existing vcl code.

To which releases?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Reverting kaddressbook back to previous version?

2010-04-14 Thread Thomas Janssen
On Tue, Apr 13, 2010 at 10:46 AM, Juha Tuomala juha.tuom...@iki.fi wrote:
 On Mon, 12 Apr 2010, Ryan Rix wrote:
 On Mon 12 April 2010 6:40:59 am Juha Tuomala wrote:
 I recall, that the earlier version had some level of Akonadi support
 as well, so in theory, would it be possible to revert the codebase
 back to the one that can actually be used?

 Sure, try `man yum`.

 You mean that we're here to solve our own problems, not to make a
 good distribution for great public?

We *have* a good distribution for great public. Kaddressbook works as
expected for me. If you have a problem with it, ask for help and you
get help.
You got the right answer for what you asked. *You* want the older
version. Good luck downgrading and have fun with it.

-- 
LG Thomas

Dubium sapientiae initium
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: potentially unmaintained packages

2010-04-14 Thread Jon Ciesla
On 04/14/2010 05:20 AM, Felix Kaechele wrote:
 Hi Michael,

 On 14.04.2010 09:19, Michael Schwendt wrote:

 Why would it need to be rebuilt manually?

 You don't need to. If a package is working perfectly fine and no update
 is available there's no need to rebuild.

 Hey, this pkg hasn't been built, even in rawhide, in a while, maybe you
 should 1. check that out and 2. if the pkg is dead or unmaintained
 consider retiring it.

 It's stable, works, and is still being used by dependencies. Would I
 rebuild just for fun (and possibly introduce bugs related to temporary
 issues with compilation, RPM, or other build deps)?

 Again, there really is no need to. And Seth didn't say that there is a
 need to do so. I think he really tried hard to make his point of the
 list not having any implications.
 For my part I found this list quite useful because I almost forgot that
 I took over rubyripper some time ago.
 I had some issues with it lately and I almost filed a bug for it. I can
 just imagine the hilarity if that bug would have been assigned to myself
 directly ;)

 So just see this list as a service that you _can_ use. But you aren't
 required to use this service.

I agree, and thought Seth made his point well.  I typically consider the 
set of things in Fedora I need to worry about to be the set of bugs 
assigned to me, plus the ones I've files, plus any FTFFS or broken deps 
I'm aware of.  If something sits there for years, no bugs, no need for 
rebuild, and no new releases, and it works, then I'm happy.  Very happy 
in fact.

As an added bonus, I took some amusement from the sheer size of my part 
of his list.

-J

 Thanks Seth.

 Felix




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


F13 Beta release notes

2010-04-14 Thread Paul W. Frields
The Documentation team has prepared and posted a draft of the Fedora
13 Release Notes for the Beta release:

http://docs.fedoraproject.org/drafts.html

It's recommended that developers check out sections that are relevant
or important to them.  If you find that a page needs changes, you can
use the link at the start of each major section, provided in rather
startling magenta, to get to the wiki page that houses the content
source for that part of the document.

Make your changes on the wiki.  Please keep in mind that to make our
translators' jobs easier, it is best to add or delete a paragraph, as
opposed to making minor tweaks inside a paragraph.  Sometimes this may
not be possible, so just give it your best shot.  Documentation folks
are almost always available on IRC Freenode #fedora-docs to help if
needed.

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
  Where open source multiplies: http://opensource.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F13 Beta release notes

2010-04-14 Thread Bruno Wolff III
On Wed, Apr 14, 2010 at 10:20:32 -0400,
  Paul W. Frields sticks...@gmail.com wrote:
 The Documentation team has prepared and posted a draft of the Fedora
 13 Release Notes for the Beta release:
 
 http://docs.fedoraproject.org/drafts.html
 
 It's recommended that developers check out sections that are relevant
 or important to them.  If you find that a page needs changes, you can
 use the link at the start of each major section, provided in rather
 startling magenta, to get to the wiki page that houses the content
 source for that part of the document.

It might be appropriate to mention bug 567113 in the Postgres section, but
Tom Lane should have the final call there.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F13 Beta release notes

2010-04-14 Thread drago01
On Wed, Apr 14, 2010 at 4:20 PM, Paul W. Frields sticks...@gmail.com wrote:
 The Documentation team has prepared and posted a draft of the Fedora
 13 Release Notes for the Beta release:

 http://docs.fedoraproject.org/drafts.html

PPC is no longer a primary arch, so the wording about supporting it
should be removed.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Graphics Test Week in progress: ATI/AMD today

2010-04-14 Thread Adam Williamson
Just a reminder to everyone that we're still right in the middle of
Graphics Test Week. The NVIDIA Test Day[1] yesterday went very well, and
of course you can still add results to that page if you didn't get
around to testing yet. Today is the ATI/AMD Test Day[2], so if your
graphics card is from ATI/AMD, please do come join us in
#fedora-test-day on Freenode IRC[3] and get your test results into the
page. And looming tomorrow, as well as what will no doubt be an epic
beatdown of the L.A. Kings by the Stanley Cup-bound Vancouver Canucks,
is Intel graphics Test Day[4]. Be there or else!

[1] https://fedoraproject.org/wiki/Test_Day:2010-04-13_Nouveau
[2] https://fedoraproject.org/wiki/Test_Day:2010-04-14_Radeon
[3] http://webchat.freenode.net/?channels=fedora-test-day
[4] https://fedoraproject.org/wiki/Test_Day:2010-04-15_Intel
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Heads-up: Configuration language changes in new varnish version

2010-04-14 Thread Matthew Garrett
On Wed, Apr 14, 2010 at 01:50:58PM +0100, Matthew Garrett wrote:
 On Wed, Apr 14, 2010 at 02:31:42PM +0200, Ingvar Hagelund wrote:
  varnish is a high performance http accellerator.
  
  I'm just to tag and build the new upstream version 2.1.0 of varnish.
  This new version has a change in the vcl configuration language that may
  need changes to existing vcl code.
 
 To which releases?

Sorry, I should have just checked koji. 13 and rawhide, so that's fine.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: intent to retire: kudzu

2010-04-14 Thread Nils Philippsen
On Tue, 2010-04-13 at 16:45 -0400, Bill Nottingham wrote:
 Bill Nottingham (nott...@redhat.com) said: 
  I'd like to retire kudzu for F-13.
  
  Why?
  - There are places where it almost certainly does not work with current 
  kernels
  - It's so deprecated that one of its replacements (HAL) has since been
frozen and deprecated
  - Given that, its upstream is very dead 
  
  However, it is still being required by two programs:
  - hwbrowser
  - fwfstab
  
  If someone wants to keep it limping along for thsese two programs I can
  orphan it. But I'd really rather just retire it.
 
 I just noticed I hadn't actually done this yet. I've retired it for
 F-14/rawhide; it can remain in F-13, although it's unlikely to see any
 useful updates there.

I've retired hwbrowser in Rawhide/F-13 as well, it doesn't make sense to
keep it around as it can't handle much of the the new hardware, i.e.
anything kudzu doesn't know.

Nils
-- 
Nils Philippsen  Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety.  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: potentially unmaintained packages

2010-04-14 Thread Patrice Dumas
On Tue, Apr 13, 2010 at 05:03:55PM -0400, Seth Vidal wrote:
 Hi,
 
 Hey, this pkg hasn't been built, even in rawhide, in a while, maybe you 
 should 1. check that out and 2. if the pkg is dead or unmaintained 
 consider retiring it.

The junction with bug information is also interesting. I think that also
having theinformation about new releases would be quite interesting, for
packages that use the automatic new updates notification system.

--
Pat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F13 Beta release notes

2010-04-14 Thread Michael Cronenworth
drago01 wrote:
 PPC is no longer a primary arch, so the wording about supporting it
 should be removed.

Sony recently removed Other OS support from all PS3 units. Should the 
Playstation line be removed as well?


(I haven't updated my PS3 yet so I can still use Fedora)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: potentially unmaintained packages

2010-04-14 Thread Toshio Kuratomi
On Wed, Apr 14, 2010 at 09:38:03AM +0200, Christoph Wickert wrote:
 Am Dienstag, den 13.04.2010, 17:03 -0400 schrieb Seth Vidal:
 
  http://skvidal.fedorapeople.org/misc/potentially-unmaintained/2010-04-13/
 
 I see packages_by_user, pkgs_with_bugs and everything. What I would like
 to see is pkgs_with_bugs_by_user, because this is something that should
 really considered harmful. If a package has no bugs, I don't think it
 needs a new build.
 
Reading this made me think that this would be a great thing to expose
continuously, for instance on this packagedb page:

https://admin.fedoraproject.org/pkgdb/users/packages/toshio

Querying bugzilla is a comparatively expensive process so it's probably
something we need to do by syncing the count of bugs into the db via a cron
job.  Any takers?

-Toshio


pgpWDyRcHOOYG.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20100413 changes

2010-04-14 Thread James Antill
On Tue, 2010-04-13 at 22:03 +0200, Michael Schwendt wrote:
 On Tue, 13 Apr 2010 12:35:09 -0700, Jesse wrote:
 
   I wonder if there's something about the commit message which
   caused the report to chop it off?
  
   No, it's a [fixed] bug in repodiff, which ignores %changelog entries  
   added
   on the same day as the latest entries found in the previous release  
   of the
   package.
  
   The sys-admins would need to upgrade repodiff, createrepo, and
   dependencies, to those versions that fix this. It's related to Yum
   upstream tickets #6 and #7.
  
  
  This report is generated in a chroot of rawhide, so if those fixed  
  builds are in rawhide than they will be used.
  
  --
  Jes
 
 Well, then somebody should reopen  http://yum.baseurl.org/ticket/7
 and ask for applying the fix to repodiff. It's included in the patch I
 added to the ticket more than a year ago (the timestamp comparison fix to
 cover changes added on the same day).

 Sorry for that, I thought I'd fixed it when I closed it!
 Anyway, just built a new yum-utils HEAD (which includes the repodiff
fix) in rawhide:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2115503

-- 
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: potentially unmaintained packages

2010-04-14 Thread Jason L Tibbitts III
 TK == Toshio Kuratomi a.bad...@gmail.com writes:

TK Querying bugzilla is a comparatively expensive process so it's
TK probably something we need to do by syncing the count of bugs into
TK the db via a cron job.  Any takers?

I could probably whip something up.

 - J
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: potentially unmaintained packages

2010-04-14 Thread Jeff Spaleta
On Wed, Apr 14, 2010 at 6:09 AM, Jon Ciesla l...@jcomserv.net wrote:
 I agree, and thought Seth made his point well.  I typically consider the
 set of things in Fedora I need to worry about to be the set of bugs
 assigned to me, plus the ones I've files, plus any FTFFS or broken deps
 I'm aware of.  If something sits there for years, no bugs, no need for
 rebuild, and no new releases, and it works, then I'm happy.  Very happy
 in fact.

I'm not actually sure that the packages on that list that I am
responsible for actually do work.. nor do I have any evidence that
anyone uses these packages on such a regular basis that they would be
tested in the run up to a release.  Hell man, matplotlib was runtime
broken for over a month and it wasn't until Beta that someone actually
filed a ticket about it (after I discovered the problem myself) and I
expect matplotlib more widely used than something like g3data.  Unless
I start getting some affirmative feedback through some sort of phone
home process, similar to popcon, that my packages are actually
installed and used I have to assume that noone is using them on a
regular basis and noone is testing prior to release.

So in that sense Seth's list is a reminder to me to test those
packages for myself on the Beta (now that I have a Beta install up and
running...even though there was an intel graphics problem during
install...but that's another story)

-jefI have a very very long rant que'd up about falling back from a
graphical install to a text install that is so minimal that it doesnt
even include lspci. I've no problem with a text based install that is
very minimal for people who deliberately choose to use it... but I
have a really big problem failing over to it from a graphical install
and expecting people who don't know what they are doing to know wtf is
going on after they reboot the systemspaleta
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20100414 changes

2010-04-14 Thread Rawhide Report
Compose started at Wed Apr 14 08:15:04 UTC 2010

Broken deps for i386
--
evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1
fwfstab-0.03-5.fc12.noarch requires kudzu
hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0
paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0
rubygem-right_aws-1.10.0-3.fc14.noarch requires 
rubygem(right-http_connection) = 0:1.2.4
sipwitch-0.7.5-0.fc14.i686 requires libucommon.so.2
sipwitch-cgi-0.7.5-0.fc14.i686 requires libucommon.so.2
sipwitch-plugin-forward-0.7.5-0.fc14.i686 requires libucommon.so.2
sipwitch-plugin-scripting-0.7.5-0.fc14.i686 requires libucommon.so.2
sipwitch-plugin-subscriber-0.7.5-0.fc14.i686 requires libucommon.so.2
sipwitch-plugin-zeroconf-0.7.5-0.fc14.i686 requires libucommon.so.2
sipwitch-runtime-0.7.5-0.fc14.i686 requires libucommon.so.2
zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2



Broken deps for x86_64
--
evolution-couchdb-0.3.2-2.fc13.x86_64 requires 
libcouchdb-glib-1.0.so.1()(64bit)
fwfstab-0.03-5.fc12.noarch requires kudzu
hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit)
paperbox-0.4.4-2.fc12.x86_64 requires libtrackerclient.so.0()(64bit)
rubygem-right_aws-1.10.0-3.fc14.noarch requires 
rubygem(right-http_connection) = 0:1.2.4
sipwitch-0.7.5-0.fc14.x86_64 requires libucommon.so.2()(64bit)
sipwitch-cgi-0.7.5-0.fc14.x86_64 requires libucommon.so.2()(64bit)
sipwitch-plugin-forward-0.7.5-0.fc14.x86_64 requires 
libucommon.so.2()(64bit)
sipwitch-plugin-scripting-0.7.5-0.fc14.x86_64 requires 
libucommon.so.2()(64bit)
sipwitch-plugin-subscriber-0.7.5-0.fc14.x86_64 requires 
libucommon.so.2()(64bit)
sipwitch-plugin-zeroconf-0.7.5-0.fc14.x86_64 requires 
libucommon.so.2()(64bit)
sipwitch-runtime-0.7.5-0.fc14.i686 requires libucommon.so.2
sipwitch-runtime-0.7.5-0.fc14.x86_64 requires libucommon.so.2()(64bit)
zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2



New package hunspell-ast
Asturian hunspell dictionaries
Removed package kiosktool
Removed package kudzu
Updated Packages:

OpenGTL-0.9.13-1.fc13
-
* Mon Apr 05 2010 Rex Dieter rdie...@fedoraproject.org - 0.9.13-1
- OpenGTL-0.9.13


Pyrex-0.9.9-1.fc14
--
* Tue Apr 13 2010 Matthew Barnes mbar...@redhat.com - 0:0.9.9-1
- Update to 0.9.9


bcfg2-1.0.1-1.fc14
--
* Tue Apr 13 2010 Jeffrey C. Ollie j...@ocjtech.us - 1.0.1-1
- Update to final version


blacs-1.1-39.fc14
-
* Tue Apr 13 2010 Tom spot Callaway tcall...@redhat.com - 1.1-39
- openmpi doesn't use TRANSCOMM = -DUseMpich
- put libraries in $MPI_LIB, not $MPI_HOME

* Wed Feb 24 2010 Tom spot Callaway tcall...@redhat.com - 1.1-38
- get rid of environment module files altogether (the openmpi/mpich2 env 
modules are sufficient)


byzanz-0.2.2-1.fc14
---
* Tue Apr 13 2010 Benjamin Otte o...@redhat.com - 0.2.2-1
- Update to 0.2.2


bzr-2.2-0.5.b1.fc14
---
* Tue Apr 13 2010 Toshio Kuratomi tos...@fedoraproject.org - 2.2-0.5.b1
- Clean up rhel/fedora conditionals bz#537254


cclive-0.6.2-1.fc14
---
* Mon Mar 29 2010 Nicoleau Fabien nicoleau.fab...@gmail.com 0.6.2-1
- Update to 0.6.2
- libquvi usage


childsplay-1.5-1.fc14
-
* Tue Apr 13 2010 Johan Cwiklinski johan AT x-tnd DOT be 1.5-1
- 1.5
- Update Sources URL making rpmlint happy


chunkd-0.6-0.7.gdd5a3430.fc14
-
* Wed Apr 14 2010 Jeff Garzik jgar...@redhat.com - 0.6-0.7.gdd5a3430
- update source to commit dd5a34302420f8fe77e73fd009c725abb30bb8b3


cld-0.3-0.13.gab66f4f4.fc14
---
* Wed Apr 14 2010 Jeff Garzik jgar...@redhat.com - 0.3-0.13.gab66f4f4
- BuildRequires: fuse-devel

* Wed Apr 14 2010 Jeff Garzik jgar...@redhat.com - 0.3-0.12.gab66f4f4
- update to 0.3git commit ab66f4f49c35e7f35b56f9da0d3828a1c474a9ae


cups-1.4.3-3.fc14
-
* Tue Apr 13 2010 Tim Waugh twa...@redhat.com 1:1.4.3-3
- Handle SNMP supply level quirks (bug #581825).


deskbar-applet-2.30.0-1.fc14

* Tue Apr 13 2010 Luke Macken lmac...@redhat.com - 2.30.0-1
- Latest upstream release
- Fixes #581881, #573772, #523561
- Updated site-packages location patch

* Tue Dec 29 2009 Luke Macken lmac...@redhat.com - 2.28.0-1
- Update to 2.28.0


desktop-effects-0.8.6-1.fc14

* Tue Apr 13 2010 Adel Gadllah adel.gadl...@gmail.com - 0.8.6-1
- Update to 0.8.6
- Adds missing translations (RH #581395)


dogtag-pki-ca-ui-1.3.1-1.fc13
-
* Tue Mar 09 2010 Ade Lee a...@redhat.com 1.3.1-1
- Bugzilla Bug #545935 -  Add new client-auth ee port to 

Re: potentially unmaintained packages

2010-04-14 Thread Adam Williamson
On Wed, 2010-04-14 at 09:19 +0200, Michael Schwendt wrote:
 On Tue, 13 Apr 2010 17:03:55 -0400 (EDT), Seth wrote:
 
  Hi,
I worked on a script back in January which produced a list of packages 
  that needed to be looked at. The reason was that the pkg had not been 
  built by koji into dist-rawhide by a non-automated process in more than 6 
  months.
 
 Why would it need to be rebuilt manually?
  
  This list is NOT to shame or embarass anyone. It is only to say:
  
  Hey, this pkg hasn't been built, even in rawhide, in a while, maybe you 
  should 1. check that out and 2. if the pkg is dead or unmaintained 
  consider retiring it.
 
 It's stable, works, and is still being used by dependencies. Would I
 rebuild just for fun (and possibly introduce bugs related to temporary
 issues with compilation, RPM, or other build deps)?

It seems to me that Seth quite carefully wrote his email specifically to
forestall replies of this kind. Apparently it wasn't enough...

It seems quite clear to me that this is just an advisory email about
*possibly* unmaintained packages. If in fact it's not been rebuilt
simply because it doesn't need to be, exactly as the email says, that's
perfectly fine and there's nothing wrong with that. Just ignore it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: devkit-power-daemon broken?

2010-04-14 Thread Adam Williamson
On Wed, 2010-04-14 at 16:44 +0530, Ankur Sinha wrote:

 There appear to be bugs on this issue[1][2] with lengthy discussions
 already having taken place. The bug has been reported in 9/2009, which
 is 6 months back. Can the concerned maintainers please prioritize this
 bug and squash it asap? Proper functioning of power manager on a laptop
 is really important. :)
 
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=521874
 [2] https://bugzilla.redhat.com/show_bug.cgi?id=499948

AFAIK none of these are generic bugs. Handling AC plug/unplug is
actually not as simple as it seems, and can vary from device to device
(or, rather, ACPI implementation to ACPI implementation). So this is to
a degree system-specific.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: potentially unmaintained packages

2010-04-14 Thread Michael Schwendt
On Wed, 14 Apr 2010 11:01:01 -0700, Adam wrote:

 It seems to me that Seth quite carefully wrote his email specifically to
 forestall replies of this kind. Apparently it wasn't enough...

Of course not. The subject says potentially unmaintained packages.
The message makes a fuss about it, even mentions scenarios like retiring
packages. What it doesn't comment on is that despite missing rebuilds,
a package may still be maintained both in Fedora and upstream. It doesn't
mention other potentially unmaintained packages which are missing on
the list because they have seen rebuilds (even if just for spec
modifications), but which are dead upstream and unmaintained in Fedora.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: potentially unmaintained packages

2010-04-14 Thread Seth Vidal


On Wed, 14 Apr 2010, Michael Schwendt wrote:

 On Wed, 14 Apr 2010 11:01:01 -0700, Adam wrote:

 It seems to me that Seth quite carefully wrote his email specifically to
 forestall replies of this kind. Apparently it wasn't enough...

 Of course not. The subject says potentially unmaintained packages.
 The message makes a fuss about it, even mentions scenarios like retiring
 packages. What it doesn't comment on is that despite missing rebuilds,
 a package may still be maintained both in Fedora and upstream. It doesn't
 mention other potentially unmaintained packages which are missing on
 the list because they have seen rebuilds (even if just for spec
 modifications), but which are dead upstream and unmaintained in Fedora.

seriously? I don't think I ever said the list was all inclusive.

-sv

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: F13 Beta release notes

2010-04-14 Thread Adam Williamson
On Wed, 2010-04-14 at 10:20 -0400, Paul W. Frields wrote:
 The Documentation team has prepared and posted a draft of the Fedora
 13 Release Notes for the Beta release:
 
 http://docs.fedoraproject.org/drafts.html

Thanks for updating the system requirements. However, this looks like a
typo:

Minimum RAM for graphical: 348 MiB 

348 is a fairly odd amount, I suspect it's meant to be 384. If so, then
the cited 32-bit and 64-bit requirements are identical, and they could
be combined into a single section.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Reverting kaddressbook back to previous version?

2010-04-14 Thread Ryan Rix
On Wed 14 April 2010 6:53:24 am Thomas Janssen wrote:
 On Tue, Apr 13, 2010 at 10:46 AM, Juha Tuomala juha.tuom...@iki.fi 
wrote:
  On Mon, 12 Apr 2010, Ryan Rix wrote:
  On Mon 12 April 2010 6:40:59 am Juha Tuomala wrote:
  I recall, that the earlier version had some level of Akonadi support
  as well, so in theory, would it be possible to revert the codebase
  back to the one that can actually be used?
  
  Sure, try `man yum`.
  
  You mean that we're here to solve our own problems, not to make a
  good distribution for great public?
 
 We *have* a good distribution for great public. Kaddressbook works as
 expected for me. If you have a problem with it, ask for help and you
 get help.
 You got the right answer for what you asked. *You* want the older
 version. Good luck downgrading and have fun with it.

I suggested that Juha fix his issue by downgrading simply because of this. 
He was the same person who has been complaining about KAddressbook in 4.4 
since its initial release, two months ago.

Ryan

-- 
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-13 Branched report: 20100414 changes

2010-04-14 Thread Branched Report
Compose started at Wed Apr 14 09:15:04 UTC 2010

Broken deps for i386
--
gnome-shell-2.29.1-4.i686 requires gobject-introspection = 0:0.6.9
hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0
python-basemap-0.99.4-2.fc13.i686 requires libgeos-3.2.0.so
zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2



Broken deps for x86_64
--
gnome-shell-2.29.1-4.x86_64 requires gobject-introspection = 0:0.6.9
hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit)
python-basemap-0.99.4-2.fc13.x86_64 requires libgeos-3.2.0.so()(64bit)
zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2



New package qbzr
Bazaar plugin for Qt interface to most Bazaar operations
Removed package kiosktool
Updated Packages:

OpenGTL-0.9.13-1.fc13
-
* Mon Apr 05 2010 Rex Dieter rdie...@fedoraproject.org - 0.9.13-1
- OpenGTL-0.9.13


desktop-effects-0.8.5-2.fc13

* Tue Apr 06 2010 Adel Gadllah adel.gadl...@gmail.com - 0.8.5-2
- Fix changelog

* Tue Apr 06 2010 Adel Gadllah adel.gadl...@gmail.com - 0.8.5-1
- Update to 0.8.5
- Fixes RH #532618
- Includes new icons
- Drop upstreamed patch


dogtag-pki-ca-ui-1.3.1-1.fc13
-
* Tue Mar 09 2010 Ade Lee a...@redhat.com 1.3.1-1
- Bugzilla Bug #545935 -  Add new client-auth ee port to address CVE-2009-3555
  TLS: MITM attacks via session renegotiation


firefox-3.6.3-4.fc13

* Tue Apr 13 2010 Martin Stransky stran...@redhat.com - 3.6.3-4
- Fixed language packs (#559960)

* Mon Apr 12 2010 Martin Stransky stran...@redhat.com - 3.6.3-3
- Fixed multilib conflict


gnome-web-photo-0.9-8.fc13
--
* Mon Apr 12 2010 Martin Stransky stran...@redhat.com - 0.9-8
- Updated gecko dependency

* Tue Apr 06 2010 Jan Horak jho...@redhat.com - 0.9-7
- Rebuild against newer gecko


iso-codes-3.15-1.fc13
-
* Mon Apr 05 2010 Parag Nemade pnemade AT redhat.com - 3.15-1
- Update to 3.15


koffice-2.1.82-1.fc13
-
* Tue Apr 06 2010 Rex Dieter rdie...@fedoraproject.org - 3:2.1.82-1
- koffice-2.1.82

* Mon Apr 05 2010 Rex Dieter rdie...@fedoraproject.org - 3:2.1.81-9
- fix validation errors in krita_psd.desktop

* Fri Apr 02 2010 Rex Dieter rdie...@fedoraproject.org - 3:2.1.81-8
- kdchart(-devel) subpkgs, until a standalone kdchart surfaces (#575170)

* Fri Apr 02 2010 Rex Dieter rdie...@fedoraproject.org - 3:2.1.81-7
- fix for multilib upgrades
- fixup Epoch references in %changelog


koffice-langpack-2.1.82-1.fc13
--
* Tue Apr 06 2010 Rex Dieter rdie...@fedoraproject.org - 2:2.1.82-1
- koffice-l10n-2.1.82


mcu8051ide-1.3.5-1.fc13
---
* Tue Apr 13 2010 Shakthi Kannan shakthimaan [AT] gmail DOT com - 1.3.5-1
- Updated package to 1.3.5 upstream release


openswan-2.6.24-3.fc13
--
* Thu Feb 18 2010 Avesh Agarwal avaga...@redhat.com - 2.6.24-3
- Fix for making explicit (or avoiding implicit) linking 
  for pthread (#565410)
- Modified package description
- Fixed a typo (IKEv2 RFC number).


pki-ca-1.3.3-1.fc13
---
* Tue Mar 09 2010 Ade Lee a...@redhat.com 1.3.3-1
- Bugzilla Bug #545935 -  Add new client-auth ee port to address CVE-2009-3555 
  TLS: MITM attacks via session renegotiation


pki-common-1.3.3-1.fc13
---
* Tue Mar 09 2010 Ade Lee a...@redhat.com 1.3.3-1
- Bugzilla Bug #545935 -  Add new client-auth ee port to address CVE-2009-3555 
  TLS: MITM attacks via session renegotiation


pki-selinux-1.3.4-1.fc13

* Tue Mar 09 2010 Ade Lee a...@redhat.com 1.3.4-1
- Bugzilla Bug #545935 -  Add new client-auth ee port to address CVE-2009-3555 
  TLS: MITM attacks via session renegotiation


pki-setup-1.3.4-1.fc13
--
* Tue Mar 09 2010 Ade Lee a...@redhat.com 1.3.4-1
- Bugzilla Bug #545935 -  Add new client-auth ee port to address CVE-2009-3555
  TLS: MITM attacks via session renegotiation


pootle-2.0.3-1.fc13
---
* Thu Mar 25 2010 Dwayne Bailey dwa...@translate.org.za - 2.0.3-1
- Update to 2.0.3
   - Support for Qt TS files
   - Support for TMX and TBX files
   - Corrections to PostgreSQL support (#1368)
   - Some improvements to memory use
   - Timestamps for news items when viewed on the web
   - It is possible to change tree style more reliably (#1363)
   - More correct method for finding alternative translations
   - A complete translation into Asturian, and other translation updates
- Update to 2.0.2
   - Don't count the templates towards the front page statistics (#1345)
   - Fix password change/reset links work without registration (#1350)
   - Allow deleting translator comments (#1349)
   - Show the date of items on the news page
   - New and updated translations, 

Re: Can I have some documentation examples excluded from Abrt crash collection?

2010-04-14 Thread Karel Klic
Hi Jeff,

Good idea, also the opencv package would use this feature for its Python 
programming examples. Current ABRT cannot ignore crashes based on paths, 
so it must be developed.

Please file a RFE in Bugzilla, and include the filename mask(s) marking 
the files you want to exclude. I think it will be something like:
/usr/lib/python2.6/site-packages/scipy/*/examples/*.py

IMHO for the beginning it is right to have even package-specific 
configuration (like the excluded paths) in ABRT. Later this kind of 
configuration should move to the packages, as ABRT configuration files 
and feature set become more mature and stable.

Karel

Jeff Spaleta wrote:
 So I'm maintaining matplotlib and scipy.. which effectively allows
 scientists to pretend they are programmers

 So matplotlib includes a large selection of examples to read over as
 documentation. Some of these example do some crazy complicated things
 which make use of matplotlib and wont work out of the box because they
 need additional python modules that are strictly related to matplotlib
 functionality...examples on how to embed matplotlib pythonically and
 other such things.

 I would really like it if abrt could be prevented from triggering bug
 tickets when these examples crash.  The examples are deliberately
 provided as documentation of examples of things you can do with
 matplotlib...but not as code meant to function without additional
 thought on part of the user.

 Can I work with someone with regard to abrt to get these things excluded?

 -jef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: urgent testing call: F13 kernel-2.6.33.1-24.fc13

2010-04-14 Thread Stefan Schulze Frielinghaus
On Mi, 2010-04-07 at 16:51 -0700, Adam Williamson wrote:
 On Wed, 2010-04-07 at 22:30 +0200, Stefan Schulze Frielinghaus wrote:
  On Mi, 2010-04-07 at 09:17 -0700, Adam Williamson wrote:
  [...]
   Thanks to everyone for their testing, it's greatly appreciated. Based on
   the positive response here and on forums, we spun a new RC of the beta
   with the -24 kernel included, so now if you still want to help testing,
   please test that. See
   http://lists.fedoraproject.org/pipermail/test-announce/2010-April/61.html
.
  
  Kernel 2.6.33.1-19 and -24 do _not_ really work for me. I hadn't had the
  time to file a proper bug report but since no one screamed here an now,
  I will have to do so ;-)
 
 If -19 didn't work for you, we actually care less, strange as that may
 seem. Mostly this was about making sure -24 has no regressions compared
 to -19.
 
  Sorry for this quick and dirty bug report. Hopefully I will find some
  time during the weekend. Otherwise, hope this helps.
 
 Please file a regular report, or this won't get followed up.

Late, but done.

Just for the records if someone has a similar problem:

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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Can I have some documentation examples excluded from Abrt crash collection?

2010-04-14 Thread Mathieu Bridon
On Wed, Apr 14, 2010 at 21:53, Karel Klic kk...@redhat.com wrote:
 Hi Jeff,

 Good idea, also the opencv package would use this feature for its Python
 programming examples. Current ABRT cannot ignore crashes based on paths,
 so it must be developed.

 Please file a RFE in Bugzilla, and include the filename mask(s) marking
 the files you want to exclude. I think it will be something like:
 /usr/lib/python2.6/site-packages/scipy/*/examples/*.py

 IMHO for the beginning it is right to have even package-specific
 configuration (like the excluded paths) in ABRT. Later this kind of
 configuration should move to the packages, as ABRT configuration files
 and feature set become more mature and stable.

I'm not sure if that could be used for my own issues with ABRT, but
let me explain it.

When I'm developing a TG2 application, I sometimes get a traceback
(well, I'm not perfect :). ABRT sees the traceback, and wants me to
report a bug against Paster.

However, the bug is not in Paster, it's in my own code, and I know it
since I'm currently developing it (Paster is used to launch TG2
applications).

Would it be possible to ignore this kind of tracebacks while not
ignoring legit Paster issues?


--
Mathieu Bridon
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Reverting kaddressbook back to previous version?

2010-04-14 Thread Matt McCutchen
On Wed, 2010-04-14 at 15:53 +0200, Thomas Janssen wrote:
 On Tue, Apr 13, 2010 at 10:46 AM, Juha Tuomala juha.tuom...@iki.fi wrote:
  On Mon, 12 Apr 2010, Ryan Rix wrote:
  On Mon 12 April 2010 6:40:59 am Juha Tuomala wrote:
  I recall, that the earlier version had some level of Akonadi support
  as well, so in theory, would it be possible to revert the codebase
  back to the one that can actually be used?
 
  Sure, try `man yum`.
 
  You mean that we're here to solve our own problems, not to make a
  good distribution for great public?
 
 We *have* a good distribution for great public. Kaddressbook works as
 expected for me.

Please take the request seriously.  If Tuju is right that most users
would be better off with the older version, then that's what Fedora
should ship.  Tuju, if you can possibly be bothered to list some of the
regressions you consider most severe, that might help the discussion.

I have no experience with kaddressbook, but I had a similar experience
in October 2008 with Evolution 2.24.  There, the merging of the disk
summary code before it was anything near release quality caused many
regressions, including breaking threaded search folders, which I rely on
heavily.  Unfortunately, Evolution 2.22 had many equally severe bugs
(notably a crash when editing a sorted task list), so by pursuing
disk-summary in 2.24 rather than just fixing bugs, upstream left Fedora
between a rock and a hard place.  I filed a bug requesting a reversion
to 2.22, which may have been a bad idea on the whole but IMO deserved
more consideration than the knee-jerk WONTFIX it got:

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

-- 
Matt

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Can I have some documentation examples excluded from Abrt crash collection?

2010-04-14 Thread Jeff Spaleta
On Wed, Apr 14, 2010 at 11:53 AM, Karel Klic kk...@redhat.com wrote:
 Please file a RFE in Bugzilla, and include the filename mask(s) marking
 the files you want to exclude. I think it will be something like:
 /usr/lib/python2.6/site-packages/scipy/*/examples/*.py

do you want that in Fedora bugzilla against abrt package or in the
upstream abrt fedorahosted trac system?

-jef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Reverting kaddressbook back to previous version?

2010-04-14 Thread Rex Dieter
Matt McCutchen wrote:

 Please take the request seriously.  If Tuju is right that most users
 would be better off with the older version, then that's what Fedora
 should ship. 

I appreciate the comment, but that oversimplifies things quite a bit.  there 
are a lot of other packages and issues and bugs involved here.  Reverting 
even part or all as you suggest would have far bigger bad consequences than 
helping fix the primary bug/app at issue here.

Fact is... qa'ing this, in updates-testing or kde-testing or whatever, and 
finding the root cause(s), in part failed to catch this in time (prior to 
push to stable updates).  The best (and honestly only) way forward is to 
better document things (userbase.kde.org ftw!) and to continue working 
toward the goal noble of making everything just work.

-- Rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Can I have some documentation examples excluded from Abrt crash collection?

2010-04-14 Thread Karel Klic
Dne 14.4.2010 22:40, Jeff Spaleta napsal(a):
 On Wed, Apr 14, 2010 at 11:53 AM, Karel Klickk...@redhat.com  wrote:
 Please file a RFE in Bugzilla, and include the filename mask(s) marking
 the files you want to exclude. I think it will be something like:
 /usr/lib/python2.6/site-packages/scipy/*/examples/*.py

 do you want that in Fedora bugzilla against abrt package or in the
 upstream abrt fedorahosted trac system?

Fedora Bugzilla

Thank you for filling it.

K.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Reverting kaddressbook back to previous version?

2010-04-14 Thread Matt McCutchen
On Wed, 2010-04-14 at 15:51 -0500, Rex Dieter wrote:
 Matt McCutchen wrote:
  Please take the request seriously.  If Tuju is right that most users
  would be better off with the older version, then that's what Fedora
  should ship. 
 
 I appreciate the comment, but that oversimplifies things quite a bit.  there 
 are a lot of other packages and issues and bugs involved here.  Reverting 
 even part or all as you suggest would have far bigger bad consequences than 
 helping fix the primary bug/app at issue here.
 
 Fact is... qa'ing this, in updates-testing or kde-testing or whatever, and 
 finding the root cause(s), in part failed to catch this in time (prior to 
 push to stable updates).  The best (and honestly only) way forward is to 
 better document things (userbase.kde.org ftw!) and to continue working 
 toward the goal noble of making everything just work.

I'm not oversimplifying: by most users would be better with the older
version, I meant to include such integration consequences.

I'll believe you that the answer is no.  You should have given this
answer to Tuju's original question rather than snippily dismissing it.

-- 
Matt

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Can I have some documentation examples excluded from Abrt crash collection?

2010-04-14 Thread Karel Klic
Dne 14.4.2010 22:02, Mathieu Bridon napsal(a):
 I'm not sure if that could be used for my own issues with ABRT, but
 let me explain it.

 When I'm developing a TG2 application, I sometimes get a traceback
 (well, I'm not perfect :). ABRT sees the traceback, and wants me to
 report a bug against Paster.

 However, the bug is not in Paster, it's in my own code, and I know it
 since I'm currently developing it (Paster is used to launch TG2
 applications).

 Would it be possible to ignore this kind of tracebacks while not
 ignoring legit Paster issues?
Yes, that should be possible after some more programming is done. To me 
it seems we will end up with package-specific semi-scriptable 
configuration in ABRT. It would read the (parsed) traceback of a crash 
and determine what to do with it, depending on its contents, on the 
origin of functions etc. Then we will also be able to ignore those 
plentiful Firefox crashes in proprietary plugins.

In other words: please file a RFE against ABRT so your request is not 
forgotten, as it's perfectly valid.

Karel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Reverting kaddressbook back to previous version?

2010-04-14 Thread Matt McCutchen
On Wed, 2010-04-14 at 17:03 -0400, Matt McCutchen wrote:
 You should have given this
 answer to Tuju's original question rather than snippily dismissing it.

Whoops, sorry, I confused Rex Dieter with Ryan Rix.  That remark was
meant for Ryan, not Rex.

-- 
Matt

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Can I have some documentation examples excluded from Abrt crash collection?

2010-04-14 Thread Roland McGrath
Ideally I think abrt's crash signature stuff ought to find two
characteristic failures are the same, and so send a reporter to
an existing bug report.  Then that bug can be marked closed with
an annotation explaining what you need to install.  (Of course,
it's also arguably wiser to have a hook in your python infrastructure
code that can talk to PackageKit magic to suggest installing a necessary
package right there instead of crashing.)


Thanks,
Roland
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Can I have some documentation examples excluded from Abrt crash collection?

2010-04-14 Thread Adam Williamson
On Wed, 2010-04-14 at 14:14 -0700, Roland McGrath wrote:
 Ideally I think abrt's crash signature stuff ought to find two
 characteristic failures are the same, and so send a reporter to
 an existing bug report.  Then that bug can be marked closed with
 an annotation explaining what you need to install.  (Of course,

It already tries to do this, but it's not at all simple. It's one of the
big areas of work in abrt (duplicate detection).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


How should chains be done in non-rawhide?

2010-04-14 Thread Jeff Johnston
I am trying to update the eclipse-egit package to 0.7.1 and it requires 
eclipse-jgit = 0.7.1 which I just built.  I would like both packages to 
be in updates-testing at the same time since use of the eclipse-egit 
package is the real test of the eclipse-jgit package.

For rawhide, I just used the chain-build target, but this doesn't work 
for F-13.  I don't really want to promote eclipse-jgit to stable just so 
I can build eclipse-egit.

What is the recommended procedure?  Ideally, I would like to use a 
chain-build-like mechanism.

-- Jeff J.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: How should chains be done in non-rawhide?

2010-04-14 Thread Jesse Keating
On Wed, 2010-04-14 at 17:31 -0400, Jeff Johnston wrote:
 I am trying to update the eclipse-egit package to 0.7.1 and it requires 
 eclipse-jgit = 0.7.1 which I just built.  I would like both packages to 
 be in updates-testing at the same time since use of the eclipse-egit 
 package is the real test of the eclipse-jgit package.
 
 For rawhide, I just used the chain-build target, but this doesn't work 
 for F-13.  I don't really want to promote eclipse-jgit to stable just so 
 I can build eclipse-egit.
 
 What is the recommended procedure?  Ideally, I would like to use a 
 chain-build-like mechanism.
 
 -- Jeff J.

Unfortunately we can't use chain-build on repos that don't self-update.
You'll need to file a releng ticket for a buildroot override to get your
eclipse-jgit into the buildroot, then you can use a koji wait-repo ...
 make build type command to automatically wait for the build to show
up in the buildroot and kick off your second build.  Then you can create
a single bodhi update that includes both builds to keep them grouped
together.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

summer coding and you

2010-04-14 Thread Karsten Wade
I'm talking to you because I know some of you work at companies,
organizations, foundations, consortiums, and so forth.  And you may be
in the perfect position to sponsor a student for Fedora Summer Coding.

We're moving the schedule back an extra month to give a chance for
more sponsors.  The proposed schedule gives us until 21 May for
sponsors to pledge funds.  (Separate announcement about schedule
changes coming.)

We need word word about Fedora Summer Coding to get to the ears of
more people.  People who:

* Have the desire to help students (learn to) contribute to FOSS  the
  Fedora Project.

* Want to associate their name or brand with being a sponsor of these
  summer coding activities.

* (Optionally) care about the future of the Fedora Project; you may be
  funding work that happens primarily upstream, but it should somehow
  benefit Fedora.

* Can pledge money toward funding students by 21 May 2010.

* Are interested in getting in at the start of a new program
  associated with Fedora.  We are already planning how to do a Summer
  Coding 2010 for the Southern Hemisphere, and entire half of the
  planet not covered by GSoC.  This can be as big as we want to grow
  it.

Is this you?  Your company?

Spread the word.  People should contact me directly, unless they want
to be transparent and in public about it. ;-) kw...@redhat.com

https://fedoraproject.org/wiki/Summer_Coding_2010#You_are_a_sponsoring_organization

Some more writing on this:

http://iquaid.org/2010/04/13/sponsoring-summer-coding-get-and-give-value/

http://iquaid.org/2010/04/02/seeking-sponsors-universities-corporations-foundations-individuals-creative-ideas/

Thanks - Karsten
-- 
name:  Karsten 'quaid' Wade, Sr. Community Gardener
team:Red Hat Community Architecture 
uri:   http://TheOpenSourceWay.org/wiki
gpg:   AD0E0C41


pgpaxc9D7KMkS.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

HEADS UP: xorg.conf.d changes

2010-04-14 Thread Peter Hutterer
There will be another set of changes to the xorg.conf.d system, in rawhide
and F-13. This may affect your input device configuration in X. My apologies
for the inconvenience, especially after the Beta.

Long story short, when the xorg.conf.d stuff went into rawhide we (well, I,
so blame me for that) picked /etc/xorg.conf.d. When server 1.8.0 was
released, Keith used /etc/X11/xorg.conf.d instead.

Now we have a number of patches queued up for 1.8.1 that split the location
of the snippets into datadir and sysconfdir. 1.8.1 will come out after F-13
though, so I need to move the patches in now to avoid disruption after
final.

The new layout is:
/usr/share/X11/xorg.conf.d for distribution-provided xorg.conf snippets
/etc/X11/xorg.conf.d for user-specified snippets*

The following packages are affected:
xorg-x11-server
system-setup-keyboard
xorg-x11-drv-wacom
xorg-x11-drv-synaptics
xorg-x11-drv-fpit
xorg-x11-drv-vmmouse

And of course any custom config files in /etc/xorg.conf.d that need to be
just moved to the new location. So your setup may break (again, but this
time it might just be the last time). I've backported the server already and
it works, the rest is still being worked on but it all should go in tonight
(Australia time).

Instead of flaming me, please go out and give a unit of your local currency
to a homeless person. That way the world might actually get a better place.

Cheers,
  Peter
 
* I'll make system-config-keyboard write into that as well, since it's
closer to a user-specific configuration.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel