|
|
 Up |
|
  |
|
|
|
|
|
|
Author: NIIBE YutakaNIIBE Yutaka
Date: Jun 8, 2010 04:00
Package: wnpp
Severity: wishlist
Owner: NIIBE Yutaka fsij.org>
Owner: NIIBE Yutaka fsij.org>
* Package name : tomoe-gtk
Version : 0.6.0
Upstream Author : Takuro Ashie
* URL : http://tomoe.sourceforge.jp/
* License : LGPL
Programming Lang: C, Python
Description : GTK+ GUI library of Tomoe handwriting engine
Tomoe is a software which provides a handwriting recognition engine
and its user interface on desktop environment.
.
This package give GTK+ GUI library for tomoe.
|
| |
|
no comments
|
|
|
Author: Peter S GalbraithPeter S Galbraith
Date: Jun 7, 2010 23:40
>> I maintain the debian directory in the upstream sources of a package
>> (gri) that uses auto-tools. So far, it seems to need the files:
>>
>> debian/source/Makefile.am
>> debian/source/Makefile.in
>
> Something like
>
> EXTRA_DIST = $(wildcard source/*)
>
> in debian/Makefile.am should work.
Thanks! Add to EXTRA_DIST and remove "source" from DIST_SUBDIRS.
Works great!
Peter
|
| |
|
no comments
|
|
|
Author: Peter S GalbraithPeter S Galbraith
Date: Jun 7, 2010 22:50
Hi all,
I maintain the debian directory in the upstream sources of a package
(gri) that uses auto-tools. So far, it seems to need the files:
debian/source/Makefile.am
debian/source/Makefile.in
in order for `make dist' to work.
But lintian complains about these files.
Anyone know how to make the auto-tools include the debian directory in
the source tar ball (with `make dist') but NOT maintain any Makefile in
those directories?
Thanks,
Peter
--
Peter S. Galbraith, Debian Developer debian.org>
http://people.debian.org/~psg
GPG key 4096/70D4A979 6309 28AE 8EB3 AB57 22F3 03BC 17DC 3CC4 70D4 A979
|
| Show full article (0.86Kb) |
|
2 Comments |
|
|
Author: FladischerMichaelFladischerMichael
Date: Jun 1, 2010 13:00
Package: wnpp
Severity: wishlist
Owner: FladischerMichael@fladi.at
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
* Package name : nose-cover3
Version : 0.0.5
Upstream Author : Ask Solem opera.com>
* URL : http://pypi.python.org/pypi/nose-cover3/
* License : LGPL-2.1+
Programming Lang: Python
Description : Coverage 3.x support for Nose
This package is a plugin for python-nose that adds python-coverage
support, providing coverage reports for nose tests.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
|
| Show full article (0.87Kb) |
|
no comments
|
|
|
Author: FladischerMichaelFladischerMichael
Date: Jun 1, 2010 12:30
Package: wnpp
Severity: wishlist
Owner: FladischerMichael@fladi.at
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
* Package name : django-nose
Version : 0.1
Upstream Author : Jeff Balogh jeffbalogh.org>
* URL : http://github.com/jbalogh/django-nose
* License : BSD
Programming Lang: Python
Description : Django test runner that uses nose
Integation of python-nose into Django test runner by extending the Django
management CLI with nose-related options.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
|
| Show full article (0.87Kb) |
|
no comments
|
|
|
Author: Roland StiggeRoland Stigge
Date: Jun 1, 2010 10:50
Hi,
On 06/01/2010 03:10 AM, Paul Szabo wrote:
> This package depends on ghostscript, and may be affected. Please
> evaluate the security of this package, and fix if needed.
There are several issues with this bug:
(1) If ghostscript has a bug, maybe it should be fixed there instead of
in all gs dependant packages?
(2) Mass bug filing (esp. RC/security) is generally not a great idea,
especially if
(3) You haven't checked the individual packages ("This package depends
on ghostscript, and may be affected").
(4) Please state clearly what's wrong with the package (hyperlatex in
this case). From the other bug reports I deduce that gs calls should be
extended with "-P- -dSAFER". This should be done in the hyperlatex
source package in bin/ps2image, for the record.
bye,
Roland
|
| Show full article (0.94Kb) |
|
1 Comment |
|
|
Author: Steve LangasekSteve Langasek
Date: Jun 1, 2010 06:10
On Tue, Jun 01, 2010 at 01:13:28AM +0200, sean finney wrote:
> On Mon, May 31, 2010 at 12:24:48PM -0700, Steve Langasek wrote:
>> Does dbconfig-common know about all of these config files?
>> I think it's the responsibility of dbconfig-common to track them, and remove
>> them on purge. That way if your package is purged while dbconfig-common is
>> installed, the config file is removed, and if dbconfig-common is removed
>> before purge, a dpkg --purge dbconfig-common can still clean it up.
> i think in hindsight that's the way it *should* have been, but the
> documentation has suggested the contrary for long enough that i'm hesitant
> to break things, at least this late into the release cycle.
Hmm, what's the risk of changing it? I guess if dependencies are allowed to
be purged when a package depending on them is removed-but-not-purged,
dbconfig-common could obliterate config files that the depending package
expects to still have around. Is that the concern?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ ubuntu.com vorlon@ debian.org
|
| Show full article (1.50Kb) |
|
1 Comment |
|
|
|
|
|
Author: Gunnar WolfGunnar Wolf
Date: Jun 1, 2010 05:10
Felix Geyer dijo [Sat, May 29, 2010 at 09:14:56PM +0200]:
> clamz [1] has been rejected from Debian NEW [2] some time ago.
> The FTP assistent that processed the package was of the
> opinion that it belongs to contrib instead of main because it's
> only useful to download non-free content.
>
> The purpose of clamz is to download MP3 files after buying them
> from Amazon. You can download MP3s with every browser though
> and Debian even has many MP3 decoders in main.
> I don't see why this is a problem.
>
> There is another package in main that is similar in this
> respect: youtube-dl.
>
> So what is the reason that clamz can't be in main?
|
| Show full article (1.51Kb) |
|
no comments
|
|
|
|
|
