Re: -Wl,--as-needed considered possibly harmful

[Neil Williams]

On Thu, 20 Dec 2007 21:44:19 -0800
Steve Langasek <[EMAIL PROTECTED]> wrote:

> Consider two libraries, libfoo and libbar.  libfoo depends on libbar,
> references functions from it and uses some of libbar's types in its own
> exported API.
> 
> We assume the Debian-style libbar-dev, which ensures that the libbar headers
> match the version of libbar.so on the system.

> The pkg-config technique guarantee that, when an application links against
> libfoo, it is also linked against libbar.  Because of the preceding, this
> guarantees that the application is linked against the version of libbar
> whose ABI matches that of the headers used when building the application.
> 
> But *nothing* here guarantees that the version of libbar the application is
> linked against has the same ABI as the one libfoo itself linked against!

... until both the application and libfoo are rebuilt. So the issue
here is triggering rebuilds of reverse dependencies of libbar? I can
see this getting to be a big problem if the "application" in this
example is actually another library. If libfoo actually doesn't build
against libbar2 because of the API changes, the whole thing grinds to
a halt. After all, libbar1->libbar2 could involve any level of changes
to the API. If the application uses 5% of the libbar functions and the
library uses 50%, it's easy to see that the library has a higher risk
of needing intrusive source changes to build against the new libbar. 

The Gtk1->Gtk2 transition is still far from complete, KDE3->4 is
current.

Though the combination of libbar1 and libbar2 raises the chances of
problems, forcing rebuilds whether the problem appears or not would
seem to increase the problems of blocked transitions and hinder
releases even further.

>  If
> libfoo linked against libbar1, the pkg-config approach only ensures that
> when your application is built against the libbar2 version of libbar-dev,
> the resulting binary will depend on both libbar1 and libbar2 (despite not
> using any symbols from libbar2).  All this does is increase the chances of
> segfaults or bad runtime behavior as a result of symbol clobbering.
> 
> So the usage recommended by pkg-config upstream does nothing at all to solve
> the problem it's supposed to, and instead causes other linkage problems.

Maybe I've got this wrong but there would appear to be a few methods to
fix this:
1. Incorporating the libbar SONAME into the libfoo package SONAME - as
Simon Richter recommended - this could quickly end up with
libany1-foo2-bar2-baz0-base4-pango0-... etc and I'm not convinced that
this would actually help anyone if, for example, libbaz0 migrates to
libbaz1 in a way that completely breaks libbar2.
2. A rebuild trigger mechanism that is separate from the library SONAME
and the pkg-config files - an automated version of what happens now for
requesting binNMU's ? Not as easy as it may sound - there's no
guarantee that libfoo *can* build against libbar2.
3. A build-time hook that checks the entire dependency chain for
duplicates and fails if a freshly built binary ends up linked to two
versions of one source? (i.e. requiring a bug in whichever package is
using libbar1 to upgrade to libbar2). That could lead to being unable
to upload packages to fix other bugs.

What is the correct solution?

Is there a way that the current pkg-config *can* provide what upstream
believe it already does? Even if pkg-config upstream are thinking of
gentoo-type distributions, you'll still end up with a prebuilt libfoo
depending on libbar1 and a freshly built application depending on
libbar2, even using libbar1-dev and libbar2-dev (although at least
that is more obvious).

Maybe debtree could be useful here - or maybe edos-debcheck could be
extended to look for problems like this. It should be apparent from the
apt cache that the application uses libbar2 and libfoo but that libfoo
depends on libbar1. Maybe there is a role here for deborphan or a
similar tool as well - to scan an installation for not just orphaned
libraries but duplicates as well.

Getting back to the original thread, if applications and libraries each
take more care not to link to spurious dependencies, it should be
easier to identify the real problems instead of chasing red herrings
where the application is linked to libbar2 and libfoo but actually only
uses symbols from libfoo.

I've just uploaded libqof1 that used the information from the new
dpkg-shlibdeps to trim the dependencies of libqof1, excluding some
libraries that were previously only brought in because of bugs in the
libgda pkg-config data. It meant changing the QOF upstream to check for
the particular functions that it needs instead of trusting the
pkg-config data from libgda so that it could identify the correct
dependency data for a public library provided by libgda but not exposed
in the pkg-config data. (libgdasql).

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


pg

Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Gerrit Pape]

qmail is meant as a replacement for the entire sendmail-binmail system
on typical Internet-connected UNIX hosts. See BLURB, BLURB2, BLURB3, and
BLURB4 in /usr/share/doc/qmail/ for more detailed advertisements.

See /usr/share/doc/qmail/PIC.* for some ``end-to-end'' pictures of mail
flowing through the qmail system.

See http://pobox.com/~djb/qmail.html for other qmail-related software
and a pointer to the qmail mailing list.

Other documentation: http://pobox.com/~djb/proto.html shows solutions to
several Internet mail problems; many of these solutions are implemented
in qmail. CHANGES and THANKS show how qmail has changed since it was
first released; SECURITY, INTERNALS, THOUGHTS, and TODO record many of
the qmail design decisions (found in /usr/share/doc/qmail/).


License
 qmail is in the public domain

There'll be the following binary packages: qmail, qmail-uid-gids,
fastforward, dot-forward, qmail-run.  The packages are derived from
the unofficial ones available through
 http://smarden.org/pape/Debian/qmail.html

Regards, Gerrit.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question sur udev : sur quelle liste ?

[David BERCOT]

Hi,

Sorry for my first mail (I thought I was writing to the devel-french
list) !

So, I have problems with my webcam. When it is unplugged, everything is
ok for Alsa. But, when it is plugged, before the startup, I sometimes
have sound problems...
In order to fix them, I thought that the best solution was to do udev
rules... So, I wrote :
SUBSYSTEM=="sound", ATTRS{device}=="0x266e",
ATTRS{vendor}=="0x8086", NAME+="snd/controlC0", SYMLINK+="carte_son"
SUBSYSTEM=="sound", ATTRS{device}=="0x266d",
ATTRS{vendor}=="0x8086", NAME+="snd/controlC1", SYMLINK+="modem"
SUBSYSTEM=="sound", ATTRS{idProduct}=="08ad",
ATTRS{idVendor}=="046d", NAME+="snd/controlC2", SYMLINK+="webcam"

It seems ok, but Alsa hang at startup. May be it is because of the last
line because the webcam has sound and video devices...

Can you help me to find where I made a mistake ?

Thank you very much.

David.

Le Fri, 21 Dec 2007 15:33:24 +0100,
Jean Parpaillon <[EMAIL PROTECTED]> a écrit :
> Hi,
> About the question itself, a devel-* list may be good, but about the
> form, this is an English spoken list. Either ask your question in
> English or post to debian-devel-french list.
> 
> Regards,
> Jean
> 
> Le 21.12.2007 15:12, David BERCOT a écrit :
> > Bonjour,
> > 
> > Je suis hors-sujet sur ma question, mais, vu les personnes présentes
> > ici, je pense que quelqu'un va pouvoir m'orienter...
> > 
> > J'ai discuté, sur la ml user-french, de questions autour d'udev. Par
> > exemple, j'ai rajouté ces règles-ci :
> > SUBSYSTEM=="sound", ATTRS{device}=="0x266e",
> > ATTRS{vendor}=="0x8086", NAME+="snd/controlC0", SYMLINK+="carte_son"
> > SUBSYSTEM=="sound", ATTRS{device}=="0x266d",
> > ATTRS{vendor}=="0x8086", NAME+="snd/controlC1", SYMLINK+="modem"
> > SUBSYSTEM=="sound", ATTRS{idProduct}=="08ad",
> > ATTRS{idVendor}=="046d", NAME+="snd/controlC2", SYMLINK+="webcam"
> > qui me plantent Alsa.
> > Il semblerait que j'ai à présent besoin de discuter sur une ml moins
> > généraliste (ce n'est en aucun cas péjoratif pour la ml
> > user-french, où, d'ailleurs, j'en connais nettement moins que de
> > nombreuses personnes, mais peut-être que celles-ci manquent de
> > temps), et je ne sais pas vraiment laquelle choisir (en anglais ou
> > en français).
> > 
> > Pourriez-vous m'indiquer la ml la plus indiquée pour ce genre de
> > questions ?
> > 
> > Merci d'avance.
> > 
> > David.


signature.asc
Description: PGP signature

Question sur udev : sur quelle liste ?

[David BERCOT]

Bonjour,

Je suis hors-sujet sur ma question, mais, vu les personnes présentes
ici, je pense que quelqu'un va pouvoir m'orienter...

J'ai discuté, sur la ml user-french, de questions autour d'udev. Par
exemple, j'ai rajouté ces règles-ci :
SUBSYSTEM=="sound", ATTRS{device}=="0x266e", ATTRS{vendor}=="0x8086",
NAME+="snd/controlC0", SYMLINK+="carte_son"
SUBSYSTEM=="sound", ATTRS{device}=="0x266d", ATTRS{vendor}=="0x8086",
NAME+="snd/controlC1", SYMLINK+="modem"
SUBSYSTEM=="sound", ATTRS{idProduct}=="08ad", ATTRS{idVendor}=="046d",
NAME+="snd/controlC2", SYMLINK+="webcam"
qui me plantent Alsa.
Il semblerait que j'ai à présent besoin de discuter sur une ml moins
généraliste (ce n'est en aucun cas péjoratif pour la ml
user-french, où, d'ailleurs, j'en connais nettement moins que de
nombreuses personnes, mais peut-être que celles-ci manquent de temps),
et je ne sais pas vraiment laquelle choisir (en anglais ou en français).

Pourriez-vous m'indiquer la ml la plus indiquée pour ce genre de
questions ?

Merci d'avance.

David.


signature.asc
Description: PGP signature

Re: Question sur udev : sur quelle liste ?

[Jean Parpaillon]

Hi,
About the question itself, a devel-* list may be good, but about the
form, this is an English spoken list. Either ask your question in
English or post to debian-devel-french list.


Regards,
Jean


Le 21.12.2007 15:12, David BERCOT a écrit :
> Bonjour,
> 
> Je suis hors-sujet sur ma question, mais, vu les personnes présentes
> ici, je pense que quelqu'un va pouvoir m'orienter...
> 
> J'ai discuté, sur la ml user-french, de questions autour d'udev. Par
> exemple, j'ai rajouté ces règles-ci :
> SUBSYSTEM=="sound", ATTRS{device}=="0x266e", ATTRS{vendor}=="0x8086",
> NAME+="snd/controlC0", SYMLINK+="carte_son"
> SUBSYSTEM=="sound", ATTRS{device}=="0x266d", ATTRS{vendor}=="0x8086",
> NAME+="snd/controlC1", SYMLINK+="modem"
> SUBSYSTEM=="sound", ATTRS{idProduct}=="08ad", ATTRS{idVendor}=="046d",
> NAME+="snd/controlC2", SYMLINK+="webcam"
> qui me plantent Alsa.
> Il semblerait que j'ai à présent besoin de discuter sur une ml moins
> généraliste (ce n'est en aucun cas péjoratif pour la ml
> user-french, où, d'ailleurs, j'en connais nettement moins que de
> nombreuses personnes, mais peut-être que celles-ci manquent de temps),
> et je ne sais pas vraiment laquelle choisir (en anglais ou en français).
> 
> Pourriez-vous m'indiquer la ml la plus indiquée pour ce genre de
> questions ?
> 
> Merci d'avance.
> 
> David.

begin:vcard
fn:Jean Parpaillon
n:Parpaillon;Jean
org:Kerlabs;Support - Development
adr:;;Campus Universitaire de Beaulieu;Rennes Cedex;;35042;France
email;internet:[EMAIL PROTECTED]
title:Engineer
tel;work:+33 2 99 84 25 99
url:http://kerlabs.com/
version:2.1
end:vcard



signature.asc
Description: OpenPGP digital signature

Re: Bug in makeinfo or install-info?

[Luis Rodrigo Gallardo Cruz]

On Mon, Dec 17, 2007 at 05:53:09PM -0600, Luis Rodrigo Gallardo Cruz wrote:
> On Mon, Dec 17, 2007 at 07:01:11PM +0100, Santiago Ruano Rincón wrote:
> > ...
> > Unpacking replacement bzip2 ...
> > Setting up bzip2 (1.0.3-7) ...
> > install-info(/usr/share/info/bzip2.info): warning, ignoring confusing 
> > INFO-DIR-ENTRY in file.
> > 
> > No `START-INFO-DIR-ENTRY' and no `This file documents'.
> > install-info(/usr/share/info/bzip2.info): unable to determine description 
> > for `dir' entry - giving up
> > dpkg: error processing bzip2 (--install):
> >  subprocess post-installation script returned error exit status 1
> > 
> > The problem is with bzip2.info, produced by makeinfo during the building
> > process.
> 
> A very similar bug hit librep-doc about a week ago (#451265) and, just
> today, sawfish (#456791) It was cloned as #451268 and supposedly solved on
> Nov 14, but it seems to have come back.

I have confirmed that rebuilding sawfish with texinfo/4.11.dfsg.1-3
solves the problem. Rebuilds of the affected packages (but I have no
idea which are those) should be scheduled after that version of
texinfo is installed in all arches (currently arm, hppa, s390 and
sparc are building, and m68k is in dep-wait).




signature.asc
Description: Digital signature

Re: Question sur udev : sur quelle liste ?

[Pierre Habouzit]

On Fri, Dec 21, 2007 at 02:33:24PM +, Jean Parpaillon wrote:
> Hi,
> About the question itself, a devel-* list may be good, but about the
> form, this is an English spoken list. Either ask your question in
> English or post to debian-devel-french list.

  for these kind of questions debian-user-* seems way more appropriate
to me.

Cheers,
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpMJMPpNCujF.pgp
Description: PGP signature

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Guus Sliepen]

On Fri, Dec 21, 2007 at 02:28:28PM +, Gerrit Pape wrote:

> qmail is meant as a replacement for the entire sendmail-binmail system
> on typical Internet-connected UNIX hosts. See BLURB, BLURB2, BLURB3, and
> BLURB4 in /usr/share/doc/qmail/ for more detailed advertisements.
[...]

This is not a proper ITP. You only mention where to find documentation
on system with a supposedly already installed qmail. To file a proper
ITP, make sure you've read the policy manual about what to put in the
short and long description of a package, and do:

aptitude install reportbug
reportbug wnpp

And select 1.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: wxwidgets 2.8, anyone?

[Ron]

Hey Daniel,

I don't want to distract you from your research too much, but perhaps
there is something you can clarify for the rest of us that are trying
to assess all this too ...

You opened all this by saying:

On Thu, Dec 20, 2007 at 09:08:53AM +0100, Daniel Baumann wrote:
> there are more and more packages which require wxwidgets >=2.8. Last 
> time[0], I hoped somebody would finally take care of it, but nothing 
> happened yet.
>
> With the new version of poedit, it's not possible to build anymore with an 
> older wxwidgets, hence the package is required for me. Does anyone have a 
> plan to upload wxwidgets 2.8 within the next four weeks? If not, I fear I 
> have to do it.

But it's been brought to my attention that the latest version
of poedit advertised here: http://www.poedit.net/

Actually works perfectly well with wx2.6, which the upstream
author told you here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457157

And you only apparently keep that bug open because some proposed
future version _may_ require 2.8.

If all this is a genuine reflection of the current state of affairs,
then please do close the fixed bug report, that isn't blocked by any
wx bugs at all, nor has it ever been, to avoid actually confusing
people more.

Then if you and the poedit upstream (who also has direct commit
access to the wx upstream repo), really do come up with some new
killer feature in some future release, we can weigh that honestly
against what we are really missing without 2.8 at present.

There are some people with genuine needs, and a lot still backporting
really important fixes to their 2.6 releases.  If I have to sort
the real claims from the astroturf, this isn't going to get done
_faster_ than if we put some Good Data into the calculation to
begin with.

Thanks in advance,
Ron


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: simplepie -- RSS and Atom feed parsing in PHP

[Marcelo Jorge Vieira (metal)]

Package: wnpp
Severity: wishlist

* Package name   : simplepie
  Version: 1.0.1
  Upstream Author: Ryan Parman
   Geoffrey Sneddon <[EMAIL PROTECTED]>
* URL: http://simplepie.org/
* License: BSD License
  Description: RSS and Atom feed parsing in PHP

  SimplePie is a very fast and easy-to-use class, written in PHP, that
  puts the ‘simple’ back into ‘really simple syndication’. Flexible enough
  to suit beginners and veterans alike, SimplePie is focused on speed,
  ease of use, compatibility and standards compliance.

-- 
Marcelo Jorge Vieira (metal)
metaldot - http://metaldot.alucinados.com
jabber - [EMAIL PROTECTED]


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Joerg Jaspert]

On 11240 March 1977, Guus Sliepen wrote:

>> qmail is meant as a replacement for the entire sendmail-binmail system
>> on typical Internet-connected UNIX hosts. See BLURB, BLURB2, BLURB3, and
>> BLURB4 in /usr/share/doc/qmail/ for more detailed advertisements.
> This is not a proper ITP. You only mention where to find documentation
> on system with a supposedly already installed qmail. To file a proper
> ITP, make sure you've read the policy manual about what to put in the
> short and long description of a package, and do:

And then there is the question if such a piece of software should really
go into Debian. There are *way* better  MTAs out there that dont need
tons of patches applied just to fulfill basic requirements for a MTA.

-- 
bye Joerg
 Meine Gedanken sind von dem Bild gefangen, wie Tolimar mit nacktem
 Oberkörper und schokoladenverschmierten Fingern vor Meike tanzt #-)
 HE: du bist eklig
 Ich bin wirklich richtig schlimm krank im Kopf.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#457333: ITP: bzr-pqm -- bzr plugin to submit an email to a Patch Queue Manager

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: bzr-pqm
  Version : 1.0.0
  Upstream Author : John Arbash Meinel <[EMAIL PROTECTED]>
James Henstridge <[EMAIL PROTECTED]>
Elliot Murphy <[EMAIL PROTECTED]>
Aaron Bentley <[EMAIL PROTECTED]>
* URL : http://launchpad.net/bzr-pqm
* License : GPL
  Programming Lang: Python
  Description : bzr plugin to submit an email to a Patch Queue Manager

A plugin for Bazaar for submitting commands to a Patch Queue Manager.

- -- System Information:
Debian Release: lenny/sid
  APT prefers gutsy
  APT policy: (500, 'gutsy'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: testing build errors on arm/sid

[Julien Cristau]

On Thu, Dec 20, 2007 at 16:18:41 +0100, Norbert Preining wrote:

> Hi all,
> 
> I need to check out some build failures on ARM arch in a sid chroot. I
> found a chroot on leisner.debian.org. 
> 
> But since I have never done this, how can I as normal user there check
> that? Is there something like a cow/pbuilder using this chroot? 
> 
Hi Norbert,

$ dchroot sid
$ apt-get source $foo
$ cd $foo-*
$ dpkg-buildpackage

should work, assuming the build-dependencies are there (if they aren't,
you should contact DSA to get them installed).

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[John H. Robinson, IV]

Joerg Jaspert wrote:
> 
> There are *way* better MTAs [than qmail] out there that dont need
> tons of patches applied just to fulfill basic requirements for a MTA.

No, there are not.

-- 
John H. Robinson, IV  [EMAIL PROTECTED]
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#430896: Do not forget KDE Desktop

[Rafael Belmonte]

I am glad by see that your are thinking or working about the propose.
But i think you are centring  the propose in the Gnome Desktop, and i would
like this functionality also in KDE Desktop.
Thanks you very much.

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Steinar H. Gunderson]

On Fri, Dec 21, 2007 at 08:17:08PM +0100, Leo costela Antunes wrote:
> There are certainly many others that don't need patches to fulfill basic
> requirements for an MTA, but whether they are better or not is
> irrelevant for us, given Qmail's level of widespread adoption.

How widespread is this anyway? I hardly see any new qmail installations
anymore, and the ones I see are largely because it's a pain to migrate away
from.

Of course, the plural of “anecdote” is not “data”...

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Leo "costela" Antunes]

John H. Robinson, IV wrote:
> Joerg Jaspert wrote:
>> There are *way* better MTAs [than qmail] out there that dont need
>> tons of patches applied just to fulfill basic requirements for a MTA.
> 
> No, there are not.

There are certainly many others that don't need patches to fulfill basic
requirements for an MTA, but whether they are better or not is
irrelevant for us, given Qmail's level of widespread adoption. There's
no discussion that there are still many people interested in having it
available.
After all, it's not like it's a 100 line C program with 10 totally
compatible alternatives... unfortunately! :-)

Cheers.

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Russ Allbery]

"John H. Robinson, IV" <[EMAIL PROTECTED]> writes:
> Joerg Jaspert wrote:

>> There are *way* better MTAs [than qmail] out there that dont need
>> tons of patches applied just to fulfill basic requirements for a MTA.

> No, there are not.

Is the version that is proposed to be packaged patched to reject mail at
the SMTP level for unknown users rather than accept mail and bounce it
later?  qmail in its default operational mode is a spam reflector and
hence broken by design, and shouldn't be accepted into Debian.  However,
perhaps this has been fixed by the community since djb's last release?

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#54138: What you can expect.

[Rachel London]

We recommend you to take two tablets once a day, after a meal.
http://doablilres.com




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Leo "costela" Antunes]

Steinar H. Gunderson wrote:
> How widespread is this anyway? I hardly see any new qmail installations
> anymore, and the ones I see are largely because it's a pain to migrate away
> from.
> 
> Of course, the plural of “anecdote” is not “data”...

Well, I have too agree with you that almost all my personal examples are
based on the "hard to migrate from" argument.

The usage surveys I could find[0][1][2] have somewhat conflicting usage
patterns, but all indicate Qmail is not the most used MTA out there.

Please note that I don't personally like Qmail either, but I still think
we should (but don't *have* to) provide it, if possible (I don't know
what's the outcome of the "putting it in public domain" story).

Cheers

[0]http://www.securityspace.com/s_survey/data/man.200707/mxsurvey.html
[1]http://www.oreillynet.com/pub/a/sysadmin/2007/01/05/fingerprinting-mail-servers.html
[2]http://cr.yp.to/surveys/smtpsoftware6.txt (not up-to-date, but
perhaps interesting nonetheless)

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re[2]: wxwidgets 2.8, anyone?

[Vadim Zeitlin]

On Thu, 20 Dec 2007 09:15:08 -0800 Robin Dunn <[EMAIL PROTECTED]> wrote:

RD> Vadim Zeitlin wrote:
RD> > On Thu, 20 Dec 2007 09:54:46 +0100 Raphael Hertzog <[EMAIL PROTECTED]> 
wrote:
RD> > 
RD> > RH> Apparently, Vadim Zeitlin <[EMAIL PROTECTED]> is ready to take care of
RD> > RH> the Debian packaging but he would need a sponsor and I'm sure some 
help
RD> > RH> would be useful as well.
RD> > 
RD> >  I can indeed take care of this (as I said in previous, private, mail, I'm
RD> > interested in having up to date and well maintained wx packages for Debian
RD> > as both wx developer and Debian user, and I'd be glad to contribute
RD> > something back to Debian too) but currently the maintenance of the 
packages
RD> > is done by Robin Dunn, another wx developer and the author of wxPython. So
RD> > maybe Robin would prefer to take this role himself -- I'm cc'ing him so
RD> > that he could take this decision.
RD> 
RD> I've considered this in the past, and even took a few steps towards 
RD> becoming the official Ubuntu maintainer, but I realized that I just 
RD> don't have the time for it.

 Hello again,

 As I said, I'm ready to fill this role in this case (if there are no other
people willing to do it). If I understand correctly, I should be working
with Daniel Baumann who, as a sponsor, would be actually uploading the
packages so I'll be contacting Daniel in the beginning of the next year to
organize all this.

 Again, as mentioned before, I'd welcome any bug reports/comments about

1. Our existing Debian packages at apt.wxwidgets.org
2. Building/using other packages using wx 2.8 instead of 2.6

 TIA,
VZ


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Hamish Moffatt]

On Fri, Dec 21, 2007 at 04:23:52PM +0100, Guus Sliepen wrote:
> On Fri, Dec 21, 2007 at 02:28:28PM +, Gerrit Pape wrote:
> 
> > qmail is meant as a replacement for the entire sendmail-binmail system
> > on typical Internet-connected UNIX hosts. See BLURB, BLURB2, BLURB3, and
> > BLURB4 in /usr/share/doc/qmail/ for more detailed advertisements.
> [...]
> 
> This is not a proper ITP. You only mention where to find documentation
> on system with a supposedly already installed qmail. To file a proper
> ITP, make sure you've read the policy manual about what to put in the

Policy doesn't dictate the format of an ITP message though, or even a
requirement to submit one. This particular ITP doesn't need to explain
what qmail is (the target audience already knows) and the ITP isn't
intended to be a review of the final descriptions.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#457373: ITP: pxsl -- Parsimonious XML Shorthand Language

[Kari Pahula]

Package: wnpp
Severity: wishlist
Owner: Kari Pahula <[EMAIL PROTECTED]>


* Package name: pxsl
  Version : 1.0
  Upstream Authors: Tom Moertel <[EMAIL PROTECTED]> and Bill Hubauer <[EMAIL 
PROTECTED]>
* URL : http://community.moertel.com/ss/space/PXSL
* License : GPLv2 or later
  Programming Lang: Haskell
  Description : Parsimonious XML Shorthand Language

 PXSL ("pixel") provides XML authors and programmers with a simple,
 concise syntax that they can use to create XML documents.
 .
 For more advanced users, PXSL offers customizable shortcuts and
 sophisticated refactoring tools like functional macros that can
 markedly reduce the size and complexity of markup-dense XML
 documents.
 .
 The short version is this: PXSL is XML turned inside-out. Instead of
 tagging the structure, you tag the non-structure, which is the better
 approach when most of your information is structure.
 .
 Also, PXSL lets users intermix PXSL and XML syntax in one
 document. Users are free to use whichever syntax works best for each
 portion of their documents.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#457384: ITP: netsend -- a speedy filetransfer and network diagnostic program

[Martin Peylo]

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

I have already completed packaging of current SVN revision 203. It is  
lintian and linda clean and builds under Etch and Sid (through  
pbuilder). I will upload it to http://mentors.debian.net as soon as I  
get the ITP bug# for the changelog file.


*** I AM LOOKING FOR A SPONSOR ***

* Package name : netsend
* License : GPL
* URL : http://netsend.berlios.de/
* SVN : http://svn.berlios.de/svnroot/repos/netsend/trunk

Netsend transmits and receives files. It is highly configurable and  
offers the transport protocols TCP, DCCP, UDP, UDPLITE and SCTP using  
either IPv4 or IPv6 on the network layer. The cluster protocol TIPC  
is also supported.


The user is able to tweak various options of the Linux network stack  
to gain maximum performance. While this is not needed for trivial  
filetransfer, it is valuable for network protocol performance testing.





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457384: ITP: netsend -- a speedy filetransfer and network diagnostic program

[Ron Johnson]

On Friday December 21 2007 20:50:44 Martin Peylo wrote:
[snip]
>
> The user is able to tweak various options of the Linux network
> stack to gain maximum performance. While this is not needed for
> trivial filetransfer, it is valuable for network protocol
> performance testing.

From reading the web page, it seems that netsend might only work 
between Linux systems.  Am I reading it wrong?

-- 
-
Ron Johnson, Jr.
Jefferson, LA  USA

"Millions of Chinese speak Chinese, and it's not hereditary..."
Dr. Dean Edell


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

Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Petter Reinholdtsen]

[Martin Pitt]
> What do you think about this approach? I'm well aware that this
> alone won't rescue desktop security (getting there is looots of more
> work), but one has to start somewhere.

Would it break fakeroot and other tools using LD_PRELOAD to get the
wanted effect?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Which spell checkers to include by default? (Was: priorities)

[Petter Reinholdtsen]

[Anthony Towns]
> Kind of reviving an old thread, but anyway:
> It also includes, but afaics, probably doesn't need to (anymore):
> 
>   ispell, dictionaries-common, iamerican, ibritish, wamerican

[Agustin Martin]
> #416572: ibritish: Should not have priority standard 

We now have aspell, myspell and hunspell as alternatives to ispell,
and it can be argued that all of them are better than ispell at
providing spell checking and recommendations for replacements.
Because of this, I believe it would be a good idea to drop ispell from
the list of standard packages, and the related packages too (i*, w*).

If we were to keep a spell checker as part of the default
installation, I would suggest using hunspell as it is most advanced
and I am told it support the most languages at the moment.  The next
step would be to change all programs currently using ispell, aspell
and myspell by default to use hunspell instead.  The only package I
use that are still using ispell is emacs.  No idea how hard it would
be to update, but it would be a good thing to support for example
Hungarian and Nothern Sami spell checking in emacs. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]