headers
Russ Allbery | 1 May 2012 01:01
Picon
Favicon

Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware

Charles Plessy <plessy <at> debian.org> writes:

> By the way I would like to add another point, that the split between
> contrib and non-free is not informative.  A program in contrib can be
> tightly coupled to a non-free library in a way that would require a
> considerable amount of work to free it.  On the other hand, a program in
> non-free can be so because of re-using non-free code that can be easily
> removed.

The distinction between contrib and non-free is not informative because
it's not based on what would be a sensible division from a user
perspective.  The distinction between contrib and non-free is purely
legal.  contrib contains software that's redistributable in its entirety
under the DFSG; non-free contains software that is not, in part or in
whole.  That's basically it; that's the whole of the distinction, and
attempting to read more into it than that is going to lead people astray.

> For instance, the seaview package went from main to non-free when it
> gained the possibility to do some kind of phylogenetic analysis, and if
> one would remove this function, the resulting program would still be
> completely functional and would be an improvement compared to the last
> free version.

This is just because the granularity of our ability to divide things
between archives is the package level.  We can't divide things at any
lower level than that, so each package has to be declared DFSG-free or not
in its entirety.

If you separated out the phylogenetic analysis into a separate package,
then we would be able to divide the software properly.  (I realize that
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carsten Hey | 1 May 2012 01:07
Picon
Favicon

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

* 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):
  * node is older and nodejs should have checked the binary name
  * first come first server
  * nodejs is used as node in the shebang line
  * my node is more widely used than yours (which node is meant depends
    on the year)
  * node is a daemon and there it does not matter what name it uses
  * one of them should use the binary name node
  * none should use the binary name node if there is no consensus
  * let the user decide via debconf
  * users from either group would complain if they need to use a name
    other than node
  * policy is wrong, packages should conflict
  * conflicts would be wrong

Nowadays, the popcon stats for both packages strongly suggest that most
of node's user are users that wanted to install node.js and did not
remove the node package after noticing that it is not what they
expected.
(Continue reading)

Permalink | Reply | 37 comments |
headers
Jonathan McCrohan | 1 May 2012 03:00
Picon
Gravatar

Bug#670984: ITP: libphidget -- Phidgets runtime library

Package: wnpp
Severity: wishlist
Owner: Jonathan McCrohan <jmccrohan <at> gmail.com>

* Package name    : libphidget
  Version         : 2.1.8.20120216
  Upstream Author : Phidgets Inc. <support <at> phidgets.com>
* URL             : http://www.phidgets.com/
* License         : LGPL-3
  Programming Lang: C
  Description     : Phidgets runtime library

Phidgets are a set of "plug and play" building blocks for low cost USB sensing
and control from your PC. All the USB complexity is taken care of by the robust
libphidget API.

Note: This package is *not* related to martin f. krafft's libphidgets library
which was previously in the archive.
Permalink | Reply | 0 comments |
headers
Chris Knadle | 1 May 2012 06:48
Picon

Re: switching from exim to postfix

On Monday, April 30, 2012 06:14:19, Riku Voipio wrote:
> On Sat, Apr 28, 2012 at 07:12:42PM -0700, Russ Allbery wrote:
...
> > There's nothing particularly wrong with Exim; it works just fine.
> 
> Exim in 2012 not supporting 8BITMIME and thus being the last Major MTA
> forcing quoted-printable conversions to make emails "7bit clean" is quite
> horribly wrong.

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?

> Debian is the main source of Exim installs in internet, it is also our
> fault. According to one old stat, 34% of mx records were exim, most
> probably almost all simply because it came by default in debian and it was
> "good enough" so people didnt' switch away from it.

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 don't know how one would verify (or 
dispute) the claim that Debian was the main source of Exim installs, and I'm 
not sure that's a "problem" that needs fixing.  (Also if you look more closely 
at the survey, ~55% of responding MTAs didn't identify themselves and are thus 
not counted in the statistics, which is a potential wide margin of error.)

> 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
(Continue reading)

Permalink | Reply | 33 comments |
headers
Philipp Kern | 1 May 2012 10:53
Picon
Favicon

Re: switching from exim to postfix

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
Permalink | Reply | 3 comments |
headers
Bernhard R. Link | 1 May 2012 11:56
Picon
Favicon

Re: Enabling hardened build flags for Wheezy

* Charles Plessy <plessy <at> debian.org> [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++
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roger Leigh | 1 May 2012 12:21

Re: RFC: OpenRC as Init System for Debian

On Mon, Apr 30, 2012 at 02:00:15PM -0300, Fernando Lemos wrote:
> On Mon, Apr 30, 2012 at 12:50 PM, Roger Leigh <rleigh <at> codelibre.net> 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 <zigo <at> debian.org> 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/Linux    http://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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard R. Link | 1 May 2012 12:31
Picon
Favicon

Re: Making -devel discussions more viable

* Russ Allbery <rra <at> debian.org> [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
Permalink | Reply | 13 comments |
headers
Ritesh Raj Sarraf | 1 May 2012 12:38
Picon
Favicon

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

Package: wnpp
Severity: wishlist
Owner: Ritesh Raj Sarraf <rrs <at> debian.org>

* Package name    : robojournal
  Version         : 0.2
  Upstream Author : Will Kraft <pwizard <at> gmail.com>
* 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
Permalink | Reply | 0 comments |
headers
David Bremner | 1 May 2012 13:04
Picon
Favicon

Re: Making -devel discussions more viable

"Bernhard R. Link" <brlink <at> debian.org> 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
Permalink | Reply | 12 comments |

Gmane