Bug#706541: ITP: r-cran-gss -- R package for multivariate smoothing splines

2013-05-01 Thread Dirk Eddelbuettel
Package: wnpp Owner: Dirk Eddelbuettel Severity: wishlist * Package name: r-cran-gss Version : 2.0-13 Upstream Author : Chong Gu * URL or Web page : http://cran.r-project.org/web/packages/gss/index.html * License : GPL (>= 2) Description : GNU R package for multivar

Bug#706555: ITP: ruby-twitter-text -- library that does auto linking and extraction items in tweets

2013-05-01 Thread Hideki Yamane
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-CC: debian-devel@lists.debian.org, debian-de...@lists.debian.or.jp, pkg-ruby-extras-maintain...@lists.alioth.debian.org Package name: ruby-twitter-text Version: 1.6.1 Upstream Author: Twitter, Inc. URL: https:

git as a source package format?

2013-05-01 Thread Daniel Pocock
Just following up on the earlier discussion about VCS (not just git) in the packaging workflow Would there be any hard objection to a source package format based on git-bundle? In other words, dpkg-source would extract all repository history (or all of the branch used to build the package) usi

Re: git as a source package format?

2013-05-01 Thread gregor herrmann
On Wed, 01 May 2013 21:28:10 +0200, Daniel Pocock wrote: > Would there be any hard objection to a source package format based on > git-bundle? Like "Format: 3.0 (git)" in dpkg-source(1)? IIRC it works, it's "just" not allowed in the archive. > Then again, some of that behavior could be achieved

Re: git as a source package format?

2013-05-01 Thread Russ Allbery
Daniel Pocock writes: > Would there be any hard objection to a source package format based on > git-bundle? ftp-master has previously made a hard objection to using the package format in the Debian archives because of... > - much harder to scan the whole history of the repo for non-DFSG content

Re: jpeg8 vs jpeg-turbo

2013-05-01 Thread Bill Allombert
On Sat, Apr 27, 2013 at 08:55:28AM +0200, Ondřej Surý wrote: > On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert > wrote: > > > > I think there are some misunderstanding about what offer libjpeg8: > > > > 1) by default, libjpeg8 creates JFIF files which are compatible with > > libjpeg62. > > > > 2

Re: jpeg8 vs jpeg-turbo

2013-05-01 Thread Paul Tagliamonte
On Thu, May 02, 2013 at 12:16:46AM +0200, Bill Allombert wrote: > > On the other hand, it is also obvious that the libjpeg-turbo upstream does > not > have a full understanding of the libjpeg code, so we are better off with Guido > as upstream maintainer. It's no reason to hold the whole distro