Ben Gertzfield [EMAIL PROTECTED] wrote:
I would be extremely happy if Debian decided to drop the new way and
just join the rest of the distributions with the (admittedly not the
best way) symlinks. Yes, I've read the rationale for doing it our way,
but it breaks *so much software*. Debian is
Raul == Raul Miller [EMAIL PROTECTED] writes:
Raul VMWare I know nothing about. Are you supposed to recompile
Raul it every time you change kernel versions? And does it
Raul really not let you specify -I/usr/local/src/linux/include/ ?
Ben Gertzfield [EMAIL PROTECTED] wrote:
Yes
Brian Servis [EMAIL PROTECTED] wrote:
My orginal post was with regards to the FHS standard which states that
the /usr/include/{linux,asm} directories should be links to the current
kernel headers.
Personally, I think that aspect of the FHS is broken, and that
we should talk to them about the
Daniel Quinlan [EMAIL PROTECTED] wrote:
Should we continue to require that /usr/include/{asm,linux} be present
(on systems including a C or C++ compiler) without specifying the exact
implementation?
Yes.
--
Raul
Thomas Sippel - Dau [EMAIL PROTECTED] wrote:
If a user wants to build a program for the current system, then the
include files should be found in /usr/include
Um.. no.
You're essentially saying that when someone boots off of a floppy the
floppy must contain the kernel include files for that
Ben Gertzfield [EMAIL PROTECTED] wrote:
Assuming you mean /usr/include/{linux,asm} need to be a valid default,
I totally agree. The current Debian system is immensely insatisfactory
in that it's pretty much impossible for any non-C-literate user to
compile a standalone module by themselves.
Theodore Y. Ts'o [EMAIL PROTECTED] wrote:
But only one kernel can be the one which boots by default --- for
example, if you just type return at the LILO prompt.
It is also not naive-user-friendly to require the user to type a kernel
name each time the computer boots!
So which ever
Ian Jackson [EMAIL PROTECTED] wrote:
I submit that the desired user interface is that the user is offered
(by defautlt) a set of `categories' or `keywords' or whatever,
something like
Standard internet protocol clients.
Software development tools.
and gets to choose whether they want
On Mon, Aug 16, 1999 at 02:24:20PM -0700, Carl R. Witty wrote:
If the standard system binaries are statically linked, then you can't
use fakeroot to build packages any more.
Only if there are no dynamically linked versions of the important
utilities available. Worst case, fakeroot could
On Wed, Aug 18, 1999 at 02:28:36PM +0200, Santiago Vila wrote:
Hello Technical Committee.
This message from Wichert was posted nearly two weeks ago.
Yes.
Which is the current state of things?
(1) The technical committee does not have a chairman yet, so is not
able to properly vote on any
On Wed, Aug 18, 1999 at 04:25:48PM -0700, Chris Waters wrote:
First of all, I'm still not convinced that this is a technical issue,
as I mentioned in my objection to Manoj's proposal. The information
is just as available whether it's found in one location or two, so
I don't see any technical
Michael Stone [EMAIL PROTECTED] writes:
No it's not. Every bash upgrade blows it away without notice or comment.
On Tue, Aug 17, 1999 at 06:20:13PM -0700, Chris Waters wrote:
Yes, but that's considered to be a bug. I agree that it's a bug that
*needs* to be fixed. Ok, it's *supposed* to be
Anthony Towns wrote:
Fourth, Raul also points out that debian-policy isn't a constitutional
body, it can only act under the auspices of the technical committee. That
is, just because we reach a consensus on -policy how to deal with an
issue, we can't suddenly declare 1000s of packages [2]
Raul == Raul Miller [EMAIL PROTECTED] writes:
Raul (*) Policy is *supposed* to be a formulation of existing
Raul practice. If everybody agrees, the technical committee doesn't
Raul need to get involved.
On Sun, Aug 29, 1999 at 02:28:12AM -0500, Manoj Srivastava wrote:
How can
On Sun, Aug 29, 1999 at 04:52:59PM +0200, Marcus Brinkmann wrote:
I think that does not make sense at all.
Current practice is a good guidance for the policy process, but being
strictly bound to it renders the policy group useless because we had
no chance to make real, innovative progress.
On Mon, Aug 30, 1999 at 01:57:51AM +1000, Anthony Towns wrote:
Consider something like: ``Your package has /usr/doc/copyright/package
instead of /usr/doc/package/copyright''. That almost certainly doesn't
cause a problem with the package itself. And the copyright is included,
and it doesn't
On Sun, Aug 29, 1999 at 12:00:08PM -0500, Manoj Srivastava wrote:
[much deleted]
I see. Is the above a reasonable facsimile of what you are
talking about?
Yes. What you're thinking is pretty close to what I'm thinking.
[Most of the text of your letter is the sort of stuff that I
On Sun, Aug 29, 1999 at 07:44:27PM +0200, Marcus Brinkmann wrote:
However, I see there are two places in the policy manual which back up my
point. Both are in section 2.4.1:
When the standards change in a way that
requires every package to change the major number will be changed.
So
On Sun, Aug 29, 1999 at 07:59:50PM +0200, Marcus Brinkmann wrote:
Whereas you and Raul seem to suggest (please correct me if I am wrong):
1. Make informal decision about something OR make decision and change policy
to allow old and new way.
2. Wait until enough packages follow the new way.
On Tue, Aug 31, 1999 at 10:17:28AM -0400, Dale Scheetz wrote:
There is currently a vote underway in the technical committee. Raul and
myself have voted, and are waiting for the others on the committee to
vote.
As has Manoj.
FYI,
--
Raul
On Tue, Aug 31, 1999 at 03:44:07PM +0200, Wichert Akkerman wrote:
Previously Raul Miller wrote:
First off, I'm not sure it's a good idea for policy to be a rapidly
changing entity.
It's not a good idea at all, but as Manoj pointed out it's now changing
rapidly.
Debian produces
On Thu, Sep 02, 1999 at 12:17:35AM +1000, Anthony Towns wrote:
AFAIK, it's just not possible to make Apache (and other web browsers)
make both /usr/doc and /usr/share/doc accessible at the one
http://localhost/doc URL.
With apache it's trivial. With less fully featured web servers
(maybe boa
On Fri, Sep 03, 1999 at 10:13:59PM -0500, Adam Heath wrote:
Setting up libapache-mod-jserv (1.0-2) ...
ln: /usr/doc//libapache-mod-jserv: cannot overwrite directory
dpkg: error processing libapache-mod-jserv (--configure):
# ls /usr/doc//libapache-mod-jserv -a
. .. .dhelp
Maybe these
Short form:
When moving to FHS, we need to provide /usr/doc/package -
/usr/share/doc/package symlink for backwards fsstnd compatability.
Long form:
See the debian-ctte mail archives.
Basically, however, Wichert asked the
committee for a migration strategy on August 5:
In the wake of the 3.0.0.0 release of debian policy, I've been studying
the policy process. In particular, I've been looking at the debian
constitution, and the contents of the 3.0.1.1 debian-policy package.
Originally, I was going to make a formal proposal to update debian
policy. However
Raul (a) documenting existing practice, and
Raul (b) getting approval from relevant package developers, and
Raul (c) getting the technical committee to approve (or disapprove) a
Raul completed proposal, and
Raul (d) getting the developers as a whole to overturn a technical committee
On Mon, Sep 06, 1999 at 02:24:36AM -0500, Manoj Srivastava wrote:
Why are you coming in to this forum, and fixing things that do
not seem to be broken?
I'm trying to understand some conflicts between various things I've
read.
I must say that I'm disappointed in the responses I've
On Mon, Sep 06, 1999 at 02:01:18PM +1000, Anthony Towns wrote:
They're not, after all, all *that* bad. Sure, we had a whole bunch of
problems with /usr/doc, amongst which were:
* 'twas a complicated issue with no elegant solutions
* everyone didn't really know how to work with
On Sun, Sep 05, 1999 at 08:10:05PM -0400, Ben Collins wrote:
Since this obviously has a consensus, I am making it amended. Here are the
final changes.
Actually, on Sept 1, Chris Waters raised an objection about
the use of the =debug abstraction.
[And, personally, I think he has a point:
When this thread first came up, the point was that the package maintainer
should have the option to not compile with -g.
That was fine.
However, the final policy depreciates the current practice in favor of
a new and almost unknown mechanism.
That's not so good:
The way I see it, this whole
On Tue, Sep 07, 1999 at 05:38:03PM +0200, Roman Hodek wrote:
You forgot the case of recompilations: If default is with -g + strip
(as policy currently recommends), a lot of time is wasted on the
auto-builder machines.
I think something like the following would work for auto-builder machines:
On Wed, Sep 08, 1999 at 12:34:27AM +0200, Wichert Akkerman wrote:
I think what Raul wants mostly is some way to incorporate the way
debian-policy works currently with the structure as layed out in the
constitution. As his position as chairman of the ctte that is not an
unlogical desire.
Look guys, I have a responsibility to see that policy is right.
And so do you.
I understand that a number of you are more than a little hostile towards
the technical committee -- I'm guessing that you don't want some random
group stepping on your work.
But, for the immediate future it doesn't
On Tue, Sep 07, 1999 at 06:12:07PM -0400, Ben Collins wrote:
Umm, what about libraries that purposely compile -dbg packages? This
is a silly idea, it's not a good idea for the autobuilders to muck
around with the way the package is meant to be built.
Good point.
Of course, this is solvable --
On Tue, Sep 07, 1999 at 09:37:19PM -0400, Ben Collins wrote:
Umm, how do you see your hack as a speed gain when it requires every
invocation of gcc to also invoke perl?!
I guess that means you didn't read the rest of the message.
It's trivial to rewrite in C, and I offered to do so.
So you
On Wed, Sep 08, 1999 at 01:58:54PM +1000, Anthony Towns wrote:
Huh? As in Build-Depends: gcc (= 2.7.2) ? How's this different to
Bug#41232? Or, rather, how is Bug#41232 lacking?
Bug#41232 is good, though [to take the example from the most recent
message], I still don't see that specifying
On Thu, Sep 09, 1999 at 08:42:18PM +0200, Marcus Brinkmann wrote:
Yes, and I acknowledge your goal. But I am concerned that people will just
drop the -g without replacement, and the rest choose the suggested way or
another. What I would like to see is to have some unified way to pass build
On Thu, Sep 09, 1999 at 07:18:05AM -0700, Jim Lynch wrote:
perl invocation per gcc invocation?? You Better Let Users Turn It OFF.
Do not depend on everyone wanting it, whatever it does (did you notice
that: I don't KNOW what it does, nor do I CARE.)
You can consider this a second SO LONG AS
Can we get liblockfile's program an routines to reliably *fail* when
it's locking an nfs file?
If so, perhaps we can recommend Maildir/ for people who need to
put mail on an nfs partition.
The bad side of this is that it requires some very specific documentation,
and it's an extra admin
On Fri, Sep 10, 1999 at 01:32:33PM +0200, Roland Rosenfeld wrote:
There are some disadvantages with this proposal:
...
You're right: there are resource consumption costs. However, when
measured against lost or damaged mail issues, these are probably worth
incurring.
The bad side of this is
On Fri, Sep 10, 1999 at 11:46:05AM +0200, Miquel van Smoorenburg wrote:
Bad idea. Why do you want to share a mail spool over NFS? Because
there's another machine that wants to access the mail, or the mail
is stored on another machine and you want to access it. That other
machine might well not
On Sep 18, Joseph Carter wrote:
It's a problem if there's no transition to speak of. We apparently have
decided not to make policy that makes a bunch of packages instantly non-
compliant without a reasonable transition.
On Sat, Sep 18, 1999 at 11:24:13PM -0500, Chris Lawrence wrote:
I
On Sun, Sep 19, 1999 at 12:45:10AM -0500, Chris Lawrence wrote:
My point is simply that changing policy does not translate into making
things happen by fiat. Perhaps you missed the entire point of my
mail, because it seems like we agree with each other.
Actually... rereading your original
On Wed, Sep 22, 1999 at 11:05:36PM +0200, Andreas Voegele wrote:
In my opinion, the installation guide should suggest creating an /opt
partition if the user intends to install commercial software like
Applixware, Civilization or the Oracle RDBMS, but nothing else should
be done.
What problem
On Wed, Sep 22, 1999 at 04:18:07PM -0700, Chris Waters wrote:
Oh c'mon. You're talking about people who are smart enough to create
symlinks in /opt/bin, but aren't smart enough to create the dir in the
first place? I don't buy it. :-)
The issue isn't that they don't know how to create
On Thu, Sep 23, 1999 at 10:19:04AM +0200, Andreas Voegele wrote:
You suggest creating the following directories by default:
/etc/opt, /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib,
/opt/man and /var/opt.
Yes.
Firstly, none of the existing applications that go to /opt use these
On Thu, Sep 23, 1999 at 11:24:37AM +0100, Philip Hands wrote:
It strikes me that if all the distributions include these directories
by default, that ISV installer writers will put stuff like:
for i in $PACKAGE_DIR/bin/* ; do ln -s $i /opt/bin ; done
in their install scripts. This is
On Thu, Sep 23, 1999 at 11:55:09AM -0700, Chris Waters wrote:
And in any case, I meant wrong in the moral sense, not the legal
sense.
I don't see that that's a meaningful distinction for this case.
--
Raul
On Fri, Sep 24, 1999 at 11:34:28PM -0500, The Doctor What wrote:
I do not like the idea of a daemon starting up with a default
configuration that I have not double checked upon installation. I
consider automatically starting with no choice a misfeature.
I think I agree.
I got a rude start
On Wed, Sep 29, 1999 at 09:57:53PM +1000, Drake Diedrich wrote:
One way to minimize the harm of unintentionally installed or
misconfigured daemons would be to add a default ipchain/ipfwadm policy
rejecting all TCP SYN (incoming initialization) and non-DNS UDP packets
except those from
distributable across international borders.
- Forwarded message from Joseph Carter [EMAIL PROTECTED] -
X-Envelope-Sender: [EMAIL PROTECTED]
Date: Sat, 2 Oct 1999 13:12:57 -0700
From: Joseph Carter [EMAIL PROTECTED]
To: Raul Miller [EMAIL PROTECTED]
Cc: Herbert Xu [EMAIL PROTECTED], Joel Klecker
example
if [ -x /usr/sbin/update-mime ]; then
update-mime
fi
/example
Seconded.
[As far as I can tell, you're documenting existing practice.]
--
Raul
On Wed, Oct 13, 1999 at 07:33:53PM -0500, Nathan E Norman wrote:
What's inelegant about sudo?
It creates (and waits for) dns traffic every time it's run.
In some circumstances this means sudo just hangs.
--
Raul
On Thu, Oct 14, 1999 at 07:20:05PM +, Lars Wirzenius wrote:
/usr/doc/debian-policy/policy.html/index.html:
Copyright ©1996,1997,1998 Ian Jackson and Christian Schwarz.
Yet the manual has been modified by others since. Should the copyright
be updated?
Briefly: yes.
--
Raul
On Wed, Oct 20, 1999 at 07:04:19PM +0100, Julian Gilbey wrote:
On Thu, Oct 14, 1999 at 07:20:05PM +, Lars Wirzenius wrote:
/usr/doc/debian-policy/policy.html/index.html:
Copyright (c)1996,1997,1998 Ian Jackson and Christian Schwarz.
Yet the manual has been modified
The one issue I can see is existing support for source packages.
We should not allow bz2 source packages into our archives until after
the source package tools have a good track record with transparently
supporting this format.
[Specifically, I'd like to build some of my packages to support bz2,
:09:13PM -0400, Raul Miller wrote:
I think it's an important point, because getting it wrong would have
all sorts of nasty implications.
On Tue, Oct 26, 1999 at 10:11:50AM +1000, Herbert Xu wrote:
But do you agree that with your current proposal, you still have to fix all
scripts that use -e
[I've elected not to Cc: debian-devel]
On Tue, Oct 26, 1999 at 08:32:18PM -0400, Chris Pimlott wrote:
There's still problems with using pre-depends to make sure bzip2
is installed.
If we decide to use bzip2 in this capacity the package should be
required and essential.
--
Raul
On Tue, Oct 26, 1999 at 10:16:05PM -0700, Joel Klecker wrote:
It's also been suggested that --rename is potentially harmful.
--rename would be harmful if the divert target would be the /bin/sh
symlink. [Or some other target which is critical to system integrity.]
In almost all other
On Wed, Oct 27, 1999 at 03:35:40PM +0300, Antti-Juhani Kaijanaho wrote:
Well, if the metapackage is in the available file, the following
shell code will create such written list (untested):
...
Last time I checked, apt-get update did not update the available file.
--
Raul
Julian Gilbey wrote:
Reading bug #31645, it seems clear that the Packaging Manual was
accepted as policy, although Joey had reservations.
Should I go ahead and make the modifications Manoj proposed?
On Tue, Oct 26, 1999 at 09:42:54PM -0700, Joey Hess wrote:
I continue to disagree that
On Tue, Oct 26, 1999 at 10:01:58PM -0700, Joel Klecker wrote:
[ Note: quoting the entire thing since this may have been missed due
to lame original subject ]
Sorry about that.
Thanks,
--
Raul
On Thu, Oct 28, 1999 at 04:26:50PM +0200, Roland Rosenfeld wrote:
I proposed to change the Manual pages section of our policy to get
rid of the undocumented(7) symlinks.
I agree that this is a good idea (I'm seconding it).
--
Raul
On Sun, Nov 21, 1999 at 12:49:02PM +1000, Anthony Towns wrote:
From: Joel Klecker [EMAIL PROTECTED]
...
+Further, since these packages may be implicitly required by any
+number of other packages, including dpkg itself, they must function
+correctly even while unconfigured.
I'm Cc'ing this message to debian-apt, to ask if the following
addittion to policy has any hidden ramifications that might
make it a bad idea.
On Tue, Nov 23, 1999 at 03:25:00PM +0100, Santiago Vila wrote:
On Tue, 23 Nov 1999, Anthony Towns wrote:
+Since dpkg will upgrade other packages
On Tue, Nov 23, 1999 at 02:54:56PM +, Julian Gilbey wrote:
But: I just realised. For bash (or whatever essential packages
provide /bin/sh and /bin/perl), the situation is far worse: what
happens if a package is *removed* when the symlink is not in place
(because the package is not
On Thu, Nov 25, 1999 at 10:17:43PM -0500, Brian Mays wrote:
Besides, is it so difficult to do dpkg -L pccts? If you want a list
of the binaries, then try dpkg -L pccs | grep bin.
Yes, people should know about dpkg -L in their quest for package level
documentation.
Not only will it show you
Wichert Akkerman [EMAIL PROTECTED] writes:
I assume we are all aware of the discussion a couple of months ago
about removing references to non-free from main. There was a consensus
this should be done and a consensus was formed to do this via a new
Enhances relation for packages.
On Tue,
On Sun, Nov 28, 1999 at 10:14:29PM -0800, Joseph Carter wrote:
I will conditionally support this...
My first condition is that this is phased in--it must not be a requirement
for potato or even potato+1. (I'll accept potato alone if a reasonable
consensus of people believe we can do it for
On Mon, Nov 29, 1999 at 10:06:39PM +0100, Wichert Akkerman wrote:
need anything that's not free at all. If we put weaken Suggest or
create a new weaker version of it we don't do that since we still
tell people that there are non-free packages that can improve things.
On Mon, Nov 29, 1999 at
On Mon, Nov 29, 1999 at 08:54:56PM +0100, Roland Rosenfeld wrote:
Your proposal means, that I should remove netpbm-nonfree from
transfig's suggests and add Enhances: netpbm-nonfree to
netpbm-nonfree.
Is this really the correct way? Why does the maintainer of
netpbm-nonfree have to change
I second Wichert's proposal that policy recommend
non-free package Enhances: free package, in place of
free package Suggests: non-free package.
--
Raul
.
Raul Miller [EMAIL PROTECTED] writes:
Raul That's solvable: create a virtual package which has a free instance
Raul (such as Mozilla) which provides the interface you're taking advantage
of.
On Tue, Nov 30, 1999 at 01:21:22PM -0600, Manoj Srivastava wrote:
This is an additional hack
Joseph Carter wrote:
I'm not so sure it's such a small set of packages, but I'm agreeable to
that if we can do it.
On Tue, Nov 30, 1999 at 01:34:25PM -0800, Joey Hess wrote:
Well, a simple[1] perl command can tell us exactly what packages are affected:
...
Hmm... ssh should no longer be
And, it looks like task-chinese-t should be in contrib.
On Tue, Nov 30, 1999 at 03:25:34PM -0800, Joey Hess wrote:
I dunno, it depends on all free stuff.
It contains no free software, just the obligatory /usr/doc/ entries,
and it suggests numerous non-free packages.
Then again, maybe it
On Tue, Nov 30, 1999 at 05:20:37PM -0600, Manoj Srivastava wrote:
No. But I am voicing my objection to a method that requires
serendipitous free equivalantrs of all non-free packages to
serve as a workaround.
That's just one of several options.
We need to have a clean
On Wed, Dec 01, 1999 at 04:15:22PM -0800, Chris Waters wrote:
Hmm, ok. I'm not convinced that there'll ever be any real[*] need to
do so, but I agree that adding the capability does no harm.
[*] that is to say, technical, rather than political.
Actually, if you look at what's supported in
On Wed, Dec 01, 1999 at 02:03:48AM +, Julian Gilbey wrote:
I would encourage people to reread sections 4 and 5 of the social
contract. Debian *acknowledges* the existence of non-free software,
and We acknowledge that some of our users require the use of programs
that don't conform to the
Raul For the worst case suggests - enhances mess, you could
Raul even create a single empty non-free package which enhances
Raul the free part and which suggests any of a suite of non-free
Raul software. This puts administrative control in the right place,
Raul yet leaves a clean
On Wed, 1 Dec 1999, Raul Miller wrote:
Perhaps the keyring (entire keyring) should be in non-us rather than
contrib?
On Wed, Dec 01, 1999 at 02:57:49PM -0700, Jason Gunthorpe wrote:
Why? There is nothing export-controlled about the keyring, if the keyring
should go anyplace, it would
On Tue, Nov 30, 1999 at 11:34:45PM -0600, Manoj Srivastava wrote:
That happens to be your interpretation of the social contract.
I see the packages in main to be absolutely free (fulfilling the
social contract about 100% free distribution) while retaining
the freedom to talk about
If the references are never displayed *to people who dio not
want* tham, why is that so bad? And why are we going through hoops to
impose the religion on everyone else as well?
Raul Miller wrote:
What do you mean by display? You want to chain people to dselect?
On Wed, Dec
[in one message]
Raul Miller [EMAIL PROTECTED] writes:
Personally, I think that hard-coding into a DFSG package a reference
to some non-DFSG package is rather grotesque. I'm disappointed that
we disagree on this issue.
[in another message]
Chris Waters [EMAIL PROTECTED] writes
Raul Miller [EMAIL PROTECTED] writes:
Personally, I think that hard-coding into a DFSG package a reference
to some non-DFSG package is rather grotesque. I'm disappointed that
we disagree on this issue.
On Thu, Dec 02, 1999 at 07:20:39PM +1000, Anthony Towns wrote:
I don't think
On Fri, Dec 03, 1999 at 02:49:24PM -0800, Chris Waters wrote:
The fact that I have already moved any non-free suggests in my
packages to the package description (even though I didn't have to)
should demonstrate that I am quite conversant with the difference.
However, what Manoj, Knghtbrd, I
Raul This isn't about talking about other packages.
On Thu, Dec 02, 1999 at 01:51:53PM -0600, Manoj Srivastava wrote:
Then it should be. Your raison de etre seems to be that good
users shall find references to non-free software r5epugnant, and
hence one must purge all references
Branden Robinson [EMAIL PROTECTED] writes:
So, I propose the following compromise:
* Downgrade xfree86-common and xlib6g from standard to optional; AND
* Modify section 5.8 to say that creating X and non-X versions of a
package is permissible *ONLY* if the non-X version
On Thu, Dec 02, 1999 at 11:10:56AM -0500, Raul Miller wrote:
On Thu, Dec 02, 1999 at 07:20:39PM +1000, Anthony Towns wrote:
I don't think that's any worse than having a GPL-compatible package
reference a non-GPL-compatible package, if we were to have a gpl-only
distribution.
Huh
On Fri, 3 Dec 1999, Raul Miller wrote:
By the time woody is released, it's likely the gif patent will have
expired.
On Fri, Dec 03, 1999 at 03:34:58PM +0100, Nils Jeppe wrote:
Patents are good for 17 years or so. When was lzw patented? And when was
it patented in countries other than the US
Raul I just don't think that specifically enhancing the package structure
Raul with extra kludge to specially support non-free packages is the right
Raul way to go.
Look below to see why it is not a kludge.
Raul I think that the right way to go is to put the references
I second this amendment -- I think it makes more sense than the original.
Thanks,
--
Raul
On Sat, Dec 04, 1999 at 03:28:18AM +0200, Antti-Juhani Kaijanaho wrote:
On Fri, Dec 03, 1999 at 03:56:35PM -0800, Joey Hess wrote:
+ Every package must have exactly one maintainer at a time. The
Amend non-free definition (#46522)
* Stalled.
* Proposed by Raul Miller; seconded by Marco d'Itri, Joseph Carter
and Joel Klecker.
* Change definition of non-free to contains packages which are not
compliant with the DFSG. Currently, non-free includes packages
On Wed, Dec 08, 1999 at 04:25:23PM +, Peter Naulls wrote:
Package: debian-policy
In section 2.3.5, who's should read whose.
who's is short for who is (or similar) while whose
is ownership (like its or hers).
I second this.
And, since you didn't include a patch:
*** policy.sgml Wed
On Thu, Dec 09, 1999 at 02:12:54PM +1000, Anthony Towns wrote:
Finishing unpacking isn't exactly a dpkg abort, though. Maybe
`This means the package must be functional even before it has been
configured when upgrading and after any dpkg abort.' ?
Unfortunately, there are some failure modes we
On Thu, 9 Dec 1999, Raul Miller wrote:
Unfortunately, there are some failure modes we don't have enough
control over.
On Thu, Dec 09, 1999 at 01:41:51PM -0700, Jason Gunthorpe wrote:
This is the only point during dpkg's operation where a failure of dpkg is
catastrophic. IMHO essential
Seconded.
--
Raul
On Thu, Jan 13, 2000 at 12:30:45AM +, Ian Jackson wrote:
You'll notice that the common thread running through these cases is
that it's usually OK to include the package if the maintainer knew
about the problem and a bug is open. So, I propose that we give the
Raul Miller wrote:
Seconded.
On Thu, Jan 13, 2000 at 08:42:53PM -0800, Joey Hess wrote:
Raul, I hope you're aware that
a) Ian's assumption that dinstall rejects packages with lintian errors is
false.
I was not aware of that.
b) Lintian already has a local exception mechanism, which
b) Lintian already has a local exception mechanism, which was announced to
debian-devel-announce recently.
I've not seen that announcement, and I've been looking for such
announcements.
What was the subject line?
On Thu, Jan 13, 2000 at 09:06:24PM -0800, Joey Hess wrote:
On Tue, Jan 18, 2000 at 02:13:57AM +, Matthew Vernon wrote:
It's tricky to write a decent manpage if you know no nroff.
Counter example: the sashconfig man page from the sash package.
The source package contains no roff for this manpage.
A one-liner in debian/rules generates the roff.
--
On Fri, Jan 28, 2000 at 11:03:27PM -0600, Adam Heath wrote:
Jump forward a few weeks, and now the client wants to start running hit
reports on the apache log data. Well, it seems that during the apache purge,
it deleted(rm -rf) /var/log/apache(also a few other dirs).
While it was not your
1 - 100 of 302 matches
Mail list logo
