Re: Every spam is sacred: tagging mails because of their content or their supposed origin?

[Colin Walters]

On Mon, 2003-06-16 at 19:33, Joey Hess wrote:

> Today I noticed those summaries were getting spamassassing scores in the
> 30 range. I ended up whitelisting myself, though that doesn't feel like
> a good idea -- now SA might mislearn spam subjects as ham, and any
> spammer who forges mail from me will probably get through.
> 
> Aside from bypassing SA entirely for local mail, is there any better
> approach?

You could add a special keyword into the summaries, and have its
spamassassin score be -1000 or whatever.

Re: Bug#196800: flex mustn't assume stdint.h is available on allplatforms

[Neil Roeth]

On Jun 13, Daniel Jacobowitz ([EMAIL PROTECTED]) wrote:
 > On Fri, Jun 13, 2003 at 06:02:02PM -0500, Manoj Srivastava wrote:
 > > On Fri, 13 Jun 2003 18:20:37 -0400, Daniel Jacobowitz <[EMAIL PROTECTED]> 
 > > said: 
 > > 
 > > > On Thu, Jun 12, 2003 at 08:40:47PM -0500, Manoj Srivastava wrote:
 > > >> On Thu, 12 Jun 2003 15:22:17 -0400, Daniel Jacobowitz
 > > >> <[EMAIL PROTECTED]> said:
 > > >>
 > > >> >> You need to read up on your standards. The language called C is
 > > >> >> defined by only one authoritative standard.
 > > >> >> --
 > > >> >> ISO/IEC 9899:1999 (E) (C)ISO/IEC
 > > >> >>
 > > >> >> Contents ix
 > > >> >>
 > > >> >> 5 This second edition cancels and replaces the first edition,
 > > >> >> ISO/IEC 9899:1990, as amended and corrected by ISO/IEC
 > > >> >> 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and ISO /IEC
 > > >> >> 9899/COR2:1996.
 > > >> >>
 > > >> >> --
 > > >> >>
 > > >> >> Thus, I need have no such qualifiers when talking abouit
 > > >> >> conforming C implmentations.
 > > >>
 > > >> > Given the real-world deployment of probably at least a dozen
 > > >> > major OSs which were 9899:1990 conformant and predate the
 > > >> > 9899:1999 standard, I'd say that's a pretty useless point of
 > > >> > view.
 > > >>
 > > >> OOh, I am blinded by the cogency of your arguments.
 > > >>
 > > >> C99 is over 3 years old.
 > > 
 > > > And still not fully implemented.  Unstable only switched to a
 > > > compiler with minimal C99 support some months ago.  GCC has no
 > > > roadmap for implementing the remaining C99 features so it may be
 > > > years before they are available on free operating systems.
 > > 
 > >And? You seem to be implying (incorrectly), that flex requires
 > >  more of C99 than is already present in Debian and a post 2.95
 > >  gcc. The new flex has been compiled, and has all the test suites
 > >  succesfully compile, on all 11 architectures Debian supports. 
 > > 
 > > >> For ancient platforms, use flex-old.
 > > >>
 > > >> Anyway, you are certainly entitled to your opinion, and you can do
 > > >> whatever you want with your packages and your code.
 > > 
 > > > I am somewhat distressed that the version of flex provided with
 > > > Debian (I am assuming from the discussion) will not be usable for
 > > > cross-platform development without constant care to use flex-old
 > > > instead.  We've finally persuaded binutils and GCC to move into the
 > > > era of C90 source.  I don't think we'll see C99 widely enough
 > > > supported to write portable software using it until 2008 at least.
 > > 
 > >Again you raise a strawman. Flex comes with a plethora of
 > >  tests, and all the tests have always been passed. Flex works with all
 > >  11 architectures that comprise debian (we have a mysterious test
 > >  failure on the most recent m68k run, though I think it may have more
 > >  to do with the new gcc there than anything else). 
 > > 
 > >Now, if you have any concrete objections as to why flex does
 > >  not work in Debian, please feeel free to point them out. If you
 > >  merely want to grumble about how flex may not work until 2008,
 > >  without providing a basis for such grumplings, I am sure I can't help
 > >  you there. 
 > 
 > You have missed my point.  I am quite aware that flex-generated lexers
 > will continue to work on all Debian platforms.  But until C99 is much
 > more mature than it is today, many other significant platforms will not
 > have a C99-compatible compiler - even to the degree of including
 > .  Therefore Debian becomes more awkward for cross-platform,
 > portable development.  Not useless, because of flex-old, but certainly
 > more awkward; I will not be able to build Debian packages which require
 > a recent flex in the same root in which I build cross-platform
 > software.
 > 
 > Certainly you have not broken Debian; but I maintain that this
 > short-sightedness does damage Debian's usefulness as a development
 > platform, for all those targets which many more practical developers
 > must support in order to do their jobs.

I think this is an excellent point.  I can think of many times when I've done
development work in Debian and ported the result to Solaris, IRIX or HPUX.  It
is, of course, not a requirement for Debian that this be easy, but the easier
it is, the more convincing the argument for integrating Debian into a mixed
*nix environment, for everyone from developers to CIOs.

-- 
Neil Roeth

Re: Every spam is sacred: tagging mails because of their content or their supposed origin?

[Joey Hess]

Duncan Findlay wrote:
> The only negative rules will be: bayesian rules, bondedsender and
> habeas. Figuring how to autolearn ham (non-spam) is the only obstacle
> we still need to figure out.

This is fairly off topic, but the other day I tired of downloading all
my spam to check it for false positives, and so I whipped up a script to
produce an index of a mailbox, with author and subject lines and sorted
by SA score, and cronned it so I'd be mailed a daily summary to peruse.

Today I noticed those summaries were getting spamassassing scores in the
30 range. I ended up whitelisting myself, though that doesn't feel like
a good idea -- now SA might mislearn spam subjects as ham, and any
spammer who forges mail from me will probably get through.

Aside from bypassing SA entirely for local mail, is there any better
approach?

-- 
see shy jo


pgpei9U6oNYFn.pgp
Description: PGP signature

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Joey Hess]

Manoj Srivastava wrote:
> >> Good point. Shall we mandate that all bug closures be adequately
> >> documented in the ChangeLog? I would be quite happy with that.

>   I do think bug closures be documented in the ChangeLog (I
>  shall attempt to do so from now on for every real bug that is closed
>  for my packages). I shall not upload for every item in my changelog. 

Like so?

debhelper (4.1.48) unstable; urgency=low

  * Not adding ld.so.conf parsing code for libraries, if your library is not
in a usual path, use the standard -X option to dh_makeshlibs to skip it.
Closes: #122174
  * No, I don't think that adding rm -rf /tmp to postinsts is a good idea.
Closed: #201012
  * Reasigned bugs #133949 and #123043 to dh-make, since dh_make is not in
debhelper. When will people learn?
  * debhelper won't include a dh_installrootkit until I see more demand for
such a program. Closes: #37337
  * I fixed the "debhelper overwrites libc" bug back in 1999, why am I still
getting reports about it? Sheesh. Closed: #393933, #209202, #384821
  * Yes, debhelper and debconf do indeed have recursive build-depends. Deal.
Closed: #197602
  * In the last release I made a typo, and accidentially closed bug #196343,
not #196344. I've reopened the former bug. Closes: #196344
  * Trimmed the last 500k of the changelog; it was 90% of the entire package
size since it recorded every dismissed feature request and dh-make bug
for the past 6 years.
  * Fixed a typo in dh_python. Closes: #197679

 -- Joey Hess <[EMAIL PROTECTED]>  Mon, 16 Jun 2003 16:58:27 -0400

-- 
see shy jo


pgpw7OVNsQEkU.pgp
Description: PGP signature

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Colin Watson]

On Mon, Jun 16, 2003 at 04:04:55PM -0500, Manoj Srivastava wrote:
> On Mon, 16 Jun 2003 09:36:24 +0100, Colin Watson <[EMAIL PROTECTED]> said: 
> > On Sun, Jun 15, 2003 at 11:42:44PM -0500, Manoj Srivastava wrote:
> >> Good point. Shall we mandate that all bug closures be adequately
> >> documented in the ChangeLog? I would be quite happy with that.
> 
> > Ai. Er, I hope you're not planning to encourage people to upload new
> > versions of packages just to add bug numbers to the changelog?
> > Because that would be most inefficient and wrong.
> 
>   *Sigh*. Has common sense totally escaped the world? I never
>  indicated that one upload every other minute or whenever something is
>  added to the changelog.
> 
>   I do think bug closures be documented in the ChangeLog (I
>  shall attempt to do so from now on for every real bug that is closed
>  for my packages). I shall not upload for every item in my changelog. 
> 
>   And note this does not involve time travel; my changelog would
>  document the bug was closed, and explain why: the fact that the
>  change was made in the past is OK.

At least don't use the Closes: syntax to do so, please. That will be a
very good way to confuse attempts to track version information ...

(By now I can't tell whether this is regarded as common sense or not,
sorry.)

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Every spam is sacred

[Dan Jacobson]

By the way some folks live in countries considered spam countries by
other people, and they can't get a email in edgewise to the high class
users.

By the way how about my http://jidanni.org/comp/spam/spamdealer.html
solution for the little guy, remote and without root.
-- 
http://jidanni.org/ Taiwan(04)25854780

RECORD?

[Biggie1110]

hey do you happen to know the world record for f1 2000...time trial at indianapolis

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Manoj Srivastava]

On Mon, 16 Jun 2003 09:36:24 +0100, Colin Watson <[EMAIL PROTECTED]> said: 

> On Sun, Jun 15, 2003 at 11:42:44PM -0500, Manoj Srivastava wrote:
>> On Mon, 16 Jun 2003 08:36:20 +1000, Herbert Xu
>> <[EMAIL PROTECTED]> said:
>> > Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> >> If it caused a Debian bug to be closed, that is a significant
>> >> change in status for the Debian package (it may not be for the
>> >> upstream software being packaged, but it is for my package).
>>
>> > What if the bug was reported after the new Debian package was
>> > uploaded?  Why does it suddenly stop being a significant change?
>>
>> Good point. Shall we mandate that all bug closures be adequately
>> documented in the ChangeLog? I would be quite happy with that.

> Ai. Er, I hope you're not planning to encourage people to upload new
> versions of packages just to add bug numbers to the changelog?
> Because that would be most inefficient and wrong.

*Sigh*. Has common sense totally escaped the world? I never
 indicated that one upload every other minute or whenever something is
 added to the changelog.

I do think bug closures be documented in the ChangeLog (I
 shall attempt to do so from now on for every real bug that is closed
 for my packages). I shall not upload for every item in my changelog. 

And note this does not involve time travel; my changelog would
 document the bug was closed, and explain why: the fact that the
 change was made in the past is OK.

manoj
-- 
I owe the public nothing. J.P. Morgan
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Manoj Srivastava]

On Mon, 16 Jun 2003 19:51:07 +1000, Herbert Xu <[EMAIL PROTECTED]> said: 

> Colin Watson <[EMAIL PROTECTED]> wrote:
>> On Sun, Jun 15, 2003 at 11:42:44PM -0500, Manoj Srivastava wrote:
>>
>>> > What if the bug was reported after the new Debian package was
>>> > uploaded?  Why does it suddenly stop being a significant change?

> This is meant to be a rhetorical question.

It turned out to be closer to the mark than you suspected ;-)

>> My answer to Herbert would be "it would be nice, but unfortunately
>> time travel is not yet among our capabilities".

> Which just proves that listing things in the changelog on the basis
> of bug reports is meaningless.  Listing things that actually have
> changed in Debian is what it was meant for in the first place. 

I disagree. Changelogs for debian packages should document all
 changes that happened to the package -- and this include bugs that
 were closed, and the reaons thereof. No inconsistency.

Thank you for helping me make my argument.

manoj
-- 
In any problem, if you find yourself doing an infinite amount of work,
the answer may be obtained by inspection.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Every spam is sacred: tagging mails because of their content or their supposed origin?

[Duncan Findlay]

On Mon, Jun 16, 2003 at 04:43:53PM -0400, Don Armstrong wrote:
> On Mon, 16 Jun 2003, Duncan Findlay wrote:
> > The only negative rules will be: bayesian rules, bondedsender and
> > habeas. Figuring how to autolearn ham (non-spam) is the only obstacle
> > we still need to figure out.
> 
> Sure sounds like throwing the baby out with the bathwater... but I
> presume you all are running statistics on email distributions...

Eventually, spammers will forge any test they can. (This of course
presumes that spamassassin is a big problem for spammers.) It's
extreme, but necessary.

All the spamassassin scores are generated with a genetic algorithm
using results from about 150k spam and 150k non-spam. The scores will
naturally be adjusted to compensate for the lack of negative scoring
rules.

Anyways, this is quite OT for debian-devel (although so is the vast
majority of this thread).

-- 
Duncan Findlay

pgpeCXv0A64y5.pgp
Description: PGP signature

Re: Every spam is sacred

[Manoj Srivastava]

On Mon, 16 Jun 2003 16:18:49 +1000, Russell Coker <[EMAIL PROTECTED]> said: 

> On Mon, 16 Jun 2003 15:06, Manoj Srivastava wrote:
>> > There is no excuse for this.  Access to servers that are not in
>> > spam lists is well available to Debian developers.  I tunnel my
>> > outgoing mail through a server in Melbourne no matter where I am,
>> > this avoids all issues of spam blocking by IP address.  I offered
>> > accounts on a choice of machines to be used for such purposes for
>> > any Debian developers who have no better options, but so far
>> > no-one has taken me up on this offer.
>>
>> I refuse to allow spammers this victory. My machines are fully
>> capable members of the internet, and I deliver my own email. My
>> philosophy is that if people drop mail from me due to incompetence
>> (since setting up machines to classify email from me as spam is
>> indeed a misconfiguration), then I have no real desire to impose my
>> musings on them.

> If your machines are fully capable then they will have permanent IP
> addresses and no spam ever coming from them.  In which case they
> will never get listed in a DNSBL (*) and there is nothing to be
> concerned about.

They are, when I send mail from home, or when I trael to the
 office. However, I often send mail from the road (or the internet
 cafe) where dhcp often rules. 

manoj
-- 
"The only way for a reporter to look at a politician is down."
H.L. Mencken
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Packages preventing other packages from going into testing (fwd)

[Jacob Hallén]

J.H.M. Dassen (Ray) wrote:
>On Sun, Jun 15, 2003 at 18:44:12 +0200, Jacob Hallén wrote:
>> I have written a little Python program that analyses
>> http://ftp-master.debian.org/testing/update_excuses.html
>> to find out where the bottlenecks are for packages going into testing.
>> Essentially, it is a count of packages that directly and indirectly depend 
on 
>> a package with at least one RC bug before they can go into testing.
>
>Maybe I'm missing something, but it looks like you're reinventing
>http://bjorn.haxx.se/debian/

Yes, you are missing a small but important thing. Björns program is designed 
to answer the question "Why is package X not in testing?". It does this very 
well and has lots of nifty features I didn't put into mine.

My program answers the question "Where will an extra effort produce drastic 
results?" I'm sure I could have modified Björns program to yield this output, 
but I don't read and write Perl programs for pleasure.

I think it is important to have a tool that answers my question and does so 
in a terse form that is pruned of all irrelevant data. 

If Testing is much closer to resleasable than it is now, it will be so much 
easier to make decisions about what to do with the few packages that are not 
ready for a release and so much easier to make a time plan for when to 
release.
I know that releases are made when "everything is ready", but this still 
means that some packages have to be dropped from the release and you have to 
make an extra effort for some time (bug squash parties etc) before a release 
is possible. Having luked on the Debian lists for many years, I think the 
next release will be more of a challenge than any of the earlier ones. Too 
few of the developers are really focused on what it takes to make a release. 
If there isn't change, I'm not sure there will ever be another stable release.

Jacob Hallén

Re: Every spam is sacred

[Keegan Quinn]

On Friday 13 June 2003 05:13 pm, Don Armstrong wrote:
> Oh, what the hell. This damn song won't get out of my head, so now you
> all get to be subjected to it to[1]:

FWIW, the original version of this song has also been in my head for weeks.  
Thanks for digging up the full text :)

> 1: Misery loves company.

Ad infinitum.

Re: Every spam is sacred: tagging mails because of their content or their supposed origin?

[Don Armstrong]

On Mon, 16 Jun 2003, Duncan Findlay wrote:
> The only negative rules will be: bayesian rules, bondedsender and
> habeas. Figuring how to autolearn ham (non-spam) is the only obstacle
> we still need to figure out.

Sure sounds like throwing the baby out with the bathwater... but I
presume you all are running statistics on email distributions...


Don Armstrong

-- 
Any excuse will serve a tyrant.
 -- Aesop

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


pgpGEO5lz6saB.pgp
Description: PGP signature

Re: Fun with python-apt

[Bernd Eckenfels]

On Mon, Jun 16, 2003 at 03:46:13PM -0400, Anthony DeRobertis wrote:
> Now, if we changed sarge to use g++-c102 (as I briefly suggested), 
> would that prevent this problem in sarge+1 or sarge+2 or whenever the 
> ABI changes again?

no, because we WANT the packages beeing build with the new abi. We jus twant
to make sure that lib providing pakcages are built with the same gcc as lib
consuming ones. 

Using the latest gcc is the simplest solution, since this sooner or later
will succeed, hopefully the packages with the unsatisfied dependencies are
bug marked before they can break testing :)

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: gcc 3.3 - what problems should I expect?

[Jean Pierre LeJacq]

Quoting Krzysztof Kajkowski <[EMAIL PROTECTED]>:

> I'm intending to move to SID from my woody box. I was wondering what
> problems should I expect while building packages using new gcc 3.3. Does
> kernel 2.4.21 build correctly? What about other progs like mplayer,
> mozilla etc? Can I install gcc 3.2 (f.egz. from testing)?

I've successfully built 2.4.20 with gcc 3.3 from unstable.  I've
been running it for about a week now with no problems.

For an in-house C++ application, I had a bit of work to port it
from 3.2 to 3.3.  Most of the issues where concerned with better
detection by gcc of non-standard usage.  Once I fixed the code,
the application compiled cleanly and ran without problems.

-- 
Jean Pierre

Re: Fun with python-apt

[Anthony DeRobertis]

On Monday, Jun 16, 2003, at 11:04 US/Eastern, Matt Zimmerman wrote:
Which, of course, does not help with the situation he originally 
reported
(building a woody package on testing with a newer compiler than was
originally used).  Time travel is still required there. :-)
Agreed. To fix Woody requires time travel. [Or the ftpmasters going 
insane.]

Now, if we changed sarge to use g++-c102 (as I briefly suggested), 
would that prevent this problem in sarge+1 or sarge+2 or whenever the 
ABI changes again?

Re: Fun with python-apt

[Anthony DeRobertis]

On Monday, Jun 16, 2003, at 14:59 US/Eastern, Bernd Eckenfels wrote:
it works in this case if you build all the packages your package 
depends on,
like the build is doing, because in that case apt wopuld habe been new 
abi,
too.
Yeah, but then again, its quite superfluous in that situation, too. 
Depending on gcc >= 3.2 or gcc >= 3.3 only makes sure the autobuilders 
don't build your supposedly new-ABI package with the old GCC.

Re: Fun with python-apt

[Anthony DeRobertis]

On Monday, Jun 16, 2003, at 02:50 US/Eastern, Andreas Metzler wrote:
Build-Depends: g++ (>= 3:3.2.2-0)
Many transitioned packages use(d) this to guarantee that the correct
compiler was used.
That doesn't guarantee the correct compiler. It could, for example, use 
gcc 3.4 which could have yet another C++ ABI.

Depending on c102 and then using "g++-c102" would not allow that.

Scripts for plotting mailinglist statistics

[Auke Jilderda]

Hi,

I want to gain some insight in how well my bayesian spam filter [1,2] 
works over time and, hence, want to plot the trends of my regular inbox 
in comparison to my spambox (that is, the spam properly identified as 
spam) and the false negatives (not identified as spam).  

The statistics as generated on the Debian website [3] seems to already 
implement exactly what I want but I cannot find the scripts that generate 
them.  Does anybody know who maintains them and/or if they are available 
some place?

Thanks a lot,


Auke

 1.  http://www.paulgraham.com/spam.html
 2.  http://pauillac.inria.fr/~xleroy/
 3.  http://lists.debian.org/stats/debian-www.png

-- 
PGP 0x4A34DD6D, http://bunny.sourceforge.net/

Re: Every spam is sacred

[John H. Robinson, IV]

Mathieu Roy wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> a tapoté :
> > 
> > The 127th Ferengi rule of acquisition: Even if you got it for
> >  free, you paid too much.
> 
> But the Rule 37th says otherwise: "If it's free, take it and worry
> about hidden costs later". 
> 
> But the 96th confirms that "For every Rule, there is an equal and
> opposite Rule, (except when there's not)". 

interesting. i found this: http://www.dmwright.com/html/ferengi.htm 

Rule 127 » Stay neutral in conflict so that you can sell supplies to both sides.

Manoj, perhaps you were thinking of this one: (same source)
Rule 011 » Even if it's free, you can always buy it cheaper.

-john

Re: Red-Handed SCO ?

[Martin List-Petersen]

On Mon, 2003-06-16 at 20:14, John Hasler wrote:
> Martin List-Petersen writes:
> > So anybody that has got a copy of the written offer can go to SCO
and
> > require the Source, even if they didn't buy the Product.
> 
> However, if SCO fails to comply only the copyright owner can sue.

That is correct .. And the first has allready said "no no", as that
article stated. It's also mentioned on Slashdot under "Settling SCOres"

Regards,
Martin List-Petersen
martin at list-petersen dot dk
--
We are MicroSoft.  You will be assimilated.  Resistance is futile.
(Attributed to B.G., Gill Bates)


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

gcc 3.3 - what problems should I expect?

[Krzysztof Kajkowski]

Hello!

I'm intending to move to SID from my woody box. I was wondering what
problems should I expect while building packages using new gcc 3.3. Does
kernel 2.4.21 build correctly? What about other progs like mplayer,
mozilla etc? Can I install gcc 3.2 (f.egz. from testing)?

regards

cayco

Re: Fun with python-apt

[Bernd Eckenfels]

On Mon, Jun 16, 2003 at 11:04:17AM -0400, Matt Zimmerman wrote:
> Which, of course, does not help with the situation he originally reported
> (building a woody package on testing with a newer compiler than was
> originally used).  Time travel is still required there. :-)

it works in this case if you build all the packages your package depends on,
like the build is doing, because in that case apt wopuld habe been new abi,
too.

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: Red-Handed SCO ?

[John Hasler]

Martin List-Petersen writes:
> So anybody that has got a copy of the written offer can go to SCO and
> require the Source, even if they didn't buy the Product.

However, if SCO fails to comply only the copyright owner can sue.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Every spam is sacred: tagging mails because of their content or their supposed origin?

[Duncan Findlay]

On Mon, Jun 16, 2003 at 10:03:45AM +0200, Josip Rodin wrote:
> On Sun, Jun 15, 2003 at 11:19:10PM -0400, Duncan Findlay wrote:
> > FWIW, the next version of spamassassin (2.60) will have no forgeable
> > negatively scoring rules. (ETA early-mid July)
> 
> Just out of curiosity, how will this be accomplished?

The only negative rules will be: bayesian rules, bondedsender and
habeas. Figuring how to autolearn ham (non-spam) is the only obstacle
we still need to figure out.

-- 
Duncan Findlay

pgptieP4vqlZ2.pgp
Description: PGP signature

Re: Red-Handed SCO ?

[Martin List-Petersen]

On Mon, 2003-06-16 at 12:36, Colin Watson wrote:

> I can't see any basis for the Inquirer's claim that anyone with a copy
> of Linux could sue. If SCO copied GPLed code into UnixWare, then the GPL
> only requires them to provide the source to those to whom they
> distribute object code or executable form, not to the whole world. (It
> can't restrict those people from passing on the source either, but
> that's another step further on.)
> 
> I'm not even sure that random UnixWare users could sue, although they
> could certainly write to SCO asking for the source. I would expect the
> litigants to be the copyright holders of misappropriated code.

It's funny that you mention it. This discussion has just been running on
the kernel list regarding to embedded wlan routers and SAN solutions
apparently based Linux.

They have to provide the source or a written offer to obtain the source.
The offer can be copied and given to anybody. So anybody that has got a
copy of the written offer can go to SCO and require the Source, even if
they didn't buy the Product.

But these are actually only 2 options of the GNU GPL. There was more to
it.

Regards,
Martin List-Petersen
martin at list-petersen dot dk
--
If God had wanted us to be concerned for the plight of the toads, he
would have made them cute and furry.
-- Dave Barry



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

Re: Status of Sarge Release Issues (Updated for June)

[Sven Luther]

On Sun, Jun 15, 2003 at 11:31:27PM +0200, Stefano Zacchiroli wrote:
> On Mon, Jun 02, 2003 at 02:38:47PM -0500, Drew Scott Daniels wrote:
> > 2 ocaml status?
> > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg00986.html
> > and bug 187155. Done?
> 
> Done! OCaml 3.06 has successfully entered testing with the whole set of
> correlated packages, including the Postgres bindings.

That said, depending on the upstream release plans for 3.07 and the
advancement of sarge, i have planes to ship sarge with ocaml 3.07. I
don't know if this will be possible dependency-wise in time, but
upstream is planning to release ocaml 3.07 in late july if everything
goes well, and it should not take us more than a month to have
everything testing-ready, but again, this would depend on the avancement
of sarge, and if it doesn't work out like that, ocaml 3.06 is now in
testing, and will not be replaced by 3.07 until 3.07 is ready to enter
testing.

Friendly,

Sven Luther

Re: Debian for x86-64 (AMD Opteron) and migration?

[Arnd Bergmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Monday 16 June 2003 09:12, Emile van Bergen wrote:

> # echo x86-64 >>/etc/dpkg/legal-archs
>
> or, if ordering matters,
>
> # echo x86-64 >/etc/dpkg/legal-archs.new
> # cat /etc/dpkg/legal-archs >>/etc/dpkg/legal-archs.new
> # mv /etc/dpkg/legal-archs.new /etc/dpkg/legal-archs

AFAICS, ordering should not matter for dpkg, it will simply 
install any legal package when asked to. I have currently
hardcoded the check for i386 packages into my amd64
dpkg...

> The biggest objection that was raised is that it will be necessary
> to make the source package for libreadline4 generate two packages,
> libreadline4 and lib64readline4. Same for all other libraries. IOW,
> there's no automatic way to create all these lib64* packages from
> source.

Currently, we are using a set of patches from Gerhard Tonn to
build libraries on amd64 and on s390x that minimize the necessary
source changes. Unfortunately, there has been no word about it
from any dpkg or debhelper maintainer.
See Bug #197117 and http://people.debian.org/~gt/lib64/.

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

iD8DBQE+7eql5t5GS2LDRf4RAkwZAKCPAzwoeCHpDdBTFlZKlKvExqy3gwCbBzzW
qS7btl9/G/tJeH7sNmVmaJg=
=PV0Q
-END PGP SIGNATURE-

Re: Bug#196800: flex mustn't assume stdint.h is available on allplatforms

[Alan Shutko]

Herbert Xu <[EMAIL PROTECTED]> writes:

> SuSv3 aka POSIX was released one year ago.

Huh?  POSIX is the same as SUSv3 now?  They used to be separate.

-- 
Alan Shutko <[EMAIL PROTECTED]> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
Ten animals I slam in a net

Re: Status of Sarge Release Issues (Updated for June)

[Rene Engelhard]

Hi,

Marcelo E. Magallon wrote:
> On Sat, Jun 14, 2003 at 09:19:19PM +0200, Christoph Hellwig wrote:
> 
>  > Stock OpenOffice seem to be able to embedd java applets into
>  > documents.  RedHat nuked this.
> 
>  And we can't do the same because ... ???

We have done that (as Jan wrote.)

Building needs Java anyhow...

Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73
  


pgpd1WqgWzCoW.pgp
Description: PGP signature

Re: Fun with python-apt

[Matt Zimmerman]

On Mon, Jun 16, 2003 at 08:50:59AM +0200, Andreas Metzler wrote:

> Build-Depends: g++ (>= 3:3.2.2-0)
> 
> Many transitioned packages use(d) this to guarantee that the correct
> compiler was used.

Which, of course, does not help with the situation he originally reported
(building a woody package on testing with a newer compiler than was
originally used).  Time travel is still required there. :-)

-- 
 - mdz

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Matt Zimmerman]

On Mon, Jun 16, 2003 at 07:51:07PM +1000, Herbert Xu wrote:

> Which just proves that listing things in the changelog on the basis of bug
> reports is meaningless.

No, it only shows that it is not possible under some circumstances:
specifically, when there was no bug report at the time.  To say that we
should not document any bugs because of this is analogous to saying that
since we cannot fix all of the bugs, we should not fix any of them.

-- 
 - mdz

Re: Every spam is sacred

[Josip Rodin]

On Mon, Jun 16, 2003 at 11:37:00AM +0200, Jesus Climent wrote:
> >  Given the ammount of spam that I get delived to my account via Debian
> >  machines, I guess the reduction in bandwidth usage by master and murphy
> >  is not to be taken lightly.
> 
> The reduction happens in the output,

Which is secondary, insignificant, right?

Here are some statistics for the BTS:

2003-04: mails received: 476 MB mails passed onto |receive: 66 MB
2003-05: mails received: 854 MB mails passed onto |receive: 79 MB
2003-06: mails received: 455 MB mails passed onto |receive: 36 MB

> but the load might increase in the server.

Watch the oidentds and bugscans on master some time... there are much better
ways to save machine load.

-- 
 2. That which causes joy or happiness.

Re: Red-Handed SCO ?

[Josselin Mouette]

Le lun 16/06/2003 à 11:44, José Luis Tallón a écrit :
> http://www.theinquirer.net/?article=9952
> 
> OK, it's the inquirer
> 
> 
> It it was proved to be true, shouldn't we *all* Linux users ( as well as 
> Stallman plus the FSF as a whole ) sue SCO for copyright infringement ???
> That could be *quite funny*  

I think only the copyright holders could sue them. That still make a few
hundred people and a few little companies like HP and IBM...
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Every spam is sacred

[Mathieu Roy]

Russell Coker <[EMAIL PROTECTED]> a tapoté :

> On Mon, 16 Jun 2003 19:37, Jesus Climent wrote:
> > >  account via Debian machines, I guess the reduction in bandwidth usage
> > >  by master and murphy is not to be taken lightly.
> >
> > The bandwidth reduction will only happen if you decide to discard the mail,
> > since the mail will always be accepted, scanned to find the IP which
> > originated the message, the IP will be checked agains the database and then
> > the mail will be tagged.
> 
> The usual implementation of DNSBL systems is to check the client IP address 
> as 
> soon as the TCP connection comes in, and disconnect with an appropriate error 
> message if it's an IP address that you don't like.
> 
> That saves a lot of bandwidth, and the mail is not discarded, it is left on 
> the sending machine to be bounced in an appropriate manner back to the 
> sender.


I think you missed the point: tagging mails is fine to everybody but
not blocking/discarding/bouncing mails (that can be done later, by
user, with their procmailrc).
So as only tagging will be done, no bandwidth will be saved.



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

Re: Red-Handed SCO ?

[Colin Watson]

[Please avoid posting messages that aren't about Debian development to
-devel. Moved to -curiosa, although -project or -legal would probably be
OK too.]

On Mon, Jun 16, 2003 at 11:44:41AM +0200, Jos? Luis Tall?n wrote:
> http://www.theinquirer.net/?article=9952
> 
> OK, it's the inquirer
> 
> 
> It it was proved to be true, shouldn't we *all* Linux users ( as well as 
> Stallman plus the FSF as a whole ) sue SCO for copyright infringement ???
> That could be *quite funny*  

I can't see any basis for the Inquirer's claim that anyone with a copy
of Linux could sue. If SCO copied GPLed code into UnixWare, then the GPL
only requires them to provide the source to those to whom they
distribute object code or executable form, not to the whole world. (It
can't restrict those people from passing on the source either, but
that's another step further on.)

I'm not even sure that random UnixWare users could sue, although they
could certainly write to SCO asking for the source. I would expect the
litigants to be the copyright holders of misappropriated code.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Every spam is sacred

[Russell Coker]

On Mon, 16 Jun 2003 19:37, Jesus Climent wrote:
> >  account via Debian machines, I guess the reduction in bandwidth usage
> >  by master and murphy is not to be taken lightly.
>
> The bandwidth reduction will only happen if you decide to discard the mail,
> since the mail will always be accepted, scanned to find the IP which
> originated the message, the IP will be checked agains the database and then
> the mail will be tagged.

The usual implementation of DNSBL systems is to check the client IP address as 
soon as the TCP connection comes in, and disconnect with an appropriate error 
message if it's an IP address that you don't like.

That saves a lot of bandwidth, and the mail is not discarded, it is left on 
the sending machine to be bounced in an appropriate manner back to the 
sender.

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

Re: Bug#196800: flex mustn't assume stdint.h is available on allplatforms

[Herbert Xu]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> 
>> SuSv3 aka POSIX was released one year ago. 
> 
>And changed nothing in the Lex definitions. As I said, we are
> dealing with decades old design.

Hmm you must've missed section 1.1 :)

The entire document is aligned with ISO/IEC 9899: 1.  There is no
requirement that lex generates code that is accepted by c89.

But of course this has no bearing on whether a particular implementation
chooses to be backwards compatible or not.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: RFC: fewer vim variants

[José Fonseca]

In article <[EMAIL PROTECTED]>, Luca Filipozzi wrote:
> Hello people,
> 
> I propose to restructure the vim package so that it builds fewer vim
> variants.
> 
> I propose to have only the following:
>   vim  (aka vim-tiny; no interpreters, no docs)
>   kvim (including all non-threaded interpreters; kde support; no docs)
>   gvim (including all non-threaded interpreters; gtk2 support; no docs)
>   vim-doc
> 
> Let me know if this rubs you the wrong way.

I think it's a good idea to merge the interpreters support. But
concerning the gnome support I think it would be better to have a
seperate package with gnome support as I did in the vim 6.2 patch (e.g., 
gvim-gnome ?)

If I'm not mistaken, the vim gnome support adds mostly session
management (when you login all your vim windows you had open on the
previous logout appear in the same positions and the same files), which
is something really handy. But of course, to add a dependency on gnome
for the non-gnome users would be too much. Therefore two packages...


José Fonseca


PS: I tried to reply via the news gateway but it didn't fall through. Sorry
if there's a dup.

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Herbert Xu]

Colin Watson <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 15, 2003 at 11:42:44PM -0500, Manoj Srivastava wrote:
>
>> > What if the bug was reported after the new Debian package was
>> > uploaded?  Why does it suddenly stop being a significant change? 

This is meant to be a rhetorical question.

> My answer to Herbert would be "it would be nice, but unfortunately time
> travel is not yet among our capabilities".

Which just proves that listing things in the changelog on the basis of
bug reports is meaningless.  Listing things that actually have changed
in Debian is what it was meant for in the first place.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Every spam is sacred

[Marcelo E. Magallon]

On Mon, Jun 16, 2003 at 11:37:00AM +0200, Jesus Climent wrote:

 > The bandwidth reduction will only happen if you decide to discard the
 > mail, since the mail will always be accepted, scanned to find the IP
 > which originated the message, the IP will be checked agains the
 > database and then the mail will be tagged.

 The IP that's checked in the DSBL is the one of the machine opening the
 connection to the MTA running at murphy/master.  You don't actually
 scan the email headers.  You are right that the bandwidth is decreased
 only if the mail is rejected instead of being just tagged, of course.

 > The reduction happens in the output, but the load might increase in
 > the server.

 Bandwidth is much more expensive than CPU time.  The bandwidth required
 by the DNS lookups can also be reduced by maintaining a local cache.

 Marcelo

Red-Handed SCO ?

[José Luis Tallón]

http://www.theinquirer.net/?article=9952
OK, it's the inquirer
It it was proved to be true, shouldn't we *all* Linux users ( as well as 
Stallman plus the FSF as a whole ) sue SCO for copyright infringement ???
That could be *quite funny*  

Regards,
J.L.

Re: Every spam is sacred

[Marcelo E. Magallon]

On Sun, Jun 15, 2003 at 02:17:23PM +0200, Santiago Vila wrote:

 > Read a previous message by Duncan Findlay. He said that 39.2668% of
 > all the spam might be blocked by using the DSBL, but doing that you
 > would block 0.0185% of ham.

 I just ran a quick test on my current email folders.  At the moment I
 have very little email stored in my Debian folders (198 messages
 actually).  I extracted IP addresses of machines connecting to master
 or murphy like this:

$ cd path/to/debian/mail
$ find -type f |
  while read f ; do
  formail -c -x Received < $f
  done |
  egrep 'by (murphy|master).debian.org' |
  perl -lne '/\[([0-9.]+)\]/ && print join(".", reverse (split /\./, $1))' |
  sort -n -u |
  grep -v '1\.0\.0\.127'

 That outputs 103 IP addresses.  Adding

  perl -pe 's/$/.list.dsbl.org/' |
  while read s ; do host $s ; done

 to that command I get a match for 175.90.65.4.list.dsbl.org

 Searching for the matchin message I get:

Subject: Someone for you.
Message-Id: <[EMAIL PROTECTED]>
X-Spam-Status: No, hits=3.5 required=5.0
tests=HTML_30_40,HTML_MESSAGE,MIME_HTML_ONLY,REMOVE_PAGE,X_LOOP,
  X_MAILING_LIST
version=2.55

 I'm sure I don't have to show you the email to convince you that it's
 spam.  Looking at my spam folder, I can extract 203 unique IP addresses
 (311 received emails) out of which 71 are *not* listed by
 list.dsbl.org.  I call that impressive.

 Feel free to come up with your own numbers using your own received
 email.

 Now the question again: why does debian-admin and/or listmaster oppose
 to running this in warning mode?  That'd be a much more accurate
 statistic since post-facto I can't tell if the IPs were added after
 observing the spam I'm testing with now, or if they were already
 present at the moment of reception.

 Marcelo

Re: Proposal for using SpamAssassin in master.d.o [Was: Re: Every spam is sacred]

[Jesus Climent]

On Sun, Jun 15, 2003 at 03:39:00PM +0200, Jesus Climent wrote:
> Hi.

[...] 

I might thing I spoke BS on my proposal, since I have not heard any
comments...

mooch

-- 
Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69
--
 Registered Linux user #66350 proudly using Debian Sid & Linux 2.4.20

I never drink ... wine.
--Dracula (Dracula)

Re: Every spam is sacred

[Jesus Climent]

On Thu, Jun 12, 2003 at 11:20:12PM +0200, Marcelo E. Magallon wrote:
> On Thu, Jun 12, 2003 at 02:18:57AM +0200, Santiago Vila wrote:
> 
>  > How can they say "no" to using some of them in /warn mode ... ?
> 
>  Santiago holds that more than half of the spam could be eventually
>  avoided.  I'd very much like to see hard evidence against or in favor
>  that assertion.  Given the ammount of spam that I get delived to my
>  account via Debian machines, I guess the reduction in bandwidth usage
>  by master and murphy is not to be taken lightly.

The bandwidth reduction will only happen if you decide to discard the mail,
since the mail will always be accepted, scanned to find the IP which
originated the message, the IP will be checked agains the database and then
the mail will be tagged.

The reduction happens in the output, but the load might increase in the
server.

mooch

-- 
Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69
--
 Registered Linux user #66350 proudly using Debian Sid & Linux 2.4.20

I say you are Lord, and I should know. I've followed a few.
--Arthur (Life of Brian)

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Colin Watson]

On Sun, Jun 15, 2003 at 11:42:44PM -0500, Manoj Srivastava wrote:
> On Mon, 16 Jun 2003 08:36:20 +1000, Herbert Xu <[EMAIL PROTECTED]> said: 
> > Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> >> If it caused a Debian bug to be closed, that is a significant
> >> change in status for the Debian package (it may not be for the
> >> upstream software being packaged, but it is for my package).
> 
> > What if the bug was reported after the new Debian package was
> > uploaded?  Why does it suddenly stop being a significant change? 
> 
>   Good point. Shall we mandate that all bug closures be
>  adequately documented in the ChangeLog? I would be quite happy with
>  that.

Ai. Er, I hope you're not planning to encourage people to upload new
versions of packages just to add bug numbers to the changelog? Because
that would be most inefficient and wrong.

My answer to Herbert would be "it would be nice, but unfortunately time
travel is not yet among our capabilities".

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Every spam is sacred

[Josip Rodin]

On Sun, Jun 15, 2003 at 10:11:22PM -0400, Theodore Ts'o wrote:
> > Given that it's been pointed out that the MTA supports per-user bouncing
> > of mail from open relays, and that it's very possible to use LDAP to
> > provide easy management of per-user preferences, why is there any need
> > to continue discussing what individual developers do or don't consider
> > acceptable for collateral damage?
> 
> I don't think it's as simple as that.  When I worked for VA Linux
> systems, we consciously decided not to use any spam-blocking systems,
> and live with the spam, because the chance that we might lose one
> e-mail from a customer due to a false-positive was considered
> unacceptable.
> 
> If some number of Debian developers utilizing blocking that has a
> false positive rate of as high as 2 per day by some estimates, do we
> as a body consider it acceptable if some percentage of Debian
> developers:

Frankly, we as a body cannot possibly have a real say in this particular
issue. Every developer can filter their mail for themselves -- and a lot of
them already do (probably a vast majority). Even people who don't filter
mail in a technical manner can perfectly well ignore mails for whatever
reason. It's practically impossible to not leave this in the discretion of
individual developers.

Besides, mails get lost all the time, for a variety of reasons most of
which are out of our control. The impact is never any more than negligible,
otherwise there'd be much more fuss raised about it.

> but the debian mail system is run by the entire Debian project, and so
> it is appropriate that the decision be one which is taken by the
> entire project about whether or not supporting a service which has
> such a high potential false positive rate is something the Debian
> project as a whole should support.

Now that's just silly. People are already allowed to use a myriad of
filtering methods on Debian systems, none of which are intrinsically worse
or better than those that aren't available systemwide (dnsbl, spamassassin,
razor, ...). And if the method isn't available systemwide, they can run it
from their home directory.

Having stuff run in a more technically sane way (like by not having everyone
maintain a duplicate copy of whatever software necessary in their $HOME, or
having hundreds or thousands of DNS lookups get made per mail instead of
just a few) is certainly something that any sysadmin would prefer.

I'm getting tired of these red herrings. I guess it serves Santiago right --
he posted the issue on -devel in a flamebait-ish way and all he (and we) got
was this useless flamewar.

-- 
 2. That which causes joy or happiness.

Re: Every spam is sacred: tagging mails because of their content or their supposed origin?

[Josip Rodin]

On Sun, Jun 15, 2003 at 11:19:10PM -0400, Duncan Findlay wrote:
> FWIW, the next version of spamassassin (2.60) will have no forgeable
> negatively scoring rules. (ETA early-mid July)

Just out of curiosity, how will this be accomplished?

-- 
 2. That which causes joy or happiness.

Re: RFC: fewer vim variants

[Jörgen Hägg]

In message <[EMAIL PROTECTED]> you write:
> Hello people,
> 
> I propose to restructure the vim package so that it builds fewer vim
> variants.
> 
> I propose to have only the following:
>   vim  (aka vim-tiny; no interpreters, no docs)
>   kvim (including all non-threaded interpreters; kde support; no docs)
>   gvim (including all non-threaded interpreters; gtk2 support; no docs)
>   vim-doc
> 
> Let me know if this rubs you the wrong way.

No, as long as I get gtk-vim without gnome. :-)

Re: Debian for x86-64 (AMD Opteron) and migration?

[Emile van Bergen]

Hi,

On Mon, Jun 16, 2003 at 07:33:35AM +0200, Xavier Roche wrote:

> Then, a nice thing would be on Debian, for a regular user/administrator:
> 
> - switch the disks to a Opteron box
> - update the APT sources to a "Opteron" source, or to a "Opteron
> migration" source
> - then, use something like :
> apt-get install base-64
> to install the essential system files for 64-bit
> apt-get install libc6-64 ..
> essential libraries and elements for 64-bit code
> apt-get kernel-image..-64
> 64-bit kernel for Opteron
> 
> I'm not sure that all remarks are wise, but I did not see this
> (migration) point clearly emerging from the "Debian for x86-64 (AMD
> Opteron)" previous discussion

Well, to some extent is was mentioned in the subthread by Wichert about
dpkg being changed to allow multiple architectures at the same time, so
that it's a matter of

# echo x86-64 >>/etc/dpkg/legal-archs

or, if ordering matters,

# echo x86-64 >/etc/dpkg/legal-archs.new
# cat /etc/dpkg/legal-archs >>/etc/dpkg/legal-archs.new
# mv /etc/dpkg/legal-archs.new /etc/dpkg/legal-archs

and suddenly an

# apt-get install fvwm2

will fetch pool/main/f/fvwm/fvwm_2.4.6-2_x86-64.deb from the archive,
and pull in packages such as lib64c6, lib64readline4, lib64gtk1.2.

In this example, only one version (32 or 64 bit) of an application such
as fvwm can exist on the system (package name is the same, only
architecture field is different), whereas both libreadline4 and
lib64readline4 can exist (package name is different too, and one
installs its files in /usr/lib, the other in /usr/lib64 as per the AMD64
ABI).

Of course, this may be different for other programs, which do require
the '64' in the package name because some other program explicitly
depends on a 64 bit version. But in general, this will only be true for
libraries because they go in the same address space. Interfaces between
programs and other programs will hopefully mostly be 64-bit clean.

The biggest objection that was raised is that it will be necessary
to make the source package for libreadline4 generate two packages,
libreadline4 and lib64readline4. Same for all other libraries. IOW,
there's no automatic way to create all these lib64* packages from
source.

Have I summarised this correctly?

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen   [EMAIL PROTECTED]  
tel. +31 (0)70 3906153   http://www.e-advies.nl


pgp7VIRUBBmvE.pgp
Description: PGP signature

Re: Fun with python-apt

[Andreas Metzler]

Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
[...]
> That could be. Somehow, the C++ ABI would have to be added to the 
> Build-Dependency information. Either that, or C++ packages would have 
> to use a specific C++ ABI compiler, e.g.,

> (control)
>Build-Depends: c102, ...
[...]

Build-Depends: g++ (>= 3:3.2.2-0)

Many transitioned packages use(d) this to guarantee that the correct
compiler was used.
  cu andreas

Re: Every spam is sacred

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>On Sun, Jun 15, 2003 at 11:45:17AM -0500, Steve Langasek wrote:
>If some number of Debian developers utilizing blocking that has a
>false positive rate of as high as 2 per day by some estimates, do we
>as a body consider it acceptable if some percentage of Debian
>developers:

Alternativly, if Debian dosn't implement spam blocking, do we consider
it acceptable that:

   Some developers stop reading any email, since the vast majority of
   it is spam.

   Developers delete messages unread because of spammy sounding
   subjects.

   Developers spend so much time reading spam they don't have time to
   fix bugs and do other useful work.

People advocating not filtering spam based on some false positives
seem to forget that being burried under the load of spam can cause
more false postitives by the human forced to do the filtering.

On my personal mailbox, I use some rather aggrasive lists that I
wouldn't recomend to Debian at this time.  (relays.osirusoft.com,
which includes SPEWS and SBL, and block.blars.org that I run myself
and don't recomend to others.)  It still gets ten times as much spam
as non-spam.  Without the spam filters, I'd probably wind up not
reading email at all.

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
"Text is a way we cheat time." -- Patrick Nielsen Hayden

Re: Every spam is sacred

[Russell Coker]

On Mon, 16 Jun 2003 15:06, Manoj Srivastava wrote:
> > There is no excuse for this.  Access to servers that are not in spam
> > lists is well available to Debian developers.  I tunnel my outgoing
> > mail through a server in Melbourne no matter where I am, this avoids
> > all issues of spam blocking by IP address.  I offered accounts on a
> > choice of machines to be used for such purposes for any Debian
> > developers who have no better options, but so far no-one has taken
> > me up on this offer.
>
>   I refuse to allow spammers this victory. My machines are fully
>  capable members of the internet, and I deliver my own email. My
>  philosophy is that if people drop mail from me due to incompetence
>  (since setting up machines to classify email from me as spam is
>  indeed a misconfiguration), then I have no real desire to impose my
>  musings on them.

If your machines are fully capable then they will have permanent IP addresses 
and no spam ever coming from them.  In which case they will never get listed 
in a DNSBL (*) and there is nothing to be concerned about.

(*)  SPEWS level 2 and other excessively agressive DNSBL's may list you, but 
don't worry about that.  No-one has suggested that we use such DNSBL's.  We 
are talking about the simplest and most conservative ones that just list open 
relays etc.

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

Re: Debian for x86-64 (AMD Opteron) and migration?

[Xavier Roche]

Ok, a bit late in this thread, but just a small remark on the future
Opteron port : we have to take a *great* care of the migration process.

The main difference betweek Intel-64 and AMD-64, if I am correct, is that
administrators can unplug their ix86 disk from the server, and replug it
on a opteron box, swicth the power button, and that's it. 
You'll get almost the same machine, and the you can start the upgrade
process to 64-bit for all applications that needs them, and them finish
the migration. This is a process that takes time (and for some servers
that will take months or years)

Therefore you can migrate smoothly machines from the 32-bit world to the
64-bit world witout having to do a painful migration from a 32-bit server
to a full 64-bit one ; this is, IMHO, the greatest advantage of Opteron.
Many people will not switch to Itanium for this reason: you have to break
everything, including production application that sill are 32-bit.

Then, a nice thing would be on Debian, for a regular user/administrator:

- switch the disks to a Opteron box
- update the APT sources to a "Opteron" source, or to a "Opteron
migration" source
- then, use something like :
apt-get install base-64
to install the essential system files for 64-bit
apt-get install libc6-64 ..
essential libraries and elements for 64-bit code
apt-get kernel-image..-64
64-bit kernel for Opteron

I'm not sure that all remarks are wise, but I did not see this
(migration) point clearly emerging from the "Debian for x86-64 (AMD
Opteron)" previous discussion

(My 2 euro cents remark)

Dien dan dau tu va so huu tri tue

[promotion]

dien dan dau tu va so huu tri tue: http://www.luatgiapham.com

Dien dan dau tu va so huu tri tue

[promotion]

dien dan dau tu va so huu tri tue: http://www.luatgiapham.com

Re: Every spam is sacred

[Manoj Srivastava]

On Mon, 16 Jun 2003 12:43:48 +1000, Russell Coker <[EMAIL PROTECTED]> said: 

> On Mon, 16 Jun 2003 12:11, Theodore Ts'o wrote:
>> false positive rate of as high as 2 per day by some estimates, do
>> we as a body consider it acceptable if some percentage of Debian
>> developers:
>>
>> 1) Don't receive a mail message from a fellow Debian developer
>> because they unfortunately got caught by a false-positive (perhaps
>> they got renumbered onto a bad SPAM address, or they were roaming
>> on a wireless from a conference or during business travel) and
>> important mail that related to Debian business gets lost?

> There is no excuse for this.  Access to servers that are not in spam
> lists is well available to Debian developers.  I tunnel my outgoing
> mail through a server in Melbourne no matter where I am, this avoids
> all issues of spam blocking by IP address.  I offered accounts on a
> choice of machines to be used for such purposes for any Debian
> developers who have no better options, but so far no-one has taken
> me up on this offer.

I refuse to allow spammers this victory. My machines are fully
 capable members of the internet, and I deliver my own email. My
 philosophy is that if people drop mail from me due to incompetence
 (since setting up machines to classify email from me as spam is
 indeed a misconfiguration), then I have no real desire to impose my
 musings on them. 

manoj
-- 
I always had a repulsive need to be something more than human. David
Bowie
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Manoj Srivastava]

On Mon, 16 Jun 2003 08:36:20 +1000, Herbert Xu <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>>
>>> Even if the bug is for upstream fixing a typo in a comment? :)
>>
>> If it caused a Debian bug to be closed, that is a significant
>> change in status for the Debian package (it may not be for the
>> upstream software being packaged, but it is for my package).

> What if the bug was reported after the new Debian package was
> uploaded?  Why does it suddenly stop being a significant change? 

Good point. Shall we mandate that all bug closures be
 adequately documented in the ChangeLog? I would be quite happy with
 that.

Indeed, the rationale would be that closing bugs is an
 important event for the Package, and needs be thus documented. I
 thank you for pointing out this defect in our ChangeLog
 standards. 

manoj
-- 
If all the world is a stage, where is the audience sitting? George
Carlin
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#196800: flex mustn't assume stdint.h is available on allplatforms

[Manoj Srivastava]

On Mon, 16 Jun 2003 13:22:24 +1000, Herbert Xu <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>>
>> I can understand the unease. But consider this: POSIX is already
>> over a decade old; and it standardized practices that were

> SuSv3 aka POSIX was released one year ago. 

And changed nothing in the Lex definitions. As I said, we are
 dealing with decades old design.

manoj
-- 
Time flies like an arrow.  Fruit flies like a banana.
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