Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Andreas Tille]

On Tue, 26 Aug 2003, Joey Hess wrote:

> Mark Howard wrote:
> >  galeon - GNOME web browser for advanced users
> > Changes:
> >  galeon (1.3.7.20030825-1) experimental; urgency=low
> >  .
> >* New CVS Checkout
> >* Moved to experimental - galeon is not yet stable enough for a Debian
> >  stable release. Packages in sid and sarge will be removed soon.
It is not only not stable enough it is lacking some key features which forced
me to try to port the latest stable Galeon to Sarge.  Unfortunately I failed
in tirst run and had no time to investigate in this task.  I think a Galeon
1.2.11 in Sarge would be a must have.

Kind regards

 Andreas.

Re: A possible GFDL compromise

[Fedor Zuev]

On Tue, 26 Aug 2003, John Galt wrote:

>On Mon, 25 Aug 2003, Fedor Zuev wrote:

>>On Sun, 24 Aug 2003, Nathanael Nerode wrote:

>>>Lack of forced distribution is not "censorship".  Get a clue, or a
>>>dictionary.
>>
>>  Heh.
>>
>>  "Why that ugly, non-free GPL license demand from me to
>>distribute source code? Source would still be freely available from
>>the FSF website! Lack of forced distribution do not harm a
>>freedom!" Agree?
>>

>GPL, section 3c, says exactly that

GPL v. 2

  3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms
of Sections 1 and 2 above provided that you also do one of the
following:
<...>

  c) Accompany it with the information you received as to the offer
to distribute corresponding source code.  (This alternative is
allowed only for noncommercial distribution and only if you
---
received the program in object code or executable form with such
---
an offer, in accord with Subsection b above.)
-

---

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

[Branden Robinson]

On Wed, Aug 27, 2003 at 05:58:24AM +0200, Josip Rodin wrote:
> Well, correction, cgi.d.o does almost nothing these days. But lists.d.o
> requires resources pretty much continuously, what with all the mhonarc,
> glimpse, stats updates and users accessing web pages and its CGI scripts.
> 
> And again, this is for -project, not for -devel. :<

Maybe debian-devel-annnounce.  We can't have master being DoSsed.

-- 
G. Branden Robinson|The best place to hide something is
Debian GNU/Linux   |in documentation.
[EMAIL PROTECTED] |-- Ethan Benson
http://people.debian.org/~branden/ |


pgpzIWWkwjgX8.pgp
Description: PGP signature

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Christian Marillat]

Joey Hess <[EMAIL PROTECTED]> writes:

> Mark Howard wrote:
>>  galeon - GNOME web browser for advanced users
>> Changes: 
>>  galeon (1.3.7.20030825-1) experimental; urgency=low
>>  .
>>* New CVS Checkout
>>* Moved to experimental - galeon is not yet stable enough for a Debian
>>  stable release. Packages in sid and sarge will be removed soon.
>
> Are you planning to not ship a galeon in sarge at all? Not even one of
> the older, fairly stable ones?

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

Christian

[no subject]

[dawood azimi]

hi   you want to get it on   
,,,
i got a good attitute and a fat cock,,,
tell me what you want to do

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Andreas Tille]

On Wed, 27 Aug 2003, Christian Marillat wrote:

> See the discussion on -gnome-gtk. Not shipping galeon in sarge is a big
> mistake. Users will be very happys.
s/happys/unhappy/

I do not have to read any list to know very sure that any GNU/Linux distribution
which lacks Galeon sucks.

Kind regards

Andreas.

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Michael Meskes]

On Wed, Aug 27, 2003 at 07:31:10AM +0200, Andreas Tille wrote:
> It is not only not stable enough it is lacking some key features which forced
> me to try to port the latest stable Galeon to Sarge.  Unfortunately I failed

What does it miss? I'm running 1.3.5 and did not notice that. :-) Okay,
probably because I don't use these features...

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Re: non-DD contributors and the debian keyringS

[Martin Quinson]

On Wed, Aug 27, 2003 at 12:35:36AM +1000, Hamish Moffatt wrote:
> On Mon, Aug 25, 2003 at 05:18:45PM +0200, Sven Luther wrote:
> > On Wed, Aug 20, 2003 at 05:03:17PM -0400, Stephen Frost wrote:
> > > * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > > > On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote:
> > > > > keyring.debian.org has only DDs in it.  I think people were suggesting
> > > > > using the public keyservers.  keyring.debian.org isn't a part of the
> > > > > public key servers.
> > > > 
> > > > That's the part of the system I was criticizing :)
> > > 
> > > Not going to change.
> > 
> > Why ?
> 
> Because an entry in the Debian keyring gives you voting rights, and so is
> limited to developers.

DudeS, there is already _4_ keyrings.  [If you don't belive me, have a look
at /usr/share/doc/debian-keyring/README.gz ;]

We are speaking about adding a 5th keyring to debian, for example for the
NM, or more generally for people not in the main keyring for a reason, but
which key may have a place on Debian for some reason.

Of course I was not asking to go in the main keyring without going through
the NM process, and being allowed to vote, upload packages, log on
servers...

> Maybe there's an argument for other classes of voting project member
> other than just developer (typically package maintainer) such as a
> translator or documentor. Those roles might have voting rights (ie be in
> the keyring) but not machine access or something, and a different (less
> rigorous?) NM process. I suggest you start a thread on debian-project if
> you think so.

Yes, thanks for the advice. I'm the kind of guy who forgets always that
d-d is for developers, and that all members have to be (said) developer, but
that d-d is not for the dicussion about the project as a whole... Sorry.

Thanks for your time, Mt.

-- 
The "US department of defense" should be renamed the "US department of
attack". 

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

[Sven Luther]

On Wed, Aug 27, 2003 at 02:31:51PM +1000, Anthony Towns wrote:
> On Tue, Aug 26, 2003 at 09:28:02PM +0200, Sven Luther wrote:
> > I agree if the FTBFS comes from something the NMUer did, then yes, it is
> > broken, but if it comes from general bad shape of the packages, then the
> > responsability is to the package maintainer
> 
> It's fine that you disagree. You're welcome to that. If you're going to
> act on your opinions though -- and not take responsibility for fixing
> the new bugs found when you upload NMUs -- then please do not NMU.

No problem, i take responsability of the packages i NMU, it is just that
i don't think this attititude is correct. 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. So, he will not do it, and the possible
FTBFS will not be discovered. As said, i don't do translations, so this
doesn't touch me.

> Again: this isn't about finding fault, it's about taking responsibility
> for the quality of your NMUs, and making sure that *all* new problems
> are resolved whether you caused them or not.

I understand that for the aim of having sarge release on december 1, it
is good for people to feel responsible for broken packages. I have
another solution for this : if the package potentially FTBFS, the
maintainer is either MIA or doesn't care, and nobody (be he NMUer or
not) cares enough to fix the FTBFS, then just remove the package from
the archive, or at least from sarge. No need to attribute
responsabilities to people who possibly cannot fullfill them.

Friendly,

Sven Luther

Re: binaries provided by multiple source packages

[Fabio Massimo Di Nitto]

Ok i see that you got apache in the middle of a transition, that is why
your check still see apache-perl as a source.

a few months ago there were 3 apache flavours built from 3 different
sources. apache, apache-ssl and apache-perl. Since the apache source code
was present in all of them and they were often out of sync we (as apache
maintainer team) decided to merge the 3 sources in one (apache) and be
able to build the 3 flavours out of it. A special cases has been done for
libapache-mod-perl. mod_perl is a requirement to build apache-perl so we
decided to generate libapache-mod-perl together with apache{-ssl,-perl}
without bloating the archive with another source package.

The only reason you still find apache-perl as source in the archive is
because ftp-master scripts still have to remove it. Of course this is
valid for sid/sarge. woody can't be changed and it willl ship the 3
sources that you see in the pool.

I think this should clarify everything.

Fabio

On Wed, 27 Aug 2003, Glenn McGrath wrote:

> On Tue, 26 Aug 2003 20:38:12 +0200 (CEST)
> Fabio Massimo Di Nitto <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 27 Aug 2003, Glenn McGrath wrote:
> >
> > > The following is a list of packages whose names are inconsistent
> > > with accepted behaviour (plz correct me if im wrong)
> >
> > Sorry for my ignorance but which is the accepted behaviour? i couldn't
> > find anything in the policies and in devel-reference (just had a fast
> > look trough them)
>
> Section 3.1
> Every package must have a name that's unique within the Debian archive.
> The package name is included in the control field Package, 
>
> It is open to interpretation a little bit i guess, but as i see it
>
> Every Package field in the Sources file must be unique to that file, and
> every Package field in the Packages file must be unique to that file.
>
> As it stands the apache-perl binary package (to pick on your case) could
> be generated from two different source packages, only one binary will
> ever be accepted as part of the binary release, if you try and insert a
> second one the old binary will be thrown out.
>
> Its hard for machines (autobuilders etc) to know which source the binary
> really should be generated from.
>
> Im not sure what should be done with regard to bootstapping apache.
>
>
>
> Glenn
>
>
>

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Sven Luther]

On Wed, Aug 27, 2003 at 07:31:10AM +0200, Andreas Tille wrote:
> On Tue, 26 Aug 2003, Joey Hess wrote:
> 
> > Mark Howard wrote:
> > >  galeon - GNOME web browser for advanced users
> > > Changes:
> > >  galeon (1.3.7.20030825-1) experimental; urgency=low
> > >  .
> > >* New CVS Checkout
> > >* Moved to experimental - galeon is not yet stable enough for a Debian
> > >  stable release. Packages in sid and sarge will be removed soon.
> It is not only not stable enough it is lacking some key features which forced

Well, what do you prefer : some missing features, or no galeon at all.

> me to try to port the latest stable Galeon to Sarge.  Unfortunately I failed
> in tirst run and had no time to investigate in this task.  I think a Galeon
> 1.2.11 in Sarge would be a must have.

Alternatively, you could help the upstream team re-implementing those
features.

Friendly,

Sven Luther

Re: A possible GFDL compromise

[Wouter Verhelst]

Op wo 27-08-2003, om 07:02 schreef Fedor Zuev:
>   c) Accompany it with the information you received as to the offer
> to distribute corresponding source code.  (This alternative is
> allowed only for noncommercial distribution and only if you
> ---
> received the program in object code or executable form with such
> ---
> an offer, in accord with Subsection b above.)
> -

Sure. For commercial redistribution, there is option 3b, accompany the
binary with a written offer for source.

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


signature.asc
Description: Dit berichtdeel is digitaal ondertekend

galeon in Debian stable

[Mark Howard]

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. [galeon developers - is this likely to be
released in the next 3 weeks, or should we really be looking at 1.3.7?].
If that's not released in a few weeks, I think we would be best looking
at a well tested cvs snapshot - there have been many great changes since
that release (5% of the changelog in only 1 month!).
I'll make a new snapshot package and upload to unstable tonight. I might
then use experimental for new snapshots for a while when trying to get
at least one version of galeon 1.3 into testing. Once 1.3.8 (or wherever
we decide to freeze) is in unstable I will also continue to make
snapshots for those of us who want them and upload these to
experimental.

  When I replaced the unbuildable, uninstallable galeon1.2 in sid with
1.3 snapshots from the galeon-snapshot package I was sent a lot of
flames (and so was the bts). This was obviously counterproductive (as was
the similar situation happening upstream around the time of the epiphany
fork). That's why I wanted a decision to include galeon to be made on
debian-gtk-gnome rather than taking all the responsibility myself :) 
(I was also concerned about releasing a developmental version in stable
- this is my first Debian release after all)
  
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 


pgpsl2f9VJSkn.pgp
Description: PGP signature

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Andreas Tille]

On Wed, 27 Aug 2003, Michael Meskes wrote:

> What does it miss? I'm running 1.3.5 and did not notice that. :-) Okay,
> probably because I don't use these features...
In no special order I'm missing:

   - the brush clearing the URL field
   - the "add bookmark to" menu entry to put a certain bookmark directly into
 the right place
   - the quick access to proxy settings and other settings which is nice
 to have in changing environments (Laptop)

Probably some others I do not remember quickly.  Upstream explains this fact
on the web pages and *I* can understand this but I earnect critics by my
wife ...

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.  I should file a wishlist bug report to ask for a
configuration feature for those hot keys but I had no time to check whether
it is just implemented and I was simply not able to find it.

Kind regards

 Andreas.

BTW: Font rendering with GTK+2.0 is so much better that switching back to
 Galeon 1.2.x would be hard, but the features above are worth it in my
 opinion.

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Andreas Tille]

On Wed, 27 Aug 2003, Sven Luther wrote:

> On Wed, Aug 27, 2003 at 07:31:10AM +0200, Andreas Tille wrote:
> > On Tue, 26 Aug 2003, Joey Hess wrote:
> >
> > > Mark Howard wrote:
> > > >  galeon - GNOME web browser for advanced users
> > > > Changes:
> > > >  galeon (1.3.7.20030825-1) experimental; urgency=low
> > > >  .
> > > >* New CVS Checkout
> > > >* Moved to experimental - galeon is not yet stable enough for a 
> > > > Debian
> > > >  stable release. Packages in sid and sarge will be removed soon.
> > It is not only not stable enough it is lacking some key features which 
> > forced
>
> Well, what do you prefer : some missing features, or no galeon at all.
I definitely would prefer a Galeon with missing features.  But the reason
to remove Galeon was its *instability* (which I did not recognized personally)
and thus the suggestion was to have the stable branch which would bring up
the additional advantage of bringing back those features.  That's all.

So *any* Galeon is fine for me with a slight preference of the stable branch.

> > me to try to port the latest stable Galeon to Sarge.  Unfortunately I failed
> > in tirst run and had no time to investigate in this task.  I think a Galeon
> > 1.2.11 in Sarge would be a must have.
>
> Alternatively, you could help the upstream team re-implementing those
> features.
Ahhh, thanks for reminding me how free software works. ;-))

Kind regards

Andreas.

Re: Updating packages' l10n without risk (~unrelated to previous)

[Martin Quinson]

On Tue, Aug 26, 2003 at 12:12:07AM +0100, Andrew Suffield wrote:
> On Mon, Aug 25, 2003 at 10:27:44PM +0200, Martin Quinson wrote:
> > On Mon, Aug 25, 2003 at 11:10:06AM -0500, Adam Heath wrote:
> > > On Fri, 22 Aug 2003, Christian Perrier wrote:
> > > 
> > > > And, as Steve pointed out, translation stuff is minimalistically
> > > > invasive so this does not require an enormous amount of attention
> > > > after the NMU.
> > > 
> > > Yes, but there are new libraries that get linked to, new compilers, etc.
> > 
> > It should be possible to get the source, rebuild to needed mo files
> > (containing the translation in a compiled form), unpack the binary package,
> > add the mo file and repack the binary package, shoudn't it ?
> 
> It might be better to ask why we are shipping translations in the
> package at all, and figure out how to make it work with them split
> out. Our current infrastructure can't handle it, but it's probably
> possible to figure out something which can.

Well, people already sometime split the documentation out of the package, so
I guess there is no fundamental reason in dinstall, katie or other
maintainance script for not doing the same about languages.

But that would mean multiplying the number of packages by about:
 \times 3-10 for all languages
 \times 1.5 to split out the documentations which are not yet (plus separating
   the man pages useless on computational servers from the extra
   documentation)
 \times 3-10 again, to split the documentation depending on the language
 
And since dpkg is known for not scale well in number of packages in the DB
(#69192, #157060), the package management system would certainly explode.

There is some well known optimisation in the dpkg parser, and the dpkg team
is working on it: tuning (#74259, #139838, #160447, #206416), use of binary
DB when possible (#149760), use of a flex parser (#179296), and maybe others. 

Most of these bugs are taged patch, so there is nothing I can do as not dpkg
developper, beside praying every night that the real life of doogie and
wichert leave them more time (to look at those patch and tell us what does
not fit in them), and wait for better days. What I do quite happily.
   
Another interesting lead is the split of the status DB in several files. One
for the critical information, and others for the less critical ones
(description, ..). It was proposed back in august 2001, and I proposed my
help to propose a patch, once the dpkg maintainer explained to me how they
wanted to design the beast. A summary of this discution is at:
http://lists.debian.org/debian-devel/2001/debian-devel-200108/msg02193.html
(partial summary, since it's mine :)

Answer was in the spirit of:
http://lists.debian.org/debian-dpkg/2001/debian-dpkg-200109/msg00082.html

and I'm still waiting for the day where capable people will be given the
time to think about the design and inform me. But that's ok, I'm unable to
do what the dpkg team does, so how could I dare complaining?

> I don't have an interest in doing this, but somebody might.

I do :)


Thanks for your time, Mt.

-- 
No, I'm not going to explain it.
If you can't figure it out, you didn't want to know anyway...
   --- Larry Wall

Re: galeon in Debian stable

[Andreas Tille]

On Wed, 27 Aug 2003, Mark Howard wrote:

>   It's great to see so many positive comments about galeon. Hopefully
> 1.3.8 will go into stable. [galeon developers - is this likely to be
Would be great.  Just ignore my vote for Galeon 1.2.x in the other thread
in debian-devel.  It was only thought as an alternative if we would have
no Galeon at all.

Thanks for your fine work on this very important piece of software

   Andreas.

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Michael Piefel]

Am 27.08.03 um 09:38:47 schrieb Andreas Tille:
>- the brush clearing the URL field
^L not working for you?

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

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

> Moreover I do not like the new hot keys because I was comfortable with
>   {,}  to go  {back,foreward}
Revert to galeon 1.2 because you have to press Alt instead of Ctrl?
Come on!

Bye,
Mike

-- 
|=| Michael Piefel
|=| Humboldt-Universität zu Berlin
|=| Tel. (+49 30) 2093 3831

Re: tmda: Challenge-response is fundamentally broken

[Tore Anderson]

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.

* 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.
 >
 > Before you respond to this I suggest you re-read Debian's Social Contract 
 > and the section of the Maintainer's Guide pertinent to bug severities.

  You just spammed me with one of your "challenges", Adam.  I do not
 think I have ever before sent you an e-mail, and I am 100% certain I
 have never sent you any trojan horse designed to break Microsoft
 Outlook.  Upon inspection of the headers, I see you did so even after
 the message scored >10 in your SpamAssassin filter.  Surely you are
 aware of the fact that such junk mail tend to have forged From:
 headers?

  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?

  How many Debian users have installed this package, and has as a result
 begun sending junk mail to innocent third parties, without even being
 aware of it?

  Think about it for a while, then you go read up on the Social contract,
 more specifically the clause stating what our priorities are.

  This program is no better than the brain-damaged content filters that
 has plauged debian-devel and countless mailboxes with the idiotic
 "you have attempted to send [EMAIL PROTECTED] a virus!"-allegations.
 Although it may relieve the junk mail flow to your and other
 TMDA/content filter users' mailboxes, it does nothing but add to the
 problem for other e-mail users around the globe.

  In fact, I find the use of this program about as disgusting as the
 sending of the original unsolicited message -- in both cases you send
 other e-mail users junk mail for your own personal benefit.

  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.

  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.
  
-- 
Tore Anderson

osirusoft down

[martin f krafft]

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

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


pgpwWGXxzyNKs.pgp
Description: PGP signature

Patch needs Sponsor - 20 bugs left - sorted by mtime

[Goswin von Brederlow]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I went through the RC bug list and collected Bugs with trivial patches
> and sorted them a bit. They realy don't need much work so if you have
> a minute pick one. If you want to NMU any of them check the
> then currently claimed bugs (url under claimed bugs).

Only 20 Bugs remaining. This time I sorted the list by the time of the
last mail to the BTS. (Ignore the last few. Anything looked at this
week is probably taken up by someone).

MfG
Goswin


TITLE #191199:  savant: FTBFS: g++ 3.2 errors
Severity:   serious
Package:savant
Age:120 days
Last changed:   117 days

TITLE #167054:  FTBFS: Build failure of xview on i386
Severity:   serious
Package:xview
Age:301 days
Last changed:   88 days

TITLE #173762:  FTBFS: Build failure of haddock on i386
Severity:   serious
Package:haddock
Age:249 days
Last changed:   53 days

TITLE #190260:  tidy: Segmentation fault on alpha
Severity:   grave
Package:tidy
Age:126 days
Last changed:   52 days

TITLE #191197:  rats: Fails to build with current flex
Severity:   serious
Package:rats
Age:120 days
Last changed:   45 days

TITLE #166737:  FTBFS with gcc 3.2
Severity:   serious
Package:snmpkit
Age:303 days
Last changed:   42 days

TITLE #102675:  libggi2-dev: should provide static archives
Severity:   serious
Package:libggi2-dev
Age:789 days
Last changed:   37 days

TITLE #204456:  libjdom-java: Wrong build-dep: does not need xalan2 nor saxon
Severity:   serious
Package:libjdom-java
Age:19 days
Last changed:   18 days

TITLE #195527:  mysql++: FTBFS with g++-3.3: Missing  include
Severity:   serious
Package:mysql++
Age:87 days
Last changed:   15 days

TITLE #192545:  pcb: Fails to build with current flex
Severity:   serious
Package:pcb
Age:110 days
Last changed:   11 days

TITLE #196149:  mkswap creates invalid swap files
Severity:   grave
Package:util-linux
Age:83 days
Last changed:   7 days

TITLE #196850:  wall is being distributed under wrong license
Severity:   serious
Package:util-linux
Age:78 days
Last changed:   7 days

TITLE #184885:  LSB 1.3 test suite failures
Severity:   serious
Package:util-linux
Age:164 days
Last changed:   7 days

TITLE #203750:  log4cpp: FTBFS: `long long' error
Severity:   serious
Package:log4cpp
Age:26 days
Last changed:   7 days

TITLE #194164:  preferences-app: FTBFS with gobjc-3.3: #import is obsolete
Severity:   serious
Package:preferences-app
Age:97 days
Last changed:   6 days

TITLE #194168:  preferences: FTBFS with gobjc-3.3: #import is obsolete
Severity:   serious
Package:preferences
Age:97 days
Last changed:   6 days

TITLE #195546:  poppassd: FTBFS with gcc-3.3: Uses obsolete varargs.h
Severity:   serious
Package:poppassd
Age:87 days
Last changed:   6 days

TITLE #201903:  xt: (m68k/unstable) FTBFS
Severity:   serious
Package:xt
Age:39 days
Last changed:   4 days

TITLE #203823:  gnuyahoo: FTBFS: automake error
Severity:   serious
Package:gnuyahoo
Age:25 days
Last changed:   4 days

TITLE #204859:  perl makes abiword FTBFS (unstable/m68k): fails to build, bad 
C++
Severity:   serious
Package:perl
Age:16 days
Last changed:   3 days

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Andreas Tille]

On Wed, 27 Aug 2003, Michael Piefel wrote:

> > Moreover I do not like the new hot keys because I was comfortable with
> >   {,}  to go  {back,foreward}
> Revert to galeon 1.2 because you have to press Alt instead of Ctrl?
> Come on!
This was intentionally not mentioned as missing features compared to Galeon 1.2
but as a would be nice to have feature if hot keys would be configurable and
if you would have tried to parse my mail again I was not voting against 1.3.x
Galeon but against having no Galeon at all.

Kind regards

Andreas.

Bug#206187: apt-get update fails to get index package list and therefore does nothing

[Josip Rodin]

On Wed, Aug 27, 2003 at 11:07:22AM +0200, Sasha Volkoff wrote:
> The only way I could eliminate this warning was putting LC_ALL=C, but this 
> is how it is already working now.
> 
> I tried what you suggested me, and this is what I got:
> "/usr/sbin/dpkg-reconfigure: locales is not fully installed".
> 
> So i tried this:
> "mafalda:~# apt-get install locales
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Sorry, locales is already the newest version."
> 
> Anyway, it doesn't seem to be very important.

Perhaps, but it may be indicative of a larger problem.

Try apt-get install locales --reinstall

-- 
 2. That which causes joy or happiness.

Re: galeon in Debian stable

[Jordi Mallach]

On Wed, Aug 27, 2003 at 08:40:39AM +0100, Mark Howard wrote:
>   It's great to see so many positive comments about galeon. Hopefully
> 1.3.8 will go into stable. [galeon developers - is this likely to be
> released in the next 3 weeks, or should we really be looking at 1.3.7?].
> If that's not released in a few weeks, I think we would be best looking
> at a well tested cvs snapshot - there have been many great changes since
> that release (5% of the changelog in only 1 month!).
> I'll make a new snapshot package and upload to unstable tonight. I might
> then use experimental for new snapshots for a while when trying to get
> at least one version of galeon 1.3 into testing. Once 1.3.8 (or wherever
> we decide to freeze) is in unstable I will also continue to make
> snapshots for those of us who want them and upload these to
> experimental.

Way to go Mark! I'm looking forward to 1.3.8, sounds promising :)

>   When I replaced the unbuildable, uninstallable galeon1.2 in sid with
> 1.3 snapshots from the galeon-snapshot package I was sent a lot of
> flames (and so was the bts). This was obviously counterproductive (as was
> the similar situation happening upstream around the time of the epiphany
> fork). That's why I wanted a decision to include galeon to be made on
> debian-gtk-gnome rather than taking all the responsibility myself :) 
> (I was also concerned about releasing a developmental version in stable
> - this is my first Debian release after all)

You learn a lot in release cycles. I, for example, did a big mistake
with nano during the woody freeze, which caused nano in woody not be as
good as it should have been. I basically uploaded an unstable version of
nano to debian unstable, thus blocking the possibility of providing
fixes to the stable nano in testing. First I thought nano 1.0.6 was
perfectly ok, but then we found out that the boot-floppies needed a
feature in 1.0.8...

In your case, there's no choice. 1.3.x is the best version we have, and
nearly everyone is happy with it.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/


pgpFL8o4yApAH.pgp
Description: PGP signature

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

[Peter Makholm]

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.


0) Substitute for any MTA you like or dislike.

-- 
 Peter Makholm | Have you ever felt trapped inside a Klein bottle?
 [EMAIL PROTECTED] |  
 http://hacking.dk |  

Re: tmda: Challenge-response is fundamentally broken

[Stephen Stafford]

[enormous snippage]

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.  

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.

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

Stephen


pgpngUSCQUk8G.pgp
Description: PGP signature

Re: DebToo: Debian, Gentoo-style

[Martin Schulze]

Chris de Vidal wrote:
> Volunteers needed!
> http://debtoo.org

I guess you haven't read

Benchmarking Debian's Performance. Indranath Neogy tried to
[35]discover what kind of gains the source based nature of Gentoo
might give it over Debian and Mandrake. The tests included timing how
long it took to open a large sheet in Gnumeric, how long to compile
the Linux kernel and how long to perform various operations in GIMP.
Gentoo was expected to lead in the tests, but the results showed no
significant variation between the distributions. Simple recompiling
doesn't seem to speed things up, fine grained tuning may.

 35. 
http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1

before assuming that recompiling everything will benefit *anything*?

Apart from that, you'd better help fix those FTBFS bugs and see that
the source packages are conforming with the current policy, contain
enough build-deps and -conflicts and that sbuild, pbuilder and
whatever are able to rebuild the package to your need.  After that,
it's a "simple" dpkg --get-selections|grep install|cut -d' ' -f1|
while read p; do $rebuild-command $p; done[1].


Btw. it's "author" and not "auther".

Regards,

Joey

[1] Not exactly, but in general...

-- 
WARNING: Do not execute!  This software violates patent EP0394160.
http://www.elug.de/projekte/patent-party/patente/EP0394160

echo -ne PROGRESSBAR\\r;for i in `seq 11`;do sleep 1;echo -n -;done;echo

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

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

[Josip Rodin]

On Wed, Aug 27, 2003 at 01:07:04AM -0500, Branden Robinson wrote:
> > Well, correction, cgi.d.o does almost nothing these days. But lists.d.o
> > requires resources pretty much continuously, what with all the mhonarc,
> > glimpse, stats updates and users accessing web pages and its CGI scripts.
> > 
> > And again, this is for -project, not for -devel. :<
> 
> Maybe debian-devel-annnounce.  We can't have master being DoSsed.

It's basically an isolated incident. Reminding people to not be foolish like
that may not actually prevent further foolishness :)

-- 
 2. That which causes joy or happiness.

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Nikolaus Rath]

Michael Piefel <[EMAIL PROTECTED]> wrote:
>>- 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?

I just updatet to the latest version from experimental and I still
don't have this menu. Did you change something with gconftool?

   --Nikolaus

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

[Masato Taruishi]

> I was looking at the various stats programs(http://master/mrtg/), and noticed
> that for the last week, master's incoming bw, outgoing bw, and load, have been
> unusually high.
> 
> After some digging, I found 2 main causes.
> 
> 1: The apt-listbugs author has seemed it nescessary to export all debbugs
>data, by way of a symlink, and then to allow admins to request bug reports
>when packages get updated.  This was not done with any consultation with
>any BTS admin, nor any admin that is invovled in the machine that would be
>handling this increased load.

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.

Anyway, i have to work for something to solve this problem. Currently, i
have a plan to make a mirror site for apt-listbugs (i didn't have a such
site) and if index.db will have subject, then apt-listbugs doesn't need
to fetch .status file at all.

>A quick grep thru the access.log for the bts, shows 116k total lines, and
>48k lines are for apt-listbugs, requesting .status files, or the index
>files.
> 
>What is not shown, is the requests for the actual bug reports.  These can't
>be easily tracked, as apt-listbugs uses querybts(from reportbug), and a few
>other fallbacks, so it's not easy to match up those lines.

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.

Actually, apt-listbugs has cgi to fetch bug reports, but it's not a 
default action. In addition, when apt-listbugs uses cgi directly, it 
sends user-agent which shows apt-listbugs.

-- 
Masato Taruishi <[EMAIL PROTECTED]>

Re: tmda: Challenge-response is fundamentally broken

[Lars Wirzenius]

On ke, 2003-08-27 at 13:44, Stephen Stafford wrote:
> 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.  

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.

Whether TDMA's behavior is bad enough to warrant removal from Debian I
don't know. (It is an issue I find it hard to be objective about.)

-- 
http://liw.iki.fi/liw/photos/swordmaiden/

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

[Andreas Barth]

* Mark Howard ([EMAIL PROTECTED]) [030826 21:35]:
> On Tue, Aug 26, 2003 at 03:46:33PM +0200, Andreas Barth wrote:
> > 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.)

> Why do you need many changes?

Because you can select your applications from experimental und the
basic libraries not. If you have a chains of four dependencies (e.g.
for kde) where you can independly select whether from experimental or
not, you'll end up with 16 variants. You may perhaps get some out of
the same files, but not all. And you can't (trivially) put more a
package more than once with the exactly same version number in the
pool. We're having this problem with subarchitectures (a thing more
prominent to solve IMHO), and it would be far worse here.


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

Re: tmda: Challenge-response is fundamentally broken

[Tore Anderson]

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

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

-- 
Tore Anderson

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

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

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

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

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

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

[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

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

[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: 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: 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: 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: 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.

unsubscribe

[David Riebenbauer]

unsubscribe

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

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

thanking u

[hishashi11]

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

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   *

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

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

[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

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