Anthony Towns wrote:
> On Thu, Jun 28, 2001 at 10:10:27AM +0100, Edward Betts wrote:
> > # 2.3.3. The description of a package
> > # ---
> > # Copyright statements and
> > # other administrivia should not be includ
Section 2.3.3 of policy says copyright information should not appear in
descriptions.
# 2.3.3. The description of a package
# ---
#
# Every Debian package must have an extended description stored in the
# appropriate field of the control record.
#
#
Arthur Korn <[EMAIL PROTECTED]> wrote:
> Hi
>
> > > On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote:
> > > > Also make the package check for the presence of the character device
> > > > /dev/.devfsd first, if that device exists then your script must not
> > > > attempt to create the
Juliusz Chroboczek <[EMAIL PROTECTED]> wrote:
> Now POSIX leaves the behaviour of ``echo'' with arguments starting
> with `-' undefined (in order to accomodate both SYSV and BSD versions
> of echo). In addition, POSIX allows echo to be a shell builtin.
>
> Therefore, the script given in 3.3.6 wil
Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
> > RMS just asked me if it was true that all our packages don't include
> > the GPL, just a reference to it, since that is a violation of the
> > GPL itself. In his words:
>
> we do not remove the copyright. it is still in the source. I fail to see
Branden Robinson <[EMAIL PROTECTED]> wrote:
> Our Xaw-replacement handling is seriously pathological in every sense of
> the term.
>
> This will no longer be a concern in woody. With XFree86 4.0.1, libXaw is
> coming out of xlib6g and can be handled with the normal
> Conflicts/Replaces/Provides m
Joey Hess <[EMAIL PROTECTED]> wrote:
> There has been some discussion lately on debian-deval (and a bit on
> -policy) about init scripts. One concern that has arisen is that it can
> be very annoying to have to modify an init script to change a simple
> value in it, and then be forced to maintain y
David Benson <[EMAIL PROTECTED]> wrote:
> PROPOSAL:
> Shared libraries and "plugins" should be
> distinguished (and defined) explicitly by policy.
>
> The intent is that policy section 4.3 will
> no longer apply to plugins, just shared libraries.
>
> PROPOSED CHANGE:
>
>
Santiago Vila <[EMAIL PROTECTED]> wrote:
> On Tue, 8 Feb 2000, Branden Robinson wrote:
> >
> > That's because people like Santiago Vila can't distinguish informative
> > statements from normative ones.
> >
> > I'm all for a kind of markup which well spell it out to dolts.
>
> Branden, will you l
Nicolás Lichtmaier <[EMAIL PROTECTED]> wrote:
> Package: debian-policy
>
> This is already standard, but I think it should be into policy because I
> already saw some programs deviating from this expected behaviour.
>
> Web clients should default to try to fetch URLs by a direct connection to
> t
in there. People can then decide to
have both libsocks libraries and one of the -dev packages. What do you think,
Am I right?
--
Edward Betts
Adam Heath <[EMAIL PROTECTED]> wrote:
> Format: 1.6
> Date: Sat, 4 Dec 1999 04:12:28 -0600
> Source: hello
> Binary: hello
> Architecture: source i386
> Version: 1.3-16
> Distribution: unstable
> Urgency: low
> Maintainer: Adam Heath <[EMAIL PROTECTED]>
> Description:
> hello - The classic
Branden Robinson <[EMAIL PROTECTED]> wrote:
> On a completely different subject, I'm not so sure that TeX and LaTeX
> should really be standard. I know that they're commonly found on Unix
> systems, but so is X. X was excluded from standard, I think, partly
> because of its size and partly becaus
Joey Hess <[EMAIL PROTECTED]> wrote:
> Manoj Srivastava wrote:
> > If I recall the discussion that went on before that was
> > included in policy correctly, we decided to let that be the decision
> > of the developer (there is something to be said about allowing the
> > developer some le
Joey Hess <[EMAIL PROTECTED]> wrote:
> 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?
>
> I continue to disagree that this has an
Branden Robinson <[EMAIL PROTECTED]> wrote:
> > bitmaps: /usr/X11R6/include/bitmaps
> This is wrong.
>
> > /usr/X11R6/include/X11/bitmaps
> This is correct.
>
> > pixmaps: /usr/X11R6/include/X11/pixmaps
> This is correct.
>
> > /usr/sha
Julian Gilbey <[EMAIL PROTECTED]> wrote:
> bitmaps: /usr/X11R6/include/bitmaps
> /usr/X11R6/include/X11/bitmaps
> pixmaps: /usr/X11R6/include/X11/pixmaps
> /usr/share/pixmaps
I think either /usr/share/pixmaps or /usr/share/bitmaps would be best.
--
I consume, therefore I am
Most of the files in my /var/log directory are owned by root.adm, some have
the group set to root, why?
--
I consume, therefore I am
Ulf Jaenicke-Roessler <[EMAIL PROTECTED]> wrote:
> I'd like to mention some general problems with packages migrating
> from /usr/doc to /usr/share/doc. Some of these problems exist,
> although they are very hard to explain and/or to reproduce.
>
> For example, I found that libpanel-applet0 le
Michael Alan Dorman <[EMAIL PROTECTED]> wrote:
> Personally, I think it's smarter to keep the development package
> unversioned. I have what I think is a technical argument: libjpeg.
>
> libjpeg has used a versioned -dev, and look at a lot of the problems
> we've had with libjpeg, where months a
Brian May <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> you write:
> >My understanding was that static IDs were for packages that did include the
> >code to support dynamic IDs. There is no really reason at all for a package
> >to
> >have a static ID.
>
> Wrong! Lets demonstrate by
Brian May <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> you write:
> >Please provide a rationale. Some of my packages need a static ID (64000
> >is assigned, the only one assigned so far) because their spool could
> >need to be NFS shared.
>
> As the maintainer of diskless, I am curi
Anthony Towns wrote:
> ] 2.1.3. The contrib section
> ] --
> ]
> ] Every package in "contrib" must comply with the DFSG.
> ]
> ] Examples of packages which would be included in "contrib" are
> ] * free packages which require "contrib", "non-free", or "no
Joey Hess <[EMAIL PROTECTED]> wrote:
> Doesn't anyone else feel this is a hack? Look at how apt does it (parse a
> Packages file, and use that info to get package versions and decide what
> needs to be updated, and then look at only those files) for a much better
> method.
>
> Basically, no one in
Gordon Matzigkeit <[EMAIL PROTECTED]> wrote:
> Do you have any tangible examples of an architecture-specific example
> file? Maybe I haven't been following this thread closely enough,
> because I've only seen discussion of ``what-if'' scenarios.
$ ls -l /usr/doc/samba-doc/examples/examples/validc
On debian-policy, Joey Hess <[EMAIL PROTECTED]> wrote:
> My rationale for mandating a changelog.gz is for consitency, so you can
> easily find the changelog in every package.
>
> I don't have a rationale for requiring a html changelog, because that is
> already in policy. It went in last fall, I b
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
> My proposal is, in short, the following: Define six new fields for
> debian/control and specify their meaning. The six new fields are used
> only in .dsc files and in the first paragraph of debian/control. They
> are:
>* Depends
> S
On debian-policy, Joey Hess <[EMAIL PROTECTED]> wrote:
> Ok, I accept the amendment into my proposal. The new proposed text:
>
> If the upstream changelog file is HTML formatted, it must be accessible as
> `/usr/doc//changelog.html.gz'. A plain text version of the
> changelog must be accessi
On debian-policy, Thomas Schoepf <[EMAIL PROTECTED]> wrote:
> [Please CC me, I'm not subscribed to this list]
>
> I have a package that contains a README file with the program's history at
> the bottom. I've read the Policy about changelog files but afai can see
> this is a special case.
>
> Curr
On debian-policy, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Hi,
> >>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
>
> Wichert> Manoj, what happened to the utmp-group proposal? I don't see it
> Wichert> mentioned in the changelog..
>
> Actually, going in to add this t the
On debian-policy, joost witteveen <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I've just released menu-2.0. It has many new features, one of
> wich is the automatic optimization of the menu tree, using
> something I've called "hints". This is what I want to start
> discussion about with this messa
ien Ninoles; seconded by Sean E. Perry, Edward
> Betts and Peter Makholm.
> * Creation of a sub-directory aside from main, contrib, non-free
> named data, that will hold non-program related data.
> Data section (#38902)
> * Stalled for 1 week.
> * Proposed on 3 Ju
On debian-policy, "Davide G. M. Salvetti" <[EMAIL PROTECTED]> wrote:
> My answer simply is: so be it.
>
> How could we build a completely free OS if we didn't separate out
> non-free from free software?
>
> If bsdgames-non-free contains non-free software, it cannot be part of
> Debian, and there
On debian-policy, "Davide G. M. Salvetti" <[EMAIL PROTECTED]> wrote:
> My answer simply is: so be it.
>
> How could we build a completely free OS if we didn't separate out
> non-free from free software?
>
> If bsdgames-non-free contains non-free software, it cannot be part of
> Debian, and there
On policy, Chris Lawrence <[EMAIL PROTECTED]> wrote:
> Therefore, I propose that we permit the use of bzip2 to compress
> source package files (.orig.tar and .diff for most packages, .tar for
> native packages). I further propose that the use of bzip2 be
> mandatory for newly uploaded source files
On debian-policy, "Davide G. M. Salvetti" <[EMAIL PROTECTED]> wrote:
> Patent restriction does not imply freedom restriction: they are two
> very different matters. In other words, gimp-non-free is misnamed,
> and (software license permitting) it should go directly to
> non-US/main, which is main
On debian-policy and debian-devel,
"Davide G. M. Salvetti" <[EMAIL PROTECTED]> wrote:
> Technically, I think the matter should be resolved by our installation
> tools ("I see you requested package foo, that depends on package bar;
> however package bar is not available on your source media (CD-ROM
On debian-policy, Chris Waters <[EMAIL PROTECTED]> wrote:
> Making this policy would require modifying a *huge* number of
> programs. The EDITOR and VISUAL variables are *NIX traditions, and
> are already supported by most well-written programs, and even many
> badly written ones.
>
> IOW, we sup
On policy, Oliver Elphick wrote:
> verse doesn't use bible-kjv-text for its source, but a compilation of
> quotes that its original author put together. It is actually a rather
> small package, with a 38Kb deb, including the verses. It's on a par
> with, say, fortune. I don't think it really fi
On Bug #38902, "Darren O. Benham" <[EMAIL PROTECTED]> wrote:
> The data section would be governed by the following rules:
> - No package can depend on a package in data.
Where does that leave bible-kjv, bible-kjv-text and verse?
Can a package in main recommend a package in data?
> - No package w
On debian-policy, Steve Greenland <[EMAIL PROTECTED]> wrote:
> What Ray said, only more so. Programs must use $EDITOR if available,
> because that is what the user sets.
>
> However, the "sensible-editor" idea is somewhat independent, in that iff
> EDITOR is not set, it could adjust according to s
On policy, Santiago Vila <[EMAIL PROTECTED]> wrote:
> Among other things: Old awk is not guaranteed to have user-defined
> functions (if I'm not mistaken).
>
> However, I have yet to see an awk packaged for Debian
> which is not a new awk.
original-awk ?
--
I consume, therefore I am
On policy, Santiago Vila <[EMAIL PROTECTED]> wrote:
> > Yes, I see what you are saying, but why should we worry about tweaking
> > upstream software in various packages (and who knows which they'll end
> > up being?) to use "awk" instead of "nawk" when we can simply provide a
> > nawk -> awk symlin
On policy, Julian Gilbey <[EMAIL PROTECTED]> wrote:
> > What about the ordering in /etc/rc?.d is it important, should we not be
> > restarting stuff out of order?
>
> I would guess not; these are not facilities being restarted but newly
> installed ones. If there is a desperate problem with this,
On policy, Piotr Roszatycki <[EMAIL PROTECTED]> wrote:
> > (That is, we should check whether /etc/rcN.d/{S,K}??script exists
> > where N is the current runlevel and start or stop the script
> > appropriately if it does -- see the rest of this bugreport for
> > details.)
> >
> > I second this propo
On debian-policy, Julian Gilbey <[EMAIL PROTECTED]> wrote:
> What is the status of accepted policy amendments which have not yet
> been incorporated into policy?
>
> In other words, is it OK to announce the move to FHS on
> -devel-announce so that developers can start making the necessary
> change
On debian-policy, Branden Robinson <[EMAIL PROTECTED]> wrote:
> I see so reason /usr/X11R6 has to continue to exist at all.
>
> /usr/{bin,include,lib}/X11/ is the canonical path with which to reach X
> stuff.
>
> Therefore,
> /usr/bin/X11 would be a symlink to /usr/bin (X11 -> .)
> /usr/inclu
On Wed, 26 May, 1999, Fabien Ninoles wrote:
> > On Tue, May 25, 1999 at 10:35:57AM +0100, Edward Betts wrote:
> > > I changed the description so it does not say it is a mirror anymore:
>
> Creation of a sub-directory aside from main, contrib, non-free named
> data.
>
On Sun, 16 May, 1999, Johnie Ingram wrote:
>
> "Dirk" == Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
>
> Dirk> So it was suggest to create an empty ogonkify package (which
> Dirk> would depend on a2ps) to give ogonkify more visibility.
> Dirk> Is this considered to be a good or a bad idea ?
>
On Sat, 15 May, 1999, Dirk Eddelbuettel wrote:
> Soemone recenly announced an ITP ogonkify. Yes, this already exists, but is
> part of a2ps. Both the upstream authors of a2ps and of ogonkify are happy
> with that situation and don't feel strongly in favour of a distinct ogonkify
> package.
>
> So
On Sat, 15 May, 1999, Chris Waters wrote:
> I've thought about that one myself, and I do like the idea, but there
> may be issues -- I'm not quite sure why some window managers have a
> separate section for things like exit and restart while others don't,
> and there may be reasons, so I'd like to
On Sat, 15 May, 1999, Chris Waters wrote:
> TWO: Create the menu_policy.txt file, using the text below. Note that
> the heirarchy is the one proposed by Joey Hess, with my suggestion of
> "Help", which he seconded, and someone else's suggestion of
> "Apps/Databases", which received a few seconds.
On Mon, 03 May, 1999, Johnie Ingram wrote:
>
> "Edward" == Edward Betts <[EMAIL PROTECTED]> writes:
>
> Edward> So IRC and AOL are free clients, non-free servers with no
> Edward> free alternatives, can we do the same with file formats?
>
> Bah, its
On Sun, 02 May, 1999, James Troup wrote:
> Edward Betts <[EMAIL PROTECTED]> writes:
>
> > So IRC and AOL are free clients, non-free servers with no free
> > alternatives,
>
> There are free IRC servers, e.g. the ircd package in main.
Sorry, I meant ICQ not IRC.
On Sat, 01 May, 1999, James Troup wrote:
> I've just rejected tik from Incoming[1] because it was targeted for
> main and as far as I can see depends on a non-free server to be
> useful. I've argued this before, for example when Adam wanted to
> upload his netscape-base (IIRC) to main. The packag
55 matches
Mail list logo
