Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component
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
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#713005: RFA: miredo -- Teredo IPv6 tunneling through NATs
Hi guys, On 28/06/13 10:52, Axel Beckert wrote: > Hi, > > Rémi Denis-Courmont wrote: > > On Fri, 28 Jun 2013 09:44:12 +0200, Axel Beckert wrote: > > >> But then again, not much as happened on development side in the > > >> last few years. > > > > > > IMHO miredo works fine for years now and I don't miss anything. So > > > from my point of viewthere's no need for new features. :-) > > > > > > If "not much happened" is just bug fixing where necessary, that should > > > be fine if it continues that way. > > > > Hmm well, the whole link-local multicast thing in the development branch > > that has never really been tested (that I'd know of) or released. Also > > there are quite a few extensions from the Microsoft/IETF Teredo protocol > > update that have not been implemented. > > I see. (Reasons why I can't take over any upstream development. ;-) > > > And then, integration with the > > network manager and init could be better. > > I usually prefer wicd over NM, but I can imagine that this would of be > use for some people. > > > There should be a few fixes in my miredo-debian.git that never hit Debian. > > If you don't take them, we should probably clear the pending tag on the > > corresponding bugs. > > From the bug reports marked as pending, I'd definitely include them. > Together with harding build flags and the 1.2.6 upstream version the > package should be back in shape. Yes. Working on that. I want first to switch to debhelper. Few questions here: * why do you compile miredo statically? shouldn't you compile dynamically and provide libmiredo or something? * I noticed that the test suite sometimes fails (rarely and randomly); the test name is libteredo-list; was testing a part of a cdbs build before? Cheers, Tomasz > > Tomasz: Please tell me if you need or want any help with the above. > > Regards, Axel > -- > ,''`. | Axel Beckert , http://people.debian.org/~abe/ > : :' : | Debian Developer, ftp.ch.debian.org Admin > `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE > `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20130628232822.ga31...@piscopia.math
Bug#714412: ITP: python-pytest-instafail -- py.test plugin to show failures instantly
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-pytest-instafail Version : 0.1.0 Upstream Author : Janne Vanhala * URL : https://pypi.python.org/pypi/pytest-instafail * License : BSD Programming Lang: Python Description : py.test plugin to show failures instantly https://pypi.python.org/pypi/pytest-instafail/0.1.0 This is now a Build-Dep for tox. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRzhioAAoJEBJutWOnSwa/su8QALU1xf3qi9vtR6eNzcq2EUTJ rkJMEvgz4rhvI3I880DzULeOtnkdh2YWkuR8cjXxvmbh6JK/2Czbiwqbpj3cu5f3 qLVX0i/ToKQgprLEn5rYYIcopFXDVC+2dRhfwtLskiy5HtmdBlpY7UHtoCEIPMvV Z7ivblsHKH32C3p50NHcc3H6RNuv0mOYIn7D23x4dLpOZhaXFdvCa3RNfGrZTAhG hzOAIuoNc6/kBEccHJPXfY0HW6e/i1oo93aRNXNUcNrc95Xtc8DfFn0Lx6n/aMea 0Smrjm29Z8lb348/JDxJPGvRllWIw9jSwJ9apK0k1TTliQj365iSvbUEObxD2CSY orOCUHAtPC+gEC+z7hQ5T2mcbnCWydpsHtXBjktSoJ9dJaERJFpFRA1VopMpPc3z QPorj4OMIgLoo1R6STC9gOWmnZZpwi2cknDFBRGTrdzvwd/cKEc985Ed4fBUu5VZ 2gy3Vn38uANgGZko3mdeW+kNchkeRR86yyTuDky1lTxsoN5cjRzEzPrzTzX8ltmg f5O5YiOfD+UTP2J2N9GcEPFyB0eh0TPMNBwORszjmTeeiov+D+d5+4DMe90JAuTc +ofzDX6Oete5qOs8l4WK2cg5ttedGXPKkqjvgSspAf8v5Z93+nfI2MXQrV3I1vJC nxgagaCQ8Kiqh3wD6piW =Yxg/ -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/20130628231352.32597.16587.report...@chemistry.wooz.org
Bug#714405: ITP: larch -- A tool to copy messages from one IMAP server to another
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: larch Version : 1.1.2 Upstream Author : Ryan Grove * URL : http://github.com/rgrove/larch * License : GPL-2 Programming Lang: Ruby Description : A tool to copy messages from one IMAP server to another Larch is a tool to copy messages from one IMAP server to another quickly and safely. It’s smart enough not to copy messages that already exist on the destination and robust enough to deal with interruptions caused by flaky connections or misbehaving servers. Larch is particularly well-suited for copying email to, from, or between Gmail accounts. -- 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/20130628213459.27441.58514.reportbug@localhost
Processed: tagging as pending bugs that are closed by packages in NEW
Processing commands for cont...@bugs.debian.org: > # Friday 28 June 20:03:27 UTC 2013 > # Tagging as pending bugs that are closed by packages in NEW > # http://ftp-master.debian.org/new.html > # > # Source package in NEW: libextutils-config-perl > tags 714374 + pending Bug #714374 [wnpp] ITP: libextutils-config-perl -- wrapper for perl's configuration Added tag(s) pending. > # Source package in NEW: libextutils-helpers-perl > tags 714375 + pending Bug #714375 [wnpp] ITP: libextutils-helpers-perl -- various portability utilities for module builders Added tag(s) pending. > # Source package in NEW: libextutils-installpaths-perl > tags 714378 + pending Bug #714378 [wnpp] ITP: libextutils-installpaths-perl -- module to make Build.PL install path logic easy Added tag(s) pending. > # Source package in NEW: boilerpipe > tags 712827 + pending Bug #712827 [wnpp] ITP: boilerpipe -- Boilerplate removal and fulltext extraction from HTML pages Added tag(s) pending. > End of message, stopping processing here. Please contact me if you need assistance. -- 712827: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712827 714374: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714374 714375: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714375 714378: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714378 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.137244982220581.transcr...@bugs.debian.org
Bug#714173: ITP: php-symfony-process -- Symfony PHP Framework - Process component
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#714390: RFP: Almohazzem - Powerful Linux packaging SDK
Package: wnpp Severity: wishlist URL :https://sourceforge.net/projects/almohazzem/ License :Waqf (Arabic General Public License) Toolkit :GTK almohazzem SDK own both developers and starter programmers the ability to produce their Linux packages in just one click. Addition to this simply in packaging , Almohazzem SDK provide multi fuctions related in already packages such as ( convert - install - extract ). Almohazzem SDK also has many special peograms like Icons Generator (IG) and Desktop Entries Generator (DEG) , all of those making the packaging operations more amazing. -- 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/384011372443...@web5e.yandex.ru
Bug#711840: marked as done (ITA: apache-mime4j -- MIME and RFC822 parser for Java)
Your message dated Fri, 28 Jun 2013 17:03:39 + with message-id and subject line Bug#711840: fixed in apache-mime4j 0.6.1-3 has caused the Debian Bug report #711840, regarding ITA: apache-mime4j -- MIME and RFC822 parser for Java to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 711840: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711840 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: normal I request an adopter for the apache-mime4j package. The package description is: mime4j provides a parser, MimeStreamParser, for e-mail message streams in plain rfc822 and MIME format. The parser uses a callback mechanism to report parsing events such as the start of an entity header, the start of a body, etc. If you are familiar with the SAX XML parser interface you should have no problem getting started with mime4j. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Source: apache-mime4j Source-Version: 0.6.1-3 We believe that the bug you reported is fixed in the latest version of apache-mime4j, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 711...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Emmanuel Bourg (supplier of updated apache-mime4j package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 14 Jun 2013 23:45:32 +0200 Source: apache-mime4j Binary: libapache-mime4j-java libapache-mime4j-java-doc Architecture: source all Version: 0.6.1-3 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers Changed-By: Emmanuel Bourg Description: libapache-mime4j-java - MIME and RFC822 parser for Java libapache-mime4j-java-doc - MIME and RFC822 parser for Java - documentation Closes: 711840 Changes: apache-mime4j (0.6.1-3) unstable; urgency=low . * Maintenance transferred to the Debian Java Maintainers (Closes: #711840) * debian/control: - Updated Standards-Version to 3.9.4 (no changes) - Use canonical URLs for the Vcs-* fields - Removed the explicit build dependency on openjdk-6-jdk - Removed the dependency on the JRE for libapache-mime4j-java - Changed the priority from extra to optional * Updated the watch file * debian/rules: Added a get-orig-source target * debian/copyright: Updated the Format URI to 1.0 Checksums-Sha1: 7816159b45bf6057abf684672f372b9ff59de1b4 2309 apache-mime4j_0.6.1-3.dsc 58f0bb722c8b1582436fd0a2c6abd2643bfa5791 2966 apache-mime4j_0.6.1-3.debian.tar.gz 8d023dc559ad6362389e93d8fb3b6f5ea21a0f2b 310830 libapache-mime4j-java_0.6.1-3_all.deb 6b5ef0cf73d82f481a81d1bc4285db31c148c9d5 229338 libapache-mime4j-java-doc_0.6.1-3_all.deb Checksums-Sha256: fbb2ab43cf5ef38aadf96a7adbbdadd0511a932dcf3105f6c3b8e7d57eea3348 2309 apache-mime4j_0.6.1-3.dsc 98132cb6b7d03ab8180940c067a4d6b9bfcdfab124ded608d11ea2c4aa8f7521 2966 apache-mime4j_0.6.1-3.debian.tar.gz 14f7d588aa0860902e39cbd7c2f400f2a3232c88b8c7b8df6d9416054c7f254f 310830 libapache-mime4j-java_0.6.1-3_all.deb e1f1e097a9ba5ae78423312b58d3c1d2464d54cc585d845deb134207a6c4d4a6 229338 libapache-mime4j-java-doc_0.6.1-3_all.deb Files: 8380d13a3e6c93d3c030f776729d99cf 2309 java optional apache-mime4j_0.6.1-3.dsc ff58b13b986359df76b96a7fefd0c73c 2966 java optional apache-mime4j_0.6.1-3.debian.tar.gz 430967ae0bba9b332aed416dc5ccefb5 310830 java optional libapache-mime4j-java_0.6.1-3_all.deb ea6da86a0ffcec81d2c759151cbd9397 229338 doc optional libapache-mime4j-java-doc_0.6.1-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRzb2jAAoJEAVLu599gGRC048P/00W5J4Mqt+JNsjQQ+396NqE KULbLIVfrfWb14Tlk785QZfddTTR+sLuNxMWG8m2gvEth37pPLMG/VMyV9dx93+A zd4ay0ZpC9ys0+FP1q06z5Tkupjp4AJN9MLge34Qal4Ojq8le3t+dk5Tkh+Mq4JD 6uL8d7c2cdt7kk0ojdLF3Q/H10+upXrawvWilaCDEdOhAy84OpYjGnSYEz2t/CM5 OA8s4H3hxjm4pa83aJzzte1w/CIl7USVHzZFUHj2z7S556RRbjMuKT66jUcMI
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 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#714382: ITP: libmodule-build-tiny-perl -- tiny replacement for Module::Build
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libmodule-build-tiny-perl Version : 0.023 Upstream Author : Leon Timmermans * URL : https://metacpan.org/release/Module-Build-Tiny/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : tiny replacement for Module::Build Many Perl distributions use a Build.PL file instead of a Makefile.PL file to drive distribution configuration, build, test and installation. Traditionally, Build.PL uses Module::Build as the underlying build system. Module::Build::Tiny provides a simple, lightweight, drop-in replacement. -- 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/20130628154350.ga23...@jadzia.comodo.priv.at
Bug#714378: ITP: libextutils-installpaths-perl -- module to make Build.PL install path logic easy
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libextutils-installpaths-perl Version : 0.009 Upstream Author : Leon Timmermans * URL : https://metacpan.org/release/ExtUtils-InstallPaths/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to make Build.PL install path logic easy ExtUtils::InstallPaths tries to make install path resolution as easy as possible. When you want to install a module, it needs to figure out where to install things. The nutshell version of how this works is that default installation locations are determined from ExtUtils::Config, and they may be individually overridden by using the install_path attribute. An install_base attribute lets you specify an alternative installation root like /home/foo and prefix does something similar in a rather different (and more complicated) way. destdir lets you specify a temporary installation directory like /tmp/install in case you want to create bundled-up installable packages. -- 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/20130628150219.ga5...@jadzia.comodo.priv.at
Bug#714375: ITP: libextutils-helpers-perl -- various portability utilities for module builders
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libextutils-helpers-perl Version : 0.021 Upstream Author : Leon Timmermans * URL : https://metacpan.org/release/ExtUtils-Helpers/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : various portability utilities for module builders ExtUtils::Helpers provides various portable helper functions for module building modules. -- 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/20130628145249.ga6...@jadzia.comodo.priv.at
Bug#714374: ITP: libextutils-config-perl -- wrapper for perl's configuration
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libextutils-config-perl Version : 0.007 Upstream Author : Leon Timmermans * URL : https://metacpan.org/release/ExtUtils-Config/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : wrapper for perl's configuration ExtUtils::Config is an abstraction around the %Config hash. -- 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/20130628144610.ga8...@jadzia.comodo.priv.at
Processed: Re: Bug#700556: Updating the wapiti Uploaders list
Processing control commands: > reassign -1 wnpp Bug #700556 [wapiti] Updating the wapiti Uploaders list Bug reassigned from package 'wapiti' to 'wnpp'. No longer marked as found in versions wapiti/1.1.6-3. Ignoring request to alter fixed versions of bug #700556 to the same values previously set > retitle -1 O: wapiti -- web application vulnerability scanner Bug #700556 [wnpp] Updating the wapiti Uploaders list Changed Bug title to 'O: wapiti -- web application vulnerability scanner' from 'Updating the wapiti Uploaders list' > severity -1 normal Bug #700556 [wnpp] O: wapiti -- web application vulnerability scanner Severity set to 'normal' from 'minor' -- 700556: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700556 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b700556.137242665619379.transcr...@bugs.debian.org
Bug#703452: [pkg-php-pear] php5-redis
Hello Cyril, > > I'd like to ask the pkg-php-pear group if they might assist by > > getting php5-redis into the debian repo. > BTW, yes, we do insist that every PEAR package should be maintained in > the team, if possible (which means: if there's no strong opposition > from the maintainer, which is pretty rare), and using Git / > git-buildpackage. any news from you? - I have started packaging php-redis at: http://anonscm.debian.org/gitweb/?p=pkg-php/php-redis.git It would be really cool, if you could tell us, if we can maintain php-redis together under the hood of the PEAR team. Greets, Jonas -- 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/20130628121007.2531a379@branka.internetstores.local
Bug#714179: [pkg-php-pear] ITP: php-json-schema -- PHP implementation of JSON schema
2013/6/28 Thomas Goirand :
> On 06/28/2013 04:43 AM, andrea rota wrote:
>> 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
>
> Same remarks as for the other package: your package is missing the
> ${phppear:Debian-Depends}, ${phppear:Debian-Recommends} and
> ${phppear:Debian-Breaks} (read man dh_phppear), and therefore, it is
> missing some important dependencies (like php-pear for example).
>
> Do not forget that a package which is --with phpcomposer is also a pear
> package, so I believe (I never tried, but I think so) you should use:
>
> dh $@ --buildsystem=phppear --with phppear,phpcomposer
>
> in your rules file. Mathieu, can you confirm that this is the way to do
> (since that's new features)?
A composer package is not a PEAR one (some are both but this is
upstream decision).
Cheers
--
Mathieu
--
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/cafx5sbzijuu3ev6h15abuh1cwkpofgqdohnqxjth4fbvd+h...@mail.gmail.com
Bug#713005: RFA: miredo -- Teredo IPv6 tunneling through NATs
On 28/06/13 10:52, Axel Beckert wrote: > Hi, > > Rémi Denis-Courmont wrote: > > On Fri, 28 Jun 2013 09:44:12 +0200, Axel Beckert wrote: > > >> But then again, not much as happened on development side in the > > >> last few years. > > > > > > IMHO miredo works fine for years now and I don't miss anything. So > > > from my point of viewthere's no need for new features. :-) > > > > > > If "not much happened" is just bug fixing where necessary, that should > > > be fine if it continues that way. > > > > Hmm well, the whole link-local multicast thing in the development branch > > that has never really been tested (that I'd know of) or released. Also > > there are quite a few extensions from the Microsoft/IETF Teredo protocol > > update that have not been implemented. > > I see. (Reasons why I can't take over any upstream development. ;-) > > > And then, integration with the > > network manager and init could be better. > > I usually prefer wicd over NM, but I can imagine that this would of be > use for some people. > > > There should be a few fixes in my miredo-debian.git that never hit Debian. > > If you don't take them, we should probably clear the pending tag on the > > corresponding bugs. > > From the bug reports marked as pending, I'd definitely include them. > Together with harding build flags and the 1.2.6 upstream version the > package should be back in shape. > > Tomasz: Please tell me if you need or want any help with the above. Hi, that was exactly my plan to cherry-pick fixes that haven't reached the Debian package yet. Tomasz > > Regards, Axel > -- > ,''`. | Axel Beckert , http://people.debian.org/~abe/ > : :' : | Debian Developer, ftp.ch.debian.org Admin > `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE > `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20130628091234.ga4...@piscopia.math
Bug#713005: RFA: miredo -- Teredo IPv6 tunneling through NATs
Hi, Rémi Denis-Courmont wrote: > On Fri, 28 Jun 2013 09:44:12 +0200, Axel Beckert wrote: > >> But then again, not much as happened on development side in the > >> last few years. > > > > IMHO miredo works fine for years now and I don't miss anything. So > > from my point of viewthere's no need for new features. :-) > > > > If "not much happened" is just bug fixing where necessary, that should > > be fine if it continues that way. > > Hmm well, the whole link-local multicast thing in the development branch > that has never really been tested (that I'd know of) or released. Also > there are quite a few extensions from the Microsoft/IETF Teredo protocol > update that have not been implemented. I see. (Reasons why I can't take over any upstream development. ;-) > And then, integration with the > network manager and init could be better. I usually prefer wicd over NM, but I can imagine that this would of be use for some people. > There should be a few fixes in my miredo-debian.git that never hit Debian. > If you don't take them, we should probably clear the pending tag on the > corresponding bugs. >From the bug reports marked as pending, I'd definitely include them. Together with harding build flags and the 1.2.6 upstream version the package should be back in shape. Tomasz: Please tell me if you need or want any help with the above. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20130628085224.gd30...@sym.noone.org
Bug#713005: RFA: miredo -- Teredo IPv6 tunneling through NATs
On Fri, 28 Jun 2013 09:44:12 +0200, Axel Beckert wrote: >> But then again, not much as happened on development side in the >> last few years. > > IMHO miredo works fine for years now and I don't miss anything. So > from my point of viewthere's no need for new features. :-) > > If "not much happened" is just bug fixing where necessary, that should > be fine if it continues that way. Hmm well, the whole link-local multicast thing in the development branch that has never really been tested (that I'd know of) or released. Also there are quite a few extensions from the Microsoft/IETF Teredo protocol update that have not been implemented. And then, integration with the network manager and init could be better. I can carry on upstream maintenance, but I don't think I ever will implement the fancy missing bits. > (And the optimist inside me thinks that at some point in time, we > won't need miredo anymore since IPv6 will be everywhere. ;-) > > Tomasz Buchert wrote: >> well I definitely can't promise I will take over >> upstream development. > > For me it's even a "I know that I can't". > >> I will look at the Debian package, fix stuff, and then we'll see. > > That's also my usual approach. :-) There should be a few fixes in my miredo-debian.git that never hit Debian. If you don't take them, we should probably clear the pending tag on the corresponding bugs. -- Rémi Denis-Courmont Sent from my collocated server -- 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/62facced4997f679492434715db87...@chewa.net
Processed: tagging as pending bugs that are closed by packages in NEW
Processing commands for cont...@bugs.debian.org:
> # Friday 28 June 08:03:08 UTC 2013
> # Tagging as pending bugs that are closed by packages in NEW
> # http://ftp-master.debian.org/new.html
> #
> # Source package in NEW: href="http://packages.qa.debian.org/efilinux";>efilinux
> tags 704323 + pending
Bug #704323 [wnpp] ITA: efilinux -- UEFI bootloader
Added tag(s) pending.
> # Source package in NEW: kzorp
> tags 713052 + pending
Bug #713052 [wnpp] ITP: kzorp -- KZorp is kernel space helper for application
level gateways, especially Zorp
Added tag(s) pending.
> # Source package in NEW: x42-plugins
> tags 712043 + pending
Bug #712043 [wnpp] ITP: x42-plugins - a collection of LV2 plugins
Added tag(s) pending.
> # Source package in NEW: href="http://packages.qa.debian.org/paramiko";>paramiko
> tags 682255 + pending
Bug #682255 [python-paramiko] python-paramiko: html docs use too much disk space
Added tag(s) pending.
> # Source package in NEW: href="http://packages.qa.debian.org/paramiko";>paramiko
> tags 690080 + pending
Bug #690080 {Done: "Jeremy T. Bouse" } [paramiko]
New upstream author/location for Python Paramiko
Added tag(s) pending.
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
682255: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682255
690080: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690080
704323: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704323
712043: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712043
713052: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713052
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
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/handler.s.c.137240661532403.transcr...@bugs.debian.org
Bug#713005: RFA: miredo -- Teredo IPv6 tunneling through NATs
Hi Rémi Rémi Denis-Courmont wrote: > On Fri, 28 Jun 2013 04:13:59 +0200, Axel Beckert wrote: > > Rémi Denis-Courmont wrote: > > > Due to lack of time, I request an adopter for the miredo package. > > > > but aren't you miredo's upstream developer, too? Does that mean that > > an adopter needs to take over upstream development, too? > > Yes. No. Ok. > But then again, not much as happened on development side in the > last few years. IMHO miredo works fine for years now and I don't miss anything. So from my point of viewthere's no need for new features. :-) If "not much happened" is just bug fixing where necessary, that should be fine if it continues that way. (And the optimist inside me thinks that at some point in time, we won't need miredo anymore since IPv6 will be everywhere. ;-) Tomasz Buchert wrote: > well I definitely can't promise I will take over > upstream development. For me it's even a "I know that I can't". > I will look at the Debian package, fix stuff, and then we'll see. That's also my usual approach. :-) Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20130628074411.gc30...@sym.noone.org
Bug#713005: RFA: miredo -- Teredo IPv6 tunneling through NATs
Hi guys, well I definitely can't promise I will take over upstream development. I will look at the Debian package, fix stuff, and then we'll see. Tomasz On 28/06/13 08:07, Rémi Denis-Courmont wrote: > On Fri, 28 Jun 2013 04:13:59 +0200, Axel Beckert wrote: > > > Hi Rémi, > > > > > > Rémi Denis-Courmont wrote: > > >> Due to lack of time, I request an adopter for the miredo package. > > > > > > but aren't you miredo's upstream developer, too? Does that mean that > > > an adopter needs to take over upstream development, too? > > > > Yes. No. But then again, not much as happened on development side in the > > last few years. > > > > -- > > Rémi Denis-Courmont > > Sent from my collocated server -- 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/20130628071447.ga7...@piscopia.math
