Ian Jackson writes:
> Is just "Dgit" too short ?
Works for me.
Bdale
pgpl5oEkTjw_X.pgp
Description: PGP signature
On Mon, 6 Jun 2011 21:56:22 +0200, Andreas Barth wrote:
> Why 3 below 5?
Introducing a new field that must be filled in and kept (manually) in
sync with information that is already present in the rules file just
doesn't seem like a good solution.
I'm less afraid of 4 than some people would be, p
On Mon, 6 Jun 2011 02:15:37 -0700, Steve Langasek wrote:
> If this were to be put to a vote today, I would propose the following ballot
> options:
>
> 1) Implement support for calling 'debian/rules build-arch' in place of
> 'debian/rules build' by checking for the presence of the target usin
Bug #545309 causes me to realize that the recent lowering of priority
for makedev to 'extra' motivates a review and update of policy section
10.6.
Given udev, the majority of Debian systems in the future are unlikely to
have makedev installed at all. There may be enough usage cases for
static dev
> I think he ment that you can not know wether the setting comes from
> dpkg-buildpackage or the user. If it comes from dpkg-buildpackage then
> debian/rules should be free to override it as needed. If it comes from
> the user then that is another story. At least that is my take on it.
This is a
[EMAIL PROTECTED] (Oohara Yuuma) writes:
> On 18 Aug 2002 20:18:43 -0400,
> Colin Walters <[EMAIL PROTECTED]> wrote:
> > + Although binaries in the build tree should be compiled with
> > + debugging information by default,
> How can I do it without wasting autobuilder's CPU time?
Don't w
[EMAIL PROTECTED] (Colin Walters) writes:
> Any seconds?
I note a typo in the first line of your change:
+ By default, when a package is being built, it any binaries
Want to lose the word 'it' in that line?
Other than that, I second this proposal.
Bdale
[EMAIL PROTECTED] (Joey Hess) writes:
> In the meantime, I would like to move forward with this transition
> before we embark on other changes like gcc 3.0 recompiles. That is all.
Sounds like a good plan.
Anyone thinking about release notes for sarge yet? Noting that the transition
is complete
[EMAIL PROTECTED] (Adrian Bunk) writes:
> > So far the following packages do not follow the rule :
> > 4) bind
For what it's worth, yesterday's upload of bind 8.2.5 eliminated the one
remaining guaranteed pause for interaction on install, so it's no longer a
problem. The bind9 packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I second the proposal to allow DFSG free crypto programs into the main
archive.
Bdale
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6gCFiZKfAp/LPAagRAvbMAJ9Bz0w/FLhDJ/vHUowgckB5Myf8
I've thought about this a bit, since Josip pointed the issue out to me on IRC.
Here is my take on it, as a long-timer...
I was never aware that policy required putting a summary of changes in the
copyright file, and I've never done it. I note that a couple packages I now
maintain contain such con
> On Sun, Nov 28, 1999 at 12:01:44AM -0700, Bdale Garbee wrote:
> > There needs to be a canonical list of the packages that are part of the
> > build-essential set *somewhere*.
>
> Why?
Ok, I've gone back and re-read the policy section carefully, and thou
In article <[EMAIL PROTECTED]> you wrote:
: 2) Create a single package suggests Tk rather than depending on or
: recommending it
I like this option, along with some text in the long description field of the
control file explaining that one or more of the utilities use Tk, but that
Tk is no
In article <[EMAIL PROTECTED]> you wrote:
:> (For simplity and without loss of generality, I'm just describing the
:> solution for kdebase and kdegraphics. Furthermore, the "Depends:" lines
:> have been simplified.)
:>
:> The Debian packages:
:> Package: kdelibs0g
:>
:> Package: kdebase
:> De
In article <[EMAIL PROTECTED]> you wrote:
: their packages are available, ours not...
I think there are two things that I must have missed in the discussion on this
topic:
- why are there two sets of KDE packages? One should be sufficient.
- why can't "your" KDE packages be mad
I would like to propose that all scripts placed in /etc/init.d should be
required to support at least the four arguments 'start|stop|reload|restart'.
In cases where there is currently no 'restart', it could easily be formed as
the sequence of actions to perform a stop followed by a start. In cases
In article <[EMAIL PROTECTED]> you wrote:
A well-stated proposal, Ian... but it gives me heartburn nonetheless.
: In the far future we can remove the compatibility links from
: base-files. This has to be considered carefully, because after those
: links are gone installing an old package will ma
In article <[EMAIL PROTECTED]> you wrote:
I'm remarkably unopinionated about how we package sources, except that I'm
pretty happy with dpkg-source and so it seems reasonable to me to tweak the
things that need tweaking in dpkg-source, rather than do something radically
different.
However, you h
19 matches
Mail list logo
