Re: mentors.debian.net rejects orig.tar."bz2"

[Christoph Haas]

On Mon, Dec 17, 2007 at 05:40:44PM +0100, Patrick Winnertz wrote:
> Am Montag, 17. Dezember 2007 16:29:40 schrieb Hideki Yamane:
> > Hi,
> >
> >  I've uploaded package to mentors.debian.net but it failed because
> > mentors rejects its orig.tar.bz2 file.
> >
> >  It says "You just uploaded a diff file
> > (ttf-vlgothic_20071215-1.diff.gz) without an upstream tarball (should
> > have been 'ttf-vlgothic_20071215.orig.tar.gz')." I did it as
> > ttf-vlgothic_20071215.orig.tar.bz2.
> Debian uses only .tar.bz2 ... please repackage it with a .orig.tar.gz

If Debian used .tar.bz2 why whould Hideki repackage the tarball as
orig.tar.gz?

I believe I recently read something about dpkg-buildpackage supporting
orig.tar.bz2 now. If that's true then I'll have to fix
mentors.debian.net. Can somebody give us a hint?

Cheers
 Christoph
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


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

Missing descriptions on mentors.debian.net

[Christoph Haas]

Fellow earthicans,

a few package maintainers have complained that sometimes newly uploaded
packages to mentors.debian.net got rejected with an "internal error"
complaining about the "Description" field. I was told that due to a
recent change in "dpkg" the ".changes" files that depict the files
belonging to a certain package no longer contain the "Description" field
from debian/control. That's a pity because I can no longer easily find
out which binary packages are built from looking at the ".dsc" or the
".changes" file. Currently such uploads display with a description of
"-" on the mentors.debian.net site. It's a feature. :(

In the next days I'll write a parser to rip the debian/control patch out
of the ".diff.gz" file and parse the information from there. Doesn't
really make me happy but at least I wanted to tell you that the problem
is known.

Thanks for using mentors.debian.net

Cheers
 Christoph

P.S.: As discussed a few weeks ago mentors.debian.net will be
  refactored. Which means it will be made more generic so that
  others can use a public repository like that on their own.
  I've started to put the work under a Trac at
  debexpo.workaround.org. Expect a shiny new mentors.debian.net
  during the summer based on "debexpo". :)
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


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

Re: Missing descriptions on mentors.debian.net

[Christoph Haas]

On Wed, Jan 30, 2008 at 08:58:10PM +1100, Ben Finney wrote:
> Christoph Haas <[EMAIL PROTECTED]> writes:
> 
> > Expect a shiny new mentors.debian.net during the summer based on
> > "debexpo". :)
> 
> *The* summer? You mean I'll be getting it before the end of February
> 2008, while those in the northern hemisphere will have to wait longer?

Debian is where I am. Besides... who said anything of 2008. Me? :)

> Also, and regardless of the above nitpick: thanks for the good news,
> can't wait to see the new site :-)

Me neither. /me opens the vim

Cheers
 Christoph
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


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

mentors.debian.net is down

[Christoph Haas]

Dear list...

No april fools joke unfortunatley. Today we experienced strange problems
on mentors.debian.net. Like it segfaulted on common commands like 'ps'
or aptitude. So we finally decided to reboot the system. Unfortunately
it refuses to come back up properly. And since it's a colocated virtual
system it's not simple to recover it.

If we should not be able to get it back up we will continue from the
last backup on another server. Be assured that we try hard to get the
system back online within the next 24 hours. So far no data seems to be
lost.

Thanks for having used mentors.debian.net so far. :)

Cheers
 Christoph
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


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

Re: mentors.debian.net is down

[Christoph Haas]

Fellow earthicans...

mentors.debian.net is back up. We are still investigating the situation
on the old server to see if we find any irregularities (script kids,
aliens, solar spots etc). Meanwhile we managed to get the service back
up on another server without losing any data.

Thank you for the numerous mails ranging from help offers to sympathy.
It's really motivating to see so many people interested in the mentors
service.

If you find any problems with the resurrected service please let me
know.

Kindly
 Christoph
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


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

SoC application deadline has been extended to April 7th

[Christoph Haas]

Dear lists...

Giridhar was kindly forwarding my offer of being a sponsor for the
Google Summer-of-Code regarding the 'debexpo' ([72]) project. You may
have read the news already ([42]) that Google has extended the
application deadline for students to April 7th. So if any student is
interested in working on a Python- and web-based generic and pluggable
software to run repositories like mentors.debian.net feel free to
contact me.

Cheers
 Christoph


[72] http://wiki.debian.org/SummerOfCode2008/debexpo
[42] http://code.google.com/soc/2008/
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


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

Re: Is there an appropriate IRC for this list?

[Christoph Haas]

On Donnerstag, 17. April 2008, Andrew McClain wrote:
> I have a bunch of small questions regarding the packages I'm rebuilding.
> Where is the appropriate place for that?

#debian-mentors on irc.debian.org - see you there

 Christoph (aka "Signum")
-- 
When you do things right people won't be sure you've done anything at all.


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

Re: Simple fix to #434272?

[Christoph Haas]

On Freitag, 18. April 2008, Andreas Rönnquist wrote:
> There seems to be a _very_ simple fix to #434272 - I have attached a
> patch that _I_ guess would fix it. The reason that I am sending it here
> and not to the bug is that I am not at all very sure about the proper
> way to handle this (I am not a DD in any way.) and I am not 100% sure
> that all is like it should with my patch.

Don't be shy. Just send it to the bug report ([EMAIL PROTECTED]). :)

Kindly
 Christoph


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

Re: Debian Mentors slow?

[Christoph Haas]

On Donnerstag, 22. Mai 2008, Magnus Therning wrote:
> Admittedly it is a while since I uploaded a package to Debian Mentors,
> but I don't remember it taking very long before a verdict was delivered
> to my email.
>
> I uploaded a message last night (about 8 hours ago) and I still haven't
> received any word on whether it's been accepted.  It doesn't appear in
> the list of my packages either so I guess it hasn't been processed yet.
>  This is quite far from the promise made on the Introduction page that
> the queue is checked every 30 seconds and that an email should arrive
> within a few minutes.
>
> Is the server not feeling well?

Hehe, yeah, something like that. I was running the import proces in a 
screen session for debugging purposes. And somehow my screen session died. 
The uploads have all been completed once I got notice of the problem. 
Sorry for the inconvenience. Yes - 30 seconds is more like the usual time 
it takes to get a package online.

Cheers
 Christoph
-- 
When you do things right people won't be sure you've done anything at all.


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

Re: how to build two differently configured binaries from the same source?

[Christoph Haas]

Hi, Evgeni...

On Sonntag, 25. Mai 2008, Evgeni Golov wrote:
> I am preparing a package for Yabause[1] and wondering what will be the
> best practice for me.
>
> Yabause has two frontends, one Qt and one Gtk. I would like to ship
> both. Is there any recipe for debian/rules how to create two identical
> packages but with one configure option changed?

Each target in debian/rules gets called once and in order. So you have to 
make sure that both binary packages get configured and compiled within the 
same "target" in the Makefile. Last time I checked the "vim" source 
package runs the compilation multiple times creating different binary 
packages from the same souce tree. Although the maintainers are using 
Makefile trickery that I would try to avoid because I find it barely 
readable.

Anyway, you can build the binary package into debian/package-binary1 and 
debian/package-binary2 and in the end build a package of each one.

According to the debhelper(7) manpage you can provide a "-P" parameter to 
define the tmpdir (temporary directory) to build the final binary package.

> Additionally the question comes up: should yabause-gtk and yabause-qt
> conflict, at they both provide a yabause binary, or should I rename the
> binarys to be able to install both GUIs side by side?

The user probably doesn't want to use "yabause-gtk" to start the program. 
So I think they should conflict. Or you just decide on either library to 
build the package and are done.

Cheers
 Christoph
-- 
When you do things right people won't be sure you've done anything at all.


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

mentors.debian.net flaky - but not much longer

[Christoph Haas]

Dear maintainers,

I'd like to apologize for the unreliability of mentors.debian.net in the 
last weeks. I am experiencing a wild mixture of problems in the backend 
code, the PGP verification and the mysql database. That lead to packages 
either left in the upload directory or being thrown away randomly during 
the import into the repository.

The good news is that I had the honor to be the mentor of the Google Summer 
of Code project called 'debexpo' [0] [1] that I proposed and which is a 
web-based Debian package repository software. Jonny Lamb - the student and 
author - finished the project recently and we are sorting out a few last 
things about before I intend to use it for mentors.debian.net. It's no 
conincidence that it will look pretty much the same as the current 
mentors.debian.net site because that was one of the design goals. But it's 
also flexible enough to provide personal package archives (PPAs) [2] or 
apt-get'able repositories like 'debpool' [3] creates if anyone is 
interested.

Expect an announcement of the beta relaunch of mentors.debian.net based on 
debexpo soon on this mailing list. Jonny and I will welcome your feedback 
then.

I just wanted to tell you that I'm aware of the problems and am working on 
a remedy right now.

Cheers
 Christoph

[0] http://debexpo.workaround.org/
[1] http://wiki.debian.org/SummerOfCode2008/debexpo
[2] http://code.google.com/p/debppa/
[3] http://wiki.debian.org/debpool


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

Re: RFS: python-goopy

[Christoph Haas]

Hi, Kumar...

On Sun, Aug 21, 2005 at 08:54:06AM +0530, Kumar Appaiah wrote:
> Goopy (http://goog-goopy.sf.net) is a Python module for functional
> programming released by Google. It has a few pure Python functions,
> and is quite small. It is released under the BSD License.
> 
> I have carefully read through the Debian Python Policy and the New
> Maintainer guide, as well as the mentors FAQ, and would request an
> interested mentor having some spare time to inspect these packages,
> and see if they're all right. They are available at
> 
> http://kumar.travisbsd.org/debpackages/
> 
> (I have uploaded all files I used to generate the deb package).

Thanks for your contribution. Please allow me to comment on your
package:

- the upstream tarball (orig.tar.gz) on your web server seems
  to be incomplete (just contains PKG-INFO and README). I downloaded
  the tarball from SourceForge.
- the README.Debian is superfluous since it does not contain more
  information than already provided in debian/control. Please remove it.
- the debian/docs contains two files that are not very helpful for the
  user. The instructions on installing the package are in fact
  misleading.
- please remove the parts of the debian/rules that you commented out
- since the package is meant to be for "Architecture: all" you do not
  need everything you are running in the *-arch targets.
- since python2.4 is out you may consider creating a second binary
  package (hint: debian/control) python2.4-goopy
- you do not have a build dependency on python. Building in a "pbuilder"
  failed here due to unsatisfied dependencies.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: python-goopy

[Christoph Haas]

On Sun, Aug 21, 2005 at 08:01:54PM +0530, Kumar Appaiah wrote:
> On Sun, Aug 21, 2005 at 02:16:27PM +0200, Christoph Haas wrote:
> > - the debian/docs contains two files that are not very helpful for the
> >   user. The instructions on installing the package are in fact
> >   misleading.
> 
> I have edited it, and added a message saying Debian users have it
> installed already.

That's self-explaining in my opinion. After all that's why a user will
have installed your package. :)

> > - since python2.4 is out you may consider creating a second binary
> >   package (hint: debian/control) python2.4-goopy
> 
> Done, though I didn't actually get your hint.

Thomas is right that it's not trivial to create multi-binary packages.
I'd upload your package if you just want to do a package for Python 2.3.
Perhaps you want to look at another Python package though. I believe
that http://packages.qa.debian.org/p/python-mysqldb.html would be a good
example. Look at the debian/control file there.

> > - you do not have a build dependency on python. Building in a "pbuilder"
> >   failed here due to unsatisfied dependencies.
> 
> My builds now depend on python2.3 as well as python2.3-dev for the
> python2.3 version.

Very good.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: python-goopy

[Christoph Haas]

Hi, Kumar...

On Tue, Aug 23, 2005 at 04:51:51PM +0530, Kumar Appaiah wrote:
> Sorry for going on and on!

Don't worry. We'll be done complaining about the package soon. ;)

> But I just wanted to inform you that I have found a way to make up for
> the docs, and want to know whether it is all right.
> 
> What I have done is, I have prepended some info in the README with
> install info, saying that this is part of the original package and not
> of relevance to Debian users, as they already have it installed.

You are actually patching the upstream's README file. I personally do
not recommend changing upstream's files. Imagine what happens when the
upstream releases a new version. You would then have to patch the new
file, too.

My suggestions is to not use/install the README file at all. It does not
contain that much useful information anyway.

- it needs python2.1 -> dependencies
- there's documentation in... -> people look for docs in /usr/share/doc
  anyway
- license -> copyright file

If you really needed to patch upstream files you might want to take a
look at the "dpatch" tool. Although it's surely overkill here. So my
conclusion: just don't care about the README.

Next... I believe that the build dependencies (debian/control) also need
an entry for "python2.4-dev". And since the package is architecture
independent it may be good to use 'Build-Depends-Indep:' instead of
'Build-Depends:'.

Another detail... you might extend the description (debian/control)
of the python2.(3|4)-goopy binary packages to read something like
"This package provides the modules for Python 2.4".

> Then, I generate an HTML file documenting all functions available
> using pydoc2.[34] (appropriate version), and install that into the
> docs directory using dh_installdocs. Is this OK?

Nice idea. I haven't packaged that many Python modules before. So I
can't say if this is the common practise.

After building the package (preferably in "pbuilder") you should run
lintian and linda on it. I get a couple of warnings and error messages
there.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: gips - an isotopic pattern calculator

[Christoph Haas]

On Wed, Aug 31, 2005 at 01:12:03AM +0200, Krugaan wrote:
> I build a package for GIPS (licenced under GPL), wich is a program to
> calculate the isotopic distribution of a given sum formula or peptide
> sequence.
> AFAIK there is no program in debian to achieve this task. Therefore I
> consider GIPS to be a nice addition to the science section.
> 
> The project home page can be found at:
> http://isotopatcalc.sourceforge.net/index.php
> 
> The original sources can be downloaded from this site:
> http://sourceforge.net/projects/isotopatcalc
> 
> The debian package is located at:
> http://isotopatcalc.sourceforge.net/debian/

I just was bored and wanted to look at your package. :) However the
orig.tar.gz file that you provide differs from the upstream tarball I
just downloaded from
http://surfnet.dl.sourceforge.net/sourceforge/isotopatcalc/gips-0.7.tar.gz

Are there multiple 0.7 versions? :)

Further annotations:
- your debian/changelog looks strange :(
- please tidy up the debian/rules file :(
- building the package works well :)
- when I tried to use the "Help" menu item I had a segfault :(

Could you please fix these minor issues?

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: kde-icons-nuvola -- popular icon theme for kde

[Christoph Haas]

On Wed, Aug 31, 2005 at 11:35:32PM +0200, Bastian Venthur wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Bastian Venthur <[EMAIL PROTECTED]>
> 
> * Package name: kde-icons-nuvola
>   Version : 1.0
>   Upstream Author : David Vignoni <[EMAIL PROTECTED]>
> * URL : http://www.icon-king.com
> * License : LGPL
>   Description : popular icon theme for kde
> 
> The package is linda/lintian-clean and you can get it here:
> http://venthur.de/debian/nuvola/

I would have liked to look at it. But using the official upstream
tarball from icon-king-com didn't match your package:

dpkg-source: error: file kde-icons-nuvola_1.0.orig.tar.gz has size
13594245 instead of expected 13567432

And the orig.tar.gz from venthur.de would take days to download (<1
KB/second). Do you have an alternative location to download?

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: kde-icons-nuvola -- popular icon theme for kde

[Christoph Haas]

On Thu, Sep 01, 2005 at 08:01:59PM +0200, Bastian Venthur wrote:
> Hmmm could you please give me a hint how to use this? My steps are the
> following:
> 
> 1) unpack tarball
> 2) rename dir if not compatible with debian's naming convention

No need to do that. Just enter the directory - no matter what it's
called.

> 3) run dh_make
> 4) adjust all the files in debian/
> 5) run debuild

I use pbuilder to make sure the dependencies are correct and I'm
building in a clean environment. But debuild is generally okay.

> 6) upload

Perfect.

> where can I improve my practice?

You are doing well. Really. :) Just some suggestions...

debian/control:
- Remove the empty "Builds:" line
- The "debhelper" dependency can go into "Build-Depends-Indep:"
  since your package is architecture-independent
- Typo. Beautifull -> Beautiful
- "Description:..." "popular" is a bit generic :) What about:
  Description: Nuvola icon theme for KDE3

debian/copyright:
- please use the exact URL where you downloaded the upstream tarball
  (http://www.icon-king.com/files/nuvola-1.0.tar.gz)
- "This library is free software"... library?
- "On debian machines"... isn't this Debian? :)

debian/docs:
- is "thanks.to" useful?
- the "readme.txt" contains a redundant copyright and not much more
  useful information IMHO. What do you think?
- "author" can surely be omitted

debian/rules:
- you need a "binary-arch" target (see
  http://www.de.debian.org/doc/debian-policy/ch-source.html#s-debianrules)

Don't be frustrated by the amount of comments. Those are mainly minor
issues. Thanks for your contribution already. I believe you'll quickly
find a sponsor once this is fixed.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: kde-icons-nuvola -- popular icon theme for kde

[Christoph Haas]

On Thu, Sep 01, 2005 at 10:00:37PM +0200, Bastian Venthur wrote:
> Christoph Haas wrote:
> > On Thu, Sep 01, 2005 at 08:01:59PM +0200, Bastian Venthur wrote:
> >> Hmmm could you please give me a hint how to use this? My steps are the
> >> following:
> >> 
> >> 1) unpack tarball
> >> 2) rename dir if not compatible with debian's naming convention
> > 
> > No need to do that. Just enter the directory - no matter what it's
> > called.
> 
> this is exactly the reason, why I allways rename the dir: dh_make refuses to
> work if I run dh_make in the "nuvola" dir:
> 
> ---
> The directory name must be - for dh_make to work!
> I cannot understand the directory name or you have an invalid directory
> name!
> ---

I haven't had any case where the upstream hasn't named the tarball's
content different from the package-version scheme. But one issue comes
to my mind:

Did you call dh_make with the "-f" option to tell it where the upstream
tarball resides? Without that option it would look for
../package_version.orig.tar.gz.

I don't think that it's completely evil to repack the upstream archive
if it has strange formats or naming conventions. Examples are:

- the archive is in .tar.bz format
- the archive is in .zip format
- the upstream provides a debian/ directory that you find unusable

> That's really no problem, it might be frustating to find a sponsor
> sometimes, but having people who are willing to help eases this a bit ;)

Just tell. I had lots of trouble finding sponsors. Yet another reason I
helped found mentors.debian.net. ;)

Once your package is fixed I'll offer sponsorship. Let us know when you
are done.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: kde-icons-nuvola -- popular icon theme for kde

[Christoph Haas]

On Thu, Sep 01, 2005 at 11:41:00PM +0200, Bastian Venthur wrote:
> Cool, thanks! I've corrected all issues but one: I've left the word
> "library" in the copyright as it is, since this snippet is a verbatim copy
> of license.txt included in the upstream tarball.
> 
> I think it's better to leave this as it is in favour of the intended
> upstream license than correct it for logic/semantic reasons. Do you agree? 

Agreed.

> PS: the updated package (I've not altered the debian version) can be found
> at http://venthur.de/debian/nuvola/

Please check your packages with linda and lintian, too. lintian found
this error here:

$ lintian -i kde-icons-nuvola_1.0-1_i386.changes
E: kde-icons-nuvola: old-fsf-address-in-copyright-file
N:
N:   The /usr/share/doc//copyright file refers to the old postal
N:   address of the Free Software Foundation (FSF). The new address is:
N:
N: Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
N: MA 02110-1301, USA.
N:

You may want to fix it and inform the upstream about it.

Everything else looks fine to me. I like the icons, too. :)

 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: Debian package of InsightToolkit - A free and powerful image segmentation and registration tool

[Christoph Haas]

On Wed, Sep 07, 2005 at 10:00:19PM +0800, Guanglei Xiong wrote:
> I have packaged InsightToolkit (www.itk.org) for Debian. This is my first
> time of packaging. I am trying to find if anyone can check and upload
> it. Thanks!

Thank you for your effort. Please tell us where you have put the Debian
packages so that everybody gets a chance to look at it.

If you don't have any space to put it consider uploading it to
mentors.debian.net.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS aldo - A morse code trainer

[Christoph Haas]

Hi, Giuseppe...

On Sat, Sep 10, 2005 at 08:22:04PM +0200, Giuseppe Martino wrote:
> Hello, I am the project administrator and developer of the Aldo
> project at savannah.nongnu.org:
> http://savannah.nongnu.org/projects/aldo  
> [...]
> The Homepage for the project is: http://aldo.nongnu.org
> Source package on: http://savannah.nongnu.org/download/aldo/aldo-0.6.8.tar.bz2
> 
> I have actually already read the New Maintainers Guide, and I have built 
> a Debian package for Aldo.

Very good!

> You can find it on: http://dakordhost.homelinux.org/~denever/aldo_debian
> 
> I have tested it. However, I am very inexperienced at making 
> packages and I would be greatful to hear any suggestions a sponsor would 
> have.  Obviously, I need a sponsor to actually upload the package but I 
> definitely could use some "mentoring" for the packaging process as a whole.

You are likely to find someone here who will be sponsoring your package.
Allow me just express a few thoughts on your debianization:

- the debian/rules file contains debhelper calls that are commented
  out and be safely be removed
- there are also debhelper calls that you don't need (like
(dh_installexamples or dh_link). You may want to read what each
debhelper script basically does (there are good manpages for each
one).

But what's more important. The build failed here:

# Add here commands to configure the package.
CFLAGS="-Wall -O2 -Wl,-z,defs" ./configure --host=i486-linux-gnu
--build=i486-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info
configure: error: cannot find install-sh or install.sh in config
./config
make: *** [config.status] Error 1

Could you take a look at that? If it works on your development system
please try it through "pbuilder".

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: calcurse - A text-based calendar

[Christoph Haas]

Hi, Ryan...

On Wed, Sep 21, 2005 at 11:11:51AM -0400, Ryan Coyner wrote:
> I'm looking for a sponsor this nifty console-based calendar.

Thanks for your contribution. I didn't find any obvious problems with
your package. You may just reconsider not using "dh_link" you run in the
"binary-arch:" target. And I believe that both the "TODO" and the
"NEWS.gz" files are not especially useful for the end-user.

But the good news: I have just uploaded it. :)

If you have updates of your package please mail me directly. I'll
sponsor future versions as well.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: Kat -- Desktop Search Enviroment for KDE

[Christoph Haas]

On Mon, Sep 26, 2005 at 02:24:15AM +0200, Adeodato Simó wrote:
> Jonas Genannt [Fri, 23 Sep 2005 21:14:55 +0200]:
> 
> > I'm searching for a sponsor for Kat.
> 
>   Uhm. Can you explain what's going on with the ITP?
> 
> 2005-05-14: #309068 - ITP: kat, by Jean-Remy Falleri
> 2005-09-16: #328610 - RFP: kat, by Nicolas DEGAND
> 2005-09-22: you retitle #328610 to ITP
> 2005-09-22, one hour later: you merge #328610 with #309068, without
> mention whether you've contacted Jean-Remy or not.

I just checked both packages. The package of Jean-Remy Falleri looks a
bit strange actually. The README talks about "kdeplayground" instead of
"kat". Perhaps just a copy/paste error. I didn't look much deper into
it.

Jonas' package looks reasonable to me. Some minor things I'm not
instantly happy about:

- Of course the ITP/merge/RFP/RFS issue should be clarified.
- The kat/doc/Makefile should probably be cleaned away. It's contained
  in the .diff.gz
- The description of "libkat0" in the debian/rules reads
  "This package contains the katlibraries."
  I'd like to rephrase it like "This package contains the library
  that are used by the kat desktop search environment."
- The copyright doesn't include the year of copyright. It also
  lacks the "e" of "file" at the end.
- The README and TODO files don't look very helpful to the end-user.
- The README.Debian doesn't contain anything that isn't found in
  the other files anyway.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: istanbul - Desktop session recorder (ITP: #316503)

[Christoph Haas]

On Mon, Sep 26, 2005 at 03:11:22PM +0200, Luca Bruno wrote:
> I'm searching a sponsor for my package istanbul (ITP: #316503).
> You can find it on debian-mentors repository:
> 
> deb-src http://mentors.debian.net/debian unstable main 
> or
> http://mentors.debian.net/debian/pool/main/i/istanbul/
> 
> It is lintian & linda clean. 

Very good. Just some thoughts:

- please close the #316503 in your debian/changelog
- "Not yet official Debian package." is nothing that has
  really changed, is it? :)
- Great that you provide a menu file. Please consider using a
  .desktop file too/instead.
  (http://freedesktop.org/Standards/desktop-entry-spec)
- The README.Debian doesn't look very helpful for the end-user.
- The revision number 0.1.1-0.1 looks like an NMU revision.
  You probably don't mean that.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: istanbul - Desktop session recorder (ITP: #316503)

[Christoph Haas]

On Tue, Sep 27, 2005 at 11:44:34AM +0200, Luca Bruno wrote:
> Christoph Haas <[EMAIL PROTECTED]> scrisse:
> > Very good. Just some thoughts:
>  
> > - The revision number 0.1.1-0.1 looks like an NMU revision.
> >   You probably don't mean that.
> > - please close the #316503 in your debian/changelog
> 
> As I've already written in my previuos message, I used -0.1 because
> that is a not (yet) official package. Your fixes (and others as well)
> will be in -0.2 soon, for another revision here.
> -1 will be the revision for first sid upload.
> I'm going to close my ITP in -1.
> Please read also [1]...

Yes, I read that. Okay. I assumed that it's an NMU but it's right that
0.1 cannot be an NMU revision since -0 is not a valid revision either.
Although I personally prefer the "pre" syntax. If you want to keep that
I recommend you override the lintian warning though.

> > - "Not yet official Debian package." is nothing that has
> >   really changed, is it? :)
> 
> It is the original status of this package, like "Initial release".
> I'm going to put something like: 
> "First official upload in debian (Closes: #316503)"
> in -1 revision...
> Is fine in this way?

That would be perfect. Closing the ITP bug with the first upload is
common practice.

> > - Great that you provide a menu file. Please consider using a
> >   .desktop file too/instead.
> >   (http://freedesktop.org/Standards/desktop-entry-spec)
> 
> I think it is already provided within my package...
> Isn't "/usr/share/applications/istanbul.desktop" what are you looking
> for?

Uh, err, it was late... and dark... and I had too much coffee...
Point taken. ;)

> > - The README.Debian doesn't look very helpful for the end-user.
> 
> Maint. Guide says: "Any extra details or discrepancies between the
> original package and your debianized version should be documented here."
> Isn't this the case (an extra manpage taken from another distro)?
> Should I really remove it?

Matter of taste. I would personally not include it. IMHO users should
first read the README.Debian to find out how the package works
specifically on Debian. Although it may be technically correct to tell
where you got the man page from it doesn't add much value to the
end-user. But that's up to you.

Another issue: the man page looks strange with an "empty" SYNOPSIS.
A first-time user would probably not have an idea how to use
"istanbul". (And actually I don't have an idea currently either. I can
start/stop a recording in the taskbar. And then? Where is the file?
How do I quit the program?)

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS: Kat -- Desktop Search Enviroment for KDE

[Christoph Haas]

On Tue, Sep 27, 2005 at 09:32:01PM +0200, Jean-Remy Falleri wrote:
> The (cleaned) packages I have made are in:
> http://jr.falleri.free.fr/fichiers/debian/kat
> 
> I am still interrested in working on it but I don't have any
> objections to work with another people.
> 
> If someone can tell me if there are some things to fix in it (and if
> not, if anybody could sponsor it :) ).

Good to hear you still like to maintain the package. Please run
"lintian" on your package and see if you can fix those issues.

Also please consider splitting the package. The end-user will probably
not need the /usr/include/kat files.

And again... why the AUTHORS, TODO and README files?

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS aldo - A morse code trainer

[Christoph Haas]

On Fri, Oct 07, 2005 at 04:56:30PM +0200, Giuseppe Martino wrote:
> I worked on the new version of aldo, aldo-0.7.0.
> 
> I uploaded aldo-0.7.0 on mentors.debian.net.

So far so good. Please:

- file an ITP bug and close it in debian/changelog
- the copyright information is incomplete - it misses e.g. the year number
- The TODO doesn't seem to have much of value for the end-user.

Regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS aldo - A morse code trainer

[Christoph Haas]

On Sat, Oct 08, 2005 at 10:16:00AM +0200, Giuseppe Martino wrote:
> > - file an ITP bug and close it in debian/changelog
> Fixed
> 
> > - the copyright information is incomplete - it misses e.g. the year number
> Fixed
> 
> > - The TODO doesn't seem to have much of value for the end-user.
> Removed TODO
> 
> I uploaded new package on mentors.debian.net

Very good. Found it.

I compared the original tarball to the *.orig.tar.gz that you uploaded.
It appears that you removed the TODO file from the orginal tarball. Please
don't change it unless you have to do that. My upload to Debian contains
the original tarball instead.

Your package has been uploaded and will hopefully appear in "unstable" soon.
Thanks for your contribution.

Regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] crystalcursors and kde-icons-nuovext

[Christoph Haas]

On Saturday 15 October 2005 14:59, Bastian Venthur wrote:
> I'm searching for sponsorship of my packages:
>
> crystalcursors
>  + http://packages.qa.debian.org/c/crystalcursors.html
>  + http://venthur.de/debian/crystalcursors/
> closes: #328298 (Hot Point of Lefthanded Themes Wrong)

Notes for crystalcursors:
- lintian is complaining bitterly
  (see the artwiz-cursor package for a lintian override if you believe
  that these warnings are okay)
- a lot of commented-out debhelper calls in debian/rules
- why dh_installexamples? There are no examples.
- why dh_installman? There are no manpage.
- why dh_link? There are no symlinks to set?

> kde-icons-nuovext
>  + http://packages.qa.debian.org/k/kde-icons-nuovext.html
>  + http://venthur.de/debian/nuovext/
> closes: #324505 (Includes text files under /usr/share/icons)

Notes for kde-icons-nuovext:
- why are you using "gzip -9"? I'd prefer dh_compress
- why move the documentation around manually instead of using
  dh_installdocs?
- the download URL is mentioned in  brackets. Why?
  It is not an email address.
- it may be a matter of taste but I would not extract the upstream
  tarball right into the debian/... directory. Why not using that file
  as an *.orig.tar.gz. Okay, it's too late for this upstream version
  since Debian already has your *.orig.tar.gz in the archives.
  It appears like your current *.orig.tar.gz consists of the real
  *.orig.tar.gz. Do I miss a reason why it's done this way?
  I would rather do it the dh_make way and install the files with
  dh_install.

Kind regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] crystalcursors and kde-icons-nuovext

[Christoph Haas]

On Saturday 15 October 2005 22:47, Bastian Venthur wrote:
> Christoph Haas wrote:
> > On Saturday 15 October 2005 14:59, Bastian Venthur wrote:
> >> I'm searching for sponsorship of my packages:
> >>
> >> crystalcursors
> >>  + http://packages.qa.debian.org/c/crystalcursors.html
> >>  + http://venthur.de/debian/crystalcursors/
> >> closes: #328298 (Hot Point of Lefthanded Themes Wrong)
> >
> > Notes for crystalcursors:
> > - lintian is complaining bitterly
> >   (see the artwiz-cursor package for a lintian override if you believe
> >   that these warnings are okay)
>
> Done, the package is now l/l-clean.

Very good.

> > - a lot of commented-out debhelper calls in debian/rules
>
> Hmm, this is rather cosmetical, isn't it?

Mostly. But the template is merely there as a superset of things you could
possibly need. It doesn't do any harm to leave it in there. And I don't
think it would waste more time and bandwidth than this thread. ;) It's just
nicer to read.

> I think crystalcursors should be OK now and I would really appreciate it
> if somebody could sponsor the upload, because it would close the "lefty"
> bug which has already been unneccesarily long open.

Okay, uploaded.

Regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] crystalcursors and kde-icons-nuovext

[Christoph Haas]

Hi, Bastian...

regarding kde-icons-nuovext...

On Monday 17 October 2005 13:10, Bastian Venthur wrote:
> Christoph Haas wrote:
> > - it may be a matter of taste but I would not extract the upstream
> >   tarball right into the debian/... directory. Why not using that file
> >   as an *.orig.tar.gz. Okay, it's too late for this upstream version
> >   since Debian already has your *.orig.tar.gz in the archives.
> >   It appears like your current *.orig.tar.gz consists of the real
> >   *.orig.tar.gz. Do I miss a reason why it's done this way?
> >   I would rather do it the dh_make way and install the files with
> >   dh_install.
>
> Done, I've changed it to a more standard-compilant method.

Okay. Just keep in mind that you cannot change the orig.tar.gz which
is currently in Debian. You can only provide new *.diff.gz files for
the same upstream tarball. So it's more a todo when your upstream
releases a new version.

Or you artificially release an orig.gar.gz with a version that appears
higher than the current one.

> Thanks for pointing out all these ugly bugs. When I created this package
> this was one of my first packages and the -2 fix is quite old too. I
> think I've learned a bit in the meanwhile. The rules file looks *much*
> better now.

You wouldn't want to look at my first package. ;)

> -2 never hit the archive. To test the -vVersion Option, I created a -3
> version with a rather verbose changelog. I hope this is Ok this time.

I'll check your work later when I'm at home. If it's remotely okay I'll
upload it. Thanks for considering my comments. And don't be upset by some
of the comments here. IMHO that was too overreacting. There are
debian/rules files which look much worse.

 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: [RFS] crystalcursors and kde-icons-nuovext

[Christoph Haas]

On Monday 17 October 2005 18:00, Bastian Venthur wrote:
> Christoph Haas wrote:
> > Okay. Just keep in mind that you cannot change the orig.tar.gz which
> > is currently in Debian. You can only provide new *.diff.gz files for
> > the same upstream tarball. So it's more a todo when your upstream
> > releases a new version.
>
> Ooops. This is not good.
>
> There is already a new upstream version (1.5) but with this version,
> upstream changed the license from GPL to CC with the bad "non
> commercial" clause -- so it's not very likely that I'll ever find a
> sponsor for this (nonfree) version. If upstream does not change his
> mind, I guess debian will only see 1.1 in the archive and so there won't
> be a "new upstream" anymore.
>
> Is it really not possible to provide a new orig.tar.gz (eg by removing
> the old one)? I mean my old version was really crappy and I don't want
> to leave this package in this state forever.

No. I even had this problem with a security upload of a package where the
upstream left bits and pieces of his own attempt to debianize the package
in (.../debian/...) which collided with our work. We had to deal with it
and wait for a new upstream release. You have no (realistic) chance to get
a new orig.tar.gz of the same upstream version into Debian.

So the more or less common workaround is to increase the revision number
(see
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version)
to make the FTP upload servers think it's a new upstream release. You can
use a higher epoch number (although you will probably regret that) or
increase the upstream version (although that's bad, too, since that invents
a version that does not exist).

In your case I'd leave it like it is and use your tidying up work for the
next upstream release.

> I've just played around with epochs. I tried to change the version to
> 1:1.1 but this does not work. I sniffed the sources of some other
> packages with epochs and saw, that they don't include the epoch in the
> filename.

That's right. The epoch is just there as an override for the package
management system to tell certain version numbers apart. You will not see
it in file names. Increasing the epoch should have worked though.

> My last desperate attempt was be to change the upstream version from 1.1
> to 1.1.0 -- would this be acceptable?

Yes, that sounds like a rather good idea. Doesn't look too ugly and tricks
the version comparison system. :) If you don't know it already... see the
man page for "dpkg". There is a nice option called "--compare-versions"
which allows you to find out whether a revision is newer than another one.

> Even if the package is not uploadable due the new orig.tar.gz -- could
> you please take a look at my other changes in this package?

Sure. Just one issue:

mv $(CURDIR)/debian/$(PACKAGE)/usr/share/doc/$(PACKAGE)/CHANGELOG 
$(CURDIR)/debian/$(PACKAGE)/usr/share/doc/$(PACKAGE)/changelog

I suggest you rather use dh_installchangelogs for that. Please see its man
page. (That means also removing the debian/docs file.)

Everything else looks like I had expected it. If you are happy with
increasing the version from 1.1 to 1.1.0 and nobody else objects (I never
had such a special case) that package would be okay for me.

Cheers
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] crystalcursors and kde-icons-nuovext

[Christoph Haas]

On Monday 17 October 2005 21:36, Bastian Venthur wrote:
> Christoph Haas wrote:
> > I suggest you rather use dh_installchangelogs for that. Please see its
> > man page. (That means also removing the debian/docs file.)
>
> The general problem here is, that upstream sometimes provides the
> filenames of optional docs in uppercase. But the policy wants them to be
> lowercase. What would be a more general solution to rename those files?
> If upstream provides a README, should I use dh_installchangelogs as
> well?

You can run dh_installchangelogs with the upstream's changelog file
as an argument. Thus the hint to the man page. :) The CHANGELOG file will
then be moved and renamed automagically. If you would change that final
issue your package would be relatively perfect.

> If the above lines of code (renaming the CHANGELOG to changelog) are
> acceptable, I'd rather have the 1.1.0 solution than using an epoch. In
> the future I'll take more care when creating an .orig.tar.gz.

Agreed.

> Maybe I can convince upstream to change his mind so he removes the "non
> commercial" clause, so a new upstream version will undo this faux pas ;)

The world would be far better without upstreams... ;)

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] crystalcursors and kde-icons-nuovext

[Christoph Haas]

On Monday 17 October 2005 23:15, Bastian Venthur wrote:
> Hehe, I guess my package is relatively perfect (and uploaded) now ;)

The $(CURDIR) is redundant in dh_installchangelogs. But I won't harass
you with that any more. :)

> But one last question. What if upstream provides a README, which want to
> keep. Would it be ok to do my "mv README readme" trick, or is there a
> dh_* I've overseen?

I would just dh_install it. Why is it a problem if it's in uppercase?

Otherwise... the "dh_install" does not allow renaming which has bugged me a
few times already. So if you really wanted to rename it you would rather
need to use "install". Moving it away would mean you cannot build the
package twice (which must be working according to the policy) since the
second time the source file is no longer there. Or am I wrong?

Your package is now uploaded. Glad you made it.

I'll stick to the nuvola icons on my system though. Less ugly... :)

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] kde-icons-nuvola and kde-icons-crystalclear

[Christoph Haas]

On Tuesday 18 October 2005 10:24, Bastian Venthur wrote:
> I'm searching for sponsorship of my packages:
>dh_install 128x128 16x16 22x22 32x32 48x48
> kde-icons-nuvola
>  + http://packages.qa.debian.org/k/kde-icons-nuvola.html
>  + http://venthur.de/debian/nuvola/

As usual I have found something to grumble about. :)

dh_install 128x128 16x16 22x22 32x32 48x48...
=> Consider putting these directories into debian/kde-icons-nuvola.install
   (See "man dh_install")

find ... -type f -exec chmod 644 {}
=> Isn't dh_fixperms doing that already?

find ... -name laptop_charge -exec rm \{\} \;
=> You are doing that after dh_builddeb? Advanced magic? :)

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] kde-icons-nuvola and kde-icons-crystalclear

[Christoph Haas]

On Tuesday 18 October 2005 10:24, Bastian Venthur wrote:
> I'm searching for sponsorship of my packages:
>
> kde-icons-crystalclear
>  + http://venthur.de/debian/crystalclear/
> closes: #322161
>  + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322161
> * Package name: kde-icons-crystalclear
>   Version : 0.0.20050623
>   Upstream Author : Everaldo Coelho <[EMAIL PROTECTED]>
> * URL :

- Similar thoughts here about dh_install and dh_fixperms.
- debian/control contains an empty "Depends:" line.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] kde-icons-nuvola and kde-icons-crystalclear

[Christoph Haas]

On Wednesday 19 October 2005 11:57, Bastian Venthur wrote:
> The package will be completely uploaded in ~45min.

Both kde-icons-nuvola and kde-icons-crystalclear uploaded.

Cheers
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS tcpxtract - extracts files from network traffic based on file signatures

[Christoph Haas]

On Tuesday 25 October 2005 14:12, Nico Golde wrote:
> Since I am not yet an official dd I search a sponsor for
> tcpxtract

Please fix the debian/copyright file. At least the year of copyrights
need to be mentioned. And you have a typo in the email address of the
author.

You do not need to mention debian/conffile.

dh_link, dh_installexamples and probably others as well are not needed.

Besides it doesn't look very stable. I ran it in the background and opened
slashdot.org in the browser. It captured 56 image files and then
segfaulted. That happened with two other websites, too.

Regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: stopwatch

[Christoph Haas]

Hi, Daniel...

On Monday 31 October 2005 03:07, Daniel Milstein wrote:
> I was wondering if anyone would be interesting in sponsoring the
> stopwatch, a virtual stopwatch and timer program, package, which is in
> the public domain. I could not find any programs like it in APT,
> although there may be some that I overlooked. 

I had also looked for a simple stopwatch program but couldn't find one.
So perhaps there is none in Debian yet. :)

> Its ITP bug number is 336534 and the package
> can be found at http://geocities.com/vze49jxa. It 
> is lintian and linda clean and has been thoroughly tested. Its upstream
> source is http://expect.nist.gov/stopwatch.

Hints/Suggestions:

- you altered the Makefile but I don't see why
- If you need to change the base path of "wish" I suggest you do that
  through the powers of "dpatch" instead of changing the script
  directly. Otherwise you will have to do that with every new
  upstream release.
- instead of copying (cp) files around you may also use dh_install
  and dh_installman for consistency.
- the debian/rules file contains dh_ lines that can be removed.
  dh_link for example. And all the lines that are commented out.
- have you offered the man page to the upstream for inclusion in
  the next upstream version?
- you use docbook-to-man but at the same time your diff.gz contains
  a stopwatch.1x file. Shouldn't that be created during building?
- the debian/copyright is too minimal. Include the proper years of
  copyright. And clarify the license. "public domain" doesn't mean much.
  Check the DFSG.

I would generally help and sponsor your package. But since verizon.net is
rejecting mail from my mail server (mx.workaround.org) for a year and does 
not intend to talk to me why they do that it may be hard to communicate 
with you. (Someone should kick them hard.)

 Christoph
-- 
|\  _,,,---,,_Famous last words of a sysadmin:
/,`.-'`'-.  ;-;;,_"We'll do the backup tomorrow."
  <|,4-  ) )-,_..;\ (  `'-'
'---''(_/--'  `-'\_)


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

Re: RFS - kommando - ITP #336607

[Christoph Haas]

On Tuesday 01 November 2005 14:42, Sune Vuorela wrote:
> I have built kommando, a kde wheel menu.
>
> It gives quicker access to some programs - and it is a nice piece of
> showoff-eyecandy ;)
>
> http://mirror.pusling.com/kommando-rfs/
>
> I have had people using the package for some time now - but I think it
> is a so cool program that it should enter debian.
>
> and of course - those picky programs, linda and lintian, do not seem to
> have any errors/warnings

I would like to to take a look at it. Notes:

- the debian/copyright lacks the years of copyright
- insane number of Build-Depends - are they all necessary?
- still it doesn't build in a pbuilder so the dependencies are
  probably wrong [1]
- the debian/control refers to "Neverwinter Nights". Although I know
  what you mean that may not be clear to many. And it's probably a
  trademark. Suggestion:
  "A wheel-menu to quickly pick menu items with the mouse"
  The long description doesn't fully taste right to me but I don't have
  any creative suggestion here.
- You have created a nice man page. Did you send it upstream so it can
  be included in the orig.tar.gz at the next upstream release?
- debian/rules contains lines that can be removed (all the dh_*
  commands that are commented out). Also you probably don't need to
  call dh_installexamples or dh_link.

 Christoph


[1]
checking if Qt needs -ljpeg... no
checking for rpath... no
checking for KDE... configure: error:
in the prefix, you've chosen, are no KDE headers installed. This will fail.
So, check this please and use another prefix!
make: *** [config.status] Error 1
pbuilder: Failed autobuilding of package

-- 
|\  _,,,---,,_Famous last words of a sysadmin:
/,`.-'`'-.  ;-;;,_"We'll do the backup tomorrow."
  <|,4-  ) )-,_..;\ (  `'-'
'---''(_/--'  `-'\_)


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

Re: statist - terminal based statistics program

[Christoph Haas]

Hi, Jakson..

On Wednesday 02 November 2005 14:41, Jakson A. Aquino wrote:
> I would like to add a small statistics software to Debian
> official packages. Statist home page currently is on:
>
>   http://www.usf.uos.de/~breiter/tools/statist/index.en.html
>
> Soon we will have a new release of statist (1.3.1)

May I assume that you are actually the (upstream) developer of
the software and want to provide a Debian package for it?

> I don't know very well how to use the Debian tools to build
> a package. I'm using only dpkg-deb, and I need help to
> replace the script with the adequate procedures.

Please read: http://www.debian.org/doc/manuals/maint-guide/

> [...]
> 5) Run the script "create_deb_rpm.sh".

I have never heard of such a shell script yet.

> Can anyone help me? I think I need a sponsor...

Sponsors would upload your ready package. But - please don't be offended - 
your package seems to have a way to go still. If you don't like to get 
deeper into Debian package building that's okay. Just find someone who 
creates a package for your developed software. In that case you would file 
an RFP (request for package) but against the "wnpp" pseudo package. That 
way you will hopefully find a potential package maintainer.

If you like to maintain the package yourself then please start by reading 
the New Maintainer's Guide which I told you the link for above.

Regards
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: RFS - kommando - ITP #336607

[Christoph Haas]

Hi, Sune...

the package looks a lot better now. Thanks for your work. I have just 
uploaded the package.

Some minor things you may want to look at for your next revision:

You change the kommando-0.2/src/kommando.desktop file. You should either 
have the upstream include this change in the next release or use "dpatch". 
If the upstream comes up with a new release you will have to remember 
changing that file again.

Spend some time looking at the debhelper scripts (dh_*). Each of them has a 
man page. And many tasks you do manually in your debian/rules file are 
easier done through debhelper. Example:
"cp debian/kommando.xpm debian/kommando/usr/share/pixmaps/" would look 
nicer if you used "dh_install" for it.

I personally don't like to "make install" into debian/$PACKAGE. I rather 
pick the files I need and use dh_install to copy them into place. At least 
in simpler packages like these which don't contain hundreds of files it's 
easy. But that's a matter of taste.

Thanks for your contribution so far.

 Christoph
-- 
|\  _,,,---,,_Famous last words of a sysadmin:
/,`.-'`'-.  ;-;;,_"We'll do the backup tomorrow."
  <|,4-  ) )-,_..;\ (  `'-'
'---''(_/--'  `-'\_)


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

Re: [RFS]qterm - BBS client for X Window System written in Qt

[Christoph Haas]

On Saturday 05 November 2005 02:24, LI Daobing wrote:
> New version(0.4.0pre3-2), fix a serious bug[1]. uploaded to mentors[2].
> lintian, linda, pbuilder clean. Thanks.

Uploaded.

One minor issue: you added debian/README.Debian to the debian/docs. I'm not 
very familiar with CDBS but since it calls dh_installdocs this file should 
get installed automatically.

 Christoph
-- 
|\  _,,,---,,_Famous last words of a sysadmin:
/,`.-'`'-.  ;-;;,_"Strange, you shut down the server but I can
  <|,4-  ) )-,_..;\ (  `'-'still log in. Which server did you say you
'---''(_/--'  `-'\_)   shut down?"


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

Re: RFS: unidesc - Tools for finding out what is in a Unicode file.

[Christoph Haas]

On Friday 04 November 2005 22:45, Mohammed Sameer wrote:
> I'd be glad if someone can sponsor me.
> Here's my work: http://home.foolab.org/debs/unidesc/2.15.1/1/
> ITP #337498

Why is the orig.tar.gz different from the file found at 
http://billposer.org/Software/Downloads/unidesc.tgz? I think it's just 
permissions inside the tar.gz but I wonder why you repacked it.

The debian/copyright is incomplete. Please add the year(s) of copyright.

Otherwise the package looks good.

 Christoph
-- 
|\  _,,,---,,_Famous last words of a sysadmin:
/,`.-'`'-.  ;-;;,_"Strange, you shut down the server but I can
  <|,4-  ) )-,_..;\ (  `'-'still log in. Which server did you say you
'---''(_/--'  `-'\_)   shut down?"


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

Re: All files are in DESTDIR but non will be copied into the packages

[Christoph Haas]

On Thursday 10 November 2005 19:25, Timo Steuerwald wrote:
> I try to create packages for sipX from sipfoundry.org. This is a PBX
> like asterisk and is composed of a few subprojects like sipXportLib,
> sipXtackLib...
> I now tried to create a package for sipXportLib.
> What I have done up to now:
> 1. Read http://www.debian.org/doc/maint-guide/ completely :-)
> 2. executed dh_make -e 
> 3. filled files like copyright, control and so on with useful
> information 4. tried to build it via dpkg-buildpackage -rfakeroot
> This has completed successfully, but inside the packages data.tar.gz ins
> nearly empty. There exists only parts of the data that belongs to the
> debian subdirectory (like usr/share/doc/sipxportlib/copyright). No libs,
> nothing. The same for the -dev package: No documentation, include files
> and so on.

Sounds to me like you haven't properly done the debian/rules file. It's 
generally the makefile which compiles and creates all the packages.

Please read:
http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules

And look at all the dh_* scripts in the debian/rules script. Each of them 
has a manpage. You may want to read it. E.g. dh_install is copying files 
from your source directory into the directory where the Debian package 
will be built. And there is a file like debian/$PACKAGE.install which 
lists files installed by dh_install.

> If I look now to the debian subdirectory, there are three subdirectories
> tmp (which is my DESTDIR in the rules file), sipxportlib and
> sipxportlib-dev.

Those are probably the same names as the binary package that you configured 
in your debian/control file.

Showing us your package so far may also help giving you a hint.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: ksudoku -- sudoku puzzle generator/solver

[Christoph Haas]

On Thursday 10 November 2005 18:50, Ryan Schultz wrote:
> * Package name: ksudoku
>   Version : 0.3
>   Upstream Author : Francesco Rossi <[EMAIL PROTECTED]>
> * URL : http://ksudoku.sourceforge.net
> * License : GPL
>   Description : sudoku puzzle generator/solver
>
>  KSudoku is an interface for creating and solving sudoku puzzles, which
>  are grid-based placement puzzles that require time and logic to solve.
>  KSudoku is able to work with both 2D and 3D versions of these puzzles,
>  in grids of any square layout up to 25x25. It can also generate
>  configurable symmetric puzzles and other special types.
>
> Documentation is relicensed under the GPL; see debian/copyright.
>
> lintian/pbuilder-clean packages available from:
> deb http://rschultz.ath.cx/debian unstable/i386/
> deb-src http://rschultz.ath.cx/debian unstable/source/

I'm generally willing to sponsor this package.

Thoughts:

- The orig.tar.gz differs from the upstream tarball. It's just a
  rename of the directory inside and the admin/CVS directory is
  removed. It's a religious issue but I would rather leave the original
  upstream archive intact. The CVS wouldn't show up in the final
  package anyway.
- You patched ksudoku-0.3/doc/en/index.docbook. Would that be better
  solved through dpatch?
- The debian/copyright lacks the years of copyright.
- A 'desktop' file would be nice in addition to the 'menu' file.
  (Don't forget to call dh_desktop.)
- Some debhelper calls (like dh_link) are not needed.
- Could you send the manpages upstream so they can be included
  in the orig.tar.gz at the next release?
- The AUTHOR section of the man pages looks strange to me.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: ksudoku -- sudoku puzzle generator/solver

[Christoph Haas]

On Friday 11 November 2005 18:55, Ryan Schultz wrote:
> On Friday 11 November 2005 03:45 am, Christoph Haas wrote:
> > - The orig.tar.gz differs from the upstream tarball. It's just a
> >   rename of the directory inside and the admin/CVS directory is
> >   removed. It's a religious issue but I would rather leave the
> > original upstream archive intact. The CVS wouldn't show up in the
> > final package anyway.
>
> Changed; lintian will complain now, though :- )

That may be ugly but I think changing the upstream tarball is even worse.
Perhaps you can convince the upstream to remove the CVS from the release 
tarballs. It really doesn't belong there.

> > - You patched ksudoku-0.3/doc/en/index.docbook. Would that be better
> >   solved through dpatch?
>
> Upstream will be including an updated index.docbook in the next release
> (there is active development), so I didn't think it was necessary to
> break out the patch management systems just yet.

Agreed.

> > - A 'desktop' file would be nice in addition to the 'menu' file.
> >   (Don't forget to call dh_desktop.)
>
> I'm not sure what you mean; a desktop file is installed as part of the
> upstream source, /usr/share/applnk/Games/ksudoku.desktop. I've added the
> call to dh_desktop, though I don't understand what it does -- the
> manpage is short and I have no application called
> update-desktop-database *shrug*.

My bad. Indeed there is a ksudoku.desktop file which is installed. IMHO in 
the wrong place though. It should be located in /usr/share/applications 
instead. (Although I admit I don't know where that's properly documented 
in the policy. Perhaps someone else has a pointer.)

dh_desktop calls the update-desktop-database command from the 
desktop-file-utils package (if installed) through the maintainer scripts 
of your package. It's use is to tell e.g. KDE that the menu structure has 
changed and the *.desktop files have to be reloaded. Otherwise KDE 
wouldn't show a menu item of your newly installed package unless you 
relogin.

> > - Some debhelper calls (like dh_link) are not needed.
>
> Removing dh_link will cause a lintian error about relative symlinks,
> actually...

Hmm. Appears like the "make install" creates a symlink with an absolute 
path:

ln -s /usr/share/doc/kde/HTML/en/common \
/home/haas/.../ksudoku-0.3/debian/ksudoku/usr/share/doc/HTML/en/ksudoku/common

And dh_link fixes absolute symlinks to relative symlinks when needed:

./usr/share/doc/kde/HTML/en/ksudoku/common -> ../common

So dh_link is indeed important here. Leave it there.

Let's fix the desktop issue (or prove me wrong once again) and I'll happily 
upload it. :)

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: ksudoku -- sudoku puzzle generator/solver

[Christoph Haas]

Ryan...

thanks for your patience. :)

On Saturday 12 November 2005 03:16, Ryan Schultz wrote:
> On Friday 11 November 2005 02:30 pm, Christoph Haas wrote:
> > My bad. Indeed there is a ksudoku.desktop file which is installed.
> > IMHO in the wrong place though. It should be located in
> > /usr/share/applications instead. (Although I admit I don't know where
> > that's properly documented in the policy. Perhaps someone else has a
> > pointer.)
>
> I found a message[1] on debian-kde mentioning this; seems to be an XDG
> file location thing. I've moved it; however, it seems like kdevelop,
> KDE's IDE, defaults to installing there, so who knows?

I still need to learn about that. XDG doesn't ring a bell. And I couldn't 
find /usr/share/applications by grep'ing through the whole /etc. I really 
need to dig deeper into this.

Unfortunately your package doesn't show up in a menu here - except the ugly 
default "Debian" submenu. So the menu entry is correct but the desktop 
specification seems wrong. I just looked at "your" .desktop file:

[Desktop Entry]
Encoding=UTF-8
Name=ksudoku
Name[xx]=xxksudokuxx
Exec=ksudoku %i %m -caption "%c"
Icon=ksudoku
Type=Application
DocPath=ksudoku/ksudoku.html
Comment=A KDE KPart Application
Comment[ca]=Una aplicació KPart per a KDE
...

This looks like a template which has been edited a bit carelessly.
"A KDE KPart Application" should rather be "Sudoku Puzzle 
generator/solver". And 'xx' is no language I have ever heard of.
And the reason it doesn't show up in my KDE menu is probably that the 
category is not defined. Look at an example file from my 'cream' package:

[Desktop Entry]
Version=1.0
Type=Application
Encoding=UTF-8
Name=Cream
Comment=Edit text files
Comment[de]=Textdateien editieren
TryExec=cream
Exec=cream %F
MimeType=text/plain
Categories=Application;Utility;TextEditor;
Icon=/usr/share/pixmaps/cream.xpm

This application is shown in the "Editors" K-menu.

I do not claim to be a guru regarding desktop specification files. But 
since your package is mainly designed for KDE I would love it to show up 
in the K-menu menu under "Games/...".

By the way... you can find the desktop specificaton at:
http://freedesktop.org/Standards/desktop-entry-spec

The available categories are listed in Appendix A of:
http://www.freedesktop.org/Standards/menu-spec

I vote for something like "LogicGame".

> I've found that KDE actually seems to have some magic to do this without
> being told (like with 'make install'), but I don't think GNOME will.

I've started using desktop files with KDE 3.3 and it didn't have such 
magic. I needed to logout and login again. Please try removing and 
installing the package and look whether the menu items appears and 
disappears. Users won't like to restart their session just because they 
installed a new application. There is a reason Debian's logo is not a 
four-colored flag. ;)

Once the desktop file is fixed I promise I'll upload your package.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All

Re: RFS: ksudoku -- sudoku puzzle generator/solver

[Christoph Haas]

On Saturday 12 November 2005 18:17, Ryan Schultz wrote:
> Upstream wasn't very vigorous about editing the KDevelop defaults, I see
> :- ) I've written a new Desktop file; I'll include it in the package for
> now and send it upstream as well. I went with a simpler description so I
> could reuse the translations from other KDE games.

The translations are... interesting. A description which refers to the real 
nature of ksudoku might have been better.

> New revision uploaded. We should be ready to go now! :- D

You will hardly believe it... your package has just been uploaded.

One thing which I'd like to ask to to keep investigating. The menu item now 
shows up in K/Games. But it's the only games which does not appear in
K/Games/Arcade or K/Games/BoardGames. What I mean is that all other games 
are in submenus - just ksudoku is not. I'm not sure whether the LogicGame 
category is unsupported. Since we didn't get any help here please ask in 
debian-devel. I'll upload a new revision once this is sorted out. Please 
contact me for updates.

Thanks for your contribution.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: Aldo new package

[Christoph Haas]

On Sunday 13 November 2005 17:20, Giuseppe Martino wrote:
> Three bugs were founded for aldo: #334153, #334152, #334288.
>
> I fixed these and I issued aldo-0.7.0-3.

Okay, uploaded. The Bug #334288 wasn't changed in your debian/changelog 
though. You will have to close it manually through the BTS.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: ngircd -- Next generation IRC Server

[Christoph Haas]

On Wednesday 16 November 2005 00:13, Mario Iseli wrote:
> Package:  ngircd
> Version:  0.9.2-1
> Author:   Alexander Barton <[EMAIL PROTECTED]>
> License:  GPL
> ITP:  295970
>
> Description: Next generation IRC Server
> ngircd is a IRC Daemon for small or private networks.  It does not
> contain all the functions like the professional ones, e.g services. It
> is written from scratch and is not based upon the original IRCd like
> many others.

The Debian package is well done. I have just uploaded it. Thanks for your 
contribution.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS - enca - charset analyzer

[Christoph Haas]

On Monday 28 November 2005 19:49, Michal Čihař wrote:
> I've ready new version of enca to upload, but current sponsor doesn't
> have time for this, can somebody look at it and possibly further
> versions? Nothing big has changed, so there should not be much
> problems, of course linda and lintian do not complain.
>
> Enca is charset analyzer, which is able to guess text chatset for many
> languages (mostly eastern Europe, but now also Chinesse).
>
> New packages are at 
>
> Current packages are already in unstable and testing:
> 

No showstopper but a tiny typo in debian/control:
"Currently, it currently supports Belarussian..."

Worse: the year of copyright is missing in debian/copyright.

Could you fix these minor issues? Upload guaranteed then. :)

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All

Re: RFS - enca - charset analyzer

[Christoph Haas]

On Tuesday 29 November 2005 22:07, Michal Čihař wrote:
> On Tue 29. 11. 2005 21:34, Christoph Haas wrote:
> > No showstopper but a tiny typo in debian/control:
> > "Currently, it currently supports Belarussian..."
>
> Oops,I upgraded only half of description.
>
> > Worse: the year of copyright is missing in debian/copyright.
>
> Fixed.
>
> > Could you fix these minor issues? Upload guaranteed then. :)
>
> Thanks.

Thanks for the quick reaction. Package is uploaded.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All

Re: RFS: debmirror 20051209

[Christoph Haas]

On Friday 09 December 2005 19:20, Goswin von Brederlow wrote:
> I'm looking for a sponsor for debmirror (perl script):

Uploaded.

 A debmirror addict ;)
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: Proposal for collaborative maintenance of packages

[Christoph Haas]

Morning,

On Sunday 18 December 2005 17:19, Raphael Hertzog wrote:
> following the last discussion at the Debian-QA meeting on Darmstadt, it
> appears that the proposal called "Collaborative maintenance" is of
> generic interest :
> - for Debian sponsors and Debian mentors
> - for QA which may use the infrastructure for orphaned packages
> - for Ubuntu's MOTU School
>
> I tried to describe the big lines of the project in this wiki page:
> http://wiki.debian.org/CollaborativeMaintenance

Thanks for writing that down.

> I'm crossposting this to all people involved (even people responsible of
> the REVU tool used by Ubuntu) because I'm sure that we should all work
> together to realize this project.

I believe that mentoring/sponsoring is a permanent issue that can always be 
improved. When I attended the Ubuntu conference in Mataro in 2004 I was 
asked to present mentors.debian.net in a BOF. And I learned that many 
things went differently in Ubuntu compared to Debian. That doesn't mean 
it's generally bad. Many good ideas came up and new maintainer's process 
in Ubuntu was about to evolve during that time. But still I think that the 
approach for maintaining packages has become completely different in both 
distributions. I'm curious to hear more of Ubuntu/MOTUs. And this is not 
meant as an excuse to not improve things. :)

> This infrastructure is seriously needed in Debian because:
> - team maintenance with SVN is more and more popular, and a good web
>   interface above a SVN repo of Debian packages would help all those
>   teams

If there is a fixed team working on a package they propbably already use 
subversion and svn-buildpackage.

> - an official way to follow interaction between mentors and sponsors is
>   needed and actual mentors.debian.net/sponsors.debian.net are not
>   enough for that

Not in the current shape. Let me announce already that we are working on a 
massive redesign of mentors.debian.net at the moment. We will rework the 
interface to improve the communication between sponsors and mentors (yes, 
it's badly needed, I know). Our approach is not a repository though. m.d.n 
is mainly a place to upload and download packages - but not work on them 
in parallel. Repositories are very useful when packages are co-maintained. 
I'm working on multiple Debian projects where we would be lost without a 
repository. But when it comes to sponsorship it's the 
maintainers/sponsoree's task to maintain the package. I don't think the 
sponsor should change the package at all. When sponsoring packages I don't 
touch them. Even if there is a typo I "complain" to the package maintainer 
and have the bug fixed. So I personally see a difference between 
co-maintainership and sponsorship. I know that Ubuntu does not have this 
"package lock" like in Debian. Everyone seems to be allowed to upload 
every package without fearing to be flamed. Although this is a nice idea I 
doubt it will work in Debian.

> - we need to facilitate the work of sponsors because we're lacking
>   sponsors

Sponsoring isn't too hard. Potential sponsors just need to look at the 
debian-mentors mailing list (there are many RFSs) or perhaps check 
mentors.debian.net/sponsors.debian.net. The problem here is non-technical. 
You need to motivate more DDs to sponsor packages. Getting a package from 
a private repository/web space/mentors.debian.net is nearly trivial. The 
only issue that can be improved here is to get more volunteer sponsors and 
to get them informed if someone needs sponsorship.

> - we need to let skilled external contributors maintain packages for us
>   (when they don't want to become DD)

I'm perfectly happy with a "permanent sponsoring relationship". Some DDs 
seem to want every maintainer to become a DD. Becoming a DD is still a 
long road and IMHO not needed. Once I have sponsored a package I know it's 
technically okay and I know the sponsoree. Uploading a consecutive update 
of the same package takes a few minutes only. I wished more sponsors would 
offer such a relationship. When I had to look for sponsors myself a while 
ago I saw sponsors come and go. And some packages didn't even make it into 
Debian because nobody was interested.

> Furthermore, if we can standardize this infrastructure between
> Debian/Ubuntu, it will be easier to integrate packages created by Ubuntu
> MOTU in Debian (I'm speaking of packages which don't exist in Debian
> yet). 

Although I would of course like to have a better integration I doubt we 
will get that done soon. Ubuntu has developed a number of own tools to 
manage their distribution. DDs and MOTUs seem to work way differently. But 
I admit I will have to learn more on how Ubuntu handles that at the very 
moment.

> FWIW, I have an alioth project ready to be used :
> http://alioth.debian.org/projects/collab-maint/

What is the purpose of that project? Creating a repository? Or moving this 
discussion to a mailing list there?

As a conclusion... some of the aspects you propo

Re: RFS - kde window decoration powder

[Christoph Haas]

On Wednesday 21 December 2005 20:32, Sune Vuorela wrote:
> On 2005-12-10, I wrote:
> > I have now a package ready to close my ITP: #338554
> >
> No one interested in sponsoring ?

Uploaded. Thanks for the contribution. Get back to me if you have an update 
which you need to get into Debian.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: libhtml-wikiconverter-perl -- An HTML to wiki markup converter

[Christoph Haas]

On Tuesday 27 December 2005 13:39, Jonas Genannt wrote:
> I am searching for an sponsor for my libhtml-wikiconverter-perl package.

You've just found one. :) The package is uploaded. In the next version you 
may want to fix the minor typo at the end of the man page you supply
(s/terms as Perlitself/terms as Perl itself). Did you send the man page 
upstream so you don't need to add it for Debian only?

Please get back to me once you need to have an updated package uploaded.
I'll sponsor subsequent uploads of course.

Regards
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] altermime: utility used to alter mime-encoded mailpacks

[Christoph Haas]

On Thursday 29 December 2005 11:11, Julien Valroff wrote:
> I'm looking for a sponsor for altermime:
>  alterMIME is a small program which is used to alter your mime-encoded
>  mailpacks as typically received by Inflex, Xamime and AMaViS.
>  alterMIME can:
> * Insert disclaimers
> * Insert arbitary X-headers
> * Modify existing headers
> * Remove attachments based on filename or content-type
> * Replace attachments based on filename
>
> Homepage: http://www.pldaniels.com/altermime/
>
> The licence terms are quite clear, and it seems clear that the package
> is DFSG free. If you feel it can be a problem, can someone help to speak
> with the legal team?
>
> Both source and i386 binary packages can be found at:
> http://packages.kirya.net/pool/main/a/altermime/

According to the WNPP there is currently an ITP by David Moreno Garza 
<[EMAIL PROTECTED]>. Did you talk to him already? The ITP is over three 
months old though. Still nice to coordinate who's doing what.

Further thoughts:
- don't mention debian/README.Debian in debian/altermime.docs
  It gets installed by dh_installdocs anyway.
- still debian/altermime.docs:
  the README doesn't carry much useful information. Consider dropping it.
- the README.Debian doesn't help much IMHO. If people find
  /usr/share/doc/altermime/README.Debian I believe they can also
  find /usr/share/doc/altermime/README
- the architecture is i386. Does it really not run on anything else?
- you call debhelper scripts like dh_link but you don't set links.
  Drop those calls.
- the man page you ship mentions a LICENSE file which does not get
  installed

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] altermime: utility used to alter mime-encoded mailpacks

[Christoph Haas]

On Friday 30 December 2005 18:39, Julien Valroff wrote:
> Thanks for your comments.
>
> As stated by Justin, I have already been advised to let dh_link, even if
> no links have to be set. Should I remove this call anyway?

I believe Justin is right. So just leave it there.

> I will build a new package if you think altermime can be uploaded. The
> changes can be viewed at:
> https://svn.kirya.net/comp.php?repname=altermime&path=&compare%5B%5D=%
> [EMAIL PROTECTED]&[EMAIL PROTECTED]

Looks good. Where can I get the diff.gz?

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] altermime: utility used to alter mime-encoded mailpacks (uploaded)

[Christoph Haas]

On Friday 30 December 2005 19:23, Julien Valroff wrote:
> I removed LICENCE as Policy states that all licence information[1]
> should be in debian/copyright. I thus changed the man page to point
> to /usr/share/doc/altermime/copyright.

Good. Package appears to be clean now. Thanks for your contribution. 
Package is uploaded. Please get back to me if you need to have a new 
version uploaded.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: [RFS] altermime: utility used to alter mime-encoded mailpacks (uploaded)

[Christoph Haas]

On Friday 30 December 2005 21:06, Julien Valroff wrote:
> However, the package was rejected as orig.tar.gz was not included in the
> upload. The package should be rebuild with dpkg-buildpackage -sa option.
> Do you need me to do that?

No, no, that was my mistake. Building with old changelog entries (-v) and 
pbuilder made me forget to add the orig file (-sa). It should be fixed 
now.

Cheers and happy new year
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: kde-style-comix

[Christoph Haas]

On Tuesday 03 January 2006 02:38, Sune Vuorela wrote:
> I have this teeny weeny package called kde-style-comix, which gives a
> nice widget style and window decorations to your kde.
> It closes a one year old itp: #286205
>
> the package is located here:
> http://mirror.pusling.com/comix-rfs/
>
> and it is almost lintian clean. upstream provides CVS-dir, which lintian
> rightfully complains about.
>
> Any comments welcome - and perhaps a sponsorship ;)

I just took a look at the package. Allow me my usual rant^H^H^H^Hhelpful 
comments:

* I don't yet like the long description. "I hope this adds a little
  more fun to your desktop..." is probably true but I'd like to read
  a more technical description like "A flat style for KDE..."
  "Thanks to..." does not really belong there. "Please read..." -
  well, the I assume everyone who is interested in the walks and
  talks of the package will look into /usr/share/doc/...
  Telling the user about bugs there is probably not inspiring
  confidence either. :)
  I see that you took that directly from the kde-look.org page.
  But perhaps this can be stripped down.
* Check the debian/docs files you install. A "NEWS" file which just
  contains "see README" is not very useful. The "README" is also
  useless because it tells the user how to install the package
  on non-Debian packages. One could argue about the "TODO" file...
* You have probably lintian-checked the package. There is a warning
  "W: kde-style-comix source: source-contains-CVS-dir admin/CVS".
  Although you can do little about it you should talk to the upstream
  author to not ship CVS directories.

That aspects aside I'd sponsor the package.

 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: kde-style-comix [uploaded]

[Christoph Haas]

On Wednesday 04 January 2006 19:36, I wrote:
> On Tuesday 03 January 2006 02:38, Sune Vuorela wrote:
> > I have this teeny weeny package called kde-style-comix, which gives a
> > nice widget style and window decorations to your kde.
> > It closes a one year old itp: #286205
> >
> > Any comments welcome - and perhaps a sponsorship ;)
>
> That aspects aside I'd sponsor the package.

As seen on IRC: package uploaded. :)

 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: tikiwiki

[Christoph Haas]

On Tuesday 10 January 2006 13:13, Marcus Better wrote:
> I am renewing my request for a sponsor for Tikiwiki. I would like to
> upload it to experimental for easier access, so that I can get it more
> widely tested.

Roughly checked and uploaded to experimental. Good luck with the package.

Kindly
 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: plotdrop - A minimal GNOME frontend to GNUPlot [uploaded]

[Christoph Haas]

Hi, Jordan...

On Wednesday 11 January 2006 01:03, Jordan Mantha wrote:
> I am looking for somebody to sponsor a new package for me.
>
> Package: plotdrop
> Version: 0.5-1
> Section: math
> Priority: optional
> License: GPL
> Maintainer: Jordan Mantha <[EMAIL PROTECTED]>
> Description: A minimal GNOME frontend to GNUPlot
>   PlotDrop is designed for quick simple visualisation of 2D data series.
> It is intended to be used in tandem with an external filesystem browser
> such as GNOME's nautilus or KDE's konqueror. Files containing data are
> added by dragging them from the browser to the file list. The homepage
> for plotdrop is : http://icculus.org/~jcspray/plotdrop/

The package looks good. It's uploaded now. Get back to me if you need 
subsequent uploads. Thanks for your contribution.

Kindly
 Christoph

P.S.: I refuse to see differences in the orig.tar.gz - okay for me.
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: knmap -- Kde interface to nmap

[Christoph Haas]

Hi, Claudio...

On Friday 13 January 2006 12:15, Claudio Moratti wrote:
> Today, the up stream author, released a new version of knmap: 2.0
> The 2.0 package is available: http://www.knio.it/debian/knmap/

I have taken a look at the package and would generally sponsor the upload.
Minor things that I would like to have fixed:

debian/docs: [WISHLIST]
 The README is absolutely useless. Please don't install it.

debian/knmap.1: [INFO]
 Thanks for creating a man page. Did you send it upstream so it
 can be included in future distributions of knmap?

debian/patches: [QUESTION/HINT]
 You are changing a whole lot of the autoconf parts. Does this have
 to do with some transitions going on? Usually just the config.guess
 and config.sub are altered in Debian packages and those are directly
 in the diff.gz (without the need to use dpatch). Just curious.

Otherwise the package looks good.

 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: knmap -- Kde interface to nmap [uploaded]

[Christoph Haas]

On Friday 13 January 2006 19:40, Claudio Moratti wrote:
> On Friday 13 January 2006 15:48, Christoph Haas wrote:
> > debian/patches: [QUESTION/HINT]
> >  You are changing a whole lot of the autoconf parts. Does this have
> >  to do with some transitions going on? Usually just the config.guess
> >  and config.sub are altered in Debian packages and those are directly
> >  in the diff.gz (without the need to use dpatch). Just curious.
>
> My first sponsor, Florian Ernst, taught me about libtoolization...
> I relibtoolize every package, if necessary, in order to have a correct
> and minimal "Depencend" field...
> this is the reason ;-)

I thought I understood at least the reason to include diffs for a 
config.guess and config.sub. But IMHO relibtooling is only needed when 
certain libraries are in a state of transitions. Could you (or Florian (or 
anyone)) shed some light on this procedure and the whys? I have never seen 
this being used as a "common procedure" for packages and would like to 
learn.

> I uploaded the fixed package!

Me, too. :)

Another minor issue: the .desktop file makes knmap show up in the 
Applications menu rather than in the Internet (Network) menu. Perhaps the 
upstream could reconsider this classification.

 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: understand dpatch

[Christoph Haas]

On Sunday 22 January 2006 18:34, Rakotomandimby Mihamina wrote:
> I have a dpatch file, attached to this email.
> If I just remove the "dpatch headers" and run it with the conventional
> "patch" utility, I have no problems. The files get patched, without no
> errors.
>
> But when using it to build a package, with dpatch, (after having putting
> the dpatch headers), then I get these errors.
>
> What could be the problem? encoding errors? Or what else?
>
> mihamina-debiandpatch apply-all --verbose
> applying patch deb-zopeconf to ./ ...
> patching file Zope/skel/bin/runzope.in
> Hunk #1 FAILED at 3.
> 1 out of 1 hunk FAILED -- saving rejects to file
> Zope/skel/bin/runzope.in.rej

Looks like the patch didn't fit in here. Bit strange though. Could be the 
order of patches perhaps.

To get working dpatches I recommend using the 'dpatch-edit-patch' command. 
While you are in the "edit" session you can apply patches as you are used 
to (with the "patch" command). Once you leave the session the changes will 
be written into a dpatch-compliant file. See the man page. And remember to 
create an "unpatch" target in your rules file.

Kindly
 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: dsbltesters

[Christoph Haas]

On Wednesday 25 January 2006 14:10, Al Nikolov wrote:
> Package: dsbltesters
> Description: open proxy/relay testing utilities
> License: GPL
> URL: http://dsbl.org/programs
> Upstream Authors: Rik van Riel, Ian Gulliver, Ron Guilmette, Fred Smith
>
> This package contains testing software configured to work with
> the DSBL (http://dsbl.org/) or DSBL-compliant services.  It
> enables you to send tests to servers based on spam that you
> receive.  If those tests succeed, the results will reach the
> DSBL host in question, and the relay will be listed.
>
> It can be downloaded from:
> http://mentors.debian.net/debian/pool/main/d/dsbltesters/

I'd be generally willing to sponsor it, but...

- Please close the WNPP bug 273204 which you opened yourself
  one and a half year ago.
- Please use the current standards version.
- The copyright file should contain the years of copyright.
- There has been long time no change. Did you contact the upstream
  to make sure the software is still maintained?
- Installing the README file doesn't seem to add any value for the
  end-user.
- The upstream tarball I just fetched from the web site has another
  md5 checksum than the orig.tar.gz you provide. How come?
  At a first "diff -r" glance the two files have many differences.
- The package is not lintian clean. Three issues there.

Please fix that first.

Kindly
 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: dsbltesters

[Christoph Haas]

On Thursday 26 January 2006 21:18, Al Nikolov wrote:
> Christoph Haas wrote:
> > - Please close the WNPP bug 273204 which you opened yourself
> >   one and a half year ago.
>
> Ok, i'll close it.
>
> I assumed though that ITP should be closed after that the package was
> become ready and was appeared in the pool. I'm i wrong?

Please use the debian/changelog to close it.
http://www.de.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-upload-bugfix

> > - The copyright file should contain the years of copyright.
>
> Ok, i'll fix that.
>
> BTW i see many copyright files in Debian packages whitout (c)year lines.
> Is it actually a violation?

http://groups.google.de/group/linux.debian.announce.devel/browse_frm/thread/ee00935883c7bec2/5326ec35388edb3c

> > - There has been long time no change. Did you contact the upstream
> >   to make sure the software is still maintained?
>
> This piece of software is developed and distributed by dsbl.org project
> which acts as great free network service. I have no doubt, the software
> is pretty _useful_ as one of methods to open proxy/relay reliable
> testing and it's included in FreeBSD ports collection. Should i care if
> it wasn't updated for 2 years?

The main concern is that security bugs may come up. And in that case the 
upstream should jump in quickly and help to fix it. If the upstream 
software became unmaintained then the situation may lead to the removal of 
the package.

It's okay if the last update is a year ago. I just wanted to make sure you 
talked to the upstream at least once.

> > - Installing the README file doesn't seem to add any value for the
> >   end-user.
>
> Ok, i'll remove it.
>
> I assumed that README.Debian is the right place to point on specific
> build options. Debian includes needed development libraries, but the
> easiest way to debianize this software was just to link it against the
> supplied versions. Should i emphasize that somewhere?

The README.Debian provides additional information for end users on how to 
use the software. Say the package installs some binaries then the user 
should start by reading the README.Debian to understand how to use the 
package.

That README.Debian should not be used to tell how your package works 
internally or which options you used to build it. That's not relevant for 
the end user.

> > - The upstream tarball I just fetched from the web site has another
> >   md5 checksum than the orig.tar.gz you provide. How come?
> >   At a first "diff -r" glance the two files have many differences.
>
> $ md5sum dsbltesters_0.9.5.orig.tar.gz dsbl-testers-0.9.5.tar.gz
> 55285009d90914048df2f62f4c9525d8  dsbltesters_0.9.5.orig.tar.gz
> 55285009d90914048df2f62f4c9525d8  dsbl-testers-0.9.5.tar.gz
>
> For me, they are identical. Perhaps, you've downloaded by mistake
> dsbl-0.9.5.tar.gz which is server software.

You are right. My mistake. Awkward... :)

> > - The package is not lintian clean. Three issues there.
>
> Do you mean issues above or something other? I saw only one:
>
> $ lintian dsbltesters_0.9.5-1.dsc
> W: dsbltesters source: out-of-date-standards-version 3.6.1

I got these messages:

W: dsbltesters source: out-of-date-standards-version 3.6.1
E: dsbltesters: file-in-etc-not-marked-as-conffile /etc/dsbl.conf
W: dsbltesters: old-fsf-address-in-copyright-file

> Could you be so kind to check dsbltesters_0.9.5-2?

Just did. Still not lintian clean. Did you use a current "Sid" (unstable) 
installation to build the package? These are the remaning messages:

E: dsbltesters: file-in-etc-not-marked-as-conffile /etc/dsbl.conf
W: dsbltesters: old-fsf-address-in-copyright-file

Please make sure your package are lintian-clean.

 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: pyme

[Christoph Haas]

On Friday 27 January 2006 17:31, Arnaud Fontaine wrote:
> I need a sponsor for pyme package. My previous sponsor doesn't have the
> time currently to review the package i have made.

So far so good. Just some thoughts:

- Wouldn't it be better if the (source) package were called
  "python-pyme" instead of just "pyme"?
- The README.Debian doesn't add much value.  You mention
  python-pyme-doc in the "Suggests:" anyway. On the other hand
  a pointer to the examples might be useful.
- I'm not a CDBS guru but you list debian/README.Debian in
  the debian/docs file and also in the rules file. Isn't that
  redundant?
- In case you still want to list the README.Debian in debian/docs:
  you use a general "debian/docs" but also a more specific file
  "debian/python-pyme-doc.docs". I personally prefer to use only
  specific files to make clear which packages has to install which
  files.
- What worse: the package doesn't build in a pbuilder environment.
  "sh: gpgme-config: command not found" probably means that you
  missed a dependency.
- There is already a package called "python-gnupginterface" in Debian.
  In what way is PyMe different?

Since I couldn't build the package I haven't lintian checked it.
Could you take a look at it again? Thanks.

Kindly
 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: proxycheck -- link

[Christoph Haas]

Hi, Al...

On Friday 27 January 2006 20:20, Al Nikolov wrote:
> http://mentors.debian.net/debian/pool/main/p/proxycheck/

Found it. Checked it. Uploaded it.

Minor thoughts on the package:

- Please don't change past entries in the changelog even though
  I understand that you wanted to correct the line wrapping.
- Consider using "dpatch" for changing the upstream sources.
  You may find it easier to keep or remove patches when the next
  upstream version is released.
- I assume you have sent your patches upstream already.

Kindly
 Christoph
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: RFS: proxycheck -- link

[Christoph Haas]

On Saturday 28 January 2006 18:57, Thomas Viehmann wrote:
> Christoph Haas wrote:
> > - Please don't change past entries in the changelog even though
> >   I understand that you wanted to correct the line wrapping.
>
> Correcting factual mistakes or typos in the changelog seems to be
> accepted practice and I can't really see the harm of doing so with the
> line wrapping and such as long as all information is preserved...

That was more a general hint because I have already seen major changes in 
the changelog in some sponsored packages. Changing line wraps surely is no 
problem.

> > - Consider using "dpatch" for changing the upstream sources.
> >   You may find it easier to keep or remove patches when the next
> >   upstream version is released.
>
> It's good to know the option, but for minor changes that are likely to
> either be kept or accepted upstream, I've found it easier to use the
> original patch. I don't think you (Christoph) wanted to require it -
> otherwise you wouldn't have uploaded the package - but for the casual
> reader, it could be even clearer that this is a matter of preference and
> consideration on a case by case basis.

In case I accidentally sounded like I wanted to enforce anything: that was 
just a hint for Al since many (new) maintainers don't know dpatch and 
happily patch around the upstream's source and sometimes start to get lost 
in it. In such a (rather simple) package it doesn't make much of a 
difference.

Since I already uploaded the package I'm perfectly happy with it. Just 
wanted to give some hints that may perhaps be useful or just be ignored. 
In my first packages I hadn't used dpatch because nobody told me how to 
keep track of multiple patches and still keep my sanity. So I'm used to 
sometimes just give a hint even though nobody is listening.

Hoping that I could convince you that I'm not just an egocentric sadistic 
sponsoree torturer...

 Christoph ;)
-- 
Never trust a system administrator who wears a tie and suit.


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

Re: scanners for debian

[Christoph Haas]

On Thursday 23 February 2006 14:25, Servio Benitez wrote:
> I wanted to install at least two scanners for debian,apart from Nmap
> and i dont know which ones are goods and where i can get them.

Please ask on debian-user@lists.debian.org - thanks.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Doing a proper package split (cream)

[Christoph Haas]

Evening...

one thing I never really dealt with before are package splits. And since I 
couldn't find any clear policy on how to define the dependencies properly 
I'd like to get a second (and even third) opinion on this.

'cream' is a package with a lot of documentation. Until version 0.33 I had 
all the files in a single package. Now in 0.34 I want to split off the 
documentation so i have cream (main) and cream-doc (documentation).

My debian/control file of the new 0.34 package now looks roughly like this:

shnip--
Source: cream
Section: editors
Priority: optional
Maintainer: Christoph Haas <[EMAIL PROTECTED]>
Build-Depends-Indep: debhelper (>= 4.0.0)
Standards-Version: 3.6.2

Package: cream
Architecture: all
Depends: gvim, ucf
Suggests: cream-doc
Description: ...
 ...

Package: cream-doc
Architecture: all
Conflicts: cream(<<0.34)
Replaces: cream(<<0.34)
Recommends: cream
Description: ...
 ...
--shnup--

Without the Conflicts+Replaces in the cream-doc part users could install 
the new cream-doc (0.34) package and get conflicts because the same 
documentation-related files were formerly in the cream (0.33) package.
So I needed to make sure it gets removed before cream-doc (0.34) is 
installed.

Now when I install cream-doc (0.34) it looks like this:

$> dpkg -i cream-doc_0.34-2_all.deb
Selecting previously deselected package cream-doc.
dpkg: considering removing cream in favour of cream-doc ...
dpkg: yes, will remove cream in favour of cream-doc.
(Reading database ... 173915 files and directories currently installed.)
Unpacking cream-doc (from cream-doc_0.34-2_all.deb) ...
Setting up cream-doc (0.34-2) ...

Then the situation would look like this:

ic  cream  0.33.1-1
ii  cream-doc  0.34-2 

The old cream package is still installed (shouldn't it be "rc"?). While 
this is sane for APT it's a bit weird for the user because the 
documentation now doesn't fit the main package any more. I would like to 
install both new versions when either new package is installed.

What would you propose to do to have a proper upgrade path here? Remove 
'cream' in the 'postinst' maintainer script of 'cream-doc' if a 'cream' 
version of <<0.34 was installed? I don't want to make it even dirtier than 
it's now.

Thanks in advance.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: Doing a proper package split (cream)

[Christoph Haas]

Justin, thanks for your reply.

On Friday 10 March 2006 16:39, Justin Pryzby wrote:
> You probably want to make a new dummy package, one which I guess will
> have just copyright and changelog files, will be named "cream", and
> will have Depends: cream-doc, cream-program.  This will cause existing
> cream installations to have the same things included in them, though
> by different packages.

Yes, that case looks simpler:

cream (split)---> cream-main + cream-doc

In this case 'cream' would just become a dummy package. To my eyes that's 
still a bit ugly. If possible I'd wish for:

cream (split)---> cream + cream-doc

> Also, if cream had conffiles which changed across the upgrade, you
> would have to deal specially with them; "transferring ownership of
> conffiles", see my bugs #345112 and friends..

True. If the latter alternative would somehow work I wouldn't need to 
transfer the conffiles to a new package because it would remain in 
'cream'.

> In any case, you can and should always drop the upgrade foo after the
> next stable release.

Another issue I would like to avoid because I'll surely forget to remove 
that cruft. :) A "good once and for all" solution would make me happier.
But it actually looks like the solution you proposed is more common.

I wonder if my proposal causes any bad things to happen. It would be very 
unlikely that a user just installed the new 'cream-doc' package without 
upgrading the 'cream' package. And since 'cream' and 'cream-doc' wouldn't 
have any hard dependencies (like "Depends:" instead of "Suggests:") in the 
future either there may well be situations where the documentation package 
could have another version than the main package.

Doubtingly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: Doing a proper package split (cream)

[Christoph Haas]

Am Freitag, 10. März 2006 18:00 schrieb Simon Richter:
> Christoph Haas wrote:
> > 'cream' is a package with a lot of documentation. Until version 0.33 I
> > had all the files in a single package. Now in 0.34 I want to split off
> > the documentation so i have cream (main) and cream-doc
> > (documentation).
>
> That only makes sense when the documentation is large and the package
> has arch-specific components. Since both packages are arch:all, at least
> in the control file you posted, I doubt it is worth it.

Sure, the architecture-dependency is one aspect. But the size of the 
package is what mattered to me:

512552 cream_0.34-2_all.deb
637582 cream-doc_0.34-2_all.deb

So separating the documentation would save 640 KB for a "normal 
installation". I thought it would be worth it.

> > Conflicts: cream(<<0.34)
> > Replaces: cream(<<0.34)
>
> If there is no functional conflict, you can omit the Conflicts: here, as
> you are merely replacing files in the old version. This would, however,
> allow a situation where the new docs and the old programs are installed.

You are right. But isn't that true for a number of other split packages, 
too?

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All

Re: Doing a proper package split (cream)

[Christoph Haas]

Am Freitag, 10. März 2006 20:36 schrieb Adeodato Simó:
>   (uhm, I was replying to this, but I see that the split is already in
>   the archive.

I decided for the split already and then was pointed at problems with 
0.34-1 so I was rather looking for a half-decent solution now. Re-joining 
the package might be sane, too. I could just add a "Replaces: cream-doc" 
and forget about the split.

>   Executive summary: please remove the conflicts; I'd 
>   personally not split the package, but is your call; current status
>   good, except for the conflicts.)

Okay.

>   Following up to Simon's considerations about size and arch:all
>   packages, let's peek at the debs:
>
> Package: cream
> Version: 0.33.1-1
> Installed-Size: 2904
>
> Package: cream
> Version: 0.34-2
> Installed-Size: 2380
>
> Package: cream-doc
> Version: 0.34-2
> Installed-Size: 884

I incorrectly considered the sizes of the binary package files instead of 
the actual installed-size. This makes the split even less useful. Rats.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All

Re: Take over an ITP in absence of an answer from the bug owner

[Christoph Haas]

On Monday 13 March 2006 20:19, Julien Valroff wrote:
> I am very interested in taking over fast-user-switch-applet package
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304763)
>
> I don't own the ITP which is almost one year old, and the owner hasn't
> (yet) answered my e-mail.

I don't think that this is handled clearly in the policy. I personally 
would allow the original ITP submitter 1-2 weeks to react. If you don't 
get any reply just change the owner to yourself and upload it. You could 
already start to look for a sponsor (RFS to this mailing list).

Usually I'm pretty careful with package cleptomania. But there are so many 
ITPs that are long dead and block other people's attempt to introduce the 
package to Debian.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: libgpiv

[Christoph Haas]

Hi, Gerber...

On Monday 13 March 2006 21:10, Gerber van der Graaf wrote:
> I just uploaded a repaired package to the debian-mentors repository
> after I got some comments from the previous one. The packages are linda
> and lintian error free. Lintian issued two warning messages:
> "source: package-uses-deprecated-debhelper-compat-version 3"
> "package-name-doesnt-match-sonames libgpiv2". I don't know what these
> warnings mean and if they're important.

Kind of. "debhelper" delivers dh_install and other dh_* tools that you use 
in your debian/rules file. Most packages still depend on version 4 of 
debhelper. A while ago debhelper 5 has been released. You are using the 
version 3 which is deprecated. Bump up the version to 5 and test if your 
build still works. Hint: DH_COMPAT in debian/rules.

"zless /usr/share/doc/debhelper/changelog.gz" gives you detailed 
information on the changes to "debhelper". Or "man 7 debhelper".

> As the previous package was not uploaded to the formal Debian repository
> by a DD, I did not increase the package number. So, its still an initial
> release which also closes the ITP BUG I reported against this package.
> Is this correct behaviour?

It's okay. But your debian/changelog file appears to have a superfluous 
linebreak and a missing blank line. Try "cat" on it to see what I mean.

> I perfectly understand that there is very little chance that there is a
> DD who might be interested in this software.

Not necessarily. I sometimes sponsor software that I don't use myself. For 
me it's more important that I can verify that your package works (e.g. I'm 
not a "cdbs" guru and prefer "debhelper"-based packages like yours). 
Libraries are a bit more complicated unless I have an application that 
uses it which I can click and torture and test.

> Even though, I kindly ask whether a DD will sponsor the package.

Sure. But please tell us more about the package. See other RFS reports as a 
template. I didn't notice your previous posts here about libgpiv so at 
least I have missed it.

> Though I am the developer of the software as well,
> the packaging has been kept separated from the upstream source packages
> available at http://gpiv.sourceforge.net

Very good. Shipping a debian/ directory with your distribution leads to 
more problems most of the time. The only location where you need it is for 
the debian package. And users can get that from the Debian repositories. 
So no need to include it.

> Description: Library for Particle Image Velocimetry (PIV)
>  This library contains functions for evaluating images from a fluid
>  flow by means of Particle Image Velocimetry (PIV), resulting into a
>  velocity field on a rectangular grid. It includes the core functions
>  for image acquiring, processing, interrogation, PIV data validation,
>  post-processing, input/output and memory allocation.
>
> Thanks a lot in forward,

Further notes:
- Why debian/Makefile? Where do you use it?
- Since you are the upstream author: why is gpiv.1 in debian and not
  generally installed by your software? It's probably not Debian-specific.
- Your debian/watch seems to be b0rked. Running "uscan" I get warnings
  and errors.
- My "pbuilder" fails to build the package:

checking for GPIV_UI_LIBS...
configure: error: The pkg-config script could not be found or is too old.  
Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

Anyway, thanks for your contribution.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: gimp-resynthesizer - Gimp plugin for texture synthesis

[Christoph Haas]

Hi, Bryan...

On Wed, Mar 22, 2006 at 08:08:44PM -0500, Bryan Donlan wrote:
> I have created a package for the gimp resynthesizer plugin, as
> requested in RFP-now-ITP #355685, and would like to request a sponsor
> for it. The upstream homepage is
> http://www.logarithmic.net/pfh/resynthesizer , and packages (binary
> and source) are at
> http://bdonlan.googlepages.com/resynthesizerpackages
> 
> Description: Gimp plugin for texture synthesis
>  This gimp plugin takes samples of textures, and synthesizes larger textures
>  from them.  It can be used to extend textures (including making tileable
>  textures), removing objects from textures, and making themed images.

I have just looked at your package. Some thoughts:

- please add the year(s) of copyright to debian/copyright
- shouldn't the binary package depend on gimp? (debian/control)

Other than that I'd be willing to upload your package.

Kind regards
 Christoph Haas
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: libhtml-fromtext-perl

[Christoph Haas]

Hi, Francesco...

On Wed, Mar 29, 2006 at 09:28:09PM +0200, Francesco Cecconi wrote:
> I'm looking a sponsor for adopt libhtml-fromtext-perl!

I'm willing to sponsor it. Just one issue: it appears like the file
/usr/share/doc/libhtml-fromtext-perl/README.gz contains the same
information as the man page HTML::FromText. Would you drop it?

Kind regards
 Christoph Haas
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: libhtml-fromtext-perl

[Christoph Haas]

On Fri, Mar 31, 2006 at 11:08:15PM +0200, Francesco Cecconi wrote:
> On Fri, 2006-03-31 at 21:47 +0200, Christoph Haas wrote:
> > I'm willing to sponsor it. Just one issue: it appears like the file
> > /usr/share/doc/libhtml-fromtext-perl/README.gz contains the same
> > information as the man page HTML::FromText. Would you drop it?
> 
> I have updated the sources package with the changes that you advised to
> me!!

Very good. Your package is now uploaded to Debian. Thanks for your
contribution.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: RFS: gimp-resynthesizer - Gimp plugin for texture synthesis

[Christoph Haas]

On Fri, Mar 31, 2006 at 02:31:41PM -0800, Bryan Donlan wrote:
> Thanks for offering to upload the package :)
> 
> I've made the changes you asked, as well as a few other changes I
> spotted at the time; specifically, I've altered it to pass CFLAGS
> properly from debian/rules to the makefile, and removed the +debian
> from my email (I've decided it's not necessary to have such
> fine-grained filtering, yet...). Source and binary can again be found
> at http://bdonlan.googlepages.com/resynthesizerpackages .

Good.

> I tried to upload to mentors.debian.net as well, using dput, but I got
> a strange problem:
> [...]
> gimp-resynthesizer_0.14-1.dsc 100%  623 0.6KB/s   00:00
> gimp-resynthesizer_0.14.orig.tar.gz   100%   18KB  17.8KB/s   00:00
> gimp-resynthesizer_0.14-1.diff.gz 100% 2045 2.0KB/s   00:00
> gimp-resynthesizer_0.14-1_i386.deb100%   22KB  21.7KB/s   00:00
> gimp-resynthesizer_0.14-1_i386.changes100% 1075 1.1KB/s   00:00
> (here it paused until I hit enter)

A bit strange.

> scp: protocol error: unexpected 
> Warning: The execution of '/usr/bin/ssh' as
>   'ssh [EMAIL PROTECTED] chmod 0644
> ~/gimp-resynthesizer_0.14-1.dsc ~/gimp-resynthesizer_0.14.orig.tar.gz
> ~/gimp-resynthesizer_0.14-1.diff.gz
> ~/gimp-resynthesizer_0.14-1_i386.deb
> ~/gimp-resynthesizer_0.14-1_i386.changes'
>   returned a nonzero exit code.
> Error while fixing permission.

That's okay. Changing the permissions at mentors.debian.net is currently
not supported. That will change soon.

> I chmodded the original files to 0644 and retried the upload; that
> time it appeared to succeed, but trying to download the orig.tar.gz
> from 
> http://mentors.debian.net/debian/pool/main/g/gimp-resynthesizer/gimp-resynthesizer_0.14.orig.tar.gz
> gives a 403.

Strange bug. I'll investigate.

> If the permissions on the file aren't corrected by a cronjob or
> something in a few hours I'll mail their support address I guess.

No need to - the mail would end up in my mailbox anyway. ;) Soon
mentors.debian.net will be relaunched and hopefully such magic things will
just vanish.

Regarding your package... it looks sane now. I have uploaded it. Thanks for
your package. And let me know if you have updates.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: fullquottel, mailtextbody, mimetic

[Christoph Haas]

On Sat, Apr 08, 2006 at 09:08:38PM +0200, gregor herrmann wrote:
> * fullquottel
> fullquottel is in testing and unstable, the new version fixes a
> wishlist bug (#356375), the only change in the package is the
> description.

Uploaded.

> * mimetic
> mimetic was already in the new queue but it was rejected due to
> inappropriate names of the binary packages. The new version fixes
> these names and is identical otherwise (ITP: #313088).

Uploaded. Although a newer version (0.9.1) seems to available already.
Yours is still 0.8.9.

Btw, is there a reason why you repacked the upstream tarball? The contents
are identical to the archive from the upstream's web page - just that you
changed the directory name from mimetic-0.8.9 to mimetic-0.8.9.orig.

> * mailtextbody
> mailtextbody is in the new queue and waiting for mimetic which it
> depends on. The new revision changes the dependencies on mimetic to
> mimetic's new binary packages names and is identical otherwise
> (ITP: #347828).

Let's wait until mimetic gets accepted before you have this package
uploaded. I assume it will not build correctly until "mimetic" is accepted.
Otherwise the package looks good.

Btw, I just wonder why you include the "README". It doesn't seem to add
much value. Consider removing it in the next revision.

Kind regards
 Christoph Haas
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS/RFC: sitebar -- A web based bookmark manager written in PHP

[Christoph Haas]

Kevin,

On Fri, Apr 14, 2006 at 08:21:30PM -0400, Kevin Coyner wrote:
> I am looking for comments on and a sponsor for 'sitebar'.  I like
> this program because I always have access to my bookmarks no matter
> where I am or whose machine I'm on (web access).

Time to get rid of my ol'bookmarks installation. :)

Your package looks sane. So I uploaded it. Just a minor issue that might as
well be my fault: when purging the package I got asked for the password I
want to use to administer sitebar in the future. Is there a mixup of
debconf dialogs? Or is it just me?

Kind regards
 Christoph Haas
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


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

Re: RFS: tcsh

[Christoph Haas]

On Sun, Apr 16, 2006 at 07:08:23PM +0200, Franz Pletz wrote:
> after finally being able to adopt tcsh (see the wnpp-bug) I'm searching
> for a sponsor to upload my new version. Basically, I only fixed a minor
> bug did some cleanups, the biggest being the scheduled removal of
> tcsh-kanji.

Well done. Uploaded.

Kind regards
 Christoph Haas
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: Slatec

[Christoph Haas]

Hello, Muammar...

On Sun, May 14, 2006 at 12:38:43PM -0400, Muammar Wadih El Khatib Rodriguez 
wrote:
> My name is Muammar El Khatib, I'm a chemistry student and I'm doing my
> thesis on nonlinear optic (quantum chemistry).
> 
> There is a package called slatec and is up for adoption. I'm
> interested to maintain this package. I talked with the developer who
> was maintaining slatec, and he told me that I had to  find a sponsor.

That's right. There is nothing wrong with maintaining a package without
being a 'Debian developer'. You just need a "sponsor" who is a developer
who uploads the package on your behalf. Depending on the reliability of the
sponsor this might be easy. Finding a Debian developer who is personally
interested in the package might help.

> I'm reading all the documentation of debian, and one step is write to
> debian-mentors.

I would suggest you first follow the procedure described in
http://www.de.debian.org/devel/wnpp/ (search the page for 'ITA') to show
everybody you are now working on the package. Find the pseudo bug report
dealing with the request for adoption at http://bugs.debian.org/263050

As soon as you have a working package online (perhaps with the current bugs
already fixed) you should post a RFS (request for sponsorship) here telling
everybody where your package can be found. If you don't have any space on
the web you can as well use mentors.debian.net. Developers will then
hopefully contact you to check the package and arrange the upload.

Good luck and thanks for your contribution.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: [RFS] wormux - A funny fight game on 2D maps

[Christoph Haas]

On Wed, May 17, 2006 at 04:35:31PM +0200, artefact wrote:
 Do you have a realname?--^

> I am looking for a sponsor for the wormux game package (ITP #352064).

Package looks good. Minor suggestions:

- use wormux.install and wormux-data.install files instead of
  "dh_install -pwormux" and "dh_install -pwormux-data".
  Matter of taste though.
- check which dh_* calls you don't need in the binary-common target
  of debian/rules (e.g. dh_installexamples is probably not needed)
- did you send your self-made man page upstream already to be included
  in the next release?
- what is the purpose of wormux.xml?
- my pbuilder chokes on the autogen.sh - could you take a look?
  (it appears like the file is not executable when needed)
- check the Standards version (lintian warning)
- linda warning:
  wormux; The font wormux-0.7.1/data/font/DejaVuSans.ttf in package
  ttf-dejavu is considered to be a duplicate.

Other than that the game is working well and I'd be willing to sponsor
it.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: [RFS] wormux - A funny fight game on 2D maps

[Christoph Haas]

On Thu, May 18, 2006 at 10:15:25AM +0300, Eddy Petrişor wrote:
> On 5/17/06, Christoph Haas <[EMAIL PROTECTED]> wrote:
> >- check the Standards version (lintian warning)
> >- linda warning:
> >  wormux; The font wormux-0.7.1/data/font/DejaVuSans.ttf in package
> >  ttf-dejavu is considered to be a duplicate.
> 
> Isn't that _only_ in the source package?

Oh, indeed, you are right.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: [RFS] wormux - A funny fight game on 2D maps

[Christoph Haas]

On Thu, May 18, 2006 at 10:57:14AM +0200, artefact wrote:

> Yes I'm Jean Parpaillon. In the package description and changelog, there
> is my real name.

Perhaps you could consider using that when sending mails.

> Le 17.05.2006 22:46, Christoph Haas a écrit :
> > - check the Standards version (lintian warning)
> >   
> As I don't use more recent features, it allows people to build the
> package for older distros.

The Standards version documents which version of the Debian Policy you
followed when creating the package. It's not a dependency that prevents
backporting.

> > - linda warning:
> >   wormux; The font wormux-0.7.1/data/font/DejaVuSans.ttf in package
> >   ttf-dejavu is considered to be a duplicate.
> >   
> It's only in the source package.

Agreed.

> I'm uploading the new packages with changes.

Great, let me know.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: Slatec

[Christoph Haas]

Hi, Muammar...

On Fri, May 19, 2006 at 11:15:30PM -0400, Muammar Wadih El Khatib Rodriguez 
wrote:
> >I would suggest you first follow the procedure described in
> >http://www.de.debian.org/devel/wnpp/ (search the page for 'ITA') to show
> >everybody you are now working on the package. Find the pseudo bug report
> >dealing with the request for adoption at http://bugs.debian.org/263050
> 
> I read documentation. I'll describe the steps I think should follow:
> 
> 1) Install reportbug.
> 2) What sort of request is this? ( Using 'My Name <[EMAIL PROTECTED]>'
> A: RFA

Careful. Not RFA. See http://www.de.debian.org/devel/wnpp/#l2
An RFA means that you were the former maintainer and that you want
someone else to become the new maintainer.

> 5) Next step, Removing entries. I should retitle its bug to replace
> 'RFA' with 'ITA' (I don't know how can i do it) [0]
>
> [0] I read http://www.de.debian.org/Bugs/server-control.en.html and I
> think I should use Debian bug tracking system to submit required
> information (replace RFA with ITA) I'm not sure but, should I use some
> Commands like submitter, retitle or owner?

See http://www.debian.org/Bugs/server-control.html and search for
"retitle". If [EMAIL PROTECTED] receives mails then it will parse
it line by line figuring out what to do. "retitle" is one of those
commands that 'control' can execute.

You can even use the 'bts' command from the command line (contained in
the package 'devscripts') so easily send commands to the 'control'
service.

> Please, excuse me. I want to make the things of the best possible way.

Don't worry. Debian has some very sophisticated tools. You can't learn
them all on one day. :)

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: RFS: FSlint - File System lint

[Christoph Haas]

On Mon, May 22, 2006 at 09:48:59AM +0100, Pádraig Brady wrote:
> I sent an RFS for FSlint 3 months ago.
> Since then, I have released 2.15 with fixes for lots
> of debian packaging comments from Justin Pryzby.
> 
> So is it ready for inclusion?
> 
> homepage: http://www.pixelbeat.org/fslint/
> source: http://www.pixelbeat.org/fslint/FSlint-2.15.tar.gz
> deb: http://www.pixelbeat.org/fslint/fslint_2.15-1_all.deb

Where can your source package be found?

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: RFS: FSlint - File System lint

[Christoph Haas]

On Mon, May 22, 2006 at 04:15:09PM +0100, Pádraig Brady wrote:
> Justin Pryzby wrote:
> >>>On Mon, May 22, 2006 at 12:06:33PM +0100, P?draig Brady wrote:
> >>As far as I can see you want me to provide:
> >>
> >>fslint_2.15-1.dsc
> >>fslint_2.15-1.orig.tar.gz
> >>fslint_2.15-1.diff.gz
> > 
> > Yea, this is the "source package".  You could have an empty .diff.gz
> 
> Done. The following "source package" was built with:
> dpkg-source -b fslint-2.15 fslint_2.15.orig.tar.gz
> 
> http://www.pixelbeat.org/fslint/debian/

Much better! Thanks.

> I'm confused as to why it didn't ask me to sign it.

Depends on how you built the package. Usually I run "debuild" which will
try to sign the package afterwards. Signing the package is important if
the package gets uploaded to Debian because you need a Debian
developer's signature on the package to be accepted in the official
repositories - just a security measure.

However the package is not yet in perfect shape. Run "lintian" on the
final package (lintian -i *deb) to see some obvious problems.

Just in case there is a misunderstanding. You usually don't need to care
for a Debian package. It's okay to have someone who is familiar with
Debian to deal with all the policy and procedures. Here I assume that
you are personally interested in maintaining the Debian package. Just to
let you know there are surely volunteers in the Debian project so you
can concentrate on developing the actual (upstream) software.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: RFS: FSlint - File System lint

[Christoph Haas]

On Tue, May 23, 2006 at 10:07:04AM +0100, Pádraig Brady wrote:
> Christoph Haas wrote:
> > On Mon, May 22, 2006 at 04:15:09PM +0100, Pádraig Brady wrote:
> cool, So I'll need to register my signature as a Debian Developer.
> I'll figure out how to do this thanks.

Uhm, you would need to become a Debian developer to be able to upload.
That means you would need to go through the so called "new maintainers
process" - see http://nm.debian.org. Although you are surely free to do
that I'm not sure whether you want to invest the time (~6 months).

If you don't want to become a Debian developer or don't find a Debian
developer who is willing to maintain the package you could use
"sponsoring". Anyone (or you) maintains the package and then looks for a
Debian developer to upload the package on their behalf. That process is
called "sponsoring". You will still be listed as the maintainer of the
package. Just that a Debian developer checks your package prior to
uploading it. If you find a reliable sponsor that is hardly a barrier.

> > However the package is not yet in perfect shape. Run "lintian" on the
> > final package (lintian -i *deb) to see some obvious problems.
> 
> Right, I'll lintian it and also read up on debian packaging policies.

Be patient. The policy is large. :)

> > Just in case there is a misunderstanding. You usually don't need to care
> > for a Debian package. It's okay to have someone who is familiar with
> > Debian to deal with all the policy and procedures. Here I assume that
> > you are personally interested in maintaining the Debian package. Just to
> > let you know there are surely volunteers in the Debian project so you
> > can concentrate on developing the actual (upstream) software.
> 
> Sure. It would be better if someone stepped up,
> but in my experience I think it will be faster if I do everything myself.

I'll take a close look at your software. I can imagine that I'll become
the Debian maintainer of it unless you like to do that yourself. That
way you don't need to worry about the Debian-specific issues.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: [RFS] wormux - A funny fight game on 2D maps

[Christoph Haas]

On Sat, May 27, 2006 at 02:42:57PM +0200, Jean Parpaillon wrote:
> I've heavily updated the package (both package and upstream, so the
> version is now 0.7.2-1).
> - I use wormux[-data].install and wormux[-data].dirs files.
> - Manpage is in upstream. But manpage is in nroff format as I don't know
> autotools enough to handle manpage transformation with it...
> - Updated the Debian policy version
> - Check unused dh_* calls.
> 
> The package can be downloaded from
> http://mentors.debian.net/debian/pool/main/w/wormux/
> 
> Could you have a look at it ?

Sure. Lintian is not quite happy about the package though:

W: wormux source: changelog-should-mention-nmu
-> your name in debian/control and debian/changelog is different

W: wormux source: source-nmu-has-incorrect-version-number 0.7.2-1
-> same reason

W: wormux: binary-without-manpage wormux
-> that's against policy. Please provide a minimal manpage.

E: wormux: menu-icon-too-big /usr/share/pixmaps/wormux-32.xpm: 32x33 > 32x32
-> self explaining

E: wormux: unstripped-binary-or-object ./usr/games/wormux
-> you don't run dh_strip in debian/rules

Kindly
 Christoph


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

Re: RFS - two icon sets for kde - kde-icons-gorilla and kde-icons-korilla

[Christoph Haas]

On Sun, May 28, 2006 at 07:20:33AM +, Sune Vuorela wrote:
> On 2006-05-01, Sune Vuorela <[EMAIL PROTECTED]> wrote:
> > On 2006-04-22, Sune Vuorela <[EMAIL PROTECTED]> wrote:
> >> I have a couple of ITPs where I finally got the two packages in shape to
> >> close 
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348101 and
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348103
> >>
> >> They are quite similar, it is only approx. the name that differs.
> >> And the packaging is quite easy to overview.
> >>
> >> It is both cool icon themes bringing monkey spirit to your desktop!
> >>
> >> And they are located here:
> >> http://mirror.pusling.com/kgorilla
> >>
> >> /Sune
> >
> > No comments?
> > Noone interested ?
> 
> Still noone ?

Just checking kde-icons-korilla. Lintian is right:

E: kde-icons-korilla; The font
/usr/share/icons/Korilla/extras/truetypefonts/comic.ttf is considered to
be non-free.
E: kde-icons-korilla; The font
/usr/share/icons/Korilla/extras/truetypefonts/comicbd.ttf is considered
to be non-free.

I find subtle amounts of my favorite arch enemy company in there. Or
does M$ distribute those as GPL nowadays? :)

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: [RFS] ajaxterm: Web based terminal written in python

[Christoph Haas]

On Fri, May 26, 2006 at 10:42:14AM +0200, Julien Valroff wrote:
> I am looking for a sponsor for ajaxterm:
> * Package name: ajaxterm
>   Version : 0.6
>   Upstream Author : Antony Lesuisse <[EMAIL PROTECTED]>
> * URL : http://antony.lesuisse.org/qweb/trac/wiki/AjaxTerm
> * License : Public Domain (with some exceptions)
>   Programming Lang: Python
>   Description : web based terminal written in python
> 
> ajaxterm is a web based terminal written in python and some AJAX javascript 
> for client side.
> It can use almost any web browser and even works through firewalls.
> 
> ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366285
> 
> Signed source and i386 binary packages can be pulled from 
> http://kirya.net/~julien/pkg-ajaxterm/
> 
> The package is lintian/linda error and warning free.
> 
> Could someone review and upload the package if it appears to be ok?

Just checked the package. I wonder why the orig.tar.gz that you provide
in your repository is different from the tarball available from the
upstream's web site. Can you verify that?

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: [RFS] ajaxterm: Web based terminal written in python

[Christoph Haas]

On Sun, May 28, 2006 at 02:32:34PM +0200, Julien Valroff wrote:
> Le dimanche 28 mai 2006 à 14:24 +0200, Christoph Haas a écrit :
> > Just checked the package. I wonder why the orig.tar.gz that you
> > provide
> > in your repository is different from the tarball available from the
> > upstream's web site. Can you verify that? 
> The upstream author has decided to apply the patches I have submitted
> but told me he was too lazy to change the version number. I have asked
> him to do this, and am sure he will accept.

Ah, okay. Please have the upstream increase the version number on every
change. It's confusing to have two files with the same version number
containing different files. A release is a release is a release. :)

Other than that: package is good for me. Uploaded. Thanks.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature

Re: RFS: kwin-style-crystal - transparant window decoration

[Christoph Haas]

On Sun, May 28, 2006 at 07:27:15AM +, Sune Vuorela wrote:
> I have a package ready for kwin-style-crystal.
> 
> ITP: 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364360
> 
> Source: kwin-style-crystal
> Section: kde
> Priority: optional
> Maintainer: Sune Vuorela <[EMAIL PROTECTED]>
> Build-Depends: debhelper (>= 4.0.0), autotools-dev, kdebase-dev
> Standards-Version: 3.7.2
> 
> Package: kwin-style-crystal
> Architecture: any
> Conflicts: crystal
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: semi transparant window decoration for KDE
>  Crystal offers you pseudo transparent titlebar, buttons and borders
>  transparent, so you can see more of your lovely background image
>  Transparancy and buttons can be costumized to match your wishes.
>  Offers rounded corners as well
>  .
>  And it is of course nice to look at. Upstream says:
>  "- Don't forget to breathe, while drooling."
> 
> And package is located at http://mirror.pusling.com/crystal-rfs

Looks good. The package at least. :) Uploaded as usual.

Kindly
 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


signature.asc
Description: Digital signature