On Sat, Jan 18, 2003 at 04:08:46PM -0800, Ron wrote:
> But even the OP agreed that not every piece of software is necessarily
> portable in which case I also agree it's up to someone who wants it on
> the port to do the porting -- the Debian maintainer is not obliged to
> port i386 assembly to some
On Sat, Jan 18, 2003 at 03:19:54PM -0600, Adam DiCarlo wrote:
> Ron <[EMAIL PROTECTED]> writes:
>
> > If -policy wants to run a flame war
>
> Hey, who ever wants a flame war?
:-) Well, I don't usually follow -policy (the list not the document)
unless something comes up that I need to chime in o
CVSROOT:/cvs/debian-policy
Module name:debian-policy
Changes by: joy Sat Jan 18 16:17:09 MST 2003
Modified files:
debian : rules
Log message:
display what gets executed as it happens, instead of just the loop code
On Fri, Jan 17, 2003 at 11:33:59PM +0100, Guenther Palfinger wrote:
> I've read the whole manual and for that 5 typos is a very small number. I
> found this literature mostly entertaining.
Thanks for the fixes, they'll appear in the next revision.
--
2. That which causes joy or happiness.
CVSROOT:/cvs/debian-policy
Module name:debian-policy
Changes by: joy Sat Jan 18 16:08:36 MST 2003
Modified files:
. : policy.sgml
debian : changelog
Log message:
Guenther Palfinger's bugs
Ron <[EMAIL PROTECTED]> writes:
> If -policy wants to run a flame war
Hey, who ever wants a flame war?
> on this topic now, knock yourselves out, but can we please leave the
> bts report off the cc, and probably also the OP (who I can't speak
> for) and myself (who I just have ;).
>
> As I've s
Colin Watson wrote:
> Perhaps it would reduce the frequency of this request if it were
> mentioned in /usr/share/doc/base-files/FAQ?
Good idea. I've just added it to the FAQ.
Thanks.
On Sat, Jan 18, 2003 at 03:42:16AM -0600, Manoj Srivastava wrote:
> However, this, too, is quite confused: by marking a package
> arch: any you are not signing up to port the package; you are not
> consigning the upstream to support hell, and indeed, if portability
> issues are discovered,
On Sat, Jan 18, 2003 at 07:25:48PM +0100, Santiago Vila wrote:
> On Sat, 18 Jan 2003, Jordi Mallach wrote:
> > Package: base-files
> > Version: 3.0.6
> > Severity: normal
> >
> > I just wanted to point at /usr/share/common-licenses/FDL in one of my
> > packages, but surprise, we distribute no such
Processing commands for [EMAIL PROTECTED]:
> reassign 177306 debian-policy
Bug#177306: please include the complete text of the GNU Free Documentation
License
Bug reassigned from package `base-files' to `debian-policy'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Adrian Bunk writes ("Bug#176506: Make debconf mandatory for prompting the
user"):
...
> The problem is that within the rules of your policy every single of your
> over thousand maintainers can decide how he wants to maintain his
> packages. Currently a maintainer can simply refuse to use debconf
reassign 177306 debian-policy
thanks
On Sat, 18 Jan 2003, Jordi Mallach wrote:
> Package: base-files
> Version: 3.0.6
> Severity: normal
>
> I just wanted to point at /usr/share/common-licenses/FDL in one of my
> packages, but surprise, we distribute no such file in base-files.
>
> Is there a goo
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
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Is a developer merely a glorified packager, who mechanically
> packages software, and shuffles off problems with the package
> blindly upstream? I hope not, and I have long rejected this narrow
> view of what a developer is.
Ahem, that is a
Adam DiCarlo <[EMAIL PROTECTED]> writes:
>> > If the upstream software maintainers state they don't want to support
>> > certain architectures, what the hell, isn't that their perogative?
>>
>> Strawman.
>
> Now, on what basis do you claim this is a strawman?
This is missing the
Adam DiCarlo <[EMAIL PROTECTED]> writes:
> "Steven G. Johnson" <[EMAIL PROTECTED]> writes:
>
>> 2. Don't set architecture to a value other than ``all'' or ``any''
>> unless the upstream package is intrinsically unportable
>> (e.g. a program to disable a Pentium CPU ID). If the pack
"Steven G. Johnson" <[EMAIL PROTECTED]> writes:
> On 18 Jan 2003, Adam DiCarlo wrote:
> > But I do think this goes too far. There might be good reasons why the
> > upstream maintainers or debian maintainers are unable to maintain a
> > ported package -- notably, if the upstream were not willing to
[I'll preface by saying I should have modulated my first post a little
bit more than I did -- you see a more balanced approach in my second
one.]
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> > I really don't understand this. The maintainers of the software the
> > the upstream folks who provi
On Sat, Jan 18, 2003 at 01:45:35PM +0100, Adrian 'Dagurashibanipal' von Bidder
wrote:
> > If you could (a) convert this into a proper policy change proposal,
> > (b) fix the /usr/share/foo where you meant /usr/share/doc/foo, and (c)
> > describe what goes in /usr/share/doc/foo-doc (just changelog
On Sat, 2003-01-18 at 09:06, Adam DiCarlo wrote:
> If you could (a) convert this into a proper policy change proposal,
> (b) fix the /usr/share/foo where you meant /usr/share/doc/foo, and (c)
> describe what goes in /usr/share/doc/foo-doc (just changelog and
> README.Debian pointing to /usr/share/
On Sat, Jan 18, 2003 at 06:14:26AM +0200, Richard Braakman wrote:
> On Sat, Jan 18, 2003 at 01:20:06AM +, Colin Watson wrote:
> > On Fri, Jan 17, 2003 at 11:32:41PM +0100, Guenther Palfinger wrote:
> > > page 81/sec. 11.7.5 User configuation files ("dotfiles"): "However,
> > > programs
> > > t
On 18 Jan 2003, Adam DiCarlo wrote:
> > If every Debian developer refused to support > architectures he/she
> > didn't have immediate access to, non-x86 Debian would > disappear
> > pretty quickly.
>
> If the upstream software maintainers state they don't want to support
> certain architectures, w
Hi,
Adam DiCarlo <[EMAIL PROTECTED]> writes:
> "Steven G. Johnson" <[EMAIL PROTECTED]> writes:
>
>> He (Ron Lee <[EMAIL PROTECTED]>) responded:
>> > I can quite sympathise with what you want, but I'm not going to
>> > make this package arch-any just so it can break on every arch
>> > except i386
On 18 Jan 2003, Adam DiCarlo wrote:
> But I do think this goes too far. There might be good reasons why the
> upstream maintainers or debian maintainers are unable to maintain a
> ported package -- notably, if the upstream were not willing to take
> patches for building in other architectures.
In
Adam DiCarlo <[EMAIL PROTECTED]> writes:
> I'm willing to second the proposal as is, with the "must" directive.
I am afraid that would not fly, since the policy group has no
mandate to be able to do so.
> I do think there should be an impact analysis done, a quick one: how
> many packag
Colin Walters <[EMAIL PROTECTED]> writes:
> On Fri, 2003-01-17 at 17:49, Manoj Srivastava wrote:>
>> perhaps we should stick to pure ascii file names, if we
>> must have policy take a stance about file names at all?
>
> First of all, I strongly believe policy should have a stance about file
> name
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hi,
>
> Just because you are using a UTF-8 capable terminal does not
> mean you can actually see a UTF encoded string. ሰው እንደቤቱ እንጅ እንደ
> ጉረቤቱ አይተዳደርም።, though encoded in UTF, is hard for me to display. If
> you are able to see this, would
"Steven G. Johnson" <[EMAIL PROTECTED]> writes:
> 2. Don't set architecture to a value other than ``all'' or ``any''
> unless the upstream package is intrinsically unportable
> (e.g. a program to disable a Pentium CPU ID). If the package
> is theoretically portable, even i
"Steven G. Johnson" <[EMAIL PROTECTED]> writes:
> He (Ron Lee <[EMAIL PROTECTED]>) responded:
> > I can quite sympathise with what you want, but I'm not going to
> > make this package arch-any just so it can break on every arch
> > except i386 (and hence keep it out of testing for everyone).
> > T
If you could (a) convert this into a proper policy change proposal,
(b) fix the /usr/share/foo where you meant /usr/share/doc/foo, and (c)
describe what goes in /usr/share/doc/foo-doc (just changelog and
README.Debian pointing to /usr/share/doc/foo?), I would be willing to
secondary the proposal.
I'm willing to second the proposal as is, with the "must" directive.
I do think there should be an impact analysis done, a quick one: how
many packages in main do interactive prompting?
I'm personally not afraid of making 30% of packages suddenly buggy if
that's what it takes to make Debian bett
31 matches
Mail list logo
