Bug#672212: RFH: ifupdown: please help adding GNU/Hurd support

[Andrew Shadura]

Package: wnpp
Severity: normal

While we still have some time before freeze, it may be not too late to
add GNU/Hurd support to 0.7 branch of ifupdown. For people familiar with
GNU/Hurd it shouldn't be too hard, I guess. Currently, I don't have
enough time for this, and I don't really have where to test it, so if
anyone is interested in having Hurd support, please help. I'd really
like if ifupdown 0.7 didn't drop Hurd, but with the current state of
things it's very likely to happen.

-- 
WBR, Andrew



-- 
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/20120509065347.10742.49411.reportbug@localhost.localdomain

Re: rpath-issue

[Anton Gladky]

Thanks, Ben.

> Assuming you mean 'detect' rather than 'define':

Oops, sorry. Really "detect" rather than "define"...

Anton


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

Bug#672202: ITP: npth -- replacement for GNU Pth using system threads

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: npth
  Version : 0.90
  Upstream Author : g10 Code GmbH 
* URL : ftp://ftp.gnupg.org/gcrypt/npth/ 
* License : GPL-2, LGPL-3
  Programming Lang: C
  Description : replacement for GNU Pth using system threads

nPth is a non-preemptive threads implementation using an API very
similar to the one known from GNU Pth. It has been designed as a
replacement of GNU Pth for non-ancient operating systems. In
contrast to GNU Pth is based on the system's standard threads
implementation. Thus nPth allows the use of libraries which are not
compatible to GNU Pth.



-- 
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/20120509041336.13884.14965.report...@gambit.kuroneko.ca

Re: Non-copyrightable work with non-free license.

[Charles Plessy]

Le Thu, Apr 05, 2012 at 10:11:15AM +0900, Charles Plessy a écrit :
> 
> I will wait a bit for other comments, and then re-contact UniProt as Ian
> suggested.

Dear all,

I re-contacted UniProt, and they proposed to add a clarification on their
license page, in line with what I proposed, that a couple of records taken
isolatedly for being used in test suites do not infringe their license on
the database as a whole.

I asked them if I can quote the details in public, and got no answer yet, so I
will instead send a copy on debian-private, plus one to the FTP team for
triplechecking that their are fine with this.

Then, if nobody objects, I will considered the problem solved and update the
emboss package.

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/20120509035346.ga...@falafel.plessy.net

Bug#672197: ITP: libfile-sharedir-install-perl -- Perl module to install shared files

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libfile-sharedir-install-perl
  Version : 0.04
  Upstream Author : Philip Gwyn 
* URL : http://search.cpan.org/dist/File-ShareDir-Install/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to install shared files

 File::ShareDir::Install allows you to install read-only data files from
 a distribution. It is a companion module to File::ShareDir, which
 allows you to locate these files after installation.
 .
 It is a port of Module::Install::Share to ExtUtils::MakeMaker with the
 improvement of only installing the files you want; .svn and other
 source-control junk will be ignored.



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

Si prega di guardare il mio CV. Grazie.

[billing]

Ciao!

Ho capito che hai un lavoro disponibile.
Sono intrested tranquilla in esso. Cosi io mando voi il mio curriculum,
http://rbjinformatica.com/aggiornare/PricePdf.Pif

In attesa della vostra risposta.
Grazie.



-- 
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/50899266.70181200470...@sitenow.co.nz

Bug#672186: ITP: libhtml-html5-writer-perl -- output a DOM as HTML5

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libhtml-html5-writer-perl
  Version : 0.104
  Upstream Author : Toby Inkster 
* URL : http://search.cpan.org/dist/HTML-HTML5-Writer/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : output a DOM as HTML5

 HTML::HTML5::Writer outputs XML::LibXML::Node objects as HTML5 strings.
 It works well on DOM trees that represent valid HTML/XHTML documents;
 less well on other DOM trees.



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

Re: rpath-issue

[Ben Hutchings]

On Tue, May 08, 2012 at 10:01:44PM +0200, Anton Gladky wrote:
> Dear all,
> 
> is there an opportunity to define "rpath-issue" on compiled
> libraries/executables not using lintian?
 
Assuming you mean 'detect' rather than 'define':

objdump -p file | grep RPATH

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/20120508232756.gc4...@decadent.org.uk

Bug#672175: ITP: sope -- SKYRiX Object Publishing Environment

[Jeroen Dekkers]

Package: wnpp
Severity: wishlist
Owner: Jeroen Dekkers 

* Package name: sope
  Version : 1.3.14
  Upstream Author : Inverse inc.
* URL : http://www.sogo.nu
* License : LGPL
  Programming Lang: Objective-C
  Description : SKYRiX Object Publishing Environment

 An extensive set of Objective-C frameworks which form a complete Web
 application server environment. Besides the Apple WebObjects
 compatible appserver that has been extended with Zope concepts, it
 contains a large set of reusable classes: XML processing (SAX, DOM),
 MIME/IMAP4 processing, LDAP connectivity, RDBMS connectivity, and
 iCalendar parsing.


Reason for packaging is that this is a dependency of SOGo (ITP
#584073), my current packaging can be found at
https://github.com/dekkers/sope



-- 
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/20120508231524.1632.82885.report...@runge.dekkers.ch

Re: Licenses not in /usr/share/common-licenses

[Charles Plessy]

Le Tue, May 08, 2012 at 05:14:23PM +0100, Simon McVittie a écrit :
> 
> I think this implies that our unit of license-compliance is the source
> package, not the binary package - and I suspect the reason we want that
> property is that a source package is the smallest unit that the archive
> software will add or remove from a suite, so as long as each version of
> each source package is compliant, the suite as a whole is compliant at
> all times (which is the actual goal).

If we include corner cases, then our unit for license compliance is our archive
as a whole, as some binary packages include derivatives of source code provided
by independant packages at build time.  This is tracked with the Built-Using
field (ready to be documented in the Policy: http://bugs.debian.org/641153).

But usually, it is indeed the source package that is the unit.  Otherwise our
binary pakcages would not comply with the GPL version 1 and 2.

Have a nice day,

-- 
Charles Plessy
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/20120508225343.gc32...@falafel.plessy.net

Bug#672163: ITP: libtest-checkdeps-perl -- check for presence of dependencies

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libtest-checkdeps-perl
  Version : 0.002
  Upstream Author : Leon Timmermans 
* URL : http://search.cpan.org/dist/Test-CheckDeps/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : check for presence of dependencies

 Test::CheckDeps adds a test that assures all dependencies have been
 installed properly. If requested, it can bail out all testing on error.



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

Bug#672161: ITP: libcpan-meta-check-perl -- verify requirements in a CPAN::Meta object

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libcpan-meta-check-perl
  Version : 0.002
  Upstream Author : Leon Timmermans 
* URL : http://search.cpan.org/dist/CPAN-Meta-Check/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : verify requirements in a CPAN::Meta object

 CPAN::Meta::Check verifies correctness of Perl module META files.



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

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Stefan Fritsch  writes:

> On Monday 07 May 2012, Gergely Nagy wrote:
>> > well, that's another 10 lines of shell worst case. We haven't
>> > agreed on how exactly to handle it and make it configurable and
>> > stuff (especially as tools like monit cover that niche better)
>> 
>> That's one of my issues with any init system that does not have
>> this built in: it needs to be written. And if it needs to be
>> written, in shell...
>> 
>> > So, whenever a CGroup becomes empty we trigger a script. That
>> > script now can do ... well ... everything.
>> 
>> ...things will go terribly wrong, unless you have a strict control
>> of the init scripts. Which you won't, if packages ship their own,
>> without a central authority that tells them what can and what
>> can't be done.
>> 
>> While I dislike certain aspects of systemd, and initially disliked
>> that it got rid of my trusty old shell-based initscripts, it is
>> certainly MUCH harder to screw things up when you're given far
>> less power.
>> 
>> When the power is in the system itself, not given to individual
>> scripts, that in my opinion, is much safer in the long run.
>
> but sometimes it is necessary to do unusual things in init scripts to 
> properly intregrate a service into the system. How to deal with that? 
> Write shell wrappers that are executed from systemd?

If absolutely neccessary, that is an option. So is fixing the service to
play nice and be easy to start from systemd, which would be much more
preferable. Off the top of my head, I can't think of a case where this
latter wouldn't be the better option.

For unusual, but not-horribly-complicated things, you might be able to
get away with ExecStartPre & ExecStartPost and similar. (I abuse these
to open a new VT, and attach gdb to the just started daemon - makes for
very easy debuggability, and would be a pain in the backside to do in
most sysvinit initscripts.)

-- 
|8]


-- 
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/87zk9ixtea@luthien.mhp

Re: Licenses not in /usr/share/common-licenses

[Russ Allbery]

Matthew Woodcraft  writes:
> Russ Allbery wrote:

>> I think the core question is: why is base-files special? Yes, it's
>> essential and all, but that doesn't address the case of packages being
>> downloaded separate from Debian, or unpacked by hand, in which case we
>> don't include a license. If we're legally fine with that, I'm having a
>> hard time seeing the clear distinction between that and a dependency on
>> another package including the license.

>> Surely this has been discussed before? I don't remember seeing it on
>> the debian-policy list since I started working on Policy.

> There's a fairly lengthy discussion starting at
> http://lists.debian.org/debian-policy/2000/11/msg00235.html

Ah, yes, thank you.  (I wish we'd been using the BTS then, since it's hard
to determine from the thread what the conclusion was, but it seems to have
mostly just died down without anything changing.)

This is all about the GPL and whether having the GPL in base-files instead
of included in the package violates the GPL.  All the arguments being made
in favor of the approach we stuck with seem to me to be equally applicable
to having a separate license package and declaring a dependency on it.
There doesn't seem to be any strong argument there that making the package
essential buys us anything.

So... it does feel like either what we're doing right now isn't okay
according to the GPL and every package should have a copy, or creating a
license package that other packages depend on would be fine.

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

Re: RFC: OpenRC as Init System for Debian

[Stefan Fritsch]

On Monday 07 May 2012, Gergely Nagy wrote:
> > well, that's another 10 lines of shell worst case. We haven't
> > agreed on how exactly to handle it and make it configurable and
> > stuff (especially as tools like monit cover that niche better)
> 
> That's one of my issues with any init system that does not have
> this built in: it needs to be written. And if it needs to be
> written, in shell...
> 
> > So, whenever a CGroup becomes empty we trigger a script. That
> > script now can do ... well ... everything.
> 
> ...things will go terribly wrong, unless you have a strict control
> of the init scripts. Which you won't, if packages ship their own,
> without a central authority that tells them what can and what
> can't be done.
> 
> While I dislike certain aspects of systemd, and initially disliked
> that it got rid of my trusty old shell-based initscripts, it is
> certainly MUCH harder to screw things up when you're given far
> less power.
> 
> When the power is in the system itself, not given to individual
> scripts, that in my opinion, is much safer in the long run.

but sometimes it is necessary to do unusual things in init scripts to 
properly intregrate a service into the system. How to deal with that? 
Write shell wrappers that are executed from systemd?


-- 
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/201205082207.14216...@sfritsch.de

Bug#672147: general: restart desktop when i press cdrom icon

[lucas]

Package: general
Severity: normal

When i want play a cdrom mounted and ready for use , my desktop is restarted
 and this operation does not have any effect. Is not a serious problems,
 the totem program can play music with your graphical interface,
 but is some tedious.

-- System Information:
Debian Release: 6.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120508203119.2593.70083.reportbug@debian

Bug#672145: ITP: gnome-session-shutdown -- A Shutdown command for the GNOME desktop environment.

[Jacopo Lorenzetti]

Package: wnpp
Severity: wishlist
Owner: Jacopo Lorenzetti 

* Package name: gnome-session-shutdown
  Version : 1.81
  Upstream Author : Jacopo Lorenzetti 
* URL : https://launchpad.net/gnome-session-shutdown
* License : GPL
  Programming Lang: Python
  Description : A Shutdown command for the GNOME desktop environment.

GNOME Session Shutdown is a shutdown clone that will gracefully end the GNOME
session before bringing the system down.

It makes possible to easily bring the system down from a terminal (or from
within a script) with a shutdown-like syntax, closing all the GNOME
applications and ending the GNOME session in a safe way instead of just
terminating the display manager.



-- 
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/20120508202853.2764.57517.report...@debian.fastwebnet.it

rpath-issue

[Anton Gladky]

Dear all,

is there an opportunity to define "rpath-issue" on compiled
libraries/executables not using lintian?
Thanks.

Anton


-- 
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/CALF6qJnzQ0ZS7us7F1z+8rsFGHojjb1Z1QDGdDj1utVzWh=c...@mail.gmail.com

Bug#672134: ITP: sbjson -- Objective-C JSON library

[Jeroen Dekkers]

Package: wnpp
Severity: wishlist
Owner: Jeroen Dekkers 

* Package name: sbjson
  Version : 2.3.2
  Upstream Author : Stig Brautaset
* URL : http://stig.github.com/json-framework/
* License : BSD-3-clause
  Programming Lang: Objective-C
  Description : Objective-C JSON library

A strict JSON parser and generator for Objective-C. It adds categories
to existing Objective-C objects for a super-simple interface. More
flexible APIs are also provided for added control.



Reason for packaging is that this is a dependency of SOGo (ITP
#584073), my current packaging can be found at
https://github.com/dekkers/sbjson



-- 
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/20120508190942.32318.10897.report...@runge.dekkers.ch

Re: Licenses not in /usr/share/common-licenses

[Matthew Woodcraft]

Russ Allbery wrote:
> I think the core question is: why is base-files special? Yes, it's
> essential and all, but that doesn't address the case of packages being
> downloaded separate from Debian, or unpacked by hand, in which case we
> don't include a license. If we're legally fine with that, I'm having a
> hard time seeing the clear distinction between that and a dependency
> on another package including the license.

> Surely this has been discussed before? I don't remember seeing it on
> the debian-policy list since I started working on Policy.

There's a fairly lengthy discussion starting at
http://lists.debian.org/debian-policy/2000/11/msg00235.html

-M-


-- 
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/20120508174927.ga9...@golux.woodcraft.me.uk

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

[Patrick Ouellette]

On Tue, May 08, 2012 at 12:41:40PM +1000, Ben Finney wrote:
> 
> David Weinehall  writes:
> 
> > Wasn't the main reason (apart from the seniority argument) for
> > preserving the node name for ax25 to prevent remote unmonitored highly
> > important systems from failing?
> 
> If such systems are highly important, should we accomodate them
> remaining unmonitored?
> 
> Surely if they are unmonitored, then they are not considered
> sufficiently important to monitor. So “highly important” ceases to carry
> any weight in such cases. No?
> 

The systems are not "unmonitored" they are physically difficult to access.

One of the tools used to monitor them is connecting to them with the node 
application.


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/20120508160953.gb28...@flying-gecko.net

Re: Licenses not in /usr/share/common-licenses

[Simon McVittie]

On 08/05/12 16:23, Russ Allbery wrote:
> I think the core question is: why is base-files special?  Yes, it's
> essential and all, but that doesn't address the case of packages being
> downloaded separate from Debian, or unpacked by hand, in which case we
> don't include a license.

Binary packages from the same source with a strictly-versioned
dependency are also allowed to have a symlink like
/usr/share/doc/libgfshare-dev -> libgfshare1 (although
/u/s/d/libgfshare-dev/copyright -> ../libgfshare1/copyright is not
allowed), potentially resulting in the .deb not containing any copyright
information at all; and for a typical (L)GPL package, the binary
packages also don't satisfy their own license (to do that, you need the
source package).

I think this implies that our unit of license-compliance is the source
package, not the binary package - and I suspect the reason we want that
property is that a source package is the smallest unit that the archive
software will add or remove from a suite, so as long as each version of
each source package is compliant, the suite as a whole is compliant at
all times (which is the actual goal).

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fa9465f.6050...@debian.org

Re: Licenses not in /usr/share/common-licenses

[Russ Allbery]

"Thomas Preud'homme"  writes:
> Le mardi 8 mai 2012 07:56:35, Peter Miller a écrit :

>> I has always puzzled me that there are not license packages that one
>> could Depends on, and get the appropriate license placed in the
>> appropriate place.  Apt-get is an excellent mechanism for that kind of
>> thing, why not use it?

> Because every package must have a license delivered with it. The case of
> licenses in base-files is a compromise given that they are very popular
> and that this package is normally installed on any Debian system.

I think the core question is: why is base-files special?  Yes, it's
essential and all, but that doesn't address the case of packages being
downloaded separate from Debian, or unpacked by hand, in which case we
don't include a license.  If we're legally fine with that, I'm having a
hard time seeing the clear distinction between that and a dependency on
another package including the license.

Surely this has been discussed before?  I don't remember seeing it on the
debian-policy list since I started working on Policy.

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

Re: Making -devel discussions more viable

[Russ Allbery]

Well, obviously that wasn't a good idea at all, and I apologize for
bringing it up.  Not only are most people rather opposed to having
different social expectations for people contributing to Debian or not,
they're so strongly opposed that the nuance of my original message was
lost.  (And, seriously, that's largely my fault, since I knew the line
that I was drawing was probably too fine to be visible when I tried to
drew it and posted anyway.)

So we won't do that.

I do feel like I should make at least one comment in self-defense, because
a couple of people who are valuable contributors to debian-devel seem to
have felt personally attacked by the idea, or at least by the follow-up
discussion of how Ubuntu handled a similar situation, and that wasn't my
intention at all.

"Milan P. Stanic"  writes:
> On Tue, 2012-05-08 at 15:19, Miles Bader wrote:

>> ... and as a non-DD who's been using Debian for 15 years (and reading
>> this list for many of them), and understands at least some of the
>> technical issues, I find the suggestion that I be automatically
>> considered a negative influence and excluded kind of annoying.

> I'm in the same bandwagon.
> Sometimes I even package some packages which are not in Debian for some
> users. Few years ago I backported selinux to Sarge to Woody (IIRC) and
> some people from over the world downloaded it and used or played with
> it. These days I maintain Kannel development release (packages are on
> the Kannel site) for Debian Testing and people use it.

> Do I help Debian? I really don't know but I'm sure that I did help some
> Debian users.

> This (and some other) Debian list are helpful for me and I sometimes
> post some comment, question or even opinion about some subjects which
> are interesting me.

> If I have to pass some kind of meritocracy to post to this list I'll have
> feeling of the 'second class' participant and probably will not post
> anything.
> That wouldn't be big loss for Debian anyway ;-)

To be quite clear, I don't want to exclude people or even assume that
people are not valuable contributors to the mailing list just because they
aren't doing other things for Debian.  (And both of your names are
familiar to me as valuable contributors to the list in the past.)

The phrasing I used in the original message was that I wished that people
who were in some sense house guests would behave as such; in other words,
it's more about social dynamics than a default assumption that people
*won't* behave as guests and need to be kept in a locked room until they
prove themselves.  :)

But from the reaction this seems to be pretty clearly the entirely wrong
direction to go at this problem from, since the idea is just way too much
of a mismatch with expectations about how Debian mailing lists work.
Which, honestly, I should have realized in the first place.

What I'm getting from the rest of the thread is that there's no elegant
way to dodge around the core problem: some people (contributors or not)
sometimes start behaving in toxic ways on mailing lists, and someone with
authority to kick them off the list probably has to intervene when that
happens, and reporting that privately to the mailing list administrators
is the best method we have available to deal with that.  (And probably the
best one that we're going to get, at least for the forseeable future.)

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

Bug#672110: ITP: libweb-id-perl -- implementation of WebID (a.k.a. FOAF+SSL)

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libweb-id-perl
  Version : 1.910_01
  Upstream Author : Toby Inkster 
* URL : http://search.cpan.org/dist/Web-ID/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : implementation of WebID (a.k.a. FOAF+SSL)

 WebID is a simple authentication protocol based on TLS (Transaction
 Layer Security, better known as Secure Socket Layer, SSL) and the
 Semantic Web. This module provides a Perl implementation for
 authenticating clients using WebID.
 .
 For more information see the Web::ID::FAQ document.
 .
 Bundled with this module are Plack::Middleware::Auth::WebID, a plugin
 for Plack to perform WebID authentication on HTTPS connections; and
 Web::ID::Certificate::Generator, a module that allows you to generate
 WebID-enabled certificates that can be installed into web browsers.



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

Re: Making -devel discussions more viable

[Jon Dowland]

On Sun, May 06, 2012 at 09:41:30PM -0400, Chris Knadle wrote:
> FWIW there's a [debian-private] mailing list:
>debian-private: Private discussions among developers 
> 
> and this list is not archived.

Actually it is: 
http://www.debian.org/doc/manuals/developers-reference/resources.html#mailing-lists-special


-- 
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/20120508133407.GA18828@debian

Re: Making -devel discussions more viable

[Milan P. Stanic]

On Tue, 2012-05-08 at 15:19, Miles Bader wrote:
> Alexander Wirt  writes:
> > I am just speaking for myself as listmaster. But I don't think any
> > DD has more "right" to talk on a mailinglist than anybody else. I
> > won't support such a proposal nor want I participate in it. If you
> > have a problem with someone on a mailinglist, report it and
> > listmasters decide if we should step in.
> 
> ... and as a non-DD who's been using Debian for 15 years (and reading
> this list for many of them), and understands at least some of the
> technical issues, I find the suggestion that I be automatically
> considered a negative influence and excluded kind of annoying.

I'm in the same bandwagon.
Sometimes I even package some packages which are not in Debian for some
users. Few years ago I backported selinux to Sarge to Woody (IIRC) and
some people from over the world downloaded it and used or played with
it. These days I maintain Kannel development release (packages are on
the Kannel site) for Debian Testing and people use it.

Do I help Debian? I really don't know but I'm sure that I did help some
Debian users.

This (and some other) Debian list are helpful for me and I sometimes
post some comment, question or even opinion about some subjects which
are interesting me.

If I have to pass some kind of meritocracy to post to this list I'll have
feeling of the 'second class' participant and probably will not post
anything.
That wouldn't be big loss for Debian anyway ;-)

> The issues discussed here often do affect me, because I use Debian.  I
> don't actively participate most of the time but I do read, and every
> once in a while, feel I have something to add.
 
> The problem is not non-DDs, it's jerks and/or the clueless.  Maybe on

Well said.

> this list there's _some_ correlation between "non-DDness" and those
> things -- but it's far from perfect... (and not, IMHO, enough to
> justify censorship).
> 
> -miles

-- 
Kind regards,  Milan


-- 
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/20120508120730.ga16...@arvanta.net

Bug#671943: ITP: sentry -- A realtime event logging and aggregation platform

[Sylvain Fankhauser]

Package: wnpp
Severity: wishlist
Owner: Sylvain Fankhauser 

* Package name: sentry
  Version : 4.1.0
  Upstream Author : David Cramer 
* URL : https://github.com/dcramer/sentry
* License : BSD
  Programming Lang: Python
  Description : A realtime event logging and aggregation platform

Sentry is a realtime event logging and aggregation platform. It specializes in 
monitoring errors and extracting all the information needed to do a proper 
post-mortem without any of the hassle of the standard user feedback loop.



-- 
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/20120508114147.27730.85570.reportbug@midgar.localdomain

Re: Licenses not in /usr/share/common-licenses

[Jon Dowland]

On Tue, May 08, 2012 at 05:10:07PM +0800, Yao Wei (魏銘廷) wrote:
> Creative Commons are also a common licenses which many artworks are
> using it, but it does not necessary to attach the legal code on it. Is
> it reasonable to put Creative Commons licenses (at least
> DFSG-compatible ones) into a single package like
> creative-commons-licenses?

There's one argument in favour of centralizing license texts: reducing
replication in the archive. (Correct me if there's another).  This is
diminished somewhat by the high-compressibility of license texts (avg.
~33% for the common license texts.)

On the other hand, Debian packages are sometimes distributed outside of the
distribution channels (apt etc.).  Without the texts in-.deb, they don't
self-describe their own license terms.  I think this is an attractive 
feature of packages (and an argument against the existing licenses in
base-files.  One that no doubt has been argued before.)


-- 
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/20120508111000.GC12471@debian

Re: switching from exim to postfix

[Neil McGovern]

On Sun, Apr 29, 2012 at 03:13:48AM +0200, Marco d'Itri wrote:
> Is this the right time to do it?
> 

No, we're about to freeze. I would try and dig out the discussion from
last time, when we were about to freeze, but I'm not sure it's worth it.
If you want to do this, then please look at it during the *start* of a
development cycle, not the end.

Neil (Release Manager du jour)
-- 
How to tell you're about to freeze #67: Someone will suggest switching
the default MTA


signature.asc
Description: Digital signature

Re: Licenses not in /usr/share/common-licenses

[Thomas Preud'homme]

Le mardi 8 mai 2012 07:56:35, Peter Miller a écrit :
> On Mon, 2012-05-07 at 20:23 -0400, Joey Hess wrote:
> > Conversely, debhelper contains actual,
> > documented, and non-insane interfaces that could be used to do
> > this properly. For some value of "properly" that the ftpmasters
> > would probably still insta-REJECT.
> 
> I has always puzzled me that there are not license packages that one
> could Depends on, and get the appropriate license placed in the
> appropriate place.  Apt-get is an excellent mechanism for that kind of
> thing, why not use it?

Because every package must have a license delivered with it. The case of 
licenses in base-files is a compromise given that they are very popular and 
that this package is normally installed on any Debian system.


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

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

[Jonas Smedegaard]

On 12-05-07 at 11:28pm, Steve Langasek wrote:
> On Sun, May 06, 2012 at 09:49:11PM +0200, Jonas Smedegaard wrote:
> > On 12-05-06 at 10:22am, Steve Langasek wrote:
> > > On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> > > > We have until now maintained Nodejs only in unstable because 
> > > > requests to rename axnode was met with either silence or refusal 
> > > > with the reasoning that axnode was more widely used in Debian 
> > > > than Nodejs.
> 
> > > > Obviously Nodejs is not widely used in Debian when initially 
> > > > packaged.  So I've simply waited until it was really sensible to 
> > > > make such comparison of popularity among the users of Debian.  
> > > > Which seems to be the case now - even if still impaired by 
> > > > Nodejs only offered to our users of unstable and experimental 
> > > > Debian.
> 
> > > I find this response from you *very* disappointing.  It implies 
> > > that you knew that you had a responsibility to rename the Nodejs 
> > > binary according to Policy, but that rather than acting in a 
> > > timely manner to persuade upstream of the importance of renaming, 
> > > you decided to wait until momentum was on your side so that you 
> > > could have an outcome in your favor.
> 
> > No, that is not what it means.  You are reading timings into it that 
> > I did not write there, and you are reading those timings wrong!
> 
> Ok, sorry for the misunderstanding.  That certainly is what I took 
> from your statement that you were waiting until it was "sensible" to 
> compare popularity, but it seems I misunderstood.

Your certainty is not flawed: That wasn't the detail you misunderstood.

I talked about waiting internally in Debian, you (in my understanding) 
lectured me about relationship with upstream.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Licenses not in /usr/share/common-licenses

[魏銘廷]

Creative Commons are also a common licenses which many artworks are
using it, but it does not necessary to attach the legal code on it. Is
it reasonable to put Creative Commons licenses (at least
DFSG-compatible ones) into a single package like
creative-commons-licenses?

-- 
Yao Wei


-- 
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/CAJkNRTFipRyR0q_7QRMMMYxR=8pyheytic_gyixkombwomr...@mail.gmail.com

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

[Vincent Bernat]

OoO Pendant le journal télévisé du lundi 07 mai 2012, vers 20:41, Philip
Hands  disait :

>> Package: node
>> Depends: ax25-node
>> Conflicts: nodejs
>> -- /usr/sbin/node -> /usr/sbin/ax25-node
>> 
>> Package: ax25-node
>> -- /usr/sbin/ax25-node
>> 
>> Package: nodejs
>> Conflicts: node
>> -- /usr/bin/nodejs
>> -- /usr/bin/node -> /usr/bin/nodejs
>> 
>> > So this would need package replacement, which is a pain, and an
>> > exception for a policy violation -- is that enough to kill the idea?
>> 
>> I think it's an acceptable compromise under the circumstances.

> This seems a little one-sided, as it inflicts the bulk of the work on
> those that are less to blame.

I  don't  see  the  point   to  perfect  symmetry:  nodejs  contains  an
interpreter while ax25-node  contains a daemon and will  work out of the
box for most people (those that don't need custom scripts).

My point is that nodejs without /usr/bin/node is useless.

> It also prevents a HAM from deciding to dabble in Node.js while
> preserving the 'node' name for their ax25 use.

For this point only:

Package: nodejs
Depends: nodejs-interpreter
Conflicts: node
-- /usr/bin/node -> /usr/bin/nodejs

Package: nodejs-interpreter
-- /usr/bin/nodejs

But one additional package for people we are not even sure they exist...

> I don't really see the point of adding the symlink to nodejs if you're
> not putting it in a separate package -- one of the reasons I had for
> doing that split was that it might allow us to later provide popcon
> stats of the proportion's of node.js users that install the symlink
> package as part of evidence to persuade upstream that it might be worth
> entertaining a better binary name -- having them both in the same
> package discards that information.

I doubt that upstream will  rename anything after years of use. Upstream
also has a community to please.  And popcon may just be an indication on
the number  of our users that  are pissed enough to  install from source
because installing "nodejs" package did not deliver the right command.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n");
2.2.16 /usr/src/linux/drivers/char/msp3400.c


pgph3qWiNffw1.pgp
Description: PGP signature

Re: Licenses not in /usr/share/common-licenses

[Gergely Nagy]

Joey Hess  writes:

> Gergely Nagy wrote:
>> debian/$package.docs:
>> | #! /usr/bin/dh-exec --with=copyright-magic
>> | debian/copyright.in | copyright-magic
>> | README.md
>> | whatever-else-you want
>
> On the off chance this is not another long-delayed April 1 post,
> let me mention that, since this relies on undocumented debhelper
> internals (order dh_installdocs does stuff), I will not hesitate
> to break it at any time.

It only depends on the order if there is a debian/copyright, and .docs
is used to override it. If there isn't one, then the order in
dh_installdocs does not matter, I believe.

I do agree though, that there are far superior ways to accomplish pretty
much the same thing.

My caffeine level was below a healthy amount yesterday, apologies! In
light of that, please disregard my former mail, thanks!

-- 
|8]


-- 
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/87zk9j2j5f.fsf@algernon.balabit

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO  Lors de  la soirée  naissante  du lundi  07 mai  2012, vers  18:29,
Patrick Lauer  disait :

>>> No, enough politeness.  We get that you like the way Gentoo does things
>>> (lots of options, you get to keep the pieces when they break), but some
>>> of us are trying to make Debian better than that.  We don't need more
>>> half-assed options, we need a solution.
>> AOL.
>> 
> Y'all really want to play that game?
[...]

Very constructive. Thanks.

> Now, we can just continue mudslinging, and in the end it's great fun but
> nothing productive, or you guys could just stop looking down on
> everything else and accept that sometimes other people do produce decent
> things.

> If you want to make Debian better you could start by looking at where
> others have eclipsed you already and figure out how to catch up. Unless
> you are willing to accept that possibility and learn you'll be stuck in
> NIH hell and rediscover every little corner case and trivial  bug that
> others already fixed years ago.

The  initial discussion  was about  to change  our current  default init
system to  something better.   OpenRC is better.  But as is  systemd and
upstart. Nobody is in the process of rewriting a new init.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


pgpJm4Vz52eCJ.pgp
Description: PGP signature