Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
On Tue, Jun 24, 2003 at 06:25:50PM -0400, Daniel Burrows wrote:
> On Tue, Jun 24, 2003 at 02:25:03PM -0700, Neil Spring
> <[EMAIL PROTECTED]> was heard to say:
>> dpkg-souce(1) implies that substitution variables are
>> limited to a single line (which seems poorly suited to long
>> descriptions).
> Then as long as the shared part is a single paragraph you should
> be fine.
> Actually, it looks like you could use ${Newline} and friends to
> include multiple lines (I haven't tried this myself, though)
Thanks, Daniel, ${Newline} worked. The trick I learned
while making this work is that when using debhelper, the
standard description must be kept in a different file, as
substvars is avoided in favor of pkgname.substvars.
So, in debian rules, anyone who would like to use a common
description with debhelper will have to:
cat debian/description.subst >> debian/pkg.substvars
cat debian/description.subst >> debian/pkg-dev.substvars
dh_gencontrol -a
thanks again,
-neil
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
On Mon, Jun 23, 2003 at 03:25:23PM -0500, Adam Heath wrote:
> Use ${description}, and debian/substvars. This is already supported.
> RTFM.
is there FM in the form of an example package? or can you
think of a method of finding packages that use this
technique?
dpkg-souce(1) implies that substitution variables are
limited to a single line (which seems poorly suited to long
descriptions). An example would likely clear this up
easily.
thanks,
-neil
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
> However I've found a number of packages which use a long > description which is more or less the _same_ as the short > description. This is just a thought, but perhaps the control file could incorporate a mechanism for common description of packages from the same source. For example, NetCDF has a fine description for the main package, but lousy, redundant ones for sub-packages, such as netcdfg-dev: Development kit for NetCDF. Includes headers, static libraries, and documentation. The maintainer has often already put time into making a good description for the main package, and it would be lovely if that description could also appear in sub-packages with little effort and without copy-and-paste. Thanks for your efforts to improve descriptions! thanks, -neil On Fri, Jun 20, 2003 at 05:53:09PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: > Policy section 2.3.3 states: > The description should be written so that it gives the system > administrator enough information to decide whether to install the > package. > However I've found a number of packages which use a long description > which > is more or less the _same_ as the short description. Sample: > $ apt-cache show kdebase-data > (...) > Description: KDE Base (shared data) > KDE Base (shared data). > . > This package is part of the official KDE base module. > And some (2) others which do not provide an extended description at > all or > provide an extended description of only one line. I've used an ugly > scripts > (attached) which produces ugly results (attached too). > I was wondering, should I make a mass filing of bugs for those packages > who fail to produce a proper description? > I would probably first do so for the packages whose short description = > long description or who do not have a description at all and would > review > which of the "one liners" do not provide sufficient information. > Regards > Javi
Re: RFC: Handling of certificates in Debian
On Fri, Aug 30, 2002 at 06:58:00PM +0100, Andrew McDonald wrote: > On a similar subject, there seem to be more than a few applications > that have had "SSL/TLS support" added, but don't do any hostname > checking against the certificate - leaving you open to > man-in-the-middle attacks. (speaking as an offender) Why is it that TLS libraries don't handle a lot of this simple validation on behalf of applications? Why is it that the sample gnutls code doesn't seem to include this check? Can you report bugs against broken packages with patches? It seems like you've contributed a lot of mutt-specific code to handle certificate validation in the-right-way, but that the procedure is both generally useful and error-prone so should be centralized. thanks, -neil
Re: flavours and modules: /lib confusion
from "man make-kpkg": --flavour foo This option is now deprecated in favour of --append_to_version. --append_to_version places modules in the place you expect, and coexists well with modules. I use it all the time. -neil On Fri, Dec 28, 2001 at 05:25:35AM +0100, martin f krafft wrote: > hi folks, > i am using a separate machine to compile kernels and module packages. > the arguments to make-kpkg are --revision with an increasing revision > number, and --flavour, where i specify the machine name. the result is > e.g. a kernel-image-2.4.17+fishbowl package. > > now, i am also compiling pcmcia-cs and alsa-source. the compilation > works and it's all happy... > > *except*: kernel-image-2.4.17+fishbowl writes its modules to > /lib/modules/2.4.17, but e.g. the pcmcia-modules package that i > generate puts its modules under /lib/modules/2.4.17+fishbowl. > > subsequently, depmod doesn't see these, and unless i cp -dR the > ./pcmcia directory in the /lib/modules/2.4.17+fishbowl tree to > /lib/modules/2.4.17, i ain't gonna get pcmcia working. > > i think that the bug is actually in the kernel-image package, because > if i choose to use flavours, then it should employ them all the way. > the kernel image in /boot is called vmlinuz-2.4.17+fishbowl, and so is > the config file, it's really just /lib/modules that does it > differently. > > your thoughts? i think that kernel-image ought to respect flavours the > same way that module packages do! > > -- > martin; (greetings from the heart of the sun.) > \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] > > don't hate yourself in the morning -- sleep till noon.
Re: sysctl should disable ECN by default
> RFC793 says > > Reserved: 6 bits > > Reserved for future use. Must be zero. > > > The last statement is the cause of all confusions. s/Must/Should/ would > have been better. No; to be forward compatible, a TCP must set the bits to zero. 2481 describes the operation of those bits and augments 793, much like SACK augments it. Some TCP's have a bug where they set the bits in the SYN/ACK if they received reserved bits in the SYN, which is why ECN negotiation is asymmetric. If you want to blame routers for not implementing standards, try 791. The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. -neil
Re: sysctl should disable ECN by default
> ECN is RFC2481 > > http://www.ietf.org/rfc/rfc2481.txt?number=2481 the internet draft by the same authors that supercedes rfc2481 and is a "Proposed Standard" instead of an "Experimental Standard" is draft-ietf-tsvwg-ecn-04. It is listed under "working group standards track" at http://www.rfc-editor.org/queue.html http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-04.txt -neil
Re: sysctl should disable ECN by default
> > (*) wha? no kernel patch is required. The default > > Not really true. After reading Herbert's mail, I understand what you were trying to do now with the patch. Thanks for explaining the baseconfig / postinst issues. What a mess. -neil
Re: sysctl should disable ECN by default
Summary:
1) why not disable ECN in kernel-image? it would be cleaner.
2) why not disable ECN in /etc/network/options? it would be
more relevant and visible than sysctl.conf.
3) can we disable ECN for joe user with the default kernel
while permitting joe custom-kernel-user to enable ECN with
one checkbox?
4) more than one place to make a configuration change
reuduces ease of use, which is what we're trying to achieve
by disabling ECN in the first place.
The Director's Cut:
> Good. The problem - it is on by default in our precompiled kernel-image
> packages. To disable (by default), (a) you have to remove ECN support from
> kernel or (b) either patch the kernel to make int off-as-default (*) or (c)
> put
> in in the template of sysctl.conf.
>
> (*) I doubt Herbert Xu would like such modifications.
(*) wha? no kernel patch is required. The default
distribution of the kernel, as distributed by Linus Himself
leaves ECN off. Somewhere, someone decided to turn it on.
Can we just choose option (a) and be done with it?
If Debian isn't going to choose option (a), why are we
talking about option (c)?
I think if Herbert believes that ECN should be enabled
in the kernel, that's an intentional statement about
his confidence in ECN. A later, standard package that
reconfigures the kernel at runtime seems inelegant when
the same configuration could easily be made just once
in the kernel config.
> Okay, why not just put the line into sysctl.conf and present a big
> warning in the baseconfig?
I'm sorry, I'm not familiar with what a warning in
baseconfig would mean. Would I see it once? many times?
at upgrade? only on the initial install?
Would this be printed when kernel-image is installed?
when kernel-package is run? from netbase? something at
all related to networking or the kernel?
Behind a default kernel configured with ECN disabled,
I would prefer the patch that puts this behavior in
/etc/network/options, since: 1) it's clear how to print
a message describing that ECN is disabled from there,
2) that configuration file has something to do with
networking, and 3) there's apparently a precedent with
syn_cookies configuration.
> > then you should see the logic in respecting the user's
> > wishes, and not trying to disable what they've knowingly
> > enabled in the kernel configuration.
>
> Look, we have in general two parts of users:
>
> - "administrator" kind, people that _may_ need ECN (but mostly don't
> though). We can expect them to RTFM and remove the hook from
> sysctl.conf after reading the baseconfig message.
>
> - the "users" - the majority. People that do as less RTFM as possible,
> that do not need ECN and the should not be bothered with such
> problems. This people would ignore the warning and have an easier life
> without getting in touch with sysctl.conf.
It seems our difference is that you think prioritizing
users means choosing for them, and I think prioritizing
users means respecting their (possibly incorrect, possibly
ignorant) choice. These don't necessarily conflict,
but it requires care to support both.
I don't think the dichotomy between illiterate idiots and
uber-administrators is realistic: I'm an 'administrator'
who'd rather spend time playing my guitar or doing research
than reading documentation. There are users of varying
skill levels, including those who have to recompile their
own kernel and will have the opportunity to decide in the
kernel configuration whether to enable ECN.
**When one checkbox should suffice, there should not be two.**
> Is my proposal acceptable now?
"Big warning" + "ECN disabled by default" => acceptable.
Who am I to complain?
All I care about is that whatever legitimate attempts
the user makes to configure his or her system are
respected whenever possible. If a user configures
a kernel and says "ECN, yes!" he has a reasonable
expectation that ECN will actually be enabled. If ECN
will not be enabled, this must be clear - not hidden in
/usr/share/doc/{netbase,procps,kernel-image}, not hidden
in the gobs of messages one clicks through when installing
Debian, but shown when a custom kernel is installed or
booted. Better yet, if the user has enabled it in the
kernel, it should just stay enabled.
I realize these are hard things. I will tell a short
story to try to justify the effort. My mother uses a
windows machine, and wanted to configure her printer to
print 360dpi instead of 180dpi. She found that to do this,
she would have to enter the printer options dialog every
time she wanted to print. From within an application,
the configuration is not saved; not even for future
use by that application. Only if you enter the identical
printer options dialog from the control panel are settings
saved permanently. She has every legitimate reason to
believe that the choice made in the options dialog from
an application would be as permanent as from the control
panel, but it is not. Let's not make it as difficult to
configure a Debia
Re: sysctl should disable ECN by default
IP is a very old standard. I don't assume that all chipsets are bug free, nor do I assume that all IP implementations are bug free. I'm going to place blame where it belongs, and be honest about whose bug this is. This is not a problem with two year old equipment. It is not the case that all IP routers made before 1999 will discard ECN traffic. Only those that reach into your TCP header and fuss with the bits will do so. So I am suggesting that you throw out your two year old zyxel piece of crap "router" if you have one, or pester their support people for the software patch, and follow Jamal's call for volunteers as descibed on linux-kernel at: http://uwsg.iu.edu/hypermail/linux/kernel/0105.1/0145.html As David noted, I'm in favor of turning ECN off-as-default. My point is still that it should be dirt simple to turn it on again. If you're going to quote the social contract, then you should see the logic in respecting the user's wishes, and not trying to disable what they've knowingly enabled in the kernel configuration. -neil On Sat, Sep 01, 2001 at 07:54:06PM -0500, David Starner wrote: > On Sun, Sep 02, 2001 at 02:17:43AM +0200, Eduard Bloch wrote: > > #include > > Neil Spring wrote on Sat Sep 01, 2001 um 04:39:30PM: > > > > > Blaming ECN for faulty IP implementations is wrong. > > > > Come back to reality please. Or stay in your dream and (for example) > > and remove all workarounds in the kernel, assuming all chipsets and > > implementations to be bug-free. Your words can be translated to "People, > > trow away your notebooks, motherboards, hard disks, and buy newer ones". > > Then you have a faulty translator. What he said was that it's not fair > to blame ECN for the problems and that implemenators had plenty of > warning that that bit might need to be used. He did not say that ECN > should be turned on by default. > > Your words can be translated (very liberally) as "We should never > improve anything; even backward compatible extensions will break > something, and so should be shunned." > > -- > David Starner - [EMAIL PROTECTED] > Pointless website: http://dvdeug.dhis.org > "I don't care if Bill personally has my name and reads my email and > laughs at me. In fact, I'd be rather honored." - Joseph_Greg > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
