On Wed, May 23, 2007 at 10:22:50PM -0400, Simon wrote:
Hey all, I'm looking for a sponsor for this package. The package is a
I'm currently a bit busy but unless someone else steps up in a few
days I can can review and sponsor openglad.
I remember that I wasn't quite happy with how others
On Sat, Apr 21, 2007 at 09:36:56PM +0200, Daniel Leidert wrote:
Some time ago (just a few weeks) I saw a .changes file, that contained
entries for several package releases:
dpkg-buildpackage -v$VERSION
Check the man page.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Sun, Oct 15, 2006 at 11:42:13PM -0700, Bjorn Hansen wrote:
Hi,
I was hoping someone could sponsor and upload my package:
http://staff.washington.edu/grethel/balder2d_debian/
I see that you have repackaged the upstream tarball. Why was this
necessary? You should detail in README.Debian
On Sun, Sep 24, 2006 at 04:56:24PM +0200, Daniel Baumann wrote:
* remove useless ${misc:Depends} in debian/control.
It's not useless. See man 7 debhelper and search for Automatic
generation of miscellaneous dependencies.. I would myself remove
${misc:Depends} only if debhelper indeed did
On Mon, Aug 28, 2006 at 10:14:24PM +0900, Charles Plessy wrote:
I am packaging a software which includes tests to check if the binary is
fully funcionnal. However, those tests are much more processor intensive
than the compilation itself. Is there a general policy about what to do
I don't know
On Mon, Aug 28, 2006 at 11:58:21PM +0900, Charles Plessy wrote:
Le Mon, Aug 28, 2006 at 05:04:40PM +0300, Kari Pahula a écrit :
I don't know about a general policy, but I've myself set gecode to run
its test suite in debian/rules, excluding some of the slower buildds.
Good idea, how do you
On Fri, Jun 30, 2006 at 10:59:27PM +0200, Arjan Oosting wrote:
Could someone look at my package and upload it?
Looks solid. However, one thing:
c2hs (0.14.5-1) unstable; urgency=low
- move groff and linuxdoc-tools to Build-Depends-Indep.
The buildds will call debian/rules build, even
On Tue, Jun 13, 2006 at 06:50:19PM +0300, Damyan Ivanov wrote:
Thijs Kinkhorst wrote:
* debian/control: Architecture is set to i386 amd64. What prevents
the package from being usable on other architectures? Are you sure
you don't mean any?
flamerobin depends on libfbclient1, which is
On Sun, Jun 11, 2006 at 08:44:10AM +0100, R.Penney wrote:
Hello,
I would appreciate someone sponsoring 'cryptmount' (licensed
under GPL2) for inclusion in the debian archives.
Build-Depends: debhelper (= 4.0.0), autotools-dev, libdevmapper-dev,
libssl-dev (= 0.9.7)
openssl's license
On Thu, Jun 08, 2006 at 06:52:24PM -0400, Felipe Sateler wrote:
Hello there. I'm re-requesting a sponsor for package checkinstall (actually
Looks good. Just two things:
I don't quite understand why you're closing #354389 in
debian/changelog. That bug is closed already, and I'm not sure how
On Fri, Jun 02, 2006 at 05:05:26PM +0200, Vedran Fura? wrote:
Done. Please check the new release.
Ok. Looks quite good, already. Still, a few things about the Debian
side of the packaging (which I could well have spotted already last
time I checked, sorry). /usr/bin/bfilter-gui is independent
Replying to myself but thought of something...
On Sat, Jun 03, 2006 at 10:32:50AM +0300, Kari Pahula wrote:
one. Here's what I'd put in /etc/default/bfilter:
DAEMON_OPTS=-u nobody -g nogroup -p /var/run/bfilter.pid
It's better to put any options like this to /etc/init.d/bfilter
itself
Mailed to mentors, we like to do stuff in public and I don't claim to
be infallible, either. ;-)
On Tue, May 30, 2006 at 02:09:49AM +0200, Vedran Fura? wrote:
Kari Pahula wrote:
As far as the technical side of packaging goes, it seems to be mostly
in a good shape. One thing you should see
On Fri, May 05, 2006 at 01:23:43AM +0200, Vedran Fura?? wrote:
Hi!
I'm looking for a sponsor (or sponsors) for the following packages:
- bfilter (Simple web filtering proxy, see http://bfilter.sf.net)
I'd like to see this in Debian and am willing to sponsor it.
As far as the technical
These two packages go together. Same upstream for both, one uses the
other. Simplelist was named as sl by the upstream, but unfortunately
that name was taken by heimdal already. Subsequently diffs are rather
large as I had to run libtoolize;aclocal;automake;autoconf on both.
I asked upstream
I'm packaging libggtl (ITP #358659), which uses libsl (ITP #358657).
The latter is rather unfortunately named. The namespace of two letter
acronyms is rather crowded and there is already a /usr/lib/libsl0 in
libsl0-heimdal.
What would be a sane way to handle this situation? I'm thinking of
just
On Wed, Mar 22, 2006 at 06:08:13PM -0500, Justin Pryzby wrote:
On Thu, Mar 23, 2006 at 12:11:59AM +0200, Kari Pahula wrote:
problems. The server runs as a daemon and will be more or less at an
inconsistent state if the maps are upgraded while it is running.
So you want to have a one-way
I'm maintaining two interrelated packages, crossfire-server and
crossfire-maps. The former depends on the latter. It is possible to
upgrade them separately, but upgrading the maps alone leads to
problems. The server runs as a daemon and will be more or less at an
inconsistent state if the maps
owner 325246 michael spang [EMAIL PROTECTED]
retitle 325246 ITP: firefox-greasemonkey -- firefox extension which enables
customization of webpages with user scripts
merge 325246 341915
thank you
On Tue, Dec 20, 2005 at 11:27:35PM -0500, Michael Spang wrote:
RFP: #325246
ITP: #341915
I hope
* Package name: preload
Version : 0.2
Upstream Author : Behdad Esfahbod [EMAIL PROTECTED]
* URL : http://preload.sf.net/
* License : GPL
Description : an adaptive readahead daemon
preload monitors applications that users run, and by analyzing this data,
I've been postponing doing this... Sorry. Here's a whole bunch of
packages that need sponsoring.
crossfire-1.8.0-1
crossfire-client-1.8.0-1
crossfire-client-images-1.7.1-1
crossfire-maps-1.8.0-1
crossfire-maps-small-1.5.0-1
Upstream's home page is at http://crossfire.real-time.com/. License
.
* Updated standards-version to 3.6.1.1.
* Build-depends on autotools-dev. cp new versions of config.{guess,sub}
on each build.
* Patched data/include/skies/earth_regular_sky.inc. (Closes: #269096)
-- Kari Pahula [EMAIL PROTECTED] Mon, 13 Jun 2005 00:47:47 +0300
It's uploaded
The package crossfire-maps-1.4.0-1 is currently based on a single
source package. Upstream has split the maps in later versions to two
map sets, -big and -small.
I was thinking of handling this situation by making crossfire-maps-big
and crossfire-maps-small and by putting to both of them:
On Fri, Jun 03, 2005 at 09:21:43AM +0300, Kari Pahula wrote:
The package crossfire-maps-1.4.0-1 is currently based on a single
source package. Upstream has split the maps in later versions to two
map sets, -big and -small.
I was thinking of handling this situation by making crossfire-maps
On Fri, Mar 05, 2004 at 01:29:37PM +, Stephen Stafford wrote:
Quoting Kari Pahula [EMAIL PROTECTED]:
I've packaged Q and would like to get a sponsor for it.
I've tried to grab it to take a look, but:
[EMAIL PROTECTED]:~/q-lang$ apt-get source q-lang
Err http://mentors.debian.net
On Fri, Mar 05, 2004 at 01:29:37PM +, Stephen Stafford wrote:
Quoting Kari Pahula [EMAIL PROTECTED]:
I've packaged Q and would like to get a sponsor for it.
I've tried to grab it to take a look, but:
[EMAIL PROTECTED]:~/q-lang$ apt-get source q-lang
Err http://mentors.debian.net
I've packaged Q and would like to get a sponsor for it.
Package: q-lang
Version: 5.2-1
Description: Q equational programming language
Q stands for equational, so Q, in a nutshell, is a programming
language which lets you program by equations. You specify a system of
equations which the
I've packaged Q and would like to get a sponsor for it.
Package: q-lang
Version: 5.2-1
Description: Q equational programming language
Q stands for equational, so Q, in a nutshell, is a programming
language which lets you program by equations. You specify a system of
equations which the
28 matches
Mail list logo
