Re: Bug#190302: Misusage of changelog!

[Mats Rynge]

* Joachim Breitner <[EMAIL PROTECTED]> [2003-05-26 18:05:11 +0200]:
> Am Mon, 2003-05-26 um 17.15 schrieb Philipp Matthias Hahn:
> > Or do you expect everbody to file duplicate bugs or subscribe to
> > existing bugs ?
> 
> AFAIK you can't subscribe to single bugs (at least I was told that a few
> month ago). But this is one thing I'd like to change at debcamp in
> Oslo...

You are right. There is a whislist bugs filed againt debbugs about this, 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=34071 which was filed
for more than 4 years ago.

It would be really nice if this feature was finally implemented.

-- 
Mats Rynge

   ,''`.Got Woody?   |   JID (Jabber):  [EMAIL PROTECTED]
  : :' :http://www.debian.org|   Webpage: http://mats.rynge.net
  `. `'
`-

Re: Maintaining kernel source in sarge

[Sven Luther]

On Tue, May 27, 2003 at 07:23:27AM +1000, Herbert Xu wrote:
> On Mon, May 26, 2003 at 10:00:06PM +0200, Yann Dirson wrote:
> > 
> > We could get around Guido's point mentionned above by having a list of
> > default patches to apply, which would by default contain the debian
> > patch.
> 
> Yes, but then the problem is that unsuspecting users could be
> building kernels using the kernel-source package thinking that
> it contained all the security fixes.

Have it depend on a kernel-source-security-fixes or something
such ? And have make-kpkg issue a big warning if it detects that the
sources were not patched ?
> 
> I believe that distributing a binary package that may contain
> known security problems is a very serious problem.
> -- 
> Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
> Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#194550: ITP: libemail-mime-encodings-perl -- A unified interfa

[Adrian 'Dagurashibanipal' von Bidder]

On Monday 26 May 2003 22:30, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Gerfried Fuchs)  wrote on 26.05.03 in 
<[EMAIL PROTECTED]>:

> As for the long descriptions, I really don't see what the use is in an
> ITP. The packages will of course have them.

A proper long description will help avoid question like Gerfried's. Also, I 
read ITPs to see whether something interesting will come to Debian soon. 
There have been some cases where the long description was improved in a 
discussion following the ITP.

greets
-- vbi

-- 
Most scientists thinks that the not-fossil theory is a red herring;
indeed, they think that oil is lots of herrings (and other things)
compacted over time into sticky black mud.
-- Prospect Magazine, March 2003, p. 6


pgpAeMOOYEbfn.pgp
Description: signature

Re: Accepted bwidget 1.6.0-1 (all source)

[Brian Nelson]

reopen 159971
reopen 124472
reopen 147059
reopen 70184
thanks

Anselm Lingnau <[EMAIL PROTECTED]> writes:

> Format: 1.7
> Date: Tue, 27 May 2003 01:15:33 +0200
> Source: bwidget
> Binary: bwidget
> Architecture: source all
> Version: 1.6.0-1
> Distribution: unstable
> Urgency: low
> Maintainer: Anselm Lingnau <[EMAIL PROTECTED]>
> Changed-By: Anselm Lingnau <[EMAIL PROTECTED]>
> Description: 
>  bwidget- A set of extension widgets for Tcl/Tk
> Closes: 70184 124472 147059 159971
> Changes: 
>  bwidget (1.6.0-1) unstable; urgency=low
>  .
>* New upstream release.
>* Upstream was changed to Tcl license.
>* Closes: #159971, #124472, #147059, #70184.

Umm, no, the changelog is for listing changes (*change* log, get it?),
not for just closing bugs without any reason given whatsoever.

Why do so many seem to have difficulty with this concept?  Is it
worthwhile to Cc this stuff to -devel, or should I just give up and let
the proliferation of these IMO useless changelogs continue?  (serious,
not rhetorical, questions)

-- 
Poems... always a sign of pretentious inner turmoil.


pgpHix3RsxqNr.pgp
Description: PGP signature

Re: Maintaining kernel source in sarge

[Yann Dirson]

Arnd wrote:
> Actually, I was thinking of a different concept with a 'Replaces: tag,

Hm.  As I understand it, it would be more something like a "Provides:"
declaration, it seems.  Such a feature does not seem useless to me at
first glance (we already see aglomerations of patches, like FOLK,
which coule have make use of this), but I'm not sure it would be
something we can work with.

Let's look at your example:

| Patch-name: Debian base patch
| Patch-id: debian
| Architecture: all
| Kernel-version: 2.4.20
| Depends: ptrace, isdnbonding, binfmtmisc, ethernetpadding, ...
|
| Patch-name: Pre-patch 2.4.21-pre7
| Patch-id: patch-2.4.21-pre7
| Architecture: all
| Kernel-version: 2.4.20
| Provides: ptrace, ethernetpadding

Here I suppose the pre-patch is supposed to be applied first, and then
the application of the debian patch would only trigger application of
those dependant patches not provided by the pre-patch.

That's only fine _if_ the replaced patches are similar enough so that
any patch in the debian set, that would depend on those, can still
apply atop the new one.  That is, if there are several revisions of a
given fix, we'll have to use versionned Provides: and Depends:, or
we're doomed.  Not that it's impossible, but I'm not sure it's exactly
trivial to implement...


| Patch-name: AMD64 CVS snapshot
| Patch-id: amd64-20030417
| Architecture: i386, amd64
| Kernel-version: 2.4.20
| Depends: debian, patch-2.4.21-pre7, simicsfs
| Provides: aic7xxx

Here I suppose you should have swapped debian and patch-2.4.21-pre7,
or that simply wouldn't apply.


> Do you think that make-kpkg and dh-kpatches could/should be merged,
> making the dh-kpatches information evaluated by make-kpkg if available, 
> or do we need changes beyond that?

They cannot be completely merged, since they work on complementary
stages of the kernel build.  OTOH, gradually the kernel-patch-scripts
package is gradually going to factorise things that currently get
duplicated in all kernel-patch packages, and since this part of
dh-kpatches will work in the same stage as make-kpkg does, it may make
sense at some point to have a look at something like a merge of this
part into make-kpkg.

But since this is all about things yet to be written, we'll see later.

Regards,
-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> |  Freedom, Power, Stability, Gratuity
 http://ydirson.free.fr/| Check 

Re: Maintaining kernel source in sarge

[Yann Dirson]

On Tue, May 27, 2003 at 07:37:42AM +0200, Sven Luther wrote:
> On Tue, May 27, 2003 at 07:23:27AM +1000, Herbert Xu wrote:
> > On Mon, May 26, 2003 at 10:00:06PM +0200, Yann Dirson wrote:
> > > 
> > > We could get around Guido's point mentionned above by having a list of
> > > default patches to apply, which would by default contain the debian
> > > patch.
> > 
> > Yes, but then the problem is that unsuspecting users could be
> > building kernels using the kernel-source package thinking that
> > it contained all the security fixes.
> 
> Have it depend on a kernel-source-security-fixes or something
> such ?

That's more or less what I'd think of as well.  We can start with an
empty security patch, and have this one grow as needed.  This way, apt
will show people they have an outdated security patch - which, BTW,
may be more of an incentive to upgrade than just an outdated
kernel-source package.

That does not mean the user will rebuild his kernel at once with the
new patch, but well, I don't think we can do much more here :)


> And have make-kpkg issue a big warning if it detects that the
> sources were not patched ?

That could be easy to do.  Just have the security patch create a
debian/APPLIED_security stamp, and have make-kpkg look at that...

Regards,
-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> |  Freedom, Power, Stability, Gratuity
 http://ydirson.free.fr/| Check 

Re: Maintaining kernel source in sarge

[Herbert Xu]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> 
> All definite benefits.  The one thing which seems to be missing is to ensure
> that the arch-specific kernels do not miss out on important fixes (such as
> security) to the main kernel source tree.

Yes that isn't easy to check apart from the fact that if there isn't
an arch update after a security update to kernel-source, then that arch
is probably vulnerable.  If you've got an idea on how this can improved,
please let us know.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Maintaining kernel source in sarge

[Arnd Bergmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday 27 May 2003 10:27, Yann Dirson wrote:

> Let's look at your example:
> | Patch-name: Debian base patch
> | Patch-id: debian
> | Architecture: all
> | Kernel-version: 2.4.20
> | Depends: ptrace, isdnbonding, binfmtmisc, ethernetpadding, ...
> |
> | Patch-name: Pre-patch 2.4.21-pre7
> | Patch-id: patch-2.4.21-pre7
> | Architecture: all
> | Kernel-version: 2.4.20
> | Provides: ptrace, ethernetpadding
>
> Here I suppose the pre-patch is supposed to be applied first, and then
> the application of the debian patch would only trigger application of
> those dependant patches not provided by the pre-patch.

The order in which the patches are applied should in general not be
significant. If it is, it should be stated in the patch description. I
assumed that the 'Depends' tag is semantically more a 'Pre-Depends',
right?

In my example, if the isdnbonding patch has to be applied after
ethernetpadding, it would have to say so in its description.
patch-2.4.21-pre7 can contain the same patch and should
consequently be applied at the same time (e.g. after
binfmtmisc, but before isdnbonding).

> That's only fine _if_ the replaced patches are similar enough so that
> any patch in the debian set, that would depend on those, can still
> apply atop the new one.  That is, if there are several revisions of a
> given fix, we'll have to use versionned Provides: and Depends:, or
> we're doomed.  Not that it's impossible, but I'm not sure it's exactly
> trivial to implement...

Yes, versioned patches are a problem that I did not think of. I
assumed that one patch providing the functionality of another
one is always a superset. It may be possible to require versioned
patches to be made as a sequence of diffs between the versions.
Of course that creates new problems.

> | Patch-name: AMD64 CVS snapshot
> | Patch-id: amd64-20030417
> | Architecture: i386, amd64
> | Kernel-version: 2.4.20
> | Depends: debian, patch-2.4.21-pre7, simicsfs
> | Provides: aic7xxx
>
> Here I suppose you should have swapped debian and patch-2.4.21-pre7,
> or that simply wouldn't apply.

No. The debian patch set should generally come first, except for the parts
in it that depend on patches 'provided' by some other patch. The maintainer
of patch-2.4.21-pre7 would have to make sure it applies on top of or mixed
with the debian patch set.

Arnd <><
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+0yoI5t5GS2LDRf4RAki3AJ9s5cnZLy3daFOzJ1tVrJLd4vOzlQCfc0t/
+v6dXGmliMSueQWE5Hxw1xI=
=Fkob
-END PGP SIGNATURE-

Re: Bug#190302: Misusage of changelog!

[Josip Rodin]

On Tue, May 27, 2003 at 12:42:29AM -0400, Matt Zimmerman wrote:
> Or better:
> 
> 1. discover security vulnerability
> 2. was it fixed in the Debian package?
> 3. read changelog
> 4. see a bunch of completely worthless "Closes:" messages
> 5. throttle maintainer

1. defenestrate loser maintainers
2. ???
3. PROFIT!

-- 
SCNR.

2.5.69 kernel needs rtc.c patch

[Victor Torrico]

RTC does not work either compiled as a module or into the kernel.  A patch for 
this is needed or a new kernel-source-2.5.69 package is needed.

Cheers,

Victor

Re: Bug#190302: Misusage of changelog!

[Luca - De Whiskey's - De Vitis]

On Tue, May 27, 2003 at 12:47:10AM -0400, Matt Zimmerman wrote:
> It is.  Unfortunately, common sense is not always as common as we would
> like.

Are you trying to say that i've no common sense?

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Re: 2.5.69 kernel needs rtc.c patch

[Arne Goetje]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday 27 May 2003 17:45, Victor Torrico wrote:
> RTC does not work either compiled as a module or into the kernel.  A
> patch for this is needed or a new kernel-source-2.5.69 package is needed.

In 2.5.69 many things are not working... there are many open bugs on 
kernel.org. I suggest you check them first, before you try it. 
Unfortunately the drivers I need are also broken... I cannot even compile 
the source. :(

Cheers
Arne
- -- 
Arne Goetje <[EMAIL PROTECTED]> 
(Spam catcher.  Address might change in future!)
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F  1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+0ztKbp/QbmhdHowRAgzFAJ9V96neqj+IOx8jHbcLG0ytz4WnYwCg5wLb
fUA5v9AHb5v+hMEfM7KBz40=
=7UEM
-END PGP SIGNATURE-

Re: Maintaining kernel source in sarge

[Russell Coker]

On Tue, 27 May 2003 19:04, Arnd Bergmann wrote:
> > Here I suppose the pre-patch is supposed to be applied first, and then
> > the application of the debian patch would only trigger application of
> > those dependant patches not provided by the pre-patch.
>
> The order in which the patches are applied should in general not be
> significant. If it is, it should be stated in the patch description. I
> assumed that the 'Depends' tag is semantically more a 'Pre-Depends',
> right?

It's fairly rare for a patch to depend on another patch without any order 
dependency.

When a patch depends (in the English language not the Debian package meaning) 
on another patch it usually changes files that were created or changed by the 
other patch.

Patches tend to be independant (IE you can use either of them on it's own or 
apply them in any order) or there is a dependency which also requires an 
ordering of the application.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Bug#190302: Misusage of changelog!

[Nick Phillips]

On Tue, May 27, 2003 at 12:46:02AM -0400, Matt Zimmerman wrote:

> > * Matt Zimmerman <[EMAIL PROTECTED]> [030526 21:41]:
> > > It is _not_ obvious, and "closes: #..." gives no clue to someone reading
> > > the changelog what might have been changed.  Internet access, knowledge
> > > of debbugs, etc. are not prerequisites for being able to make use of a
> > > changelog.
> > 
> > Then why do you limit your critic to the bug closed. Which bugs are closed
> > are often the least interisting item of a new version.
> 
> Bug fixes are one of the most interesting things in a changelog.  This is
> not the daily news, it is a record of what changed, and _when_.

It should be possible, for example, for me to read the changelog from a
version of a package in unstable and from that to be able to judge whether
it's worthwhile installing that version of the package on my stable system.

This means I need to know what bugs have been fixed and when, and what
scary new features have been added, and when. There's no way I'm going to
be able to keep track of it by looking up every bug that's been fixed in
that time in the BTS.

Alternatively, I might want to work out why a package might depend on a
specific version of your package -- for example when trying to backport
the other package to stable. If you have a decent changelog I can quickly
and easily judge whether the fixes that were introduced in the version
mentioned in the dependency are necessary to me or not.

If your changelog merely says "New upstream version, closes: #123 #456",
it's no help whatsoever, and I will (rightly) think that you suck.

FFS, it's a *change*log -- so log the effing changes in it.



Cheers,


Nick
-- 
Nick Phillips -- [EMAIL PROTECTED]
Do not overtax your powers.

Re: Maintaining kernel source in sarge

[Sven Luther]

On Tue, May 27, 2003 at 08:16:59PM +1000, Russell Coker wrote:
> On Tue, 27 May 2003 19:04, Arnd Bergmann wrote:
> > > Here I suppose the pre-patch is supposed to be applied first, and then
> > > the application of the debian patch would only trigger application of
> > > those dependant patches not provided by the pre-patch.
> >
> > The order in which the patches are applied should in general not be
> > significant. If it is, it should be stated in the patch description. I
> > assumed that the 'Depends' tag is semantically more a 'Pre-Depends',
> > right?
> 
> It's fairly rare for a patch to depend on another patch without any order 
> dependency.

Why don't we use a scheme similar to what xfree86 use for its patches.
Sure we would need to adapt it as the patches are distributed, but we
could well do it. 

Friendly,

Sven Luther

Re: Accepted bwidget 1.6.0-1 (all source)

[Paul Slootman]

On Mon 26 May 2003, Brian Nelson wrote:

> Umm, no, the changelog is for listing changes (*change* log, get it?),
> not for just closing bugs without any reason given whatsoever.
> 
> Why do so many seem to have difficulty with this concept?  Is it
> worthwhile to Cc this stuff to -devel, or should I just give up and let
> the proliferation of these IMO useless changelogs continue?  (serious,
> not rhetorical, questions)

Presumably the people who continue to do this don't read debian-devel,
or at least not thoroughly (the subject line of your messages don't
necessarily reflect the point you're trying to get across).

Perhaps a separate, concise message to debian-devel-announce?


Paul Slootman

消除视频干扰－地线回路平衡器

[王亚]

debian-devel:您好!

消除视频干扰,诚信圣通
网址：www.spwe.com

在CCTV系统中，当摄像机与显示终端的距离大于200米以上时，就容易出现二者接地电位有差异，
当接地电位大于一定幅值时，视频信号就会出现干扰的条纹信号，严重的甚至视频信号严重扭曲，
乃至无法观看。采用地线回路平衡器，即可消除接地环路电压带来的干扰以及空间电磁波带来的干扰。
广泛用于CCTV的各个行业，如：安防、交通、铁路、电力等。

相关热门产品：远传无噪音监听器

诚信圣通公司网站：http://www.spwe.com
联系电话：010-66027364、010-66026820
传　　真：010-66025560 
销售经理：王先生
电话：010-66027364 
QQ：94631723 


致
礼!
  　　 王亚
  　　 [EMAIL PROTECTED]
  　　 2003-05-27

Re: Bug#190302: Misusage of changelog!

[Luca - De Whiskey's - De Vitis]

On Tue, May 27, 2003 at 10:47:15PM +1200, Nick Phillips wrote:
> If your changelog merely says "New upstream version, closes: #123 #456",
> it's no help whatsoever, and I will (rightly) think that you suck.

This is debian-devel: as soon as one declares he stops reading a thread,
beasts came out and offends by praying on the tail of a discussion.

You discriminate and offend people only by reading a list of changes, and i
should be the one who suks (supposing i'm not right)?

> FFS, it's a *change*log -- so log the effing changes in it.

The contraddiction of all this tread, is that: if i make a change to a package
i've to list my change in the package changelog (Matt Zimmerman, no one ever
objected this). If i build a new upstream, i've to list each change in
the upstream changelog that let me declare a bug as closed; change that does
not refer to the Debian package (but to the original upstream), and that i did
not applied as part of my package working (because it was applied from the
upstream).

To demostrate how much this issue is stupid, i'll make any one here happy by
including the entire upstream changelog in changelog.Debian.gz, next time i'll
build a new upstream.

have a nice day,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

does debian also support 64-bit x86 systems > HP i2000 itanium

[PPMW]

dear sirs,
does VMware also support 64-bit x86 systems > HP i2000 itanium
... what do we need?
paul!
_
NOTE: This message is for the named person's use only. It may contain 
confidential, proprietary or legally privileged information. No 
confidentiality or privilege is waived or lost by any mistransmission. If 
you receive this message in error, please immediately delete it and all 
copies of it from your system, destroy any hard copies of it and notify the 
sender. You must not, directly or indirectly, use, disclose, distribute, 
print, or copy any part of this message if you are not the intended 
recipient. We and any of our subsidiaries each reserve the right to monitor 
all email communications through its networks. Any views expressed in this 
message are those of the individual sender, except where the message states 
otherwise and the sender is authorized to state them to be the views of any 
such entity. Thank You.;)

Anonymity & Privacy Is Not A Crime! Freeware PGP: encryption + signature: 
http://www.pgpi.org. Get signature + public key (PGP Server): 
http://pgpkeys.mit.edu:11371

Re: Bug#190302: Misusage of changelog!

[Michael Banck]

On Tue, May 27, 2003 at 07:14:28AM -0500, Luca - De Whiskey's - De Vitis wrote:
> To demostrate how much this issue is stupid, i'll make any one here
> happy by including the entire upstream changelog in
> changelog.Debian.gz, next time i'll build a new upstream.

Didn't you just complain that people said you wouldn't have common
sense?

How odd.


Michael

-- 
 i actually never planned to be in any other channel than #c++
 everywhere else seemed like the loonie bin. or worst, the
internet community. ;D

Re: Bug#190302: Misusage of changelog!

[Mathieu Roy]

Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> a tapoté :
> 
> You discriminate and offend people only by reading a list of
> changes, and i should be the one who suks (supposing i'm not right)?

He has the right to think that you sucks at filling changelogs,
regarding how you fill changelogs.
Anybody has the right to express a point of view on anybody else work,
right?

> > FFS, it's a *change*log -- so log the effing changes in it.
> 
> The contraddiction of all this tread, is that: if i make a change to a package
> i've to list my change in the package changelog (Matt Zimmerman, no one ever
> objected this). If i build a new upstream, i've to list each change in
> the upstream changelog that let me declare a bug as closed; change that does
> not refer to the Debian package (but to the original upstream), and that i did
> not applied as part of my package working (because it was applied from the
> upstream).

You said you have "to list each change in the upstream changelog" to
know which bug can be declared as closed. And that's, as maintainer,
your job, isn't it? But is it users job to do it too?

> To demostrate how much this issue is stupid, i'll make any one here
> happy by including the entire upstream changelog in
> changelog.Debian.gz, next time i'll build a new upstream.

Is this mature?

You still did not answer to the question: is it too much extra work
you can afford to add in the changelog what permits you to declare a
bug closed?


-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: does debian also support 64-bit x86 systems > HP i2000 itanium

[Nathan Poznick]

Thus spake PPMW:
> dear sirs,
> 
> does VMware also support 64-bit x86 systems > HP i2000 itanium
> 
>   ... what do we need?

http://www.debian.org/ports/ia64/
The HP i2000 is mentioned as "working well" with Debian ia64.

-- 
Nathan Poznick <[EMAIL PROTECTED]>

Not that I'm against sneaking some notions into people's heads upon
occasion. (Or blasting them in outright.) -- Larry Wall

Re: Bug#190302: Misusage of changelog!

[Luca - De Whiskey's - De Vitis]

On Tue, May 27, 2003 at 03:10:36PM +0200, Mathieu Roy wrote:
> Anybody has the right to express a point of view on anybody else work,
> right?

I'll try to keep in mind this gentlemen example of "expressing a point of view 
on
anybody else work" next time, so i'll not misunderstend it with an offense.

> You said you have "to list each change in the upstream changelog" to
> know which bug can be declared as closed. And that's, as maintainer,
> your job, isn't it? But is it users job to do it too?

I do not understand that: could you rephrase?

> Is this mature?

It is as much mature as all the argument you people brought to this
discussione, from my point of view. If you asked that question yourself,
you're probably going to understand my point.

> You still did not answer to the question: is it too much extra work
> you can afford to add in the changelog what permits you to declare a
> bug closed?

Speaking about entry like "New upstream closes #...", my position is:

This kind of request is futile, redundant and of no real need in _any_ case.
Hunting maintainers down for a log entry of that kind is a waste of time
either for the maintainer and for the hunters. All the arguments brought to
this discussion to confute my observation are so childish and contraddictory,
that the only way i have to demonstrate it is to act as previously stated.

Have a nice day,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Re: Bug#190302: Misusage of changelog!

[Luca - De Whiskey's - De Vitis]

On Tue, May 27, 2003 at 03:11:11PM +0200, Michael Banck wrote:
> Didn't you just complain that people said you wouldn't have common
> sense?
> 
> How odd.

Not that odd: if someone feels to be in the position of telling me that i've no
common sense or express any other kind of colorful expression about my works,
i thought i should have given him a real reason.

The real odd think is that there are really a lot of people who think to be in
the right position to point other maintainers as "loosers" or "without common
sense"; and many are in charge of something in Debian. That make me
wander...

Have a nice day,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Re: Bug#190302: Misusage of changelog!

[Hamish Moffatt]

On Tue, May 27, 2003 at 07:14:28AM -0500, Luca - De Whiskey's - De Vitis wrote:
> The contraddiction of all this tread, is that: if i make a change to a package
> i've to list my change in the package changelog (Matt Zimmerman, no one ever
> objected this). If i build a new upstream, i've to list each change in
> the upstream changelog that let me declare a bug as closed; change that does
> not refer to the Debian package (but to the original upstream), and that i did
> not applied as part of my package working (because it was applied from the
> upstream).
> 
> To demostrate how much this issue is stupid, i'll make any one here happy by
> including the entire upstream changelog in changelog.Debian.gz, next time i'll
> build a new upstream.

Here's a suggestion for you. How about a simple changelog entry saying
what the bug was and that it was closed by the new upstream code? Here's
what I used in a recent xpdf upload, for example:

xpdf (2.02-1) unstable; urgency=low
 
  * New upstream release
  * Incorporated new Arabic language package 2003-feb-16
  * Updated Hebrew language support to 2003-feb-16
  * Upstream: fixed display problems in some PDFs (closes: #181076,
#144047, #167827, #176856, #180829)
  * Upstream: fixed crash on find-next before find (closes: #172973)
  * Upstream: fixed color handling in buttons (closes: #171398)
  * Upstream: fixed crash if Ctrl-W pressed while file open (closes: #177698)
 
 -- Hamish Moffatt <[EMAIL PROTECTED]>  Sun, 30 Mar 2003 14:06:43 +1000
 
This is more informative than just

  * New upstream release (closes: #n, #m, #i, #j)

and not really a lot of work. I started doing this after an earlier
version of this same discussion...

Comments on the above format welcome, btw.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Bug#194902: ITP: libfilesys-statvfs-perl -- perl extension for statvfs()

[Ingo Saitz]

Package: wnpp
Version: unavailable; reported 2003-05-27
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libfilesys-statvfs-perl
  Version : 0.68
  Upstream Author : Ian Guthrie <[EMAIL PROTECTED]>
* URL :
* http://www.cpan.org/modules/by-module/Filesys/IGUTHRIE/
* License : Perl (dual GPL/Artistic License)
  Description : perl extension for statvfs()

Filesys::Statvfs provides an interface between Perl and the statvfs()
system call.

Filesys::Df uses Filesys::Statvfs to obtain filesystem statistics then
creates additional filesystem information such as percent full, user and
superuser differentials, etc.

This module differs from libfilesys-diskfree in that it does call
statfs() directly and does not rely on the output of /bin/df.

- -- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux pinguin 2.4.21-rc3-1 #1 Fre Mai 23 17:40:10 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+03Pw4XrXtQkN2NURAkhXAKDMUEOhaUYGHb5fA9kj2o7ZzM4wBACgiykW
no10g2icagQ1KpWSDAIjd44=
=KdvU
-END PGP SIGNATURE-

Re: Bug#190302: Misusage of changelog!

[Mathieu Roy]

Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> a tapoté :

> > You said you have "to list each change in the upstream changelog" to
> > know which bug can be declared as closed. And that's, as maintainer,
> > your job, isn't it? But is it users job to do it too?
> 
> I do not understand that: could you rephrase?

I can. 
You wrote that you have "to list each change in the upstream
changelog" to know which bug can be declared as closed. Right?

You need to do that as the maintainer. Right?

Do you think that users should list "each change in the upstream
changelog" to know how the bug they submitted as been closed?


> > You still did not answer to the question: is it too much extra work
> > you can afford to add in the changelog what permits you to declare a
> > bug closed?
> 
> Speaking about entry like "New upstream closes #...", my position is:
> 
> This kind of request is futile, redundant and of no real need in _any_ case.
> Hunting maintainers down for a log entry of that kind is a waste of time
> either for the maintainer and for the hunters. All the arguments brought to
> this discussion to confute my observation are so childish and contraddictory,
> that the only way i have to demonstrate it is to act as previously stated.

So the only way you have to demonstrate it is to act as a child?

You do not think that providing these info in the changelog is
useful. That your choice. But apparently many people disagree with
you. 
You have an easy solution: follow the 4. of the Debian social
contract ( http://www.debian.org/social_contract ).

-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: Bug#190302: Misusage of changelog!

[Brian Nelson]

Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> writes:

> On Tue, May 27, 2003 at 10:47:15PM +1200, Nick Phillips wrote:
>> If your changelog merely says "New upstream version, closes: #123 #456",
>> it's no help whatsoever, and I will (rightly) think that you suck.
>
> This is debian-devel: as soon as one declares he stops reading a thread,
> beasts came out and offends by praying on the tail of a discussion.
>
> You discriminate and offend people only by reading a list of changes, and i
> should be the one who suks (supposing i'm not right)?
>
>> FFS, it's a *change*log -- so log the effing changes in it.
>
> The contraddiction of all this tread, is that: if i make a change to a package
> i've to list my change in the package changelog (Matt Zimmerman, no one ever
> objected this). If i build a new upstream, i've to list each change in
> the upstream changelog that let me declare a bug as closed; 

The bug was most likely fixed upstream because you informed them about
the bug.  It's even possible you sent upstream a patch to fix the bug (I
know I've done this several times).  So, you either know for yourself or
have been told by upstream how the bug was fixed.  What is so fucking
hard about describing this in the changelog?

If you're not going to describe upstream fixes in the changelog, then
don't close the bug in the changelog.  The changelog is for describing
changes, not listing meaningless numbers.  Close it by hand with a note
saying it's fixed in upstream version x.y.z.

> change that does not refer to the Debian package (but to the original
> upstream), and that i did not applied as part of my package working
> (because it was applied from the upstream).

Uhh, your packages include the upstream source, and therefore the
upstream source is "part of your package working".

> To demostrate how much this issue is stupid, i'll make any one here
> happy by including the entire upstream changelog in
> changelog.Debian.gz, next time i'll build a new upstream.

You're quickly entering Matt Ryan territory.

-- 
Poems... always a sign of pretentious inner turmoil.


pgp2qJtiYvakE.pgp
Description: PGP signature

Re: Accepted bwidget 1.6.0-1 (all source)

[Brian Nelson]

Paul Slootman <[EMAIL PROTECTED]> writes:

> On Mon 26 May 2003, Brian Nelson wrote:
>
>> Umm, no, the changelog is for listing changes (*change* log, get it?),
>> not for just closing bugs without any reason given whatsoever.
>> 
>> Why do so many seem to have difficulty with this concept?  Is it
>> worthwhile to Cc this stuff to -devel, or should I just give up and let
>> the proliferation of these IMO useless changelogs continue?  (serious,
>> not rhetorical, questions)
>
> Presumably the people who continue to do this don't read debian-devel,
> or at least not thoroughly (the subject line of your messages don't
> necessarily reflect the point you're trying to get across).

I always send my messages to the maintainer as well.  Unfortunately, it
seems that for every message I send, 3 more changelogs show up with shit
entries in them.

> Perhaps a separate, concise message to debian-devel-announce?

I doubt it would help.  I see changelog abuse as an act of laziness, not
ignorance.  Common sense says that you should be listing changes in the
changelog.  It's not like there aren't plenty examples of changelogs, as
well as discussions on IRC and mailing lists, and a lengthy dissertation
in the Developer's Reference.

If a few particular maintainers are going to ignore all of the examples
of proper changelog use, why should a message to debian-devel-announce
help?  They'll just ignore that too.

-- 
Poems... always a sign of pretentious inner turmoil.


pgpwZlqyozVmy.pgp
Description: PGP signature

Re: Orphaning my packages

[Aaron M. Ucko]

David Nusinow <[EMAIL PROTECTED]> writes:

> Another point of note is that nascent packagers are encouraged to adopt
> other software that's already in the archive before packaging new
> items. In this case, he is merely following that advice.

Granted.  OTOH, applications may be a better place to start, inasmuch
as they are easier to deal with in many respects and accidentally
breaking them may not necessarily affect anything else (though it
obviously depends on the program in question).

>  - David Nusinow

Any relation to the Nusinoviches?

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

Re: Bug#190302: Misusage of changelog!

[Luca - De Whiskey's - De Vitis]

On Tue, May 27, 2003 at 05:12:22PM +0200, Mathieu Roy wrote:
> I can. 
> You wrote that you have "to list each change in the upstream
> changelog" to know which bug can be declared as closed. Right?

That is what i wrote, but is not what i meant: it have a difference meaning if
you take it out of the context, but my english is not so good to commit that i
explained my self. I'll rephrase:

--
You people told me that:
- If i make a change to a package i've to list my changes in the package
  changelog (Matt Zimmerman, no one ever objected this).
- If i build a new upstream, i've to list each change in the upstream
  changelog that let me declare a bug as closed; change that does not refer to
  the Debian package (but to the original upstream), and that i did not
  applied as part of my package working (because it was applied from the
  upstream).
--

The second contradict the first, and does not follow what stated in policy
about debian chagelog file (13.7 an 5.3 of policy).

> Do you think that users should list "each change in the upstream
> changelog" to know how the bug they submitted as been closed?

If you mean "read" by the word "list", of course i do. First came the upstream
changelog, then the Debian one.

> So the only way you have to demonstrate it is to act as a child?

So the only way to confute my observation is to bring childish arguments to
the discussion?

> You have an easy solution: follow the 4. of the Debian social
> contract ( http://www.debian.org/social_contract ).

I'm already doing it in many ways and, untill now, no one has conviced me that
this would be a real improovement.

have a nice day.
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Re: Bug#190302: Misusage of changelog!

[Luca - De Whiskey's - De Vitis]

On Tue, May 27, 2003 at 08:31:39AM -0700, Brian Nelson wrote:
> Uhh, your packages include the upstream source, and therefore the
> upstream source is "part of your package working".

So it is part of my work, and changes to my work should be included in
changelog.Debian...

> > To demostrate how much this issue is stupid, i'll make any one here
> > happy by including the entire upstream changelog in
> > changelog.Debian.gz, next time i'll build a new upstream.

... And since all upstream changes are included in upstream changelog, there is
nothing wrong or childish in including the entire file in the changelog.Debian.

have a nice day,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Re: Bug#190302: Misusage of changelog!

[John Hasler]

Brian Nelson writes:
> If you're not going to describe upstream fixes in the changelog, then
> don't close the bug in the changelog.  The changelog is for describing
> changes, not listing meaningless numbers.

If you want to have rigid, detailed rules for the content and structure of
changelog entries make them policy and write them up in debian-policy.
Anything less will just result in more pointless flamewars.
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

Re: Accepted bwidget 1.6.0-1 (all source)

[Josip Rodin]

On Tue, May 27, 2003 at 08:39:50AM -0700, Brian Nelson wrote:
> > Perhaps a separate, concise message to debian-devel-announce?
> 
> I doubt it would help.  I see changelog abuse as an act of laziness, not
> ignorance.  Common sense says that you should be listing changes in the
> changelog.  It's not like there aren't plenty examples of changelogs, as
> well as discussions on IRC and mailing lists, and a lengthy dissertation
> in the Developer's Reference.
> 
> If a few particular maintainers are going to ignore all of the examples
> of proper changelog use, why should a message to debian-devel-announce
> help?  They'll just ignore that too.

Actually, they might not. The developers' reference section on that is
fairly new, so not all people may have seen it. Reminding them via -d-a
wouldn't quite be as effective as shoving it down their throats :) but
I'm sure it would help a lot of people.

-- 
 2. That which causes joy or happiness.

Re: Bug#190302: Misusage of changelog!

[Matt Zimmerman]

On Tue, May 27, 2003 at 11:43:22AM -0500, John Hasler wrote:

> Brian Nelson writes:
> > If you're not going to describe upstream fixes in the changelog, then
> > don't close the bug in the changelog.  The changelog is for describing
> > changes, not listing meaningless numbers.
> 
> If you want to have rigid, detailed rules for the content and structure of
> changelog entries make them policy and write them up in debian-policy.
> Anything less will just result in more pointless flamewars.

There's no need for the rigidity of policy here, and the developer's
reference already contains detailed information on this subject.

-- 
 - mdz

Bug#194938: ITP: drivel -- A LiveJournal client for the GNOME desktop

[Neil McGovern]

Package: wnpp
Version: unavailable; reported 2003-05-27
Severity: wishlist

* Package name: drivel
  Version : 0.9.1
  Upstream Author : Todd Kulesza <[EMAIL PROTECTED]> 
* URL : http://sourceforge.net/projects/drivel/
* License : GPL
  Description : A LiveJournal client for the GNOME desktop

Drivel is a LiveJournal.com client for the GNOME desktop.

It supports all livejournal-based servers, and allows you to perform
most functions that are supported by the server (posting, friends editing,
friend groups, friend page checking, post editing etc).

It is designed to utilize the new features of GNOME 2.0 including GConf and
GTK 2.0.

I'm currently in the NM queue, and Chris Butler ([EMAIL PROTECTED]) will
be sponsoring my upload.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux vivacia 2.4.20-1-k7-smp #1 SMP Sat Mar 22 15:58:43 EST 2003 i686
Locale: LANG=en_GB, LC_CTYPE=en_GB

Re: Bug#190302: Misusage of changelog!

[Peter S Galbraith]

Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> wrote:

> You people told me that:
> - If i make a change to a package i've to list my changes in the package
>   changelog (Matt Zimmerman, no one ever objected this).
> - If i build a new upstream, i've to list each change in the upstream
> changelog that let me declare a bug as closed; change that does not
> refer to the Debian package (but to the original upstream), and that i
> did not applied as part of my package working (because it was applied
> from the upstream).
> 
> The second contradict the first, and does not follow what stated in policy
> about debian chagelog file (13.7 an 5.3 of policy).
> 
> > Do you think that users should list "each change in the upstream
> > changelog" to know how the bug they submitted as been closed?
> 
> If you mean "read" by the word "list", of course i do. First came the
> upstream changelog, then the Debian one.

Fine then.  In that case it would be better for you _not_ to use the
Debian changelog to close bugs by the new upstream version, but rather
to email [EMAIL PROTECTED] with a proper explanation of what
was done upstream.  Right?

Re: Maintaining kernel source in sarge

[Yann Dirson]

Sven wrote:
> Why don't we use a scheme similar to what xfree86 use for its patches.
> Sure we would need to adapt it as the patches are distributed, but we
> could well do it. 

As I understand it, the xfree86 package uses (some derivative of) dbs,
in which the package maintainer has to order the patches by hand,
instead of declaring explicit dependencies (much like sysvinit and
others do, and like the patch-ordering facility in make-kpkg).

If the above is correct, I'd see that as a step backwards.

Regards,
-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> |  Freedom, Power, Stability, Gratuity
 http://ydirson.free.fr/| Check 

Re: Accepted bwidget 1.6.0-1 (all source)

[Brian Nelson]

Josip Rodin <[EMAIL PROTECTED]> writes:

> On Tue, May 27, 2003 at 08:39:50AM -0700, Brian Nelson wrote:
>> > Perhaps a separate, concise message to debian-devel-announce?
>> 
>> I doubt it would help.  I see changelog abuse as an act of laziness, not
>> ignorance.  Common sense says that you should be listing changes in the
>> changelog.  It's not like there aren't plenty examples of changelogs, as
>> well as discussions on IRC and mailing lists, and a lengthy dissertation
>> in the Developer's Reference.
>> 
>> If a few particular maintainers are going to ignore all of the examples
>> of proper changelog use, why should a message to debian-devel-announce
>> help?  They'll just ignore that too.
>
> Actually, they might not. The developers' reference section on that is
> fairly new, so not all people may have seen it. Reminding them via -d-a
> wouldn't quite be as effective as shoving it down their throats :) but
> I'm sure it would help a lot of people.

Hmm.  Maybe for each major release of the developers' reference, an
announcement on d-d-a should be made that recites the new additions.
Currently, it's not really obvious what's been added to it, and many
developers probably ignore it for months or years at a time.

-- 
Poems... always a sign of pretentious inner turmoil.


pgpoQy4leaGA5.pgp
Description: PGP signature

Asking for maintainer for astronomical packages and some important (and related) issues

[Javier Fernández-Sanguino Peña]

Hi there,

Since I'm overloaded with work (in and out of Debian) I'm considering
orphaning a number of packages related to astronomy, they are:
- openuniverse
- starplot
- spacechart
- yale 
and
- gliese

The first three are GUIs to view astronomical date whileas the last 
two include astronomic data themselves. There is a reason for separating 
both, mainly that the legal status for this data files is not all too clear.

I would rather given them all to the same person than breaking them up,
since I expect that a prospective maintainer would take care of 
the following issues:

1.- Copyright issues, these impact on quite a number of 
astronomical-related packages. 

I made the decision of breaking the star catalogs into packages 
into non-free but others have not (see bug #174456 - which details 
some of the copyright issues).

This issue should be pursued to:

- determine wether or not the star data can be distributed in
  main (I have a number of mails that need pursuing)

- contact maintainers to coordinate the use of a single data
  package instead of having the same star catalogs in every
  astronomical packages (maybe even ask for a 
  'star-catalog' virtual package that all could provide)

This issue needs to be coordinated with other maintainers since other
packages (like kstars?) might be affected.

2.- New releases (bug #169603 - startplot new version and
bug #172203 - spacechart new release mainly) although the data files
might need to be updated (haven't checked)

3.- The issue on wether to keep or remove openuniverse
(its no longer maintained upstream, and maintainers have moved to
improve celestia but it's not a full replacement for it). The 
relevant thread in debian-devel starts here:
http://lists.debian.org/debian-devel/2002/debian-devel-200212/msg01597.html

4.- Determine if a new section should be created for astronomic-related
packages. Some are in section 'science' some in section 'math'...

Of course, maintainers should also consider checking out
bugs #188183 (gstar package, now orphaned), #170824 (celestia is now
also orphaned) and #173440 (an ITP for yet another astronomy 
program: nightfall) in order to make a coordinated action. Writting an
astronomy-related mini-policy for Debian could be in order.

So, after all this rant, any takers? (I hope somebody raises his hand) :-)

Regards

Javi





pgpxW439cBDPm.pgp
Description: PGP signature

Re: debian-exim mailing list?

[Martin Schulze]

Andreas Metzler wrote:
> It would be nice if there were documented mechanisms to move a list
> /painlessly/ from alioth to lists and vice versa, i.e. keeping the
> subscriber list and redirections for the old list addresses.

Please send me a patch to the List HOWTO I once wrote.  You'll need
monthly archives of the list as mbox files (may be compressed, of course)
and the list of subscribers, in addition to the other things we request
for a new list.

The current howto is here:
http://www.debian.org/MailingLists/HOWTO_start_list

Regards,

Joey

-- 
Testing? What's that? If it compiles, it is good, if it boots up, it is perfect.

Please always Cc to me when replying to me on the lists.

Re: Maintaining kernel source in sarge

[Yann Dirson]

Arnd wrote:
> > Let's look at your example:
> > | Patch-name: Debian base patch
> > | Patch-id: debian
> > | Architecture: all
> > | Kernel-version: 2.4.20
> > | Depends: ptrace, isdnbonding, binfmtmisc, ethernetpadding, ...
> > |
> > | Patch-name: Pre-patch 2.4.21-pre7
> > | Patch-id: patch-2.4.21-pre7
> > | Architecture: all
> > | Kernel-version: 2.4.20
> > | Provides: ptrace, ethernetpadding
> >
> > Here I suppose the pre-patch is supposed to be applied first, and then
> > the application of the debian patch would only trigger application of
> > those dependant patches not provided by the pre-patch.
[...]
> In my example, if the isdnbonding patch has to be applied after
> ethernetpadding, it would have to say so in its description.
> patch-2.4.21-pre7 can contain the same patch and should
> consequently be applied at the same time (e.g. after
> binfmtmisc, but before isdnbonding).

OK, let's assume a moment that isdnbonding declares a dependency on
ethernetpadding:

Let's apply the debian patch first, since that's what you suggested
later.  This patch application will trigger, among others, the
(pre-)application of isdnbonding, which itself will trigger the
(pre-)application of ethernetpadding.

Now the "Provides" logic will have to cause the application of
patch-2.4.21-pre7 instead.  That seems to settle reasonably.

But now suppose that a new version of the ptrace patch is issued.
Either we just rely on the current version of the debian patch, and
the new ptrace one won't even be considered by the mechanism here
described, if you ask for the application of patch-2.4.21-pre7.  Or we
have to issue a new revision of the debian patch, either depending on
a new ptrace2 patch, declaring a conflict with old ptrace (in which
case we have to handle conflicts as well), or with a versionned
depends (which has to be implemented as well) on the new version of
ptrace.

Basically, this means bring a full dpkg/apt-like dependency model into
patch application.  This overall sounds to my ears a bit like
overkill...


> The debian patch set should generally come first, except for the parts
> in it that depend on patches 'provided' by some other patch. The maintainer
> of patch-2.4.21-pre7 would have to make sure it applies on top of or mixed
> with the debian patch set.

I don't know what you mean with "mixed with".  It is already some work
when we have to provide, in addition to the upstream version, a
version of the patch(es) that applies to the (current) debian kernel
(some people may have noted that dh-kpatches supports declaring such
patches since recently).  I hope you're not suggesting all mixes of
sub-patches of the debian patch should be supported - this idea would
have no chance to survive long :)

Regards,
-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> |  Freedom, Power, Stability, Gratuity
 http://ydirson.free.fr/| Check 

Re: Maintaining kernel source in sarge

[Yann Dirson]

Herbert wrote:
> Yes that isn't easy to check apart from the fact that if there isn't
> an arch update after a security update to kernel-source, then that arch
> is probably vulnerable.  If you've got an idea on how this can improved,
> please let us know.

A possibility would be to define a versionning scheme on the arch-dep
kernel-patches.  You issue version 2.4.20-8, and others release a new
version as 2.4.20-8, and then possibly further -8.1 and such, and
don't bump to -9 before you do.

That steps into the NMU numbering-space, but I suppose we can expect
NMUs on arch kernel-patches to be quite rare anyway.  And we could
give a NMU numbering-space with 2 dots, by making the 1st revision of
an arch patch to be -8.0 at first.

Does it make sense ?
-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> |  Freedom, Power, Stability, Gratuity
 http://ydirson.free.fr/| Check 

Re: Accepted bwidget 1.6.0-1 (all source)

[Brian Nelson]

Christian Kurz <[EMAIL PROTECTED]> writes:

> Hi Brian
>
> On [26/05/03 23:13], Brian Nelson wrote:
>> Anselm Lingnau <[EMAIL PROTECTED]> writes:
> [...]
>> >* Closes: #159971, #124472, #147059, #70184.
>
>> Umm, no, the changelog is for listing changes (*change* log, get it?),
>> not for just closing bugs without any reason given whatsoever.
>
>> Why do so many seem to have difficulty with this concept?  Is it
>
> Why do you seem to have a problem with contacting the maintainer in
> private instead of this public reprimanding? 

For a few reasons:

1. To show others, especially NM's, what not to do.  NM's mostly learn
   by example, and I think it helps to ensure they don't follow bad
   examples.

2. It's something that should be obvious.  Producing poor quality
   changelogs shows a real neglect for the quality of Debian overall,
   and they deserve to be publicly reprimanded.

3. It publicly shows which developers are not really involved in the
   community.  If they were involved, they would know how to write a
   proper changelog.  Developers who aren't involved in the community
   don't belong in Debian, IMO.

4. I'd be willing to guarantee that any maintainer who can't handle
   something as simple as a changelog is probably making many more
   critical mistakes in their package.  Therefore, I think it's
   important to point out these maintainers in public so everyone is
   aware of them.

>> worthwhile to Cc this stuff to -devel, or should I just give up and
>> let the proliferation of these IMO useless changelogs continue?
>> (serious, not rhetorical, questions)
>
> It's not worthwhile to Cc such e-mails to -devel or use harsh language
> like you do, if you want to encourage maintainers to make better usage
> of the changelog. With e-Mails that publicly reprimand a maintainer and
> point a finger at him, you are generating a feeling of sadness,
> annoyance or maybe even humilation, which isn't helpful. If you want to
> encourage people to improve their changelog entries, then contact them
> in private and point out the problem in a gentle manner, together with
> an explanation why the current changelog is a problem and how he can
> improve his changelog entries in the future. I don't think that your
> current behaviour and attitude to solve the problem is going to solve
> it. Change your behaviour and attitude and you will be more helpful and
> be able to solve the problem.

FWIW, I do privately contact NM's who make such mistakes.  They may not
know better, and probably don't deserve public humiliation.  Of course,
their sponsor should be correcting such mistakes...

However, I think anyone with developer status *should* know better.  I
don't particularly care if it hurts their feelings; I'd be perfectly
happy to see crappy maintainers quit maintaining their packages.

-- 
Poems... always a sign of pretentious inner turmoil.


pgp8Hn1m2BlzV.pgp
Description: PGP signature

Re: Very uneven distribution of packages per maintainer

[Yann Dirson]

Adam wrote:
> So doing bts work is worthless?  :)

Hey, someone once wrote similar scripts to count how many bugreports
were reported by anyone !

/me rejoices recalling he was ranked 3rd by the number of open bugs :)

Well, never mind :)

-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> |  Freedom, Power, Stability, Gratuity
 http://ydirson.free.fr/| Check 

Re: Maintaining kernel source in sarge

[Gunnar Wolf]

Yann Dirson dijo [Tue, May 27, 2003 at 10:38:54AM +0200]:
> That's more or less what I'd think of as well.  We can start with an
> empty security patch, and have this one grow as needed.  This way, apt
> will show people they have an outdated security patch - which, BTW,
> may be more of an incentive to upgrade than just an outdated
> kernel-source package.
> 
> That does not mean the user will rebuild his kernel at once with the
> new patch, but well, I don't think we can do much more here :)

I like the idea... And maybe we should alert the user that he needs to
rebuild the kernel using a debconf dialog or by mailing him...

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Packages with i18n support disabled

[Denis Barbier]

On Sun, May 18, 2003 at 11:39:09PM +0200, Denis Barbier wrote:
> Hi,
> 
> below is a list of source packages containing gettext .po files,
> for which binary packages do not ship any file under a LC_MESSAGES
> directory.
> There might be several reasons:
>   a. Programs use gettext PO files to store translations but manage them
>  with other tools at run time (eg. abiword, Zope or Qt applications)
>   b. PO files are not used, e.g. they are test files (po-debconf)
>   c. I18n support is not enabled at build time
>   d. Errors in PO files prevent l10n
> 
> I am going to file bugs about (c) and (d), but it needs manual checking.
> 
> If you know that your packages are correctly l10ned, or if you want to
> help me checking these packages, please let me know.

Many thanks to those who replied, here is an updated list.

   Aaron Lehmann (aaronl at vitelus.com)
 skipstone

   Alastair McKinstry (mckinstry at computer.org)
 console-common
 gtk+2.0-directfb

   Alberto Gonzalez Iniesta (agi at agi.as)
 fwlogwatch

   Aurelien Jarno (aurel32 at debian.org)
 hddtemp

   Bastian Blank (waldi at debian.org)
 zope-zwiki

   Ben Burton (bab at debian.org)
 kile

   Bradley Bell (btb at debian.org)
 bakery-gnomeui1.3

   Chip Salzenberg (chip at debian.org)
 libcpanplus-perl

   Craig Small (csmall at debian.org)
 lprng

   David Coe (davidc at debian.org)
 zope-cmfphoto
 zope-cmfphotoalbum
 zope-cmfplone
 zope-localizer

   David Schleef (ds at schleef.org)
 comedilib

   Ed Boraas (ed at debian.org)
 aime

   Enrique Robledo Arnuncio (era at debian.org)
 mctools-lite

   Eray Ozkural (erayo at cs.bilkent.edu.tr)
 sourcenav

   Federico Di Gregorio (fog at debian.org)
 grass

   Fernando Sanchez (fer at debian.org)
 qcad

   Filip Van Raemdonck (mechanix at debian.org)
 gxset

   Francois Gurin  (matrix at debian.org)
 fsviewer

   Frederic Peters (fpeters at debian.org)
 pronto

   Greg Norris (adric at debian.org)
 rio500

   Hidetaka Iwai (tyuyu at debian.or.jp)
 widestudio

   Jan-Hendrik Palic (jan.palic at linux-debian.de)
 gtkpbbuttons
 pbbuttonsd
 powerprefs

   Javier Fernandez-Sanguino Pen~a (jfs at computer.org)
 bastille

   Jereme Corrado (jereme at zoion.net)
 faqomatic

   Jordi Mallach (jordi at debian.org)
 freeciv

   Joshua Kwan (joshk at triplehelix.org)
 ircd-hybrid

   Kyle McMartin (kyle at debian.org)
 mad

   Lenart Janos (ocsi at debian.org)
 dfm   #193484

   Luca - De Whiskey's - De Vitis (luca at debian.org)
 phpgroupware

   Luca Filipozzi (lfilipoz at debian.org)
 ifhp

   Mario Lang (mlang at debian.org)
 oleo

   Mark Brown (broonie at debian.org)
 tua

   Martin Mitchell (martin at debian.org)
 apcupsd
 eject #192829

   Matt Zimmerman (mdz at debian.org)
 gpe-todo

   Matthew Garrett (mjg59 at srcf.ucam.org)
 dasher

   Mike Markley (mike at markley.org)
 aide

   Noah Meyerhans (noahm at debian.org)
 wdm #193899

   Peter Karlsson (peterk at debian.org)
 turqstat

   Phil Blundell (pb at debian.org)
 libgpewidget

   Robert Woodcock (rcw at debian.org)
 id3lib

   Robin Verduijn (robin at debian.org)
 kvirc

   Samuele Giovanni Tonon (samu at debian.org)
 apcupsd-devel

   Siggi Langauf (siggi at debian.org)
 gnome-xine

   Stefan Schwandter (swan at debian.org)
 snd

   Steve Kostecke (steve at debian.org)
 linuxlogo

   Susumu OSAWA (susumuo at debian.org)
 bookview

   Søren Boll Overgaard (boll at debian.org)
 gkrellweather

   Uwe Steinmann (uwe at steinmann.cx)
 gpmudmon-applet

   Wilmer van der Gaast (lintux at lintux.cx)
 pyne

   Yoshiaki Yanagihara (yochi at debian.org)
 gbiff

   Zed Pobre (zed at debian.org)
 licq

Denis

Bug#194961: ITP: yaz -- A C/C++ toolkit for Z39.50/ISO23950 applications

[Eric Schwartz]

Package: wnpp
Version: unavailable; reported 2003-05-27
Severity: wishlist

* Package name: yaz
  Version : 2.0.2
  Upstream Author : IndexData
* URL : http://www.indexdata.dk/yaz/
* License : BSD-ish: http://www.indexdata.dk/yaz/doc/license.php
  Description : A C/C++ toolkit for Z39.50/ISO23950 applications

YAZ is a C/C++ programmer's toolkit supporting the development of
Z39.50v3/SRW clients and servers. Sample clients and servers are
included with the distribution, as well as documentation.

I've put prospective packages up at

http://people.debian.org/~emschwar/yaz.html

if anybody cares to take a look.  The license is basically BSD; it lacks
clause 2 in /usr/share/common-licenses/BSD, and the disclaimer is worded
slightly differently but AFAICT it is functionally identical.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux wormtongue 2.4.20skif #1 Tue Feb 18 17:27:36 MST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Jetzt kannst Du mich endlich sehen!

[Laura]

Hi!

Habe gerade die Bestätigung erhalten, das mein Kontakt-Video bei
Echter-Sex.com veröffentlicht wurde.

Jetzt kannst Du Dir mein Video ansehen. Am Ende des Videos wird meine
Kontaktadresse veröffentlicht.

Schau Dir mein privates Kontaktvideo an unter:
http://www.echter-sex.com/?ref=276505

Ja, ich suche noch immer ein reales Date!

Bussi, Laura

在“材”与“财”之间选择！

[gdgkm]

Ç×°®µÄÍø³æ£ºÈç¹ûÕâ·âÓʼþ´òÈÅÁËÄ㣬ÎÒÉî¸Ð²»°²²¢ÖÂǸ£¡
ÓÐÓÃÊÇÐÅÏ¢£¬ÎÞÓÃÊÇÀ¬»ø¡£ÇëÄã¿´ÍêÔÙɾ£¡ ^0^

ÍøÂçʱ´ú£¬¿ÉÄÜÄãʲô¶¼ÍæÁË£¬¾ÍÊÇûÓÐÍæÍøÂç׬Ǯ¡£Ôõô˵ÄØ£¬ÓÐÇ®µÄ²»Ð¼ÓÚÍæÕâÑùµÄ¶«Î÷£¬Ã»Ç®µÄÓÖÅÂÉϵ±¡£ÒÔÎÒÀ´Ëµ£¬²»Íæ
°É£¬×ܾõµÃ×÷ΪÍø³æ»¹ÉÙÁËÒ»ÖÖÔÄÀú£¨È˼ÒÎÊÎÒÍøÉϵ½µ×Äܲ»ÄÜ׬µ½Ç®£¬ÎÒÎ޴ӻش𣩡£ÒªÍæ°É£¬ÎÒ¾ÍÓÐÈý¸öÔ­Ôò£ºÒªÏȽ»Ç®µÄ£¨ÄÄÅÂ
ÊÇһԪǮ£©²»Í棬ÐíÔ¸ÈÃÎÒÒ»¸öÔ³ɰÙÍò¸»Î̵IJ»Í棬¹úÄÚµÄСÍøÕ¾²»Íæ¡£


»ùÓÚÕâÑùµÄÔ­Ôò£¬ÎÒµ¹¾õµÃ¹úÍâµÄÊÕÓʼþºÍ³åÀË׬ǮºÜÊʺÏÓÚÎÒ¡£×¬ÁËÇ®²»¸Ò¶ÀÏí£¬¾Í¹«¿ª°É£º
 

1¡¢±¾ÐÅÏ¢Ö»ÄÜΪÄãÌù²¹Ò»µãÉÏÍø·ÑÓã¨Ò»Ìì´ó¸ÅÖ»ÓÐÈý¡¢ÎåÔªÈËÃñ±Ò£¬Èç¹ûÄãÔËÆøºÃ£¬¿ÉÒÔ»ñµÃ¶îÍâ½±½ð£©;
2¡¢±¾ÐÅÏ¢ÍêÈ«Ãâ·ÑÉêÇ룬µ«Ã¿ÌìÒª»¨Ê®À´·ÖÖÓÉÏÍøʱ¼ä£¨ºÙºÙ£¬Ê±¼äÒ²ÊǽðÇ®°¡£©;
3¡¢Èç¹ûÄã·ûºÏÉÏÃæÁ½µã£¬Äã×îºÃ»¹Òª¶®Ò»µãÓ¢Óï;
4¡¢Èç¹ûÄã²»¶®Ó¢ÓÄã±ØÐëÖªµÀд×Ô¼ºµÄÐÕÃûºÍסַµÄººÓïÆ´Òô;
5¡¢Èç¹ûÄãÁ¬×Ô¼ºÐÕÃûºÍסַµÄººÓïÆ´Òô¶¼²»ÖªµÀд£¬ÄÇ¡«¡«¡«¡«Äã°ÑÕâÓʼþɾ³ý°É¡£

  ÖúÄã³É²Ä£º»¶Ó­·ÃÎÊ¡°Ñ§º£µ´ÖÛ¡± ==>>http://www.gdjyw.com

  ¿É·¢Ð¡²Æ£º  ±ßÉÏÍø±ß׬Ǯ/ÊÕÓʼþ׬Ǯ==>>
http://www.gdjyw.com/shangye/email.htm

 ¿ªÊ¼ÄãµÄÐж¯°É£¡
   

Re: Very uneven distribution of packages per maintainer

[Colin Watson]

On Tue, May 27, 2003 at 10:40:06PM +0200, Yann Dirson wrote:
> Adam wrote:
> > So doing bts work is worthless?  :)
> 
> Hey, someone once wrote similar scripts to count how many bugreports
> were reported by anyone !

Try:

  http://bugs.debian.org/cgi-bin/pkgindex.cgi?indexon=submitter&sortby=count

(Beware, the output is over a megabyte.)

> /me rejoices recalling he was ranked 3rd by the number of open bugs :)

You still are. :)

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: LDAP adduser/deluser

[Matthew Palmer]

On Tue, 27 May 2003, Zed Pobre wrote:

> > Could you elaborate on what ways yours works better than the original
> > adduser?  I'm sure Roland would love to hear about functionality
> > improvements, and I'd certainly be keen for any improvements to the
> > LDAP-specific code...
> 
> My version will iterate through a list of users, has a "quiet"
> mode that fills in only minimal information automatically, and instead

Bulk creation would probably be a good thing for adduser to have anyway, and
the "quiet" mode (not really quiet, I'd say non-intrusive, perhaps )
would be a good complement to that.  If you can turn them into patches to
adduser, I'm sure Roland would be appropriately interested.  I don't have a
need for them directly myself, and I'm a bit snowed to be triaging general
patches for adduser at the moment.

> of calling chfn, produces questions that better represent the kind of
> information you can store with the cosine and inetorgperson schemas
> (first name and surname are split up, for instance, and you can tell
> it to ask additional questions about departmental code, title, etc.).

Now *that* might be something to integrate into the LDAP support.  It does
suck mightily that you've got to install a hacked chfn from ldap-utils to
make adduser work, and the superior user info storage in LDAP *should* be
utilised better.  I'd be interested in your scripts for that functionality,
if nothing else.

> Since I still have a need to better handle bulk account creation,
> I'm contemplating adding in support for automatic password generation
> in the next day or two as well.

I've never had to deal with bulk accounts myself, but wouldn't it generally
be better to either have the password specified in the list of accounts, or
leave the account disabled until it's manually enabled by an admin or
someone?

> Okay, should I be sending my scripts to you to look at, then?

I'll certainly have a look at them, but I probably couldn't do too much with
anything except the LDAP support.

- Matt

Re: Accepted bwidget 1.6.0-1 (all source)

[Steve Langasek]

On Tue, May 27, 2003 at 12:15:37PM -0700, Brian Nelson wrote:

> 1. To show others, especially NM's, what not to do.  NM's mostly learn
>by example, and I think it helps to ensure they don't follow bad
>examples.

> 2. It's something that should be obvious.  Producing poor quality
>changelogs shows a real neglect for the quality of Debian overall,
>and they deserve to be publicly reprimanded.

"Obvious" is a key word indicating that you need to check your
assumptions at the door.  While I will certainly concede that changelogs
that spell out the nature of relevant upstream changes are more useful
than those which do not, the only argument extended that persuades me
it's worth extra effort on my part is that it impacts the work of our
long-suffering Security Team.  It disappoints me that anyone would
consider this such a serious offense that it justifies prolonged
flogging on a public mailing list.

While using the changelog to close bugs without explaining what was done
or to close bugs that were not fixed by the upload in question should
not be tolerated, you're getting upset about bug closings that
absolutely *do* include a description of what the maintainer changed in 
order to fix them: incorporating a "new upstream release".  That this is
too succinct for some applications does not make it "changelog abuse".
Nor, BTW, is it changelog abuse to have forgotten to close a fixed bug
in the changelog: your hard-line stance invites maintainers to simply
close *all* bugs manually after upload, which makes the changelog a much
less useful tool on many levels.

> 3. It publicly shows which developers are not really involved in the
>community.  If they were involved, they would know how to write a
>proper changelog.  Developers who aren't involved in the community
>don't belong in Debian, IMO.

Mmm-hmm.

> 4. I'd be willing to guarantee that any maintainer who can't handle
>something as simple as a changelog is probably making many more
>critical mistakes in their package.  Therefore, I think it's
>important to point out these maintainers in public so everyone is
>aware of them.

Some of us are a little more focused on those aspects of our packages
that are actually mandated by policy.

-- 
Steve Langasek
postmodern programmer


pgpRcmDfDYYZs.pgp
Description: PGP signature

Re: Accepted bwidget 1.6.0-1 (all source)

[Brian Nelson]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Tue, May 27, 2003 at 12:15:37PM -0700, Brian Nelson wrote:
>
>> 1. To show others, especially NM's, what not to do.  NM's mostly learn
>>by example, and I think it helps to ensure they don't follow bad
>>examples.
>
>> 2. It's something that should be obvious.  Producing poor quality
>>changelogs shows a real neglect for the quality of Debian overall,
>>and they deserve to be publicly reprimanded.
>
> "Obvious" is a key word indicating that you need to check your
> assumptions at the door.  While I will certainly concede that changelogs
> that spell out the nature of relevant upstream changes are more useful
> than those which do not, the only argument extended that persuades me
> it's worth extra effort on my part is that it impacts the work of our
> long-suffering Security Team.  It disappoints me that anyone would
> consider this such a serious offense that it justifies prolonged
> flogging on a public mailing list.
>
> While using the changelog to close bugs without explaining what was done
> or to close bugs that were not fixed by the upload in question should
> not be tolerated, 

That was the case in this thread.

> you're getting upset about bug closings that absolutely *do* include a
> description of what the maintainer changed in order to fix them:
> incorporating a "new upstream release".  That this is too succinct for
> some applications does not make it "changelog abuse".  

I'll concede this point, though I still think we should encourage
maintainers to spell out upstream fixes in the changelog.

> Nor, BTW, is it changelog abuse to have forgotten to close a fixed bug
> in the changelog: your hard-line stance invites maintainers to simply
> close *all* bugs manually after upload, which makes the changelog a
> much less useful tool on many levels.

Hmm, I don't understand.  Every bug that has been fixed should be closed
in the changelog when possible.  If a maintainer forgets, then close it
manually with a note mentioning in which version it was fixed.  When did
I say otherwise?

-- 
Poems... always a sign of pretentious inner turmoil.


pgpSLvF2OnGrh.pgp
Description: PGP signature

Re: Accepted bwidget 1.6.0-1 (all source)

[Steve Langasek]

On Tue, May 27, 2003 at 07:41:34PM -0700, Brian Nelson wrote:

> > "Obvious" is a key word indicating that you need to check your
> > assumptions at the door.  While I will certainly concede that changelogs
> > that spell out the nature of relevant upstream changes are more useful
> > than those which do not, the only argument extended that persuades me
> > it's worth extra effort on my part is that it impacts the work of our
> > long-suffering Security Team.  It disappoints me that anyone would
> > consider this such a serious offense that it justifies prolonged
> > flogging on a public mailing list.

> > While using the changelog to close bugs without explaining what was done
> > or to close bugs that were not fixed by the upload in question should
> > not be tolerated, 

> That was the case in this thread.

In recent threads (I've lost track of which), it's happened more than
once that maintainers have been criticized simultaneously for both types
of changelog entries.  Indeed, the bulk of these threads have been
dedicated to arguing the legitimacy of 'New upstream release; closes: ...'
bugs, *not* to defending maintainers who use the changelog to fix bugs
unrelated to the upload.

> > you're getting upset about bug closings that absolutely *do* include a
> > description of what the maintainer changed in order to fix them:
> > incorporating a "new upstream release".  That this is too succinct for
> > some applications does not make it "changelog abuse".  

> I'll concede this point, though I still think we should encourage
> maintainers to spell out upstream fixes in the changelog.

Encouraging, yes; but, ...

> > Nor, BTW, is it changelog abuse to have forgotten to close a fixed bug
> > in the changelog: your hard-line stance invites maintainers to simply
> > close *all* bugs manually after upload, which makes the changelog a
> > much less useful tool on many levels.

> Hmm, I don't understand.  Every bug that has been fixed should be closed
> in the changelog when possible.  If a maintainer forgets, then close it
> manually with a note mentioning in which version it was fixed.  When did
> I say otherwise?

point being that public ridicule may simply encourage maintainers to
sidestep the issue by not closing bugs in the changelog at all --
particularly when there are differing opinions on what is or is not an
"acceptable" explanation in the changelog.

-- 
Steve Langasek
postmodern programmer


pgp6Vz5NKjSYd.pgp
Description: PGP signature