Re: ITR: libitpp (updated package)

[Kumar Appaiah]

Dear Neil,

I have a new package ready at:
http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_3.99.2-1.dsc

On 01/07/07, Neil Williams wrote:

> > A -dbg package needs to be provided.
> > (-dbg packages are likely to become mandatory by Lenny.)


Done this.


In practical terms, not all those who need the -dev package are
actually writing new software with that -dev. A lot are simply
*building* reverse dependencies of that -dev. When someone needs to
build pilot-qof, there is no need for them to have libqof-doc, they
only need libqof-dev. Such issues also affect the autobuilders - there
is no need for them to have the doc content when trying to build a
dependency using the -dev.


I understand this well. It's just that IT++ isn't meant to be a
library used by applications, though I don't discount that. Mostly,
it's for writing simulation programs for various communication schemes
etc., with many of GNU Octave or Matlab type features. But, I am also
in favour of splitting the docs.


No, tidying up the short descriptions so that the new packages are not
simple copies (as the -dev is currently).


I got this. Please look into the package now.


? You should always build your own packages with pbuilder at least once
for each upstream release - if only to ensure you have the
Build-Depends right. Simply watching or reading the pdebuild log will
show you that your package brings in more packages than a relatively
large GUI application. Please look beyond your own package and try to
anticipate problems.


Henceforth I shall be more aware. And the above debs are made using pbuilder.


> However, I guess I can drop dependency on atlas (see
> http://itpp.sourceforge.net/index.php?wiki=About ), though I'd consult 
upstream
> before doing that.

Yes, the reduced functionality is a concern. Upstream may be able to
separate the codebase so that you can create a libitpp-atlas6 and
libittp6 that would be without atlas - one conflicting and replacing
the other (not ideal) or one complementing the other by adding new
files without replacing libittp6 (harder to do upstream).


Right now, I've just removed the atlas3 dependency. Please check it
out, and I'll also talk to upstream about it. However, I don't think
features are lost by this change. If anything, performance will be
affected, to the best of my understanding.


Just put your email address into the subscribe box at:
http://packages.qa.debian.org/a/atlas3.html


Have done this.


> I am an "end-user" of this package, and not very familiar with the 
dependencies.
> Therefore, I didn't see the storm brewing.

Hmm. The New Maintainer Guide does clearly warn about packaging
libraries. What is the application that uses libittp? As sponsor I can
help with libittp issues and advise on other general issues but you do
need to take a lot of this on board yourself and find your own
motivation to look beyond the specific package and into the issues that
are just waiting to become *your* problems later.


I accept this advice. But note that it is highly unlikely that a
mathematical simulation type toolkit type library like IT++ will have
any applications based on it, though the possibility cannot be
discounted.

Anyway, I promise a more proactive role in the Debian packaging
procedure. After all, I am to be "mentored", right? :-)


> > > The package is lintian clean.
> >
> > No, it is not.


It is now.

Thanks a lot for your inputs. I am sure the package is a lot better
now, but please do mail in your comments for changes, and I shall
incorporate them.

Thanks again!

Kumar
--
Kumar Appaiah,
462, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600036


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

Re: RFS: kde-icons-crystalproject

[Paul Wise]

On 6/28/07, Raphael Geissert <[EMAIL PROTECTED]> wrote:


I'm using a datestamp because that seems to be the best way to handle
the 'version' of the icons pack.


To prevent the need for an epoch if upstream decides to use versions,
you might want to go with something like 0.0.20070625-1 or
0.0.2007.06.25-1.

--
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: ITS: fortunes-ru -- Russian data files for fortune

[DS]

2007/7/1, Nico Golde <[EMAIL PROTECTED]>:

Hi,
* Denis V. Sirotkin <[EMAIL PROTECTED]> [2007-07-01 16:25]:
> I am looking for a sponsor for my package "fortunes-ru".

I will sponsor this package. Just a few notes:

You use the Homepage tag in control but you just indent with·
one space, please use 2 as described in 6.2.4 developers·
reference.


Done.



You use Architecture: any in control which is wrong since·
the fortune data is architecture-independent. Please fix·
this, see policy 5.6.8.


Done.


Why do you have a build-dependency on fortune-mod?


Oh! I had removed this.


> The package is lintian clean.

It's not please check.
Fix the above issues and I will upload the package for you.


Fixed and uploaded to mentors.d.o. Please check again.

Thanks in advance.

--
wbr
 Denis Sirotkin

Re: A note on lintian clean packages and mentors.d.n

[Russ Allbery]

Neil Williams <[EMAIL PROTECTED]> writes:

> Minor and wishlist bugs still count - particularly for things like linda
> and lintian, which leads to 16 outstanding. (The lintian maintainer
> correctly insists that lintian - and therefore linda - are only
> indicators of problems and cannot catch all such problems, they are not
> intended to be the authoritative implementation of Policy.  Therefore,
> bugs in linda or lintian that relate to false positives, missing checks
> and wrong results are requested to be filed as wishlist only.) On that
> score, lintian has 99 bugs - yet lintian is still the better of the two.

Minor correction:  Missing checks should be filed as wishlist bugs, but
false positives and wrong results, unless explicitly already noted in the
long tag description, should be filed at normal or minor severity.  I try
to correct those as much as possible before each upload.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RFS: command-not-found

[Justin Pryzby]

On Sun, Jul 01, 2007 at 10:08:47PM +0200, Julian Andres Klode wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "command-not-found".
> 
> * Package name: command-not-found
>   Version : 0.2.4+debian-1
>   Upstream Author : Zygmunt Krynicki <[EMAIL PROTECTED]>
> Michael Vogt <[EMAIL PROTECTED]>
> * URL : https://launchpad.net/command-not-found
> * License : GPL
>   Section : admin
> 
> It builds these binary packages:
> command-not-found - Suggest installation of packages in interactive bash 
> sessions
How does it compare with auto-apt?  This a "shell-only" implementation
whereas auto-apt will find things which are accessed otherwise
(perhaps not bad).


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

Re: A note on lintian clean packages and mentors.d.n

[Neil Williams]

On Sun, 1 Jul 2007 15:05:54 -0500
"Raphael Geissert" <[EMAIL PROTECTED]> wrote:

> > > I have an alias in my .bashrc which helps me with this stuff:
> > >
> > > alias checkdeb='linda -i *.deb; linda -i *.dsc; lintian -i -I
> > > *.deb;
> > > lintian -i -I *.dsc'

What's wrong with just passing the .changes? That checks the .dsc and
each .deb

I stopped using linda some time ago - it is just incredibly buggy. I
admit I didn't file a bug report for every false positive or other
linda problem. I just uninstalled linda.

It shouldn't be too hard for someone to identify all packages in the
archive that are lintian-clean (without overrides) and run them through
linda to get a report of where lintian and linda disagree. Not all of
those will be bugs (because linda works differently to lintian and can
catch problems that lintian cannot and vice versa) but it's not
something I would want to do.

> > Linda has way too much false-positives (the above is just
> > one example) which is really bad.
> > bugs.debian.org/linda vs bugs.debian.org/lintian does look
> > like this as well.
> 
> There are only 5 bugs in linda:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=src&data=linda&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=important&sev-inc=normal

Minor and wishlist bugs still count - particularly for things like
linda and lintian, which leads to 16 outstanding. (The lintian
maintainer correctly insists that lintian - and therefore linda - are
only indicators of problems and cannot catch all such problems, they
are not intended to be the authoritative implementation of Policy.
Therefore, bugs in linda or lintian that relate to false positives,
missing checks and wrong results are requested to be filed as wishlist
only.) On that score, lintian has 99 bugs - yet lintian is still the
better of the two. 

As indicators of problems, lintian is the one to use but you and I
know that just because a package is lintian clean does NOT mean that the
package is in a good enough condition to be uploaded. Equally, there
are a small number of instances where a lintian override is the correct
response to a lintian error but sponsorees should not use
overrides without talking to their sponsor first!

-- 


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



pgpmcAMKvDLjW.pgp
Description: PGP signature

Re: RFS: secpanel (updated package)

[Bruno Costacurta]

On Sunday 01 July 2007 18:15, Thijs Kinkhorst wrote:
> On Sunday 1 July 2007 18:12, Thijs Kinkhorst wrote:
> > Otherwise it looks fine.
>
> One more thing: there's some bugs open against the package, including a
> wishlist bug regarding a new upstream version. Perhaps you want to take a
> look at those to see whether you can address them?
>
>
> Thijs

I'll update with latest upstream and upload to debian-mentors.

Bye,
Bruno

-- 
PGP key ID: 0x2e604d51
Key fingerprint = 713F 7956 9441 7DEF 58ED  1951 7E07 569B 2E60 4D51
--


pgprUn4WHtBCY.pgp
Description: PGP signature

RFS: syck

[Thomas Jollans]

Dear mentors,

I am looking for the new version 0.55+svn256-1 of the package syck which is 
already in Debian, maintained by Robert Jordens <[EMAIL PROTECTED]>. jordens 
doesn't use it any more and has given me permission to "take it". (He isn't 
responding to my mail - might be on vacation)

* Package name: syck
  Version : 0.55+svn256-1
  Upstream Author : Why The Lucky Stiff <[EMAIL PROTECTED]>
* URL : http://whytheluckystiff.net/syck
* License : BSD
  Section : devel

* Syck is a simple YAML parser kit.
  .
  YAML(tm) (rhymes with 'camel') is a straightforward machine parsable
  data serialization format designed for human readability and
  interaction with scripting languages such as Perl and Python. YAML is
  optimized for data serialization, formatted dumping, configuration
  files, log files, Internet messaging and filtering. This specification
  describes the YAML information model and serialization format. Together
  with the Unicode standard for characters, it provides all the
  information necessary to understand YAML Version 1.0 and construct
  computer programs to process it.
  .
  The whole point of Syck is to make parsing and emitting YAML very
  simple for scripting languages through C bindings.  It doesn't strive
  to be a pull parser or very extendible.  It just is concerned with
  loading a YAML document into a C structure which can be easily
  translated into a scripting language's internal native data type.


It builds these binary packages:
libsyck0-dev - YAML parser kit -- development files
php5-syck  - YAML parser kit -- PHP5 bindings

The package is lintian and linda clean
The upload would fix these bugs: 324316, 359245, 378440, 415217, 418308

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/s/syck
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/s/syck/syck_0.55+svn256-1.dsc


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

-- 
  Regards,   Thomas Jollans
GPG key: 0xF421434B may be found on various keyservers, eg pgp.mit.edu
Hacker key :
v4sw6+8Yhw4/5ln3pr5Ock2ma2u7Lw2Nl7Di2e2t3/4TMb6HOPTen5/6g5OPa1XsMr9p-7/-6


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

Re: RFS: command-not-found

[Julian Andres Klode]

Christoph Haas wrote:
> On Sun, Jul 01, 2007 at 10:08:47PM +0200, Julian Andres Klode wrote:
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "command-not-found".
>>
>> * Package name: command-not-found
>>   Version : 0.2.4+debian-1
>>   Upstream Author : Zygmunt Krynicki <[EMAIL PROTECTED]>
>> Michael Vogt <[EMAIL PROTECTED]>
>> * URL : https://launchpad.net/command-not-found
>> * License : GPL
>>   Section : admin
> 
> Not sure. Perhaps "shell" as a section might match better.
> 
>> It builds these binary packages:
>> command-not-found - Suggest installation of packages in interactive bash 
>> sessions
>> command-not-found-data - Set of data files for command-not-found
> 
> I just built and installed it. There is some funny whitespace in between
> the messages:
> 
> ===
> $ inetd
> Command 'inetd' is available in '/usr/sbin/inetd'
> The command could not be located because '/usr/sbin' is not i ncluded in the 
> PATH environment variable.
> This is most likely caused by the lack of administ rative priviledges 
> associated with your user account.
> bash: inetd: command not found
> ===
> 
> i ncluded -> included
> administ rative -> administrative
> priviledges -> privileges
Fixed.

> 
> Did you talk to the Ubuntu maintainer already? Perhaps it make sense to
> join forces so that only one package is built?
He's CCed, so: mvo: What's your opinion?

-- 
Julian Andres Klode

IRC Nickname:   juliank (Debian/OFTC + Freenode)
Fellow of FSFE: https://www.fsfe.org/en/fellows/jak (No. 1049)
Debian Wiki:http://wiki.debian.org/JulianAndresKlode
Ubuntu Wiki:http://wiki.ubuntu.com/JulianAndresKlode
In Launchpad:   https://launchpad.net/~juliank
Packages Overv: http://qa.debian.org/[EMAIL PROTECTED]
Languages:  German, English, [bit French]



signature.asc
Description: OpenPGP digital signature

RFS: app-install-data (updated package)

[Julian Andres Klode]

Dear mentors,

I am looking for a sponsor for the new version 0.20070627
of my package "app-install-data" (I took it over from the previous maintainer, 
with permission).

It builds these binary packages:
app-install-data - Application Installer Data Files

The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/a/app-install-data
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/a/app-install-data/app-install-data_0.20070627.dsc

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

Kind regards
 Julian Andres Klode


-- 
Julian Andres Klode

IRC Nickname:   juliank (Debian/OFTC + Freenode)
Fellow of FSFE: https://www.fsfe.org/en/fellows/jak (No. 1049)
Debian Wiki:http://wiki.debian.org/JulianAndresKlode
Ubuntu Wiki:http://wiki.ubuntu.com/JulianAndresKlode
In Launchpad:   https://launchpad.net/~juliank
Packages Overv: http://qa.debian.org/[EMAIL PROTECTED]
Languages:  German, English, [bit French]



signature.asc
Description: OpenPGP digital signature

Re: RFS: command-not-found

[Christoph Haas]

On Sun, Jul 01, 2007 at 10:08:47PM +0200, Julian Andres Klode wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "command-not-found".
> 
> * Package name: command-not-found
>   Version : 0.2.4+debian-1
>   Upstream Author : Zygmunt Krynicki <[EMAIL PROTECTED]>
> Michael Vogt <[EMAIL PROTECTED]>
> * URL : https://launchpad.net/command-not-found
> * License : GPL
>   Section : admin

Not sure. Perhaps "shell" as a section might match better.

> It builds these binary packages:
> command-not-found - Suggest installation of packages in interactive bash 
> sessions
> command-not-found-data - Set of data files for command-not-found

I just built and installed it. There is some funny whitespace in between
the messages:

===
$ inetd
Command 'inetd' is available in '/usr/sbin/inetd'
The command could not be located because '/usr/sbin' is not i ncluded in the 
PATH environment variable.
This is most likely caused by the lack of administ rative priviledges 
associated with your user account.
bash: inetd: command not found
===

i ncluded -> included
administ rative -> administrative
priviledges -> privileges

Did you talk to the Ubuntu maintainer already? Perhaps it make sense to
join forces so that only one package is built?

 Christoph
-- 
Peer review means that you can feel better because someone else
missed the problem, too.


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

Re: A note on lintian clean packages and mentors.d.n

[Christoph Haas]

On Sun, Jul 01, 2007 at 02:39:10PM -0500, Raphael Geissert wrote:
> On 01/07/07, Christoph Haas <[EMAIL PROTECTED]> wrote:
> >On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote:
> >> Hi,
> >> * Christoph Haas <[EMAIL PROTECTED]> [2007-07-01 19:13]:
> >> > On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote:
> >> > > I saw many packages using the template from
> >> > > mentors.debian.net which then always says:
> >> > > "The package is lintian clean."
> >> > >
> >> > > And I saw many packages which are not lintian clean but
> >> > > state otherwise which really sucks. Can you change this
> >> > > string to something like:
> >> [...]
> >> > Sounds a bit complicated. I have changed the text slightly to
> >> > "...appears to be lintian-clean". The lintian version on
> >> > mentors.debian.net is the Etch version. We can install a backport
> >> > though.
> >>
> >> That would be very nice.
> >
> >Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that helps.
> 
> Is lintian only checking the .deb file or the .dsc file too?
> By the way, what do you think about making linda check the package too?

The .deb file (if it is uploaded at all) is thrown away. Lintian is
doing the checks on the .dsc file.

/me puts linda on the todo list.

 Christoph
-- 
Peer review means that you can feel better because someone else
missed the problem, too.


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

RFS: command-not-found

[Julian Andres Klode]

Dear mentors,

I am looking for a sponsor for my package "command-not-found".

* Package name: command-not-found
  Version : 0.2.4+debian-1
  Upstream Author : Zygmunt Krynicki <[EMAIL PROTECTED]>
Michael Vogt <[EMAIL PROTECTED]>
* URL : https://launchpad.net/command-not-found
* License : GPL
  Section : admin

It builds these binary packages:
command-not-found - Suggest installation of packages in interactive bash 
sessions
command-not-found-data - Set of data files for command-not-found

The package appears to be lintian clean.

The upload would fix these bugs: 418613

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/c/command-not-found
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/c/command-not-found/command-not-found_0.2.4+debian-1.dsc

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

Kind regards
 Julian Andres Klode

-- 
Julian Andres Klode

IRC Nickname:   juliank (Debian/OFTC + Freenode)
Fellow of FSFE: https://www.fsfe.org/en/fellows/jak (No. 1049)
Debian Wiki:http://wiki.debian.org/JulianAndresKlode
Ubuntu Wiki:http://wiki.ubuntu.com/JulianAndresKlode
In Launchpad:   https://launchpad.net/~juliank
Packages Overv: http://qa.debian.org/[EMAIL PROTECTED]
Languages:  German, English, [bit French]



signature.asc
Description: OpenPGP digital signature

Re: A note on lintian clean packages and mentors.d.n

[Raphael Geissert]

Hi,

On 01/07/07, Nico Golde <[EMAIL PROTECTED]> wrote:

Hi,
* Raphael Geissert <[EMAIL PROTECTED]> [2007-07-01 21:51]:
[...]
> >> By the way, what do you think about making linda check the
> >> package too?
> >
> >Linda itself is too buggy I think. Linda is not bad but when
> >looking at the past I came to a point where I stopped using
> >it because of its bugs.
>
> I have an alias in my .bashrc which helps me with this stuff:
>
> alias checkdeb='linda -i *.deb; linda -i *.dsc; lintian -i -I
> *.deb;
> lintian -i -I *.dsc'
>
> The only "problem" I've found with linda is that when checking
> the source of a package it sometimes complains about duplicate files
> like:
>
> W: zend-framework; The font
> zend-framework-1.0.0-RC2/tests/Zend/Pdf/_fonts/Vera.ttf in
> package ttf-bitstream-vera is considered to be a duplicate.
> The font shown above is considered to be a duplicate of a
> commonly available font.
>
> even tough those files aren't included in the final .deb

Linda has way too much false-positives (the above is just
one example) which is really bad.
bugs.debian.org/linda vs bugs.debian.org/lintian does look
like this as well.


There are only 5 bugs in linda:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=src&data=linda&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=important&sev-inc=normal
By the way, looks like the BTS is kind of buggy:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=src&data=linda&archive=no&repeatmerged=no&version=&dist=unstable&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-exc=wishlist&sev-exc=fixed&exclude=fixed&exclude=fixed-in-experimental&exclude=fixed-upstream
That should normally exclude all those bugs marked as done, but it
isn't excluding them.

Cheers
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






--
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: Request for additions to the mentors RFS template

[Neil Williams]

On Sun, 1 Jul 2007 20:54:35 +0200
Nico Golde <[EMAIL PROTECTED]> wrote:

> > 1. An ITP usually includes a "Language: C/C++/Python/Perl etc."
> > line, so for requests for sponsors, it would be good to carry this
> > over so that packages that already exist in the archive also carry
> > this information in the RFS. It would help me enormously to be able
> > to scan the RFS and disregard all python or ruby packages and
> > concentrate on C/C++ or Perl without having to research each one
> > via various web pages.
> 
> Is this really necessary as the information should be 
> present in the ITP?

I'm thinking of requests that don't involve an ITP, as above, where the
package already exists in the archive. It would still be useful to have
it, from my perspective, in the RFS without having to load up the web
browser to inspect the ITP.

> > 3. The URL field is commonly just the URL for the mentors.debian.net
> > site (which itself is often little more than the template) when it
> > would be useful to either recommend the upstream homepage or include
> > that separately - naturally, if the long description is included, a
> > lot of packages will include this anyway. (Those that do not
> > include a Homepage link in the long description should expect to be
> > asked to add one.)
> 
> As the upstream homepage should be also in the ITP for my 
> taste the URL is just obsolete if a dget URL is included.

As above, if there is no ITP, this gets left behind. However, this is a
minor request.

> 5. If the RFS is for a package update, please include a 
> debdiff between the versions.

That's a great idea! mentors.debian.net may even be able to do that
automatically and put the results in the same directory as the .dsc -
perhaps running either debdiff or interdiff against the existing
version in the debian archive. 'interdiff -z ' against the two .diff.gz
files would be useful. It doesn't help native packages but then that's
probably for the best, an RFS doesn't usually intend to relate to a
native package.

-- 

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


pgpbYl2V1KSkc.pgp
Description: PGP signature

Re: A note on lintian clean packages and mentors.d.n

[Nico Golde]

Hi,
* Raphael Geissert <[EMAIL PROTECTED]> [2007-07-01 21:51]:
[...] 
> >> By the way, what do you think about making linda check the
> >> package too?
> >
> >Linda itself is too buggy I think. Linda is not bad but when
> >looking at the past I came to a point where I stopped using
> >it because of its bugs.
> 
> I have an alias in my .bashrc which helps me with this stuff:
> 
> alias checkdeb='linda -i *.deb; linda -i *.dsc; lintian -i -I 
> *.deb;
> lintian -i -I *.dsc'
> 
> The only "problem" I've found with linda is that when checking 
> the source of a package it sometimes complains about duplicate files 
> like:
> 
> W: zend-framework; The font
> zend-framework-1.0.0-RC2/tests/Zend/Pdf/_fonts/Vera.ttf in 
> package ttf-bitstream-vera is considered to be a duplicate.
> The font shown above is considered to be a duplicate of a 
> commonly available font.
> 
> even tough those files aren't included in the final .deb

Linda has way too much false-positives (the above is just 
one example) which is really bad.
bugs.debian.org/linda vs bugs.debian.org/lintian does look 
like this as well.
Cheers
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


pgpNi4Dn99Ll8.pgp
Description: PGP signature

Re: A note on lintian clean packages and mentors.d.n

[Raphael Geissert]

Hi,

On 01/07/07, Nico Golde <[EMAIL PROTECTED]> wrote:

Hi,
* Raphael Geissert <[EMAIL PROTECTED]> [2007-07-01 21:41]:
> On 01/07/07, Christoph Haas <[EMAIL PROTECTED]> wrote:
> >On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote:
[...]
> >Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that
> >helps.
>
> Is lintian only checking the .deb file or the .dsc file too?

Not that I know it but I guess the scan the .changes file.

> By the way, what do you think about making linda check the
> package too?

Linda itself is too buggy I think. Linda is not bad but when
looking at the past I came to a point where I stopped using
it because of its bugs.


I have an alias in my .bashrc which helps me with this stuff:

alias checkdeb='linda -i *.deb; linda -i *.dsc; lintian -i -I *.deb;
lintian -i -I *.dsc'

The only "problem" I've found with linda is that when checking the
source of a package it sometimes complains about duplicate files like:

W: zend-framework; The font
zend-framework-1.0.0-RC2/tests/Zend/Pdf/_fonts/Vera.ttf in package
ttf-bitstream-vera is considered to be a duplicate.
The font shown above is considered to be a duplicate of a commonly
available font.

even tough those files aren't included in the final .deb


Cheers
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






--
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: A note on lintian clean packages and mentors.d.n

[Nico Golde]

Hi,
* Raphael Geissert <[EMAIL PROTECTED]> [2007-07-01 21:41]:
> On 01/07/07, Christoph Haas <[EMAIL PROTECTED]> wrote:
> >On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote:
[...] 
> >Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that 
> >helps.
> 
> Is lintian only checking the .deb file or the .dsc file too?

Not that I know it but I guess the scan the .changes file.

> By the way, what do you think about making linda check the 
> package too?

Linda itself is too buggy I think. Linda is not bad but when 
looking at the past I came to a point where I stopped using 
it because of its bugs.
Cheers
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


pgp8SJQsPy88q.pgp
Description: PGP signature

Re: A note on lintian clean packages and mentors.d.n

[Raphael Geissert]

On 01/07/07, Christoph Haas <[EMAIL PROTECTED]> wrote:

On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote:
> Hi,
> * Christoph Haas <[EMAIL PROTECTED]> [2007-07-01 19:13]:
> > On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote:
> > > I saw many packages using the template from
> > > mentors.debian.net which then always says:
> > > "The package is lintian clean."
> > >
> > > And I saw many packages which are not lintian clean but
> > > state otherwise which really sucks. Can you change this
> > > string to something like:
> [...]
> > Sounds a bit complicated. I have changed the text slightly to
> > "...appears to be lintian-clean". The lintian version on
> > mentors.debian.net is the Etch version. We can install a backport
> > though.
>
> That would be very nice.

Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that helps.


Is lintian only checking the .deb file or the .dsc file too?
By the way, what do you think about making linda check the package too?



Cheers
 Christoph
--
Peer review means that you can feel better because someone else
missed the problem, too.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGh+6eCV53xXnMZYYRArtLAJ9SEollItFIN3eKdpWLJH+ezLxgJwCfbrlD
rYYTgcV2OzFlRzL+FdRtiVQ=
=PGV7
-END PGP SIGNATURE-






--
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


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

Re: Request for additions to the mentors RFS template

[Nico Golde]

Hi,
* Neil Williams <[EMAIL PROTECTED]> [2007-07-01 20:29]:
> I'd like to ask if the template could advise/require that certain extra
> fields are always specified?
> 
> 1. An ITP usually includes a "Language: C/C++/Python/Perl etc." line, so
> for requests for sponsors, it would be good to carry this over so that
> packages that already exist in the archive also carry this information
> in the RFS. It would help me enormously to be able to scan the RFS and
> disregard all python or ruby packages and concentrate on C/C++ or Perl
> without having to research each one via various web pages.

Is this really necessary as the information should be 
present in the ITP?

> 2. I frequently find that the short description of RFS emails is
> insufficient and I would value the opportunity to scan RFS emails that
> include the long description. Descriptions are commonly tweaked during
> the process of sponsorship as it is rare that a new maintainer makes a
> genuinely understandable short and long description on their first
> attempt and existing packages can also suffer from poor descriptions.

ACK and iirc it was common practice to include the long 
description in RFS requests back in the days before 
mentors.d.n :)

> 3. The URL field is commonly just the URL for the mentors.debian.net
> site (which itself is often little more than the template) when it
> would be useful to either recommend the upstream homepage or include
> that separately - naturally, if the long description is included, a lot
> of packages will include this anyway. (Those that do not include a
> Homepage link in the long description should expect to be asked to add
> one.)

As the upstream homepage should be also in the ITP for my 
taste the URL is just obsolete if a dget URL is included.

> 4. Some kind of statement in the template that a bare template with
> minimal information is usually insufficient.
> 
> Those who may want to ask me to sponsor their packages, please note -
> if you include this information in the very first RFS email to this
> list, you have a much higher chance of attracting my interest. In most
> cases, a bare template RFS will simply be ignored, regardless of the
> merits of that particular package.

ACK.

I want to come up with an additional wish.

5. If the RFS is for a package update, please include a 
debdiff between the versions.

Cheers
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


pgpZpOBcgQU5t.pgp
Description: PGP signature

Re: RFS: ntfs-config

[Roberto C . Sánchez]

On Thu, Jun 28, 2007 at 08:37:33PM +, Joseph Nahmias wrote:
> 
> Can you please give more information about what ntfs-config actually
> does.  Also, the URL above does not respond...
> 
Here is where the first RFS thread started:

http://lists.debian.org/debian-mentors/2007/06/msg00055.html

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Request for additions to the mentors RFS template

[Neil Williams]

I'd like to ask if the template could advise/require that certain extra
fields are always specified?

1. An ITP usually includes a "Language: C/C++/Python/Perl etc." line, so
for requests for sponsors, it would be good to carry this over so that
packages that already exist in the archive also carry this information
in the RFS. It would help me enormously to be able to scan the RFS and
disregard all python or ruby packages and concentrate on C/C++ or Perl
without having to research each one via various web pages.

2. I frequently find that the short description of RFS emails is
insufficient and I would value the opportunity to scan RFS emails that
include the long description. Descriptions are commonly tweaked during
the process of sponsorship as it is rare that a new maintainer makes a
genuinely understandable short and long description on their first
attempt and existing packages can also suffer from poor descriptions.

3. The URL field is commonly just the URL for the mentors.debian.net
site (which itself is often little more than the template) when it
would be useful to either recommend the upstream homepage or include
that separately - naturally, if the long description is included, a lot
of packages will include this anyway. (Those that do not include a
Homepage link in the long description should expect to be asked to add
one.)

4. Some kind of statement in the template that a bare template with
minimal information is usually insufficient.

Those who may want to ask me to sponsor their packages, please note -
if you include this information in the very first RFS email to this
list, you have a much higher chance of attracting my interest. In most
cases, a bare template RFS will simply be ignored, regardless of the
merits of that particular package.

Personally, I expect people requesting sponsorship to be enthusiastic
about the package to be sponsored. I would expect such enthusiasm to
manifest as a tendency to include too much information rather than too
little and I am prone to disregarding requests for sponsorship
that suffer from a lack of information in the original RFS.

-- 


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



pgpK1klgdY1gh.pgp
Description: PGP signature

Re: A note on lintian clean packages and mentors.d.n

[Christoph Haas]

On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote:
> Hi,
> * Christoph Haas <[EMAIL PROTECTED]> [2007-07-01 19:13]:
> > On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote:
> > > I saw many packages using the template from 
> > > mentors.debian.net which then always says:
> > > "The package is lintian clean."
> > > 
> > > And I saw many packages which are not lintian clean but 
> > > state otherwise which really sucks. Can you change this 
> > > string to something like:
> [...] 
> > Sounds a bit complicated. I have changed the text slightly to
> > "...appears to be lintian-clean". The lintian version on
> > mentors.debian.net is the Etch version. We can install a backport
> > though.
> 
> That would be very nice.

Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that helps.

Cheers
 Christoph
-- 
Peer review means that you can feel better because someone else
missed the problem, too.


signature.asc
Description: Digital signature

Re: RFS: powertop (updated package)

[Krzysztof Burghardt]

2007/7/1, Christoph Haas <[EMAIL PROTECTED]>:

Sponsored! Is there a reason you took the SVN version instead of 1.7
stable?


Just because it have been translated to Polish (in opposite to pure 1.7).
Thanks for upload.

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: ITR: libitpp (updated package)

[Neil Williams]

On Sun, 1 Jul 2007 09:58:52 + (UTC)
Kumar Appaiah <[EMAIL PROTECTED]> wrote:

> Neil Williams  debian.org> writes:
> > > I am looking for a sponsor for the new version 3.99.2-1
> > > of my package "libitpp".
> > When asking for a sponsor, please mention whether the package already
> > exists in Debian - i.e. whether you have had a sponsor who is now busy
> > etc.
> 
> OK, so this is the last time I rely on the template in Mentors. Anyway, I
> thought the "updated" subject line would do, but it's OK.

That's the thing with templates - they are meant to be edited.
;-)

Do please use the template, just ensure that you add sufficient
information to the template for your specific request and check that
every single part of the template is accurate *before* clicking Send.

> > A -dbg package needs to be provided.
> > (-dbg packages are likely to become mandatory by Lenny.)
> 
> Will look into this.

It should be a simple addition to dh_strip:
dh_strip --dbg-package=libfooSONAME-dbg

and then the content in debian/control

-dbg packages should usually be priority extra if the package is
optional or optional|extra for higher priorities.

> > There is 500kb of source in the doc/ directory and probably more by the
> > time the generated HTML docs are installed - more than enough to
> > warrant a -doc package too.
> 
> Ah, so here's the trouble. I did _exactly_ that, but my previous sponsor told 
> me
> not to do it, since he felt 500 kb didn't warrant a new package, and that the
> dev package is almost useless without the docs. But if you insist, so be it.

In practical terms, not all those who need the -dev package are
actually writing new software with that -dev. A lot are simply
*building* reverse dependencies of that -dev. When someone needs to
build pilot-qof, there is no need for them to have libqof-doc, they
only need libqof-dev. Such issues also affect the autobuilders - there
is no need for them to have the doc content when trying to build a
dependency using the -dev.

> > With these in place, you can tweak the short descriptions to indicate
> > what is contained in each package by only mentioning "C++ library" for
> > libitpp6 and adding a suffix of (development files) (debug files)
> > (documentation) or something along those lines. Compare with libqof1:
> 
> I would request you to elaborate on this. Do you just mean to explain 
> separation
> of packages into docs, dev and dbg?

No, tidying up the short descriptions so that the new packages are not
simple copies (as the -dev is currently).

libqof-dev  Query Object Framework - Development Headers
libqof-doc  Query Object Framework - API Documentation
libqof1 Query Object Framework
 
libitpp-dev - signal processing and communication - development files
libitpp-doc - signal processing and communication - API documentation
libittp-dbg - signal processing and communication - debug symbols
libitpp6- C++ library for signal processing and communication

debtags are useful too but a lot of people still limit their searches
to apt-cache search so it is best to make short descriptions unique.

> > This package has a large dependency tree (127MB of archives). Libraries
> > are difficult enough without adding so many dependencies.
> 
> I was unaware of the fact that atlas suffered from so many deficiencies.

? You should always build your own packages with pbuilder at least once
for each upstream release - if only to ensure you have the
Build-Depends right. Simply watching or reading the pdebuild log will
show you that your package brings in more packages than a relatively
large GUI application. Please look beyond your own package and try to
anticipate problems.

> However, I guess I can drop dependency on atlas (see
> http://itpp.sourceforge.net/index.php?wiki=About ), though I'd consult 
> upstream
> before doing that.

Yes, the reduced functionality is a concern. Upstream may be able to
separate the codebase so that you can create a libitpp-atlas6 and
libittp6 that would be without atlas - one conflicting and replacing
the other (not ideal) or one complementing the other by adding new
files without replacing libittp6 (harder to do upstream).

It's not something to do now (unless upstream already make it easy to
do) but ensure that you subscribe to atlas via the PTS so that you are
kept updated with the status of it's RC bug(s) and general health.

Just put your email address into the subscribe box at:
http://packages.qa.debian.org/a/atlas3.html

Note that according to the PTS, the maintainer of atlas has not made an
upload himself since 2005, there are 4 unapplied patches in the BTS
(two of which are debconf translations that are normally trivial to
apply) and the standards version is out of date. All signs of a
maintainer who is more active in other areas as well as a quiet/dead
upstream.

> > Tell me about yourself - how familiar are you with some of the
> > dependencies of this package? 
> 
> I am an "end-user" of this package, and not very familia

Re: RFS: gimmie

[Michael Biebl]

Thierry Randrianiriana schrieb:
> Dear mentors,
> 
> I am looking for a sponsor for my package "gimmie".
> 
> * Package name: gimmie
>  Version : 0.2.7-1
> Upstream Authors:
>  Alex Graveley <[EMAIL PROTECTED]>
>  David Trowbridge <[EMAIL PROTECTED]>
>  Mike Hearn <[EMAIL PROTECTED]>
>  Tony Tsui <[EMAIL PROTECTED]>
> * URL : http://www.beatniksoftware.com/gimmie
> * License : LGPL
>  Section : gnome
> 
> It builds these binary packages:
> gimmie - elegant desktop organizer
> 
> The package is lintian clean.
> 
> The upload would fix these bugs: 415937
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/g/gimmie
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/g/gimmie/gimmie_0.2.7-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Hi Thierry,

the package looks well done, I only have some smaller points:
1.) Package description
gimmie seems to be a replacement/enhancement of the traditional (GNOME)
panel and it can either be run in standalone mode or as applet in the
GNOME panel. This information is somehow missing in the description.
2.) The second paragraph in the long descriptions does not show nicely
in aptitude. The separate points are not correctly wrapped and thus it
gets a bit unreadable.
3.) python-support
IIRC the recommended way to specify the supported python versions with
python-support is debian/pyversions [1]. But as python-support also
supports the XS-Python-Version field, you can also keep it as is.
4.) ./configure checks for a couple of python modules like gmenu etc,
which are are not added to the the Depends list of gimmie. Could you
elaborate on that? Should these python modules be added to the list of
runtime dependencies?
5.) debian/copyright
gdm-logout-action.c is missing
6.) inlined copy of libsexy
gimmie uses a inlined copy of libsexy. I would very much prefer if
gimmie could be made to use the system libsexy. See [2] for more
details. Maybe you can also forward this information to upstream.

If you can address the above issues, I'll gladly sponsor your package.

Cheers,
Michael

[1] http://wiki.debian.org/DebianPython/NewPolicy
[2] http://www.chipx86.com/blog/?p=205

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: RFS: secpanel (updated package)

[Ralf Meyer]

On Sun, 1 Jul 2007 18:01:39 +0200 
Bruno Costacurta <[EMAIL PROTECTED]> wrote:

> I am looking for a sponsor for the new version 0.41+0.4.2-4
> of my package "secpanel".

Small typo in debian/control: managining
-- 
bye
ranf


signature.asc
Description: PGP signature

Re: RFS: powertop (updated package)

[Ralf Meyer]

On Sun, 1 Jul 2007 17:57:50 +0200 
Christoph Haas <[EMAIL PROTECTED]> wrote:

> Funny though that uscan found out there is a 1.17 version online
> although the web site says 1.7 is the most current version.

When I browse to:
http://www.linuxpowertop.org/download/
there actually is a version 1.17.
Looks like a problem on Arjan's side.

-- 
bye
ranf


signature.asc
Description: PGP signature

Re: RFS: secpanel (updated package)

[Bruno Costacurta]

On Sunday 01 July 2007 18:12, Thijs Kinkhorst wrote:
> Hi Bruno,
>
> On Sunday 1 July 2007 18:01, Bruno Costacurta wrote:
> > Dear mentors,
> >
> > I am looking for a sponsor for the new version 0.41+0.4.2-4
> > of my package "secpanel".
>
> Thanks for your effort to adopt an orphaned package.
I meet few Debian guys and they reckon this is the best way to start giving  
collaboration (modest as a newbie) to Debian.

>
> I've taken a look and have the following points:
>
> - Why the strange version number "0.41+0.4.2"?
Indeed. I was ot sure about which numbering I should adopt and try to follow 
current one as a first upload.

>
> - You've made two changes like this:
> -#!/bin/sh
> +#!/usr/bin/wish
>   but do not document that in the changelog.
Right. Changelog to be completed.

>
> - You seemed to have switched the package from
>   non-native to Debian native, perhaps an accident?
>   If you use "debuild" to build your package you will
>   be warned of that.
I used dpkg-buildpackage. I did not notice this switch.
Should I use 'debuild' and leave dpkg-buildpackage ?

>
> Otherwise it looks fine.
Question: 
can I submit (still via mentors-debian) a new version called 0.42 including  
these corrections / remarks ? 

>
>
> Thijs
Thanks for your attention.

Bye,
Bruno

-- 

PGP key ID: 0x2e604d51
Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html
Key fingerprint = 713F 7956 9441 7DEF 58ED  1951 7E07 569B 2E60 4D51
--

Re: A note on lintian clean packages and mentors.d.n

[Nico Golde]

Hi,
* Christoph Haas <[EMAIL PROTECTED]> [2007-07-01 19:13]:
> On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote:
> > I saw many packages using the template from 
> > mentors.debian.net which then always says:
> > "The package is lintian clean."
> > 
> > And I saw many packages which are not lintian clean but 
> > state otherwise which really sucks. Can you change this 
> > string to something like:
[...] 
> Sounds a bit complicated. I have changed the text slightly to
> "...appears to be lintian-clean". The lintian version on
> mentors.debian.net is the Etch version. We can install a backport
> though.

That would be very nice.
Thanks
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


pgpEqF4INUK6z.pgp
Description: PGP signature

Re: A note on lintian clean packages and mentors.d.n

[Christoph Haas]

On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote:
> I saw many packages using the template from 
> mentors.debian.net which then always says:
> "The package is lintian clean."
> 
> And I saw many packages which are not lintian clean but 
> state otherwise which really sucks. Can you change this 
> string to something like:
> 
> "Please check your package for the Debian policy using
> the lintian package. If it doesn't complain please state
> that the package is lintian clean. This is a must for most
> of the packages".

Sounds a bit complicated. I have changed the text slightly to
"...appears to be lintian-clean". The lintian version on
mentors.debian.net is the Etch version. We can install a backport
though.

Cheers
 Christoph
-- 
Peer review means that you can feel better because someone else
missed the problem, too.


signature.asc
Description: Digital signature

Re: ampache sponsor

[Thijs Kinkhorst]

Hi Charlie,

On Sunday 1 July 2007 12:43, Charlie wrote:
> Dear mentors,
>
> I am looking for a sponsor for my package "ampache".

I've taken a look and have found the following remarks.

* You install under /usr/share/ampache. The webapps
  policy (still draft, but not quite controversial) recommends
  /usr/share/ampache/www. I suggest to change it because
  changing it later can be bothersome.

* Your debconf template reads:
  "Ampache supports any web server that php and mysql does, but this automatic
configuration process only supports Apache2. Please select which apache 
version you want to configure."
  It only supports Apache2 but you can indicate which version to configure?
  That doesn't make sense. You also sometimes write Apache and sometimes
  apache.

* You depend on php5-common, is that really necessary or already satisfied
  by the other dependencies?

* You depend on dbconfig-common but don't use it.

* debian/copyright reads: "This package was debianized by root
   <[EMAIL PROTECTED]>".

* In debian/rules you do some loops to install your files. Can't you use
  the dh_install call to handle this for you?

Otherwise it generally looks quite ok, thanks for your work!


Thijs




pgprCCp7T2dD4.pgp
Description: PGP signature

Re: RFS: secpanel (updated package)

[Thijs Kinkhorst]

On Sunday 1 July 2007 18:12, Thijs Kinkhorst wrote:
> Otherwise it looks fine.

One more thing: there's some bugs open against the package, including a 
wishlist bug regarding a new upstream version. Perhaps you want to take a 
look at those to see whether you can address them?


Thijs


pgpI0XF2rc02N.pgp
Description: PGP signature

Re: RFS: secpanel (updated package)

[Thijs Kinkhorst]

Hi Bruno,

On Sunday 1 July 2007 18:01, Bruno Costacurta wrote:
> Dear mentors,
>
> I am looking for a sponsor for the new version 0.41+0.4.2-4
> of my package "secpanel".

Thanks for your effort to adopt an orphaned package.

I've taken a look and have the following points:

- Why the strange version number "0.41+0.4.2"?

- You've made two changes like this:
-#!/bin/sh
+#!/usr/bin/wish
  but do not document that in the changelog.

- You seemed to have switched the package from
  non-native to Debian native, perhaps an accident?
  If you use "debuild" to build your package you will
  be warned of that.

Otherwise it looks fine.


Thijs


pgpXdbdc0WTPP.pgp
Description: PGP signature

A note on lintian clean packages and mentors.d.n

[Nico Golde]

Hi,
I saw many packages using the template from 
mentors.debian.net which then always says:
"The package is lintian clean."

And I saw many packages which are not lintian clean but 
state otherwise which really sucks. Can you change this 
string to something like:

"Please check your package for the Debian policy using
the lintian package. If it doesn't complain please state
that the package is lintian clean. This is a must for most
of the packages".

Cheers
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


pgpQTxPXXInxu.pgp
Description: PGP signature

Re: ITS: fortunes-ru -- Russian data files for fortune

[Nico Golde]

Hi,
* Denis V. Sirotkin <[EMAIL PROTECTED]> [2007-07-01 16:25]:
> I am looking for a sponsor for my package "fortunes-ru".

I will sponsor this package. Just a few notes:

You use the Homepage tag in control but you just indent with·
one space, please use 2 as described in 6.2.4 developers·
reference.

You use Architecture: any in control which is wrong since·
the fortune data is architecture-independent. Please fix·
this, see policy 5.6.8.

Why do you have a build-dependency on fortune-mod?

> The package is lintian clean.

It's not please check.
Fix the above issues and I will upload the package for you.
Cheers
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


pgpbiReTCvo2R.pgp
Description: PGP signature

RFS: secpanel (updated package)

[Bruno Costacurta]

Dear mentors,

I am looking for a sponsor for the new version 0.41+0.4.2-4
of my package "secpanel".

It builds these binary packages:
secpanel   - A graphical user interface for SSH and SCP

The upload would fix these bugs: 317063

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/s/secpanel
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/s/secpanel/secpanel_0.41+0.4.2-4.dsc

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

Kind regards
 Bruno Costacurta
-- 

PGP key ID: 0x2e604d51
Key fingerprint = 713F 7956 9441 7DEF 58ED  1951 7E07 569B 2E60 4D51
--


pgpLSpSJBz88p.pgp
Description: PGP signature

Re: RFS: powertop (updated package)

[Christoph Haas]

On Sun, Jul 01, 2007 at 05:21:03PM +0200, Krzysztof Burghardt wrote:
> I am looking for a sponsor for the new version 1.7~svn-r227-1
> of my package "powertop".

Sponsored! Is there a reason you took the SVN version instead of 1.7
stable?

Funny though that uscan found out there is a 1.17 version online
although the web site says 1.7 is the most current version.

Cheers
 Christoph
-- 
Peer review means that you can feel better because someone else
missed the problem, too.


signature.asc
Description: Digital signature

RFS: powertop (updated package)

[Krzysztof Burghardt]

Dear mentors,

I am looking for a sponsor for the new version 1.7~svn-r227-1
of my package "powertop".

It builds these binary packages:
powertop   - linux tool to find out what is using power on a laptop

The package is lintian clean.

The upload would fix these bugs: 427345, 427548, 429305, 430035

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/powertop
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/p/powertop/powertop_1.7~svn-r227-1.dsc

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

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


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

sbuild and -vversion dpkg-buildpackage option

[Daniel Leidert]

Hello,

I used to create one package with using the -vversion dpkg-buildpackage
option. Now my sponsor uses sbuild. How can the -vversion option be
passed to sbuild? I personally don't use sbuild, but took a quick look
into the manpage, but didn't find anything. Or are there any
workarounds?

Regards, Daniel


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

ampache sponsor

[Charlie]

Ok let's try this one more time

From: Charlie Smotherman <[EMAIL PROTECTED]>
To: debian-mentors@lists.debian.org
Subject: RFS: ampache

Dear mentors,

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

* Package name: ampache
  Version : 3.3.3.2-1
  Upstream Author : [EMAIL PROTECTED]
* URL : www.ampache.org
* License : GPL
  Section : web

It builds these binary packages:
ampache- A web based audio file management system written in PHP

The package is lintian clean.

The upload would fix these bugs: 407337

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/a/ampache
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.3.3.2-1.dsc

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

Kind regards
 Charlie Smotherman


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

Ampache Sponsor

[Charlie]

From: Charlie Smotherman <[EMAIL PROTECTED]>
To: debian-mentors@lists.debian.org
Subject: RFS: ampache

Dear mentors,

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

* Package name: ampache
  Version : 3.3.3.2-1
  Upstream Author : [fill in name and email of upstream]
* URL : [fill in URL of upstreams web site]
* License : [fill in]
  Section : web

It builds these binary packages:
ampache- A web based audio file management system written in PHP

The package is lintian clean.

The upload would fix these bugs: 407337

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/a/ampache
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.3.3.2-1.dsc

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

Kind regards
 Charlie Smotherman


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

Re: ITR: libitpp (updated package)

[Kumar Appaiah]

Neil Williams  debian.org> writes:
> > I am looking for a sponsor for the new version 3.99.2-1
> > of my package "libitpp".
> 
> http://packages.qa.debian.org/libi/libitpp.html
> 
> When asking for a sponsor, please mention whether the package already
> exists in Debian - i.e. whether you have had a sponsor who is now busy
> etc.

OK, so this is the last time I rely on the template in Mentors. Anyway, I
thought the "updated" subject line would do, but it's OK.

My mentor, Daniel Baumann, has decided to stop sponsoring packages. Therefore, I
need someone else to help me out.

> > It builds these binary packages:
> > libitpp-dev - C++ library for signal processing and communication
> > libitpp6   - C++ library for signal processing and communication
> 
> (I wish the mentors template would require the long description in RFS
> emails.)
> 
> A -dbg package needs to be provided.
> (-dbg packages are likely to become mandatory by Lenny.)

Will look into this.

> There is 500kb of source in the doc/ directory and probably more by the
> time the generated HTML docs are installed - more than enough to
> warrant a -doc package too.

Ah, so here's the trouble. I did _exactly_ that, but my previous sponsor told me
not to do it, since he felt 500 kb didn't warrant a new package, and that the
dev package is almost useless without the docs. But if you insist, so be it.

> With these in place, you can tweak the short descriptions to indicate
> what is contained in each package by only mentioning "C++ library" for
> libitpp6 and adding a suffix of (development files) (debug files)
> (documentation) or something along those lines. Compare with libqof1:

I would request you to elaborate on this. Do you just mean to explain separation
of packages into docs, dev and dbg?

> Some of the content from the Features list at
> http://itpp.sourceforge.net/ needs to be summarised in the
> long description - remove the repeated research section:
[snip]

Will be done.

> Shorten the bit about NEWCOM - mention NEWCOM if you have to, otherwise
> concentrate on what the library can do, not who might be using it
> outside Debian.

Accepted.

> These are trivial to fix:
> 
> dpkg-source: warning: file debian/copyright has no final newline (either
original or modified version)
> dpkg-source: warning: file debian/itpp-config.1 has no final newline (either
original or modified version)
> dpkg-source: warning: file debian/changelog has no final newline (either
original or modified version)
> dpkg-source: warning: file debian/libitpp6.docs has no final newline (either
original or modified version)
> dpkg-source: warning: file debian/watch has no final newline (either original
or modified version)
> dpkg-source: warning: file debian/control has no final newline (either
original or modified version)
> dpkg-source: warning: file debian/libitpp-dev.manpages has no final newline
(either original or
> modified version)

Fine.

> Now to the serious stuff:
[snip]
> 2 RC bugs, a dependency on an outdated compiler and a quiet/dead
> upstream have been more than enough to have even a popular package
> removed from a release before now - if that happens to atlas, your
> package will be removed too (especially as libitpp2 only has 6 popcon
> users).
> 
> This package has a large dependency tree (127MB of archives). Libraries
> are difficult enough without adding so many dependencies.

I was unaware of the fact that atlas suffered from so many deficiencies.
However, I guess I can drop dependency on atlas (see
http://itpp.sourceforge.net/index.php?wiki=About ), though I'd consult upstream
before doing that.

> Tell me about yourself - how familiar are you with some of the
> dependencies of this package? 

I am an "end-user" of this package, and not very familiar with the dependencies.
Therefore, I didn't see the storm brewing.

> I am interested in this package, even though it is clearly outside my
> normal remit of embedded development, but I am also concerned about
> whether it is wise to encourage a package with such problematic
> dependencies.

Well, I'll see what I can do. This will mean redoing a lot of old work, and will
take some time. I guess I'll do this sometime in the next few days.

> > 
> > The package is lintian clean.
> 
> No, it is not.
> 
> W: libitpp source: debian-rules-ignores-make-clean-error line 35
> W: libitpp source: substvar-source-version-is-deprecated libitpp-dev

Got that.

> > I would be glad if someone uploaded this package for me.
> 
> Sorry, not in the current state.

I'll get back to you with a better package.

Thanks for the inputs.

Kumar





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

Re: ITR: libitpp (updated package)

[Neil Williams]

On Sun, 1 Jul 2007 13:51:33 +0530
Kumar Appaiah <[EMAIL PROTECTED]> wrote:

> I am looking for a sponsor for the new version 3.99.2-1
> of my package "libitpp".

http://packages.qa.debian.org/libi/libitpp.html

When asking for a sponsor, please mention whether the package already
exists in Debian - i.e. whether you have had a sponsor who is now busy
etc.

Different sponsors have different requirements. The following are mine.
;-)

> It builds these binary packages:
> libitpp-dev - C++ library for signal processing and communication
> libitpp6   - C++ library for signal processing and communication

(I wish the mentors template would require the long description in RFS
emails.)

A -dbg package needs to be provided.
(-dbg packages are likely to become mandatory by Lenny.)

There is 500kb of source in the doc/ directory and probably more by the
time the generated HTML docs are installed - more than enough to
warrant a -doc package too.

With these in place, you can tweak the short descriptions to indicate
what is contained in each package by only mentioning "C++ library" for
libitpp6 and adding a suffix of (development files) (debug files)
(documentation) or something along those lines. Compare with libqof1:
ii  libqof-backend-qsf0Query Object Framework - XML backend module
ii  libqof-backend-sqlite0 Query Object Framework - SQLite backend 
module
ii  libqof-dev Query Object Framework - Development Headers
ii  libqof-doc Query Object Framework - API Documentation
ii  libqof1Query Object Framework
ii  libqof1-dbgQuery Object Framework - Debug Symbols

Some of the content from the Features list at
http://itpp.sourceforge.net/ needs to be summarised in the
long description - remove the repeated research section:

"It is being developed by researchers in these areas and is widely used
by researchers,"
doesn't make a lot of sense and is probably redundant anyway. Explain
what the package does, not who you expect to be able to use it.

Shorten the bit about NEWCOM - mention NEWCOM if you have to, otherwise
concentrate on what the library can do, not who might be using it
outside Debian.

These are trivial to fix:

dpkg-source: warning: file debian/copyright has no final newline (either 
original or modified version)
dpkg-source: warning: file debian/itpp-config.1 has no final newline (either 
original or modified version)
dpkg-source: warning: file debian/changelog has no final newline (either 
original or modified version)
dpkg-source: warning: file debian/libitpp6.docs has no final newline (either 
original or modified version)
dpkg-source: warning: file debian/watch has no final newline (either original 
or modified version)
dpkg-source: warning: file debian/control has no final newline (either original 
or modified version)
dpkg-source: warning: file debian/libitpp-dev.manpages has no final newline 
(either original or modified version)

Now to the serious stuff:

What's the dependency on gcc-3.4 gcc-3.4-base all about? (brought in
when built in pbuilder). Is atlas3 really dependent on such an old
compiler? atlas doesn't seem to have had much attention upstream for
some time.

By depending on what appears to be a dead (or extremely slow) upstream,
you may be storing up a lot of problems for your own package.

Atlas3 already has an RC bug, filed by one of the gcc maintainers,
regarding compiler issues. Is there an alternative? Is there anyone
working on atlas upstream? The problem arises from the fortran
dependency within atlas, it should be updated to use libfortran2
instead of libg2c0 but that is probably a large upstream change. Is it
likely to happen? (It has also FTBFS on arm which is another RC bug.)
http://buildd.debian.org/build.php?pkg=atlas3&ver=3.6.0-20.6&arch=arm

2 RC bugs, a dependency on an outdated compiler and a quiet/dead
upstream have been more than enough to have even a popular package
removed from a release before now - if that happens to atlas, your
package will be removed too (especially as libitpp2 only has 6 popcon
users).

This package has a large dependency tree (127MB of archives). Libraries
are difficult enough without adding so many dependencies.

Tell me about yourself - how familiar are you with some of the
dependencies of this package? 

I am interested in this package, even though it is clearly outside my
normal remit of embedded development, but I am also concerned about
whether it is wise to encourage a package with such problematic
dependencies.

> 
> The package is lintian clean.

No, it is not.

W: libitpp source: debian-rules-ignores-make-clean-error line 35
W: libitpp source: substvar-source-version-is-deprecated libitpp-dev

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

Sorry, not in the current state.
 
-- 


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



pgpsij5T8Rl4n.pgp
De

RFS: libitpp (updated package)

[Kumar Appaiah]

Dear Mentors,

I am looking for a sponsor for the new version 3.99.2-1
of my package "libitpp".

It builds these binary packages:
libitpp-dev - C++ library for signal processing and communication
libitpp6   - C++ library for signal processing and communication

The package is lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libitpp
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_3.99.2-1.dsc

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

Kind regards
Kumar Appaiah
-- 
Kumar Appaiah,
462, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036


signature.asc
Description: Digital signature