Re: Seeking co-maintainers: monit

[Stewart Adam]

On 2010/07/03 8:09 PM, Michel Alexandre Salim wrote:
> I've started using monit recently, so I volunteer to co-maintain it as
> well (salimma on pkgdb)
>
> Cheers,
>

Thanks! I've approved your and Maxim's request.

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

Re: I claimed qgis

[Bruno Wolff III]

On Sun, Jul 04, 2010 at 02:21:22 +0200,
  Kevin Kofler  wrote:
> 
> The added complication is that the criterion is when the package was last 
> touched before being orphaned (and some people say it should be when it was 
> last touched by the maintainer, which is even longer ago in qgis's case), 
> not when the ownership was released.

Well there seem to be exceptions to that. Packages often go 3 months without
updates, yet (at least informally) people orphan packages briefly to hand
them over to other people without this being checked. Presumably there is
an exception for orderly handovers where packages are only in orphan status
for a short amount of time.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: I claimed qgis

[Bruno Wolff III]

On Sun, Jul 04, 2010 at 01:40:52 +0200,
  Kevin Kofler  wrote:
> 
> Sorry, but qgis has been orphaned and not updated for more than 3 months, so 
> it needs a rereview as per:
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure

I wasn't sure what the state was. I saw that you had done an update in February
and thought maybe it was recently released. There is also a co-maintainer
still listed.

> which is already in progress here:
> https://bugzilla.redhat.com/show_bug.cgi?id=605373
> where the specfile is also updated to 1.4.

Thanks. You guys were further along than I was, though I have some suggestions
that I have added to the review. Thanks for adding me to it.

> The package is supposed to be owned by Volker Fröhlich, who is being 
> sponsored as part of the rereview.
> 
> So please release ownership again, and you can apply for comaintainership 
> once the required rereview is through.

I released ownership, but hung on to the watch stuff. The bug where ownership
switched on release seems to have been fixed. I'll apply for commit later.
I'd rather be a co-maintainer in any case, as my use case for the package
is fairly limited, and there are a lot of things it does that I probably
won't be playing with.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: I claimed qgis

[Kevin Kofler]

Michel Alexandre Salim wrote:
> Would be nice if our package database supports freezing up packages
> that should not be claimed -- and automatically do that once a package
> is orphaned for long enough?

The added complication is that the criterion is when the package was last 
touched before being orphaned (and some people say it should be when it was 
last touched by the maintainer, which is even longer ago in qgis's case), 
not when the ownership was released.

Kevin Kofler

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

Re: Seeking co-maintainers: monit

[Michel Alexandre Salim]

I've started using monit recently, so I volunteer to co-maintain it as
well (salimma on pkgdb)

Cheers,

-- 
Michel

On Sat, Jul 3, 2010 at 9:32 AM, Maxim Burgerhout  wrote:
> Hi,
>
> I use it on a couple of servers, and I wouldn't mind co-maintaining  it with
> you.
>
> Regards,
>
> Maxim Burgerhout (wz...@fedoraproject.org)
>
> On 2010-07-02 7:55 PM, "Stewart Adam"  wrote:
>
>  Hi,
>
> I packaged monit a while ago but never really got around to using it as I
> found Nagios to be more suitable for my needs... I do not mind continuing to
> package Monit, but seeing as I rarely use it myself it would be great if
> someone who does would like to co-maintain it and help troubleshoot any
> bugs, etc.
>
> Thanks,
> Stewart
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: I claimed qgis

[Michel Alexandre Salim]

On Sun, Jul 4, 2010 at 1:40 AM, Kevin Kofler  wrote:
> Bruno Wolff III wrote:
>> I was looking at qgis for doing roleplaying maps (I am not sure if that
>> will work out) and noticed it was way behind upstream and then when filing
>> a bug, noticed that it was orphaned.
>> I am going to try to get it updated to 1.4 and see how things go. If it
>> works out for roleplaying, I'll be a long term maintainer, if not I might
>> orphan it again.
>
> Sorry, but qgis has been orphaned and not updated for more than 3 months, so
> it needs a rereview as per:
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure
> which is already in progress here:
> https://bugzilla.redhat.com/show_bug.cgi?id=605373
> where the specfile is also updated to 1.4.
>
> The package is supposed to be owned by Volker Fröhlich, who is being
> sponsored as part of the rereview.
>
> So please release ownership again, and you can apply for comaintainership
> once the required rereview is through.
>
Would be nice if our package database supports freezing up packages
that should not be claimed -- and automatically do that once a package
is orphaned for long enough?

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

Re: I claimed qgis

[Kevin Kofler]

Bruno Wolff III wrote:
> I was looking at qgis for doing roleplaying maps (I am not sure if that
> will work out) and noticed it was way behind upstream and then when filing
> a bug, noticed that it was orphaned.
> I am going to try to get it updated to 1.4 and see how things go. If it
> works out for roleplaying, I'll be a long term maintainer, if not I might
> orphan it again.

Sorry, but qgis has been orphaned and not updated for more than 3 months, so 
it needs a rereview as per:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure
which is already in progress here:
https://bugzilla.redhat.com/show_bug.cgi?id=605373
where the specfile is also updated to 1.4.

The package is supposed to be owned by Volker Fröhlich, who is being 
sponsored as part of the rereview.

So please release ownership again, and you can apply for comaintainership 
once the required rereview is through.

Kevin Kofler

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

Re: Bodhi 0.7.5 release

[Michel Alexandre Salim]

On Wed, Jun 30, 2010 at 12:37 AM, Luke Macken  wrote:
> Hi,
>
> I just pushed a version 0.7.5 of bodhi into production.  This release
> contains the following notable changes:
>
> proventesters & strict critical path update handling
> 
>
> Critical path package[0] updates now require positive karma from two
> proventesters[1], and a single +1 from one other community member.
>
> You can get a list of critical path updates using the bodhi web interface:
>
>   https://admin.fedoraproject.org/updates/critpath?release=F13untested=True
>
> You can optionally pass in a specific 'release' or an 'untested' flag,
> which will return a list of critical path updates that have yet to be
> approved.  I have not added these links to the main interface yet,
> because at the moment they are fairly expensive calls.  This will be
> addressed in an upcoming release.
>
> The latest command-line client also supports these options as well:
>
>     $ bodhi --critpath --untested --release F13
>
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.

If we need more testers, we should automate their task as much as
humanly (or, in this case, computerly :p ) possible

Thanks,

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: 78884778
Jabber: hir...@jabber.ccc.de   | IRC: hir...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Packages in RHEL-5 missing from RHEL-6

[Michel Alexandre Salim]

Hi all,

Some key audio packages appear to be missing from RHEL-6, even though
they are in RHEL 5 (not in EPEL):

e.g. attempting to build libfishsound, I get the following error in EL-6:
http://koji.fedoraproject.org/koji/taskinfo?taskID=22931

DEBUG util.py:256:  No Package Found for flac-devel
DEBUG util.py:256:  1:doxygen-1.6.1-3.el6.x86_64
DEBUG util.py:256:  No Package Found for libvorbis-devel
DEBUG util.py:256:  1:pkgconfig-0.23-9.1.el6.x86_64
DEBUG util.py:256:  No Package Found for speex-devel
DEBUG util.py:256:  No Package Found for libsndfile-devel
DEBUG util.py:256:  No Package Found for liboggz-devel

libsndfile is in EPEL and I've requested an EL-6 branch, and I
maintain liboggz, so I'll request EL-5 and EL-6 branches, but flac,
libvorbis and speex really should be there. Is the dist-6E-epel target
misconfigured, or the packages are really not there?

On EL-5 only liboggz is missing (this can be added to EPEL)
http://koji.fedoraproject.org/koji/taskinfo?taskID=2293162

DEBUG util.py:256:  0:flac-devel-1.1.2-28.el5_0.1.i386
DEBUG util.py:256:  1:doxygen-1.4.7-1.1.i386
DEBUG util.py:256:  1:libvorbis-devel-1.1.2-3.el5_4.4.i386
DEBUG util.py:256:  1:pkgconfig-0.21-2.el5.i386
DEBUG util.py:256:  0:speex-devel-1.0.5-4.el5_1.1.i386
DEBUG util.py:256:  0:libsndfile-devel-1.0.17-2.el5.i386
DEBUG util.py:256:  No Package Found for liboggz-devel

Thanks,

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: 78884778
Jabber: hir...@jabber.ccc.de   | IRC: hir...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Need help for Gimp 2.7.1

[drago01]

On Sat, Jul 3, 2010 at 11:28 PM, Luya Tshimbalanga
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/07/10 03:25 AM, Mamoru Tasaka wrote:
>> Luya Tshimbalanga wrote, at 07/03/2010 07:10 PM +9:00:
>>> Hello,
>>>
>>> I attempted to build a new version of Gimp 2.7.1 using Koji scratch
> method but
>>> ended up with that result[1]. Here is attached spec file borrowed from
> Nils as I
>>> wanted to experiment that version along with Design. Can anyone check
> what went
>>> wrong.
>>>
>>> Thanks
>>>
>>>
>>> [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=2291828
>>>
>>
>> build.log says:
>> -
>> extracting debug info from
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpbase-2.0.so.0.701.0
>> extracting debug info from
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpcolor-2.0.so.0.701.0
>> extracting debug info from
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpmath-2.0.so.0.701.0
>> extracting debug info from
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpconfig-2.0.so.0.701.0
>> extracting debug info from
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpmodule-2.0.so.0.701.0
>> extracting debug info from
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpthumb-2.0.so.0.701.0
>> extracting debug info from
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpwidgets-2.0.so.0.701.0
>> extracting debug info from
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimp-2.0.so.0.701.0
>> extracting debug info from
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpui-2.0.so.0.701.0
>> --
>>
>> So it seems that %minorver macro needs changing.
>>
>> Regards,
>> Mamoru
>
> What does %minorver macro do? Looking at the spec file, it stated 600.

Bump it to 701 (should fix your issue).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Need help for Gimp 2.7.1

[Luya Tshimbalanga]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/10 03:25 AM, Mamoru Tasaka wrote:
> Luya Tshimbalanga wrote, at 07/03/2010 07:10 PM +9:00:
>> Hello,
>>
>> I attempted to build a new version of Gimp 2.7.1 using Koji scratch
method but
>> ended up with that result[1]. Here is attached spec file borrowed from
Nils as I
>> wanted to experiment that version along with Design. Can anyone check
what went
>> wrong.
>>
>> Thanks
>>
>>
>> [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=2291828
>>
>
> build.log says:
> -
> extracting debug info from
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpbase-2.0.so.0.701.0
> extracting debug info from
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpcolor-2.0.so.0.701.0
> extracting debug info from
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpmath-2.0.so.0.701.0
> extracting debug info from
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpconfig-2.0.so.0.701.0
> extracting debug info from
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpmodule-2.0.so.0.701.0
> extracting debug info from
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpthumb-2.0.so.0.701.0
> extracting debug info from
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpwidgets-2.0.so.0.701.0
> extracting debug info from
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimp-2.0.so.0.701.0
> extracting debug info from
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpui-2.0.so.0.701.0
> --
>
> So it seems that %minorver macro needs changing.
>
> Regards,
> Mamoru

What does %minorver macro do? Looking at the spec file, it stated 600.

- -- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.thefinalzone.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iQEcBAEBAgAGBQJML6tzAAoJEGZ+gIukWeEeHXoIAI7pfY7YMNSAQdgf8skclIZt
GBLdsVv5UhNNXCYhdG8rF/zqN1JkI/7aUY6Z5y76a0wGt/PUcQxxa6IPXCUIk9Z2
im83557kuO0S2hSamXN8Z88yw0m/gnGL2PrWqE6uyw7moJWcWoaxPlSRYGwuaJm0
uQpgk278SOnUjv4nV/hVBQ0mDd/jAEOIEhcYI8ub1xrf72i4CZqkUdkXjeRoOB9Z
SgjfG01wahyroladqUAuIrYjsyiZrz5/uGT4QJ8Gy+kxjAkc2Z8Pufg4egTOCMMP
BZWIL/OhhLl0dnZvRzi3OStJANvmN1ob+73eK9ldKFovBVVbO3qx4K+HvTskGg4=
=vwhu
-END PGP SIGNATURE-

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

Re: Need help for Gimp 2.7.1

[Luya Tshimbalanga]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/10 04:13 AM, Muayyad AlSadi wrote:
>> error: File not found:
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/li
> b64/libgimp-2.0.so.0.600.1
>
> is version hard-coded in spec %files

You can view at the spec file I attached on the original post. It is
first time I noticed that minorver macro.

- -- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.thefinalzone.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iQEcBAEBAgAGBQJML6rYAAoJEGZ+gIukWeEe7RsIAM7KikEsqbH7zc6q5Bc1eTH+
Xk0s5uO/6VOllXw917P9EXCcUx5BLo4SMunDFI3p7/7bG5u4RxqqHCQO3EydyyvP
ER0nNHOcsC6elbUYzuoYgupjuGT4LfG0m77CBtUZnIXlTr0mChPYFdTjxs1pqLxR
Pr6BEbBa+pS7dqWTwR1KyXz97BoUeylN2o4D2FtHKm37HEUW+OJgeKvsPeX79rhK
uP/lYirPesbJhGKRgdWAmwYdNKeCnxCCbWbYqDc5RAWlglb7ogqAdwGCMpWefN0Q
hT13GagAh5C3AgSypFTEk8EyUXsL/0E9H4EyKHenf1I36lUY7LqUgu1R3+q7OGw=
=2RGl
-END PGP SIGNATURE-

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

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

[Adam Williamson]

On Sat, 2010-07-03 at 20:40 +0200, Michael Schwendt wrote:
 
> > That only handles a subset of the 'broken dependencies' problem. We've
> > already had an example this year of a dependency issue the proposed
> > autoqa depcheck test wouldn't catch, and Michael's script didn't - the
> > nss-softokn update 
> 
> Which one was that?
> https://bugzilla.redhat.com/596840 ?

Yep.

> > (as the broken dep is only apparent if you take into
> > consideration multilib issues and which repositories will have which
> > updated packages available).
> 
> There are multiple problems:
> 
> * Upgrades from F12 to F13. The depcheck for F13 would need to enable F12
> repos _always_ - to catch upgrade path violations that lead to dependency
> problems. I only do this a few times shortly before the release of FN+1
> (=F13).
> 
> * Yum depsolving behaviour on systems where multiarch packages are
> installed and an update isn't multiarch anymore. For example, where Yum on
> x86_64 would pull in lots of i686 packages to resolve dependencies, that
> would be considered a problem by the user but not by a depchecker, because
> there are no unresolvable dependencies to detect. Unless you teach the
> depsolver (and depchecker) that cross-arch dependencies are something
> to report as a problem. That would be more than "repository closure".
> The depchecker doesn't look for file conflicts either. There could be a
> dependency chain, which doesn't suffer from unresolvable deps but from
> implicit file conflicts.

Yep, indeed. I'm really not criticising the script. I'm just pointing
out that we know there are some pretty complex scenarios out there which
we haven't yet figured out how to test in an automated way; I'm
challenging the assumption that we can write a perfect depcheck test
which will ensure there is never a dependency issue ever again.
-- 
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

I claimed qgis

[Bruno Wolff III]

I was looking at qgis for doing roleplaying maps (I am not sure if that
will work out) and noticed it was way behind upstream and then when filing
a bug, noticed that it was orphaned.
I am going to try to get it updated to 1.4 and see how things go. If it
works out for roleplaying, I'll be a long term maintainer, if not I might
orphan it again.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Michael Schwendt]

On Sat, 03 Jul 2010 10:05:07 -0700, Adam wrote:

> On Fri, 2010-07-02 at 18:24 +0200, Ralf Corsepius wrote:
> > On 07/02/2010 06:20 PM, Will Woods wrote:
> > 
> > 
> > > The main reasons we want to perform testing are things like: to avoid
> > > pushing updates with broken dependencies, or updates that cause serious
> > > regressions requiring manual intervention / emergency update
> > > replacements. That sort of thing.
> > >
> > Should be done scripted as part of the "package push process".
> > No need for karmas, no need for "provenpackager"
> 
> That only handles a subset of the 'broken dependencies' problem. We've
> already had an example this year of a dependency issue the proposed
> autoqa depcheck test wouldn't catch, and Michael's script didn't - the
> nss-softokn update 

Which one was that?
https://bugzilla.redhat.com/596840 ?

> (as the broken dep is only apparent if you take into
> consideration multilib issues and which repositories will have which
> updated packages available).

There are multiple problems:

* Upgrades from F12 to F13. The depcheck for F13 would need to enable F12
repos _always_ - to catch upgrade path violations that lead to dependency
problems. I only do this a few times shortly before the release of FN+1
(=F13).

* Yum depsolving behaviour on systems where multiarch packages are
installed and an update isn't multiarch anymore. For example, where Yum on
x86_64 would pull in lots of i686 packages to resolve dependencies, that
would be considered a problem by the user but not by a depchecker, because
there are no unresolvable dependencies to detect. Unless you teach the
depsolver (and depchecker) that cross-arch dependencies are something
to report as a problem. That would be more than "repository closure".
The depchecker doesn't look for file conflicts either. There could be a
dependency chain, which doesn't suffer from unresolvable deps but from
implicit file conflicts.
-- 
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

[Mamoru Tasaka]

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?

Regards,
Mamoru

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

Re: Bodhi 0.7.5 release

[Till Maas]

On Wed, Jun 30, 2010 at 12:50:53PM -0700, Adam Williamson wrote:
> On Wed, 2010-06-30 at 15:37 -0400, Stephen Gallagher wrote:
> 
> > A suggestion: when critical path updates hit updates-testing, a
> > notification should go to both devel@lists.fedoraproject.org and
> > q...@lists.fedoraproject.org to encourage testing.
> 
> This would probably be too high traffic. We're working on making sure
> there's easy processes for the proventesters to identify and quickly
> provide feedback on critpath updates. fedora-easy-karma will soon sprout
> options to list only critpath updates, or only critpath updates which do
> not yet have sufficient feedback; I'm talking to Till about this now.

If anyone wants to use this feature, download
http://fedorapeople.org/gitweb?p=till/public_git/fedora-easy-karma.git;a=blob_plain;f=fedora-easy-karma.py;hb=561718c892ddaf8e094194044f5666cb05e03530
and add --critpath-only to the commandline.

Regards
Till


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

Re: concept of package "ownership"

[Kevin Kofler]

Michael Schwendt wrote:
> How would you find out whether that's the case? - You would need to talk
> to the package maintainer(s). Having arbitrary provenpackagers perform
> random upgrades won't do it.

We need to get packagers to document the reason why they're not upgrading 
some package in a standard place. That'll also save them repetitive "Why is 
XYZ not up to date?" questions.

Kevin Kofler

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

Re: Bodhi 0.7.5 release

[Till Maas]

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

Regards
Till


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

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

[Adam Williamson]

On Fri, 2010-07-02 at 18:24 +0200, Ralf Corsepius wrote:
> On 07/02/2010 06:20 PM, Will Woods wrote:
> 
> 
> > The main reasons we want to perform testing are things like: to avoid
> > pushing updates with broken dependencies, or updates that cause serious
> > regressions requiring manual intervention / emergency update
> > replacements. That sort of thing.
> >
> Should be done scripted as part of the "package push process".
> No need for karmas, no need for "provenpackager"

That only handles a subset of the 'broken dependencies' problem. We've
already had an example this year of a dependency issue the proposed
autoqa depcheck test wouldn't catch, and Michael's script didn't - the
nss-softokn update (as the broken dep is only apparent if you take into
consideration multilib issues and which repositories will have which
updated packages available).

Given Murphy's Law, I am willing to bet that, even when we have an
automated dependency checker in place, someone will manage to push an
update which causes a dependency problem which the automated test
doesn't catch. Manual testing will help us catch that.

And, again, though Will mentioned two types of broken update, you only
considered one in your reply.

> Doesn't Michael Schwendt have a script for this?

Yes. Is a script all you need to implement an automated step in the
updaate push process? No.
-- 
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: Building under mock (rawhide)

[Dennis Gilmore]

On Saturday, July 03, 2010 08:14:57 am Paul wrote:
> Hi,
> 
> I'm trying to build under mock currently but am getting the following
> throwback (both as su and as me)
> 
> ERROR: Exception(rpmbuild/SRPMS/VirtualBox-OSE-3.2.6-1.src.rpm)
> Config(fedora-rawhide-x86_64) 0 minutes 36 seconds
> INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
> ERROR: Command failed:
>  # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/
> groupinstall buildsys-build
> Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
>Requires: rpm >= 4.6.0
> Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
>Requires: /bin/bash
> Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
>Requires: /bin/sh
> Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
>Requires: perl(Getopt::Long)
> Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
>Requires: mktemp
> Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
>Requires: /usr/bin/perl
> 
> [p...@pb3 ~]$ rpm -qa rpm
> rpm-4.8.1-2.fc14.i686
> 
> [p...@pb3 ~]$ perl --version
> 
> This is perl 5, version 12, subversion 1 (v5.12.1) built for
> i386-linux-thread-multi
> 
> Is this something that needs to be put into BZ or is it known about and
> easy to fix?
> 
> TTFN
> 
> Paul
yo cant build 64 bit binaries on a 32 bit box.  you will need either a 64 bit 
box or to setup a qemu guest thats 64 bit.  not the qemu route will be slow as 
the cpu will be fully emulated

The error you get is because the host rpm has excluded the 
unistallable/runable 64 bit binarries so you end up with only installable 
noarch packages

Dennis


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: concept of package "ownership"

[Thomas Janssen]

On Sat, Jul 3, 2010 at 3:28 PM, Kevin Kofler  wrote:
> Thomas Janssen wrote:
>> I'm sorry, i can't agree with you here. Being more aggressive, putting
>> pressure on whatever just to have the latest versions of all the
>> software around in rawhide, sounds to me like we would go and break
>> rawhide a lot.
>> 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.

I'm with Fedora because we have the latest and greatest. Though
blindly, aggressively bomb in the latest releases if they're
compatible or not is the wrong way. Doing that breaks even koji from
time to time (thanks for our real quick rel-eng helping out there).
BTW is there a big difference between being a stable Debian or doing
the latest and greatest updates the smart way. I know that you know
that as well.
Just recall from time to time that putting too much pressure and being
too aggressive is often counter productive.
I generally trust in our maintainers that they know what they do. So
if they hold an update back will be for something good. We have
processes for everything else.

-- 
LG Thomas

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

Re: concept of package "ownership"

[Michael Schwendt]

On Sat, 03 Jul 2010 15:33 +0200, Kevin wrote:

> Rawhide should always have the latest upstream release unless there's a 
> strong reason why a particular release needs to be skipped (i.e. it's 
> broken, it contains illegal stuff or something like that).

How would you find out whether that's the case? - You would need to talk
to the package maintainer(s). Having arbitrary provenpackagers perform
random upgrades won't do it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Seeking co-maintainers: monit

[Stewart Adam]

Great! Just apply for access in PackageDB and I'll grant you access.

https://admin.fedoraproject.org/pkgdb/acls/name/monit

Cheers,
Stewart

On 2010/07/03 3:32 AM, Maxim Burgerhout wrote:
> Hi,
>
> I use it on a couple of servers, and I wouldn't mind co-maintaining  it with
> you.
>
> Regards,
>
> Maxim Burgerhout (wz...@fedoraproject.org )
>
>> On 2010-07-02 7:55 PM, "Stewart Adam" > > wrote:
>>
>>  Hi,
>>
>> I packaged monit a while ago but never really got around to using it as I
>> found Nagios to be more suitable for my needs... I do not mind continuing to
>> package Monit, but seeing as I rarely use it myself it would be great if
>> someone who does would like to co-maintain it and help troubleshoot any
>> bugs, etc.
>>
>> Thanks,
>> Stewart
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org 
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>

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

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

[Kevin Kofler]

Adam Miller wrote:
> If there are any discrepancy with the proventesters critpath policy then
> please feel free to file a ticket with FESCo and allow our elected
> officials decide the fate of this.

There isn't any such discrepancy, it's the policy which is broken and FESCo 
which refuses to understand the issues.

Kevin Kofler

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

Re: concept of package "ownership"

[Kevin Kofler]

Michael Schwendt wrote:
> Ridiculous. :( The way you've phrased it doesn't meet the "be excellent"
> guidelines IMO. There is nothing "completely unacceptable" or "against
> Fedora's objectives" with skipping certain upstream releases. And I hope
> that nobody will become "more aggressive" or try to force me (or other
> packagers) to upgrade packages. I don't want anyone among the Fedora
> contributors to be "aggressive" in any way when talking to me or when
> trying to make me do something.

I didn't mean to say that we should be aggressive towards some person, just 
that we should "aggressively", i.e. proactively, quickly, routinely, 
systematically, frequently etc., update packages to new upstream versions 
because that's part of the Fedora Objectives.

Rawhide should always have the latest upstream release unless there's a 
strong reason why a particular release needs to be skipped (i.e. it's 
broken, it contains illegal stuff or something like that).

Kevin Kofler

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

Re: Multi-owned perl directories in perl package in F-13

[Ralf Corsepius]

On 07/03/2010 10:16 AM, Iain Arnell wrote:
> On Sat, Jul 3, 2010 at 10:06 AM, Remi Collet  wrote:
>> Le 03/07/2010 10:02, Iain Arnell a écrit :
>>
 How this should be handled nicely ?
>>>
>>> Exactly as it is at the minute - continue allow perl modules to share
>>> directory ownership.
>>>
>>> I think the "Multiple packages own files in a common directory but
>>> none of them needs to require the others."[1] rule would cover it. In
>>> general, module A::B::C doesn't necessarily require A::B (or even A).
>>
>> Of course, I was asking in the case A::B::C requires A::B
>>
>> In the case of the package I'm working on the review:
>>   perl-Test-Script-Run requires perl-Test-Exception
>>   which own /usr/share/perl5/Test dir.
>
> Well the perl rpm itself owns /usr/share/perl5/Test, so then no
> perl-Test-* module should own it.
Even in this case, all perl-modules installing something below */Test 
should own */Test, because "Test" modules (even those now in perl) may 
move between modules in future.

Ralf
--
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"

[Kevin Kofler]

Thomas Janssen wrote:
> I'm sorry, i can't agree with you here. Being more aggressive, putting
> pressure on whatever just to have the latest versions of all the
> software around in rawhide, sounds to me like we would go and break
> rawhide a lot.
> 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.

Kevin Kofler

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

Building under mock (rawhide)

[Paul]

Hi,

I'm trying to build under mock currently but am getting the following
throwback (both as su and as me)

ERROR: Exception(rpmbuild/SRPMS/VirtualBox-OSE-3.2.6-1.src.rpm)
Config(fedora-rawhide-x86_64) 0 minutes 36 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
ERROR: Command failed: 
 # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/
groupinstall buildsys-build
Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
   Requires: rpm >= 4.6.0
Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
   Requires: /bin/bash
Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
   Requires: /bin/sh
Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
   Requires: perl(Getopt::Long)
Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
   Requires: mktemp
Error: Package: redhat-rpm-config-9.1.0-5.fc14.noarch (fedora)
   Requires: /usr/bin/perl

[p...@pb3 ~]$ rpm -qa rpm
rpm-4.8.1-2.fc14.i686

[p...@pb3 ~]$ perl --version

This is perl 5, version 12, subversion 1 (v5.12.1) built for
i386-linux-thread-multi

Is this something that needs to be put into BZ or is it known about and
easy to fix?

TTFN

Paul
-- 
Biggles was quietly reading his favourite book when Algy burst through
the door. Distracted for a moment, Biggles surveyed what had happened
and turned a page. "Algy old man" he said, clearing his throat, "use the
handle next time..." - Taken from "Biggles combs his Hair"


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: webkitgtk abi bump

[Ben Boeckel]

Matthias Clasen  wrote:
> uzbl-core

Rebuilt.

--Ben

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

rawhide report: 20100703 changes

[Rawhide Report]

Compose started at Sat Jul  3 08:15:05 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
awn-extras-applets-0.4.0-17.fc14.i686 requires libwebkit-1.0.so.2
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
empathy-2.31.3-2.fc14.i686 requires libwebkit-1.0.so.2
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
2:gimp-help-browser-2.6.9-4.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
1:gnumeric-plugins-extras-1.10.0-1.fc14.i686 requires 
perl(:MODULE_COMPAT_5.10.1)
gstreamer-plugins-bad-free-0.10.19-4.fc14.i686 requires libcelt.so.0
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
libproxy-webkit-0.4.0-1.fc14.i686 requires libwebkit-1.0.so.2
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
mrpt-apps-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-apps-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-apps-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-apps-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-apps-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-base-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-base-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-base-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-base-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-base-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-gui-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-gui-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-gui-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-gui-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-gui-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-maps-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-maps-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-maps-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-maps-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-maps-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-obs-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-obs-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-obs-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-obs-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-obs-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-opengl-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-opengl-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-opengl-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-opengl-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-opengl-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-slam-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-slam-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-slam-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-slam-0.9.0-0.

Re: concept of package "ownership"

[Rahul Sundaram]

 On 07/03/2010 04:05 PM, Till Maas wrote:
> Most of the packages listed here are not up to date:
> https://bugzilla.redhat.com/buglist.cgi?emailreporter1=1&emailtype1=exact&query_format=advanced&bug_status=ASSIGNED&email1=upstream-release-monitoring%40fedoraproject.org&product=Fedora

Yeah but this is a partial view only since very few of the package
maintainers sign up for upstream monitoring.  I forget to do it for new
packages myself.  If we were monitoring ALL upstreams for packages in
Fedora and creating a web page to note differences like the DEHS, we
would understand how far we are behind in a glance.

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

Broken dependencies: perl-DBI-Dumper

[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

[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

Broken dependencies: perl-Data-Alias

[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

rpms/perl-Class-MOP/devel .cvsignore, 1.39, 1.40 perl-Class-MOP.spec, 1.52, 1.53 sources, 1.37, 1.38

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Class-MOP/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv14734

Modified Files:
.cvsignore perl-Class-MOP.spec sources 
Log Message:
* Sat Jul 03 2010 Iain Arnell  1.03-1
- update to latest upstream
- re-enable tests
- BR Test::LeakTrace and Test::Output to enable more tests



Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Class-MOP/devel/.cvsignore,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -p -r1.39 -r1.40
--- .cvsignore  7 May 2010 10:50:51 -   1.39
+++ .cvsignore  3 Jul 2010 11:58:37 -   1.40
@@ -1 +1 @@
-Class-MOP-1.01.tar.gz
+Class-MOP-1.03.tar.gz


Index: perl-Class-MOP.spec
===
RCS file: /cvs/pkgs/rpms/perl-Class-MOP/devel/perl-Class-MOP.spec,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -p -r1.52 -r1.53
--- perl-Class-MOP.spec 16 May 2010 04:49:45 -  1.52
+++ perl-Class-MOP.spec 3 Jul 2010 11:58:37 -   1.53
@@ -1,6 +1,6 @@
 Name:   perl-Class-MOP
-Version:1.01
-Release:2%{?dist}
+Version:1.03
+Release:1%{?dist}
 Summary:A Meta Object Protocol for Perl 5
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -16,14 +16,18 @@ BuildRequires:  perl(Class::C3)
 BuildRequires:  perl(Devel::GlobalDestruction)
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.42
 BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(List::MoreUtils) >= 0.12
 BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(MRO::Compat) >= 0.05
+BuildRequires:  perl(Package::Stash)
 BuildRequires:  perl(Scalar::Util) >= 1.18
 BuildRequires:  perl(Sub::Name) >= 0.04
 BuildRequires:  perl(SUPER)
 BuildRequires:  perl(Task::Weaken)
 BuildRequires:  perl(Test::Exception) >= 0.27
+BuildRequires:  perl(Test::LeakTrace)
 BuildRequires:  perl(Test::More) >= 0.88
+BuildRequires:  perl(Test::Output)
 BuildRequires:  perl(Test::Pod)
 BuildRequires:  perl(Test::Pod::Coverage)
 BuildRequires:  perl(Try::Tiny) >= 0.02
@@ -73,8 +77,7 @@ find %{buildroot} -depth -type d -exec r
 %{_fixperms} %{buildroot}/*
 
 %check
-# switch off until Class::ISA will be in buildroot
-#make test
+make test
 
 %clean
 rm -rf %{buildroot}
@@ -87,6 +90,11 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*
 
 %changelog
+* Sat Jul 03 2010 Iain Arnell  1.03-1
+- update to latest upstream
+- re-enable tests
+- BR Test::LeakTrace and Test::Output to enable more tests
+
 * Sat May 15 2010 Chris Weyl  1.01-2
 - update our -tests (should all pass when installed now)
 - fix source0 link


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Class-MOP/devel/sources,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -p -r1.37 -r1.38
--- sources 7 May 2010 10:50:51 -   1.37
+++ sources 3 Jul 2010 11:58:37 -   1.38
@@ -1 +1 @@
-52002e8b9f1e3c14346e065a9e478136  Class-MOP-1.01.tar.gz
+96b44730ae040c30d5e8e85b48e8cbe7  Class-MOP-1.03.tar.gz

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

File Class-MOP-1.03.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

A file has been added to the lookaside cache for perl-Class-MOP:

96b44730ae040c30d5e8e85b48e8cbe7  Class-MOP-1.03.tar.gz
--
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: measuring success

[Till Maas]

On Sat, Jul 03, 2010 at 01:03:41PM +0200, Michael Schwendt wrote:
> On Sat, 03 Jul 2010 12:50:15 +0200, Till wrote:

> > Also Bodhi does not allow to [...]
> 
> Bodhi ought to meet the package maintainers' requirements, not vice versa.
> If you determine a problem with the typical work-flow, how about talking
> to the bodhi developer and/or the people who decide on the release policies.

Btw. this was not meant as Bodhi-bashing but as an explanation why these
kind of ways to break the deps unintended are likely to happen.

Regards
Till


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

Re: measuring success

[Till Maas]

On Sat, Jul 03, 2010 at 01:03:41PM +0200, Michael Schwendt wrote:
> On Sat, 03 Jul 2010 12:50:15 +0200, Till wrote:
> 
> > This is not true, because there can be runtime dependencies on another
> > update in -testing that is not build dependency, e.g. if an python app
> > requires a newer version of a python module.
> 
> 1) To make such run-time deps BuildRequires would be helpful (because it
> doesn't make much sense to build something for a target that is missing
> something). Several broken deps in old dist branches have been because
> of a discrepancy between Requires and BuildRequires.

If this should be normal, then IMHO rpmbuild should be changed to
use all explicit Requires also as BuildRequires.

> 2) You don't need to push your python app before the python module.


> > Just requiring proper communication will lead to failure, because e.g.
> > new maintainers might not know some of these problems and autokarma
> > pushes one of the dependent updates to stable but not the other. And
> > this already happened with a highly used package.
> 
> Then don't rush. If you are aware of a strict dependency, you either need
> to communicate or wait for the require piece to be pushed first.

Yes, but this is something that might happen, which is what mistakes
are and testing is there to prevent.

> > Also Bodhi does not allow to [...]
> 
> Bodhi ought to meet the package maintainers' requirements, not vice versa.
> If you determine a problem with the typical work-flow, how about talking
> to the bodhi developer and/or the people who decide on the release policies.

Except that Bodhi never met this requirement and development is too slow
to catch up here. And there seems also be a lack of effort to test
changes to Bodhi before they go stable, which is somehow ironic since
the changes made to Bodhi are there intended to ensure better package
quality but not better Bodhi quality. Btw. the autokarma issue is
already reported in Bodhi:
https://fedorahosted.org/bodhi/ticket/396
And a broken deps detection ticket exists for 3 years:
https://fedorahosted.org/bodhi/ticket/79

Regards
Till


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

Re: Need help for Gimp 2.7.1

[Muayyad AlSadi]

> error: File not found: 
> /builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/li
b64/libgimp-2.0.so.0.600.1

is version hard-coded in spec %files
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: measuring success

[Michael Schwendt]

On Sat, 03 Jul 2010 12:50:15 +0200, Till wrote:

> This is not true, because there can be runtime dependencies on another
> update in -testing that is not build dependency, e.g. if an python app
> requires a newer version of a python module.

1) To make such run-time deps BuildRequires would be helpful (because it
doesn't make much sense to build something for a target that is missing
something). Several broken deps in old dist branches have been because
of a discrepancy between Requires and BuildRequires.

2) You don't need to push your python app before the python module.
It would be good to test the python module first, give feedback in bodhi,
and then you also receive the notification when it's pushed to
stable. Then you can push the app. IOW, wait for the new python module
version to be released.

> Just requiring proper communication will lead to failure, because e.g.
> new maintainers might not know some of these problems and autokarma
> pushes one of the dependent updates to stable but not the other. And
> this already happened with a highly used package.

Then don't rush. If you are aware of a strict dependency, you either need
to communicate or wait for the require piece to be pushed first.

> Also Bodhi does not allow to [...]

Bodhi ought to meet the package maintainers' requirements, not vice versa.
If you determine a problem with the typical work-flow, how about talking
to the bodhi developer and/or the people who decide on the release policies.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: measuring success

[Till Maas]

On Sat, Jul 03, 2010 at 12:27:50PM +0200, Michael Schwendt wrote:
> On Fri, 02 Jul 2010 20:12:26 +0200, Till wrote:
> 
> > Btw. on a related issue:How do provenpackagers properly test for broken
> > deps manually?
> 
> Every packager can [configure and] run repoclosure from yum-utils.
> Enable updates-testing, and optionally add a local repo for your own
> candidate builds. It should work with the default Yum configuration.
> 
> > The case where two updates in updates-testing are
> > required to update one of them seems to me hard to ensure manually. But
> > when only one of both updates is pushed to stable, there will be a
> > broken dependency. I know that the fix is to bundle the builds of both
> > updates into one, but how is this tested?
> 
> (I don't understand the question.)  Ordinary test-updates cannot break
> other test-updates unless a koji buildroot override is involved.
> For updates without a koji buildroot override, only when an incompatible
> test-update is pushed to stable, it breaks dependencies of released
> packages outside updates-testing and also becomes available in the koji
> buildroot.

This is not true, because there can be runtime dependencies on another
update in -testing that is not build dependency, e.g. if an python app
requires a newer version of a python module.

> So, you don't have anything like "only one of both updates is pushed to
> stable", because with a proper announcement of an incompatible update
> *and* communication about a koji buildroot override, all needed rebuilds
> should be known.  Whether you let one packager put them all into the same
> bodhi ticket or have one packager push multiple tickets at once, is a
> process/documentation issue.  There is no need to create bodhi tickets
> before all rebuilds are available, btw.

Just requiring proper communication will lead to failure, because e.g.
new maintainers might not know some of these problems and autokarma
pushes one of the dependent updates to stable but not the other. And
this already happened with a highly used package.

Also Bodhi does not allow to fix updates by other people than the update
submitter afaik. Also it is not possible to e.g. add my new package to
some other update to ensure atomicity. E.g. when I wrote
fedora-easy-karma, it needed a version of python-fedora that was only in
updates-testing. But there was no easy way for me to ensure in Bodhi
that f-e-k will only be pushed to stable after the python-fedora update.
The only supported way other than ensuring it manually is to ask the
python-fedora update submitter to include the f-e-k build. But then all
changes wrt to the f-e-k build need to be proxied through the
python-fedora submitter, which just means double work. And it also means
that for the manually method I need to ensure that autokarma is off, but
it also tries to re-activate itself with every update edit.

Regards
Till


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

Re: concept of package "ownership"

[Michael Schwendt]

On Sat, 3 Jul 2010 18:08:03 +0800, Chen wrote:

> I'm fully agree with you, but there are some maintainers who don't
> respond on bugzilla at all or for a very long time. They may be still
> active on koji, but they don't respond even when you attach a
> patch/spec to solve known issues or request for co-maintainership.
> Obviously, they cannot be defined as nonresponsive package
> maintainers, so we have no process/policy to treat those packages.

Not responding => non-responsive.

For non-upgrade patches, the provenpackagers' guidelines make it
possible to apply those fixes if the maintainer doesn't do that. The
maintainer _should_ see the commit, and you are even permitted to
submit a build request after a few days.

It just doesn't work, if some maintainers hate Fedora bugzilla or private
email and prefer IRC. Or if others don't seem to see cvs commit notifications
or pkgdb requests.

> I filled dozens of reports in bugzilla to request for updating long
> unmaintained packages(more than 3 years) several months ago, no
> packager respond yet.

IMO you've waited too long to see a response from those people. You
could have started the non-responsive maintainer procedure much sooner.
And if it results in a quick reply and NOTABUG/WONTFIX closing of your
tickets, contact FESCo and ask for a mediator.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: concept of package "ownership"

[Till Maas]

On Fri, Jul 02, 2010 at 07:43:26PM +0530, Rahul Sundaram wrote:
>  On 07/02/2010 07:37 PM, Patrice Dumas wrote:
> > Ok, this policy was for the other case, a case when the maintainer
> > does not respond. I am not saying that it happens a lot, but it
> > happened in the past, and the syslog-ng case exposed in the thread is
> > another recent case. Maybe a policy is not needed and a case by 
> > case handling by escalation to FESCo is enough, though. In my
> > days as a Fedora contributor, however, this issue was annoying
> > enough that I proposed the policy, maybe things have changed
> > now.
> 
> A global view of package versions in rawhide vs the latest upstream
> similar to http://wiki.debian.org/DEHS would be useful to know how we
> stand.  Rakesh Pandit was looking into this earlier.  Not sure of the
> status on that now. 

Most of the packages listed here are not up to date:
https://bugzilla.redhat.com/buglist.cgi?emailreporter1=1&emailtype1=exact&query_format=advanced&bug_status=ASSIGNED&email1=upstream-release-monitoring%40fedoraproject.org&product=Fedora

Regards
Till


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

rpms/perl-Statistics-Descriptive/F-13 .cvsignore, 1.2, 1.3 perl-Statistics-Descriptive.spec, 1.8, 1.9 sources, 1.2, 1.3

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Statistics-Descriptive/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv7976

Modified Files:
.cvsignore perl-Statistics-Descriptive.spec sources 
Log Message:
* Sat Jul 03 2010 Iain Arnell  3.0200-1
- update to latest upstream version.



Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Statistics-Descriptive/F-13/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore  15 Jul 2006 09:27:23 -  1.2
+++ .cvsignore  3 Jul 2010 10:29:41 -   1.3
@@ -1 +1 @@
-Statistics-Descriptive-2.6.tar.gz
+Statistics-Descriptive-3.0200.tar.gz


Index: perl-Statistics-Descriptive.spec
===
RCS file: 
/cvs/pkgs/rpms/perl-Statistics-Descriptive/F-13/perl-Statistics-Descriptive.spec,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- perl-Statistics-Descriptive.spec7 Dec 2009 02:45:28 -   1.8
+++ perl-Statistics-Descriptive.spec3 Jul 2010 10:29:41 -   1.9
@@ -1,60 +1,58 @@
 Name:   perl-Statistics-Descriptive
-Version:2.6
-Release:6%{?dist}
+Version:3.0200
+Release:1%{?dist}
 Summary:Perl module of basic descriptive statistical functions
-
-Group:  Development/Libraries
 License:GPL+ or Artistic
+Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Statistics-Descriptive/
-Source0:
http://www.cpan.org/authors/id/C/CO/COLINK/Statistics-Descriptive-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/S/SH/SHLOMIF/Statistics-Descriptive-%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
 BuildArch:  noarch
-BuildRequires:  perl(ExtUtils::MakeMaker)
-Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
+BuildRequires:  perl(Module::Build)
+BuildRequires:  perl(Test::More)
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
-%description
-This module provides basic functions used in descriptive
-statistics. It has an object oriented design and supports two
-different types of data storage and calculation objects: sparse and
-full. With the sparse method, none of the data is stored and only a
-few statistical measures are available. Using the full method, the
-entire data set is retained and additional functions are available.
+%{?perl_default_filter}
 
+%description
+This module provides basic functions used in descriptive statistics. It has
+an object oriented design and supports two different types of data storage
+and calculation objects: sparse and full. With the sparse method, none of
+the data is stored and only a few statistical measures are available. Using
+the full method, the entire data set is retained and additional functions
+are available.
 
 %prep
 %setup -q -n Statistics-Descriptive-%{version}
 
-
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
-
+%{__perl} Build.PL installdirs=vendor
+./Build
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
 
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 
-%check
-make test
+%{_fixperms} $RPM_BUILD_ROOT/*
 
+%check
+./Build test
 
 %clean
 rm -rf $RPM_BUILD_ROOT
 
-
 %files
 %defattr(-,root,root,-)
-%doc Changes README UserSurvey.txt
-%{perl_vendorlib}/Statistics/
-%{_mandir}/man3/Statistics::Descriptive.3*
-
+%doc Changes examples README UserSurvey.txt
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
 
 %changelog
+* Sat Jul 03 2010 Iain Arnell  3.0200-1
+- update to latest upstream version.
+
 * Mon Dec  7 2009 Stepan Kasal  - 2.6-6
 - rebuild against perl 5.10.1
 


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Statistics-Descriptive/F-13/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 15 Jul 2006 09:27:24 -  1.2
+++ sources 3 Jul 2010 10:29:41 -   1.3
@@ -1 +1 @@
-05602b7028ada0393b503acee79d2616  Statistics-Descriptive-2.6.tar.gz
+918f06cf7419d28c122b7222eaf10302  Statistics-Descriptive-3.0200.tar.gz

--
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: measuring success

[Michael Schwendt]

On Fri, 02 Jul 2010 20:12:26 +0200, Till wrote:

> Btw. on a related issue:How do provenpackagers properly test for broken
> deps manually?

Every packager can [configure and] run repoclosure from yum-utils.
Enable updates-testing, and optionally add a local repo for your own
candidate builds. It should work with the default Yum configuration.

> The case where two updates in updates-testing are
> required to update one of them seems to me hard to ensure manually. But
> when only one of both updates is pushed to stable, there will be a
> broken dependency. I know that the fix is to bundle the builds of both
> updates into one, but how is this tested?

(I don't understand the question.)  Ordinary test-updates cannot break
other test-updates unless a koji buildroot override is involved.
For updates without a koji buildroot override, only when an incompatible
test-update is pushed to stable, it breaks dependencies of released
packages outside updates-testing and also becomes available in the koji
buildroot.

So, you don't have anything like "only one of both updates is pushed to
stable", because with a proper announcement of an incompatible update
*and* communication about a koji buildroot override, all needed rebuilds
should be known.  Whether you let one packager put them all into the same
bodhi ticket or have one packager push multiple tickets at once, is a
process/documentation issue.  There is no need to create bodhi tickets
before all rebuilds are available, btw.

For any update that isn't tested by the packager for incompatibilities
with previous releases (e.g. using tools from the "rpmdevtools" package),
so far it's important to not skip updates-testing and give me at least 24
hours to run extras-repoclosure (with stable test-updates entering nirvana
until they become available in the updates repo, there is a window during
which some packages are missing). For any incompatible test-update, the
package dependencies it will break will be discovered.

[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".]
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rpms/perl-Statistics-Descriptive/EL-6 .cvsignore, 1.2, 1.3 perl-Statistics-Descriptive.spec, 1.7, 1.8 sources, 1.2, 1.3

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Statistics-Descriptive/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv7483

Modified Files:
.cvsignore perl-Statistics-Descriptive.spec sources 
Log Message:
* Sat Jul 03 2010 Iain Arnell  3.0200-1
- update to latest upstream version.



Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Statistics-Descriptive/EL-6/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore  15 Jul 2006 09:27:23 -  1.2
+++ .cvsignore  3 Jul 2010 10:27:36 -   1.3
@@ -1 +1 @@
-Statistics-Descriptive-2.6.tar.gz
+Statistics-Descriptive-3.0200.tar.gz


Index: perl-Statistics-Descriptive.spec
===
RCS file: 
/cvs/pkgs/rpms/perl-Statistics-Descriptive/EL-6/perl-Statistics-Descriptive.spec,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- perl-Statistics-Descriptive.spec26 Jul 2009 16:33:17 -  1.7
+++ perl-Statistics-Descriptive.spec3 Jul 2010 10:27:37 -   1.8
@@ -1,60 +1,58 @@
 Name:   perl-Statistics-Descriptive
-Version:2.6
-Release:5%{?dist}
+Version:3.0200
+Release:1%{?dist}
 Summary:Perl module of basic descriptive statistical functions
-
-Group:  Development/Libraries
 License:GPL+ or Artistic
+Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Statistics-Descriptive/
-Source0:
http://www.cpan.org/authors/id/C/CO/COLINK/Statistics-Descriptive-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/S/SH/SHLOMIF/Statistics-Descriptive-%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
 BuildArch:  noarch
-BuildRequires:  perl(ExtUtils::MakeMaker)
-Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
+BuildRequires:  perl(Module::Build)
+BuildRequires:  perl(Test::More)
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
-%description
-This module provides basic functions used in descriptive
-statistics. It has an object oriented design and supports two
-different types of data storage and calculation objects: sparse and
-full. With the sparse method, none of the data is stored and only a
-few statistical measures are available. Using the full method, the
-entire data set is retained and additional functions are available.
+%{?perl_default_filter}
 
+%description
+This module provides basic functions used in descriptive statistics. It has
+an object oriented design and supports two different types of data storage
+and calculation objects: sparse and full. With the sparse method, none of
+the data is stored and only a few statistical measures are available. Using
+the full method, the entire data set is retained and additional functions
+are available.
 
 %prep
 %setup -q -n Statistics-Descriptive-%{version}
 
-
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
-
+%{__perl} Build.PL installdirs=vendor
+./Build
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
 
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 
-%check
-make test
+%{_fixperms} $RPM_BUILD_ROOT/*
 
+%check
+./Build test
 
 %clean
 rm -rf $RPM_BUILD_ROOT
 
-
 %files
 %defattr(-,root,root,-)
-%doc Changes README UserSurvey.txt
-%{perl_vendorlib}/Statistics/
-%{_mandir}/man3/Statistics::Descriptive.3*
-
+%doc Changes examples README UserSurvey.txt
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
 
 %changelog
+* Sat Jul 03 2010 Iain Arnell  3.0200-1
+- update to latest upstream version.
+
 * Sun Jul 26 2009 Fedora Release Engineering  
- 2.6-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
 


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Statistics-Descriptive/EL-6/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 15 Jul 2006 09:27:24 -  1.2
+++ sources 3 Jul 2010 10:27:37 -   1.3
@@ -1 +1 @@
-05602b7028ada0393b503acee79d2616  Statistics-Descriptive-2.6.tar.gz
+918f06cf7419d28c122b7222eaf10302  Statistics-Descriptive-3.0200.tar.gz

--
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: Need help for Gimp 2.7.1

[Mamoru Tasaka]

Luya Tshimbalanga wrote, at 07/03/2010 07:10 PM +9:00:
> Hello,
>
> I attempted to build a new version of Gimp 2.7.1 using Koji scratch method but
> ended up with that result[1]. Here is attached spec file borrowed from Nils 
> as I
> wanted to experiment that version along with Design. Can anyone check what 
> went
> wrong.
>
> Thanks
>
>
> [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=2291828
>

build.log says:
-
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpbase-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpcolor-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpmath-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpconfig-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpmodule-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpthumb-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpwidgets-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimp-2.0.so.0.701.0
extracting debug info from 
/builddir/build/BUILDROOT/gimp-2.7.1-1.fc13.x86_64/usr/lib64/libgimpui-2.0.so.0.701.0
--

So it seems that %minorver macro needs changing.

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

Re: concept of package "ownership"

[Chen Lei]

2010/7/3 Michael Schwendt :
> On Sat, 03 Jul 2010 03:40:57 +0200, Kevin wrote:
>
>>
>> It is part of the Fedora Objectives:
>> https://fedoraproject.org/wiki/Objectives
>> to "be on the leading edge of free and open source technology". Given that,
>> it is completely unacceptable to not upgrade software to the current release
>> in Rawhide (within a reasonable timeframe, of course we're all not available
>> 24/7) unless there's a really good reason to (in which case that reason
>> ought to be given in the bug report asking for the upgrade!), especially
>> when upstream is asking for their software to be upgraded.
>>
>> So the maintainer's decision (assuming there even WAS a decision rather than
>> just lack of time or worse) goes against Fedora's Objectives and so it's not
>> OK to say that it should just get accepted.
>>
>> We should really be more aggressive about allowing to upgrade other people's
>> packages in Rawhide if the maintainers don't do it within a reasonable
>> timeframe and don't document any good reason not to do the upgrade.
>
> Ridiculous. :( The way you've phrased it doesn't meet the "be excellent"
> guidelines IMO. There is nothing "completely unacceptable" or "against
> Fedora's objectives" with skipping certain upstream releases. And I hope
> that nobody will become "more aggressive" or try to force me (or other
> packagers) to upgrade packages. I don't want anyone among the Fedora
> contributors to be "aggressive" in any way when talking to me or when
> trying to make me do something.
>
> As a user or fellow packager [or upstream developer], you are free to
> suggest upgrades in a bugzilla ticket. And hopefully you evaluate the new
> release to examine it for changes compared with the previous release in
> Fedora, so you can give a rationale for your upgrade request. If you meet
> resistance, you'll have to live with that or return with a competent
> mediator.
>

I'm fully agree with you, but there are some maintainers who don't
respond on bugzilla at all or for a very long time. They may be still
active on koji, but they don't respond even when you attach a
patch/spec to solve known issues or request for co-maintainership.
Obviously, they cannot be defined as nonresponsive package
maintainers, so we have no process/policy to treat those packages.

I filled dozens of reports in bugzilla to request for updating long
unmaintained packages(more than 3 years) several months ago, no
packager respond yet.

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

Re: measuring success

[Till Maas]

On Sat, Jul 03, 2010 at 06:31:35AM +0200, Ralf Corsepius wrote:
> On 07/02/2010 08:12 PM, Till Maas wrote:
> 
> > Btw. on a related issue:How do provenpackagers properly test for broken
> > deps manually?
> Like ordinary packagers should do ;)
> 
> The only difference between provenpackagers and "ordinary packagers" is 
> them having write access to packages they do not own.

The only way I know is pushing the update to testing and then the broken
dep checker will kick in, because only at push time the package set for
the next stable is known.

Regards
Till


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

Re: concept of package "ownership"

[Michael Schwendt]

On Sat, 03 Jul 2010 03:40:57 +0200, Kevin wrote:

> Thomas Janssen wrote:
> > You have to accept the maintainers decision to not update it yet? What
> > do you think will happen if everyone builds the wishes he has and
> > breaks a lot of stuff with it? Anarchy? We have processes for that in
> > Fedora: https://fedoraproject.org/wiki/MikeKnox/AWOL_Maintainers
> 
> It is part of the Fedora Objectives:
> https://fedoraproject.org/wiki/Objectives
> to "be on the leading edge of free and open source technology". Given that, 
> it is completely unacceptable to not upgrade software to the current release 
> in Rawhide (within a reasonable timeframe, of course we're all not available 
> 24/7) unless there's a really good reason to (in which case that reason 
> ought to be given in the bug report asking for the upgrade!), especially 
> when upstream is asking for their software to be upgraded.
> 
> So the maintainer's decision (assuming there even WAS a decision rather than 
> just lack of time or worse) goes against Fedora's Objectives and so it's not 
> OK to say that it should just get accepted.
> 
> We should really be more aggressive about allowing to upgrade other people's 
> packages in Rawhide if the maintainers don't do it within a reasonable 
> timeframe and don't document any good reason not to do the upgrade.

Ridiculous. :( The way you've phrased it doesn't meet the "be excellent"
guidelines IMO. There is nothing "completely unacceptable" or "against
Fedora's objectives" with skipping certain upstream releases. And I hope
that nobody will become "more aggressive" or try to force me (or other
packagers) to upgrade packages. I don't want anyone among the Fedora 
contributors to be "aggressive" in any way when talking to me or when
trying to make me do something.

As a user or fellow packager [or upstream developer], you are free to
suggest upgrades in a bugzilla ticket. And hopefully you evaluate the new
release to examine it for changes compared with the previous release in
Fedora, so you can give a rationale for your upgrade request. If you meet
resistance, you'll have to live with that or return with a competent
mediator.

If you demonstrate interest in the packaged software (and I truly hope
more people will do that), become a maintainer of the packages you want to
upgrade and collaborate with existing maintainers. It *can* be a great
deal of extra fun to see multiple people work on the same packages,
push fixes and updates, communicate with upstream, and experience
progress.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Adam Miller]

If there are any discrepancy with the proventesters critpath policy then
please feel free to file a ticket with FESCo and allow our elected officials
decide the fate of this.

-AdamM (From Android)

On Jul 2, 2010 8:16 PM, "Kevin Kofler"  wrote:

Will Woods wrote:
> The main reasons we want to perform testing are things like: to avoid
> pushing ...
The right way to prevent that is to get AutoQA completed, which will, if it
works as intended, automatically detect and throw out updates with broken
dependencies without needlessly delaying all those updates which don't have
broken dependencies. Once AutoQA is completed, the testing process will do
NOTHING whatsoever to prevent broken dependencies because they wouldn't make
it through AutoQA anyway.


> or updates that cause serious regressions requiring manual intervention /
> emergency update repl...
No amount of testing is going to catch all such cases, and when it does
happen, the testing requirements actually HINDER a quick fix, increasing the
window of exposure to the bug and therefore making it affect many more users
and for longer time.


> In fact, Kevin, given a set of metrics we're both happy with, I'd be
> willing to stake my subscr...
No. Metrics just encourage working to the metric to game the system, and any
improvement you measure from the new process might just be due to chance or
to factors we aren't considering at all. Plus, do we even have the
historical data to compare with, given that everything older than F12 is
deleted from Bodhi?

   Kevin Kofler


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

Re: Seeking co-maintainers: monit

[Maxim Burgerhout]

Hi,

I use it on a couple of servers, and I wouldn't mind co-maintaining  it with
you.

Regards,

Maxim Burgerhout (wz...@fedoraproject.org)

On 2010-07-02 7:55 PM, "Stewart Adam"  wrote:

 Hi,

I packaged monit a while ago but never really got around to using it as I
found Nagios to be more suitable for my needs... I do not mind continuing to
package Monit, but seeing as I rarely use it myself it would be great if
someone who does would like to co-maintain it and help troubleshoot any
bugs, etc.

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