Charles Plessy | 1 Oct 03:28 2009
Picon

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

Dear all,

my question triggered a lot of answers… In this message, I will first make a
few clarifications, then try to summarise, and conclude with my own opition.

First, I would like to underline that I am not questionning how applications
should be named, or whether Debian maintainer who chose to rename applications
whose suffix indicates their language should stop to do so. What I am asking is
whether the advantages of renaming always balance the inconveniences in such a
systematic way that not renaming is a bug for which there is most often no
excuse. Rephrased more formally, I would like the ‘should’ request to rename in
the Policy 10.4 to be either softened or removed.

Some people expressed opinions in this discussion which either support my point
of view [1,2], or suggest that the issue of this debate is open [3,4,5].

[1] http://lists.debian.org/msgid-search/20090929062143.GA5792 <at> sumost.ca
[2] http://lists.debian.org/msgid-search/4AC20F1A.1000103 <at> glondu.net
[3] http://lists.debian.org/msgid-search/87fxa560x9.fsf <at> windlord.stanford.edu
[4] http://lists.debian.org/msgid-search/20090929094727.GA7923 <at> pcpool00.mathematik.uni-freiburg.de
[5] http://lists.debian.org/msgid-search/1254218108.19307.21.camel <at> shizuru

One of the biggest problems of renaming programs is that it breaks systems [6]
as well as documentation [7]. In case of online documentation, we can not
correct it.

[6] http://lists.debian.org/msgid-search/1254217244.28005.5.camel <at> fsopti579.F-Secure.com
[7] http://lists.debian.org/msgid-search/200909292045.35783.david.goodenough <at> btconnect.com

The typical way Debian deals with renaming programs is to keep the original
(Continue reading)

Picon

Bug#549160: ITP: qjson -- qt-based library that maps JSON data to QVariant objects

Package: wnpp
Severity: wishlist
Owner: "Lisandro Damián Nicanor Pérez Meyer" <perezmeyer <at> gmail.com>

* Package name    : qjson
  Version         : 0.6.2
  Upstream Author : Flavio Castelli <flavio <at> castelli.name>
* URL             : http://qjson.sourceforge.net/
* License         : LGPL-2
  Programming Lang: C++
  Description     : qt-based library that maps JSON data to QVariant objects

JSON (JavaScript Object Notation) is a lightweight data-interchange format.
It can represents integer, real number, string, an ordered sequence of value,
and a collection of name/value pairs.

QJson is a qt-based library that maps JSON data to QVariant objects: JSON
arrays will be mapped to QVariantList instances, while JSON objects will be
mapped to QVariantMap.

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org

John H. Robinson, IV | 1 Oct 04:41 2009
Picon

Re: renamings to remove extensions

Steve Langasek wrote:
> On Tue, Sep 29, 2009 at 10:05:29AM -0700, John H. Robinson, IV wrote:
> 
> > /var/qmail/bin/qmail-send
> > /command/supervise
> 
> DJB bug.

The correct answer:
  Difference of opinion.

> (And a symlink doesn't make the software FHS-compliant.)

In the case of qmail-send[1], the binary lives in /usr/sbin, which is
FHS compliant. The symlink is to keep it DJB compliant.

 [1] and the rest of the qmail binaries

--

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

Andreas Tille | 1 Oct 07:39 2009
Picon

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

On Thu, Oct 01, 2009 at 10:28:38AM +0900, Charles Plessy wrote:
> my question triggered a lot of answers??? In this message, I will first make a
> few clarifications, then try to summarise, and conclude with my own opition.

Charles, thanks for the summary.

> If Debian some day publishes a list of
> universal best practices, I will be of course be happy so send a link to it
> Upstream, and suggest them to follow it for their next project. Of course,
> writing such a document is a real challenge, and as an illustration it was
> pointed that suffixes are necesary on Windows [15], an operating system that
> many Upstreams are committed to support.

This is also an important point I wanted to rise (but just forgot).
Currently every single maintainer is forced to invent a convincing text
to educate upstream.  The position of a single maintainer could be
drastically strengthened if there would be a widely accepted document
(not only in the Debian world) which gives a clear reasoning.  Writing
such a document and finding agreement in several distributions is
challenging - but IMHO a reasonable step if we want to stick to our
policy in the current form.  Relaxing the policy as Charles proposed
might be the alternative.

Kind regards

         Andreas.

--

-- 
http://fam-tille.de

(Continue reading)

Ben Finney | 1 Oct 08:48 2009
Picon

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

Andreas Tille <andreas <at> an3as.eu> writes:

> Currently every single maintainer is forced to invent a convincing
> text to educate upstream. The position of a single maintainer could be
> drastically strengthened if there would be a widely accepted document
> (not only in the Debian world) which gives a clear reasoning. Writing
> such a document and finding agreement in several distributions is
> challenging - but IMHO a reasonable step if we want to stick to our
> policy in the current form.

Perhaps <distributions <at> lists.freedesktop.org> would be an appropriate
forum to attempt formulation of such a policy.

-- 
 \       “Liberty, n. One of imagination's most precious possessions.” |
  `\                   —Ambrose Bierce, _The Devil's Dictionary_, 1906 |
_o__)                                                                  |
Ben Finney

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org

Alan Woodland | 1 Oct 17:40 2009
Picon

Bug#549216: ITP: libvisca -- Implementation of VISCA cameras control protocol

Package: wnpp
Severity: wishlist
Owner: Alan Woodland <awoodland <at> debian.org>

* Package name    : libvisca
  Version         : 1.0.1
  Upstream Author : Damien Douxchamps <ddouxchamps <at> users.sourceforge.net>
* URL             : http://damien.douxchamps.net/libvisca/
* License         : LGPL-2
  Programming Lang: C
  Description     : Implementation of VISCA cameras control protocol

 VISCA is a protocol used to control many pan and tilt cameras. It is commonly
 found in cameras used for computer vision or robotics research, as well as
 video conferencing.
 .
 libVISCA is a library for controlling a VISCA(tm) compliant camera through the
 RS232 port of your PC. VISCA, on its side, is a protocol developed by Sony so
 that a lot of machine vision cameras from Sony are compliant with VISCA.
 .
 Typical cameras include the FCB-IX47 family of camera block for OEMs.
 Note that other devices, such as VCRs, can be controlled.
 .

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

(Continue reading)

Ernesto Hernández-Novich | 1 Oct 17:56 2009
Picon

Is Mari Wang MIA?

Hi.

I've been trying to contact Mari Wang for about three weeks now, first
through private e-mail then through the BTS [1]. The private e-mail was
pretty much the same as the last response to #521889, explaining that I
work on the webgui package and it needed the latest upstream for
libimage-exiftool-perl (thus filing a bug), but also offering to take
over the package to the Debian Perl Group [2]

The last upload for that package was on 2008-06-15, sponsored by Petter
Reinholdtsen [3]. Also, libimage-exiftool-perl is the lone package being
maintained by Mari Wang.

Can anyone get in touch with her?

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521889
[2] http://pkg-perl.alioth.debian.org
[3] http://packages.qa.debian.org/libi/libimage-exiftool-perl.html
    who-uploads --date libimage-exiftool-perl
-- 
Prof. Ernesto Hernández-Novich - MYS-220C
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org

(Continue reading)

Adam C Powell IV | 1 Oct 20:34 2009
Picon

Bug#549238: ITP: elmerdoc -- Elmer FEA documentation

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel <at> lists.debian.org, debian-science <at> lists.debian.org

Package name: elmer-doc
Version: 2009.09.22
Author: CSC – IT Center for Science, Finland
License: CC-BY-ND 3.0
URL: http://www.csc.fi/elmer/
Description: Documentation for Elmer finite element analysis package

Elmer is an open source mutiphysics simulation package developed by CSC
in collaboration with Finnish universities, research institutes and
industry.  It includes physical models of fluid dynamics, structural
mechanics, electromagnetics, heat transfer and acoustics, for example.
These are described by partial differential equations which Elmer solves
by the Finite Element Method (FEM).

This non-free package will contain the PDF documentation files for Elmer
which are available under the Creative Commons Attribution-No Derivative
Works 3.0 License.

-Adam
--

-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
Daniel Nicoletti | 1 Oct 20:49 2009
Picon

Re: Debconf and PackageKit

Hey Josselin,

> De: Josselin Mouette

> > > > This solution is not implemented as I don't know debconf verry well
> > > > but there is one problem that I'd like to know if there is a already a way
> > > > to deal with this:
> > > > when aptcc backend starts installing packages it's status are in a fd
> > > > which might be localized is LANG is set, so I clean LANG
> > > > and get dpkg to give strings like
> > > > removing, unpacking, that can be converted to an enum.
> > > Ugh, that’s an absolutely horrible and broken solution. You should use
> > > the --status-fd dpkg option instead.
> > hmm ok I'll investigate on how to use that in an apt-get based code..
> 
> Why do you use apt-get and not libapt? Especially if you’re working on a
> C++ frontend…

Ok now I'm forking and using --status-fd, but i got this localized
pmstatus:k3b:0:Removendo k3b

which i can't parse, actually i'm a bit afraid if it's status are
some kind of standard, maybe i should look at the source.. :P

So what's the best solution anyway?
Clean the child env vars?

Thanks,
Daniel.

(Continue reading)

Kevin B. McCarty | 1 Oct 21:30 2009
Picon

Re: Orphaning my packages...

Hi Francois,

On Wed, Sep 30, 2009 at 3:04 AM, francois.niedercorn2 <at> laposte.net
<francois.niedercorn2 <at> laposte.net> wrote:

> Now, the first step I've to do is to answer every of these bug reports
> (cernlib - #508413, cfortran - #508500,geant321 - #508496, mclibs -
> #508498, mn-fit - #508501, paw - #508495) by changing the subject with
> ITA, am I right ?

Yes.  (By the way, if you don't use all of those packages, you aren't
obligated to adopt every single one!  I know that mn-fit and mclibs,
at least, have really low popcon numbers, so if you don't have any use
for them, feel free to leave them orphaned.)

> For the second step : "upload the packages with my name in its
> Maintainer: field, and put something like | * New maintainer (Closes:
> #bugnumber) | in the changelog of the package in order to automatically
> close this bug once the package has been installed." I can't upload the
> packages, so I need to ask to debian-mentors-list (or debian-science) to
> find a sponsor for the upload, is this correct ?

Yes.  However, take note that some of the source packages are quite
large, and it is a little hard on the buildd machines to make a new
upload solely for the purpose of changing the maintainer name/email.
I'd suggest also doing at least some cleanup of Lintian warnings prior
to a new upload.

(But really, you're free to do whatever you like as long as someone
will sponsor it :-)
(Continue reading)


Gmane