RFS: cxxtest - xUnit-like framework for C/C++ applications

Hello mentors, I am looking for a sponsor for my package "cxxtest". CxxTest is a lightweight xUnit-like testing framework for C/C++ applications. Writing test is easier and simpler than others C/C++ testing frameworks because it is not required to register them. Once the test case is written, it

Re: git-buildpackage and tarballs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Charles, On 22.10.2011 03:36, Charles Plessy wrote: > if as an upstream author you are not using tarballs, you can use the format > ‘3.0 (native)’. It will make a source package where everything is included in > a single tarball. that's not qu

RFS: mpg321 (2nd try)

Dear mentors, I am looking for a sponsor for my package "mpg321". * Package name: mpg321 Version : 0.3.0-1 Upstream Author : Nanakos Chrysostomos * URL : http://mpg321.sourceforge.net * License : GPL-2+ Section : sound It builds those binary package

Re: git-buildpackage and tarballs

Le Sat, Oct 22, 2011 at 12:46:12PM +0200, Arno Töll a écrit : > > On 22.10.2011 03:36, Charles Plessy wrote: > > if as an upstream author you are not using tarballs, you can use the format > > ‘3.0 (native)’. It will make a source package where everything is included > > in > > a single tarball.

Re: git-buildpackage and tarballs

* Charles Plessy , 2011-10-22, 20:09: if as an upstream author you are not using tarballs, you can use the format ‘3.0 (native)’. It will make a source package where everything is included in a single tarball. that's not quite what native packages are for. Native packages should be used only, w

Re: git-buildpackage and tarballs

Le Sat, Oct 22, 2011 at 01:29:57PM +0200, Jakub Wilk a écrit : > > Just because some developers choose to abuse native source format, > doesn't mean it's something that should be advocated to newcomers. > So please stop. Thanks. Apart from the point I raised about translations (for which I never

git-buildpackage, dfsg-clean branches, tarballs and non-distributable files

Hi all, In the spotweb package[0], currently in the NEW queue, I have a git upstream branch, a dfsg branch and a debian branch. The upstream branch is pulled from the upstream git repository, then merged into the dfsg branch, with a number of files removed. The dfsg branch is then merged into the

Re: git-buildpackage, dfsg-clean branches, tarballs and non-distributable files

Le Sat, Oct 22, 2011 at 02:36:32PM +0200, Jan-Pascal van Best a écrit : > > - the debian/rules get-orig-source target is supposed to build the dfsg > tarball from the canonical upstream source location. That is, NOT from > my own dfsg branch. Which is a bit weird. How do other people handle > that

Re: git-buildpackage and tarballs

On Sat, 22 Oct 2011 20:41:34 +0900 Charles Plessy wrote: > Le Sat, Oct 22, 2011 at 01:29:57PM +0200, Jakub Wilk a écrit : > > > > Just because some developers choose to abuse native source format, > > doesn't mean it's something that should be advocated to newcomers. > > So please stop. Thanks.

Re: git-buildpackage and tarballs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Antonio, On 22.10.2011 15:27, Antonio Ospite wrote: > In a native package every changes you make to the debian packaging > metadata translates into a new upstream release, and this is not nice > if you think to other distributions too. > > Am I

RFS: charmap.app/0.2-11 (RC bugfix)

Dear mentors, I am looking for a sponsor for my package "charmap.app". It builds these binary packages: charmap.app - Character map for GNUstep The upload should fix #645927. Thanks in advance. http://mentors.debian.net/debian/pool/main/c/charmap.app/charmap.app_0.2-11.dsc -- To UNSUBSCRIBE,

Re: git-buildpackage and tarballs

Le Sat, Oct 22, 2011 at 03:27:39PM +0200, Antonio Ospite a écrit : > > I am a newbie about debian development, but I think that you generally > want to have the possibility to make multiple iteration for the package > metadata for the _same_ upstream release. > > In a native package every changes

Re: RFS: flex-sdk-4.5

On Mon, Oct 17, 2011 at 13:32, Jaldhar H. Vyas wrote: > Have you created the repo yet? I'm waiting on it to do the upload. Sorry it took so long to reply, I've been out of town for a few days. I have submitted a request to alioth for hosting, but I have not received any reply yet. I have an

Re: RFS: flex-sdk-4.5

On Mon, Oct 17, 2011 at 19:06, Damien Raude-Morvan wrote: > On Thu, 13 Oct 2011 13:01:11 +0200, Joey Parrish > wrote: > > Note that the Flex SDK itself cannot yet be built from Adobe's source > > code under Debian, even though the code is released under the MPL. > > Adobe's build system relies on

RFS: php-db-dataobject

Dear mentors, I am looking for a sponsor for my package "php-db-dataobject". * Package name: php-db-dataobject Version : 1.9.6-1 Upstream Author :Alan Knowles a...@akbkhome.com * URL :http://pear.php.net/pack

RFS: php-db-dataobject-formbuilder

Dear mentors, I am looking for a sponsor for my package "php-db-dataobject-formbuilder". * Package name: php-db-dataobject-formbuilder Version : 1.0.1-1 Upstream Author : Norbert Mocsnik * URL : http://pear.php.net/package/DB_DataObject_FormBuilder/ * License

RFS: l2tp-ipsec-vpn (updated package)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for the new version 1.0.1-2 of my package "l2tp-ipsec-vpn". This upload would fix several bugs. * Package name: l2tp-ipsec-vpn Version : 1.0.2-1 Upstream Author : Werner Jaeger * URL

RFS: Apper

Dear mentors, I am looking for a sponsor for my package "apper". * Package name: apper Version : 0.7.0-1 Upstream Author : Daniel Nicoletti * URL : http://kde-apps.org/content/show.php/Apper?content=84745 * License : GPL-2+ Section : kde It bu

Re: git-buildpackage and tarballs

Charles Plessy writes: > This is excactly why I am limiting my recommendation to the case where > there is no upstream release as tarball. In that sense, a new source > package is still a downstream event that is not indicative of an > upstream release. > I am not sure that it is a situation th

Re: git-buildpackage and tarballs

Le Sat, Oct 22, 2011 at 07:08:45PM -0700, Russ Allbery a écrit : > > The same issue as with a tarball applies, though: unless the intention is > to tag a new upstream release every single time a new version of the > Debian package is uploaded (or unless the upstream doesn't even tag > releases, bu

Re: git-buildpackage and tarballs

On 10/22/2011 07:41 PM, Charles Plessy wrote: > Le Sat, Oct 22, 2011 at 01:29:57PM +0200, Jakub Wilk a écrit : > >> Just because some developers choose to abuse native source format, >> doesn't mean it's something that should be advocated to newcomers. >> So please stop. Thanks. >> > Apart

Re: git-buildpackage and tarballs

On 10/23/2011 11:37 AM, Charles Plessy wrote: > Hi Russ, > I think that we are discussing two separate questions: whether a maintainer of > his own software in Debian should release a new upstream version when updating > the Debian package If the change in the software isn't located in the packagi

Re: git-buildpackage and tarballs

Charles Plessy writes: > I think that we are discussing two separate questions: whether a > maintainer of his own software in Debian should release a new upstream > version when updating the Debian package, and whether the the maintainer > of a Debian package for which there is no upstream tarbal

RFS: evilvte (updated package)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1,SHA512 Dear mentors, I am looking for a sponsor for the new version 0.5.0-1 of my package "evilvte". (Programming language: C) It builds the binary package: evilvte The package is lintian clean. (http://mentors.debian.net/package/evilvte) evilvte (