Sean Whitton writes:
> On Thu, Aug 03, 2017 at 05:51:27PM +0200, Philip Hands wrote:
>> P.S. Just in case this is an oversight, rather than an intentional
>> change:
>>
>> Shouldn't "desktop entry" and "Debian menu entry" be somehow
>>
:
installs a FreeDesktop desktop entries
I guess that should instead be:
installs FreeDesktop desktop entries
(or perhaps it should be singular throughout, I'm not sure)
Cheers, Phil.
P.S. Just in case this is an oversight, rather than an intentional
change:
Shouldn't "
Joel Klecker <[EMAIL PROTECTED]> writes:
> You're implying of course that only the US has software patents,
> which is false. mp3 encoding is covered by both US and German patents
> and IDEA is claimed to be patented in Europe as well as the US (I
> think ascom is deliberately misleading as to
Richard Braakman <[EMAIL PROTECTED]> writes:
> Do we really have other packages in there for other reasons than the
> cryptography laws? I couldn't find any. I think calling it "crypto"
> makes a lot of sense. It's a clear label, and people will know how
> to treat those packages in their count
Chris Lawrence <[EMAIL PROTECTED]> writes:
> AFAIK there is no "perfect" regime in the world, and the political
> situation in many countries wrt. crypto (for example) is rather
> unstable. For example, the LinuxDVD code is probably only illegal in
> the UK, since the "rip" of the encryption algo
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> > I thought about naming it 'crypto', but it would also not describe it
> > correctly
> > (since we also have packages encumbered by other silly laws there, like
> > software patents). Any ideas?
>
> legally-unsafe ?
> country-sensitive ?
> re
Raul Miller <[EMAIL PROTECTED]> writes:
> Our job is to give them a better alternative.
>
> > The fact that the FHS makes their existence optional, means that it's
> > not insisting that we install them.
>
> True, but this doesn't solve any problems as far as I can see.
The status quo is that t
Joey Hess <[EMAIL PROTECTED]> writes:
> This just shows why policy should not specify. This is an area where the
> maintainer should be allowed to use common sense.
>
> If you maintain a package, you _wrote_ the init script. You know if it
> supports reload, and if so, you use it. Otherwise, you
Santiago Vila <[EMAIL PROTECTED]> writes:
> Sorry for the aol mode, but I fully agree.
>
> If the lack of /opt is not a bug, and no package in the system
> requires it, then I don't see the point in creating it.
I think we should create /opt because the FHS requires it, and
possibly /opt/README.
Andreas Voegele <[EMAIL PROTECTED]> writes:
> >> 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.
>
Raul Miller <[EMAIL PROTECTED]> writes:
> 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. :-)
>
> T
"J.H.M. Dassen (Ray)" <[EMAIL PROTECTED]> writes:
> On Tue, Sep 21, 1999 at 20:23:00 -0700, Daniel Quinlan wrote:
> > The primary reason distributions are permitted to install software in
> > /opt is that some commercial software may come hard-coded that way.
> > Given the DFSG, that should never
Joseph Carter <[EMAIL PROTECTED]> writes:
> Anyway, if those dirs should exist (and I think they probably should as
> they're useful for providing symlinks to other dirs to keep paths and the
> like sane) should we actually create them or rely on the sysadmin to do
> that if they plan to use those
This change of style already reached consensus once (that's why the
releases and the official CDs are both labeled this way).
The documentation is out of date, and should cite examples like 1.2r3
Cheers, Phil.
Raul Miller <[EMAIL PROTECTED]> writes:
> 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 s
Julio <[EMAIL PROTECTED]> writes:
> Given the comments on my proposal, I'm rewriting it to the following:
>
> 1. to provide support for separation of local initialization
> scripts, allow update-rc.d to handle subdirectories. So, a
> /etc/init.d/local (or whatever) dir could be created and a scri
Ben Collins <[EMAIL PROTECTED]> writes:
> I think sticking with an env will make it much easier for some one to just
> use dpkg-buildpackage (without modification) and call it like:
>
> BUILD_DEBUG=y && dpkg-buildpackage -B
Just a minor nit. That should be:
BUILD_DEBUG=y dpkg-buildpackage -B
"Marco d'Itri" <[EMAIL PROTECTED]> writes:
> On Aug 26, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
>
> >> But only fcntl() locking is not enough, because Linux 2.0.* doesn't
> >> support this over NFS and then we have no locking over NFS.
> >
> >And linux 2.2.x with a userland server also do
Gordon Matzigkeit <[EMAIL PROTECTED]> writes:
> Can somebody remind me again why it's so important to be FHS-compliant
> on this issue? Why not just change the few /usr/share/doc packages
> back to /usr/doc,
Because people who want to save disk space by mounting architecture
independant director
> > Finding that you cannot rebuild a package, that built perfectly
> > yesterday, simply because you decided to have a look at the latest
> > kernel source, is very depressing.
>
> Any Joe User will expect the correct headers to be in place. Any user
> that is building unstable kernels will know
Ben Gertzfield <[EMAIL PROTECTED]> writes:
> Yes and no. :) There is a default install that assumes #include
> is your current kernel version, and it does
> not prompt you for a -I to specify. It's not difficult to edit
> the makefiles by hand and add this, but Joe User is never going
> to be abl
Steve Greenland <[EMAIL PROTECTED]> writes:
> This is a bizarre interpretation. If it unpacks to the same code (such
> that "diff -r" produces no output), it's effectively the same source.
> Who cares about the packaging? (Yes, I understand that it screws
> up md5sums/whatevers on the archive. So
[EMAIL PROTECTED] (Karl M. Hegbloom) writes:
> /dev/ttySx ought to be group owned by `dialout'. The directories
> where the `uucp' programs need writes ought to be owned by a `uucp'
> user and group `uucp'. The `uucp' user should be put into the
> `dialout' group. Where does `dip' fit in?
Daniel Martin <[EMAIL PROTECTED]> writes:
...
> I would conclude from this that the imapd (or is it c-client?) authors
> don't know when they want to use $MBOXROOT and when they want to use
> $HOME; in fact, I doubt if it is ever tested upstream with $MBOXROOT
> set to anything other than $HOME.
S
> Philip Hands <[EMAIL PROTECTED]> took the time to put together a simple perl
> script that does this and packaged it into a program called debian-test.
> As you can tell by the version number, it's just something to get us
> started with, wishlist bugs are welcome.
Ther
> ip-{up,down}.d scripts take no parameter at this time, so any new parameter
> would be ignored. I think it would be reasonable to add the init.d ability
> and depreciate the older method, maintaining it for compatibility. The new
> files would be symlinks, so...
There's problem with this propo
> As soon as I have confirmation that the maintainers have
> indeed agreed to hand over control, I shall upload a new revision of
> the policy documents, with no changes except to the maintianer
> field.
I'll do it for you on debian-policy.deb if you like.
We're setting the maintainer t
> Philip> I think I'm the Policy Czar, if we have one.
>
> You. Have. Got. To. Be. Kidding. You mean you missed the two
> weeks of discussion, followed by the 10 day voting period, the vote
> results, the discussion of the vote results, my reply to Jim about
> the current state of affars
Jim Pick <[EMAIL PROTECTED]> wrote:
> I'm not clear on what our current setup is for that. Do we have a policy
> czar? Maybe it goes up to Ian Jackson?
I think I'm the Policy Czar, if we have one.
> Maybe he'd like to put it to a
> developer vote. I'm not sure. Does anybody h
> Phil writes:
> > Especially since there is really no possibility of having DFSG free
> > license, since any DFSG license would be self-referential and I'm not
> > convinced any of the legal profession are going to put up with that sort
> > of thing.
>
> -
> However, the essential package that provides
> /usr/doc/copyright caould well live in the verbatim section. We
> should not compromise on our free license stance any more than we
> compromise on our free software stance.
I don't mind either way on this example, but if you follow this lo
> You have heard incorrectly. The GPL comes with this immutable
> license:
> __
> GNU GENERAL PUBLIC LICENSE
>Version 2, June 1991
>
> Copyright (C) 1989, 1991 Free Software Fou
> So if we do not go with a verbatim section, even the
> freely redistributable standards can't be part of Debian. And I think
> that is sad.
Unless we decide to define ``verbatim'' to be ``part of Debian'' :-)
Cheers, Phil.
>
> >
> >Including anything that is non-DFSG in main, means that people have to
> start
> >checking licences, before playing with the source --- a Bad Thing IMHO.
> >
> >Cheers, Phil.
> >
> >
>
>
> People should always check licenses when they are playing with source.
> "was that library LGPL or
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> I think that mutable strandards are an anathema: supporting a
> plethora of modified almost standards dilutes the benefits of a
> standard, the strength of a standard lies in the fact that *everyone*
> follows the same document.
I agree absolu
> Marcus> a) Without documentation, you can't use the software.
>
> Does not apply to a standard. You use the standard by reading
> it -- nothing has to be modified. A standard is not documentation for
> a program.
Ok, lets take an example I know about: Mgetty and the Class 2 Fax standa
> 1.2. People Seconding the Proposal
> --
>
> Well, since Michael Alan Dorman and Richard Braakman have volunteered
> to serve on the policy maintainer team, I think they have no objection
> to being seconds.
>
> 1. Michael Alan Dorman <[EMAIL
> The fact that I may be a policy maintainer does in no way
> lessen my ability, as a Debian developer, to send in a proposal to
> amend policy.
Right, to get us past any circular arguments on this front, I'm uploading a
New Maintainer Upload of debian-policy, including a few minor bug fi
> Hi,
> >>"Jules" == Jules Bean <[EMAIL PROTECTED]> writes:
>
> Jules> I don't think it would be appropriate to post it to
> Jules> debian-devel. It's a policy issue. It belongs here. I
> Jules> suppose one could make a concession by posting an update every
> Jules> n weeks to debian-devel
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Lacking a formal process, I would still like to reasonable
> sure that the change indeed is something to which there is no serious
> objection; and that requires, I think, possibly an announcement on
> Debian devel (stating the change, and requ
> Hi,
> >>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
>
> Philip> This seems reasonable.
>
> Indeed.
>
> Philip> If no one objects I'll upload a copy of the policy manual
> Philip> with this change.
>
>
Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> Philip Hands:
> > Is nogroup guaranteed never to own any files ?
>
> The Policy manual does not guarantee it, but it's the only reason for
> the group (and the corresponding user) to exist in the first place.
> Actually
Raul Miller <[EMAIL PROTECTED]> wrote:
> I don't think we should hold up hamm for this, but I don't
> think we should be making cds with these binaries on them.
OK. Is this something like a consensus ?
Make the CD's without the controversial contrib binaries, and sort
the archive out once we've
Ted Whalen <[EMAIL PROTECTED]> wrote:
> I've generally found that rudderless committees lead to impasse.
> Perhaps if we redesignate the 'policy manager' the 'policy chairman'.
> Moving the position away fron definition of policy and final decision
> making and towards /leadership/ of the policy
> Hi,
> >>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
>
> Philip> I think the ``one underscore, many dashes'' layout must be
> Philip> legal, since we already have some
> Philip> (libc6-pre2.1-doc_2.0.93-980414-1.deb, it
> Whoa. Are these legal? Are we sure that it's OK to have an
> underscore *inside* a version, or to have more than one dash within a
> version. By OK, I don't just mean "does dpkg choke on it".
>
> Perhaps this is OK, but we should be careful. If we get too liberal
> with our allowable version
> > Something along the lines of
> >
> > foo-1.2.2-1.2.3alpha-1
>
> In which case, this comes out as
>
> > foo_1.2.2_1.2.3alpha-1
or even
foo_1.2.2-1.2.3alpha-1
I obviosly haven't been getting enough sleep.
Cheers, Phil.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject o
> > foo-1.2.2foo-1.2.2-1
> > foo-1.2.2-2
> > foo-1.2.3alpha foo-1.2.2.99.1-1
> > foo-1.2.2.99.1-2
> > foo-1.2.3betafoo-1.2.2.99.2-1
> > fo
> Philip> The ``put the painful bit after the dash in the debian
> Philip> version'' suggestion is no good I'm afraid, because the
> Philip> orig.tar.gz ends up giving the impression that Debian has the
> Philip> release version already, whereas it's just the pre-release
> Philip> version with
> I'm still really vague on what REAL technical objection has been raised to
> actually using (oh, horror!) epochs. Yes, it will remain in the version
> number "forever". So what? Who cares? If the epoch reaches 50, who is
> going to notice and care? The reason we use the upstream version numb
Manoj,
Was my previous mail really that annoying ? If so, I apologise profusely (I
was fairly tired at the time I wrote it, so may have started to be rather more
argumentative that I meant to be)
I think we actually hold fairly similar opinions about this subject. Did you
ever see my previou
On 29 Apr 1998, Manoj Srivastava wrote:
> Hi,
> >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes:
>
> Dale> The Policy Statement is a set of rules for the behavior of
> Dale> developers, set down by the "ruling body", sometimes referred to
> Dale> as "the government". When those rules are view
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Philip> [Oxford English Dictionary] policy[1]: noun. prudent conduct,
> Philip> sagacity; course or general plan of action (to be) adopted by
> Philip> government, party, person etc.
>
> Raul Miller <[EMAIL PROTECTED]> also quoted things
> simila
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Raul> Since when is "The flight of the Bumble Bee" the right thing to
> Raul> do?
>
> Since I decided on it. What is to prevent me?
This epitomises the point you insist on missing here.
What prevents you, is YOU. If it turns out that you are a
> I hereby propose an "Aleph-zero-policy", that controls how
> meta-meta-...-meta-policies are handled.
>
> Uh, did I mention the Aleph-one-policy" ?
>
> Marcus
ROFL :-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> ``We are a bunch of 300 developers who maintain 2000 packages. Since
> everyone knows best how to solve upcoming problems and since everyone
> always agrees with others--or in case of disagreement we have a
> constitution--there is no need to specify who is working on what part.
> Everyone
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
> > I shall have to think about how far do we go, and how to limit
> > the scope of this document. I do not think we can cover secure
> > programming, portable programming, introduction to common softeware
> > tools, historic bugs, I/O progra
> [EMAIL PROTECTED] (Philip Hands) wrote on 10.04.98 in <[EMAIL PROTECTED]>:
>
> > > I have one point to add to this. Handling files not mentioned
> > > in the *.list file was one way of several packages to handle/edit a
> > > common file, for example,
> Hi,
> >>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
>
> Philip> For example, suppose we decided to move `organisation' to be
> Philip> under /usr/share at some point in the future. I can see how
> Philip> we would arrange this with
> Hi,
>
> I was thinking about /etc/news/organization. Seems silly to
> have a package just have that file. All kinds of packages depend on
> it -- mailagent, vm, gnus, news-readers, news servers
>
> Seems easier to look for the file, and ask the user for an
> organization and
> Hi,
>
> I have one point to add to this. Handling files not mentioned
> in the *.list file was one way of several packages to handle/edit a
> common file, for example, if a bunch of packages need /etc/foo to
> exist, and foo can contain the word bar or bah, then any package, in
> the p
> On Tue, 7 Apr 1998, Philip Hands wrote:
>
> > OK, an example where it might make sense to have a non-configuration file,
> > listed as a conffile:
> >
> > A package includes a script (under /usr/bin say) that is commonly
> > customised by the local
> Hi,
> >>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
>
> Joey> Manoj Srivastava wrote:
> >> I do seem to remember the policy manager coming with a resolution
> >> that so stated. Conffiles are a strict subset of configuration
> >> files.
>
> Joey> I know he didn't, becuase if he had, I would
> Kevin Dalley wrote, referring to Bug#18118:
> >It would be nice if postgresql upgrade would remove the lines from
> >/etc/crontab which were added by previous version of postgresql.
>
> For a while, it did. Nevertheless, it is a violation of policy to
> modify /etc/crontab, which is why I
> The reason is that inside of debian/rules a stamp-file is used
> to indicate that the build process was successful. Unfortunately
> this stamp-file is called 'build' - similar to the target I have
> to use
That's what the .PHONY: target is for:
---
bash-2.01$ cat rules
build:
touch b
Charles Briscoe-Smith <[EMAIL PROTECTED]> wrote:
> Right. Since they're under /etc, they should be conffiles, to avoid
> nasty suprises. However, they won't be -modified- conffiles simply
> because the sysadmin doesn't want them run.
>
> I'd suggest the following:
>
> When run-parts is started,
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> That was my original proposal, except it was more genral than
> just fetchmailrc. To refresh peoples memory:
>
> Non-conffile /etc/ppp/ip.conf is searched like so:
> egrep "^fetchmail.*UP=YES' /etc/ppp/ip.conf || exit 0
>
> One line, w
Hi,
I'd just like to make my position (as ppp maintainer) clear on this ip-up/down
issue (I've been off skiing for a week, so have not been able to get involved
before this).
People seem to be drawing a couple of false conclusions from the fact that I
changed the ip-up/down scripts to use run-
Ian Jackson <[EMAIL PROTECTED]> wrote:
> Furthermore, noone has yet to my knowledge come up with a good
> argument as to why we should distribute source code in .deb files,
> when we have a much better scheme for source code.
The reason for doing this is in those cases where people who under norma
> > "Martin" == Martin Schulze <[EMAIL PROTECTED]> writes:
>
> > On Fri, Jan 09, 1998 at 03:16:00PM +, Ian Jackson wrote:
>
> >> Some people might want to be able to prefilter their mail into
> >> folders for different packages, and so encode the package into
> >> the emai
> Let's make a conffile every script in /usr/bin, then.
Santiago,
Please shut up.
In order to change the status quo, you need to come up with a positive reason
for doing so (in this case, an example of a /etc/init.d script that definitely
should not be a conffile might be nice).
Saying ``I th
> -force reload?
I think we need to choose a single word for this, to minimise the script
changes. A single word would allow a simple chang to the case statement in
most cases:
- reload )
+ reload | rewibble )
Possibilities for ``rewibble'':
force-reload
revisit
or from the Oxf
> > Try looking at how exim does it---it adds a crontab for the mail user, but
> > does correctly handle the mail user's existing crontab.
> >
> > To install it does this:
> >
> > # Install in crontab for user mail if not there
> > oldcrontab=$(crontab -u mail -l|t
73 matches
Mail list logo
