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 multivariate estimation using smoothing 
splines

This package is a new dependency of our r-cran-fbasics package (which itself
has been in the archive since 2004).  

r-cran-gss is a standard CRAN package and should not pose any issues. 

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqriykxm@max.nulle.part

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://github.com/twitter/twitter-text-rb
License: Apache-2.0

Description: library that does auto linking and extraction items in tweets
 twitter-text is a library that does auto linking and extraction of usernames,
 lists and hashtags in tweets


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130501233327.ca8670553132999d3e85b...@debian.or.jp

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) using the git-bundle command.
The bundle file would then be uploaded to the FTP server instead of a
traditional source tarball.

A slight variation of this idea is that the repository would be cloned
into a temporary bare repo, and that bare repo would be tarred up and
the tarball would become the source upload.

Some of the problems I see with this:

- much harder to scan the whole history of the repo for non-DFSG content

- more disk space is used

The benefit is that we are distributing something much more useful than
a tarball snapshot of each upstream.  Running `apt-get source' will
retrieve a VCS and a user can immediately start patching it or even
developing a local branch.

Then again, some of that behavior could be achieved by creating an
`apt-get vcs-clone' function to read the Vcs control fields and make a
clone for a traditional source package's repo.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51816cca.4060...@pocock.com.au

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 by creating an
> `apt-get vcs-clone' function to read the Vcs control fields and make a
> clone for a traditional source package's repo.

Isn't that what debcheckout already does?

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital signature

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

...this.  It's of course possible to publish shallow clones, but at the
point that the clone is sufficiently shallow that the review is equivalent
to the current DFSG review, it's not at all clear there's any remaining
benefit from using this distribution format.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehdqcwbm@windlord.stanford.edu

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) by default, libjpeg8 uses a different subsampling which lead to higher
> > quality output than libjpeg62.
> >
> > However this leads to files which are not byte per byte indentical to what
> > libjpeg62 would produce, but this is in no way required by the JPEG 
> > standard.
> > Indeed the standard explicitely allow for different DCT implementation.
> 
> No this is not the case. It was just this initial issue which raise my
> attention to what is happening with libjpeg in Debian.

What is not the case ? Even libjpeg6b include three DCT implementations which
can leads to different output.

I find interesting that you have just discovered #629963 I reported two years
ago.

> P.S.: You still haven't answered my questions in the previous email. I
> don't think they are unreasonable.

Let start with the beginning:

I became the maintainer of libjpeg62 in November 2001, the package having been
unmaintained for 3 years. During the last twelve year, Guido has served as
the upstream maintainer, helping me to deal with bug reports, providing patches
to fix issues, and finally releasing libjpeg7 which included, inter alia, 
patches
I wrote for the need of the Debian package (the DP xxx patches in the 
changelog).
Guido also agreed to the release of libjpeg 6b1 which is libjpeg 6b with
versionned symbols, which was needed to move forward with libjpeg7. Since the
release of libjpeg7, Guido makes one release (minor or major) each year in
January.

During that time, it became obvious that Guido has a deep understanding of the
libjpeg code and the JPEG technology, and at the same time that the quality
of libjpeg is very high (there have been no security vulnerability reported
against libjpeg6b in 15 years. Compare that number to libtiff, libpng or even
libjpeg-turbo.)

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.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130501221646.GA22352@yellowpig

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 back, however.

Perhaps after he figures out he has no more users he'd be more open to
merging the fork back in, and *collaborating* in a productive way.

I'll take an upstream that takes slightly longer to fix a bug and is
open to evolving with the software it uses than a project that
breaks A[P|B]I regularly (from what I read here) any way.

I don't have all the facts, and I only know what I read others saying
about it, but +1 to turbo. Why has this taken so long?

I mean, every other major distro is using -turbo. It can't be that bad.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature