On Tue, 2003-07-01 at 10:41, Manoj Srivastava wrote:
> severity 197835 wishlist
> severity 197835 fixed
> retitle 197835 [FAILED]: integrated environments are allowed
> thanks
>
> Hi,
>
> Far from reaching close consensus on this issue, this proposal
> has met stiff opposition, and discu
On Wed, 2003-06-18 at 17:02, Bill Allombert wrote:
> Not really because we are only talking about the Debian default.
I thought we were talking about EDITOR and BROWSER, which are common on
other systems as well.
> All GNOME
> programs I have seen have a way to change the default locally, so th
On Wed, 2003-06-18 at 15:56, Chris Waters wrote:
> If the history of the vi vs. emacs flamewars teach us anything, it's
> that most experienced users would rather fight than switch when it
> comes to editors. Frankly, if some stupid app insists on ignoring
> what I've defined as the One True $EDI
On Wed, 2003-06-18 at 14:44, Colin Watson wrote:
> On Wed, Jun 18, 2003 at 02:11:06PM -0400, Colin Walters wrote:
> > On Wed, 2003-06-18 at 13:36, Bill Allombert wrote:
> > > Not having the buildd installing tons of unneeded packages reduce
> > > build problems and
On Wed, 2003-06-18 at 10:11, Sebastian Rittau wrote:
> Normally they don't have a good reason,
I outlined a ton of good reasons earlier. See:
http://lists.debian.org/debian-policy/2003/debian-policy-200306/msg00115.html
> except that they can rely on the
> existance of that editor. *If* I set
On Wed, 2003-06-18 at 13:36, Bill Allombert wrote:
> As for your solution, this is a matter of taste between cleanness in the
> code and cleaness in what is done.
>
> I prefer the later.
I am most interested in what the buildd maintainers think. James?
> Not having the buildd installing tons
On Wed, 2003-06-18 at 05:00, Colin Watson wrote:
> [As Joey said recently in another discussion, please follow up to the
> bug, not to debian-policy.]
Yeah, sorry, I have a habit of just hitting Reply To List.
> On Wed, Jun 18, 2003 at 01:02:37AM -0400, Colin Walters wrote:
> *
On Wed, 2003-06-18 at 06:16, Bill Allombert wrote:
> On Tue, Jun 17, 2003 at 06:27:11PM -0400, Colin Walters wrote:
> > On Tue, 2003-06-17 at 06:50, Andrew Suffield wrote:
> > > (or possibly an alias for build-arch)
> >
> > Then it seems to me what you want is to m
On Tue, 2003-06-17 at 20:28, Colin Watson wrote:
> I think this is very bad. At the moment policy says that my EDITOR and
> PAGER variables have priority over what random programs think is a good
> idea, which I think is excellent.
Yes...but the idea is if programs have a preferred version for a
Package: debian-policy
Version: 3.5.10.0+cvs20030617
Severity: normal
Hi,
The following patch attempts to codify the current practice wrt
integrated environments (can anyone think of a better term? I just sort
of made that up). There should be no changes required to programs as
far as I know, th
On Tue, 2003-06-17 at 06:50, Andrew Suffield wrote:
> When I do it, I ignore what policy says and do what works. That means
> the build target is a no-op
This, of course, has the disadvantage of making the build target
useless.
> (or possibly an alias for build-arch)
Then it seems to me what y
On Tue, 2003-06-17 at 16:58, Bill Allombert wrote:
> If browser is a per-user preference, this should be a constant value for
> a particular user if he has not set the preference, and letting each
> programs start their browser of choice should be wrong. Debian needs to
> be consistant.
Sure, Deb
On Tue, 2003-06-17 at 15:40, Bill Allombert wrote:
> Then as long as it is a per-user decision and not a per launcher
> program, I cannot find anything wrong with Joey proposal.
The only problem is that Joey's proposal makes programs with a preferred
browser buggy.
> Users have already a way to
On Tue, 2003-06-17 at 06:31, Bill Allombert wrote:
> Then I have a question: If a user use both KDE and GNOME stuff in a,
> say, KDE environment, should x-www-browser always launch konqueror
> or have GNOME programs launch the GNOME browser ?
I'm not sure what you mean; x-www-browser is just a sy
On Mon, 2003-06-16 at 19:15, James Troup wrote:
> Colin Walters <[EMAIL PROTECTED]> writes:
> >> If Build-Depends-Indep were
> >> installed to satisfy 'build' their entire raison d'etre would be
> >> voided.
> >
> > The buildds[...]
On Mon, 2003-06-16 at 17:09, Bill Allombert wrote:
> On Mon, Jun 16, 2003 at 12:55:45PM -0400, Colin Walters wrote:
> > This, I have a big issue with. Let's say I have a multiuser system
> > where I install GNOME and KDE. Now, suppose konqueror registers itself
> > at
On Mon, 2003-06-16 at 15:06, Joey Hess wrote:
> > This proposal is probably great for unintegrated environments, but some
> > sort of exception should be made for integrated ones.
>
> The funny thing is that this proposal is just a reworking of section
> 12.4 of policy which deals with editors and
[ Let's move this discussion to -policy, where it belongs. For
people reading -policy, the context is in bug #197100. ]
On Mon, 2003-06-16 at 16:45, James Troup wrote:
> I don't think it's a bug in the buildds.
And you do think it is a bug in laptop-net? (really cdbs) I don't.
> If Build
On Mon, 2003-06-16 at 17:09, Bill Allombert wrote:
> No, this is not broken, this is just not what you would prefer. Currently,
> mozilla or worse netscape is hardcoded in lot of software and they do
> not even check whether they are available. *That* is broken.
> Joey has spent a lot of time fix
On Mon, 2003-06-16 at 14:23, Joey Hess wrote:
> (Please restrict followups to the bug report, it's a PITA to have to go
> back and search debian-policy for discussion relating to a proposal.)
Oops, sorry about that.
> You cut out the bit that says
>
> In addition, programs should choose a good
On Mon, 2003-06-16 at 11:36, Joey Hess wrote:
> Thus, every program that launches a web browser with an URL must
We're making this RC?
> use the
> BROWSER environment variable to determine what browser the user wishes
> t
On Fri, 2003-06-13 at 03:57, Colin Watson wrote:
> On Fri, Jun 13, 2003 at 01:40:34AM -0400, Colin Walters wrote:
> > I don't quite understand the point of having the 'build' target be
> > mandatory.
>
> dpkg-buildpackage requires it. You'd have to make
Hi,
I don't quite understand the point of having the 'build' target be
mandatory. My problem with it is precisely what policy says:
> For some packages, notably ones where the same source tree is
> compiled in different ways to produce two binary packages, the
> `build' target does not make much
On Mon, 2003-06-09 at 12:05, Henrique de Moraes Holschuh wrote:
> On Sun, 08 Jun 2003, Wouter Verhelst wrote:
> > [EMAIL PROTECTED]:~$ echo $LANG
> > nl_BE.UTF-8
>
> Is it in locale.gen? Otherwise, you will NOT have the locale information...
Ah, good call. We should have that in the default loca
[ no need to CC me ]
On Sat, 2003-06-07 at 17:39, Wouter Verhelst wrote:
> No, I'm using bash...
Weird. It works here. What's your $LANG? If you're inputting Unicode
it should probably be something.UTF-8.
On Sat, 2003-06-07 at 15:36, Wouter Verhelst wrote:
> Yeah, but it's not always as good as the legacy support is. For
> instance, last I tried uxterm (like, 2 minutes ago), I put in a euro
> sign somewhere. Which appeared correctly (hurray), but doing backspace
> over that didn't do what it was su
On Sat, 2003-06-07 at 13:43, Dmitry Borodaenko wrote:
> I don't see it as a proper credit to your contributors if their name
> appears as 'J?rg?n' (or even '' in case of Kanji) on my display.
That's a problem with your display.
> What I objected to is that they may: I'd rather they may not.
On Sat, 2003-06-07 at 09:59, Dmitry Borodaenko wrote:
> I am using KOI8-R terminal which can not display Latin-1 characters, and
> it seems backward to me to mandate or even allow _usage_ of UTF-8 ahead
> of getting it _supported_ across the system.
A growing amount of software in Debian has UTF
On Fri, 2003-06-06 at 12:37, Bill Allombert wrote:
> 1) Changelog are required to be written in english, so non 7bit
> characters should be rare, and use of non latin-1 characters are
> probably not a good idea. For example, writing the name of a
> developer with japanese characters might cause
On Thu, 2003-06-05 at 16:40, Josip Rodin wrote:
> On Thu, Jun 05, 2003 at 02:58:12PM -0400, Colin Walters wrote:
> > The problem is that we have no way to know what encoding an individual
> > Debian Changelog entry is in.
>
> The problem is that my point entirely flew over
On Thu, 2003-06-05 at 08:23, Josip Rodin wrote:
> Ahm. You need it written in the Policy manual to use a 16-bit charset?
As Steve points out, the size of the code space isn't particularly
relevant.
> I don't see all those (7|8)-bit-charset-using people requiring the same...
The problem is that
On Sat, 2003-02-01 at 17:10, Joey Hess wrote:
> As far as I can see, this proposal has one conditional second (from aph
> pending an impact study), and some discussion, and has been stalled
> since mid-January. It also looks to me, from reading the thread, that
> we have an easy consensus on just
On Sat, 2003-01-18 at 03:38, Manoj Srivastava wrote:
> Actually, if we must take a stance, I would say that while
> unicode does remain the only sane choice in the future, at this
> point the only sane choice is pure ascii; for reasons that have come
> up often in this thread.
I think th
On Fri, 2003-01-17 at 17:49, Manoj Srivastava wrote:
> Hi,
>
> Sorry for the late entry into the discussion. I am
> comfortable with making the changelog UTF-8 only, but file names in
> pure UTF-8 perhaps is premature. (मनोज्.conf, anyone?).
Please see my second proposal (the third in
On Thu, 2003-01-16 at 03:55, Denis Barbier wrote:
> Excerpt from http://www.openi18n.org/docs/html/LI18NUX-2000-amd4.htm
>
> portable filename character set
>
>The set of characters from which portable filenames are constructed.
Yes, I saw that. I should have been clearer: They are s
On Wed, 2003-01-15 at 06:15, Colin Watson wrote:
> I think this ought to be a reminder that taking a Debian-specific
> approach to this and reckoning that we can probably "get a fair number
> of upstreams to go along with it" is a mistake. If there isn't a
> widely-accepted standard, we will just
On Tue, 2003-01-14 at 21:50, [EMAIL PROTECTED] wrote:
> And? A POSIX filename is not a string of characters, it's a string
> of bytes. You have no technical need to differentiate between the
> two.
If you do any sort of character-oriented manipulation on those names,
you will.
> Good. It remind
On Tue, 2003-01-14 at 22:28, Junichi Uekawa wrote:
> The point is, we have working "iconv", and
> changing changelog will work.
Yep, definitely.
> man may need some hacking or other, I am not sure.
I hear the other Colin is on the job :)
> Not all of the statements made in that thread are not
On Tue, 2003-01-14 at 02:23, [EMAIL PROTECTED] wrote:
> Not acceptable. Filenames are and must be in the locale charset.
> There is no other sane option [...]
Heh. I will quote from a previous message of mine about filenames in
the locale charset, which, since you joined the discussion later, y
On Sat, 2003-01-11 at 06:21, David Starner wrote:
> You can input any Unicode character you want, but you probably have
> to out of your way to input something outside your charset (i.e. probably
> not on your keyboard or standard IM.)
Ok, that is probably going to be true.
> If I receive a fil
On Thu, 2003-01-09 at 23:05, David Starner wrote:
> Not anything written up that I know of. Debian-i18n has a large cross
> membership, which was part of the reason this should be on debian-i18n.
Ok, if people want to move this discussion that's fine by me.
> >Are you saying that programs should
On Thu, 2003-01-09 at 20:57, David Starner wrote:
> A Posix filename is a null terminated byte string (sans '/'). Any
> widescale conversion is going to cause aliasing issues and other
> bugs, whether or not we stay Posix compatible.
> Just as important, conversion is not an issue for debian-pol
On Thu, 2003-01-09 at 13:28, Jochen Voss wrote:
> Hello,
>
> On Wed, Jan 08, 2003 at 01:00:19AM -0500, Colin Walters wrote:
> > Seriously, I didn't mean it that way; I just meant that I think everyone
> > has generally accepted that UTF-8 is the way of the future; we
On Wed, 2003-01-08 at 18:03, John Goerzen wrote:
> Colin was advocating what amounted to exactly that. He was advocating
> removing all support for non-UTF8 terminals.
Um, woah there. The key word is *eventually*. Again: the only "must"
my present policy proposal introduces is for filenames in
On Tue, 2003-01-07 at 03:07, Jakob Bohm wrote:
> I agree, this is the only way to go. Naive, simple, classic
> UNIX-style programming should continue to "just work",
Naïve, simple, classic UNIX-style programs are ASCII-only. Then someone
got the idea to bolt this huge "locale" kludge on top of
On Mon, 2003-01-06 at 16:15, Jochen Voss wrote:
> Hello Colin,
>
> On Fri, Jan 03, 2003 at 09:50:26PM -0500, Colin Walters wrote:
> > In summary, UTF-8 is the *only* sane character set to use for
> > filenames.
> At least I agree to this :-)
Cool.
> I think that
On Tue, 2003-01-07 at 11:58, Denis Barbier wrote:
> On Tue, Jan 07, 2003 at 10:23:14AM -0500, Colin Walters wrote:
> [...]
> > It looks to me like at this point almost everyone agrees with the
> > content of my proposal in #99933, and we are discussing implementation
> > d
On Tue, 2003-01-07 at 18:50, David Starner wrote:
> If you're using a terminal that can't support UTF-8, you always have the
> option of running
> something like GNU screen to translate the system charset to the terminal
> charset.
> It seems more important to get a systemwide encoding working, t
On Tue, 2003-01-07 at 15:10, John Goerzen wrote:
> Colin Walters <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2003-01-07 at 13:50, John Goerzen wrote:
> >
> > Sorry, we have to start somewhere. Unicode is the way of the future,
> > and if we wait until every ve
On Tue, 2003-01-07 at 14:22, Jochen Voss wrote:
> Hello,
>
> On Tue, Jan 07, 2003 at 10:23:14AM -0500, Colin Walters wrote:
> > It looks to me like at this point almost everyone agrees with the
> > content of my proposal in #99933, and we are discussing implementation
> &g
On Tue, 2003-01-07 at 13:49, Osamu Aoki wrote:
> I think it may be best if this encoding changes are done at the same
> time when this documentation is moved to docbook-xml format.
That's perfectly fine by me.
On Tue, 2003-01-07 at 13:50, John Goerzen wrote:
> I don't disagree. I'm saying that your solution is worse than the problem.
Sorry, we have to start somewhere. Unicode is the way of the future,
and if we wait until every vendor of some random terminal updates it
with support for UTF-8, we will
On Tue, 2003-01-07 at 10:22, John Goerzen wrote:
> Then your solution is broken. Seriously, this would be a huge problem
> for many people.
But the current situation is *already* broken! For example, for a
Chinese person, an ISO-8859-1 system simply cannot encode, nor display,
their language.
On Tue, 2003-01-07 at 04:29, Denis Barbier wrote:
> > but unless someone starts actually _using_ UTF-8, we would never know
> > which tools are broken and which are not (I already found one bug
> > in handling of UTF-8 GPG alias - I'll file the bugreport after some more
> > testing).
Testing our
[ CC's trimmed, since mail to the bug will reach -policy ]
On Mon, 2003-01-06 at 16:07, Jason Gunthorpe wrote:
> Fixing progams that handle terminal input is a different matter IMHO, it's
> something that should be decided on a more case by case basis, and alot of
> cases might be effortless han
On Mon, 2003-01-06 at 16:01, Jochen Voss wrote:
> On Mon, Jan 06, 2003 at 12:21:27AM -0500, Colin Walters wrote:
> > After we have a "sufficient" number of programs supporting UTF-8
> > natively in this way, we change the policy on filenames to a "must",
> &
On Mon, 2003-01-06 at 02:46, Jason Gunthorpe wrote:
> I think you'd need to have all of argv be converted to utf-8 by the shell.
Besides Sebastien's reply, there is another good reason not to do
recoding in the shell: for any program which actually manipulates
filenames, we will need to add Unico
On Sun, 2003-01-05 at 22:00, Richard Braakman wrote:
> Hmm. Remember the far more common case of a program that takes a
> filename on the command line and then tries to open it. The user
> would have typed it in the local encoding, so it needs conversion.
> On the other hand, if the program was
On Sun, 2003-01-05 at 22:00, Richard Braakman wrote:
> On Sun, Jan 05, 2003 at 09:12:36PM -0500, Colin Walters wrote:
> > However, if these programs display
> > them to the user on a tty, it will be necessary to convert them to the
> > user's locale encoding
>
On Sun, 2003-01-05 at 15:13, Denis Barbier wrote:
> Consider a program written in C, which creates new files with open(2);
> if I understand your proposal right, when a filename is not UTF-8
> encoded, it should be converted into UTF-8 according to user's locale.
Well, broadly speaking, there are
On Sun, 2003-01-05 at 11:07, Michael Bramer wrote:
> The DDTP has no problmes with UTF-8 in control fields. Some maintainer
> use UTF-8 or something else with 'some translations' in the descriptions.
>
> This is not nice.
>
> The policy should be: use normal ACSII and UTF-8 encoding if you use
On Sun, 2003-01-05 at 09:23, Denis Barbier wrote:
> On Sat, Jan 04, 2003 at 12:10:42PM -0500, Colin Walters wrote:
> [...]
> > What *is* debatable is when and how to make the transition, which is
> > what we're doing now.
> [...]
>
> So how to implement your propos
On Sun, 2003-01-05 at 08:05, Sebastian Rittau wrote:
> (Evolution is bad enough by creating an "evolution" directory in my
> homne [...]
The reason it does this is because evolution's directory isn't just
configuration files; it also contains all your mail. Having your mail
hidden away in a . d
[ CC'd to the Debian Description Translation Project maintainer, as he
may be interested ]
On Fri, 2003-01-03 at 13:24, Colin Walters wrote:
> On Fri, 2003-01-03 at 11:45, Radovan Garabik wrote:
>
> > > #99933 goes a lot farther than #174982. First of all, we can'
On Sat, 2003-01-04 at 21:17, Marco d'Itri wrote:
> On Jan 04, Colin Walters <[EMAIL PROTECTED]> wrote:
>
> >> We may want a BOM, at the start, though.
> >
> >We don't need one for UTF-8. That's another one of the great things
> >about i
On Sat, 2003-01-04 at 20:01, Marco d'Itri wrote:
> The same applies to bash. There has been patch in the BTS for a very
> long time but it has never been applied.
Hm, the latest bash appears to work for me at least. I've been using it
when I want to do UTF-8 file manipulation until zsh is fixed.
On Sat, 2003-01-04 at 19:22, Tollef Fog Heen wrote:
> Actually, the file names are in UTF8 already. :)
Well, hey, so they are. Don't know why it didn't look like it before...
> And any hard coded scripts using -d norsk (or -d bokmal) for getting
> Norwegian ispell output.
Hm, but if the filena
On Sat, 2003-01-04 at 16:33, Robert Bihlmeyer wrote:
> Don't you think this is a common case? I'd even say more common than
> your scenarios. At least common enough that it should be acknowledged.
I agree, it is common enough. But previously people had no choice but
to use a broken hack; now we
On Sat, 2003-01-04 at 13:15, Tollef Fog Heen wrote:
> * Colin Walters
>
> | Note that in my proposal UTF-8 filenames are only mandatory (a "must")
> | for files *included directly* in Debian packages or created by
> | maintainer scripts. Since I don't think
On Sat, 2003-01-04 at 10:55, Robert Bihlmeyer wrote:
> Colin Walters <[EMAIL PROTECTED]> writes:
>
> > > As I see it, the current (broken ?) behaviour is, to use the user's
> > > locale setting (LC_CTYPE) to encode file names.
> >
> > It appea
On Sat, 2003-01-04 at 06:10, Marco d'Itri wrote:
> On Jan 04, Colin Walters <[EMAIL PROTECTED]> wrote:
>
> >In summary, UTF-8 is the *only* sane character set to use for
> >filenames.
> True, but does not work in reality for too many people, so this cannot
>
On Fri, 2003-01-03 at 18:11, Jochen Voss wrote:
> Is this meant to apply to programs like "ls", "bash", "touch", and
> "emacs"?
Yes.
> I imagine that the transition period could be a hard time
> for users who (like me) use non-ASCII characters in file-names.
That is probably true. But we real
On Fri, 2003-01-03 at 11:45, Radovan Garabik wrote:
> > #99933 goes a lot farther than #174982. First of all, we can't even
> > suggest that people use UTF-8 in package control fields until all our
> > tools support it. Right now it is just plain broken to put anything but
> > ASCII in them.
>
On Thu, 2003-01-02 at 13:57, Colin Walters wrote:
> #99933 goes a lot farther than #174982.
I have a counter-proposal to #99933, which I have attached. I believe
it fixes the problems I raised with your proposal, and should also cover
some new areas (like filenames). I also hopefully fi
On Thu, 2003-01-02 at 16:28, Josip Rodin wrote:
> I'm not seeing that with the copy of policy.txt.gz which I generated myself.
> Looks like debiandoc2text on Manoj's system used a different, Latin1 locale
> and replaced Š for © on my Latin2 system it did no such (foolish) thing.
> For the record,
On Thu, 2003-01-02 at 12:37, James Troup wrote:
> Colin Walters <[EMAIL PROTECTED]> writes:
>
> > + http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2279.html";
> > name="UTF-8">
>
> Could we please have a more, err, generic URL for the RFC?
Th
On Thu, 2003-01-02 at 13:24, Josip Rodin wrote:
> Umm, maybe because we use ©?
Right, but the output documents seem to be ISO-8859-1 encoded. For
example:
[EMAIL PROTECTED]> zcat /usr/share/doc/debian-policy/policy.txt.gz | iconv
--from-code=UTF-8 --to-code=UTF-8 1>/dev/null
iconv: illegal inp
On Thu, 2003-01-02 at 13:12, Radovan Garabik wrote:
> see #99933. It has been seconded and generally accepted at the time,
> but policy freeze caused it did not get into policy then.
Hmm, I searched the policy bug list, I don't know how I missed those.
Probably my fault for using galeon-snapshot
Package: debian-policy
On Thu, 2003-01-02 at 11:48, Clint Adams wrote:
> > This proposal is a fairly important yet easy to take first step along
> > the way of transitioning all of Debian to UTF-8.
> >
> > Attached is a patch against the latest version of policy.
>
> Seconded. The policy docume
On Thu, 2003-01-02 at 09:12, Colin Watson wrote:
> Policy applies to all packages, whether they state that they comply with
> it yet or not. I'd also go with "should" in the meantime until a survey
> is done and we know how many changelogs need to be fixed, but I think in
> the long run it ought t
Well, I whipped up a quick lintian patch to check for this, which I will
submit against lintian once this proposal gathers the necessary
seconds. I've attached it for now in case anyone else wants to see how
many packages are broken on their machine.
Here are some statistics that may be of intere
[ No need to CC me; I am subscribed to -policy ]
On Thu, 2003-01-02 at 00:23, David B Harris wrote:
> Could you provide a quick background about what Unicode is
Sure. Essentially Unicode is a universal character set, used to encode
all the world's languages, plus other symbols from mathematics
Package: debian-policy
Support for Unicode, and specifically UTF-8, is steadily increasing
among popular applications in Debian. For example, in unstable, GNOME 2
has excellent support (almost level 2) in almost all its applications;
the big remaining one is gnome-terminal, of which one requires
On Wed, 2002-12-11 at 18:58, Adam DiCarlo wrote:
> The consensus we arrived at on debian-doc list (with the exception of
> Colin Walters) was that XML/SGML source is in fact source and
> shouldn't be there bloating binary pkgs.
FYI, I wasn't really against the consensus
On Wed, 2002-12-11 at 07:56, Bill Allombert wrote:
> Package: debian-policy
> Version: 3.5.8.0
> Severity: wishlist
> Tags: patch
>
> Here a patch that clarify the behavior of /etc/init.d/foo restart.
>
> This is taken straight out of
> LSB 1.2 / Chapter 22. / System Initialization / Init Script
On Mon, 2002-12-09 at 08:28, Josip Rodin wrote:
> The screenshot thing is often not handy, so I wouldn't waste much time about
> that...
Just thought I'd point out that at least the Lindows people appear to
have screenshots on their packages page:
http://www.lindows.com/lindows_products_details.
On Sun, 2002-12-08 at 17:32, Adam DiCarlo wrote:
> I have a question for further discussion, which I'm unsure about. May
> or may not be a policy issue.
>
> Is it a good practice for SGML or XML documentation to ship with
> source?
>
> Pros:
> - providing source lets contributors make patches m
On Sun, 2002-11-17 at 10:04, Christian Marillat wrote:
> Hi,
>
> We simply add 40 points if a window manager is compliant with "The
> Window Manager Specification Project" instead of 20. this will solve the
> metacity problem.
Seconded.
This proposal should be considered as superseding my orig
On Wed, 2002-11-13 at 12:38, Josip Rodin wrote:
> The contents of the policy proposals is what matters, how it's formatted
> is a really minor technical detail which only distracts IMHO.
I think we should encourage people to submit SGML patches, because this
encourages people to do things like li
On Wed, 2002-10-30 at 18:00, Branden Robinson wrote:
> On Tue, Oct 29, 2002 at 08:41:44PM -0500, Colin Walters wrote:
> > It turns out that just bumping the priority of x-window-managers like
> > metacity which implement the EWMH spec isn't enough. Other window
> > ma
On Wed, 2002-10-30 at 09:29, Christian Marillat wrote:
> I disagree with that. Users already don't know how to setup the default
> x-window manager, and now you want to introduce an new
> update-alternative...
Well, changing the alternatives is really only for advanced users. We
should advise us
Package: debian-policy
It turns out that just bumping the priority of x-window-managers like
metacity which implement the EWMH spec isn't enough. Other window
managers like twm still take priority, mainly because they support the
Debian menu system directly (which metacity doesn't, it relies on t
[ Sorry if this comes through twice, my Postfix/TLS certificate expired,
and mail stopped working for a bit ]
Here's an updated patch which should address the concerns raised.
--- debian-policy-3.5.6.1/policy.sgml 2002-03-14 13:17:48.0 -0500
+++ debian-policy-3.5.6.1.hacked/policy.sgml
On Mon, 2002-08-19 at 20:35, Richard Braakman wrote:
> Note that many packages don't currently do this. I often had to do
> horrible things to Makefiles to get a binary with debugging symbols.
> I speak in past tense because I usually don't bother to do this anymore.
> So listen up, maintainers:
On Mon, 2002-08-19 at 18:07, Bdale Garbee wrote:
> 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?
Yep, good catch. Thanks.
On Sun, 2002-08-18 at 20:19, Oohara Yuuma wrote:
> -O0 is the default of gcc. Why do I have to add it explicitly?
Well, you don't strictly speaking have to do anything yet;
DEB_BUILD_OPTIONS is a recommendation of policy, not a requirement.
Anyways, I just mentioned adding -O0 just for clarity'
severity 113525 wishlist
merge 157131 113525
retitle 157131 [PROPOSAL] Rework DEB_BUILD_OPTIONS section
thanks
On Sun, 2002-08-18 at 18:52, James Troup wrote:
> I can
> guarantee you that the additional time incurred by using '-g' is so
> insignificant it's insulting to have to even discuss it.
On Sun, 2002-08-18 at 05:46, Richard Braakman wrote:
> For that matter, there are also Heisenbugs to consider: some bugs only
> appear in the optimized version, not the un-optimized. Compiling the
> debugging version with different optimization flags would make tracking
> down these bugs needless
On Sun, 2002-08-18 at 15:45, Ian Jackson wrote:
> Please see also my comments in #113525.
I personally have no strong opinion on this, really. Whoever wrote the
Rationale: part of this section obviously disagrees with you, though.
Maybe machines are fast enough today in general that it isn't as
[ No need to CC me, btw, despite the evil the BTS does to Reply-To ]
On Sat, 2002-08-17 at 23:14, Marcus Brinkmann wrote:
> You might want to add a warning that this needs to be tested. Some
> packages, like glibc or the Hurd, can not be built without optimization
> (for example because of inlin
1 - 100 of 122 matches
Mail list logo
