Re: NMUs applying sleeping wishlist bugs about translation

[Anthony Towns]

On Wed, Aug 27, 2003 at 09:01:26PM -0500, Steve Langasek wrote:
> Quite.  But I believe that doing NMUs *does* improve the overall quality
> of Debian, and I believe that putting NMUers on the spot over bugs they
> didn't cause would be a sufficient deterrent that Debian would suffer
> for it.  

Honestly, I think you're underrating the capacity of our developer body.

Taking responsibility for potential problem doesn't mean knowing the
answer to everything that might happen, and it doesn't mean fixing it
yourself. It means staying around, and staying active, until the problem
is fixed.

It's the difference between asking for help and searching for help:
between saying "hello, can anyone help? No. Oh well. I tried." and
"hello, can anyone help? No? Hrm, how about over here? No? What about
you guys? Well, how about any tips? ..."

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpcVLARf1K4E.pgp
Description: PGP signature

Re: New release of ifupdown planned

[Anthony Towns]

On Wed, Aug 27, 2003 at 09:36:31PM +0200, Thomas Hood wrote:
> Since the maintainer of ifupdown doesn't answer repeated attempts
> to contact him by e-mail, I suppose it is appropriate to report
> here that there is a group of people working on a new ifupdown
> release.  

The term is "an ifupdown NMU".

You certainly should not be considering hijacking it.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpNDf9DgRIvM.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Adam McKenna]

On Wed, Aug 27, 2003 at 05:40:46PM -0700, Don Armstrong wrote:
> On Wed, 27 Aug 2003, Adam McKenna wrote:
> > TMDA does not ship with any defaults, except a couple of customizable
> > text files (templates).  It is entirely up to the user to create a
> > TMDA configuration along with his own whitelist and filter
> > directives.
> 
> If possible, perhaps you could consider whitelisting common debian.org
> address by default? [Things like [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED], etc.]

When I said "there are no defaults", I meant it.  There is no system-wide 
TMDA configuration.  Installing TMDA is analagous to installing procmail, 
or maildrop, or any other mail filtering software.  In order to utilize it,
you must configure your MTA to deliver mail to it, and set up several 
configuration files (e.g. .procmailrc in procmail's case or .mailfilter in 
maildrop's case).

The whitelist is just a list of e-mail addresses.  I could include a 
"sample whitelist", but listing the "recommended addresses to whitelist" 
in README.Debian should be equivalent or better.

--Adam
-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>

Re: New release of ifupdown planned

[Noah L. Meyerhans]

On Wed, Aug 27, 2003 at 09:36:31PM +0200, Thomas Hood wrote:
> The ifupdown package hasn't been touched by its maintainer for over
> two years and it is about time some of its problems were addressed.

Thanks for taking the initiative on this.  I'd noticed it's neglect a
while back but didn't have time to do anything about it.

> Since the maintainer of ifupdown doesn't answer repeated attempts
> to contact him by e-mail, I suppose it is appropriate to report
> here that there is a group of people working on a new ifupdown
> release.  Please contact me if you are interested or would like to
> help.  We would like to have a release ready well before the
> deadline for sarge.

I'd especially like to see bug 168776 closed.  There's even a patch
attached to it.

> This message should also be considered to be a query as to the
> whereabouts of the missing maintainer for the purposes of section
> 7.4 of the developer's reference "Dealing with inactive and/or
> unreachable maintainers".

AJ is definitely around...  In fact it's been less than 24 hours since
he's posted to this list...  AJ?

noah



pgpfF7LWCRUjo.pgp
Description: PGP signature

Re: DebToo: Debian, Gentoo-style

[Diego Calleja García]

El Wed, 27 Aug 2003 22:22:28 +1000 Glenn McGrath <[EMAIL PROTECTED]> escribió:

> Source based distro's are more bandwidth friendly as the source can be
> reused to produce new revisions of existing packages.
> 
> As a developer i would _much_ rather have a cache of old source code
> than a cache of stale binaries.

Or not. For sid I'd choose binary; woody would benefit from source. I think.

Take into account the time you waste compiling. What do you want to
pay, bandwith or CPU usage? The answer isn't the same for everybody...
(if we want to touch perfection)

> 
> USE settings are the best packaging innovation since apt.
> 
> Optimised binaries wont run slower than non-optimised binaries.

It depends a lot of what "optimizations" you do. (It'd be interesting
to measure gentoo's systems compiled from scratch with -O3. They even
compile kernels with -O3; this has been measured and kernels are slower)

The main problem with debian vs optimizations is that we compile for i386
code, which sucks. Most of the debian people use i586/i686 systems today.
Why are we compiling code for a small minority that still uses a 486 as
routing box? I386 could very well be a subproyect. I don't think
any i386 needs X 4.3 with gnome/kde, so why are providing binaries
optimized for a machines which aren't going to use them?


> We have the begginings of support for user optimised binaries, but we
> have a long way to go before catching upto gentoo.
> 
> We shouldnt be so wrapped up in our own importance that it blinds us to
> the community. Gentoo is doing something right.

I'm already doing optimised binaries in Debian. It's already there
(Just too complex).

I don't like gentoo 100%. It does some good things, but it doesn't do most
of them in the right way; IMHO.


To start with; we don't want to make a distro which has to be recompiled.
Binary packages are cool for installations.
(Gentoo could do this as a subset of their system "get that specific
architecture; get a standard USE selection, make packages and burn a iso
which installs 100% binary packages")

Some issues with a USE flag for me are:

o USE benefits would have to be measured. What's the cost of everything
  depending of everything? How configurable can be a gentoo system;
  that it can justify a USE flag? Can't we compile things with everything
  compiled in; and just provide binary packages for some specific options?

o It's THE reason why gentoo doesn't provide binary packages.(Actually; gentoo
  could solve this with a good p2p-based distribution system for packages. It'd
  be also cool to have a p2p method for apt and download optimised binaries...
  we could keep the MD5s at debian.org and check against them before installing)

o If you change a flag in a package; you should recompile all the dependencies.
  This is important. This makes reconfiguration of a system REALLY _hard_ (Gee,
  I got this new hardware which supports X feature and now I'll recompile 200
  libraries). Do we want this just to get a 'better' package system?

o If at the end you need a USE flag because it allows a good configuration;
  what you really should do? Write a new package system because apt sucks?
  Or fix your software because it doesn't allow dynamic configuration of some
  settings?

(NOTE: I'm not suggesting gentoo sucks; just wondering what people thinks...)

o I've other things in mind, but I've to sleep.


(I think at the end we'll come with this conclusion: There're different people
and different needs and both distros have to live together)

Whatever we do: It's much easier to create whatever package system you want and
migrate to them inside debian, than creating a new distro and all the
infrastructure it requires.

Diego Calleja

Re: NMUs applying sleeping wishlist bugs about translation

[Steve Langasek]

On Wed, Aug 27, 2003 at 02:05:15PM -0500, Manoj Srivastava wrote:
> On Wed, 27 Aug 2003 11:46:41 -0500, Steve Langasek <[EMAIL PROTECTED]> said: 

> > This is the sticking point, I think.  Are we talking about resolving
> > the possible problems *from* NMUing, or are we talking about
> > resolving any problems that happen to show up after the NMU?  I

>   How can one distinguish between the two, without
>  investigation? Often bugs are caused by the darndest things, and some
>  of the worst are the "can't happen" category bugs.

Oh, surely you can't; but once a determination is made, I don't think
the NMUer bears any more responsibility than any other developer to fix
those bugs that were not actually caused by the NMU.

> > absolutely agree that an NMUer is responsible for fixing any
> > problems caused by the NMU, but I don't agree that NMUers should be
> > held responsible for pre-existing bugs in the package -- whether or
> > not they happened to be exposed by the NMU in question.

>   If you upload caused things to get worse for the users of the
>  package, you are responsible. If the upload has changed things for
>  the worse, you should try and fix it. The very least you *must* do is
>  monitor the package to ensure that your NMU is not causing problems.

I agree with you but some of the assertions made in this discussion
appear to go farther.

> > If that's the case, I have no inclination whatsoever to NMU buggy
> > packages -- I'd much rather file for their removal from the archive.

>   No one is holding a gun to your head. You are a volunteer, and
>  can't be forced to NMU. 

Quite.  But I believe that doing NMUs *does* improve the overall quality
of Debian, and I believe that putting NMUers on the spot over bugs they
didn't cause would be a sufficient deterrent that Debian would suffer
for it.  I have no qualms about requesting package removals from the
archive, but when I'm doing NMUs, I usually start with packages I
*don't* think should be removed.

> > Holding NMUers accountable for the quality of their uploads: yes.

>   Quite. If your upload caused the situation to deteriorate,
>  whether you deliberately caused the change that made it so or it was
>  inadvertent, you are responsible.

I can't tell if we're agreeing here or not. :)  Yes, if you make a
change in the NMU that causes the situation to deteriorate, you are
responsible; but a pre-existing FTBFS error in the package that just
hasn't been filed yet isn't the result of a change made by the NMUer,
and therefore the NMUer should not be held responsible.

-- 
Steve Langasek
postmodern programmer


pgpNbZi9f88fW.pgp
Description: PGP signature

Re: Patch needs Sponsor - 20 bugs left - sorted by mtime

[Goswin von Brederlow]

Joel Baker <[EMAIL PROTECTED]> writes:

> On Wed, Aug 27, 2003 at 12:32:59PM +0200, Goswin von Brederlow wrote:
> > 
> > TITLE #195527:  mysql++: FTBFS with g++-3.3: Missing  include
> > Severity:   serious
> > Package:mysql++
> > Age:87 days
> > Last changed:   15 days
> 
> Please be more careful about these reports; this bug has been claimed for
> some time (I've been waiting on getting someone from the mips folks to get
> in touch about testing it on that platform, for the *other* RC bug, before
> uploading the fix).

You have to check the claimed page for that. Thats not realy parser
friendly so I don't even try to parse it. I have checked it manually a
few times so I would be surprised if it has been claimed
continously. But who is perfect.

I heart of the mysql having more problems on mips on irc, probably
you, making fixing the others difficult or impossible for now so I
will add this to the exclude list.

MfG
Goswin

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Colin Watson]

On Wed, Aug 27, 2003 at 07:26:24PM -0400, Joey Hess wrote:
> Colin Watson wrote:
> > Some of those challenges arrive at [EMAIL PROTECTED] instead.
> 
> I'm curious; how many would you say it gets per package on avarage, that
> have some real impact? (A TMDA response to a BTS ACK mail has little
> impact.) Perhaps my numbers were low, since I only counted the ones I
> occasionaly see.

Oh, a fraction of a percent at the moment, fortunately, although my
perceptions are lower than reality since most of the challenges get
caught by the filters we use to catch the bazillion bounces and mail
delivery warnings that come our way, and end up in a rarely-read mailbox
on master.

The ones that are actually interesting would probably be challenges in
response to your-bug-has-been-closed acknowledgements.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow ([EMAIL PROTECTED]) [030826 21:50]:
> > Andreas Barth <[EMAIL PROTECTED]> writes:
> > > This mass-introduces bugs reports of glibc-bugs to other packages. No,
> > > glibc (and the other core parts) must be the most conservative part of
>  
> > If you are not able to test experimental-core packages properly (like
> > glibc) then don't have experimental-core activated on your client.
> 
> We've often had whining here about sid breaking something production
> critical. Well, sid is not meant to be used for that, but enough
> people do. (In other words: I don't trust the users enough that they
> will make the right choices.) So, in theory you're right. In practice
> users will manage to break.

The problem is that woody is to old for many users. Thats why they use
sid. Experimental and sid would be just days/weeks apart
versionwise. There would be no big need for users to choose
experimental.

> > > the system. (And, I don't believe that a proposal with so many changes
> > > to the pool and mirror system has a real chance to be implemented.)
> 
> > The pool doesn't change at all. Its a change of the script generating
> > the Packages/Sources files (adding a few lines for the new files) and
> > a long needed fix for source-only uploads to the mirror maintanace
> > scripts.
> 
> example: New version of apache in experimental which db5 (instead of
> db4.2). With which versions should the modules in libapache-mod-* be
> compiled? If you request to take all libapache-mod-* then out of
> experimental, you can quite easily transfer this to a newer glibc.
> That means that you need experimental-core if you enable anything in
> experimental. Discrepance and so q.e.d. for my claim.

Thats why I say make it a source distribution. Recompile for the set
of experimental sections selected by the user.

The only other halfway sane choise would be to compile every section
against sid and its own section with all the problems you then get
when mixing in experimental-core libs nearly everything links to.

> > Thats if you keep with building eperimental packages on the fly on the
> > client. If not you have a bunch of changes to the autobuilders.
> 
> Only way out. But - who wants on-the-fly autobuilding can do that also
> now. Perhaps a bit of infrastructure can be added for this (e.g. new
> build-depends-headers like:
> build-depends-woody: ... which supersede the original b-d header if
> builded under woody). But in general you can build packages quite easy
> today with apt-get source package, apt-get build-dep package, cd
> directory, dpkg-buildpackage -rfakeroot. Perhaps you should package an
> easy script for that, but that's all that can be done for that.

Build-depends are fine for it. It just need some nicer way to set this
up for the user. It needs to run with a single command preferably. At
the moment you have to do an update, look ast an upgrade (but don#t do
it), get sources of all packages and compile, dpkg -i the debs.

Alternatively a buildd which is even more work to install.

MfG
Goswin

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Steve Langasek]

On Wed, Aug 27, 2003 at 02:57:28PM -0400, Stephen Frost wrote:
> * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > Holding NMUers accountable for the quality of their uploads: yes.
> > Holding NMUers accountable for the quality of the maintainer's package: no.

> I'm happy to clarify my position if you aren't clear on it and would
> rather you do that then make misleading claims.  I don't know how NMUers
> could be *more* accountable than the official maintainer.  My position
> is that they should be equally responsible for bugs in the package,
> until the maintainer does an upload. 

Which is what I understood your position to be, and which is the
position I disagree with.  I'm sorry if you feel I've misrepresented
your views in some way.

I suppose I can concede that an NMUer should be as responsible as the
maintainer -- to the extent that, if the package is being NMUed, the
maintainer usually isn't taking all that much responsibility for the
package at the time, so the bar isn't set very high. ;P

-- 
Steve Langasek
postmodern programmer


pgpDibU2A3LML.pgp
Description: PGP signature

Re[5]:

[dutogemyp]

Title: 0rCm1Rey






and when it Debian-devel wtz He's about  cjDFr

dRTE Wrong number I Debian-devel some advice about kbZFZ

Re: DebToo: Debian, Gentoo-style

[Goswin von Brederlow]

Andrew Pimlott <[EMAIL PROTECTED]> writes:

> On Tue, Aug 26, 2003 at 01:14:41PM -0700, Chris de Vidal wrote:
> > Volunteers needed!
> > http://debtoo.org
> 
> You get Debian's benefits, like their stellar package
> management, with *completely* optional optimization.
> 
> I would be interested in a source-based system that is focused on
> convenience and flexibility, not optimization.  When I can pick a
> package in aptitude and have it download and compile the source, not
> a binary package.  When source dependencies are managed as well as
> binary dependencies.  When I can make patches and have them
> automatically merged when I upgrade.
> 
> So far, apt-src is the best thing I know about, but it's not
> intergrated into the rest of the system, which limits its
> usefulness.

Best would be if you could easily select the additional features
compiled in, like jpeg support.

You select gimp and it sees no libjpeg. It suggests libjpeg and one
has the choice. If libjpeg is then installed all packages that can use
libjpeg will also pop up and ask to be rebuild to take advantage of
it. That would be nice but a big change to debians sources.

MfG
Goswin

Re: cpu usage, consideration of others, apt-listbugs

[Goswin von Brederlow]

Masato Taruishi <[EMAIL PROTECTED]> writes:

> Adam Heath wrote:
> 
> > > On IRC, I was suggested that apt-listbugs should use index.db. I had to
> > > use debbugs .status file too because index.db doesn't have subject.
> > >
> > > apt-listbugs fetches just few static files from web server, two index
> > > files and .status files of actual critical bugs. So if 5 critical
> > > bugs are found, total 7 static files are downloaded. apt-listbugs
> > > can be used via normal proxy servers.
> > 
> > Requesting those files isn't itself causing load.  I just don't like that 
> > the
> > debbugs database is exported that way.
> 
> I agree. debbugs database is an internal format and not interface to
> other programs. Actually, I wanted a released interface to access bts
> other than cgi because it's slow and can't be cached easily. But 
> there was no fast interface to fetch bug reports. There is e-mail
> interface, but it's little complex to manage database. I prefer LDAP
> interface rather than e-mail interface. I'm sorry, but I'm not on
> debbugs-ml. Is there any plan to implement LDAP interface? (There is
> LDAP interface, but it searches debbugs dynmically and therefore slow
> and no-indexing). 

Afaik its already there:

See wnpp-mail for an example:
http://cvs.infodrom.org/tools/master/wnpp-mail?rev=1.8&content-type=text/x-cvsweb-markup&cvsroot=infodrom&only_with_tag=HEAD

MfG
Goswin

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Don Armstrong]

On Wed, 27 Aug 2003, Adam McKenna wrote:
> TMDA does not ship with any defaults, except a couple of customizable
> text files (templates).  It is entirely up to the user to create a
> TMDA configuration along with his own whitelist and filter
> directives.

If possible, perhaps you could consider whitelisting common debian.org
address by default? [Things like [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], etc.]

That would at least avoid some of the annoying C-R's that come from
TMDA on this list. [Probably wouldn't help the few other C-R systems
that don't understand what X-Mailing-List: means, though.]


Don Armstrong

-- 
It has always been Debian's philosophy in the past to stick to what
makes sense, regardless of what crack the rest of the universe is
smoking.
 -- Andrew Suffield in [EMAIL PROTECTED]

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


pgptqujdgVWht.pgp
Description: PGP signature

Re: looking for nco maintainer Brain Mays

[Brian Mays]

Rorik Peterson <[EMAIL PROTECTED]> wrote:

> I am one of the upstream developers of the nco package.  We have
> been unable to contact via email the maintainer Brian Mays after
> several attempts beginning 2003/03/03, although db.debian.org reports
> activity as recent 2003/08/13.  We would greatly like to update
> the unstable source since many improvements (in my mind) have been
> made since the last upload in October, 2002.  If Brian is MIA, or
> no longer interested in maintaining the nco package, I'd personally
> be interested in adopting it if no one else is (although I'm not
> currently a debian maintainer).

I am not quite MIA, but I do have quite a few things going on in my life
since this spring.  Finishing a PhD, moving, and starting a new job take
up quite a bit of one's time, and while I typically can make minor
improvements to packages without much difficulty, I haven't been able to
spare the time -- which most likely would require a couple of days -- to
update the NCO packages.

Right now, I have several other Debian packages that need changes, I
need to write at least two papers for publication in the Journal of
Computational Physics, and I am settling down into my new job.  Since
only one of these activities results in my rent being paid, it receives
the highest priority.  The others will be done when I have time.

The main problem in the past year or so is that the upstream maintainers
totally changed the way in which the upstream code is distributed (i.e.,
they moved away from the usual ftp site where I was downloading the
source) without telling anyone.  Therefore, I was unaware that ongoing
development was occurring upstream until I receive an email out of the
blue in March.  (Sorry, but I don't have the time to scan Google
periodically for NCO to find where the source code has gone.)  Note that
even the NCO sourceforge website lists the location of the upstream
sources incorrectly.

Thus, I receive an email informing me of all sorts of upstream
development and pointing out that the Debian package is out of date.
That in itself would not be a problem, but the message also included a
fairly detailed list of changes in the way the code is built, including
a special "debian" directory provided in the upstream source.  This
immediately signaled to me that significant work (more than a day) will
be required to incorporate these changes into the current Debian
package.  These "improvements" will need to be carefully read, digested,
understood, and modified to produce a quality result.  Too many times, I
have seen well-meaning, but not entirely competent, developers take a
stab at doing their own version of a Debian package, and the results
often require extensive effort to work around their code so that one can
produce a real, quality package.  I'm sorry, but the job used upstream
to "debianize" NCO just looks sloppy to me, and they would have received
a faster response from me if they had left well enough alone.

Thus, the situation is as follows.  If someone can point me to an new
upstream source that is fairly similar to the source in the current
Debian package, then I can incorporate these changes into Debian in a
very short time.  If, however, the upstream source contains "significant
improvements" to the way the software is built (i.e., it has extensive
changes), then don't expect anything from me before the middle of
September.

Respectfully,

- Brian

unsubscribe

[Rodrigo Tadeu Claro]

-- 

  .''`.  Rodrigo Tadeu Claro (rlinux)
 : :'  : Debian-SP - irc.freenode.net - #debian-sp
 `. `'`  email - [EMAIL PROTECTED]
   `-www.rodrigoclaro.cjb.net ->> UIN168799234
 --
 Linux User Registered #301748  Debian-BR User #504
 GPGkey ID D33084F2  -->>  http://www.keyserver.net
 Duvidas sobre Debian? Visite o Rau-tu do CIPSGA:
http://rautu.cipsga.org.br


pgpQCDAKmDFzP.pgp
Description: PGP signature

Re: NMUs applying sleeping wishlist bugs about translation

[Stephen Frost]

* Joel Baker ([EMAIL PROTECTED]) wrote:
> This argument would carry more weight with me if it were possible to either
> A) test the upload *completely* before making it (IE, catch all possible
> FTBFS bugs or other quirks that happen when dealing with the build daemons,
> many of which even a sane chroot build can't catch), or B) to back out an
> upload and say "Well, damn. It has an FTBFS bug that I can't fix; I should
> file a bug on *that*, and back out to the last known good copy".

Or file the FTBFS bug and if the maintainer isn't going to do anything
and no one is willing to actually maintain it then have it orphaned to
QA and/or removed.

Stephen


pgp4g8EXvniJe.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Stephen Gran]

This one time, at band camp, Adam McKenna said:
> Stephen,
> 
> TMDA does not ship with any defaults, except a couple of customizable
> text files (templates).  It is entirely up to the user to create a TMDA 
> configuration along with his own whitelist and filter directives.
> 
> TMDA is actually not just a C-R system.  C-R is only part of the system.  It
> is also has a very powerful and configurable mail filter, and it is also a
> Mail Delivery Agent.  You can read about the features of TMDA at
> http://tmda.net/features.html
> 
> I don't have a problem with adding documentation, in fact I had already
> planned on adding a note to README.Debian on the next release listing the
> addresses that the user should be sure to whitelist if he expects to be able
> to communicate with the BTS.

Well, if it ships essentially disabled, and has to be purposefully
enabled to do any harmful behavior by the user, and there is
documentation included that lets the user know about whitelisting and so
forth, that takes care of all of my objections.  I see no reason for
this to be RC either, but that's just IMHO.

Good luck with the debate,

Steve (who still hates C-R systems :)
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpXDdMGtYMos.pgp
Description: PGP signature

Re: Bits from the RM

[Branden Robinson]

On Mon, Aug 25, 2003 at 09:58:31PM +0200, Sven Luther wrote:
> On Wed, Aug 20, 2003 at 08:11:55PM -0500, Branden Robinson wrote:
> > Interested parties, please catch up on the last month's worth of traffic
> > to the debian-x mailing list to get a feel for the environment.
> 
> Maybe you could split the debian-x list some, it would make reading it
> easier. The signal to noise ratio has rather much degraded there these
> last month, especially with all the control.bugs.debian processed mails
> going to it.

IMO, people who can't keep up with debian-x in its current state
probably don't have the time to be the kind of committer who can
measurably help me get 4.3.0 into sarge.

I will be availing myself more of "help" tags, though, so people could
always scan the xfree86 bug list for bugs tagged "help", and volunteer
to help in specific cases.  Effort could be coordinated simply via
[EMAIL PROTECTED]

-- 
G. Branden Robinson|
Debian GNU/Linux   |Yeah, that's what Jesus would do.
[EMAIL PROTECTED] |Jesus would bomb Afghanistan. Yeah.
http://people.debian.org/~branden/ |


pgpevBDMDp06h.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Joey Hess]

Colin Watson wrote:
> Some of those challenges arrive at [EMAIL PROTECTED] instead.

I'm curious; how many would you say it gets per package on avarage, that
have some real impact? (A TMDA response to a BTS ACK mail has little
impact.) Perhaps my numbers were low, since I only counted the ones I
occasionaly see.

-- 
see shy jo


pgptCU7i7BnNf.pgp
Description: PGP signature

Do you Think Your Funny??? Want to be a Comedian??

[Brad]

 Laugh Across America  Las 
Vegas Comedy Festival
3945 W. Reno Ave., Suite E
Las Vegas, NV 89118
  Phone: (702) 736-6595 Fax: (702) 
736-3360
[EMAIL PROTECTED] http://www.laughacrossamerica.com 
 Contact: MILA ORTIZ-BROTHERS

Do you want to show people how funny you are

 HAVE A CHANCE TO SHOW YOUR FUNNY SIDE AND WIN A TRIP TO "PLAY VEGAS" LIVE AT 
THE LAS VEGAS COMEDY FESTIVAL!!!
15 CITY NATIONWIDE "LAUGH ACROSS AMERICA" TALENT SEARCH FOR COMEDIANS, BOTH 
AMATEUR AND PROFESSIONALS, TO BEGIN SEPT. 2ND IN HOUSTON, TEXAS AND END IN LAS 
VEGAS, NEVADA ON OCTOBER 15TH
The 2nd Laugh Across America Contest and Tour is underway seeking amateur and 
professionals comics for a chance to win a trip to Las Vegas to perform at the 
2nd Annual Las Vegas Comedy Festival set for October 29-November 2nd. The 
contest will hold open auditions for aspiring comedians and professionals in a 
city near you starting September 2nd in Houston. 
The Laugh Across America College category is open to College students (must 
have ID) to audition. Cities on the Laugh Across America contest and encore 
tour include Houston (Sept.2-3); Orlando (Sept.6-7); Miami (Sept.8-9); Atlanta 
(Sept.10-11); New York (Sept.14-16); Boston (Sept.17-18); Cleveland 
(Sept.20-21); Chicago (Sept.23-24); St. Louis (Sept.25-27); Denver (Sept.30); 
Seattle (Oct. 2-3); San Francisco (Oct.5-6); Los Angeles (Oct.8-10); Phoenix 
(Oct.12-12) and Las Vegas (Oct.15).
One finalist from the college category from each of the 15 cities across the 
country will win a trip to Las Vegas for the Las Vegas Comedy Festival October 
29-November 2 to compete for the Grand Prizeto "Play Vegas" and a spot to 
perform in the Laugh Across America Encore Tour around the country. The 4-day 
festival will include comedy seminars, celebrity panels, workshops, industry 
showcases, luncheons and a star-studded final awards banquet. 
For further information on the Laugh Across America Contest and Encore Tour and 
the Las Vegas Comedy Festival, registration and competition rules, please call 
(702) 736-6595 or visit http://www.laughacrossamerica.com
Mila Ortiz-Brothers
Marketing Director
Laugh Across America
Las Vegas Comedy Festival
[EMAIL PROTECTED] 

looking for nco maintainer Brain Mays

[Rorik Peterson]

I am one of the upstream developers of the nco package.  We have been 
unable to contact via email the maintainer Brian Mays after several 
attempts beginning 2003/03/03, although db.debian.org reports activity 
as recent 2003/08/13.   We would greatly like to update the unstable 
source since many improvements (in my mind) have been made since the 
last upload in October, 2002.  If Brian is MIA, or no longer interested 
in maintaining the nco package, I'd personally be interested in adopting 
it if no one else is (although I'm not currently a debian maintainer).

Rorik Peterson

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Gunnar Wolf]

Stephen Gran dijo [Wed, Aug 27, 2003 at 03:02:33PM -0400]:
> The project certainly can and should prohibit maintainers from uploading
> things that will cause problems for the project (crypto, copyright
> infringement, etc.), but that is a different case than this.
> Distributing TMDA doesn't infringe copyrights, and is not illegal, at
> least AFAIK.  The fact that it is distasteful to me personally (and
> clearly, many others) is a sad thing, but not RC quality.  Remember
> that we explicitly state in the Social Contract that we allow groups like
> the KKK to use our software for distasteful ends.

I completely agree - If a user is going to shoot himself in the foot, he
can do it with TMDA or with any other package.

> I think that either a large warning on bugs.d.o about the use of C-R
> systems in corrspondence, or a similar warning in the description of
> TMDA would suffice.  I am not familiar with TMDA, so I may be wrong, but
> couldn't it be shipped with a default of not issuing a C-R, and have a
> note in README.Debian about how to do enable it, with the caveat that
> using C-R for BTS correspondence will likely result in ignored bug
> reports and problems for the project?

Description, with the possible addition of a note in README.Debian would
be better - it is targetted at the user. Bugs are targetted to the
maintainer, and most users will not be aware of them.

-- 
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


pgphQ2E8JzhRw.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Adam McKenna]

On Wed, Aug 27, 2003 at 03:02:33PM -0400, Stephen Gran wrote:
> I think that either a large warning on bugs.d.o about the use of C-R
> systems in corrspondence, or a similar warning in the description of
> TMDA would suffice.  I am not familiar with TMDA, so I may be wrong, but
> couldn't it be shipped with a default of not issuing a C-R, and have a
> note in README.Debian about how to do enable it, with the caveat that
> using C-R for BTS correspondence will likely result in ignored bug
> reports and problems for the project?

Stephen,

TMDA does not ship with any defaults, except a couple of customizable
text files (templates).  It is entirely up to the user to create a TMDA 
configuration along with his own whitelist and filter directives.

TMDA is actually not just a C-R system.  C-R is only part of the system.  It
is also has a very powerful and configurable mail filter, and it is also a
Mail Delivery Agent.  You can read about the features of TMDA at
http://tmda.net/features.html

I don't have a problem with adding documentation, in fact I had already
planned on adding a note to README.Debian on the next release listing the
addresses that the user should be sure to whitelist if he expects to be able
to communicate with the BTS.

--Adam
-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>

Re: NMUs applying sleeping wishlist bugs about translation

[Joel Baker]

On Wed, Aug 27, 2003 at 02:05:15PM -0500, Manoj Srivastava wrote:
> On Wed, 27 Aug 2003 11:46:41 -0500, Steve Langasek <[EMAIL PROTECTED]> said: 
> 
> > Holding NMUers accountable for the quality of their uploads: yes.
> 
>   Quite. If your upload caused the situation to deteriorate,
>  whether you deliberately caused the change that made it so or it was
>  inadvertent, you are responsible.

This argument would carry more weight with me if it were possible to either
A) test the upload *completely* before making it (IE, catch all possible
FTBFS bugs or other quirks that happen when dealing with the build daemons,
many of which even a sane chroot build can't catch), or B) to back out an
upload and say "Well, damn. It has an FTBFS bug that I can't fix; I should
file a bug on *that*, and back out to the last known good copy".

Of course, the "last known good" copy is known to have an FTBFS bug, but
*that* can't be the NMUer's fault, since it existed (simply undetected)
prior to the NMU. And really, do we want it going into testing, and then
stable, with an FTBFS bug that might have been caught otherwise, but isn't
because folks are afraid to NMU stuff lest they get bitten by, say, a C
compiler semantics change that may involve restructuring fairly important
parts of the program to fix?

Until one of these two things is possible, I find it likely to make a lot
of folks who might otherwise consider NMUing (and do a perfectly good job)
unwilling to do it, because they'd then be held responsible for the fact
that the package was broken *apart* from anything they did to break it.

If they're going to have all the pain of a maintainership on the package
from then on, why shouldn't they just hijack it in the first place? I know
that if I'm going to be held responsible for everything on the package from
the last maintainer upload to the next (possibly non-existant) one, I'm
sure as heck more likely to restructure it a manner which lets me handle
it efficiently and without undue pain. And that generally means hijacking
it (or adopting it, but NMUing an orphaned package is sort of silly; you
REALLY should just adopt it if you care, since otherwise it's just going to
get dropped).

Of course, that means I'll handle about an order of magnitude fewer RC
bugs, but we didn't want to release Sarge anytime soon, did we?

Saying "well, they shouldn't NMU" is a risk, in my view, for the simple
reason that can be observed by doing a wc -l on the claims files on master.
If they aren't going to, it's very evident that nobody else is, either, and
so the NMUs just won't happen at all. And perhaps that's fine and we should
just remove the packages - but if that's the case, why are we bothering to
have BSPs every weekend, and a 0-day NMU test?
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU NetBSD/i386 porter: :' :
 `. `'
   `-


pgps19BPchjEX.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Adam McKenna]

On Wed, Aug 27, 2003 at 07:49:27PM +0100, Colin Watson wrote:
> On Wed, Aug 27, 2003 at 12:30:07PM -0400, Joey Hess wrote:
> > Adam McKenna wrote:
> > > The arguments are facile and specious, I do not intend to waste my
> > > precious time responding to them.
> 
> That's a shame. I don't believe Karsten to be in the habit of putting
> forward specious arguments.

Well, let's see, I'll try to be brief:

#0, #1, #2 and #11 are basically opinion and rhetoric.  Karsten has stated
that he has a 'religious' objection to CR, and I'm not willing to have a
debate about it.  I've already noted some of the places that Karsten can go 
if he wants a debate.

#3 blames CR for actions taken by an ISP (IOW, user configuration error).

#4 claims that CR is less effective without giving any empirical data to back
up that claim.

#5 claims a high false positive rate without giving any empirical data to
back up that claim.

#6 singles out CR for a DOS attack that all autoresponders and vacation
programs, as well as some MTA's are vulnerable to.  In addition, the effect
of such an attack would still identify the original sending machine through
the headers of the quoted message, so it would basically be equivalent to 
mailbombing someone from your own machine.

#7 does not apply to TMDA

#8 does not really make any sense at all.  It seems like he is saying that
spammers might start to send out fake confirmation requests in order to 
harvest e-mail addresses.  This seems far-fetched at best.

#9 just sounds like a threat.

#10 blames CR for user configuration errors (failing to set up a proper
whitelist)

--Adam
-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>

Re: Urgent coreutils/libc6? problem

[Jaldhar H. Vyas]

On Wed, 27 Aug 2003, Jørgen Hermanrud Fjeld wrote:

> I don't think so, since
> #
> egrep "(^passwd)|(^group)" /etc/nsswitch.conf
> passwd: files
> group:  files
> #
> And PAM should have no interference with looking up groups, as far as I can
> see, and this is not a login issue.
>

The reason I brought up PAM was because that was a recent change to
webmin.

That's all the ideas I had.  Sorry.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Dagfinn Ilmari MannsÃker]

Matijs van Zuijlen <[EMAIL PROTECTED]> writes:

>> That's over two months (and two releases) old. The current galeon in
>> unstable is 1.3.7.20030813-1, which has the "Add bookmark to" submenu at
>> the top of the bookmark menu.
>
> I only have the "Add bookmark" submenu, not the "Add bookmark to"
> submenu (not the "to"), and I'm running 1.3.7.20030813-1. The "Add
> bookmark to" menu items used to appear in every bookmark folder, to add
> bookmarks to that particular bookmark folder.

Sorry, my memory was playing tricks on me. I remembered seing that menu
recently, but that was in Mozilla, which I had forgotten that I had used
a bit lately (only Galeon 1.2.x on the cs lab computers).

You can, hower, right-click on a folder in the bookmark menu to get the
sub-menu containing "Add bookmark here".

-- 
ilmari

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Branden Robinson]

On Wed, Aug 27, 2003 at 12:30:07PM -0400, Joey Hess wrote:
> Adam McKenna wrote:
> > The arguments are facile and specious, I do not intend to waste my precious
> > time responding to them.
> 
> Speaking of precious time, let me bore you with another facile and
> specious argument..
[snip]

He's not listening, and he won't.  The best thing may be to reassign the
bug to the Technical Committee.

-- 
G. Branden Robinson|There is no housing shortage in
Debian GNU/Linux   |Lincoln today -- just a rumor that
[EMAIL PROTECTED] |is put about by people who have
http://people.debian.org/~branden/ |nowhere to live.-- G. L. Murfin


pgpadg7ifrAbb.pgp
Description: PGP signature

Re: 0 RC bugs == releasable quality?

[Gunnar Wolf]

Branden Robinson dijo [Tue, Aug 26, 2003 at 01:07:04PM -0500]:
> > Hrm. I guess that theory doesn't scale up beyond the package level...
> 
> It doesn't even scale up to XFree86.  *Every time* someone talks to me
> in person about XFree86, I expect they want my help with a problem, or
> they want to complain.
> 
> The exceptions, comprising about 10% of personal feedback, are:
> 1) "Why isn't XFree86 4.3.0 in woody?"
> 2) questions about what I think about the flamewar of the day (Keith
>Packard, Xouvert, etc.)
> 3) "Good job!" (okay, okay, I admit, this only about 0.0001% of all
>feedback)

Keep up with the good job, Branden! Go get'em all!

(is it at least 0.003% already? :) )

-- 
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


pgpmamLsP7r8m.pgp
Description: PGP signature

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Sven Luther]

On Wed, Aug 27, 2003 at 10:27:10AM -0400, Omen Wild wrote:
> Quoting Andreas Tille <[EMAIL PROTECTED]> on Wed, Aug 27 09:38:
> >
> >- the "add bookmark to" menu entry to put a certain bookmark directly 
> > into
> >  the right place
> 
> Turns out this feature is actually there.  Go into your bookmarks like
> you are going to open one, right click on the folder, and select "Add
> Bookmark Here".

Nope, will only append to the folder, not put the new bookmark in the
right place immediately.

Friendly,

Sven Luther

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Sven Luther]

On Wed, Aug 27, 2003 at 04:50:28PM +0200, Dagfinn Ilmari Mannsåker wrote:
> Andreas Tille <[EMAIL PROTECTED]> writes:
> 
> > On Wed, 27 Aug 2003, Michael Piefel wrote:
> >
> > To answer you other questions after checking on a machine with Galeon
> > 1.3 installed:
> >
> >> Am 27.08.03 um 09:38:47 schrieb Andreas Tille:
> >>
> >>>- the "add bookmark to" menu entry to put a certain bookmark
> >>>  directly into the right place
> >> My menu has that entry, what's wrong with yours?
> >
> > ~> dpkg -l galeon | grep ^ii
> > ii  galeon 1.3.5.20030615 GNOME web browser for advanced users
> >
> > This and all previous 1.3.x Galeon versions have only two entries in
> > the top of the bookmark menu and "add bookmark *to*" is missing.
> 
> That's over two months (and two releases) old. The current galeon in
> unstable is 1.3.7.20030813-1, which has the "Add bookmark to" submenu at
> the top of the bookmark menu.

I think the point is that in galeon 1.3, you cannot add a bookmark
directly into a certain place of the bookmark folder, but only can
append a bookmark to a given folder. This forces you to then go to the
bookmark editor and move things around instead of just adding it to the
right place to begin with.

I can live with that, but hope that this misfeature will be fixed in a
next version or something.

As for the URL pasting thingy, you only have to open a new tab, and even
if you add the new tab button to your toolbar, you can paste an url into
it, and have it open the url in a new tab. Now you only need a similar
single paste technique for opening an url in the same tab.

I also miss the tab migration between different windows that was present
in galeon 1.2 but is only possible to detach tabs in galeon 1.3. But
then, again, i can live with that, until it is reintroduced again in a
next version.

Friendly,

Sven Luther

New release of ifupdown planned

[Thomas Hood]

The ifupdown package hasn't been touched by its maintainer for over
two years and it is about time some of its problems were addressed.

Since the maintainer of ifupdown doesn't answer repeated attempts
to contact him by e-mail, I suppose it is appropriate to report
here that there is a group of people working on a new ifupdown
release.  Please contact me if you are interested or would like to
help.  We would like to have a release ready well before the
deadline for sarge.

This message should also be considered to be a query as to the
whereabouts of the missing maintainer for the purposes of section
7.4 of the developer's reference "Dealing with inactive and/or
unreachable maintainers".

--
Thomas Hood

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Sven Luther]

On Wed, Aug 27, 2003 at 11:46:41AM -0500, Steve Langasek wrote:
> On Thu, Aug 28, 2003 at 12:31:30AM +1000, Anthony Towns wrote:
> > On Wed, Aug 27, 2003 at 09:35:08AM +0200, Sven Luther wrote:
> > > It only means that someone
> > > wanting to do an NMU for some probably minor, not really touching the
> > > package, will not do it because he don't want that responsaibility or
> > > more probably cannot assume it. 
> 
> > That's the correct response. If you can't handle the responsibility you
> > shouldn't be touching other people's packages; you should be sending
> > the maintainer patches through the BTS. If someone who can handle the
> > responsibility of NMUing comes along and sees the patch before the
> > maintainer gets around to it, that's all to the good.
> 
> > > No need to attribute
> > > responsabilities to people who possibly cannot fullfill them.
> 
> > If you can't cope with -- ie, resolve -- the possible problems from NMUing,
> > you should not be NMUing.
> 
> This is the sticking point, I think.  Are we talking about resolving the
> possible problems *from* NMUing, or are we talking about resolving any
> problems that happen to show up after the NMU?  I absolutely agree that
> an NMUer is responsible for fixing any problems caused by the NMU, but I
> don't agree that NMUers should be held responsible for pre-existing bugs
> in the package -- whether or not they happened to be exposed by the
> NMU in question.
> 
> I think that it's generally very silly for someone to NMU a package if
> they don't care enough about it to want to try to resolve any RC bugs
> that show up and keep the package out of testing; but I don't like the
> climate of blame that Stephen Frost's posts seem to be promoting.  He
> seems to suggest that NMUers be held even more accountable than the
> packages' maintainers:  the worst that happens to a maintainer is that
> he doesn't get to see his package included in the stable release, but it
> sounds like NMUers are going to be roasted three ways from Sunday for
> bugs they didn't actually cause.  If that's the case, I have no
> inclination whatsoever to NMU buggy packages -- I'd much rather file for
> their removal from the archive.

BTW, that would be another way of achieving full translation of all
packages in a release, remove all them that don't quickly enough apply
the transition patch :)))

Friendly,

Sven Luther

Ye olde " and is not working in X" bug

[Adrian 'Dagurashibanipal' von Bidder]

Yo!

This was discussed at length (iirc soon after woody release, in one of the 
'what should be better in sarge' threads). but without any real solution 
being presented.

I don't know, has there been any progress? Somebody (a DD) failed to reproduce 
it. I did set up a few Debian machines recently - the bug is still present. 
One observation that was iirc not made in the previous thread: the 4 or 5 
machines I saw with this problem were all set up with the woody installer, 
but switched to a testing and/or unstable sources.list quite early in the 
installation (Don't remember if it was already in the initial sources.list or 
only just after the installation, after declining to run dselect/tasksel).

The 3 computers at home (all set up with the potato installer when woody was 
testing, and since continuously apt-gotten, one of them into a quite unholy 
stable/testing/unstable mix) don't have the problem.

Please excuse me for not filing a bug - but what package

greetings
-- vbi

-- 
featured link: http://fortytwo.ch/gpg/subkeys


pgpmyahdlH75S.pgp
Description: signature

Re: NMUs applying sleeping wishlist bugs about translation

[Manoj Srivastava]

On Wed, 27 Aug 2003 11:46:41 -0500, Steve Langasek <[EMAIL PROTECTED]> said: 

> This is the sticking point, I think.  Are we talking about resolving
> the possible problems *from* NMUing, or are we talking about
> resolving any problems that happen to show up after the NMU?  I

How can one distinguish between the two, without
 investigation? Often bugs are caused by the darndest things, and some
 of the worst are the "can't happen" category bugs.

> absolutely agree that an NMUer is responsible for fixing any
> problems caused by the NMU, but I don't agree that NMUers should be
> held responsible for pre-existing bugs in the package -- whether or
> not they happened to be exposed by the NMU in question.

If you upload caused things to get worse for the users of the
 package, you are responsible. If the upload has changed things for
 the worse, you should try and fix it. The very least you *must* do is
 monitor the package to ensure that your NMU is not causing problems.

> If that's the case, I have no inclination whatsoever to NMU buggy
> packages -- I'd much rather file for their removal from the archive.

No one is holding a gun to your head. You are a volunteer, and
 can't be forced to NMU. 

> Holding NMUers accountable for the quality of their uploads: yes.

Quite. If your upload caused the situation to deteriorate,
 whether you deliberately caused the change that made it so or it was
 inadvertent, you are responsible.

manoj

-- 
"OK, now let's look at four dimensions on the blackboard." Dr. Joy
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Allan Wind]

On 2003-08-27T09:38:47+0200, Andreas Tille wrote:
> Moreover I do not like the new hot keys because I was comfortable with
>   {,}  to go  {back,foreward}
> which was replaced by some other keys which are used in my special environment
> for a different purpose.

Sounds like gnome vs emacs text editing short cuts.  You can switch
between the two with:

GNOME | Applications | Desktop Prefences | Keyboard Shortcuts


/Allan
-- 
Allan Wind
P.O. Box 2022
Woburn, MA 01888-0022
USA


pgpk3G26bl7O8.pgp
Description: PGP signature

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Stephen Frost]

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> Holding NMUers accountable for the quality of their uploads: yes.
> Holding NMUers accountable for the quality of the maintainer's package: no.

I'm happy to clarify my position if you aren't clear on it and would
rather you do that then make misleading claims.  I don't know how NMUers
could be *more* accountable than the official maintainer.  My position
is that they should be equally responsible for bugs in the package,
until the maintainer does an upload. 

This also isn't to say they have to be able to fix every bug in the
package but like the maintainer they need to try and tag it help, etc.
Additionally, any DD should also have the ability to request a package 
be removed or orphaned to QA if it's clearly not being maintained.  The
same goes for hijacking packages but I think most understand that
already.

Stephen


pgpGC4OIlpTuc.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Colin Watson]

On Wed, Aug 27, 2003 at 12:30:07PM -0400, Joey Hess wrote:
> Adam McKenna wrote:
> > The arguments are facile and specious, I do not intend to waste my
> > precious time responding to them.

That's a shame. I don't believe Karsten to be in the habit of putting
forward specious arguments.

> Speaking of precious time, let me bore you with another facile and
> specious argument..
> 
> Like many of us here, I occasionally receive bug reports from our users,
> and reply for more information, and get back some kind of challenge[1],
> or possibly a warning that my mail is being rejected because I am in a
> DUL (such as the osirusoft one). Since I consider my time just as
> precious as Adam's, I typically ignore all such challenges.

Some of those challenges arrive at [EMAIL PROTECTED] instead. AFAIK,
we typically don't have enough time to respond to them what with all the
other stuff we're doing, and on a matter of principle I think that
people interacting with the Debian BTS should whitelist it; imagine if
we had to respond to a challenge by hand for every maintainer and
submitter who ever uses bugs.debian.org!

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Stephen Gran]

This one time, at band camp, Joey Hess said:
> 
> I don't think that TMDA is yet enough of a problem for this to be a big
> deal, but I think it has the potential to become one. Debian as a whole
> is empowered to override the wishes of one maintainer, if it turns out
> that the software he is packaging is detrimental to the distribution as
> a whole. We do not let maintainers package software in us/main that puts
> us at risk of copyright infringement, or certian patent infringements,
> or in the past, crypto that cannot be exported. If we find that TMDA has
> the potential to cause significant problems for the project, we can
> certianly decide that we will not promote it or distribute it, and we
> can warn our users not to use it in communication with the project.

Let me start by saying I absolutely hate C-R systems, and give up on
communicating with people who use them.  That being said, I think the
argument you're making is a slippery slope, and is not something I'm
entirely comfortable with.

The project certainly can and should prohibit maintainers from uploading
things that will cause problems for the project (crypto, copyright
infringement, etc.), but that is a different case than this.
Distributing TMDA doesn't infringe copyrights, and is not illegal, at
least AFAIK.  The fact that it is distasteful to me personally (and
clearly, many others) is a sad thing, but not RC quality.  Remember
that we explicitly state in the Social Contract that we allow groups like
the KKK to use our software for distasteful ends.

I think that either a large warning on bugs.d.o about the use of C-R
systems in corrspondence, or a similar warning in the description of
TMDA would suffice.  I am not familiar with TMDA, so I may be wrong, but
couldn't it be shipped with a default of not issuing a C-R, and have a
note in README.Debian about how to do enable it, with the caveat that
using C-R for BTS correspondence will likely result in ignored bug
reports and problems for the project?

Just some thoughts,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpE67eWs0xH6.pgp
Description: PGP signature

Re: tmda: Challenge-response is fundamentally broken

[Steve Lamb]

On Wed, 27 Aug 2003 11:44:34 +0100
Stephen Stafford <[EMAIL PROTECTED]> wrote:
> Sorry, but I do NOT see how this is a grave bug.  It's wishlist (at best).

I tend to agree with the grave aspect.

> YOU might not agree that C-R systems are good (personally I detest them),
> but that does NOT mean that we shouldn't release one.  If the package is in
> good shape and functions as advertised, then it IS fit for release.  
 
> Hey, how about if I decide that emacs is a huge bloaded piece of shit?  Does
> that mean we shouldn't release it?
 
> Or if I decide that CUPS is rubbish and lprng is the One True Printer
> Daemon?
 
> Or that Gnome is a steaming pimple on the arse of desktop managers?
 
> As long as SOME users like it, and find it useful and it fits THEIR needs,
> then we should not be removing it from Debian (as long as it meets DFSG).
> tmda appears to meet those criteria.  It is NOT your place to decide what
> software our users can and can't use.

Fine.  Some users like to send spam should Debian then package all spam
producing software?

Just because some users want the software is not enough of a reason to
package and distribute it when there is a clear and demonstrable bad behavior
inherent to the design and implementation of the software in question. 
Karsten's original filing proves there is a clear and demonstrable bad
behavior inherent in *ALL* C-R systems.  While I dislike Emacs and Gnome one
would be hard pressed to demonstrate how they or their design are inherently
exhibiting bad behavior.

> This is NOT a grave bug.  You have given NO reasons why the package does not
> work as advertised, or fails to build, or fails to install or causes major
> breakage to significant numbers of systems.  

Yes, Karsten did.  Did you skip over the entire report or should we start
packaging viruses now, too, since they perform as expected regardless of their
effect on the larger picture?  IE, it is possible for a package to "work as
advertised" and still be wrong.

> All you have is an opinion that C-R systems are bad.  I share that opinion,
> but that does NOT make this a grave bug.

I await your spam and virus packages with earnest.

-- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
---+-


pgpdq0VGTDBnL.pgp
Description: PGP signature

Re: osirusoft down

[Martin List-Petersen]

On Wed, 2003-08-27 at 20:12, martin f krafft wrote:
> also sprach Martin List-Petersen <[EMAIL PROTECTED]> [2003.08.27.1832 +0200]:
> > >   http://www.merit.edu/mail.archives/nanog/msg12818.html
> > 
> > Actually there is a chance of your/my mail getting through
> 
> how?

The line at osirusoft was so overloaded, that there was no answer at all
some of the time. Thus the mta not filtering the mail.

Regards,
Martin List-Petersen
martin at list-petersen dot se
--
BOFH excuse #223:

The lines are all busy (busied out, that is -- why let them in to begin
with?).


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

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Bernhard R. Link]

* Florian Weimer <[EMAIL PROTECTED]> [030827 19:08]:
> That's why it's better to get rid of generic MX secondaries (IOW
> secondaries which are not under you administrative control).  The
> effect you describe hampers effective anti-spam measures, too.  

It can also help anti-spam measures. They are in my eyes a good solution
for large universities together with a block for incomming smtp-messages
except to one or two central machines beeing backup MX for anything. 
I don't know a better way to close open relays.

> For
> example, you might want to defer a message from a sender whose
> temporarily domain doesn't have any MX (or A) record.  If you do this,
> significant numbers of messages will pile up in the queues of your
> secondary MXes, and their operators won't be happy about that.

This is merely an argument againt badly configured backups or backups
with operations getting sad to fast...

Hochachtungsvoll,
  Bernhard R. Link

-- 
They said: "Smile and be happy, it could become worse."
And I smiled and was happy. And it became worse.

Re: osirusoft down

[martin f krafft]

also sprach Martin List-Petersen <[EMAIL PROTECTED]> [2003.08.27.1832 +0200]:
> >   http://www.merit.edu/mail.archives/nanog/msg12818.html
> 
> Actually there is a chance of your/my mail getting through

how?

> and if people at least have configured their mailer to monitor
> abandoned mail, then they'll notice. 

my MTA just rejects such messages, thus i will never know.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpq6rOQU8WPL.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Mark Brown]

On Wed, Aug 27, 2003 at 05:16:40PM +0200, Florian Weimer wrote:

> Most MTAs support rejecting unknown destinations at the SMTP level.
> They don't generate bounce messages in such cases.

> It's a pity if Postfix can't do this.  So far, I assumed only qmail
> had this weird property.

Postfix supports this perfectly well now (it used to not support this
well at the SMTP level due to having a modular design much like qmail
but that hasn't been the case for quite some time).

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

Re: cpu usage, consideration of others, apt-listbugs

[Masato Taruishi]

2003$BG/(B08$B7n(B28$BF|(B(?)$B$N(B01$B;~(B58$BJ,$K(B Adam Heath 
(Bwrote:
(B
(B> > On IRC, I was suggested that apt-listbugs should use index.db. I had to
(B> > use debbugs .status file too because index.db doesn't have subject.
(B> >
(B> > apt-listbugs fetches just few static files from web server, two index
(B> > files and .status files of actual critical bugs. So if 5 critical
(B> > bugs are found, total 7 static files are downloaded. apt-listbugs
(B> > can be used via normal proxy servers.
(B> 
(B> Requesting those files isn't itself causing load.  I just don't like that the
(B> debbugs database is exported that way.
(B
(BI agree. debbugs database is an internal format and not interface to
(Bother programs. Actually, I wanted a released interface to access bts
(Bother than cgi because it's slow and can't be cached easily. But 
(Bthere was no fast interface to fetch bug reports. There is e-mail
(Binterface, but it's little complex to manage database. I prefer LDAP
(Binterface rather than e-mail interface. I'm sorry, but I'm not on
(Bdebbugs-ml. Is there any plan to implement LDAP interface? (There is
(BLDAP interface, but it searches debbugs dynmically and therefore slow
(Band no-indexing). 
(B
(B-- 
(BMasato Taruishi <[EMAIL PROTECTED]>

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Matijs van Zuijlen]

On Wed, Aug 27, 2003 at 04:50:28PM +0200, Dagfinn Ilmari Manns??ker wrote:
> Andreas Tille <[EMAIL PROTECTED]> writes:
> 
> > On Wed, 27 Aug 2003, Michael Piefel wrote:
> >
> > To answer you other questions after checking on a machine with Galeon
> > 1.3 installed:
> >
> >> Am 27.08.03 um 09:38:47 schrieb Andreas Tille:
> >>
> >>>- the "add bookmark to" menu entry to put a certain bookmark
> >>>  directly into the right place
> >> My menu has that entry, what's wrong with yours?
> >
> > ~> dpkg -l galeon | grep ^ii
> > ii  galeon 1.3.5.20030615 GNOME web browser for advanced users
> >
> > This and all previous 1.3.x Galeon versions have only two entries in
> > the top of the bookmark menu and "add bookmark *to*" is missing.
> 
> That's over two months (and two releases) old. The current galeon in
> unstable is 1.3.7.20030813-1, which has the "Add bookmark to" submenu at
> the top of the bookmark menu.

I only have the "Add bookmark" submenu, not the "Add bookmark to"
submenu (not the "to"), and I'm running 1.3.7.20030813-1. The "Add
bookmark to" menu items used to appear in every bookmark folder, to add
bookmarks to that particular bookmark folder.

-- 
Matijs van Zuijlen


pgpMJOJO05U10.pgp
Description: PGP signature

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Tim Dijkstra]

On Wed, 27 Aug 2003 16:50:28 +0200
[EMAIL PROTECTED] (Dagfinn Ilmari Mannsåker) wrote:

> That's over two months (and two releases) old. The current galeon in
> unstable is 1.3.7.20030813-1, which has the "Add bookmark to" submenu
> at the top of the bookmark menu.

Huh?!? well I must be blind then...

ii  galeon 1.3.7.20030813-1 GNOME web browser for advanced users

And I don't see no "Add bookmark to"-submenu. Are you sure you didn't do
any manual tweeking of some configuration file?

grts Tim

Re: osirusoft down

[Martin List-Petersen]

On Wed, 2003-08-27 at 11:43, martin f krafft wrote:
> In case you run a mailserver with RBL and you don't know about this
> yet. (mh, are you going to get this mail then?)
> 
>   http://www.merit.edu/mail.archives/nanog/msg12818.html

Actually there is a chance of your/my mail getting through and if people
at least have configured their mailer to monitor abandoned mail, then
they'll notice. 

If you are reading lkml you'll notice very fast, that something is
wrong. Never have i seen less mail on lkml.

Regards,
Martin List-Petersen
martin at list-petersen dot se
--
Killing is wrong.
-- Losira, "That Which Survives", stardate unknown


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

Re: tmda: Challenge-response is fundamentally broken

[Kalle Kivimaa]

Mark Brown <[EMAIL PROTECTED]> writes:
> The part where SMTP is completely unauthenticated means that this
> doesn't help - the SMTP envelope sender can be forged just as easily as
> the From: inside the message.

You're right, I forgot to say that the idea only applies to
non-relayed mail where the other end is the originator. Forging the
TCP connection is more difficult than simple header forgery.

-- 
*A man's only as old as the woman he feels. (Groucho Marx)*
*   PGP public key available @ http://www.iki.fi/killer   *

thanking u

[hishashi11]

Thanks for mailing. I'll reply u as soon as possible.
   Have a nice day.
   ...Shashi...

Re: Urgent coreutils/libc6? problem

[Jørgen Hermanrud Fjeld]

On Tue, Aug 26, 2003 at 10:21:27PM -0400, Jaldhar H. Vyas wrote:
> Could it be something in your nsswitch or PAM configuration?  Are you
> using NIS? (I heard it was broken in the latest libc6)

I don't think so, since
#
egrep "(^passwd)|(^group)" /etc/nsswitch.conf
passwd: files 
group:  files 
#
And PAM should have no interference with looking up groups, as far as I can
see, and this is not a login issue.

Sincerely
Jørgen

Re: cpu usage, consideration of others, apt-listbugs

[Adam Heath]

On 27 Aug 2003, Masato Taruishi wrote:

> On IRC, I was suggested that apt-listbugs should use index.db. I had to
> use debbugs .status file too because index.db doesn't have subject.
>
> apt-listbugs fetches just few static files from web server, two index
> files and .status files of actual critical bugs. So if 5 critical
> bugs are found, total 7 static files are downloaded. apt-listbugs
> can be used via normal proxy servers.

Requesting those files isn't itself causing load.  I just don't like that the
debbugs database is exported that way.

> apt-listbugs doesn't use querybts implicity. It's invoked by people. So
> I guess many cgi access is nothing to do with apt-listbugs.

No, but it gives users a stepping board to request those reports.  Previously,
there was no automated listing of bugs fixed, and no automated prompting to
allow users to see those bug reports.

Re: tmda: Challenge-response is fundamentally broken

[Tore Anderson]

* Mark Brown

 > You do realise that all parts of SMTP are generally completely
 > unauthenticated and can be trivially forged?

  Yes.  It's indeed very sad that it is so.

  However, my main issue still remains -- the difference (for the user)
 between

 «I'm installing this package and accept that my correspondents
 must jump through a few hoops to get in touch with me»

  and

 «I'm installing this package and accept that my correspondends must
 jump through a few hoops to get in touch with me -and- that it is
 overwhelmingly likely that I will send unsolicited junk mail to third
 parties so that they will have to deal with the problem instead of
 myself»

  is, in my opinion, vast.

  If TMDA warned the user that it'll take the latter approach, I'd
 probably be happy with that.   (It would have been even better if
 there were some tutorial included, that could give a crash course
 in how to make TMDA -not- send challenges to e-mail SpamAssassin and/or
 ClamAV classified as junk mail.)

-- 
Tore Anderson

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Steve Langasek]

On Thu, Aug 28, 2003 at 12:31:30AM +1000, Anthony Towns wrote:
> On Wed, Aug 27, 2003 at 09:35:08AM +0200, Sven Luther wrote:
> > It only means that someone
> > wanting to do an NMU for some probably minor, not really touching the
> > package, will not do it because he don't want that responsaibility or
> > more probably cannot assume it. 

> That's the correct response. If you can't handle the responsibility you
> shouldn't be touching other people's packages; you should be sending
> the maintainer patches through the BTS. If someone who can handle the
> responsibility of NMUing comes along and sees the patch before the
> maintainer gets around to it, that's all to the good.

> > No need to attribute
> > responsabilities to people who possibly cannot fullfill them.

> If you can't cope with -- ie, resolve -- the possible problems from NMUing,
> you should not be NMUing.

This is the sticking point, I think.  Are we talking about resolving the
possible problems *from* NMUing, or are we talking about resolving any
problems that happen to show up after the NMU?  I absolutely agree that
an NMUer is responsible for fixing any problems caused by the NMU, but I
don't agree that NMUers should be held responsible for pre-existing bugs
in the package -- whether or not they happened to be exposed by the
NMU in question.

I think that it's generally very silly for someone to NMU a package if
they don't care enough about it to want to try to resolve any RC bugs
that show up and keep the package out of testing; but I don't like the
climate of blame that Stephen Frost's posts seem to be promoting.  He
seems to suggest that NMUers be held even more accountable than the
packages' maintainers:  the worst that happens to a maintainer is that
he doesn't get to see his package included in the stable release, but it
sounds like NMUers are going to be roasted three ways from Sunday for
bugs they didn't actually cause.  If that's the case, I have no
inclination whatsoever to NMU buggy packages -- I'd much rather file for
their removal from the archive.

Holding NMUers accountable for the quality of their uploads: yes.
Holding NMUers accountable for the quality of the maintainer's package: no.

-- 
Steve Langasek
postmodern programmer


pgpnDmZZA1Ro7.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Joey Hess]

Adam McKenna wrote:
> The arguments are facile and specious, I do not intend to waste my precious
> time responding to them.

Speaking of precious time, let me bore you with another facile and
specious argument..

Like many of us here, I occasionally receive bug reports from our users,
and reply for more information, and get back some kind of challenge[1],
or possibly a warning that my mail is being rejected because I am in a
DUL (such as the osirusoft one). Since I consider my time just as
precious as Adam's, I typically ignore all such challenges. I will leave
the bug open for a while in case another user, who is willing to hold up
his end of the implied BTS social contract and also sees the bug is able
to respond to it. Eventually though I will have no choice but to close
it.

This is ok when the percentage of such bugs is low -- in the 1% area.
If the percentage of such bugs becomes higher, say 10%, I belive that
Debian will start to suffer from it. If we're unable to contact the
submitters of 10% of our bugs, then a lot of bugs will go unfixed, and
quality will drop. I'm already finding it much harder to get a response
from users on bug reports than I did years ago.

I don't think that TMDA is yet enough of a problem for this to be a big
deal, but I think it has the potential to become one. Debian as a whole
is empowered to override the wishes of one maintainer, if it turns out
that the software he is packaging is detrimental to the distribution as
a whole. We do not let maintainers package software in us/main that puts
us at risk of copyright infringement, or certian patent infringements,
or in the past, crypto that cannot be exported. If we find that TMDA has
the potential to cause significant problems for the project, we can
certianly decide that we will not promote it or distribute it, and we
can warn our users not to use it in communication with the project.

-- 
see shy jo

[1] Which is fairly amusing, since I both gpg sign all my mail with a
and use TLS for sending it. There's no shortage of identification
here.


pgpRzn1e779Cz.pgp
Description: PGP signature

unsubscribe

[David Riebenbauer]

unsubscribe

Re: tmda: Challenge-response is fundamentally broken

[Florian Weimer]

Mark Brown <[EMAIL PROTECTED]> writes:

>> Why cannot the C-R system issue the challenge during the SMTP session
>> (respond with a reject containing the challenge)? With the latest
>> Sobig flood I've begun to consider all list software sending back
>
> The part where SMTP is completely unauthenticated means that this
> doesn't help - the SMTP envelope sender can be forged just as easily as
> the From: inside the message.

*You* don't generate a bounce in this case.  Others might do, but in
the case of Sobig.F and a sizeable chunk of spamming operations, no
bounces at all are sent.

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Adam McKenna]

On Wed, Aug 27, 2003 at 12:37:36PM +0100, Colin Watson wrote:
> Perhaps some compromise could be found here to improve the package's
> description. Adam, I also think it would be helpful if you could respond
> to at least some points from the original bug report. I do believe that
> Karsten has thought about this in some thoroughness and is not simply
> trying to antagonize you.

The arguments are facile and specious, I do not intend to waste my precious
time responding to them.  There is no reason for me to remove TMDA from
Debian, and therefore I will not do so.  If Karsten or anyone else wants to
have a debate about which of these arguments apply to TMDA, and why, then I
suggest he take his complaints to the upstream mailing lists @tmda.net.  I
will not debate this in the BTS or on any debian list.

--Adam

-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Joey Hess]

Stephen Stafford wrote:
> As long as SOME users like it, and find it useful and it fits THEIR needs,
> then we should not be removing it from Debian (as long as it meets DFSG).

Great! Then someone needs to revive that ITP filed April 1st 2002. This
new policy will certianly make a lot of script kiddies very happy.

-- 
see shy jo


pgpN7fm59MxZx.pgp
Description: PGP signature

Re: Patch needs Sponsor - 20 bugs left - sorted by mtime

[Joel Baker]

On Wed, Aug 27, 2003 at 12:32:59PM +0200, Goswin von Brederlow wrote:
> 
> TITLE #195527:mysql++: FTBFS with g++-3.3: Missing  include
> Severity: serious
> Package:  mysql++
> Age:  87 days
> Last changed: 15 days

Please be more careful about these reports; this bug has been claimed for
some time (I've been waiting on getting someone from the mips folks to get
in touch about testing it on that platform, for the *other* RC bug, before
uploading the fix).
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU NetBSD/i386 porter: :' :
 `. `'
   `-


pgpcWNs7oavq8.pgp
Description: PGP signature

Re: DebToo: Debian, Gentoo-style

[Andrew Pimlott]

On Tue, Aug 26, 2003 at 01:14:41PM -0700, Chris de Vidal wrote:
> Volunteers needed!
> http://debtoo.org

You get Debian's benefits, like their stellar package
management, with *completely* optional optimization.

I would be interested in a source-based system that is focused on
convenience and flexibility, not optimization.  When I can pick a
package in aptitude and have it download and compile the source, not
a binary package.  When source dependencies are managed as well as
binary dependencies.  When I can make patches and have them
automatically merged when I upgrade.

So far, apt-src is the best thing I know about, but it's not
intergrated into the rest of the system, which limits its
usefulness.

Andrew

Re: tmda: Challenge-response is fundamentally broken

[Brian T. Sniffen]

Tore Anderson <[EMAIL PROTECTED]> writes:

> severity 207300 grave
> quit
>
> * Karsten M. Self
>
>  > Briefly:  challenge-response (C-R) spam fighting systems are
>  > fundamentally broken by design.
>
>  > I am recommending that TMDA be dropped from Debian.

I use tmda, but not in challenge-response mode.  I find it useful for
its cryptographic hash-address system and the autowhitelisting code.

-Brian

-- 
Brian T. Sniffen[EMAIL PROTECTED]
   http://www.evenmere.org/~bts/

Re: DebToo: Debian, Gentoo-style

[Steve Langasek]

On Wed, Aug 27, 2003 at 10:22:28PM +1000, Glenn McGrath wrote:

> Source based distro's are more bandwidth friendly as the source can be
> reused to produce new revisions of existing packages.

This is only true in cases where you get more than one Debian revision
out of a given upstream release of a package before the sources expire
out of your cache.  In general, I see that individual source packages
tend to be much larger than the corresponding binary packages that users
would be downloading; so this is only of benefit on packages that rev
frequently, and on the whole, it's probably a net loss.

-- 
Steve Langasek
postmodern programmer


pgpJmDIezlgIQ.pgp
Description: PGP signature

Re: galeon in Debian stable

[Sebastian Kapfer]

On Wed, 27 Aug 2003 10:10:11 +0200, Mark Howard wrote:

> Sorry for cross-posting. There are many interested people who only read
> one of the lists I'm posting to.
> 
> Hello again,
>   It's great to see so many positive comments about galeon. Hopefully
> 1.3.8 will go into stable.

It would be really sad to release Sarge without a Galeon. I use your 1.3
debs every day, and while they crash sometimes, they aren't totally
unusable. 1.3.5 was even better - it proved rock-stable for me. What about
a slight regression to 1.3.5 if we can't stabilize 1.3.[78] in time for
the release?

-- 
Best Regards,   |   Hi! I'm a .signature virus. Copy me into
 Sebastian  |   your ~/.signature to help me spread!

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Mark Howard]

On Wed, Aug 27, 2003 at 03:53:42PM +0200, Andreas Tille wrote:
> I forgot a further very helpful feature: External viewer / editor for viewing
> page source is missing. 
right click->open with

> And last but not least I'm missing the "Page information" feature.  No doubt 
> that
> the brilliant Galeon programmers are busy reimplementing this stuff
I don't think anyone is actually, there are other things which they're
more interested in at the moment. Patches would really help speed things
up - even if the code you submit isn't that great, sombody would look at
it and hopefully work in it. Submitting patches also have the wonderful
effect of motivating developers to spend more time on the project.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Joey Hess]

Christian Marillat wrote:
> See the discussion on -gnome-gtk. Not shipping galeon in sarge is a big
> mistake. Users will be very happys.

I think I agree with you. I'm also glad I've switched to firebird..

Sorry about starting a duplicate thread.

-- 
see shy jo


pgpKM4OihI3LN.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Florian Weimer]

John Goerzen <[EMAIL PROTECTED]> writes:

> Sometimes, there is no choice.  That could be the case if, for instance, you
> are backup MX for a server that is down.  You have accepted the message from
> the original sender already -- possibly hours ago.  The primary server comes
> back up and rejects the message.  You have no choice but to generate a
> bounce mail to the original sender.

That's why it's better to get rid of generic MX secondaries (IOW
secondaries which are not under you administrative control).  The
effect you describe hampers effective anti-spam measures, too.  For
example, you might want to defer a message from a sender whose
temporarily domain doesn't have any MX (or A) record.  If you do this,
significant numbers of messages will pile up in the queues of your
secondary MXes, and their operators won't be happy about that.

Re: tmda: Challenge-response is fundamentally broken

[Wouter Verhelst]

On Wed, Aug 27, 2003 at 04:07:58PM +0300, Kalle Kivimaa wrote:
> Mark Brown <[EMAIL PROTECTED]> writes:
> > You do realise that all parts of SMTP are generally completely
> > unauthenticated and can be trivially forged?  A system like this has no
> > option but to work with unauthenticated data.
> 
> Why cannot the C-R system issue the challenge during the SMTP session
> (respond with a reject containing the challenge)?

Read SMTP 2821, and find out for yourself. Hint: SMTP is intended to be
noninteractive, while this thing tries to get confirmation from a human
being.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Andreas Tille]

On Wed, 27 Aug 2003, Mark Howard wrote:

> right click->open with
... which is not as fast as , isn't it?

> I don't think anyone is actually, there are other things which they're
> more interested in at the moment. Patches would really help speed things
> up - even if the code you submit isn't that great, sombody would look at
> it and hopefully work in it. Submitting patches also have the wonderful
> effect of motivating developers to spend more time on the project.
Thanks for explaining me again how free software works.  I see no relevance for
submitting patches if the code which provides a feature is in the history of
older versions available.  I think patiently waiting until those brilliant
developers of Galeon will find the time to reimplement these features is fine
for me.  I just was answering the question, which features are not yet 
implemented.

Kind regards

   Andreas.

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Florian Weimer]

Peter Makholm <[EMAIL PROTECTED]> writes:

> I think we could just as well remove postfix[0] on this account. I have
> received a lot of so called bounces because some silly postfix
> installation believes that I have send mail to some non-existant
> account.

Most MTAs support rejecting unknown destinations at the SMTP level.
They don't generate bounce messages in such cases.

It's a pity if Postfix can't do this.  So far, I assumed only qmail
had this weird property.

Re: tmda: Challenge-response is fundamentally broken

[Florian Weimer]

Bernd Eckenfels <[EMAIL PROTECTED]> writes:

> Every MTA is sending bounces to mails with forged headers.

The MXes I'm responsible for don't do this (even the secondary MXes
handle such cases gracefully).  They just refuse messages with unknown
destinations at the SMTP level.  AFAIK, all MTAs which are part of
Debian can do this.  You need some extra configuration to cover the
secondaries, too, but that's usually worth the trouble.

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Andreas Metzler]

On Wed, Aug 27, 2003 at 10:00:13PM +1000, Brian May wrote:
> On Wed, Aug 27, 2003 at 12:58:19PM +0200, Peter Makholm wrote:
> > Tore Anderson <[EMAIL PROTECTED]> writes:
> > >   How many other innocent third parties have you spammed through the use
> > >  of this broken program?  How many of these are Debian users, do you
> > >  think?
 
> > I think we could just as well remove postfix[0] on this account. I have
> > received a lot of so called bounces because some silly postfix
> > installation believes that I have send mail to some non-existant
> > account.
 
> I think the difference here is that postfix never bounces valid emails.
 
> Apparently TMDA will under some situations???
[...]

TMDA will send a mail saying something along the lines of "This is
the first mail I've received from your address, I won't actualy
recieve it until you send "verify fgf$%ZTRD4315835671658998719710" to
[EMAIL PROTECTED]

Comparing to vacation(1) fits better.
  cu andreas

Re: tmda: Challenge-response is fundamentally broken

[Mark Brown]

On Wed, Aug 27, 2003 at 04:07:58PM +0300, Kalle Kivimaa wrote:
> Mark Brown <[EMAIL PROTECTED]> writes:

> > You do realise that all parts of SMTP are generally completely
> > unauthenticated and can be trivially forged?  A system like this has no
> > option but to work with unauthenticated data.

> Why cannot the C-R system issue the challenge during the SMTP session
> (respond with a reject containing the challenge)? With the latest
> Sobig flood I've begun to consider all list software sending back

The part where SMTP is completely unauthenticated means that this
doesn't help - the SMTP envelope sender can be forged just as easily as
the From: inside the message.

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

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Dagfinn Ilmari MannsÃker]

Andreas Tille <[EMAIL PROTECTED]> writes:

> On Wed, 27 Aug 2003, Michael Piefel wrote:
>
> To answer you other questions after checking on a machine with Galeon
> 1.3 installed:
>
>> Am 27.08.03 um 09:38:47 schrieb Andreas Tille:
>>
>>>- the "add bookmark to" menu entry to put a certain bookmark
>>>  directly into the right place
>> My menu has that entry, what's wrong with yours?
>
> ~> dpkg -l galeon | grep ^ii
> ii  galeon 1.3.5.20030615 GNOME web browser for advanced users
>
> This and all previous 1.3.x Galeon versions have only two entries in
> the top of the bookmark menu and "add bookmark *to*" is missing.

That's over two months (and two releases) old. The current galeon in
unstable is 1.3.7.20030813-1, which has the "Add bookmark to" submenu at
the top of the bookmark menu.

-- 
ilmari

Re: Removal of automake1.5, Phase 2: The Mass Bug filing

[Mikael Andersson]

ons 2003-08-27 klockan 14.37 skrev Artur R. Czechowski:
> On Sat, Aug 16, 2003 at 08:28:40PM -0400, Eric Dorland wrote:
> > Luckily, my previous message seemed to have spurred many into action,
> > as only 21 source packages have automake1.5 in their Build-Depends
> > line, and of those only:
> Some packages has been fixed (bugs closed or NMUed). I've checked all
> remaining packages in clean pbuilder environment. Those packages
> builds with automake1.7 without major changes or does not require
> automake during build stage. All those packages has submitted patches
> and are patch-tagged:
> 
> Package Maintainer Bug number
> --
*snip*
> krb4  [EMAIL PROTECTED]   #205986

I have an updated package aviable, but I'm waiting for bam to recompile
heimdal against it before I dupload it. 

Sincerely
Mikael

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Anthony Towns]

On Wed, Aug 27, 2003 at 09:35:08AM +0200, Sven Luther wrote:
> It only means that someone
> wanting to do an NMU for some probably minor, not really touching the
> package, will not do it because he don't want that responsaibility or
> more probably cannot assume it. 

That's the correct response. If you can't handle the responsibility you
shouldn't be touching other people's packages; you should be sending
the maintainer patches through the BTS. If someone who can handle the
responsibility of NMUing comes along and sees the patch before the
maintainer gets around to it, that's all to the good.

> No need to attribute
> responsabilities to people who possibly cannot fullfill them.

If you can't cope with -- ie, resolve -- the possible problems from NMUing,
you should not be NMUing.

And there are plenty of people who are interested in translations and
who are competent to NMU.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpeQPWkIqhTY.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Anthony Towns]

On Wed, Aug 27, 2003 at 01:43:29PM +0200, Tore Anderson wrote:
>   I fully agree, and I would not hesitate to submit a RC bug on the
>  Postfix 

That's a completely inappropriate use of the RC severity, and possibly
the BTS entirely. The discussion is a good and useful one, trying to
inflate your difference of opinion into an RC bug is not.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpavE8qre6Jt.pgp
Description: PGP signature

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Omen Wild]

Quoting Andreas Tille <[EMAIL PROTECTED]> on Wed, Aug 27 09:38:
>
>- the "add bookmark to" menu entry to put a certain bookmark directly into
>  the right place

Turns out this feature is actually there.  Go into your bookmarks like
you are going to open one, right click on the folder, and select "Add
Bookmark Here".

Omen

-- 
WARNING TO ALL PERSONNEL: Firings will continue until morale improves.


pgpk7lUcRb9DR.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[John Goerzen]

On Wed, Aug 27, 2003 at 01:43:29PM +0200, Tore Anderson wrote:
>   However, a quick test shows that this is not the case (as Postfix
>  appears to reject the SMTP RCPT command for non-existent accounts),
>  so I fail to see how it is relevant.

Sometimes, there is no choice.  That could be the case if, for instance, you
are backup MX for a server that is down.  You have accepted the message from
the original sender already -- possibly hours ago.  The primary server comes
back up and rejects the message.  You have no choice but to generate a
bounce mail to the original sender.

This behavior is not limited to Postfix.  Perhaps you would like to file a
grave bug against the SMTP virtual package?

Re: tmda: Challenge-response is fundamentally broken

[Kalle Kivimaa]

Mark Brown <[EMAIL PROTECTED]> writes:
> You do realise that all parts of SMTP are generally completely
> unauthenticated and can be trivially forged?  A system like this has no
> option but to work with unauthenticated data.

Why cannot the C-R system issue the challenge during the SMTP session
(respond with a reject containing the challenge)? With the latest
Sobig flood I've begun to consider all list software sending back
"your message is waiting for moderation" messages broken, let alone a
software package designed to reduce SPAM (or virus checkers responding
to a completely wrong person warning about infected system). And yes,
I'm actually considering filing grave bugs against each such list
software package (I'm willing to live with such behaviour being
optional with the default being no response, if the documentation says
"beware SPAM worms if you enable autoresponse).

-- 
*  Outside of a dog, a book is man's best friend. Inside of a dog, it's   *
*too dark to read. (Groucho Marx) *
*   PGP public key available @ http://www.iki.fi/killer   *

Re: tmda: Challenge-response is fundamentally broken

[Stephen Stafford]

On Wed, Aug 27, 2003 at 01:35:12PM +0200, Tore Anderson wrote:
> [ Please do not send me CC's, as I have not explicitly asked for them. ]

Apologies.

> 
> * Stephen Stafford
> 
>  > Sorry, but I do NOT see how this is a grave bug.  It's wishlist (at best).
>  >
>  > YOU might not agree that C-R systems are good (personally I detest them),
>  > but that does NOT mean that we shouldn't release one.  If the package is in
>  > good shape and functions as advertised, then it IS fit for release.  
> 
>   I do not have anything against C-R systems per se, and I do not care if
>  others use them, or if we distribute them.  What I -do- have a problem
>  with is that the C-R system in question ignores the fact that SMTP
>  headers are trivially (and regulary) forged.  I believe this is deliberate,
>  and that TMDA does not attempt to verify that the recipient of the
>  challenge truly was the sender of the original e-mail.  (If it did, I
>  would have no problem with it at all.)
> 
>   Therefore third-party users, who had nothing to do with the original
>  sending of the mail, will receive unsolicited e-mail, and that even
>  from a program which is designed to stop such junk.
> 
>  > Hey, how about if I decide that emacs is a huge bloaded piece of shit?
>  > Does that mean we shouldn't release it?
>  >
>  > Or if I decide that CUPS is rubbish and lprng is the One True Printer
>  > Daemon?
>  >
>  > Or that Gnome is a steaming pimple on the arse of desktop managers?
> 
>   None of these are comparable - that one user installs Gnome on his
>  system does not hurt you in any way.  You can simply ignore it and
>  go on with your life.  You do not even have to know -- Gnome will not
>  send you unsolicited junk mail, regardless of it being a 'steaming
>  pimple' or no.

The original submitter was NOT compaining that the package was badly
implemented, he was complaining that C-R systems are bad (okay, he has lots
of reasons why he thinks they are bad, but it's all opinion in the end) and
should not be released.  The TMDA package is not broken with respect to what
it is meant to do.  It does exactly what it is meant to do.  The fact that
you don't like it is neitehr here nor there.

My examples of Gnome, emacs and CUPs were just that...examples.  They are
designs which some people like and some people don't.  The variety that says
we can have different designs is a good thing.

Personally I do not like C-R systems.  In general if I get a challenge from
one, I ignore it.

This does not mean that the tmda package is buggy.  All it means is that you
don't like what it does.  That being the case, it is exactly comparable to
someone deciding that because they don't like emacs, or Gnome or whatever
that we should file a RC bug on it to prevent it being released.  The only
thing that isn't comparable WHY you don't like it.  Sorry, but from where I
sit, it's not a good enough reason to remove it from the archive, or to
prevent it being released.

I dislike C-R based anti-spam measures, and I will tell anyone who asks me
WHY I don't like them.  Someone who likes vi and detests emacs will tell
anyone why he dislikes emacs.  I don't see why this should be a good reason
for removal from the archive, or why this is a release critical bug.

Stephen


pgpugmGC7ruZW.pgp
Description: PGP signature

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Christian Perrier]

Quoting Martin Quinson ([EMAIL PROTECTED]):

> with not only translating abilities (in fact I'm even rather bad at
> translating).

That's fine, I'm rather bad at programming... :-)

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Andreas Tille]

On Wed, 27 Aug 2003, Michael Piefel wrote:

To answer you other questions after checking on a machine with Galeon 1.3 
installed:

> Am 27.08.03 um 09:38:47 schrieb Andreas Tille:
> >- the brush clearing the URL field
> ^L not working for you?
^L just marks the URL and thus removes the mouse buffer which I wanted to 
insert.
But the brush *clears* the URL entry and I'm able to paste the mouse buffer into
place.  That's a difference.

> >- the "add bookmark to" menu entry to put a certain bookmark directly 
> > into
> >  the right place
> My menu has that entry, what's wrong with yours?

~> dpkg -l galeon | grep ^ii
ii  galeon 1.3.5.20030615 GNOME web browser for advanced users

This and all previous 1.3.x Galeon versions have only two entries in the top
of the bookmark menu and "add bookmark *to*" is missing.

> >- the quick access to proxy settings and other settings which is nice
> >  to have in changing environments (Laptop)
> Ack. I'm not entirely sure about the philosophy behind it.
I think the philosophy is just that you have *quick* access to features you
*need*.

I forgot a further very helpful feature: External viewer / editor for viewing
page source is missing. Moreover the hotkey to view the source vanished.  (Again
this is no real _problem_ but Galeon was the browser of choice because of its
nifty small features which make life easier.)

And last but not least I'm missing the "Page information" feature.  No doubt 
that
the brilliant Galeon programmers are busy reimplementing this stuff and I would 
have
never claimed about it.  My reasoning was about it would be worth to have Galeon
inside Debian and if Galeon 1.3.x would not be possible for some reasons, than
I would be happy with 1.2.x.  Please do not count me among the people who blame
developers just because I made this list of not yet implemented features.  They
did a fine job and probably Gnome 2 integration is worth to cope with this
temporarily lack of features.

Kind regards

Andreas.

Re: tmda: Challenge-response is fundamentally broken

[Richard Atterer]

On Wed, Aug 27, 2003 at 11:08:23AM +0200, Tore Anderson wrote:
[snip... oh my!]

How amusing to see Sobig.F cited as the reason for reassigning grave 
severity to a bug! Looks to me as if you just didn't find a sobig-f package 
to file the bug against, so something else had to be the culprit.

In the long run, it would be nice to have a special mail header used by all
auto-responders - bounces, virus alerts, out-of-office, maybe even a
variant for challenge-response systems -, to allow these mails to be
filtered.

A good (temporary) solution for people who use c-r systems is to filter
Sobig.F, like so (.procmailrc):

:0
* ^Subject: (Re: That movie|Re: Wicked screensaver|Re: Your application|Re: 
Approved|Re: Re: My details|Re: Details|Your details|Thank you!)$
* ^X-MailScanner: Found to be clean
Mail/spam

Challenge-response antispam systems are considered useful by enough users 
to be included in the archive. IMHO it must be left to the user to decide 
whether they're worth the trouble or not - Debian has no business making 
such decisions on behalf of the user.

Cheers,

  Richard (who, also hates c-r systems, but that's irrelevant)

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: DebToo: Debian, Gentoo-style

[Peter Makholm]

Glenn McGrath <[EMAIL PROTECTED]> writes:

> Optimised binaries wont run slower than non-optimised binaries.

It actually does happen. One reason can be loop-unrolling and
cache-sizes. 

-- 
 Peter Makholm |'Cause suicide is painless
 [EMAIL PROTECTED] | It brings on many changes
 http://hacking.dk |And I can take or leave it if I please
   |-- Suicide is painless

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Martin Quinson]

On Tue, Aug 26, 2003 at 07:28:03PM +1000, Anthony Towns wrote:
> On Tue, Aug 26, 2003 at 10:26:32AM +0200, Sven Luther wrote:
> > Let's say i do translataion work, for that i have to build the package,
> > and notice that it FTBFS (at least on some obscure arch or something). I
> > then fill a FTBFS bug report, thus liberating me of the responsability
> > you want to trust on me, and then NMU the translation improved package.
> 
> Uh, no. If it liberates you of anything, it'll likely be your ability to
> do any more NMUs.
> 
> If the package is less useful to people after you do the NMU than before
> you started looking at it, that's a problem. If it was formerly able
> to be run by everyone no matter which architecture, and now no longer
> works on alpha, that's a problem.


If I were in Christian shoes facing such issue (dormant l10n bug, but the
rebuild triggers a FTBFTS), I would report the FTBFTS, and look at another
package (ie, not doing the NMU if he obviously cannot do it right). 

If it's too late already (ie, the FTBFTS is trigered by build daemons on
alpha or other), I will go cry on debian-l10n-french or other to get some
help. I am coordinator of the french l10n, but in the civilian, I work on
massively heterogeneous platforms (yup, da grid). So, I guess I could try to
work around such issues. I know some perl semi-gods in the team. Other
members may be good at libraries puzzles.

As we work heavily in team, we know that the responsability of fixing the
mess we introduce in NMUs is ours. Not only Christian's, but ours. And our
chance is that there is many of us, all wanting to get a better l10n, but
with not only translating abilities (in fact I'm even rather bad at
translating).


Little need to worry about who's responsability it is to fix the mess, it
has to be done, that's all.

Thanks for your time, Mt.

-- 
Un clavier azerty en vaut deux.

Re: tmda: Challenge-response is fundamentally broken

[Ulrich Eckhardt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 27 August 2003 11:08, Tore Anderson wrote:
>  > I do not intend to play BTS games here; if you change the severity back
>  > to grave, or to any other RC state, I will consider it to be abuse of
>  > the BTS and report your actions to the BTS maintainer, and your ability
>  > to use the BTS will be taken away.

>   I'm Cc'ing debian-devel for comments, as you do not seem to be
>  interested in having any sensible discussion regarding this issue,
>  and amazingly enough instead go on threatening the submitter that you
>  will go to the BTS guys and have him blacklisted from the BTS.  Not
>  very polite to one of our users, I'd say.  Feel free to attempt having
>  me blacklisted, though.

Reread that. All he says is that the BTS is not the right place to settle 
%DISPUTE% and that he will try to prevent its abuse. Without even looking at 
what %DISPUTE% really is, he is right in that. That is what (in this case) 
debian-devel is good for.

Just wondering, is a keyring not also some kind of C-R system ? 

clam down,
Uli
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/TKbuwVdGSYi8Mq8RAiRKAJ9pNH8svNS07wX+bhzJMDwR5DCeAwCgleWP
GXWsDGm8hpxuKYvxyae7LH0=
=BCQ3
-END PGP SIGNATURE-

Re: DebToo: Debian, Gentoo-style

[Halil Demirezen]

Debian is caching debs rather than targzs. What i got from here,
if the argument is on deciding on whether project shold cache-old
the source code tarballs rather then binaries - i got debs from here
as binary , because i did not come accross other binaries cached in
the system - , I cannot see any differencess between debs and tarballs
in such a way that debs are optimized and suited version of tarballs 
for debian. They are compiled in a manner of a similar architecture
and some similar compiling tools. So what about inefficiency of
compiling the whole source code after removing the binary and 
after that you felt yourself, in your brain or in your emotions, you 
would like to install it again. On idealism, binary caching and 
re-installing from them (if no updates) should be, On pragmatism,
it also should be for keeping away the system using over resources
while compiling the tarballs again and again

Sincerely.


> Source code is more important than binaries, that we should all agree
> on.
> 
> Fixing bugs that such a project uncovers makes Free software more
> robusts and is good for the community.
> 
> Source based distro's are more bandwidth friendly as the source can be
> reused to produce new revisions of existing packages.
> 
> As a developer i would _much_ rather have a cache of old source code
> than a cache of stale binaries.
> 
> USE settings are the best packaging innovation since apt.
> 
> Optimised binaries wont run slower than non-optimised binaries.
> 
> 
> Performance is commonly stated as the number one goal of source
> distro's, i think its really about control, getting the most out of your
> system.
> 
> Its pragmatism vs idealism, pragmatists say its not worth the effort,
> idealists say it doesnt matter how much effort it takes to achieve
> perfection.
> 
> Arguing pragmatism vs idealism is futile unless we agree on common
> values.
> 
> Debian does have finite resource so we have to be pragmatic in terms of
> what binaries we provide, but we can be more idealistic about the build
> system that we make available for our users.
> 
> We have the begginings of support for user optimised binaries, but we
> have a long way to go before catching upto gentoo.
> 
> We shouldnt be so wrapped up in our own importance that it blinds us to
> the community. Gentoo is doing something right.
> 
> 
> 
> Glenn
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


pgp6hIKiHYzmx.pgp
Description: PGP signature

Re: tmda: Challenge-response is fundamentally broken

[Bernd Eckenfels]

On Wed, Aug 27, 2003 at 02:54:43PM +0300, Lars Wirzenius wrote:
> TDMA seems to hurt innocent outsiders by sending them mail (e.g., in
> response to garbage sent by viruses or spammers). The other examples you
> gave (Emacs, Gnome, CUPS) don't do that, as far as I know. The
> difference is important, I think.

Every MTA is sending bounces to mails with forged headers.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Brian May]

On Wed, Aug 27, 2003 at 12:58:19PM +0200, Peter Makholm wrote:
> Tore Anderson <[EMAIL PROTECTED]> writes:
> 
> >   How many other innocent third parties have you spammed through the use
> >  of this broken program?  How many of these are Debian users, do you
> >  think?
> 
> I think we could just as well remove postfix[0] on this account. I have
> received a lot of so called bounces because some silly postfix
> installation believes that I have send mail to some non-existant
> account.

I think the difference here is that postfix never bounces valid emails.

Apparently TMDA will under some situations???

(however, I am not making any judgements as far as this
dispute is concerned; I am not familiar with TMDA either).
-- 
Brian May <[EMAIL PROTECTED]>

Re: DebToo: Debian, Gentoo-style

[Glenn McGrath]

Some comments

Source code is more important than binaries, that we should all agree
on.

Fixing bugs that such a project uncovers makes Free software more
robusts and is good for the community.

Source based distro's are more bandwidth friendly as the source can be
reused to produce new revisions of existing packages.

As a developer i would _much_ rather have a cache of old source code
than a cache of stale binaries.

USE settings are the best packaging innovation since apt.

Optimised binaries wont run slower than non-optimised binaries.


Performance is commonly stated as the number one goal of source
distro's, i think its really about control, getting the most out of your
system.

Its pragmatism vs idealism, pragmatists say its not worth the effort,
idealists say it doesnt matter how much effort it takes to achieve
perfection.

Arguing pragmatism vs idealism is futile unless we agree on common
values.

Debian does have finite resource so we have to be pragmatic in terms of
what binaries we provide, but we can be more idealistic about the build
system that we make available for our users.

We have the begginings of support for user optimised binaries, but we
have a long way to go before catching upto gentoo.

We shouldnt be so wrapped up in our own importance that it blinds us to
the community. Gentoo is doing something right.



Glenn

Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)

[Andreas Barth]

* Goswin von Brederlow ([EMAIL PROTECTED]) [030826 21:50]:
> Andreas Barth <[EMAIL PROTECTED]> writes:
> 
> > * Goswin von Brederlow ([EMAIL PROTECTED]) [030826 15:20]:
> > > Only those contained in the sections enabled on the users system. If
> > > you have experimental-core and experimental-gnome all gnome debs
> > > should be comnpiled against the experimental glibc for example.

> > This mass-introduces bugs reports of glibc-bugs to other packages. No,
> > glibc (and the other core parts) must be the most conservative part of
 
> If you are not able to test experimental-core packages properly (like
> glibc) then don't have experimental-core activated on your client.

We've often had whining here about sid breaking something production
critical. Well, sid is not meant to be used for that, but enough
people do. (In other words: I don't trust the users enough that they
will make the right choices.) So, in theory you're right. In practice
users will manage to break.

> > the system. (And, I don't believe that a proposal with so many changes
> > to the pool and mirror system has a real chance to be implemented.)

> The pool doesn't change at all. Its a change of the script generating
> the Packages/Sources files (adding a few lines for the new files) and
> a long needed fix for source-only uploads to the mirror maintanace
> scripts.

example: New version of apache in experimental which db5 (instead of
db4.2). With which versions should the modules in libapache-mod-* be
compiled? If you request to take all libapache-mod-* then out of
experimental, you can quite easily transfer this to a newer glibc.
That means that you need experimental-core if you enable anything in
experimental. Discrepance and so q.e.d. for my claim.

> Thats if you keep with building eperimental packages on the fly on the
> client. If not you have a bunch of changes to the autobuilders.

Only way out. But - who wants on-the-fly autobuilding can do that also
now. Perhaps a bit of infrastructure can be added for this (e.g. new
build-depends-headers like:
build-depends-woody: ... which supersede the original b-d header if
builded under woody). But in general you can build packages quite easy
today with apt-get source package, apt-get build-dep package, cd
directory, dpkg-buildpackage -rfakeroot. Perhaps you should package an
easy script for that, but that's all that can be done for that.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

MEI Whitelist Autoresponse

[paul]

Your message to [EMAIL PROTECTED] has been quarantined!

You only need to do this once, but this time, you must verify
that you are a human.

This is an automated response send by the MEI Whitelist system.
At paul's request, this system blocks and quarantines email from
senders that are not on a list of approved addresses.  If you
reply to this message with the following line intact, you will be
added to paul's white list automatically!

MEI verification code: MEI0250511061987327tId9CNuNr3t1YZv3sJrT8g

Your message has been quarantined and will be delivered after
you're successfully added to the whitelist.   You will be sent
separate confirmation emails at each stage.  Typically that will
be two more automated messages.

Thank you for your patience.

The first 55 lines of your original message:
> From debian-devel@lists.debian.org  Wed Aug 27 08:28:47 2003
> Return-Path: 
> Received: from OITRM05-10A (bordermanager1.kellogg.cc.mi.us [204.39.194.3])
>   by mei.net (8.12.9/8.12.9) with ESMTP id h7RCSOHL024889
>   for <[EMAIL PROTECTED]>; Wed, 27 Aug 2003 08:28:25 -0400
> Message-Id: <[EMAIL PROTECTED]>
> From: 
> To: <[EMAIL PROTECTED]>
> Subject: Thank you!
> Date: Thu, 28 Aug 2003 8:34:52 --0400
> X-MailScanner: Found to be clean
> Importance: Normal
> X-Mailer: Microsoft Outlook Express 6.00.2600.
> X-MSMail-Priority: Normal
> X-Priority: 3 (Normal)
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>   boundary="_NextPart_000_000CF422"
> BCT-delivery-for: paul
> MEI-wl-code: MEI0250511061987327tId9CNuNr3t1YZv3sJrT8g
> 
> This is a multipart message in MIME format
> 
> --_NextPart_000_000CF422
> Content-Type: text/plain;
>   charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> 
> See the attached file for details
> --_NextPart_000_000CF422
> Content-Type: application/octet-stream;
>   name="document_all.pif"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
>   filename="document_all.pif"
> 
> TVqQAAME//8AALgAQAAA
> 4A4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
> ZGUuDQ0KJADToEjPl8EmnJfBJpyXwSacFN0onI3BJpx/3iyc7cEmnMHeNZyawSacl8Em
> nJTBJpyXwSecBsEmnPXeNZyawSacf94tnI3BJpxSaWNol8EmnABQRQAA
> TAEEAF2zPz8AAOAADwELAQYAAABw1usBAAAQYAEAAABQ
> AgAABAAEAgAAEAAAF/EBAAIAABAAABAAEAAAEBAA
> AOLrAQCcfuwBAAgA
> 
> AAAgAC5zaHJpbmsAAFABAAAQxBAAAEAAAMAu
> c2hyaW5rAAAwYAEAABIAAADUAABAAADALnNocmluawAAQJABAAAS
> 5gAAQAAAwC5zaHJpbmsAADDQAQAAIgAAAPgA
> AEAAAMAA
> 
> 
> 
> 
> 
> 
> 

Re: Removal of automake1.5, Phase 2: The Mass Bug filing

[Artur R. Czechowski]

On Sat, Aug 16, 2003 at 08:28:40PM -0400, Eric Dorland wrote:
> Luckily, my previous message seemed to have spurred many into action,
> as only 21 source packages have automake1.5 in their Build-Depends
> line, and of those only:
Some packages has been fixed (bugs closed or NMUed). I've checked all
remaining packages in clean pbuilder environment. Those packages
builds with automake1.7 without major changes or does not require
automake during build stage. All those packages has submitted patches
and are patch-tagged:

Package Maintainer Bug number
--
apcupsd [EMAIL PROTECTED]   #205981
krb4[EMAIL PROTECTED]   #205986
libquicktime[EMAIL PROTECTED]   #205987
modlogan[EMAIL PROTECTED]   #205988
pdns[EMAIL PROTECTED]   #205990
xkbd[EMAIL PROTECTED]   #205992
xkeysw  [EMAIL PROTECTED]   #205993
yank[EMAIL PROTECTED]   #205995

Please note, that automake1.5 has been removed from archive[1] and all above
bugs are now FTBFS category.

[1] http://bugs.debian.org/207085

Cheers
Artur
-- 
[...] ja też od czasu do czasu kupuję w knajpie małże tylko po to,
żeby jeszcze raz się przekonać, że nadal ich nie lubię ;)
/Wrota/


pgpQ6DGvsPRxz.pgp
Description: PGP signature

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Tore Anderson]

[ Please do not send me CC's, as I have not explicitly asked for them. ]

* Tore Anderson

 >>   How many other innocent third parties have you spammed through the use
 >>  of this broken program?  How many of these are Debian users, do you
 >>  think?

* Peter Makholm

 > I think we could just as well remove postfix[0] on this account. I have
 > received a lot of so called bounces because some silly postfix
 > installation believes that I have send mail to some non-existant
 > account.

  I fully agree, and I would not hesitate to submit a RC bug on the
 Postfix (or any other MTA) package, if it by default came with the
 broken configuration you speak of.

  However, a quick test shows that this is not the case (as Postfix
 appears to reject the SMTP RCPT command for non-existent accounts),
 so I fail to see how it is relevant.

-- 
Tore Anderson

Re: cpu usage, consideration of others, apt-listbugs

[Colin Watson]

On Wed, Aug 27, 2003 at 07:54:07PM +0900, Masato Taruishi wrote:
> On IRC, I was suggested that apt-listbugs should use index.db. I had to 
> use debbugs .status file too because index.db doesn't have subject.

I suggest that you generate your own index.db file containing the
subjects you need. This could be done quite cheaply if you base it on
the existing index.db and only read .status files for the bugs you're
interested in.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: tmda: Challenge-response is fundamentally broken

[Mark Brown]

On Wed, Aug 27, 2003 at 01:35:12PM +0200, Tore Anderson wrote:

>  with is that the C-R system in question ignores the fact that SMTP
>  headers are trivially (and regulary) forged.  I believe this is deliberate,
>  and that TMDA does not attempt to verify that the recipient of the
>  challenge truly was the sender of the original e-mail.  (If it did, I
>  would have no problem with it at all.)

You do realise that all parts of SMTP are generally completely
unauthenticated and can be trivially forged?  A system like this has no
option but to work with unauthenticated data.

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

Re: tmda: Challenge-response is fundamentally broken

[Colin Watson]

severity 207300 wishlist
thanks

On Wed, Aug 27, 2003 at 11:08:23AM +0200, Tore Anderson wrote:
> severity 207300 grave
> quit

Sorry, Tore, but this is not a grave bug. The package does what it says
on the tin, even if you think that its goals are broken in the wider
picture (and I'd happen to agree there, personally, especially in light
of the recent Sobig.F fiasco; but that's neither here nor there as far
as bug severities go).

I express no opinion about whether the bug is wishlist, minor, normal,
or important; but it doesn't qualify for release-critical.

> * Karsten M. Self
> 
>  > Briefly:  challenge-response (C-R) spam fighting systems are
>  > fundamentally broken by design.
> 
>  > I am recommending that TMDA be dropped from Debian.
> 
> * Adam McKenna
> 
>  > I will not respond to this bug other than to state that I don't
>  > believe it meets the requirements for filing a grave bug, and I
>  > will not remove TMDA from Debian just because you and a few others
>  > don't like it, or don't like this particular class of software.
>  >
>  > I do not intend to play BTS games here; if you change the severity
>  > back to grave, or to any other RC state, I will consider it to be
>  > abuse of the BTS and report your actions to the BTS maintainer, and
>  > your ability to use the BTS will be taken away.

Speaking as a BTS maintainer, that seems unlikely to happen. We have a
high threshold for banning people, and it does not include isolated
arguments. If it did, very few people would be able to use the BTS any
more!

Please don't deliberately escalate this argument.

>   Therefore I join the original submitter in the recommendation that
>  TMDA should be removed from Debian, or failing that, it should carry
>  a prominent notice in the description that it will send junk mail to
>  random third parties and will thus not remove the junk mail problem,
>  but simply transfer it (very rudely, I might add) to someone else.

Perhaps some compromise could be found here to improve the package's
description. Adam, I also think it would be helpful if you could respond
to at least some points from the original bug report. I do believe that
Karsten has thought about this in some thoroughness and is not simply
trying to antagonize you.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)

[Andreas Barth]

* Goswin von Brederlow ([EMAIL PROTECTED]) [030826 21:50]:
> Mark Howard <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Aug 26, 2003 at 10:25:24AM +0200, Goswin von Brederlow wrote:
> > > So speak up Mark, what do you mean with changed?
> > 
> > I meant identifying that bug X was fixed in version Y; packages in
> > experimental contain the fix but sid and testing packages do not (yet).
> > I think this feature would be even more useful when developers are
> > fixing bugs reported by sid users and uploading to experimental.
> 
> A Tag "min-version=" and "fixed-version=" as extensions to
> potato/woody/sarge/sid and have those 4 autochanged as versions move
> around.
> 
> yep. would be nice. finer grained than just the tags.

Even better would be to make the version-tags meta-tags.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C