Aprenda a fazer jogos no PC

[Base Binaria]

Ola caro amigo.

Aprenda a fazer jogos e programas no seu computador pessoal. 
Vamos ao longo do nosso curso de programacao estudar varias
linguagens de programacao assim como diversos sistemas
informaticos. Entre no mundo maravilhoso dos jogos de video
com os nossos tutoriais, ponha em prática os seus projetos 
de programacao.

Vao ser abordadas as seguintes linguagens de programacao:

- Assembly
- C++
- Pascal
- Visual Basic
- JAVA  




Webmaster: J.P.S

Contactos:

EMail: basebinaria.n...@iol.pt
   basebinaria@iol.pt
   basebina...@netcabo.pt
 
Site:  http://www.basebinaria.net
---
Info OUT-2011

Enviado por server1
---


-- 
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/b786a0$1557...@neti05smtpa.hdi.tvcabo

Re: RFC: Making mail-transport-agent Priority: optional

[Jonas Meurer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Thanks to Josh for starting this discussion. I think that you summarized
most arguments very well in your mail.

Am 12.10.2011 23:39, schrieb Josh Triplett:
> Not every system needs an MTA, and I'd argue that today most systems
> don't.  End-user systems (desktops, laptops) typically handle mail via
> one or more smarthosts elsewhere, driven by MUAs that know how to talk
> SMTP.  Other tools which send mail have learned to send SMTP as well,
> and tools that cannot still have the option of recommending or depending
> on an MTA without needing one in standard.  And many servers don't need
> an MTA either, unless they run programs which need to send mail by
> calling sendmail.

I agree with the counter-arguments in this thread, that a default UNIX
server setup should contain an MTA. This also is true for desktop
systems of advanced UNIX sysadmins.

But if Debian cares about desktop users which don't know the internals
of a Linux/UNIX system, we need to accept that they have a very
different vision of a default installation. For them a system should be
kept easy, with as few daemons as possible. For them things like power
consumption and RAM usage of default systems count much more than
whether the system has all required elements of a standard UNIX system.

I suggest that there is no "one size fits all" for servers, desktops and
mobile systems. Either we distingush between different needs, or we
focus on one target user group. In case we want a "universal operating
system", we need to provide _different_ sane defaults depending on the
needs.

Why not use tasksel for this? It should be easy to introduce a basic
server task which contains things like default MTA, SSH server, etc.
while a basic desktop task doesn't.

To make my point clear: I'm much in favour of supporting default
installations without a MTA.

Regards,
 jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOmUOYAAoJEFJi5/9JEEn+vIEQAKtUUGiGmp6xlY4W2s+AHyCb
j0N4w2BXcMJZ6wzAp3f8/SvC4jtcnaToBvE7J6YCJ3p95GxqztbhOcrqPTRt2XhM
b4odvTJanbF80dMHPQ9nkisL432uKW+WAd0Z4P4bhQJUY/oR/BOlZ7lCGywJ17Ax
W6tL78l4hMLVLKvedKbZlleY2/kATFz88vqCa/UdE8mFnYEvvg1jvfQOS8w+iKWu
ZZrgetzwN5F4tX6FZTMSbqWB/lOjxxAYObAV8iNv8Eems4fMIniZpuDEOzja/y3e
4bY7l2DiRY/cEoEl5NQIyY9zNMRGSBeXdgoEl1TvLhHtVNeAouva+YjIr3bj7lpV
q/y0JisKmUYlvaVGKRMDh3OVJf8TNxkaC5xZYbo5zTWjUoCNYlzdedgjFFyD3mpt
MHzdcpeArULJ4W+4lBJV9Hk3qJhKALdL8fXfit5Nixeb8P+k690H7Vwdk9GCUhfB
AcY2O3FywKdr4qZzlpANUihWmsegPrwXz2tKcAmf5UtEcODgF3y1uPWKbtbepOGp
yI72ZcHb9TmUoFICfsdIlBjCQRP1CzX5zuEdefu5DBu4AuZwZYz5Y08jn5ItiZ7O
A/RY/R9mBcLMwXHgs4t3FtQNVMRpjGK72ZdEr+e+yGcH2D/pW7eKuS+au8TGDE6I
pKfdUFQI+oQjc3FgkqZC
=kJcq
-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/4e99439e.9050...@freesources.org

Re: RFC: Making mail-transport-agent Priority: optional

[Simon McVittie]

On Fri, 14 Oct 2011 at 16:02:09 -0700, Don Armstrong wrote:
> On Wed, 12 Oct 2011, Josh Triplett wrote:
> > End-user systems (desktops, laptops) typically handle mail via one
> > or more smarthosts elsewhere, driven by MUAs that know how to talk
> > SMTP.
> 
> While this definitely is the current state, it's not optimal.

What's bad about it? What's better about sending through an MTA,
particularly on a machine that basically only has one user?

On a personal desktop or (particularly) laptop, there's often no practical
difference between configuring mail once per machine or once per user,
because the machine only has one user anyway; but configuring for the
machine requires root authentication and configuring for the user
doesn't, so for a naive user, the MUA is better.

Credentials for authenticated SMTP are typically per-real-person anyway,
so ideally you want per-user configuration. (My mailserver has ended up
with user accounts representing machines too, solely so they can have
system-wide mail submission...)

Sending through an MTA does let you press "send" without connectivity
and have the mail server submit the mail eventually, but without any
particularly useful feedback to the user (who can't easily distinguish
between "mail got sent", "mail is still queued", and "an error
occurred, the mail will never arrive"). Many GUI MUAs will retry mail
delivery or have a "work offline" mode, and a GUI MUA can give the
user useful feedback; so for a naive user, the MUA is better.

I concede that using an MTA may be better for Mutt users, but I would
imagine that anyone who's taught themselves to use Mutt is quite capable
of installing an MTA to go with it. My Mutt configuration currently
uses a local postfix installation for personal/Debian mail, but speaks
SMTP directly for my work mail; I'm honestly not sure what I gain from
the local postfix installation, except the local-mail-receiving side
(cron jobs etc.), which is orthogonal to whether I use the MTA for
sending.

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/20111015093259.gb29...@reptile.pseudorandom.co.uk

Re: RFC: Making mail-transport-agent Priority: optional

[Andrei Popescu]

On Sb, 15 oct 11, 10:26:06, Jonas Meurer wrote:
> 
> Why not use tasksel for this? It should be easy to introduce a basic
> server task which contains things like default MTA, SSH server, etc.
> while a basic desktop task doesn't.

Actually there already exists a "Mail Server" task[1]. Not very useful 
given that exim is already installed through the "Standard" task.

[1] at least in the squeeze installer, I seem to recall some plans to 
redefine the default tasks.

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: RFC: Making mail-transport-agent Priority: optional

[Adam Borowski]

On Sat, Oct 15, 2011 at 12:46:31AM +0200, Josselin Mouette wrote:
> Le vendredi 14 octobre 2011 à 11:32 -0300, Henrique de Moraes Holschuh a
> écrit : 
> > I seem to recall our super duper memory-bloated DEs were not even
> > warning the user when something was screaming blood murder on the
> > emergency, alert and critical priorities in syslog until wheezy...  That
> > absurd negligence has been fixed, AFAIK, at least in KDE4.  I assume
> > gnome is no worse, and also notifies the user.
> 
> Certainly not. GNOME will not present to the user information that he
> will not be able to process. It will warn, for example, when hardware is
> failing and this can be clearly diagnosed, but showing raw syslog
> entries sounds like one of the less useful features to implement.
> 
> The best approach is probably the current one: do nothing and let users
> configure their email setup.

Hell no.  I'd go as far as labelling it a severity:critical bug.

If some part of the system has something important to say, you need to tell
it to the user -- or face serious data loss.  Mails sent to root are
something important (or the part which sends them should be spanked for
spamming).

I've recently attempted to recover data lost by a client -- they had a RAID1
setup.  It turns out one of the disks failed seven months ago, mdadm duly
kept notifying about that, but this wonderous Gnome feature meant no one
knew.  And seven months later, the other disk failed...

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Re: RFC: Making mail-transport-agent Priority: optional

[Josselin Mouette]

Le samedi 15 octobre 2011 à 12:36 +0200, Adam Borowski a écrit : 
> Hell no.  I'd go as far as labelling it a severity:critical bug.

Go ahead, reporting bugs doesn’t necessarily get people to give a fuck.

> If some part of the system has something important to say, you need to tell
> it to the user -- or face serious data loss.  Mails sent to root are
> something important (or the part which sends them should be spanked for
> spamming).

You seem to be unaware of the fact that users faced with too many
messages or alerts will discard them without reading. This is part of
what makes Vista a security disaster.

> I've recently attempted to recover data lost by a client -- they had a RAID1
> setup.  It turns out one of the disks failed seven months ago, mdadm duly
> kept notifying about that, but this wonderous Gnome feature meant no one
> knew.  And seven months later, the other disk failed...

In squeeze, GNOME prints alerts about failing disks. This is the perfect
example of a well-defined error message that the user can take action
upon. This is also a perfect example where using syslog would be
completely irrelevant.

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


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

Re: RFC: Making mail-transport-agent Priority: optional

[Adam Borowski]

On Sat, Oct 15, 2011 at 12:46:50PM +0200, Josselin Mouette wrote:
> Le samedi 15 octobre 2011 à 12:36 +0200, Adam Borowski a écrit : 
> > Hell no.  I'd go as far as labelling it a severity:critical bug.
>
> Go ahead, reporting bugs doesn’t necessarily get people to give a fuck.

So "causes serious data loss" is no longer RC?  Good to know.

> > If some part of the system has something important to say, you need to tell
> > it to the user -- or face serious data loss.  Mails sent to root are
> > something important (or the part which sends them should be spanked for
> > spamming).
> 
> You seem to be unaware of the fact that users faced with too many
> messages or alerts will discard them without reading. This is part of
> what makes Vista a security disaster.

Do you mean, "are you sure you want to exit the program?" that has recently
been added to some programs because "Windows users expect that"?  Or the
envelope icon Gnome3 adds that holds such important info like the last song
that started playing (used to OSD for a couple of seconds), or that you got
new mail (no matter it's already shown elsewhere, and the mail is long read
and gone).

If a daemon thinks a notification is important enough to send a mail to
root, it most likely is.

> > I've recently attempted to recover data lost by a client -- they had a RAID1
> > setup.  It turns out one of the disks failed seven months ago, mdadm duly
> > kept notifying about that, but this wonderous Gnome feature meant no one
> > knew.  And seven months later, the other disk failed...
> 
> In squeeze, GNOME prints alerts about failing disks. This is the perfect
> example of a well-defined error message that the user can take action
> upon. This is also a perfect example where using syslog would be
> completely irrelevant.

I don't know about squeeze, but at least in unstable in May it did not send
any alerts for degraded RAID.  I guess it may consider a "failing disk" to
be one that has I/O errors or SMART notices and not one which is missing
(this time, I didn't insert the data ribbon right after messing inside), but
the effect is mostly the same.

Also, do you mean that every single check has to be duplicated for Gnome? 
That every single daemon which might have something important to say needs
to depend on some Gnome libs so it can send a notification?


-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Re: RFC: Making mail-transport-agent Priority: optional

[Henrique de Moraes Holschuh]

On Sat, 15 Oct 2011, Josselin Mouette wrote:
> Le vendredi 14 octobre 2011 à 11:32 -0300, Henrique de Moraes Holschuh a
> écrit : 
> > I seem to recall our super duper memory-bloated DEs were not even
> > warning the user when something was screaming blood murder on the
> > emergency, alert and critical priorities in syslog until wheezy...  That
> > absurd negligence has been fixed, AFAIK, at least in KDE4.  I assume
> > gnome is no worse, and also notifies the user.
> 
> Certainly not. GNOME will not present to the user information that he
> will not be able to process. It will warn, for example, when hardware is

I see.  You *really* might want to reconsider the two highest priority
levels, at least for the kernel facility.

Unsuitable messages on these levels are considered a bug, and get fixed.
I should know, since I was responsible for one such problem in the
thinkpad-acpi driver.

So, exactly which emergency or alert messages are *so common* and
useless that justifies gnome deciding to conceal _all_ such warnings
from their users?  A rare message the user cannot do anything about is
certainly not an excuse to hide the rare message that the user COULD do
something about, so there must be more to this.

-- 
  "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/20111015133442.gb2...@khazad-dum.debian.net

Re: RFC: Making mail-transport-agent Priority: optional

[Henrique de Moraes Holschuh]

On Sat, 15 Oct 2011, Adam Borowski wrote:
> On Sat, Oct 15, 2011 at 12:46:50PM +0200, Josselin Mouette wrote:
> > Le samedi 15 octobre 2011 à 12:36 +0200, Adam Borowski a écrit : 
> > > Hell no.  I'd go as far as labelling it a severity:critical bug.
> >
> > Go ahead, reporting bugs doesn’t necessarily get people to give a fuck.
> 
> So "causes serious data loss" is no longer RC?  Good to know.

Be reasonable.  This is more like "might increase the risk of worse damage",
after all it also depends on the user being able to act on the notification
in the first place.

> If a daemon thinks a notification is important enough to send a mail to
> root, it most likely is.

Well, if anything logs on emergency and alert levels, it is a bug if it is
*not* important enough to pester all logged users immediately.   It is an
even more clearcut case.

-- 
  "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/20111015135057.gc2...@khazad-dum.debian.net

RFC transitioning to gnutls28

[Andreas Metzler]

Hello,

gnutls28 (that is GnuTLS 3.x) has been available in experimental for
quite some time. While the API breakage compared to gnutls26 (2.x) is
not too bad, there are two major issues:

* It uses nettle instead of gcrypt as crypto backend[1]. Packages that
  directly use gcrypt will need an additional build-dependency. Also
  quite a lot packages use special code for thread locking which needs
  to be replaced/deleted/whatever.

* The new version uses LGPLv3+/GPLv3+ instead of v2+, and can
  therefore not be used in GPLv2 projects anymore. (Hello, cups!)

Because of these issue I think that I should not upload gnutls28 to
unstable and build libgnutls-dev from the gnutls28 version. Building
against the new version should only happen if the maintainer of the
depending package has doublechecked bothat that he/she may use
gnutls28 and that the package still works. Therefore I plan to use a
versioned name for the development package (libgnutls28-dev) when
uploading to unstable.

The obvious downside is that we will have two versions in unstable
(and probably even in squeeze). At least we are using versioned
symbols.

Thoughts/comments/magic bullet anyone?

thanks, cu andreas
PS: X-posted to -devel and -release, please followup to devel. I am
subscribed.

[1] Actually even for 2.12.x nettle is the prefered crypto backend.

http://mid.gmane.org/<20110819174110.GA2105%40downhill.g.la>


-- 
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/20111015155227.ga2...@downhill.g.la

Re: RFC: Making mail-transport-agent Priority: optional

[Steve Langasek]

On Fri, Oct 14, 2011 at 04:02:09PM -0700, Don Armstrong wrote:
> On Wed, 12 Oct 2011, Josh Triplett wrote:
> > End-user systems (desktops, laptops) typically handle mail via one
> > or more smarthosts elsewhere, driven by MUAs that know how to talk
> > SMTP.

> While this definitely is the current state, it's not optimal. It would
> be ideal to have an MTA like esmtp or similar,[1] which was easily
> configured and could then be used by all things that need to send
> outgoing mail without configuring them directly. [Possibly with
> unified user configuration in .config/mail or similar which overrode
> the system configuration and could be written and read by any of the
> existing MUAs we have.]

> Instead of band-aiding over this problem, lets actually fix it.

Hear, hear.  "How do I deliver mail?" is a per-system setting, not a
per-application setting, and the move towards having MUAs talking SMTP
directly to send mail is a flawed model picked up on the Linux desktop from
certain other OSes.  The right solution here is to fix the MTAs to be
configurable from the desktop, and fix the MUAs to use the MTA - *not* to
get rid of the MTA.

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

DEP-5 for Upstream

[Schrober]

Hi,

I've read from time to time that DEP-5 should also work for upstream. Since 
SPDX looks to complicated to have it stored in the upstream repos, I wanted to 
use the more simpler, but still extreme useful DEP-5 in a license file. Is it 
ok to use DEP-5 for a LICENSE file and how should it be changed? For example 
the "On Debian systems, the full text of the GNU General Public..." part 
sounds wrong for an upstream version.

Btw. when is the next debian-policy release that should include DEP-5.. and 
therefore provide a good url for the VERSIONED_FORMAT_URL?

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/2662837.nixkfao...@sven-desktop.home.narfation.org

Re: Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

On Fri, Oct 14, 2011 at 10:35:13AM +0100, Philip Hands wrote:
> On Thu, 13 Oct 2011 10:17:38 +0200, "Bernhard R. Link"  
> wrote:
> ...
> > > - Taking time to download and install, which increases the time and
> > >   bandwidth needed to install or upgrade a Debian system.
> > 
> > Please drop the "upgrade". If you deinstall it there is no cost at
> > upgrading.
> 
> I think the point here is that people that accept a default install are
> liable to not be brave enough to remove chunks of the system, or even
> perceptive enough to notice that some daemon that seems to be surplus to
> requirements is running, let alone then doing the work to find out that
> they can safely remove it, and then actually do so.
> 
> Also, most normal users will never remove it on the basis that it's
> "standard" (assuming that they discover that fact).
> 
> That being the case, they will get every upgrade.

Thank you for your much clearer restatement of the problem.  That's
exactly what I mean, and what I'd like to avoid by removing an MTA from
standard.

- Josh Triplett


-- 
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/20111015170101.GA22885@leaf

Re: aptitude weirdness wrt upgrades and keeps

[Josh Triplett]

Norbert Preining wrote:
> In the current transition to gnome3 (or it seems) I press
> U
> to update all packages, and then it suggests me to remove 30 or
> so packages.
> 
> I know this game, normally I have to press "." a few times to come
> to the solution that simply keeps some of the packages at the current
> level.
> 
> Well, normally it is a few times ".", no with gnome3, I stopped after
> 100 (hundred!) times pressing ".", and still aptitude does not suggest
> the simple solution to keep all those gnome3 packages on their current
> state. And every time I press "." it takes more and more time.
> 
> That cannot be the intended behaviour? Or is there any way to 
> teach aptitude that aptitude orders the solutions depending on
> the number of removals?

While I would certainly like to see aptitude making some smarter
decisions to begin with, you can reach a solution you like much more
quickly by using the "reject" and "approve" mechanism.  When you view
aptitude's solution, press 'r' on any action you want to reject (such as
removing a critical package), and 'a' on any action you know you want to
approve.  Then, press '.' again, and aptitude will come up with a
solution which definitely doesn't contain any of the rejected actions,
and which likely contains the approved actions.

Most of the time, this will quickly get you to a solution you like, or
to the "No more solutions" message (in the case of active breakage in
unstable, for which you might not like any solution other than "don't do
the upgrade you had originally intended").

- Josh Triplett


-- 
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/20111015171331.GA22967@leaf

Re: RFC transitioning to gnutls28

[Marco d'Itri]

On Oct 15, Andreas Metzler  wrote:

> * It uses nettle instead of gcrypt as crypto backend[1]. Packages that
Why?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: Making mail-transport-agent Priority: optional

[Ben Hutchings]

On Sat, 2011-10-15 at 09:53 -0700, Steve Langasek wrote:
> On Fri, Oct 14, 2011 at 04:02:09PM -0700, Don Armstrong wrote:
> > On Wed, 12 Oct 2011, Josh Triplett wrote:
> > > End-user systems (desktops, laptops) typically handle mail via one
> > > or more smarthosts elsewhere, driven by MUAs that know how to talk
> > > SMTP.
> 
> > While this definitely is the current state, it's not optimal. It would
> > be ideal to have an MTA like esmtp or similar,[1] which was easily
> > configured and could then be used by all things that need to send
> > outgoing mail without configuring them directly. [Possibly with
> > unified user configuration in .config/mail or similar which overrode
> > the system configuration and could be written and read by any of the
> > existing MUAs we have.]
> 
> > Instead of band-aiding over this problem, lets actually fix it.
> 
> Hear, hear.  "How do I deliver mail?" is a per-system setting, not a
> per-application setting,

It's not per-system, or even per-user.

If I want to send mail from my personal address I should send it through
my own smarthost.  If I want to send mail from my work address I *must*
send it through the work smarthost (thanks to SPF).  I could possibly
configure this at the MTA level, but no other user should be allowed to
use my credentials to send mail through the work smarthost.

For my own systems there is a reasonable system default of using my own
smarthost, but I wouldn't expect most households to have that.  Other
people could use their ISP's smarthost.  But in general, each member of
a household might use a different mail service.  Then what would be the
system default?

> and the move towards having MUAs talking SMTP
> directly to send mail is a flawed model picked up on the Linux desktop from
> certain other OSes.

While I agree that MUAs tend to have lousy SMTP implementations, this is
a necessary option.

> The right solution here is to fix the MTAs to be
> configurable from the desktop, and fix the MUAs to use the MTA - *not* to
> get rid of the MTA.

The MTA has to be able to get error reports back to the MUA, so we need
the MUA to support local mail too.  Now the user has an MTA and two
accounts in the MUA, when all he wanted was a single account.  How much
complexity should we foist on users for the sake of doing it 'right'?

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.


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

Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

Steve Langasek wrote:
> "How do I deliver mail?" is a per-system setting, not a per-application
> setting, and the move towards having MUAs talking SMTP directly to send
> mail is a flawed model picked up on the Linux desktop from certain other
> OSes.

No, "How do I deliver mail?" represents a per-user setting, and
sometimes a per-user-email-address setting depending on the pickiness of
mail servers about the addresses in "From:".

I'll certainly agree that it might make sense to have a common SMTP
configuration for sending email for a particular user (and possibly
email address), so that MUAs can share it; the same thing goes for IMAP
configuration, as well.  However, neither of those should live in a
system MTA, not least of which because if a system really did have
multiple users, it wouldn't make sense to do all the work of figuring
out which smarthost to use for which user rather than just letting each
user's MUA handle mail for that user.

> The right solution here is to fix the MTAs to be
> configurable from the desktop, and fix the MUAs to use the MTA - *not* to
> get rid of the MTA.

MTAs would need to advance quite a bit to get anywhere near as usable as
a MUA that speaks SMTP, not least of which in error reporting.  (Most of
the people I know who run local MTAs have had at least one "all my mail
got stuck in a queue for one or more weeks" story.)

More importantly, I don't advocate getting rid of any MTAs; I'm
advocating that an MTA should not form part of standard, on the basis
that most users don't want or need one.  Anyone who needs an MTA can
easily install one, while many people who *don't* need an MTA don't know
that they can and should remove it.

- Josh Triplett


-- 
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/20111015173945.GA23214@leaf

Re: DEP-5 for Upstream

[Joey Hess]

Schrober wrote:
> I've read from time to time that DEP-5 should also work for upstream. Since 
> SPDX looks to complicated to have it stored in the upstream repos, I wanted 
> to 
> use the more simpler, but still extreme useful DEP-5 in a license file. Is it 
> ok to use DEP-5 for a LICENSE file and how should it be changed? For example 
> the "On Debian systems, the full text of the GNU General Public..." part 
> sounds wrong for an upstream version.

I use DEP-5 this way for my software. I use a wording like this to
meet both use cases:

License: GPL-3+
 The full text of version 3 of the GPL is distributed as doc/GPL in
 this package's source, or in /usr/share/common-licenses/GPL-3 on
 Debian systems.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFC: Making mail-transport-agent Priority: optional

[brian m. carlson]

On Sat, Oct 15, 2011 at 09:53:32AM -0700, Steve Langasek wrote:
> Hear, hear.  "How do I deliver mail?" is a per-system setting, not a
> per-application setting, and the move towards having MUAs talking SMTP
> directly to send mail is a flawed model picked up on the Linux desktop from
> certain other OSes.  The right solution here is to fix the MTAs to be
> configurable from the desktop, and fix the MUAs to use the MTA - *not* to
> get rid of the MTA.

Until you can get an MTA to deliver mail to a smarthost authenticating
via GSSAPI with the Kerberos credentials of the sending user, I'm
going to keep using mutt's SMTP support.  TTBOMK, no MTA in Debian
supports outgoing GSSAPI authentication *at all*, let alone with the
specific user credentials.  Only a few MTAs support per-user
configuration on any level at all.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Re: RFC: Making mail-transport-agent Priority: optional

[Joey Hess]

Josh Triplett wrote:
> What would it take to make this change?
> 
> I will happily work to coordinate this transition.

For me this thread raises two interesting questions. The first is the one
Josh asks above, which has not been answered. How do we make decisions
about the content of standard? How can that decision process be improved?

My other question comes from policy:

 `standard'
  These packages provide a reasonably small but not too limited
  character-mode system.  This is what will be installed by default
  if the user doesn't select anything else.  It doesn't include
  many large applications.

As I read this, it would be legal for tasksel, when the user selects the
desktop task, to *not* install standard, or not all of standard. It
could, for example, decide to drop the MTA. I'm curious what the
reaction to that would be, in both this specific and the general case.
Is it a compromise that allows us to keep standard full of unix goodness
while still catering to the desktop, or a greedy power grab?

(Other examples of the general case would be a Freedombox task that
didn't install a MTA, since the freedombox devs have decided to use some
other inter-user communication, IIRC -- or a specialized Debian Pure
blend that chose to not install standard at all.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

Jonas Meurer wrote:
> Thanks to Josh for starting this discussion. I think that you summarized
> most arguments very well in your mail.

Thank you for your very clear explanation of the issue, as well.

> Am 12.10.2011 23:39, schrieb Josh Triplett:
> > Not every system needs an MTA, and I'd argue that today most systems
> > don't.  End-user systems (desktops, laptops) typically handle mail via
> > one or more smarthosts elsewhere, driven by MUAs that know how to talk
> > SMTP.  Other tools which send mail have learned to send SMTP as well,
> > and tools that cannot still have the option of recommending or depending
> > on an MTA without needing one in standard.  And many servers don't need
> > an MTA either, unless they run programs which need to send mail by
> > calling sendmail.
>
> I agree with the counter-arguments in this thread, that a default UNIX
> server setup should contain an MTA. This also is true for desktop
> systems of advanced UNIX sysadmins.
>
> But if Debian cares about desktop users which don't know the internals
> of a Linux/UNIX system, we need to accept that they have a very
> different vision of a default installation. For them a system should be
> kept easy, with as few daemons as possible. For them things like power
> consumption and RAM usage of default systems count much more than
> whether the system has all required elements of a standard UNIX system.

I think you've captured the problem here precisely.  A desktop, laptop,
or other end-user system does not have the same needs as a server.  An
MTA may well make sense on a UNIX server, either for actual use as a
mail server, or as a component needed by daemons that need to send mail.
However, a default personal system does not typically need an MTA,
though advanced users with particular needs or preferences may wish to
install one on their systems.

Note that anyone participating in this thread almost certainly qualifies
as an "advanced user". :)

We have a "server" task, and a "mail server" task.  The former might
want to include an MTA, and the latter obviously should.  Standard
shouldn't.

- Josh Triplett


-- 
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/20111015184225.GA23236@leaf

Re: RFC: Making mail-transport-agent Priority: optional

[Steve Langasek]

On Sat, Oct 15, 2011 at 06:53:02PM +0100, Ben Hutchings wrote:
> > Hear, hear.  "How do I deliver mail?" is a per-system setting, not a
> > per-application setting,

> It's not per-system, or even per-user.

> If I want to send mail from my personal address I should send it through
> my own smarthost.  If I want to send mail from my work address I *must*
> send it through the work smarthost (thanks to SPF).  I could possibly
> configure this at the MTA level, but no other user should be allowed to
> use my credentials to send mail through the work smarthost.

Needing to send mail through specific per-user smarthosts is the exception,
not the rule.  Most machines have a designated forwarding smarthost based on
who their ISP is, not based on which email address someone wants to use.

So yes, there is unfortunately the need for complex SMTP handling in the MUA
in some cases, but the *default* should still be per-system.

> > The right solution here is to fix the MTAs to be
> > configurable from the desktop, and fix the MUAs to use the MTA - *not* to
> > get rid of the MTA.

> The MTA has to be able to get error reports back to the MUA, so we need
> the MUA to support local mail too.  Now the user has an MTA and two
> accounts in the MUA, when all he wanted was a single account.

Which brings us back to the problem of delivering system-level notifications
to the admin (cron failures and the like).  Yes, the user wants to have a
single account.  But if that one account is remote, and cron mail isn't
forwarded to it, how does the admin user get notifications of system
problems?  I think any policy on desktop mail handling needs to account for
this.  The status quo does not.

> How much complexity should we foist on users for the sake of doing it
> 'right'?

I don't think the current situation is less complicated, it's just letting
things fall through the cracks.

-- 
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: RFC: Making mail-transport-agent Priority: optional

[Steve Langasek]

On Sat, Oct 15, 2011 at 06:33:14PM +, brian m. carlson wrote:
> On Sat, Oct 15, 2011 at 09:53:32AM -0700, Steve Langasek wrote:
> > Hear, hear.  "How do I deliver mail?" is a per-system setting, not a
> > per-application setting, and the move towards having MUAs talking SMTP
> > directly to send mail is a flawed model picked up on the Linux desktop from
> > certain other OSes.  The right solution here is to fix the MTAs to be
> > configurable from the desktop, and fix the MUAs to use the MTA - *not* to
> > get rid of the MTA.

> Until you can get an MTA to deliver mail to a smarthost authenticating
> via GSSAPI with the Kerberos credentials of the sending user, I'm
> going to keep using mutt's SMTP support.  TTBOMK, no MTA in Debian
> supports outgoing GSSAPI authentication *at all*, let alone with the
> specific user credentials.  Only a few MTAs support per-user
> configuration on any level at all.

postfix most definitely supports GSSAPI authentication, because it supports
SASL and GSSAPI is just one more SASL mechanism.  But yes, per-user GSSAPI
authentication passed through the MTA is non-trivial, and is one of the
better justifications why MUAs need to talk SMTP.  They just shouldn't do so
by default.

-- 
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: Re: RFC: Making mail-transport-agent Priority: optional

[Steve Langasek]

On Wed, Oct 12, 2011 at 08:34:52PM -0700, Josh Triplett wrote:

> The main reasons to stop having an MTA in standard:

> - Starting a daemon at boot time, which slows down booting.  This led me
>   to notice the problem in Debian Live: it took a non-trivial amount of
>   time for the boot process to finish starting exim and move on.

Does Debian Live use insserv with parallel booting?  Granted, I/O is the
bottleneck for booting from CD, so there's still going to be some impact;
but on my systems (which all use postfix - so you can count me among the 20%
of popcon users who have uninstalled exim to install postfix), MTA startup
time is pretty small - on the order of 1.5s according to my bootcharts,
which is hardly anything on the systems in question.

If exim is too heavy on startup, there are other options we could consider.

> - Listening on ports by default, which exposes the system to any
>   potential vulnerabilities, as well as potentially allowing the sending
>   of spam.  I've checked, and out of all the packages with priority
>   standard or above, only exim and isc-dhcp-client listen on ports by
>   default.  Removing an MTA significantly reduces the attack surface of
>   a default Debian system.

Running an MTA does not imply accepting mail from outside the machine for
delivery.  We could address this by configuring our standard MTA to only
accept from localhost by default, or to only accept submissions via
/usr/sbin/sendmail by default.

> - Asking configuration questions via debconf at install time, which
>   increases the amount of work and complexity required to install
>   Debian.  For most users, these questions will duplicate the process
>   they later go through to configure their MUA.

That's absolutely a bug in the MUAs for requiring additional configuration
instead of working with the default.

> - Taking time to download and install, which increases the time and
>   bandwidth needed to install or upgrade a Debian system.

I think you're reaching with this one.

> - Running a daemon all the time, which takes up RAM.

You're worried about this on a desktop system running firefox?

> - Taking up space on disk, as with any other package installed but not used.

Anyone for whom this is a real problem is not installing standard anyway.

Your proposed benefits become more outlandish from there, so 

-- 
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: RFC: Making mail-transport-agent Priority: optional

[Neil Williams]

On Sat, 15 Oct 2011 14:56:15 -0400
Joey Hess  wrote:

> My other question comes from policy:
> 
>  `standard'
>   These packages provide a reasonably small but not too limited
>   character-mode system.  This is what will be installed by default
>   if the user doesn't select anything else.  It doesn't include
>   many large applications.
> 
> As I read this, it would be legal for tasksel, when the user selects the
> desktop task, to *not* install standard, or not all of standard. It
> could, for example, decide to drop the MTA. I'm curious what the
> reaction to that would be, in both this specific and the general case.
> Is it a compromise that allows us to keep standard full of unix goodness
> while still catering to the desktop, or a greedy power grab?
> 
> (Other examples of the general case would be a Freedombox task that
> didn't install a MTA, since the freedombox devs have decided to use some
> other inter-user communication, IIRC -- or a specialized Debian Pure
> blend that chose to not install standard at all.)

It's quite common with embedded systems to only select Priority:
required and then a carefully hand-picked set of packages from anywhere
relevant in main. "Priority: standard", MTA, MUA, it really doesn't
matter in the slightest. If some things don't work, work around it or
find a package which does work. It's not worth worrying about and it's
not that specialised.

As part of this, Emdebian provides cut-down tasks which tasksel can use.
I see no reason why those would not be compliant with Policy just
because no MTA is included.

The problem with "Standard" is that it is currently (and heavily) biased
towards multi-user servers and most of the replies in this thread which
decry the absence of an MTA would appear to come from those principally
concerned with servers. It just doesn't fit with desktop users or
embedded users.

The test in Policy just seems wrong - in definition or in application
I really don't think it matters which. It appears to be based on an
assumption that an experienced sysadmin will connect to the box and
wonder where stuff has gone. That *must* be context-sensitive - many
routers are Unix / Linux - some may use .deb packaging systems (at
least in the programming stage). Nobody would expect those to have ALL
the packages from Priority: standard packages from the full Debian main
archive. Debian is just too fat for that.

Please, stop basing the judgement on MTAs on the use case of a
multi-user server.

Debian pushes itself as The Universal OS - our tests and assessments
must be Universal too.

The consensus here is clear - having an MTA as Priority: standard is
only useful to a subset of interested parties and it actively hinders
other subsets of interested parties. There needs to be another way of
doing this. If there is no sane default for a particular choice, the
choice needs to be retained and no default asserted (cribbed from the
debconf docs).

A no-op MTA is still not a useful choice for embedded systems.

Priority: standard doesn't currently match The Universal OS and - as
defined - never could.

The decision about whether some package is missing MUST be
context-sensitive. Context of usage, context of deployment, context of
access. If a device has no external connectivity it cannot possibly
matter that it does not have an MTA installed. It is still running
Debian and that use of Debian cannot possibly be considered as breaking
Debian Policy for that way lies madness. Next thing we'll have Policy
mandating that any device running Debian has to have an ethernet card.
Breaking news: many devices (including commercial machines currently on
sale for real money on the open market) are running Debian but have
never seen eth0 or friends but real people still want them and pay
good money for them - usually in preference to machines which do have
unnecessary hardware fitted. The one I'm thinking of also has no MTA and
has never needed one. Users don't miss it because there is no use case
for it on such machines. In fact, putting an MTA on such machines could
conceivably hurt sales.

About the only packages which most people truly would notice missing
are those with Essential: yes and an MTA is definitely, absolutely,
unthinkable in Essential. Even the list of packages in Essential is
context sensitive - Emdebian doesn't retain "Essential: yes", including
allowing systems which don't have apt or dpkg installed on the final
system, let alone stuff like adduser, netbase of libdb* [0]

Priority: Standard just doesn't matter any more. It is already
irrelevant to those who need to ignore it, like Emdebian. If we need to
adapt the tools to not care about Priority: standard and treat it as
Priority: optional then let's do that. The line between Priority:
optional and Priority: extra already appears largely arbitrary - more
useful where it is flouted than where it is followed.

While we're about it, lose Priority: optional, extra & standard 

Re: RFC: Making mail-transport-agent Priority: optional

[Josselin Mouette]

Le samedi 15 octobre 2011 à 10:50 -0300, Henrique de Moraes Holschuh a
écrit : 
> Well, if anything logs on emergency and alert levels, it is a bug if it is
> *not* important enough to pester all logged users immediately.   It is an
> even more clearcut case.

Let me ask the question otherwise: what kind of information do you think
is important enough to show to all logged users immediately?

Failing hardware? Depending on the setup you might want to warn a system
administrator rather than users, but that’s indeed a case to consider.
GNOME will warn you, for example, when your battery has been recalled. I
have yet to see such important information in the syslog.

System about to break down? Users will notice soon enough that it has
stopped working. Having a nice warning to tell them the computer is
falling into pieces doesn’t help much.

Security intrusion warning? In most cases it has to be routed to
appropriate people. Home users will ignore such alerts anyway.

What is the use case for such a feature?
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: RFC: Making mail-transport-agent Priority: optional

[Andreas Barth]

* Neil Williams (codeh...@debian.org) [111015 22:23]:
> The problem with "Standard" is that it is currently (and heavily) biased
> towards multi-user servers and most of the replies in this thread which
> decry the absence of an MTA would appear to come from those principally
> concerned with servers. It just doesn't fit with desktop users or
> embedded users.

"Standard" is just another word for "what someone expect so it's
considered as normal unix", which *is* a multi-user server.

Perhaps the task isn't named perfect, but that's just what standard
is.


> It appears to be based on an
> assumption that an experienced sysadmin will connect to the box and
> wonder where stuff has gone.

Oh yes, that's the definition.


> That *must* be context-sensitive - many
> routers are Unix / Linux - some may use .deb packaging systems (at
> least in the programming stage). Nobody would expect those to have ALL
> the packages from Priority: standard packages from the full Debian main
> archive. Debian is just too fat for that.

Nobody claims that. If you don't expect the standard unix things,
then don't install standard. End of story.


> The decision about whether some package is missing MUST be
> context-sensitive.

The only packages which are must are required.




Andi


-- 
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/20111015202956.gd15...@mails.so.argh.org

Re: RFC transitioning to gnutls28

[Josselin Mouette]

Le samedi 15 octobre 2011 à 17:52 +0200, Andreas Metzler a écrit : 
> gnutls28 (that is GnuTLS 3.x) has been available in experimental for
> quite some time. While the API breakage compared to gnutls26 (2.x) is
> not too bad

It doesn’t require large changes, but it can break in subtle ways. For
example, see https://bugzilla.gnome.org/show_bug.cgi?id=659233

Therefore I like the idea of using a different development package name.
OTOH it would be nice to push hard for its adoption.

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


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

Re: Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

Steve Langasek wrote:
> On Sat, Oct 15, 2011 at 06:53:02PM +0100, Ben Hutchings wrote:
> > > Hear, hear.  "How do I deliver mail?" is a per-system setting, not a
> > > per-application setting,
> 
> > It's not per-system, or even per-user.
> 
> > If I want to send mail from my personal address I should send it through
> > my own smarthost.  If I want to send mail from my work address I *must*
> > send it through the work smarthost (thanks to SPF).  I could possibly
> > configure this at the MTA level, but no other user should be allowed to
> > use my credentials to send mail through the work smarthost.
> 
> Needing to send mail through specific per-user smarthosts is the exception,
> not the rule.  Most machines have a designated forwarding smarthost based on
> who their ISP is, not based on which email address someone wants to use.

Every ISP mailserver I've seen, and for that matter almost every other
mailserver I've seen, requires SMTP AUTH to send mail; the SMTP AUTH
credentials vary by user.  And for that matter, while most of those
mailservers[1] will allow sending from email addresses other than the
one used for SMTP AUTH, many such servers *will* prohibit sending from
another address at the same domain/service, requiring you to SMTP AUTH
for that address instead.

- Josh Triplett

[1] Notable exception: gmail, which will silently change the from
address to the primary address on the account, unless the user has
proven they own the email address they want to send from.  Not a
crazy policy for a mail server where anyone can trivially obtain an
account for free, and thus banning someone for spamming just lets
them create another 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/20111015203923.GA25507@leaf

Re: RFC: Making mail-transport-agent Priority: optional

[Russ Allbery]

Josh Triplett  writes:
> Steve Langasek wrote:

>> Needing to send mail through specific per-user smarthosts is the
>> exception, not the rule.  Most machines have a designated forwarding
>> smarthost based on who their ISP is, not based on which email address
>> someone wants to use.

> Every ISP mailserver I've seen, and for that matter almost every other
> mailserver I've seen, requires SMTP AUTH to send mail; the SMTP AUTH
> credentials vary by user.  And for that matter, while most of those
> mailservers[1] will allow sending from email addresses other than the
> one used for SMTP AUTH, many such servers *will* prohibit sending from
> another address at the same domain/service, requiring you to SMTP AUTH
> for that address instead.

I agree with Josh here.  I think this is much more common than one might
think.  Getting people set up with an MUA that does authentication on
sending mail properly is something I've run into repeatedly when helping
users use Linux, and none of the MTAs really cut it.  I've set up
single-user Postfix installations that use the user's credentials to send
system mail, but it's a very uneasy and hard-to-maintain configuration.

-- 
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/87hb3aufg7@windlord.stanford.edu

Re: RFC: Making mail-transport-agent Priority: optional

[Neil Williams]

On Sat, 15 Oct 2011 22:29:56 +0200
Andreas Barth  wrote:

> * Neil Williams (codeh...@debian.org) [111015 22:23]:
> > The problem with "Standard" is that it is currently (and heavily) biased
> > towards multi-user servers and most of the replies in this thread which
> > decry the absence of an MTA would appear to come from those principally
> > concerned with servers. It just doesn't fit with desktop users or
> > embedded users.
> 
> "Standard" is just another word for "what someone expect so it's
> considered as normal unix", which *is* a multi-user server.
> 
> Perhaps the task isn't named perfect, but that's just what standard
> is.

If it was just a task used by tasksel, I'd be happy. The connotation of
Priority: standard in debian/control is somewhat different and, to me
at least, completely unnecessary.

tasksel doesn't need anything in the Packages file, so why do we still
retain Priority: in debian/control other than for Priority: required?
The list of standard packages could just live in /usr/share/tasksel/ -
only one place to change it.

Why is it anywhere else?

It would seem to make things a lot clearer for most people if
the Standard Task was not linked in any way to Priority: * in
debian/control.

> > It appears to be based on an
> > assumption that an experienced sysadmin will connect to the box and
> > wonder where stuff has gone.
> 
> Oh yes, that's the definition.

Then should it not be renamed "Server" instead of Standard? We already
have one of those, there's nothing to say that desktop cannot include
some packages / tasks which are also in server, laptops too. Standard
shouldn't be used in place of a shared task.

On that basis, we should not expect any tools to use this information
other than tasksel.

I think I'm going to have to put something on the Emdebian website
about *not* choosing "Standard" when using the new ISO images using
Debian Installer...

> > That *must* be context-sensitive - many
> > routers are Unix / Linux - some may use .deb packaging systems (at
> > least in the programming stage). Nobody would expect those to have ALL
> > the packages from Priority: standard packages from the full Debian main
> > archive. Debian is just too fat for that.
> 
> Nobody claims that. If you don't expect the standard unix things,
> then don't install standard. End of story.

For non-server tasks I don't. I think there is a reason to not have
server tasks in 'standard'. Quite why locales is considered to be in the
same task list as bind9 is beyond me.

It would be much more useful to be able to choose a task which brings
in locales, file and gettext without also bringing in bind9, exim and
kerberos IMHO.

I may look into that for Emdebian & Debian Installer too

-- 


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



pgpMp8EJHRvzS.pgp
Description: PGP signature

Re: Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

Andreas Barth wrote:
> * Neil Williams (codeh...@debian.org) [111015 22:23]:
> > The problem with "Standard" is that it is currently (and heavily) biased
> > towards multi-user servers and most of the replies in this thread which
> > decry the absence of an MTA would appear to come from those principally
> > concerned with servers. It just doesn't fit with desktop users or
> > embedded users.
> 
> "Standard" is just another word for "what someone expect so it's
> considered as normal unix", which *is* a multi-user server.
> 
> Perhaps the task isn't named perfect, but that's just what standard
> is.

The name doesn't matter.  What does matter: d-i installs standard by
default, unless you explicitly unselect it, and few users would think it
a good idea to deselect standard unless they'd already had experiences
like I had, namely "this contains several things I don't want, I'd
rather install what I want then remove what I don't".  And that only
works well for me because I've gone to the trouble of creating a set of
metapackages for myself which install exactly what I want; otherwise,
I'd probably just live with installing standard and combing aptitude
afterward for the half-dozen things I want to purge every time.

I think most packages in standard make perfect sense, not just for
multi-user UNIX servers but for any non-minimal Linux system.  Perfect
examples include: less (scrolling back in manpages is nice),
bash-completion (make the shell much more friendly), openssh-client,
reportbug, pciutils (lspci), file, locales.  These are tools burned into
people's finger memory, or which otherwise help people greatly even when
setting up a more complete system, or which people often use for
troubleshooting.  A Debian system without a decent amount of standard
installed proves rather painful to use.  Nonetheless, if you want to
install a truly minimal system and choose everything else yourself, you
need not install any of them.

So, I think having a standard set of packages installed by default but
deselectable in the installer makes sense.  On the other hand, tasksel
already has a task named "Mail Server", and that seems like the right
place to put an MTA, rather than standard.

- Josh Triplett


-- 
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/20111015210530.GA25566@leaf

Re: RFC: Making mail-transport-agent Priority: optional

[Russ Allbery]

Josselin Mouette  writes:

> Let me ask the question otherwise: what kind of information do you think
> is important enough to show to all logged users immediately?

If the system runs out of memory and starts up the OOM killer, it would be
nice to find some way to give the user a dialog to let them know that's
happening so that they could, for example, close a large application
rather than letting the semi-random OOM killer decide to take out the X
server or something.  (It may have gotten better.)

> Failing hardware? Depending on the setup you might want to warn a system
> administrator rather than users, but that’s indeed a case to consider.

That's the main one that I'd worry about.  Also overheating warnings, for
which even the home user can do something immediately.

-- 
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/878volvs0p@windlord.stanford.edu

Re: RFC transitioning to gnutls28

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:
> On Oct 15, Andreas Metzler  wrote:

>> * It uses nettle instead of gcrypt as crypto backend[1]. Packages that

> Why?

Does that fix the problems with using GnuTLS in setuid programs?

-- 
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/874nz9vrzx@windlord.stanford.edu

Re: RFC: Making mail-transport-agent Priority: optional

[Philipp Kern]

On 2011-10-15, Josh Triplett  wrote:
> MTAs would need to advance quite a bit to get anywhere near as usable as
> a MUA that speaks SMTP, not least of which in error reporting.  (Most of
> the people I know who run local MTAs have had at least one "all my mail
> got stuck in a queue for one or more weeks" story.)

Erhm, did you ever encounter a 5xx SMTP error message with, say, Icedove?

You don't want to be in that situation, really.  You want the MTA to accept
everything from the client and sending him a bounce to his mailbox because the
applications don't cope with it in a sane way neither.

(For the latter a little GUI tool would do.  Something like [0], which only
supports Exim, though.)

Kind regards
Philipp Kern

[0] 
http://opensource.fsmi.uni-karlsruhe.de/cgi-bin/gitweb.cgi?p=users/pkern/mail-queue-watch.git;a=summary


-- 
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/slrnj9k122.hgu.tr...@kelgar.0x539.de

Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

Joey Hess wrote:
> Josh Triplett wrote:
> > What would it take to make this change?
> > 
> > I will happily work to coordinate this transition.
> 
> For me this thread raises two interesting questions. The first is the one
> Josh asks above, which has not been answered. How do we make decisions
> about the content of standard? How can that decision process be improved?

In the past, for relatively uncontroversial cases, I've had some success simply
filing bugs against the packages in question.  See
http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;include=subject%3Apriority;submitter=josh%40joshtriplett.org
for some of them; note that all of those except procmail got addressed without
any particular objection.

However, something told me that I would not have the same success with
exim4 without starting a discussion on debian-devel first. :)

Improving the decision process does seem like a good idea; this
certainly isn't the last change I hope to make to the default set of
installed packages, though I suspect it's the most controversial. :)

> My other question comes from policy:
> 
>  `standard'
>   These packages provide a reasonably small but not too limited
>   character-mode system.  This is what will be installed by default
>   if the user doesn't select anything else.  It doesn't include
>   many large applications.
> 
> As I read this, it would be legal for tasksel, when the user selects the
> desktop task, to *not* install standard, or not all of standard. It
> could, for example, decide to drop the MTA. I'm curious what the
> reaction to that would be, in both this specific and the general case.
> Is it a compromise that allows us to keep standard full of unix goodness
> while still catering to the desktop, or a greedy power grab?

I think a strict reading of the sentence in policy allows the behavior
you describe.  However, it seems rather confusing to me to have tasksel
install *parts* of tasks rather than entire tasks, and I definitely
think a default install (regardless of other tasks installed) should
include almost all of what currently exists in standard.

I also don't think that saying "I don't want a GUI", or "I don't want
all the packages in the Desktop task", should necessarily mean "I want
an MTA".  That seems both confusing and incorrect.  I install plenty of
random systems with no GUI (such as research or scratch systems), and an
MTA makes even less sense on those than it would on my laptop.

So, I'd recommend against that approach.

- Josh Triplett


-- 
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/20111015215542.GA25813@leaf

Bug#645449: general: freezes on restore from suspend

[Jimmy Li]

Package: general
Severity: important

Using wheezy
radeon 5450 with nonfree installed
when restoring from suspend, I get a "split-screen" with half on top and half
underneath, very slow
when going to console, keep getting radeon restart messages
have to reset to recover



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20111015223257.3098.18647.report...@link.hsd1.ca.comcast.net

Re: aptitude weirdness wrt upgrades and keeps

[Norbert Preining]

On Sa, 15 Okt 2011, Josh Triplett wrote:
> quickly by using the "reject" and "approve" mechanism.  When you view

Thanks for that hint, yes, that works actually much better.
No I only have to remember it ;-)

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.
   --- Windows Error Haiku


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

Re: RFC: Making mail-transport-agent Priority: optional

[Don Armstrong]

On Sat, 15 Oct 2011, Simon McVittie wrote:
> On Fri, 14 Oct 2011 at 16:02:09 -0700, Don Armstrong wrote:
> > On Wed, 12 Oct 2011, Josh Triplett wrote:
> > > End-user systems (desktops, laptops) typically handle mail via one
> > > or more smarthosts elsewhere, driven by MUAs that know how to talk
> > > SMTP.
> > 
> > While this definitely is the current state, it's not optimal.
> 
> What's bad about it? What's better about sending through an MTA,
> particularly on a machine that basically only has one user?

Assume we are able to design things properly, with a single
configuration we get per-user mail and system-wide mail which is
capable of working in call cases, whether a user uses an MUA or uses
some webmail or whatever. It doesn't matter to the user if they switch
MUAs, and the MUA that they want to use doesn't necessarily need to
support whatever complicated authentication or sending scheme they
wish to use; it just works.[1]

> Credentials for authenticated SMTP are typically per-real-person
> anyway, so ideally you want per-user configuration.

Right; there should be a system-wide default configuration, and a
per-person configuration which overrides it (and possibly the option
for more complex rules based on From address or similar to handle
separate roles or something like that.)

> Sending through an MTA does let you press "send" without
> connectivity and have the mail server submit the mail eventually,
> but without any particularly useful feedback to the user (who can't
> easily distinguish between "mail got sent", "mail is still queued",
> and "an error occurred, the mail will never arrive").

Because of the way that SMTP is designed, users don't really ever know
this anyway... but a properly set up MTA does give at least limited
feedback.


Don Armstrong

1: I should note that I personally use a custom written nullmailer
plugin which uses ssh to connect to my central mail host and then run
/usr/lib/sendmail there... granted, that's probably a little bit
crazy, but it works great for my laptops which are often operating on
networks which try do all sorts of crazy things to outgoing mail. Some
people on this list are probably doing other similarly crazy things.
-- 
Clothes make the man. Naked people have little or no influence on
society.
 -- Mark Twain 

http://www.donarmstrong.com  http://rzlab.ucr.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/20111015225045.gd11...@rzlab.ucr.edu

Re: RFC: Making mail-transport-agent Priority: optional

[Faidon Liambotis]

On 10/15/11 22:06, Steve Langasek wrote:

Needing to send mail through specific per-user smarthosts is the exception,
not the rule.  Most machines have a designated forwarding smarthost based on
who their ISP is, not based on which email address someone wants to use.


The exception to which rule? In this part of the world, at least, people 
have been switching away from using their ISP's e-mail account and use 
webmail providers like Gmail instead.


So, if we're talking majorities here, then most desktops don't need an 
MTA (or an MUA talking SMTP...) in their system at all.


It's sad but (IMO) true.

Regards,
Faidon


--
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/4e9a025e.7020...@debian.org

Re: RFC: Making mail-transport-agent Priority: optional

[Don Armstrong]

On Sat, 15 Oct 2011, Ben Hutchings wrote:
> If I want to send mail from my personal address I should send it
> through my own smarthost. If I want to send mail from my work
> address I *must* send it through the work smarthost (thanks to SPF).
> I could possibly configure this at the MTA level, but no other user
> should be allowed to use my credentials to send mail through the
> work smarthost.

Right, so what would be ideal is if a transport-only MTA knew enough
to read ~/.config/mail to figure out that if it was executed as your
user, and you were sending with From: b...@work.org,[1] it should use
smtp.work.org with your specific configuration. Then, if you happened
to be sending using mailx to work, or needed to switch MUAs, it would
all "just work" correctly, without needing to manually configure
things again.
 
> For my own systems there is a reasonable system default of using my
> own smarthost, but I wouldn't expect most households to have that.
> Other people could use their ISP's smarthost. But in general, each
> member of a household might use a different mail service. Then what
> would be the system default?

Presumably, one would select one of them to be the system default,
which would also be the user default.
 

Don Armstrong

-- 
The carbon footprint of a single human being is enormous.
If you think about it, your honour,
I'm an environmentalist.
 -- a softer world #283
http://www.asofterworld.com/index.php?id=283

http://www.donarmstrong.com  http://rzlab.ucr.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/20111015230022.ge11...@rzlab.ucr.edu

Re: Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

Neil Williams wrote:
> On Sat, 15 Oct 2011 22:29:56 +0200
> Andreas Barth  wrote:
> > * Neil Williams (codeh...@debian.org) [111015 22:23]:
> > > The problem with "Standard" is that it is currently (and heavily) biased
> > > towards multi-user servers and most of the replies in this thread which
> > > decry the absence of an MTA would appear to come from those principally
> > > concerned with servers. It just doesn't fit with desktop users or
> > > embedded users.
> > 
> > "Standard" is just another word for "what someone expect so it's
> > considered as normal unix", which *is* a multi-user server.
> > 
> > Perhaps the task isn't named perfect, but that's just what standard
> > is.
> 
> If it was just a task used by tasksel, I'd be happy. The connotation of
> Priority: standard in debian/control is somewhat different and, to me
> at least, completely unnecessary.
> 
> tasksel doesn't need anything in the Packages file, so why do we still
> retain Priority: in debian/control other than for Priority: required?
> The list of standard packages could just live in /usr/share/tasksel/ -
> only one place to change it.
> 
> Why is it anywhere else?

As far as I know, Priority has the following non-cosmetic uses:
- d-i installs everything >= important by default.
- tasksel's standard task, selected by default in d-i, additionally
  installs packages with priority standard.
- The Debian CDs and DVDs sort packages by priority so that the earlier
  discs contain packages people will more likely want.  Given that we
  carefully try to ensure that standard plus the desktop task fits on
  the first disc, and standard fits on the netinst disc, this mostly
  means that priority optional comes before priority extra on the later
  discs, for people who use discs for something other than initial
  installation.
- Policy requires that packages not have dependencies of lower priority.
  As far as I know, this requirement exists primarily to support the
  previous point.

I don't know if Priority has any magic internal effects on the
dependency resolvers in apt and aptitude; for the purposes of the
discussion below I'll assume it doesn't.

Based on that, I do think we could reduce the number of distinctions in
Priority if we want to, without too much trouble.  The distinction
between required and important doesn't really matter since we have
"Essential: yes"; a quick search shows that everything with priority
required either has Essential: yes or forms part of the dependency chain
of an essential package.  (Oddly, the reverse doesn't hold, since apt
has priority important but Essential: yes; bug filed.)  The distinction
between optional and extra doesn't seem that critical either.

So, we could comfortably pare down Priority to three cases: important,
standard, and optional.  If, as you suggest, the task of determining the
contents of standard falls entirely to tasksel, then we could reduce to
just two priorities: important and optional.  The distinction between
required/important and standard does seem useful ("working system"
versus "default, comfortable system"), though occasionally I wish for
the option to truly install the bare minimum set of packages needed to
fetch more packages over the network.  (Arguably, the set of packages in
important could go elsewhere as well, since it just represents the set
of packages we consider too important to allow the user to deselect at
install time, such as packages needed for networking.)

> It would seem to make things a lot clearer for most people if
> the Standard Task was not linked in any way to Priority: * in
> debian/control.

Seems like a reasonable idea to me.  I do think the contents of a
standard install should not depend on a pile of individual priorities
set by package maintainers.

> > > It appears to be based on an
> > > assumption that an experienced sysadmin will connect to the box and
> > > wonder where stuff has gone.
> > 
> > Oh yes, that's the definition.
> 
> Then should it not be renamed "Server" instead of Standard? We already
> have one of those, there's nothing to say that desktop cannot include
> some packages / tasks which are also in server, laptops too. Standard
> shouldn't be used in place of a shared task.

Agreed.  Standard makes sense as a pile of tools which the system
doesn't need to function, but which fingers would stage an uprising
about if missing.  I'd suggest moving other things to "Mail Server",
"Web Server", "Traditional UNIX Server",etc.

(Also, I feel that programs which simply provide a command on $PATH, and
don't install a daemon, init script, or similar, matter very little.
They still seem worth caring about to reduce the size of the standard
install, but they have far less impact than daemons like exim.)

> I think I'm going to have to put something on the Emdebian website
> about *not* choosing "Standard" when using the new ISO images using
> Debian Installer...

Hopefully removing exim will help there, but I do suspect that Emdebian
wi

Re: RFC: Making mail-transport-agent Priority: optional

[Adam Borowski]

On Sun, Oct 16, 2011 at 12:59:58AM +0300, Faidon Liambotis wrote:
> On 10/15/11 22:06, Steve Langasek wrote:
> >Needing to send mail through specific per-user smarthosts is the exception,
> >not the rule.  Most machines have a designated forwarding smarthost based on
> >who their ISP is, not based on which email address someone wants to use.
> 
> The exception to which rule? In this part of the world, at least,
> people have been switching away from using their ISP's e-mail
> account and use webmail providers like Gmail instead.
> 
> So, if we're talking majorities here, then most desktops don't need
> an MTA (or an MUA talking SMTP...) in their system at all.

This is not about outside mail, it's about local mail that originates from
the system itself, cron jobs and so on.

And I seriously hope no one proposes to remove cron.

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Re: RFC: Making mail-transport-agent Priority: optional

[Russ Allbery]

Adam Borowski  writes:

> This is not about outside mail, it's about local mail that originates
> from the system itself, cron jobs and so on.

> And I seriously hope no one proposes to remove cron.

I think it's pretty obvious that we need some way of notifying people
about cron errors other than email.  Not only are there lots of problems
with figuring out how to get email to the local user of the box, but
increasingly new computer users aren't using email at all, or at least
very intermittantly, and are instead using other things (IM, social media,
etc.).  Email just isn't necessarily the center of the electronic
communications world the way that it used to be.

In a desktop world, I'd rather see some way that cron errors can be viewed
by a local account with appropriate permissions, combined with some sort
of notification scheme that's integral to the desktop rather than based on
the assumption that everyone reads mail.

(In a server world, of course, email continues to be a good mechanism for
reporting.)

-- 
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/87vcrpu91a@windlord.stanford.edu

Re: DEP-5 for Upstream

[Charles Plessy]

> Btw. when is the next debian-policy release that should include DEP-5.. and 
> therefore provide a good url for the VERSIONED_FORMAT_URL?

Dear Franz,

The final URL for DEP 5 is being decided in the following discussion:

  http://bugs.debian.org/640737

If nothing changes it will be 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Debian Developers who think that this URL is good and consensual can second the
proposition in the bug, and review the other issues opened for the DEP in the
debian-policy package.  Getting reviews and seconds is one of the current
bottlenecks.

  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy;include=subject%3Acopyright-format

I think that for version 1.0, the syntax is very unlikely to change.  We
reached a consensus that was not challenged for monthes and we have stable
and tested parsers.  So in the end, if you use an unversionned URL,
it will be fine.

The URL chosen in #640737 will probably available by the next upload of the
Policy, but that upload is decided taking other factors than the DEP into
account, so I can not give a timeline, as I am not a maintainer of the Policy.

Have a nice day,

-- 
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/20111015233224.gd3...@merveille.plessy.net

Re: Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

Philipp Kern wrote:
> On 2011-10-15, Josh Triplett  wrote:
> > MTAs would need to advance quite a bit to get anywhere near as usable as
> > a MUA that speaks SMTP, not least of which in error reporting.  (Most of
> > the people I know who run local MTAs have had at least one "all my mail
> > got stuck in a queue for one or more weeks" story.)
> 
> Erhm, did you ever encounter a 5xx SMTP error message with, say, Icedove?
> 
> You don't want to be in that situation, really.  You want the MTA to accept
> everything from the client and sending him a bounce to his mailbox because the
> applications don't cope with it in a sane way neither.

Consider the case of incorrect SMTP AUTH credentials, either because the
user failed the initial setup, or because they changed their password
and haven't yet remembered to update their client.  A MUA can give a
friendly error message, and point the user towards their username and
password.  An MTA will likely queue the mail and then never manage to
deliver it.

Using something like ssmtp or equivalent that talks to SMTP while
sendmail runs (and doesn't return successfully unless the mail gets
queued by the SMTP server) would solve part of that problems, but then
your MUA ends up reporting a much less friendly error message straight
from sendmail, and doesn't necessarily know how to help the user resolve
it.

Many other cases exist where the SMTP server knows it can't send the
mail, and can tell the client immediately.

- Josh Triplett


-- 
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/20111015231827.GA29239@leaf

Re: RFC: Making mail-transport-agent Priority: optional

[Russ Allbery]

Josh Triplett  writes:

> As far as I know, Priority has the following non-cosmetic uses:

[...]

A couple more:

One and only one conflicting alternative provider of a particular
exclusive API or interface may have priority higher than extra according
to Policy, so priority forces us to pick a "winner" among implementations
of the same thing that we recommend people use by default.

There's also the guarantee that all packages of priority optional or
higher can be coinstalled, although it's not entirely clear whether that
guarantee is useful to anyone.

> The distinction between optional and extra doesn't seem that critical
> either.

The distinction between optional and extra is mostly about conflicts, but
I also like having extra for things like debug packages or development
packages for libraries where it's rather unlikely that a user is going to
write code against that library.

To eliminate extra, we'd have to decide what we want to do about
conflicting packages and allow there to be mutually exclusive packages in
the optional set.  It also means we'd stop picking a recommended option
among the providers of a single interface if that interface isn't
important enough to be standard.

> The distinction between required/important and standard does seem useful
> ("working system" versus "default, comfortable system"), though
> occasionally I wish for the option to truly install the bare minimum set
> of packages needed to fetch more packages over the network.

To me, that bare minimum is what required should be, and where it might be
distinct from Essential (since Essential could exclude packages that
aren't required to boot the system but are required for networking and
network package installs).  Of course, I think it's somewhat questionable
that apt is in Essential, since one really only needs dpkg for a bare
minimal system.

>> It would seem to make things a lot clearer for most people if the
>> Standard Task was not linked in any way to Priority: * in
>> debian/control.

> Seems like a reasonable idea to me.  I do think the contents of a
> standard install should not depend on a pile of individual priorities
> set by package maintainers.

Well, strictly speaking, ftpmaster sets the priorities based on advice
from package maintainers, but yes.

I think package maintainers are best at determining optional vs. extra
(insofar as that distinction is useful) and somewhat less so for
determining optional vs. standard.  Beyond that, we probably need someone
with a more high-level view of the archive making a more overarching
analysis.

-- 
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/87r52du8mm@windlord.stanford.edu

Re: Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

Don Armstrong wrote:
> On Sat, 15 Oct 2011, Ben Hutchings wrote:
> > If I want to send mail from my personal address I should send it
> > through my own smarthost. If I want to send mail from my work
> > address I *must* send it through the work smarthost (thanks to SPF).
> > I could possibly configure this at the MTA level, but no other user
> > should be allowed to use my credentials to send mail through the
> > work smarthost.
> 
> Right, so what would be ideal is if a transport-only MTA knew enough
> to read ~/.config/mail to figure out that if it was executed as your
> user, and you were sending with From: b...@work.org,[1] it should use
> smtp.work.org with your specific configuration. Then, if you happened
> to be sending using mailx to work, or needed to switch MUAs, it would
> all "just work" correctly, without needing to manually configure
> things again.

That sounds like an interesting solution to make MTAs handle
configurations that MUAs currently handle just fine.

Alternative proposal: create a standard for storing SMTP (and IMAP)
server information in ~/.config/mail , and have MUAs standardize on that
location for storing email configuration (or at least have the option to
import/export that configuration).  MTAs could choose to read that
information too, if they have support for per-user configuration.

(Also note that some people want to use different MUAs for *different*
uses; at one point I used evolution for work mail and mutt for personal
mail.  So, teaching the system MTA about both doesn't help; it just
makes the configuration more complex.)

Either way, I don't think either of those proposals relates to whether
an MTA should appear in the default install.

You're suggesting that we should make MTAs capable of handling
configurations that MUAs currently handle just fine, *and* convince
users to use MTAs that way rather than configuring their MUA as usual,
and then keep MTAs in the default install in the hopes that users will
use them.

I'm suggesting that we should recognize that most users use
configurations that involve MUAs talking SMTP, without using MTAs, and
change our default install accordingly.

Debian Policy tries to be descriptive of current practice, rather than
prescriptively determining current practice.  Shouldn't standard operate
similarly, particularly given that we define it based on user
expectations?

> > For my own systems there is a reasonable system default of using my
> > own smarthost, but I wouldn't expect most households to have that.
> > Other people could use their ISP's smarthost. But in general, each
> > member of a household might use a different mail service. Then what
> > would be the system default?
> 
> Presumably, one would select one of them to be the system default,
> which would also be the user default.

And what if no sensible default exists, because none of them make sense
as the system default?  The configuration you describe either requires
allowing the system to send mail as one of the users, or giving the
system an email account of its own.  Neither one seems appealing.  I'd
argue that the system should not be sending external mail by default.

On a related note, consider that some users intentionally don't store
their email passwords, and instead type them every time their MUA
prompts for them (perhaps allowing it to remember them for the session
but not store them on disk).  That configuration works with MUAs, but
not with MTAs.  (Again, fixable, but already working with MUAs.)

- Josh Triplett


-- 
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/20111016003909.GA29905@leaf

Re: RFC: Making mail-transport-agent Priority: optional

[Josh Triplett]

Steve Langasek wrote:
> On Wed, Oct 12, 2011 at 08:34:52PM -0700, Josh Triplett wrote:
> > The main reasons to stop having an MTA in standard:
>
> > - Starting a daemon at boot time, which slows down booting.  This led me
> >   to notice the problem in Debian Live: it took a non-trivial amount of
> >   time for the boot process to finish starting exim and move on.
>
> Does Debian Live use insserv with parallel booting?  Granted, I/O is the
> bottleneck for booting from CD, so there's still going to be some impact;
> but on my systems (which all use postfix - so you can count me among the 20%
> of popcon users who have uninstalled exim to install postfix), MTA startup
> time is pretty small - on the order of 1.5s according to my bootcharts,
> which is hardly anything on the systems in question.

As far as I know, it uses insserv; I don't know if it uses parallel
booting or not.  I suspect it uses the default configuration, which
means it uses parallel booting.  However, even with parallel booting,
the login prompt does not become available until all the init scripts
finish.  exim4 took several seconds to start, and the login prompt did
not appear until it finished.

I was booting from a USB disk, and not a particularly fast one, which
may have contributed to how long exim took.  I can say that it took a
nontrivial fraction of the total boot time.

On the flipside, getting to the point where the system only takes a
couple of seconds to boot means eliminating everything unnecessary.

> > - Listening on ports by default, which exposes the system to any
> >   potential vulnerabilities, as well as potentially allowing the sending
> >   of spam.  I've checked, and out of all the packages with priority
> >   standard or above, only exim and isc-dhcp-client listen on ports by
> >   default.  Removing an MTA significantly reduces the attack surface of
> >   a default Debian system.
>
> Running an MTA does not imply accepting mail from outside the machine for
> delivery.  We could address this by configuring our standard MTA to only
> accept from localhost by default, or to only accept submissions via
> /usr/sbin/sendmail by default.

If the MTA didn't listen on any ports by default (localhost or
otherwise), only accepted submissions via sendmail, and didn't run a
daemon, then I'd care a lot less about getting it out of standard.

> > - Asking configuration questions via debconf at install time, which
> >   increases the amount of work and complexity required to install
> >   Debian.  For most users, these questions will duplicate the process
> >   they later go through to configure their MUA.
>
> That's absolutely a bug in the MUAs for requiring additional configuration
> instead of working with the default.

I've already found out via this thread that exim4 now defaults to
local-only delivery, and asks no questions at startup, so feel free to
ignore this point.

> > - Taking time to download and install, which increases the time and
> >   bandwidth needed to install or upgrade a Debian system.
>
> I think you're reaching with this one.

The primary bottleneck when installing Debian consists of waiting for a
large number of packages to download and install.  Making that process
take less time, multiplied across the huge number of people installing
Debian, seems worth it.  This holds particularly true for slower
Internet connections.

> > - Running a daemon all the time, which takes up RAM.
>
> You're worried about this on a desktop system running firefox?

So we should make it that much worse for everyone?  Every bit of RAM
used by a program represents that much less disk cache.  Plenty of
people work on making Firefox and other programs use less RAM; let's not
contribute to the problem.

Also, exim4, as a daemon that doesn't wake up often, is a pretty
good candidate for swapping out, which makes for that much more of a
performance hit when it needs to swap back in.

(Oh, and one reason I forgot: waking up periodically also makes systems
use marginally more power.)

> Your proposed benefits become more outlandish from there, so 

I listed every reason I could think of here, rather than pruning at the
point where I felt it already far outweighed the cost of requiring mail
server administrators to type one command to install a mail server.

- Josh Triplett


-- 
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/20111016004513.GA29963@leaf

Re: RFC: Making mail-transport-agent Priority: optional

[Ben Hutchings]

On Sat, 2011-10-15 at 14:55 -0700, Russ Allbery wrote:
> Josselin Mouette  writes:
> 
> > Let me ask the question otherwise: what kind of information do you think
> > is important enough to show to all logged users immediately?
> 
> If the system runs out of memory and starts up the OOM killer, it would be
> nice to find some way to give the user a dialog to let them know that's
> happening so that they could, for example, close a large application
> rather than letting the semi-random OOM killer decide to take out the X
> server or something.  (It may have gotten better.)
> 
> > Failing hardware? Depending on the setup you might want to warn a system
> > administrator rather than users, but that’s indeed a case to consider.
> 
> That's the main one that I'd worry about.  Also overheating warnings, for
> which even the home user can do something immediately.

The user generally can't even read the warning in time to make a
decision; the system must handle OOM or over-temperature quickly.

However, the user should be notified about that decision, if possible.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner


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

Periodic automake cleanup: removal of automake1.7

[Eric Dorland]

As has become custom, it's time for removal of another old automake
version. This round it's automake 1.7's turn. 

Below is a list of packages that build depend on
automake1.7. Please fix them by:

1. Not build depending on automake in the first place. It may be
completely unnecessary, or you can ship the generated Makefile.in's in
the diff.gz. You will never have to deal with these transition
problems again.

2. Upgrade to the latest version of automake, automake1.11, to stave
off obsolescence.

3. Using dh-autoreconf.

In a couple of weeks I will be filing wishlist bugs with patches to
remove the automake1.7. Probably about a month after that I will start
NMUing any packages who haven't acted on the bugs. Then I will ask for
automake1.7's removal. Thanks in advance for your help.


W. Martin Borgert 
   snacc
   snacc (U)

Jan-Michael Brummer 
   isdnutils (U)

Debian Accessibility Team 
   dots

Debian Games Team 
   burgerspace
   kobodeluxe

Debian Lustre Packaging team

   lustre

Debian Maemo Maintainers

   hildon-theme-tools

Dirk Eddelbuettel 
   quantlib

Rene Engelhard 
   libtextcat

Debian QA Group 
   apachetop
   quiteinsanegimpplugin

Damyan Ivanov 
   kobodeluxe (U)

Noèl Köthe 
   lustre (U)

Jonny Lamb 
   hildon-theme-tools (U)

Rolf Leggewie 
   isdnutils

John Lines 
   plptools

Loic Minier 
   hildon-theme-tools (U)

Masahito Omote 
   sary

Michael Piefel 
   snacc (U)

Ari Pollak 
   libsdl-sound1.2

Tomas Pospisek 
   mailsync

Samuel Thibault 
   dots (U)

Riku Voipio 
   hildon-theme-tools (U)

Patrick Winnertz 
   lustre (U)


-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com



signature.asc
Description: Digital signature

Re: Periodic automake cleanup: removal of automake1.7

[Paul Wise]

On Sun, Oct 16, 2011 at 10:20 AM, Eric Dorland wrote:

> As has become custom, it's time for removal of another old automake
> version. This round it's automake 1.7's turn.

Shouldn't automake1.4 be first in the queue?

> Debian QA Group 
>   apachetop

Made a QA upload of this.

> quiteinsanegimpplugin

Probably this can be removed since it is dead upstream and xsane seems
to have a GIMP plugin.

-- 
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/CAKTje6GvAk35gObCk=8ru-ntfxkmfnetwioxyqfna1mxulg...@mail.gmail.com

Re: Periodic automake cleanup: removal of automake1.7

[Eric Dorland]

* Paul Wise (p...@debian.org) wrote:
> On Sun, Oct 16, 2011 at 10:20 AM, Eric Dorland wrote:
> 
> > As has become custom, it's time for removal of another old automake
> > version. This round it's automake 1.7's turn.
> 
> Shouldn't automake1.4 be first in the queue?

We could do automake1.4. I hesitate because there may still be older
software out there that wants automake 1.4's particular set of
quirks. What do other people think?

> > Debian QA Group 
> >   apachetop
> 
> Made a QA upload of this.

Thanks!

> > quiteinsanegimpplugin
> 
> Probably this can be removed since it is dead upstream and xsane seems
> to have a GIMP plugin.
> 

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com



signature.asc
Description: Digital signature