date:20100706

On Tue, Jul 06, 2010 at 10:51:37AM +0200, josef radinger wrote:
> sorry for being offline. had some longer trouble in real life and am now
> wading through lots of mails which piled up since some weeks.

Welcome back.

> what is the correct way for being unavailable?
> is a vacation message ok, or would we spam our mailinglists?
> as far as i remember vacation would leave mails from vacation-lists
> alone, though.

If you are unavailable for a long time (e.g. longer than two weeks) it
is imho best to announce it on the mailing list. Also if there are
unhandled issues, it is better to ask for help here even on a shorter
vacation. Also there is a wiki page to document absence:
https://fedoraproject.org/wiki/Vacation

Regards
Till

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

Re: concept of package "ownership"

2010-07-06 Thread Patrice Dumas

On Mon, Jul 05, 2010 at 01:30:37PM -0700, Adam Williamson wrote:
> 
> This generally works out pretty well, and helps out with the problem of
> having quite a small set of maintainers for an extremely large set of
> packages. I was often in the situation where I happened to notice a
> small issue with 'someone else's' package and could just go ahead and
> fix it, instead of having to go through the bureaucracy of filing a bug
> report and waiting for them to do it. It's rarely the case that someone
> makes a really stupid change and causes friction. I'd say the system
> works more often than it doesn't, and it'd probably be good for Fedora
> too to - as Dave proposes - explicitly _not_ have a concept of
> ownership, and be more liberal about non-maintainers touching packages.

If I recall well, historically, both in fedora extra and fedora core 
commit rights were pretty liberal. After the merge there was the 
provenpackagers set up and some packages are more or less protected.

But I don't think that what matters is the ACL system, more interesting
are the policies and how things are done and why. As you say above the 
open system fits well 'having quite a small set of maintainers for an 
extremely large set of packages'. But this is not the case for all of 
fedora. More precisely, with a bit exageration, there seems to be 4
sets of people. 

1) The dedicated community packager works benevolently (though he may be 
paid for that work and, for example, be a redhat emplyee, it wouldn't matter
if he wasn't) and really takes care of his packages. It corresponds, in 
my opinion to most of former fedora extra packagers and most people 
at redhat that are hired from the community. For that packager it is 
important to have people avoid touching his package, but he won't mind 
if things that are obviously broken are taken care of, especially when he 
is not available, and he generally have co-maintainers to do the job 
anyway. (You can guess that I am biased, and find that I am myself in that
category).

2) The forced packager has to maintain packages as part of his job. This 
holds for some people @rh, but not only. For the packages maintained by
those packagers, it is better if they are open since they tend not to
be very dedicated. Some of them may be picky, however, since they have
to make as if they were maintaining their packages, even if they are
doing a poor job. Being forced to own a package doesn't mean that,
necessarily, the packager will do a poor job, but this is a possibility.

3) The diletante packager is a community packager who steps to do some
packaging but after some short time stops without any reason or explanation.
I still haven't understood where those come from, what their motivations
are, but there are quite a bit in fedora. For the corresponding packages, 
obviously, having an open system is good. (But having a sponsoring model 
that avoids them is also good...).

4) The dedicated non community packager is a specie disappearing from 
fedora, corresponding more or less with packagers, in general redhat
old timers who are dedicated but prefer doing things their way. They 
obviously prefer closed packages.

Historically there was a majority of packagers of type 1) in fedora extras
and a mix, with, in my opinion, a majority of type 2) and 4) in fedora core. 
So something closed was more logical, and it was certainly quite different 
from mandriva. This has moved over the years, with people changing in 
categories, with some moves in the right direction, mainly from packagers 
in 2) and 4) going to 1), but, more importantly, there has been people 
leaving and other entering. Overall, it seems to me that the 2) and 3) are
winning over in numbers (category 4) is almost extinct), especially in 
number of packages. 

Maybe Fedora should do a transition to a more open system, since the dedicated
packager is less present nowadays. But it should be done carefully, in order
not to piss off the remaining dedicated packagers, who are those who deliver, 
in my opinion, the packages with highest quality.

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

Re: Make pkgdb grant co-maintainer status automatically?

On Tue, Jul 06, 2010 at 10:32:06AM +0200, Sven Lankes wrote:

> Maybe we could tweak the pkgdb in a way that a co-maintainer request
> would automatically be granted if it isn't answered within a long enough
> timeframe (say 8 weeks).
> 
> That way packages with AWOL maintainers could grow co-maintainers
> without going through the complicated AWOL-process.

If something is going to be automated, that imho it should be the
non-responsive maintainer process directly. E.g. PkgDB could send out
nag-mails and if they are unhandled, a FESCo ticket is opened and the
non responsive maintainer process is followed.

Regards
Till

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

Re: Plan for tomorrow's FESCo meeting (2010-07-06 at 19:30UTC)

On Mon, Jul 05, 2010 at 09:56:50PM -0600, Kevin Fenzi wrote:

> If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/fesco,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor topic. 

Is someone still keeping an eye on ticket 370[0] about libiberty?
And if not, can the ticket process maybe be changed to keep use two
keywords, e.g. a "meeting" keyword for all stuff that needs to be
handled in a meeting and a "next_meeting" keyword for stuff that will be
discussed in the next meeting? Then there could be a report about all
meeting items that are not a next_meeting item but have not been touched
for e.g. 2 weeks to easier spot items that are unhandled.

Regards
Till

[0] https://fedorahosted.org/fesco/ticket/370

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

2010-07-06 Thread Alexander Kurtakov

> > On Tue, Jul 6, 2010 at 6:32 PM, Sven Lankes  wrote:
> > 
> > 
> > Maybe we could tweak the pkgdb in a way that a co-maintainer request
> > would automatically be granted if it isn't answered within a long enough
> > timeframe (say 8 weeks).
> > 
> > That way packages with AWOL maintainers could grow co-maintainers
> > without going through the complicated AWOL-process.
> > 
> > --
> > sven === jabber/xmpp: s...@lankes.net
> > --
> 
> Sounds reasonable enough to me.
> 
> Regards

Big +1 from me too for such change.

Alexander Kurtakov


> 
> 
> 
> --
> Chris Jones
> Photographic Imaging Professional and Graphic Designer
> ABN: 98 317 740 240
> 
> Photo Resolutions - Photo Printing, Editing and Restorations
> Web: http://photoresolutions.freehostia.com
> Email:  or 
> 
> Fedora Design Suite Developer and Co-Maintainer
> Email: 
> 
> --
> GnuPG v1.4.10 (GNU/Linux)
> Public Key Fingerprint:
> 6915 0761 5754 D091 99F4
> 5384 BA37 FD5D 34F9 F115
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Non responsive maintainer: cheese ?

2010-07-06 Thread Pierre-Yves

On Tue, 2010-07-06 at 10:51 +0200, josef radinger wrote:
> sorry for being offline. had some longer trouble in real life and am
> now
> wading through lots of mails which piled up since some weeks.
> 
Good to hear you are back :-)

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

Re: CVS connection time-outs

2010-07-06 Thread Patrick MONNERAT

On Mon, 2010-07-05 at 18:24 +0200, Till Maas wrote:

> The Fedora Infrastructure issue tracker can be accessed here to report a
> problem:
> https://fedorahosted.org/fedora-infrastructure

Thanks. Ticket opened there:
https://fedorahosted.org/fedora-infrastructure/ticket/2255

Connectivity is still VERY bad today.

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

Re: Can anyone contact Gér ard Milmeister (gemi)?

On Tue, Jul 06, 2010 at 10:13:40AM +0800, Chen Lei wrote:
> 2010/6/18 Chen Lei :
> > Hi all,
> >
> > Following the process
> >
> > https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
> >
> > Is someone able to get in touch with Gérard Milmeister.(gemi)
> >
> > I can't find any activity of him from koji and bugzilla in the past
> > eight months, I also got no response from him after sending a private
> > mail a month ago.
> >
> > See https://bugzilla.redhat.com/show_bug.cgi?id=530565 for more details.
> >
> >
> > Regards,
> > Chen Lei
> >
> 
> Hi FESCo,
> 
> Can we orphan his packages now? I'd like to take scons, I don't think
> waiting more time will be helpful.

According to:
https://admin.fedoraproject.org/pkgdb/users/packages/gemi

[This list includes packages which are co-maintained]

GtkAda -- Ada graphical toolkit based on Gtk+
TeXmacs -- Structured wysiwyg scientific text editor
abcMIDI -- ABC to/from MIDI conversion utilities
abcm2ps -- A program to typeset ABC tunes into Postscript
audacity -- Multitrack audio editor
bigloo -- Bigloo is compiler for the Scheme programming language
clisp -- Common Lisp (ANSI CL) implementation
compat-erlang -- General-purpose programming language and runtime environment
cook -- File construction tool
curry -- Münster Curry compiler
ecl -- Embeddable Common-Lisp
erlang -- General-purpose programming language and runtime environment
erlang-esdl -- Erlang OpenGL/SDL api and utilities
ffcall -- Libraries for foreign function call interfaces
gauche -- Scheme script interpreter with multibyte character handling
gauche-gl -- OpenGL binding for Gauche
gauche-gtk -- Gauche extension module to use GTK
genius -- An arbitrary precision integer and multiple precision floatingpoint 
calculator
gforth -- Fast and portable implementation of the ANS Forth language
global -- Source code tag system
gtkglarea2 -- OpenGL GTK widget
gtklp -- A GTK frontend to CUPS
hugs98 -- Haskell Interpreter
lush -- An object-oriented Lisp interpreter and compiler
nyquist -- Sound synthesis and composition language with a Lisp syntax
ocaml -- Objective Caml compiler and programming environment
ocaml-lablgl -- LablGL is an OpenGL interface for Objective Caml
ocaml-lablgtk -- Objective Caml interface to gtk+
ocaml-ocamlnet -- Network protocols for OCaml
oorexx -- Open Object Rexx
pari -- Number Theory-oriented Computer Algebra System
pl -- SWI-Prolog - Edinburgh compatible Prolog compiler
plt-scheme -- Graphical environment for developing programs using Scheme
polyml -- Poly/ML compiler and runtime system
q -- Equational programming language
qcad -- Simple 2D CAD program
scons -- An Open Source software construction tool
sweep -- An audio editor and live playback tool
tclabc -- A Tcl interface and a Tk GUI to the ABC notation
tkcvs -- TkCVS and TkDiff
ucblogo -- An interpreter for the Logo programming language
unison213 -- Multi-master File synchronization tool
unison227 -- Multi-master File synchronization tool
wings -- 3D Subdivision Modeler
xaos -- A fast, portable real-time interactive fractal zoomer
yap -- High-performance Prolog Compiler

-

I have requested co-maint on the OCaml-related ones and gtkglarea2 and
Unison.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

On Tue, Jul 06, 2010 at 10:32:06AM +0200, Sven Lankes wrote:
> On Tue, Jul 06, 2010 at 09:21:29AM +1000, Chris Jones wrote:
> 
> > This seems to be happening a lot lately regarding maintainers and/or
> > co-maintainers losing interest in their projects somewhere along the
> > line and just stopping development without any warning and
> > notification to other members who may be interested.
> 
> Maybe we could tweak the pkgdb in a way that a co-maintainer request
> would automatically be granted if it isn't answered within a long enough
> timeframe (say 8 weeks).

+1, good idea.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: CVS connection time-outs

2010-07-06 Thread Andreas Schwab

Patrick MONNERAT  writes:

> Connectivity is still VERY bad today.

FWIW, I had no problem cvs-importing a 16Mb glibc srpm about an hour
ago (from within the M-net network).

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: CVS connection time-outs

2010-07-06 Thread Patrick MONNERAT

On Tue, 2010-07-06 at 11:57 +0200, Andreas Schwab wrote:

> FWIW, I had no problem cvs-importing a 16Mb glibc srpm about an hour
> ago (from within the M-net network).

The problems I get (from Switzerland) seem to be connection-related
rather than data amount-related. I don't know how many times your glibc
srpm upload invokes the cvs command; my srpm has 5 sources and 13
patches. Once the connection is established, the command succeeds (may
be because the files are small ?).

I've finally succeeded in my srpm upload by reissuing manually the
failed "cvs add" from another terminal during the script pause. I also
had to manually "make tag" after script exit, because the cvs tagging
command failed. I have to say the cvs-import.sh idea is great, but the
script is not fault-tolerant at all: there is now way to restart it
where it failed because the temporary directory is purged away at script
exit.

Thanks for your info.

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

Re: CVS connection time-outs

2010-07-06 Thread Manuel Wolfshant

On 07/06/2010 01:20 PM, Patrick MONNERAT wrote:
> On Tue, 2010-07-06 at 11:57 +0200, Andreas Schwab wrote:
>
>
>> FWIW, I had no problem cvs-importing a 16Mb glibc srpm about an hour
>> ago (from within the M-net network).
>>  
> The problems I get (from Switzerland) seem to be connection-related
> rather than data amount-related. I don't know how many times your glibc
> srpm upload invokes the cvs command; my srpm has 5 sources and 13
> patches. Once the connection is established, the command succeeds (may
> be because the files are small ?).
>
> I've finally succeeded in my srpm upload by reissuing manually the
> failed "cvs add" from another terminal during the script pause. I also
> had to manually "make tag" after script exit, because the cvs tagging
> command failed. I have to say the cvs-import.sh idea is great, but the
> script is not fault-tolerant at all: there is now way to restart it
> where it failed because the temporary directory is purged away at script
> exit.

Patrick, you describe almost the same problems that I faced 4 days ago. 
cvs stalled / timing out, need for repeating the "cvs add" commands, 
koji build disconnected and so on.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Fedora-r-devel-list] R-multcomp and a lot of new R packages

2010-07-06 Thread Pierre-Yves

On Wed, 2010-01-20 at 08:37 +0100, Pierre-Yves wrote:
> On Tue, 2010-01-19 at 22:57 -0500, Tom "spot" Callaway wrote:
> > Is there any interest in helping me maintain and review these new R
> > packages in Fedora? The packages are already done, its just the
> > reviews
> > and upkeep that I'd need help with.
> > 
> > Here's the packages:
> > 
> > http://auroralinux.org/people/spot/review/R-multcomp/
> > 
> > These are the R packages I made today:
> > 
> > coin, colorspace, ipred, lme4, mboost, mlbench, modeltools, multicore,
> > party, robustbase, sandwich, strucchange, vcd, xtable
> > 
> > If any of these look interesting to you, speak up! If no one cares, I
> > might just let R-multcomp orphan off, but if there are some willing
> > helpers, I'll keep it alive with its new dependencies.
> 
> Hi all,
> 
> Even though I do not use them, I am always in favour of getting new R
> packages into Fedora (and/or keeping them in).
> I am therefore willing to help reviewing and/or maintain some if you
> like.

It starts to be some time ago, but as I said I am willing to do the
reviews and be co-maintainer (can I do the review and be co-maintainer?)

>From the original list, red has already pushed xtable into Fedora but
that's the only new one I see.

Pierre
___
r-devel mailing list
r-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/r-devel

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

2010-07-06 Thread Thomas Spura

Am Tue, 6 Jul 2010 10:57:06 +0100
schrieb "Richard W.M. Jones" :

> On Tue, Jul 06, 2010 at 10:32:06AM +0200, Sven Lankes wrote:
> > On Tue, Jul 06, 2010 at 09:21:29AM +1000, Chris Jones wrote:
> > 
> > > This seems to be happening a lot lately regarding maintainers
> > > and/or co-maintainers losing interest in their projects somewhere
> > > along the line and just stopping development without any warning
> > > and notification to other members who may be interested.
> > 
> > Maybe we could tweak the pkgdb in a way that a co-maintainer request
> > would automatically be granted if it isn't answered within a long
> > enough timeframe (say 8 weeks).
> 
> +1, good idea.

If this is implemented, the 'next' co-maintainer should become the real
maintainer after another 8 weeks non-commiting by the former maintainer.

For me it doesn't make much sense to be co-maintainer everywhere, but
actually:
1. doing all the tasks alone.
2. when there is a problem with the package, other contact at
first the maintainer, which should be the new one, too.

Maybe a button with 'take the package, when maintainer doesn't want to
keep it' and transfer, when the maintainer agrees or doesn't respond in
the 8 weeks or so?

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

Re: [Fedora-r-devel-list] Review Request: R-GenomicRanges

2010-07-06 Thread Dan Bolser

Sorry for the dumb question, but can you link me to a step by step
review process?

I'd like to do an 'internal review' if not a propper review.


Dan.

On 5 July 2010 12:25, Pierre-Yves  wrote:
> On Thu, 2010-07-01 at 11:16 +0200, Pierre-Yves wrote:
>> Hi,
>>
>> If someone could have a look at this review I would be pleased. I need
>> it to update R-BSgenome which is needed for R-hgu95av2probe.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=609079
>>
> No taker ?
>
> Pierre
> ___
> r-devel mailing list
> r-de...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/r-devel
>
___
r-devel mailing list
r-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/r-devel

Broken dependencies: perl-Data-Alias

2010-07-06 Thread buildsys



perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1)
On i386:
perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-DBI-Dumper

2010-07-06 Thread buildsys



perl-DBI-Dumper has broken dependencies in the rawhide tree:
On x86_64:
perl-DBI-Dumper-2.01-8.fc12.x86_64 requires perl(:MODULE_COMPAT_5.10.0)
On i386:
perl-DBI-Dumper-2.01-8.fc12.i686 requires perl(:MODULE_COMPAT_5.10.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Pugs-Compiler-Rule

2010-07-06 Thread buildsys



perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires 
perl(:MODULE_COMPAT_5.10.1)
On i386:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires 
perl(:MODULE_COMPAT_5.10.1)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: concept of package "ownership"

2010-07-06 Thread Darryl L. Pierce

On Sat, Jul 03, 2010 at 03:28:31PM +0200, Kevin Kofler wrote:
> > I thought rawhide should be more useful and less broken if i recall
> > the latest threads right. Anyways, exactly that's why i do *not* want
> > anybody can do anything with any package. That's just insane, sorry.
> 
> This is Fedora. Debian is that  way.
> 
> Please don't destroy what Fedora is all about. If we don't focus on 
> packaging the latest software anymore, we will just be another Debian or 
> Ubuntu.

There _is_ a middle ground between bleeding edge and extremely stable.

A Fedora release should have a locked version of key shared packages,
such as Python, Rails, etc., should be kept at a specific version (with
upgrades only for bug fixes).

Packages within a release can be upgraded so long as they don't require
the next version of those shared packages. So, if F13 is Rails 2.3.5 and
Rake 0.8.7, then an app that requires newer versions of either should
wait until F14 to push _that_ update out, and not go to F13 at all.
Especially since even a minor upgrade of such a shared component can
break a lot of apps.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

On Tue, Jul 06, 2010 at 01:26:21PM +0200, Thomas Spura wrote:
> If this is implemented, the 'next' co-maintainer should become the real
> maintainer after another 8 weeks non-commiting by the former maintainer.

I think this is another problem with pkgdb or Fedora.  Why is there a
maintainer ("owner"?) and co-maintainers, rather than just having all
co-maintainers be equal?

As people know, my default position is for inclusion: we should try to
include as many packages in Fedora that we can, except where there is
a legal or insuperable technical problem with that.

So I think it's valid for packages to have 0, 1, 2, or more
maintainers.

If #maintainers == 0 then the package is either just sitting there (as
long as there are no serious bugs), or is being best-effort maintained
by provenpackagers, at least until that becomes a burden and only then
should the package be dropped.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20100706 changes

2010-07-06 Thread Rawhide Report

Compose started at Tue Jul  6 08:15:06 UTC 2010

Broken deps for i386
--
BackupPC-3.1.0-14.fc14.noarch requires perl-suidperl
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
claws-mail-plugins-geolocation-3.7.6-3.fc14.i686 requires 
libchamplain-gtk-0.4.so.0
claws-mail-plugins-geolocation-3.7.6-3.fc14.i686 requires 
libchamplain-0.4.so.0
dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11
deskbar-applet-2.30.0-1.1.fc14.i686 requires libedataserver-1.2.so.12
eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle-optional = 
0:4.1
eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle = 0:4.1
emerillon-0.1.1-2.fc13.i686 requires libchamplain-0.4.so.0
emerillon-0.1.1-2.fc13.i686 requires libchamplain-gtk-0.4.so.0
emerillon-devel-0.1.1-2.fc13.i686 requires pkgconfig(champlain-0.4)
empathy-2.31.3-3.fc14.i686 requires libchamplain-gtk-0.4.so.0
empathy-2.31.3-3.fc14.i686 requires libchamplain-0.4.so.0
eog-plugins-2.30.0-1.fc14.i686 requires libchamplain-0.4.so.0
eog-plugins-2.30.0-1.fc14.i686 requires libchamplain-gtk-0.4.so.0
epiphany-2.31.3-1.fc14.i686 requires libwebkit-1.0.so.2
evolution-rss-0.1.9-7.20100525git.fc14.i686 requires libwebkit-1.0.so.2
gmpc-0.19.1-3.fc14.i686 requires libwebkit-1.0.so.2
gnome-phone-manager-0.65-6.fc14.i686 requires libgnome-bluetooth.so.7
gnucash-2.3.13-1.fc14.i686 requires libwebkit-1.0.so.2
gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0
gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0
7:kdenetwork-4.4.90-1.fc14.i686 requires libmsn.so.0.1
kst-fits-1.8.0-7.fc14.i686 requires cfitsio = 0:3.240
lekhonee-gnome-0.11-2.fc14.i686 requires libwebkit-1.0.so.2
libpeas-0.5.1-1.fc14.i686 requires libgdk_pixbuf-3.0.so.0
libpeas-devel-0.5.1-1.fc14.i686 requires libgdk_pixbuf-3.0.so.0
1:liferea-1.6.3-1.fc14.i686 requires libwebkit-1.0.so.2
maven2-plugin-checkstyle-2.0.8-3.fc12.noarch requires 
checkstyle-optional >= 0:4.1
merkaartor-0.16.1-1.fc13.i686 requires libexiv2.so.6
midori-0.2.6-1.fc14.i686 requires libwebkit-1.0.so.2
mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires 
mingw32(libpng-3.dll)
moblin-panel-status-0.1.21-3.fc14.i686 requires libchamplain-0.4.so.0
perl-DBI-Dumper-2.01-8.fc12.i686 requires perl(:MODULE_COMPAT_5.10.0)
perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1)
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires 
perl(:MODULE_COMPAT_5.10.1)
perl-Test-AutoBuild-1.2.2-9.fc12.i686 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
python3-beaker-1.5.3-4.fc14.noarch requires python3-paste
pywebkitgtk-1.1.6-3.fc14.i686 requires libwebkit-1.0.so.2
qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18
seed-2.31.1-1.fc14.i686 requires libwebkit-1.0.so.2
shotwell-0.5.2-1.fc14.i686 requires libwebkit-1.0.so.2
skyviewer-1.0.0-4.fc14.i686 requires libQGLViewer.so.2.3.5
spacewalk-certs-tools-1.1.1-1.fc14.noarch requires 
spacewalk-backend-libs >= 0:0.8.28
themonospot-gui-qt-0.1.3-6.fc14.i686 requires mono(qt-dotnet) = 
0:4.5.0.0
themonospot-gui-qt-0.1.3-6.fc14.i686 requires libqyotoshared.so.1
vfrnav-0.4-1.fc13.i686 requires libgps.so.18
viking-0.9.91-3.fc13.i686 requires libgps.so.18
xcf-pixbuf-loader-0.0.1-3.8af913d1.fc14.i686 requires 
/usr/lib/gtk-2.0/2.10.0/loaders
xenner-0.48-1.fc14.i386 requires libxenguest.so.3.4



Broken deps for x86_64
--
BackupPC-3.1.0-14.fc14.noarch requires perl-suidperl
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)
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)
eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle-optional = 
0:4.1
eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle = 0:4.1
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

(lack of) maintainership of epiphany?

2010-07-06 Thread pbrobin...@gmail.com

I wonder about the maintainer ship of epiphany. The ownership of it is
gecko-maint but in none of the current versions of fedora is epiphany
gecko based and of the 18 other maintainers not a single person is on
the bugzilla watch ACL. There's a bug that was introduced at some
point in the F-13 time frame where it crashes on all the machines I
attempt to use it on when it first tries to load a page, there's quite
a few dupes. I'm really surprised that no one has picked this up.

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

2010-07-06 Thread Patrice Dumas

On Tue, Jul 06, 2010 at 01:39:43PM +0100, Richard W.M. Jones wrote:
> 
> I think this is another problem with pkgdb or Fedora.  Why is there a
> maintainer ("owner"?) and co-maintainers, rather than just having all
> co-maintainers be equal?

Because this ensures that there is a well defined person who is responsible
for the package, and has the last word (with the usual procedure when people
disagree with the maintainer).

It doesn't prevent from having, in practice, equal maintainers when it
comes to maintaining the package. This was the case for some packages I 
co-maintained, for example netcdf related packages, where all the 
co-maintainers were more or less equal in practice.

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

Re: Plan for tomorrow's FESCo meeting (2010-07-06 at 19:30UTC)

2010-07-06 Thread Adam Jackson

On Tue, 2010-07-06 at 11:23 +0200, Till Maas wrote:
> On Mon, Jul 05, 2010 at 09:56:50PM -0600, Kevin Fenzi wrote:
> 
> > If you would like to add something to this agenda, you can reply to
> > this e-mail, file a new ticket at https://fedorahosted.org/fesco,
> > e-mail me directly, or bring it up at the end of the meeting, during
> > the open floor topic. 
> 
> Is someone still keeping an eye on ticket 370[0] about libiberty?

I keep meaning to pay attention to this but it's been a busy month.
I'll poke at it more today.

- ajax


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: [Fedora-r-devel-list] Review Request: R-GenomicRanges

2010-07-06 Thread Pierre-Yves

On Tue, 2010-07-06 at 13:23 +0100, Dan Bolser wrote:
> Sorry for the dumb question, but can you link me to a step by step
> review process?
> 
> I'd like to do an 'internal review' if not a propper review.

Hi Dan,

Indeed you will not be able to do an official review until you have been
approved as packager.
The idea of the review is to check the quality of the package and make
sure that it follows the guidelines.

The process to join the packagers is described here:
http://fedoraproject.org/wiki/PackageMaintainers/Join

R packages should follow the official packaging guidelines:
http://fedoraproject.org/wiki/Packaging:Guidelines
and the R specific guidelines:
http://fedoraproject.org/wiki/Packaging:R


The guidelines for the review itself can be found there:
http://fedoraproject.org/wiki/Packaging:ReviewGuidelines


Thanks in advance,

Pierre

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

Fedora 14 Schedule Reminder

2010-07-06 Thread John Poelstra

Start   End Name
Wed 26-May  Tue 03-Aug  Packaging and Development (precedes Alpha)
Tue 06-Jul  Tue 06-Jul  Feature Submission Deadline One Week away
Thu 08-Jul  Thu 08-Jul  Create Installable Images for QA testing #1
Tue 13-Jul  Tue 13-Jul  Custom Spins Submission Deadline
Tue 13-Jul  Tue 13-Jul  Feature Submission Deadline
Thu 15-Jul  Thu 15-Jul  Create Installable Images for QA testing #2
Fri 16-Jul  Fri 16-Jul  Alpha Blocker Meeting (f14alpha) #1
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rpms/shared-mime-info/devel shared-mime-info.spec,1.84,1.85

2010-07-06 Thread Colin Walters

On Sat, Jul 3, 2010 at 2:40 PM, Mamoru Tasaka
 wrote:
> Colin Walters wrote, at 07/04/2010 03:23 AM +9:00:
>> Author: walters
>>
>> Update of /cvs/pkgs/rpms/shared-mime-info/devel
>> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv21405
>>
>> Modified Files:
>>       shared-mime-info.spec
>> Log Message:
>> * Sat Jul  3 2010 Colin Walters  - 0.71-3
>> - Requires(pre) on glib, since update-mime-database uses it
>
> Why is this needed, although calling update-mime-database appears in
> %post scriptlet?

Ah, it should be Requires(post) I guess?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

2010-07-06 Thread Michael Schwendt

On Tue, 6 Jul 2010 13:39:43 +0100, Richard wrote:

> So I think it's valid for packages to have 0, 1, 2, or more
> maintainers.

Why 0? Who will be notified about bugzilla tickets? Who will receive
mail sent to the PACKAGE-owner Fedora e-mail alias?

For each package in the collection, there ought to be at least (!) one
maintainer, who wants to be responsible for taking care of the package.

> If #maintainers == 0 then the package is either just sitting there (as
> long as there are no serious bugs), or is being best-effort maintained
> by provenpackagers, at least until that becomes a burden and only then
> should the package be dropped.

Sounds like the infamous dumping-ground for packages. Welcome back,
contrib.redhat.com! Or what? "Best-effort maintained" ranging from
"no effort" to "over-ambitious upgrade hell".
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rpms/shared-mime-info/devel shared-mime-info.spec,1.84,1.85

2010-07-06 Thread Mamoru Tasaka

Colin Walters wrote, at 07/06/2010 11:29 PM +9:00:
> On Sat, Jul 3, 2010 at 2:40 PM, Mamoru Tasaka
>   wrote:
>> Colin Walters wrote, at 07/04/2010 03:23 AM +9:00:
>>> Author: walters
>>>
>>> Update of /cvs/pkgs/rpms/shared-mime-info/devel
>>> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv21405
>>>
>>> Modified Files:
>>>shared-mime-info.spec
>>> Log Message:
>>> * Sat Jul  3 2010 Colin Walters- 0.71-3
>>> - Requires(pre) on glib, since update-mime-database uses it
>>
>> Why is this needed, although calling update-mime-database appears in
>> %post scriptlet?
>
> Ah, it should be Requires(post) I guess?

If you want to avoid potential dependency loop, it should be
Requires(post).

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

Re: rpms/shared-mime-info/devel shared-mime-info.spec,1.84,1.85

2010-07-06 Thread Colin Walters

On Tue, Jul 6, 2010 at 10:48 AM, Mamoru Tasaka
 wrote:
> > If you want to avoid potential dependency loop, it should be
> Requires(post).

Fixed, thank you!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

2010-07-06 Thread Orcan Ogetbil

On Tue, Jul 6, 2010 at 10:44 AM, Michael Schwendt wrote:
> On Tue, 6 Jul 2010 13:39:43 +0100, Richard wrote:
>
>> So I think it's valid for packages to have 0, 1, 2, or more
>> maintainers.
>
> Why 0? Who will be notified about bugzilla tickets? Who will receive
> mail sent to the PACKAGE-owner Fedora e-mail alias?
>

Some mailing list like dumping-gro...@fedoraproject.org. I am sure
someone can come up with a better name.

> For each package in the collection, there ought to be at least (!) one
> maintainer, who wants to be responsible for taking care of the package.
>

Yes. And everyone who is subscribed to the above mailing list is a
potential maintainer of those packages with 0 principal maintainers.
Great idea.

>> If #maintainers == 0 then the package is either just sitting there (as
>> long as there are no serious bugs), or is being best-effort maintained
>> by provenpackagers, at least until that becomes a burden and only then
>> should the package be dropped.
>
> Sounds like the infamous dumping-ground for packages. Welcome back,
> contrib.redhat.com! Or what? "Best-effort maintained" ranging from
> "no effort" to "over-ambitious upgrade hell".

+1. Exactly. Good thinking!

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

On Tue, Jul 06, 2010 at 10:54:29AM -0400, Orcan Ogetbil wrote:
> On Tue, Jul 6, 2010 at 10:44 AM, Michael Schwendt wrote:
> > On Tue, 6 Jul 2010 13:39:43 +0100, Richard wrote:
> >
> >> So I think it's valid for packages to have 0, 1, 2, or more
> >> maintainers.
> >
> > Why 0? Who will be notified about bugzilla tickets? Who will receive
> > mail sent to the PACKAGE-owner Fedora e-mail alias?
> >
> 
> Some mailing list like dumping-gro...@fedoraproject.org. I am sure
> someone can come up with a better name.

We can use "uberpackagers" ;-) or maybe "package-monkeys", make it a SIG
and then it is afaik already covered by Fedora procedures, because a SIG
or group of packagers can own a package, like e.g. the lvm-team.

Orcan, Richard, who else is in?

Regards
Till


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

depcheck test (was Re: measuring success)

2010-07-06 Thread Will Woods

On Sat, 2010-07-03 at 12:27 +0200, Michael Schwendt wrote:

> [About automating this during the push process, it is possible to have
> a depchecker simulate a --skip-broken and exclude packages which break
> dependencies. There are different strategies. However, the procedure
> must be backed up by strong policies, or else we will see broken deps
> whenever somebody skips the automated depchecking to push "something
> important".]

This is approximately what the (in-progress) 'depcheck' test does. And
the proposed policy backing it is fairly strong: no package that fails
depcheck will be eligible for push to a live repo without rel-eng
override.

I've been meaning to write a blog post detailing the depcheck algorithm,
because getting the test right turns out to be *really* tricky. There
have been a lot of meandering discussions about how it *should* be done,
but it's complex enough that nobody's actually managed to sit down and
*do* it before now.

I'll attempt to give a brief summary here. First you need to understand
that there are three states for a package that has been built with the
hope of being pushed as an update:
* 'candidate': freshly-built packages intended for updates
* 'proposed': bodhi request filed, but not pushed live
* 'live': packages that have been pushed live by rel-eng

So. What we want to do in AutoQA is trigger a test to check dependencies
*before* the package goes live. So we trigger our test when the request
is filed (this is the 'post-bodhi-update' hook in AutoQA, which was
merged a week or two back).

It should be obvious that the goal of the test is to examine the
proposed updates and hold back the ones whose dependencies are
inconsistent with the packages in the live repos[1]. To phrase it
slightly differently: we want to look at the set of 'proposed' updates
and pass the packages whose dependencies *are* consistent with the live
repos.

As Michael correctly suggests, this is almost exactly the same as
running yum --skip-broken and seeing which packages can be installed. In
fact, we use the exact same depsolving code to determine this[2].

The first automated runs of this test should start this week - but it
may take a week or two of testing to ensure depcheck is running as
expected.

Once we're satisfied that depcheck does the right thing, we will
probably set it up to start adding automatic +1 karma from 'autoqa' when
updates pass the automated test suite (depcheck and possibly other tests
- rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
apply to all packages or just critpath packages; it may apply
everywhere, which will make it a bit easier to get to +3 karma for
automated updates.

Once that's working we plan to add code to bodhi to show rel-eng which
updates have passed depcheck, so only those packages which won't break
the repos will get pushed. And then life will be lots nicer.

I know that's kind of a long explanation, but it's kind of a complicated
problem. Please feel free to examine the depcheck code and ask any
questions you like. If you have any "does it handle situation X"
questions, try to construct an actual test case (e.g. create some
trivial RPMs to illustrate the situation) and we'll put that into the
depcheck test suite.

If there are any other questions, feel free to ask.

-w

[1] Note that the test needs to check *all* the proposed updates, not
just the new individual update that is triggering the test. Otherwise
anything that got rejected would have to be resubmitted to re-trigger
the test (which would be annoying) and mutually dependent updates would
fail forever (which would be broken).

[2]
http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=tests/depcheck/depcheck

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

Re: depcheck test (was Re: measuring success)

On Tue, Jul 06, 2010 at 11:34:25AM -0400, Will Woods wrote:

> Once we're satisfied that depcheck does the right thing, we will
> probably set it up to start adding automatic +1 karma from 'autoqa' when
> updates pass the automated test suite (depcheck and possibly other tests
> - rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
> apply to all packages or just critpath packages; it may apply
> everywhere, which will make it a bit easier to get to +3 karma for
> automated updates.

IMHO it should not be a +1 karma but some different flag that is set for
updates that passed the tests.

Regards
Till


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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

2010-07-06 Thread Toshio Kuratomi

On Tue, Jul 06, 2010 at 12:31:32PM +0300, Alexander Kurtakov wrote:
> > > On Tue, Jul 6, 2010 at 6:32 PM, Sven Lankes  wrote:
> > > 
> > > 
> > > Maybe we could tweak the pkgdb in a way that a co-maintainer request
> > > would automatically be granted if it isn't answered within a long enough
> > > timeframe (say 8 weeks).
> > > 
> > > That way packages with AWOL maintainers could grow co-maintainers
> > > without going through the complicated AWOL-process.
> > > 
> > > --
> > > sven === jabber/xmpp: s...@lankes.net
> > > --
> > 
> > Sounds reasonable enough to me.
> > 
> > Regards
> 
> Big +1 from me too for such change.
> 

If anyone wants to help code this, I think the way to do it is to implement
an events queue in pkgdb.  With the queue we can do two things -- first,
have the pkgdb send nagmail when an acl request has not been answered.
second have the pkgdb batch status messages when many requests are done at
the same time.

-Toshio


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

Re: Plan for tomorrow's FESCo meeting (2010-07-06 at 19:30UTC)

On Mon, Jul 05, 2010 at 09:56:50PM -0600, Kevin Fenzi wrote:

> If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/fesco,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor topic. 

Can you maybe shortly evaluate whether FESCo would not object to a
collective maintaince SIG of interested packagers that maintainer
together several unrelated packages?

The SIG would address the suggestions, wishes and concerns that have
been expressed in these mails for the set of packages the SIG maintains:
http://article.gmane.org/gmane.linux.redhat.fedora.devel/135221
http://article.gmane.org/gmane.linux.redhat.fedora.devel/135398
http://article.gmane.org/gmane.linux.redhat.fedora.devel/135157
http://article.gmane.org/gmane.linux.redhat.fedora.devel/135206

Regards
Till


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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

On Tue, Jul 06, 2010 at 12:00:23PM -0400, Toshio Kuratomi wrote:

> If anyone wants to help code this, I think the way to do it is to implement
> an events queue in pkgdb.  With the queue we can do two things -- first,
> have the pkgdb send nagmail when an acl request has not been answered.
> second have the pkgdb batch status messages when many requests are done at
> the same time.

I guess for the nagmail a separate cron job that queries the db for old
requests and send sends the mail might be enough and probably be
straight forward to implement as long as there is a timestamp saved when
a ACL request is made.

Regards
Till


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

Re: Bodhi 0.7.5 release

On Sat, 03 Jul 2010 19:55:27 +0200
Till Maas  wrote:

> On Fri, Jul 02, 2010 at 10:33:04PM +0200, Till Maas wrote:
> > On Fri, Jul 02, 2010 at 12:48:43PM -0600, Kevin Fenzi wrote:
> > 
> > > I have updated the page. 
> > > 
> > > Does it look clear now? Re-wording or tweaks very welcome. 
> > > 
> > > https://fedoraproject.org/wiki/Package_update_acceptance_criteria
> > 
> > Btw. does Bodhi really work the way it is said there? What happens
> > if there are +1 and -1 karma values for an critpath update?
> > According to the criteria, -1 karma does not have any impact at all
> > except for all other updates, because they contain a karma
> > threshold.
> 
> Interestingly the first critpath update I saw with f-e-k is not
> approved but should be according to the criteria:
> https://admin.fedoraproject.org/updates/F12/FEDORA-2010-9850

It doesn't have enough karma... it got: 

-1, +1, +1, for a total of 1. 

So, I guess it's not going to push without hitting +2. 

I've asked Luke to comment here and your parent post about how things
work, as I would love to know too. ;) 

kevin


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

Re: Non-responsive maintainer fast track procedure for libsndfile

On Tue, 6 Jul 2010 09:21:29 +1000
Chris Jones  wrote:

> This seems to be happening a lot lately regarding maintainers and/or
> co-maintainers losing interest in their projects somewhere along the
> line and just stopping development without any warning and
> notification to other members who may be interested.

Yeah, the current process is not ideal, as it not only requires some
maintainer to notice that they are gone, but be interested enough to
start a process and follow through on it. 

> I am wondering, is the process efficient enough for other willing
> developers to take over development of unplanned orphaned and
> unmaintained code from unresponsive developers/maintainers and
> co-maintainers?

I think it could be better, and there are some good ideas later in this
thread. ;) 

kevin


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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

On Tue, 6 Jul 2010 13:39:43 +0100
"Richard W.M. Jones"  wrote:

> On Tue, Jul 06, 2010 at 01:26:21PM +0200, Thomas Spura wrote:
> > If this is implemented, the 'next' co-maintainer should become the
> > real maintainer after another 8 weeks non-commiting by the former
> > maintainer.
> 
> I think this is another problem with pkgdb or Fedora.  Why is there a
> maintainer ("owner"?) and co-maintainers, rather than just having all
> co-maintainers be equal?

If co-maintainers have all the same checkboxes as 'owner' then the only
difference is that the 'owner' will show up in some queries as the
primary contact for the package. Otherwise there's no difference. The
co-maintainers can approve other people for acls, etc. 

> As people know, my default position is for inclusion: we should try to
> include as many packages in Fedora that we can, except where there is
> a legal or insuperable technical problem with that.
> 
> So I think it's valid for packages to have 0, 1, 2, or more
> maintainers.

I disagree with the 0. 

> If #maintainers == 0 then the package is either just sitting there (as
> long as there are no serious bugs), or is being best-effort maintained
> by provenpackagers, at least until that becomes a burden and only then
> should the package be dropped.

If some provenpackager want's to maintain it, why don't they take
ownership?

kevin



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

Re: Plan for tomorrow's FESCo meeting (2010-07-06 at 19:30UTC)

On Tue, 06 Jul 2010 18:06:55 +0200
Till Maas  wrote:

> On Mon, Jul 05, 2010 at 09:56:50PM -0600, Kevin Fenzi wrote:
> 
> > If you would like to add something to this agenda, you can reply to
> > this e-mail, file a new ticket at https://fedorahosted.org/fesco,
> > e-mail me directly, or bring it up at the end of the meeting, during
> > the open floor topic. 
> 
> Can you maybe shortly evaluate whether FESCo would not object to a
> collective maintaince SIG of interested packagers that maintainer
> together several unrelated packages?
> 
> The SIG would address the suggestions, wishes and concerns that have
> been expressed in these mails for the set of packages the SIG
> maintains:
> http://article.gmane.org/gmane.linux.redhat.fedora.devel/135221
> http://article.gmane.org/gmane.linux.redhat.fedora.devel/135398
> http://article.gmane.org/gmane.linux.redhat.fedora.devel/135157
> http://article.gmane.org/gmane.linux.redhat.fedora.devel/135206

We can bring it up. It would help if you guys hashed out a proposal
with a wiki page of exactly what you intend. 

I would be afraid that this would lead to packages that are only rarely
poked at that would be better to just be removed from the collection,
but personally I am willing to let you guys try it out and see what
works. ;) 

kevin


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

Re: concept of package "ownership"

2010-07-06 Thread Jesse Keating

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/6/10 2:16 AM, Patrice Dumas wrote:
> Maybe Fedora should do a transition to a more open system, since the dedicated
> packager is less present nowadays. But it should be done carefully, in order
> not to piss off the remaining dedicated packagers, who are those who deliver, 
> in my opinion, the packages with highest quality.

The "system" is fairly open with regard to just about everything except
attitude.  Currently it's mostly attitude that prevents "openness".

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwzW1IACgkQ4v2HLvE71NUGigCgkVZUzkxqfhhcS95PbwEpjLxz
9noAn2c7LTeD2CWs6QNhxezm+rXaC07L
=RNzg
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: depcheck test (was Re: measuring success)

2010-07-06 Thread Jesse Keating

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/6/10 8:52 AM, Till Maas wrote:
> On Tue, Jul 06, 2010 at 11:34:25AM -0400, Will Woods wrote:
> 
>> Once we're satisfied that depcheck does the right thing, we will
>> probably set it up to start adding automatic +1 karma from 'autoqa' when
>> updates pass the automated test suite (depcheck and possibly other tests
>> - rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
>> apply to all packages or just critpath packages; it may apply
>> everywhere, which will make it a bit easier to get to +3 karma for
>> automated updates.
> 
> IMHO it should not be a +1 karma but some different flag that is set for
> updates that passed the tests.
> 

Using karma is viewed as the path of least resistance to getting support
in current bodhi for this.  For future bodhi yes, it makes some sense to
use some different flagging mechanism.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwzXGEACgkQ4v2HLvE71NWG/gCfWBn186RjSugsdftn3fgscVfk
2HgAn0D4gbh7ukm1nLN8lkMXZTffkrIG
=66bz
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

take over of gnustep-make

2010-07-06 Thread Jochen Schmitt

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo,

I will inform you, that I have taken the ownership of the
gnustep-make package.

Of course, co-maintainers may be welcome.

Best Regards:

Jochen Schmitt
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iJwEAQECAAYFAkwzW2oACgkQZLAIBz9lVu+XVQQAwzHR4nBLG9hPNakkd6UFy95Z
iglzA/wpaxny3HLK19b2CUS7n/bbAdM7LIzeD+0iw1XCFj7QD+PzxGSycVF5xvuW
sj+5IaQEIlnyukD1ZiZ+Sp5oE187Mg+5k+ZGa7M5/AvEcpapYyDNYZXTq3we2tcU
OxhY2JnLyfJOQ/ZFZt4=
=kHYY
-END PGP SIGNATURE-

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

Outage: PHX2 outage - 2010-07-05 01:00 UTC

2010-07-06 Thread Mike McGrath


There is an ongoing outage at this time in PHX2.  The exact start time is
not yet known and the ETA to be fixed is not yet known.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2010-07-05 01:00'

Reason for outage:

Several people are experiencing issues connecting to various Fedora
services (see below).  The cause for these issues seems to be network
related and it is impacting different people differently.  Some see packet
loss, other see complete connectivity loss and other still aren't having
any issues at all.

Some services listed as unaffected would have been impacted previously to
this announcement but as we became aware of the issue have made some
changes to bring those services back online.  Those services include
bodhi, the account system, pkgdb, main website/wiki, community and
mirrormanager.

Affected Services:

Bodhi - https://admin.fedoraproject.org/updates/
Buildsystem - http://koji.fedoraproject.org/
CVS / Source Control
DNS - ns1.fedoraproject.org, ns2.fedoraproject.org
Email system

Unaffected Services:

Fedora Account System - https://admin.fedoraproject.org/accounts/
Fedora Community - https://admin.fedoraproject.org/community/
BFO - http://boot.fedoraproject.org/
Docs - http://docs.fedoraproject.org/
Fedora Hosted - https://fedorahosted.org/
Fedora People - http://fedorapeople.org/
Fedora Talk - http://talk.fedoraproject.org/
Main Website - http://fedoraproject.org/
Mirror List - https://mirrors.fedoraproject.org/
Mirror Manager - https://admin.fedoraproject.org/mirrormanager/
Package Database - https://admin.fedoraproject.org/pkgdb/
Smolt - http://smolts.org/
Spins - http://spins.fedoraproject.org/
Start - http://start.fedoraproject.org/
Torrent - http://torrent.fedoraproject.org/
Translation Services - http://translate.fedoraproject.org/
Wiki - http://fedoraproject.org/wiki/


Ticket Link:

https://fedorahosted.org/fedora-infrastructure/ticket/2255

Contact Information:

Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.


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

Re: depcheck test (was Re: measuring success)

On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote:
> On 7/6/10 8:52 AM, Till Maas wrote:
> > On Tue, Jul 06, 2010 at 11:34:25AM -0400, Will Woods wrote:
> > 
> >> Once we're satisfied that depcheck does the right thing, we will
> >> probably set it up to start adding automatic +1 karma from 'autoqa' when
> >> updates pass the automated test suite (depcheck and possibly other tests
> >> - rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
> >> apply to all packages or just critpath packages; it may apply
> >> everywhere, which will make it a bit easier to get to +3 karma for
> >> automated updates.
> > 
> > IMHO it should not be a +1 karma but some different flag that is set for
> > updates that passed the tests.
> > 
> 
> Using karma is viewed as the path of least resistance to getting support
> in current bodhi for this.  For future bodhi yes, it makes some sense to
> use some different flagging mechanism.

Essentially using a different flag is just re-using the code used to
flag a package as critpath-approved only with a different name.
Therefore it should not need that much more effort.

Btw. using the "path of least resistance" to implement policy
changes seems to be what makes the new workflows suck for package
maintainers, e.g. with the change in place using a auto-karma value of 1
will become 0.

Regards
Till


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

Re: depcheck test (was Re: measuring success)

On Tue, Jul 06, 2010 at 11:34:25AM -0400, Will Woods wrote:

> I'll attempt to give a brief summary here. First you need to understand
> that there are three states for a package that has been built with the
> hope of being pushed as an update:
> * 'candidate': freshly-built packages intended for updates
> * 'proposed': bodhi request filed, but not pushed live
> * 'live': packages that have been pushed live by rel-eng

I first thought that
live == stable and 
proposed = "in testing with request for stable" and
candidate = "pending, not in tested, not requested to become testing"?

But this does not match the remainder of this e-mail.

> So. What we want to do in AutoQA is trigger a test to check dependencies
> *before* the package goes live. So we trigger our test when the request
> is filed (this is the 'post-bodhi-update' hook in AutoQA, which was
> merged a week or two back).
> 
> It should be obvious that the goal of the test is to examine the
> proposed updates and hold back the ones whose dependencies are
> inconsistent with the packages in the live repos[1]. To phrase it
> slightly differently: we want to look at the set of 'proposed' updates
> and pass the packages whose dependencies *are* consistent with the live
> repos.

> Once we're satisfied that depcheck does the right thing, we will
> probably set it up to start adding automatic +1 karma from 'autoqa' when
> updates pass the automated test suite (depcheck and possibly other tests
> - rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
> apply to all packages or just critpath packages; it may apply
> everywhere, which will make it a bit easier to get to +3 karma for
> automated updates.

If I interpret the terms live, proposed and candidate as above, the +1
karma will not have any effect on autokarma, because the check is only
run after there is a request to push the updates to stable and autokarma
does not matter anymore.

But if live == testing and proposed == "pending with request to
testing", there might still dep breakage happend when not all dependent
updates are pushed to stable. Therefore it seems the test needs to run
twice, once to avoid breakage in testing and once to avoid breakage in
stable. Is this intended or do I miss something?

Regards
Till

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

Fedora 14 Feature Submission Deadline is One Week Away (2010-07-13)

2010-07-06 Thread John Poelstra

This email serves as the last reminder for the Fedora 14 Feature 
Submission Deadline--Tuesday, July 13, 2010.  After this date newly 
submitted features will be targeted for Fedora 15 unless an exception is 
granted by FESCo.

Accepted Fedora 14 features so far: 
https://fedoraproject.org/wiki/Releases/14/FeatureList

If you are a current feature page owner, thank you for submitting your 
feature for Fedora 14 and contributing to the next release of Fedora. 
If you haven't updated your feature page in the last month it would be a 
great help to every one if you would do so now.

As we start to reach deadlines and test releases for Fedora 14, more and 
more people will query the feature pages.  We'd love to know that what 
they find is current and correct.

Thank you,
John


More information:
   Fedora 14 Schedule: https://fedoraproject.org/wiki/Releases/14/Schedule

   Fedora Feature Process: https://fedoraproject.org/wiki/Features/Policy
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Help with Koji error: "error: possibly undefined macro: AS_MESSAGE_LOG_FDdnl"

I get this build failure trying to build vhostmd:

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

http://koji.fedoraproject.org/koji/getfile?taskID=2298704&name=build.log

+ autoreconf
configure:11354: error: possibly undefined macro: AS_MESSAGE_LOG_FDdnl
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

I can't reproduce it locally on my nearly up to date Rawhide machine,
and the literal string 'AS_MESSAGE_LOG_FDdnl' doesn't appear anywhere
in the source.  The fact that 'dnl' immediately follows 'AS_MESSAGE_LOG_FD'
might imply some sort of corruption of some m4 file.

No ideas ...  anyone?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Can anyone contact Gérard Milmeister (gemi)?

2010-07-06 Thread Thomas Janssen

On Tue, Jul 6, 2010 at 8:48 AM, Gérard Milmeister  wrote:
> On Tue, 2010-07-06 at 10:13 +0800, Chen Lei wrote:
>> Hi FESCo,
>>
>> Can we orphan his packages now? I'd like to take scons, I don't think
>> waiting more time will be helpful.
>
> Hi,
>
> I am still alive.
> I had always hoped to find the time to resume work on the packages,
> however it turned out that circumstances do not allow me any leisure
> anymore for serious participation (at least for now). So I would be glad
> if people take over packages, especially those that require some work. I
> will try to follow the mailing-list for the next days.

Thanks for supporting all the packages since a long time. I will take: sweep

-- 
LG Thomas

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

Re: depcheck test (was Re: measuring success)

2010-07-06 Thread Jesse Keating

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/06/2010 10:21 AM, Till Maas wrote:
> Essentially using a different flag is just re-using the code used to
> flag a package as critpath-approved only with a different name.
> Therefore it should not need that much more effort.

critpath approved is based on karma as well, so I'm not sure what you're
suggesting here.

> 
> Btw. using the "path of least resistance" to implement policy
> changes seems to be what makes the new workflows suck for package
> maintainers, e.g. with the change in place using a auto-karma value of 1
> will become 0.

You're welcome to contribute some design/code to make this happen, but
we felt that it was best to get something in place to prevent the broken
deps then to wait for major changes in bodhi code base.


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkwzdP0ACgkQ4v2HLvE71NUajgCgmFKsIeCiL+g9fRT/1TxzQNG7
S1cAoKdjF7aA0YyMnx7IIMmRlpRk3xQH
=dPfd
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: depcheck test (was Re: measuring success)

2010-07-06 Thread Will Woods

On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote:
> On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote:
> > On 7/6/10 8:52 AM, Till Maas wrote:
> > > IMHO it should not be a +1 karma but some different flag that is set for
> > > updates that passed the tests.
> > 
> > Using karma is viewed as the path of least resistance to getting support
> > in current bodhi for this.  For future bodhi yes, it makes some sense to
> > use some different flagging mechanism.
> 
> Essentially using a different flag is just re-using the code used to
> flag a package as critpath-approved only with a different name.
> Therefore it should not need that much more effort.

Feel free to help write the code to prove this point!

> Btw. using the "path of least resistance" to implement policy
> changes seems to be what makes the new workflows suck for package
> maintainers, e.g. with the change in place using a auto-karma value of 1
> will become 0.

Well that's only one *proposed* idea. We could just as easily have
autoqa give a comment with neutral (0) karma on updates which pass, and
-1 on failed updates, which would serve all the same purposes. That
might be a better idea, actually.

-w

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

Re: depcheck test (was Re: measuring success)

On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote:

> Essentially using a different flag is just re-using the code used to
> flag a package as critpath-approved only with a different name.
> Therefore it should not need that much more effort.
> 
> Btw. using the "path of least resistance" to implement policy
> changes seems to be what makes the new workflows suck for package
> maintainers, e.g. with the change in place using a auto-karma value of 1
> will become 0.

I'm with Till, this particular bit seems to be a hack too far. I'd say
until we can get a proper mechanism in place, the most the test should
do with current Bodhi is file a comment saying the depcheck test passed,
with 0 karma (not +1).
-- 
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: depcheck test (was Re: measuring success)

On Tue, 2010-07-06 at 11:34 -0400, Will Woods wrote:

> If there are any other questions, feel free to ask.
> 
> -w

Did you get to look at the nss-softokn situation (details of which I
sent to autoqa-devel) yet? How hard would it be to catch that?
-- 
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: Bodhi 0.7.5 release

On Sun, 2010-07-04 at 17:27 +0200, Michel Alexandre Salim wrote:
> On Sun, Jul 4, 2010 at 1:27 PM, Till Maas  wrote:
> > On Sun, Jul 04, 2010 at 12:34:59PM +0200, Michel Alexandre Salim wrote:
> >> On Sun, Jul 4, 2010 at 10:34 AM, Till Maas  wrote:
> >> > On Sun, Jul 04, 2010 at 01:32:16AM +0200, Michel Alexandre Salim wrote:
> >> >
> >> >> Could a flag be added to only output the package names, so that I can
> >> >> pipe the output directly to yum? Or even better, have that flag
> >> >> automatically cause the bodhi client to invoke yum with
> >> >> --enable-repo=updates-testing with the packages required.
> >> >
> >> > You can just install all critpath updates using:
> >> >
> >> > yum groupinstall --enable-repo=\*-testing critical-path\* core
> >> >
> >> > and then use f-e-k from git with --critpath-only to get only asked for
> >> > the unapproved ones.
> >> Ah! Would be great if this is listed on the QA page.
> >
> > If you know on which page it fits, just add it. I did not find a
> > matching page when I swept through the QA pages.
> >
> I don't -- Adam Williamson probably knows better. Adam?

We have a page with general instructions for testing stuff in
updates-testing:

https://fedoraproject.org/wiki/QA/Updates_Testing

and also a page of instructions for proven testers:

https://fedoraproject.org/wiki/Proven_tester

This is info that's probably useful for both, really. I certainly
intended to extend the proven_tester page with instructions on the new
functionality in f-e-k, as soon as it's available in a released f-e-k
version (I really don't want to be bothering proventesters with
suggestions to check their f-e-k out of git, so it'd be nice to have a
new version pushed with the new features). We could certainly add the
info on using yum to *install* only critpath updates too.
-- 
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: Help with Koji error: "error: possibly undefined macro: AS_MESSAGE_LOG_FDdnl"

2010-07-06 Thread Jochen Schmitt

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 06.07.2010 19:42, schrieb Richard W.M. Jones:
> + autoreconf
> configure:11354: error: possibly undefined macro: AS_MESSAGE_LOG_FDdnl
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
>
> I can't reproduce it locally on my nearly up to date Rawhide machine,
> and the literal string 'AS_MESSAGE_LOG_FDdnl' doesn't appear anywhere
> in the source.  The fact that 'dnl' immediately follows 'AS_MESSAGE_LOG_FD'
> might imply some sort of corruption of some m4 file.
I assume, that thei phrase may occures in a file under

/usr/share/aclocal

In this case you may have a dependency issue based by a
package which is installed on your rawhide system, but which
is not declared as a BuildRequires for your package.

Best Regards:

Jochen Schmitt
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iJwEAQECAAYFAkwzgWsACgkQZLAIBz9lVu824wP/RKiVepZnJXUUfkCJcGICvbiE
4Nn+UokCQ6tNMW8U8jAQrGSke7EaPOvPxwfAJ/nc4Y/GRqgzxdntXjJsTYpPGnk5
EanB+f37mO0q/zkpxdMACpVTTOD49Oz9CywjBFCAxzFN5apccr1L7BPack2PWgDP
gDAQPYi7vAsKhvHUcFc=
=Z3NA
-END PGP SIGNATURE-

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

[Bug 609600] cduce : does not adhere to Static Library Packaging Guidelines

2010-07-06 Thread bugzilla

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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

Michael Schwendt  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution||RAWHIDE

--- Comment #1 from Michael Schwendt  2010-07-06 15:46:58 
EDT ---
Closed by: fedora-report-static-batch.py

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel

[Test-Announce] Please help test 389 Directory Server 1.2.6 Release Candidate 3

2010-07-06 Thread Rich Megginson

The 389 team is pleased to announce the availability of Release
Candidate 3 of version 1.2.6.  This release contains a couple of bug fixes.

***We need your help!  Please help us test this software.***  It is a
Release Candidate release, so it may have a few glitches, but it has
been tested for regressions and for new feature bugs.  The Fedora system
strongly encourages packages to be in Testing until verified and pushed
to Stable.  If we don't get any feedback while the packages are in
Testing, the packages will remain in limbo, or get pushed to Stable.

The more testing we get, the faster we can release these packages to
Stable.  See the Release Notes for information about how to provide
testing feedback (or just send an email to
389-us...@lists.fedoraproject.org).

The packages that need testing are:
* 389-ds-base-1.2.6.rc3 - 389-ds-base

More information:
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download

=== Bugs Fixed ===
This release contains a few bug fixes.  The complete list of bugs
fixed is found at the link below.  Note that bugs marked as MODIFIED
have been fixed but are still in testing.
* Tracking bug for 1.2.6 release -
https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0
**  Bug 606920 - anonymous resource limit - nstimelimit - also applied 
to "cn=directory manager"
** Bug 604453 - SASL Stress and Server crash: Program quits with the 
assertion failure in PR_Poll
** Bug 605827 - In-place upgrade: upgrade dn format should not run in 
setup-ds-admin.pl
** Bug 578296 - Attribute type entrydn needs to be added when subtree 
rename switch is on
** Bug 609256 - Selinux: pwdhash fails if called via Admin Server CGI
** Bug 603942 - null deref in _ger_parse_control() for subjectdn





___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: depcheck test (was Re: measuring success)

On Tue, Jul 06, 2010 at 03:06:37PM -0400, Will Woods wrote:
> On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote:
> > On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote:
> > > On 7/6/10 8:52 AM, Till Maas wrote:
> > > > IMHO it should not be a +1 karma but some different flag that is set for
> > > > updates that passed the tests.
> > > 
> > > Using karma is viewed as the path of least resistance to getting support
> > > in current bodhi for this.  For future bodhi yes, it makes some sense to
> > > use some different flagging mechanism.
> > 
> > Essentially using a different flag is just re-using the code used to
> > flag a package as critpath-approved only with a different name.
> > Therefore it should not need that much more effort.
> 
> Feel free to help write the code to prove this point!
> 
> > Btw. using the "path of least resistance" to implement policy
> > changes seems to be what makes the new workflows suck for package
> > maintainers, e.g. with the change in place using a auto-karma value of 1
> > will become 0.
> 
> Well that's only one *proposed* idea. We could just as easily have
> autoqa give a comment with neutral (0) karma on updates which pass, and
> -1 on failed updates, which would serve all the same purposes. That
> might be a better idea, actually.

Using karma 0 the patch could be this one:
http://till.fedorapeople.org/tmp/0001-support-passed_autoqa.patch

Tested with:
http://0.0.0.0:8084/updates/sos-2.2-0.fc13

To make it pass autoqa run in sqlite3 /var/tmp/bodhi.sqlite
update comment set author = "autoqa" where update_id = 1435;

Instead of making it a bool, it might be also a good idea to use three
values: untested, passed, failed and in case if failed a pointer to the
test results.

Regards
Till


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

Re: depcheck test (was Re: measuring success)

On Tue, Jul 06, 2010 at 11:25:01AM -0700, Jesse Keating wrote:
> On 07/06/2010 10:21 AM, Till Maas wrote:
> > Essentially using a different flag is just re-using the code used to
> > flag a package as critpath-approved only with a different name.
> > Therefore it should not need that much more effort.
> 
> critpath approved is based on karma as well, so I'm not sure what you're
> suggesting here.

I thought it is its own field in the database, because according to the
current policy it is not supposed to change once it was true. But yes,
the current implementation did not help that much here, but the patch in
the other mail shows how it can be done.

Regards
Till

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

Re: depcheck test (was Re: measuring success)

On Tue, Jul 06, 2010 at 10:09:34PM +0200, Till Maas wrote:
> On Tue, Jul 06, 2010 at 03:06:37PM -0400, Will Woods wrote:
> > On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote:
> > > On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote:
> > > > On 7/6/10 8:52 AM, Till Maas wrote:
> > > > > IMHO it should not be a +1 karma but some different flag that is set 
> > > > > for
> > > > > updates that passed the tests.
> > > > 
> > > > Using karma is viewed as the path of least resistance to getting support
> > > > in current bodhi for this.  For future bodhi yes, it makes some sense to
> > > > use some different flagging mechanism.
> > > 
> > > Essentially using a different flag is just re-using the code used to
> > > flag a package as critpath-approved only with a different name.
> > > Therefore it should not need that much more effort.
> > 
> > Feel free to help write the code to prove this point!
> > 
> > > Btw. using the "path of least resistance" to implement policy
> > > changes seems to be what makes the new workflows suck for package
> > > maintainers, e.g. with the change in place using a auto-karma value of 1
> > > will become 0.
> > 
> > Well that's only one *proposed* idea. We could just as easily have
> > autoqa give a comment with neutral (0) karma on updates which pass, and
> > -1 on failed updates, which would serve all the same purposes. That
> > might be a better idea, actually.
> 
> Using karma 0 the patch could be this one:
> http://till.fedorapeople.org/tmp/0001-support-passed_autoqa.patch
> 
> Tested with:
> http://0.0.0.0:8084/updates/sos-2.2-0.fc13
> 
> To make it pass autoqa run in sqlite3 /var/tmp/bodhi.sqlite
> update comment set author = "autoqa" where update_id = 1435;
> 
> Instead of making it a bool, it might be also a good idea to use three
> values: untested, passed, failed and in case if failed a pointer to the
> test results.

Also the patch is not quite correct depending on how autoqa is supposed
to provide comments. In case it really does provide a -1 comment in case
of a broken dep, it also needs to provide a +1 comment afterwards once
the dep is fixed. This is currently not implemented. But in case autoqa
only ever adds a comment in case the update is ok, which is unlikely,
because a later update might break the deps again, then it would work.

A better documentation about what autoqa actually does would help to
write a proper patch.

Regards
Till


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

Re: who is Petr Pisar from redhat ?

2010-07-06 Thread Chitlesh GOORAH

On Thu, Jul 1, 2010 at 9:21 PM, seth vidal  wrote:
>
> try to be excellent, please.
> -sv

Be excellent would be that guy to drop me a mail stating my package is
being updated to a new version. This is respect !

Similarly my package perl-perlilog is now part of RHEL-6, I haven't
got any email from its RH maintainer whether he cares to co-maintain
it with me on fedora as well. Where is that sense of friendship Fedora
once had ? This is disgusting !

I FULLY support Ralf Corsepius's comments.

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

Re: who is Petr Pisar from redhat ?

2010-07-06 Thread seth vidal

On Tue, 2010-07-06 at 22:26 +0200, Chitlesh GOORAH wrote:
> On Thu, Jul 1, 2010 at 9:21 PM, seth vidal  wrote:
> >
> > try to be excellent, please.
> > -sv
> 
> Be excellent would be that guy to drop me a mail stating my package is
> being updated to a new version. This is respect !
> 
> Similarly my package perl-perlilog is now part of RHEL-6, I haven't
> got any email from its RH maintainer whether he cares to co-maintain
> it with me on fedora as well. Where is that sense of friendship Fedora
> once had ? This is disgusting !

It's not a one way street. But if you follow the rest of the discussion
you'll see it wasn't a malicious action either.

I think you need to calm down.

> 
> I FULLY support Ralf Corsepius's comments.

Then you SERIOUSLY need to take a step back from things.

-sv


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

Minutes/Summary from today's FESCo meeting (2010-07-06 at 19:30UTC)

===
#fedora-meeting: FESCO (2010-07-06)
===

Meeting started by nirik at 19:30:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-07-06/fesco.2010-07-06-19.30.log.html

Meeting summary
---
* init process (nirik, 19:30:01)
* cwickert and mclasen are unable to attend today and have added
votes/comment to ticket items. (nirik, 19:30:41)

* #387 compile list of supported CPUs and reacto to recent loss of
support for Geode LX on F13 (nirik, 19:33:17)

* #412 Non-responsive maintainer (ixs); request fast-track orphaning of
libsndfile (nirik, 19:35:46)
* AGREED: nirik will try and contact ixs one last time, will reassign
libsndfile if no response in a few days. (nirik, 19:41:42)

* #409 Feature Request: GNUstep (nirik, 19:41:55)
* AGREED: defer a week to ask questions in the ticket / wiki page
(nirik, 19:51:33)

* #410 F14Feature: http://fedoraproject.org/wiki/Features/D_Programming
(nirik, 19:52:14)
* AGREED: Feature is approved. (nirik, 19:55:18)

* #413 F14Feature: http://fedoraproject.org/wiki/Features/Go_Programming
(nirik, 20:00:25)
* AGREED: will defer a week to ask which compiler will be used and
more info from feature owners. (nirik, 20:06:11)

* #351 Create a policy for updates - status report on implementation
(nirik, 20:06:19)
* LINK: https://fedorahosted.org/fesco/ticket/351 (nirik, 20:06:19)
* LINK: http://bochecha.fedorapeople.org/bodhi_karma_revamped
(lmacken, 20:18:09)
* AGREED: lmacken writes up what the exact logic currently is. Next
week we visit that and see what changes we would like to make.
(nirik, 20:19:11)

* #382 Implementing Stable Release Vision (nirik, 20:20:42)
* LINK:

https://fedoraproject.org/wiki/User:Dafrito/Stable_release_updates_vision_implementation_ideas
(nirik, 20:50:38)
* ACTION: notting to work on Fedora 14: Document this stance in
maintainer docs and announce to maintainers the new docs. (nirik,
20:56:51)
* ACTION: SMParrish to work on Fedora 14: metrics on how many updates
each branch gets including rawhide? (nirik, 20:57:03)
* ACTION: nirik to work on Fedora 14: Some way to document failures to
quality and consistency so we can learn from them, and see that the
incidence is decreasing. (nirik, 20:57:14)
* ACTION: kylem to work on Fedora 14: Have an updates-features
optional repository. (nirik, 21:00:18)
* ACTION: mjg59 to work on Fedora 14: Document a exception process.
Some packages will need to provide updates for security reasons or
working with external sources, etc. (nirik, 21:00:52)

* Fedora orphanage/collective maint SIG (nirik, 21:03:09)
* ACTION: will review proposal from the group (nirik, 21:07:32)

* FES tickets roundup (nirik, 21:07:44)

* Open floor (nirik, 21:13:41)

Meeting ended at 21:16:41 UTC.

Action Items

* notting to work on Fedora 14: Document this stance in maintainer docs
and announce to maintainers the new docs.
* SMParrish to work on Fedora 14: metrics on how many updates each
branch gets including rawhide?
* nirik to work on Fedora 14: Some way to document failures to quality
and consistency so we can learn from them, and see that the incidence
is decreasing.
* kylem to work on Fedora 14: Have an updates-features optional
repository.
* mjg59 to work on Fedora 14: Document a exception process. Some
packages will need to provide updates for security reasons or working
with external sources, etc.
* will review proposal from the group
--
19:30:01 #startmeeting FESCO (2010-07-06)
19:30:01 Meeting started Tue Jul 6 19:30:01 2010 UTC. The chair is
nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 Useful Commands: #action #agreed #halp #info #idea #link
#topic.
19:30:01 #meetingname fesco
19:30:01 #chair mclasen notting nirik SMParrish kylem ajax pjones
cwickert mjg59
19:30:01 #topic init process
19:30:01 The meeting name has been set to 'fesco'
19:30:01 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59
nirik notting pjones
19:30:27 g'afternoon.
19:30:40 morning, sunshine.
19:30:41 .fas bioinfornatics
19:30:41 #info cwickert and mclasen are unable to attend today and have
added votes/comment to ticket items.
19:30:41 bioinfornatics: bioinfornatics 'MERCIER Jonathan'

19:30:49 Afternoon all
19:31:02 evening here :)
19:31:23 come on party people
19:31:25 Afternon
19:32:32 ok, lets go ahead and get started I guess.
19:33:03 lets go ahead and do the updates items at the end, so we have
more time...
19:33:17 #topic #387 compile list of supported CPUs and reacto to
recent loss of support for Geode LX on F13
19:33:18 .fesco 387
19:33:19 nirik: #387 (compile list of supported CPUs and react to
recent loss of support for Geode LX on F13) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/387
19:33:22 kylem: any news

[389-devel] Please review: Bug 611850 - fix coverity Defect Type: Error handling issues

2010-07-06 Thread Rich Megginson

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

https://bugzilla.redhat.com/attachment.cgi?id=429926&action=diff

https://bugzilla.redhat.com/attachment.cgi?id=429926&action=edit
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: measuring success [was Re: Bodhi 0.7.5 release]

Michael Schwendt wrote:
> One can quickly see that several (if not many) of them are due
> to orphans/retired packages in Fedora 12. And due to violated upgrade
> paths (e.g. compat-db):

That just proves that we should avoid retiring packages, but try to keep 
them alive as long as we can, even if it's just rebuilds for new 
dependencies.

> ==
> Broken packages in fedora-12-x86_64:
> 3:koffice-kivio-1.6.3-26.20090306svn.fc12.i686  requires  koffice-core
> = 3:1.6.3-26.20090306svn.fc12
> kdeedu-math-4.3.2-2.fc12.i686  requires  libboost_python-mt.so.5

These are multilib problems. koffice-kivio and kdeedu-math are no longer 
multilib. But people should not have those installed as multilib anyway, 
since they're leaf packages. This just shows how the "install everything as 
multilib" option is harmful and we should finally stop supporting that 
nonsense completely (it stopped being the default in F9, thankfully).

On all architectures:
> kdelibs-experimental-devel-4.3.5-1.fc12.i686  requires 
> libknotificationitem-1.so.1
> kdelibs-experimental-devel-4.3.5-1.fc12.i686  requires 
> kdelibs-experimental = 0:4.3.5-1.fc12

This is because kdelibs-devel only Obsoletes kdelibs-experimental-devel on 
F12.

> pinentry-qt4-0.8.0-2.fc12.i686  requires  pinentry = 0:0.8.0-2.fc12

Missing Obsoletes, I guess.

Kevin Kofler

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

Deactivating LVDS display when laptop lid is closed

2010-07-06 Thread Orion Poplawski

Apparently[1] it is up to the desktop environment now to deactivate the LVDS 
display if the laptop lid is closed at boot (or whenever?).  I now have 
several F13 laptops in docks with external monitors that boot with the lid 
closed, but kdm_greet puts the login panel on the closed LVDS display (see 
bug[2]).  I've also filed a Fedora bug for similar stuff here [3].  I don't 
know how gdm behaves.

Any other comments/help?  I tried doing:

# Disable LVDS if another output is up
if xrandr --current | grep -qE '^(DVI|VGA).* connected'
then
lvds=$(xrandr --current | awk '$1 ~ /LVDS/ { print $1 }')
xrandr --output $lvds --off
fi

in /etc/kde/kdm/Xsetup, but kdm_greet appears to get stuck in an infinite loop 
and I only see the small round black spinner cursor, never the login panel.

I thought about posting to the Fedora KDE list, but I'd like to get some wider 
input.

1 - https://bugs.freedesktop.org/show_bug.cgi?id=28936
2 - https://bugs.kde.org/show_bug.cgi?id=243807
3 - https://bugzilla.redhat.com/show_bug.cgi?id=539180

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Requires --> BuildRequires (was: Re: measuring success)

Michael Schwendt wrote:
> And there would be drawbacks, too, for a hardcoded "Req => BR" rule.
> It would make circular deps impossible: Pkg A requires Pkg A-extras,
> and Pkg A-extras BR Pkg A.  It would make bootstrapping a dist more
> complicated. For some pkgs (e.g. leaf pkgs) it is fine if they are
> not available in the buildroot when building a pkg that requires the
> leaf pkg at run-time.  For other pkgs it is fine if you build them
> with an old build tool for a target env that is build upon a newer tool.

Also note that we explicitly patch the build time checks for PyKDE4 
(subpackage of kdebindings) out of some KDE modules which have Python-based 
subpackages needing PyKDE4 at runtime because we DON'T want to BR PyKDE4, 
since kdebindings is usually one of the last packages we build for a given 
KDE version.

Kevin Kofler

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

Re: depcheck test (was Re: measuring success)

Till Maas wrote:
> Btw. using the "path of least resistance" to implement policy
> changes seems to be what makes the new workflows suck for package
> maintainers, e.g. with the change in place using a auto-karma value of 1
> will become 0.

That would be a good thing! It'd make all those requirements of karma 1 
(which is also implied in the critpath process which needs an extra karma 
point IN ADDITION TO the proventesters approval, as if a proven tester could 
not be trusted :-/ ) actually bearable.

Kevin Kofler

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

Re: (lack of) maintainership of epiphany?

On Tue, 2010-07-06 at 13:59 +0100, pbrobin...@gmail.com wrote:
> I wonder about the maintainer ship of epiphany. The ownership of it is
> gecko-maint but in none of the current versions of fedora is epiphany
> gecko based and of the 18 other maintainers not a single person is on
> the bugzilla watch ACL. There's a bug that was introduced at some
> point in the F-13 time frame where it crashes on all the machines I
> attempt to use it on when it first tries to load a page, there's quite
> a few dupes. I'm really surprised that no one has picked this up.

I thought I had, but it may have been something I filed under 'poke
someone about later when I'm not so busy'...

To me it would seem to make sense for the desktop team to own it, since
it's a part of GNOME.
-- 
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: concept of package "ownership"

Nils Philippsen wrote:
> AIUI, a SIG are more people than those who actually work on related
> packages as maintainers, or are competent and responsible enough to not
> break things in the process of updating packages with which they're not
> familiar (otherwise they'd be (co-)maintainers, wouldn't they?).
> 
> If we ever get group ACLs, I think we should have $SIG-packager groups,
> consisting of SIG members who fulfill the above, who get that kind of
> access.

That's true, not all SIG members are packagers, only those that actually are 
should get packaging access.

(As for what packagers to trust with such access, that's really the 
individual SIG's business. I'm personally a defender of the "give everyone 
the benefit of the doubt, but yell loudly and threaten revoking access if 
they screw up" approach. :-) )

Kevin Kofler

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

Re: concept of package "ownership"

Darryl L. Pierce wrote:
> There _is_ a middle ground between bleeding edge and extremely stable.
> 
> A Fedora release should have a locked version of key shared packages,
> such as Python, Rails, etc., should be kept at a specific version (with
> upgrades only for bug fixes).

Well, I don't know how Rails works, but for Python, yes, of course we don't 
want Python upgraded to an ABI-incompatible version (say, from 2.6 to 2.7) 
in updates! If you thought I was asking for that kind of updates (which 
require rebuilding half of the distro!), you misunderstood me!

On the other hand, point releases (as in 2.6.n to 2.6.n+1) ARE "only bug 
fixes" and as such SHOULD get pushed.

Kevin Kofler

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

Sven Lankes wrote:
> Maybe we could tweak the pkgdb in a way that a co-maintainer request
> would automatically be granted if it isn't answered within a long enough
> timeframe (say 8 weeks).
> 
> That way packages with AWOL maintainers could grow co-maintainers
> without going through the complicated AWOL-process.

+1, good idea!

And IMHO 8 weeks is too much, it should be somewhere between 2 and 4.

Kevin Kofler

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

Thomas Spura wrote:
> For me it doesn't make much sense to be co-maintainer everywhere, but
> actually:
> 1. doing all the tasks alone.

I don't see the big problem. I'm "comaintaining" a few packages in that way 
for a while (xchat and mingw32-nsis come to my mind) and that just works 
(though I do sometimes get angry about "maintainers" being registered there 
and rarely doing anything).

(BTW, it's quite funny that the main GTK+-based IRC client is maintained 
almost exclusively by a KDE SIG member. ;-) )

> 2. when there is a problem with the package, other contact at
> first the maintainer, which should be the new one, too.

They should contact -ow...@fedoraproject.org, which also includes 
comaintainers.

Kevin Kofler

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

Till Maas wrote:
> We can use "uberpackagers" ;-) or maybe "package-monkeys", make it a SIG
> and then it is afaik already covered by Fedora procedures, because a SIG
> or group of packagers can own a package, like e.g. the lvm-team.
> 
> Orcan, Richard, who else is in?

As an "inclusionist" and someone who has often stepped in to fix broken 
dependencies in, uhm, "very passively maintained" packages, count me in!

I think it's in almost all cases better to have a package than not to have 
it, even if it's not well maintained.

Kevin Kofler

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

Kevin Fenzi wrote:

> On Tue, 6 Jul 2010 13:39:43 +0100
> "Richard W.M. Jones"  wrote:
>> If #maintainers == 0 then the package is either just sitting there (as
>> long as there are no serious bugs), or is being best-effort maintained
>> by provenpackagers, at least until that becomes a burden and only then
>> should the package be dropped.
> 
> If some provenpackager want's to maintain it, why don't they take
> ownership?

Because I can fix the occasional broken dependency, but I can't commit to 
actually maintain hundreds of packages. For example, the bugmail would flood 
me, I couldn't fix any of those bugs anyway, only the complete showstoppers 
(i.e. broken deps and MAYBE (!) FTBFS).

Kevin Kofler

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

2010-07-06 Thread Chris Jones

On Wed, Jul 7, 2010 at 9:43 AM, Kevin Kofler  wrote:

>
> And IMHO 8 weeks is too much, it should be somewhere between 2 and 4.
>
>        Kevin Kofler
>
>

I initially thought 8 weeks was too long also, but I guess people have
busy lifestyles. 4 weeks is probably more realistic. If you can't
access your email and reply within 4 weeks then there's definitely
something going on there. 

Regards

--
Chris Jones
Photographic Imaging Professional and Graphic Designer
ABN: 98 317 740 240

Photo Resolutions - Photo Printing, Editing and Restorations
Web: http://photoresolutions.freehostia.com
Email:  or 

Fedora Design Suite Developer and Co-Maintainer
Email: 
--
GnuPG v1.4.10 (GNU/Linux)
Public Key Fingerprint:
6915 0761 5754 D091 99F4
5384 BA37 FD5D 34F9 F115
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

Richard W.M. Jones wrote:
> I think this is another problem with pkgdb or Fedora.  Why is there a
> maintainer ("owner"?) and co-maintainers, rather than just having all
> co-maintainers be equal?

Good point. I think, just like you, that there should be a list of owners 
rather than just 1 owner.

> As people know, my default position is for inclusion: we should try to
> include as many packages in Fedora that we can, except where there is
> a legal or insuperable technical problem with that.
> 
> So I think it's valid for packages to have 0, 1, 2, or more
> maintainers.
> 
> If #maintainers == 0 then the package is either just sitting there (as
> long as there are no serious bugs), or is being best-effort maintained
> by provenpackagers, at least until that becomes a burden and only then
> should the package be dropped.

This is really a separate issue, but FWIW, I agree with you on this point as 
well.

Kevin Kofler

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

On Wed, 2010-07-07 at 01:46 +0200, Kevin Kofler wrote:

> (BTW, it's quite funny that the main GTK+-based IRC client is maintained 
> almost exclusively by a KDE SIG member. ;-) )

Well, I use the xchat-gnome fork. I suspect quite a lot of other GNOME-y
folks do...that one's maintained by Brian Pepple.
-- 
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

Fedora 14 test release blocker bugs

2010-07-06 Thread John Poelstra

Hard to believe, but Fedora QA starts its "Pre-Alpha Rawhide Acceptance 
Test Plan" testing this Thursday (2010-07-08).

We've run out of time and run way to implement a new means of tracking 
blocker bugs for Fedora--previously discussed in the context of using 
flags in Bugzilla.  We'll continue to use the same process we've used 
for past releases.

I've created tracker bugs for the Fedora 14 Alpha and Beta releases:

Fedora 14 Alpha = F14Alpha = 
https://bugzilla.redhat.com/show_bug.cgi?id=611990

Fedora 14 Beta = F14Beta = 
https://bugzilla.redhat.com/show_bug.cgi?id=611990

Other tracker bugs for Fedora 14 are at: 
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers#Fedora_14

The criteria for considering a bug a release blocker is at:
Alpha--http://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria#Alpha_Blocker_Bugs

Beta--http://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria#Beta_Blocker_Bugs

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

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

Orcan Ogetbil wrote:
> Some mailing list like dumping-gro...@fedoraproject.org. I am sure
> someone can come up with a better name.
[snip]
> Yes. And everyone who is subscribed to the above mailing list is a
> potential maintainer of those packages with 0 principal maintainers.

Well, you'd have to allow us to disable mail delivery and access the ML 
through Gmane though, otherwise there's no way I could keep up with the 
volume! I really don't want my POP3 mailbox to be flooded. :-)

Kevin Kofler

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

Re: Fedora 14 test release blocker bugs