On Wed, 2006-05-03 at 18:21 -0700, Russ Allbery wrote:
Thijs Kinkhorst [EMAIL PROTECTED] writes:
debian/README.Debian: contains information that's interesting, but not
really very important for people who install the package. I'd turn it
into 'regular' documentation. README.Debian is more
On Thu, 04 May 2006, Paul Wise wrote:
They were mostly fine for the current python policy (although a bit
overkill). I'm looking forward to a more sane python policy, as
described in this email:
http://lists.debian.org/debian-python/2006/01/msg00028.html
Who is the python policy
Some issues seem to come up time and again when somebody inspects RFS'd
packages. Some of these are not breaches of policy but simply bad
practices, like leaving quoted dh_* commands in debian/rules. Some are
breaches of policy but common enough to focus separate attention to.
I wonder, whether
Here are two users' checklists that I have used for reference.
http://people.debian.org/~neilm/sponsorship.html
http://people.debian.org/~mpalmer/sponsorship_checklist.html
-Ted
Panu Kalliokoski wrote:
I wonder, whether there is a list of these common gotchas in packaging
somewhere, or a
On Thu, May 04, 2006 at 02:52:43PM +0300, Panu Kalliokoski wrote:
Some issues seem to come up time and again when somebody inspects RFS'd
packages. Some of these are not breaches of policy but simply bad
practices, like leaving quoted dh_* commands in debian/rules. Some are
breaches of
Hello,
I am adopting Yorick and packaging add-ons for this interpreted language
aimed at scientific number crunching, data visualisation etc.
I know the packages need more work (in particular concerning the
copyright files, removing commented-out dh_*lines in rules and
rebuilding under sid), so
Hello,
Panu Kalliokoski schrieb:
Some issues seem to come up time and again when somebody inspects RFS'd
packages. Some of these are not breaches of policy but simply bad
practices, like leaving quoted dh_* commands in debian/rules.
I do that all the time. It is much easier to see that a
On 5/4/06, Laszlo Boszormenyi [EMAIL PROTECTED] wrote:
Hi,
On Wed, 2006-05-03 at 22:55 +0200, mariodebian wrote:
I'm a 3 years debian user and I have presented my personal project to
google summer of code.
[...]
Google admins say me that I need a DD to be a mentor of my project.
Can
On Thu, May 04, 2006 at 04:50:29PM +0200, Simon Richter wrote:
Hello,
Panu Kalliokoski schrieb:
Some issues seem to come up time and again when somebody inspects RFS'd
packages. Some of these are not breaches of policy but simply bad
practices, like leaving quoted dh_* commands in
Hello Thibaut,
I know the packages need more work (in particular concerning the
copyright files, removing commented-out dh_*lines in rules and
rebuilding under sid), so I am not requesting a detailed review, but I
think advice on the following few questions would be timely:
That's always a
At 1146760598 past the epoch, MarioDebian wrote:
The project is based on shell scripts and understand
GNU/Linux init process, any DD can help me during project
with the possible problems
There has been some blogging activity along these
lines[1]... you may also find the
Hello Mario,
On Thu, 2006-05-04 at 16:36 +0200, MarioDebian wrote:
I have readed the mentors faq [1] and I have understand that the
mentor is a student tutor who made a review of student's work along
the summer.
I suppose that the mentor have to make a dialog with google summer of
code
Hi!
I'm using svn-buildpackage to build a debian package.
To test with other versions of g++ I changed the link /usr/bin/g++ to
point to g++-4.1 rather than to g++-4.0 and change it back after the test.
Is there a simpler way to tell svn-buildpackage (or the underlying build
tools) which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fabian Guter wrote:
Hi!
I'm using svn-buildpackage to build a debian package.
To test with other versions of g++ I changed the link /usr/bin/g++ to
point to g++-4.1 rather than to g++-4.0 and change it back after the test.
Is there a simpler
Hallo dam,
In case your package uses auto*, then configure script most probably
honours CC, CXX, CPP and CXXPP environment variables. Put
# Force usage of 4.1
export CC=gcc-4.1
export CXX=g++-4.1
export CPP=cpp-4.1
export CXXPP=cpp-4.1
before invoking configure and you should be
Hi mentors!
It's been some week since I last sent this RFC/RFS. I guess it's time to send
it again :)
The package seems to be clean now. Please help this really useful software find
his way into the Debian archive!
* Package: rhinote
Version: 0.7.0
* License: GPL
URL:
Fabian Guter wrote:
Hallo dam,
In case your package uses auto*, then configure script most probably
honours CC, CXX, CPP and CXXPP environment variables. Put
# Force usage of 4.1
export CC=gcc-4.1
export CXX=g++-4.1
export CPP=cpp-4.1
export CXXPP=cpp-4.1
before invoking configure and you
Thomas Girard wrote:
You can override these inconditionnally define variables no using
environment but using make.
I meant You can override these inconditionally defined variables not
using environment but using make arguments. Sorry about that.
So to summarize, using `make CXX=g++-4.1'
Justin Pryzby [EMAIL PROTECTED] wrote:
Agreed; my motivation for leaving commented lines around is that it is
arguably easier to merge with newer dh_make template files (if one
were to do that ..). The reason to not leave them around is that not
doing so indicates some level of familiarity
Hi!
I'm looking for a sponsor (or sponsors) for the following packages:
- bfilter (Simple web filtering proxy, see http://bfilter.sf.net)
Was built fine in pbuilder environment. Install, remove, purge and upgrade
are successfully tested.
Man pages are missing for bfilter and bfilter-gui
On 5/4/06, Panu Kalliokoski [EMAIL PROTECTED] wrote:
Some issues seem to come up time and again when somebody inspects RFS'd
packages. Some of these are not breaches of policy but simply bad
practices, like leaving quoted dh_* commands in debian/rules. Some are
breaches of policy but common
Simon Richter [EMAIL PROTECTED] writes:
I do that all the time. It is much easier to see that a program is not
being run if it is explicitly commented out rather than just not
there, as Makefiles tend to be executed in interesting nonlinear ways,
and it doesn't really hurt either. Even the
Panu Kalliokoski [EMAIL PROTECTED] writes:
I wonder, whether there is a list of these common gotchas in packaging
somewhere, or a checklist for package quality? In a similar vein, I
wonder whether there is a checklist of qa procedures to do for a fresh
package, like lintian/linda testing,
Hi!
So to summarize, using `make CXX=g++-4.1' should do.
OK, that looks simple! But how about passing parameters to make when using
svn-buildpackage. I looked into the documentation (also of dpkg-buildbackage)
but didn't find anything helpful.
Do I have to build 'by hand' using make or is it
On 5/5/06, Fabian Guter [EMAIL PROTECTED] wrote:
Hi!
So to summarize, using `make CXX=g++-4.1' should do.
OK, that looks simple! But how about passing parameters to make when using
svn-buildpackage. I looked into the documentation (also of dpkg-buildbackage)
but didn't find anything helpful.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vedran Furač wrote:
Linda also
complains with message:
A binary links against a library it does not use symbols from
Which library, which binary? I'm not sure what to do about that.
That is a linda bug
- aspell-hr (The Croatian dictionary for
[sorry Eddy, resending this to the ml]
Eddy Petrişor wrote:
On 5/5/06, Fabian Guter [EMAIL PROTECTED] wrote:
Hi!
So to summarize, using `make CXX=g++-4.1' should do.
OK, that looks simple! But how about passing parameters to make when
using
svn-buildpackage. I looked into the documentation
27 matches
Mail list logo
