Re: Bodhi 0.7.5 release

[Luke Macken]

On 07/01/2010 12:47 AM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> There is a slight wrinkle in that right now, the bodhi code will
>> automatically request a push of an item that reaches this karma threshold,
>> and I don't believe there is a way yet to force it to wait for even
>> greater amounts of karma.  I believe that fine grained tuning of karma
>> automation is planned for the next major version (and rewrite) of bodhi.
>
> That's not a "slight wrinkle", that's a fatal showstopper which means this
> change should never have hit production. I consider it completely
> unacceptable for my updates to get promoted to stable when I didn't request
> it (e.g. I disable karma automatism for all my updates).

If you disable karma automatism for your updates, they will not 
automatically get promoted to stable upon critpath approval.

> The way the workflow should work (*) is that:
> * case 1: The maintainer requests the push to stable before the promotion is
> approved. Then it will get withheld until approval. Once approval is
> obtained, the push is automatically requested by Bodhi.

This is the workflow that occurs by default.

All critpath updates go to testing first, even if the maintainer chooses 
stable.  It's tested and approved, then bodhi automatically promotes it 
to stable.

> * case 2: The approval happens before a push to stable is requested. In that
> case, the update is marked as approved and the maintainer can queue it to
> stable at any time.
> That's the only sane way to handle such approval, everything else is just
> plain broken. (And isn't that how the security team approval works now? Why
> is the proventester approval implemented differently?)

This is the workflow that occurs when you disable karma automatism.

 > (*) under the (bad) assumption that this process makes sense at all,
 > of course

Your description of how the workflow "should" work is how the workflow 
works.

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

Re: Bodhi 0.7.5 release

[Dave Airlie]

On Thu, 2010-07-01 at 07:00 +0200, Kevin Kofler wrote:
> Dave Airlie wrote:
> > So in your mind, there is a majority of people on your side, but they
> > are just too lazy to stand for election and take over the board?
> 
> s/too lazy/too busy doing actual work/
> (as opposed to wasting their time with politics or bureaucracy)
> 
> Have you noticed that all the people who are complaining about the policies 
> are highly experienced packagers?
> 
> And there are actually many more people disagreeing with those broken 
> policies than the ones you notice on the ML, they just don't have the time 
> to write mails to complain about them. (For example, rumors are that several 
> people in the Brno RH office share my concerns.)

but these people are still in a minority. you are living in a fallacy.

There is also a large percentage of people who agree with the changes
are also "too busy doing actual work", I agree with them, I don't run
for the board, I barely vote, I am an "experienced packager". Like I can
totally handle you being anti-everything anyone does around here, I
can't handle you thinking you are in a majority.

I also work in Brisbane RH office, and I have lots of examples of people
who don't share your concerns.

I've seen surveys before where side A says, I have 100 scientists who
agree with my POV, and you get the other side saying I have 100
scientists all called Dave, who agree with mine.

Dave.

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

rpms/perl-Test-YAML-Valid/devel perl-Test-YAML-Valid.spec,1.9,1.10

[Mark Chappell]

Author: tremble

Update of /cvs/pkgs/rpms/perl-Test-YAML-Valid/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv10434

Modified Files:
perl-Test-YAML-Valid.spec 
Log Message:
Add missing Build requires YAML::XS YAML::Tiny so all tests now run


Index: perl-Test-YAML-Valid.spec
===
RCS file: /cvs/pkgs/rpms/perl-Test-YAML-Valid/devel/perl-Test-YAML-Valid.spec,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- perl-Test-YAML-Valid.spec   30 Jun 2010 12:27:08 -  1.9
+++ perl-Test-YAML-Valid.spec   1 Jul 2010 07:49:23 -   1.10
@@ -1,6 +1,6 @@
 Name:   perl-Test-YAML-Valid
 Version:0.04
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Lets you test the validity of YAML files in unit tests
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -10,9 +10,12 @@ BuildRoot:  %{_tmppath}/%{name}-%{ve
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(YAML) >= 0.60
+BuildRequires:  perl(YAML::XS)
+BuildRequires:  perl(YAML::Tiny)
 BuildRequires:  perl(YAML::Syck)
 BuildRequires:  perl(Test::Pod)
 BuildRequires:  perl(Test::Pod::Coverage)
+BuildRequires:  perl(CPAN)
 BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Test::Builder)
 BuildRequires:  perl(Test::Builder::Tester)
@@ -56,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*3pm*
 
 %changelog
+* Thu Jul 01 2010 Mark Chappell  - 0.04-2
+- Add in missing BR for extra tests
+
 * Wed Jun 30 2010 Mark Chappell  - 0.04-1
 - New upstream version
 

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

[Bug 609807] New: perl-YAML-LibYAML - request for EL-6 branch

[bugzilla]

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

Summary: perl-YAML-LibYAML - request for EL-6 branch

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

   Summary: perl-YAML-LibYAML - request for EL-6 branch
   Product: Fedora
   Version: rawhide
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: medium
  Priority: low
 Component: perl-YAML-LibYAML
AssignedTo: mmasl...@redhat.com
ReportedBy: trem...@tremble.org.uk
 QAContact: extras...@fedoraproject.org
CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com
Classification: Fedora


Please could we have an EL-6 branch for perl-YAML-LibYAML (EPEL)

I (tremble) am happy to (co)maintain in EPEL/Fedora

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

[Bug 608024] perl-Carp-Assert-More - request for EL-6 branch

[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=608024

Mark Chappell  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||trem...@tremble.org.uk
 Resolution||NEXTRELEASE

--- Comment #3 from Mark Chappell  2010-07-01 03:59:29 
EDT ---
Packages branched and built, thanks Tom.

-- 
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.
--
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: Bodhi 0.7.5 release

[Till Maas]

On Thu, Jul 01, 2010 at 05:23:06PM +1000, Dave Airlie wrote:
> On Thu, 2010-07-01 at 07:00 +0200, Kevin Kofler wrote:
> > Dave Airlie wrote:
> > > So in your mind, there is a majority of people on your side, but they
> > > are just too lazy to stand for election and take over the board?
> > 
> > s/too lazy/too busy doing actual work/
> > (as opposed to wasting their time with politics or bureaucracy)
> > 
> > Have you noticed that all the people who are complaining about the policies 
> > are highly experienced packagers?
> > 
> > And there are actually many more people disagreeing with those broken 
> > policies than the ones you notice on the ML, they just don't have the time 
> > to write mails to complain about them. (For example, rumors are that 
> > several 
> > people in the Brno RH office share my concerns.)
> 
> but these people are still in a minority. you are living in a fallacy.

How do you know who is a minority and who is not? I still wonder why
there are so many claims that the majority of Fedora maintainers or
users want to manually test all updates, but still the majority is not
involved in testing the updates. When the discussion started, it was
claimed that submitting karma was too complicated and took too much
time. This is not the case for several months, but still there are
updates that do not receive any karma for more than a month. The last
Bodhi statistics showed 595 unique karma submitters for F13 and there
seem to be 1035 approved packagers currently in Fedora. So if only
packagers submitted karma, it would be the majority. But since there are
a lotsmore users and also dedicated testers for Fedora, it does not look
like a majority anymore.

Regards
Till


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

Re: Bodhi 0.7.5 release

[Till Maas]

On Thu, Jul 01, 2010 at 12:31:06AM -0400, James Antill wrote:
> On Thu, 2010-07-01 at 00:20 +0200, Till Maas wrote:
> > On Wed, Jun 30, 2010 at 12:50:53PM -0700, Adam Williamson wrote:
> > > You can already view all pending critpath updates in Bodhi's web
> > > interface and command line client, as per Luke's initial mail.
> > 
> > But a yum enhancement or plugin to restrict e.g. update or check-update
> > on only critpath updates might be interesting for people only interested
> > in critpath testing.
> 
>  I thought the idea was that critpath packages would be in a critpath
> group in comps?

I just looked and there are two such groups:
critical-path-base
critical-path-gnome

But how can they be used for this? From the manpage I get that e.g. yum
groupupdate critical-path-base would also install all critical-path-base
packages, but the command I was looking for is "update all installed
packages that are in the group critical-path-base". Is there a way to do
this in yum?

Regards
Till


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

Seeking new maintainer for iasl

[Till Maas]

Hi,

a long time ago I packaged iasl, because it is a BR for VirtualBox. I
even received once a bug report for it, because someone used it for
something else which did not work. Since I do not know what to do with
it and I am not involved in packaging VirtualBox anymore, the package
might be better off with someone who knows more about it, because there
are still new releases made for it afaics.

So if someone uses this package, please tell me and I will orphan it:
https://admin.fedoraproject.org/pkgdb/acls/name/iasl

Regards
Till


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

Re: Seeking new maintainer for iasl

[Daniel P. Berrange]

On Thu, Jul 01, 2010 at 12:49:27PM +0200, Till Maas wrote:
> Hi,
> 
> a long time ago I packaged iasl, because it is a BR for VirtualBox. I
> even received once a bug report for it, because someone used it for
> something else which did not work. Since I do not know what to do with
> it and I am not involved in packaging VirtualBox anymore, the package
> might be better off with someone who knows more about it, because there
> are still new releases made for it afaics.
> 
> So if someone uses this package, please tell me and I will orphan it:
> https://admin.fedoraproject.org/pkgdb/acls/name/iasl

It is a BuildRequires for KVM/QEMU still.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: my EPEL-6 packages up for takers

[Marc Bradshaw]

Hi Patrice,

One of my packages has a dependency on docbook2X, so I will take that one.

Thanks,

On 2 May 2010 00:51, Patrice Dumas  wrote:

> Hello,
>
> I won't, at least for now, maintain the packages I maintain in EPEL-5 in
> EPEL-6. I have added a nobranch file in all of them. If you want to take up
> the package, you can. It is still unclear to me how to practically ensure
> that you become the EPEL-6 branch owner, instead of me, though. Hopefully
> this will be sorted out.
>
> If you want to maintain the EL-5 (or even EL-4) branch too, don't
> hesitate, the less package I maintain the better I am.
>
> I think that wdm should not be maintained in EL-6 anyway, since upstream
> is dead and there is no ConsoleKit integration.
>
> For the dap-* packages it maybe worth waiting for a stabilisation of
> the ABI, and maybe integration with bes and packaging of olfs to have a
> working hyrax server before branching. My guess is that there are no
> users of these packages anyway. Also maybe the opendap implementantion
> in netcdf itself could be used instead of libdap/libnc-dap.
>
> The list is:
> acpitool
> asa
> bibexport
> BibTool
> bitmap
> boolstuff
> cernlib
> cernlib-g77
> cppunit
> dap-freeform_handler
> dap-hdf4_handler
> dap-netcdf_handler
> dap-server
> docbook2X
> elektra
> esmtp
> flasm
> g2clib
> gnochm
> gpicview
> grads
> halevt
> html2ps
> kchmviewer
> libdap
> libdockapp
> libesmtp
> libnc-dap
> libsx
> ooo2txt
> pam_ssh
> perl-Algorithm-CurveFit
> perl-Cache
> perl-Feed-Find
> perl-File-BaseDir
> perl-File-DesktopEntry
> perl-File-MimeInfo
> perl-File-NFSLock
> perl-Heap
> perl-HTML-FormatText-WithLinks
> perl-LWP-Authen-Wsse
> perl-Math-MatrixReal
> perl-Math-Symbolic
> perl-Module-Signature
> perl-Parse-Yapp
> perl-Statistics-Descriptive
> perl-Test-Distribution
> perl-Text-CHM
> perl-Text-Unidecode
> pmount
> ps2eps
> python-chm
> tetex-elsevier
> tetex-tex4ht
> uread
> wdm
> wmacpi
> wmix
> xbae
> xchm
> xdialog
>
>
> --
> Pat
>
> ___
> epel-devel-list mailing list
> epel-devel-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Seeking new maintainer for iasl

[Till Maas]

On Thu, Jul 01, 2010 at 11:52:29AM +0100, Daniel P. Berrange wrote:
> On Thu, Jul 01, 2010 at 12:49:27PM +0200, Till Maas wrote:
> > Hi,
> > 
> > a long time ago I packaged iasl, because it is a BR for VirtualBox. I
> > even received once a bug report for it, because someone used it for
> > something else which did not work. Since I do not know what to do with
> > it and I am not involved in packaging VirtualBox anymore, the package
> > might be better off with someone who knows more about it, because there
> > are still new releases made for it afaics.
> > 
> > So if someone uses this package, please tell me and I will orphan it:
> > https://admin.fedoraproject.org/pkgdb/acls/name/iasl
> 
> It is a BuildRequires for KVM/QEMU still.

I never knew that, but I just checked and this stopped after F10 for kvm
and F11 for qemu.

Regards
Till


pgpsGzGxJYsPP.pgp
Description: PGP signature
-- 
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-Net-GPSD

[buildsys]

perl-Net-GPSD has broken dependencies in the rawhide tree:
On x86_64:
perl-Net-GPSD-0.37-4.fc14.noarch requires perl(GPS::PRN)
On i386:
perl-Net-GPSD-0.37-4.fc14.noarch requires perl(GPS::PRN)
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

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

rawhide report: 20100701 changes

[Rawhide Report]

Compose started at Thu Jul  1 08:15:21 UTC 2010

Broken deps for i386
--
BackupPC-3.1.0-14.fc14.noarch requires perl-suidperl
1:NetworkManager-gnome-0.8.1-0.4.fc14.i686 requires 
libgnome-bluetooth.so.7
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
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
gnome-phone-manager-0.65-6.fc14.i686 requires libgnome-bluetooth.so.7
gnome-user-share-2.30.0-1.fc14.i686 requires libgnome-bluetooth.so.7
1:gnumeric-plugins-extras-1.10.0-1.fc14.i686 requires 
perl(:MODULE_COMPAT_5.10.1)
1:imlib-devel-1.9.15-14.fc14.i686 requires libjpeg-devel(x86-32)
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
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
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.3.fc14.i686 requires libhighgui.so.2.0
mrpt-slam-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-topography-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-topography-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-topography-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-topography-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0
mrpt-topography-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0
mrpt-vision-0.9.0-0.3.fc14.i686 requires libcv.so.2.0
mrpt-vision-0.9.0-0.3.fc14.i686 requires libml.so.2.0
mrpt-vision-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0
mrpt-vi

Re: libjpeg-turbo conflicts in rawhide

[Adam Tkac]

On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote:
> Hi all,

Hello,

> I'm trying to build a package that has a BuildRequires: libjpeg-devel in 
> Rawhide [1].  I get a message in root.log that libjpeg-turbo-devel 
> obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead.  
> Unfortunately, when it pulls in dependencies for my other BuildRequires, 
> it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict 
> since they both provide libjpeg.so.62.0.0
> 
> The only thing I can think of is that one of the packages I'm requiring 
> has an explicit dep on libjpeg (I'm about to investigate which).  For 
> the time being, is there any to work around this?

I read this thread and
https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two
reasonable solutions for this problem:

1. Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package
which contains only libjpeg.so.62*. I believe this will solve both
update and buildroot problems. However it also means all users of
libjpeg programs (djpeg, cjpeg and friends) will need to manually
install libjpeg-turbo-tools

2. Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as
done in libjpeg.

I must admit I like the first solution. People usually needs only
libjpeg.so, not programs. People which need libjpeg programs can
easily install libjpeg-turbo-tools package themselves, this
"incompatibility" seems acceptable for me in development branch.

What is your opinion about this proposal?

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rebuild of wxGTK without the internal crash handler in Rawhide

[Dan Horák]

Hello,

I will rebuild wxGTK without the internal crash handler for the the
devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
this change affects all applications linked with wxGTK, because one
symbol is removed from the "base" library. I will take care of
rebuilding the packages in the next days, but the package owners should
still check what is their implementation of the
wxApp::OnFatalExpection() virtual method doing, because it will not be
called anymore. Usually it is used to display the wxGTK-based crash
report. Please let me know if you want to rebuild the package yourself
or if you have some questions.

This is the list of packages that have wxGTK-devel as BuildRequires:

DivFix++
LuxRender
OpenSceneGraph
audacity
bacula
boinc-client
codeblocks
crystalspace
erlang
extrema
fbg
filezilla
fityk
flamerobin
freedink-dfarc
gdl
glest
gnuplot
gspiceui
hugin
iaxclient
kicad
mathgl
mkvtoolnix
mrpt
multiget
nightview
panoglview
perl-Alien-wxWidgets (doesn't look to link with library?)
perl-Wx
pgadmin3
plee-the-bear
plplot
poedit
rapidsvn
scorched3d
scummvm-tools
simdock
sooperlooper
springlobby
toped
trustedqsl
ucblogo
vavoom
wxMaxima
wxPython
xchm
xmlcopyeditor


Dan


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

[Bug 609807] perl-YAML-LibYAML - request for EL-6 branch

[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=609807

--- Comment #1 from Marcela Mašláňová  2010-07-01 08:44:19 
EDT ---
Feel free to take this package in EPEL.

-- 
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.
--
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: Bodhi 0.7.5 release

[Chris Adams]

Once upon a time, Kevin Kofler  said:
> No. It means there haven't been enough such candidates. People did vote for 
> me. But alone against 8 people who didn't agree with me, I wasn't able to 
> achieve anything.
> 
> If you give people ballots with only Evil Dictator on them, of course Evil 
> Dictator will win. It doesn't say anything about the electorate.

Why do you continue to hang around in a group you believe has a silent
majority that agrees with you (but doesn't show up for elections) and
that you think is run by Evil Dictators?  That's really an insult to the
people putting in effort to make Fedora better.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: my EPEL-6 packages up for takers

[Deji Akingunola]

On Sat, May 1, 2010 at 10:51 AM, Patrice Dumas  wrote:

> g2clib
> grads

I'll take these 2.

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

[Bug 609807] perl-YAML-LibYAML - request for EL-6 branch

[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=609807

Mark Chappell  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||trem...@tremble.org.uk
 Resolution||NEXTRELEASE

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

[Bug 608669] perl-Pod-Strip - Request for EL-6 branch

[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=608669

Mark Chappell  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||trem...@tremble.org.uk
 Resolution||NEXTRELEASE

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

[Bug 610055] New: Broken dependencies: missing perl(GPS::PRN)

[bugzilla]

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

Summary: Broken dependencies: missing perl(GPS::PRN)

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

   Summary: Broken dependencies: missing perl(GPS::PRN)
   Product: Fedora
   Version: rawhide
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: medium
  Priority: low
 Component: perl-Net-GPSD
AssignedTo: tcall...@redhat.com
ReportedBy: ppi...@redhat.com
 QAContact: extras...@fedoraproject.org
CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com
Classification: Fedora
Target Release: ---


Date: Thu,  1 Jul 2010 11:55:54 + (UTC)
From: build...@fedoraproject.org
To: perl-net-gpsd-ow...@fedoraproject.org
Subject: Broken dependencies: perl-Net-GPSD

perl-Net-GPSD has broken dependencies in the rawhide tree:
On x86_64:
perl-Net-GPSD-0.37-4.fc14.noarch requires perl(GPS::PRN)
On i386:
perl-Net-GPSD-0.37-4.fc14.noarch requires perl(GPS::PRN)


This is caused by removal of perl-GPS-PRN from F-14:

$ cat dead.package 
This package was renamed upstream to GPS::OID, so it has been renamed in Fedora
to perl-GPS-OID.

Tom "spot" Callaway . Wed Jun 30, 2010

Upstream released new version 0.39 that fixes it. Please do the upgrade.

-- 
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.
--
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 Net-GPSD-0.39.tar.gz uploaded to lookaside cache by spot

[Tom Callaway]

A file has been added to the lookaside cache for perl-Net-GPSD:

994a6251b15eea7cf748fe8350a1f94f  Net-GPSD-0.39.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

rpms/perl-Net-GPSD/devel .cvsignore, 1.7, 1.8 perl-Net-GPSD.spec, 1.13, 1.14 sources, 1.7, 1.8

[Tom Callaway]

Author: spot

Update of /cvs/pkgs/rpms/perl-Net-GPSD/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv22967

Modified Files:
.cvsignore perl-Net-GPSD.spec sources 
Log Message:
update to 0.39


Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Net-GPSD/devel/.cvsignore,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- .cvsignore  13 Mar 2009 22:22:50 -  1.7
+++ .cvsignore  1 Jul 2010 13:39:33 -   1.8
@@ -1 +1 @@
-Net-GPSD-0.37.tar.gz
+Net-GPSD-0.39.tar.gz


Index: perl-Net-GPSD.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-GPSD/devel/perl-Net-GPSD.spec,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- perl-Net-GPSD.spec  4 May 2010 10:20:44 -   1.13
+++ perl-Net-GPSD.spec  1 Jul 2010 13:39:33 -   1.14
@@ -1,6 +1,6 @@
 Name:   perl-Net-GPSD
-Version:0.37
-Release:4%{?dist}
+Version:0.39
+Release:1%{?dist}
 Summary:Provides an object client interface to the gpsd server daemon
 
 Group:  Development/Libraries
@@ -13,7 +13,7 @@ BuildArch:  noarch
 BuildRequires:  perl(Geo::Forward) => 0.09
 BuildRequires:  perl(Geo::Functions) => 0.06
 BuildRequires:  perl(Geo::Inverse) => 0.02
-BuildRequires:  perl(GPS::PRN)
+BuildRequires:  perl(GPS::OID)
 BuildRequires:  perl(LWP::UserAgent)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
@@ -58,6 +58,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Thu Jul 01 2010 Tom "spot" Callaway  - 0.39-1
+- update to 0.39
+
 * Tue May 04 2010 Marcela Maslanova  - 0.37-4
 - Mass rebuild with perl-5.12.0
 


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Net-GPSD/devel/sources,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- sources 13 Mar 2009 22:22:51 -  1.7
+++ sources 1 Jul 2010 13:39:33 -   1.8
@@ -1 +1 @@
-058ab2f2ca3fac9f6cbf0a843776c164  Net-GPSD-0.37.tar.gz
+994a6251b15eea7cf748fe8350a1f94f  Net-GPSD-0.39.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: Seeking new maintainer for iasl

[Jon Ciesla]

On 07/01/2010 06:36 AM, Till Maas wrote:
> On Thu, Jul 01, 2010 at 11:52:29AM +0100, Daniel P. Berrange wrote:
>
>> On Thu, Jul 01, 2010 at 12:49:27PM +0200, Till Maas wrote:
>>  
>>> Hi,
>>>
>>> a long time ago I packaged iasl, because it is a BR for VirtualBox. I
>>> even received once a bug report for it, because someone used it for
>>> something else which did not work. Since I do not know what to do with
>>> it and I am not involved in packaging VirtualBox anymore, the package
>>> might be better off with someone who knows more about it, because there
>>> are still new releases made for it afaics.
>>>
>>> So if someone uses this package, please tell me and I will orphan it:
>>> https://admin.fedoraproject.org/pkgdb/acls/name/iasl
>>>
>> It is a BuildRequires for KVM/QEMU still.
>>  
> I never knew that, but I just checked and this stopped after F10 for kvm
> and F11 for qemu.
>
> Regards
> Till
>
repoquery --repoid=rawhide-source --archlist=src --whatrequires iasl 
returns nothing.  It looks like we may not need it for anything else, 
though it may have value to developers for other things.

If you don't want to maintain it, I can packagemonkey it and keep it up 
to date, unless someone with more use for it or knowledge of it steps up.

-J

-- 
- in your fear, speak only peace
   in your fear, seek only love

-d. bowie

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

Re: libjpeg-turbo conflicts in rawhide

[Chen Lei]

2010/7/1 Adam Tkac :
> On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote:
>> Hi all,
>
> Hello,
>
>> I'm trying to build a package that has a BuildRequires: libjpeg-devel in
>> Rawhide [1].  I get a message in root.log that libjpeg-turbo-devel
>> obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead.
>> Unfortunately, when it pulls in dependencies for my other BuildRequires,
>> it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict
>> since they both provide libjpeg.so.62.0.0
>>
>> The only thing I can think of is that one of the packages I'm requiring
>> has an explicit dep on libjpeg (I'm about to investigate which).  For
>> the time being, is there any to work around this?
>
> I read this thread and
> https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two
> reasonable solutions for this problem:
>
> 1. Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package
> which contains only libjpeg.so.62*. I believe this will solve both
> update and buildroot problems. However it also means all users of
> libjpeg programs (djpeg, cjpeg and friends) will need to manually
> install libjpeg-turbo-tools
>
> 2. Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as
> done in libjpeg.
>
> I must admit I like the first solution. People usually needs only
> libjpeg.so, not programs. People which need libjpeg programs can
> easily install libjpeg-turbo-tools package themselves, this
> "incompatibility" seems acceptable for me in development branch.
>
> What is your opinion about this proposal?
>
> Regards, Adam
>
> --
Only three packages in the rawhide depend on -utils:

renrot
gallery2-jpegtran
gocr

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

[Bug 610055] Broken dependencies: missing perl(GPS::PRN)

[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=610055

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution||RAWHIDE

--- Comment #1 from Tom "spot" Callaway  2010-07-01 
09:57:08 EDT ---
0.39 is built in rawhide.

-- 
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.
--
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: Seeking new maintainer for iasl

[Till Maas]

On Thu, Jul 01, 2010 at 08:54:01AM -0500, Jon Ciesla wrote:

> repoquery --repoid=rawhide-source --archlist=src --whatrequires iasl 
> returns nothing.  It looks like we may not need it for anything else, 
> though it may have value to developers for other things.

Ah, this is a nice query. It is still BR'ed by VirtualBox-OSE as
repoquery --disablerepo \* --enablerepo rpmfusion\*-source
--archlist=src --whatrequires iasl
tells me.

> If you don't want to maintain it, I can packagemonkey it and keep it up 
> to date, unless someone with more use for it or knowledge of it steps up.

Thank you, I just released ownership:
http://admin.fedoraproject.org/pkgdb/acls/name/iasl

Regards
Till


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

Re: libjpeg-turbo conflicts in rawhide

[Adam Tkac]

On Thu, Jul 01, 2010 at 09:55:08PM +0800, Chen Lei wrote:
> 2010/7/1 Adam Tkac :
> > On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote:
> >> Hi all,
> >
> > Hello,
> >
> >> I'm trying to build a package that has a BuildRequires: libjpeg-devel in
> >> Rawhide [1].  I get a message in root.log that libjpeg-turbo-devel
> >> obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead.
> >> Unfortunately, when it pulls in dependencies for my other BuildRequires,
> >> it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict
> >> since they both provide libjpeg.so.62.0.0
> >>
> >> The only thing I can think of is that one of the packages I'm requiring
> >> has an explicit dep on libjpeg (I'm about to investigate which).  For
> >> the time being, is there any to work around this?
> >
> > I read this thread and
> > https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two
> > reasonable solutions for this problem:
> >
> > 1. Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package
> > which contains only libjpeg.so.62*. I believe this will solve both
> > update and buildroot problems. However it also means all users of
> > libjpeg programs (djpeg, cjpeg and friends) will need to manually
> > install libjpeg-turbo-tools
> >
> > 2. Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as
> > done in libjpeg.
> >
> > I must admit I like the first solution. People usually needs only
> > libjpeg.so, not programs. People which need libjpeg programs can
> > easily install libjpeg-turbo-tools package themselves, this
> > "incompatibility" seems acceptable for me in development branch.
> >
> > What is your opinion about this proposal?
> >
> > Regards, Adam
> >
> > --
> Only three packages in the rawhide depend on -utils:
> 
> renrot
> gallery2-jpegtran
> gocr

Thanks for your inspection. Those packages can be very
easily fixed by adding "Requires: /usr/bin/djpeg" to them.
This change will be compatible with both former "monolitic" libjpeg
and new libjpeg-turbo-utils. I will do this myself.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[James Antill]

On Thu, 2010-07-01 at 12:06 +0200, Till Maas wrote:
> On Thu, Jul 01, 2010 at 12:31:06AM -0400, James Antill wrote:
> >  I thought the idea was that critpath packages would be in a critpath
> > group in comps?
> 
> I just looked and there are two such groups:
> critical-path-base
> critical-path-gnome
> 
> But how can they be used for this? From the manpage I get that e.g. yum
> groupupdate critical-path-base would also install all critical-path-base
> packages, but the command I was looking for is "update all installed
> packages that are in the group critical-path-base". Is there a way to do
> this in yum?

 There are a couple of other things you can do now:

 yum groupinfo -v critical-path\*
 yum --filter-groups=critical-path\* (requires yum-filter-data plugin)

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

File Catalyst-View-Component-SubInclude-0.09.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

A file has been added to the lookaside cache for 
perl-Catalyst-View-Component-SubInclude:

160806960b548fcb02e5ee3209ce48dc  Catalyst-View-Component-SubInclude-0.09.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

rpms/perl-Catalyst-View-Component-SubInclude/F-12 perl-Catalyst-View-Component-SubInclude.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-12
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31783/F-12

Modified Files:
.cvsignore sources 
Added Files:
perl-Catalyst-View-Component-SubInclude.spec 
Log Message:
initial import


--- NEW FILE perl-Catalyst-View-Component-SubInclude.spec ---
Name:   perl-Catalyst-View-Component-SubInclude
Version:0.09
Release:2%{?dist}
Summary:Use subincludes in your Catalyst views
License:GPL+ or Artistic
Group:  Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-View-Component-SubInclude/
Source0:
http://www.cpan.org/authors/id/B/BO/BOBTFISH/Catalyst-View-Component-SubInclude-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch
BuildRequires:  perl(Catalyst::Action::RenderView)
BuildRequires:  perl(Catalyst::Plugin::SubRequest)
BuildRequires:  perl(Catalyst::Runtime) >= 5.80014
BuildRequires:  perl(Catalyst::View::TT)
BuildRequires:  perl(ExtUtils::MakeMaker)
BuildRequires:  perl(File::Copy::Recursive)
BuildRequires:  perl(Moose)
BuildRequires:  perl(Moose::Role)
BuildRequires:  perl(MooseX::Types)
BuildRequires:  perl(namespace::clean)
BuildRequires:  perl(Test::More) >= 0.88
Requires:   perl(Catalyst::Plugin::SubRequest)
Requires:   perl(Catalyst::Runtime) >= 5.80014
Requires:   perl(MooseX::Types)
Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))

%{?perl_default_filter}

%description
Catalyst::View::Component::SubInclude allows you to include content in your
templates (or, more generally, somewhere in your view's render processing)
which comes from another action in your application. It's implemented as a
Moose::Role, so using Moose in your view is required.

%prep
%setup -q -n Catalyst-View-Component-SubInclude-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

make pure_install DESTDIR=$RPM_BUILD_ROOT

find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;

%{_fixperms} $RPM_BUILD_ROOT/*

%check
make test

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*

%changelog
* Thu Jul 01 2010 Iain Arnell  0.09-2
- remove automatically detected explicit requires

* Wed Jun 30 2010 Iain Arnell  0.09-1
- Specfile autogenerated by cpanspec 1.78.


Index: .cvsignore
===
RCS file: 
/cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore  1 Jul 2010 04:59:43 -   1.1
+++ .cvsignore  1 Jul 2010 14:46:09 -   1.2
@@ -0,0 +1 @@
+Catalyst-View-Component-SubInclude-0.09.tar.gz


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Jul 2010 04:59:43 -   1.1
+++ sources 1 Jul 2010 14:46:10 -   1.2
@@ -0,0 +1 @@
+160806960b548fcb02e5ee3209ce48dc  
Catalyst-View-Component-SubInclude-0.09.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

rpms/perl-Catalyst-View-Component-SubInclude/devel perl-Catalyst-View-Component-SubInclude.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31783/devel

Modified Files:
.cvsignore sources 
Added Files:
perl-Catalyst-View-Component-SubInclude.spec 
Log Message:
initial import


--- NEW FILE perl-Catalyst-View-Component-SubInclude.spec ---
Name:   perl-Catalyst-View-Component-SubInclude
Version:0.09
Release:2%{?dist}
Summary:Use subincludes in your Catalyst views
License:GPL+ or Artistic
Group:  Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-View-Component-SubInclude/
Source0:
http://www.cpan.org/authors/id/B/BO/BOBTFISH/Catalyst-View-Component-SubInclude-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch
BuildRequires:  perl(Catalyst::Action::RenderView)
BuildRequires:  perl(Catalyst::Plugin::SubRequest)
BuildRequires:  perl(Catalyst::Runtime) >= 5.80014
BuildRequires:  perl(Catalyst::View::TT)
BuildRequires:  perl(ExtUtils::MakeMaker)
BuildRequires:  perl(File::Copy::Recursive)
BuildRequires:  perl(Moose)
BuildRequires:  perl(Moose::Role)
BuildRequires:  perl(MooseX::Types)
BuildRequires:  perl(namespace::clean)
BuildRequires:  perl(Test::More) >= 0.88
Requires:   perl(Catalyst::Plugin::SubRequest)
Requires:   perl(Catalyst::Runtime) >= 5.80014
Requires:   perl(MooseX::Types)
Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))

%{?perl_default_filter}

%description
Catalyst::View::Component::SubInclude allows you to include content in your
templates (or, more generally, somewhere in your view's render processing)
which comes from another action in your application. It's implemented as a
Moose::Role, so using Moose in your view is required.

%prep
%setup -q -n Catalyst-View-Component-SubInclude-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

make pure_install DESTDIR=$RPM_BUILD_ROOT

find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;

%{_fixperms} $RPM_BUILD_ROOT/*

%check
make test

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*

%changelog
* Thu Jul 01 2010 Iain Arnell  0.09-2
- remove automatically detected explicit requires

* Wed Jun 30 2010 Iain Arnell  0.09-1
- Specfile autogenerated by cpanspec 1.78.


Index: .cvsignore
===
RCS file: 
/cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore  1 Jul 2010 04:59:43 -   1.1
+++ .cvsignore  1 Jul 2010 14:46:11 -   1.2
@@ -0,0 +1 @@
+Catalyst-View-Component-SubInclude-0.09.tar.gz


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Jul 2010 04:59:43 -   1.1
+++ sources 1 Jul 2010 14:46:11 -   1.2
@@ -0,0 +1 @@
+160806960b548fcb02e5ee3209ce48dc  
Catalyst-View-Component-SubInclude-0.09.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

rpms/perl-Catalyst-View-Component-SubInclude/F-13 perl-Catalyst-View-Component-SubInclude.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31783/F-13

Modified Files:
.cvsignore sources 
Added Files:
perl-Catalyst-View-Component-SubInclude.spec 
Log Message:
initial import


--- NEW FILE perl-Catalyst-View-Component-SubInclude.spec ---
Name:   perl-Catalyst-View-Component-SubInclude
Version:0.09
Release:2%{?dist}
Summary:Use subincludes in your Catalyst views
License:GPL+ or Artistic
Group:  Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-View-Component-SubInclude/
Source0:
http://www.cpan.org/authors/id/B/BO/BOBTFISH/Catalyst-View-Component-SubInclude-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch
BuildRequires:  perl(Catalyst::Action::RenderView)
BuildRequires:  perl(Catalyst::Plugin::SubRequest)
BuildRequires:  perl(Catalyst::Runtime) >= 5.80014
BuildRequires:  perl(Catalyst::View::TT)
BuildRequires:  perl(ExtUtils::MakeMaker)
BuildRequires:  perl(File::Copy::Recursive)
BuildRequires:  perl(Moose)
BuildRequires:  perl(Moose::Role)
BuildRequires:  perl(MooseX::Types)
BuildRequires:  perl(namespace::clean)
BuildRequires:  perl(Test::More) >= 0.88
Requires:   perl(Catalyst::Plugin::SubRequest)
Requires:   perl(Catalyst::Runtime) >= 5.80014
Requires:   perl(MooseX::Types)
Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))

%{?perl_default_filter}

%description
Catalyst::View::Component::SubInclude allows you to include content in your
templates (or, more generally, somewhere in your view's render processing)
which comes from another action in your application. It's implemented as a
Moose::Role, so using Moose in your view is required.

%prep
%setup -q -n Catalyst-View-Component-SubInclude-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

make pure_install DESTDIR=$RPM_BUILD_ROOT

find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;

%{_fixperms} $RPM_BUILD_ROOT/*

%check
make test

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*

%changelog
* Thu Jul 01 2010 Iain Arnell  0.09-2
- remove automatically detected explicit requires

* Wed Jun 30 2010 Iain Arnell  0.09-1
- Specfile autogenerated by cpanspec 1.78.


Index: .cvsignore
===
RCS file: 
/cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-13/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore  1 Jul 2010 04:59:43 -   1.1
+++ .cvsignore  1 Jul 2010 14:46:10 -   1.2
@@ -0,0 +1 @@
+Catalyst-View-Component-SubInclude-0.09.tar.gz


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-13/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Jul 2010 04:59:43 -   1.1
+++ sources 1 Jul 2010 14:46:11 -   1.2
@@ -0,0 +1 @@
+160806960b548fcb02e5ee3209ce48dc  
Catalyst-View-Component-SubInclude-0.09.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: How to lure me to updates-testing

[Adam Williamson]

On Wed, 2010-06-30 at 16:44 -0500, Michael Cronenworth wrote:
> Nathanael Noblet wrote:
> > I presume a fedora account with certs are required for this?
> 
> Yes, but for your karma to have any merit, you need a Fedora account. 
> Non-Fedora account karma does not count.
> 
> I agree a GUI would be nice for all of this, and I would be willing to 
> create one, but time has been an issue lately.

If we're in pony mode, sure, this is a pony I would also like to see. :)
Although I think perhaps it would be best to integrate the functions
into PackageKit (perhaps as an optional extension package) than to write
an entirely new tool.
-- 
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: How to lure me to updates-testing

[Michael Cronenworth]

Adam Williamson wrote:
> Although I think perhaps it would be best to integrate the functions
> into PackageKit (perhaps as an optional extension package) than to write
> an entirely new tool.

That is my intention. I'd quote myself from months back saying this, but 
then it would reveal my procrastination.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File Catalyst-Controller-ActionRole-0.14.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

A file has been added to the lookaside cache for 
perl-Catalyst-Controller-ActionRole:

7fc32dfeba824185a33ba55b93d8d2f9  Catalyst-Controller-ActionRole-0.14.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: How to lure me to updates-testing

[seth vidal]

On Thu, 2010-07-01 at 07:46 -0700, Adam Williamson wrote:
> On Wed, 2010-06-30 at 16:44 -0500, Michael Cronenworth wrote:
> > Nathanael Noblet wrote:
> > > I presume a fedora account with certs are required for this?
> > 
> > Yes, but for your karma to have any merit, you need a Fedora account. 
> > Non-Fedora account karma does not count.
> > 
> > I agree a GUI would be nice for all of this, and I would be willing to 
> > create one, but time has been an issue lately.
> 
> If we're in pony mode, sure, this is a pony I would also like to see. :)
> Although I think perhaps it would be best to integrate the functions
> into PackageKit (perhaps as an optional extension package) than to write
> an entirely new tool.

This would make more sense if PK was a fedora-tool - but PK is targeted
to be cross-distro - and integrating bodhi-reporting would not be
cross-distro.

So, if you want to make this work we'll need someway to plugin AROUND
PK.

Might be worth having some time with Richard to discuss how that should
happen.

-sv


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

rpms/perl-Catalyst-Controller-ActionRole/F-13 perl-Catalyst-Controller-ActionRole.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-Controller-ActionRole/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv325/F-13

Modified Files:
.cvsignore sources 
Added Files:
perl-Catalyst-Controller-ActionRole.spec 
Log Message:
initial import


--- NEW FILE perl-Catalyst-Controller-ActionRole.spec ---
Name:   perl-Catalyst-Controller-ActionRole
Version:0.14
Release:1%{?dist}
Summary:Apply roles to action instances
License:GPL+ or Artistic
Group:  Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-Controller-ActionRole/
Source0:
http://www.cpan.org/authors/id/F/FL/FLORA/Catalyst-Controller-ActionRole-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch
BuildRequires:  perl(Catalyst::Runtime) >= 5.71001
BuildRequires:  perl(Class::MOP) >= 0.80
BuildRequires:  perl(ExtUtils::MakeMaker)
BuildRequires:  perl(Moose) >= 0.90
BuildRequires:  perl(MooseX::Types::Moose)
BuildRequires:  perl(namespace::clean)
BuildRequires:  perl(String::RewritePrefix) >= 0.004
Requires:   perl(Catalyst::Runtime) >= 5.71001
Requires:   perl(Class::MOP) >= 0.80
Requires:   perl(Moose) >= 0.90
Requires:   perl(String::RewritePrefix) >= 0.004
Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))

%{?perl_default_filter}

%description
This module allows to apply roles to the Catalyst::Actions for different
controller methods.

%prep
%setup -q -n Catalyst-Controller-ActionRole-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

make pure_install DESTDIR=$RPM_BUILD_ROOT

find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;

%{_fixperms} $RPM_BUILD_ROOT/*

%check
make test

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*

%changelog
* Wed Jun 30 2010 Iain Arnell  0.14-1
- Specfile autogenerated by cpanspec 1.78.


Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Controller-ActionRole/F-13/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore  1 Jul 2010 04:59:23 -   1.1
+++ .cvsignore  1 Jul 2010 14:53:54 -   1.2
@@ -0,0 +1 @@
+Catalyst-Controller-ActionRole-0.14.tar.gz


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Controller-ActionRole/F-13/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Jul 2010 04:59:23 -   1.1
+++ sources 1 Jul 2010 14:53:55 -   1.2
@@ -0,0 +1 @@
+7fc32dfeba824185a33ba55b93d8d2f9  Catalyst-Controller-ActionRole-0.14.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

rpms/perl-Catalyst-Controller-ActionRole/devel perl-Catalyst-Controller-ActionRole.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-Controller-ActionRole/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv325/devel

Modified Files:
.cvsignore sources 
Added Files:
perl-Catalyst-Controller-ActionRole.spec 
Log Message:
initial import


--- NEW FILE perl-Catalyst-Controller-ActionRole.spec ---
Name:   perl-Catalyst-Controller-ActionRole
Version:0.14
Release:1%{?dist}
Summary:Apply roles to action instances
License:GPL+ or Artistic
Group:  Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-Controller-ActionRole/
Source0:
http://www.cpan.org/authors/id/F/FL/FLORA/Catalyst-Controller-ActionRole-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch
BuildRequires:  perl(Catalyst::Runtime) >= 5.71001
BuildRequires:  perl(Class::MOP) >= 0.80
BuildRequires:  perl(ExtUtils::MakeMaker)
BuildRequires:  perl(Moose) >= 0.90
BuildRequires:  perl(MooseX::Types::Moose)
BuildRequires:  perl(namespace::clean)
BuildRequires:  perl(String::RewritePrefix) >= 0.004
Requires:   perl(Catalyst::Runtime) >= 5.71001
Requires:   perl(Class::MOP) >= 0.80
Requires:   perl(Moose) >= 0.90
Requires:   perl(String::RewritePrefix) >= 0.004
Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))

%{?perl_default_filter}

%description
This module allows to apply roles to the Catalyst::Actions for different
controller methods.

%prep
%setup -q -n Catalyst-Controller-ActionRole-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

make pure_install DESTDIR=$RPM_BUILD_ROOT

find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;

%{_fixperms} $RPM_BUILD_ROOT/*

%check
make test

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*

%changelog
* Wed Jun 30 2010 Iain Arnell  0.14-1
- Specfile autogenerated by cpanspec 1.78.


Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Controller-ActionRole/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore  1 Jul 2010 04:59:23 -   1.1
+++ .cvsignore  1 Jul 2010 14:53:55 -   1.2
@@ -0,0 +1 @@
+Catalyst-Controller-ActionRole-0.14.tar.gz


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Controller-ActionRole/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Jul 2010 04:59:23 -   1.1
+++ sources 1 Jul 2010 14:53:55 -   1.2
@@ -0,0 +1 @@
+7fc32dfeba824185a33ba55b93d8d2f9  Catalyst-Controller-ActionRole-0.14.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

rpms/perl-Catalyst-Controller-ActionRole/F-12 perl-Catalyst-Controller-ActionRole.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-Controller-ActionRole/F-12
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv325/F-12

Modified Files:
.cvsignore sources 
Added Files:
perl-Catalyst-Controller-ActionRole.spec 
Log Message:
initial import


--- NEW FILE perl-Catalyst-Controller-ActionRole.spec ---
Name:   perl-Catalyst-Controller-ActionRole
Version:0.14
Release:1%{?dist}
Summary:Apply roles to action instances
License:GPL+ or Artistic
Group:  Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-Controller-ActionRole/
Source0:
http://www.cpan.org/authors/id/F/FL/FLORA/Catalyst-Controller-ActionRole-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch
BuildRequires:  perl(Catalyst::Runtime) >= 5.71001
BuildRequires:  perl(Class::MOP) >= 0.80
BuildRequires:  perl(ExtUtils::MakeMaker)
BuildRequires:  perl(Moose) >= 0.90
BuildRequires:  perl(MooseX::Types::Moose)
BuildRequires:  perl(namespace::clean)
BuildRequires:  perl(String::RewritePrefix) >= 0.004
Requires:   perl(Catalyst::Runtime) >= 5.71001
Requires:   perl(Class::MOP) >= 0.80
Requires:   perl(Moose) >= 0.90
Requires:   perl(String::RewritePrefix) >= 0.004
Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))

%{?perl_default_filter}

%description
This module allows to apply roles to the Catalyst::Actions for different
controller methods.

%prep
%setup -q -n Catalyst-Controller-ActionRole-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

make pure_install DESTDIR=$RPM_BUILD_ROOT

find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;

%{_fixperms} $RPM_BUILD_ROOT/*

%check
make test

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*

%changelog
* Wed Jun 30 2010 Iain Arnell  0.14-1
- Specfile autogenerated by cpanspec 1.78.


Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Controller-ActionRole/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore  1 Jul 2010 04:59:23 -   1.1
+++ .cvsignore  1 Jul 2010 14:53:54 -   1.2
@@ -0,0 +1 @@
+Catalyst-Controller-ActionRole-0.14.tar.gz


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Controller-ActionRole/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Jul 2010 04:59:23 -   1.1
+++ sources 1 Jul 2010 14:53:54 -   1.2
@@ -0,0 +1 @@
+7fc32dfeba824185a33ba55b93d8d2f9  Catalyst-Controller-ActionRole-0.14.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: Seeking new maintainer for iasl

[Matthew Garrett]

On Thu, Jul 01, 2010 at 08:54:01AM -0500, Jon Ciesla wrote:

> repoquery --repoid=rawhide-source --archlist=src --whatrequires iasl 
> returns nothing.  It looks like we may not need it for anything else, 
> though it may have value to developers for other things.

Under some circumstances it can end up being used in the seabios build, 
but I don't think it's a requirement right now.

> If you don't want to maintain it, I can packagemonkey it and keep it up 
> to date, unless someone with more use for it or knowledge of it steps up.

I use it on a pretty much daily basis and recently got hit by a bug that 
was fixed in a later release, so I'll happily take it if you're not 
hugely enthusiastic about looking after it.

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

[Bug 582163] Review Request: perl-Test-Smoke - Perl core test smoke suite

[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=582163

Marcela Mašláňová  changed:

   What|Removed |Added

   Flag||fedora-cvs?

--- Comment #7 from Marcela Mašláňová  2010-07-01 10:57:23 
EDT ---
New Package CVS Request
===
Package Name: perl-Test-Smoke
Short Description: Perl core test smoke suite
Owners: mmaslano psabata ppisar
Branches: F-13
InitialCC: perl-sig

-- 
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.
--
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: How to lure me to updates-testing

[Adam Williamson]

On Thu, 2010-07-01 at 10:52 -0400, seth vidal wrote:
> On Thu, 2010-07-01 at 07:46 -0700, Adam Williamson wrote:
> > On Wed, 2010-06-30 at 16:44 -0500, Michael Cronenworth wrote:
> > > Nathanael Noblet wrote:
> > > > I presume a fedora account with certs are required for this?
> > > 
> > > Yes, but for your karma to have any merit, you need a Fedora account. 
> > > Non-Fedora account karma does not count.
> > > 
> > > I agree a GUI would be nice for all of this, and I would be willing to 
> > > create one, but time has been an issue lately.
> > 
> > If we're in pony mode, sure, this is a pony I would also like to see. :)
> > Although I think perhaps it would be best to integrate the functions
> > into PackageKit (perhaps as an optional extension package) than to write
> > an entirely new tool.
> 
> This would make more sense if PK was a fedora-tool - but PK is targeted
> to be cross-distro - and integrating bodhi-reporting would not be
> cross-distro.
> 
> So, if you want to make this work we'll need someway to plugin AROUND
> PK.

Good point. I guess in my head it already worked that way. =)

> Might be worth having some time with Richard to discuss how that should
> happen.

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

rpms/perl-Catalyst-View-Component-SubInclude/F-12 perl-Catalyst-View-Component-SubInclude.spec, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-12
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3027/F-12

Modified Files:
perl-Catalyst-View-Component-SubInclude.spec 
Log Message:
* Thu Jul 01 2010 Iain Arnell  0.09-3
- Require perl(Catalyst) >= 5.80014



Index: perl-Catalyst-View-Component-SubInclude.spec
===
RCS file: 
/cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-12/perl-Catalyst-View-Component-SubInclude.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-Catalyst-View-Component-SubInclude.spec1 Jul 2010 14:46:09 
-   1.1
+++ perl-Catalyst-View-Component-SubInclude.spec1 Jul 2010 15:13:09 
-   1.2
@@ -1,6 +1,6 @@
 Name:   perl-Catalyst-View-Component-SubInclude
 Version:0.09
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Use subincludes in your Catalyst views
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -10,6 +10,9 @@ BuildRoot:  %{_tmppath}/%{name}-%{ve
 BuildArch:  noarch
 BuildRequires:  perl(Catalyst::Action::RenderView)
 BuildRequires:  perl(Catalyst::Plugin::SubRequest)
+# perl-Catalyst-Runtime provides unversioned perl(Catalyst::Runtime)
+# Ensure that we really have a good version
+BuildRequires:  perl(Catalyst) >= 5.80014
 BuildRequires:  perl(Catalyst::Runtime) >= 5.80014
 BuildRequires:  perl(Catalyst::View::TT)
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -20,6 +23,9 @@ BuildRequires:  perl(MooseX::Types)
 BuildRequires:  perl(namespace::clean)
 BuildRequires:  perl(Test::More) >= 0.88
 Requires:   perl(Catalyst::Plugin::SubRequest)
+# perl-Catalyst-Runtime provides unversioned perl(Catalyst::Runtime)
+# Ensure that we really have a good version
+Requires:   perl(Catalyst) >= 5.80014
 Requires:   perl(Catalyst::Runtime) >= 5.80014
 Requires:   perl(MooseX::Types)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
@@ -62,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 01 2010 Iain Arnell  0.09-3
+- Require perl(Catalyst) >= 5.80014
+
 * Thu Jul 01 2010 Iain Arnell  0.09-2
 - remove automatically detected explicit requires
 

--
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-Catalyst-View-Component-SubInclude/F-13 perl-Catalyst-View-Component-SubInclude.spec, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3027/F-13

Modified Files:
perl-Catalyst-View-Component-SubInclude.spec 
Log Message:
* Thu Jul 01 2010 Iain Arnell  0.09-3
- Require perl(Catalyst) >= 5.80014



Index: perl-Catalyst-View-Component-SubInclude.spec
===
RCS file: 
/cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/F-13/perl-Catalyst-View-Component-SubInclude.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-Catalyst-View-Component-SubInclude.spec1 Jul 2010 14:46:10 
-   1.1
+++ perl-Catalyst-View-Component-SubInclude.spec1 Jul 2010 15:13:10 
-   1.2
@@ -1,6 +1,6 @@
 Name:   perl-Catalyst-View-Component-SubInclude
 Version:0.09
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Use subincludes in your Catalyst views
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -10,6 +10,9 @@ BuildRoot:  %{_tmppath}/%{name}-%{ve
 BuildArch:  noarch
 BuildRequires:  perl(Catalyst::Action::RenderView)
 BuildRequires:  perl(Catalyst::Plugin::SubRequest)
+# perl-Catalyst-Runtime provides unversioned perl(Catalyst::Runtime)
+# Ensure that we really have a good version
+BuildRequires:  perl(Catalyst) >= 5.80014
 BuildRequires:  perl(Catalyst::Runtime) >= 5.80014
 BuildRequires:  perl(Catalyst::View::TT)
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -20,6 +23,9 @@ BuildRequires:  perl(MooseX::Types)
 BuildRequires:  perl(namespace::clean)
 BuildRequires:  perl(Test::More) >= 0.88
 Requires:   perl(Catalyst::Plugin::SubRequest)
+# perl-Catalyst-Runtime provides unversioned perl(Catalyst::Runtime)
+# Ensure that we really have a good version
+Requires:   perl(Catalyst) >= 5.80014
 Requires:   perl(Catalyst::Runtime) >= 5.80014
 Requires:   perl(MooseX::Types)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
@@ -62,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 01 2010 Iain Arnell  0.09-3
+- Require perl(Catalyst) >= 5.80014
+
 * Thu Jul 01 2010 Iain Arnell  0.09-2
 - remove automatically detected explicit requires
 

--
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-Catalyst-View-Component-SubInclude/devel perl-Catalyst-View-Component-SubInclude.spec, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3027/devel

Modified Files:
perl-Catalyst-View-Component-SubInclude.spec 
Log Message:
* Thu Jul 01 2010 Iain Arnell  0.09-3
- Require perl(Catalyst) >= 5.80014



Index: perl-Catalyst-View-Component-SubInclude.spec
===
RCS file: 
/cvs/pkgs/rpms/perl-Catalyst-View-Component-SubInclude/devel/perl-Catalyst-View-Component-SubInclude.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-Catalyst-View-Component-SubInclude.spec1 Jul 2010 14:46:11 
-   1.1
+++ perl-Catalyst-View-Component-SubInclude.spec1 Jul 2010 15:13:10 
-   1.2
@@ -1,6 +1,6 @@
 Name:   perl-Catalyst-View-Component-SubInclude
 Version:0.09
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Use subincludes in your Catalyst views
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -10,6 +10,9 @@ BuildRoot:  %{_tmppath}/%{name}-%{ve
 BuildArch:  noarch
 BuildRequires:  perl(Catalyst::Action::RenderView)
 BuildRequires:  perl(Catalyst::Plugin::SubRequest)
+# perl-Catalyst-Runtime provides unversioned perl(Catalyst::Runtime)
+# Ensure that we really have a good version
+BuildRequires:  perl(Catalyst) >= 5.80014
 BuildRequires:  perl(Catalyst::Runtime) >= 5.80014
 BuildRequires:  perl(Catalyst::View::TT)
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -20,6 +23,9 @@ BuildRequires:  perl(MooseX::Types)
 BuildRequires:  perl(namespace::clean)
 BuildRequires:  perl(Test::More) >= 0.88
 Requires:   perl(Catalyst::Plugin::SubRequest)
+# perl-Catalyst-Runtime provides unversioned perl(Catalyst::Runtime)
+# Ensure that we really have a good version
+Requires:   perl(Catalyst) >= 5.80014
 Requires:   perl(Catalyst::Runtime) >= 5.80014
 Requires:   perl(MooseX::Types)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
@@ -62,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 01 2010 Iain Arnell  0.09-3
+- Require perl(Catalyst) >= 5.80014
+
 * Thu Jul 01 2010 Iain Arnell  0.09-2
 - remove automatically detected explicit requires
 

--
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: Bodhi 0.7.5 release

[Adam Williamson]

On Thu, 2010-07-01 at 06:29 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > ...or convince enough others of your position that they will vote for
> > the candidates you favour in our leadership elections. Since there've
> > been several of these since you first stated you don't approve of
> > Fedora's leadership, it seems the electorate doesn't agree with you...
> 
> No. It means there haven't been enough such candidates. People did vote for 
> me. But alone against 8 people who didn't agree with me, I wasn't able to 
> achieve anything.

I voted for you, but given how you behaved when actually a member of
FESCo, I kind of came to regret it. I think your assessment is not
entirely correct. It wasn't because (or not entirely because) it was You
Versus 8, but because of how you conducted yourself in meetings and
discussions. Essentially, you were a large part of *making* it You
Versus 8, rather than nine people with various different opinions but
also some broad common ground.

This time I again made a point of voting for people who are not in 'the
cabal' (which doesn't exist, of course), but tried to pick ones who I
thought would work in productive and co-operative ways within FESCo.

> If you give people ballots with only Evil Dictator on them, of course Evil 
> Dictator will win. It doesn't say anything about the electorate.

I realize you're just drawing a rather shaky analogy and not suggesting
the other FESCo candidates were Evil Dictators, but even still, I don't
think this is an appropriate illustration of the process.
-- 
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

[Adam Williamson]

On Wed, 2010-06-30 at 18:38 -0400, Tom Lane wrote:

> 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma.  Is the
> restrictive policy in force for F-12 too?

As far as I'm aware, no. We're starting at F-13.
-- 
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

File Catalyst-Plugin-Unicode-Encoding-1.0.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

A file has been added to the lookaside cache for 
perl-Catalyst-Plugin-Unicode-Encoding:

ab6a5f204352c8fa56671aa12f33fee9  Catalyst-Plugin-Unicode-Encoding-1.0.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

rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-12 perl-Catalyst-Plugin-Unicode-Encoding.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-12
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3554/F-12

Modified Files:
.cvsignore sources 
Added Files:
perl-Catalyst-Plugin-Unicode-Encoding.spec 
Log Message:
initial import


--- NEW FILE perl-Catalyst-Plugin-Unicode-Encoding.spec ---
Name:   perl-Catalyst-Plugin-Unicode-Encoding
Version:1.0
Release:1%{?dist}
Summary:Unicode aware Catalyst
License:GPL+ or Artistic
Group:  Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-Plugin-Unicode-Encoding/
Source0:
http://www.cpan.org/authors/id/B/BO/BOBTFISH/Catalyst-Plugin-Unicode-Encoding-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch
BuildRequires:  perl(Catalyst) >= 5.80
BuildRequires:  perl(Class::Data::Inheritable)
BuildRequires:  perl(ExtUtils::MakeMaker)
BuildRequires:  perl(IO::Scalar)
BuildRequires:  perl(LWP) >= 5.828
BuildRequires:  perl(Test::More) >= 0.88
BuildRequires:  perl(URI) >= 1.36
# tests
BuildRequires:  perl(Test::Pod)
BuildRequires:  perl(Test::Pod::Coverage)
BuildRequires:  perl(Test::WWW::Mechanize::Catalyst)
Requires:   perl(Catalyst) >= 5.80
Requires:   perl(Class::Data::Inheritable)
Requires:   perl(LWP) >= 5.828
Requires:   perl(URI) >= 1.36
Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))

%{?perl_default_filter}

%description
On request, decodes all params from encoding into a sequence of logical
characters. On response, encodes body into encoding.

%prep
%setup -q -n Catalyst-Plugin-Unicode-Encoding-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

make pure_install DESTDIR=$RPM_BUILD_ROOT

find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;

%{_fixperms} $RPM_BUILD_ROOT/*

%check
TEST_POD=1 make test

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*

%changelog
* Wed Jun 30 2010 Iain Arnell  1.0-1
- Specfile autogenerated by cpanspec 1.78.


Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore  1 Jul 2010 05:00:03 -   1.1
+++ .cvsignore  1 Jul 2010 15:18:05 -   1.2
@@ -0,0 +1 @@
+Catalyst-Plugin-Unicode-Encoding-1.0.tar.gz


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Jul 2010 05:00:03 -   1.1
+++ sources 1 Jul 2010 15:18:06 -   1.2
@@ -0,0 +1 @@
+ab6a5f204352c8fa56671aa12f33fee9  Catalyst-Plugin-Unicode-Encoding-1.0.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: Bodhi 0.7.5 release

[Adam Williamson]

On Thu, 2010-07-01 at 01:26 -0400, Luke Macken wrote:
> On 07/01/2010 12:47 AM, Kevin Kofler wrote:
> > Jesse Keating wrote:
> >> There is a slight wrinkle in that right now, the bodhi code will
> >> automatically request a push of an item that reaches this karma threshold,
> >> and I don't believe there is a way yet to force it to wait for even
> >> greater amounts of karma.  I believe that fine grained tuning of karma
> >> automation is planned for the next major version (and rewrite) of bodhi.
> >
> > That's not a "slight wrinkle", that's a fatal showstopper which means this
> > change should never have hit production. I consider it completely
> > unacceptable for my updates to get promoted to stable when I didn't request
> > it (e.g. I disable karma automatism for all my updates).
> 
> If you disable karma automatism for your updates, they will not 
> automatically get promoted to stable upon critpath approval.

It would probably be good to advertise this more prominently somewhere.
I must admit I wasn't aware we still had this wrinkle - I assumed you'd
be getting it fixed this time around - and we should definitely alert
maintainers to it.

> > The way the workflow should work (*) is that:
> > * case 1: The maintainer requests the push to stable before the promotion is
> > approved. Then it will get withheld until approval. Once approval is
> > obtained, the push is automatically requested by Bodhi.
> 
> This is the workflow that occurs by default.
> 
> All critpath updates go to testing first, even if the maintainer chooses 
> stable.  It's tested and approved, then bodhi automatically promotes it 
> to stable.
> 
> > * case 2: The approval happens before a push to stable is requested. In that
> > case, the update is marked as approved and the maintainer can queue it to
> > stable at any time.
> > That's the only sane way to handle such approval, everything else is just
> > plain broken. (And isn't that how the security team approval works now? Why
> > is the proventester approval implemented differently?)
> 
> This is the workflow that occurs when you disable karma automatism.

Perhaps it would surprise people less if we made case 2 default for
critpath?
-- 
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

rpms/perl-Catalyst-Plugin-Unicode-Encoding/devel perl-Catalyst-Plugin-Unicode-Encoding.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3554/devel

Modified Files:
.cvsignore sources 
Added Files:
perl-Catalyst-Plugin-Unicode-Encoding.spec 
Log Message:
initial import


--- NEW FILE perl-Catalyst-Plugin-Unicode-Encoding.spec ---
Name:   perl-Catalyst-Plugin-Unicode-Encoding
Version:1.0
Release:1%{?dist}
Summary:Unicode aware Catalyst
License:GPL+ or Artistic
Group:  Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-Plugin-Unicode-Encoding/
Source0:
http://www.cpan.org/authors/id/B/BO/BOBTFISH/Catalyst-Plugin-Unicode-Encoding-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch
BuildRequires:  perl(Catalyst) >= 5.80
BuildRequires:  perl(Class::Data::Inheritable)
BuildRequires:  perl(ExtUtils::MakeMaker)
BuildRequires:  perl(IO::Scalar)
BuildRequires:  perl(LWP) >= 5.828
BuildRequires:  perl(Test::More) >= 0.88
BuildRequires:  perl(URI) >= 1.36
# tests
BuildRequires:  perl(Test::Pod)
BuildRequires:  perl(Test::Pod::Coverage)
BuildRequires:  perl(Test::WWW::Mechanize::Catalyst)
Requires:   perl(Catalyst) >= 5.80
Requires:   perl(Class::Data::Inheritable)
Requires:   perl(LWP) >= 5.828
Requires:   perl(URI) >= 1.36
Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))

%{?perl_default_filter}

%description
On request, decodes all params from encoding into a sequence of logical
characters. On response, encodes body into encoding.

%prep
%setup -q -n Catalyst-Plugin-Unicode-Encoding-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

make pure_install DESTDIR=$RPM_BUILD_ROOT

find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;

%{_fixperms} $RPM_BUILD_ROOT/*

%check
TEST_POD=1 make test

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*

%changelog
* Wed Jun 30 2010 Iain Arnell  1.0-1
- Specfile autogenerated by cpanspec 1.78.


Index: .cvsignore
===
RCS file: 
/cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore  1 Jul 2010 05:00:03 -   1.1
+++ .cvsignore  1 Jul 2010 15:18:06 -   1.2
@@ -0,0 +1 @@
+Catalyst-Plugin-Unicode-Encoding-1.0.tar.gz


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Jul 2010 05:00:03 -   1.1
+++ sources 1 Jul 2010 15:18:06 -   1.2
@@ -0,0 +1 @@
+ab6a5f204352c8fa56671aa12f33fee9  Catalyst-Plugin-Unicode-Encoding-1.0.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

rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-13 perl-Catalyst-Plugin-Unicode-Encoding.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3554/F-13

Modified Files:
.cvsignore sources 
Added Files:
perl-Catalyst-Plugin-Unicode-Encoding.spec 
Log Message:
initial import


--- NEW FILE perl-Catalyst-Plugin-Unicode-Encoding.spec ---
Name:   perl-Catalyst-Plugin-Unicode-Encoding
Version:1.0
Release:1%{?dist}
Summary:Unicode aware Catalyst
License:GPL+ or Artistic
Group:  Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-Plugin-Unicode-Encoding/
Source0:
http://www.cpan.org/authors/id/B/BO/BOBTFISH/Catalyst-Plugin-Unicode-Encoding-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch
BuildRequires:  perl(Catalyst) >= 5.80
BuildRequires:  perl(Class::Data::Inheritable)
BuildRequires:  perl(ExtUtils::MakeMaker)
BuildRequires:  perl(IO::Scalar)
BuildRequires:  perl(LWP) >= 5.828
BuildRequires:  perl(Test::More) >= 0.88
BuildRequires:  perl(URI) >= 1.36
# tests
BuildRequires:  perl(Test::Pod)
BuildRequires:  perl(Test::Pod::Coverage)
BuildRequires:  perl(Test::WWW::Mechanize::Catalyst)
Requires:   perl(Catalyst) >= 5.80
Requires:   perl(Class::Data::Inheritable)
Requires:   perl(LWP) >= 5.828
Requires:   perl(URI) >= 1.36
Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))

%{?perl_default_filter}

%description
On request, decodes all params from encoding into a sequence of logical
characters. On response, encodes body into encoding.

%prep
%setup -q -n Catalyst-Plugin-Unicode-Encoding-%{version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

make pure_install DESTDIR=$RPM_BUILD_ROOT

find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;

%{_fixperms} $RPM_BUILD_ROOT/*

%check
TEST_POD=1 make test

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*

%changelog
* Wed Jun 30 2010 Iain Arnell  1.0-1
- Specfile autogenerated by cpanspec 1.78.


Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-13/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore  1 Jul 2010 05:00:03 -   1.1
+++ .cvsignore  1 Jul 2010 15:18:06 -   1.2
@@ -0,0 +1 @@
+Catalyst-Plugin-Unicode-Encoding-1.0.tar.gz


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-13/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Jul 2010 05:00:03 -   1.1
+++ sources 1 Jul 2010 15:18:06 -   1.2
@@ -0,0 +1 @@
+ab6a5f204352c8fa56671aa12f33fee9  Catalyst-Plugin-Unicode-Encoding-1.0.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: Feature, Fedora 14: Go Programming

[Brandon Lozza]

http://www.pwnage.ca/dist/SRPMS
http://www.pwnage.ca/dist/RPMS

Working F13 packages are available if anyone wants to try or make comments
on them. (Might not meet package guidelines yet)

On Tue, Jun 29, 2010 at 11:27 AM, Brandon Lozza  wrote:

> I got it setup for the feature wrangler too
>
>
> On Mon, Jun 28, 2010 at 8:41 PM, Brandon Lozza  wrote:
>
>> https://fedoraproject.org/wiki/Features/Go_Programming
>>
>> Here is the
>> feature page
>>
>>
>> On Sun, Jun 27, 2010 at 10:58 PM, Rakesh Pandit 
>> wrote:
>>
>>> 2010/6/27 Brandon Lozza :
>>> > No I have not actually, didn't know I had to. I saw some other feature
>>> > requests here. Could you help me do this?
>>> >
>>> [..]
>>>
>>> If you want to start this feature, here are helpful instructions (links -
>>> FAQs):
>>> https://fedoraproject.org/wiki/Features/Policy
>>>
>>>
>>> --
>>> Rakesh Pandit
>>> https://fedoraproject.org/wiki/User:Rakesh
>>> freedom, friends, features, first
>>> --
>>> 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

rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-13 perl-Catalyst-Plugin-Unicode-Encoding.spec, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv5389/F-13

Modified Files:
perl-Catalyst-Plugin-Unicode-Encoding.spec 
Log Message:
* Thu Jul 01 2010 Iain Arnell  1.0-1.2
- disable Module::AutoInstall



Index: perl-Catalyst-Plugin-Unicode-Encoding.spec
===
RCS file: 
/cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-13/perl-Catalyst-Plugin-Unicode-Encoding.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-Catalyst-Plugin-Unicode-Encoding.spec  1 Jul 2010 15:18:06 -   
1.1
+++ perl-Catalyst-Plugin-Unicode-Encoding.spec  1 Jul 2010 15:31:50 -   
1.2
@@ -1,6 +1,6 @@
 Name:   perl-Catalyst-Plugin-Unicode-Encoding
 Version:1.0
-Release:1%{?dist}
+Release:1%{?dist}.2
 Summary:Unicode aware Catalyst
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -34,6 +34,8 @@ characters. On response, encodes body in
 %prep
 %setup -q -n Catalyst-Plugin-Unicode-Encoding-%{version}
 
+sed -i -e '/auto_install/d' Makefile.PL
+
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
@@ -61,5 +63,8 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 01 2010 Iain Arnell  1.0-1.2
+- disable Module::AutoInstall
+
 * Wed Jun 30 2010 Iain Arnell  1.0-1
 - Specfile autogenerated by cpanspec 1.78.

--
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-Catalyst-Plugin-Unicode-Encoding/F-12 perl-Catalyst-Plugin-Unicode-Encoding.spec, 1.1, 1.2

[Iain Arnell]

Author: iarnell

Update of /cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-12
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv5389/F-12

Modified Files:
perl-Catalyst-Plugin-Unicode-Encoding.spec 
Log Message:
* Thu Jul 01 2010 Iain Arnell  1.0-1.2
- disable Module::AutoInstall



Index: perl-Catalyst-Plugin-Unicode-Encoding.spec
===
RCS file: 
/cvs/pkgs/rpms/perl-Catalyst-Plugin-Unicode-Encoding/F-12/perl-Catalyst-Plugin-Unicode-Encoding.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-Catalyst-Plugin-Unicode-Encoding.spec  1 Jul 2010 15:18:05 -   
1.1
+++ perl-Catalyst-Plugin-Unicode-Encoding.spec  1 Jul 2010 15:31:49 -   
1.2
@@ -1,6 +1,6 @@
 Name:   perl-Catalyst-Plugin-Unicode-Encoding
 Version:1.0
-Release:1%{?dist}
+Release:1%{?dist}.2
 Summary:Unicode aware Catalyst
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -34,6 +34,8 @@ characters. On response, encodes body in
 %prep
 %setup -q -n Catalyst-Plugin-Unicode-Encoding-%{version}
 
+sed -i -e '/auto_install/d' Makefile.PL
+
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
@@ -61,5 +63,8 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 01 2010 Iain Arnell  1.0-1.2
+- disable Module::AutoInstall
+
 * Wed Jun 30 2010 Iain Arnell  1.0-1
 - Specfile autogenerated by cpanspec 1.78.

--
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: libjpeg-turbo conflicts in rawhide

[Toshio Kuratomi]

On Thu, Jul 01, 2010 at 02:26:57PM +0200, Adam Tkac wrote:
> On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote:
> > Hi all,
> 
> Hello,
> 
> > I'm trying to build a package that has a BuildRequires: libjpeg-devel in 
> > Rawhide [1].  I get a message in root.log that libjpeg-turbo-devel 
> > obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead.  
> > Unfortunately, when it pulls in dependencies for my other BuildRequires, 
> > it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict 
> > since they both provide libjpeg.so.62.0.0
> > 
> > The only thing I can think of is that one of the packages I'm requiring 
> > has an explicit dep on libjpeg (I'm about to investigate which).  For 
> > the time being, is there any to work around this?
> 
> I read this thread and
> https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two
> reasonable solutions for this problem:
> 
> 1. Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package
> which contains only libjpeg.so.62*. I believe this will solve both
> update and buildroot problems. However it also means all users of
> libjpeg programs (djpeg, cjpeg and friends) will need to manually
> install libjpeg-turbo-tools
> 
> 2. Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as
> done in libjpeg.
> 
> I must admit I like the first solution. People usually needs only
> libjpeg.so, not programs. People which need libjpeg programs can
> easily install libjpeg-turbo-tools package themselves, this
> "incompatibility" seems acceptable for me in development branch.
> 
> What is your opinion about this proposal?
> 
solution #1 seems like the logical choice.

-Toshio


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

Re: Seeking new maintainer for iasl

[Don Dutile]

Jon Ciesla wrote:
> On 07/01/2010 06:36 AM, Till Maas wrote:
>> On Thu, Jul 01, 2010 at 11:52:29AM +0100, Daniel P. Berrange wrote:
>>
>>> On Thu, Jul 01, 2010 at 12:49:27PM +0200, Till Maas wrote:
>>>  
 Hi,

 a long time ago I packaged iasl, because it is a BR for VirtualBox. I
 even received once a bug report for it, because someone used it for
 something else which did not work. Since I do not know what to do with
 it and I am not involved in packaging VirtualBox anymore, the package
 might be better off with someone who knows more about it, because there
 are still new releases made for it afaics.

 So if someone uses this package, please tell me and I will orphan it:
 https://admin.fedoraproject.org/pkgdb/acls/name/iasl

>>> It is a BuildRequires for KVM/QEMU still.
>>>  
>> I never knew that, but I just checked and this stopped after F10 for kvm
>> and F11 for qemu.
>>
>> Regards
>> Till
>>
> repoquery --repoid=rawhide-source --archlist=src --whatrequires iasl 
> returns nothing.  It looks like we may not need it for anything else, 
> though it may have value to developers for other things.
> 
used to decode DMAR tables in BIOS (intel-iommu cfg info) when there are
'bios features'.  

> If you don't want to maintain it, I can packagemonkey it and keep it up 
> to date, unless someone with more use for it or knowledge of it steps up.
> 
> -J
> 

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

Re: Seeking new maintainer for iasl

[M A Young]

On Thu, 1 Jul 2010, Jon Ciesla wrote:

> repoquery --repoid=rawhide-source --archlist=src --whatrequires iasl returns 
> nothing.  It looks like we may not need it for anything else, though it may 
> have value to developers for other things.

For me it finds 3 packages,
iasl-0:20090123-3.fc12.src
bochs-0:2.4.5-1.fc14.src
xen-0:4.0.0-2.fc14.src

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

Re: Seeking new maintainer for iasl

[seth vidal]

On Thu, 2010-07-01 at 17:14 +0100, M A Young wrote:
> On Thu, 1 Jul 2010, Jon Ciesla wrote:
> 
> > repoquery --repoid=rawhide-source --archlist=src --whatrequires iasl 
> > returns 
> > nothing.  It looks like we may not need it for anything else, though it may 
> > have value to developers for other things.
> 
> For me it finds 3 packages,
> iasl-0:20090123-3.fc12.src
> bochs-0:2.4.5-1.fc14.src
> xen-0:4.0.0-2.fc14.src
> 


I get the same list.

-sv


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

Re: Seeking new maintainer for iasl

[Jon Ciesla]

On 07/01/2010 09:58 AM, Matthew Garrett wrote:
> On Thu, Jul 01, 2010 at 08:54:01AM -0500, Jon Ciesla wrote:
>
>
>> repoquery --repoid=rawhide-source --archlist=src --whatrequires iasl
>> returns nothing.  It looks like we may not need it for anything else,
>> though it may have value to developers for other things.
>>  
> Under some circumstances it can end up being used in the seabios build,
> but I don't think it's a requirement right now.
>
>
>> If you don't want to maintain it, I can packagemonkey it and keep it up
>> to date, unless someone with more use for it or knowledge of it steps up.
>>  
> I use it on a pretty much daily basis and recently got hit by a bug that
> was fixed in a later release, so I'll happily take it if you're not
> hugely enthusiastic about looking after it.
>
>
I think you'd be a better candidate.  Have at.

-J

-- 
- in your fear, speak only peace
   in your fear, seek only love

-d. bowie

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

Re: Seeking new maintainer for iasl

[Jon Ciesla]

On 07/01/2010 11:17 AM, seth vidal wrote:
> On Thu, 2010-07-01 at 17:14 +0100, M A Young wrote:
>
>> On Thu, 1 Jul 2010, Jon Ciesla wrote:
>>
>>  
>>> repoquery --repoid=rawhide-source --archlist=src --whatrequires iasl returns
>>> nothing.  It looks like we may not need it for anything else, though it may
>>> have value to developers for other things.
>>>
>> For me it finds 3 packages,
>> iasl-0:20090123-3.fc12.src
>> bochs-0:2.4.5-1.fc14.src
>> xen-0:4.0.0-2.fc14.src
>>
>>  
>
> I get the same list.
>
> -sv
>
>
>
Wierd.  Wonder how I missed that.  Anyway, I have an interest in it's 
existing, as I co-maintain and will eventually probably take over bochs, 
but I'll let Mr. Garrett handle it.  I can certainly help out if 
needed.  I may even apply to co-maintain.

-J

-- 
- in your fear, speak only peace
   in your fear, seek only love

-d. bowie

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

[no subject]

[Toshio Kuratomi]

libart_l...@fedoraproject.org, liboil-ow...@fedoraproject.org,
librs...@fedoraproject.org
Bcc: 
Subject: A few orphaned desktop/graphics packages
Reply-To: 

The following packages related to graphics and the desktop have been
orphaned by Behdad::

'eog', 'gthumb', 'libart_lgpl', 'liboil', 'librsvg2'

Each of these has a large number of people with commit rights on the package
(members of the desktop group, I believe.)  liboil has a maintianer in
devel but not the other active branches.  If someone would like to step up
to become the official maintainer (to have the power to approve new acl
requests and to be the person who deals with bugs entered in bugzilla) that
would be great.

-Toshio


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

Orphaned packages (was Re:)

[Siddhesh Poyarekar]

On Thu, Jul 01, 2010 at 01:07:02PM -0400, Toshio Kuratomi wrote:
> libart_l...@fedoraproject.org, liboil-ow...@fedoraproject.org,
> librs...@fedoraproject.org
> Bcc: 
> Subject: A few orphaned desktop/graphics packages
> Reply-To: 
> 
> The following packages related to graphics and the desktop have been
> orphaned by Behdad::
> 
> 'eog', 'gthumb', 'libart_lgpl', 'liboil', 'librsvg2'
> 

I'll take eog.


--
Siddhesh


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

[Bug 582163] Review Request: perl-Test-Smoke - Perl core test smoke suite

[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=582163

--- Comment #8 from Jason Tibbitts  2010-07-01 13:33:39 EDT 
---
CVS done (by process-cvs-requests.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.
--
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: How to lure me to updates-testing

[Richard Hughes]

On 1 July 2010 16:07, Adam Williamson  wrote:
>> This would make more sense if PK was a fedora-tool - but PK is targeted
>> to be cross-distro - and integrating bodhi-reporting would not be
>> cross-distro.
>>
>> So, if you want to make this work we'll need someway to plugin AROUND
>> PK.

I disagree here. This isn't a Fedora specific problem, and I've got no
problem adding distro specific API to PK to make some stuff possible

> Good point. I guess in my head it already worked that way. =)

Then you've got to deal with the authentication. Boo.

>> Might be worth having some time with Richard to discuss how that should
>> happen.
>
> Sounds reasonable.

Sure, send me an email to my rh email, and we'll schedule a conf call.

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

Re: How to lure me to updates-testing

[seth vidal]

On Thu, 2010-07-01 at 18:47 +0100, Richard Hughes wrote:
> On 1 July 2010 16:07, Adam Williamson  wrote:
> >> This would make more sense if PK was a fedora-tool - but PK is targeted
> >> to be cross-distro - and integrating bodhi-reporting would not be
> >> cross-distro.
> >>
> >> So, if you want to make this work we'll need someway to plugin AROUND
> >> PK.
> 
> I disagree here. This isn't a Fedora specific problem, and I've got no
> problem adding distro specific API to PK to make some stuff possible

I didn't say the general problem was fedora-specific - but I think bodhi
is a fedora-specific solution.

sorry for the confusion.
-sv


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

who is Petr Pisar from redhat ?

[Chitlesh GOORAH]

Hello there,

I would appreciate if someone else who is NEITHER a co-maintainer NOR
FESCo member don't version bump my packages, without notifying me.

Petr Pisar seems to mess with my packages.

It's simply disgusting !!

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

Re: who is Petr Pisar from redhat ?

[seth vidal]

On Thu, 2010-07-01 at 21:09 +0200, Chitlesh GOORAH wrote:
> Hello there,
> 
> I would appreciate if someone else who is NEITHER a co-maintainer NOR
> FESCo member don't version bump my packages, without notifying me.
> 
> Petr Pisar seems to mess with my packages.
> 
> It's simply disgusting !!

1. 'disgusting' seems a bit strong - you sure that word is what you
wanted to choose?

2. maybe instead of calling it out on the list in public you could email
him and ask?

try to be excellent, please.
-sv


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

Re: CVS admin requests

[Kevin Fenzi]

On Sat, 26 Jun 2010 11:21:06 +0200
Michael Schwendt  wrote:

> The page "Package Change Requests for existing packages" is unclear:
> 
> http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#Package_Change_Requests_for_existing_packages
> 
> Please expand on what "explanatory text" you want in addition to the
> "Package Change Request" template. If there is a branch request,
> e.g.  for a released dist version, is it necessary to transcribe the
> filled out template into a full sentence?

Well, I'm not sure how to rephrase that... Basically we want to know
if there are any non standard conditions to look at, ie: 

- You are not the owner and want to maintain in epel. Did you contact
  the fedora owner and wait and/or hear back that they didn't want to
  maintain it?

- Is the package a dead package you are bringing back?

etc. 

You don't need to add additional text for normal vanilla regular
requests. It just saves cvsadmins the time to ask you what you want. 

kevin


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

Re: Bodhi 0.7.5 release

[Kevin Fenzi]

On Wed, 30 Jun 2010 18:38:03 -0400
Tom Lane  wrote:

> I see that libtiff.fc13 and libpng.fc13 are now showing "critical path
> approved", for which I thank those who did the work. 

Thanks. ;) 

>  I remain a bit
> unclear about a couple of things:
> 
> 1. Bodhi is showing both packages as requested push-to-stable.  Which
> *I* certainly didn't do, and considering they are only at +2 karma,
> this means that the threshold for auto-push is actually lower than it
> was before, not higher.  WTF?  Is the idea here to remove every last
> vestige of the maintainer's judgment from the process?

No. Please stop assuming everything in a negative light. ;)

This looks like a bug to me... if you didn't request stable, it
shouldn't go yet. I can talk to Luke about it, perhaps you could file a
bodhi bug on it?

> 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma.  Is
> the restrictive policy in force for F-12 too?  I'm even less willing
> to believe that we have enough testing manpower to cover both back
> branches right away.

Yes, it does appear to be there as well. 

I am just ramping up my f12 test machine now... but yeah, it's not
clear that we intended this to go live for f12 too. ;( 

kevin


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

Re: Bodhi 0.7.5 release

[Luke Macken]

On 07/01/2010 03:38 PM, Kevin Fenzi wrote:
> On Wed, 30 Jun 2010 18:38:03 -0400
> Tom Lane  wrote:
>
>> I see that libtiff.fc13 and libpng.fc13 are now showing "critical path
>> approved", for which I thank those who did the work.
>
> Thanks. ;)
>
>>   I remain a bit
>> unclear about a couple of things:
>>
>> 1. Bodhi is showing both packages as requested push-to-stable.  Which
>> *I* certainly didn't do, and considering they are only at +2 karma,
>> this means that the threshold for auto-push is actually lower than it
>> was before, not higher.  WTF?  Is the idea here to remove every last
>> vestige of the maintainer's judgment from the process?
>
> No. Please stop assuming everything in a negative light. ;)
>
> This looks like a bug to me... if you didn't request stable, it
> shouldn't go yet. I can talk to Luke about it, perhaps you could file a
> bodhi bug on it?

There /was/ a bug with the initial release that left a small window of 
time where updates would have been auto-promoted even if karma 
automatism was enabled.  This has since been resolved.

>> 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma.  Is
>> the restrictive policy in force for F-12 too?  I'm even less willing
>> to believe that we have enough testing manpower to cover both back
>> branches right away.
>
> Yes, it does appear to be there as well.
>
> I am just ramping up my f12 test machine now... but yeah, it's not
> clear that we intended this to go live for f12 too. ;(

It also wasn't clear that this was supposed to be for F13 only :(
Right now bodhi treats *all* critical path packages the same, across all 
releases.

If we only want this policy to be in place for F13, then I'm sure I 
could hack around it.

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

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/1/10 2:48 AM, Till Maas wrote:
> How do you know who is a minority and who is not? I still wonder why
> there are so many claims that the majority of Fedora maintainers or
> users want to manually test all updates, but still the majority is not
> involved in testing the updates. When the discussion started, it was
> claimed that submitting karma was too complicated and took too much
> time. This is not the case for several months, but still there are
> updates that do not receive any karma for more than a month. The last
> Bodhi statistics showed 595 unique karma submitters for F13 and there
> seem to be 1035 approved packagers currently in Fedora. So if only
> packagers submitted karma, it would be the majority. But since there are
> a lotsmore users and also dedicated testers for Fedora, it does not look
> like a majority anymore.
> 

Simply, if it's not mandatory, it's too easy to be lazy and not do it.
But when it is mandatory, more people participate.

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

iEYEARECAAYFAkwtBRMACgkQ4v2HLvE71NWXDQCgxUX/5EQwNK4TVASuAqK39ORI
VKEAnjaND4F98KB0XtEjDeY+wOCdOP+q
=RMEJ
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[Till Maas]

On Thu, Jul 01, 2010 at 02:13:59PM -0700, Jesse Keating wrote:
> On 7/1/10 2:48 AM, Till Maas wrote:
> > How do you know who is a minority and who is not? I still wonder why
> > there are so many claims that the majority of Fedora maintainers or
> > users want to manually test all updates, but still the majority is not
> > involved in testing the updates. When the discussion started, it was
> > claimed that submitting karma was too complicated and took too much
> > time. This is not the case for several months, but still there are
> > updates that do not receive any karma for more than a month. The last
> > Bodhi statistics showed 595 unique karma submitters for F13 and there
> > seem to be 1035 approved packagers currently in Fedora. So if only
> > packagers submitted karma, it would be the majority. But since there are
> > a lotsmore users and also dedicated testers for Fedora, it does not look
> > like a majority anymore.
> > 
> 
> Simply, if it's not mandatory, it's too easy to be lazy and not do it.
> But when it is mandatory, more people participate.

Do the participate because they care or because they have to to get the
things they care about done, when it is mandatory? I am very convinced
that people who care about something will do it nonetheless, even if it
is not mandatory and people who do something only because it is
mandatory will perform not as good as convinced people, i.e. "bend" the
rules to achieve what needs to be achieved with as little effort as
possible instead of trying to be as good as one can be. I also found
some other interesting number. According to
http://fedoraproject.org/wiki/File:Accounts_2010-02.jpg there are more
than 25.000 active Fedora Accounts. So for a majority there would be
more than 12.500 people wanting manual testings and only about 5% of this
interested people care enough to submit at least one karma comment in
Bodhi for Fedora 13. And
http://fedoraproject.org/wiki/Statistics#Who_uses_Fedora.3F claims that
even millions of people use Fedora. But I guess somehow it boils down to
"the majority wants that other people to work for them", which might
even be true. But in a FOSS community I doubt it is very healthy to
follow this too much.

Regards
Till


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

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/1/10 2:55 PM, Till Maas wrote:
> But I guess somehow it boils down to
> "the majority wants that other people to work for them", which might
> even be true. But in a FOSS community I doubt it is very healthy to
> follow this too much.
> 

I bet if we stopped making package reviews mandatory, none would get
done.  This follows the same.

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

iEYEARECAAYFAkwtEyAACgkQ4v2HLvE71NXm3gCaA5I3IvWDhjkKEzaZFZXgjVRg
sEYAoMRRWlHg9IXSHr3WuvvN/fTWZFe7
=Skyz
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

concept of package "ownership"

[Dave Airlie]

So I've noticed maintainers of packages in Fedora seem to have a concept
of ownership, and I'm wondering if we could remove that word from usage
about maintainership.

I'm come from working as a maintainer in the kernel, and its long been
said that kernel maintainers don't *own* the code, they are merely the
stewards of the code and the code belongs to everyone. Linus reminds you
of this by routinely doing stuff to code behind your back and when you
give out he reminds you that maintainership doesn't imply ownership.

I see Fedora maintainers as doing things on behalf of the Fedora
project, and not merely providing the Fedora project with stuff they
own, but I see a lot of others see "me owns this package" as the
priority not "me enjoys maintaining things on behalf of Fedora".

Dave.

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

Re: Bodhi 0.7.5 release

[Dave Airlie]

On Thu, 2010-07-01 at 11:48 +0200, Till Maas wrote:
> On Thu, Jul 01, 2010 at 05:23:06PM +1000, Dave Airlie wrote:
> > On Thu, 2010-07-01 at 07:00 +0200, Kevin Kofler wrote:
> > > Dave Airlie wrote:
> > > > So in your mind, there is a majority of people on your side, but they
> > > > are just too lazy to stand for election and take over the board?
> > > 
> > > s/too lazy/too busy doing actual work/
> > > (as opposed to wasting their time with politics or bureaucracy)
> > > 
> > > Have you noticed that all the people who are complaining about the 
> > > policies 
> > > are highly experienced packagers?
> > > 
> > > And there are actually many more people disagreeing with those broken 
> > > policies than the ones you notice on the ML, they just don't have the 
> > > time 
> > > to write mails to complain about them. (For example, rumors are that 
> > > several 
> > > people in the Brno RH office share my concerns.)
> > 
> > but these people are still in a minority. you are living in a fallacy.
> 
> How do you know who is a minority and who is not? I still wonder why

I think the fact that there is about x:1 people standing for the
board/fesco with one view vs the other. The same reasons Kevin gives for
nobody who shares his view as having motiviation for running for the
board, can just as easily be applied to everyone who doesn't share his
view. As one of the people who is too "busy doing actual work" to run
for the board I see my views reflected by the x members of the
board/fesco as opposed to the one. So it probably stacks up like a the
majority of people don't care, the next sizeable minority agree with the
decision, and the final group disagree and make most noise, and hence
seem to imply they are largest.

Dave.

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

Re: concept of package "ownership"

[Roland McGrath]

I agree.  The relevant concept is not "owner", but "sucker", or "victim".
When businessspeak people say someone "owns" a piece of work, what they
mean is to identify the person as the recipient of problems, complaints,
pleas for help, and perhaps even, rarely, praise, regarding the state of
the work.  We don't own the code, the code owns us.  It knows where we
live, and it keeps bringing people over and expecting us to feed them.

When a robot sends me email via an alias that ends with "-owner",
I never, ever, get the feeling that I am the one in charge.


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

Re: concept of package "ownership"

[Kevin Kofler]

Dave Airlie wrote:
> So I've noticed maintainers of packages in Fedora seem to have a concept
> of ownership, and I'm wondering if we could remove that word from usage
> about maintainership.

+1

IMHO any sponsored packager should be free to do changes which benefit the 
Fedora Project to any package, no matter who officially maintains the 
package. And such changes include things like upgrading the package to the 
current upstream release in Rawhide, especially when that release is needed 
for other packages. Even a provenpackager can't always make such changes 
without getting yelled at.

I think we need to get rid of the concept of ownership entirely, that'd also 
make orphaned or de-facto orphaned packages less of a problem. You see a 
problem, you fix it. Who cares whether the package has an active maintainer 
or not?

Kevin Kofler

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

Re: Evolution update in F13

[Kevin Kofler]

Ralf Corsepius wrote:
> To me this is a clear case of package-push which should not have
> happened and is not related to karma votes at all.

+1. The proper solution to prevent this kind of issues 100% reliably is to 
implement AutoQA, the only decent part of the Update Proposal and the one 
which is still vaporware. Rushing the silly proventesters nonsense is only a 
bandaid which is not even guaranteed to prevent all broken dependencies, 
automatic enforcement is.

Kevin Kofler

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

Re: Evolution update in F13

[Kevin Kofler]

Kevin Fenzi wrote:
> It's only in updates-testing yet.

Now this is complete nonsense. The update is required to fix broken 
dependencies so it should go to stable IMMEDIATELY.

Kevin Kofler

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

Re: rebuild of wxGTK without the internal crash handler in Rawhide

[Kevin Kofler]

Dan Horák wrote:
> I will rebuild wxGTK without the internal crash handler for the the
> devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
> apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
> this change affects all applications linked with wxGTK, because one
> symbol is removed from the "base" library. I will take care of
> rebuilding the packages in the next days, but the package owners should
> still check what is their implementation of the
> wxApp::OnFatalExpection() virtual method doing, because it will not be
> called anymore. Usually it is used to display the wxGTK-based crash
> report. Please let me know if you want to rebuild the package yourself
> or if you have some questions.

Do you really think this is a good idea? IMHO crash reports should go 
upstream, so using upstream's crash handler is a much better idea. ABRT 
spams our downstream Bugzilla with crash reports which really should go 
upstream instead. It's also technically nicer for the crash handler to be in 
the app, since it prevents having to dump core and then having an external 
process inspect the core dump.

FWIW, we have no plans to disable KCrash/DrKonqi in KDE at this time. We're 
already having enough trouble with the small percentage of crashes which 
makes it through to ABRT for whatever reason (non-GUI KDE apps (which cannot 
currently use KCrash because it's in kdeui), kdesupport stuff, recurring 
crashes in autorespawned stuff like plasma-desktop (where KCrash gets 
disabled on respawn to prevent infinite respawning loops), KCrash itself 
crashing (ugh!)), since those are still hundreds of bugs!

Kevin Kofler

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

Re: Evolution update in F13

[Kevin Fenzi]

On Fri, 02 Jul 2010 03:46:29 +0200
Kevin Kofler  wrote:

> Kevin Fenzi wrote:
> > It's only in updates-testing yet.
> 
> Now this is complete nonsense. The update is required to fix broken 
> dependencies so it should go to stable IMMEDIATELY.

It's in stable now. The time in testing allowed us to fix and add
several more packages to it and confirm that it did indeed fix things. 

I know you don't like testing, but IMHO the delay was slight and the
ability to confirm the fixes and add some more made it very much worth
it. 

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"

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/1/10 6:18 PM, Kevin Kofler wrote:
> I think we need to get rid of the concept of ownership entirely, that'd also 
> make orphaned or de-facto orphaned packages less of a problem. You see a 
> problem, you fix it. Who cares whether the package has an active maintainer 
> or not?

While I agree that package "ownership" should not feel possessive, I do
strongly feel that there still should be some single person (or team I
suppose...) who is ultimately responsible for the package.  A place for
bug reports, for autoqa activity, for reviewing potential patches and
changes from other people, etc...

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

iEYEARECAAYFAkwtaF8ACgkQ4v2HLvE71NXCCwCgxoNtzgQ/DDpx78uI4jjodHSu
GTYAnAxN9OwDW/qnXMDnZKfp4zCNG8NO
=F1ef
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: concept of package "ownership"

[Kevin Fenzi]

On Fri, 02 Jul 2010 08:16:35 +1000
Dave Airlie  wrote:

> So I've noticed maintainers of packages in Fedora seem to have a
> concept of ownership, and I'm wondering if we could remove that word
> from usage about maintainership.

...snip...

I agree. I think 'stewards' or 'guardian' or something might be better,
but those don't quite work either. ;( 

The packages I steward for Fedora (with a few exceptions of things I
should orphan or the like) I use and enjoy using, and wish to make sure
they are in good shape for others to use and enjoy too. I think it's
always been the case that something you use and enjoy and want other
people to use and enjoy ends up handled much better than something you
"own" for other reasons. 

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"

[Adam Miller]

I don't think it really matters what we call it, I just think that
package maintainers are starting to get a sense of entitlement and I
feel that's counter productive to the open environment we're used to
and are trying to help continue to grow.

The package "owner" gets emails about cvs commits, so they are always
aware of what's going on and can review the changes to packages they
maintain. In the event of a discrepancy then the person receiving the
email obviously has an email account and can easily email the person
who made the edit in order to extend a friendly inquiry as to the
change. It doesn't need to be any more complicated than that.

I for one welcome co-maintainers because I'm a big fan of
collaboration and a sense of community, and if I can't trust my fellow
community member and contributor to help in the maintenance of
packages that I just so happen to have a bit flipped for in the pkgdb,
then I'm in the wrong place.

-AdamM

-- 
http://maxamillion.googlepages.com
-
()  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: concept of package "ownership"

[Kevin Fenzi]

On Thu, 01 Jul 2010 21:17:38 -0700
Jesse Keating  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 7/1/10 6:18 PM, Kevin Kofler wrote:
> > I think we need to get rid of the concept of ownership entirely,
> > that'd also make orphaned or de-facto orphaned packages less of a
> > problem. You see a problem, you fix it. Who cares whether the
> > package has an active maintainer or not?
> 
> While I agree that package "ownership" should not feel possessive, I
> do strongly feel that there still should be some single person (or
> team I suppose...) who is ultimately responsible for the package.  A
> place for bug reports, for autoqa activity, for reviewing potential
> patches and changes from other people, etc...

Agreed. While wandering provenpackagers or whoever can assist with
sticky issues, there needs to be a group of people who manage bugs,
build a relationship with upstream, follow upstream development, etc. 

So, while I think we should try and reduce the possessiveness of
"owning" packages, we still need a group of stewards or whatever for
packages. 


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"

[Tom Lane]

Kevin Fenzi  writes:
> Jesse Keating  wrote:
>> While I agree that package "ownership" should not feel possessive, I
>> do strongly feel that there still should be some single person (or
>> team I suppose...) who is ultimately responsible for the package.  A
>> place for bug reports, for autoqa activity, for reviewing potential
>> patches and changes from other people, etc...

> Agreed. While wandering provenpackagers or whoever can assist with
> sticky issues, there needs to be a group of people who manage bugs,
> build a relationship with upstream, follow upstream development, etc. 

Yeah.  There needs to be somebody in the Fedora community with a
long-term commitment to each package.  Perhaps the term "owner" is
politically incorrect but nonetheless there is always going to be
somebody who knows more about that package than anybody else in Fedora.
I think it's counterproductive to downgrade that responsibility,
or even worse pretend that it doesn't matter --- and Kevin's lead
statement in this thread is damn close to pretending that.  Sorry
Kevin, we are not interchangeable parts.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: concept of package "ownership"

[Ralf Corsepius]

On 07/02/2010 06:34 AM, Kevin Fenzi wrote:
> On Thu, 01 Jul 2010 21:17:38 -0700
> Jesse Keating  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 7/1/10 6:18 PM, Kevin Kofler wrote:
>>> I think we need to get rid of the concept of ownership entirely,
>>> that'd also make orphaned or de-facto orphaned packages less of a
>>> problem. You see a problem, you fix it. Who cares whether the
>>> package has an active maintainer or not?
>>
>> While I agree that package "ownership" should not feel possessive,
Should the name "owner" be an issue, why not call them by what they 
actually are, "maintainer" and "co-maintainer"?

> Agreed. While wandering provenpackagers or whoever can assist with
> sticky issues, there needs to be a group of people who manage bugs,
> build a relationship with upstream, follow upstream development, etc.
Agreed.

> So, while I think we should try and reduce the possessiveness of
> "owning" packages, we still need a group of stewards or whatever for
> packages.
We need groups, with "grouped privileges/acls" etc. It's essentially 
what e.g. the "perl-sig" originally was meant to be.

Unfortunately, technical limitations of Fedora's "packager 
infrastructure" so far have prevented to take full advantage of this 
(c.f. "Petr's" mass acl-changes in recent weeks).

Ralf

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

Re: concept of package "ownership"

[Kevin Fenzi]

On Fri, 02 Jul 2010 00:44:29 -0400
Tom Lane  wrote:

> Yeah.  There needs to be somebody in the Fedora community with a
> long-term commitment to each package.  Perhaps the term "owner" is
> politically incorrect but nonetheless there is always going to be
> somebody who knows more about that package than anybody else in
> Fedora. 

Sure. But they should also welcome others joining them, not say "I own
this package, its mine all mine!", IMHO. 

> I think it's counterproductive to downgrade that
> responsibility, or even worse pretend that it doesn't matter --- and
> Kevin's lead statement in this thread is damn close to pretending
> that.  Sorry Kevin, we are not interchangeable parts.

Which Kevin? I never intended to say any such thing... :)

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"

[David Woodhouse]

On Thu, 2010-07-01 at 23:28 -0500, Adam Miller wrote:
> I don't think it really matters what we call it, I just think that
> package maintainers are starting to get a sense of entitlement and I
> feel that's counter productive to the open environment we're used to
> and are trying to help continue to grow. 

Absolutely. I've often commented on this problem -- we really don't want
package maintainers to throw their toys out of the pram when someone
touches "their" package; this is a collaborative effort.

In the old days of RHL and beehive, I think we had it about right...
with the obvious exception that it was Red Hat only, but the attitude to
packaging was right, IMHO. There _was_ someone who knew most about a
package and was expected to deal with it most of the time, but it was
also perfectly reasonable for other people to work on the packages too.

Fedora seems to have regressed a lot in that respect, although it did
improve after we started approving ProvenPackagers.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

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

Re: who is Petr Pisar from redhat ?

[David Woodhouse]

On Thu, 2010-07-01 at 21:09 +0200, Chitlesh GOORAH wrote:
> 
> I would appreciate if someone else who is NEITHER a co-maintainer NOR
> FESCo member don't version bump my packages, without notifying me.
> 
> Petr Pisar seems to mess with my packages.
> 
> It's simply disgusting !!

You haven't provided enough information. What's _wrong_ with helping out
by packaging the latest version (I assume that's what he did?) Did he do
it only for rawhide, or also with updates for F-13 etc.? Was there a
good reason to upgrade? Are there open bugs which are fixed by the old
version? Was there a good reason _not_ to upgrade?

I see no fundamental reason why a Fedora packager shouldn't update a
Fedora package; without any further information my first inclination is
to think that you're being far too precious.

-- 
dwmw2

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

File Net-CIDR-Lite-0.21.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-Net-CIDR-Lite:

12280b3754886b876918f03f53aee4f5  Net-CIDR-Lite-0.21.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

rpms/perl-Net-CIDR-Lite/EL-6 .cvsignore, 1.3, 1.4 perl-Net-CIDR-Lite.spec, 1.9, 1.10 sources, 1.3, 1.4

[Paul Howarth]

Author: pghmcfc

Update of /cvs/pkgs/rpms/perl-Net-CIDR-Lite/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31350

Modified Files:
.cvsignore perl-Net-CIDR-Lite.spec sources 
Log Message:
* Fri Jun  2 2010 Paul Howarth  - 0.21-1
- Update to 0.21
  - Fix spanner clean() docs (CPAN RT#14535)
  - Undef dereference with empty object (CPAN RT#25898)
  - Add short_list_range() method (CPAN RT#30777)
  - clean() or list() before add() causes error (CPAN RT#48308)
  - spanner add() did not accept non-object (CPAN RT#50042)
  - "::" not accepted as valid IPv6 address (CPAN RT#52571)
- Don't create license files



Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Net-CIDR-Lite/EL-6/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore  21 Mar 2006 22:12:44 -  1.3
+++ .cvsignore  2 Jul 2010 06:39:49 -   1.4
@@ -1 +1 @@
-Net-CIDR-Lite-0.20.tar.gz
+Net-CIDR-Lite-0.21.tar.gz


Index: perl-Net-CIDR-Lite.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-CIDR-Lite/EL-6/perl-Net-CIDR-Lite.spec,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- perl-Net-CIDR-Lite.spec 26 Jul 2009 13:38:44 -  1.9
+++ perl-Net-CIDR-Lite.spec 2 Jul 2010 06:39:49 -   1.10
@@ -1,6 +1,6 @@
 Name:   perl-Net-CIDR-Lite
-Version:0.20
-Release:6%{?dist}
+Version:0.21
+Release:1%{?dist}
 Summary:Net::CIDR::Lite Perl module
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -35,9 +35,6 @@ find $RPM_BUILD_ROOT -depth -type d -exe
 
 %{_fixperms} $RPM_BUILD_ROOT/*
 
-perldoc -t perlgpl > COPYING
-perldoc -t perlartistic > Artistic
-
 %check
 make test
 
@@ -46,19 +43,20 @@ rm -rf $RPM_BUILD_ROOT
 
 %files
 %defattr(-,root,root,-)
-%doc Changes README COPYING Artistic
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%doc Changes README
+%{perl_vendorlib}/Net/
+%{_mandir}/man3/Net::CIDR::Lite.3pm*
 
 %changelog
-* Sun Jul 26 2009 Fedora Release Engineering  
- 0.20-6
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
-
-* Thu Feb 26 2009 Fedora Release Engineering  
- 0.20-5
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
-
-* Thu Mar 06 2008 Tom "spot" Callaway  - 0.20-4
-Rebuild for new perl
+* Fri Jun  2 2010 Paul Howarth  - 0.21-1
+- Update to 0.21
+  - Fix spanner clean() docs (CPAN RT#14535)
+  - Undef dereference with empty object (CPAN RT#25898)
+  - Add short_list_range() method (CPAN RT#30777)
+  - clean() or list() before add() causes error (CPAN RT#48308)
+  - spanner add() did not accept non-object (CPAN RT#50042)
+  - "::" not accepted as valid IPv6 address (CPAN RT#52571)
+- Don't create license files
 
 * Wed Apr 18 2007 Steven Pritchard  0.20-3
 - Use fixperms macro instead of our own chmod incantation.


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Net-CIDR-Lite/EL-6/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 21 Mar 2006 22:12:45 -  1.3
+++ sources 2 Jul 2010 06:39:49 -   1.4
@@ -1 +1 @@
-54998db6b297ffc8a20adb91ea744200  Net-CIDR-Lite-0.20.tar.gz
+12280b3754886b876918f03f53aee4f5  Net-CIDR-Lite-0.21.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: Evolution update in F13

[Peter Hutterer]

On Fri, Jul 02, 2010 at 03:46:29AM +0200, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > It's only in updates-testing yet.
> 
> Now this is complete nonsense. The update is required to fix broken 
> dependencies so it should go to stable IMMEDIATELY.

people make mistakes. it happens, no big deal.

pushing it to testing helps to ensure the fix won't be another screwup but
really fixes the issue.

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