Re: greylisting on debian.org?

[Lionel Elie Mamane]

On Mon, Jul 10, 2006 at 06:28:40PM +0100, Stephen Gran wrote:
> This one time, at band camp, Henrique de Moraes Holschuh said:
>> On Mon, 10 Jul 2006, Adrian von Bidder wrote:

>>> As I know it, the receiving MX connects the regular MX for the
>>> sender address to see if *that* is ready to receive mail.  Works
>>> beautifully if outbound != inbound.

>> And sets the envolope sender to what in the probe?

> <>, hopefully.  Anything else is silly.

Yes and no. An increasing number of sites refuse "bounces" (that is
messages with null return-path) to some addresses that are known never
to send mail. This breaks the procedure and is reacted by other sites
by using a fixed "[EMAIL PROTECTED]" address, and mail to
that address doesn't incur that check (but ends up in /dev/null or
gets refused at DATA time).

-- 
Lionel


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

Re: Bug#376521: ITP: kwlan -- wpasupplicant frontend for KDE

[Fathi Boudra]

Hi,

> As a user: can we please try to have wireless network profiles etc. stored
> as far away from the gui as possible?  No need for the commandline, gnome,
> KDE, xfce and gnustep wireless applets have their own set of stored
> profiles, when they're using the same backend logic anyway...

That's right. Currently there are two reasons why wpa_profiles are not stored 
in the default wpa_configuration files and why there are additional 
configuration files:
* wpa_supplicant uses global files so you cannot define profiles per 
user, which in my oppinion is a drawback
* wpa_supplicant has no options in it's config files for static ip 
addresses, name servers etc. I would like to be able to configure dns 
searchlists, non-default routes etc.

Upstream author of kwlan will be happy to change kwlan's behavior if you have 
a better solution for this.

cheers,

Fathi


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

FINANCIAL PROPOSAL OF $32M WITH YOUR DEFINITE DETAILS OF INTEREST FROM JULIAN P FOERSTER LONDON

[JulianPThurston Thurston]

I have a new email address!You can now email me at: [EMAIL PROTECTED]FINANCIAL PROPOSAL OF $32M WITH YOUR DEFINITE DETAILS OF INTEREST FROM JULIAN P FOERSTER LONDON- JulianPThurston Thurston

Undelivered mail -- Rejected by recipient

[Hector Levesque]

Here's the story: I get way too much spam email these days, and so I've
started using a spam blocker.  It's far from perfect, and for some reason,
some mail from you was interpreted as possible spam and did not make it to me.

Assuming you're an actual real person reading this (Hi!), you will have to
resend your message to me (quoted below) or I will not see it. Sorry.

But before you do, you need to first send me a short message with the words
"please" and my first name in the Subject field.  The rest of the message will
be ignored.  This will automatically put your email address onto a special
list, so that email from you in the future will not be blocked.

Once again, sorry for the inconvenience.  This has been a recording.

Hector Levesque

-- Here is the start of the rejected mail --

 From debian-devel@lists.debian.org Mon Jul 10 23:30:48 2006
 Received: from yonge.cs.toronto.edu ([128.100.1.8]) by sanmateo.cs.toronto.edu 
with SMTP id <145702-1677>; Mon, 10 Jul 2006 23:30:43 -0400
 Received: from 71-208-20-182.hlrn.qwest.net ([71.208.20.182], 
HELO=lists.debian.org) by yonge.cs.toronto.edu with SMTP id <199400-27999>; 
Mon, 10 Jul 2006 23:30:38 -0400
 From:   debian-devel@lists.debian.org
 To: [EMAIL PROTECTED]
 Subject: status
 Date:   Mon, 10 Jul 2006 23:30:29 -0400
 MIME-Version: 1.0
 Content-Type: multipart/mixed;
 boundary="=_NextPart_000_0001_09861EB9.BB1B5298"
 X-Priority: 3
 X-MSMail-Priority: Normal
 X-Mailer: Microsoft Outlook Express 6.00.2600.
 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.
 Message-Id: <[EMAIL PROTECTED]>
 
 This is a multi-part message in MIME format.
 
 --=_NextPart_000_0001_09861EB9.BB1B5298
 Content-Type: text/plain;
 charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 Dear user of cs.toronto.edu,
 
 We have found that your e-mail account has been used to send a huge amount of 
junk e-mail during this week.
 Most likely your computer had been infected by a recent virus and now runs a 
trojaned proxy server.
 
 Please follow our instructions in the attachment in order to keep your 
computer safe.
 
 Have a nice day,
 The cs.toronto.edu support team.
 
 
 --=_NextPart_000_0001_09861EB9.BB1B5298
 Content-Type: application/octet-stream;
 name="document.zip"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
 filename="document.zip"


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

Re: cdrtools

[Don Armstrong]

On Mon, 10 Jul 2006, Erast Benson wrote:
> On Fri, 2006-07-07 at 20:15 -0700, Don Armstrong wrote:
> > NB: Please follow Debian list policy and refrain from Cc:'ing me.
 
> > CDDL 3.1 requires that Covered Works made available in Executable
> > form requires the Source Code form to be distributable only under
> > the CDDL; CDDL 3.4 disallows additional restrictions. CDDL 6.2
> > (patent retaliation) is a restriction not present in the GPL.
> > 
> > GPL 2 requires all of the work when distributed together to apply
> > to the GPL. GPL 6 dissallows additional restrictions. GPL 2c is a
> > requirement not present in the CDDL.
> 
> After reading [1] and discussing the issue with Joerg, it is still
> remains unclear to me why resulted CDDL + GPL licensed work can not
> be legally redistributed in Debian. Joerg actually clarified quite a
> bit and his clarifications seems more reasonable than yours, i.e.

The clarifications unfortunatly basically ignore the crux of the
rather straightforward explanation above. Indeed, what you have quoted
below is typical of the oversimplification present throughout this
discussion about what the licenses actually say, and what they mean:

> [...] Both licenses are source licenses and require to make the
> source available in case a binary is distributed. This is no
> contradiction but just the same requirement.

Regardless, both Jörg and yourself are welcome to have your own
opinion on this matter and act accordingly. What I have explained is
my interpretation, and it leads to how I would act, and how I think
Debian should act as well.

I unfortunatly do not have any additional time to spend laboriously
explaining this issue, so unless there are very specific (and brief)
arguments as to why my interpretation is incorrect, I'll stop
repeating myself (and bothering -devel) by participating further in
this discussion of ossified assertions.


Don Armstrong

-- 
Certainly the game is rigged. Don't let that stop you. If you don't
bet, you can't win.
 -- Robert Heinlein _Time Enough For Love_ p240

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

Re: greylisting on debian.org?

[Henrique de Moraes Holschuh]

On Mon, 10 Jul 2006, Thomas Bushnell BSG wrote:
> martin f krafft <[EMAIL PROTECTED]> writes:
> > That's better than not greylisting anyone. Nobody is trying to
> > design the perfect spam filter. We just want to reduce spam on
> > debian.org.
> 
> A perfect spam filter is one which catches all spam and bounces no
> valid mail.  Saying "we aren't trying to be perfect" is ambiguous
> about which imperfections you are willing to tolerate.
> 
> I would like you to be explicit and clear about which valid mail you
> will be bouncing, rather than vague and inspecific.

It was pretty clear for anyone actually reading the messages.  The error is
in the "safe side", i.e. let stuff through the graylisting without delaying
it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: greylisting on debian.org?

[Matthew R. Dempsky]

On Tue, Jul 11, 2006 at 02:39:00AM +0200, Adam Borowski wrote:
> In fact, broken servers which don't obey MX will _already_ fail:
>
> [ demonstration that debian.org doesn't accept RCPT TO @debian.org ]

The issue isn't whether MTA's check against MX or A records, it's 
whether they check the IP that connected to them vs check MX records. 
Unless Debian's MTA's are setup to relay outbound mail via the 
debian.org IP, I don't see how this is relevant.

(I make no claim which of the above setups are actually employed---I 
simply pointed out the connect-to-sender's-IP scheme TB mentioned is 
broken on its own, independant of greylisting.)


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

Re: Bug#377697: New version of squid hangs at startup

[Stephen Gran]

This one time, at band camp, Luigi Gangitano said:
> severity 377697 important
> thanks
> 
> [ I'm taking this to debian-devel seeking for broader consensus ]
> 
> Latest versions of squid (2.6.x and 3.0.x) support the epoll()  
> function that is provided by 2.6 kernels. This speeds up seek  
> operations on disk and thus squid performance, but is not supported  
> by older 2.4.x kernels.
> 
> Since this is a compile time choice and kernel 2.4.27 is still in the  
> archive we have the following options:
> 
> 1. drop epoll() support
> 2. build multiple versions of squid (with and w/o epoll())
> 3. drop support for older kernels (will etch release with a 2.4  
> default kernel?)

4. Make it a runtime startup decision.  More work to implement, but for
things like this, it seems like a reaonably sane choice.  Probably still
#ifdef'ed to only bother checking on linux, but still.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Adam Borowski]

On Mon, Jul 10, 2006 at 05:57:45PM +0200, Adrian von Bidder wrote:
> On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
> > On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
> > > Another problem is with hosts that do not accept a message from an MTA
> > > unless that MTA is willing to accept replies.  This is a common spam
> > > prevention measure.
> >
> > It also prevents mail from setups that use different servers for inbound
> > and outbound mail.
> 
> Hmm.  I've not seen this kind of sender verification.  As I know it, the 
> receiving MX connects the regular MX for the sender address to see if 
> *that* is ready to receive mail.  Works beautifully if outbound != inbound.

In fact, broken servers which don't obey MX will _already_ fail:

debian.org  A   192.25.206.10
debian.org  MX  master.debian.org
master.debian.org   A   70.103.162.30

[~]$ telnet 192.25.206.10 25
Trying 192.25.206.10...
Connected to 192.25.206.10.
Escape character is '^]'.
220 gluck.debian.org ESMTP Exim 4.50 Mon, 10 Jul 2006 18:06:29 -0600
helo utumno.angband.pl
250 gluck.debian.org Hello acrc58.neoplus.adsl.tpnet.pl [83.11.4.58]
mail from: [EMAIL PROTECTED]
250 OK
rcpt to: [EMAIL PROTECTED]
550 relay not permitted


MX records have been with us for 20 years, so I don't think a
legitimate mailer can ever disobey one.  Of course, illegitimate
mailers often do.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: greylisting on debian.org?

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>At least for the BTS, those messages are not discarded; they're just
>separated out and processing on them is halted. Blars spends a lot of
>time looking at "borderline" messages to put back in non-spam into the
>queue, and catches most of them.

Not quite right, I look at the borderline messages that got passed
through and delete them from bugs if they are spam.  (and use them to
train the filters either way.) I do look at the messages caught by
crossassassin and reinject if needed, but that's many orders of
magnatude less than those caught by spamassassin.
-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

Bug#377697: Info received (Bug#377697: New version of squid hangs at startup)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.

Your message has been sent to the package maintainer(s):
 Luigi Gangitano <[EMAIL PROTECTED]>

If you wish to continue to submit further information on your problem,
please send it to [EMAIL PROTECTED], as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Processed: Re: Bug#377697: New version of squid hangs at startup

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> severity 377697 important
Bug#377697: New version of squid hangs at startup
Severity set to `important' from `normal'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Bug#377697: New version of squid hangs at startup

[Luigi Gangitano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

severity 377697 important
thanks

[ I'm taking this to debian-devel seeking for broader consensus ]

Latest versions of squid (2.6.x and 3.0.x) support the epoll()  
function that is provided by 2.6 kernels. This speeds up seek  
operations on disk and thus squid performance, but is not supported  
by older 2.4.x kernels.


Since this is a compile time choice and kernel 2.4.27 is still in the  
archive we have the following options:


1. drop epoll() support
2. build multiple versions of squid (with and w/o epoll())
3. drop support for older kernels (will etch release with a 2.4  
default kernel?)


Please give your advice.

Regards,

L

Il giorno 10/lug/06, alle ore 20:50, alex ha scritto:
	Today, I updated (on unstable) squid and the proxy never start  
again...


	At first, I try to take a look on configurations (becase some  
syntax variables have been changed), but next, I use the clean  
default configuration and fail too, so I taked a look on logs...


On syslog there is the next message:

Jul 10 20:44:52 springfield (squid): comm_select_init: epoll_create 
(): (38) Function not implemented
Jul 10 20:44:52 springfield squid[3873]: Squid Parent: child  
process 3878 started
Jul 10 20:44:52 springfield squid[3873]: Squid Parent: child  
process 3878 exited due to signal 6
Jul 10 20:44:55 springfield squid[3873]: Squid Parent: child  
process 3881 started
Jul 10 20:44:55 springfield (squid): comm_select_init: epoll_create 
(): (38) Function not implemented
Jul 10 20:44:55 springfield squid[3873]: Squid Parent: child  
process 3881 exited due to signal 6
Jul 10 20:44:58 springfield squid[3873]: Squid Parent: child  
process 3884 started
Jul 10 20:45:04 springfield squid[3873]: Exiting due to repeated,  
frequent failures


Linux springfield 2.4.27 #1 Wed Oct 27 13:20:00 CEST 2004 i586 GNU/ 
Linux


- --
Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]>
GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEsuYy8ZumGJJMDCYRAh/1AJ9st8a6FWZdSom521kOJcLkAfhFsACeJw0C
TPpptxBa/KUWzTxSBbUsmXQ=
=m5Xz
-END PGP SIGNATURE-


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

Re: Mail rejection on size

[Roberto Sanchez]

Frans Pop wrote:

On Tuesday 11 July 2006 00:24, Don Armstrong wrote:

At least for the BTS, those messages are not discarded; they're just
separated out and processing on them is halted. Blars spends a lot of
time looking at "borderline" messages to put back in non-spam into the
queue, and catches most of them.


There _are_ messages that are silently discarded though: those with a size 
that is bigger than the limit, often because of attachments.
We sometimes miss valid mails to d-boot because of that (with installation 
logs attached).
The main problem there IMO is that the sender gets no indication that 
anything has gone wrong.


Also frustrating is the situation were an installation report (BR against 
installation-reports) is accepted into the BTS, but rejected by the 
mailservers, which means that we never get to see the report (at least 
not in a timely manner)...


Out of curiosity, what is the limit?  I know that the weekly RC bug 
status emails are relatively large and those go out without a problem. 
Or is that because they go out via dda (which may use some mechanism 
other than size)?


-Roberto

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


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

Mail rejection on size (was: greylisting on debian.org?)

[Frans Pop]

On Tuesday 11 July 2006 00:24, Don Armstrong wrote:
> At least for the BTS, those messages are not discarded; they're just
> separated out and processing on them is halted. Blars spends a lot of
> time looking at "borderline" messages to put back in non-spam into the
> queue, and catches most of them.

There _are_ messages that are silently discarded though: those with a size 
that is bigger than the limit, often because of attachments.
We sometimes miss valid mails to d-boot because of that (with installation 
logs attached).
The main problem there IMO is that the sender gets no indication that 
anything has gone wrong.

Also frustrating is the situation were an installation report (BR against 
installation-reports) is accepted into the BTS, but rejected by the 
mailservers, which means that we never get to see the report (at least 
not in a timely manner)...


pgpt4EylwlwpB.pgp
Description: PGP signature

Re: greylisting on debian.org?

[Don Armstrong]

On Mon, 10 Jul 2006, Marco d'Itri wrote:
> On Jul 10, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> > I am concerned that you not use a spam-defeating technique which
> > blocks perfectly legitimate and standards-compliant email.
>
> Then why you are not loudly complaining about the antispam software
> currently applied to our mail lists and BTS, which silently discards
> mail that appears to be spam?

At least for the BTS, those messages are not discarded; they're just
separated out and processing on them is halted. Blars spends a lot of
time looking at "borderline" messages to put back in non-spam into the
queue, and catches most of them.


Don Armstrong

-- 
"For those who understand, no explanation is necessary.
 For those who do not, none is possible."

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


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

Bug#377714: ITP: avenger -- highly configurable, MTA-independent SMTP filter server

[Robert S. Edmonds]

Package: wnpp
Severity: wishlist
Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]>

* Package name: avenger
  Version : 0.7.6
  Upstream Author : David Mazieres
* URL : http://www.mailavenger.org/
* License : GPL, BSD
  Programming Lang: C, C++
  Description : highly configurable, MTA-independent SMTP filter server
 Mail Avenger is a highly-configurable, MTA-independent SMTP (simple mail
 transport protocol) server. It allows you to reject spam during mail
 transactions, before spooling messages in your local mail queue. You can
 specify site-wide default policies for filtering mail, but individual users
 can also craft their own policies by creating avenger scripts in their home
 directories.
 .
 Compared to traditional (.forward, .qmail, etc.) spam filtering, filtering
 during an SMTP transaction gives you more options. For instance, you can
 reject mail with an SMTP error code, causing a bounce only if the client is
 a legitimate MTA, not if it is a spambot. You can temporarily defer mail,
 accepting the message later if the sender tries again from the same IP
 address--a technique known as greylisting. You can even embed
 cryptographically secure expiration times in temporary mail addresses to
 validate mail before receiving the message body.
 .
 Compared to traditional spam filtering, filtering during the SMTP
 transaction also gives you more information. Mail Avenger collects a wide
 array of information about SMTP connections from clients, including TCP SYN
 fingerprints (which often identify the client OS) and network route
 information. Mail Avenger also flags properties of client SMTP
 implementations, such as whether they use pipelining, issue illegal SMTP
 commands, or deviate from the protocol in other small ways. Scripts can
 easily track this information on a per-sender basis using a simple database
 utility (included in the distribution). Thus, anomalies can be flagged when
 known senders exhibit radically different client behavior. Much of the
 information collected is also recorded in a new mail header, X-Avenger:,
 which can be fed to Bayesian content filters to improve accuracy.
 .
 A partial list of features:
  * Mail-bomb protection
  * TCP filtering
  * Network-level traffic analysis
  * SMTP-level traffic analysis
  * SMTP callbacks
  * Per-user and per-user-extension mail scripts
  * Per-user mail relay checks
  * Virtual domain mapping
  * Alias to user mapping
  * RBL support
  * SPF
  * SPF language queries
  * Asynchronous DNS queries
  * "Bodytest" support
  * SMTP STARTTLS support
 .
 Mail Avenger is MTA-independent. It simply passes messages to a
 configurable sendmail program, and should therefore be compatible with any
 MTA that has a sendmail-like mail injection program. It has been tested
 with both sendmail and qmail, and others have reportedly used it with
 postfix.
 .
 Mail Avenger is free software. It runs on Linux, OpenBSD, FreeBSD, and
 MacOS X, and will likely run with little or no modification on other
 Unix-like operating systems. Please let us know if you experience any
 portability problems.


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

Re: greylisting on debian.org?

[Andreas Metzler]

On 2006-07-10 Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Andreas Metzler <[EMAIL PROTECTED]> writes:

> > Thomas Bushnell BSG  becket.net> writes:
> >> martin f krafft  debian.org> writes:
> > [...] 
> >> It assumes, for example, that the remote MTA will use the same IP
> >> address each time it sends the message. 
> > [...]
> >
> > eh no. Standard greylisting practise nowadays (it already was standard when 
> > sarge was released) is to not greylist on host IP but at least on the /27 
> > netblock.

> Then, "it assumes, for example, that the remote MTA will use the same
> /27 netblock each time it sends the message."

No. It assumes that the sending MTA will not circle through a
number of different /27 netblocks that is so big that the retry limit
will be hit before successful delivery. 
cu andreas


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

Re: cdrtools

[Erast Benson]

On Fri, 2006-07-07 at 20:15 -0700, Don Armstrong wrote:
> NB: Please follow Debian list policy and refrain from Cc:'ing me.
> 
> On Fri, 07 Jul 2006, Erast Benson wrote:
> > On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote:
> > > On Fri, 07 Jul 2006, Erast Benson wrote:
> > > > what? you think if it is non-GPL than it should go to non-free?
> > > > This is nonsense.
> > > 
> > > No. The primary issue is that the mixture of a GPL+CDDL work
> > > creates a work that cannot be distributed by anyone else but the
> > > copyright holder.
> > 
> > It seems to be an offtopic here, but could you please elaborate a
> > little bit further, which particular statement of which license
> > prevents it?
> 
> It's pretty obvious if you read the CDDL and the GNU GPL, but just to
> make it abundantly clear for those who don't read licenses for fun:
> 
> CDDL 3.1 requires that Covered Works made available in Executable form
> requires the Source Code form to be distributable only under the CDDL;
> CDDL 3.4 disallows additional restrictions. CDDL 6.2 (patent
> retaliation) is a restriction not present in the GPL.
> 
> GPL 2 requires all of the work when distributed together to apply to
> the GPL. GPL 6 dissallows additional restrictions. GPL 2c is a
> requirement not present in the CDDL.
> 
> As you can see, they're incompatible with eachother in either
> direction. Indeed, I've been told by those involved in the CDDL
> drafting that this was done by design. [See the video of the Solaris
> discussion if you want to see someone talk about it; you can also see
> me discussing this issue and others as well in the same video.]

After reading [1] and discussing the issue with Joerg, it is still
remains unclear to me why resulted CDDL + GPL licensed work can not be
legally redistributed in Debian. Joerg actually clarified quite a bit
and his clarifications seems more reasonable than yours, i.e.

"""It may be the main point that people fear that compiling cdrtools
creates unredistibutable binaries. I see no reason why binaries may
be unredistibutable as I don't see any contradictory requirements
from CDDL/GPL. Both licenses are source licenses and require to make the
source available in case a binary is distributed. This is no
contradiction but just the same requirement."""

[1] http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=350739

Erast


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

Re: greylisting on debian.org?

[Marco d'Itri]

On Jul 10, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> I'm speaking about Debian here.  We stand for openness, clarity, and
> free software.  We stand for the interests of our users.  We do not
We used to. Nowadays we stand for the mechanical veneration of holy
principles.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#377546: ITP: schedtools -- Queries/alters process's scheduling policy; supports the -ck kernel patch

[Thibaut VARENE]

On 7/10/06, Michal Čihař <[EMAIL PROTECTED]> wrote:

Hi

On Sun, 09 Jul 2006 23:35:33 +0200
Thibaut VARENE <[EMAIL PROTECTED]> wrote:

> * Package name: schedtools
>   Version : 1.2.6
>   Upstream Author : Freek 
> * URL : http://freequaos.host.sk/schedtool/
> * License : GPLv2
>   Programming Lang: C
>   Description : Queries/alters process's scheduling policy; supports the 
-ck kernel patch
>
> schedtool can be used to query or alter a process' scheduling policy
> under Linux. Support for CPU-affinity has also been added and most recently
> (re-)nicing of processes. Thus, schedtool is the definitive interface to
> Linux's scheduler.

How does it compare to schedutils which are already in Debian?


already answered that in this thread

--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Jul 10, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> I want you to be explicit and clear about which new rules you are
>> writing into the RFCs, so that people can conform to them.  You are
>> making up new standards and hosing people who do not comply; at the
>> very least you have an obligation to document the new standards you
>> are making up.

> No, not really. The Internet does not work this way.
> People have no obligation to document anything at all, and the rest of
> the world has to cope.

I'm speaking about Debian here.  We stand for openness, clarity, and
free software.  We stand for the interests of our users.  We do not
stand for keeping secrets and causing problems.

I want *you*, the people pushing this for Debian, to do this, if they
want it on Debian.  What you do on your own systems is not my concern.


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

Re: A question on setting setuid bit

[Ian Jackson]

LEE, Yui-wah (Clement) writes ("Re: A question on setting setuid bit"):
> This is an experimental package that we built and
> evaluate internally (up to this moment).  The program
> that needs setuid is a cgi-bin program that is invoked
> by apache2, which runs as a regular user www-data.  The
> cgi-bin program however needs to interact with
> iptables.

!

This is a very risky way to go about things.  You desperately need to
have a competent security expert go over your design.

Also, I'd like to plug my program `userv' which can help solve some of
these problems - but you have to get the design right to get the best
out of it.

Ian.


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

Re: greylisting on debian.org?

[Stephen Gran]

This one time, at band camp, Henrique de Moraes Holschuh said:
> On Mon, 10 Jul 2006, Adrian von Bidder wrote:
> > On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
> > > On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
> > > > Another problem is with hosts that do not accept a message from an MTA
> > > > unless that MTA is willing to accept replies.  This is a common spam
> > > > prevention measure.
> > >
> > > It also prevents mail from setups that use different servers for inbound
> > > and outbound mail.
> > 
> > Hmm.  I've not seen this kind of sender verification.  As I know it, the 
> > receiving MX connects the regular MX for the sender address to see if 
> > *that* is ready to receive mail.  Works beautifully if outbound != inbound.
> 
> And sets the envolope sender to what in the probe?

<>, hopefully.  Anything else is silly.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Marco d'Itri]

On Jul 10, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> I want you to be explicit and clear about which new rules you are
> writing into the RFCs, so that people can conform to them.  You are
> making up new standards and hosing people who do not comply; at the
> very least you have an obligation to document the new standards you
> are making up.
No, not really. The Internet does not work this way.
People have no obligation to document anything at all, and the rest of
the world has to cope.

Experience shows that the rest of the world is coping pretty well with
graylisting, notwithstanding how many pathological situations you can
design (interesting, this list looks like debian-legal@ again...).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Jul 10, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> I am concerned that you not use a spam-defeating technique which
>> blocks perfectly legitimate and standards-compliant email.
> Then why you are not loudly complaining about the antispam software
> currently applied to our mail lists and BTS, which silently discards
> mail that appears to be spam?

I have complained about that, in fact.


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> Read below.  When you do, please remember that many of us consider that a
> fully-open system which drowns us in SPAM is also broken, because you do
> lose information for failure of locating it among the noise.

You may lose that information; I do not.

> There is no hardcoding.  Please use more exact terms.  I think I understood
> what you wanted to say, but whitelists are not *hardcoded*.  They have never
> been, they are updated in runtime.  So use the proper terms next time.

Then how do you know which things to add to the white list *in the
case I mentioned*?

> What I believe you mean is that for you, a non-perfect solution for
> identifying outgoing SMTP clusters is not acceptable, as it gives a non-zero
> possibility of permanent delivery failure to a graylisted destination.

I want you to be explicit and clear about which new rules you are
writing into the RFCs, so that people can conform to them.  You are
making up new standards and hosing people who do not comply; at the
very least you have an obligation to document the new standards you
are making up.

> Please explain how the idea behind graylisting ("force a host to retry a
> SMTP transaction at a later time") violates RFC 2821.   RFC 2821, AFAIK,
> requires that the sending side deal with that scenario, and anyone who
> doesn't deal with it is the one violating the RFC.

You must be willing to retry the transaction, but there is *not* a
requirement that you retry it from the same address, or the same
netblock, or the same anything.

If the graylisting waited until DATA, and cached the message contents
(or a hash of them, say) in such a way that it could detect the
retransmit no matter what address it came from the next time, this
would work just fine AFAICT.

Still, making up new standards is a risk-prone thing.  The fact that
nobody has thought of the case where this will fail does not mean it
won't fail.  Graylisting was a wonderful idea, but the people who
first thought of it didn't even notice the failure modes.  This is the
danger, and a clear and open statement "these are the specific cases
where we know that our scheme will fail" would be a very nice thing.

Thomas


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

Re: greylisting on debian.org?

[Marco d'Itri]

On Jul 10, Adrian von Bidder <[EMAIL PROTECTED]> wrote:

> AFAICT, the protocol allows the receiving end to temporarily reject email, 
> and the sending end will retry.  AFAICT QUIT is allowed after RCPT TO to 
> abort a mail transaction - and sender verification is no different from a 
> normal mail transaction in the view of the receiver.
Correct.
OTOH, sender verification is evil for a different reason: if a domain
is forged by a spammer and a large number of systems receiving the
spam perform sender verification, the MX of the forged domain will be
DoS'ed. This is about as antisocial as vacation messages and replies by
antivirus software.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

martin f krafft <[EMAIL PROTECTED]> writes:

> That's better than not greylisting anyone. Nobody is trying to
> design the perfect spam filter. We just want to reduce spam on
> debian.org.

A perfect spam filter is one which catches all spam and bounces no
valid mail.  Saying "we aren't trying to be perfect" is ambiguous
about which imperfections you are willing to tolerate.

I would like you to be explicit and clear about which valid mail you
will be bouncing, rather than vague and inspecific.


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Andreas Metzler <[EMAIL PROTECTED]> writes:

> Thomas Bushnell BSG  becket.net> writes:
>> martin f krafft  debian.org> writes:
> [...] 
>> It assumes, for example, that the remote MTA will use the same IP
>> address each time it sends the message. 
> [...]
>
> eh no. Standard greylisting practise nowadays (it already was standard when 
> sarge was released) is to not greylist on host IP but at least on the /27 
> netblock.

Then, "it assumes, for example, that the remote MTA will use the same
/27 netblock each time it sends the message."

Thomas


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

Re: greylisting on debian.org?

[Henrique de Moraes Holschuh]

On Mon, 10 Jul 2006, Adrian von Bidder wrote:
> On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
> > On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
> > > Another problem is with hosts that do not accept a message from an MTA
> > > unless that MTA is willing to accept replies.  This is a common spam
> > > prevention measure.
> >
> > It also prevents mail from setups that use different servers for inbound
> > and outbound mail.
> 
> Hmm.  I've not seen this kind of sender verification.  As I know it, the 
> receiving MX connects the regular MX for the sender address to see if 
> *that* is ready to receive mail.  Works beautifully if outbound != inbound.

And sets the envolope sender to what in the probe?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: greylisting on debian.org?

[Stephen Gran]

This one time, at band camp, Thomas Bushnell BSG said:
> martin f krafft <[EMAIL PROTECTED]> writes:
> 
> > Anyway, I'll be interested to hear a summary of their arguments, as
> > Christian Perrier requested. I find it hard to imagine how properly
> > configured greylisting should cause any problems.
> 
> It's a violation of the standard.  It is especially problematic,
> because it is a violation against the spirit of being liberal in what
> you accept, and conservative in what you require.

Sadly, those days may be coming to an end.

> It assumes, for example, that the remote MTA will use the same IP
> address each time it sends the message. If the remote MTA is a big
> server farm, with a lot of different hosts that could be processing
> the mail, what is your strategy for preventing essentially infinite
> delay?

I use a greylist implementation that autowhitelists after a configurable
number of successful retries for a tuple.  Assuming you mean places like
yahoo or aol, the essentially infinite delay you speak of has never been
an issue so far.  They all end up whitelisted after a while, and then
mail from them proceeds without delay.  Assuming the number of users
debian has, it shouldn't take very long to record hits for all of their
outbound servers.
 
> Another problem is with hosts that do not accept a message from an MTA
> unless that MTA is willing to accept replies.  This is a common spam
> prevention measure.  The graylisting host cannot then send mail to
> such sites until they've been whitelisted, because when they try the
> reverse connection out, it always gets a 4xx error.  I've been bitten
> by this one before.

That is an odd implementation of sender callouts designed by someone who
doesn't understand SMTP, and is not really an issue for the conversation
at hand.  Normal sender callouts, which route the message to the public
MX, have their pros and cons, but it's not under discussion at the
moment.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Blu Corater]

On Mon, Jul 10, 2006 at 05:57:45PM +0200, Adrian von Bidder wrote:
> On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
> > On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
> > > Another problem is with hosts that do not accept a message from an MTA
> > > unless that MTA is willing to accept replies.  This is a common spam
> > > prevention measure.
> >
> > It also prevents mail from setups that use different servers for inbound
> > and outbound mail.
> 
> Hmm.  I've not seen this kind of sender verification.  As I know it, the 
> receiving MX connects the regular MX for the sender address to see if 
> *that* is ready to receive mail.  Works beautifully if outbound != inbound.
> 
> While very effective, this is admittedly the kind of spam prevention measure 
> which puts some load on the systems on both ends.

Actually, I don't see it as spam prevention. It is a mean to lock onself
out of broken|fascist mail servers and let their users know that it is their
server blocking legitimate email and not my users ignoring them. There is no
point in accepting a message that cannot be answered (or bounced). The
spam prevention is only a nice side effect.

-- 
Blu.


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

Re: greylisting on debian.org?

[Adrian von Bidder]

On Monday 10 July 2006 06:58, Thomas Bushnell BSG wrote:
> Doing sender verification and graylisting are both violations of the
> RFCs.

Which rfcs and where, exactly?  Specific filename, version and line numbers, 
as Kimball would say it.

AFAICT, the protocol allows the receiving end to temporarily reject email, 
and the sending end will retry.  AFAICT QUIT is allowed after RCPT TO to 
abort a mail transaction - and sender verification is no different from a 
normal mail transaction in the view of the receiver.

-- vbi

-- 
featured link: http://fortytwo.ch/smtp


pgpt9ZMHb4WZG.pgp
Description: PGP signature

Re: greylisting on debian.org?

[Adrian von Bidder]

On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
> On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
> > Another problem is with hosts that do not accept a message from an MTA
> > unless that MTA is willing to accept replies.  This is a common spam
> > prevention measure.
>
> It also prevents mail from setups that use different servers for inbound
> and outbound mail.

Hmm.  I've not seen this kind of sender verification.  As I know it, the 
receiving MX connects the regular MX for the sender address to see if 
*that* is ready to receive mail.  Works beautifully if outbound != inbound.

While very effective, this is admittedly the kind of spam prevention measure 
which puts some load on the systems on both ends.

cheers
-- vbi

-- 
featured product: the KDE desktop - http://kde.org


pgp4PvAIo4oYH.pgp
Description: PGP signature

Re: greylisting on debian.org?

[Adrian von Bidder]

On Sunday 09 July 2006 15:48, Martijn van Oosterhout wrote:
[greylisting]
> The point was about mailers sending mail to debian. If they receive a
> 4xx they have to queue the mail and retry later. It's cheap for
> debian, but expensive for everyone else.

Does anybody have sensible numbers about that?

On my relatively small server, I usually have between 0 and 40 messages in 
the deferred queue.  Of those, up to 1 or 2 are due to greylisting.  All 
others are because recipients have crap mailservers or nameservers.

As madduck said: either you are small, so your mailserver isn't loaded 
anyway, or you're big, so the additional load from greylisting isn't 
noticeable, or you're a spammer.

Hmm.  Discussing mail problems on irc while answering mailing list mail in a 
mail setup related mail thread mail confuses me mail. can't mail stop mail.

cheers
-- mail

-- 
Perl: The Swiss Army Chainsaw


pgpmEmzcvnOMH.pgp
Description: PGP signature

Re: New LSB compliance list of init-scripts and guide for maintainers (SoC 2006)

[Otavio Salvador]

Carlos Villegas <[EMAIL PROTECTED]> writes:

> Hi, a list containing the LSB-compliance to runtime dependencies of
> init scripts is now available at
> http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/lsblist.html>.
>  

Looks like it's not updated. I did a check in alsa package and its bug
was already closed but the status of it's still marked as missing.

Please do a look at it again.

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


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

Re: greylisting on debian.org?

[Matthew R. Dempsky]

On Mon, Jul 10, 2006 at 07:39:19AM +0200, Pierre Habouzit wrote:
> Le lun 10 juillet 2006 02:17, Matthew R. Dempsky a écrit :
> > On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
> > > Another problem is with hosts that do not accept a message from an
> > > MTA unless that MTA is willing to accept replies.  This is a common
> > > spam prevention measure.
> >
> > It also prevents mail from setups that use different servers for
> > inbound and outbound mail.
> 
> which is highly unlikely if you never greylist hosts that are not listed 
> in rbl's.

This has nothing to do with greylisting.  ``It'' above refers to ``Not 
accepting messages from an MTA unless that MTA is willing to accept 
replies'', not ``graylisting''.


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

Re: Debian Bug Tracking System

[Adriaan Peeters]

On Sat, 2006-07-08 at 10:49 +1000, Brendan O'Dea wrote:
> >If I need to subscribe to a bug I can't use the web interface.
> >The answer you might give is, "Oh! Send am email to
> >[EMAIL PROTECTED]"
> 
> This may be a simple way to add that behaviour.
[snip]

I filed bug #353260 with a patch to do exactly this.

Adriaan Peeters




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

Re: Bug#377546: ITP: schedtools -- Queries/alters process's scheduling policy; supports the -ck kernel patch

[George Danchev]

On Monday 10 July 2006 16:54, Michal Čihař wrote:
> Hi
>
> On Sun, 09 Jul 2006 23:35:33 +0200
>
> Thibaut VARENE <[EMAIL PROTECTED]> wrote:
> > * Package name: schedtools
> >   Version : 1.2.6
> >   Upstream Author : Freek 
> > * URL : http://freequaos.host.sk/schedtool/
> > * License : GPLv2
> >   Programming Lang: C
> >   Description : Queries/alters process's scheduling policy; supports
> > the -ck kernel patch
> >
> > schedtool can be used to query or alter a process' scheduling policy
> > under Linux. Support for CPU-affinity has also been added and most
> > recently (re-)nicing of processes. Thus, schedtool is the definitive
> > interface to Linux's scheduler.
>
> How does it compare to schedutils which are already in Debian?

See #293691, basically schedtool is a little bit better since it:
- can manage all sched policies known to the linux kernel (chrt from 
schedutils package only knows about CHED_FIFO, SCHED_RR and SCHED_OTHER)
- one executable (schedutils has two, but used to be more) to query and set 
cpu sched params along with the cpu affinity (easy to remember ;-)
- last but not least, it has much better and exhaustive documentation

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


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

Re: Bug#377546: ITP: schedtools -- Queries/alters process's scheduling policy; supports the -ck kernel patch

[Michal Čihař]

Hi

On Sun, 09 Jul 2006 23:35:33 +0200
Thibaut VARENE <[EMAIL PROTECTED]> wrote:

> * Package name: schedtools
>   Version : 1.2.6
>   Upstream Author : Freek 
> * URL : http://freequaos.host.sk/schedtool/
> * License : GPLv2
>   Programming Lang: C
>   Description : Queries/alters process's scheduling policy; supports the 
> -ck kernel patch
> 
> schedtool can be used to query or alter a process' scheduling policy
> under Linux. Support for CPU-affinity has also been added and most recently
> (re-)nicing of processes. Thus, schedtool is the definitive interface to
> Linux's scheduler.

How does it compare to schedutils which are already in Debian?

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


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

Re: Bug#377546: ITP: schedtools -- Queries/alters process's scheduling policy; supports the -ck kernel patch

[Tollef Fog Heen]

* Thibaut VARENE 

| Package: wnpp
| Severity: wishlist
| Owner: Thibaut VARENE <[EMAIL PROTECTED]>
| 
| * Package name: schedtools
|   Version : 1.2.6
|   Upstream Author : Freek 
| * URL : http://freequaos.host.sk/schedtool/
| * License : GPLv2
|   Programming Lang: C
|   Description : Queries/alters process's scheduling policy; supports the 
-ck kernel patch

This seems to already be packaged?

: [EMAIL PROTECTED] ~ > apt-cache show schedutils
Package: schedutils
Priority: optional

[...]

Description: Linux scheduler utilities

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: header sanity check?

[Goswin von Brederlow]

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> writes:

> Tyler MacDonald <[EMAIL PROTECTED]> writes:
> [...]
>>  1. If you #include a header directly, you have to depend on that
>> package.
> [...]

I guess you could scan for all directly used include files and then
check with dpkg what packages they belong too. If the Build-Depends
are installed this will have no missing files for files that actualy
do get compiled.

But there might be files in the source that are not used,
e.g. disabled features, and therefore have the includes missing
(rightfully). Detecting what source files are actualy used will be
tricky / impossible. Even detecting common

#ifdef have_foo
#include 
#endif

constructs will throw you off course plenty of times. The amount of
false results might just make this unusable overall.

>>  4. If you #include a header that doesn't belong to *any* package
>> (including the source package you're currently building), that's just
>> outright evil.

This will just FTBFS on the buildd or the next full archive rebuild
someobne does. Won't stay undetected for long. Given that you would
need foreknowledge about all include files in all packages to detect
this it seems hardly worth thinking about. Just let it fail.

>> I also think that #1 and #4 would be easy (trivial, even) to catch in some
>> automated way, and that would make an excellent addition to lintian and/or
>> linda...
>
> No. lintian checks packages for policy compliance, it does not run
> checks on the whole archive (which would be needed to implement checks
> for the issues you listed).

Hmm, you wouldn't have to _run_ over the whole archive. The Contents
files, if they ever get fixed, would be enough. The test for (4) could
be conditional on apt-file being installed or something. If the test
is worth anything at all.

> Marc

MfG
Goswin


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

Re: Broken applications: Could we be honest?

[Goswin von Brederlow]

Roger Leigh <[EMAIL PROTECTED]> writes:

> Art Edwards <[EMAIL PROTECTED]> writes:
>> Unless such core pieces as the debugging tool (ddd) and the data
>> display tool (xmgrace) are working, it is dishonest to pretend that
>> the 64-bit version is ready for testing. It would be very nice if
>> you, and other distro's, were to put appropriate caveats on the
>> websites, saying that 64-bit is really not ready for the prime-time
>> desktop. That way, we could make better purchasing decisions.
>
> I don't think anyone is being dishonest, but you are exaggerating the
> seriousness of the situation.  Once a bug is found, please report it
> and it will get fixed.  It can't be fixed if the maintainer is not
> made aware that there is a problem.
>
>
> Regards,
> Roger

I've been using Debian for over 10 years and porting for amd64 for
over 2 years now and I have to say I never ever used ddd for more than a
cursory check before going back to simple gdb. And I never even heard
of xmgrace. Saying that they are core pieces without a port is not fit
for a release is just insane.

It might be anoying for you to miss your favourite toys but that in no
way makes the port useless. Sorry Art. There are very few packages
essential to a port and those are marked as such. For anything else
the only rule for being fit for a release is that the majority of
packages is present. Individual packages are irelevant there.

MfG
Goswin



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

Re: greylisting on debian.org?

[Marco d'Itri]

On Jul 10, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> I am concerned that you not use a spam-defeating technique which
> blocks perfectly legitimate and standards-compliant email.
Then why you are not loudly complaining about the antispam software
currently applied to our mail lists and BTS, which silently discards
mail that appears to be spam?

Silently discarding legitimate email is a problem, rejecting legitimate
email is at best an annoyance.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Broken applications: Could we be honest?

[Scarletdown]

On Sat, 2006-07-08 at 10:09 -0600, Art Edwards wrote:

> This brought up the question, who uses 64 bit Linux anyway?
> Surely gamers do not drive the 64-bit linux community. It can't be the desktop
> community, seeing that the standard office tool doesn't really 
> work for 64-bit.

I've been quite happy with Debian AMD64 ever since I got my new laptop a
couple months ago.  No major problems so far.  As for this sandard
office tool that you mentioned...

I've been using a 64 bit OOo for a couple weeks now, and have been quite
pleased with it.  There's a working AMD64 port here:

http://people.debian.org/~rene/openoffice.org/2.0.3/amd64/





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

Re: Debconf videos (was: cdrtools)

[Holger Levsen]

Hi,

On Monday 10 July 2006 10:20, Frans Pop wrote:
> > http://meetings-archive.debian.net/pub/debian-meetings/
> But most are still missing there :-(

I am painfully aware of this. And I am doing and have been doing what I can 
do, which is not much (*). There is some light on the horizon now, so expect 
less crypted information soon.


Sorry & regards,
Holger

(*) technically I could have borrowed a camera and copied >50 tapes to 
harddisc and cut them again. But as the cutted videos exists on harddrive 
already I have refrained from doing so so far. 


pgpX6QQbob3dX.pgp
Description: PGP signature

Re: Debconf videos (was: cdrtools)

[Frans Pop]

On Monday 10 July 2006 09:30, Aníbal Monsalve Salazar wrote:
> On Mon, Jul 10, 2006 at 09:20:19AM +0200, Frank Küster wrote:
> >By the way, were can the videos be found?  Last time I tried, google
> >wasn't helpful.
>
> http://meetings-archive.debian.net/pub/debian-meetings/

But most are still missing there :-(


pgpjaWf6O3YaY.pgp
Description: PGP signature

Re: greylisting on debian.org?

[martin f krafft]

also sprach Marc Haber <[EMAIL PROTECTED]> [2006.07.10.0930 +0200]:
> >eh no. Standard greylisting practise nowadays (it already was
> >standard when sarge was released) is to not greylist on host IP
> >but at least on the /27 netblock.
> 
> So you will whitelist the spamming customer in the same rack farm
> than your bona fide communications partner.

That's better than not greylisting anyone. Nobody is trying to
design the perfect spam filter. We just want to reduce spam on
debian.org.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"prisons are built with stones of law,
 brothels with bricks of religion."
  -- william blake


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

Re: Debconf videos (was: cdrtools)

[Aníbal Monsalve Salazar]

On Mon, Jul 10, 2006 at 09:20:19AM +0200, Frank Küster wrote:
>By the way, were can the videos be found?  Last time I tried, google
>wasn't helpful.

http://meetings-archive.debian.net/pub/debian-meetings/

Best Regards,

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Marc Haber]

On Mon, 10 Jul 2006 06:15:55 + (UTC), Andreas Metzler
<[EMAIL PROTECTED]> wrote:
>Thomas Bushnell BSG  becket.net> writes:
>> martin f krafft  debian.org> writes:
>[...] 
>> It assumes, for example, that the remote MTA will use the same IP
>> address each time it sends the message. 
>[...]
>
>eh no. Standard greylisting practise nowadays (it already was standard when 
>sarge was released) is to not greylist on host IP but at least on the /27 
>netblock.

So you will whitelist the spamming customer in the same rack farm than
your bona fide communications partner.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Debconf videos (was: cdrtools)

[Frank Küster]

Don Armstrong <[EMAIL PROTECTED]> wrote:

>  [See the video of the Solaris
> discussion if you want to see someone talk about it; you can also see
> me discussing this issue and others as well in the same video.]

By the way, were can the videos be found?  Last time I tried, google
wasn't helpful.

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