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

[Simon McVittie]

On Sat, 15 Oct 2011 at 13:23:00 +0200, Adam Borowski wrote:
> Do you mean [...] 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).

When you say "GNOME 3" are you thinking of Unity, Ubuntu's ironically-named
GNOME 3 competitor? This sounds like a description of the Messaging Menu
in Unity.

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/20111017074221.ga30...@reptile.pseudorandom.co.uk

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

[Simon McVittie]

On Sun, 16 Oct 2011 at 16:09:50 +0100, Roger Lynn wrote:
> On 15/10/11 22:00, Josh Triplett wrote:
> > 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.
> 
> I don't believe this is usually the case in the UK. Most mailservers
> (both in ISPs and elsewhere) will usually allow unauthenticated
> connections from machines connected to their networks. Only if they
> allow users to send mail from elsewhere will they require SMTP AUTH.

... so on a typical laptop, you need to remember to set up SMTP AUTH if
you will ever send mail from not-your-house (e.g. a public wifi or 3G
connection).

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/20111017075002.gb30...@reptile.pseudorandom.co.uk

MUA's vs. local mail

[Ivan Shmakov]

> Henrique de Moraes Holschuh  writes:

[…]

 > I do know many of the GUI MUAs are incomplete jack-jobs that fail to
 > add a handler for local system folders (i.e. were only partially
 > ported to Linux).  I am not sure which would be the better aproach to
 > deal with this deficiency.

Recommends: dovecot-imapd, and let the MUA's use imap://[::1]/
by default?

Please also note that dovecot-imapd is perfectly runnable even
without special privileges, and even without a real network
socket (a pipe is just fine.)  In particular, my Gnus/Emacs
setup has the following server's definition:

(nnimap "Maildir"
(nnimap-stream shell)
;; FIXME: use nnimap-shell-program here
(imap-shell-program
 ("MAIL=maildir:\"$HOME\"/Maildir /usr/lib/dovecot/imap")))

That way, Gnus is also unaware of my system's password.

Contrary to having a MUA access local mail directly, Dovecot
will cache certain headers, thus allowing the list of messages
to be prepared rather quickly.  For the larger mailboxes, there
may be a really huge difference between using Maildir + Dovecot
vs. a MUA that accesses a Unix mbox file directly.

-- 
FSF associate member #7257


-- 
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/86zkh0vv1k.fsf...@gray.siamics.net

Re: ITP: wolf4sdl -- SDL-Port of Wolfenstein 3-D and Spear of Destiny

[Fabian Greffrath]

I have prepared a new package of upstream SVN snapshot r262 that 
replaces the non-free MAME OPL2 emulator with a GPL'ed one from 
DOSBOX. Furthermore, I got a confirmation email by John Carmack 
himself of iD software stating that the original Wolf3d source code 
has been relicensed under the GPL. Thus, the whole package is under 
GPL now!


I am still looking for a sponsor/co-maintainer. Please find the 
package here


 http://debian.greffrath.com/unstable/wolf4sdl_1.7%2bsvn262%2bdfsg1-1.dsc

and here

 http://anonscm.debian.org/gitweb/?p=pkg-games/wolf4sdl.git;a=summary


 - Fabian


--
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/4e9bf87f.2050...@greffrath.com

Re: Periodic automake cleanup: removal of automake1.7 [and 1 more messages]

[Ian Jackson]

Eric Dorland writes ("Re: Periodic automake cleanup: removal of automake1.7"):
> The versions after 1.4 were where backwards-incompatible changes
> started showing up. As a very unscientific census using google code
> search, there are about 36,800 Makefile.in's generated by automake 1.4
> on the web, versus 113,000 generated by automake 1.6 and later.

This is a good reason to keep 1.4, at least for now and perhaps
indefinitely.

Michael Biebl writes ("Re: Periodic automake cleanup: removal of automake1.7"):
> I don't think we should be advocating the usage of automake 1.4 by
> shipping it in out next stable release. [...]

Shipping an older version of a tool like automake is not "advocating
[its] usage".  It's making life less difficult for people who still
need it.

I don't imagine it takes much maintenance but of course I'm not saying
that someone else ought to do the work.  If the existing maintainer
wants to get rid of automake1.4, I would be happy to take it over to
keep it in the archive.

Ian.


-- 
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/20124.6605.27897.220...@chiark.greenend.org.uk

Bug#645621: ITP: libnet-ssh-perl-perl -- Perl module implementing a Perl client interface to SSH

[Salvatore Bonaccorso]

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

* Package name: libnet-ssh-perl-perl
  Version : 1.34
  Upstream Author : David Robins 
* URL : http://search.cpan.org/dist/Net-SSH-Perl/
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : Perl module implementing a Perl client interface to SSH

Net::SSH::Perl is an all-Perl module implementing an SSH (Secure Shell)
client. It is compatible with both the SSH-1 and SSH-2 protocols.

Net::SSH::Perl enables you to simply and securely execute commands on remote
machines, and receive the STDOUT, STDERR, and exit status of that remote
command. It contains built-in support for various methods of authenticating
with the server (password authentication, RSA challenge-response
authentication, etc.). It completely implements the I/O buffering, packet
transport, and user authentication layers of the SSH protocol, and makes use
of external Perl libraries (in the Crypt:: family of modules) to handle
encryption of all data sent across the insecure network. It can also read
your existing SSH configuration files (/etc/ssh_config, etc.), RSA identity
files, DSA identity files, known hosts files, etc.

This module is needed as dependency for libvirt-tck (#645059) testsuite.



-- 
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/1318856315.198900.10098@elende

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

[Luca Capello]

Hi there!

Disclaimer: I am not an SMTP expert.

On Sun, 16 Oct 2011 21:37:59 +0200, Josh Triplett wrote:
> Andrea Bolognani wrote:
>> The proxy one needs to go through to access the Internet from inside my
>> University buildings cuts off SMTP.
>
> Have you checked to see if it blocks SMTPS, or the submission port?
> The latter often gets through when port 25 won't, and SMTPS almost
> always works.

Andrea, if you need to ask, please do for the submission port [1][2]
with STARTTLS.  AFAIK there is no sense for SMTPS nowadays, and the fact
that port 465 has been assigned to something else [3] and that some MTA
do not support it are signs already in disfavor of SMTPS [4][5].

[1] 
[2] 
[3] 
[4] 
[5] 

Thx, bye,
Gismo / Luca


pgpBl6yEMdHyZ.pgp
Description: PGP signature

Tasksel's "standard" task (was: RFC: Making mail-transport-agent Priority: optional)

[Luca Capello]

Hi there!

On Sun, 16 Oct 2011 00:48:11 +0200, Josh Triplett wrote:
> 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.

It seems there is *no* tasksel's standard task:
=
luca@gismo:~$ tasksel --list
u desktop   Debian desktop environment
u web-serverWeb server
u print-server  Print server
u database-server   SQL database
u dns-serverDNS Server
u file-server   File server
u mail-server   Mail server
u ssh-serverSSH server
u laptopLaptop
u manualmanual package selection

luca@gismo:~$ apt-cache policy tasksel
tasksel:
  Installed: 3.05
  Candidate: 3.05
  Version table:
 *** 3.05 0
990 http://cdn.debian.net/debian/ sid/main amd64 Packages
100 /var/lib/dpkg/status

luca@gismo:~$ 
=

So I stand corrected by myself for the installation tests I did last
week [1].  And in this vision, what d-i shows as a tasksel's "standard"
tasks is actually not a tasksel's task at all.  Is this a bug?

[1] 

Thx, bye,
Gismo / Luca


pgpiZW9uEn9xJ.pgp
Description: PGP signature

Advocating the use of RDF for Debian's published metadata - Was: Re: Proposal for additional metadata in Debian archives (DEP-11)

[Olivier Berger]

Hi.

I'm not subscribed to ftpmasters, so feel free to CC me in response, and
I hope d-d@l.d.o is the proper place it will be debated, then (even
thouh -project already holds some bits too).

Le vendredi 14 octobre 2011 à 19:08 +0200, Matthias Klumpp a écrit :

> AppStream features XML to store metadata. Because we don't use XML
> somewhere in Debian, DEP-11 features a well-known RFC822-style format.

May I suggest to implement some (standardized) variant of RDF [0] to
represent this meta-data ? 


I think it would help here, to adopt standards for more interoperability
of Debian's metadata with others'. 
The "package metadata" could even be delivered on the Web of Data
(Linked Open Data), right from the Debian servers, to allow any
application to be created, that would consume such metadata.

If RDF/XML (as seems to be proposed by SPDX, to be verified once the
Linux Foundation site is back) is not suitable, then another format
would be great as long as it relies on some explicit prefix+suffix
combination, in order to allow for extensibility, for instance some JSON
variant of RDF like Turtle [1].

If a package can both be described with some generic purpose
"ontology"/standard/schema (for instance the one you envisioned
initially in DEP 11), and also, depending on context (embedded or
science, for instance) with another set of metadata (spdx or whatever
else), you'd be able to mix in the same file, metadata relating to
different contexts.

Still, I'm not sure RFC822-style is perfectly compliant with the habit
of RDF to separate prefix and suffix with a column character ':'. Maybe
'_' could act as such a separator (must say I haven't checked the RFC
for allowed tokens in the grammar) ?

Let's try with an example (btw, the DEP
http://wiki.debian.org/AppStreamDebianProposal *lacks* examples IMHO) :

In turtle representation format for RDF, one would have a document that
looks like this :
@prefix rdf: .
@prefix dep11: .
@prefix debbugs: .
@prefix spdx: .

 
  a dep11:DebianPackage;
  dep11:application "Iceweasel";
  dep11:package "iceweasel";
  spdx:license "MPL-1.1"
  debbugs:bugs .

(Maybe I didn't understand very well the Application and Package
meanings in your DEP11 proposal, btw.)

Anyway, as you can see, here we could have several "domains" of metadata
sources (ontologies / prefixes) to describe the same package combined in
a single document.

In RFC822-style, this could be something like :

DEP11_Application: Iceweasel
DEP11_Package: iceweasel
spdx_license: MPL-1.1
debbugs_bugs: http://bugs.debian.org/iceweasel

etc.

But clearly, not reinventing the wheel should be a goal, and adopting
existing standards for meta-data representation would be my choice, i.e.
Semantic Web standards (namely RDF).


Of course, translators from/to different syntaxes will be trivial to
develop, but if, from the source, a proper standard is used, it can be
readily delivered to the Web without any transformation needed. Such an
approach (often called Linked Data), clearly favors interoperability
(more at http://linkeddata.org/guides-and-tutorials if I failed to make
my point).


Again, in case you'd doubt it, RDF is just a model, which can be written
in a number of different formats (not only XML), but the key here is the
embedded identification of the reference of the ontologies/prefixes
which render the documents self described and extensible, out of the
box.

Note that the same rationale stands for all metadata to be eventually
published on the Web by Debian servers.

Hope this helps.

Best regards,

[0] http://www.w3.org/RDF/
[1] http://www.w3.org/TeamSubmission/turtle/
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
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/1318865495.3675.36.ca...@inf-8657.int-evry.fr

Re: / vs. /usr vs. fsck(8)

[Luca Capello]

Hi there!

On Thu, 13 Oct 2011 14:15:43 +0200, Ben Hutchings wrote:
> On Thu, 2011-10-13 at 11:19 +0200, Luca Capello wrote:
>> On Wed, 12 Oct 2011 21:24:33 +0200, Marco d'Itri wrote:
>> > The Debian initramfs of my sid system is 10 MB, while the one from my
>> > RHEL 6.1 servers is 12 MB. So there is no big difference here.
>> 
>> I checked my systems and found out something strange about initrd sizes,
>> all with MODULES=most in /etc/initramfs-tools/initramfs.conf:
[...]
>> On my sid, using MODULES=dep I get 4062599 for 3.1.0-rc7-amd64, which is
>> practically no different from MODULES=most.  Considering that my sid is
>> full-disk encrypted, there is something odd, here.
>
> I think you're mistaken about those last few.  MODULES=most still
> results in a ~10 MB initramfs on x86.

This is exactly why I updated my initrd for 3.1.0-rc7-amd64 before
posting the results above and I still get the same number if I create a
new one.  I finally found the problem:
=
root@gismo:/boot# cat /etc/initramfs-tools/conf.d/driver-policy
# Driver inclusion policy selected during installation
# Note: this setting overrides the value set in the file
# /etc/initramfs-tools/initramfs.conf
MODULES=dep

root@gismo:/boot#
=

Indeed I was not aware that /e/i-t/conf.d/ options take precedence over
/e/i-t/initramfs.conf.  From `man initramfs.conf` (which BTW erroneously
refers to /etc/mkinitramfs):

--8<---cut here---start->8---
  DESCRIPTION
  [...]
Configuration options  can be broken out  into configuration
snippets   and   placed   in   individual   files   in   the
/etc/mkinitramfs/conf.d directory.  Files  in this directory
are always  read after the  main configuration file,  so you
can override  the settings in  the main config  file without
editing it directly.
--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca


pgpB6y4b0t75L.pgp
Description: PGP signature

Re: Tasksel's "standard" task (was: RFC: Making mail-transport-agent Priority: optional)

[Neil Williams]

On Mon, 17 Oct 2011 16:55:09 +0200
Luca Capello  wrote:

> On Sun, 16 Oct 2011 00:48:11 +0200, Josh Triplett wrote:
> > 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.
> 
> It seems there is *no* tasksel's standard task:

Hmm, thanks for checking, Luca.

> So I stand corrected by myself for the installation tests I did last
> week [1].  And in this vision, what d-i shows as a tasksel's "standard"
> tasks is actually not a tasksel's task at all.  Is this a bug?

I suspect it's tasksel or d-i doing stuff on the Priority:, so maybe
it's time to export that list from Priority: into a dedicated task.

Is there any other reason to have Priority: standard in debian/control?

In that process, the actual packages can be moved around and it would
make it easier for people like Emdebian to provide a replacement
standard task.

-- 


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



pgpRe25zW0ToT.pgp
Description: PGP signature

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

[Luca Capello]

Hi there!

Just some small notes without re-iterating what other people already
wrote in this (now too-long) thread.

On Sat, 15 Oct 2011 10:26:06 +0200, Jonas Meurer wrote:
> 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.
[...]
> 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.

I think that the real question is: how much should Debian GNU/Linux
mimic a standard UNIX system by default?

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

I do not see why a system with a lot of daemons should not be considered
easy or, IOW, the two things are not mutually self-exclusive.

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

As Steve already pointed out [1], there is user-friendly software bigger
and more memory-eater than MTAs.  I run Postfix on my laptop [2] and
have no problem using it [my laptop] for ~3h on battery, but as soon as
I start XULrunner everything changes [3] (and I do not use any fancy DE,
simply ratpoison, screen and Emacs).

[1] 
[2] except for the SSD, my laptop is "old" (mostly 5-year-old)

[3] 

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

Just to be clear as well: I am not.

Thx, bye,
Gismo / Luca


pgpxUfyWt9rt8.pgp
Description: PGP signature

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

[Josselin Mouette]

Le dimanche 16 octobre 2011 à 02:41 +0100, Ben Hutchings a écrit : 
> > 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.

Actually some cases of overheating have to be handled by hardware, since
CPUs can heat so quickly (e.g. in case of a detached cooler) they will
be damaged before they can even switch states. For HDDs or some other
pieces, it would still be interesting.

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

Agreed. It would be nice to have a kernel interface to be notified of
such things, since the syslog sounds like a poor way of doing it.

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


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

Bug#645683: ITP: xul-ext-imkbizle -- Parses 3. party web sites to retrieve IMKB100 stock data

[Bekir Dogan]

Package: wnpp
Severity: wishlist
Owner: Erhan Kesken 

* Package name: xul-ext-imkbizle
  Version : 2.4
  Upstream Author : Erhan Kesken 
* URL : http://code.google.com/p/imkbizle/
https://addons.mozilla.org/en-US/firefox/addon/imkbizle/
* License : GPL3
  Programming Lang: XUL & Javascript
  Description : Parses 3. party web sites to retrieve IMKB100 stock data

Shows latest Istanbul Stock Exchange XU100 (IMKB100) values of selected stock
on iceweasel statusbar and shows detailed statistics on tool tip text.

--
/ekesken



-- 
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/20111017192456.15368.21470.report...@hede.bdgn.net

Bug#645700: RFP: civicrm -- contact and relationship management system for community and advocacy groups

[Ben Finney]

Package: wnpp
Severity: wishlist

* Package name: civicrm
  Version : 4.0
  Upstream Author : CiviCRM LLC
* URL or Web page : http://civicrm.org/
* License : GNU AGPL-3
  Description : contact and relationship management system for community 
and advocacy groups

CiviCRM is a Contact and Relationship Manager designed specifically to
meet the needs of advocacy, non-profit, and non-governmental groups.
.
Many optional components provide additiona integrated functionality:
* Case management for clients and constituents.
* Online fundraising and donor management.
* Online event registration and participant tracking.
* Online signup and membership management.
* Personalized email campaigns and newsletters.
* Report generation and template management.

-- 
 \   “We have clumsy, sputtering, inefficient brains…. It is a |
  `\ *struggle* to be rational and objective, and failures are not |
_o__) evidence for an alternative reality.” —Paul Z. Myers, 2010-10-14 |
Ben Finney 



--
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/87sjmr6yy9@benfinney.id.au

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

[brian m. carlson]

On Mon, Oct 17, 2011 at 07:20:54PM +0200, Luca Capello wrote:
> I think that the real question is: how much should Debian GNU/Linux
> mimic a standard UNIX system by default?

I think this is the real question.  If standard is a default Unix
system, then it needs to have an MTA.  I believe this even though I do
not use an MTA on most of my systems (and I always use something other
than Exim).  I'd also like to point out that if we don't ship an MTA in
standard, we should also not ship nfs-common, rpcbind, or libtirpc since
NFS is used even less often than an MTA and the same rationale for not
installing it applies.

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

[Clint Adams]

On Tue, Oct 18, 2011 at 12:26:12AM +, brian m. carlson wrote:
> standard, we should also not ship nfs-common, rpcbind, or libtirpc since
> NFS is used even less often than an MTA and the same rationale for not
> installing it applies.

Those seem like reasonable things to drop, though I don't think any of
those are likely to fill /var up with emails that most users will never
read or even be aware of.


-- 
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/20111018035923.ga24...@scru.org

Bug#645723: general: asks for root password instead of user password

[Jimmy Li]

Package: general
Severity: important

Apparently, anything that needs root asks for the root password instead of my
user password. Apparently, it's using su instead of sudo. Just a moment ago, I
had to manually re-add myself to the sudo group. Now sudo works, but all
applications still ask for the root password instead of the user password.
Also, I get "You are not allowed to modify the system configuration."



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

Bug#645723: marked as done (general: asks for root password instead of user password)

[Debian Bug Tracking System]

Your message dated Tue, 18 Oct 2011 00:56:15 -0500
with message-id <20111018055615.ga18...@elie.hsd1.il.comcast.net>
and subject line Re: general: asks for root password instead of user password
has caused the Debian Bug report #645723,
regarding general: asks for root password instead of user password
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
645723: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645723
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important

Apparently, anything that needs root asks for the root password instead of my
user password. Apparently, it's using su instead of sudo. Just a moment ago, I
had to manually re-add myself to the sudo group. Now sudo works, but all
applications still ask for the root password instead of the user password.
Also, I get "You are not allowed to modify the system configuration."



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


--- End Message ---
--- Begin Message ---
Hi Jimmy!

Jimmy Li wrote:

> Apparently, anything that needs root asks for the root password instead of my
> user password. Apparently, it's using su instead of sudo.

Please file this against whatever package you are referring to by "anything".

Sorry for the trouble, and good luck,
Jonathan

--- End Message ---