Removing the MTA from the default install

[Josselin Mouette]

Is this the right time to do it?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1335945757.4277.215.camel@pi0307572

Re: Removing the MTA from the default install

[Aron Xu]

On Wed, May 2, 2012 at 4:02 PM, Josselin Mouette  wrote:
> Is this the right time to do it?
>

Not sure whether it's the right time, but I'm sure it's something I've
been waiting for quite some time. :-)



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7iNu4fkHzEm9GPt6bbivjsiYt7dt=cyoob8qqu3vt...@mail.gmail.com

Re: Removing the MTA from the default install

[Adam Borowski]

On Wed, May 02, 2012 at 10:02:37AM +0200, Josselin Mouette wrote:
> Is this the right time to do it?

No.  Cron needs some way to report about its jobs, mdadm has to notify about
failures, etc, etc.

On the other hand, going from a full blown MTA like exim to something like
ssmtp or dma¹ would be a great idea.



[¹]. dma would be far better as it can handle transient failures when
configured to send to a remote host, however, that cronjob every 5 minutes
disqualifies it for the job of a laptop MTA.  That's fixable, though.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


signature.asc
Description: Digital signature

Bug#671154: ITP: lhasa -- lha archive decompressor

[Jon Dowland]

Package: wnpp
Severity: wishlist
Owner: Jon Dowland 

* Package name: lhasa
  Version : 0.0.4
  Upstream Author : Simon Howard 
* URL : http://fragglet.github.com/lhasa/
* License : ISC
  Programming Lang: C
  Description : lha archive decompressor

Lhasa is a library for parsing LHA (.lzh) archives and a free replacement
for the Unix LHA tool.

Currently it is only possible to read from (ie. decompress) archives;
generating (compressing) LHA archives may be an enhancement for future
versions. The aim is to be compatible with as many different variants
of the LHA file format as possible, including LArc (.lzs) and
PMarc (.pma). A suite of archives generated from different tools is
included for regression testing.

The command line tool aims to be interface-compatible with the non-free
Unix LHA tool (command line syntax and output), for backwards compatibility
with tools that expect particular output.

Lhasa is licensed under the ISC license, which is a simplified version of
the MIT/X11 license that is functionally identical.

It's my intention to initially package the lhasa binary and later add
the library package.


signature.asc
Description: Digital signature

Re: switching from exim to postfix

[Riku Voipio]

On Tue, May 01, 2012 at 08:18:07PM +0200, Philipp Kern wrote:
> So just stop Postfix doing the conversion?

It's not just postfix, it's at least courier and sendmail and various
propiertary MTA's do conversions when encountering default configured
exims.

It would be a RFC violation to just pass 8bit mails to servers not
advertizing 8bitmime. It would be rfc compatible to the sending server
to bounce instead of qp-converting 8bit mails, but that would arguably
be even worse. 

> Or teach Exim to announce 8BITMIME by default.

That would be a rfc violation as well. 

Riku


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502082913.ga15...@afflict.kos.to

Re: RFC: OpenRC as Init System for Debian

[Josselin Mouette]

Le dimanche 29 avril 2012 à 18:45 +0100, Roger Leigh a écrit : 
> As a
> trivial example: systemd creates user session information in
> /run/user/$user .  I brought up with lennart the fact that this would
> only permit one session per user.  He rejected out of hand the fact
> that more than one session would ever be needed, because Gnome only
> allowed one session per user.  So the limitations of Gnome in this
> respect have led to a fundamental limitation in systemd's session
> management.

There hasn’t been such a limitation in GNOME for years.

OTOH, there is a *design choice* in GDM 2.30+, which is to switch users
to a new session instead of starting a new one. This choice is
consistent with any thinkable reasonable use of a workstation (except
for testing purposes, but a production system should not be tailored for
testing requirements). 

Making the same design choice in systemd is consistent with this, but it
is way too restrictive for a low-level component, which could be used by
many other things than the display manager. In any case it is completely
unrelated to GNOME.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1335949080.4277.298.camel@pi0307572

Re: switching from exim to postfix

[Russell Coker]

On Wed, 2 May 2012, Riku Voipio  wrote:
> It would be a RFC violation to just pass 8bit mails to servers not
> advertizing 8bitmime. It would be rfc compatible to the sending server
> to bounce instead of qp-converting 8bit mails, but that would arguably
> be even worse. 

No, bouncing mail when it can't be properly delivered is much better than 
violating RFCs.

Mail that is bounced with a human readable message describing the real cause 
of the problem can then be re-sent once the problem is fixed.

Having mail be silently corrupted is not acceptable.

I've spent a lot of time debugging email problems over the years...

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205021905.14630.russ...@coker.com.au

Re: switching from exim to postfix

[Jon Dowland]

On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote:
> No it doesn't if 8BITMIME annouces are turned off!

If exim receives an 8 bit mail, even if it hadn't announced 8BITMIME in
the EHLO response, it will relay that message verbatim to other hosts.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502090631.GD17757@debian

Re: switching from exim to postfix

[Jon Dowland]

On Wed, May 02, 2012 at 07:05:14PM +1000, Russell Coker wrote:
> Having mail be silently corrupted is not acceptable.

Can you expand on "silently corrupted", here? Is that when you re-encode the
mail and send it on as 7-bit, or when you leave it alone and send it as 8 bit
to a host that doesn't advertise accepting 8-bit?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502090740.GE17757@debian

Re: Removing the MTA from the default install

[Jon Dowland]

On Wed, May 02, 2012 at 10:37:31AM +0200, Adam Borowski wrote:
> On Wed, May 02, 2012 at 10:02:37AM +0200, Josselin Mouette wrote:
> > Is this the right time to do it?
> 
> No.  Cron needs some way to report about its jobs, mdadm has to notify about
> failures, etc, etc.

Indeed, some form of tighter guarantees that the user will get these messages
would be welcome IMHO.  Perhaps all MUAs ship with a local account pre-defined
(for the "blessed" user who gets root's mail, at least).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502090951.GF17757@debian

Re: Removing the MTA from the default install

[Aron Xu]

On Wed, May 2, 2012 at 4:37 PM, Adam Borowski  wrote:
> On Wed, May 02, 2012 at 10:02:37AM +0200, Josselin Mouette wrote:
>> Is this the right time to do it?
>
> No.  Cron needs some way to report about its jobs, mdadm has to notify about
> failures, etc, etc.
>
> On the other hand, going from a full blown MTA like exim to something like
> ssmtp or dma¹ would be a great idea.


Ah, but then we should remove the "Mail server" option from d-i, which
is almost useless.


-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5-ikbB62EhZfbG94B77=njus0wlfnx_0g1ty6x-bu...@mail.gmail.com

Re: switching from exim to postfix

[Russell Coker]

On Wed, 2 May 2012, Jon Dowland  wrote:
> On Wed, May 02, 2012 at 07:05:14PM +1000, Russell Coker wrote:
> > Having mail be silently corrupted is not acceptable.
> 
> Can you expand on "silently corrupted", here? Is that when you re-encode
> the mail and send it on as 7-bit, or when you leave it alone and send it
> as 8 bit to a host that doesn't advertise accepting 8-bit?

When you send 8 bit mail to a host that only supports 7 bit then it will be 
corrupted, usually without any notification of what happened - definitely 
silent corruption.

When you re-encode mail and send it on IFF the message is DKIM signed it could 
be considered to be silent corruption as the change will usually count as 
breakage.

It would be possible for a DKIM verification program to re-encode 7bit 
messages to 8bit for a second attempt at verification.  But if a DKIM milter 
author was going to do tricky things then a better first option would be to 
try removing anything between [] in the subject line which is the most common 
cause of DKIM failures that I see on valid mail.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205021923.13856.russ...@coker.com.au

Bug#671180: RFP: libnginx-perl -- Nginx::Perl - full-featured perl support for nginx

[Roman V. Nikolaev]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

   Package name: libnginx-perl
Version: 1.2.0.4
Upstream Author: Alexandr Gomoliako 
URL: 
http://search.cpan.org/~zzz/Nginx-Perl-1.2.0.4/src/http/modules/perl/Perl.pm
License: same as "nginx" Debian package
Description: Nginx::Perl - full-featured perl support for nginx

-- 

 Roman V. Nikolaev

mail:rsha...@rambler.ru
icq: 198-364-657
jabber:  rsha...@jabber.org
site:http://www.rshadow.ru



signature.asc
Description: OpenPGP digital signature

Re: switching from exim to postfix

[Scott Kitterman]

On Wednesday, May 02, 2012 07:23:13 PM Russell Coker wrote:
> On Wed, 2 May 2012, Jon Dowland  wrote:
> > On Wed, May 02, 2012 at 07:05:14PM +1000, Russell Coker wrote:
> > > Having mail be silently corrupted is not acceptable.
> > 
> > Can you expand on "silently corrupted", here? Is that when you re-encode
> > the mail and send it on as 7-bit, or when you leave it alone and send it
> > as 8 bit to a host that doesn't advertise accepting 8-bit?
> 
> When you send 8 bit mail to a host that only supports 7 bit then it will be
> corrupted, usually without any notification of what happened - definitely
> silent corruption.
> 
> When you re-encode mail and send it on IFF the message is DKIM signed it
> could be considered to be silent corruption as the change will usually
> count as breakage.
> 
> It would be possible for a DKIM verification program to re-encode 7bit
> messages to 8bit for a second attempt at verification.  But if a DKIM milter
> author was going to do tricky things then a better first option would be to
> try removing anything between [] in the subject line which is the most
> common cause of DKIM failures that I see on valid mail.

That and mailing list footers.  

Receivers are, of course, free to manage inbound mail filtering however they 
want, but if you take a message and try to recode it from 7 bit to 8 bit and 
see if a DKIM signature passes verification, it's still not a valid DKIM 
signature in any sense that RFC 4871 or its successors would recognize.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1669928.j8eO2yxEKH@scott-latitude-e6320

Re: Removing the MTA from the default install

[Henrique de Moraes Holschuh]

On Wed, 02 May 2012, Aron Xu wrote:
> On Wed, May 2, 2012 at 4:37 PM, Adam Borowski  wrote:
> > On Wed, May 02, 2012 at 10:02:37AM +0200, Josselin Mouette wrote:
> >> Is this the right time to do it?
> > No.  Cron needs some way to report about its jobs, mdadm has to notify about
> > failures, etc, etc.
> >
> > On the other hand, going from a full blown MTA like exim to something like
> > ssmtp or dma¹ would be a great idea.
> 
> Ah, but then we should remove the "Mail server" option from d-i, which
> is almost useless.

No.  We can keep it, it just doesn't need to be selected by default.

However, we really should switch the mail server option to something that
would be suitable for mail servers (i.e. something that doesn't play stupid
games with standards), such as postfix.  I've advocated keeping the
status-quo in the past, but I was not aware of the exim4 brokenness.

I agree that installing "mda" by default on desktop installs would be
useful.  However IME, server installs are much better served by installing
postfix, even when they're not MTAs, let alone when they are MTAs...

-- 
  "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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502112448.ga17...@khazad-dum.debian.net

Re: switching from exim to postfix

[Russell Coker]

On Wed, 2 May 2012, Scott Kitterman  wrote:
> > It would be possible for a DKIM verification program to re-encode 7bit
> > messages to 8bit for a second attempt at verification.  But if a DKIM
> > milter author was going to do tricky things then a better first option
> > would be to try removing anything between [] in the subject line which
> > is the most common cause of DKIM failures that I see on valid mail.
> 
> That and mailing list footers.  

Footers can be solved with the l= flag.  The threat of a hostile party 
appending data to a message probably isn't something you really worry about 
when posting to a mailing list.

It would be possible for a DKIM signing program to use l= for every message 
which has a recipient address containing the string "list".

> Receivers are, of course, free to manage inbound mail filtering however
> they  want, but if you take a message and try to recode it from 7 bit to 8
> bit and see if a DKIM signature passes verification, it's still not a
> valid DKIM signature in any sense that RFC 4871 or its successors would
> recognize.

If a milter replaced the message body such that it matched then it would be.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205022131.30133.russ...@coker.com.au

Re: Node.js and it's future in debian

[Bernhard R. Link]

* Russ Allbery  [120501 19:28]:
> I have to admit that I'm tempted to change Policy from "if there's no
> consensus, rename both of them" to "if there's no consensus, try harder to
> reach a consensus, and the technical committee decides in last resort."
>
> Most of the time, renaming both of them isn't the right answer.

On the other hand, if renaming both of them is the only possible outcome
if both parties cannot agree, it makes it more likely both sides will
actually be willing to discuss the matter, instead of just issuing demands,
hoping the other side will either give up or will be overruled by the
TC at the end.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502124909.gb18...@server.brlink.eu

Re: Making -devel discussions more viable

[Bernhard R. Link]

* Russ Allbery  [120501 18:18]:
> David Bremner  writes:
> > "Bernhard R. Link"  writes:
> 
> >> My suggestion to everyone feeling the need to tell anyone on a public
> >> mailing list that they should shut up because they are no contributors
> >> is thus: Please refrain from any more posts to this discussion.
> 
> > I have nothing against this principle, and I do this. But I also stop
> > reading such threads. And this means I read less and less of this list.
> 
> Right.  As good as that idea sounds on the surface, what that actually
> translates into in practice is making debian-devel useless.

And how does enhancing the noise rate by adding mails not about technical
arguments make the mailing lists useful?

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502123933.ga18...@server.brlink.eu

Re: switching from exim to postfix

[Andrew Shadura]

Hello,

On Wed, 2 May 2012 10:06:31 +0100
Jon Dowland  wrote:

> On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote:
> > No it doesn't if 8BITMIME annouces are turned off!

> If exim receives an 8 bit mail, even if it hadn't announced 8BITMIME
> in the EHLO response, it will relay that message verbatim to other
> hosts.

But it won't receive it at all if the sender is standards-compliant.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Node.js and it's future in debian

[Jérémy Lal]

On 02/05/2012 14:49, Bernhard R. Link wrote:
> * Russ Allbery  [120501 19:28]:
>> I have to admit that I'm tempted to change Policy from "if there's no
>> consensus, rename both of them" to "if there's no consensus, try harder to
>> reach a consensus, and the technical committee decides in last resort."
>>
>> Most of the time, renaming both of them isn't the right answer.
> 
> On the other hand, if renaming both of them is the only possible outcome
> if both parties cannot agree, it makes it more likely both sides will
> actually be willing to discuss the matter, instead of just issuing demands,
> hoping the other side will either give up or will be overruled by the
> TC at the end.

Ok then, since i'm the nodejs maintainer, i'm willing to discuss this matter,
even privately if that is more effective, with someone representing the node
package, so we can close this issue in some way.

Jérémy Lal


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fa12f10.5010...@melix.org

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Andreas Tille]

Hi,

I just would like to warm up this thread a bit because I wonder if a
solution would be found in time for Wheezy release.  It seems nobody
really seems to care about those suggested scripts and we are breaking a
certain amount of programs if mailcap entries are dropped without any
replacement.  I wonder whether the severity of "important" is to weak to
reflect this.  Several people in this thread expressed their annoyance
about this but nothing has happened so far.  If nobody works on
automatic scripts (which are hard to write as Russ expressed here
because mailcap has features not implemented in freedesktop.org) should
we try something else to not spoil the wheezy user experience of terminal
addicted users?

Kind regards

  Andreas.

On Sat, Feb 18, 2012 at 04:44:10PM +0100, Raphael Hertzog wrote:
> Hello,
> 
> On Wed, 01 Feb 2012, Josselin Mouette wrote:
> > Le mardi 31 janvier 2012 à 21:51 +0100, Andreas Tille a écrit : 
> > > I agree that an automatic solution would be prefered.  However, as long
> > > as such someone does not stand up and write such a program removing
> > > existing solutions is .
> > 
> > The point is, no one will write such a program until we remove support
> > for the old system entirely.
> 
> FWIW, it looks like Josselin suggested this in #497779 more than 3 years
> ago already.
> 
> So he certainly tried something else before simply removing the mailcap
> file. I pinged the mime support maintainer, pointing to Russ' mail
> explaining how to generate mailcap entries out of the desktop files.
> 
> Hopefully this will help since he seemed interested into supporting this.
> 
> Cheers,
> -- 
> Raphaël Hertzog ◈ Debian Developer
> 
> Pre-order a copy of the Debian Administrator's Handbook and help
> liberate it: http://debian-handbook.info/liberation/
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/20120218154410.ga22...@rivendell.home.ouaza.com
> 
> 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502133020.gc21...@an3as.eu

Re: Removing the MTA from the default install

[Bjørn Mork]

Josselin Mouette  writes:

> Is this the right time to do it?

Wasn't this just recently discussed?  Just replay the thread:
http://lists.debian.org/debian-devel/2011/10/msg00227.html


Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k40u4s1g@nemi.mork.no

console-tools removal from sid / wheezy?

[Alastair McKinstry]

Hi,

Ok, might we proceed with the console-tools removal for wheezy?
Bugs have been filed against the following packages:
#645937  goto-fai
#671079 hotkey-setup
#671081 hibernate
#671082 gcpegg

to move to kbd rather than console-tools.

regards
Alastair


On 2011-10-19 16:37, Sven Joachim wrote:
> On 2011-10-19 14:35 +0200, Alastair McKinstry wrote:
>
>> I propose to remove console-tools from sid, in favour of kbd.
>> This is long planned: console-tools has been dead upstream for many
>> years, with only Debian and derivatives
>> still using it; For squeeze, kbd was made priority: optional and
>> console-tools priority: extra
>> (both provide virtual console-utilities).
>>
>> Does anyone have any objections?
> There seem to be a few packages which still depend on console-tools
> without an alternative dependency on kbd or console-utilities, e.g.
> goto-fai or gcpegg.  You probably want to file bugs against those.
>
> Otherwise, removing console-tools is a good idea IMO.
>
> Cheers,
>Sven
>
>


-- 
Alastair McKinstry  ,  , 
http://blog.sceal.ie

Anyone who believes exponential growth can go on forever in a finite world
is either a madman or an economist - Kenneth Boulter, Economist.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fa13804.9090...@debian.org

Re: Node.js and it's future in debian

[The Fungi]

On 2012-05-02 14:49:09 +0200 (+0200), Bernhard R. Link wrote:
> On the other hand, if renaming both of them is the only possible
> outcome if both parties cannot agree, it makes it more likely both
> sides will actually be willing to discuss the matter, instead of
> just issuing demands, hoping the other side will either give up or
> will be overruled by the TC at the end.

It seems to me to be more akin to, or some variant on, an
all-or-nothing Prisoner's Dilemma. Neither side is necessarily
encouraged to give in since the only "favorable" outcome for an
individual application--keeping its well-known name--comes from
holding out longest in the confrontation. In this scenario, altruism
on the part of one participant is the only alternative to preventing
an unfavorable outcome for both... and as such both sides (following
classic Game Theory principles) will default to the unfavorable
outcome. In other words, it does nothing to promote compromise
between uncooperative parties.

With the TC as an assumed impartial arbitrating body, this changes
the game to (theoretically) favor the side with the most effective
technical argument when neither can come to an agreement on their
own.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502135222.gu...@yuggoth.org

Bug#671209: ITP: libmoosex-role-timer-perl -- Role for measuring elapsed time with Time::HiRes

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org, 
m...@cpan.org

* Package name: libmoosex-role-timer-perl
  Version : 0.03
  Upstream Author : Michael Langner (m...@cpan.org)
* URL : http://search.cpan.org/dist/MooseX-Role-Timer/
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : Role for measuring elapsed time with Time::HiRes

MooseX::Role::Timer is a Moose role that provides timers to your
object, making it easier to keep track of how long whatever actions
take. Time is measured with Time::Hires so sub-second timers are possible.

This Perl module is patched to be compatible with Any::Moose. 

Dominique


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

Re: switching from exim to postfix

[Ben Hutchings]

On Wed, 2012-05-02 at 19:23 +1000, Russell Coker wrote:
> On Wed, 2 May 2012, Jon Dowland  wrote:
> > On Wed, May 02, 2012 at 07:05:14PM +1000, Russell Coker wrote:
> > > Having mail be silently corrupted is not acceptable.
> > 
> > Can you expand on "silently corrupted", here? Is that when you re-encode
> > the mail and send it on as 7-bit, or when you leave it alone and send it
> > as 8 bit to a host that doesn't advertise accepting 8-bit?
> 
> When you send 8 bit mail to a host that only supports 7 bit then it will be 
> corrupted, usually without any notification of what happened - definitely 
> silent corruption.
> 
> When you re-encode mail and send it on IFF the message is DKIM signed it 
> could 
> be considered to be silent corruption as the change will usually count as 
> breakage.
[...]

So DKIM is broken by design.  Not sure why anyone should care to work
around this.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


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

Re: The future of non-dependency-based boot

[James Cloos]

> "PR" == Petter Reinholdtsen  writes:

PR> You do not have to edit the init.d files themselves to override
PR> their dependencies, and risk them going away during upgrades.  I
PR> created the possibility for the system administrator to insert
PR> overrides in /etc/insserv/overrides/ for just this use case.

Good to know,

Thanks.

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m3pqam7k7e@carbon.jhcloos.org

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Ben Hutchings]

On Wed, 2012-05-02 at 15:30 +0200, Andreas Tille wrote:
> Hi,
> 
> I just would like to warm up this thread a bit because I wonder if a
> solution would be found in time for Wheezy release.  It seems nobody
> really seems to care about those suggested scripts and we are breaking a
> certain amount of programs if mailcap entries are dropped without any
> replacement.  I wonder whether the severity of "important" is to weak to
> reflect this.  Several people in this thread expressed their annoyance
> about this but nothing has happened so far.  If nobody works on
> automatic scripts (which are hard to write as Russ expressed here
> because mailcap has features not implemented in freedesktop.org) should
> we try something else to not spoil the wheezy user experience of terminal
> addicted users?

I'm also not seeing GNOME applications as file type handlers in
Akregator (KDE application).  So I'm not sure this is even 'just' a
problem for text-mode applications.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


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

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Sune Vuorela]

On 2012-05-02, Ben Hutchings  wrote:
> I'm also not seeing GNOME applications as file type handlers in
> Akregator (KDE application).  So I'm not sure this is even 'just' a
> problem for text-mode applications.

I just tried to install 'gedit' to test it, and I can nicely now set
gedit as a handler for text/plain mimetype in my KDE Plasma Desktop.

So it seems to integrate quite nicely ?

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjq2hde.p7v.nos...@sshway.ssh.pusling.com

Bug#671224: ITP: saint -- Significance Analysis of INTeractome

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: saint
  Version : 2.3.3
  Upstream Author : Hyung Won Choi 
* URL : http://saint-apms.sourceforge.net/Main.html
* License : GPL
  Programming Lang: C
  Description : Significance Analysis of INTeractome
 SAINT implements the scoring algorithm for protein-protein interaction
 data using label free quantitative proteomics data in AP-MS experiments.
 It was used for spectral count data in the yeast kinase interactome work
 not incorporating control purification, as well as a generalized
 implementation for spectral count data with and without control
 purification.
 .
 Alternatively, you can also run SAINT in combination with ProHits.
 .
 The package was written for either doing analysis without or with
 control IPs and

The package will be maintained in the Debian Med team and the packaging
code is available at
   svn://svn.debian.org/debian-med/trunk/packages/saint/trunk/



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120502145655.23714.41304.report...@mail.an3as.eu

Re: Removing the MTA from the default install

[Aron Xu]

On Wed, May 2, 2012 at 7:24 PM, Henrique de Moraes Holschuh
 wrote:
> On Wed, 02 May 2012, Aron Xu wrote:
>> On Wed, May 2, 2012 at 4:37 PM, Adam Borowski  wrote:
>> > On Wed, May 02, 2012 at 10:02:37AM +0200, Josselin Mouette wrote:
>> >> Is this the right time to do it?
>> > No.  Cron needs some way to report about its jobs, mdadm has to notify 
>> > about
>> > failures, etc, etc.
>> >
>> > On the other hand, going from a full blown MTA like exim to something like
>> > ssmtp or dma¹ would be a great idea.
>>
>> Ah, but then we should remove the "Mail server" option from d-i, which
>> is almost useless.
>
> No.  We can keep it, it just doesn't need to be selected by default.
>

Currently if I select only OpenSSH server and basic system tools in
expert mode, Exim gets installed, too.

> However, we really should switch the mail server option to something that
> would be suitable for mail servers (i.e. something that doesn't play stupid
> games with standards), such as postfix.  I've advocated keeping the
> status-quo in the past, but I was not aware of the exim4 brokenness.
>
> I agree that installing "mda" by default on desktop installs would be
> useful.  However IME, server installs are much better served by installing
> postfix, even when they're not MTAs, let alone when they are MTAs...
>

I don't think installing mail servers for desktop installation can be
_that_ useful, not all Debian users are power users who read system
email and mutt (or likewise).


-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4mtmk3-gz5acnoc2tzg_xqhfmzctbxkfvhy6xdc_a...@mail.gmail.com

Re: Making -devel discussions more viable

[Russ Allbery]

"Bernhard R. Link"  writes:
> * Russ Allbery  [120501 18:18]:
>> David Bremner  writes:
>>> "Bernhard R. Link"  writes:

 My suggestion to everyone feeling the need to tell anyone on a public
 mailing list that they should shut up because they are no contributors
 is thus: Please refrain from any more posts to this discussion.

>>> I have nothing against this principle, and I do this. But I also stop
>>> reading such threads. And this means I read less and less of this list.

>> Right.  As good as that idea sounds on the surface, what that actually
>> translates into in practice is making debian-devel useless.

> And how does enhancing the noise rate by adding mails not about
> technical arguments make the mailing lists useful?

That's why I drew the distinction between "on the surface" and "in
practice."  On the surface, it's a good idea because one doesn't add to
the noise.  In practice, it leaves the problem unaddressed and technical
contributors just leave.

Telling people that there's nothing they can do about the noise and they
should just give up and ignore it means that people will stop reading the
mailing list and the only people left to have discussions are the people
who enjoy the noise.  I don't want technical decisions in this project to
only be discussed by people who enjoy the noise.

So, while "don't add to the noise" is *part* of the solution, if one just
says that and puts a period at the end, it makes the problem worse.  It
needs to be part of a solution that actually *reduces the noise*.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqampnzc@windlord.stanford.edu

Re: Making -devel discussions more viable

[Bernhard R. Link]

* Russ Allbery  [120502 18:06]:
> I don't want technical decisions in this project to
> only be discussed by people who enjoy the noise.

That's why it is cruical to get the noise reduced. If in any discussion
there is a DD escalating the flames then there won't be any people with
technical arguments left. Getting some non-contributers out of the
picture will not change it much. I wholeheartly believe that the only
reason you see those people so prominently is that everything else
already is in ignore mode because of contributors heating the flames.

> So, while "don't add to the noise" is *part* of the solution, if one just
> says that and puts a period at the end, it makes the problem worse.  It
> needs to be part of a solution that actually *reduces the noise*.

Not adding to the noise is reducing the noise. And especially telling
people that you do not care about their arguments because you they are
not insiders, which this is from some point of view, is the noise that
makes an discussion in my eyes the most unwelcoming and thus a good
reason to only expect noise and no more signal.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502164118.gb2...@client.brlink.eu

Re: RFC: OpenRC as Init System for Debian

[Martin Wuertele]

* Carlos Alberto Lopez Perez  [2012-05-01 23:07]:

> On 27/04/12 19:33, Tollef Fog Heen wrote:
> > ]] Martin Wuertele 
> > 
> >> * Josselin Mouette  [2012-04-27 09:53]:
> >>
> >>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
> > Yes of course, because event-driven init systems have *always* been
> > *only* about mounting USB devices. 
> 
>  Then explain the _real_ reasons for having an event driven boot system!
> >>>
> >>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
> >>
> >> That's a reason for udev/mdev, however I still fail to see why this
> >> results in the requirement for an event based boot process. 
> > 
> > A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
> > mounted and /srv/somewhere comes off iscsi, which means it requires
> > networking to be up, which means network drivers loaded, etc.  So the
> > event «network driver loaded» causes ifup to be spawned, which causes
> > $network to be satisfied which causes the iscsi daemons to be started
> > which causes mount to be called.
> > 
> 
> A better example is bluetooth.
> 
> In my Debian system I have /usr/sbin/bluetoothd running and I don't have
> any bluetooth devices on my system... So wouldn't be better that instead
> of launching the bluetooth daemon and let it waiting for the day that I
> plug a USB bluetooth device (and still I never did that) to just launch
> this daemon only when the kernel detects a bluetooth device?

I don't think this is a better example. Actually I think this is an
example where udev/mdev could launch/stop bluetoothd.

Yours Martin


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502170533.ga11...@anguilla.debian.or.at

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Wookey]

+++ Patrick Ouellette [2012-05-01 23:12 -0400]:
> Of course the #! line is not the issue.  The issue is two upstream maintainers
> separated by years and miles selected the same generic name for their binary
> file.  Compounding the issue, some Debian Maintainer seeking to better the
> project by packaging additional software for the project failed to perform
> "due diligence" in researching if any of the binary names from the proposed
> new package were already in use. 

Just a quick question - is there an easy way to do this? I worry
sometimes that I might be creating a binary name that is already used
somewhere, and thus a potential clash, but it is not obvious to me how
to check. Strictly this applies to every file in a package, although
clashes are most likely in /usr/bin


Wookey


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502165354.gc13...@stoneboat.aleph1.co.uk

Re: switching from exim to postfix

[Andreas Metzler]

Russell Coker  wrote:
[...]
> When you send 8 bit mail to a host that only supports 7 bit then it will be 
> corrupted, usually without any notification of what happened - definitely 
> silent corruption.
[...]


Have you really seen this happening in this century? Are there really
MTAs active in the wild nowadays which are not 8-bit clean?

I thought all of these were fixed when qmail was popular.

cu andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pr7879-3kr@argenau.downhill.at.eu.org

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Russ Allbery]

Wookey  writes:

> Just a quick question - is there an easy way to do this? I worry
> sometimes that I might be creating a binary name that is already used
> somewhere, and thus a potential clash, but it is not obvious to me how
> to check. Strictly this applies to every file in a package, although
> clashes are most likely in /usr/bin

I usually just search Debian, since we have most things, but it's not a
great solution.  djb at one point tried to start a registry of command
names at http://cr.yp.to/slashcommand/used but I don't think it's been
maintained.  (It doesn't, for example, have node.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjfio547@windlord.stanford.edu

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Neil Williams]

On Wed, 2 May 2012 17:53:54 +0100
Wookey  wrote:

> +++ Patrick Ouellette [2012-05-01 23:12 -0400]:
> > file.  Compounding the issue, some Debian Maintainer seeking to better the
> > project by packaging additional software for the project failed to perform
> > "due diligence" in researching if any of the binary names from the proposed
> > new package were already in use. 
> 
> Just a quick question - is there an easy way to do this? I worry
> sometimes that I might be creating a binary name that is already used
> somewhere, and thus a potential clash, but it is not obvious to me how
> to check. Strictly this applies to every file in a package, although
> clashes are most likely in /usr/bin

ftp://ftp.uk.debian.org/debian/dists/sid/Contents-amd64.gz ?

$ zgrep bin Contents-amd64.gz |wc -l
78822

There's also http://packages.debian.org/#search_contents which can
search for files listed within packages.

The 23Mb size of Contents*.gz is a barrier to doing this automatically
or via lintian etc. For those with slow connections, p.d.o is possibly
the best option, for specific files which may have problems.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgphaCBgcxkMs.pgp
Description: PGP signature

Re: switching from exim to postfix

[Christian PERRIER]

(slightly off-topic)

Quoting Russell Coker (russ...@coker.com.au):

> No, bouncing mail when it can't be properly delivered is much better than 
> violating RFCs.
> 
> Mail that is bounced with a human readable message describing the real cause 
> of the problem can then be re-sent once the problem is fixed.


You mean a message readable by a human even when it happens that this
human is a non English-speaking non-geek person? :-)

All MTA bounce messages are just plain unreadable crap for the average
human on Earth, I'm afraid. For some of them, it's even worse than
Vogon poetry.

(and, no, I have no solution to this, by the way...just reacting to
the assumption that bounce messages are readable: they are not)



signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Michael Biebl]

On 02.05.2012 19:05, Martin Wuertele wrote:
> I don't think this is a better example. Actually I think this is an
> example where udev/mdev could launch/stop bluetoothd.

Long running daemons should *not* be started by udev. udev is *not* a
service manager.
What udev should do is signal the init system that the device is
available and the init system will start and manage the daemon. That's
what systemd and upstart do.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Tollef Fog Heen]

]] Wookey 

> Just a quick question - is there an easy way to do this?

Given most names don't explain particularly well what the command does,
just use something inspired by pwgen.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk9q4acm@qurzaw.varnish-software.com

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Adam D. Barratt]

On Wed, 2012-05-02 at 17:53 +0100, Wookey wrote:
> +++ Patrick Ouellette [2012-05-01 23:12 -0400]:
> > Of course the #! line is not the issue.  The issue is two upstream 
> > maintainers
> > separated by years and miles selected the same generic name for their binary
> > file.  Compounding the issue, some Debian Maintainer seeking to better the
> > project by packaging additional software for the project failed to perform
> > "due diligence" in researching if any of the binary names from the proposed
> > new package were already in use. 
> 
> Just a quick question - is there an easy way to do this?

At least for projects hosted / listed on a variety of sites such as
freshmeat^Wfreecode, there's Steve Kemp's "namecheck" script, a version
of which is included in devscripts.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1335989318.24513.18.ca...@jacala.jungle.funky-badger.org

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Jon Dowland]

On Wed, May 02, 2012 at 05:53:54PM +0100, Wookey wrote:
> Just a quick question - is there an easy way to do this? I worry
> sometimes that I might be creating a binary name that is already used
> somewhere, and thus a potential clash, but it is not obvious to me how
> to check. Strictly this applies to every file in a package, although
> clashes are most likely in /usr/bin

I wonder if there's any mileage in a lintian check against e.g. a local apt-file
cache (removing files belonging to a package binary name that your source 
package
claims to offer)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502202701.GA12471@debian

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Russ Allbery]

Patrick Ouellette  writes:

> I'm more than a bit disappointed that this will be the second time a ham
> radio tool in Debian is forced to use a name the wider Linux ham
> community does not use.  No one seems to be considering the issues or
> complications caused to the ham users.  I've heard the assertion that
> the ham users are a "smaller" community, but I have not seen the
> numbers.  It seems the issue has come down to a popularity contest, and
> since the Node.js folks don't understand ham radio the ham radio people
> will be made to bear the burden of the change.

Speaking solely for myself, the primary reason why it seems reasonable to
me to just rename the ham radio node program is that it's in /usr/sbin and
not meant to be regularly run directly by users, but rather to be
configured once and then largely left alone.  That means that coping with
a non-standard name is quite a bit easier than with a program that's meant
to be run regularly by end users.

The place where the popularity comes into play for me is in weighing the
impact on our users for calling the Node.js node program something else.
My *default* opinion, when there's a package already in Debian and another
comes along with a binary with the same name, is to just shrug and say
"first come, first serve" and tell the second group to call their program
something different.  It's the popularity and the expectations of our
users that in this case I think warrant looking further into other
possible solutions.  But I wouldn't extend that to say that the ham radio
folks should obviously "lose."

If the ham radio node program were also a user interface routinely used by
end users instead of used as part of system configuration, this would be a
much harder discussion.  Thankfully, that doesn't appear to be the case.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bom6i7ja@windlord.stanford.edu

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Patrick Ouellette]

On Tue, May 01, 2012 at 08:22:05PM -0700, Russ Allbery wrote:
> 
> Maybe we should short-circuit this part of the conversation, since it
> doesn't sound like you're horribly interested in agreeing to change the
> name of node in the existing package.  :)
> 

Actually, despite my vigorous defense of the ham radio use of node as
a binary name, I am not adverse to renaming it provided it can be done
in a manner that minimally disrupts the users.

I believe the Node.js people need to help since they are the "late comers"
and their upstream seems to be the issue, and they ignored policy at their
peril to force the issue.

I'm more than a bit disappointed that this will be the second time a ham radio
tool in Debian is forced to use a name the wider Linux ham community does not
use.  No one seems to be considering the issues or complications caused to the
ham users.  I've heard the assertion that the ham users are a "smaller"
community, but I have not seen the numbers.  It seems the issue has come down
to a popularity contest, and since the Node.js folks don't understand ham 
radio the ham radio people will be made to bear the burden of the change.


> I think it would make sense to take this to the Technical Committee at
> this point and just make a decision, unless anyone thinks something
> substantially new is likely to turn up.  (We should probably give it a few
> more days to see if anything does, but it's feeling increasingly unlikely
> to me, as is the idea that we're all going to reach a consensus.)
> 

I forwarded the message proposing the Node.js people step up with a migration
plan and code to transition the ham radio package to the linux-hams list.
It usually takes a few days to get any substantive comments on that list.


Pat
-- 
,-.
> Patrick Ouellette|  It is no use walking anywhere to preach unless  <
> pat(at)flying-gecko.net  |  our walking is our preaching.   <
> Amateur Radio: NE4PO |  -- Francis of Assisi<
`-'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502211033.gk7...@flying-gecko.net

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Patrick Ouellette]

On Wed, May 02, 2012 at 06:43:04PM +0100, Neil Williams wrote:
> 
> There's also http://packages.debian.org/#search_contents which can
> search for files listed within packages.
> 

That's where I check.

Pat
-- 
,-.
>  Patrick Ouellette|  No one is to be called an enemy, all are your  <
>  pat(at)flying-gecko.net  |  benefactors, and no one does you harm. <
>  Amateur Radio: NE4PO |  You have no enemy except yourselves.   <
>   |  -- Francis of Assisi   <
`-'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502211226.gl7...@flying-gecko.net

Re: switching from exim to postfix

[Henrique de Moraes Holschuh]

On Wed, 02 May 2012, Christian PERRIER wrote:
> (slightly off-topic)
> Quoting Russell Coker (russ...@coker.com.au):
> > No, bouncing mail when it can't be properly delivered is much better than 
> > violating RFCs.
> > 
> > Mail that is bounced with a human readable message describing the real 
> > cause 
> > of the problem can then be re-sent once the problem is fixed.
> 
> You mean a message readable by a human even when it happens that this
> human is a non English-speaking non-geek person? :-)

Well, FWIW postfix allows you to override all MTA notifications, not just
bounce messages, but the full set.  We do that at work.

> All MTA bounce messages are just plain unreadable crap for the average
> human on Earth, I'm afraid. For some of them, it's even worse than
> Vogon poetry.

IME this is true even after you translate it to the local language and dumb
it down a whole lot.

-- 
  "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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502232308.ga15...@khazad-dum.debian.net

Re: Removing the MTA from the default install

[Chris Knadle]

On Wednesday, May 02, 2012 04:37:31, Adam Borowski wrote:
> On Wed, May 02, 2012 at 10:02:37AM +0200, Josselin Mouette wrote:
> > Is this the right time to do it?

FWIW, de-selecting "standard system" tasksel option (at least when using the 
netinstall .iso) results in an installation with no MTA.

> No.  Cron needs some way to report about its jobs, mdadm has to notify
> about failures, etc, etc.

There's been a lot of discussion in the past concerning several MUAs which by 
default don't show local mail.  [more on this below]

> On the other hand, going from a full blown MTA like exim to something like
> ssmtp or dma¹ would be a great idea.
> 
> [¹]. dma would be far better as it can handle transient failures when
> configured to send to a remote host, however, that cronjob every 5 minutes
> disqualifies it for the job of a laptop MTA.  That's fixable, though.

During testing DMA yesterday I realized that I hadn't set up my laptop to 
forward mail externally.  It turned out that the system was trying to notify 
me about files existing in /lost+found.  [This is not a surprise, because I'm 
using XFS on top of LUKS encryption, and I recently had to hard-power-off the 
box.]

I was successful in getting DMA to send mail using SMTP AUTH over TLS to port 
587.  [The only snag was that I had to reconfigure Mutt to set 
"envelope_from=yes", otherwise the sending email address was invalid, but this 
isn't DMA's fault.  :-P]

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


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

Re: switching from exim to postfix

[Vincent Lefevre]

On 2012-05-02 15:00:36 +0200, Andrew Shadura wrote:
> Hello,
> 
> On Wed, 2 May 2012 10:06:31 +0100
> Jon Dowland  wrote:
> 
> > On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote:
> > > No it doesn't if 8BITMIME annouces are turned off!
> 
> > If exim receives an 8 bit mail, even if it hadn't announced 8BITMIME
> > in the EHLO response, it will relay that message verbatim to other
> > hosts.
> 
> But it won't receive it at all if the sender is standards-compliant.

True for SMTP. But what if exim received an 8-bit mail by another
mean (e.g. on the command line via the sendmail command)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120503001506.gd5...@xvii.vinc17.org

Re: switching from exim to postfix

[Scott Kitterman]

Vincent Lefevre  wrote:

>On 2012-05-02 15:00:36 +0200, Andrew Shadura wrote:
>> Hello,
>> 
>> On Wed, 2 May 2012 10:06:31 +0100
>> Jon Dowland  wrote:
>> 
>> > On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote:
>> > > No it doesn't if 8BITMIME annouces are turned off!
>> 
>> > If exim receives an 8 bit mail, even if it hadn't announced
>8BITMIME
>> > in the EHLO response, it will relay that message verbatim to other
>> > hosts.
>> 
>> But it won't receive it at all if the sender is standards-compliant.
>
>True for SMTP. But what if exim received an 8-bit mail by another
>mean (e.g. on the command line via the sendmail command)?

Then it's irrelevant to the discussion. It's a local system issue and it's up 
to the local administrator. Internet standards have nothing to do with it.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/572df31b-7661-487c-8e43-5b150234a...@email.android.com

Re: switching from exim to postfix

[Vincent Lefevre]

On 2012-05-02 20:23:41 -0400, Scott Kitterman wrote:
> Vincent Lefevre  wrote:
> >On 2012-05-02 15:00:36 +0200, Andrew Shadura wrote:
> >> Hello,
> >> 
> >> On Wed, 2 May 2012 10:06:31 +0100
> >> Jon Dowland  wrote:
> >> 
> >> > On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote:
> >> > > No it doesn't if 8BITMIME annouces are turned off!
> >> 
> >> > If exim receives an 8 bit mail, even if it hadn't announced
> >8BITMIME
> >> > in the EHLO response, it will relay that message verbatim to other
> >> > hosts.
> >> 
> >> But it won't receive it at all if the sender is standards-compliant.
> >
> >True for SMTP. But what if exim received an 8-bit mail by another
> >mean (e.g. on the command line via the sendmail command)?
> 
> Then it's irrelevant to the discussion. It's a local system issue
> and it's up to the local administrator. Internet standards have
> nothing to do with it.

Wrong. It's relevant in the sense that Exim will transmit the mail
to a remote MTA. If it doesn't do the 8-bit to 7-bit conversion if
the remote MTA doesn't announce 8BITMIME, then Exim is broken.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120503004506.ga25...@xvii.vinc17.org

Re: RFC: OpenRC as Init System for Debian

[Patrick Lauer]

On 05/03/12 02:16, Michael Biebl wrote:
> On 02.05.2012 19:05, Martin Wuertele wrote:
>> I don't think this is a better example. Actually I think this is an
>> example where udev/mdev could launch/stop bluetoothd.
> Long running daemons should *not* be started by udev. udev is *not* a
> service manager.
> What udev should do is signal the init system that the device is
> available and the init system will start and manage the daemon. That's
> what systemd and upstart do.
>
So, this whole sub-thread boils down to this:

"Our current init scripts don't handle dependencies properly"

Once you fix that you can just let udev trigger /etc/init.d/bluetooth
start, and that will do all the needed magic properly.

... and OpenRC has been doing that for such a long time that I find it
hard to understand that people are still not using it ;)

I'm still slightly confused what people mean with "event based", I think
there are at least three similar, but distinct definitions going around.
A good part of that is already handled by the device manager, and the
rest appears to be user actions - if someone can find me a good example
of an event that doesn't fit into these categories I might understand
why from my point of view people seem to be violently agreeing so hard.

Thanks,

Patrick


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fa1d733.5040...@gentoo.org

#508644 Sorting out mail-transport-agent mess (was Re: switching from exim to postfix

[Holger Levsen]

Hi,

On Sonntag, 29. April 2012, Roger Leigh wrote:
> On Sun, Apr 29, 2012 at 07:03:11PM +0200, Julien Cristau wrote:
> > The 500 packages that would have to change their Depends from "exim4 |
> > mta" to something else.
> The brokenness of having to have a default package hardcoded in
> every virtual dependency rather than having a virtual defaults
> package and/or central list is an insanity I wish we could have
> fixed years ago. 

yeah, if only people used the bts more often ;) This problem is being tracked 
since 4 years...

If the BTS is right, it's only three packages blocking #508644
 "Sorting out mail-transport-agent mess":

Fix blocked by 645024: fwknop-server: dependencies spell default-mta wrong, 
645022: nmh: please change Recommends to default-mta | mail-transport-agent, 
645020: pyca: please change Depends to default-mta | mail-transport-agent

;-)


cheers,
Holger

P.S.: please only reply to the bug#, that will make sure it reaches debian-
devel@ - I just cc:ed the list to keep the thread views intact...


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205021920.39532.hol...@layer-acht.org

smaller than 0 but not negative (Re: question about "Conflicts:"

[Holger Levsen]

Hi,

On Montag, 30. April 2012, Ralf Treinen wrote:
> Conflicts: foo (>= 0), foo (<< 0)
> to be exact, since versions smaller than 0 are possible.

*grin*

btw, is the concept of numbers smaller than zero but not negative known/used 
anywhere outside of debian/dpkg?


cheers,
Holger


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205021928.39275.hol...@layer-acht.org

Re: smaller than 0 but not negative (Re: question about "Conflicts:"

[Cyril Brulebois]

Holger Levsen  (02/05/2012):
> *grin*
> 
> btw, is the concept of numbers smaller than zero but not negative known/used 
> anywhere outside of debian/dpkg?

Something like that?
  https://en.wikipedia.org/wiki/Signed_zero

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: switching from exim to postfix

[Scott Kitterman]

On Thursday, May 03, 2012 02:45:06 AM Vincent Lefevre wrote:
> On 2012-05-02 20:23:41 -0400, Scott Kitterman wrote:
> > Vincent Lefevre  wrote:
> > >On 2012-05-02 15:00:36 +0200, Andrew Shadura wrote:
> > >> Hello,
> > >> 
> > >> On Wed, 2 May 2012 10:06:31 +0100
> > >> 
> > >> Jon Dowland  wrote:
> > >> > On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote:
> > >> > > No it doesn't if 8BITMIME annouces are turned off!
> > >> > 
> > >> > If exim receives an 8 bit mail, even if it hadn't announced
> > >
> > >8BITMIME
> > >
> > >> > in the EHLO response, it will relay that message verbatim to other
> > >> > hosts.
> > >> 
> > >> But it won't receive it at all if the sender is standards-compliant.
> > >
> > >True for SMTP. But what if exim received an 8-bit mail by another
> > >mean (e.g. on the command line via the sendmail command)?
> > 
> > Then it's irrelevant to the discussion. It's a local system issue
> > and it's up to the local administrator. Internet standards have
> > nothing to do with it.
> 
> Wrong. It's relevant in the sense that Exim will transmit the mail
> to a remote MTA. If it doesn't do the 8-bit to 7-bit conversion if
> the remote MTA doesn't announce 8BITMIME, then Exim is broken.

True, but that's a different bit of brokenness.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1402413.fhnghq13dI@scott-latitude-e6320

Re: switching from exim to postfix

[Russell Coker]

On Thu, 3 May 2012, Henrique de Moraes Holschuh  wrote:
> > All MTA bounce messages are just plain unreadable crap for the average
> > human on Earth, I'm afraid. For some of them, it's even worse than
> > Vogon poetry.
> 
> IME this is true even after you translate it to the local language and dumb
> it down a whole lot.

For non-technical users the best thing to do is to have an error message 
that's informative to a sysadmin which they can paste or forward to someone 
who can fix it.

One of my pet hates with some MS email software is when it doesn't display the 
real error message to the user and hides it in a way that's beyond the ability 
of the non-technical user to discover and report.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205031222.23307.russ...@coker.com.au

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Charles Plessy]

Hi all,

I think that we are asking the impossible, to be universal, cover a large
number of fields, and fit all of this in a single name space witout conflicts.

With our current approach, to rename at least one of the program names, we make
Debian systems incompatible with outside documentation and scripts, and one of
the drawbacks of this approach is that there is no easy way to mechanically
discover and report to the user which programs have been renamed compared to
their original upstream distribution.

If we would tolerate conflicts, we would not support the parallel use of some
of our packages, but there would be the benefit that the package dependancy
graph could be parsed to report clusters of mutually-incompatible packages.
Often, these incompatibilities will not correspond to use cases, as there is an
obvious selection pressure upstream to avoid conflicts with other programs that
are directlyqused in combination with the upstream work.

A third solution is possible (and of course requires work), it would be to
implement namespaces in a similar way to the alternative system.  Packages
competing for a program name would have the original upstream name in one
namespace, and leave it to the other package(s) in other namespaces.

Lastly, I just read Fedora's page about packaging conflicts, and noted
that among the recommendations, there is a suggestion to coordinate
with the other distributions in case of renaming.  

  http://fedoraproject.org/wiki/Packaging:Conflicts#Approaching_Upstream

Perhaps it would be usefult to see what they would think of renaming the ham
radio 'node' (it looks like currently the renamed program is the one of the
draft node.js package).

  https://bugzilla.redhat.com/show_bug.cgi?id=815018

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120503034742.gd20...@falafel.plessy.net

Re: Making -devel discussions more viable

[Raphael Hertzog]

Hi,

On Wed, 02 May 2012, Bernhard R. Link wrote:
> Not adding to the noise is reducing the noise. And especially telling
> people that you do not care about their arguments because you they are
> not insiders, which this is from some point of view, is the noise that
> makes an discussion in my eyes the most unwelcoming and thus a good
> reason to only expect noise and no more signal.

Which is why I reply to those "outsiders" privately and gently point
them to a page that lists some of the mistakes they are doing
(FTR it's http://raphaelhertzog.com/go/ml/).

I certainly agree with Russ that several non-contributors had a
significant negative impact on recent discussions and that we ought
to be doing something about this.

When I see that the bad patterns tend to continue, I mail the listmasters
and ask them to send a warning to to the person. If enough persons
complain, they might even put a filter if that person doesn't stop.

But it's difficult to do it on a regular basis because:
- if I'm alone doing it, it won't have much impact
- given I have no way to know that others are doing the same, I tend to
  assume that it doesn't help much, and thus loses some of the motivation
  to draft gentle replies pointing out the problematic behaviour

Maybe we need a private DD-only list where people interested in
improving our lists can CC their private complaints. listmasters
could follow the list and take action when they notice that
the same person got multiple complaints.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120503065041.ga4...@rivendell.home.ouaza.com