Re: RFS: normalize-audio (updated package)

[Kapil Hari Paranjape]

Hello,

On Mon, 03 Sep 2007, Joachim Reichel wrote:
> I am looking for a sponsor for the new version 0.7.7-2
> of my package "normalize-audio".

I haven't checked this in detail but a quick look shows additional
build-dependencies:
Build-Depends: debhelper (>= 5), dpatch, autotools-dev,
  libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac

as compared with:
Build-Depends: debhelper (>= 5), autotools-dev,
  libaudiofile-dev, libmad0-dev, vorbis-tools

As far as I could see the build does not depend on mpg321,
vorbis-tools or flac as no audio files are being converted during the
build.

Regards,

Kapil.
--



signature.asc
Description: Digital signature

Re: RFS: steam-powered

[Miriam Ruiz]

2007/9/3, Ben Finney <[EMAIL PROTECTED]>:
>
> "Michael Gilbert" <[EMAIL PROTECTED]> writes:
>
> > > The users *are* free to choose the software that's out there. The
> > > Debian project is also free to refuse to choose what software it
> > > distributes.
> >
> > the key word is "distribution."  the question is whether the part of
> > the software to be added to the archive is distributable.  for
> > steam-powered, all of the software in the package is fully GPL'd, and
> > thus freely redistributable under the terms of the GPL.
>
> I don't think that was in question. This sub-thread is discussing
> whether we *want* software in Debian whose only purpose is to sell
> non-free software.


I for one would prefer not to concentrate too much in adding that kind of
software to Debian, and even less in trying to promote it if there's no real
demand for it beforehand. Of course if someone is willing to do the job and
there's demand for it and Debian in general sees it OK, it's OK for me. It
would be nice to launch the flame to debian-devel in advance, just in case.

Anyway, even if the Team as a group decides to invest some effort into those
kind of programs, I'll concentrate myself in DFSG-free stuff and, the most,
some other slightly less free, but not that much.

So, my personal vote, just speaking for myself, is that I'm not willing to
devote a single second of my time supporting those programs

Software must be DFSG-free to be in Debian. Not all DFSG-free software
> must be distributed by Debian.


Agreed

Miry

RFS: Piklab - IDE for PIC-microcontroller development

[Miriam Ruiz]

Piklab is an integrated development environment for applications based on
Microchip PIC and dsPIC microcontrollers similar to the MPLAB environment.

Support for several compiler and assembler toolchains is integrated. The
GPSim simulator, the ICD1 programmer, the ICD2 debugger, the PICkit1 and
PICkit2 programmers, the PicStart+ programmer, and most direct programmers
are supported. A command-line programmer and debugger is also available.

Piklab is an application for the KDE desktop.

Homepage: http://piklab.sourceforge.net/

Packages: http://mentors.debian.net/debian/pool/main/p/piklab/
DSC File:
http://mentors.debian.net/debian/pool/main/p/piklab/piklab_0.14.5-1.dsc

As usual, feedback is welcome :)

Miry

does anyone work on SMSer ?

[Jabka Atu]

Hello ,..


i wish to create a debian package for SMSer by guySoft i didn't found an
itp for it but maybe someone is working and didn't send one ;-)



-- 
--
Could you at least use man ?
Jabka Atu (aka mha13/Mashrom Head)
--


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

Re: RFS: steam-powered

[Josef Spillner]

On Monday 03 September 2007 11:29:17 Miriam Ruiz wrote:
> I for one would prefer not to concentrate too much in adding that kind of
> software to Debian, and even less in trying to promote it if there's no
> real demand for it beforehand.

Very well said, Miriam. There are similar issues with other applications which 
rely on non-free services to work correctly. GmailFS is a prime example for 
this. Instead of promoting clients for provider-specific services, Debian 
should promote standard interfaces to services and free implementations 
thereof, and free clients to access them. This gives users more choice, and 
as business people would say, provide a safer investment for the future.

We already have free multiplayer frameworks in Debian. Let's promote those as 
they in turn promote running free games on them.

Another issue with Steam specifically is that it doesn't allow users to be 
located in countries which were erased from the USA proprietary variant of 
the world map (http://www.valvesoftware.com/terms.html). I would say that 
this renders even the downloader non-DFSG-free, but that's probably 
for -legal to decide.

Josef


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

Re: RFS: normalize-audio (updated package)

[Kevin Coyner]

On Mon, Sep 03, 2007 at 12:32:38PM +0530, Kapil Hari Paranjape wrote..

> > I am looking for a sponsor for the new version 0.7.7-2
> > of my package "normalize-audio".
> 
> I haven't checked this in detail but a quick look shows additional
> build-dependencies:
>   Build-Depends: debhelper (>= 5), dpatch, autotools-dev,
> libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac
> 
> as compared with:
>   Build-Depends: debhelper (>= 5), autotools-dev,
> libaudiofile-dev, libmad0-dev, vorbis-tools

I think you do need dpatch though ...

Separately, in the control file, is it still necessary to keep:

Replaces: normalize
Conflicts: normalize

since normalize was removed from unstable back in Jan. 2005? I guess
it is possible that a system was built back in 2004, or off of an
old install disk, and that that system had normalize installed and
is still using it. Just wondering how long it makes sense to keep
Conflicts/Replaces statements for packages no longer in the
archives

Regards,
Kevin


-- 
Kevin Coyner  GnuPG key: 1024D/8CE11941


signature.asc
Description: Digital signature

RFS: xpn

[Michael Krauss]

Dear mentors,

I am looking for a sponsor for my package "xpn".

* Package name: xpn
  Version : 0.7.0-3
  Upstream Author : Antonio Caputo <[EMAIL PROTECTED]>
* URL : http://xpn.altervista.org/index-en.html
* License : GPLv2
  Section : net

It builds these binary packages:
xpn- GTK based news reader, written in python

The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/x/xpn
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/x/xpn/xpn_0.7.0-3.dsc

I would be glad if someone uploaded this package for me.


Beside the above standard text i want to give a more detailed
description of the debianic part of the package.

Originally XPN runs out of its own directory where all program files
and the user data are stored. Fortunately the program provides an
option to store user data in home directory. Thus i have done the
following:

- made storing user data in home directory standard by using a shell
  script for start XPN (xpn.sh)
- added a simple man page to comply to policy
- added a desktop file and converted icon to xpm format for smooth menu
  integration
- created a symlink from /usr/bin/xpn to /usr/share/xpn/xpn.sh
  When putting the shell script directly into /usr/bin, the program
  isn't running (See README file in original source)  

Of course one can ask, why putting xpn to /usr/share and not
to /usr/lib. I was unsure in this point, so i read FHS chapter 4. After
comparing
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
and
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
i concluded to use /usr/share, because the python files are
architecture independent (as far as a python interpreter is available,
of course).

As this is my first debian package, comments are most welcome.


Kind regards
 Michael Krauss


signature.asc
Description: PGP signature

Re: RFS: xpn

[schoenfeld / in-medias-res]

Hi,

Michael Krauss wrote:
> - dget http://mentors.debian.net/debian/pool/main/x/xpn/xpn_0.7.0-3.dsc

IANADD, therefore i cannot upload you package, but anyways some comments:

Major problems:
* xpn appears to be the first package you release, therefore it must not
 have a debian revision higher then -1. This has an affect on
debian/changelog which should only contain one version.
* the script that launches xpn is installed without the executable bit
set. this is an error, cause it makes it impossible to start xpn without
   adding the flag manually.
* README.Debian must not be present if it does not contain any useful
information for the users. It should be removed.

Minor problems:
* debian/changelog has a useless empty line at EOF
* debian/rules contains some not neccessary empty lines

Best Regards
Patrick




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

Re: RFS: xpn

[Jan C. Nordholz]

Hi,

> Major problems:
> * xpn appears to be the first package you release, therefore it must not
>  have a debian revision higher then -1. This has an affect on
>  debian/changelog which should only contain one version.

I don't remember that there was a consensus about whether unreleased versions
should be kept in the changelog (link appreciated if someone knows better).
This will depend on the sponsor's preference, and thus I wouldn't consider it
a "major problem" (but IANADD either).


Regards,

Jan


signature.asc
Description: Digital signature

Re: RFS: xpn

[Norbert Preining]

On Mon, 03 Sep 2007, Jan C. Nordholz wrote:
> > * xpn appears to be the first package you release, therefore it must not
> >  have a debian revision higher then -1. This has an affect on
> >  debian/changelog which should only contain one version.
> 
> I don't remember that there was a consensus about whether unreleased versions
> should be kept in the changelog (link appreciated if someone knows better).
> This will depend on the sponsor's preference, and thus I wouldn't consider it
> a "major problem" (but IANADD either).

I guess it shouldn't be a problem to "start" real Debian life with a
revision higher than -1, but you have to take care that the .changes
file contains a reference to the .orig.tar.gz so that it is uploaded,
otherwise it will be missing.

But I never tried it.

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
HAGNABY (n.)
Someone who looked a lot more attractive in the disco than they do in
your bed the next morning.
--- Douglas Adams, The Meaning of Liff


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

Re: RFS: xpn

[schoenfeld / in-medias-res]

Jan C. Nordholz wrote:
> I don't remember that there was a consensus about whether unreleased versions
> should be kept in the changelog (link appreciated if someone knows better).
> This will depend on the sponsor's preference, and thus I wouldn't consider it
> a "major problem" (but IANADD either).

Hmm. Well i have no link, cause i don't know that there has been any
different opinions on this. It might not be a technical problem, but as
the changelog is part of what the users _can_ see it might not be a good
idea to publish something thats not available to anyone, but the
developer. To say: If there is something you don't wanna show the user,
why would you want to tell him, that it exists? Just to nag him?

Apart from this: I don't think that Michael did this by intension.

Regards,
Patrick


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

RFS: New ccontrol package, 0.9.1+20060806-4

[Ted Percival]

Hello mentors!

I have a new ccontrol package ready for upload. Once again it is a minor
change from the last version:

  * Force-disable GCC stack protection as it is incompatible with the
current dietlibc (Ubuntu #109157).
  * Don't ignore errors in $(MAKE) distclean.

The first change will fix an unavoidable segfault at startup on Ubuntu.
Is there a name for that, FTRAA - Fails To Run At All?

The second is a change suggested by Lintian for the clean target.

It should be a nice safe upload for Debian and a lifesaving fix on
Ubuntu which I just found out is well on its way into freeze.

Here it is: 
http://mentors.debian.net/debian/pool/main/c/ccontrol/ccontrol_0.9.1+20060806-4.dsc


I originally emailed my regular sponsor, Amaya, but this time didn't get 
an immediate reply -- so I'm posting to mentors. This fix is important 
for Ubuntu so I'd like to get it into Debian ASAP so it can be synced.


Please CC me on replies.

--
\0


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

Advocate needs

[Alexander Rodin]

Hi all!
I have develop program (http://qstardict.ylsoftware.com) and maintain
Debian package for them. Now I want to put them to Debian. Can anyone to
be my advocate?
-- 
Alexander Rodin <[EMAIL PROTECTED]>


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

Re: Advocate needs

[Nico Golde]

Hi,
* Alexander Rodin <[EMAIL PROTECTED]> [2007-09-03 16:18]:
> I have develop program (http://qstardict.ylsoftware.com) and maintain
> Debian package for them. Now I want to put them to Debian. Can anyone to
> be my advocate?

You don't need an advocate if you don't want to become an 
official Debian developer. If you just want your package in 
Debian you need a sponsor who uploads your package for you.
Have a look at:
http://mentors.debian.net/cgi-bin/maintainer-intro

Kind regards
Nico
-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
http://people.debian.org/~nion/sponsoring-checklist.html


pgp39z3ou1viA.pgp
Description: PGP signature

Re: Advocate needs

[Justin Pryzby]

On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote:
> Hi all!
> I have develop program (http://qstardict.ylsoftware.com) and maintain
> Debian package for them. Now I want to put them to Debian. Can anyone to
> be my advocate?
Hi Alexander,

Where are the debian sources?

Justin


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

Re: Advocate needs

[Alexander Rodin]

В Пнд, 03/09/2007 в 16:29 +0200, Nico Golde пишет:
> Hi,
> * Alexander Rodin <[EMAIL PROTECTED]> [2007-09-03 16:18]:
> > I have develop program (http://qstardict.ylsoftware.com) and maintain
> > Debian package for them. Now I want to put them to Debian. Can anyone to
> > be my advocate?
> 
> You don't need an advocate if you don't want to become an 
> official Debian developer. If you just want your package in 
> Debian you need a sponsor who uploads your package for you.
> Have a look at:
> http://mentors.debian.net/cgi-bin/maintainer-intro
> 
> Kind regards
> Nico
Thanks!
-- 
Alexander Rodin <[EMAIL PROTECTED]>


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

Re: Advocate needs

[Alexander Rodin]

В Пнд, 03/09/2007 в 10:19 -0400, Justin Pryzby пишет:
> On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote:
> > Hi all!
> > I have develop program (http://qstardict.ylsoftware.com) and maintain
> > Debian package for them. Now I want to put them to Debian. Can anyone to
> > be my advocate?
> Hi Alexander,
> 
> Where are the debian sources?
> 
> Justin
> 
> 
Hi, Justin!
There is a Debian sources:
http://qstardict.ylsoftware.com/files/qstardict-0.07-debian-sources.tar.bz2 .
But this have some problem: written by me manpage "qstardict.1" don't
installs...
 
Alexander


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

Re: RFS: xpn

[Daniel Leidert]

Am Montag, den 03.09.2007, 14:50 +0200 schrieb Norbert Preining:
> On Mon, 03 Sep 2007, Jan C. Nordholz wrote:
> > > * xpn appears to be the first package you release, therefore it must not
> > >  have a debian revision higher then -1. This has an affect on
> > >  debian/changelog which should only contain one version.
> > 
> > I don't remember that there was a consensus about whether unreleased 
> > versions
> > should be kept in the changelog (link appreciated if someone knows better).
> > This will depend on the sponsor's preference, and thus I wouldn't consider 
> > it
> > a "major problem" (but IANADD either).
> 
> I guess it shouldn't be a problem to "start" real Debian life with a
> revision higher than -1, but you have to take care that the .changes
> file contains a reference to the .orig.tar.gz so that it is uploaded,
> otherwise it will be missing.
> 
> But I never tried it.

I used to do this for several packages I provided via my personal page
before they were added to the Debian distribution. We (my sponsor and
me) never had problems with this. In the OPs case, I would suggest to
use the

- -v option for a .changes file over -1 to -3|uploaded revision
- -sa option for including the .orig.tar.gz

as documented in dpkg-buildpackage(1).

@Michael: Tell your sponsor, when you used these options! Most sponsors
rebuild the package and the -v and -sa options are not used by default.

Regards, Daniel


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

Re: RFS: xpn

[Jan C. Nordholz]

Hi,

> Hmm. Well i have no link, cause i don't know that there has been any
> different opinions on this. It might not be a technical problem, but as
> the changelog is part of what the users _can_ see it might not be a good
> idea to publish something thats not available to anyone, but the
> developer. To say: If there is something you don't wanna show the user,
> why would you want to tell him, that it exists? Just to nag him?

Why should I try to hide the normal course of development?  I don't see
the necessity to create extra loops (reformatting the changelog after
each intermediate package creation that is not uploaded) for me to jump
through. Have a look at this[1] thread, for example... that's not the
full discussion I remember, but I can't find it at the moment.

> Apart from this: I don't think that Michael did this by intension.

Hm, hard to tell. Oh, and for more real-world examples...

] [EMAIL PROTECTED]:/usr/share/doc$ find . -name changelog.Debian.gz | xargs 
zgrep -i UNRELEASED


Regards,

Jan

[1] http://lists.debian.org/debian-mentors/2007/07/msg00238.html


signature.asc
Description: Digital signature

review: qstardict (Re: Advocate needs)

[Justin Pryzby]

On Mon, Sep 03, 2007 at 07:12:18PM +0400, Alexander Rodin wrote:
> В Пнд, 03/09/2007 в 10:19 -0400, Justin Pryzby пишет:
> > On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote:
> > > Hi all!
> > > I have develop program (http://qstardict.ylsoftware.com) and maintain
> > > Debian package for them. Now I want to put them to Debian. Can anyone to
> > > be my advocate?
> > Hi Alexander,
> > 
> > Where are the debian sources?
> > 
> Hi, Justin!
> There is a Debian sources:
> http://qstardict.ylsoftware.com/files/qstardict-0.07-debian-sources.tar.bz2 .
> But this have some problem: written by me manpage "qstardict.1" don't
> installs...
Some comments.

You're the upstream author; why don't you include the manpage upstream
instead of in the .diff.gz?  I realize that manpages for graphical
programs are difficult to write well.  Does your program accept
keystrokes?  Does it have any other help file?

Is debian/dirs really necessary?  It's probably best if this is
handled by upstream install scripts, and debian foo used only as a
fallback.

Your changelog has two "Initial release" entries.  The second should
(by convention) instead read "New upstream release.".  Since you're
the upstream author you can include sub-bullets with the major changes
for that release.

The copyright file should specify under which versions of the GPL the
content is licensed and ideally include the full GPL header (but not
the full GPL).

doc-base isn't for listing manpage; see dh_installman for how to fix
that.

Section: universe/devel doesn't make sense for Debian.

At least the manpage and "rules" files should probably have some of
their comments removed.  Perhaps not all of them though.  The only
advantage to not removing comments is to easily be able to diff to new
templates...

+install: build

+binary-arch: build install

I really wish the redundant dependancy on "build" was either not
specified in the template or that someone would explain to me what
purpose it serves.  But I already reported it as bug #358722 and
apparently knowbody nos.

Justin


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

Re: RFS: normalize-audio (updated package)

[Joachim Reichel]

Hi,

>> I am looking for a sponsor for the new version 0.7.7-2
>> of my package "normalize-audio".
> 
> I haven't checked this in detail but a quick look shows additional
> build-dependencies:
>   Build-Depends: debhelper (>= 5), dpatch, autotools-dev,
> libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac
> 
> as compared with:
>   Build-Depends: debhelper (>= 5), autotools-dev,
> libaudiofile-dev, libmad0-dev, vorbis-tools
> 
> As far as I could see the build does not depend on mpg321,
> vorbis-tools or flac as no audio files are being converted during the
> build.

the reason for the Build-Depends is the configure script. If these
packages are not present at build time, the configure script does not
generate the default settings needed to call these tools. You can still
supply the necessary command line arguments for the enconder/decoder on
the command line, but it is quite convenient to have working defaults.

Joachim


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

Re: RFS: normalize-audio (updated package)

[Joachim Reichel]

Hi Kevin,


>>> I am looking for a sponsor for the new version 0.7.7-2
>>> of my package "normalize-audio".

>> I haven't checked this in detail but a quick look shows additional
>> build-dependencies:
>>  Build-Depends: debhelper (>= 5), dpatch, autotools-dev,
>>libaudiofile-dev, libmad0-dev, mpg321, vorbis-tools, flac
>>
>> as compared with:
>>  Build-Depends: debhelper (>= 5), autotools-dev,
>>libaudiofile-dev, libmad0-dev, vorbis-tools
> 
> I think you do need dpatch though ...

Did you confuse both stanzas? Kapil listed them in reverse order: I
*added* the dpatch dependency.

> Separately, in the control file, is it still necessary to keep:
> 
> Replaces: normalize
> Conflicts: normalize
> 
> since normalize was removed from unstable back in Jan. 2005? I guess
> it is possible that a system was built back in 2004, or off of an
> old install disk, and that that system had normalize installed and
> is still using it. Just wondering how long it makes sense to keep
> Conflicts/Replaces statements for packages no longer in the
> archives

Good point. Since they are not a large burden, it prefer to keep them
for now -- unless someone has a good point to drop them. Is there a
general consensus? I couldn't find anything in the docs.

Regards,
   Joachim


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

Re: debian .orig.tar.gz vs. upstream tar.gz

[Jörg Sommer]

Hi,

Kapil Hari Paranjape <[EMAIL PROTECTED]> wrote:
> On Mon, 27 Aug 2007, Jörg Sommer wrote:
>> > Do *not* get the upstream .tar.gz which may have changed for some
>> > mysterious reason.
>> 
>> I don't think the upstream tar.gz have changed, but your orig.tar.gz is
>> not the same as the upstream tar.gz. This happens if the orig.tar.gz was
>> repacked to rename the top directory to -.
>> dpkg-buildpackage -S does this as described by Policy C.4.
>
> Section C.4 describes how to unpack the source without dpkg-source
> not how it is repacked by dpkg-buildpackage

Right, but it's said there that you find a directory
-.orig. A simple program may fail, when it follows
the instructions in section C.4.

Bye, Jörg.
-- 
Wer in einem gewissen Alter nicht merkt, dass er hauptsächlich von
Idioten umgeben ist, merkt es aus einem gewissen Grunde nicht.
(Curt Goetz)


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

Re: review: qstardict (Re: Advocate needs)

[Alexander Rodin]

Thank you!

> You're the upstream author; why don't you include the manpage upstream
> instead of in the .diff.gz?  I realize that manpages for graphical
> programs are difficult to write well.  Does your program accept
> keystrokes?  Does it have any other help file?
I don't include manpage into program sources because it doesn't accept
any command line options.

> Is debian/dirs really necessary?  It's probably best if this is
> handled by upstream install scripts, and debian foo used only as a
> fallback.
> 
> Your changelog has two "Initial release" entries.  The second should
> (by convention) instead read "New upstream release.".  Since you're
> the upstream author you can include sub-bullets with the major changes
> for that release.
> 
> The copyright file should specify under which versions of the GPL the
> content is licensed and ideally include the full GPL header (but not
> the full GPL).
> 
> doc-base isn't for listing manpage; see dh_installman for how to fix
> that.
> 
> Section: universe/devel doesn't make sense for Debian.
> 
> At least the manpage and "rules" files should probably have some of
> their comments removed.  Perhaps not all of them though.  The only
> advantage to not removing comments is to easily be able to diff to new
> templates...
> 
> +install: build
> 
> +binary-arch: build install
> 
> I really wish the redundant dependancy on "build" was either not
> specified in the template or that someone would explain to me what
> purpose it serves.  But I already reported it as bug #358722 and
> apparently knowbody nos.
I have fix all this bugs and check package using lintian.
-- 
Alexander Rodin <[EMAIL PROTECTED]>


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

Re: review: qstardict

[Neil Williams]

On Mon, 03 Sep 2007 21:55:07 +0400
Alexander Rodin <[EMAIL PROTECTED]> wrote:

> > You're the upstream author; why don't you include the manpage upstream
> > instead of in the .diff.gz?  I realize that manpages for graphical
> > programs are difficult to write well.  Does your program accept
> > keystrokes?  Does it have any other help file?
> I don't include manpage into program sources because it doesn't accept
> any command line options.

? What has that got to do with anything ?

A manpage tells a user what a program does without having to run the
program - e.g. when interrogating a system over SSH or if X has just
died for whatever reason.

There is a reason why manpages are necessary for executables and it has
nothing to do with what any one particular executable can or cannot
actually do. It is about providing information on what the user can do
when faced with problems or when the user just needs information
without a GUI.

-- 


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



pgpG6Rgeq8xfj.pgp
Description: PGP signature

Re: RFS: xpn

[Michael Krauss]

Am Mon, 03 Sep 2007 17:39:54 +0200 schrieb Daniel Leidert:
> Am Montag, den 03.09.2007, 14:50 +0200 schrieb Norbert Preining:
> > On Mon, 03 Sep 2007, Jan C. Nordholz wrote:
> > > > * xpn appears to be the first package you release, therefore it
> > > > must not have a debian revision higher then -1. This has an
> > > > affect on debian/changelog which should only contain one
> > > > version.
> > > 
> > > I don't remember that there was a consensus about whether
> > > unreleased versions should be kept in the changelog (link
> > > appreciated if someone knows better). This will depend on the
> > > sponsor's preference, and thus I wouldn't consider it a "major
> > > problem" (but IANADD either).
> > 
> > I guess it shouldn't be a problem to "start" real Debian life with a
> > revision higher than -1, but you have to take care that the .changes
> > file contains a reference to the .orig.tar.gz so that it is
> > uploaded, otherwise it will be missing.
> > 
> > But I never tried it.
> 
> I used to do this for several packages I provided via my personal page
> before they were added to the Debian distribution. We (my sponsor and
> me) never had problems with this. In the OPs case, I would suggest to
> use the

This issue seems to be seen controversial. I had chosen the normal
revisions because of this page, linked from the "Instructions for
Maintainers" page:
http://people.debian.org/~codehelp/#sponsor
in particular the second item in the requirements section.

> - -v option for a .changes file over -1 to -3|uploaded revision

How should i use this option exactly?
In the newest .changes file only the last log entry is included by
default. Using -v1 includes the complete changelog into the .changes
file. That is strange, because the man page says: 
"Use changelog information from all versions *strictly* later than
version."

Well, for the next upload i will use -v1 to include the whole changelog.

> - -sa option for including the .orig.tar.gz

That makes sense.
 

Kind regards,
Michael Krauss


signature.asc
Description: PGP signature

Re: RFS: xpn

[Michael Krauss]

Hi,

Am Mon, 03 Sep 2007 14:27:40 +0200 schrieb schoenfeld / in-medias-res:
> Major problems:
> * xpn appears to be the first package you release, therefore it must
> not have a debian revision higher then -1. This has an affect on
> debian/changelog which should only contain one version.

there seem to exist different opinions on this issue.
I will change it, if necessary.
See other mail too.

> * the script that launches xpn is installed without the executable bit
> set. this is an error, cause it makes it impossible to start xpn
> without adding the flag manually.

Are you sure, that the executable bit isn't set?
Here i get the following:
[EMAIL PROTECTED]:~$ ls -l /usr/share/xpn/xpn.sh
-rwxr-xr-x 1 root root 559 2007-09-03 20:41 /usr/share/xpn/xpn.sh
What looks like i expected. And the program is executable.

> * README.Debian must not be present if it does not contain any useful
> information for the users. It should be removed.

Done. 
 
> Minor problems:
> * debian/changelog has a useless empty line at EOF

Done. I am always afraid of that kind of program, which expects a new
line at the end of a file. I am sorry.

> * debian/rules contains some not neccessary empty lines

Deleted some. Only the empty lines between two make targets remain.


Kind Regards,
Michael Krauss


signature.asc
Description: PGP signature

Re: RFS: xpn

[schönfeld / in-medias-res]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jan C. Nordholz wrote:
> Why should I try to hide the normal course of development?  I don't see

I agree that this *is* suboptimal. But it should not be part of normal
development cycle to create extra revisions that you do not release,
should it? IMHO it makes sense for some developer-only changelog, but
the debian/changelog has gotten a file, which is shown to the users
often and it might seem odd to them if versions therein do not exist.

> the necessity to create extra loops (reformatting the changelog after
> each intermediate package creation that is not uploaded) for me to jump

Well you are right in this point. But I seem to develope my packages in
another way then you. Cause i only start a new changelog entry, if i
really uploaded something through my sponsor to the archive.

> Hm, hard to tell. Oh, and for more real-world examples...

Yeah yeah. I think you are right if you say, that it *is* used and that
its okay to be used (even though i don't agree with it), but i would not
recommend it either, cause I think there are a lot of sponsors that just
will not upload such packages. This opinion results from the fact, that
I have seen more people criticizing multiple changelog entries/versions
for just a single release, then people that say that it is okay.

- -Patrick
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG3Ft5TKIzE6LY9r8RAu3qAKCM3OKsROlvo/OU7nkjr/HnFDoO7gCfazg/
PcJpWBo4fjf4hwaz6aIx6/o=
=wdo7
-END PGP SIGNATURE-


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

Re: RFS: steam-powered

[Michael Gilbert]

> This sub-thread is discussing whether we *want* software in Debian
> whose only purpose is to sell non-free software.

like i said before, the purpose of the package is to help the average
user to easily run the software of their choice on linux.  steam does
include a store, but it is by no means the only purpose for the
software.

> Software must be DFSG-free to be in Debian. Not all DFSG-free software
> must be distributed by Debian.

if someone is willing to package and maintain it, then why not?  i
thought the goal was for debian to be the universal operating system.
how can the system be universal if software is refused because it is
used to run non-dfsg software?  if that is the case, then one should
reject wine, iceweasel, gcc, and any other software that could be used
to run non-dfsg software.

as i understand it, to become a debian developer, one has to agree to
adhere to the social contract (even if it doesn't fully conform to
one's personal feelings -- it is after all for the greater good of the
debian project).  hence, your argument needs to be made in the context
of the social contract, and it is very clear that the contrib and
non-free archives are to be supported by debian for those users who
require the use of non-dfsg works.


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

Re: RFS: xpn

[Jan C. Nordholz]

Hi,

> Are you sure, that the executable bit isn't set?
> Here i get the following:
> [EMAIL PROTECTED]:~$ ls -l /usr/share/xpn/xpn.sh
> -rwxr-xr-x 1 root root 559 2007-09-03 20:41 /usr/share/xpn/xpn.sh
> What looks like i expected. And the program is executable.

] dpkg-deb -c xpn_*deb
[...]
-rw-r--r-- root/root   559 2007-09-03 21:42 ./usr/share/xpn/xpn.sh

No, it isn't. You are calling dh_fixperms in your debian/rules... I guess
you'll have to tell it not to modify the permissions of that file.


Regards,

Jan


signature.asc
Description: Digital signature

Re: RFS: steam-powered

[Michael Gilbert]

> I for one would prefer not to concentrate too much in adding that
> kind of software to Debian, and even less in trying to promote it
> if there's no real demand for it beforehand.

there is demand.  90% of computer users play games, and steam has a
lot of users (3 million players per month [1]).  having an easy to
install package will ease their transition to an alternative operating
system.

>  So, my personal vote, just speaking for myself, is that I'm not willing to
> devote a single second of my time supporting those programs

although i personally disagree (i think "free" and "non-free" software
can and should coexist equally), i do understand your viewpoint.  i
will take full responsibility for the package.  if it becomes RC-buggy
or goes unfixed, i would understand if it were removed from the
archive -- of course i will work hard to make sure that doesn't
happen.  i will not need much support except for someone willing to
upload the package.

> We're not really discussing whether such a package should belong to
> Debian or not, that's not our task and in any case that kind of discussion
> should be taken to debian-devel instead. We're not even discussing
> whether such a package should belong to contrib or to non-free, that
> discussion should be better handled in debian-legal. And of course, if
> someone is willing to maintain such a package, it's not gonna be me who
> forbid them to do so.

ok, i will take the discussion to the appropriate lists.  i have been
trying to address the concerns as they have been brought up on this
list.

[1] http://www.steampowered.com/v/index.php?area=stats&cc=US


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

Advice on HTML docs

[Neil Williams]

homebank was the subject of an RFS some time ago and had problems with
non-GPL licenced SVG images (which, I admit, I completely missed).

These were fixed and I uploaded a new upstream version provided by the
maintainer but it was rejected because there is no source for the HTML
documentation.

"
rejected, the source of doc/*.html is missing. If you look into the
files you see a "Generator" Metatag pointing at GuideML. According
to wikipedia (http://en.wikipedia.org/wiki/GuideML) thats a
meta-language used to generate files out of it.
"

The history is this: The HTML docs were (once upon a time) created
using an Amiga application before the port to Ubuntu/Debian. Upstream
now maintain the docs using text editors rather than automated tools -
upstream just haven't removed the generator meta tags. The maintainer
put a note to this effect in README.Debian prior to the rejection.

The docs themselves are nicely done and there is no good reason to
recommend one of the standard automated documentation tools which
would tend to produce a less polished output overall.

README.Debian in the rejected package contains:

homebank for Debian
---

Homebank is a project born for the amiga, now the author has migrated it
to GTK+, the primary development target is linux, but the roadmap
previews a macOS port (quite done) and a window$ port.

PATCHES TO HTML DOCUMENTATION
-
If you want to contribute enhancing the html feel free to send patches
to the upstream author or to the maintainers of homebank. Consider that
the documentation is made using a normal text editor, so a simple patch
is fine.

 -- Francesco Namuri <[EMAIL PROTECTED]>  Mon, 20 Aug 2007 00:57:09
+0200

Does Debian really need to ask upstream for a new release with the
meta tags tweaked when there is notice that a normal text editor is used
for the docs?

The generator tag is historical - an artefact of the original migration
from Amiga. OK, README.Debian could be a bit more explicit I know, but
what else can / should be done to allow homebank into Debian without
requiring a new upstream release?

-- 


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



pgp2ECDkw3rY2.pgp
Description: PGP signature

Re: RFS: normalize-audio (updated package)

[Kevin Coyner]

On Mon, Sep 03, 2007 at 12:09:41AM +0200, Joachim Reichel wrote..

> I am looking for a sponsor for the new version 0.7.7-2
> of my package "normalize-audio".
> http://mentors.debian.net/debian/pool/main/n/normalize-audio/normalize-audio_0.7.7-2.dsc

You need to complete the debian/copyright a little more as it does
not even reference GPL v2, which it is. See the package tnef for an
example. A good habit is to run

licensecheck -r .

from the working directory on every package you work on.

A bit picky on my part, but remove the:

## All lines beginning with `## DP:' are a description of the patch.

line in debian/patches/*.dpatch files. It just takes up space. You
might also consider slightly more verbose descriptions in each patch
just to make it easier on yourself (or the next maintainer) a few
years from now. Also, make sure to pass on the patches to upstream.

Other than that, looking O.K. although I'm unable to build it right
now because pbuilder can't seem to pull down the packages:

libvorbis0a
libvorbisenc2
libvorbisfile3

from the ftp.us.debian.org archives. I'll try again in a little bit.

Regards,
Kevin

-- 
Kevin Coyner  GnuPG key: 1024D/8CE11941


signature.asc
Description: Digital signature

Re: RFS: xpn

[Patrick Schoenfeld]

Michael Krauss wrote:
> Are you sure, that the executable bit isn't set?

Yes.

> Here i get the following:
> [EMAIL PROTECTED]:~$ ls -l /usr/share/xpn/xpn.sh
> -rwxr-xr-x 1 root root 559 2007-09-03 20:41 /usr/share/xpn/xpn.sh

That is why you should use something like pbuilder etc. to test your
packaging, cause its bad to test things in an environment where other
conditions might be met. Just sidenoted.

> Done. I am always afraid of that kind of program, which expects a new
> line at the end of a file. I am sorry.

Well, i think not everybody finds that bad. I find it ugly. Thats why i
told you to better remove it.

>> * debian/rules contains some not neccessary empty lines
> 
> Deleted some. Only the empty lines between two make targets remain.

Yeah, fine. Those empty lines between the targets are good. I just
thought that those empty lines in between commands in a target are
silly, or double-empty lines.

So well:
I have checked your new version -4 and I'm afraid that it builds up a
bogus link to the binary. You must not use absolute pathes in the links,
as this will fail on systems other then the one were the package is
built (and ofcourse it will not work after removing the src directory)-
I would recommend you to use dh_link.

Regards,
Patrick


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

Re: RFS: xpn

[Daniel Leidert]

Am Montag, den 03.09.2007, 20:59 +0200 schrieb Michael Krauss:
> Am Mon, 03 Sep 2007 17:39:54 +0200 schrieb Daniel Leidert:
> > Am Montag, den 03.09.2007, 14:50 +0200 schrieb Norbert Preining:

[..]
> > > I guess it shouldn't be a problem to "start" real Debian life with a
> > > revision higher than -1, but you have to take care that the .changes
> > > file contains a reference to the .orig.tar.gz so that it is
> > > uploaded, otherwise it will be missing.
> > > 
> > > But I never tried it.
> > 
> > I used to do this for several packages I provided via my personal page
> > before they were added to the Debian distribution. We (my sponsor and
> > me) never had problems with this. In the OPs case, I would suggest to
> > use the
> 
> This issue seems to be seen controversial. I had chosen the normal
> revisions because of this page, linked from the "Instructions for
> Maintainers" page:
> http://people.debian.org/~codehelp/#sponsor
> in particular the second item in the requirements section.

This sounds like the common way and it is similar to what I suggested.

> > - -v option for a .changes file over -1 to -3|uploaded revision
> 
> How should i use this option exactly?
> In the newest .changes file only the last log entry is included by
> default. Using -v1 includes the complete changelog into the .changes
> file. That is strange, because the man page says: 
> "Use changelog information from all versions *strictly* later than
> version."

Yes, it says "version", not "Debian revision". The options expects the
full version, including the upstream version and the Debian revision.
Say you have

1.2.3-0mk1 private
1.2.3-1 released to mentors
1.2.3-2 released to mentors
1.2.3-3 released to Debian

then use `-v1.2.3-0mk1'.

Regards, Daniel


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

Re: Advice on HTML docs

[Russ Allbery]

Neil Williams <[EMAIL PROTECTED]> writes:

> These were fixed and I uploaded a new upstream version provided by the
> maintainer but it was rejected because there is no source for the HTML
> documentation.

> "
> rejected, the source of doc/*.html is missing. If you look into the
> files you see a "Generator" Metatag pointing at GuideML. According
> to wikipedia (http://en.wikipedia.org/wiki/GuideML) thats a
> meta-language used to generate files out of it.
> "

> The history is this: The HTML docs were (once upon a time) created using
> an Amiga application before the port to Ubuntu/Debian. Upstream now
> maintain the docs using text editors rather than automated tools -
> upstream just haven't removed the generator meta tags. The maintainer
> put a note to this effect in README.Debian prior to the rejection.

I think the only problem may be that the note isn't in the place they
looked.  I have a package with a similar problem (openafs-doc) and it was
approved, but I put the note to that effect in debian/copyright, which is
the file that the ftp-masters review for these sorts of issues and which
is the place to note the provenance and licensing of the source.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RFS: xpn

[Jan C. Nordholz]

Hi Patrick,

> Well you are right in this point. But I seem to develope my packages in
> another way then you. Cause i only start a new changelog entry, if i
> really uploaded something through my sponsor to the archive.

I usually do it that way, too. But there are cases when I have to create
intermediate packages anyway, e.g. preparing a new major version which I'd
like to test at work before I consider it ready for upload... installing
something on 100+ computers is easier if you create .deb's and throw them
into a private repository - and I wouldn't mind increasing the version
number after each test cycle if the number of new changelog entries warrants
it.

If the point is that users shouldn't see changelog entries which they've
never seen the corresponding package version to, then we should start
merging all changes made during a number of uploads to experimental in
one single big blob when a new upload to unstable is made - the users of
unstable have never seen those experimental versions, so we have to
artificially make it look like they have never happened?

I, too, remember there was a quite strong opposition - but I'm still searching
for the thread.

(Besides, I wouldn't call the Debian changelog a user-exposed file - its
contents are often quite cryptic to the casual user ("updated po files"...
"rediffed patch foo and blorb, minor changes to work nicely with libbar"...),
and the more experienced can live with a few more interspersed numbers. ;) )


Regards,

Jan


signature.asc
Description: Digital signature

Re: RFS: libsbc (updated package)

[Krzysztof Burghardt]

2007/8/9, Krzysztof Burghardt <[EMAIL PROTECTED]>:
> 2007/7/28, Krzysztof Burghardt <[EMAIL PROTECTED]>:
> > I am looking for a sponsor for the new version 0.0cvs20070728-1
> > of my package "libsbc".
> >
> > It builds these binary packages:
> > libsbc-dev - Development files for subband codec (SBC) library
> > libsbc0- Subband codec (SBC) library
> > sbcinfo- Subband codec (SBC) analyzer
> >
> > The package appears to be lintian clean.
> >
> > The package can be found on mentors.debian.net:
> > - URL: http://mentors.debian.net/debian/pool/main/l/libsbc
> > - Source repository: deb-src http://mentors.debian.net/debian unstable
> > main contrib non-free
> > - dget 
> > http://mentors.debian.net/debian/pool/main/l/libsbc/libsbc_0.0cvs20070728-1.dsc
> >
> > I would be glad if someone uploaded this package for me.
>
> I'm still looking for sponsor. This is really small library and
> changes aren't too big:
>  * New upstream checkout
>  * Add debian/get-orig-source.sh
>  * Add autotools clean rules
>  * Fixed dependency to use ${binary:Version} instead of ${Source-Version}
>  * Changed package build rules to not ignore "make clean" return code

This little package is waiting for its sponsor for 1 month. Anyone?

With regards,
-- 
Krzysztof Burghardt <[EMAIL PROTECTED]>
http://www.burghardt.pl/


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

Re: RFS: eprints

[Charles Plessy]

Le Thu, Aug 30, 2007 at 03:17:18PM +0100, David C Tarrant a écrit :
> Dear mentors,
> 
> I am looking for a sponsor for my package "eprints".
> 
> "Making Research Freely Available - For many years we have been helping 
> researchers and their institutions to provide free online access to their 
> research output (documents, multimedia and data)."

Dear David,

did you find a sponsor? If not, you can also try your luck on the
debian-science mailing list.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


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

Re: RFS: xpn

[Patrick Schoenfeld]

Jan C. Nordholz wrote:
> (Besides, I wouldn't call the Debian changelog a user-exposed file - its
> contents are often quite cryptic to the casual user ("updated po files"...
> "rediffed patch foo and blorb, minor changes to work nicely with libbar"...),
> and the more experienced can live with a few more interspersed numbers. ;) )

Hm, i don't remember if it was policy, but somewhere it has been said,
that changelog entries should not be to technical. But in fact more and
more application do expose the changelog to the user. See aptitude
changelog or the update-mananger.

Best Regards,

Patrick


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