Re: switching from exim to postfix

[Andrew Shadura]

Hello,

On Tue, 1 May 2012 23:03:38 +0200
Philipp Kern  wrote:

> > I wonder why many people in this thread still don't understand this.
> > And also I can't see why some find this annoying behaviour or
> > something wrong. There's absolutely nothing wrong with what it does
> > now, as re-encoding will happen somewhere anyway as there are still
> > many really non-8-bit-compliant MTAs, so why should Exim do this?

> Exim transmits 8bit mails to non-8bit-compliant MTAs, so what exactly
> are you arguing?

No it doesn't if 8BITMIME annouces are turned off!

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Node.js and it's future in debian

[Jonathan Nieder]

Hi again,

Steve Langasek wrote:

> [Dropped Cc; what does any of this have to do with the DPL?]

I was alerting him to a conversation that was going nowhere fast,
in the hope that he might use his power to

participate in discussions amongst the Developers in a helpful
way

It has also been my experience in the past that he is way better than
I am at figuring out a productive way forward when an endeavor is
stuck.

[...]
> I mean that it is not reasonable to expect a maintainer to recognize a
> "consensus" among other people who are not the maintainer, where his or her
> package is concerned, except when that's a consensus of a
> constitutionally-empowered body such as the TC.

That implies two bugs in debian-policy. :)  You are probably right.

[...]
>   The Technical Committee may:
>
>   [...]
>
>   2. Decide any technical matter where Developers' jurisdictions overlap.

If I understand correctly, the general conclusion in this thread has
been that that is the right way to decide this.

I don't see anything fundamentally opposed to one another about the
goals of Pat, Jonas, and Jérémy, who seem to be the developers who
would be involved.  The implied impossibility of a reasonable
conversation between them without some authority figure arbitrating is
a bit disappointing.  Oh well.

[...]
> Ok - sorry, that's not what came across in your message, it's possible I
> overlooked some context up-thread that would have made this clear.  Yes, a
> bug that's been filed against the package and gone unanswered by the
> maintainer is fair game for NMUing.  OTOH, a bug that the maintainer
> disagrees is a bug would not be fair game.

Thanks again for the clarifications and sorry for the lack of clarity.
(Also sorry for the somewhat inflamatory way I've proceeded in this
discussion --- stating my biases up front and tying this in with my
concerns about lack of an active maintainer to vet changes to the node
package was probably not the best approach.  Someone with a more
delicate touch could probably have gotten more done.)

Sincerely,
Jonathan


--
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/20120502063443.GA2691@burratino

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Tue, May 01, 2012 at 05:22:34PM -0700, Russ Allbery a écrit :
> 
> See, for example, the --help output of any recent configure script:
> 
> | Some influential environment variables:
> |   CC  C compiler command
> |   CFLAGS  C compiler flags
> |   LDFLAGS linker flags, e.g. -L if you have libraries in a
> |   nonstandard directory 
> |   LIBSlibraries to pass to the linker, e.g. -l
> |   CPPFLAGS(Objective) C/C++ preprocessor flags, e.g. -I if
> |   you have headers in a nonstandard directory 
> |   CPP C preprocessor

Thanks.  I have updated our upstream guide on wiki.debian.org, to mention
dpkg-buildflags and the variables it sets.

Perhaps somebody more experienced than me can proofread and complement if
needed ?  Here is the current content.

  Some make variables are reserved to the user, and the Automake manual and the
  GNU coding standards advise to never use them for switches that are required
  for proper compilation of the package. When a Debian binary package is built,
  default environment variables are prepared by dpkg-buildflags (In Debian
  Wheezy: CFLAGS, CPPFLAGS, CXXFLAGS, FFLAGS and LDFLAGS), to allow the build
  system to override the corresponding variables in the Makefile. We therefore
  strongly recommend to follow the above advice, and to make your makefiles use
  these variables were relevant, in a way that our build system can override
  them. 

http://wiki.debian.org/UpstreamGuide#Make

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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/20120502060634.ga2...@falafel.plessy.net

Re: Do we really need a 'contrib' area ? (Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware).

[Paul Wise]

On Wed, May 2, 2012 at 8:27 AM, Charles Plessy wrote:

> I actually question if we need our current level of division, which is already
> lower than in other distributions.

Your question seems more appropriate on debian-project.

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

Re: Definition of _boot_

[Clint Byrum]

Excerpts from Ben Hutchings's message of Sun Apr 29 16:27:54 -0700 2012:
> On Sun, Apr 29, 2012 at 11:11:08PM +0200, Svante Signell wrote:
> > On Sun, 2012-04-29 at 21:52 +0100, Ben Hutchings wrote:
> > > On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote:
> > > > Hello,
> > > > 
> > > > In line with the recent discussion, lets aim at defining what _boot_ is:
> > > [...]
> > > 
> > > No, let's not.  Beyond RAM, CPU, IRQ controllers and timers (all
> > > of which are part of the kernel's early initialisation) pretty
> > > much all of this varies from system to system and potentialy from
> > > boot to boot.
> > 
> > I'd assume that. Thank you.
> > 
> > > Further, if I normally log in to my laptop through gdm then gdm most
> > > certainly is part of the boot process *on that laptop*.  And if I set
> > > up a Debian-based system as a web kiosk, starting the web browser is
> > > also part of the boot process *on that system*.
> > 
> > Then why can't we define what _boot_ is then? Single user, multi-user,
> > desktop, laptop, server, with or without X (soon wayland) etc?
>  
> Ignoring special boot modes for the moment, the system is booted when
> its usual services are available.  Exactly what those usual services
> are is determined by package selection and local configuration.  We
> cannot make an exhaustive definition.

Hi,

I personally distill it down to this:

A system is booted when it can perform its intended function.

I do not have a laptop so that it can start udev, or fsck its
filesystems. I have it so I can interact with it. So, when my endpoint
UI is available, it is booted.

I do not have servers so they can configure bonded interfaces, or start
an MTA.  I have them so that they can serve web pages, or database
queries, or queue mail.

So, to me, to "boot" a system is to bring it into service completely.


-- 
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/1335932296-sup-1...@fewbar.com

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Russ Allbery]

Patrick Ouellette  writes:

> Of course the #! line is not the issue.  The issue is two upstream
> maintainers separated by years and miles selected the same generic name
> for their binary file.

I agree with this.

> Compounding the issue, some Debian Maintainer seeking to better the
> project by packaging additional software for the project failed to
> perform "due diligence" in researching if any of the binary names from
> the proposed new package were already in use.  Having packaged the
> software and uploaded it, someone noticed the issue and started us down
> the path we are on.

Maybe we should short-circuit this part of the conversation, since it
doesn't sound like you're horribly interested in agreeing to change the
name of node in the existing package.  :)

I think it would make sense to take this to the Technical Committee at
this point and just make a decision, unless anyone thinks something
substantially new is likely to turn up.  (We should probably give it a few
more days to see if anything does, but it's feeling increasingly unlikely
to me, as is the idea that we're all going to reach a consensus.)

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

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Patrick Ouellette]

On Tue, May 01, 2012 at 03:24:58PM -0700, Russ Allbery wrote:
> Date: Tue, 01 May 2012 15:24:58 -0700
> From: Russ Allbery 
> Subject:  Re: [Pkg-javascript-devel] Node.js and it's future in debian
> To: debian-devel@lists.debian.org
> 
> Patrick Ouellette  writes:
> > On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote:
> 
> >> Node.js is becoming quite popular and is known generally to use "node" 
> >> in its hash-bang.
> 
> > Seriously? People are writing scripts that start
> > #!node
> 
> The #! part is really not the issue, since the two packages don't conflict
> there (the ham radio one is in /usr/sbin).
> 

Of course the #! line is not the issue.  The issue is two upstream maintainers
separated by years and miles selected the same generic name for their binary
file.  Compounding the issue, some Debian Maintainer seeking to better the
project by packaging additional software for the project failed to perform
"due diligence" in researching if any of the binary names from the proposed
new package were already in use.  Having packaged the software and uploaded
it, someone noticed the issue and started us down the path we are on.

> However, Googling for Node.js tutorials and documentation actually reveal
> that people usually *don't* use #!, which would avoid the conflict, and
> instead run "node ".  Which means when both packages are installed,
> which node they get depends on what their PATH looks like, which is the
> sort of conflict that we try to avoid.
> 

So Google says most people run the files interactively from the command
line, almost never from scripts? 

Be careful using search engine results to support your position.  You
can usually skew the results depending on which search engine you use
and how you word the search.

Do you still do things (especially repetitive things) the way you learned
in the tutorial/documentation?  Do you automate processes with shell scripts,
or type the command each time?


Pat


-- 
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/20120502031200.gb18...@flying-gecko.net

Re: Definition of _boot_

[Ben Hutchings]

On Tue, May 01, 2012 at 10:36:58PM +0200, Svante Signell wrote:
> On Mon, 2012-04-30 at 20:30 +0200, Vincent Bernat wrote:
> > OoO En  ce doux  début de matinée  du lundi  30 avril 2012,  vers 08:15,
> > Svante Signell  disait :
> > 
> > >> I'm rather sure that he wants to define booting as part of what
> > >> currently is done in /etc/rcS.d.  Configuring the network or mounting
> > >> non-essential remote file systems wouldn't be part of this definition.
> > >> 
> > >> Then he would state that these early tasks do not need events at all,
> > >> and conclude that later tasks can be handled in event based userspace
> > >> tools, but that the initial process that invokes these event based tools
> > >> doesn't require events and thus can stay simple.
> > 
> > > Nice summary, thanks. This is the whole idea behind defining boot...
> > > Some people get it, others don't.
> > 
> > Since your  boot definition  is mostly the  current initrd, you  seem to
> > agree that the current init system could be replaced with something more
> > current like upstart and systemd.
> 
> On the contrary, with this definition init scripts are sufficient, and
> the event-based stuff happens later, e.g. with event based user space
> tools, udev<->linux kernel.
 
So your definition is circular: booting is what you can do with the
current init scripts, therefore the current init scripts are fine for
booting.  Unsurprisingly, you didn't persuade others to agree with
this definition.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120502015309.gw3...@decadent.org.uk

Re: switching from exim to postfix

[Vincent Lefevre]

On 2012-05-01 18:55:20 +0300, Riku Voipio wrote:
> On Tue, May 01, 2012 at 12:48:10AM -0400, Chris Knadle wrote:
> > I think it would be useful to describe what issue(s) there are concerning 
> > 8BITMIME and why this is important.  I've found some information [1] about 
> > this, but it isn't clear what problems are actially *caused* by the lack of 
> > 8BITMIME support by default in Exim.  Is it just slow sending of outbound 
> > attachments?
> 
> It's both extra traffic (not that much if western encodings) and extra
> cpu work. In lesser annoyance, it means that you no longer can read
> mailbox files with non-mime capable readers (for example less) with ease,
> as there will be qp encodings here and there. People who only use english
> only hit the issue when having lines longer than 76 characters.

It might also affect spam detection.

Now, the main reason I dislike Exim is

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

Basically, when invoked as sendmail, Exim breaks the sendmail
compatibility by keeping the Bcc header, involving security
and/or privacy problems. And since this is by design, it won't
be fixed.

BTW, since it must accept 8-bit mail via this interface, it is
also broken as the mail may be sent to a MTA that doesn't announce
8BITMIME, since Exim doesn't know to do the conversion. :)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20120502010917.ga5...@xvii.vinc17.org

Re: switching from exim to postfix

[brian m. carlson]

On Tue, May 01, 2012 at 07:47:08PM +0100, Roger Lynn wrote:
> I have enabled accept_8bitmime in every exim I've installed for the last
> 10 years and no one has reported any problems. I think the risk of
> encountering a truly 7 bit MTA in this decade is low enough to be
> ignored for most purposes. Anyone still using one is likely to find that
> a substantial fraction of their incoming mail is corrupted.

I actually use Sendmail's strict 8BITMIME support to help catch spam.  I
agree that 7-bit MTAs are essentially gone, but with the volume of spam
I receive, I set my mail software to be extremely strict with regard to
protocols.  Legitimate software (of any sort) generally generates
protocol-compliant messages.  Malicious and illicit software (and that
created by Microsoft) generally does not.  Legitimate software also
generally has a userbase that will complain about rejected data if the
software is not protocol-compliant, which often leads to fixes.

I've complained to the listmasters that they send 8-bit data that is not
MIME (virtually all of which is spam) under the auspices of the 8BITMIME
extension; they refuse to fix this, and as a consequence they have to
deal with the occasional piece of undeliverable mail.  This is not a
knock against the listmasters, just an observation that if you violate
the protocols, some places will reject your data.

-- 
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: Bug#671130: ITP: gesftpserver -- sftp server submodule for OpenSSH

[Russ Allbery]

Jonas Smedegaard  writes:

> * Package name: gesftpserver
>   Version : 0.1
>   Upstream Author : Richard Kettlewell
> * URL : https://github.com/ewxrjk/sftpserver
> * License : GPL-2+
>   Programming Lang: C
>   Description : sftp server submodule for OpenSSH

>  Green End SFTP Server is an SFTP server supporting up to protocol
>  version 6.  It is possible to use it as a drop-in replacement for the
>  OpenSSH server.

For the eventual package long description, it would be good to add some
explanation of *why* one would want to use it as a drop-in replacement for
the OpenSSH server.  Presumably it adds some additional features?

The upstream README is not particularly informative on that front.

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

Bug#671130: ITP: gesftpserver -- sftp server submodule for OpenSSH

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: gesftpserver
  Version : 0.1
  Upstream Author : Richard Kettlewell
* URL : https://github.com/ewxrjk/sftpserver
* License : GPL-2+
  Programming Lang: C
  Description : sftp server submodule for OpenSSH

 Green End SFTP Server is an SFTP server supporting up to protocol
 version 6.  It is possible to use it as a drop-in replacement for the
 OpenSSH server.
 .
 NB! This server is currently experimental and still under development.
 Don't trust your critical data to it.  The code has an extensive and
 growing test suite (invoke 'make check' to run it) but bugs may yet
 remain.



-- 
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/20120502003237.20284.94028.report...@auryn.jones.dk

Do we really need a 'contrib' area ? (Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware).

[Charles Plessy]

Hi again,

I actually question if we need our current level of division, which is already
lower than in other distributions.  How often do people enable contrib without
non-free ?  Doing so would be to install packages such as the ones discussed
every year on that list, which do not trigger installation of non-free
material, but are narrowly specialised to some non-Free, non-packaged data or
code.  That could go in main, and the rest in non-free, without major changes
the definition of these two areas: main is DFSG-free and self-contained from a
packaging point of view (I do not see workable alternative points of view), and
non-free contains packages which, when installed, cause non-Free materials to
be installed automatically on the system with apt's default configuration.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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/20120502002724.gc1...@falafel.plessy.net

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Charles Plessy  writes:

> This said, the point that I want to make, is that we switched from a
> situation where the actual communication channel between our and
> upstreams makefile was C(XX)FLAGS, to a situation where CPPFLAGS and
> LDFLAGS also got some data input in by our toolchain.  If there are
> other variables that forseen to be used the same way in the future, it
> would be great to document it somewhere, so that we can be prepared.

Other than CC and CPP (the compiler and preprocessor, which you rarely
need to change), LIBS is the only other one, and that's specifically for
libraries to link with.

Other than the flags for Fortran (and similar for other languages), that's
the complete set of variables that Autoconf cares about for communication
with the compiler and the build system, and that set has been unchanged
for quite a while.  I don't expect it to change in the future, or at least
if it does we'll have lots of warning.

See, for example, the --help output of any recent configure script:

| Some influential environment variables:
|   CC  C compiler command
|   CFLAGS  C compiler flags
|   LDFLAGS linker flags, e.g. -L if you have libraries in a
|   nonstandard directory 
|   LIBSlibraries to pass to the linker, e.g. -l
|   CPPFLAGS(Objective) C/C++ preprocessor flags, e.g. -I if
|   you have headers in a nonstandard directory 
|   CPP C preprocessor

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

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Mon, Apr 30, 2012 at 03:46:51PM -0700, Russ Allbery a écrit :
> 
> Most C programs use Autoconf in my experience.  I know that scientific
> software often doesn't, but I think scientific software is the significant
> outlier in that respect.

I see...  That probably explains everything.  My experience was indeed that
most software do not use autoconf, put everything in CFLAGS, and that CPPFLAGS
and LDFLAGS were very rarely used (I hope that also answers Bernhards
interrogations).  We enabled hardening in some of these packages using
Dephelper 9 or CDBS, only to realise later that D_FORTIFY_SOURCE=2 and
-Wl,-z,relro were left out.

This said, the point that I want to make, is that we switched from a situation
where the actual communication channel between our and upstreams makefile was
C(XX)FLAGS, to a situation where CPPFLAGS and LDFLAGS also got some data input
in by our toolchain.  If there are other variables that forseen to be used the
same way in the future, it would be great to document it somewhere, so that we
can be prepared.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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/20120502001705.gb1...@falafel.plessy.net

Re: Node.js and it's future in debian

[Carsten Hey]

* Patrick Ouellette [2012-05-01 16:55 -0400]:
> I was under the impression that neither package was going to move forward with
> a binary named "node"

Some proposed this, some agreed, others did not.

In the just reported bug #671120 I wrote regarding this neither package
should get the name part of the policy:
| The common reading of the according section does neither match what
| seems to be the original intention [1] nor my common sense.
|
|  [1] http://lists.debian.org/<879142cjni@slip-61-16.ots.utexas.edu>


> The proposal was made for a transition plan to be made then the nodejs
> person quit talking/posting.

Ian's proposal was as far as I understood it when reading it basically
rolling a dice and I hope that I either misread it or that it was meant
as a joke.


If the node package needs to rename the binary it obviously needs a new
name ;)  Hamish suggested axnode once, the patch lying in the BTS uses
ax25-node.  Do you have any preference in case it is needed?


Thanks for caring about this thread.

Carsten


-- 
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/20120501223105.gb14...@furrball.stateful.de

Re: Node.js and it's future in debian

[Patrick Ouellette]

On Tue, May 01, 2012 at 01:07:11AM +0200, Carsten Hey wrote:
> Date: Tue, 1 May 2012 01:07:11 +0200
> From: Carsten Hey 
> Subject:  Re: Node.js and it's future in debian
> To: debian-devel@lists.debian.org
> Mail-Followup-To: Carsten Hey ,
>  debian-devel@lists.debian.org
> 
> * Carl Fürstenberg [2012-04-28 03:31 +0200]:
> > There has been an log struggle between the nodejs package and the node
> > package, which is still unresolved (bug #611698 for example) And I
> > wonder now what the future should look like.
> 
> In short I think that there is only one sane solution to this and that
> the way to reach this solution is to ask the tech-ctte for a decision.
> 
> 
> This is the second thread about this topic on -devel, the first one was
> in November 2011.  In both threads and in some smaller ones, people
> basically claimed things like (incomplete list):

It is at least the third discussion that I can remember.

> Given that node is a rarely used daemon and that nodejs is a widely used
> language, I think that nodejs should get the binary name node; but due
> to the non-responsiveness of node's maintainers I think this might be
> a case where involving the tech-ctte would help.
> 
> node's maintainers don't participate in such discussions in a reasonable
> and timely manner, for example the RC bug had no action for months
> despite the patch and nobody ever explained what exactly the problem of
> a changed binary name for a daemon would be (node can be used
> interactively, but it is not supposed to be used that way and those
> users that do would be able to set up an alias anyway).  The first
> answer from one of the uploaders was sent nearly a year after nodesjs'
> maintainer asked about this issue on the maintainer's list (back then he
> didn't seem to notice that those who answered were unrelated to the node
> package).  The subject of the -devel thread last year "Is anyone
> maintaining (the ham radio tool) node?" speaks for itself.

So expel all the maintainers for having a real life and not living and
breathing only the Debian project and it's fire hose like mailing lists.

If timeliness is an issue, email the maintainer(s) directly.  No other
package is subverted because of slowness to address a bug (the exception
being NMU uploads, which I would not class as subverting the package).
Packages are dropped from the release for RC bugs.

A package that has been in Debian for YEARS should not expect a RC 
bug to be filed on the basis on a name space collision. (Otherwise
look out for your favorite executable, because someone WILL name the
"next new thing" with the same name.)

As was put forth in the "Is anyone maintaining" thread, node is a fairly 
mature piece of code that has been working without major upstream changes
because it does the job it was written to do.

> 
> I assume all of node's uploaders did great work on many ham related
> packages, but all that the two uploaders that replied to this issue
> during the last two years did related to the node package is that they
> also replied to the "Call for debian hamradio developers pool" from
> node's actual but now retired maintainer who then added them as
> uploaders.  Only Hamish, who did not respond to this issue, uploaded
> node once in 2005, the others did never do any upload.  The responses
> from the other two uploaders were essentially "please report a bug"
> (although this was already done) by one; and "... then no package should
> get the name" and in one mail "this patch needs to be tested by someone
> who runs node and nodejs" by the other.
> 

There hasn't been any upstream changes in node for a long time.  The package
builds fine in the auto-builders and does what it was designed to do.

The number of active ham radio maintainers has varied over time, just like
other packages.  Right now there are only a few, and most of us are busy
(just like everyone else).

-- 
,-.
> Patrick Ouellette   | It is not fitting, when one is in God's service,  <
> pat(at)flying-gecko.net | to have a gloomy face or a chilling look. <
> Amateur Radio: NE4PO| -- Francis of Assisi  <
`-'


-- 
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/20120501213654.gl30...@flying-gecko.net

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Russ Allbery]

Patrick Ouellette  writes:
> On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote:

>> Node.js is becoming quite popular and is known generally to use "node" 
>> in its hash-bang.

> Seriously? People are writing scripts that start
> #!node

The #! part is really not the issue, since the two packages don't conflict
there (the ham radio one is in /usr/sbin).

However, Googling for Node.js tutorials and documentation actually reveal
that people usually *don't* use #!, which would avoid the conflict, and
instead run "node ".  Which means when both packages are installed,
which node they get depends on what their PATH looks like, which is the
sort of conflict that we try to avoid.

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

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Patrick Ouellette]

On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote:
> Node.js is becoming quite popular and is known generally to use "node" 
> in its hash-bang.

Seriously? People are writing scripts that start
#!node

That is truely messed up!

Pat

-- 
,-.
>   Patrick Ouellette |   Lord, grant that I might not so much seek   <
>   pat(at)flying-gecko.net   |   to be loved as to love. <
>   Amateur Radio: NE4PO  |   -- Francis of Assisi<
`-'


-- 
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/20120501211803.gk30...@flying-gecko.net

Re: Node.js and it's future in debian

[Patrick Ouellette]

On Fri, Apr 27, 2012 at 08:26:47PM -0700, Russ Allbery wrote:
> 
> > Contrast that with the positive actitude of the NFS developers of CITI
> > at UMichi when heimdal-dev and libgssapi-dev both contained
> > /usr/lib/libgssapi.a [1]. They went to the trouble of renaming libgssapi
> > to libgssglue.
> 
> Indeed, and I'm very grateful for that.  But realistically that was also a
> lot easier than renaming Node.js's interpreter, and I think the CITI folks
> did actually know that was coming.  The conflict had already been pointed
> out in the Kerberos community and had been discussed prior to it coming up
> here.  But more significantly that library was essentially used only by
> NFS, so only a few clients had to change and the renaming was fairly
> straightforward.

The Node.js developer KNEW there were other binaries named node, and just
went on as if it did not matter.  Check the development history/blog.

> 
> Node.js is at this point another matter; it's the topic of books,
> widespread use independent of the upstream developers, and lots of
> articles and Internet documentation with a life of its own.  A quick
> Google search comes up with tons of indepedent sites telling people to run
> programs with "node ".  That makes renaming a much more
> difficult prospect.

And the ham radio binary is the subject of sections of how-to's and books
on amateur radio.  It also has "a life of it's own" in the ham radio
community.

If a binary's name is simply a matter of a popularity contest in Debian,
at some point every name may be made to change.

-- 
,-.
>   Patrick Ouellette |It is in pardoning that we are pardoned.   <
>   pat(at)flying-gecko.net   |-- Francis of Assisi   <
>   Amateur Radio: NE4PO  |   <
`-'


-- 
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/20120501211011.gj30...@flying-gecko.net

Bug#671117: ITP: openlp -- OpenLP is an open source church worship presentation application.

[Raoul Snyman]

Package: wnpp
Severity: wishlist
Owner: Raoul Snyman 

* Package name: openlp
  Version : 1.9.9
  Upstream Author : Raoul Snyman 
* URL : http://openlp.org/
* License : GPL
  Programming Lang: Python
  Description : OpenLP is an open source church worship presentation 
application.

OpenLP is free church presentation software, or lyrics projection software, 
used to display slides of songs, Bible verses, videos, images, and even 
presentations for church worship using a computer and a data projector.



-- 
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/20120501214052.2873.91548.report...@zoot.lan.labs

Re: Node.js and it's future in debian

[Steve Langasek]

[Dropped Cc; what does any of this have to do with the DPL?]

On Tue, May 01, 2012 at 04:32:49PM -0500, Jonathan Nieder wrote:
> Steve Langasek wrote:
> > On Tue, May 01, 2012 at 03:30:50PM -0500, Jonathan Nieder wrote:

> >> Wait, really?  What happened to respect by maintainers for the
> >> project?

> > "The project" is not "a set of random maintainers who have a filename
> > conflict with you".

> Sorry, I don't understand the above sentence.  Do you mean that it is
> impossible to come to a consensus when one maintainer of a relevant
> package disagrees?  I can understand that claim, but it doesn't seem
> to be the same as the sentence above.

I mean that it is not reasonable to expect a maintainer to recognize a
"consensus" among other people who are not the maintainer, where his or her
package is concerned, except when that's a consensus of a
constitutionally-empowered body such as the TC.

> >  We have a constitution to *prevent* such decisions
> > being made by a tyranny of the majority of the minority.

> Thanks, that perhaps suggests a method for resolving this.  Could you
> point to the section of the constitution you are referring to?

I am bewildered that I should need to point this out:

  6. Technical committee

  6.1. Powers

  The Technical Committee may:

  [...]

  2. Decide any technical matter where Developers' jurisdictions overlap.

 In cases where Developers need to implement compatible technical
 policies or stances (for example, if they disagree about the priorities
 of conflicting packages, or about ownership of a command name, or about
 which package is responsible for a bug that both maintainers agree is a
 bug, or about who should be the maintainer for a package) the technical
 committee may decide the matter.

As you seem to be involved with various process discussions within Debian,
may I gently suggest that you familiarize yourself with our governing
document? :)

> > NMUs are *not* a tool for forcing a maintainer to accept a technical
> > outcome he disagrees with.

> Sure.  To be clear, I should say that I am not advocating that anyone
> NMU the node or nodejs package.  What I meant (and I could easily be
> wrong) is that when the maintainer of a package is not working on an
> important bug and has not given any reason, Debian does not need to be
> held hostage by that.

Ok - sorry, that's not what came across in your message, it's possible I
overlooked some context up-thread that would have made this clear.  Yes, a
bug that's been filed against the package and gone unanswered by the
maintainer is fair game for NMUing.  OTOH, a bug that the maintainer
disagrees is a bug would not be fair game.

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


-- 
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/20120501220033.gd5...@virgil.dodds.net

Re: Node.js and it's future in debian

[Russ Allbery]

Patrick Ouellette  writes:
> On Fri, Apr 27, 2012 at 08:26:47PM -0700, Russ Allbery wrote:

>> Indeed, and I'm very grateful for that.  But realistically that was
>> also a lot easier than renaming Node.js's interpreter, and I think the
>> CITI folks did actually know that was coming.  The conflict had already
>> been pointed out in the Kerberos community and had been discussed prior
>> to it coming up here.  But more significantly that library was
>> essentially used only by NFS, so only a few clients had to change and
>> the renaming was fairly straightforward.

> The Node.js developer KNEW there were other binaries named node, and
> just went on as if it did not matter.  Check the development
> history/blog.

The important part is the last sentence: changing the name was fairly
easy.  Also, upstream was willing to change it, which in this case I doubt
is the case (although we can certainly ask).

>> Node.js is at this point another matter; it's the topic of books,
>> widespread use independent of the upstream developers, and lots of
>> articles and Internet documentation with a life of its own.  A quick
>> Google search comes up with tons of indepedent sites telling people to
>> run programs with "node ".  That makes renaming a much
>> more difficult prospect.

> And the ham radio binary is the subject of sections of how-to's and
> books on amateur radio.  It also has "a life of it's own" in the ham
> radio community.

That community is much smaller, and the binary isn't invoked directly by
users, which makes the impact fairly minimal in practice.

You aren't going to get any argument that the Node.js upstream did
something that was at the least rude.  But we have no control over that,
unfortunately.  We have to live with the consequences, and I think
usability for our users is more important than fairness if they come
directly in conflict, which I think they are in this case.

> If a binary's name is simply a matter of a popularity contest in Debian,
> at some point every name may be made to change.

I think that assertion is unsupported.  We don't encounter situations like
this that frequently.  We will continue to encounter them, but I think
we're talking about a case every year or two.

-- 
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/877gwvwohd@windlord.stanford.edu

Re: Node.js and it's future in debian

[Patrick Ouellette]

On Sat, Apr 28, 2012 at 03:31:02AM +0200, Carl Fürstenberg wrote:
> 
> There has been an log struggle between the nodejs package and the node
> package, which is still unresolved (bug #611698 for example) And I
> wonder now what the future should look like.
> 
> To summarize the problem:
> * the nodejs upstream binary is called "node", and the upstream
> developers have refused to change it's binary name to nodejs for
> debian;
> * The the hamradio package "node" shipping a binary called "node", and
> as it's so old, the developers argue that the package must ship a
> binary called "node" or breakage will occur.
> * The reason the nodejs developers want to ship the binary as "node"
> is because all programs written for nodejs all has /usr/bin/node in
> it's shebang
> * the nodejs package are not allowed to conflict on the node package
> just because the binary name is the same
> 
> As I'm not a hamradio user, I'm off course biased towards letting
> nodejs having the "node" binary and let it pass to testing. But we
> must find a solution to this, as nodejs is getting more and more used,
> and developers are forced to install nodejs from source to be able to
> use it instead of install it via the package manager.
> 

I was under the impression that neither package was going to move forward with
a binary named "node" 

The proposal was made for a transition plan to be made then the nodejs 
person quit talking/posting.

Pat
-- 
,-.
>  Patrick Ouellette|   Start by doing what's necessary; then do  <
>  pat(at)flying-gecko.net  |   what's possible; and suddenly you are doing   <
>  Amateur Radio: NE4PO |   the impossible.  -- Francis of Assisi <
`-'


-- 
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/20120501205524.gi30...@flying-gecko.net

Re: Node.js and it's future in debian

[Jonathan Nieder]

Steve Langasek wrote:
> On Tue, May 01, 2012 at 03:30:50PM -0500, Jonathan Nieder wrote:

>> Wait, really?  What happened to respect by maintainers for the
>> project?
>
> "The project" is not "a set of random maintainers who have a filename
> conflict with you".

Sorry, I don't understand the above sentence.  Do you mean that it is
impossible to come to a consensus when one maintainer of a relevant
package disagrees?  I can understand that claim, but it doesn't seem
to be the same as the sentence above.

>  We have a constitution to *prevent* such decisions
> being made by a tyranny of the majority of the minority.

Thanks, that perhaps suggests a method for resolving this.  Could you
point to the section of the constitution you are referring to?

> NMUs are *not* a tool for forcing a maintainer to accept a technical outcome
> he disagrees with.

Sure.  To be clear, I should say that I am not advocating that anyone
NMU the node or nodejs package.  What I meant (and I could easily be
wrong) is that when the maintainer of a package is not working on an
important bug and has not given any reason, Debian does not need to be
held hostage by that.

Jonathan


-- 
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/20120501213249.GB1044@burratino

Re: switching from exim to postfix

[Jon Dowland]

On Tue, May 01, 2012 at 09:30:23PM +0200, Andrew Shadura wrote:
> Hello,
> 
> On Tue, 1 May 2012 20:18:07 +0200
> Philipp Kern  wrote:
> 
> > So just stop Postfix doing the conversion?  Or teach Exim to announce
> > 8BITMIME by default.
> 
> No, Exim should not announce 8BITMIME, or it will violate RFC, not
> otherwise.

Only if it forwards the mail: if delivery stops on the local host, then
there isn't a problem. So it could be enabled if the debconf question
was answered accordingly without risking violating the RFC afaics


-- 
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/20120501211948.GA17757@debian

Re: switching from exim to postfix

[Chris Knadle]

On Tuesday, May 01, 2012 11:55:20, Riku Voipio wrote:
> On Tue, May 01, 2012 at 12:48:10AM -0400, Chris Knadle wrote:
...
> > The quoted 2010 survey [2] showed Exim was the most popular MTA (which I
> > found surprising), deployment of Exim growing just slightly faster than
> > Postfix, and everything else falling in popularity.
> 
> I think it is because other distro's have mostly stopped shipping
> anything that listens on port 25 by default.

By default selecting "standard system" during the Debian Squeeze netinstall 
installs Exim, but it only listens on port 25 on localhost, and not the public 
interface.  [IIRC I believe that was the default in Lenny also.]  I'm pretty 
sure this means that by default the local MTA won't show up on the internet.

...
> > > So yes, switching to postfix by default  would reduce the workload of
> > > email servers around the globe (no need to burn cpu cycles and thus
> > > co2 to convert emails to quoted-printable).
> > 
> > The statistics quoted showed that Exim was most popular, so wouldn't
> > switching to Postfix by default actually be more CPU costly than the
> > reverse?  :-/  [I'm not saying you're wrong, just that I don't see the
> > logic in the argument.]
> 
> The less there are MTA's out there not announcing 8bitmime, the less
> conversions there will be (eventually). While the exim->exim deliveries
> are not generating conversions (unless the MUA does it), exim is still
> only at 34% of mx, not 34% of the traffic.

Yes that makes sense -- DNS MX records are probably easier to test for.  
Agreed that the % of traffic is not captured in the statistics -- however the 
number of MX records per MTA is more relevant than % of traffic per MTA to the 
arugument you brought up anyway, because that had to do with the number of 
installs and thus the number of boxes needing to switch the installed MTA.  
;-)  [BTW I found it odd that Qmail wasn't in the top 20 in terms of 
deployments vs MX records, and perhaps it is in terms of % of net traffic.]

> > I've likewise often wondered if a low-resource MTA like DMA or ssmtp
> > could be the default MTA for Desktop installs (and I've occasionally
> > tried them), but as has been discussed there seem to be some issues with
> > the idea.  In my case for Desktops I want the local MTA to be able to
> > handle sending local outbound mail to a server via port 587 over TLS
> > with authentication, to retry sending at increasing time intervals,
> > using a "queue runner" but without a daemon listening, and to notify the
> > sender on a permanent failure.  Thusfar I've only been able to find all
> > of that in a full-fledged MTA.
> 
> Indeed, switching to a lightweight mta like dma as default makes probably
> more sense than switching by default postfix. I tried ssmpt and it didn't
> work for me.. Would dma do TLS auth and queque fine?

Yes, it looks like it can.  Manpage [1] example setup [2].

The Readme.Debian document that comes with the dma package also states that 
although a cron job is run by default every 5 minutes, that does *not* mean a 
sending attempt is made every 5 minutes -- dma does an exponential back-off on 
successive sending failures.  It can also notify the sender of sending 
failures [and has a "double bounce" setting in case the sender's address also 
bounces].

I'm testing it now -- looks promising.  Might be worth further consideration 
for a default MTA.


[1] http://manpages.ubuntu.com/manpages/natty/man8/dma.8.html

[2] http://www.dragonflybsd.org/docs/howtos/HowTo_dma_gmail/

  -- Chris

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


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

Re: RFC: OpenRC as Init System for Debian

[Carlos Alberto Lopez Perez]

On 27/04/12 19:33, Tollef Fog Heen wrote:
> ]] Martin Wuertele 
> 
>> * Josselin Mouette  [2012-04-27 09:53]:
>>
>>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
> Yes of course, because event-driven init systems have *always* been
> *only* about mounting USB devices. 

 Then explain the _real_ reasons for having an event driven boot system!
>>>
>>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
>>
>> That's a reason for udev/mdev, however I still fail to see why this
>> results in the requirement for an event based boot process. 
> 
> A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
> mounted and /srv/somewhere comes off iscsi, which means it requires
> networking to be up, which means network drivers loaded, etc.  So the
> event «network driver loaded» causes ifup to be spawned, which causes
> $network to be satisfied which causes the iscsi daemons to be started
> which causes mount to be called.
> 

A better example is bluetooth.

In my Debian system I have /usr/sbin/bluetoothd running and I don't have
any bluetooth devices on my system... So wouldn't be better that instead
of launching the bluetooth daemon and let it waiting for the day that I
plug a USB bluetooth device (and still I never did that) to just launch
this daemon only when the kernel detects a bluetooth device?


"""
For a fast and efficient boot-up two things are crucial:

* To start less.
* And to start more in parallel.

What does that mean? Starting less means starting fewer services or
deferring the starting of services until they are actually needed. There
are some services where we know that they will be required sooner or
later (syslog, D-Bus system bus, etc.), but for many others this isn't
the case. For example, bluetoothd does not need to be running unless a
bluetooth dongle is actually plugged in or an application wants to talk
to its D-Bus interfaces. Same for a printing system: unless the machine
physically is connected to a printer, or an application wants to print
something, there is no need to run a printing daemon such as CUPS.
Avahi: if the machine is not connected to a network, there is no need to
run Avahi, unless some application wants to use its APIs. And even SSH:
as long as nobody wants to contact your machine there is no need to run
it, as long as it is then started on the first connection. (And admit
it, on most machines where sshd might be listening somebody connects to
it only every other month or so.)

Starting more in parallel means that if we have to run something, we
should not serialize its start-up (as sysvinit does), but run it all at
the same time, so that the available CPU and disk IO bandwidth is maxed
out, and hence the overall start-up time minimized.
""" http://0pointer.de/blog/projects/systemd.html

-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: switching from exim to postfix

[Philipp Kern]

On Tue, May 01, 2012 at 09:30:23PM +0200, Andrew Shadura wrote:
> On Tue, 1 May 2012 20:18:07 +0200
> Philipp Kern  wrote:
> 
> > So just stop Postfix doing the conversion?  Or teach Exim to announce
> > 8BITMIME by default.
> 
> No, Exim should not announce 8BITMIME, or it will violate RFC, not
> otherwise. Now it doesn't announce it, but accepts, so RFC-compliant
> MUA or other MTA should do the conversion themselves and everything
> just works. If it announces the support, it effectively lies as it
> doesn't support conversion which is needed if it wants to send mail to
> non-compliant MTA.

If I use sendmail it will happily accept 8bit, because there's no way to tell
if the MTA is 8BITMIME-compliant.  And POSIX doesn't mandate 7bit, does it?

> I wonder why many people in this thread still don't understand this.
> And also I can't see why some find this annoying behaviour or something
> wrong. There's absolutely nothing wrong with what it does now, as
> re-encoding will happen somewhere anyway as there are still many really
> non-8-bit-compliant MTAs, so why should Exim do this?

Exim transmits 8bit mails to non-8bit-compliant MTAs, so what exactly are you
arguing?

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Node.js and it's future in debian

[Steve Langasek]

On Tue, May 01, 2012 at 03:30:50PM -0500, Jonathan Nieder wrote:
> > I was talking about a consensus among the maintainers of the affected
> > packages.  Even if all but the maintainers of one of the affected
> > packages would agree to a solution, there would be no way to implement
> > this solution without asking the tech-ctte or (what would be not
> > appropriate for this) a GR.

> Wait, really?  What happened to respect by maintainers for the
> project?

"The project" is not "a set of random maintainers who have a filename
conflict with you".  We have a constitution to *prevent* such decisions
being made by a tyranny of the majority of the minority.

>  What happened to NMUs when a maintainer is stalling work?

NMUs are *not* a tool for forcing a maintainer to accept a technical outcome
he disagrees with.  It's demotivating enough to be overridden, without it
coming in the form of a fellow developer taking matters into his own hands.

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


-- 
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/20120501205624.gc5...@virgil.dodds.net

Re: Definition of _boot_

[Svante Signell]

On Mon, 2012-04-30 at 20:30 +0200, Vincent Bernat wrote:
> OoO En  ce doux  début de matinée  du lundi  30 avril 2012,  vers 08:15,
> Svante Signell  disait :
> 
> >> I'm rather sure that he wants to define booting as part of what
> >> currently is done in /etc/rcS.d.  Configuring the network or mounting
> >> non-essential remote file systems wouldn't be part of this definition.
> >> 
> >> Then he would state that these early tasks do not need events at all,
> >> and conclude that later tasks can be handled in event based userspace
> >> tools, but that the initial process that invokes these event based tools
> >> doesn't require events and thus can stay simple.
> 
> > Nice summary, thanks. This is the whole idea behind defining boot...
> > Some people get it, others don't.
> 
> Since your  boot definition  is mostly the  current initrd, you  seem to
> agree that the current init system could be replaced with something more
> current like upstart and systemd.

On the contrary, with this definition init scripts are sufficient, and
the event-based stuff happens later, e.g. with event based user space
tools, udev<->linux kernel.


-- 
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/1335904618.3707.192.ca...@hp.my.own.domain

Re: Node.js and it's future in debian

[Jonathan Nieder]

Carsten Hey wrote:

> I was talking about a consensus among the maintainers of the affected
> packages.  Even if all but the maintainers of one of the affected
> packages would agree to a solution, there would be no way to implement
> this solution without asking the tech-ctte or (what would be not
> appropriate for this) a GR.

Wait, really?  What happened to respect by maintainers for the
project?  What happened to NMUs when a maintainer is stalling work?

[...]
> node.js might not be that widespread in use as python, but shipping
> a node.js with /usr/bin/nodejs seems to be broken in a similar way as
> the above example.

I would agree with you if we were proposing going forward against
upstream's wishes.  But I was not proposing that --- we don't know
upstream's wishes yet, but I was going to send a patch once we know
it works.  Sorry for the lack of clarity.

This kind of thing has precedent.  For example, there is gmake and
there are commands like axlisten.

Hoping that clarifies a little,
Jonathan


-- 
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/20120501203050.GA32510@burratino

Re: Node.js and it's future in debian

[Carsten Hey]

* Jonathan Nieder [2012-05-01 12:57 -0500]:
> Carsten Hey wrote:
>
> > I don't think that there ever will be a consensus in all those
> > discussions without discussing in a reasonable way (which failed in the
> > past multiple times).
>
> Note that a consensus does not imply everyone agreeing.

I was talking about a consensus among the maintainers of the affected
packages.  Even if all but the maintainers of one of the affected
packages would agree to a solution, there would be no way to implement
this solution without asking the tech-ctte or (what would be not
appropriate for this) a GR.

> I am starting
> to see a consensus already and would welcome well reasoned opinions
> and clarifications that show where my understanding is lacking.
>
> By the way, separate from what happens to the "node" command are a few
> other questions:
>
>  - Can we come up with alternate names for both commands, so while
>Debian users might be using the "node" command, Debian packages do
>not need to?

nodejs for node.js and ax25-node for the ham radio node.  If ax25-node
is not appropriate, then one of the debian-hams can suggest something
more appropriate.

>I think on the Node.js side this is basically a solved problem,

I would consider a Linux distribution that uses /usr/bin/monty-python as
binary for the python language to be utterly broken.  Users of it would
not be able to run any python script without adapting its shebang. Even
making /usr/bin/python a symlink that can be changed between a game and
the language would not make the situation any better, since users that
do not want to change the shebang line would need to check if the
symlink is set to the language on every box they want to run a python
script on.

node.js might not be that widespread in use as python, but shipping
a node.js with /usr/bin/nodejs seems to be broken in a similar way as
the above example.

Anyway, if the nodejs maintainers would be happy with a hack that
involves changing /usr/bin/node to /usr/bin/nodejs, then there is not
much we could do about this as it's their package.

>  - Is the "node" package undermaintained?  Should it be orphaned to
>encourage active users to take on the burden of its maintenance
>without worrying about stepping on people's toes?

If it would be orphaned, then the problem could be solved easily by
a QA-upload.

It was maintained in a great way until the one that did the last upload
retired from maintaining it in 2009.  I'd assume that a FTBFS bug or
a missing dependency would be solved by the remaining uploaders quickly
(as it happened in 2005 once) and the packages does not require much
attention in general.  I don't think it is orphaned, but I also wouldn't
consider it to be well maintained either.


Carsten


-- 
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/20120501192020.gd17...@furrball.stateful.de

Re: switching from exim to postfix

[Andrew Shadura]

Hello,

On Tue, 1 May 2012 20:18:07 +0200
Philipp Kern  wrote:

> So just stop Postfix doing the conversion?  Or teach Exim to announce
> 8BITMIME by default.

No, Exim should not announce 8BITMIME, or it will violate RFC, not
otherwise. Now it doesn't announce it, but accepts, so RFC-compliant
MUA or other MTA should do the conversion themselves and everything
just works. If it announces the support, it effectively lies as it
doesn't support conversion which is needed if it wants to send mail to
non-compliant MTA.

I wonder why many people in this thread still don't understand this.
And also I can't see why some find this annoying behaviour or something
wrong. There's absolutely nothing wrong with what it does now, as
re-encoding will happen somewhere anyway as there are still many really
non-8-bit-compliant MTAs, so why should Exim do this?

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: switching from exim to postfix

[Roger Lynn]

On 01/05/12 15:10, Chris Knadle wrote:
> I think the reason Exim does not do this protocol conversion is that from the 
> point of view of an MTA author, the point of an MTA is to transmit the body 
> of 
> the message without any modification to it once received, and body 
> modification would be required to convert 8-bit MIME to 7-bit MIME.  I seem 
> to 
> remember reading something along these lines in the Exim documentation years 
> ago and I'm having another look through it, but haven't found a reference to 
> this yet.

http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo
says:
"This option causes Exim to send 8BITMIME in its response to an SMTP
EHLO command, and to accept the BODY= parameter on MAIL commands.
However, though Exim is 8-bit clean, it is not a protocol converter, and
it takes no steps to do anything special with messages received by this
route. Consequently, this option is turned off by default."

I have enabled accept_8bitmime in every exim I've installed for the last
10 years and no one has reported any problems. I think the risk of
encountering a truly 7 bit MTA in this decade is low enough to be
ignored for most purposes. Anyone still using one is likely to find that
a substantial fraction of their incoming mail is corrupted.

Roger


-- 
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/4fa02fac.7060...@rilynn.me.uk

Re: switching from exim to postfix

[Philipp Kern]

On Tue, May 01, 2012 at 06:55:20PM +0300, Riku Voipio wrote:
> It's both extra traffic (not that much if western encodings) and extra
> cpu work. In lesser annoyance, it means that you no longer can read
> mailbox files with non-mime capable readers (for example less) with ease,
> as there will be qp encodings here and there. People who only use english
> only hit the issue when having lines longer than 76 characters.
> 
> Basicly that the qmail author is suggesting is violating the rfc by
> announcing 8bitmime sopport but never doing any conversions if you bump
> into a server that doesn't support 8bitmime. This is the same as the
> exim's accept_8bitmime option.
> 
> In the real world, violating the rfc is a non-issue, as most likely the
> only non-8bitmime compliant servers your server encouters are qmail and exim4,
> both which have no problems with 8bit mails itself.
> 
> Honesstly. my grievance is really just having to convert things to 7bit.. 
> still!

So just stop Postfix doing the conversion?  Or teach Exim to announce 8BITMIME
by default.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Node.js and it's future in debian

[Jonathan Nieder]

Carsten Hey wrote:

> I don't think that there ever will be a consensus in all those
> discussions without discussing in a reasonable way (which failed in the
> past multiple times).

Note that a consensus does not imply everyone agreeing.  I am starting
to see a consensus already and would welcome well reasoned opinions
and clarifications that show where my understanding is lacking.

By the way, separate from what happens to the "node" command are a few
other questions:

 - Can we come up with alternate names for both commands, so while
   Debian users might be using the "node" command, Debian packages do
   not need to?

   (Among other benefits, this would simplify upgrades for people who
   have /usr/sbin too early in $PATH.)

   I think on the Node.js side this is basically a solved problem,
   though help with the actual coding would be welcome.  (E.g., I have
   a patch against upstream 0.7.y that does the right thing, but 0.7.y
   is not packaged for experimental yet.  Feel free to contact me or
   nod...@packages.debian.org if you have time to help.)

   There is a patch taking the first step in this direction for the
   LinuxNode package at  but no
   maintainer has weighed in since then, except to note on
   debian-devel@ that they are having trouble finding someone to test
   the patch.

 - Is the "node" package undermaintained?  Should it be orphaned to
   encourage active users to take on the burden of its maintenance
   without worrying about stepping on people's toes?

Thanks,
Jonathan


-- 
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/20120501175747.GA31508@burratino

Re: Node.js and it's future in debian

[Russ Allbery]

Carsten Hey  writes:

> The origin of what the policy suggests to do if there is no consensus is
> a mail from Guy Maor <879142cjni@slip-61-16.ots.utexas.edu>, in
> which he writes:
> | That's basically a stick to force developers to reach a consensus.

> Christian Schwarz uploaded this change later in this month.

> I don't think that there ever will be a consensus in all those
> discussions without discussing in a reasonable way (which failed in the
> past multiple times).  Previously to this, asking the VP of Engineering
> for a decision was suggested in this thread.

I have to admit that I'm tempted to change Policy from "if there's no
consensus, rename both of them" to "if there's no consensus, try harder to
reach a consensus, and the technical committee decides in last resort."

Most of the time, renaming both of them isn't the right answer.

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

8 bit to 7 bit conversion - was Re: switching from exim to postfix

[Scott Kitterman]

On Tuesday, May 01, 2012 06:55:20 PM Riku Voipio wrote:
...
> Honesstly. my grievance is really just having to convert things to 7bit.. s
...
In the future, you're likely to still be stuck doing this for other 'fun' 
reasons.  The one I ran into recently was that 8 bit -> 7 bit conversions will 
break DKIM signatures, so it's only safe (from a reliability perspective) to 
sign 8 bit mail if you know the entire path is 8 bit clean.  Since there's 
really no way to know that, now I flatten everything to 7 bit and then sign it.

Scott K

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

Re: Node.js and it's future in debian

[Carsten Hey]

* Carsten Hey [2012-05-01 01:07 +0200]:
> Only Hamish, who did not respond to this issue, uploaded
> node once in 2005,

I need to correct myself, Hamish replied once.  In
<20110208230458.ga23...@risingsoftware.com> he wrote:
| I think renaming the node binary to axnode is reasonable and
| consistent with this, but I don't think the nodejs program should be
| using that name either.

Pat replied earlier than I thought, but these earlier replies were
indistinguishable from replies of other people that are not listed in
the uploaders field (i.e., without priorly checking who is listed in
it).


The origin of what the policy suggests to do if there is no consensus is
a mail from Guy Maor <879142cjni@slip-61-16.ots.utexas.edu>, in
which he writes:
| That's basically a stick to force developers to reach a consensus.

Christian Schwarz uploaded this change later in this month.


I don't think that there ever will be a consensus in all those
discussions without discussing in a reasonable way (which failed in the
past multiple times).  Previously to this, asking the VP of Engineering
for a decision was suggested in this thread.


Carsten


-- 
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/20120501160354.gz17...@furrball.stateful.de

Re: Making -devel discussions more viable

[Russ Allbery]

David Bremner  writes:
> "Bernhard R. Link"  writes:

>> My suggestion to everyone feeling the need to tell anyone on a public
>> mailing list that they should shut up because they are no contributors
>> is thus: Please refrain from any more posts to this discussion.

> I have nothing against this principle, and I do this. But I also stop
> reading such threads. And this means I read less and less of this list.

Right.  As good as that idea sounds on the surface, what that actually
translates into in practice is making debian-devel useless.

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

Re: switching from exim to postfix

[Riku Voipio]

On Tue, May 01, 2012 at 12:48:10AM -0400, Chris Knadle wrote:
> I think it would be useful to describe what issue(s) there are concerning 
> 8BITMIME and why this is important.  I've found some information [1] about 
> this, but it isn't clear what problems are actially *caused* by the lack of 
> 8BITMIME support by default in Exim.  Is it just slow sending of outbound 
> attachments?

It's both extra traffic (not that much if western encodings) and extra
cpu work. In lesser annoyance, it means that you no longer can read
mailbox files with non-mime capable readers (for example less) with ease,
as there will be qp encodings here and there. People who only use english
only hit the issue when having lines longer than 76 characters.

Basicly that the qmail author is suggesting is violating the rfc by
announcing 8bitmime sopport but never doing any conversions if you bump
into a server that doesn't support 8bitmime. This is the same as the
exim's accept_8bitmime option.

In the real world, violating the rfc is a non-issue, as most likely the
only non-8bitmime compliant servers your server encouters are qmail and exim4,
both which have no problems with 8bit mails itself.

Honesstly. my grievance is really just having to convert things to 7bit.. still!

> The quoted 2010 survey [2] showed Exim was the most popular MTA (which I 
> found 
> surprising), deployment of Exim growing just slightly faster than Postfix, 
> and 
> everything else falling in popularity. 

I think it is because other distro's have mostly stopped shipping
anything that listens on port 25 by default.

> I don't know how one would verify (or dispute) the claim that Debian was the
> main source of Exim installs

Indeed that is not verifiable from the given report. However, they list
the most common exim version being 4.69 which is same as what was in
lenny at that time.

> > So yes, switching to postfix by default  would reduce the workload of email
> > servers around the globe (no need to burn cpu cycles and thus co2 to
> > convert emails to quoted-printable).
 
> The statistics quoted showed that Exim was most popular, so wouldn't 
> switching 
> to Postfix by default actually be more CPU costly than the reverse?  :-/  
> [I'm 
> not saying you're wrong, just that I don't see the logic in the argument.]

The less there are MTA's out there not announcing 8bitmime, the less
conversions there will be (eventually). While the exim->exim deliveries
are not generating conversions (unless the MUA does it), exim is still
only at 34% of mx, not 34% of the traffic.

> I've likewise often wondered if a low-resource MTA like DMA or ssmtp could be 
> the default MTA for Desktop installs (and I've occasionally tried them), but 
> as has been discussed there seem to be some issues with the idea.  In my case 
> for Desktops I want the local MTA to be able to handle sending local outbound 
> mail to a server via port 587 over TLS with authentication, to retry sending 
> at increasing time intervals, using a "queue runner" but without a daemon 
> listening, and to notify the sender on a permanent failure.  Thusfar I've 
> only 
> been able to find all of that in a full-fledged MTA.

Indeed, switching to a lightweight mta like dma as default makes probably more
sense than switching by default postfix. I tried ssmpt and it didn't
work for me.. Would dma do TLS auth and queque fine?

Riku



-- 
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/20120501155520.ga6...@afflict.kos.to

Re: switching from exim to postfix

[Chris Knadle]

On Tuesday, May 01, 2012 04:53:03, Philipp Kern wrote:
> On Tue, May 01, 2012 at 12:48:10AM -0400, Chris Knadle wrote:
> > I think it would be useful to describe what issue(s) there are concerning
> > 8BITMIME and why this is important.  I've found some information [1]
> > about this, but it isn't clear what problems are actially *caused* by
> > the lack of 8BITMIME support by default in Exim.  Is it just slow
> > sending of outbound attachments?
> 
> The only issue I found so far is that Postfix will convert mails when
> sending to an Exim that does not advertise 8BITMIME (like *.d.o).  Which
> let me with the need to handle qp although the mails are initially sent
> with 8bit (build logs).
> 
> I also assume that Exim does send 8bit mails to non-8bit compliant MTAs
> (i.e. not advertising 8BITMIME).  I don't know if that's some sort of
> violation.

I think it is.

If 'accept_8bitmime' is enabled (default is disabled), then Exim will send 
email containing 8bit MIME to non-8bit compliant MTAs.  (For verification of 
this, see [1] and [2].)  This would violate RFC 1652 section 3 [3]:

   "If a server SMTP does not support the 8-bit MIME transport extension
(either by not responding with code 250 to the EHLO command, or by
not including the EHLO keyword value 8BITMIME in its response), then
the client SMTP must not, under any circumstances, attempt to
transfer a content which contains characters outside the US-ASCII
octet range (hex 00-7F)."

and also RFC 6152 section 3 [4] (which contains the idential paragraph above 
from RFC 1652).


I think the reason Exim does not do this protocol conversion is that from the 
point of view of an MTA author, the point of an MTA is to transmit the body of 
the message without any modification to it once received, and body 
modification would be required to convert 8-bit MIME to 7-bit MIME.  I seem to 
remember reading something along these lines in the Exim documentation years 
ago and I'm having another look through it, but haven't found a reference to 
this yet.


[1] https://en.wikipedia.org/wiki/Extended_SMTP#8BITMIME

[2] http://www.exim.org/exim-html-3.20/doc/html/spec_11.html

[2] https://tools.ietf.org/html/rfc1652#section-3

[3] https://tools.ietf.org/html/rfc6152#section-3

  -- Chris

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


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

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

[Goswin von Brederlow]

Aron Xu  writes:

> On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow  wrote:
>> Aron Xu  writes:
>>
>>> But what if I endianness does matters for those gettext .mo files?
>>> Installing them as libfoo-translations-be and libfoo-translations-le
>>> will need some change in gettext support of those
>>> applications/libraries, that is finding mo files in alternative paths,
>>> and choosing the right one when being built (cross or not) and run
>>> (host or qemu).
>>
>> Yes it does. Or maybe not. Lets talk about the general case instead of
>> gettext (gettext uses /usr/share/... so they must be arch independent).
>>
>> With libfoo being in /usr/lib// any endian dependent data
>> should be in /usr/lib/// or /usr/lib/> tuple>// (sorry, did we pick one of them as standard yet?),
>> which is usualy a configure option.
>>
>
> /usr/lib//package/ is more natural with Autotools and CMake,
> which I prefer to use.

Ok, lets stick with that then.

>>> M-A:foreign is questionable. How do we specify dependencies in
>>> d/control? If libfoo requires either libfoo-data-be or libfoo-data-le
>>> on different architectures, do we really want to hard code which
>>> architecture to depend on which package manually?
>>
>> For the moment I don't see any other choice. If this is a frequent
>> problem then some dpkg support could be added or some debhelper
>> tool. Detecting the endianness at compile time and setting a substvar
>> would be relatively easy even now.
>>
>
> Yes, detecting endianness at compile time and setting substvar is

For example:

echo >>debian/$(PKG).substvars "endian:Depends=libfoo-data-$(shell 
dpkg-architecture -qDEB_HOST_ARCH_ENDIAN)"

> easy, but again if those packages are arch:any, then they'll actually
> consume a lot of space on our mirrors (discussed at -devel before).

Just for wheezy: Does that matter?

We aren't talking about many package and not a lot of data (yet). I
totaly agree that in the long term it is a terrible solution to
duplicate all the data for all archs when we only need 2 copies.

But at the moment I'm more concerned to get something that is
installable in wheezy. As long as the solution isn't too hard to get out
of again for wheezy+1 I don't quite care so much about mirror space.

>>> Generating data files for both be and le then making it an arch:all
>>> and M-A:foreign package is not a solution for all maintainers, as this
>>> requires to patch the software which upstream are tend to reject of
>>> inclusion in many cases. Generating such data files in maintainer
>>> scripts is another thing I hate because I believe these data meant to
>>> have checksum stored in the package file list so that users can verify
>>> its integrity when needed.
>>
>> There is no one solution for all maintainers.
>>
>
> If we want to reduce the mirror space consumed by such a package,
> building arch:all package is a straightforward solution without
> modifying archive management software and dpkg/apt, but it's again not
> a good choice because we have to keep using binary upload mechanism

That would be fine with me for wheezy if the maintainer is ok with that.

> (or the maintainer will be required to patch the software so it can
> generate both be/le data during a single buildd run).

If the software can generate both that usualy means it can also easily
use both and then you don't need the be/le destinction anymore. That is
the ideal solution. But not always feasable, esspecially not for wheezy.

>> At the moment and given the closeness of the freeze I would just do
>> whatever works for now. If that means big and little endian flavours of
>> the library have to conflict (libfoo-data-be conflicts libfoo-data-le)
>> because the path can't be untangeled then I would still think that would
>> be better than no multiarch support at all. The most common case is
>> amd64+i386 and adding armel is probably the next common. So most
>> multiarch users would be ok.
>>
>> MfG
>>        Goswin
>
> I agree on your opinion. It's much better than nothing. But we do need
> to discover possible solution for Wheezy+1 or even Wheezy+2, don't we?
> :-)

Yes. Just keep the two discussion ('what to do now' and 'what to do long
term') clearly seperate. So far I've only been concerned with the NOW part.

MfG
Goswin


-- 
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/8762cg11a5.fsf@frosties.localnet

Re: Making -devel discussions more viable

[David Bremner]

"Bernhard R. Link"  writes:

> My suggestion to everyone feeling the need to tell anyone on a public
> mailing list that they should shut up because they are no contributors
> is thus: Please refrain from any more posts to this discussion. 

I have nothing against this principle, and I do this. But I also stop
reading such threads. And this means I read less and less of this list.

d


-- 
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/87bom8p3gz.fsf@zancas.localnet

Bug#671020: ITP: robojournal -- cross-platform journal/diary tool

[Ritesh Raj Sarraf]

Package: wnpp
Severity: wishlist
Owner: Ritesh Raj Sarraf 

* Package name: robojournal
  Version : 0.2
  Upstream Author : Will Kraft 
* URL : http://sf.net/projects/robojournal
* License : GPL
  Programming Lang: C++
  Description : cross-platform journal/diary tool

 RoboJournal is a free, open source journal/diary application written in
 C++ using Qt libraries. RoboJournal works in conjunction with MySQL to
 allow the user to create journal databases locally or on a remote server.
 Support for Sqlite and Postgres is planned.
 .
 RoboJournal emphasizes streamlined, practical design plus ease-of-use. 
 .
 RoboJournal depends on the Qt UI toolkit library



-- 
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/20120501103837.17213.40426.report...@champaran.researchut.com

Re: Making -devel discussions more viable

[Bernhard R. Link]

* Russ Allbery  [120430 19:11]:
> I want our technical discussions to be welcoming to anyone who has
> information to share and who can bring additional clarity and insight to
> the discussion.  But once things start getting heated or people start
> throwing around accusations or verge towards personal attacks, there's a
> real psychological difference between people who are contributing to
> Debian and people who aren't.

I'd rather argue that abusive behaviour from contributors is far worse
than from non-contributors. It's easier to ignore people not involved
and people not doing anything are usually not around for long.

There is also nothing keeping anyone with technical arguments out of a
discussion as someone insulting anyone with different opinions and if
running out of insults accusing people as not being contributors.

My suggestion to everyone feeling the need to tell anyone on a public
mailing list that they should shut up because they are no contributors
is thus: Please refrain from any more posts to this discussion. I do
not care if you rationalize it as "no need to feed the troll" or if
you understand you left the level of technical discussion and have
little chance to come back to it till the discussion will be over, but
once that point is reached there really is no sense it keeping it up.

Bernhard R. Link


-- 
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/20120501103126.ga2...@client.brlink.eu

Re: RFC: OpenRC as Init System for Debian

[Roger Leigh]

On Mon, Apr 30, 2012 at 02:00:15PM -0300, Fernando Lemos wrote:
> On Mon, Apr 30, 2012 at 12:50 PM, Roger Leigh  wrote:
> > On Mon, Apr 30, 2012 at 12:04:32PM -0300, Fernando Lemos wrote:
> >> On Mon, Apr 30, 2012 at 11:57 AM, Thomas Goirand  wrote:
> >> > On 04/30/2012 04:56 AM, Fernando Lemos wrote:
> >> >> I agree that OpenRC would be an improvement over the status
> >> >> quo, but migrating *away* from OpenRC later on would be a major pain
> >> >> as we would have to support both LSB/sysvinit scripts and OpenRC
> >> >> service descriptions for the foreseeable future.
> >> >>
> >> > Ah? Is this any different with other alternatives like
> >> > upstart or systemd?
> >>
> >> Yes. The kernel isn't getting any less event-based, so OpenRC would be
> >> an interim solution.
> >
> > Unless OpenRC itself could become more event-based.
> 
> How realistic is that?

I'm not sure yet.  That's one of the things I'd like to find out.


Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120501102134.go28...@codelibre.net

Re: Enabling hardened build flags for Wheezy

[Bernhard R. Link]

* Charles Plessy  [120430 16:26]:
> If people who are interested by improving our dozens of thousands upstream
> makefiles could spend time forwarding patches upstream by themselves, that
> would be appreciated.  I have a hard time finding convincing words when I 
> think
> the patch is borderline useless.

What are you talking about? Sorry, but I really cannot make any sense
out of that.

Let me try to explain the situation, so you can tell me where you
disagree:

We want some options enabled in as many package builds as possible.
Options that have not been the decade long defaults in compilers, so
they break a significant amount of software.

Changing the compiler defaults would have the side effect of also
affecting users and forcing all packages to cope with the changed
defaults at once. (And the packages having the hardest to fix issues
are usually the packages with the most absurd build systems, so
having to fix all of them to include compiler options disabling the
hardening flags is not that easy).

So instead of an opt-out by changing what the compiler does by default
and forcing the package maintainer to override them, we have a opt-in
system: the maintainer can give the options to the build system.

For that there is the new dpkg-buildflags command, that outputs all
categories of flags a package maintainer would want to have: It give
you preprocessor flags, it gives you C compiler flags, it gives you C++
compiler flags, it gives you fortran compiler flags and it gives you
linker flags. By default it gives some default hardning flags but also
supports the maintainer requesting more intrusive flags or disabling
some classes of flags (see the discussion of DEB_BUILD_MAINT_OPTIONS
in dpkg-buildflags manpage). It's also done in a way that support for
'noopt' it automatic, so it even makes it even less work for the
maintainer.

To ease it for package maintainers, the flags dpkg-buildflags generates
have the names the GNU coding standards request all package build
systems should support. As those are quite influental, many build
systems name them this way. And as they are split into the flags the
different tools want to have, every other scheme can be computed out of
those easily by just appending those set of flags you need.

If you have a build-system that does not support passing flags to the
compiler, then you won't get support for hardning with this opt-in way,
of course.  But such a package would also have no way to override a
specific set of hardening flags, so it would have problems with the
opt-out way to, because it cannot opt-out.

As not everyone build systems has the same names for variables holding
the compiler (meaning preprocessor/actual compiler/linker) flags.
There is not even theoretically (compare "halting problem") a way to
determine what the variables are named like and what content they
expect. This simply needs a human to look at it and say which flags
need to be put where so that the upstream build system will pick them
up.

If a build system does not support passing flags to the compiler, and
you want it to have hardening flags, that might need some makefile
patches. But if there is no time for this or this is too complicated,
then one can just do without, generating a package without hardening
(and most likely also without support for noopt and the like, so do
not suppose other people will be extremly willing to help you fix the
bugs in it), but so be it.

The release goal is
"This goal is to update as many packages as possible to use security
hardening build flags via dpkg-buildflags. These flags enable various
protections against security issues such as stack smashing, predictable
locations of values in memory, etc."
It's not
"Every package even if only hardly being of a quality to be included in
a distribution must support hardening flags or it must be removed from
Debian".

Bernhard R. Link


-- 
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/20120501095606.ga2...@client.brlink.eu

Re: switching from exim to postfix

[Philipp Kern]

On Tue, May 01, 2012 at 12:48:10AM -0400, Chris Knadle wrote:
> I think it would be useful to describe what issue(s) there are concerning 
> 8BITMIME and why this is important.  I've found some information [1] about 
> this, but it isn't clear what problems are actially *caused* by the lack of 
> 8BITMIME support by default in Exim.  Is it just slow sending of outbound 
> attachments?

The only issue I found so far is that Postfix will convert mails when sending
to an Exim that does not advertise 8BITMIME (like *.d.o).  Which let me with
the need to handle qp although the mails are initially sent with 8bit (build
logs).

I also assume that Exim does send 8bit mails to non-8bit compliant MTAs (i.e.
not advertising 8BITMIME).  I don't know if that's some sort of violation.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature