Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component
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
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
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
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#714179: [pkg-php-pear] ITP: php-json-schema -- PHP implementation of JSON schema
On Fri, Jun 28, 2013 at 10:16:40AM +0800, Thomas Goirand wrote: On 06/28/2013 04:43 AM, andrea rota wrote: good point. i was starting directly from upstream's git, but have now updated the workflow to use both upstream git *and* pristine-tar as per http://www.eyrie.org/~eagle/journal/2013-04/001.html - tried on a fresh sid install and this now builds correctly for me there. If you use upstream Git, then I would suggest to use tags, and declare that in the debian/gbp.conf, plus provide a way in debian/rules to generate upstream tarball (I use ./debian/rules gen-orig-xz in my pcakges). thanks - this is very useful. in my local tests, i see that the upstream tarball is generated by git-buildpackage, but this is part of the whole build process and i couldn't find out how to just generate the upstream tarball. i had a look at some of your packages but couldn't find one with an example of tag-based upstream generation via task in debian/rules: could you point me to one i can use as an example? 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
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#714179: ITP: php-json-schema -- PHP implementation of JSON schema
Thomas, Prach, thanks for your advice: On Thu, Jun 27, 2013 at 11:53:17AM +0800, Thomas Goirand wrote: [...] zigo@d(ebian-sid)_ ~/sources/pkg-php-pear/php-json-schema/php-json-schema$ git-buildpackage dh clean --with phpcomposer dh_testdir dh_auto_clean dh_clean gbp:error: upstream/1.3.2 is not a valid treeish Are you using pristine-tar? If so, please push that branch, edit debian/gbp.conf to add the pristine-tar = True, and push all tags. good point. i was starting directly from upstream's git, but have now updated the workflow to use both upstream git *and* pristine-tar as per http://www.eyrie.org/~eagle/journal/2013-04/001.html - tried on a fresh sid install and this now builds correctly for me there. [...] On Thu, Jun 27, 2013 at 02:01:06PM +0700, Prach Pongpanich wrote: [...] Hi Andrea, I hope this help for creating a new git repository. [...] this tutorial is great! is it available online somewhere?! otherwise, it'd be great to have it added somewhere under http://wiki.debian.org/PHP/ for developers starting collaborating on pkg-php packages. thanks andrea -- andrea rota Xelera - IT infrastructures http://xelera.eu/contact-us/ signature.asc Description: Digital signature
Bug#714176: ITP: php-symfony-console -- Symfony PHP Framework - Console component
an initial package repo is available on git.debian.org: http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-console.git;a=summary comments/sponsorship welcome :) 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
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
Bug#714177: ITP: php-symfony-finder -- Symfony PHP Framework - Finder component
an updated initial package repo is available on git.debian.org: http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony-finder.git;a=summary comments/sponsorship welcome :) 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 - the Process component executes commands in sub-processes
Package: wnpp Severity: wishlist Owner: andrea rota a...@xelera.eu * Package name: php-symfony-process Version : 2.3.1 Upstream Author : Fabien Potencier fab...@symfony.com * URL : https://github.com/symfony/Process * License : MIT Programming Lang: PHP Description : Symfony2 PHP Framework - Process component: executes commands in sub-processes Symfony2 is a full stack, free software MVC Web Development Framework written in PHP. . This package provides the Process component, which executes commands in sub-processes. -- 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/20130626152346.18396.84840.report...@x12yad.0.lon.net.0x0b.net
Bug#714176: ITP: php-symfony-console -- Symfony2 PHP Framework - Console component: eases the creation of beautiful and testable command line interfaces
Package: wnpp Severity: wishlist Owner: andrea rota a...@xelera.eu * Package name: php-symfony-console Version : 2.3.1 Upstream Author : Fabien Potencier fab...@symfony.com * URL : https://github.com/symfony/Console * License : MIT Programming Lang: PHP Description : Symfony2 PHP Framework - Console component: eases the creation of beautiful and testable command line interfaces Symfony2 is a full stack, free software MVC Web Development Framework written in PHP. . This package provides the Console component, which eases the creation of beautiful and testable command line interfaces. -- 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/20130626154409.19249.57902.report...@x12yad.0.lon.net.0x0b.net
Bug#714177: ITP: php-symfony-finder -- Symfony2 PHP Framework - Finder component: finds files and directories via an intuitive fluent interface
Package: wnpp Severity: wishlist Owner: andrea rota a...@xelera.eu * Package name: php-symfony-finder Version : 2.3.1 Upstream Author : Fabien Potencier fab...@symfony.com * URL : https://github.com/symfony/Process * License : MIT Programming Lang: PHP Description : Symfony2 PHP Framework - Finder component: finds files and directories via an intuitive fluent interface Symfony2 is a full stack, free software MVC Web Development Framework written in PHP. . This package provides the Finder component, which finds files and directories via an intuitive fluent interface. -- 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/20130626154837.3002.59300.report...@x12yad.0.lon.net.0x0b.net
Bug#714178: ITP: php-jsonlint -- Validating parser of JSON data structures, written in PHP
Package: wnpp Severity: wishlist Owner: andrea rota a...@xelera.eu * Package name: php-jsonlint Version : 1.1.1 Upstream Author : Jordi Boggiano j.boggi...@seld.be * URL : https://github.com/Seldaek/jsonlint * License : MIT Programming Lang: PHP Description : Validating parser of JSON data structures, written in PHP JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages. These properties make JSON an ideal data-interchange language. . This package provides a validating parser of JSON files, written in PHP. -- 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/20130626160359.14044.96819.report...@x12yad.0.lon.net.0x0b.net
Bug#714179: ITP: php-json-schema -- PHP implementation of JSON schema
Package: wnpp Severity: wishlist Owner: andrea rota a...@xelera.eu * Package name: php-json-schema Version : 1.2.0 * URL : https://github.com/justinrainbow/json-schema * License : BSD-3-clause Programming Lang: PHP Description : PHP implementation of JSON schema JSON Schema defines the media type application/schema+json, a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it. JSON Schema is intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data. . This package provides a PHP library for validating JSON Structures against a given Schema. -- 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/20130626161148.20718.64454.report...@x12yad.0.lon.net.0x0b.net
Bug#714179: ITP: php-json-schema -- PHP implementation of JSON schema
i have pushed an initial version of the package to http://anonscm.debian.org/gitweb/?p=pkg-php/php-json-schema.git in this case i did not include the tests for the moment (and noted this in debian/TODO) as they require (via composer's require-dev) further composer packages not yet packaged in Debian. i have also uploaded the .dsc file here: http://mentors.debian.net/package/php-json-schema i had trouble with git-buildpackage on the first build attempt: invoking git-buildpackage only would fail with a git error: gbp:debug: ['git', 'ls-tree', 'upstream/1.3.2'] gbp:error: upstream/1.3.2 is not a valid treeish (in fact, the ref was listed correctly via git ls-tree 1.3.2, not via git ls-tree upstream/1.3.2 in my working dir) however, after building the package once with git-buildpackage --git-upstream-tree=1.3.2 i can now build the package with git-buildpackage only, on the same machine (couldn't try on a different VM yet) - i'm not sure why this is and how to correctly inform git-buildpackage of which ref to look for initially. thanks andrea -- andrea rota Xelera - IT infrastructures http://xelera.eu/contact-us/ signature.asc Description: Digital signature
Bug#692353: ITP: php-wpcli -- PHP PEAR module for a WordPress CLI interface
Package: wnpp Severity: wishlist Owner: andrea rota a...@xelera.eu * Package name: php-wpcli Version : 0.6.0 Upstream Author : scribu m...@scribu.net, Andreas Creten andr...@madewithlove.be * URL : http://wp-cli.org/ * License : MIT Programming Lang: PHP Description : PHP PEAR module for a WordPress CLI interface wp-cli is a set of command-line tools for managing WordPress installations. You can update plugins, set up multisite installs, manage users, interact with the database, manage themes, create posts and much more. It can be extented through plugins to let administrators manage even more aspects of a WordPress installation. -- 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/20121105102859.10755.50723.report...@x12yad.0.lon.net.0x0b.net
Bug#692353: ITP: php-wpcli -- PHP PEAR module for a WordPress CLI interface
hi Thomas, On Mon, Nov 05, 2012 at 09:33:44PM +0800, Thomas Goirand wrote: [...] It'd be great if you could have this package made using pkg-php-tools, and make sure you work together with the PKG PHP PEAR team (and have the package team maintained). If you never tried it, please try debpear, which will create a working package quickly! I'd be happy to review / sponsor such package if you need. thanks - i have prepared an initial package which works ok on a couple of production nodes: what would be the best way to make the code available for review? the upstream git repo (https://github.com/wp-cli/wp-cli) is not in the layout used by debpear once it extracts the pear package tgz (this is not in the pear.php.net channel so i fed the tarball downloaded via pear download wp-cli.github.com/pear/wpcl to debpear for the initial debian/ folder setup) so i can't simply fork it and add the work-in-progress debian/ folder to my fork - shall i just create a git repo with the full tree - unpacked upstream tgz and debian folder - i have on my working dir now? thank you, andrea -- andrea rota Xelera - IT infrastructures http://xelera.eu/contact-us/ signature.asc Description: Digital signature
Bug#692353: ITP: php-wpcli -- PHP PEAR module for a WordPress CLI interface
hi Thomas, On Tue, Nov 06, 2012 at 03:24:17AM +0800, Thomas Goirand wrote: On 11/06/2012 12:28 AM, andrea rota wrote: thanks - i have prepared an initial package which works ok on a couple of production nodes: what would be the best way to make the code available for review? Upload the package somewhere (it doesn't have to be mentors.debian.net, as long as download is fast enough), and give the link to the .dsc file (that file is the result of a dpkg-buildpackage, and it links to the .orig.tar.gz and debian.tar.gz files, which will be downloaded automatically by dget). ok - my first attempt is now on mentors.debian.net (http://mentors.debian.net/package/php-wpcli) and i can already see some obvious issues that had escaped my attention when looking at lintian's output in the terminal - including the fact that it seems that a git submodule of the upstream repo (src/php/php-cli-tools) should probably be packaged separately :S the upstream git repo (https://github.com/wp-cli/wp-cli) is not in the layout used by debpear once it extracts the pear package tgz (this is not in the pear.php.net channel so i fed the tarball downloaded via pear download wp-cli.github.com/pear/wpcl to debpear for the initial debian/ folder setup) so i can't simply fork it and add the work-in-progress debian/ folder to my fork - shall i just create a git repo with the full tree - unpacked upstream tgz and debian folder - i have on my working dir now? I would advise you to read this: http://pkg-php.alioth.debian.org/ and do what is advised there. I wrote that page, feel free to be critic about it, and ask me to rewrite parts of it if you don't understand some of it. Extracting the upstream tar.gz in the upstream-sid branch is what I would do, another way is to do like here (I'm also in the Openstack packaging team in Debian), which is a very good workflow as well: http://openstack.alioth.debian.org/ what's cool is that it uses upstream git tags. ok, that's great. i love git awesomeness. my first packaging attempt did not use any of this - i'll give it another go tomorrow. thanks again for your help! best andrea -- andrea rota Xelera - IT infrastructures http://xelera.eu/contact-us/ signature.asc Description: Digital signature
