Package: wnpp
Severity: wishlist
Owner: "Dmitry Eremin-Solenikov"
* Package name: gppcscconnectionplugin
Version : 1.1.0
Upstream Author : Karsten Ohme
* URL : http://globalplatform.sourceforge.net/
* License : LGPL-v3
Programming Lang: C
Description :
Package: wnpp
Severity: wishlist
Owner: "Dmitry Eremin-Solenikov"
* Package name: gpshell
Version : 1.4.4
Upstream Author : Karsten Ohme
* URL : http://globalplatform.sourceforge.net
* License : GPL-v3
Programming Lang: C
Description : GlobalPlatform s
Package: x264
Version: 2:0.116.2042+git178455c-1
Severity: wishlist
Bug forwarded from https://bugs.launchpad.net/bugs/919509
Seems that according to Policy §10.2, we need to document why we are not
building the shared library with -fPIC in the file README.Debian and get
consensus on that on the
+++ Paul Wise [2012-01-21 20:37 +0800]:
> On Thu, Jan 19, 2012 at 8:10 PM, Wookey wrote:
>
> > Currently on Debian you'll need to have made the emdebian repositories
> > available because otherwise you won't find any cross-compilers, but
> > hopefully we'll have them in the main archive in the not
On Montag, 23. Januar 2012, Enrico Zini wrote:
> in order to make collab-maint[1] applications on Alioth faster, we would
> like to introduce a super light procedure. Here it is:
very cool, thanks!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe"
Package: wnpp
Owner: gregor herrmann
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libcpan-perl-releases-perl
Version : 0.42
Upstream Author : Chris Williams
* URL : http://search.cpan.org/dist/CPAN-Perl-Re
Reinhard Tartler writes:
> Bug forwarded from https://bugs.launchpad.net/bugs/919509
> Seems that according to Policy §10.2, we need to document why we are not
> building the shared library with -fPIC in the file README.Debian and get
> consensus on that on the debian-devel mailing list.
> The
Package: wnpp
Severity: wishlist
Owner: Sandro Tosi
* Package name: futures
Version : 2.1.2
Upstream Author : Alex Grönholm
* URL : http://pypi.python.org/pypi/futures
* License : BSD
Programming Lang: Python
Description : backport of concurrent.future
Sandro Tosi writes:
> * Package name: futures
> Version : 2.1.2
> Upstream Author : Alex Grönholm
> * URL : http://pypi.python.org/pypi/futures
> * License : BSD
> Programming Lang: Python
> Description : backport of concurrent.futures package from Pyt
On Mon, Jan 23, 2012 at 22:06, Russ Allbery wrote:
> python-futures for the package name, surely, no?
do you mean the binary? that will be python-concurrent.futures, as per
python policy; for the source I'm open to comments
Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: ht
Sandro Tosi writes:
> On Mon, Jan 23, 2012 at 22:06, Russ Allbery wrote:
>> python-futures for the package name, surely, no?
> do you mean the binary? that will be python-concurrent.futures, as per
> python policy; for the source I'm open to comments
I was thinking of the source. If you're bu
* Russ Allbery , 2012-01-23, 13:30:
python-futures for the package name, surely, no?
do you mean the binary? that will be python-concurrent.futures, as per
python policy; for the source I'm open to comments
I was thinking of the source. If you're building a single binary
package from the sourc
On Tue, 17 Jan 2012, Ansgar Burchardt wrote:
> SUMMARY
> ===
>
> We plan to ask for the creation of a new pseudo-package
> debian-mentors or mentors.debian.org [3] (contact:
> debian-ment...@lists.debian.org) in Debian's bug tracking system (the
> name is still subject to change). A workflow f
Package: wnpp
Severity: wishlist
Owner: Barry Warsaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: flufl.password
Version : 1.1.1
Upstream Author : Barry Warsaw
* URL : http://launchpad.net/flufl.password
* License : LGPL
Programming Lang:
Jakub Wilk writes:
> I normally advocate using upstream name for source package name (even if
> it's a single binary package and the binary package would have a
> different name due to $LANGUAGE policy).
This can make things unnecessarily awkward and confusing for, say, the
BTS. Nothing that pe
On Mon, 23 Jan 2012, Jakub Wilk wrote:
> I normally advocate using upstream name for source package name
> (even if it's a single binary package and the binary package would
> have a different name due to $LANGUAGE policy).
If you are only building one binary package, the source package should
hav
On Tue, 17 Jan 2012 13:59:14 -0800, Ansgar Burchardt
wrote:
We propose to use the BTS to handle sponsoring requests. Both sponsorees
and sponsors should already be familiar with its usage and we hope it
will improve the sponsoring process for both sides. It will also make it
easier to analyse s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: bugs.debian.org
Severity: wishlist
Hello,
as we seem to have reached general consensus about the approach to
handle sponsor requests in the BTS. The last thing subject to discussion
is the name of the pseudo-package to agree upon.
Zack made
Hi,
On Mon, 23 Jan 2012, Enrico Zini wrote:
> * What happens next?
>
> A few days after all the steps have been completed, you should get an
> email from Alioth saying that you are now a member of the collab-maint
> project.
I don't know if this has been fixed on the FusionForge side, but when
Package: wnpp
Severity: wishlist
Owner: Andrew Pollock
* Package name: barnyard2
Version : 1.9
Upstream Author : Ian Firns >
* URL : http://www.securixlive.com/barnyard2/
* License : GPLv2
Programming Lang: C,
Description : output co-processor for Snort
20 matches
Mail list logo
