On 3 January 2014 12:14, Didier 'OdyX' Raboud wrote:
> I'm awfully sorry to have failed to answer you earlier, let's correct
> that now.
That's no problem, I've been caught up with work stuff so I dropped the ball
as well.
> Could you make your git repository available somewhere so that I could
reopen 712118
thank you
Hi Didier and Till,
I'm reopening the RFS bug for splix.
I've uploaded a new version of splix that merges the last upstream changes
(mainly dropping patches that have been accepted upstream), sets the
maintainer as the Debian Printing Team and moves the packaging to a
git
Hi Didier,
it took me some time but I moved the splix packaging to git.
The new dsc is available at:
http://mentors.debian.net/debian/pool/main/s/splix/splix_2.0.0+svn308-1.dsc
The git repo lives on my local machine, I think I cannot push it to
alioth as I am
not a DD.
I will also answer some of y
There's one thing that I would like to see in the Debian BTS: automatic
linking to other bug reports every time someone writes #NN.
I would like to file a wishlist report against it with a patch, but I don't
know how to try it beforehand - the svn trunk can run a self-contained
server, but I
2009/5/3 George Danchev :
> Nod. I'm in favour of removing any lintian assertions from m.d.o, since that
> might be misleading.
Maybe write something like:
[Check the package with lintian --pedantic and explain the reason for
warnings and errors or state that is clean]
In the RFS template? (Maybe
2009/5/2 Neil Williams :
> One important fact missing from your RFS: what programming language(s)
> is/are in use in the package? No need to specify the build system, just
> the basic C, C++, C#, python, perl, etc. although it would be better to
> mention "C source code using ncurses", "C source c
2009/5/2 Patrick Matthäi :
> * debian/changelog:
> It is the initial release in Debian but it is containing some more
> versions and builds, also the initial debian revision starts with -2,
> please bump it to -1.
Upstream had its own debian sudirectory with a debian changelog, I
thought about ke
dget
http://mentors.debian.net/debian/pool/main/f/fswebcam/fswebcam_20070108-2.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Luca Niccoli
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
2009/4/27 Jonas Meurer :
> Hey,
> I'm not absolutely sure about it, but linux-libc-dev might be the answer
> to your questions.
>
Yes!
I was completely mistaken, I thought the headers I needed were in my
system because I had linux-headers-whatever installed...
But then do I have to explicitly dep
Dear mentors,
in a package I'm preparing I need to build depend on linux headers,
but if I just put "linux-headers" in debian/control lintian shrieks
virtual-package-depends-without-real-package-depends
The problem is that AFAICS all the real packages in question are
either version-specific (linux
rs.debian.net/debian/pool/main/g/grcm/grcm_0.1.6-1.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Luca Niccoli
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
2009/3/25 Paul Wise :
> Ahhh, upstream should not be using this variable, please get them to
> switch to the po/LINGUAS file instead. This way it should not be
> nessecary to rebuild the configure & Makefiles in order to support and
> install a new language.
After I'm done with packaging this ver
2009/3/24 Daniel Leidert :
> Can you provide the patch you are applying to configure.in? It is often
Of course:
--- temp/grcm-0.1.6/configure.in2008-06-07 05:35:00.0 +0200
+++ grcm-0.1.6/configure.in 2009-03-24 00:32:09.0 +0100
@@ -22,7 +22,7 @@
AC_DEFINE_UNQUOTED(GE
2009/3/24 Paul Wise :
> In automake-based packages the recommended way to clean up after
> autotools regeneration is 'make maintainer-clean'. Unfortunately
> automake doesn't remove Makefile.in files in maintainer-clean by
> default so you may have to delete them manually or with dh_clean.
Actual
Hi mentors,
I would like to adopt grcm.
I'm repackaging it from scratch, since it used a rules file I was not
confident with and didn't have a patch system.
I need to regenerate ./configure with autoconf; I'm doing it by
putting autoconf in the rules file.
The problem is that this way if I build t
2009/3/1 Jelle de Jong :
> Would it not be better to improver bluez-gnome? or work with the
bluez-gnome is... for gnome.
> Nope there are no official command line tools for pairing, there is the
> simple-agent.py script in the testing directory of the git source, but it
> is not supported and d
ource repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/f/fswebcam/fswebcam_20070108-2.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Luca Niccoli
--
To UNSUBSCRIBE, ema
ebian/pool/main/f/fswebcam
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/f/fswebcam/fswebcam_20070108-2.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Luca Niccoli
--
To U
2009/2/1 Luca Niccoli :
> 2009/1/31 Ben Finney :
>
>> If you can come up with a reproducible test case for 'licensecheck'
>> not behaving as it should, submit it as a bug report.
>
> I'm sure on my system it doesn't check files with names ending in
2009/1/31 Ben Finney :
> If you can come up with a reproducible test case for 'licensecheck'
> not behaving as it should, submit it as a bug report.
I'm sure on my system it doesn't check files with names ending in '.h'
In an empty dir do:
$ touch lc.h && touch lc.c
$ licensecheck *
it returns
l
2009/1/30 Sandro Tosi :
> I'd say file a bug on licensecheck
I have an other problem with licensecheck:
it doesn't check .h files if given multiple files as an argument.
Is this intented? I didn't find it documented in the manpage (there's
a default regexp for files to be ignored, but I don't see
2009/1/30 Eduardo M KALINOWSKI :
> Wasn't it a debian/changelog file, describing the releases upstream has
> made?
Yes, so I was thinking about just appending changes to the original file.
(If the program gets packaged in Debian, upstream agrees not to
create his own debian subdirectory, so ther
Souce files of the program I'm packaging contain the following header:
/* fswebcam - Small and simple webcam for *nix */
/*===*/
/* Copyright (C)2005-2006 Philip Heron*/
/*
2009/1/28 Adeodato Simó :
> (The recommendation above is my opinion, and there are other DDs who
> think different. Me, I believe having a readable diff.gz is motivation
> enough as to repack the tarball.)
OTOH, reading the policy manual I get the idea that a pristine
original tarball is not some
Hi DD,
I found a very nice little program to take pictures from a webcam, and
I would like to package it.
The original tarball already contains a debian subdirectory (which
needs some corrections anyway), how should I deal with that?
If I dh_make straight after unpacking the tarball, dh_make won't
25 matches
Mail list logo
