Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component

2013-07-01 Thread andrea rota 
On Sun, Jun 30, 2013 at 12:29:57PM -0400, David Prévot wrote:
[...]
 FYI, I just uploaded a similar php-symfony-eventdispatcher taking into
 account the previous remarks.
 
 http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-eventdispatcher.git

thanks, this was very useful, especially for examples of overrides in
debian/rules.

i have pushed my changes, taking your feedback into account, to
http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-process.git;a=summary

On Sat, Jun 29, 2013 at 09:13:21PM -0400, David Prévot wrote:
[..]
 Here are some early thoughts after a quick overview of your package.
 
 On top of the s/2// already in discussion, please update debian/compat.
 
 What is the use of the explicit “Build-Depends-Indep: php-pear” in
 debian/control?

i was wondering myself :)
it was generated by debpear and i was hit by a sudden headeache when
trying to understand the Build-Depends-Indep field's purpose from the
new maintainer's guide... :)
i have now updated these based on your example.

 What is the use of override_dh_auto_configure, override_dh_auto_clean,
 and override_dh_auto_build in debian/rules?

legacy of an attempt to add a meta-package before discussing the
symfony/symfony2 issue in package names - removed now.

however, override_dh_auto_configure was taken from what i was previously
using as an example
(http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony2-yaml.git;a=blob;f=debian/rules;h=9a0185a4de308d6d6545464cbaaa9aa2778cee73;hb=HEAD)
and relates to my question below re package.xml contents: not sure if
this is useful/needed.

 Not sure it’s useful to enforce gbp default values (upstream-tag and
 pristine-tar).

you're right. i have only left upstream-tag since upstream use vX.Y.Z
whereas the default (at least in my local
git-buildpackage=0.6.0~git20130530) is in the X.Y.Z form. thanks.

 debian/watch shouldn’t miss the beta and RC.

thanks, updated.

 Please, drop the tests from the binary package, as well as
 phpunit.xml.dist, composer.json, CHANGELOG.md and the misplaced
 README.md (hint: you can compare the the two binary packages, the
 Composer and the PEAR one, to notice the differences).

thanks, updated as well.

the package.xml file is packaged intact so it does actually contain
XML elements for the removed files under Test - is this ok?

and finally, this package could be useful on CLI-only systems, however
when built as a composer package as in my first attempt, substvars made
it depend on php5 | php5-cli, whereas when building it as a PEAR
package, substvars make it depend on php5 only: short of adding this by
hand in debian/control, am i using substvars in a wrong way or is this
enforced by the phppear build system? i think it would be ok for these
components to depend on either, for use on systems without the full php5
meta-package installed.

thanks
andrea

-- 
andrea rota

Xelera - IT infrastructures
http://xelera.eu/contact-us/


signature.asc
Description: Digital signature

Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component

2013-06-29 Thread andrea rota 
On Sat, Jun 29, 2013 at 11:09:13AM +0800, Thomas Goirand wrote:
 On 06/29/2013 08:30 AM, andrea rota wrote:
  these three php-symfony-* packages i'm working on are dependencies for
  Composer, alongside two other PHP libraries which are only distributed
  via composer itself (not via any PEAR channels), whereas the Symfony
  components are distributed via both methods.
  
  i started packaging these Symfony components with the dh_phpcomposer
  helper as suggested previously on the pkg-php-pear list, but i see there
  are different opinions.
 
 My understanding of it isn't that there was 2 opinions, but that you
 didn't know about pear.symfony.com. I didn't really follow the
 dh_phpcomposer discussions, I'm sorry if that wasted some of your time.
 
  i can re-package the Symfony components from pear.symfony.com if that is
  the preferred method, of course.
 
 Yeah, please do!

here is a first attempt:
http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony2-process.git

[...]

On Sun, Jun 30, 2013 at 01:24:37AM +0800, Thomas Goirand wrote:
 On 06/28/2013 05:20 PM, Mathieu Parent wrote:
  Another thing: I have noticed that what is used as upstream source is
   quite wrong for all packages. They should all be coming from
   http://pear.symfony.com/. In there, you will find packages the way they
   should: including a package.xml, so that we can use the PEAR things to
   get them installed, have a registry file, manage dependencies
   automatically, etc. Missing the package.xml is simply wrong, IMO.
  Again, those are not PEAR pkg.
 
 I think there's a miss-understanding here. I'm saying that we should use
 what's in pear.symfony.com as it seems to be the same thing (and it
 seems to be the same version), but in a PEAR package format. Am I wrong?
 
 (I'm taking about php-symfony-process, I haven't looked at other
 packages yet)

pear.symfony.com seems complete to me, providing latest versions of all
the Symfony2 components also available via upstream git.

i have used the existing naming scheme for this Debian package
(php-symfony2-component), however this will clash with substvars
generated (for libraries from other sources only distributed via
composer) by dh_phpcomposer: in composer/packagist, these same Symfony2
packages are labelled (by the Symfony project) as 'symfony/component'
(e.g. symfony/process), which is correctly translated to
php-symfony-process by dh_phpcomposer.

I originally suggested using Provides: but Mathieu pointed out that
Provides is not versioned (and i can see this being an issue with some
fast-changing packages) - Mathieu suggested considering metapackages as
well, which should indeed work here. However, when i tried adding a
second binary package to debian/control for php-symfony2-process,
building failed:

-
dh clean --buildsystem=phppear --with phppear
   dh_testdir -O--buildsystem=phppear
   dh_clean -O--buildsystem=phppear
gbp:info: php-symfony2-process_2.3.1.orig.tar.gz does not exist, creating from 
'upstream/v2.3.1'
gbp:info: Exporting 'HEAD' to 
'/home/e402b82b49d23e6d2c7ff5f4ede872ab400fee6d/debian.org/packages/pkg-php/php-symfony2-process/build-area/php-symfony2-process-tmp'
gbp:info: Moving 
'/home/e402b82b49d23e6d2c7ff5f4ede872ab400fee6d/debian.org/packages/pkg-php/php-symfony2-process/build-area/php-symfony2-process-tmp'
 to 
'/home/e402b82b49d23e6d2c7ff5f4ede872ab400fee6d/debian.org/packages/pkg-php/php-symfony2-process/build-area/php-symfony2-proces$
-2.3.1'
 dpkg-buildpackage -rfakeroot -D -us -uc -i -I
dpkg-buildpackage: source package php-symfony2-process
dpkg-buildpackage: source version 2.3.1-1
dpkg-buildpackage: source changed by andrea rota a...@xelera.eu
 dpkg-source -i -I --before-build php-symfony2-process-2.3.1
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh clean --buildsystem=phppear --with phppear
   dh_testdir -O--buildsystem=phppear
   dh_clean -O--buildsystem=phppear
 dpkg-source -i -I -b php-symfony2-process-2.3.1
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building php-symfony2-process using existing 
./php-symfony2-process_2.3.1.orig.tar.gz
dpkg-source: warning: ignoring deletion of file Process-2.3.1/package.xml
dpkg-source: info: building php-symfony2-process in 
php-symfony2-process_2.3.1-1.debian.tar.gz
dpkg-source: info: building php-symfony2-process in 
php-symfony2-process_2.3.1-1.dsc
 debian/rules build
dh build --buildsystem=phppear --with phppear
   dh_testdir -O--buildsystem=phppear
   debian/rules override_dh_auto_configure
make[1]: Entering directory 
`/home/e402b82b49d23e6d2c7ff5f4ede872ab400fee6d/debian.org/packages/pkg-php/php-symfony2-process/build-area/php-symfony2-process-2.3.1'
dh_auto_configure -O--buildsystem=phppear
# Remove references of .gitignore
sed -i 's@^.*\.gitignore.*$@@' */package.xml
make[1]: Leaving directory 
`/home/e402b82b49d23e6d2c7ff5f4ede872ab400fee6d/debian.org/packages/pkg-php/php-symfony2-process/build-area/php-symfony2-process-2.3.1'

Bug#714173: [pkg-php-pear] Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component

2013-06-29 Thread David Prévot 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Le 29/06/2013 16:03, andrea rota a écrit :

 here is a first attempt:
 http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony2-process.git
[…]
 i have used the existing naming scheme for this Debian package
 (php-symfony2-component), however this will clash with substvars
 generated

Why bother with the spurious “2”, isn’t it installed into
/usr/share/php/Symfony/$Component/ anyway?

Regards

David

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJRz0B6AAoJEAWMHPlE9r08toMH/1R9jaaQ2vriqwNre+Af44z9
sawBU7clfEnNMB74X96WVvMKs7AVkjZFmtinSW1Wl1QL5IhW/N+CVKQR8JDk2NMv
qC5SDz+u09Z6kCm5VsaJoa/wrSmwnvnVN/GNkUIDyaKxauJZUU97xED4hN+ZXIUh
PXmr4ypFYeBM0vjhXAUfWOxsvgqtAVwNfwaorrCjirbCQd4yl0iQzdjwmQNHHoAL
jeAxQDn/LhpYskFVRwJgTSCdcVlsUTt4rIvZxYpy7ZnIpHCPfWuzAsX0Okb1+bgf
34gHReTsLv2XDVnrtbmo7nwz306NnZscrzVDDsNdWobbIjXu5GgaImKb0M0wnk8=
=+R58
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51cf407b.2070...@tilapin.org

Bug#714173: [pkg-php-pear] Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component

2013-06-29 Thread andrea rota 
On Sat, Jun 29, 2013 at 04:15:55PM -0400, David Prévot wrote:
[...]
  i have used the existing naming scheme for this Debian package
  (php-symfony2-component), however this will clash with substvars
  generated
 
 Why bother with the spurious “2”, isn’t it installed into
 /usr/share/php/Symfony/$Component/ anyway?

that would actually make things easier. seeing that work on symfony2
components has just started, this could be a good time for DDs in this
group to think about this, i guess.

if i'm not wrong, the bits of legacy Symfony (v1.x) currently in
Debian are:
* pear-symfony-project-channel (rdepends: php-symfony-yaml)
* php-symfony-yaml (rdepends: phpunit, php-aws-sdk)

so these bits are actually in active use (though the latest phpunit on
git.debian.org depends on the new php-symfony2-yaml package)

for everything else, and seeing that Symfony 1 is past EOL upstream,
dropping the '2' should work.

my 0.5 cents would go in favour of using php-symfony-component for any
upcoming packaging of Symfony2 components.

best
andrea

-- 
andrea rota

Xelera - IT infrastructures
http://xelera.eu/contact-us/


signature.asc
Description: Digital signature

Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component

2013-06-28 Thread andrea rota 
On Thu, Jun 27, 2013 at 07:51:01PM -0400, David Prévot wrote:
[...]
 Then, some nitpicking details:
 
 Framework should be framework in Description from debian/control.

thanks, this is fixed now.

 The email address of the upstream copyright holder should appear in
 debian/copyright.

ok, fixed.

 Please, consider renaming debian/php-symfony-process.docs and
 debian/php-symfony-process.install into debian/docs and debian/install
 (that will ease the comparison/copy between php-symfony- packages as
 long as they produce only one binary package).

very good point - fixed.

[...]

On Fri, Jun 28, 2013 at 10:14:31AM +0800, Thomas Goirand wrote:
[...]
 IMO, the long description should have:
 
  Symfony is a PHP framework, a set of tools and a development
  methodology.
 
 *after*
 
  This package provides the Process component, which executes commands in
  sub-processes.
 
 Because describing the Symfony framework should (IMO) appear in all
 description of all Symfony packages, and it may be better to read this
 way for anyone using the package. Also the paragraph which doesn't
 describe the Symfony framework should be, IMO, longer. The only words
 that are helpful are which executes commands in sub-processes (the
 rest is in the package name itself). Please extend this long description.

agreed - longdesc is updated. i personally find it easier to read the
generic Symfony framework description first and the component's
description second, but either way works well so i have updated control
according to your suggestion.

 Last, and that's the most important bit that *must* be fixed before
 upload, the resulting package doesn't depend on pear-symfony-channel. I
 don't think it is right to put: ${phpcomposer:Debian-require}. I am
 guessing it is because ${phppear:Debian-Depends},
 ${phppear:Debian-Recommends} and ${phppear:Debian-Breaks} are missing.
 It would also be a good idea to use ${phppear:summary} and
 ${phppear:description} if they produce a correct output (I didn't check
 if they do, sometimes we don't use them if they don't).

having followed this part of the thread between yourself and Mathieu, i
have left the phpcomposer substvars in place and have *not* added any
phppear ones.

Mathieu, you mentioned that the Symfony PEAR channel is out of date -
however, as Thomas pointed out, somehow confusingly there are two
distinct ones at different domains, and http://pear.symfony.com/ seems
indeed indeed up to date to me, with all components up to version 2.3.1.

however, to add to the confusion, upstream's PEAR packages use symfony2
as part of the package name, whereas upstream's composer.json data use
symfony. unless i'm missing something, Debian packages for these
Symfony(2) components could be generated either via phpcomposer or
phppear, although this needs to be done consistently (which is easy
since we're just starting and there aren't that many components).

i assume upstream provide both distribution methods for different use
cases (PEAR for system-wide installs, composer for in-project-folder
installs).

other than this, i think php-symfony-process should be in rather good
shape by now:
http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-process.git;a=summary

best,
andrea

-- 
andrea rota

Xelera - IT infrastructures
http://xelera.eu/contact-us/


signature.asc
Description: Digital signature

Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component

2013-06-28 Thread Thomas Goirand 
On 06/29/2013 12:28 AM, andrea rota wrote:
 i personally find it easier to read the
 generic Symfony framework description first and the component's
 description second

This has nothing to do with preference, but with the standards we have
in Debian. I always saw things in the order I am vouching for.

 having followed this part of the thread between yourself and Mathieu, i
 have left the phpcomposer substvars in place and have *not* added any
 phppear ones.
 
 Mathieu, you mentioned that the Symfony PEAR channel is out of date -
 however, as Thomas pointed out, somehow confusingly there are two
 distinct ones at different domains, and http://pear.symfony.com/ seems
 indeed indeed up to date to me, with all components up to version 2.3.1.

Yeah, the other one was from Symfony 1, and they created another one for
Symfony 2...

 however, to add to the confusion, upstream's PEAR packages use symfony2
 as part of the package name, whereas upstream's composer.json data use
 symfony. unless i'm missing something, Debian packages for these
 Symfony(2) components could be generated either via phpcomposer or
 phppear, although this needs to be done consistently (which is easy
 since we're just starting and there aren't that many components).

Please use stuff from PEAR channels. Otherwise it's not called a PEAR
package! :P

 i assume upstream provide both distribution methods for different use
 cases (PEAR for system-wide installs, composer for in-project-folder
 installs).
 
 other than this, i think php-symfony-process should be in rather good
 shape by now:
 http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-process.git;a=summary

I don't agree that it's in good shape. I think I have to insist here.
Your package should:
- depend on pear-symfony-channel (by the way, should it have been
pear-symfony2-channel???)
- depend on php-pear
- contain a .reg for the PEAR package

as for every other PEAR package...

Currently, you fail to respect these essentials rules for a PEAR
package, which means that the process Symfony package will appear as
not installed when doing pear list for the symfony channel. Eg:

For example:
# pear config-set default_channel symfony2
config-set succeeded
# pear list
Installed packages, channel pear.symfony.com:
=
Package Version State
Yaml2.2.1   stable

When I install your package, it should show here. It's not the case!

Please use the upstream tarball from here and not Git:
http://pear.symfony.com/get/Process-2.3.1.tgz

so that you can use the package.xml from the tarball, and do a normal
pear packaging. I don't even understand why something had to be done for
phpcomposer. Maybe you can explain?

and add the necessary ${phppear:Debian-Depends},
${phppear:Debian-Recommends} and ${phppear:Debian-Breaks} as I suggested.

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51cdd763.7080...@debian.org

Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component

2013-06-28 Thread andrea rota 
On Sat, Jun 29, 2013 at 02:35:15AM +0800, Thomas Goirand wrote:
[...]
  other than this, i think php-symfony-process should be in rather good
  shape by now:
  http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-process.git;a=summary
 
 I don't agree that it's in good shape. I think I have to insist here.
 Your package should:
 - depend on pear-symfony-channel (by the way, should it have been
 pear-symfony2-channel???)
 - depend on php-pear
 - contain a .reg for the PEAR package
 
 as for every other PEAR package...
 
 Currently, you fail to respect these essentials rules for a PEAR
 package, which means that the process Symfony package will appear as
 not installed when doing pear list for the symfony channel. Eg:
 
 For example:
 # pear config-set default_channel symfony2
 config-set succeeded
 # pear list
 Installed packages, channel pear.symfony.com:
 =
 Package Version State
 Yaml2.2.1   stable
 
 When I install your package, it should show here. It's not the case!
 
 Please use the upstream tarball from here and not Git:
 http://pear.symfony.com/get/Process-2.3.1.tgz
 
 so that you can use the package.xml from the tarball, and do a normal
 pear packaging. I don't even understand why something had to be done for
 phpcomposer. Maybe you can explain?
 
 and add the necessary ${phppear:Debian-Depends},
 ${phppear:Debian-Recommends} and ${phppear:Debian-Breaks} as I suggested.

these three php-symfony-* packages i'm working on are dependencies for
Composer, alongside two other PHP libraries which are only distributed
via composer itself (not via any PEAR channels), whereas the Symfony
components are distributed via both methods.

i started packaging these Symfony components with the dh_phpcomposer
helper as suggested previously on the pkg-php-pear list, but i see there
are different opinions.

i can re-package the Symfony components from pear.symfony.com if that is
the preferred method, of course.

can i depend on this even though it's not in sid yet?
http://anonscm.debian.org/gitweb/?p=pkg-php/pear-symfony2-channel.git;a=summary

pear-symfony-project-channel should be the obsolete one.

best
andrea

-- 
andrea rota

Xelera - IT infrastructures
http://xelera.eu/contact-us/


signature.asc
Description: Digital signature

Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component

2013-06-28 Thread Thomas Goirand 
On 06/29/2013 08:30 AM, andrea rota wrote:
 these three php-symfony-* packages i'm working on are dependencies for
 Composer, alongside two other PHP libraries which are only distributed
 via composer itself (not via any PEAR channels), whereas the Symfony
 components are distributed via both methods.
 
 i started packaging these Symfony components with the dh_phpcomposer
 helper as suggested previously on the pkg-php-pear list, but i see there
 are different opinions.

My understanding of it isn't that there was 2 opinions, but that you
didn't know about pear.symfony.com. I didn't really follow the
dh_phpcomposer discussions, I'm sorry if that wasted some of your time.

 i can re-package the Symfony components from pear.symfony.com if that is
 the preferred method, of course.

Yeah, please do!

 can i depend on this even though it's not in sid yet?
 http://anonscm.debian.org/gitweb/?p=pkg-php/pear-symfony2-channel.git;a=summary
 
 pear-symfony-project-channel should be the obsolete one.

Yes. The FTP masters will anyway accept pear-symfony2-channel first.

Thomas


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ce4fd9.7080...@debian.org

Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component

2013-06-27 Thread andrea rota 
an updated initial package is available on git.debian.org:

http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-process.git;a=summary

comments/sponsorship welcome :)

best
andrea

-- 
andrea rota

Xelera - IT infrastructures
http://xelera.eu/contact-us/


signature.asc
Description: Digital signature