Bug 337791

There's not much to these channel packages.

rpmlint says:
  php-channel-symfony.noarch: W: no-documentation
which is true, but not a blocker.

I'm not sure your URL: is correct.  Shouldn't it point to symfony-project.com? 
phing.info seems to be the page for a different project.

I'm not even sure the channel.xml contains copyrightable content, but given that
the actual symfony-project software is all under the MIT license, are you sure
that LGPLv2 is proper?  Where do you find that documented?

* source file matches upstream:
   b5e1ea8f15922ce174428fc9b264a08434a81ee97a327fd84692bf042a218533  channel.xml
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
? license field matches the actual license.
* latest version is being packaged.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* rpmlint output is OK.
* final provides and requires are sane:
   php-channel(pear.symfony-project.com)
   php-channel-symfony = 1.0.0-1.fc8
  =
   /bin/sh
   /usr/bin/pear
   php-cli
   php-pear(PEAR)
* doesn't own any directories it shouldn't.
* no duplicates in %files (only one file!)
* file permissions are appropriate.
* scriptlets are OK (PEAR channel registration)

(In reply to comment #1)
[...]
> I'm not sure your URL: is correct.  Shouldn't it point to symfony-project.com? 
> phing.info seems to be the page for a different project.
> 
> I'm not even sure the channel.xml contains copyrightable content, but given that
> the actual symfony-project software is all under the MIT license, are you sure
> that LGPLv2 is proper?  Where do you find that documented?
[...]

Both issues you point out are mistakes I've made when copying the phing channel
spec file as a template for this one and not making the double check.

This should fix it:
Updated Spec URL:
http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SPECS/php-channel-symfony.spec
Updated SRPM URL:
http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SRPMS/php-channel-symfony-1.0.0-2.fc7.src.rpm

OK, the license looks good to me and the URL is correct.

APPROVED

New Package CVS Request
=======================
Package Name: php-channel-symfony
Short Description: Adds symfony project channel to PEAR
Owners: akahl
Branches: F-7 F-8
InitialCC: 
Cvsextras Commits: yes

All builds successful.

Package Change Request
======================
Package Name: pkgname
New Branches: EL-6
Owners: remi

This is a bit confusing.

"pkgname" obviously isn't what you intended to put there; I can guess, but as these are processed by a script, please do try to make proper requests.

I see the owner has recently changed so that you own this package.  However, since you won't own the EL-6 branch, we need an ack from remi.

I am sorry, here is the correct one. Remi asked me to create the branch, because he needs the channel for another package he has for EL-6. Would it help if I put myself also in as additional owner for EL-6 ?


Package Change Request
======================
Package Name: php-channel-symfony 
New Branches: EL-6
Owners: remi

@Jason : my RFE for this branch in EL-6 is bug #592528

And yes, I'm ok to maintain it in EPEL.

Great, although it would have been simpler to just raise the CVS flag in that bug as the explanation is all there.

CVS done.

(In reply to comment #10)
> Great, although it would have been simpler to just raise the CVS flag in that
> bug as the explanation is all there.
> 
> CVS done.    

I will remember for the next time. I was under the impression that they always should go on the review request. But the other bug makes obviously more sense.

We will find any ticket with the fedora-cvs flag set to '?'.  The intent is to keep folks from opening separate tickets just to request CVS, and the package review ticket works for this.  But if you have an existing ticket that actually contains useful context regarding the CVS request you're making, it of course makes sense to raise the fedora-cvs flag there.