Re: Switching to mozilla ESR in stable-security

[Simon McVittie]

On 29/05/13 00:17, John Paul Adrian Glaubitz wrote:
> Also, if anyone of the GNOME package maintainers is reading this,
> why does the gnome meta package depend on xul-ext-adblock-plus?

"For feature parity with the previous meta-gnome3 web browser", it appears:

meta-gnome3 (1:3.4+3) unstable; urgency=low
...
  * Install iceweasel instead of epiphany :(
See bug#682481.
  * Let gnome recommend iceweasel-l10n-all.
  * Drop RSS readers recommendations.
  * Require firefox extensions that match epiphany functionality:
keyring, adblock.
...
 -- Josselin Mouette   Sat, 29 Sep 2012 10:36:58 +0200

Regards,
S


-- 
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/51a5a54c.9070...@debian.org

Re: default MTA

[Chris Knadle]

On Monday, May 27, 2013 21:02:22, Marco d'Itri wrote:
> Now that we are done with systemd for the time being, can we have the
> flame war about replacing Exim with Postfix as the default MTA?
> 
> Are there any objections other than "but I like it this way!"?

What are the reasons to make the switch?  (I think it's more important to hear 
the "pro" reasoning than the "con" reasoning.)



But to answer your question: my "objections" to Postfix over Exim,
off-the-top-of-my-head:

  - Exim is more popular

http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html

  - Exim has a GPL license, which is preferable IMHO.

Postfix uses the "IBM Public License" which places any liability on
the distributor of the software, and has some other unfortunate
clauses and is GPL incompatible.

https://en.wikipedia.org/wiki/IBM_Public_License

  - Exim configuration is more human readable than Postifx's, IMHO.

Postfix configuration is concise but terse, and there are typically
blocks of options separated by commas that doesn't easily allow
commenting on specific config options.

  - Exim logging is cleaner than Postfix's, IMHO.  Postfix seems to
"redeliver mail to itself" repeatedly which makes it more difficult
to grep the logs for a complete transaction.


  -- Chris

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


-- 
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/201305290218.03379.chris.kna...@coredump.us

Re: default MTA

[Chris Knadle]

On Tuesday, May 28, 2013 19:32:08, Carlos Alberto Lopez Perez wrote:
> On 28/05/13 18:53, Don Armstrong wrote:
> > On Tue, 28 May 2013, Arno Töll wrote:
> >> Why not consider something light, better suited for most systems which
> >> need nothing but a sendmail binary which is suited to relay to a
> >> real(tm) mail-server and deliver local mail and does not involve lots
> >> of configuration and/or listening ports?
> > 
> > nullmailer or similar can do this fairly well. You really only need to
> > have 1) configured the remote smart host 2) a remote e-mail address to
> > send all local mail to.
> 
> We already (I believe) ship exim4-daemon-light as default MTA. I don't
> know how much lighter are the alternatives like dma or nullmailer.
> 
> I tried both, and I ended going back to exim4-daemon-light because of
> the problems I had with them (#686164 #697871 and #329192).

Similarly, a while back I tried using the ssmtp package (on an embedded 
system) and ran into problems because it doesn't spool messages, so any 
sending failure (such as are caused by greylisting) causes messages to get 
lost.

> So I'm not sure if is worth the effort changing the default MTA.
> 
> 
> Does anybody recommend any light MTA other than this ones?

The only reason I know of to run something lighter than exim4-daemon-light is 
if you need an MTA on an embedded system.  Embedded systems are a special case 
because local storage is a premium, and the local storage is likely flash 
which has limited rewrite cycles.  Even here my preferred solution here is to 
increase the local storage enough to run exim4-daemon-light, because that's 
been reliable for me.

  -- Chris

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


-- 
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/201305290228.03454.chris.kna...@coredump.us

Re: MBF: transition from texi2html to texinfo

[Steve Langasek]

On Tue, May 28, 2013 at 10:45:25PM -0400, Ryan Kavanagh wrote:
> On Tue, May 28, 2013 at 05:08:06PM -0700, Steve Langasek wrote:
> > There have been two responses to your proposal so far, neither of
> > which particularly looks to be in favor of your plan.  I don't think
> > it's reasonable to proceed with a mass-bug filing on over 800 packages
> > as a first step, certainly not after such a short comment period.

> As for the package count, where did you find the additional 700+
> packages? If I'm missing something, please let me know. Of matches in
> the search[0] Paul Wise linked to, many matches are from the same
> package, or more prominently (as with e.g., festival, gcc, geiser,
> id-utils, gcl, etc.), found in the upstream build system but never
> called at build time (one can deduce this from the fact that they don't
> build-depend on texi2html). As I stated in my initial email, there are
> at most 96 packages which would require some form of change, and these
> are the packages that either build-depend (94) or depend (2) on
> texi2html.

Oops, sorry, I misread Paul's mail.  I see now that he wrote that there were
"877 pages worth [of matches] in Debian sid", not that there were 877
*packages*.

So 100 packages does seem much more reasonable to me for an MBF, yes.

> > Why are you not proposing to provide a texi2html wrapper from the
> > makeinfo package which translates the arguments as described on
> > , and have makeinfo
> > Provide: texi2html?

> If by this, you mean remove the texi2html package from the archive after
> introducing the texi2html wrapper for makeinfo, and hope people would
> then transition after being warned by lintian, then it would fail to
> address Sébastien's concerns.

That concern being that makeinfo is not a drop-in replacement for texi2html
functionality, and therefore this would cause regressions - ok.

> If you mean something else, could please explain in greater detail what
> you meant, and how it would allow me to remove the texi2html package
> much more quickly from the archive than with my current plan?

It is still *potentially* faster, in the sense that in both cases, texi2html
can't really be removed until makeinfo is a feature-complete replacement,
but in one case we have to wait for all the other reverse-deps to also be
updated whereas in the other case we *only* need updates on the makeinfo
side (@math support + wrapper) to unblock the texi2html removal.  I guess
it's a question of whether we think @math support is going to be on the
critical path for this transition.

> > This could be coupled with a lintian warning, or other soft means of
> > encouraging maintainers to do the transition.

> Given the above, I think the best approach, assuming there's no further
> support of the MBF over the next week, is:
>  * start off with a lintian warning (lintian maintainers willing);
>  * in 3, 4, or 6 months time, proceed with a mass bug filing against
>the remaining packages.

> Steve, does this seem reasonable to you?

Now that I've read the numbers correctly, I don't mind an MBF here if that's
what you prefer.  But a lintian warning could probably also be a good
approach.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Switching to mozilla ESR in stable-security

[Paul Wise]

On Wed, May 29, 2013 at 4:33 AM, Moritz Muehlenhoff wrote:

> we need to change the way security fixes are handled for Mozilla
> in stable-security. The backporting of security fixes is no
> longer sustainable resource-wise.

Please propose an announcement about this to the Debian press team and
add a paragraph about it to DPN (all DDs have commit access).

https://wiki.debian.org/ProjectNews/HowToContribute

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6h0tuj08nhvomaa8sunr4axbganu2xfi_goscnvofh...@mail.gmail.com

Re: MBF: transition from texi2html to texinfo

[Ryan Kavanagh]

On Tue, May 28, 2013 at 05:08:06PM -0700, Steve Langasek wrote:
> There have been two responses to your proposal so far, neither of
> which particularly looks to be in favor of your plan.  I don't think
> it's reasonable to proceed with a mass-bug filing on over 800 packages
> as a first step, certainly not after such a short comment period.

Sorry, I was overly eager in pushing this change. Thanks Steve for being
the "tempering voice of reason".

As for the package count, where did you find the additional 700+
packages? If I'm missing something, please let me know. Of matches in
the search[0] Paul Wise linked to, many matches are from the same
package, or more prominently (as with e.g., festival, gcc, geiser,
id-utils, gcl, etc.), found in the upstream build system but never
called at build time (one can deduce this from the fact that they don't
build-depend on texi2html). As I stated in my initial email, there are
at most 96 packages which would require some form of change, and these
are the packages that either build-depend (94) or depend (2) on
texi2html.

I'll give it a week long comment period to see if people see any value
in the MBF. If there is public support of the idea, then I'll go ahead
with it, otherwise I will proceed as described at the end of this email.

> Why are you not proposing to provide a texi2html wrapper from the
> makeinfo package which translates the arguments as described on
> , and have makeinfo
> Provide: texi2html?

If by this, you mean remove the texi2html package from the archive after
introducing the texi2html wrapper for makeinfo, and hope people would
then transition after being warned by lintian, then it would fail to
address Sébastien's concerns.

If you mean something else, could please explain in greater detail what
you meant, and how it would allow me to remove the texi2html package
much more quickly from the archive than with my current plan?

> This could be coupled with a lintian warning, or other soft means of
> encouraging maintainers to do the transition.

Given the above, I think the best approach, assuming there's no further
support of the MBF over the next week, is:
 * start off with a lintian warning (lintian maintainers willing);
 * in 3, 4, or 6 months time, proceed with a mass bug filing against
   the remaining packages.

Steve, does this seem reasonable to you?

Respectfully yours,
Ryan

[0] http://codesearch.debian.net/search?q=texi2html&skip=877

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  http://ryanak.ca/   | GPG Key 4A11C97A


signature.asc
Description: Digital signature

Re: MBF: transition from texi2html to texinfo

[Norbert Preining]

On Di, 28 Mai 2013, Ryan Kavanagh wrote:
> Norbert, as Texinfo maintainer, do you know if upstream has an ITA for
> when the math-images-in-HTML will arrive in makeinfo?

No I don't know, but I have forwarded the question to bug-texinfo,
let us see what we get.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



-- 
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/20130529005505.gh7...@gamma.logic.tuwien.ac.at

Re: MBF: transition from texi2html to texinfo

[Steve Langasek]

On Tue, May 28, 2013 at 07:06:23PM -0400, Ryan Kavanagh wrote:
> As a final notice, unless I get any objections (there have been none so
> far), I plan to go forward with the MBF at 03:00UTC on 2013-05-29. As
> explained on the Texi2htmlTransition wiki page[0], if you are
> unwilling/unable to transition to texinfo due to missing math rendering,
> please mark your bug as blocking on http://bugs.debian.org/710171 .

There have been two responses to your proposal so far, neither of which
particularly looks to be in favor of your plan.  I don't think it's
reasonable to proceed with a mass-bug filing on over 800 packages as a first
step, certainly not after such a short comment period.

Why are you not proposing to provide a texi2html wrapper from the makeinfo
package which translates the arguments as described on
, and have makeinfo Provide:
texi2html?  That would surely allow you to remove the texi2html package from
the archive much more quickly than your current plan, and with less
unnecessary pressure on maintainers to transition.  This could be coupled
with a lintian warning, or other soft means of encouraging maintainers to do
the transition.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: default MTA

[Carlos Alberto Lopez Perez]

On 28/05/13 18:53, Don Armstrong wrote:
> On Tue, 28 May 2013, Arno Töll wrote:
>> Why not consider something light, better suited for most systems which
>> need nothing but a sendmail binary which is suited to relay to a
>> real(tm) mail-server and deliver local mail and does not involve lots
>> of configuration and/or listening ports?
> 
> nullmailer or similar can do this fairly well. You really only need to
> have 1) configured the remote smart host 2) a remote e-mail address to
> send all local mail to.
> 

We already (I believe) ship exim4-daemon-light as default MTA. I don't
know how much lighter are the alternatives like dma or nullmailer.

I tried both, and I ended going back to exim4-daemon-light because of
the problems I had with them (#686164 #697871 and #329192).

So I'm not sure if is worth the effort changing the default MTA.


Does anybody recommend any light MTA other than this ones?



signature.asc
Description: OpenPGP digital signature

Re: Switching to mozilla ESR in stable-security

[John Paul Adrian Glaubitz]

Hi Moritz!

On 05/28/2013 10:33 PM, Moritz Muehlenhoff wrote:

we need to change the way security fixes are handled for Mozilla
in stable-security. The backporting of security fixes is no
longer sustainable resource-wise.


I second this. Having one of the most commonly used desktop applications
lacking so much behind the current upstream versions in a newly
released Debian version is very frustrating and annoying.

Having the current ESR versions of Iceweael and Icedove in Debian
stable is the best practice as these releases were just intended
to be used in scenarios were Debian stable is deployed.


As such, we'll switch to releasing the ESR releases of iceweasel
and icedove in stable-security.


Great! Really looking forward.

Let me add to that there is currently no easy way (e.g. without
rebuilding the package) to install Icedove ESR on Wheezy. The
Debian Mozilla packaging team suggests installing Icedove
ESR from unstable [1], but alas this version is linked against
libc6 2.17 and will therefore force an update of the libc6
installed on Wheezy which is unacceptable [2].

I therefore urge anyone involved in packaging Icedove to provide
a version of Icedove ESR linked against the version of libc6
in Wheezy.

Also, if anyone of the GNOME package maintainers is reading this,
why does the gnome meta package depend on xul-ext-adblock-plus? This
often causes major headache when upgrading either Iceweasel or
Icedove in the form that using the wrong upgrade path will
result in partial or full removal of GNOME.


In the future the majority of packages should thus rather be installed
through http://addons.mozilla.org instead of Debian packages.


I think this is the best approach. Most addons should be installed
through the built-in addon manager as this will make keeping
addons up-to-date much easier and reduces maintaining efforts. As
long as we're going with the latest ESR versions, I assume that
most of the most popular addons will work when installed through
the official upstream sources.

Cheers,

Adrian

> [1] http://mozilla.debian.net/
> [2] http://paste.debian.net/7192/

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/51a53af2.3010...@physik.fu-berlin.de

Re: MBF: transition from texi2html to texinfo

[Ryan Kavanagh]

As a final notice, unless I get any objections (there have been none so
far), I plan to go forward with the MBF at 03:00UTC on 2013-05-29. As
explained on the Texi2htmlTransition wiki page[0], if you are
unwilling/unable to transition to texinfo due to missing math rendering,
please mark your bug as blocking on http://bugs.debian.org/710171 .

I've settled on severity `minor'. Earlier today, I thought of severity
`wishlist', but this is neither a feature request nor a bug that is "very
difficult to fix due to major design considerations", but rather "a problem
which doesn't affect the package's usefulness, and is presumably trivial to
fix"[1].

The final versions of the text are
--
Dear maintainer,

[ This is an automated bug report, submitted as part of the mass bug
  filing discussed at
  http://lists.debian.org/debian-devel/2013/05/msg01516.html ]

The package `texi2html` on which #PACKAGE# build-depends is
unmaintained upstream and destined to be removed from the archive in
the near future. Unless your package makes use of texi2html
functionality not yet provided by `makeinfo' utility from the
texinfo package, e.g. rendering @math blocks as images in HTML
output, please update your package to use `makeinfo' instead. More
details may be found at http://wiki.debian.org/Texi2htmlTransition .

Thanks for considering,
Best wishes.
--
for reverse-build-dependencies, and
--
Dear maintainer,

[ This is an automated bug report, submitted as part of the mass bug
  filing discussed at
  http://lists.debian.org/debian-devel/2013/05/msg01516.html ]

The package `texi2html` on which #PACKAGE# depends is
unmaintained upstream and destined to be removed from the archive in
the near future. Unless your package makes use of texi2html
functionality not yet provided by `makeinfo' utility from the
texinfo package, e.g. rendering @math blocks as images in HTML
output, please update your package to use `makeinfo' instead. More
details may be found at http://wiki.debian.org/Texi2htmlTransition .

Thanks for considering,
Best wishes.
--
for reverse-dependencies.

Best wishes,
Ryan

[0] http://wiki.debian.org/Texi2htmlTransition
[1] http://www.debian.org/Bugs/Developer#severities

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  http://ryanak.ca/   | GPG Key 4A11C97A


signature.asc
Description: Digital signature

Switching to mozilla ESR in stable-security

[Moritz Muehlenhoff]

Hi,
we need to change the way security fixes are handled for Mozilla
in stable-security. The backporting of security fixes is no
longer sustainable resource-wise.

As such, we'll switch to releasing the ESR releases of iceweasel
and icedove in stable-security. 
Reverse-deps of the older xulrunner libs have negligable security
impact and we won't update them any further.

One problematic aspect are the various xul-ext-* packages currently
packaged. It's very likely that some of them will break with ESR17
and ESR24 in the future. 

However, there's not much we can do here. We can select a narrow (!)
set of important addons (e.g. enigmail for Icedove) that we will
keep in sync through stable-security, but that doesn't scale for
the full scale of Mozilla extensions currently packaged. 

In the future the majority of packages should thus rather be installed
through http://addons.mozilla.org instead of Debian packages.

If you maintain an extension, you can test the compatibility with
the packages already available at http://people.debian.org/~jmm/

Cheers,
Moritz







-- 
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/20130528203303.GA5425@pisco.westfalen.local

Re: default MTA

[Jonathan Dowland]

Hi Simon,

On Tue, May 28, 2013 at 01:05:24PM +0100, Simon McVittie wrote:
> The participants in this thread are debian-devel subscribers: the sort
> of people who know that Debian is a Unix system, know what a Unix system
> is, and have some idea of what a "btrfs scrub cron job", or indeed an
> MTA, means. That's a pretty limiting audience for an operating system.
> The Universal Operating System should also be usable by people who don't
> meet those criteria, and I think Joss is right to speak up on their behalf.

I think the problem is that Aunt Tilly will stumble across packages which
expect a working sendmail whether or not they are ready for them: they'll read
advice suggesting they should have smartd/smartmontools running; or they'll
install some other semi-random Debian package after performing a search for a
tool to solve a specific task, which supposes that mail works. We were all
Aunt Tillys, once, and I certainly had this experience (although in my day
everyone faced the exim3 configuration stuff on a fresh install. Not that I'm
advocating that for a minute.)

Such novices may well have no idea what cron or at are, but once they begin
reading around to try and solve problems like scheduling things, they'll
soon stumble across them.

To address this problem, I think we have to either adjust all packages which
expect a working sendmail to use some other universal local messaging system or
better configure the system (including the desktop) to handle local mail, as
Adam suggests. I don't think the former solution is viable, not least because
there is no alternative, universal local messaging system to switch to.


-- 
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/20130528202633.GA30037@debian

Re: default MTA

[Adam Borowski]

On Tue, May 28, 2013 at 05:58:15PM +0200, Thibaut Paumard wrote:
> I was going to say that by default, this mail was sent to root, but
> checked before I typed and... what? I do have unread local mail!? Just
> to say: at the moment, there's no obvious notification about local mail.
> 
> In addition, it is not straightforward to read local mail, especially
> if you are used to reading you mail only via some webmail interface
> (which is more and more common).
> 
> We could imagine running a simple biff applet by default in every
> desktop interface, and clicking it could trigger a simple mail reader,
> configured for local mail.

Why would we multiply entities without necessity?  Desktop environments
install mail clients by default, they just should come configured to have
local mail among the accounts.

Most graphical clients can do this:

http://askubuntu.com/questions/192572/how-read-local-email-in-thunderbird
http://askubuntu.com/questions/21695/how-can-i-set-up-evolution-to-access-a-local-mail-box

so that's enough for a biff and a reader.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130528195150.gb27...@angband.pl

Re: default MTA

[Tzafrir Cohen]

On Tue, May 28, 2013 at 07:10:51PM +0200, Matthias Klumpp wrote:
> 2013/5/28 Игорь Пашев :
> > 2013/5/28 Josselin Mouette :
> >> Nobody,
> >> I repeat, nobody, ever reads local mail on most desktop systems
> >[...]
> Would it help if we had a desktop-component, which is able to:
>  1) Show a notification *on the desktop* if the user received new mail
>  2) Offer a GUI way to read system mails
>  3) Offer a way to delete these mails
> The advantage would be that these mails would be read more often,
> while on a system configured for desktop-use, no such mails would be
> send, so the users wouldn't be bothered with it.
> Cheers,
> Matthias

Forwarding root's mail to all users in the group users. Then using the
standard mail clients (kmail, evolution or even mutt).

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend


-- 
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/20130528191203.gx14...@lemon.cohens.org.il

Re: default MTA

[Bjørn Mork]

Russ Allbery  writes:
> Bjørn Mork  writes:
>
>> The local MTA serves as a common configuration for the external SMTP
>> server, with a well known interface supported by every single package
>> which wants to send mail.
>
> And which requires storing passwords or other authentication credentials
> on disk if your external SMTP server requires authentication (increasingly
> common), which is bad security practice (not to mention awkward for a lot
> of people to configure).  Whereas using an external MTA directly in the
> mail client means the mail client has the ability to prompt you
> interactively for authentication credentials or use the system keyring to
> store them, which is somewhat more secure.

Yes, this is a problem common to any system wide authenticated service,
like for example a bluetooth keyboard or a PPP network connection.  I
still don't think it makes any sense delegating the configuration to
packages needing those services.  The keyboard and the network
connection are system services, even if they need credentials stored in
the file system.

IMHO, the same goes for SMTP.  There may not be as many packages needing
it as those needing a keyboard. But I'm guessing that there still are a
handful SMTP clients installed on an average single user desktop system.
And it does not make sense to have each and every one of those packages
configure external SMTP access independently.


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/87vc637y6s@nemi.mork.no

Re: optimizing PNGs

[Don Armstrong]

On Tue, 28 May 2013, Bastien ROUCARIES wrote:
> optimizing the svg file by removing all space and comments ?

svgz (or similar) will handle this far better, and retain source.
[Though it's not clear to me if everything supports on-the-fly
decompression of SVG images.]
 

-- 
Don Armstrong  http://www.donarmstrong.com

[A] theory is falsifiable [(and therefore scientific) only] if the
class of its potential falsifiers is not empty.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ §21


-- 
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/20130528175158.gn3...@teltox.donarmstrong.com

Re: default MTA

[Andreas Metzler]

Marco d'Itri  wrote:
> Now that we are done with systemd for the time being, can we have the 
> flame war about replacing Exim with Postfix as the default MTA?
[...]

I do not think we need another flame-war. Thank you very much.
cu Andreas
-- 
The more contact I have with humans, the more I learn.
T-101


-- 
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/vq6f7a-ge4@argenau.downhill.at.eu.org

Re: default MTA

[Russ Allbery]

Bjørn Mork  writes:

> The local MTA serves as a common configuration for the external SMTP
> server, with a well known interface supported by every single package
> which wants to send mail.

And which requires storing passwords or other authentication credentials
on disk if your external SMTP server requires authentication (increasingly
common), which is bad security practice (not to mention awkward for a lot
of people to configure).  Whereas using an external MTA directly in the
mail client means the mail client has the ability to prompt you
interactively for authentication credentials or use the system keyring to
store them, which is somewhat more secure.

-- 
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/8761y3uhnr@windlord.stanford.edu

Bug#710166: ITP: ruby-haml-contrib -- Elegant, structured XHTML/XML templating engine - addons

[Jérémy Bobbio]

Package: wnpp
Severity: wishlist
Owner: Jérémy Bobbio 

* Package name: ruby-haml-contrib
  Version : 1.0.0.1
  Upstream Author : Norman Clarke 
* URL : https://github.com/haml/haml-contrib
* License : Expat
  Programming Lang: Ruby
  Description : Elegant, structured XHTML/XML templating engine - addons

Haml (HTML Abstraction Markup Language) is a layer on top of XHTML or
XML that's designed to express the structure of XHTML or XML documents
in a non-repetitive, elegant, easy way, using indentation rather than
closing tags and allowing Ruby to be embedded with ease.

This package provides several extra filters: builder, markaby, maruku,
nokogiri, php, textile, wiki, yajl.

-- 
Jérémy Bobbio.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Re: optimizing PNGs

[Bastien ROUCARIES]

On Mon, May 27, 2013 at 8:32 PM, Russ Allbery  wrote:
> Helmut Grohne  writes:
>
>> I'd like to add some bits from the doxygen point of view. Documentation
>> packages created using doxygen currently have a number of issues with
>> respect to size. Some of them are to be addressed soon(TM).
>
>>  * Packages shipping .md5 and .map files. Even though these files are
>>small, there can be very many of them adding up to the installation
>>size for filesystems with large block sizes. These files are used for
>>incremental recreation of the documentation, so they are completely
>>useless in a binary package. A future version of the doxygen package
>>will include a dh_doxygen to aid in getting rid of these files.
>
> Yes, yes, please!  That would make my life so much better for several of
> my packages.
>
>>  * The embedding of jquery and files from doxygen is another story with
>>wider implications, but this is rather a small constant per package,
>>so the reduction in size is negligible.
>
> I've been replacing the copy of jquery with a symlink to the one shipped
> in Debian and adding a dependency on that package, and some quick testing
> didn't turn up anything that broke.  If that strategy works, maybe
> dh_doxygen can do that as well?

optimizing the svg file by removing all space and comments ?

from http://petercollingridge.appspot.com/svg-editor/ we could gain
about 20%-50% per svg file
or this
https://github.com/svg/svgo
> --
> 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/87txlo2rzi@windlord.stanford.edu
>


-- 
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/CAE2SPAZJeErCsvKRfpOtGkLQWWm0DOBZiM-6PTtKsECn_Vf=x...@mail.gmail.com

Re: default MTA

[Bjørn Mork]

Josselin Mouette  writes:
> Le mardi 28 mai 2013 à 13:07 +0200, Bjørn Mork a écrit : 
>> The local MTA serves as a common configuration for the external SMTP
>> server, with a well known interface supported by every single package
>> which wants to send mail.
>
> Which packages are entitled to send mail to the outside without
> configuration from the sysadmin, exactly?

All packages are installed and configured by the sysadmin.  So that
would be none.

But there should be exactly one package asking the sysadmin about smtp
smarthost settings.  The other mail sending packages should just depend
on that package and reuse the settings already configured.

> We are talking about a default configuration, and the only useful thing
> in a default configuration is local mail. 

I disagree. The only useful default configuration is a default-mta
package asking how to deliver both local and remote mail, and holding
the sysadmin's hand while setting up delivery to a smarthost.  Possibly
mapping local accounts to a single remote address.

> Local mail not being read by anyone on most machines.

This we can agree on :)

>> I don't see the point discussing this at all until there is an
>> alternative interface with a similar level of support.  Otherwise you
>> are just going to repeat the MIME support mess again.
>
> Just like for the MIME support mess, the damage is already done. Nobody,
> I repeat, nobody, ever reads local mail on most desktop systems, and
> even many server systems. For desktops, we need to rely on direct user
> notification. For servers, careful people rely on real-time monitoring. 
>
> Local mail is a quick solution for persistent notification of the system
> administrator, but it doesn’t scale at all when you have more than 3
> machines under your control.
>
> I don’t think the situation is that bad. We could probably work on
> alternative notification systems for cron jobs, but for the other
> important use cases of local mail, we already have what we need.

Sure.  Yes, I agree that local mail isn't necessarily the answer to any
notification requirement.  But I don't think that means that it never is
the answer.   There are situations where local mail notification is
fine.


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/8738t79h4i@nemi.mork.no

Re: default MTA

[Matthias Klumpp]

2013/5/28 Игорь Пашев :
> 2013/5/28 Josselin Mouette :
>> Nobody,
>> I repeat, nobody, ever reads local mail on most desktop systems
>[...]
Would it help if we had a desktop-component, which is able to:
 1) Show a notification *on the desktop* if the user received new mail
 2) Offer a GUI way to read system mails
 3) Offer a way to delete these mails
The advantage would be that these mails would be read more often,
while on a system configured for desktop-use, no such mails would be
send, so the users wouldn't be bothered with it.
Cheers,
Matthias


--
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/caknhny_foz+pjrkceq8duz_6jgsjiwsnl-2gzfbuf1fny0o...@mail.gmail.com

Re: optimizing PNGs

[Jonathan Dowland]

On 28 May 2013, at 14:04, Paul Tagliamonte  wrote:

> Some plugins for photoshop etc store data in the fields that get removed
> by pngcrush and friends. In a sense, doing this is removing source data.

This is a bug that should be fixed in the optimiser(s). However, it could 
easily be worked around by a service such as the one I outlined.

> I've been debating writing dh_pngcrush / dh_jpegoptim. I think it's a
> good idea. Just don't expect graphic designers to want the result.

For the reasons already outlined, I for one wouldn't use it and would object to 
it being part of default debhelper or dh rules.

--
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/888155df-e06e-47f7-809c-fe51508a7...@debian.org

Re: default MTA

[Don Armstrong]

On Tue, 28 May 2013, Arno Töll wrote:
> Why not consider something light, better suited for most systems which
> need nothing but a sendmail binary which is suited to relay to a
> real(tm) mail-server and deliver local mail and does not involve lots
> of configuration and/or listening ports?

nullmailer or similar can do this fairly well. You really only need to
have 1) configured the remote smart host 2) a remote e-mail address to
send all local mail to.

[More complicated configurations of 2 should be supported so that you
can have simple mappings, but that's not really required.]

-- 
Don Armstrong  http://www.donarmstrong.com

"You have many years to live--do things you will be proud to remember
when you are old."
 -- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413)


-- 
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/20130528165342.gm3...@teltox.donarmstrong.com

Re: default MTA

[Thomas Goirand]

On 05/28/2013 10:24 PM, Josselin Mouette wrote:
> Just like for the MIME support mess, the damage is already done. Nobody,
> I repeat, nobody, ever reads local mail on most desktop systems, and
> even many server systems.

The question you have to ask yourself is: why?

The answer is simple: because we don't provide an easy way to have it
configured correctly by default. That is the problem to solve, and
nothing else, IMHO.

Thomas


-- 
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/51a4dad9.9040...@debian.org

Re: default MTA

[Sune Vuorela]

On 2013-05-28, Thomas Goirand  wrote:
> I agree. Which is why postfix can be configured for that:

I think most full-blown mta's can do that. But the much smaller ones can
also.

/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/slrnkq9mgq.j8.nos...@sshway.ssh.pusling.com

Re: default MTA

[Thomas Goirand]

On 05/28/2013 06:39 PM, Mike Hommey wrote:
> Running your own MTA without a smart host is a
> PITA these days. So you're better off using an external SMTP server
> directly.

I agree. Which is why postfix can be configured for that:

# cat /etc/postfix/main.cf
[ ... ]
relayhost = mx.example.com
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/saslpw
smtp_sasl_security_options =
[ ... ]

# cat /etc/postfix/saslpw
mx.example.com tho...@example.com:MySuPeRpAsS

Isn't this what the smarthost option of postfix does (I do this by
hand)? If we don't have it, it'd be easy to implement anyway.

Thomas


-- 
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/51a4d9ba.5000...@debian.org

Re: default MTA

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Le 28/05/2013 17:21, Adam Borowski a écrit :
>> 
>> We are talking about a default configuration, and the only useful
>> thing in a default configuration is local mail. Local mail not
>> being read by anyone on most machines.
> 
> If you don't read it, you get a reminder every login.
> 

I was going to say that by default, this mail was sent to root, but
checked before I typed and... what? I do have unread local mail!? Just
to say: at the moment, there's no obvious notification about local mail.

In addition, it is not straightforward to read local mail, especially
if you are used to reading you mail only via some webmail interface
(which is more and more common).

We could imagine running a simple biff applet by default in every
desktop interface, and clicking it could trigger a simple mail reader,
configured for local mail.

Kind regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRpNQXAAoJEJOUU0jg3ChAe6kP/iodkPyi+j9tVDoO6fFX5feJ
gnIrlETxGdx1sQUWweZAW75dt0R0LO01PENmna0MeF0p9X1/gOwQbLoE/SVq7mbQ
uK7XepHC555ssRyA2ipyRZpWnwF0/VJeMF8tIcDNNTGN2HRbufzrkjY3MslQzwJ6
DsOcuEqno79C7/AyBorR9HScz+vMgdf19K1gYmppbHdFKt0nAVZ1Otd2PGTCRN5m
+HAJJUZ5ykoaodg66EYLoVRETcW/vOxeMRH0JHBnQ0Yk0Jp/J5UeAfMAyE2rRdFn
Ds0/0EVoN3MvD7QyQbY/fyBqOn5UyXEeaL8+PHStYGerqoSStgfVOkD/zsK0iviM
rydKK2hvblthD2Flw/lvIga3/KZ8WVrW6KdGKxjXeX1wfUQK1b0hGCwj+geB8Tpe
5u7edBJ0gIz9iZe1pVUu2ZlAoDsoXXh2ZyzTxNjksGfdyYtKR2jKP5TnVNkthXpL
TnjB2QhgaqtCyckhNVi62hO0MxtShZxV/Hl6WzbumKLr5A6wqJ2xd2V2Nhj99liv
1HR0DJBJBSB9ars6kKho++NPHxrSVjzTwlcHnuNZoj+2+jUVj0xvGoBCWYA/uVNB
yyBvYlWayHoFhbm/ZJouUVY1IFmLcX9dtflk0iEFou6QXBY3kt4o8CD7W1gwt5Zf
sL88m1H/2pqoLS/6PLVF
=3urK
-END PGP SIGNATURE-


-- 
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/51a4d417.4020...@debian.org

Re: default MTA

[Игорь Пашев]

2013/5/28 Josselin Mouette :
> Nobody,
> I repeat, nobody, ever reads local mail on most desktop systems


I read mail from my desktop :-)
It is forwarded to my gmail account


-- 
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/CALL-Q8xL8vibh9w7eaUVf9kfGxhzzLqjiBiM9Xo=_w-jxea...@mail.gmail.com

Re: default MTA

[Thomas Goirand]

On 05/28/2013 07:05 PM, Josselin Mouette wrote:
> And on desktop systems, nobody reads local email. We might want to think
> of a better notification system, but email is definitely not fit for
> that anymore.

I do read the mails that my system is sending me (smartd, cron, mdadm,
etc.), and I like the feature to receive such notifications in my inbox.
If you want to reinvent the wheel, and have notification for example in
a gnome popping bubble thing, feel free. But please do it as an option,
and do not impose such choice to everyone.

I'm fine with whatever default you choose, if at least I can keep things
running as I'm used to though, and if there's an *easy* way (eg: not
hidden in a dpkg-reconfigure or an obscure config file) to select the
old behavior (for example, with an easily reachable option in d-i).

On 05/28/2013 08:05 PM, Simon McVittie wrote:
> The participants in this thread are debian-devel subscribers: the sort
> of people who know that Debian is a Unix system, know what a Unix
> system is, and have some idea of what a "btrfs scrub cron job", or
> indeed an MTA, means. That's a pretty limiting audience for an
> operating system. The Universal Operating System should also be
> usable by people who don't meet those criteria, and I think Joss is
> right to speak up on their behalf.

If we want to be universal, that means we satisfy all cases, and we do
not limit ourselves to the choices of the majority only.

On 05/28/2013 08:05 PM, Simon McVittie wrote:
> I'm quite prepared to believe that *our* Unix systems - and in
> particular, servers and development machines - need an MTA, but my
> parents' laptops really shouldn't need one.

Are you saying that they don't know what a mail server is, but they
installed Debian on their own, and made the choice of Debian as well on
their own? I'm having a hard time believing this, which is why I'm asking.

A few remarks here:

1/ Your parents don't read mail? That is surprising to me. In this days
and age, everyone does.

2/ Can't you configure their system to send *you* the system
notifications so that you can fix a problem? That is a very nice feature
to have.

3/ If you want them to receive the system notification, it's nice as
well to get it by email, because this way, they can forward you anything
that they don't understand.

The point is: did you at least configure the root alias, so that it gets
forwarded to a mailbox which someone actually reads?

On 05/28/2013 08:05 PM, Simon McVittie wrote:
> Ideally, we can have a sensible default that is suitable for both
> experts and non-experts; but if we can't, then the non-experts should
> probably have priority.

I'm not sure I agree with the above. I'm fine with Debian being the OS
for the experts.

On 05/28/2013 08:05 PM, Simon McVittie wrote:
> but my parents don't even know that they *have* an MTA.

They don't have to know. If at least they receive the system
notifications in their inbox, or if you do, then everything is fine.

Thomas


-- 
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/51a4d070.60...@debian.org

Re: default MTA

[Nick Andrik]

2013/5/28 Adam Borowski :
> If you don't read it, you get a reminder every login.

If you login in command line, which is not the default case for desktop systems.

--
=Do-
N.AND


-- 
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/cann5kovt9jx1oz0nvednqam2obgy8fbofkkq43v8faq3r-_...@mail.gmail.com

Re: default MTA

[Adam Borowski]

On Tue, May 28, 2013 at 04:24:27PM +0200, Josselin Mouette wrote:
> Le mardi 28 mai 2013 à 13:07 +0200, Bjørn Mork a écrit : 
> > The local MTA serves as a common configuration for the external SMTP
> > server, with a well known interface supported by every single package
> > which wants to send mail.
> 
> Which packages are entitled to send mail to the outside without
> configuration from the sysadmin, exactly?
> 
> We are talking about a default configuration, and the only useful thing
> in a default configuration is local mail. Local mail not being read by
> anyone on most machines.

If you don't read it, you get a reminder every login.

If some environment fails to pass it in its default config, that's the
environment's rather than user's fault.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130528152109.ga30...@angband.pl

Re: MBF: transition from texi2html to texinfo

[Ryan Kavanagh]

On Mon, May 27, 2013 at 08:28:37PM -0400, Ryan Kavanagh wrote:
> See attached for a dd-list of affected packages.

On Tue, May 28, 2013 at 04:37:44PM +0200, Emilio Pozuelo Monfort wrote:
> Please attach a list of packages run through dd-list before doing the MBF.

Sorry, I guess I forgot to actually attach the list. Let's try that
again :)

Best wishes,
Ryan

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  http://ryanak.ca/   | GPG Key 4A11C97A
Adam Conrad 
   glibc-doc-reference (U)

Andreas Barth 
   mgetty

Andreas Metzler 
   autogen

Andreas Tille 
   blitz++ (U)

Andres Mejia 
   libav (U)

Arjan Oosting 
   drift

Arthur Loiret 
   tcc (U)

Aurelien Jarno 
   glibc-doc-reference (U)
   qemu (U)

Axel Beckert 
   zsh (U)

Barak A. Pearlmutter 
   bbdb (U)
   ilisp
   mailcrypt (U)

Barry deFreese 
   xnee (U)

Ben Pfaff 
   pspp (U)

Ben Pfaff 
   autoconf2.13

Bob Proulx 
   time

bojo42 
   pspp

Bradley Smith 
   autogen

Christophe Trophime 
   blitz++ (U)

Clint Adams 
   zsh (U)
   zsh-beta

Clint Adams 
   glibc-doc-reference (U)

Colin Watson 
   grub (U)

D Haley 
   mathgl (U)

Daniel Jacobowitz 
   glibc-doc-reference (U)

Davide G. M. Salvetti 
   auctex
   mailcrypt

Debian Accessibility Team 
   flite

Debian Common Lisp Team 
   cl-plplot

Debian GNUstep maintainers 
   gnustep-base
   gnustep-dl2 (U)
   gnustep-gui
   gnustep-make
   gorm.app (U)

Debian Lustre Packaging Team 
   ldiskfsprogs

Debian Multimedia Maintainers 

   libav
   rumor

Debian Multimedia Team 
   ocp (U)

Debian OCaml Maintainers 
   apron

Debian Octave Group 
   dynare
   octave

Debian QA Group 
   bc
   emacspeak

Debian QEMU Team 
   qemu

Debian Science Maintainers 
   maria
   mathgl
   rheolef
   yorick

Debian Science Team 
   blitz++
   geomview

Debian Zsh Maintainers 
   zsh

Dimitrios Eftaxiopoulos 
   mathgl (U)

Dirk Eddelbuettel 
   ess (U)
   r-base
   rpy

Don Armstrong 
   lilypond

Erich Schubert 
   enigma

ESS Debian Maintainers 
   ess

Fabian Greffrath 
   libav (U)

Federico Gimenez Nieto 
   gnustep-dl2

Felipe Augusto van de Wiel (faw) 
   translate-docformat

Felix Zielcke 
   grub (U)
   multiboot (U)

Francesco Paolo Lovergine 
   zlibc

Francois-Denis Gonthier 
   boa

Frank Terbeck 
   zsh (U)

Ganesan Rajagopal 
   jlint

GNU Hurd Maintainers 
   hurd

GNU Libc Maintainers 
   glibc-doc-reference

GOTO Masanori 
   glibc-doc-reference (U)

GRUB Maintainers 
   grub
   multiboot

Guus Sliepen 
   tinc

Gürkan Sengün 
   gnustep-base (U)
   gnustep-gui (U)
   gnustep-make (U)
   gorm.app
   ocp

Hendrik Tews 
   proofgeneral

Jari Aalto 
   genparse

Jeff Bailey 
   glibc-doc-reference (U)
   hurd (U)

Joerg Jaspert 
   bbdb
   elib

John Sullivan 
   planner-el

Jonas Smedegaard 
   libav (U)

Jordi Mallach 
   multiboot (U)

Kurt Roeckx 
   libtool

Loïc Minier 
   libav (U)

Ludovic Brenta 
   asis
   polyorb (U)

Lukas Loehrer 
   flite (U)

Manoj Srivastava 
   make-doc-non-dfsg
   vm

Mario Lang 
   erc (U)
   flite (U)

Martin A. Godisch 
   gnugo

Mathieu Trudel-Lapierre 
   acct

Matteo Cypriani 
   fdutils

Matthias Klose 
   bash

Matthias Urlichs 
   mgetty (U)

Michael Banck 
   hurd (U)

Michael Biebl 
   avrdude

Michael Prokop 
   zsh (U)

Michael Tokarev 
   qemu (U)

Michael W. Olson (GNU address) 
   erc
   remember-el (U)

Neal H. Walfield 
   hurd (U)

Neil Roeth 
   psgml

Noèl Köthe 
   ldiskfsprogs (U)

OHURA Makoto 
   auctex (U)
   xemacs21
   xemacs21-packages

Oleksandr Moskalenko 
   bashdb

Patrick Winnertz 
   ldiskfsprogs (U)

Peter Eisentraut 
   source-highlight

Peter S Galbraith 
   libforms

Peter Samuelson 
   gpm

Philipp Benner 
   cl-plplot (U)

Pierre Saramito 
   rheolef (U)

Python Applications Packaging Team 
   turnin-ng (U)

QA Group 
   units

Ralf Treinen 
   maria (U)
   yap

Reinhard Tartler 
   libav (U)

Richard Hartmann 
   zsh (U)

Riku Voipio 
   qemu (U)

Robert Millan 
   grub (U)
   multiboot (U)

rosea grammostola 
   rumor (U)

Ryan Kavanagh 
   bc

Ryan Kavanagh 
   rumor (U)
   turnin-ng

Sam Hocevar (Debian packages) 
   libav (U)

Samuel Mimram 
   apron (U)

Samuel Thibault 
   flite (U)
   hurd (U)

Sandra Jean Chua (Sacha) 
   remember-el

Santiago Vila 
   diffutils
   indent
   m4
   recode
   sharutils
   wdiff

Steve M. Robbins 
   geomview (U)

Stéphane Glondu 
   apron (U)

Sébastien Villemot 
   dynare (U)
   octave (U)

Takaya Yamashita 
   twittering-mode

Theodore Y. Ts'o 
   e2fsprogs

Thibaut Paumard 
   yorick (U)

Thierry Randrianiriana 
   php-elisp

Thomas Bushnell, BSG 
   jacal
   scm
   slib

Thomas Preud'homme 
   tcc

Thomas Preud'homme 
   tcc

Thomas Weber 
   dynare (U)
   octave (U)

Thorsten Glaser 
   cvs

Tim Cutts 
   am-utils

Tommi Vainikainen 
   flex-old

Vagrant Cascadian 
   qemu (U)

Vincent Bernat 
   xnee

Xavier Grave 
   asis (U)
   polyorb

Yann Dirson 
   cssc
   gcompris

Yavor Doganov 
   gnustep-base (U)
   gnustep-gui (U)
   gnustep-make (U)



signa

Re: MBF: transition from texi2html to texinfo

[Emilio Pozuelo Monfort]

On 28/05/13 16:01, Ryan Kavanagh wrote:

On the basis of Sébastien's objection, I propose the MBF to have
severity wishlist and the following amended text. Not everybody will be
able to transition from texi2html, but those who can should. It will be
easier to transition the remaining few packages that use math
functionality when makeinfo gains those features than to additionally
have to transition all those that could have transitioned now.


Please attach a list of packages run through dd-list before doing the MBF.

Thanks,
Emilio


--
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/51a4c138.4000...@debian.org

Re: default MTA

[Josselin Mouette]

Le mardi 28 mai 2013 à 13:07 +0200, Bjørn Mork a écrit : 
> The local MTA serves as a common configuration for the external SMTP
> server, with a well known interface supported by every single package
> which wants to send mail.

Which packages are entitled to send mail to the outside without
configuration from the sysadmin, exactly?

We are talking about a default configuration, and the only useful thing
in a default configuration is local mail. Local mail not being read by
anyone on most machines.

> I don't see the point discussing this at all until there is an
> alternative interface with a similar level of support.  Otherwise you
> are just going to repeat the MIME support mess again.

Just like for the MIME support mess, the damage is already done. Nobody,
I repeat, nobody, ever reads local mail on most desktop systems, and
even many server systems. For desktops, we need to rely on direct user
notification. For servers, careful people rely on real-time monitoring. 

Local mail is a quick solution for persistent notification of the system
administrator, but it doesn’t scale at all when you have more than 3
machines under your control.

I don’t think the situation is that bad. We could probably work on
alternative notification systems for cron jobs, but for the other
important use cases of local mail, we already have what we need.

Cheers,
-- 
 .''`.  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/1369751067.12592.667.camel@pi0307572

Re: MBF: transition from texi2html to texinfo

[Ryan Kavanagh]

On Tue, May 28, 2013 at 08:45:04AM +0200, Sébastien Villemot wrote:
> AFAIK, makeinfo is not able to render @math blocks as images (formatted
> with LaTeX), while texi2html does. The output of math formulas with
> makeinfo --html is very ugly, since it basically dumps the Texi/LaTeX
> source of the formula in the HTML.

I didn't know that, but that seems to be right according to §14.6 of the
Texinfo manual[0]. The other differences between texi2html and makeinfo
are documented in §22.8 of the Texinfo manual[1].

> I would therefore prefer to keep texi2html around (until makeinfo
> grows the missing feature). I use the ability to have nice math
> formulas in HTML in one of my scientific packages.

That sounds very fair. I can update the texi2html package to the 5.0
upstream release (Closes: #615812) and just disable the test checking
which was causing FTBFS---even the pristine upstream tarball fails its
tests!

Norbert, as Texinfo maintainer, do you know if upstream has an ITA for
when the math-images-in-HTML will arrive in makeinfo?

Again, to quote from the texi2html front page[2],
the route forward for authors is, in most cases, to alter manuals
and build processes as necessary to use the new features of the
makeinfo/texi2any implementation of GNU Texinfo. The Texi2HTML
maintainers (one of whom is the principal author of the GNU Texinfo
implementation) do not intend to make further releases of Texi2HTML.

On the basis of Sébastien's objection, I propose the MBF to have
severity wishlist and the following amended text. Not everybody will be
able to transition from texi2html, but those who can should. It will be
easier to transition the remaining few packages that use math
functionality when makeinfo gains those features than to additionally
have to transition all those that could have transitioned now.

-- BEGIN AMENDED MBF TEXT --
Dear maintainer,

[ This is an automated bug report, submitted as part of the mass bug
  filing discussed at TODO-ADD-URL-TO-DEVEL-THREAD-HERE ]

The texi2html package on which your package depends or build-depends is
unmaintained upstream and destined to be removed from the archive in the
near future. Unless your package makes use of texi2html functionality
not yet provided by `makeinfo' utility from the texinfo package, e.g.
rendering @math blocks as images in HTML output, please update your
package to use `makeinfo' instead. More details may be found at
http://wiki.debian.org/Texi2htmlTransition .

Thanks for considering,
Best wishes.
-- END AMENDED MBF TEXT --

[0] 
http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Inserting-Math
[1] http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#texi2html
[2] http://www.nongnu.org/texi2html/

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  http://ryanak.ca/   | GPG Key 4A11C97A


signature.asc
Description: Digital signature

OpenRC, Upstart, systemd wishlist stuff

[Daniel Pocock]

There seem to be a few new discussions about these possible solutions

As well as the traditional init scripts, I've worked with systemd on
Fedora and SMF on Solaris.  Out of all possible solutions, I don't have
any strong feelings about which solution Debian should go with at this
stage.

However, one thing that comes to mind is the ease of integration with
management tools - as far as I know, Nagios users currently have to
a) manually declare service relationships (duplicating the LSB data from
their init scripts)
b) manually write action scripts that invoke init scripts or whatever
else is in use to try and restart a failed service.

In a more ideal environment (this is obviously a wishlist item, but an
important one), Nagios, NRPE or any similar tool would dynamically
discover the service inter-dependencies, mechanisms for checking state
and the corrective actions to use.  The admin could then do little more
than setting some switch in Nagios that says `manage all my services
automatically'

To enable such convenient deployment, it is probably necessary for one
or more of these init solutions to expose sufficient data for automated
scanning.

Another nice wishlist item would be to have a single init/scheduler
paradigm that can work standalone or in a distributed manner, for load
balancing, HA and to ensure that services are only brought up when
services on other hosts are available.  E.g. don't start Tomcat on host1
unless MySQL on host2 is up, or only run a particular cron job when the
necessary DB is up, or try to bring up the DB when the cron job wants to
run.

If jessie includes features like these then it would easily leapfrog the
advances that other distributions have made recently in progressing past
SysV init.


-- 
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/51a4a860.5040...@pocock.com.au

Re: optimizing PNGs

[Paul Tagliamonte]

On Tue, May 28, 2013 at 02:01:06PM +0100, Jonathan Dowland wrote:
> From my brief experience of working on games-thumbnails, I can appreciate that
> the space savings may well be worth it at scale, but performing
> compression/optimisation at package build stage is a major PITA. For
> lossless-compression, there's no reason for the compressed PNGs to not be
> integrated upstream (esp. in the case of local packages like 
> games-thumbnails).

Some plugins for photoshop etc store data in the fields that get removed
by pngcrush and friends. In a sense, doing this is removing source data.

While treating .png files as prefered forms of modification is insane,
there are cases where crushing this will render them even worse.

I've been debating writing dh_pngcrush / dh_jpegoptim. I think it's a
good idea. Just don't expect graphic designers to want the result.

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: optimizing PNGs

[Jonathan Dowland]

Hi Adam,

On Sun, May 26, 2013 at 05:56:06PM +0200, Adam Borowski wrote:
> A while ago, someone raised the possibility of recompressing PNG files. 

From my brief experience of working on games-thumbnails, I can appreciate that
the space savings may well be worth it at scale, but performing
compression/optimisation at package build stage is a major PITA. For
lossless-compression, there's no reason for the compressed PNGs to not be
integrated upstream (esp. in the case of local packages like games-thumbnails).

> This massive number of files seems to be concentrated mostly in a limited
> number of packages:

What isn't clear here is whether these packages full of PNGs are already
efficiently compressed or not.

> So here are the results:

How did you decide on which packages to sample from the above list?

> fonts-mathjax-extra  4  94.6%  90.0%

This (at least) didn't appear in the above list.
 
I think an ideal solution would be a central/separate PNG recompression service
that could alert maintainers if their PNGs were not optimal (bug perhaps? "Dear
maintainer, foo.png in your package could be more optimal! Perhaps replace it
with pngcrush.debian.net/v1/srcpackage/path/foo.png"?) rather than
maintainers/buildds paying the compression cost. If compressed PNGs could be
annotated with some metadata indicating that they were recompressed (or checked
for recompression), then that might help to avoid costly recompression
attempts. (foo.png is marked up that pngcrush.debian.net compressed it with
version 1 of it's preferred compression solution; bar.png with version 2¸
current is version 3, recompress both… or perhaps pngcrush.debian.net could
maintain checksums for files it has already checked.)


--
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/20130528130106.GB20013@debian

Re: default MTA

[Redalert Commander]

2013/5/28 Simon McVittie :
[...]
>
> The participants in this thread are debian-devel subscribers: the sort
> of people who know that Debian is a Unix system, know what a Unix system
> is, and have some idea of what a "btrfs scrub cron job", or indeed an
> MTA, means. That's a pretty limiting audience for an operating system.
> The Universal Operating System should also be usable by people who don't
> meet those criteria, and I think Joss is right to speak up on their behalf.
>
> I'm quite prepared to believe that *our* Unix systems - and in
> particular, servers and development machines - need an MTA, but my
> parents' laptops really shouldn't need one. Ideally, we can have a
> sensible default that is suitable for both experts and non-experts; but
> if we can't, then the non-experts should probably have priority. After
> all, the sort of people who read debian-devel know how to switch away
> from a default MTA that isn't suitable for us, but my parents don't even
> know that they *have* an MTA.
>

I agree that a lot of (if not most) non-tech people probably don't use it, I do
see some benefits to this as opposed to desktop notifications. I
believe there was
a similar discussion going on about Ubuntu update notifications a few years ago,
when they started just popping up the update-manager window. My point here
being that those e-mails are more persistent than some notification
that can easily
get lost. Or perhaps there should be a more permanent system for such
notifications.
I'm not talking about the output of the btrfs scrub, but consider
important messages
on upgrades, such as were some things break compatibility with something and the
user needs to know that. For instance as the consequence of a security fix,
something no longer works (java applet? Instant messaging application?
that sort of
thing). You don't want a volatile message that they can't review after a reboot,
maybe they haven't even seen it if they ware away from the computer.
Also the e-mail doesn't get in the way of things, your work doesn't
get interrupted
by an e-mail, whereas desktop notifications may be more intrusive.

Perhaps there is a need for more permanent desktop notifications,
besides the current one-time notifications such as "USB storage drive has
been detected". Something that persists a reboot. I don't know, I'm
just brainstorming here.


-- 
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/camdu+mn_jqp6qb2yhfjqncu3t0sgzvlsbfy1ka-couytux6...@mail.gmail.com

Re: default MTA

[Adam Borowski]

On Tue, May 28, 2013 at 07:37:52AM -0400, Scott Kitterman wrote:
> It might help if we used a bit more precision in terimonolgy.  "Not a full
> blown MTA" as described here is a Mail Submission Agent (MSA).  See RFC
> 5598 for details:
> 
> http://tools.ietf.org/html/rfc5598#section-4.3.1

A mere MSA cannot handle local mail.  One such example is ssmtp which
doesn't know how to deliver rejections if it can't reach the smarthost,
making all failure notifications outright lost.

I don't think there's a name for a no-listen MTA.

There's no point in prolonged discussions about naming, though.  Just decide
if you're allergic to that rose smell :)

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130528121748.gd22...@angband.pl

Re: default MTA

[Simon McVittie]

On 28/05/13 12:25, Redalert Commander wrote:
> 2013/5/28 Josselin Mouette :
>> And on desktop systems, nobody reads local email. We might want to think
>> of a better notification system, but email is definitely not fit for
>> that anymore.
> 
> I don't think that is true at all. Personally, I use it to get the
> reports from smartd,
> from btrfs scrub cron jobs, other cron jobs, the changelogs for updated 
> packages
> get mailed there, which I really like (happens only with certain packages).

The participants in this thread are debian-devel subscribers: the sort
of people who know that Debian is a Unix system, know what a Unix system
is, and have some idea of what a "btrfs scrub cron job", or indeed an
MTA, means. That's a pretty limiting audience for an operating system.
The Universal Operating System should also be usable by people who don't
meet those criteria, and I think Joss is right to speak up on their behalf.

I'm quite prepared to believe that *our* Unix systems - and in
particular, servers and development machines - need an MTA, but my
parents' laptops really shouldn't need one. Ideally, we can have a
sensible default that is suitable for both experts and non-experts; but
if we can't, then the non-experts should probably have priority. After
all, the sort of people who read debian-devel know how to switch away
from a default MTA that isn't suitable for us, but my parents don't even
know that they *have* an MTA.

(Actually, the only reasons *my* laptop needs a working sendmail these
days are reportbug and bts, and until I got round to configuring
Postfix, my sendmail was a shell script to ssh into my email server and
submit the mail there. In some ways I'd rather just have syslog and
remote SMTP+IMAP.)

S


-- 
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/51a49d84.7060...@debian.org

Bug#710113: ITP: libquoin-clojure -- Library for Clojure with utilities for template engines

[Eugenio Cano-Manuel Mendoza]

Package: wnpp
Severity: wishlist
Owner: "Eugenio Cano-Manuel Mendoza" 

* Package name: libquoin-clojure
  Version : 0.1.0
  Upstream Author : David Santiago 
* URL : https://github.com/davidsantiago/quoin
* License : EPL-1
  Programming Lang: Clojure, Java
  Description : Library for Clojure with utilities for template engines

Library for Clojure with useful functions for template engines, it
provides quoin.text and quoin.map-access. quoin.text defines functions
to escape html and indent strings. quoin.map-access provides map lookups
with variant keys. This package is a dependency for stencil, a template
engine


-- 
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/20130528115515.18750.31336.reportbug@localhost

Re: default MTA

[Bjørn Mork]

Josselin Mouette  writes:
> Le mardi 28 mai 2013 à 10:34 +0100, Jonathan Dowland a écrit : 
>> There is an impedence mismatch between packages which consider an MTA and the
>> sendmail interface to be standard and those desktop components that make no
>> such assumption. If we are going to keep ensuring a local MTA/sendmail 
>> interface
>> going forward, I'd love to see it better integrated into the desktop stack. 
>> (In
>> fact I still battle debconf-stuff-on-top-of-exim from time to time, when I 
>> have
>> a system where I don't want any local mail.)
>
> I don’t think desktop components lack integration with the MTA. For
> example, evolution will use /usr/sbin/sendmail by default. The problem
> is that usually, the MTA will not be configured to do anything useful,

Moving the configuration from 1 package providing the MTA to N packages
is certainly not going to improve this...

> so users are better off using an external SMTP server, usually with
> authentication.

In what why does a local MTA prevent that?

The local MTA serves as a common configuration for the external SMTP
server, with a well known interface supported by every single package
which wants to send mail.

I don't see the point discussing this at all until there is an
alternative interface with a similar level of support.  Otherwise you
are just going to repeat the MIME support mess again.


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/87k3mj9xbo@nemi.mork.no

Re: default MTA

[Scott Kitterman]

Adam Borowski  wrote:

>On Tue, May 28, 2013 at 11:07:04AM +0200, Arno Töll wrote:
>> Why not consider something light, better suited for most systems
>which
>> need nothing but a sendmail binary which is suited to relay to a
>> real(tm) mail-server and deliver local mail and does not involve lots
>of
>> configuration and/or listening ports?
>
>+1000.
>
>Unlike some who want to eliminate m-t-a completely, and have
>notifications
>about failing RAID, nightly rsync cronjob being broken, etc, kindly
>delivered to /dev/null by this week's proprietary invention of
>$DESKTOP_ENV,
>I think a m-t-a is still vital on an UNIX system.
>
>Having a way to send outgoing mail without having to configure every
>single
>program to do so is nice, too.
>
>Those who want to run a real mail server will install know how to
>install a
>full-blown m-t-a.  And for example I accept mail on only two machines,
>one
>being a standby for the second.
>
>There's no reason for a mail daemon to listen on the network, or even
>to
>reside in memory, on the rest.  All you need is /usr/sbin/sendmail
>which can
>deliver remote mail remotely, and local mail locally.
>
>> On 28.05.2013 03:02, Marco d'Itri wrote:
>> > Now that we are done with systemd for the time being, can we have
>the 
>> > flame war about replacing Exim with Postfix as the default MTA?
>
>I for one find Postfix's config outright bizarre.  And compared to
>exim,
>that's quite an achievement.  (Let's not even mention the name of The
>Champ.)  So it'd not fit as a default.
>
>So let's replace exim with something simple, efficient and lightweight.

It might help if we used a bit more precision in terimonolgy.  "Not a full 
blown MTA" as described here is a Mail Submission Agent (MSA).  See RFC 5598 
for details:

http://tools.ietf.org/html/rfc5598#section-4.3.1

I think MSA instead of MTA by default is a reasonable discussion point 
(personally I use postfix as an MSA and it's trivial to set up via debconf, but 
I understand not everyone will want to do that ).  Let's decide MTA or MSA 
first and then decide what color we want to paint the MSA bikeshed later if 
that's the way the decision goes. 

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/5eb86cab-846a-45f5-81ea-5a8dbbd6f...@email.android.com

Re: optimizing PNGs

[Adam Borowski]

> A while ago, someone raised the possibility of recompressing PNG files. 

It turns out that since recently, some crazy googlers are guilty of "zopfli"
which can optimize PNGs even better, but taking all the CPU in the world for
doing so.  This doesn't sound useful for automated use during package
builds, but can be great for one-shot use.

Where an image is static (as opposed to being generated at runtime), in the
order of utility and efficiency:
upstream > source packages > binary packages
But then, upstream is outside your control, and you often want to use
unmodified upstream tarballs.  In such cases, build time is it.


I wonder what's the best way to do so.  The recommended way to optimize PNGs
is going to change: today, I nominate optipng -o4 -i0 -fix "$@" && advpng
-z4 "$@", but tomorrow we can expect optipng's upstream to integrate
advanced deflate, googles to come up with ultra-fast zopfli2, pngcrush
deciding they don't like to be upstaged, etc.

So my idea would be to have a token package with nothing but:
(git ls-files || find -type f)|grep -i '\.png$'|xargs -d '\n' ...
and Depends: on this week's best optimizer.

Is this sane?

Asking for a debhelper addition could be better but can't be used to specify
dependencies.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130528112609.gc22...@angband.pl

Re: default MTA

[Redalert Commander]

2013/5/28 Josselin Mouette :
> Le mardi 28 mai 2013 à 12:13 +0200, Adam Borowski a écrit :
>> Being able to send outgoing mail, and to handle local (such as SMTP rejects
>> or notifications from system daemons) seems plenty useful to me.
>
> Most clients (apart maybe from mailx) can use an external SMTP server to
> send email.
>
> And on desktop systems, nobody reads local email. We might want to think
> of a better notification system, but email is definitely not fit for
> that anymore.
>

I don't think that is true at all. Personally, I use it to get the
reports from smartd,
from btrfs scrub cron jobs, other cron jobs, the changelogs for updated packages
get mailed there, which I really like (happens only with certain packages).
It certainly makes my life easier.
I imagine a lot of people on a desktop use it, admittedly not everyone.
I do like the proposal to replace the current default MTA with a more
lightweight system for desktops,
but to remove it completely doesn't seem like a good idea to me.

Regards,
Steven


--
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/camdu+mnh2p2j65aiy-3dvg3xuz1tl68w8+qgj3jop9prazg...@mail.gmail.com

Re: default MTA

[Mike Hommey]

On Tue, May 28, 2013 at 12:09:07PM +0200, Josselin Mouette wrote:
> Le mardi 28 mai 2013 à 10:34 +0100, Jonathan Dowland a écrit : 
> > There is an impedence mismatch between packages which consider an MTA and 
> > the
> > sendmail interface to be standard and those desktop components that make no
> > such assumption. If we are going to keep ensuring a local MTA/sendmail 
> > interface
> > going forward, I'd love to see it better integrated into the desktop stack. 
> > (In
> > fact I still battle debconf-stuff-on-top-of-exim from time to time, when I 
> > have
> > a system where I don't want any local mail.)
> 
> I don’t think desktop components lack integration with the MTA. For
> example, evolution will use /usr/sbin/sendmail by default. The problem
> is that usually, the MTA will not be configured to do anything useful,
> so users are better off using an external SMTP server, usually with
> authentication.

Also, a *lot* of mail servers, including those of Debian developers are
rejecting mails on some stupid basis (like reverse DNS doesn't match
EHLO[1], EHLO host not found, some f*ckwit RBL decided that since you're
on a DSL IP range, you're a spammer, lack of a reverse DNS record at
all[2], etc.), effectively rejecting mails that don't go through an ISP
external SMTP server. Running your own MTA without a smart host is a
PITA these days. So you're better off using an external SMTP server
directly.

Mike

1. alioth lists do that, now.
2. thanks to ipv6.


-- 
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/20130528103957.ga28...@glandium.org

Re: default MTA

[Josselin Mouette]

Le mardi 28 mai 2013 à 12:13 +0200, Adam Borowski a écrit : 
> Being able to send outgoing mail, and to handle local (such as SMTP rejects
> or notifications from system daemons) seems plenty useful to me.

Most clients (apart maybe from mailx) can use an external SMTP server to
send email.

And on desktop systems, nobody reads local email. We might want to think
of a better notification system, but email is definitely not fit for
that anymore.

-- 
 .''`.  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/1369739125.12592.642.camel@pi0307572

Re: default MTA

[Adam Borowski]

On Tue, May 28, 2013 at 11:07:04AM +0200, Arno Töll wrote:
> Why not consider something light, better suited for most systems which
> need nothing but a sendmail binary which is suited to relay to a
> real(tm) mail-server and deliver local mail and does not involve lots of
> configuration and/or listening ports?

+1000.

Unlike some who want to eliminate m-t-a completely, and have notifications
about failing RAID, nightly rsync cronjob being broken, etc, kindly
delivered to /dev/null by this week's proprietary invention of $DESKTOP_ENV,
I think a m-t-a is still vital on an UNIX system.

Having a way to send outgoing mail without having to configure every single
program to do so is nice, too.

Those who want to run a real mail server will install know how to install a
full-blown m-t-a.  And for example I accept mail on only two machines, one
being a standby for the second.

There's no reason for a mail daemon to listen on the network, or even to
reside in memory, on the rest.  All you need is /usr/sbin/sendmail which can
deliver remote mail remotely, and local mail locally.

> On 28.05.2013 03:02, Marco d'Itri wrote:
> > Now that we are done with systemd for the time being, can we have the 
> > flame war about replacing Exim with Postfix as the default MTA?

I for one find Postfix's config outright bizarre.  And compared to exim,
that's quite an achievement.  (Let's not even mention the name of The
Champ.)  So it'd not fit as a default.

So let's replace exim with something simple, efficient and lightweight.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130528103351.gb22...@angband.pl

Re: default MTA

[Adam Borowski]

On Tue, May 28, 2013 at 12:09:07PM +0200, Josselin Mouette wrote:
> Le mardi 28 mai 2013 à 10:34 +0100, Jonathan Dowland a écrit : 
> > There is an impedence mismatch between packages which consider an MTA and 
> > the
> > sendmail interface to be standard and those desktop components that make no
> > such assumption. If we are going to keep ensuring a local MTA/sendmail 
> > interface
> > going forward, I'd love to see it better integrated into the desktop stack. 
> > (In
> > fact I still battle debconf-stuff-on-top-of-exim from time to time, when I 
> > have
> > a system where I don't want any local mail.)
> 
> I don’t think desktop components lack integration with the MTA. For
> example, evolution will use /usr/sbin/sendmail by default. The problem
> is that usually, the MTA will not be configured to do anything useful,
> so users are better off using an external SMTP server, usually with
> authentication.

Being able to send outgoing mail, and to handle local (such as SMTP rejects
or notifications from system daemons) seems plenty useful to me.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130528101337.ga22...@angband.pl

Re: default MTA

[Josselin Mouette]

Le mardi 28 mai 2013 à 10:34 +0100, Jonathan Dowland a écrit : 
> There is an impedence mismatch between packages which consider an MTA and the
> sendmail interface to be standard and those desktop components that make no
> such assumption. If we are going to keep ensuring a local MTA/sendmail 
> interface
> going forward, I'd love to see it better integrated into the desktop stack. 
> (In
> fact I still battle debconf-stuff-on-top-of-exim from time to time, when I 
> have
> a system where I don't want any local mail.)

I don’t think desktop components lack integration with the MTA. For
example, evolution will use /usr/sbin/sendmail by default. The problem
is that usually, the MTA will not be configured to do anything useful,
so users are better off using an external SMTP server, usually with
authentication.

-- 
 .''`.  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/1369735748.12592.634.camel@pi0307572

Re: Eliminating mail-transport-agent from standard

[Rodolfo García Peñas (kix)]

Josh Triplett  escribió:

[...]


- mutt: can easily Suggests a mail-transport-agent, since it supports
  IMAP and SMTP, leaving aside more exotic configurations like
  getmail/fetchmail.  (That leaves aside the question of whether mutt
  should be standard or optional, but I think either way it should only
  Suggests an MTA.)


I agree with this point. See this bug about this topic:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670769

Cheers,
kix

Rodolfo García Peñas (kix)
http://www.kix.es/


--
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/20130528095030.horde.jinr6wx3quqb0aohx7ek...@kix.es

Re: Bug#706078: ITP: base91 -- base91 encoder/decoder

[Jonathan Dowland]

On Tue, May 28, 2013 at 09:42:20AM +0200, Franck Routier (perso) wrote:
> this description is from the upstream readme. I have submited a bug
> report to ask for a correction.
> Should I patch the readme inbetween ?

If you mean the package description, then yes: it should be tailored
to Debian. When one can reuse upstream text in a package description,
great, but if it isn't correct it should be fixed. If you mean patch
an upstream documentation file shipped in the Debian package, that's
less important (IMHO), and could wait for an upstream correction.


-- 
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/20130528093633.GB16477@debian

Re: default MTA

[Jonathan Dowland]

On Tue, May 28, 2013 at 03:02:22AM +0200, Marco d'Itri wrote:
> Now that we are done with systemd for the time being, can we have the 
> flame war about replacing Exim with Postfix as the default MTA?
> 
> Are there any objections other than "but I like it this way!"?

As things stand, for the vast majority of users the actual MTA that is deployed
is irrelevant, as their only interface to it is via the debconf stuff which has
been engineered on top. (one might ask: why bother switching?)

Personally I've settled on using exim as an MTA everywhere, as a consequence of
it being the default MTA, however I have no objection with it being replaced by
default. (In fact I find the debconf engineering hinders rather than helps as
soon as you want to do anything complicated. Perhaps the need for some much
structure would go if it were not the default MTA.)

There is an impedence mismatch between packages which consider an MTA and the
sendmail interface to be standard and those desktop components that make no
such assumption. If we are going to keep ensuring a local MTA/sendmail interface
going forward, I'd love to see it better integrated into the desktop stack. (In
fact I still battle debconf-stuff-on-top-of-exim from time to time, when I have
a system where I don't want any local mail.)

I'd be interested in reading the arguments for switching: can you point my at
some relevant historic threads?


Thanks


-- 
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/20130528093430.GA16477@debian

Re: default MTA

[Arno Töll]

Hi,

On 28.05.2013 03:02, Marco d'Itri wrote:
> Now that we are done with systemd for the time being, can we have the 
> flame war about replacing Exim with Postfix as the default MTA?

I like Postfix and I use it everywhere I need a matured MTA. But I
wonder, what the benefit would be to replace a full blown MTA by another
one?

Why not consider something light, better suited for most systems which
need nothing but a sendmail binary which is suited to relay to a
real(tm) mail-server and deliver local mail and does not involve lots of
configuration and/or listening ports?

Assuming we can fix the dma situation (#671364) I'd rather consider that
one a (possible) future default MTA.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Eliminating mail-transport-agent from standard

[Holger Levsen]

Hi,

On Dienstag, 28. Mai 2013, Josh Triplett wrote:
> In addition to determining the MTA pulled in by default for packages
> which require mail-transport-agent in order to function (the provider of
> default-mta), I'd like to propose as a release goal that we not have any
> MTA in standard anymore.

while I'm not sure I consider removing the MTA from the standard install to be 
sensible, I'd like to point out

#508644 Sorting out mail-transport-agent mess

where many questions were already discussed.


cheers,
Holger


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

Re: Bug#706078: ITP: base91 -- base91 encoder/decoder

[Franck Routier (perso)]

Le 25/04/2013 23:42, Andreas Bombe a écrit :

On Wed, Apr 24, 2013 at 03:40:57PM +0200, Franck wrote:

basE91 is an advanced method for encoding binary data as ASCII characters. It
is similar to UUencode or base64, but is more efficient. The overhead produced
by basE91 depends on the input data. It amounts at most to 23% (versus 33% for
base64) and can range down to 14%, which typically occurs on 0-byte blocks.
This makes basE91 very useful for transferring larger files over binary
insecure connections like e-mail or terminal lines.

That word should be safety, not security. Safety here means the message
does not get mangled, security on the other hand would mean things like
encryption.

HI,

this description is from the upstream readme. I have submited a bug 
report to ask for a correction.

Should I patch the readme inbetween ?

Franck



smime.p7s
Description: Signature cryptographique S/MIME

Re: systemd .service file conversion

[Helmut Grohne]

On Mon, May 27, 2013 at 09:13:44AM +0200, Ond??ej Surý wrote:
> I would be quite happy to write service files for two (systemd, upstart) or
> three (systemd, upstart, openrc) of those in all my packages[*], if it
> stops the endless flamewar here. I would also be happy to have the
> requirement to support two (or three) of them in the Debian policy.

My major point here was precisely that you are *not* done with just
writing the service/job descriptions/scripts for all those init systems.
You'd likely have to patch every single daemon to enable the socket
activation method for those init systems, that the authors of your
daemon did not like to use.

If on the other hand you omit this patching, then that init system
partially loses one of its selling points. So instead of supporting one
init system properly, we support four init systems poorly.

What you are proposing is no solution.

Helmut


-- 
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/20130528063738.ga27...@alf.mars