Re: Urgency bug, or am I missing something?

[Thijs Kinkhorst]

On Wed, 2006-08-02 at 12:29 -0600, Wesley J. Landaker wrote:
> And the "Urgency" field matches Debian policy 5.6.17, where it explicitly 
> states: "It consists of a single keyword usually taking one of the values 
> low, medium or high (not case-sensitive) followed by an optional commentary 
> (separated by a space) which is usually in parentheses."
> 
> Is this a bug, or am I actually just missing something here?

This is indeed a bug in DAK, see #327801.


Thijs


signature.asc
Description: This is a digitally signed message part

Re: Centralized darcs

[Thijs Kinkhorst]

On Wed, 2006-08-02 at 15:34 -0500, John Goerzen wrote:
> 
> > Ok, third time. Please do not do that:
> > To: George Danchev <[EMAIL PROTECTED]>
> > CC: debian-devel@lists.debian.org
> 
> Then SET YOUR HEADERS to reflect that, like everyone else does. 

So you're shouting to people to use non-standard and not generally
implemented headers to in order to have you comply with the mailinglist
code of conduct?

Please review: http://www.debian.org/MailingLists/#codeofconduct

Thanks.

Thijs


signature.asc
Description: This is a digitally signed message part

Re: Centralized darcs

[Frank Küster]

Matthew Palmer <[EMAIL PROTECTED]> wrote:

> On Wed, Aug 02, 2006 at 06:31:18PM +0200, Frank Küster wrote:
>> John Goerzen <[EMAIL PROTECTED]> wrote:
>> > I think people that are NMUing packages rarely care about this.
>> 
>> When NMU'ing a package, I'd really appreciate to know which changes have
>> which purpose and which "specificity".  In particular when trying to
>> incorporate a fix provided by upstream - why the hell doesn't it apply
>> cleanly?  Did the Debian maintainer already try to address the problem
>> differently,
>
> We have changelogs for that.  If a maintainer doesn't fill out changelogs
> adequately, what are the chances that they're going to document their
> patches any better?

The changelog will say something like "patched component foo to no
longer fail on bar", as well as "patched component foo to support baz"
and "patched component foo, I think the code might be insecure".  You
can't tell which changelog entry corresponds to which hunk in which
file.  With separated patches this is much easier, even if they are
undocumented (except for the name).

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Centralized darcs

[Mark Brown]

On Wed, Aug 02, 2006 at 03:34:34PM -0500, John Goerzen wrote:
> On Wed, Aug 02, 2006 at 09:09:12PM +0300, George Danchev wrote:

> > Care to describe how without using your SCM but apt-get source instead ?

> apt-get source packagename

> Really, what is the problem here?

With a system like dpatch when one downloads the source package it
includes any modifications made to upstream as a series of logically
separate patches, hopefully helping to document what the purpose of each
individual modification is or at least providing information on which
sets of changes go together.  This information makes it much easier to
understand what has been modified for the package and why.  This is
especially useful where you're trying to do something like figure out
behaviour which diverges from upstream.

Similar information should be provided by a revision control system but
normally only with the repository.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[Miles Bader]

Thijs Kinkhorst <[EMAIL PROTECTED]> writes:
> So you're shouting to people to use non-standard and not generally
> implemented headers to in order to have you comply with the mailinglist
> code of conduct?

Er, well the advantage of the headers is that in practice they pretty
much work most of the time (despite being "non-standard" and "not
generally implemented" they seem to work with the sort of MUA dds tend
to use), unlike the c-o-c, which doesn't really.

-Miles
-- 
Everywhere is walking distance if you have the time.  -- Steven Wright


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[Lars Wirzenius]

to, 2006-08-03 kello 17:56 +0900, Miles Bader kirjoitti:
> Er, well the advantage of the headers is that in practice they pretty
> much work most of the time (despite being "non-standard" and "not
> generally implemented" they seem to work with the sort of MUA dds tend
> to use), unlike the c-o-c, which doesn't really.

Debian's lists support List-ID, List-Post, and the other List- headers.
If mutt's L command doesn't use that to figure out the list reply
address, perhaps someone would be so kind as to write a suitable patch?

(That's what evolution's control-L seems to cue in on, fwiw.)

-- 
Rule #13 for successful communication: don't do Latin quotations


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[martin f krafft]

also sprach Lars Wirzenius <[EMAIL PROTECTED]> [2006.08.03.1116 +0100]:
> Debian's lists support List-ID, List-Post, and the other List- headers.
> If mutt's L command doesn't use that to figure out the list reply
> address, perhaps someone would be so kind as to write a suitable patch?
> 
> (That's what evolution's control-L seems to cue in on, fwiw.)

It sure works, but you have to let mutt know about it:

  subscribe debian-devel@lists.debian.org

That's a *good* thing.

> Rule #13 for successful communication: don't do Latin quotations

quidquid latine dictum sit, altum viditur. Never forget that!

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"women who want to be equal to men lack ambition."
  -- timothy leary


signature.asc
Description: Digital signature (GPG/PGP)

Re: Centralized darcs

[Lars Wirzenius]

to, 2006-08-03 kello 11:23 +0100, martin f krafft kirjoitti:
> also sprach Lars Wirzenius <[EMAIL PROTECTED]> [2006.08.03.1116 +0100]:
> > Debian's lists support List-ID, List-Post, and the other List- headers.
> > If mutt's L command doesn't use that to figure out the list reply
> > address, perhaps someone would be so kind as to write a suitable patch?
> > 
> > (That's what evolution's control-L seems to cue in on, fwiw.)
> 
> It sure works, but you have to let mutt know about it:
> 
>   subscribe debian-devel@lists.debian.org
> 
> That's a *good* thing.

My point was that having to tell mutt manually about every mailing list
is a pain, and people don't do it. The List- headers are sufficient, in
my experience, to automate this.

-- 
When in doubt, use brute force.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[Magnus Holmgren]

On Thursday 03 August 2006 12:23, martin f krafft took the opportunity to say:
> also sprach Lars Wirzenius <[EMAIL PROTECTED]> [2006.08.03.1116 +0100]:
> > Debian's lists support List-ID, List-Post, and the other List- headers.
> > If mutt's L command doesn't use that to figure out the list reply
> > address, perhaps someone would be so kind as to write a suitable patch?
> >
> > (That's what evolution's control-L seems to cue in on, fwiw.)
>
> It sure works, but you have to let mutt know about it:
>
>   subscribe debian-devel@lists.debian.org

When I tried it, version 1.5.9-2sarge2, L worked without having to let mutt 
know anything manually. It seems to use List-Post.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpxsFMYUD0Je.pgp
Description: PGP signature

Re: Two versions of pan in etch?

[David Weinehall]

On Thu, Jul 27, 2006 at 08:31:34PM +0200, Søren Boll Overgaard wrote:
> Hello,
> 
> Pan[0] is currently undergoing a major rewrite, and being the
> maintainer, I am currently considering what version of pan to include
> in etch. This mail[1] from one of the pan mailing lists sums up the
> situation quite nicely.

Is the new version of pan able to migrate the information from the
old version yet?  Last time I tried switching to the new version,
it wouldn't recognize the fact that I was subscribed to several
newsgroups.

If it does support this now (or if you could at least add a postinst
script that does the migration), then I'm all for a switch to the
new version.


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[Shot (Piotr Szotkowski)]

Lars Wirzenius:

> to, 2006-08-03 kello 11:23 +0100, martin f krafft kirjoitti:

>> It sure works, but you have to let mutt know about it:

>>   subscribe debian-devel@lists.debian.org

>> That's a *good* thing.

> My point was that having to tell mutt manually about every mailing
> list is a pain, and people don't do it. The List- headers are
> sufficient, in my experience, to automate this.

:0
* ^Delivered-To: mailing list \/[a-z0-9_+-]+
lists/$MATCH/

:0
* ^List-Id: .*<\/[a-z0-9_+-]+
lists/$MATCH/

:0
* ^List-Id: \/[a-z0-9_+-]+
lists/$MATCH/

:0
* ^To: Multiple recipients of list <\/[a-zA-Z0-9_+-]+
lists/$MATCH/

in my ~/.procmailrc coupled with
folder-hook . "lists `cd /home/shot/Mail/lists/; echo *`"
In my ~/.muttng/muttngrc seems to work very nice.

-- Shot
-- 
I have discovered a truly remarkable solution to Fermat's
Last Theorem which this signature is too small to contain.


pgpDuUVj8ZXrU.pgp
Description: PGP signature

Re: Centralized darcs

[Alexander Sack]

On Thu, Aug 03, 2006 at 08:09:44AM +0200, Mike Hommey wrote:
> > 
> > Nobody has to learn Darcs to hack on my packages.
> 
> Well if someone has to work on a "which of the applied patch broken
> the package is such a way" kinda issue, he will have to, in order to
> have access to the patches.
> dpatch, quilt and others, in this case, make life easier (especially for
> security support).
> 

Ack  but on the other hand if the repository is public *and*
people do organize their checkins in a sorted manner, than using a SCM
can be fine too.

Anyway, as a side note on this thread: *darcs is just far t
slow* for decent maintenance of large pieces of software. I tried once
to create a mozilla repository, do some work with it and it was completely
unusable. I am not talking about minutes, but almost hours to finish
tasks that should take seconds.

 - Alexander

-- 
 GPG messages preferred.|  .''`.  ** Debian GNU/Linux **
 Alexander Sack | : :' :  The  universal
 [EMAIL PROTECTED]| `. `'  Operating System
 http://www.asoftsite.org/  |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Otavio Salvador]

Robert Collins <[EMAIL PROTECTED]> writes:

> bzr is also working on a high performance server at the moment, which
> will operate over either a socketpair - i.e. tunnelling via ssh (which
> can still be done without granting shell access), or over plain http via
> an apache rewrite rule.

Is it already working? How we can try?

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[Otavio Salvador]

Alexander Sack <[EMAIL PROTECTED]> writes:

> Anyway, as a side note on this thread: *darcs is just far t
> slow* for decent maintenance of large pieces of software. I tried once
> to create a mozilla repository, do some work with it and it was completely
> unusable. I am not talking about minutes, but almost hours to finish
> tasks that should take seconds.

It has improved a lot in last releases. You might redo your try.

:-D

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

thedebianuser.org started

[Wolfgang Lonien]

DDD (Dear Debian Developers),

two days ago, I started a new community project - mostly a blog page
until now - called "thedebianuser.org".

I kindly invite all of you to contribute, or send comments, critics,
whatever.

The "official" announcement is on LXer, because I promised them since
long to write a "Feature" there - so you can read about it at:

http://lxer.com/module/newswire/view/66474/index.html

Those (few) of you who know me: you know that since long I'm trying to
contribute *without* being a DD (yet?) - I helped Wouter with the booth
at this year's FOSDEM, spoke at this year's Debian Day at Linuxtag,
report errors, all that kind of stuff. Now opening a domain like that
should be just another way to contribute and to help spreading and
promoting Debian.

To all the others, who don't know me (yet):

I'm really grateful for your work and efforts, even for something you
write in your blogs and which is aggregated on the planet. I said so at
Linuxtag, and I will keep saying it - so thanks a lot.

(A small sidenote perhaps: while short *before* Linuxtag, I read
somewhere on your blogs or on debian.org (forgot): "We have to listen
and react more to the users", there was no DD in the room during my
talk, interestingly;)

I hope that some of you find the time to contribute, or to read the
user's planet as soon as I setup one.

Thanks again,
and kind regards,
wjl aka Wolfgang Lonien

- Please CC me in case of answers. Thanks -

-- 
cheers,
+---+
|   wjl aka Wolfgang Lonien   |   GPG key: 728D9BD0 |
|-|   Fingerprint:  |
|   Mail: |   a923 2294 b7ed eb3e 2f18  |
|   wolfgang - at - lonien.de |   ae56 aab8 d36a 728d 9bd0  |
+---+


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Thu, 2006-08-03 at 08:27 -0300, Otavio Salvador wrote:
> Robert Collins <[EMAIL PROTECTED]> writes:
> 
> > bzr is also working on a high performance server at the moment, which
> > will operate over either a socketpair - i.e. tunnelling via ssh (which
> > can still be done without granting shell access), or over plain http via
> > an apache rewrite rule.
> 
> Is it already working? How we can try?

typo - I meant 'bzr developers are also'...

Its partially functional at this point - we have it passing all the
transport selftests, which means it can be used [by the brave!] as an
alternative to sftp for read-write access, but it no faster. The
higher-level semantic operations are coming along nicely - we hope to
have it in 0.10 due out 4th september.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Centralized darcs

[Frank Küster]

Otavio Salvador <[EMAIL PROTECTED]> wrote:

> Alexander Sack <[EMAIL PROTECTED]> writes:
>
>> Anyway, as a side note on this thread: *darcs is just far t
>> slow* for decent maintenance of large pieces of software. I tried once
>> to create a mozilla repository, do some work with it and it was completely
>> unusable. I am not talking about minutes, but almost hours to finish
>> tasks that should take seconds.
>
> It has improved a lot in last releases. You might redo your try.

Would it be usable for a source tree of a size where dpatch usage
becomes a pain?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Otavio Salvador]

Robert Collins <[EMAIL PROTECTED]> writes:

> On Thu, 2006-08-03 at 08:27 -0300, Otavio Salvador wrote:
>> Robert Collins <[EMAIL PROTECTED]> writes:
>> 
>> > bzr is also working on a high performance server at the moment, which
>> > will operate over either a socketpair - i.e. tunnelling via ssh (which
>> > can still be done without granting shell access), or over plain http via
>> > an apache rewrite rule.
>> 
>> Is it already working? How we can try?
>
> typo - I meant 'bzr developers are also'...
>
> Its partially functional at this point - we have it passing all the
> transport selftests, which means it can be used [by the brave!] as an
> alternative to sftp for read-write access, but it no faster. The
> higher-level semantic operations are coming along nicely - we hope to
> have it in 0.10 due out 4th september.

Great!

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions

[Christian Garbs]

On Thu, Aug 03, 2006 at 12:08:48AM +0200, Josselin Mouette wrote:
> Le mercredi 02 août 2006 à 23:15 +0200, Bart Martens a écrit :
> >  Instead of editing the scripts in /etc/init.d to give daemons the
> >  nicelevel you want (and get prompted at every package update because
> >  these files are conffiles) you can just run reniced once a day.
 
> Out of curiosity, what real-life uses does this tool have? Daemons
> don't need to be reniced, so there must be something else.

Why don't daemons need to be reniced?

I have a rather "slow" system here (Cyrix 100MHz, 64MB RAM) that runs
some server processes like exim, inn2, spamassassin etc.  News for
example is no realtime application so I want my inn2 to run with a
certain nice value.

I don't know of an INN configuration value that sets this level.  So
my first approach was to edit /etc/init.d/inn2 and insert a
"renice 5 $$" somewhere in the script.  This makes updates a hassle
because I've edited a configuration file.

On the other hand, I've got a remote MP3-player that is powered by a
server process "slimserver" which runs under my user account.  To
avoid skips I like to run it with a negative nice value.  I'd need
root priviledges to set these values so I'd have to run a wrapper
using sudo or something.


To address both of these scenarios I've written reniced.  It runs
daily, has the needed root priviledges and does everything as needed.
I've attached my current configuration to this mail, perhaps this
gives you an idea what I'm up to :-)


The best solution IMHO would be to add an optional nice value to
/etc/default/ and let this be used in every script in
/etc/init.d.  I think some packages already do this, but changing
every package would need some work (I don't know if this feature
is needed by someone else besides me).

Regards,
Christian
-- 
Christian.Garbs.http://www.cgarbs.de

The purpose of computing is insight, not numbers.  (R.W. Hamming)
...but for the student, numbers are often the  
best road to insight.  (A. Ralston)
# against SLIM hickups
-7 ^slimserver.pl
-3 ^mDNSResponderPo

# high prio network services
0 ^apache
0 ^cannaserver
0 ^dictd
0 ^dhcpd
0 ^dnscache
0 ^lockd
0 ^mysqld
0 ^nfsd
0 ^ntpd
0 ^openvpn
0 ^portmap
0 ^powermust
0 ^ppp
0 ^rpc.
#0 ^slimserver.pl
0 ^sshd
0 ^syslogd
0 ^tinydns
0 ^ups
0 ^wdm
0 ^xfs

# medium prio network services
5 ^cupsd
5 ^inn$
5 ^japana
5 ^logger
#5 ^mDNSResponderPo
5 ^multilog
8 ^sslwrap
8 ^stunnel
5 ^twistd

# low prio network services
15 ^amavisd-new
15 ^clamd
15 ^controlchan
15 ^exim4
15 ^freshclam
15 ^innwatch
15 ^mailman
12 ^nmbd
15 ^popa3d
15 ^rc.news
12 ^smbd
15 ^spamd
12 ^supervise
12 ^svscan

# long running user processes
8 ^btlaunch
8 ^rtorrent
3 ^irssi


signature.asc
Description: Digital signature

Re: Centralized darcs

[John Goerzen]

On Thu, Aug 03, 2006 at 08:37:10AM +0200, Eduard Bloch wrote:
> #include 
> * John Goerzen [Wed, Aug 02 2006, 04:12:50PM]:
> 
> > Because everyone knows how to use cp and diff, and because I get diffs
> > sent to the BTS all the time.  It works.  And it has nothing to do with
> > VCS -- it's just Debian packages.
> 
> Bingo. Therefore, your efforts to use the regular process as an argument
> supporting darcs' patch management are pointless.

What?  Are you trying to just be a troll here?

I am saying that:

 * For the MAINTAINER, a single diff.gz is often not the most
   convenient.

 * I believe that ANY VCS is a better solution to this than ANY
   custom patch solution.

 * No matter which VCS you use, third parties (NMUers, etc)
   don't have to learn it -- they can use standard Debian tools.

 * No matter which custom patching solution you use, third parties
   DO have to learn it before they can start hacking on your code.

 * Darcs has certain advantages over other VCS.

If *I* use Darcs instead of a patching tool, then if Joe Random Hacker
wants to NMU my package, *HE* doesn't have to learn a thing.  Plus I get
all the benefits of patch management and history with more features than
any patching tool.

If *I* use Darcs, then EVERYONE ELSE can use the regular process.

If *I* use a patching tool, then EVERYONE ELSE IS FORCED TO ALSO.

Clear now?

> > > And if the user has more than one patch which needs to be maintained
> > > separately, is it still is still trivial FOR HIM? (or her)
> > 
> > Who is the user?
> 
> A system admin adding 3-5 extra patches to his local package
> installation?

How does this bolster your case?  The local sysadmin has the potential
to need to learn 3-5 patching tools in this case.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[John Goerzen]

On Thu, Aug 03, 2006 at 08:09:44AM +0200, Mike Hommey wrote:
> Well if someone has to work on a "which of the applied patch broken
> the package is such a way" kinda issue, he will have to, in order to
> have access to the patches.

No, they are all in the diff.gz, and that's easy enough to find.

> dpatch, quilt and others, in this case, make life easier (especially for
> security support).

As someone that has on occasion had the opportunity to NMU others'
packages, I really disagree with that.  Plus we've had someone in here
from the QA team that agrees with my position on this.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[John Goerzen]

On Thu, Aug 03, 2006 at 03:13:30PM +0200, Frank Küster wrote:
> Otavio Salvador <[EMAIL PROTECTED]> wrote:
> 
> > Alexander Sack <[EMAIL PROTECTED]> writes:
> >
> >> Anyway, as a side note on this thread: *darcs is just far t
> >> slow* for decent maintenance of large pieces of software. I tried once
> >> to create a mozilla repository, do some work with it and it was completely
> >> unusable. I am not talking about minutes, but almost hours to finish
> >> tasks that should take seconds.
> >
> > It has improved a lot in last releases. You might redo your try.
> 
> Would it be usable for a source tree of a size where dpatch usage
> becomes a pain?

I've used it with both the Linux kernel tree and Asterisk with good
results.

-- John

Re: Centralized darcs

[Peter Van Eynde]

Alle Thursday 03 August 2006 13:42, Otavio Salvador ha scritto:
> Alexander Sack <[EMAIL PROTECTED]> writes:
> 
> > Anyway, as a side note on this thread: *darcs is just far t
> > slow* for decent maintenance of large pieces of software. I tried once
> > to create a mozilla repository, do some work with it and it was completely
> > unusable. I am not talking about minutes, but almost hours to finish
> > tasks that should take seconds.
> 
> It has improved a lot in last releases. You might redo your try.

As a recent post of mine to darcs-devel [1] shows it seems to be going well 
for a while and then after a few upstream releases it just breaks down.

Hints for solving this mess would be appreciated, I'm investigating bzr at the 
moment, but tailor doesn't seem to like it all that much either seeing all 
the errors I get.

Groetjes, Peter

1: http://article.gmane.org/gmane.comp.version-control.darcs.user/10145
 never mind my idiotic duplicate.

-- 
signature -at- pvaneynd.mailworks.org 
http://www.livejournal.com/users/pvaneynd/
"God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[John Goerzen]

On Thu, Aug 03, 2006 at 09:15:05AM +0300, George Danchev wrote:
> The very same "debian patch manager" clearly identifies patches you've 
> produced against a certain upstream version and if I want to see the text of 
> your diffs altering src/file.c|h|whatever, not just a mere changelog entry, I 
> must track your SCM repo and its logs (learning a debian patch manager is 

No, you must just: zcat packagename-blah.diff.gz | less

> certainly easier as compared to any SCM and there are certainly more SCM out 
> there than debian patch managers). Why do I need to track your changes to the 
> upstream code ? Probably because I want to be sure that you haven't added any 
> offending changes or any other defects to the upstream source code when 
> upstream claims that their branch is working properly. Now you want to kill 

And the Debian diff will show you that.

> that important information from the debian source package itself and make 
> like of people even harded to find out your SCM, learn to use it and track 
> down the changes made to the upstream branch. I don't find that very 
> impresive, and I think Security Team will not be impressed too.

Why don't you stop speculating about what they think and just ask them
for their opinion?

Someone from the QA team already offered an opinion, and it wasn't
yours.

> > They don't have to know anything about the SCM to manipulate a monolithic
> > diff.gz package.  This is in contrast to a "patch-managed" package, where
> > you *MUST* learn the patch management system to make a minimal, useful NMU
> > patch.
> 
> Seems like you don't consider clearly identified patches prepared against a 
> given upstream version important, and (as you said in a previous message) a 
> mere changelog entries should be enough for you. This is just a very 
> interesting way of tracking changes ;-)

No patch management system that I've seen tracks changes.  It shows the
current patches against upstream, not history for all time.  This is a
feature you get ONLY with a VCS, or manually by using
shapshot.debian.net.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions

[Christian Garbs]

Wesley J. Landaker wrote:

> Wow, that sounds like an annoying bug just waiting to get reported!
> (Having to edit scripts in /etc/init.d is an exceptionally bad way
> to configure a daemon.)

This is about daemons that are not designed to be configured in that
way.  The "easiest" solution was to just add a line to the /etc/init.d
script.

A better way would be to add a nice configuration value to either
every daemon (lots of work upstream) or at least to the init scripts
(still lots of work, but start-stop-daemon already has an --nicelevel
option).

But I did not want to run wild and add wishlist bugs against every
package, so I wrote reniced instead.

Regards,
Christian
-- 
Christian.Garbs.http://www.cgarbs.de

And that one shall come to you garbed in raiment of
blue, descending upon a field of gold to forge anew
our ties with the lost land. (Nausicaä)


signature.asc
Description: Digital signature

Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions

[Christian Garbs]

martin f krafft wrote:
>also sprach Josselin Mouette <[EMAIL PROTECTED]> [2006.08.02.2308 +0100]:

>> Out of curiosity, what real-life uses does this tool have? Daemons
>> don't need to be reniced, so there must be something else.

> reniced /(g(cc|++)|c(c|++))/ 15

> or whatever the syntax is. I often wanted to have such a feature on
> public machines.

Sorry, but this does not work.

reniced does not wait for new processes to act on them.  It is
designed to be run once a day and affect the processes running in that
moment.

Basically it's something like "ps | grep | renice" - this works only
with long running processes.  Interactive commands are not the
intended targets.

Regards,
Christian
-- 
Christian.Garbs.http://www.cgarbs.de

"There are three kinds of lies: lies, politics and statistics."
  - known source


signature.asc
Description: Digital signature

Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions

[martin f krafft]

also sprach Christian Garbs <[EMAIL PROTECTED]> [2006.08.03.1436 +0100]:
> reniced does not wait for new processes to act on them.  It is
> designed to be run once a day and affect the processes running in
> that moment.

Then don't call it renice*d*, please.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"heuristic is computer science jargon for 'doesn't actually work.'"
 -- charlie reiman


signature.asc
Description: Digital signature (GPG/PGP)

Re: Centralized darcs

[Otavio Salvador]

Frank Küster <[EMAIL PROTECTED]> writes:

> Otavio Salvador <[EMAIL PROTECTED]> wrote:
>
>> Alexander Sack <[EMAIL PROTECTED]> writes:
>>
>>> Anyway, as a side note on this thread: *darcs is just far t
>>> slow* for decent maintenance of large pieces of software. I tried once
>>> to create a mozilla repository, do some work with it and it was completely
>>> unusable. I am not talking about minutes, but almost hours to finish
>>> tasks that should take seconds.
>>
>> It has improved a lot in last releases. You might redo your try.
>
> Would it be usable for a source tree of a size where dpatch usage
> becomes a pain?

It depends of what means by usable and the size that you think it'll
happen ;-)

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: Centralized darcs

[Jon Dowland]

At 1154609291 past the epoch, Shot (Piotr Szotkowski) wrote:


I use something similar, but I generate procmailrc and
muttrc snippets from a master file of mailing lists using m4
and some scripts.

-- 
Jon Dowland
http://alcopop.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions

[Otavio Salvador]

martin f krafft <[EMAIL PROTECTED]> writes:

> also sprach Christian Garbs <[EMAIL PROTECTED]> [2006.08.03.1436 +0100]:
>> reniced does not wait for new processes to act on them.  It is
>> designed to be run once a day and affect the processes running in
>> that moment.
>
> Then don't call it renice*d*, please.

Maybe renice-daily ;-)

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[Alexander Sack]

On Thu, Aug 03, 2006 at 08:32:28AM -0500, John Goerzen wrote:
> On Thu, Aug 03, 2006 at 08:09:44AM +0200, Mike Hommey wrote:
> > Well if someone has to work on a "which of the applied patch broken
> > the package is such a way" kinda issue, he will have to, in order to
> > have access to the patches.
> 
> No, they are all in the diff.gz, and that's easy enough to find.
> 

The total of changes is in the  diff.gz, but obviously in a combined 
fashion. That is: if you have applied multiple patches for different
issues on the same file, how will you extract a certain patch from
that  impossible.

So, as a matter of fact, in diff.gz you loose information that you can
keep in separately shipped patches. Just having the diff.gz can
be a major PITA for security maintenance ... for instance, if you try
to track down a regression that you know nothing about other than that
it appeared somewhere between now and the beginning of life. 

 - Alexander

-- 
 GPG messages preferred.|  .''`.  ** Debian GNU/Linux **
 Alexander Sack | : :' :  The  universal
 [EMAIL PROTECTED]| `. `'  Operating System
 http://www.asoftsite.org/  |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions

[Roberto C. Sanchez]

On Thu, Aug 03, 2006 at 02:52:50PM +0100, martin f krafft wrote:
> also sprach Christian Garbs <[EMAIL PROTECTED]> [2006.08.03.1436 +0100]:
> > reniced does not wait for new processes to act on them.  It is
> > designed to be run once a day and affect the processes running in
> > that moment.
> 
> Then don't call it renice*d*, please.
> 
Agreed, the name makes me think that it is a daemon that monitors for
new processes starting up and *then* renices the processes based on the
provided regex.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: Digital signature

Re: Centralized darcs

[Jon Dowland]

At 1154593998 past the epoch, Eduard Bloch wrote:
> And you can do all that with dpatch-edit-dpatch and the
> regular Unix commands without learning another VCS and/or
> without needing access to it. Advantage? Yes.

Someone is more likely to know a particular VCS than an
in-house tool like dpatch, I reckon, and that skillset is
going to be more useful and applicable in other contexts as
well.

-- 
Jon Dowland
http://alcopop.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: thedebianuser.org started

[Joseph Smidt]

Wolfgang,
  I think that is a great idea.  You should make a post on
forums.debian.net to since that is another place many of the community
hang out.  That's just my two cents.


Joseph Smidt

-- 

Joseph Smidt
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: thedebianuser.org started

[Steve Kemp]

On Thu, Aug 03, 2006 at 08:26:57AM -0600, Joseph Smidt wrote:
> Wolfgang,
>   I think that is a great idea.  You should make a post on
> forums.debian.net to since that is another place many of the community
> hang out.  That's just my two cents.

  Seconded.  I put a simple advert on Debian-Administration which 
 you can follow here:

http://www.debian-administration.org/adverts/47

  If people wish to advertise other sites of interest to Debian users
 on my site then feel free to submit them here:

http://www.debian-administration.org/create/advert

  (Adverts are free, and are only vetted to ensure they *do* go
 to Debian-friendly sites.)

Steve
-- 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[Matthew R. Dempsky]

On Thu, Aug 03, 2006 at 01:27:45PM +0300, Lars Wirzenius wrote:
> My point was that having to tell mutt manually about every mailing list
> is a pain, and people don't do it.

I do.

> The List- headers are sufficient, in my experience, to automate this.

They don't support following up to cross-posted messages.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions

[Matthew R. Dempsky]

On Wed, Aug 02, 2006 at 11:26:24PM +0100, martin f krafft wrote:
> reniced /(g(cc|++)|c(c|++))/ 15

How about ``pgrep '(g(cc|\+\+)|c(c|\+\+))' | xargs renice 15''?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: thedebianuser.org started

[Wolfgang Lonien]

Steve Kemp wrote:
> On Thu, Aug 03, 2006 at 08:26:57AM -0600, Joseph Smidt wrote:
>>Wolfgang,
>>  I think that is a great idea.  You should make a post on
>>forums.debian.net to since that is another place many of the community
>>hang out.  That's just my two cents.
>   Seconded.  I put a simple advert on Debian-Administration which 
>  you can follow here:

Thanks, Joseph and Steve,

I feel honoured to get reactions like these, and even contributions and
ads from guys like you.

I have just added links to the forums, and to the new "Debian Times".

-- 
cheers,
+---+
|   wjl aka Wolfgang Lonien   |   GPG key: 728D9BD0 |
|-|   Fingerprint:  |
|   Mail: |   a923 2294 b7ed eb3e 2f18  |
|   wolfgang - at - lonien.de |   ae56 aab8 d36a 728d 9bd0  |
+---+


signature.asc
Description: OpenPGP digital signature

Code of Conduct on the Debian mailinglists

[Wouter Verhelst]

On Thu, Aug 03, 2006 at 10:20:26AM +0200, Thijs Kinkhorst wrote:
> On Wed, 2006-08-02 at 15:34 -0500, John Goerzen wrote:
> > 
> > > Ok, third time. Please do not do that:
> > > To: George Danchev <[EMAIL PROTECTED]>
> > > CC: debian-devel@lists.debian.org
> > 
> > Then SET YOUR HEADERS to reflect that, like everyone else does. 
> 
> So you're shouting to people to use non-standard and not generally
> implemented headers to in order to have you comply with the mailinglist
> code of conduct?

You know, I use a mail program. Replying to people is in my fingers as
"hitting a button". A very specific button, especially for that purpose.
I expect my MUA to Do The Right Thing (TM). It usually does, except on
the Debian mailinglists, where people start whining to me about some
silly CoC.

Personally, I happen to think that our current CoC is flawed, mostly in
this respect.

A good Code of Conduct, in my opinion, should be written so as to
*reduce* the amount of flamage on the list and should try to improve the
general atmosphere.

However, IME, the only reason why the CoC is ever pointed to is to tell
people that they are breaking the CoC and that they should learn to
respect the rules and that they should not Cc people and that they
should learn to configure their mail client. Goddammit.

Guess what that will have of an effect on the atmosphere and on the
general level of flamage?

Personally, I think that if you have very specific ideas about how
someone should (or should not) send you any Cc's, that your MUA should
just DTRT. And/or that you should have some procmail bit to just throw
away any duplicates you get, if you think that is a problemat. Other
than that, what the hell?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: thedebianuser.org started

[Eduard Bloch]

#include 
* Joseph Smidt [Thu, Aug 03 2006, 08:26:57AM]:
> Wolfgang,
>   I think that is a great idea.  You should make a post on
> forums.debian.net to since that is another place many of the community
> hang out.  That's just my two cents.

Why don't you create a web ring and place banners everywhere? (seriously)

Eduard.
-- 
Eine schlechte Sache erregt, eine gute verträgt viel Kritik.
-- Charles Tschopp


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions

[Peter Palfrader]

On Thu, 03 Aug 2006, Josselin Mouette wrote:

> Le mercredi 02 août 2006 à 23:15 +0200, Bart Martens a écrit :
> >  Instead of editing the scripts in /etc/init.d to give daemons the
> >  nicelevel you want (and get prompted at every package update because
> >  these files are conffiles) you can just run reniced once a day.
> 
> Out of curiosity, what real-life uses does this tool have? Daemons don't
> need to be reniced, so there must be something else.

I use and, the auto nice daemon for this purpose on my compute servers,
renicing users' jobs that run longer than an hour, longer than a day,
longer than week respectively.  The idea is that while a process is
still young it should get more CPU in order to get better response
times.

Cheers,
Peter
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/

Re: Code of Conduct on the Debian mailinglists

[Thijs Kinkhorst]

On Thu, 2006-08-03 at 20:30 +0200, Wouter Verhelst wrote:
> On Thu, Aug 03, 2006 at 10:20:26AM +0200, Thijs Kinkhorst wrote:
> > On Wed, 2006-08-02 at 15:34 -0500, John Goerzen wrote:
> > > 
> > > > Ok, third time. Please do not do that:
> > > > To: George Danchev <[EMAIL PROTECTED]>
> > > > CC: debian-devel@lists.debian.org
> > > 
> > > Then SET YOUR HEADERS to reflect that, like everyone else does. 
> > 
> > So you're shouting to people to use non-standard and not generally
> > implemented headers to in order to have you comply with the mailinglist
> > code of conduct?
> 
> You know, I use a mail program. Replying to people is in my fingers as
> "hitting a button". A very specific button, especially for that purpose.
> I expect my MUA to Do The Right Thing (TM). It usually does, except on
> the Debian mailinglists, where people start whining to me about some
> silly CoC.

If your mailer makes you automatically go shouting on the push of a
button, it may be time to download the source and get some serious
hacking done.

You won't see me making a fuss out of someone who sends someone else a
CC when that was undesired. However, some mailinglist poster has clearly
indicated for a couple of times already that he rather does not have
that, so he appearently thinks that's important. I find it to be common
courtesy if someone makes an explicit request, and stresses that request
once more, to honour that request when reasonably possible. It doesn't
cost me anything significant, does it?

The person I was replying to chooses to ignore the request of the OP and
even meets his request with hostility (shouting). Then in my opinion
you've reached the limit of acceptable behaviour on this mailinglist.


Thijs


signature.asc
Description: This is a digitally signed message part

Re: thedebianuser.org started

[Steve Kemp]

On Thu, Aug 03, 2006 at 08:26:41PM +0200, Eduard Bloch wrote:

> Why don't you create a web ring and place banners everywhere? (seriously)

  There is a "promote debian" ring already:

http://spreaddebian.com/

  I like to see related sites linking to each other, and I
 like to see friendly cooperation and communication between
 Debian-community sites maintainers/users.

  That is something which I think does exist currently.
 I've heard from/chatted to several site-maintainers and
 everybody seems very keen on promoting resources for the
 benefit of the *users* rather than the site-owners.
 (Only one minor exception.)

  But having said that I'm not personally a fan of web-rings.

  Mostly because you have no control over the quality of the
 other sites which join.  By having a lot of big sites join
 you're implicitly endorsing the ring and the other members of
 that ring, sight-unseen.  If I want to endorse a site I want
 to do so knowingly.

  Still I think there are probably valuable Debian-friendly, or
 Debian-community sites/pages which could do with more promotion
 and recognition.  I guess the Debian wiki is a good starting point:

http://wiki.debian.org/DebianResources

Steve
-- 


signature.asc
Description: Digital signature

Re: Two versions of pan in etch?

[Yavor Doganov]

David Weinehall wrote:
> 
> Is the new version of pan able to migrate the information from the
> old version yet?

No, and it won't be until somebody writes the code.  Charles Kerr (the
upstream author) said that he's not going to do it as it's non-trivial
and fairly difficult.  I understand him, and I suffer as well as I'm
subscribbed to a gazillion groups.

> If it does support this now (or if you could at least add a postinst
> script that does the migration), then I'm all for a switch to the
> new version.

I guess this (important, indeed) feature is irrelevant to the
question.  You'll hit the migration issue anyway.

As a devoted Pan user, I'd like the new Pan in Etch, but since the
code is changing very rapidly and is not yet mature, I think it's not
a wise choice.  Having the old and the new Pan together is
over-projecting and not worth it, IMHO.

OTOH, I really hope that upstream will release a stable version before
freeze time.

-- 
In the GNU Project, discrimination against proprietary software is not
just a policy -- it's the principle and the purpose.  Proprietary
software is fundamentally unjust and wrong, so when we have the
opportunity to place it at a disadvantage, that is a good thing. --RMS


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Code of Conduct on the Debian mailinglists

[John Goerzen]

On Thu, Aug 03, 2006 at 10:24:10PM +0200, Thijs Kinkhorst wrote:
> > You know, I use a mail program. Replying to people is in my fingers as
> > "hitting a button". A very specific button, especially for that purpose.
> > I expect my MUA to Do The Right Thing (TM). It usually does, except on
> > the Debian mailinglists, where people start whining to me about some
> > silly CoC.
> 
> If your mailer makes you automatically go shouting on the push of a
> button, it may be time to download the source and get some serious
> hacking done.

The mailer is doing the right thing.  Sending a CC isn't a "shout".

The sender isn't.  If the sender doesn't want CCs, it's fully within the
sender's power to specify that in the list headers.  Most senders on
this list that don't want CCs do that.

I am on dozens of mailing lists.  There are thousands of participants on
this list alone.  I subscribe to, and leave, mailing lists all the time.
Why should a person with a personal preference expect me to shoulder the
burden of maintaining a mental list of that, when it's within his power
to express his preference in a way that mail readers understand
automatically?

The same goes for the Debian CoC.  I agree with Wouter on this.  The CoC
is at odds with the desires expressed in the mail headers.

Reply-To has been around since at least RFC822 (1982), and the person
that wants to avoid personal CCs could use it.  It is standard and it is
widely supported.

There are, of course, problems with it.  Mail-Followup-To is also a
defacto standard (note that RFC is not the only way for a standard to
occur; HTML, for instance, was a standard long before it got an RFC).
Many mail clients do the right thing when they see it, and that is
especially true here.

If the person with the complaint had used this, he would have been fine.

Remember the old FidoNet mantra?  "Don't be excessively annoying, and
don't be easily annoyed."  If he was bothered so much by the CCs, he
should have added the Mail-Followup-To header to his messages rather
than getting excessively annoyed about it.

It's a personal preference thing, and since it is trivially accomodated
on his end, why should thousands of people try to remember that this
person on this list doesn't want CC's?

> The person I was replying to chooses to ignore the request of the OP and
> even meets his request with hostility (shouting). Then in my opinion
> you've reached the limit of acceptable behaviour on this mailinglist.

I did not *choose to ignore* it.  I didn't even see it until his latest
message, and I meant not to CC him there but accidentally did anyway due
to force of habit.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Code of Conduct on the Debian mailinglists

[George Danchev]

On Friday 04 August 2006 00:37, John Goerzen wrote:
> On Thu, Aug 03, 2006 at 10:24:10PM +0200, Thijs Kinkhorst wrote:
> > > You know, I use a mail program. Replying to people is in my fingers as
> > > "hitting a button". A very specific button, especially for that
> > > purpose. I expect my MUA to Do The Right Thing (TM). It usually does,
> > > except on the Debian mailinglists, where people start whining to me
> > > about some silly CoC.
> >
> > If your mailer makes you automatically go shouting on the push of a
> > button, it may be time to download the source and get some serious
> > hacking done.
>
> The mailer is doing the right thing.  Sending a CC isn't a "shout".

Obviously he was pointing your caps... how do you feel that...

> The sender isn't.  If the sender doesn't want CCs, it's fully within the
> sender's power to specify that in the list headers.  Most senders on
> this list that don't want CCs do that.
>
> I am on dozens of mailing lists.  There are thousands of participants on
> this list alone.  I subscribe to, and leave, mailing lists all the time.
> Why should a person with a personal preference expect me to shoulder the
> burden of maintaining a mental list of that, when it's within his power
> to express his preference in a way that mail readers understand
> automatically?
>
> The same goes for the Debian CoC.  I agree with Wouter on this.  The CoC
> is at odds with the desires expressed in the mail headers.

You can CC despite headers set by the other parties, therefore the current CoC 
is fine wrt 'do not CC to people subscribed', though it could be updated with 
Reply-To and Mail-Followup-To if you think it is currently being odd.

> Reply-To has been around since at least RFC822 (1982), and the person
> that wants to avoid personal CCs could use it.  It is standard and it is
> widely supported.
>
> There are, of course, problems with it.  Mail-Followup-To is also a
> defacto standard (note that RFC is not the only way for a standard to
> occur; HTML, for instance, was a standard long before it got an RFC).
> Many mail clients do the right thing when they see it, and that is
> especially true here.
>
> If the person with the complaint had used this, he would have been fine.

OK, fine, point taken.

> Remember the old FidoNet mantra?  "Don't be excessively annoying, and
> don't be easily annoyed."  If he was bothered so much by the CCs, he
> should have added the Mail-Followup-To header to his messages rather
> than getting excessively annoyed about it.

My 'excessive annoyance' is your assumption. I just wrote 'Please, ...' 
nothing more, so do not accept that as any sort of annoyance or flamage.

> It's a personal preference thing, and since it is trivially accomodated
> on his end, why should thousands of people try to remember that this
> person on this list doesn't want CC's?
>
> > The person I was replying to chooses to ignore the request of the OP and
> > even meets his request with hostility (shouting). Then in my opinion
> > you've reached the limit of acceptable behaviour on this mailinglist.
>
> I did not *choose to ignore* it.  I didn't even see it until his latest
> message, and I meant not to CC him there but accidentally did anyway due
> to force of habit.

Ok, that's fine, minor communication disturbance happend and should no more be 
an issue.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centralized darcs

[Eduard Bloch]

#include 
* John Goerzen [Thu, Aug 03 2006, 08:29:33AM]:
> On Thu, Aug 03, 2006 at 08:37:10AM +0200, Eduard Bloch wrote:
> > #include 
> > * John Goerzen [Wed, Aug 02 2006, 04:12:50PM]:
> > 
> > > Because everyone knows how to use cp and diff, and because I get diffs
> > > sent to the BTS all the time.  It works.  And it has nothing to do with
> > > VCS -- it's just Debian packages.
> > 
> > Bingo. Therefore, your efforts to use the regular process as an argument
> > supporting darcs' patch management are pointless.
> 
> What?  Are you trying to just be a troll here?
> 
> I am saying that:
> 
>  * For the MAINTAINER, a single diff.gz is often not the most
>convenient.

Really? For me, it sounded like having a single diff.gz is ok for
everyone and patch management should be done in the VCS.

>  * I believe that ANY VCS is a better solution to this than ANY
>custom patch solution.

Believes are not proofs, sorry. They are hypotheses based on subjective
ground.

> If *I* use Darcs instead of a patching tool, then if Joe Random Hacker
> wants to NMU my package, *HE* doesn't have to learn a thing.  Plus I get
> all the benefits of patch management and history with more features than
> any patching tool.
> 
> If *I* use Darcs, then EVERYONE ELSE can use the regular process.
> 
> If *I* use a patching tool, then EVERYONE ELSE IS FORCED TO ALSO.
> 
> Clear now?

??

It has been clear before. There are just too many null-arguments blowing
up this discussion.

> > > > And if the user has more than one patch which needs to be maintained
> > > > separately, is it still is still trivial FOR HIM? (or her)
> > > 
> > > Who is the user?
> > 
> > A system admin adding 3-5 extra patches to his local package
> > installation?
> 
> How does this bolster your case?  The local sysadmin has the potential
> to need to learn 3-5 patching tools in this case.

One can easily add those modifications. In different atoms (patches).
One can update those atoms with newer versions from 3rd party sources.
Without having to deal with maintainer's VCS or setup a custom one.

Eduard.

-- 
Der Haß ist ein aktives Mißvergnügen, der Neid ein passives, deshalb
darf man sich nicht wundern, wenn der Neid so schnell in Haß übergeht.
-- Johann Wolfgang von Goethe


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Brian May]

> "Adeodato" == Adeodato  <"=?utf-8?B?U2ltw7M=?=" <[EMAIL PROTECTED]>> 
> writes:

Adeodato> But if you have a set of equal developers, bzr can be
Adeodato> also used in a very similar way to Subversion, where all
Adeodato> commits go to a central repository, and nobody has to
Adeodato> collect them. It's just a matter of setting up a
Adeodato> directory somewhere with the appropriate write
Adeodato> permissions, and say "This is our canonical archive, the
Adeodato> uploader will include what it's in there, nothing more,
Adeodato> nothing less".

For documentation on checkouts and bound branches, see

http://bazaar-vcs.org/CheckoutTutorial

http://bazaar-vcs.org/BzrUsingBoundBranches

However, I am not convinced the following paragraph in the first
page is correct:

"Getting a checkout is generally faster than making a copy of a
branch. The catch though is that whenever the checkout needs to look
at the RCS data it will do so by accessing the branch. This holds true
even if the branch is on some distant network that you accessed over
the internet."

To me, this sounds like it might be talking about a "lightweight
checkout", as I believe a checkout is a complete copy of the branch,
and network access is only required for commits or updates. "Bound
branches in bzr take the place of remote 'checkouts' in systems like
CVS or SVN and we refer to them as 'checkouts'. (bzr also supports
"lightweight checkouts", which are like local checkouts, and aren't
branches at all.)"

Can anyone confirm/deny?


My central dislike of bzr is bugs like:

http://bugs.debian.org/380412
https://launchpad.net/products/bzr/+bug/54253

...which unfortunately makes it unusable for some of my applications.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Fri, 2006-08-04 at 09:56 +1000, Brian May wrote:


> For documentation on checkouts and bound branches, see
> 
> http://bazaar-vcs.org/CheckoutTutorial
> 
> http://bazaar-vcs.org/BzrUsingBoundBranches
> 
> However, I am not convinced the following paragraph in the first
> page is correct:
> 
> "Getting a checkout is generally faster than making a copy of a
> branch. The catch though is that whenever the checkout needs to look
> at the RCS data it will do so by accessing the branch. This holds true
> even if the branch is on some distant network that you accessed over
> the internet."

Yes, thats bogus. Getting a heavyweight checkout is identical to getting
a new branch. Getting a lightweight one *may* be cheaper, depending on
how much history is needed to reconstruct file versions.

> To me, this sounds like it might be talking about a "lightweight
> checkout", as I believe a checkout is a complete copy of the branch,
> and network access is only required for commits or updates. "Bound
> branches in bzr take the place of remote 'checkouts' in systems like
> CVS or SVN and we refer to them as 'checkouts'. (bzr also supports
> "lightweight checkouts", which are like local checkouts, and aren't
> branches at all.)"
>
> Can anyone confirm/deny?

A checkout --lightweight over the net is currently not a good thing to
do. When the smart server is released, that will be about the same
performance as traditional client-server vcs's like CVS or SVN. 

> 
> My central dislike of bzr is bugs like:
> 
> http://bugs.debian.org/380412
> https://launchpad.net/products/bzr/+bug/54253
> 
> ...which unfortunately makes it unusable for some of my applications.

Are you doing conversions from SVN? Current bzr uses 20MB of ram to do a
native branch operation in similar circumstances. (bug report gets
fixed, new at 11 :)). 

0.9RC1 is out, and 0.9 will be out Monday/Tuesdau. As soon as that lands
in debian the bug should be closed. 

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Code of Conduct on the Debian mailinglists

[John Goerzen]

On Fri, Aug 04, 2006 at 01:27:15AM +0300, George Danchev wrote:
> On Friday 04 August 2006 00:37, John Goerzen wrote:
> > > If your mailer makes you automatically go shouting on the push of a
> > > button, it may be time to download the source and get some serious
> > > hacking done.
> >
> > The mailer is doing the right thing.  Sending a CC isn't a "shout".
> 
> Obviously he was pointing your caps... how do you feel that...

Ah, I had forgotten about that.  Sorry,  I shouldn't have shouted there.

> You can CC despite headers set by the other parties, therefore the current 
> CoC 
> is fine wrt 'do not CC to people subscribed', though it could be updated with 
> Reply-To and Mail-Followup-To if you think it is currently being odd.

Yes, I think that would make a lot of sense.

-- John


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Code of Conduct on the Debian mailinglists

[Matthias Julius]

John Goerzen <[EMAIL PROTECTED]> writes:

> I am on dozens of mailing lists.  There are thousands of participants on
> this list alone.  I subscribe to, and leave, mailing lists all the time.
> Why should a person with a personal preference expect me to shoulder the
> burden of maintaining a mental list of that, when it's within his power
> to express his preference in a way that mail readers understand
> automatically?

On Debian lists the desire for no Ccs is not a personal preference but
it is the default.  Only if you want a Cc you should say so.  This is
what the CoC says.  If you don't agree with that - change it.  But
don't just ignore it.

Decent MUAs can be configured to send followups to the list only and
just Do The Right Thing.

>
> The same goes for the Debian CoC.  I agree with Wouter on this.  The CoC
> is at odds with the desires expressed in the mail headers.

In my view a missing mail header doesn't express any desire.

>
> Reply-To has been around since at least RFC822 (1982), and the person
> that wants to avoid personal CCs could use it.  It is standard and it is
> widely supported.

There are people who distinguish between followups and replies.  There
Reply-To is not a perfect solution either.

>
> There are, of course, problems with it.  Mail-Followup-To is also a
> defacto standard (note that RFC is not the only way for a standard to
> occur; HTML, for instance, was a standard long before it got an RFC).
> Many mail clients do the right thing when they see it, and that is
> especially true here.
>
> If the person with the complaint had used this, he would have been
> fine.

My MUA sets MFT but I still get a number of Ccs.  Fact is that MFT is
not implemented in every MUA or is disabled by default.

Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Code of Conduct on the Debian mailinglists

[Ben Finney]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> You know, I use a mail program. Replying to people is in my fingers
> as "hitting a button". A very specific button, especially for that
> purpose.  I expect my MUA to Do The Right Thing (TM).

Most MUAs will do the right thing when you reply; they'll send a
message to the single person who wrote the message. The person who
wrote the message can indicate where this single-person reply should
go, by specifying header fields such as 'From' and 'Reply-To'.

Many MUAs also have a separate specific facility, for replying to
*every* address related to the discussion. This is fine for a group of
individuals, but problematic for a mailing list, since one of those
addresses will be the mailing list address itself, and then some
people get two copies -- one individually (which usually arrives
first, since it has less processing time) and one from the mailing
list.

With mailing lists, there's a third kind of reply needed, a "followup"
to continue the discussion. This usually should be sent to the mailing
list address, and to people not on the mailing list but who want to
receive followup responses.

We can't use the mailing list address for this: that misses anyone
who's not subscribed but wants followup messages.

We can't use the Reply-To field in an existing message: that is
specifically for *individual* responses to the person posting the
message. This is completely wrong for followup messages intended for
all interested parties.

There *is* no header field recommended by the IETF that meets this
need. We use Mail-Followup-To because it actually meets the need
described above.

-- 
 \  "My interest is in the future, as I am going to spend the rest |
  `\   of my life there."  -- Charles F. Kettering |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Code of Conduct on the Debian mailinglists

[Magnus Holmgren]

On Thursday 03 August 2006 23:37, John Goerzen took the opportunity to say:
> The mailer is doing the right thing.  Sending a CC isn't a "shout".
>
> The sender isn't.  If the sender doesn't want CCs, it's fully within the
> sender's power to specify that in the list headers.  Most senders on
> this list that don't want CCs do that.
>
> I am on dozens of mailing lists.  There are thousands of participants on
> this list alone.  I subscribe to, and leave, mailing lists all the time.
> Why should a person with a personal preference expect me to shoulder the
> burden of maintaining a mental list of that, when it's within his power
> to express his preference in a way that mail readers understand
> automatically?
> 
> The same goes for the Debian CoC.  I agree with Wouter on this.  The CoC
> is at odds with the desires expressed in the mail headers.

In the absence of a stated preference in a machine-readable format, a default 
policy should be followed. The Debian mailing lists CoC says that you should 
only send followups to the list. How is this at odds with "the desires 
expressed in the mail headers", when no desire *is* expressed in the mail 
headers? No Reply-To or Mail-Followup-To at all is not expressing a desire to 
get a separate copy.

> Reply-To has been around since at least RFC822 (1982), and the person
> that wants to avoid personal CCs could use it.  It is standard and it is
> widely supported.

The problem with Reply-To is that there are two kinds of reply you can make to 
a list post: a list reply (follow up) and a private reply. It's not defined 
which kind of reply Reply-To applies to (that's the rationale behind 
Mail-Followup-To and Mail-Reply-To). One view is that Reply-To points to 
where the sender wants replies to go, without discussion. In that case you 
can't use it to say "I don't want copies of list mail, but it's OK to send 
private replies". I think it should only be interpreted in the context of 
private replies. In any case, if you set Reply-To to the list, many mailers 
will make it cumbersome to send private replies. That's one of the arguments 
against Reply-To mangling. That it collides with any Reply-To set by the 
sender is just another one.

> There are, of course, problems with it.  Mail-Followup-To is also a
> defacto standard (note that RFC is not the only way for a standard to
> occur; HTML, for instance, was a standard long before it got an RFC).
> Many mail clients do the right thing when they see it, and that is
> especially true here.
>
> If the person with the complaint had used this, he would have been fine.

Problem: With most mailers you can't readily do that. You'd have to use your 
own MTA or some hack to automatically add it. Not only geeks use mailing 
lists, so it's not a viable option. On the other hand, all mailers let you 
edit the recipient list (although admittedly it can become rather 
repetitive). But why don't you use the list-reply command that Mutt provides? 
It's bound to L by default, AFAICS.

Furthermore, all mailers involved in a thread have to know about 
Mail-Followup-To and preserve it, or things will break. Though you could say 
that it's a good policy to keep all the other recipients when replying.

In short, it's a mess. Lots of improvements can be made, to MUAs, MLMs, as 
well as MTAs. An RFC straightening things out could help.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpQQ7nWGwdKx.pgp
Description: PGP signature

Work-needing packages report for Aug 4, 2006

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 328 (new: 7)
Total number of packages offered up for adoption: 82 (new: 2)
Total number of packages requested help for: 24 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   44bsd-rdist (#380192), orphaned 6 days ago
 Description: 4.4BSD rdist.
 Installations reported by Popcon: 5

   august (#381207), orphaned yesterday
 Description: Tcl/Tk HTML editor
 Installations reported by Popcon: 38

   cipe (#381162), orphaned yesterday
 Description: lightweight encrypted IP tunnels over UDP
 Reverse Depends: pkcipe
 Installations reported by Popcon: 34

   dcc (#380542), orphaned 4 days ago
 Description: Distributed Checksum Clearinghouse
 Reverse Depends: dcc-client dcc-common dcc-milter dcc-server
 Installations reported by Popcon: 601

   gch (#380193), orphaned 6 days ago
 Description: Ada quality & style checker
 Installations reported by Popcon: 23

   gpdf (#380382), orphaned 5 days ago
 Description: Portable Document Format (PDF) viewer
 Reverse Depends: papaya
 Installations reported by Popcon: 2001

   pronto (#38), orphaned yesterday
 Description: highly modularized GTK+ mail client written in Perl
 Installations reported by Popcon: 17

321 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   galeon (#381028), offered 2 days ago
 Description: GNOME web browser for advanced users
 Reverse Depends: galeon gnome-desktop-environment mozilla-mplayer
   mozplugger sun-java5-plugin
 Installations reported by Popcon: 2556

   libmms (#381029), offered 2 days ago
 Description: MMS stream protocol library - development files
 Reverse Depends: gstreamer0.10-plugins-bad gstreamer0.8-mms
   libmms-dev mimms
 Installations reported by Popcon: 1174

80 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] mc (#380999), requested 2 days ago
 Description: midnight commander - a powerful file manager
 Reverse Depends: junior-system
 Installations reported by Popcon: 4247

   aboot (#315592), requested 406 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-server
 Installations reported by Popcon: 52

   apt-build (#365427), requested 96 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 435

   athcool (#278442), requested 646 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 226

   cvs (#354176), requested 161 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (16 more
   omitted)
 Installations reported by Popcon: 7275

   docbook (#358522), requested 134 days ago
 Description: standard SGML representation system for technical
   documents
 Reverse Depends: alcovebook-sgml docbook-dsssl docbook-to-man
   sgmltools-lite
 Installations reported by Popcon: 3295

   docbook-xml (#358520), requested 134 days ago
 Description: standard XML documentation system, for software and
   systems
 Reverse Depends: dblatex docbook-dsssl docbook-ebnf
   docbook-html-forms docbook-jrefentry docbook-mathml docbook-simple
   docbook-slides docbook-website docbook-xsl-stylesheets-ko (6 more
   omitted)
 Installations reported by Popcon: 8439

   dpkg (#282283), requested 621 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-src backuppc
   build-essential clamsmtp crosshurd cvs-autoreleasedeb
   cvs-buildpackage (82 more omitted)
 Installations reported by Popcon: 14037

   grub (#248397), requested 815 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild grub-splashimages grubconf replicator
 Installations reported by Popcon: 10746

   gtkpod (#319711), requested 375 days ago
 Description: manage songs and playlists on an Apple iPod
 Installations reported by Popcon: 374

   lirc (#364606), requested 101 days ago
 Description: Linux Infra-red Remote Control support
 Reverse Depends