Re: RFS: line6-usb

[Thijs Kinkhorst]

Hi Jelmer,

On Saturday 19 January 2008 18:25, Jelmer Vernooij wrote:
> I am looking for a sponsor for my package "line6-usb".

The package looks good, I've uploaded it. Good work!


Thijs


pgp0zj8VBqUoo.pgp
Description: PGP signature

Re: RFS: hashalot (updated)

[Thijs Kinkhorst]

On Thursday 24 January 2008 04:40, Kapil Hari Paranjape wrote:
> > * Vcs-Svn and Vcs-Browser.
>
> Shouldn't the Vcs-Svn entry start with "svn:" instead of "http:"?

SVN can be run over a variety of protocols, next to svn including ssh and 
http(s). Which is an excellent feature if you ask me :-)


Thijs


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

Re: RFS: workbone - QA Upload with RC bugfix

[Thijs Kinkhorst]

On Sunday 3 February 2008 17:04, Barry deFreese wrote:
> I've made a QA upload for workbone that closes the RC bug if someone
> could review/upload I would appreciate it.
>
> http://mentors.debian.net/debian/pool/main/w/workbone/workbone_2.40-8.dsc

Thanks - I'm building this now and will upload it if all is well.


Thijs


pgp9YAxwADuGG.pgp
Description: PGP signature

Re: RFS: many packages

[Thijs Kinkhorst]

On Mon, February 4, 2008 14:21, José Luis Tallón wrote:
> Any of you with "upload powers" has some time left to sign and
> upload some packages?
>
> I have a little too many bugs waiting for an upload to be fixed,
> some of them quite old already. My usual sponsors have been much too busy
> as of lately. Anyone wants to volunteer?

If you have an update for up-imapproxy (which I see is one of 'yours'),
I'm willing to take a look at it. Send me an URL to the .dsc and I'll
check it out tonight.

It may help to actually list the packages you're looking for sponsors for.


Thijs


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

Re: Tests that take more than ten times build time.

[Thijs Kinkhorst]

On Wed, February 13, 2008 07:24, Charles Plessy wrote:
> Test time on arch (build time)
> 1h05 on sparc (3 min),
> 37 min on mipsel (2 min),
> 39 min on mips (3 min),
> 37 min on powerpc (2 min),
> 19 min on hppa (2 min),
> 6 min on amd64 (1 min)…
>
>
> Of course, if this is an exception, there is no need to argue. But in
> the Debian-Med packaging team, we have a few package whose tests are not
> yet enabled (bioperl, emboss,...); I do not know if it would be wise to do
> so systematically if they have a similar pattern of CPU usage...

I don't see a problem here. Tests catch errors, we have enough build time
available, so just run them. Time spent by users and developers when a
problem slips through is a lot more expensive than the buildd time to run
them.


Thijs


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

Re: Tests that take more than ten times build time.

[Thijs Kinkhorst]

On Wed, February 13, 2008 11:34, Charles Plessy wrote:
> And another one, who was never built in mips, is number 509 in the queue
> (glam2).
>
> For njplot, the waiting time is already 29 days. Therefore, I am a bit
> doubtful that we have enough build power. Would we have, my original
> question would of course be pointless.

That is a fundamental problem with that architecture, and should be fixed
by porters of that architecture.  If you can't handle the build times you
posted in your previous mail, they can definately not handle a significant
part of our archive. Which can be seen by the large queue for that arch.

Either they can keep up or they are not a release architecture. We should
not be sacrificing our package quality over some fringe arch, while all
others can keep up just fine.


Thijs


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

Re: RFS: some long-due updates

[Thijs Kinkhorst]

Hi J.L.,

On Sunday 9 March 2008 01:57, José Luis Tallón wrote:
> * imapproxy 1.2.6-1
> http://devel.adv-solutions.net/debian/pool/main/mail/imapproxy/up-imapproxy
>_1.2.6-1.dsc

I've taken a look at this one. It looks good in general, thanks for your work 
on this! There's just a couple of minor things I'd like to see resolved 
before uploading:

* You accidentally left out the -10.2 NMU changelog entry. Please reinclude it 
so that an accurate overview of package history remains. You can see this 
when you do a "debdiff" between the archive version of imapproxy (apt-get 
source) and your new version.

* The nl.po file seems to have completely vanished.

* I still get one lintian warning:
  W: up-imapproxy source: debian-rules-ignores-make-clean-error line 52

* Optionally, you could consider adding a Homepage: field to debian/control.


thanks,
Thijs


pgpSVJxaeX4xt.pgp
Description: PGP signature

Re: RFS: some long-due updates

[Thijs Kinkhorst]

On Sunday 9 March 2008 13:14, José Luis Tallón wrote:
> Indeed. "Make clean" (as shipped by upstream) always fails, and so the
> error needs to be ignored for the build to succeed --- what it does is
> however needed for a package build to complete.
>
> I don't normally like lintian overrides, but this feels like a good
> candidate for one.
> Meanwhile, I can try and fix the problem (non-trivial, already took a
> look) and submit it upstream. Delaying this upload just for this reason
> is not a good idea, given that we are approaching a release. I'd rather
> have the package fully tested  before inclusion.

I agree that this lintian warning is not top priority. It seems fair to leave 
this one for now and get the other fixes into the archive first. When that's 
done, we can take a look at this issue.

Let me know when new packages are available.

bye,
Thijs


pgpLgzExKibxU.pgp
Description: PGP signature

Re: RFS: tcpser (updated package) (try 5)

[Thijs Kinkhorst]

Hi Peter,

On Monday 10 March 2008 15:25, Peter Collingbourne wrote:
> I am looking for a sponsor for my updated package "tcpser".

I've uploaded this package for you now. Thanks for your work, and sorry that 
it took so long for someone to pick it up.

One point: upstream has included all .svn dirs in their tarball. While this 
isn't really a problem for a package of this size, you may want to alert them 
of that, because it wastes space and can be inconvenient for someone wanting 
to import it into Subversion. "svn export" is the key here.


Thijs


pgpnUToiL9t0b.pgp
Description: PGP signature

Re: RFS: some long-due updates

[Thijs Kinkhorst]

On Sunday 9 March 2008 13:14, José Luis Tallón wrote:
> > * You accidentally left out the -10.2 NMU changelog entry. Please
> > reinclude it so that an accurate overview of package history remains. You
> > can see this when you do a "debdiff" between the archive version of
> > imapproxy (apt-get source) and your new version.
> >  
>
> I prepared this update before 10.2 existed, and I overlook the fact that
> and additional NMU happened meanwhile.

Thanks for fixing this in the updated package, I've now uploaded it.

There was one problem during testing, that is that when the remote server has 
an IPv6 address but the local host does not have a globally routable IPv4 
address, then the connection fails and does not fall back to IPv4. Maybe you 
can pass this on to upstream.


thanks,
Thijs


pgpZ73DRu18hd.pgp
Description: PGP signature

Re: RFS: remaining packages

[Thijs Kinkhorst]

Hi J.L.,

On Tuesday 18 March 2008 02:53, José Luis Tallón wrote:
> - Couriergraph
> - Bindgraph

You got a sponsorship offer for these here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468134#15


Thijs


pgpxdDBKoKrLS.pgp
Description: PGP signature

Re: Version number in rules

[Thijs Kinkhorst]

On Tuesday 6 May 2008 12:45, Sveinung Kvilhaugsvik wrote:
> Is there a way to get the Debian version as a variable in the rules
> file? Is there a standard way to remove the .dsfg from it?

The following works well for me. I'm not sure but I don't believe
there's a more 'standard' way. To remove the .dfsg, add some
sed to this line.

DEB_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 -d ' 
')


cheers,
Thijs


pgp1wLV1gTfCt.pgp
Description: PGP signature

Re: Developer names within debian/changelog

[Thijs Kinkhorst]

On Monday 12 May 2008 06:17, Ben Finney wrote:
> In recent years I've seen entries in 'debian/changelog' that are
> broken up into "sections" by developer name. I'm referring to entries
> like this:

> The Policy section above is silent on this extension to the format,
> though I've seen Joey Hess discussing it in the past. I also know that
> 'debchange' can produce it, and 'dpkg' can consume it.

Indeed debchange generates the format. I'm not sure what you mean that dpkg 
can consume it. I know of no special meaning that dpkg assigns to those 
names, as far as I know it just treats them like any other changelog line. If 
there's any specification to it, I think it's best found in debchange's 
source code.


Thijs


pgpkdQIHmDtx9.pgp
Description: PGP signature

Re: Developer names within debian/changelog

[Thijs Kinkhorst]

On Tuesday 13 May 2008 13:24, Ben Finney wrote:
> I'm less interested in strictness in Policy than I am in finding out
> how this is *specified* for all consumers, rather than merely
> *implemented* in specific programs.

Maybe you can specify what problem you are trying to solve.


Thijs


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

Re: Developer names within debian/changelog

[Thijs Kinkhorst]

On Tuesday 13 May 2008 16:28, Ben Finney wrote:
> All the answers I've had so far indicate that there *is* no
> specification for developer names within a changelog entry, and that
> any format at all is allowed so long as the loose definition in Policy
> is followed.
>
> My issue with that is that it leads to this information being recorded
> in many, mutually-incompatible ways (which was, I believe, the
> existing state when the format was proposed), with no simple guide of
> how one *should* put the information in to be a good Debian citizen.

Ok, so to answer your question: the information was until now only ever 
intended to be human-readable. That debchange generated is is a convenience 
measure so you don't have to type it, not a way to encode it specifically.

Nearly all of the changelog is currently not machine-parsable, with notable 
exclusion of the first and last line (-- author), and the closes: statements. 
Everything else, like descriptions of files changed, bugs fixed, translations 
updated, release codenames and indeed maintainer names are there only for 
humans to read.

If there were a concrete use case to standardising the format of any of them, 
of course we could do that. See debian/copyright, that has been freeform for 
many years, only when there was a use case for parsing did people start to 
standardise it.

If you have this concrete use case, please present it so we can see if it's 
worthwhile to require everyone to use the format, or that the current 
free-for-all is just as sufficient.


cheers,
Thijs


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

Re: Lintian warning messages

[Thijs Kinkhorst]

Hi Richard,

On Tuesday 5 August 2008 14:02, Richard Hurt wrote:
> I am getting quite a few lintian warnings that I would like to quell.
> Do we have any best practices on how to deal with these messages?
>
> W: : debian-copyright-line-too-long  -- As I understand it
> long lines are now OK.  I am following the new, proposed guidelines
> for the copyright file (http://wiki.debian.org/Proposals/
> CopyrightFormat) and it almost guarantees long lines.

This warning has been scratched from the upcoming Lintian version so I would 
not worry about it.

> W: : script-non-executable  -- Since this is a scripted web
> application (RoR) there are quite a few "scripts" that are not
> executable directly in the shell.  Can I turn this warning off for
> these files?

Maybe you could find out why this warning is triggered. Probably, these 
scripts have shebang lines (#!/usr/bin/ruby  perhaps?) but are not 
executable. That doesn't match, as the shebang line is useless if the script 
is not executable.

So if they're not going to be executed on the shell anyway, upstream can 
remove those shebang lines. That said, I don't think it's necessary to be 
going through the effort to make a Debian-specific patch to the source for 
that.

> W: : extra-license-file  -- There are several LICENSE files
> scattered throughout the package and I have documented them in the
> copyright file.  Do I need to do anything with these?  Should I remove
> them or is there a way to ignore them?

Just remove them when building the package (e.g. doing rm in debian/rules 
somewhere after the dh_install). It's useless cruft that we do not want to 
see installed on user's systems.

In general it's worth the effort to put extra commands in your debian/rules 
file if that causes less unnecessary things on the user's system - a package 
is rarely built but after that installed on many systems.

> W: : embedded-javascript-library  -- Basically, prototype.js
> (versions 1.6.0.1 & 1.5.0) is being used in several places.  Obviously
> it would be best to depend on the libjs-prototype package and remove
> the embedded versions.  Once I get upstream using a single version of
> prototype do I just remove the original prototype.js files and symlink
> to the package version?

Yes, that would probably work fine. Until then, just keep the warning to 
remind you and others that this isn't done yet.

> W: : package-contains-empty-directory  -- Some of these are
> necessary (cache, assets, etc.) and some aren't (test).  Can I turn
> these off?

You can remove the unnecessary ones (similar to the licence files above) and 
add overrides for the needed ones.


cheers,
Thijs


pgpRQUMn2JWr6.pgp
Description: PGP signature

Re: RFS: openttd (updated package)

[Thijs Kinkhorst]

Hi,

On Wednesday 13 August 2008 00:41, Andreas Wenning wrote:
> You should add a debian/watch file to the package. Due to the RC/beta
> packages at the site the content of the file should probably look
> something like (possibly improvable):
>
> version=3
> opts="uversionmangle=s/-(alpha|beta|RC)/~$1/" \
> http://sf.net/openttd/openttd-(.*)-source\.tar\.bz2
>
> The Stadards-Version should be updated to 3.8.0
>
> lintian -iI gives a number of warnings when running it against the
> build .deb packages. You might want to have a look at those to see if
> any of them are relevant.
>
> That was all I could find. So looks good.

Yes, agreed. I sponsored the upload now anyway because of the security issue, 
and changed urgency to high. Please take care to fix these issies above for a 
next upload.


cheers,
Thijs


pgp0NeelAevjt.pgp
Description: PGP signature

Re: README.source for dpatch

[Thijs Kinkhorst]

On Tuesday 19 August 2008 13:02, Jörg Sommer wrote:
> the new policy version 3.8.0 recommends a README.source that describes
> how to use the patch system. I'm using dpatch and I thought the dpatch
> maintainer publish a README.source with their package. But it didn't
> happen until now. Does anyone who uses dpatch has written a
> README.source?

Actually, dpatch does, since version 2.0.30.


cheers,
Thijs


pgpyL2uv5Prja.pgp
Description: PGP signature

Re: Bug#496544: RFS: reportbug-ng (closes RC #496544)

[Thijs Kinkhorst]

On Wednesday 27 August 2008 09:09, Serafeim Zanikolas wrote:
> On Tue, Aug 26, 2008 at 11:26:06PM +0200, Bastian Venthur wrote [edited]:
> > But since the release team decided that rng is 'unfit for release' and
> > blocked rng, it won't enter testing even if you NMU the bug.
>
> For future reference, where is this information recorded?

http://packages.qa.debian.org/r/reportbug-ng.html shows:

| Not touching package, as requested by pkern (contact debian-release if
| update is needed) 

Then looking at (via http://release.debian.org)
http://release.debian.org/britney/hints/pkern

| # blocked for #422085
| block reportbug-ng

So there you can find the bug number that makes reportbug-ng blocked from a 
stable release.

cheers,
Thijs


pgppXeETyil8f.pgp
Description: PGP signature

Re: No sponsor found for weeks, what to do now?

[Thijs Kinkhorst]

On Wednesday 27 August 2008 19:02, Neil Williams wrote:
> 3. You're asking for sponsorship of PHP packages which are a security
> nightmare (esp. wordpress that had a huge flamewar around the time of
> the Etch release due to security issues). Many sponsors are justifiably
> wary of PHP packages after seeing many others being flamed to a crisp by
> the security team and ftp-master team. Personally, I won't touch PHP
> packages ever again - I'm reconsidering my own PHP in favour of perl and
> if I could do without php on my own servers, I would.

Although there are PHP applications that are a security nightmare, there are 
well-written applications just as well. This goes for any programming 
language. Generalising, unseen, that the program being in PHP meaning that it 
must be insecure is not exactly helpful. In fact, the problems caused by 
things like buffer overflows in the C language are for Debian a significantly 
larger task.

Plus, I've surely not seen anyone being "flamed [...] by the security team", 
let alone "to crisp", let even further alone those "many" people you're 
talking about, and find the suggestion that we would act in such a way a bit 
offensive.

Please, this mailinglist is intended as a friendly place to get help and 
sponsorship on your packages. It would be helpful to write in a more balanced 
tone than you used in this email.


thanks,
Thijs


pgpkyroiJ6vfo.pgp
Description: PGP signature

Re: No sponsor found for weeks, what to do now?

[Thijs Kinkhorst]

On Wednesday 27 August 2008 20:23, Neil Williams wrote:
> > Plus, I've surely not seen anyone being "flamed [...] by the security
> > team", let alone "to crisp",
>
> (Some of that happened off-list and one of the people involved is
> well-known to me due to interests outside Debian. I can vouch that some
> of the off-list stuff was easily described as 'flaming to a crisp'.)
>
> >  let even further alone those "many" people you're
> > talking about, and find the suggestion that we would act in such a way a
> > bit offensive.
>
> Mentors might not, others certainly have done. It doesn't serve the list
> to pretend that security and PHP are not poor bedfellows or that PHP
> will not invite some very firm, very pointed and extremely critical
> responses outside this list.

Whatever you personally think of PHP, I'm not charmed with you making 
allegations on a public forum that "many" people were "flamed to crisp" by 
the team I am a member of, but then fail to support that statement when asked 
where you base it on. If you want to make statements that put a team in a bad 
light in a public forum you'll have to be prepared to back them up.

It seems to boil down to "trust me, I once heard somewhere that a person was 
flamed by a security team member".

I think it's evident that I'm not charmed by you postulating that "many" 
people were "flamed" by that team, suggesting structural issues, without 
presenting a piece of material on that. I believe that only helps to set a 
negative atmosphere around that team.


Thijs


pgpLQDFGm0UsX.pgp
Description: PGP signature

Re: apt-proxy, apt-cacher & approx

[Thijs Kinkhorst]

On Mon, September 22, 2008 08:11, Kel Modderman wrote:
> On Monday 22 September 2008 15:20:20 Cameron Dale wrote:
>
>> On Sun, Sep 21, 2008 at 10:14 PM, Thomas Goirand <[EMAIL PROTECTED]>
>> wrote:
>>
>>> We've been using apt-proxy for about a year, and then found it quite
>>> buggy. So we moved to using apt-cacher. Now we have loads of problems
>>> with apt-cacher as well (like currently, a recurring tzdata size
>>> mismatch error). I was wondering if approx is any better than the
>>> other two. Did any of you try?
>>
>> I have also experienced similar problems with both apt-proxy and
>> -cacher. I am now using approx, and I can report no errors with it at
>> all. It may be slightly slower, but that could be my imagination. I would
>> definitely recommend approx.
>
> I agree, approx has served myself well for quite some time.

I had some caching issues with approx in etch. When I upgraded to the
version from lenny in backports.org, that trouble went away and it runs
smoothly.

Just as a note there seems to be now a fourth alternative: apt-cacher-ng...


Thijs


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

Re: RFS: whohas (new upstream)

[Thijs Kinkhorst]

Hi Jonathan,

On Thu, January 8, 2009 07:26, Paul Wise wrote:
> On Thu, Jan 8, 2009 at 8:22 AM, Jonathan Wiltshire
>  wrote:

>> I have uploaded whohas 0.22-1 to m.d.n, which is a new upstream
>> integrating a lot of the bugs, and some tweaks to the packaging because
>> of his changes.

Great. As I think this can be very useful to Debian developers, I have
added a news item to the DeveloperNews queue, which will be posted to
debian-devel-annnounce sometime in the near future:
http://wiki.debian.org/DeveloperNews
Feel free to update/change it.

>> I've also included a NEWS file detailing the patches
>> that are still active.
>
> I don't think that is an appropriate use of NEWS.Debian, documenting
> them in the patch headers should be enough.

Agreed; NEWS.Debian is for changes to the package that are relevant to end
users. This information is indeed most appropriate in the individual patch
headers.

> Listing all the distros supported may not be a good idea because this
> will change over time and thus add work for those translating Debian
> package descriptions.

I think that's actually rather informative as it gives a good overview of
the breadth of the package and what kind of distributions it searches.
It's not critical that the list is exactly up to date, so I don't think it
would be a problem if some translations were to get a little behind on the
most recent version. So I would leave it in.


cheers,
Thijs


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: whohas (new upstream)

[Thijs Kinkhorst]

On Thu, January 8, 2009 11:19, Jonathan Wiltshire wrote:
> Devref mentions NEWS.Debian as a changelog supplement: "This is the
> preferred means to let the user know [...] changes in a package" [1]. I
> didn't use README.Debian as the same paragraph seems to discourage this,
> but if you think it would be better I will change it.
>
> Clarification of these files would be appreciated :-)

An important distinction of NEWS.Debian is that it is shown to users on
package upgrade. I think we should use this sparingly as to not devaluate
the use of this functionality. Nearly every Debian package has patches
relative to upstream, it is good that they are documented for those
actively looking for it. README.Debian is in that sense also acceptable.

On Thu, January 8, 2009 11:21, Jonathan Wiltshire wrote:
> > http://wiki.debian.org/DeveloperNews
> > Feel free to update/change it.

> Good idea, thanks. Should it mention that whohas is still <1.0 and being
> heavily developed though? Or is the BTS mention enough?

I think that's not quite important - developers are not afraid of such
software and keeping the text short means more people read it :-)


Thijs


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Added requirement for translation of debconf templates

[Thijs Kinkhorst]

On Sun, January 18, 2009 20:04, Mark Brown wrote:
> On Sun, Jan 18, 2009 at 05:24:05PM +, Neil Williams wrote:

 using debconf that requires sponsorship, that debconf translations
 are requested and updated by the maintainer on an ongoing basis.
>
>>> You mean "that requires [my] sponsorship" ?
>>>
>
> ...

...

> For the first upload I broadly agree but for other uploads I think it's
> worth considering other aspects of the tempo of development - is the effect
> of uploading without waiting for translations likely to be a long term
> thing or is it likely to be a brief interlude in unstable.

Yes, in some circumstances I think it could be considered a good idea to
first make an upload to unstable, and once you're sure that the new
debconf template and the code associated with it has stabilised, only then
ask for translations. Suppose it seems the template wasn't required
afterall, or a change is needed, all translation work is wasted or has to
be redone.

Of course you're free to declare the boundaries of what you want to
sponsor and make them as sharp as you see fit. I prefer not to post an
elaborate set of rules, but rather judge a package on a case by case
basis. Both are valid approaches, and have different tradeoffs in
predictability versus flexibility.

I would appreciate it if you would make it more clear that what your
present are *your* requirements for sponsorship. Your mail reads like an
annoucement  rather than a change in what are your personal preferences.


thanks,
Thijs


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: When is a hint required?

[Thijs Kinkhorst]

If there is a circular dependency preventing two related packages from going into 
testing (both are >=10 days old and valid candidates), will the hint be put in 
place automatically or is it down to the maintainer for one or other package to 
ask?

http://bjorn.haxx.se/debian/testing.pl?package=gnotime

(I gather from Google it's debian-release for actual requests for hints but I 
couldn't find details of who is responsible for actually noticing a hint could 
be required.)
  
As with many things in Debian, if you notice something needs attention, 
just put it to the people that can fix it. In this case, those packages 
indeed need to go in together, it's just fine to contact the 
debian-release list with a short request to let those packages go in 
together.



Thijs


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

Re: [RFS] freeloader: a nice Gnome download manager written in python and supporting torrents

[Thijs Kinkhorst]

Hello Julien,

Here's some more feedback, I hope it's useful.

> Added in SVN [1], I'm waiting for other comments before building another
> package.

You must not install the reportbug hook if you're going to make the
package part of Debian proper, since that will circumvent the BTS.

You might want to raise debhelper compatibility level in file
'debian/compat' to 5, since it's the most recent. Only drawback is that
that version is not in sarge, it makes backporting a very tiny bit
harder.

The debian/copyright file misses years, like this:
Copyright 2005 Mr Potatohead.

In the man page you write "This manual page was written for the Debian
system by Julien Valroff <[EMAIL PROTECTED]>.". Although not required, I
find it good custom to add "but may be used by others" to it.

Your changelog doesn't close RFP bug #337598 (which would better have
been retitled to an ITP by you).

Good luck with your package!

Thijs



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

Re: Rationale behind script-not-executable lintian warning

[Thijs Kinkhorst]

On Thu, 2005-12-22 at 12:25 +0100, Bas Wijnen wrote:
> Then it seems logical to me that an override would be in order.  However, I
> don't understand what the check is for, if not for cases like these.  So my
> logic may very well be incorrect.

Many tests document a short rationale in their description; it would be
good to add this for tests where it doesn't exist. For example by
sending patches to the BTS.


Thijs


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

Re: Remove an ITP

[Thijs Kinkhorst]

On Thu, December 22, 2005 20:01, Rogério Brito wrote:
>> Packages are ready, but vamps can not enter in Debian, because the
>> upstream author don't want to make public his real identity (now in
>> debian/copyright I've a "Vamps Admin ", but this solution does
>> not follow the Debian Policy
>
> If the author is really reachable via that e-mail, I'd think that it
> should be OK, but, unfortunately, I haven't read the sections of the Policy
> regarding legal issues and I am certainly outdated on these issues.
>
> (Right after I wrote the paragraph above, I went to read the Policy
> sections 2.3 and 12.5 and I don't quite see a problem regarding an upload
> of these programs under a pseudonym).

I'm pretty convinced that the anonimity of the upstream author shouldn't
be an issue. We never check the identity of any upstream author, so any
name could be a pseudonym, and some definately will be, only this author
is open about it. We already have such software in the archive, such as
nmap.

It's probably best to send this issue to the debian-legal though to get
some more advice. But in any case I wouldn't close the ITP because of this
reason right now.


Thijs


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

Re: Remove an ITP

[Thijs Kinkhorst]

On Thu, 2005-12-22 at 22:14 -0500, Justin Pryzby wrote:
> It was deliberate, but not a joke.  My point is that there's no
> difference between such names; "Public Flood Software", "FSF", and,
> for example, the "the Debian Installer team" [0].

This is getting a bit off-topic, but from a legal point of view there's
a clear difference between "FSF" on the one hand and "Public Flood
Software","the Debian Installer team" on the other hand. The former is a
formal legal entity and thus can actually hold copyrights itself, while
the latter are informal groups with no more status than the collection
of authors has.


Thijs


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

Re: RFS: libmemcache_1.4.0.b9-1

[Thijs Kinkhorst]

Hi Zakame,

> Hence, I'm needing a sponsor for this package.  I hope for your positive
> reply, and contructive comments are very much welcome!!!

Unfortunately I can't upload your package, but a quick review showed me
that the copyright file talks about Ubuntu everywhere, like in "This is
the Ubuntu package for libmemcache", "On Ubuntu GNU/Linux systems, the
complete text of the GNU General...". Is this on purpose? It might
confuse Debian users.

And just a tiny note, you indicate the standards version as 3.6.2.1,
it's very common to leave off the last '.1', since increments in policy
on that level only contain textual changes. Hence your package will
comply with any 3.6.2.x policy, so listing 3.6.2 would be best.


bye,
Thijs


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

RE: RFS: directnet -- A serverless, mesh network instant messaging client

[Thijs Kinkhorst]

On Tue, January 3, 2006 09:47, Gregor Richards wrote:
> I updated the package to 1.0.0.  The version compare algorithm doesn't
> like it ... it thinks that 1.0.0 is less than 1.0.0rc5 ... but that's not
> how release candidates work :)

That's indeed a caveat on the Debian version compare algorithm. When
you're packaging a release candidate, you normally should watch out for
adding 'rcN' to the version to avoid being able to update it to the real
version later.

What's done commonly is something like this: 0.9.9+1.0.0rc5, or for a
higher version: 2.4.3+2.4.4rc1. So you take the version number one lower,
you concatenate the real version with a plus in between. The algorithm
will handle this correctly and the archive will accept a subsequent upload
of 1.0.0 or 2.4.4 proper.


Thijs


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

Re: How to close Bugs in experimental

[Thijs Kinkhorst]

On Wed, 2006-01-18 at 00:38 +0100, Armin Berres wrote:
> There was _never_ any version of Initng in unstable. The current version
> (uploaded today) doesn't contain the bugs anymore.
> 
> > - Can you point me to a bug which is counted as "open" for unstable when
> >   it's clearly clearly tagged fixed for some version?
> > - Which statistics do you mean?
> 
> I'm talking about this statistics:
> http://packages.qa.debian.org/i/initng.html
> http://qa.debian.org/[EMAIL PROTECTED]
> 
> Have a look at the pending bugs. If I shouldn't close them I shouldn't
> have them marked pending too (cause pending means pending to unstable as
> I see now).
> The bugs are still as pending in the satistic, but they are now fixed in
> every Debian package (after tey've been built).
> If I wouldn't have marked them pending they would now still appear as
> opened...

You should ask yourself the question here: why should I keep this bug
open? A reason to keep a bug open is if there's another version in
Debian still affected. But there isn't. The bug is not present in Debian
for any release. It can safely be closed. This is of course for your
special case where experimental is the only distribution containing your
package.

In a more general sense, it's important to note that the
fixed-in-experimental tag is deprecated, and definately not necessary
anymore. The BTS version tracking feature is just what you want. It
allows for specifying exactly which versions of the package contain the
bug. The BTS can than determine all by it self to which distributions
(sid, etch, woody, experimental) this applies.

So, the correct way to handle this is to mail to
[EMAIL PROTECTED] with on the first line of your message
"Version: ". You should close bugs like this for any you
fix, regardless of in which distribution the fix will end up.


bye,
Thijs




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

Re: How to close Bugs in experimental

[Thijs Kinkhorst]

On Wed, 2006-01-18 at 10:00 -0200, Henrique de Moraes Holschuh wrote:
> > You mean "close" commands...
> 
> No, as close commands ARE clearly deprecated as well, and not at all
> equivalent to adding a tag.  We are taliking about uploads to experimental,
> after all.

The close command was indeed deprecated, but this was before the arrival
of the version tracking feature. I've experienced myself that e.g.
making a mistake is not really correctable other than by using 'close'.

There's currently no other way to specify a fixed-version other than
mailing '-done' or using 'close. Mailing -done is not always
appropriate. This will trigger a mail to the submitter which is not
desirable if you for example just want to specify the affected version
better, or made a mistake when using the 'found' or 'reopen' command.

There needs to be a way to indicate a fixed-version without telling the
submitter that their bug is being closed. This tool is currently using
'close'. Either close needs to be de-deprecated (precated?) for this
use, or there needs to be a new command allowing this. Maybe 'found' can
be extended to also allow a fixed-version to be specified.


Thijs


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

Re: RFC: arpoison

[Thijs Kinkhorst]

Hello P-A,

> I'm trying to package arpoison 0.6 (arpoison.sf.net). So far, so good:
> everything seems to work. I uploaded it to mentors.debian.net. If any of you
> would like to have a look ..

I have, and here are some results.

* First of all, the package is signed but your key is not signed by
anyone else. That doesn't make the signing much useful. It's a very good
idea to get some signatures on your key (even if you do not want to
become a Debian Developer). See http://www.debian.org/events/keysigning
or http://biglumber.com to find people who want to sign near you.

* debian/control: The description of the package is way too terse. The
text in README would be more fit for this.

* debian/copyright: The copyright holder is incomplete; you list only
the last name, and you miss the name of the other author. You also need
(a) year(s) with that: "(c) 2005-2006 Steve Buer" for example. BTW this
information misses in the upstream source aswell, see below.
This file has very long lines; although sensible editors should be able
to handle it, it doesn't look really good in 'less' for example.

* debian/dirs: contains usr/bin and usr/sbin while you only seem to
install into usr/bin.

* debian/rules: you should remove commented out stuff, and optional
targets, you don't use. No reason to keep it.

* debian/compat, debian/control: the current recommended debhelper
version is 5, not 4.

Some notes for upstream, not packaging problems, but good to feed back
to them:
* The README file claims this is ARPoison 0.5 while it's 0.6.
* It doesn't include a changelog.
* LICENSE contains a very old FSF address
* The source files do not explicitly state their licence; this is a very
good idea to do (in case the file LICENCE gets lost somewhere); just put
it in comment to the top. An example text is at the bottom of LICENCE.
It should also contain some statement like "Copyright  ".
* It contains "lookup.c" which doesn't seem to do anything interesting
and isn't built.
* Make clean yields an error if the source is already clean. Turn the
"rm" into a "rm -f".
* It has some build warnings.


Otherwise, the package works fine. It just needs some polishing up on
the details.


Thijs




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

Re: RFS: aabrowse: Server browser for America's Army game

[Thijs Kinkhorst]

Hello Martin,

On Wed, 2006-02-01 at 23:54 +, Martin Meredith wrote:
> Would still love to get this sponsored - Anyone interested ? (forwarding to
> pkg-games-devel too)

>>  AABrowse is a Linux-native server browser/query/game-launch
> >>  tool for America's Army (http://www.americasarmy.com/).

Unfortunately cannot sponsor you yet, but I did a review of your
package. Here's some points that may be improved:

* debian/aabrowse.1.docbook: under description, it says: "Katapult is a
KDE laucher. It uses text-based queries to launch a program, a bookmark
or a directory." Copy-paste error?

* debian/control: has a "Section: unknown". What about "games"?

* debian/compat, debian/control: the current recommended debhelper
version is 5, not 4.

* debian/docs: You ship the upstream README, but that file doesn't
contain information relevant to Debian users.

Otherwise, the package looks good. I hope you can find someone to
sponsor the package for you (if you fix Section, I guess)!


bye,
Thijs


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

Resolving a bug when the maintainer is unwilling to

[Thijs Kinkhorst]

Hello all,

I could use some advice on bug 307833 (and its duplicates) against
apt-file. Please see the buglog for full context, especially my most
recent message from Jan 26th.

In short, apt-file doesn't work out of the box because it requires curl
but doesn't depend on it. I think that should be changed, the maintainer
thinks it should not. The maintainer has literally said "discussion
closed" and didn't recently respond to the bug.

My question is what to do now. From my view, I can do either of the
following options: nothing, nmu, refer to the technical committee. What
would be most appropriate?


thanks,
Thijs




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

Re: Looking for sponsors

[Thijs Kinkhorst]

Hello Panu,

On Tue, 2006-02-28 at 13:43 +0200, Panu Kalliokoski wrote:
> Hello, I'm interested in becoming a debian developer and I'm looking for

Welcome!

> sponsors.  I'm not sure what else I should say; I'm willing to answer
> any questions.  The new maintainer's guide says I should find sponsors
> for my packages (or fixes, translations, etc., which I haven't made)
> before applying for NM, so I'm doing that now. 

That's right, but it's customary to look for a sponsor on a
package-by-package basis, i.e.: if you have some package finished and
think it's ready for upload, post a message to this list with a
description of the package and where it can be found.

On a related note, at the location you specified I can only find binary
packages (.deb). For successful sponsoring, you need to provide the full
source packages (.dsc, .diff.gz, .orig.tar.gz). The .deb itself is not
really needed, even, since the sponsor will rebuild the package from the
source.

Good luck,

Thijs


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

Re: RFS: b5

[Thijs Kinkhorst]

Hello Panu,

On Tue, 2006-02-28 at 16:05 +0200, Panu Kalliokoski wrote:
> Where to get it:
> http://sange.fi/~atehwa/debian/b5_2.3.dsc
> http://sange.fi/~atehwa/debian/b5_2.3.tar.gz
> http://sange.fi/~atehwa/debian/b5_2.3_all.deb
> http://sange.fi/~atehwa/debian/b5_2.3_i386.changes

The same goes for packages bfc, python-selecting, sokoedit, stx2any:
why are these Debian native packages? All of these do not seem to be
Debian specific tools. Since you are the upstream author aswell, you'd
best create an .orig.tar.gz "release" (without the debian/ dir), and
then package that as a regular, non-native package. That allows for
other distributions to include the software aswell, if they wish so.

Native packages should ideally only be packages that have no real use
outside of Debian.


Thijs


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

Re: RFS: b5

[Thijs Kinkhorst]

On Tue, 2006-02-28 at 17:55 +0200, Panu Kalliokoski wrote:
> On Tue, Feb 28, 2006 at 04:32:16PM +0100, Thijs Kinkhorst wrote:
> > Native packages should ideally only be packages that have no real use
> > outside of Debian.
> 
> Really?  I've never seen such a guideline (although I admit it's been a
> long time since I read the relevant documents).  In fact, the Debian
> Developer's Reference, section 5.4, seems to suggest that the difference
> is purely technical and has no political or social implications.  If you
> could show me some document that explains whether and why native
> packages are not preferred for software that could live outside Debian,
> I'd appreciate that very much.

I'm not sure if it's actually clearly written down, so it might be more
of an opinion, but it's customary at least to package debian-specific
things as native and others as non-native packages.

I'm not sure where you're getting the political and social aspects from,
as I am only talking about technical aspects.

If someone is packaging your software for other distributions and you're
using a non-native package, it's very clear which part is the shared
part by all distributions, and which are the Debian-specific changes
that are being made. This would e.g. also make an NMU more transparent.

It's your call, but since making them non-native is not really that much
more work, I'd recommend doing it that way.


Thijs


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

Re: RFS: b5

[Thijs Kinkhorst]

On Wed, 2006-03-01 at 03:52 +1100, skaller wrote:
> On Tue, 2006-02-28 at 17:12 +0100, Thijs Kinkhorst wrote:
> 
> > It's your call, but since making them non-native is not really that much
> > more work, I'd recommend doing it that way.
> 
> It can be quite a lot more work if you have powerful scripts 
> that can generate the required meta-information during the 
> build process (since that requires no work .. once the scripts
> are got right :)

If you have powerfull script you can reduce the amount of work in the
build process, not increase it, right? Having powerfull scripts would
only help here.


Thijs


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

Re: RFS: b5

[Thijs Kinkhorst]

On Wed, 2006-03-01 at 09:13 +0200, Panu Kalliokoski wrote:
> It seems the only sensible way, then, because I really want to include
> the debian/ files in my real release (they contain possibly useful
> metadata, like the changelog, after all).

You would best place the changelog in the root of your package, since
debian/changelog is the place for Debian-specific changes.


Thijs


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

Re: RFS: eva -- An IM client under kde using Tencent QQ's protocal

[Thijs Kinkhorst]

On Wed, 2006-03-01 at 22:18 +0800, Hou ZhengPeng wrote:
> I'm looking for a sponsor for the following package:
> ITP : #349997
> Author: casper <[EMAIL PROTECTED]> yunfan <[EMAIL PROTECTED]>
> Home Page:  http://sourceforge.net/projects/evaq
> License: GPL-2
> Source: eva

Where can the source package be found?


Thijs


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

Re: RFP - package: Looking for a Sponsor!!

[Thijs Kinkhorst]

Hello Francesco,

I'm not a DD yet, but I've reviewed your package anyway and here are
some comments:

> This package is in the Requested Packages list:
> 
> RFP: libtime-unix-perl -- cross-platform time() for Perl  
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290136

You should retitle this bug from "RFP" to "ITP" to make it clear that
someone is working on this. See here for more info:
http://www.debian.org/devel/wnpp/
You should also close this bug in your changelog.

From the package description:
It talks about a "below RFC" which is not present in that description.
It also says that it's indended mainly as a proof of concept. Would it
be useful to include a proof of concept in Debian or are there real
scripts using this module?

The last sentence is: "This doesn't do anything useful on UNIX
platforms, so don't do that.". So, I should not use this package in
Debian? Then why is it in Debian? Either change this sentence or do not
package the module :)

And some tweaks: you are encouraged to remove commented-out dh_ lines
from debian/rules, and you could consider upgrading to debhelper
compatibility level 5 since that's the recommended release.


bye,
Thijs


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

Re: gaim-snapshot (possible) newbie question

[Thijs Kinkhorst]

On Fri, 2006-03-10 at 17:18 +0100, Marco Cabizza wrote:
> Can anybody review (and hopefully upload) those?

My main concern (apart from the valid hijacking concerns raised) is that
it's a Debian native package. That's not right; you should use an
orig.tar.gz from upstream; even if you pull from CVS yourself, you need
to make a tgz out of that and use that as the orig.tar.gz. The .diff.gz
will then contain exactly the packaging and other Debian-specific
changes.

The package also exhibits some other lintian/linda warnings/errors:
> W: gaim-snapshot source: maintainer-script-lacks-debhelper-token
> debian/gaim-snapshot-dev.postinst
> W: gaim-snapshot source: source-contains-CVS-dir .ssh/CVS
> E: gaim-snapshot; Uses cdbs and debhelper.mk, but debhelper
> Build-Depends is too old.

The CVS one may be caused by using "cvs co" instead of "cvs export".


bye,
Thijs


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

Re: RFS : kscoreticker

[Thijs Kinkhorst]

Hello Varun,

>  I am looking for a sponser for my package kscoreticker. KScoreTicker is 
> a simple applet for KDE that shows the latest cricket scores on the taskbar. 
> I am the developer of this package and I would like to maintain it as well. 
> The package builds with pbuilder and is lintian free.
> The package can be downloaded from this site:
> http://www.ae.iitm.ac.in/~ae03b032/package_debian.php

I've taken a look; unfortunately I can't upload your package but I hope
this is still useful. Here's some things that I found:

* README.Debian contains just a package description. That's not
  necessary, please remove it: README.Debian is intended for important
  information that users really should read before using the package.
  Keeping unimportant information there discourages people to actually
  read those files.

* debian/dirs contains usr/bin and usr/sbin while you don't seem
  to install anything in those dirs at all.

* debian/rules contains many commented-out debhelper commands. Please
  remove them to unclutter the file.

* You include an manpage.1.ex example file, this is just a leftover
  from dh_make, please remove.

If you fix these things, I think the package would be acceptable for
Debian, good work!


bye,
Thijs




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

Re: RFS: texmaker

[Thijs Kinkhorst]

Hello Joseph,

> I am looking for a sponsor for texmaker.  My files can be found at
> http://josephsmidt.googlepages.com/debianpackages

I've taken a quick look at your package; unfortunately can't upload it for
you but still hope this is useful.

> I relise there is another ITP from Gauvain Pocentek
> <[EMAIL PROTECTED] > but I
> since emailed him and he assured me he only intended to send an RFP just
> as his subject

Yes, it was retitled and merged with the ITP. Closing one of the reports
will close the other automatically.

When looking at your package, I see that the .diff is mostly example files
from debhelper (*.ex). Please remove all those examples if you're not
using them. This makes the diff a lot better readable.

You use 'mv' quite a lot in debian/rules, you could also use dh_install
for that.

This is all from the first look, so that's already quite ok! Hope you can
find someone to sponsor it for you.


Thijs


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

Re: Re: RFS: texmaker

[Thijs Kinkhorst]

Hey Joseph,

On Tue, 2006-04-04 at 16:21 -0600, Joseph Smidt wrote:
> I think I have fixed the problems in my .diff and control files.  The 
> new files have been uploaded to:
> 
>   http://josephsmidt.googlepages.com/debianpackages
> 
> Hopefully now it is ready to be sponsered. :)  Thanks a lot for your 
> help.  I really would like to see this package in Debian, which is why I 
> ITP'd it.

I've taken another look and it already looks a lot better without all
the clutter :) It builds fine. Here's some more comments:

The copyright/licence statement is not entirely consistent:
- The about box says 2004-2006 and GPLv2 only
- The source says 2003-2005 and GPLv2 or later
- debian/copyright says the same as the source

I think the About box is just incorrect and I don't see it as a
showstopper, but it's best to take this up with the author.

The menu items Help -> LaTeX reference and Help -> User Manual do not
work (file not found resp. just a no-op). Am I perhaps missing some
package(s)? In that case better recommend or suggest them.

Minor thing, the description in debian/control contains
"Web page: ..." but the convention is "Homepage: ..."

For the rest, good work. Unfortunately I can't upload your package but
hopefully someone else will, it looks good.


Thijs


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

Re: RFS: scim-bridge--Yet another IM client for scim

[Thijs Kinkhorst]

On Mon, 2006-04-03 at 10:53 +0800, Hou ZhengPeng wrote:
>   Description :  Another IM client of SCIM
>  Scim-bridge is yet another IM client of SCIM.
>  The im-module of scim-bridge communicates with
>  scim via socket.

Maybe in the description you can tell us casual bystanders what "SCIM"
is or "IM". I guess the latter is Instant Messenging? Still, it's of
course a service for those not yet "in the know" to quickly detail what
this is al about.

A cursory look didn't reveal any other problems.


Thijs


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

Re: RFS: checkinstall

[Thijs Kinkhorst]

Hello Felipe,

On Tue, 2006-04-04 at 15:13 -0400, Felipe Sateler wrote:
> Apparently my package is good enough, since it didn't get any more comments
> in my RFC thread [1]. I tried one last time to contact Matt Hope (previous
> checkinstall maintainer), and gave him a week to answer, but he didn't
> answer. So, I now request for a sponsor to upload the checkinstall package
> now [2]. Of course, any suggestions/fixes/comments are greatly appreciated.

The package looks fine, builds fine, good work. The only think I'd
change is to remove the README.Debian file. That contains information
that's already known: all Debian packages put their config under /etc.
There's no need to bother the user with that information. Can't upload
the package for you, sorry!


Thijs


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

Re: RFS: checkinstall

[Thijs Kinkhorst]

On Thu, 2006-04-06 at 12:52 -0400, Felipe Sateler wrote:
> Frank Küster wrote:
> > If the place for configuration is mentioned anywhere in the upstream
> > documentation, this is the place to indicate the Debian-specific
> > placement.
> Mmmh, so I put again the file, plus a note on where locales are installed
> (which again upstream installed in a strange location).

I think that Frank meant to say that if the documentation mentions some
place for configuration files, then you should change that part of the
documentation instead of providing a separate file.


Thijs

Re: RFS: checkinstall

[Thijs Kinkhorst]

On Fri, April 7, 2006 23:24, Felipe Sateler wrote:
>> I think that Frank meant to say that if the documentation mentions some
>>  place for configuration files, then you should change that part of the
>>  documentation instead of providing a separate file.

> I don't think so. AFAIK the package should modify the original files as
> little as possible.

I'm not sure where you got that information, because it's not really true.
Many Debian packages include heavily patched versions of upstream
software. Whether this is right can only be decided on a case-by-case
basis.

For this specific case: it's definately good to modify upstream to change
things that are Debian specific. You probably change the config file path
in the source, for example. If you do that, why shouldn't you patch the
documentation aswell? What use is it to provide incorrect information to
the end user only to correct it in some other file?


Thijs


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

Re: [RFS] cmus: Lightweight ncurses audio player

[Thijs Kinkhorst]

Hello Julien,

On Sun, April 9, 2006 11:17, Julien Louis wrote:
> Some times ago, i asked for a sponsor[1] without any answer. Does anyone
> would
> be interested in sponsoring this package ?
>
> Package is still available at http://ptitlouis.sysif.net/debian/cmus/

The package looks good from a quick overview. It might be good to address
these points:


- debian/copyright misses the years for which the copyright applies.
  Please see
  http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
  for details.

- In debian/control you write "it can be control with" which should be
  'controlled'.

- In debian/rules, it's good custom to remove the commented dh_ lines
  you're not using.

Good luck with finding a sponsor!


Thijs



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

Re: RFS: texi2html

[Thijs Kinkhorst]

Hello Francesco,

On Sun, April 9, 2006 03:16, Francesco Cecconi wrote:
> Hi all DD,

I'm not a DD so can't upload your package, but here's some small comments:

> Sources:
>
> http://mentors.debian.net/debian/pool/main/t/texi2html/

- In debian/copyright you write "The current maintainer is Florian Ernst",
  that's not true anymore :)

- You are including the full text of the GPL, that's not necessary because
you
  can refer to that file in /usr/share/common-licences. You also add some
  other licence texts which are appearently not present in the upstream
  package. Is that actually necessary, and if so, did you contact upstream
  about adding those texts?

Good luck with finding a sponsor!


Thijs


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

Re: Doing RFS on -mentors

[Thijs Kinkhorst]

Hello Nico,

On Sun, April 9, 2006 20:52, Nico Golde wrote:
> Hi,
> to make it as easy as possible for purspective package checkers
> if you post an RFS on the -mentors list please put all parts
> of the source package in a directory (FTP or HTTP).

You should use `dget` from the devscripts package. You just pass it the
full url to the source package and it gets all other parts; call it with
the -x flag to also unpack the package after downloading.


Thijs


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

Re: Doing RFS on -mentors

[Thijs Kinkhorst]

On Mon, 2006-04-10 at 20:51 +0200, Nico Golde wrote:
> > You should use `dget` from the devscripts package. You just pass it the
> > full url to the source package and it gets all other parts; call it with
> > the -x flag to also unpack the package after downloading.
> 
> That wont work too in described scenario but thanks for the 
> hint with dget.

I've tried it with wmworkflop ('old situation') and it works; I also
don't know why it should fail?


Thijs


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

Re: RFS: checkinstall

[Thijs Kinkhorst]

On Tue, 2006-04-11 at 11:44 -0400, Felipe Sateler wrote:
> All right, I changed the documentation to point to the actual places.
> However, I am doubtful if I should remove the README.Debian, since people
> who had worked with checkinstall (upstream, not Debian's package)
> previously might get confused if they don't find the configuration or the
> locales.

I doubt it. Debian users are used to find their configuration
under /etc, because all packages do that. Even, users of any LSB/FHS
compliant distro expect that. I can't think of a reason why someone
would think that for "checkinstall" this would be different than for any
of the thousands of other packages in Debian.


Thijs


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

Re: RFS: vim-latexsuite

[Thijs Kinkhorst]

Hello Franz,

> I'm in search of a sponsor to adopt vim-latexsuite. I've uploaded all
> my files to:
> http://franz-pletz.org/debian/vim-latexsuite/

> The corresponding bug is at:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307166
> 
> Package: vim-latexsuite
> Description: brings the LaTeX power to Vim
> 
> I've packaged a new upstream version and changed a few bits to get it
> linda & lintian clean.

It looks fine. I can't upload the package for you, but I do have some
comments which may help to further improve the package:

- Description: I don't like the short and long description. I realise
  you didn't make it up but it's your responsibility now :)

| Description: brings the LaTeX power to Vim
|  Vim is undoubtedly one of the best editors ever made. LaTeX is an extremeley
|  powerful, intelligent typesetter. Vim-LaTeX aims at bringing together the 
best
|  of both of these worlds.
|  .
|  We attempt to provide a comprehensive set of tools to view, edit and compile
|  LaTeX documents without the need to ever quit Vim. Together, they provide
|  tools like macros speeding up the edition of LaTeX documents, means for
|  compiling tex files to forward searching .dvi documents.
|  .
|  This package also provides help to LaTeX in vim.

  The short description doesn't really tell one what exactly this
  package brings to Vim. The long description already does a bit better,
  but I'd put the second paragraph first, because that's the one that
  actually tells us what this does. The first paragraph is quite
  redundant and I suggest you just drop it, or at least move it down.

  Maybe change the short one to "View, edit and compile LaTeX documents
  entirely from within Vim".

- You've made some miscellaneous changes but you didn't mention them in
  the changelog:
* New upstream release
* Adoption of package (Closes: #307166)
  For example: you've updated the standards-version, you've added a
  dependency and made changes to debian/rules. Please make sure you
  document all the packaging changes you make in your changelog.

- Standards-Version: you've changed this to 3.6.2.2, I'd suggest to
  state just "3.6.2". The last part of the version number indicates
  only textual/formatting revisions to the policy so it's not
  significant for the package (i.e.: you never need to make changes
  to your package between 3.6.2.2 and 3.6.2.3).

- debian/rules: for clarity, please remove the commented-out dh_*
  commands.

- debhelper: you could consider moving to debhelper compatibility
  level 5 (newest and recommended) but this is not necessary.

- debian/copyright: doesn't list the years of the copyright, please see
  http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html

Good luck with the adoption, and if you look at these points I'm pretty
sure that someone will sponsor you.

bye,
Thijs


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

Re: wmcalc

[Thijs Kinkhorst]

Hello Antony,

On Thu, April 13, 2006 16:46, Antony Gelberg wrote:
> I have tried to contact Gordon Fraser, wmcalc maintainer, regarding
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320597, which although
> of important status, renders the package useless to those who expect it to
> calculate correctly.
>
> My emails to him bounce.  What do I do next?  I would like to maintain
> this package if he is MIA.

I don't think he's MIA, because he uploaded something last week:
http://qa.debian.org/developer.php?login=gordon

If mails bounce, you might consider contacting him on [EMAIL PROTECTED]


Thijs



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

Re: Getting close to releasing my first .deb's... What's next?

[Thijs Kinkhorst]

Hello Tyler,

On Tue, April 25, 2006 00:01, Tyler MacDonald wrote:
> I'm working on creating .deb packages for one of my projects, with the
> eventual goal of having it included in the debian distribution.

Then you've come to the right place for help :)

I'm out of town, so just some general comments here:

Your package is a "Debian native" package, i.e. without an orig.tar.gz.
That's not considered a good idea unless it's really Debian-specific.
Normally you'd have an .orig.tar.gz from upstream and a .diff.gz with the
Debian-specific changes.

> 1. lintian complains that I don't have manpages for my executables.
> This is because the project is still young and they haven't actually been
> written yet. However, the executables aren't the meat of the project,
> they're just nice-to-haves and some may disappear/get re-arranged. Is the
>  lack of manpages for these tools a blocker? I've noticed several
> packages that get installed with a generic "no manpage was written for
> this" manpage, can I just do that for now?

Just include no manpage at all. Don't silence Lintian for it, because man
pages need to be made eventually. However, will the binaries really change
that much that it creating man pages would be wasted effort? Just some
general documentation is already a lot more helpful than nothing at all.
My advice would be to include as much of a manpage as is reasonable
looking at what you expect of the future of that binary.

> 2. "php5-apache2-mod-bt". This package actually needs php5, apache2,
> and mod-bt to be installed and links them all together, providing a php5
> interface to inspect the data of a running mod_bt tracker on an apache2
> server. Should the ordering of the name be rearranged? Like
> "libapache2-php5-mod-bt" or something?

I'm not entirely sure since I'm not well aware of the specifics of your
module. If other people on this list can't help with that, you could
consider contacting e.g. the debian-apache list for a second review of
your package.

> 3. Currently, one set of documentation is generated for all of
> mod_bt's components. All of the components are part of the same
> distribution and released under the same license (Apache 2.x). I'm
> guessing I should place this documentation in the deepest common
> dependancy (libbtt) and symlink the other package's share/doc/ directories
> over there. I saw that libzvt does that with it's -dev package.. Is that a
> generally accepted practice? Even if we're talking about 8 different
> .deb's?

Sure. Just make sure that users have the documentation they need when they
install just one of the packages, and that they have all information
required by policy (Debian changelog).

> Also, one other thing; once mod_bt gets injected into debian, I was
> toying with the idea of having the debian BTS be the mod_bt's official bug
>  tracking database. This would save having to maintain two bug lists,
> forward things upstream, etc., especially because as of 0.0.15 I'll be
> distributing the source debian-ready. To get used to it I've set up a
> debbugs server to play with (http://bts.yi.org/). Is it acceptable to use
> the debian bug database as the official bug database for a package that's
> available in debian, but also available elsewhere? (eg; if I made RPM's,
> etc)

Please don't include the 'debian/' directory in the upstream tarball. This
is just a little convenient when maintainer == upstream, but as soon as
either one changes, this can lead to confusion when the debian-diff is a
diff over an existing debian dir. There's been quite some discussion about
this previously.

You can use the debian BTS as your upstream bts though, as long as you're
keeping it in shape of course :)


Good luck with your package!

Thijs


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

Re: RFS: Templayer - HTML Templating Library for Python

[Thijs Kinkhorst]

Hello Ian,

> Templayer is available at: http://excess.org/templayer/

I've taken a look. First, there's no direct link to the source package.
With some manual url manipulation I arrived there
(http://excess.org/dists/unstable/main/binary-i386/) but it's easiest
for a potential sponsor to just provide a direct link to a dir
containing all relevant files.

Second, the location misses the file that's referenced in the .dsc:
python-templayer_1.1.tar.gz. That means I can't unpack your source
package. Make sure you always provide a .dsc, and the files mentioned in
the .dsc's "Files" section.

Third, the package seems to be Debian Native, i.e. one tarball which
includes all Debian packaging, instead of an orig.tar.gz + .diff.gz.
Please see this useful posting for details on why not to package
software as Debian-native that isn't really Debian-specific:
http://lists.debian.org/debian-devel/2006/02/msg01194.html

At least point two needs to be fixed before anyone can even unpack your
package :) Good luck and let us know if you need any more information.


Thijs


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

Re: ifpgui deb - review / upload

[Thijs Kinkhorst]

Hello Jacob,

> I updated the debianization in the ifpgui source package and got their 
> blessing to include it in debian.  Could someone review my packaging and 
> perhaps upload it for me?  :)
> 
> You can download it from my web server here:
> http://www.gnifty.net/code/ifpgui-deb/

Thanks. It looks like you've done some good work on the package, it
already looks in good shape! I have some comments though from a cursory
look:

debian/control:
- Debian Policy has been updated recently, please update your package to
the latest requirements (see the upgrading-checklist in the
debian-policy package)
- From the description I can't decide what the iRiver iFP actually
plays. Is it music perhaps? Maybe clarify a bit more for interested
readers.

debian/copyright: you include two different statements, but do not
really indicate which applies to what. Maybe you can briefly document
what parts of the source are covered by the GPL and what by the SMC
licence. The statement "All Rights Reserved" after which some rights are
released doesn't seem entirely logical but I think it's clear enough
what's intended.

Otherwise it looks good. Unfortunately I can't sponsor you since I'm not
a DD, but I hope these comments are useful none the less. Good luck!


Thijs


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

Re: man1 or man8?

[Thijs Kinkhorst]

On Wed, 2006-05-03 at 16:35 -0700, Tyler MacDonald wrote:
> I can't find a consistent rule for what should go into man1 vs. man8. For
> instance, "apt-get" can be used as an unprivileged user to download source
> tarballs, but it's in man8, whereas "defoma-reconfigure", which can only be
> run as root, is located in man1.
> 
> Under debian, bt_xml2db and bt_db2xml will probably require you to be either
> www-data or root to operate on the installed mod_bt tracker database.
> Should documentation for these tools go into man1 or man8? Is this even up
> to debian, or is it an upstream source thing?

This isn't 100% clear for every case. Of course, when a package is
solely useful to the system administrator to do system administrative
tasks, it should belong in 8, and if it's neither of those it's in 1.
But there's a lot in between like the examples you mention.

I think the question is whether the program is mainly, or in principle,
a system administration tool. If that's the case, it should be in man8.
Like apt-get, where the unprivileged operation is just a small part.

As far as your upstream question, I wouldn't deviate from upstream
unless you have a really convincing argument why the man page placement
is incorrect. And even then, you'd better try to persuade upstream.


Thijs


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

Re: man1 or man8?

[Thijs Kinkhorst]

On Wed, 2006-05-03 at 16:53 -0700, Tyler MacDonald wrote:
>   OK, so according to that, defoma-reconfigure being in man1 (and
> /usr/bin) is a bug, because nobody but root can use it?

Yes, from a cursory look I think that's a minor bug. You should file it,
if the maintainer disagrees he/she will let you know :)

>   I should have been more clear I guess. I am upstream in this case,
> and I'm about to start writing documentation. Based on your advice I think I
> will put it in man8, but install the binaries into /usr/bin, since www-data
> should run them for database backup/recovery.

That could be a valid reasoning, yes.


Thijs


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

Re: RFS moodss

[Thijs Kinkhorst]

Hello Thierry,

On Wed, 2006-04-26 at 18:47 +0300, Thierry Randrianiriana wrote:
> The source is also available at :
> 
> http://mentors.debian.net/debian/pool/main/m/moodss/

I'm sorry that there was a delay before someone could look at your
package. I unfortunately can't upload your package, since I'm not a DD,
but I hope these comments are useful.

Let me state at first that the package looks good in general.

debian/README.Debian: contains information that's interesting, but not
really very important for people who install the package. I'd turn it
into 'regular' documentation. README.Debian is more for major changes
that influence the behaviour of the package since previous versions, for
example.

debian/control: You've updated the standards-version, but a newer
version of Debian policy has been released. Please see the
upgrading-checklist in the debian-policy package.

From the description, short and long, I can't determine at all what the
program does. It love to provide some hints, but I really don't have a
clue what it does. Can you be a bit more concrete?

debian/copyright: it misses the years over which the author asserts the
copyright. E.g.: (c) 2002-2003 John Doe

debian/docs: you're installing install.txt, which is not useful to users
of the Debian package.

debian/rules: please remove commented out commands, since they don't add
any real value to the file.

That's it for now, I hope you can improve the package even more, good
luck!

Thijs


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

Re: RFS moodss

[Thijs Kinkhorst]

On Wed, 2006-05-03 at 18:21 -0700, Russ Allbery wrote:
> Thijs Kinkhorst <[EMAIL PROTECTED]> writes:
> 
> > debian/README.Debian: contains information that's interesting, but not
> > really very important for people who install the package. I'd turn it
> > into 'regular' documentation. README.Debian is more for major changes
> > that influence the behaviour of the package since previous versions, for
> > example.
> 
> Hm, are you confusing README.Debian with NEWS.Debian, maybe?  I think of
> README.Debian as regular documentation.

Sorry, I was. Thank you for spotting.


Thijs


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

Re: RFC: Yorick (scientific interpreted language) & plug-ins

[Thijs Kinkhorst]

Hello Thibaut,

> I know the packages need more work (in particular concerning the
> copyright files, removing commented-out dh_*lines in rules and
> rebuilding under sid), so I am not requesting a detailed review, but I
> think advice on the following few questions would be timely:

That's always a good idea.

> * package granularity: I have currently 7 add-on packages (one more
>   coming soon), each one rather small (few 100K each) but coming from a
>   different upstream and depending on different libraries (like libtiff,
>   zlib and other). Should I keep these add-ons separate or compile a
>   single yorick-addons package? (I need this question sorted out before
>   I start filling ITP bugs).

With 'different upstream', do you mean different upstream tarballs and
upstream authors? Then I'd stick with the
one-source-package-per-upstream approach. Merging stuff from different
upstream sources makes sense when they are very numerous and/or very
small. They do not seem to be exceptionally small, nor is there a very
big number of them.

By the way, the dependencies are only relevant to binary packages. So if
you merge them into one source, you could still create separate binary
packages for each add-on with its own dependencies.

>   I have the reversed question for the upcoming package (yeti,
>   http://www-obs.univ-lyon1.fr/~thiebaut/yeti/yeti-6.0.2.tar.gz )
>   which is indeed 4 plugins: a set of general purpose utilities, and
>   wrappers for regex functionnalities, libtiff and libfftw2. If I stick
>   to one package per plugin, should I split this one?

Ok, are you talking about source or binary packages here? For source
packages, the reasoning might be the same as above.

> * name space: I prepended yorick- to each upstream name to help users
>   find out what add-ons are available, comments welcome. Some upstream
>   names can really not be left untouched: e.g. "curses" for the curses
>   wrapper... Of course this question is resolved if I go for a single
>   package.

I think prepending 'yorick-' to the package names is a sensible thing to
do.

> * version numbers: upstream Yorick is named "2.1.02" although it is very
>   regularly updated on cvs. I'm currently sticking to 2.1.01cvs
>   to be ready when an official 2.1.02 is released. The upstream author
>   (and former Debian packager) is ready to create a CVS tag to give some
>   substance to the version that will eventually go into Debian, even if
>   not making a point release. Do you have any piece of wisdom with that
>   respect? (Note that the CVS version contains changes I asked for for
>   better Debian policy conformance, so I don't want to package the
>   already released version 2.1.01).
> 
>   If I go for grouping all the add-ons in a single package, what version
>   numbers should I use for it?

It should be sensible. Is there a common denominator in the version
numbers of all the contents (e.g. they all start with abc) then you
could use that as a basis. If there's absolutely no connection at all
between the version numbers, you could use the date you put them all
together.


Thijs


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

Re: Google sumer of code, need a DD

[Thijs Kinkhorst]

Hello Mario,

On Thu, 2006-05-04 at 16:36 +0200, MarioDebian wrote:
> I have readed the mentors faq [1] and I have understand that the
> mentor is a student tutor who made a review of student's work along
> the summer.
> 
> I suppose that the mentor have to make a dialog with google summer of
> code admins in money aspects (mentor organization learn 500 $).
> 
> The project is based on shell scripts and understand GNU/Linux init
> process, any DD can help me during project with the possible
> problems

I'm sorry, I don't quite understand what project you'd like to take up.

But this is probably the best way to go about it: Debian is quite large
and has lots of specialised mailinglists (and IRC channels), on
lists.debian.org and alioth.debian.org. Try to find out if there's
already a list or group that's related to the project of your liking.
Contact them describing your project, and try to find someone there that
has knowledge about the area and is willing to assist you.

If you can't find out where to go, we can help you here to look for a
group that might be fit, but then please provide some details about the
project you're interested in.


Thijs


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

Re: RFS : aircrack-ng --- Wireless WEP/WPA cracking utilities

[Thijs Kinkhorst]

Bonjour Le Vert,

I'm not sure of your CC to ftpmaster, so I've removed that CC.


I'm looking for a sponsor to upload the new version of aircrack-ng. I
have already uploaded the 0.3 release but my sponsor has no time for me
for now...


I've taken a look and it looks like a very good package, good work! I've 
got some very small details:


You might consider updating the package to the latest policy version 
3.7.2 while you're at it.


I don't like the directory "stuff" under debian/. Stuff doesn't mean 
anything. May I suggest to move the manpages subdir of that to just 
under debian/, or even just put the manpage straight into debian/? The 
2-level deep structure for one manpage is just a bit overkill if you ask 
me. But in any case, don't name stuff "stuff", or things "things", but 
make sure people can actually know what's in it.


You did forward your patches to upstream?

There's still an "aircrack" package in Debian, but you say it's dead 
upstream. Did you persue any effort to have this newer version replace 
the aircrack package or are there reasons to keep both in Debian?


As said, looks good and I hope someone can sponsor you.


bye,
Thijs


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

Re: RFS : aircrack-ng --- Wireless WEP/WPA cracking utilities

[Thijs Kinkhorst]

On Sun, 2006-05-07 at 15:13 +0200, Le_Vert wrote:
> > There's still an "aircrack" package in Debian, but you say it's dead 
> > upstream. Did you persue any effort to have this newer version replace 
> > the aircrack package or are there reasons to keep both in Debian?
> > 
> > As said, looks good and I hope someone can sponsor you.
> 
> As both aircrack and aircrack-ng can be installed at the same I've
> decided to consider them as two different software. What do you think
> about it ?

To me it's more a question of whether it's useful to keep both. As I
understand it, aircrack-ng can be considered as a newer version of
aircrack. If it can do the same things as aircrack, plus more or better
than aircrack, then I see no sense in keeping aircrack around.

I'd keep aircrack around only if it does things that aircrack-ng can't.


Thijs


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

Re: RFS: advancecomp -- collection of recompression utilities

[Thijs Kinkhorst]

Hello Piotr,

On Sat, 2006-05-13 at 23:29 +0200, Piotr Ozarowski wrote:
> I'm looking for a sponsor for advancecomp (ITP #367112).
> Package is lintian/linda clean and builds in pbuilder.

> dget http://debian.pox.one.pl/advancecomp_1.15-1.dsc

Unfortunately I can't upload your package, but I did take a look.

In general the package looks very good and I could hardly spot any
problems. Therefore I think it shouldn't be a problem to find a sponsor
for it.

Some details I did spot:

- debian/control: you the last line with "Homepage:" has an extra space
  in front of it;

- debian/watch: some people prefer to use
  http://qa.debian.org/watch/sf.php instead of direct queries of sf.net.

That's all!

Good luck,
Thijs


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

Re: RFS: gnome-ppp 0.3.23-1

[Thijs Kinkhorst]

Hello Zak,

> I'm looking for a sponsor for the `gnome-ppp' package.  I got to ITA it
> around 10 days ago,[0] due to my touching it for Ubuntu, and I noticed
> that it needed a new developer to love it =)

> [1]  http://mentors.debian.net/debian/pool/main/g/gnome-ppp/

Thanks for adopting the package. I'm unfortunately unable to upload your
package, but did take a look. In general, the package looks and builds
fine and is free of lintian/da errors.

I did find that the homepage you reference, www.gnome-ppp.org, does not
exist; the domain has expired. You reference it in the description of
the package, the copyright file and the watch file, which I think should
all be changed.

Otherwise, the package looks good and I hope you find a sponsor.


bye,
Thijs


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

Re: RFS: advancecomp -- collection of recompression utilities

[Thijs Kinkhorst]

On Fri, 2006-05-19 at 13:09 +0100, Adam James wrote:
> A minor quibble with your post, the following is from the Debian
> Developer's Reference [0]:
> 
> Note the spaces prepending the line, which serves to break the lines
> correctly. To see an example of how this displays, see
> http://packages.debian.org/unstable/web/wml
> 
> [0]
> http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-upstream-info

Hmm indeed, but to be honest I don't understand dit. I can't tell how
this extra space will aid in the breaking of lines? The only space in
that line will be right after "Homepage:" and I dare say that no
interface is going to have less than 10 characters width...

Can someone give an example where this will go wrong?


Thijs



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

Re: How can a non-DD fix broken packages?

[Thijs Kinkhorst]

On Tue, 2006-05-30 at 21:48 -0300, Henrique de Moraes Holschuh wrote:
> IMHO we really should have a global NMU blacklist (no, never per-package.
> That way lies lameness) which we could ask the ctte to place maintainers in
> for a few months when someone does the NMU-and-forget routine and that NMU
> causes problems: screw up an NMU and don't clean up after yourself, get
> punished by not being able to screw up through NMUs again for a while.

Is this actually such a big problem that there needs to come a separate
infrastructure and procedure for punishment? Or does it only happen
occasionally and would contacting those maintainers to tell them the
results of their actions suffice?

> We should *also* have the pts auto-add anyone who does an NMU to receive all
> bug reports.  If you NMU, you *are* responsible for it, and it is not nice
> to make it so easy for one to forget he NMUed something, after all.

That sounds like a good idea; just send copies to the last uploader if
that's not in the list of maintainers. That would also automatically
stop the mails to you upon the next maintainer upload.


Thijs


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

Re: RFS: revelation 0.4.7-1

[Thijs Kinkhorst]

Hello Stefan,

> I am looking for a sponsor for revelation, since my current sponsor
> ([EMAIL PROTECTED]) is too busy. This version would fix a lot of oben BTS 
> bugs:

Unfortunately I can't upload your package for you, but I did review it
and here's some comments.

* In general the package looks and builds fine, good work!

* debian/control: you're not up-to-date with the latest policy version.

* debian/copyright: this misses some required information, like a
  copyright statement (a la "revelation is copyrighted (c) 1996 by
  John"). It also doesn't mention that the user can choose to apply
  a GPL version > 2 to the software. This provides some guidelines:
  http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html

* You include the file "README" but it doesn't have information that's
  not already elsewhere.

* debian/rules: contains some commented out commands, these can be
  safely removed to clean up.

* debian/changelog: "* fixed
  debian/{copyright,control,.postinst,.prerm}"
  mentioning that some file is "fixed" is not useful information.
  Either mention what was changed or leave it out.

If you address this I'm pretty certain you can find a sponsor.

bye,
Thijs


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

Re: Request for sponorship.

[Thijs Kinkhorst]

> James Pringle <[EMAIL PROTECTED]> writes:
> 
> > HI my name is james pringle i will be coming to ft lewis on june 15
> > i will be at the seattleaiport at 1415on the 15th and am in need of
> > sponor if u would have time for me that would be great thank u for
> > ur time

You are looking for a sponsor or for someone to sign your key? That's
quite a different process. Please make sure you have a good grasp of the
terminology. http://nm.debian.org provides you with pointers.

As for keysigning, if you look at https://nm.debian.org/gpg_offer.php
you can find some people in the Seattle area offering key signing so it
might make sense to contact them. Another source for keysigning outside
of Debian is http://biglumber.com . Good luck!


On Wed, 2006-05-31 at 23:20 +, lcs Mixmaster Remailer wrote:
> Seattle is near Redmond, well-known source of toxic radiation.  Be
> sure to wear your tinfoil hat.  :>

Please only add meaningful content to the mailinglist - thanks.


Thijs


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

Re: RFS: collectd - statistics collection daemon

[Thijs Kinkhorst]

Hello Sebastian,

> I'm looking for a sponsor for my collectd package. collectd is a small daemon
> that collects various system statistics and saves them to RRD files. Since it
> is written in C and stays in memory it is very fast and easy on the system.
> The statistics are very fine grained since the files are updated every 10
> seconds.
> 
> The package is linda and lintian clean and builds with pbuilder.
> 
> The source package is available from
> http://debian.tokkee.org/debian.org/collectd/

Unfortunately I'm not a DD yet so can't upload your package, but I did
take a look and here's the result.

All in all the package looks well-done, good work!

I couldn't find a WNPP bug for collectd. Please file one now, and
mention the bug number in your changelog with a "Closes:" in front of
it.

Your standards-version is a bit behind the most current, so it makes
sense to update it to the most recent policy (3.7.2).

That's it, I didn't spot any other problems on a first sight. Good luck
with finding a sponsor!

regards,
Thijs


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

Re: RFS: flamerobin

[Thijs Kinkhorst]

Hello Damyan,

> I am looking for a sponsor for flamerobin - а graphical database
> administration tool for Firebird DBMS. (ITP# 334489)

I can't sponsor you (yet), but I did review your package. Here's some
things I found.

* debian/control: Architecture is set to "i386 amd64". What prevents
  the package from being usable on other architectures? Are you sure
  you don't mean "any"?

* debian/docs: you install BUILD.txt as documentation, but Debian users
  do not need that info at all. Better leave it out. You install the
  'real' documentation under /usr/share/flamerobin/docs, why not under
  /usr/share/doc ?

* debian/changelog: you mention in the -3 version that that's the first
  upload to the Debian archive, but it's not. Maybe better to not claim
  that and move the text + bug closing to the -4 version.

* debian/patches: what's with the commented out patches in 00list that
  aren't packaged? Doesn't make sense to refer to patches that aren't 
  included. What's the intent of the 137kB patch
  remove-supplied-fbheaders.dpatch? I can't really judge from its
  description, but it's huge - is that necessary?

* debian/postinst,postrm: these are essentially empty and can be
  removed.

* debian/watch: some people prefer to use
  http://qa.debian.org/watch/sf.php instead of direct queries of sf.net.

Otherwise the package looks fine, and I hope you will find a sponsor.

regards,
Thijs


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

Homepage-field in description

[Thijs Kinkhorst]

On Fri, 2006-05-19 at 14:25 +0200, Thijs Kinkhorst wrote:
> On Fri, 2006-05-19 at 13:09 +0100, Adam James wrote:
> > A minor quibble with your post, the following is from the Debian
> > Developer's Reference [0]:
> > 
> > Note the spaces prepending the line, which serves to break the lines
> > correctly. To see an example of how this displays, see
> > http://packages.debian.org/unstable/web/wml
> > 
> > [0]
> > http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-upstream-info
> 
> Hmm indeed, but to be honest I don't understand dit. I can't tell how
> this extra space will aid in the breaking of lines? The only space in
> that line will be right after "Homepage:" and I dare say that no
> interface is going to have less than 10 characters width...
> 
> Can someone give an example where this will go wrong?

I haven't seen any reply to this, and from a quick look over 1000
packages are *not* using the space in front of the Homepage field. I've
not seen any problem with those packages till now. I'm filing a bug
against the developer's reference that this section be changed to not
recommend the space in front.


Thijs


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

Re: Homepage-field in description

[Thijs Kinkhorst]

There's two points to this discussion:
1) The original issue I touched, which is whether the extended advice on
   a space in front of the Homepage 'field' is necessary;
2) A spin-off discussion: do we need a homepage field at all or do
   we need to provide it in another way.

As to the first point:
the developer's reference currently goes to great length to explain how
it should be formatted, whereas frontends like pdo currently handle the
simpler situation just as well (if you shorten your webbrowser to a 20
char width it will still be a valid url). The devref explicitly mentions
that the space is needed for pdo which is quite incorrect.

I remain at my original point that the current devref overregulates this
field with the extra spaces and regex (it uses five paragraphs!), and
should just recommend to add "Homepage: " to the end of the
description if that homepage provides useful information. Could be
stated in one sentence.

On Wed, 2006-06-14 at 21:13 -0700, Russ Allbery wrote:
> We should either provide the link properly (namely in a way that package
> management systems can do something reasonable with it if they desire,
> automated systems can find and present the link if they desire, etc.), or
> we shouldn't provide it at all beyond the copyright file.

This is the second point. As we can see, a packaging frontend like
packages.debian.org currently handles the homepage field well. So we
would not need to change packages for that.

Whether or not the field provides value, I think it does (of course only
if the homepage actually provides useful content). People are searching
for packages with the frontend, and the frontend should give a
reasonable summary of that package (the description). However, we
shouldn't aim to download all information from upstream (extended lists
of features, references to people that use it, screenshots, plans for
the future) into the package, that's not our task.

Afterall, they actually make the software.

If the upstream homepage provides this information, we should refer
people to them for the in-depth information about the package. And we
should do that about as prominent as the description itself.

Referencing in the copyright or watch files doesn't satisfy this; they
are not as prominently accessible as the description and contain a lot
of noise. The current way provides a clickable link, a "see here for
more information". Just what we need.


Thijs


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

Re: Homepage-field in description

[Thijs Kinkhorst]

On Thu, 2006-06-15 at 11:13 +0200, Vincent Danjean wrote:
> It is the case (20-character-wide windows or less) with some terminals
> for blind people... In this case, one more character increase the cost
> of the terminal, so there are not many.

If the terminal is not more wide than 20 characters but the URL is, then
there's no way you can actually display that URL correctly in any case.
It needs to be truncated in some way or the other because it just
doesn't fit, and adding an extra space doesn't help there.


Thijs


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

Re: Who should be listed in Uploaders ?

[Thijs Kinkhorst]

On Tue, 2006-06-20 at 13:25 +0900, Charles Plessy wrote:
> I am in the same situation with some debian-med packages, and I ended up
> adding myself in Uploaders. I think that it is important that the users
> have a clue that there are real persons which take care of the packages.

Yes, and I would personally advise to have a real person to bear the
final responsibility for any package, rather than just a mailinglist.
This might aswell be the person listed in Uploaders in your case.


Thijs


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

Re: Request-For-Sponsorship (xfardic)

[Thijs Kinkhorst]

On Wed, 2006-06-21 at 22:31 +0200, Adam Borowski wrote:
> * On the first upload, debian/changelog should have just one entry.
>   This is somewhat clumsy if you have a history of this package in
>   your private/local repository (like me with debs of kbtin on
>   SourceForge), but I remember someone being shouted upon for this. 
>   I can't recall the reason, but I guess someone can say what it was. 

I'm not sure about a specific incident, but in general I'd say that for
an otherwise unreleased package, more than one changelog entry is quite
redundant. There's no reason to bother people with the different
versions that never left your hard drive, so why include it? Keep it
simple.


Thijs


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

Re: Request-For-Sponsorship (xfardic)

[Thijs Kinkhorst]

On Fri, 2006-06-30 at 11:49 +0300, Jari Aalto+mail.linux wrote:
> The history in package indicates that there has been work going on
> before the package was added to Debian. The history documents the
> changes and gives indication of overall activity and competence the
> package was previously handled. A comment "First initial official
> Debian release" will clearly indicate when the package become part of
> the Debian.

Maybe I was not clear enough. I did not mean that a previous changelog
shoud never be included; however, I think one needs to be critical not
to include 'virtual' versions on one's own harddrive that offer no real
information to the user.

I've seen changelogs with the following different versions: (1) initial
packaging, (2) fix a typo in this-and-that, (3) update description for
lintian, (4) initial release. That just doesn't add anything.

It's no disaster of course, but worthwhile to check if including some
'versions' that only you yourself have seen actually makes sense.


Thijs


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

Re: bug got stuck in "Fixed and Pending"? How comes?

[Thijs Kinkhorst]

Hello Harald,

> http://packages.qa.debian.org/b/blockade.html shows that
> bug #346938 is set to "Fixed and Pending" :-{. This
> bug was fixed more that 6 months ago, so what is the
> BTS waiting for?

The upload that fixed the bug, 20041028-9, contained these fields:
| Maintainer: Marc 'HE' Brockschmidt <[EMAIL PROTECTED]>
| Changed-By: Harald Dunkel <[EMAIL PROTECTED]>
and thus, this is considered an NMU (the one uploading != the maintainer).

A fixed-in-NMU (tag 'fixed') bug is not closed. You need to close it
separately. I see you have done that today. Good, that means that it's
now considered closed, and the PTS will update later today to reflect
that.

One more note, you closed the bug with the message "This bug was fixed
in version 20041028-9.". You should have added a "Version: 20041028-9"
pseudo-header to your mail so the BTS version tracking handles this
correctly.


Thijs


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

Re: changelog of debian policy?

[Thijs Kinkhorst]

Hello Harri,

> Is there a changelog of the Debian policy online?
> Actually I would have expected a pointer on
> http://www.debian.org/doc/debian-policy/, but maybe
> I am too blind to see.

That depends on what information you need. If you're refering to the
packaging of the policy, that URL's have passed by now. But what I guess
you mean is the changes between policy versions, i.e. what you need to
change to upgrade a package's standards-version. That information is
in /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. I don't
think that's available online though.


Thijs


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

Re: changelog of debian policy?

[Thijs Kinkhorst]

On Sun, 2006-07-02 at 12:25 -0700, tony mancill wrote:
> It might be nice to distribute it as html and/or fix-up the reference in
> section 1.2 to point this file.  Perhaps the checklist could be referenced
> as an appendix or the like so that the  tag could be used, and then
> dwww could easily find it as well.  However, I'm not sure whether this is
> wishlist bug-worthy or not.

If you think it's a useful addition that might be useful to others
aswell, it surely is worth a wishlist bug (such a bug isn't quite
expensive). Whether the maintainer implements it is of course a
different question, but expressing your wishes for improvement is always
a good idea.


Thijs


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

Re: Procedure for adopting a package?

[Thijs Kinkhorst]

On Sun, 2006-07-02 at 22:53 +0200, Bartosz Fenski aka fEnIo wrote:
> Please don't feel offended. I tried to contact you several times and
> I hijacked this packaged because I couldn't do that. 

In the future, an NMU might be a better start for improving a package
that lacks care, rather than hijacking it right away.


Thijs


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

Re: RFS: mp3togo - Audio transcode utility for portable players

[Thijs Kinkhorst]

Hello Simeon,

On Tue, 2006-07-04 at 23:41 -0700, sim wrote:
> I am looking for a sponsor for my package "mp3togo".

I've taken a look at your package, and have the following comments, from
important to nitpicks:

* The package is a debian native package although it's not Debian
  specific. That situation is by many considered undesirable, as
  has been discussed on this list and other places a couple of times;
  see the archives. I suggest you "release" a tarball of your
  program and package that as a non-native package.

* Building the package yields a huge warning:
  
  Your package does not conform to the new Python policy.
  Please consider updating.  Here is some documentation:
  http://wiki.debian.org/DebianPython/NewPolicy
  http://wiki.debian.org/DebianPythonFAQ
  

* The file 'README' mentions a set of years that's disjunct from the
  years mentioned in 'debian/copyright', and 'copyright' mentions
  an interval that covers both. What is it?

* You install README under /usr/share/doc but it doesn't provide
  relevant information for Debian users (e.g. build info) that isn't
  available already.

* copyright mentions "All rights reserved", but not all rights
  are reserved as mentioned below that. "Some rights reserved"
  may be better.

* LICENCE has an outdated FSF street address.

That's it for now, good luck!


Thijs


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

Re: RFS: tcpser

[Thijs Kinkhorst]

Hello Peter,

> I am looking for a sponsor for my package "tcpser".

I haven't fully checked your package out, but I noted that there's no
Intent To Package (ITP) bug filed for it. It's good practice to do that
beforehand, so you might aswell do that now, and list the bug number as
being closed in your changelog.


Thijs


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

Re: RFS: tcpser

[Thijs Kinkhorst]

On Thu, 2006-07-06 at 05:54 +0100, Peter Collingbourne wrote:
> For some reason mentors.debian.org won't take, here is the new location:
> 
> http://www.doc.ic.ac.uk/~pcc03/tmp/debian/tcpser_1.0rc10-1.diff.gz
> http://www.doc.ic.ac.uk/~pcc03/tmp/debian/tcpser_1.0rc10-1.dsc
> http://www.doc.ic.ac.uk/~pcc03/tmp/debian/tcpser_1.0rc10.orig.tar.gz

Excellent, uploaded.


Thijs


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

Re: RFS: gpsd - GPS (Global Positioning System) service daemon (bugfix upload)

[Thijs Kinkhorst]

Hello Tilman,

> I'm looking for a one-time sponsor for the gpsd package. My usual
> sponsor is not available at the moment, and the new upload would fix a
> serious bug.
> 
> The changes to the previous revision consist of two lines only, not
> counting the changelog.

When I diff the package with the version currently in the archive, I get
a lot more changes than that, mostly in the documentation/manpages it
seems. Did you upload the right version?


Thijs


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

Re: RFS: pmplib - create music databases used by portable media players

[Thijs Kinkhorst]

On Mon, 2006-07-03 at 00:30 +0100, Martin Ellis wrote: 
> I'm looking for someone to review the package as it stands, in order
> that any necessary changes for inclusion in Debian can be made
> before 0.12 is released.

Sure, no problem, here goes. In general the package looks good, good
work! I've got two small points:

* You install the upstream README, but that contains no relevant
  information (licence info is already in copyright);

* Upstream COPYING has an old FSF address.

Good luck with your package!


Thijs




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

Re: Temporary sponsor for ldap-account-manager

[Thijs Kinkhorst]

Hello Roland,

> can somebody check the 1.0.3-1 release of ldap-account-manager and
> upload it? My sponsor has hardware problems and will not be able to do
> the upload until next week.
> 1.0.3-1 closes a security related bug.

I've uploaded it.

One problem: I just realised that the urgency of the upload was 'low'
which should have been 'high'. No need to reupload, you can ask on
#debian-release to have it bumped.

Is the version in sarge vulnerable? If it is, you should contact the
security team and present them with a minimally patched package. If you
need help with that you can always ask of course.

Thanks for your work.


Thijs


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

Re: jlj package

[Thijs Kinkhorst]

On Sat, 2006-07-15 at 21:35 +0100, Michael Stevens wrote:
> #debian-mentors suggest this is unacceptably vague. Any suggested
> approaches to the upstream author? I've failed to get a response from
> him on other matters so far.

Contacting him is of course the best way to resolve the issue. I think
it works best if you suggest a concrete licence and ask if he agrees
that his software be distributed under that licence.

In this case, putting it in the public domain seems to match the intent
of the original author best, or a BSD licence.


Thijs


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

Re: plea to sponsees about announcing location of packages

[Thijs Kinkhorst]

On Tue, 2006-07-25 at 13:30 +0200, Christoph Haas wrote:
> > And being on the whishlist line, May long description be included in
> > the RFS templates too?
> 
> I'm open to suggestions. The importer that processes uploaded packages just 
> takes into account the *.dsc and *.changes files AFAIK. None of them 
> contain the one-line description of the package. I had to take the diff.gz 
> (unless it's a native package) and extract the debian/control and parse 
> it. Or perhaps "dpkg-source -x ...dsc" and then access 
> $PKG/debian/control. Hmmm. Ideas?

Actually, the .changes file does contain the short description:

---
Maintainer: Jeroen van Wolffelaar <[EMAIL PROTECTED]>
Changed-By: Thijs Kinkhorst <[EMAIL PROTECTED]>
Description:
 squirrelmail - Webmail for nuts
---


Thijs





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

Re: plea to sponsees about announcing location of packages

[Thijs Kinkhorst]

On Thu, 2006-07-27 at 12:48 +0200, Magnus Holmgren wrote:
> > > What's wrong with apt-get source?
> >
> > You have to add a line to /etc/apt/sources.list to make it work.
> 
> Yes, but only once. It's still a useful alternative for anyone that
> checks out source packages from mentors.debian.net regularly.

Only once for every possible repository where a sponsor might have
stored their packages. Mentors is far from the only one.


Thijs


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

Re: Override disparity

[Thijs Kinkhorst]

On Mon, 2006-08-07 at 22:26 +0900, Charles Plessy wrote:
> > There are disparities between your recently accepted upload and the
> > override file for the following file(s):
> > 
> > muscle-doc_3.60-1_all.deb: package says section is doc, override says 
> > science.
> 
> I searched the policy, but did not find anything about this particular
> kind of override. Could anybody point me to a relevant documentation ?

This refers to the override file as maintained by the FTP-masters.
That's the canonical file that tells in which section a package is and
which priority it has. The fields in your package are just
informational.

This message means that there's different information in your control
file than in that of the FTP-masters. Usually, you need to change your
packaging to reflect the override file (since that's canonical), but if
you believe that your section is actually better, you can contact the
FTP-masters to discuss it.


Thijs


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

Re: NMU of #370144 from BSP at Mexico

[Thijs Kinkhorst]

On Sun, 2006-08-13 at 23:25 -0500, Carlos C Soto wrote:
> Hello mentors!
> I was in a squashing party in Mexico DF, thank to Gunnar for all the 
> help, damog, rodrigo and many others.
> 
> I made a diff patch for bug 370144  mkvtoolnix.
> I want to make a NMU to corrent this bug. All the information is in the 
> bug page.
> I'll be glad if any of you can make the upload.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370144

Thanks for the work, but that bug has been release critical for just two
days now. Given the NMU policy, we can make uploads for RC bugs after 7
days. If it's still present next Monday, I can review and upload your
NMU.


Thijs


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

Re: NMU of #370144 from BSP at Mexico

[Thijs Kinkhorst]

On Mon, 2006-08-14 at 11:49 +0100, Colin Tuckley wrote:
> Thijs Kinkhorst wrote:
> 
> > Thanks for the work, but that bug has been release critical for just two
> > days now. Given the NMU policy, we can make uploads for RC bugs after 7
> > days. If it's still present next Monday, I can review and upload your
> > NMU.
> 
> We are in BSP mode at the moment - the 7 day restriction is reduced.

"During the BSP we should use a 0-Day NMU policy again, that means
uploads that fix RC bugs that are more than a week old can be uploaded
directly."
  -- http://lists.debian.org/debian-devel-announce/2005/08/msg00015.html

Please not the difference between the age of the bug and the waiting
time after you announce the intent to NMU. Only the latter has been
reduced.


Thijs


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