On 2829T010700+0200, Wichert Akkerman wrote:
> Previously Josip Rodin wrote:
> > On Mon, Aug 28, 2000 at 06:23:52PM +0200, Marcus Brinkmann wrote:
> > > The packaging manually actually says it is a makefile:
> >
> > Yes, and that makes it policy.
>
> No it doesn't.
Interesting. I seem to re
Anthony Towns wrote:
> I think though, probably because policy wasn't very clear about this,
> that packages in potato already look in /usr/share/doc for documentation,
> so they're already broken, and this may no longer really matter.
At least apache seems to still use /usr/doc. dhelp uses some i
Santiago Vila wrote:
> Please note that not every dependency or conflict is explicit. You
> can't read new manpages using an old enough man-db package, unless you
> make a little bit of tweaking in the configuration file, and we don't
> speak about "breakage" because of the need of this tweaking.
Previously Josip Rodin wrote:
> On Mon, Aug 28, 2000 at 06:23:52PM +0200, Marcus Brinkmann wrote:
> > The packaging manually actually says it is a makefile:
>
> Yes, and that makes it policy.
No it doesn't.
Wichert.
--
_
/
On Tue, Aug 29, 2000 at 12:22:44AM +0200, Josip Rodin wrote:
> Perhaps my logic is flawed; anyway, even if it's not official, the packaging
> manual should be changed to say that non-makefile debian/rules files are
> allowed.
In this case, you need to replace it with "machine-independant scripts"
> > > has been useless more often than I liked... thanks to undocumented(1).
On Mon, 28.08.00 13:03 -0400, Raul Miller wrote:
> > Wasn't there a policy proposal to get rid of these bogus pages?
On Fri, Aug 25, 2000 at 07:50:29PM +0200, Christian Hammers wrote:
> ... to be replaced by what? The ma
Hello
On Mon, 28.08.00 13:03 -0400, Raul Miller wrote:
> > has been useless more often than I liked... thanks to undocumented(1).
> Wasn't there a policy proposal to get rid of these bogus pages?
... to be replaced by what? The maintainers simply won't write manpages
en mass, so when deleting undo
Josip Rodin wrote:
> The Policy says:
>
> This manual does _not_ describe the technical mechanisms involved in
> package creation, installation, and removal. This information can be
> found in the _Debian Packaging Manual_ and the _Debian System
> Administrators' Manual_.
>
>
On Mon, Aug 28, 2000 at 03:03:45PM -0700, Joey Hess wrote:
> > > The packaging manually actually says it is a makefile:
> >
> > Yes, and that makes it policy.
> >
> > > I don't know if Manoj succeeded in making the packaging man a part of the
> > > policy.
> >
> > That's the way it is, if I'm no
On Mon, Aug 28, 2000 at 07:24:00PM +0200, Goswin Brederlow wrote:
> > > Whats Build-Depends-Indep for anyway?
> >
> > Read chapter 8 for the answer to your question.
>
> I did, but thats pretty unclear. Currently I wouldn't know which one
> to use and I map both to Build-Depends for the autobuild
Josip Rodin wrote:
> > The packaging manually actually says it is a makefile:
>
> Yes, and that makes it policy.
>
> > I don't know if Manoj succeeded in making the packaging man a part of the
> > policy.
>
> That's the way it is, if I'm not mistaken.
This is news to me; when did it happen?
--
Howdy,
Policy 3.2.1.0 states that MUAs should be setgid mail. This is so that
they can create lockfiles in /var/spool/mail. This has the unfortunate
consequence that MUA bugs can be exploited to read the email of other
users. A setgid mail locking utility has been added to liblockfile so
that M
Package: debian-policy
Version: 3.2.1.0
Two misspellings in menu-policy.sgml managed to slip by uncorrected.
The attached patch fixes them. Thanks to Colin Watson for noticing
these the first time through.
Matt
--- menu-policy.sgml.orig Mon Aug 28 10:36:18 2000
+++ menu-policy.sgmlMon
On Mon, Aug 28, 2000 at 06:36:16PM +0200, "J?rgen A. Erhard" wrote:
> "dpkg -L foo |grep man"
>
> has been useless more often than I liked... thanks to undocumented(1).
Yep, another reason for getting rid of that junk.
[Personally, I've got dpkg redirected so that the cover
script fires up a li
On Mon, Aug 28, 2000 at 06:23:52PM +0200, Marcus Brinkmann wrote:
> > Which is rather unwarranted... all that should be necessary is a executable
> > file that can act differently based on the first command-line argument
> > passed to it. Whether it is makefile, a shell or a Perl script, or even a
"dpkg -L foo |grep man"
has been useless more often than I liked... thanks to undocumented(1).
Just my EU 0.02
Bye, J
--
Jürgen A. Erhard[EMAIL PROTECTED] phone: (GERMANY) 0721 27326
My WebHome: http://members.tripod.com/Juergen_Erhard
Debian GNU/Linux (http://w
On Mon, Aug 28, 2000 at 05:59:11PM +0200, Josip Rodin wrote:
> Which is rather unwarranted... all that should be necessary is a executable
> file that can act differently based on the first command-line argument
> passed to it. Whether it is makefile, a shell or a Perl script, or even a
> compiled
Hi,
On Mon, Aug 28, 2000 at 05:59:11PM +0200, Josip Rodin wrote:
> Which is rather unwarranted... all that should be necessary is a executable
> file that can act differently based on the first command-line argument
> passed to it. Whether it is makefile, a shell or a Perl script, or even a
> comp
On Mon, Aug 28, 2000 at 06:53:47PM +0300, Antti-Juhani Kaijanaho wrote:
> > Hmm, the dependency on make is flawed, as it is perfectly possible to
> > write debian/rules that is a perl script, for example.
>
> If you find a flaw in my application of the criteria, bug reports against
> build-essenti
> If someone wants to create another build daemon (for i386!) and can't
> be bothered to install debhelper, I personally am not going to feel
> sorry for them.
FYI, the build daemons assume debhelper is build essential just to
preserve sanity. That does not make build-deps any less important,
howe
On 2828T172935+0200, Paul Slootman wrote:
> > An informational list can be found in package `build-essential'.
> > (NOTE: Don't file bugs about debhelper against this package. They will
> > be summarily closed. If you feel that the criteria for selecting
> > build-essential packages are wrong
On Mon 28 Aug 2000, Antti-Juhani Kaijanaho wrote:
> On 2828T153322+0200, Paul Slootman wrote:
> > anyway. BTW, what is the list of "build essential packages"? I'm
> > assuming that gcc libc6-dev etc. don't need to be put in. However,
> > this isn't discussed in the packaging manual at section
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:18:57 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#70315: automatic build fails for potato
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
Your message dated Mon, 28 Aug 2000 12:28:04 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy 3.2.1.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
On Sun, Aug 27, 2000 at 07:08:23PM +0200, Goswin Brederlow wrote:
> Package: packaging-manual
> Version: 3.1.1.1
>
> Whats Build-Depends-Indep for anyway?
You're right, they should all be mentioned in chapter 4.
Read chapter 8 for the answer to your question.
Julian
--
=-=-=-=-=-=-=-=-=-=-
43 matches
Mail list logo
