Re: add information on what was adopted to the WNPP report?

[Martin Michlmayr]

* Paul Wise  [2009-11-13 09:42]:
> > Total number of orphaned packages: 683 (new: 20)
> > Total number of packages offered up for adoption: 147 (new: 0)
> > Total number of packages requested help for: 53 (new: 0)
> 
> This is kinda depressing, it would be nice to see information on what
> was adopted in the WNPP report.

afaik this script is not actively maintained but it's in SVN so you
can give it a go.
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: common, FHS-compliant, default document root for the various web servers

[Stefano Zacchiroli]

Sorry for the delay in replying to this. I've just re-read all the
disagreements with the original proposal and they all seem to be related
to this main counter-argument by Sean, hence I'll reply here.

On Mon, Nov 09, 2009 at 11:50:11PM +0100, sean finney wrote:
> > FWIW, I'm fine with /vendor.
> 
> personally, beyond the aesthetically displeasing name, i'm really
> skeptical that this will accomplish anything useful.
> 
> * most apps require extra config and splitting out of stuff into other
>   directories for fhs compliance anyway, thus requiring some level of
>   webserver configuration, meaning this adds no benefit (beyond 1 line
>   fewer in the server config).
> * this encourages a "working in unconfigured state" for packages, which
>   seems very sketchy wrt security (similarly, to apps dropping random
>   publically executable scripts in /usr/lib/cgi-bin.

I understand this problem, but I think you're shooting at the wrong
target. The advanced proposal (beside the aesthetically displeasing
name) is about standardizing a default vendor document root on disk so
that packages can install content in it, as well as defining a base URL
that maps to it.

Inherently, such a proposal applies to static content, not CGI
applications. I fail to see where lay problems about unconfigured static
content.

So, regarding your "working in unconfigured state" I think we should
rather just be clear that CGI should not be enabled by default, if this
is actually a concern. Personally, while I understand it, I wouldn't
like carving that in stone: maintainers should be free to decide whether
their applications have a sane default that enable apps to work out of
the box or not. I easily see both apps that can work without any conf
(e.g. CGI-based doc browsers for the local machine) and apps that would
forcibly require conf (e.g. multi-intance blog engines or other
webapps).

All in all, I don't see why adding a default root for static content
make things worse wrt your problems.

A couple of other misc remarks:

- Stating that those defaults should be enabled only for the localhost
  virtual host will help a lot. For web servers with no virtual host
  support we can simply state that they should not have the proposed
  vendor document root enabled by default.

- We already have a de facto default vendor dir rooted at /doc/, why
  should this be a special case? Implementing the advanced proposal
  would enable generalizing that unfortunate ad-hoc case.

Of course, thanks to all the participants for their feedback!
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: RFC: RelaxNG and XML schema schemes packaged for Debian

[Daniel Leidert]

Am Donnerstag, den 12.11.2009, 15:14 +0100 schrieb Bastien ROUCARIES:
> Le jeudi 12 novembre 2009 14:18:51, Daniel Leidert a écrit :
> > Am Mittwoch, den 11.11.2009, 22:57 +0100 schrieb Samuel Thibault:
> > > Daniel Leidert, le Wed 11 Nov 2009 17:36:05 +0100, a écrit :
> > > > A question: I'm currently working with relaxNG and found, that we
> > > > (Debian) AFAIK don't have the schemes for RNG [1] or XSD [2] packaged.
> > >
> > > I don't know very much about relaxNG, but I guess you could be
> > > interested in the isorelax and jing packages.  Don't hesitate to help
> > > maintaining them :)
> > 
> > We were already talking about this when jing-trang was in NEW; you
> > remember :) ? But I currently maintain around 50 source packages. So I
> > would like to see some new maintainers interested in XML to step in. The
> > XML/SGML group is currently pretty small.
> 
> I have an interest in xml. I could join after my phd defence (aka after 
> november the 27th).

Any help is appreciated. Some packages are spread over the Debian
community (like jing/trang) and some are collected under the hat of the
Debian XML/SGML group:

http://debian-xml-sgml.alioth.debian.org/
http://alioth.debian.org/projects/debian-xml-sgml
http://svn.debian.org/wsvn/debian-xml-sgml
http://git.debian.org/ (debian-xml-sgml/...)
http://qa.debian.org/developer.php?login=debian-xml-sgml-p...@lists.alioth.debian.org

There are also some orphaned docbook* packages. If you are interested in
XML/SGML please check, which packages might be of interest for you or
where you can/want to help. Some topics coming to my mind:

- packaging RELAX NG and W3C schema support (I started relax-ng)
- rewriting update-(sgml|xml)catalog (sgml-base, xml-core)
- docbook-utils needs a lot of love (SGML-related)
- the policies need to be updated and adjusted (especially after
rewriting xml-core/sgml-base)
- of course: bug fixing/tracking

So if you are interested, please don't hesitate to join packaging effort
of XML/SGML related packages.

Regards, Daniel


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

[Bill Allombert]

On Wed, Nov 11, 2009 at 11:11:40PM +0100, Wouter Verhelst wrote:
> On Wed, Nov 11, 2009 at 08:52:23PM +0100, Bill Allombert wrote:
> > 2.1 This clause restricts how you can modify the software.  
> > Doing a simple modification to a AGPL-covered software might require 
> > you to
> > write a substantial amount of extra code to comply with this clause.
> 
> How is this any different from the requirement in the regular GPL to
> provide source at no cost? Often this is done through website, too.

If you modify a GPL-licensed software and distribute the modified version in
source form only, you do not have any long standing obligation. This is not
the case here.

> > 2.2 This clause forces the developer modifying the software to incur cost.
> > A developer modifying the software and distributing the modified version
> > need to incur the cost of providing access to the Corresponding Source 
> > from
> > a network server as long as at least one person is using the software 
> > and
> > this for all published modifications, even long after the developer 
> > stopped
> > using and/or distributing the software.
> 
> Actually, that's not true.
> 
> This clause applies to service providers who provide a service based
> upon a slightly modified piece of AGPL software. The requirement to

The clause apply to whoever made the modification, not whoever provide the
service. They might be different people, and the modifier should not be
responsible for what the service provider do. Do you agree ?

> distribute the modifications only applies to your service:
> 
> "if you modify the program, your modified version must [...] offer [...]
> an opportunity to receive the Corresponding Source of your version"
> 
> It does not say that you must distribute the Corresponding Source for
> all eternity. 

The license does not specify a limitation of time.

> Compliance with this clause can be accomplished by simply
> adding a hyperlink to a .tar.gz with your source on an appropriate
> place.

This require you for keeping the .tar.gz online for as long a people are
providing services using your modified software, which can be a long time
after you stopped distributing it and stopped to care about it.

> That does require you to have proper procedures in place to make
> sure the .tar.gz is always up-to-date with regards to the 'released'
> version of your service, but this is no different from doing the same
> with releasing embedded hardware that uses GPL software, for instance.

Not really: with the GPL, you can just ship a CD-ROM with the source code with
each embedded devices. At this point your have no further obligation. 
(I bought several devices which provided such CD-ROM. This is far from
hypothetical.)

> > 2.2. While this clause does restrict mere use of the software, instead it
> >creates liabilities for people modifying the software, even if they
> >distributed their modified version in source form, with respect to the 
> > way
> >the software perform on user systems.
> > 
> >-- Modifying the software can unwillingly introduce a bug that cause it
> >   not to comply with this clause.
> 
> That hardly matters; bugs can be fixed. If you bring someone to court
> because they introduced a bug in their software, I'm sure the judge will
> punish you for wasting the court's time.
> 
> On the other hand, if such a bug were to exist and the developers would
> seem unwilling to fix the issue in a reasonable timeframe upon being
> notified of the problem, then that would mean they simply do not comply
> with the requirements of this license, and should be sued.

The developer might release a fixed version of the software (and thus 
a new Corresponding Source) without being able to force the service provider
to switch to that new version, which has no legal obligation.

> >-- A user of the modified version can mis-install it, mis-configure it or
> >   run it in an untested environment where it does not comply with this
> >   clause.
> >
> >-- A user of the modified version can use it in a configuration that 
> > cause
> >   it to fail to comply with this clause (for example using a reverse 
> > proxy
> >   that remove link to the source code from the html output).
> 
> No. If you do not modify the software _yourself_, you do not need to
> publish such a link. Only if you have local modifications is this
> necessary.

So if you are as service provider, is the AGPL trivially bypassable by having 
someone doing the modification for you but never actually provide any service ?

> > 3. This clause is incompatible with Section 6. of the Debian Free Software
> >Guideline.
>
> > 3.1 This clause does not allow you to modify the software to perform tasks
> > where complying with it is not technically feasible, for example:
> > 
> >-- The code is modified to run on an embedded system with tight size 
> > limit.
> >
> >-- The code is modified to interact with 

Bug#556100: ITP: c-icap -- ICAP server coded in C

[Jochen Friedrich]

Package: wnpp
Severity: wishlist
Owner: Jochen Friedrich 

* Package name: c-icap
  Version : 20080706rc3
  Upstream Author : Christos Tsantilas 
* URL : http://c-icap.sourceforge.net/
* License : GPLv2+
  Programming Lang: C
  Description : ICAP server coded in C

C-ICAP is an implementation of an ICAP server.

c-icap can be used with HTTP proxies that support the
ICAP protocol. Most of the comercial HTTP proxies must
support ICAP protocol.

Currently, only two services exist: the echo service and
an antivirus service based on ClamAV.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Iceweasel and Firefox compatibility

[John Goerzen]

Mike Hommey wrote:
> On Wed, Nov 11, 2009 at 06:38:25PM -0600, John Goerzen wrote:
>> On Tue, Nov 10, 2009 at 10:45:04PM +0100, Mike Hommey wrote:
>>> On Tue, Nov 10, 2009 at 11:43:19AM -0600, John Goerzen wrote:
 John Goerzen wrote:
> My suggestion is this:
>
> Take the default Firefox user agent.
>
> Where you see Firefox/x.y.z, change it to:
>
>   Firefox/x.y.z Iceweasel/x.y.z
>
> And that will accomplish everything needed.
>
> Sound good, Mike?
>>> Sounds too Firefoxy. Would you mind trying the Camino style for a while?
>> Well, we've had some reports that Camino style is an improvement.
>> Will you wind up using that or Flock style?
> 
> The UA in Iceweasel 3.5.5-1 uploaded today is:
> Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091112
> Iceweasel/3.5.5 (like Firefox/3.5.5; Debian-3.5.5-1)

Thank you!

-- John

> 
> Mike
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

[David Claughton]

The Fungi wrote:
> On Thu, Nov 12, 2009 at 11:07:12PM +, David Claughton wrote:
> [...]
>> It is always possible to modify free software in ways that effectively
>> make it non-free - for example if you remove all the copyright
>> statements from a BSD covered program.
> [...]
> 
> This is untrue, at least for modern 3-clause BSD[*] and its
> derivatives. I can remove the copyright statements from any
> BSD-licensed software I like, as long as I don't *redistribute* it
> in that form. By my reading, licenses like BSD or (classic) GPL
> place no restrictions on use, even of modified versions.

Distribution is what we're talking about here - if you can no longer
redistribute it then it has become non-free.

> The AGPL
> goes a great deal further than this, by *requiring* you to become a
> distributor of software you use, even if you only do something so
> simple as make a minor modification to an AGPL-covered work
> providing a network service.

You are only required to distribute the source if you choose to run it
on a publicly accessible server.  If it's on your own machine or a
private server and no-one outside your organisation can access it, then
you don't have to worry about it.

If you are only distributing the software conventionally then you only
have to provide or offer the source in exactly the same way as required
by GPL.

Cheers,

David.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Using a perl lib from postinst

[Patrick Matthäi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tollef Fog Heen schrieb:
> ]] Dominique Dumont 
> 
> | Since the postinst is a shell script, you cannot call directly the
> | perl lib.
> 
> Postinsts can be written in any language, including perl, so he could
> just write it in perl and use the relevant module.
> 

Yep and what is with:
#!/bin/sh
# some foo to be inserted here
perl -e -MMy::Module 'My::Module->do_something_nasty();'

- --
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkr9r3cACgkQ2XA5inpabMfA3wCgjML8iAbYj5vo4fZtElLr9zYc
pukAnjFCDQITemD1CkkYOiO9efllXte8
=NOTC
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Using a perl lib from postinst

[Tollef Fog Heen]

]] Dominique Dumont 

| Since the postinst is a shell script, you cannot call directly the
| perl lib.

Postinsts can be written in any language, including perl, so he could
just write it in perl and use the relevant module.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#556131: ITP: opensips -- very fast and configurable SIP server

[Alejandro Rios P.]

Package: wnpp
Severity: wishlist
Owner: "Alejandro Rios P." 

* Package name: opensips
  Version : 1.6.0
  Upstream Author : OpenSIPS Project 
* URL : http://www.opensips.org
* License : GPL
  Programming Lang: C
  Description : very fast and configurable SIP server

 OpenSIPS is a very fast and flexible SIP (RFC3261)
 server. Written entirely in C, OpenSIPS can handle thousands calls
 per second even on low-budget hardware.
 .
 C Shell-like scripting language provides full control over the server's
 behaviour. Its modular architecture allows only required functionality to be
 loaded.
 .
 Among others, the following modules are available: Digest Authentication, CPL
 scripts, Instant Messaging, MySQL support, Presence Agent, Radius
 Authentication, Record Routing, SMS Gateway, Jabber/XMPP Gateway, Transaction
 Module, Registrar and User Location, Load Balaning/Dispatching/LCR,
 XMLRPC Interface.
 .
 This package contains the main OpenSIPS binary along with the principal modules
 and support binaries.


signature.asc
Description: Digital signature

Re: GR proposal: the AGPL does not meet the DFSG (take 2)

[David Claughton]

David Claughton wrote:
> The Fungi wrote:
>> goes a great deal further than this, by *requiring* you to become a
>> distributor of software you use, even if you only do something so
>> simple as make a minor modification to an AGPL-covered work
>> providing a network service.
> 
> You are only required to distribute the source if you choose to run it
> on a publicly accessible server.  If it's on your own machine or a
> private server and no-one outside your organisation can access it, then
> you don't have to worry about it.
> 
> If you are only distributing the software conventionally then you only
> have to provide or offer the source in exactly the same way as required
> by GPL.
> 

OK, I've just re-read section 13 of the AGPL and I'm going to retract
that last sentence.  It is indeed not quite that simple.

If you modify the program you also need to modify the offer to download
the source so it gets your modified code instead of the original.  One
way to do this is to point it to your server, but it is not the only way.

For example, another way you might be able to comply with this
requirement is to always distribute the source along with the binaries
and arrange for the source to be downloaded from the same server the
binary is running from.

Now this could certainly involve more extensive modifications than you
might otherwise want to do, and you might well decide it's not worth the
effort.  However I'm still not entirely convinced it makes the license
non-free.

Cheers,

David.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Using a perl lib from postinst

[Daniel Pittman]

Patrick Matthäi  writes:
> Tollef Fog Heen schrieb:
>> ]] Dominique Dumont
>>
>> | Since the postinst is a shell script, you cannot call directly the
>> | perl lib.
>>
>> Postinsts can be written in any language, including perl, so he could
>> just write it in perl and use the relevant module.
>>
>
> Yep and what is with:
> #!/bin/sh
> # some foo to be inserted here
> perl -e -MMy::Module 'My::Module->do_something_nasty();'

Er, it wasn't in Debian, but in a couple of bits of my private packaging I did
something akin to that in order to use the debhelper shell script injected
into the postinst easily.

Given that one line of Perl was required it looked the nicer strategy, and
less prone to break strangely if the debhelper shell code did something
strange.

Daniel

-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#556169: ITP: openide-util -- Netbeans utility library

[Giovanni Mascellani]

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

   Package name: openide-util
Version: from netbeans 6.7
Upstream Author: Sun Microsystems, Inc.
URL: http://netbeans.org/
License: GPL-2 | CDDL
Description: Netbeans utility library
OpenIde util is a collection of miscellaneous libraries from Netbeans, a
powerful IDE for many languages.

These libraries are independently packaged in order to be used by other
independent software as well (FreeHEP in my case), because right now
Debian Netbeans package is not maintained.

As soon as someone will adopt and start maintaining netbeans, that
version on openide-util will be used and this package will be dropped.

Giovanni.
-- 
Giovanni Mascellani 
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org



signature.asc
Description: OpenPGP digital signature

Bug#556167: ITP: scilab-ann -- Scilab toolbox for artificial neural networks

[Sylvestre Ledru]

Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru 

* Package name: scilab-ann
  Version : 0.4.2.3
  Upstream Author : Ryurick M. Hristev 
* URL : http://atoms.scilab.org/toolboxes/ANN_Toolbox/
* License : GPL 2
  Programming Lang: Scilab
  Description : Scilab toolbox for artificial neural networks

 Current features
  - Only layered feedforward networks are supported *directly* at the moment
(for others use the "hooks" provided)
  - Unlimited number of layers
  - Unlimited number of neurons per each layer separately
  - User defined activation function (defaults to logistic)
  - User defined error function (defaults to SSE)
  - Algorithms implemented so far:
* standard (vanilla) with or without bias, on-line or batch
* momentum with or without bias, on-line or batch
* SuperSAB with or without bias, on-line or batch
* Conjugate gradients
* Jacobian computation
* Computation of result of multiplication between "vector" and Hessian
  - Some helper functions provided



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#556171: ITP: scilab-swt -- Scilab Wavelet Toolbox

[Sylvestre Ledru]

Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru 

* Package name: scilab-swt
  Version : 0.1.0rc4-1
  Upstream Author : Roger Liu
* URL : http://scwt.sourceforge.net/
* License : GPL
  Programming Lang: C & Scilab
  Description : Scilab Wavelet Toolbox


 Wavelet is a powerful signal processing tool developed and developing
 in the last two decades. Scilab Wavelet Toolbox is a free software package
 to enable you using wavelet analysis tools freely in Scilab on most OSes
 including GNU/Linux, BSD and Windows. Scilab Wavelet Toolbox is designed
 to work with any Scilab Image Processing Toolbox like SIP or SIVP
 for displaying 2-D results.
 .
 What Scilab Wavelet Toolbox supposed to do:
 * Discrete Fast Wavelet Transform, daubechies wavelets
 * 1-D single level signal decomposition and reconstruction
 * 1-D multi-level signal decomposition and reconstruction
 * 2-D single level image decomposition and reconstruction
 * 2-D multi-level image decomposition and reconstruction



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Iceweasel and Firefox compatibility

[Jesús M. Navarro]

Hi, Steve:

On Wednesday 11 November 2009 08:17:50 Steve Langasek wrote:
> On Wed, Nov 11, 2009 at 07:37:56AM +0100, Christian Perrier wrote:
> > IMHO, with not very convincing arguments. And no sign of answer about
> > the real potential problem: would that be another trademark issue.
> >
> > Whatever solution is taken in the other branches of this thread where
> > possible UA strings are discussed, I think we should at some point
> > check with Mozilla Corporation about their stance: would they consider
> > it to be a trademark violation if we mention "Firefox" in some way in
> > the UA string of Iceweasel?

Trade Mark protection as usual.  It is not about naming the cursed word; it's 
the way you mention it.

> I strongly disagree that we should do this, because it's *not* a trademark
> violation, so any opinion they might hold to the contrary is not relevant.

Of course you are not talking with your attorney hat here.

Just take it a bit out of context (as a lawyer would probably do):

Attorney: What's a User Agent String?
Expert: Well, it's the way the browser identifies itself against the server.
A.: So, can I say it's like me asking you "Who are you" and you answering 
me "I'm Mr. Smith?"  or "what's that? is this a Pepsi or what is it?"
E.: Well... I'd say that...
A.: Just answer yes or not!
E.: Hummm... Err... Well, yes.
A.: So then, Iceweasel is claiming to be "Firefox" against the server which 
asks it?
E.: Yes.
A.: It is not answering "I'm *like* Firefox" or "My codebase is based on that 
from Firefox" but "I'm Firefox"?
E.: Yes.
A.: No more questions.

Forget it's only machine to machine chatting and think for a second the 
user-agent string were on a newspaper.  I think it's clear that "Firefox 3.5" 
would be an obvious copyright infringement while "Based on Firefox 3.5" would 
be perfectly safe.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Iceweasel and Firefox compatibility

[Russ Allbery]

"Jesús M. Navarro"  writes:

> Just take it a bit out of context (as a lawyer would probably do):

> Attorney: What's a User Agent String?
> Expert: Well, it's the way the browser identifies itself against the server.

That's an uncoached expert who just gave a crappy answer to that question,
since in practice that's not what User-Agent is at all.

Attorney: What's a User Agent String?
Expert: It's a list of random product identifiers that the browser wants
   to claim that it's compatible with, some of which normally refer to
   products that have been dead for years in any context other than code
   that looks at user agent strings.

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

Processed: Re: Bug#542872: Please Recommend default-mta | m-t-a, not exim4 | m-t-a

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 542872 by 508644
Bug #542872 [at] Please Recommend default-mta | m-t-a, not exim4 | m-t-a
Was not blocked by any bugs.
Added blocking bug(s) of 542872: 508644
> thanks
Stopping processing here.

Please contact me if you need assistance.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org