from:"Patrick Schoenfeld"

Charles Plessy wrote:
> Fortunately, the wise people who wrote the Social Contract made it
> clear:
> 
>   We have created contrib and non-free areas in our archive for these
>   works. The packages in these areas are not part of the Debian system,
>   although they have been configured for use with Debian.

Unfortunately it does not seem that clear, because policy states, that
packages for its inclusion in main "must not require a package outside
of main for compilation or execution (thus, the package must not declare
a "Depends", "Recommends", or "Build-Depends" relationship on a non-main
package)".
So according to the policy (as I understand it) steam (which is - as of
what I've got from in this discussion - GPL) would go to main, as it is
*not* non-free nor does it require any non-free software to be
installed. Even if it is *used* to install non-free software, it does
not depend on it (via the usual depend mechanisms). So in sense of the
policy, steam would be a main-candidate. But it seems that here
arepeople, that either do not accept this or interpret it other then I do.

Regards,
Patrick

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

Re: RFS: steam-powered

Patrick Schoenfeld schrieb:
> Charles Plessy wrote:
>> Fortunately, the wise people who wrote the Social Contract made it
>> clear:
>>
>>   We have created contrib and non-free areas in our archive for these
>>   works. The packages in these areas are not part of the Debian system,
>>   although they have been configured for use with Debian.
> 
> [...]

Please ignore what I have written. I found out that this package just
downloads non-free software in the style of e.g. msttcorefonts and
therefore i understand that it is not suitable for main. Anyways I think
that policy could need some polishing cause it is not clear enough in
this point, cause it says by its exact wording that it requires Depends:
etc. for contrib, which is not the only way to depend on things in case
of such meta-packages.

Regards,
Patrick

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

In-Program documentation

Hi there,

I'am currently in progress of packaging password-gorilla, which is a
tcl/tk application. Well everything is fine so far, except that the
application contains menu items LICENSE and HELP which rely on files in
the source distribution, which I currently install with dh_installdocs.
So basically I need to make these files available to the tcl/tk scripts.
But how should I do this properly?

1) Variant 1:
I could install the files to /usr/share/doc, but not with dh_installdocs
 so that they don't get compressed and then link them to the target
directory (/usr/share/password-gorilla).

2) Variant 2:
Install them to /usr/share/doc AND to the target directory.

3) Variant 3:
Install them only to the target directory.

It seems to me as if variant 1 would be the only that makes sense. But
is this okay? Is there another way to do it? What would you recommend?

Regards,
Patrick


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

Re: In-Program documentation

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Norbert Preining wrote:
> dh_installdocs does not compress (AFAIR), it is dh_compress. And you can
> give dh_compress the -X option to exclude those file from being
> compressed.

Yeah. When i acutally tested what i meant it revealed that dh_compress
- -X would do the trick, not installing in another way.

> Variant 4, probably to be preferred:
> Install it into /usr/share/password-gorilla/ and add only a link from
> /usr/share/doc/password-gorilla, so that they won't be compressed.

So variant 4 is just variant 1, except that i don't use another install
method. Just "dh_compress -XLICENSE.txt -Xhelp.txt", then appropriate
links in debian/link with dh_link and voila? Seems to be the cleanest
method to me and is more or less what I wanted to do. You agree with this?

Regards,

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

iD8DBQFG3cVkTKIzE6LY9r8RAroRAJ9S1fWBIE32A5/zo2IkYZ9s8qtEAgCeMMbM
qIwebYBIIW2wSPuI08nIb2w=
=Wy/R
-END PGP SIGNATURE-


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

Re: RFS: cellwriter

2007-09-06 Thread Patrick Schoenfeld

Michael Levin wrote:
> Accidentally filed two (#441087, #441088) but the changelog closes both
> of them.

You know, that bugs can be merged?

Regards,

Patrick


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

Re: daemon stop and start during upgrade

2007-09-11 Thread Patrick Schoenfeld

Adeodato Simó schrieb:
> Your init.d script should *not* exit with status non-zero if the daemon
> was already stopped. You can do that either by passing --oknodo to
> start-stop-daemon, or by checking by hand if the return status is 1.
> *Not*, in any case, by appending "|| true", since that would hide the
> case when a real errors occurs and the daemon can't be stopped.

Hm. If i think about this topic it appears to make sense to let
invoke-rc.d not fail (I actually do it like this), but I'm asking myself
the question why this is not formalized in the policy? Cause it is a
discuss able point if you think on it from this side: If nothing is
there to be stopped, then the requested action (say: stopping something)
obviously failed. But then again, we know that it does not make much
sense to let an upgrade fail, just because any admin stopped a daemon.
So rationale there are reasons for and against letting stop fail with a
non-zero exit code if there is nothing running, which could be stopped.
It would be a pro to take this into the policy, wouldn't it?

> If you wrote your init.d script from some template that advocates
> returning directly the exit status of start-stop-daemon without
> --oknodo, that template needs fixing.

Hm. It would be better to fix start-stop-daemon, cause policy does
*hardly* recommend to use it, while it does not have any recommends
about which template you may use. So it seems like not the template is
wrong, but the behavior of start-stop-daemon is wrong. Or not?
But then again it makes it hard to decide that, because policy does not
have a rule for this case.

Regards,
Patrick


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

Re: daemon stop and start during upgrade

2007-09-12 Thread Patrick Schoenfeld

Justin Pryzby schrieb:
>> It would be a pro to take this into the policy, wouldn't it?
> 
> It is 9.3.2:
> 
> | [...]

No, it isn't. This part of the policy just says that it should not kill
other processes, which are eventually named unfortunately, just because
the process it *should* kill does not run. It does not say anything
about how the init script should behave, if the application is not
running. But, and thats important, this does again recommend to use
start-stop-daemon which exits with a non-zero exit-code if there is
nothing to stop.

> It's a very interesting question whether packages should inhibit
> starting a daemon that wasn't running when it would otherwise have
> been stopped.  I guess the current state of affairs is that a

That is another thing, but yes, I agree that this is very interestering
as well.

> think the ideal situation is that a manually-stopped daemon would
> cause a message to be printed: "Not starting food: not stopped at
> preinst time" in the same style of messages that are shown with
> [...]

ACK. I think this would be a good proposal. But how to realise this
properly? It would need a change to the init script, would it?

Regards

Patrick


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

Re: daemon stop and start during upgrade

2007-09-12 Thread Patrick Schoenfeld

Felipe Sateler wrote:
>  - Behave sensibly when invoked with 'start' and already running
>  - Behave sensibly when invoked with 'stop' and not running

Ah.. yeah, that would be a possible interpretation of the policy. But
formalizing something as to "behave sensibly" is not really exact, cause
it is up to the reader how he interprets it. I do interpret it like this:

- Don't do nasty things with 'start' when already running (like killing
the firsts pidfiles, launching a seconds instance, etc.)
- Don't do nasty things with 'stop' when not running (like killing other
processes or changing something in the environment so it won't start the
next time).

I understand it so, that the third one is just there to describe it more
exactly. Because exiting with zero or non-zero has absolutely nothing to
do with "behaving sensibly". Actually returning a non-zero exit code is
the right thing to do, cause the action to stop a process _did_ fail,
because the process has not been running. Then again it would be
"sensible" not to let the upgrade process fail just because of this, but
i think thats far from the scope.

So in the end I agree that would be sensible to exit with 0, if the
process is not running, cause their might be different errors to occur
when stopping (even though I never met one), but that it would make
sense to describe this more clear in the policy.

Regards,

Patrick

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

Re: daemon stop and start during upgrade

2007-09-13 Thread Patrick Schoenfeld

Felipe Sateler schrieb:
> Not really. It also depends on how you see it: if I ask some process to

Sure. Thats exactly what I'm saying.

> stop,  I don't care if it was running or not. All I care is that it does
> end up stopped. I see it like this:

Really? So maybe *you* don't care about the services state when you stop
it. But *I* could expect it to be running, if I ask it to stop. Because
something could be wrong, if the service is not running, I want to know
if it isn't. OTOH its not me requesting the service to stop, but a
process that can't know that I eventually stopped the service, because I
wanted to do.

Well doesn't matter, really. I agree to what you are saying. But the
point is, that others could see that different. Thats were rules and
policies come in handy.

Regards,
Patrick


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

Re: RFS: mirmon

2007-09-15 Thread Patrick Schoenfeld

Hi,

Hideki Yamane wrote
> [...]
> The package can be found on mentors.debian.net:

IANADD but anyways some (hopefully useful) comments.

- debian/rules:
  * There is no reason to keep all those comments, that come from
the template you are using for it
  * Is there any reason to recreate the (already existing) manpage
during build? Eventually the other way round: Is it needed to have
a manpage in debian/ if you create a newer version of it during
build? Also this causes the clean target to be (afaic) not
policy-confirm, cause it leaves changes to the source unreverted.
  * i would also remove the un-needed empty lines (like the ones between
#export DH.. and CLFAGS)
  * you have a lot of uncommented debhelpers in your rules file. there
is no reason to keep them in the file.
  * is there a reason why you create the patch/unpatch targets yourself?
you could use dpatch.make (see dpatch.make(7))
- debian/copyright:
  Seems like you copied the license text from a source file due to the
  comment signs. should be removed, imho.
- debian/watch
  Is there a reason for the empty lines at the end of the file?

General comments:
The programs default location contains a state definition, which points
to a place inside the document root. would that normally be wanted?

Regards,
Patrick


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

Re: Sponsor for multipipe

2007-09-16 Thread Patrick Schoenfeld

Hi,

Christopher Zimmermann schrieb:
> I just packaged the small multipipe tool from
> http://sourceforge.net/projects/multipipe.

IANADD but anyways, here are some (hopefully useful) comments:

At first: You would help potential sponsors a lot if you could post more
information about your package / the software you package. Like Author,
Upstream URL, license, etc. You should consider your sponsorship request
as an ad for your package, as such more information on first sight makes
it easier to get some DD to sponsor your upload. But at least should you
point a direct link to the .dsc file so that DD can use dget to get your
package.

Ok, but to go on:
- debian/changelog: You should file an ITP bug for this package and
close this one in the changelog (by adding (Closes: #))
- debian/copyright: According to the policy this file needs to include
informations about copyright(s), upstream author, upstream location and
license. See Policy 12.5 for more information.
- debian/rules:
  * there is no need to keep the comments derived from the dh-make
template
  * there are some uncommented entries, like line 38 or 72-83. If you
don't need them, then don't keep them.
  * using dh_install for the installation of just one binary seems
to be an overkill. i recommend you to use install instead. you can
use with -D, then it will also create usr/bin which makes
debian/dirs and the dh_installdirs call not needed

Best Regards,

Patrick


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

Re: RFS: mirmon

2007-09-17 Thread Patrick Schoenfeld

Hi,

Hideki Yamane wrote:
>>   * Is there any reason to recreate the (already existing) manpage
>> during build? Eventually the other way round: Is it needed to have
>> a manpage in debian/ if you create a newer version of it during
>> build? Also this causes the clean target to be (afaic) not
>> policy-confirm, cause it leaves changes to the source unreverted.
> 
>  added remove target in rule file.

ah.. this manpage isn't part of the upstream source is it?

>  Because I'm using debhelper style.

It was just a suggestion, cause i find dpatch.make more convenient.

>> General comments:
>> The programs default location contains a state definition, which points
>> to a place inside the document root. would that normally be wanted?
> 
>  Upstream did that.

Well, then I don't see a reason to change it, even though it seems
suspicious to me.

Regards,
Patrick


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

Re: RFS: ario

2007-09-18 Thread Patrick Schoenfeld

Michal Čihař wrote:
> I just noticed one more thing - as we now have Homepage field support
> in dpkg, please use it instead of URL pseudo tag (some tools will
> complain about Homepage for now, but you can ignore it).

Is this field really available at the time of writing? (I'm just aware
of #433469 which is not closed as I am writing this). And: If it is,
then is it (properly) supported by packages.debian.org?

Gruß
Patrick

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

Re: RFS: gnome-color-chooser

2007-09-18 Thread Patrick Schoenfeld

Jon Dowland schrieb:
> On Tue, Aug 28, 2007 at 07:19:22PM +0200, JackTheDipper wrote:
>> - dget 
>> http://mentors.debian.net/debian/pool/main/g/gnome-color-chooser/gnome-color-chooser_0.2.2-1.dsc
> 
> My initial test with debuild did not work:

I can confirm this. Your clean target is wrong. With this commented out
I have additional comments (note, that I am not a DD so this is just for
your help:

* You obviously miss all build-depends. Thats the reason why the
configure target fails with missing dependencies. You should try to
build your package in a e.g. pbuilder environment, so that you see what
dependencies your package has.

* debian/rules:
- No need to keep template comments
- What does this ifneq construct do in the config.status
  target? The build process should not make any assumptions on
  what might exist on the build system and should not use
  anything outside of the package (IMHO)
- No need to keep commented debhelpers
- dh_installman seems to be useless as you don't ship a manpage
- there are plenty whitespaces at the end of lines, you should
  remove them
* debian/copyright:
- I don't think that "JackTheDipper" is a valid legal person,
  therefore i consider debian/copyright to be invalid. It may
  be better to contain real names.
- a lot of empty spaces at the end of line
* debian/dirs (and dh_installdirs in rules) seems useless. Directories
will normally be created by the makefiles so this is double effort. But
I can't tell for sure as it does not build.
* debian/changelog:
- Again: I don't think that "JackTheDipper" is a valid legal
  person.
* debian/control:
- Description is invalid. See 3.4 in the debian policy for  
  informations about this.

Regards,

Patrick


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

debian/watch, sf.net and -dev versions

Hi there,

the following is a problem that I already had with another package where
a solution for this is also pending. The problem is the following.

A Sourceforge project, for which I create the packages, does have
several files on sf.net. One is the stable tree with a version like
1.4.x and then it has a -devel tree with a version like 1.5.x. If i scan
 for upstream versions with a standard debian/watch like this:

version=3
http://sf.net//-(.*)\.tar\.gz

Then it will report every development version as a newer version, which
is wrong. On the sourceforges projet site this files are divided into
different packages, on called  and one -dev. Is there
any way to handle this properly? I currently think of changing the regex
to contain a fixed version part (1.4.*), but that would break as soon as
upstream decides to release a stable 1.5.

Anny ideas?

Regards,
Patrick


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

Re: debian/watch, sf.net and -dev versions

Kumar Appaiah wrote:
> If you are sure that they use only dots and numbers, you may wish to
> use ([\d\.]+) instead of (.*) for versioning.

How would that help me? This would match digits and points as part of
the version instead of everything and so it would also consider 1.5.x to
be newer then 1.4.x.
Which is right, if one just compares version numbers to each other. But
then again I do package only stable versions of the software, so I don't
mind those -dev versions. Ehm. To make it more clearer. The package name
has the same scheme:

-1.4.1 for example vs. -1.4.2

The only difference is - in sourceforge terms - a different package name.

> Could you please tell us the package you are interested in, if this
> doesn't help?

Well, the one I used for the example is not actual anymore, as I noticed
that the program I wanted to package is already part of mysql-client.
But another package where I have this issue is mantis.

> P.S. [OT] For sf.net, if you want a standard directory listing instead of
> using the watch sf.net workaround, try
> http://heanet.dl.sourceforge.net/sourceforge/, for example:
> http://heanet.dl.sourceforge.net/sourceforge/maxima/

Thanks, for this tipp, but that does not help me either.

Thanks in advance for any useful information,
Best Regards

Patrick

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

Re: debian/watch, sf.net and -dev versions

Hi,

Daniel Leidert schrieb:
> Then use
> 
> http://sf.net//-([\d\.]+)\.tar\.gz
> 
> I always use this to avoid matching on packages like
> package-foo-x.y.z.tar.gz, if I want to match on package-x.y.z.tar.gz

no this does not help me. I think there is a misunderstanding.

The filenames of the packages are identical. Its always
package-version.tar.gz. And it is _one_ project page. You can see this
for one of this packages here:

http://sourceforge.net/project/showfiles.php?group_id=14963

You see that Sourceforge calls it package. But I think it would be
better described as a branche. The question is if I can use this
sourceforge package name in some way. (In the file listing directory
they show up all in one directory, so this does not help).

Regards,
Patrick


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

Re: debian/watch, sf.net and -dev versions

Daniel Leidert schrieb:
> Well, you removed the second proposal from my answer, which exactly
> handles this case (I e.g. have a similar problem for gchempaint and
> gnome-chemistry-utils, see the debichem SVN). So I'm wondering, why you
> didn't give it a try?

Well, probably because it is _not_ handling the case. It is eventually a
temporary hack to get it running for the moment, but not a solution.
Because upstream is not making a difference between odd and even version
numbers by intension. Its just coincidence that it happens like that. I
don't like to build a debian/watch file on coincidence, cause thats
likely to break in the future (as early as 1.1.x is released as the next
stable release).

So i cannot take this package names of sourceforge into account, but
need to base something on the versioning scheme?

Regards,

Patrick


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

Re: debian/watch, sf.net and -dev versions

Daniel Leidert schrieb:
> version=3
> http://sourceforge.net/project/showfiles.php?group_id=14963&package_id=166159 
> .*mantisbt\/mantis-([\d\.]+)\.tar\.gz.*

Thanks. I will test that und use that concept for further packages.
Seems to be an example of not seeing the forest cause of so much trees,
because that solution seems to be the obvious one.

Best Regards,

Patrick


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

Re: RFS: gimmix

2007-10-01 Thread Patrick Schoenfeld

Hi,

IANADD but anyway some comments:

On Sun, Sep 30, 2007 at 12:48:36PM +0200, Vincent Legout wrote:
> It builds these binary packages:
> gimmix - Graphical music player

It appears to be inappropriate to speak a about a music player as it would be a
standalone music player, if in reality gimmix is *just* a frontend to mpd. So I
think you should change your description.

debian/menu: gimmix is a graphical application so it makes sense to have menu
entries. You lack an appropriate menu file, which is (IMHO) essential because
update-menus handles other window managers then those supporting the .desktop
file properly, while currently those users may have to search for your
application.

Regards,

Patrick

signature.asc
Description: Digital signature

Re: Bug#444514: marked as done (gpredict: FTBFS: error: 'GtkTooltips' undeclared)

2007-10-15 Thread Patrick Schoenfeld

Hi,

IANADD, but...

On Sun, Oct 14, 2007 at 01:28:36AM +0200, Cyril Brulebois wrote:
> Shall we open bugs for each and every problem encountered, with
> individual patch, and then check them regularly through the QA? Or fix

yes, thats probably the best way to go.

> them all while we're at it, and then be slapped by the maintainer, and
> eventually some of them reverted or fixed in a different way? I took the
> second road until now, increasing my blame counter from 0 to 1.

Thats probably not the way to go. Consider that NMUs purpose is to fix bugs (!)
if serious problems are to be addressed and the maintainer is not able to do an
upload in a timeley manner. See the developers reference for best practices:

http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu

It states: "Do not do housekeeping tasks, do not change the name of modules or
files, do not move directories; in general, do not fix things which are not
broken. Keep the patch as small as possible. If things bother you
aesthetically, talk to the Debian maintainer, talk to the upstream maintainer,
or submit a bug. However, aesthetic changes must not be made in a
non-maintainer upload."

Regards,

Patrick

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

Re: Bug#444514: marked as done (gpredict: FTBFS: error: 'GtkTooltips' undeclared)

2007-10-15 Thread Patrick Schoenfeld

On Mon, Oct 15, 2007 at 08:36:26PM +0900, Charles Plessy wrote:
> in the past, I followed those rules for an obviously unmanitained
> package, and all it resulted in was that a DD ignored my NMU patch and
> uploaded his own NMU which contained all the fixes I refrained to
> include... (and I think he made the good choice).

I'm unsure where the relation to the current case is.

> Since the maintainer is not a DD and is apparently inactive for one

No? The maintainer of gpredict appearently is active (he answered in this
thread..) and a DD.

> year, I would recommend Cyril to ask on -devel, and -qa if he can orphan
> the package, and then propose comprehensive NMU.

But also if he wasn't a DD there is no reason to ignore the processes meant to
be used. Before assuming that someone is appearently inactive someone should at
least try to *contact* the maintainer, regardless of weither the maintainer is
a DD or not. I'm missing that step in your list.

BTW. in Cyrils case I don't see how it makes sense to orphan and adopt the
package? He did an NMU and the maintainer complained that it was to intrusive
and so Cyril asked what policy he should follow.

Regards,

Patrick

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

Re: Bug#444514: marked as done (gpredict: FTBFS: error: 'GtkTooltips' undeclared)

2007-10-16 Thread Patrick Schoenfeld

On Tue, Oct 16, 2007 at 01:05:32PM +0200, Cyril Brulebois wrote:
> wdg-html-validator‽

Forget it. Must have made something wrong when calling your link,

> I'm pointing you to the messages in the buglog of the gpredict package,
> so that you stop lacking context.

Well. I don't understand that...

> > And as far as I see the maintainer of gpredict is pretty active, so
> > the idea to orphan this package and hijack it seems a bit odd.
> 
> Did I ever say that? I NMU'd grig, fullstop. And again, I didn't NMU
> gpredict.

.. with knowledge of that. But that does not matter, because I said that I
don't argue about what you've done or said, but:

> > That wasn't critism at you, but at Charles for his idea to hijack a
> > somewhaat okay maintained package.
> 
> I had several things to write, and answering to your mail seemed more
> relevant than to Charles'.

Yeah, but you always forget to see *my* sentences in the context of my
statement stated above. It was not meant as a critism at you, so I haven't
checked the context, because I does not care. But it seemed as if gpredit were
on topic (because of the subjects, the bug reports, etc.) because i did not
study the backlog in detail AND Charles was the one who talked about just
orphaning and adopting.

So to make it clear: I don't have any critisims about what you've done and I
never had any!

> You might have forgotten you wrote:
> > But also if he wasn't a DD there is no reason to ignore the processes
> > meant to be used. […]

No, i haven't forgotten, but...

> And I'm defending that I followed that process, since this particular
> case is being debated again and again.

... again: You don't need to defend anything, because I never attacked *you*. 
And thats also why it does not matter in this case.

> Then someone has to take care of the package… You might want to bug the
> devref so that it mentions it is better to send both a personal mail and
> a mail to the buglog. I wrote to the bug as always, because it gets
> archived and because of the publicity.

You are right. I've misread the devref, so it is just my opinion, that one
should try to contact the maintainer additionaly to the bts entry by a mail
directed towards him.

> If an “FTBFS” thread is to be  overseen, then it looks like clear
> that time is lacking, and that someone has to fix the bugs, but YMMV.

You are right. It might mean that time is lacking and to NMU and helpout is
okay if contact to the maintainer were made. I was not argueing about this,
except that I think it would be good to contact maintainer directly by mail and
that I find Charles proposed behaviour inappropriate.

> Again, I didn't say anything about adopting or orphaning. Or I can't
> read the mails I already sent.

Hehe. No: The problem was that you seem not to be able to read _my_ emails.

> <[EMAIL PROTECTED]> looked alike, hence my defense.

Well, the mail you are talking about where In-Reply-To:
<[EMAIL PROTECTED]> -- the mail from Charles.

> And that's my last mail to this thread, since I'm “irritating you a
> bit”.

Well, now things are more clearer, so actually talking about something where
somebody is irritated is probably the best we can do.

Best Regards,

Patrick

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

Re: Bug#444514: marked as done (gpredict: FTBFS: error: 'GtkTooltips' undeclared)

2007-10-16 Thread Patrick Schoenfeld

On Tue, Oct 16, 2007 at 01:18:11AM +0200, Cyril Brulebois wrote:
> There's no need to be a DD to answer to a (RC) bugreport. There's no
> need to be a DD to answer to a mail announcing an NMU uploaded to
> DELAYED/*5*. I can understand one might need time to prepare an upload

BTW. apart from what I've stated in along with this thread
(Again: Don't think of it is critism, I just try to understand that):
I see that there was some time between bug posting and preparing the NMU, so
this part of the process is as normal. But is there a specific reason to upload 
to DELAYED/5
instead of DELAYED/7 how the developers reference says? Is there some of those
times where NMU-rules are relaxed, as it is from times to times? Or is there
another reason I don't know?

-Patrick

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

Re: 0-day NMUs, DELAYED/n uploads

2007-10-16 Thread Patrick Schoenfeld

On Tue, Oct 16, 2007 at 02:39:47PM +0200, Cyril Brulebois wrote:
> The rules defined in [1] applied. And instead of pinging the maintainer,

Thanks for pointing this rules out to me. I wasn't aware of them.
Now that I know them I feel a bit more wiser.

Regards,
PatricNow that I know them I feel a bit more wiser.

Regards,
Patrick


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

Re: 0-day NMUs, DELAYED/n uploads

2007-10-17 Thread Patrick Schoenfeld

On Wed, Oct 17, 2007 at 11:03:04AM +0200, Bas Wijnen wrote:
> No, not really.  The post you replied to stated explicitly that it
> wasn't talking about any specific event, just about general procedure.

I think this is a missunderstanding. I asked if there is some general rule
change or if some special temporary rules apply that I am not aware off.
Cyril pointed the announcement maed by Luk Claes out to me, which obviously
says that we are in an everlasting BSP since 1th September 2007, where those
rules posted on d-d-a apply. Is that wrong? Then one should maybe post some
information about this to d-d-a.

Regards,
Patrick

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

Re: RFS: folding

2007-10-23 Thread Patrick Schoenfeld

On Tue, Oct 23, 2007 at 09:22:30PM -0400, Zachary Palmer wrote:
> Whoah; good catch.  Forgot to specify "mentors" in my command line.

BTW. just as a tip: dut supports configurable default targets, so I would
suggest you to configure it as long as you are not a DD. If the entry in your
.dput.cf for mentors would start with [mentors] it would look like this:

[DEFAULT]
default_host_main = mentors

[mentors]
...

With this configuration dput will always upload to mentors, if you don't
specify another target.

Best Regards,

Patrick


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

Re: RFS: Catfish

2007-11-03 Thread Patrick Schoenfeld

Hi,

On Fri, Nov 02, 2007 at 10:07:52PM -0300, Cody A.W. Somerville wrote:
> I am looking for a sponsor for my package "catfish".

IANADD so I cannot sponsor your upload. Anyway some comments:

* debian/rules:
- clean target does not work
- unneeded debhelper comments
- some unneeded spaces at eol

* debian/patches/10Disable_compile.dpatch:
- Should contain your name before your mail address
- Should contain a description, so that others can follow
your intensions when adding the patch

* debian/changelog:
- Hm.. Is "Reversioning for debian" really everything you did? :)
- distribution should be unstable (see [1])

* debian/control:
- you should use the new homepage field (see [2]) and remove the Homepage
in the description instead.
- the Build-Depends-Indep should probably be listed as Build-Depends,
- Short Description is errornous. See [3]
- some useless empty spaces at eol
- useless empty lines at eof

* debian/docs:
- what is this file for? It would be suffice to add the README filename to
the call in debian/rules

* debian/menu:
- Section Apps/Tools is not valid anymore. Thats the reason why lintian
complains. See the updated menu policy, that has been changed as of June
2007.

And last but not least:
You probably want to add a desktop file aswell. That would achieve a better
integration into gnome and kde.

[1] http://www.debian.org/doc/debian-policy/footnotes.html#f35
[2] http://wiki.debian.org/DpkgHomepageFieldTransition
[3]
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis

Regards,
Patrick

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

Re: RFS: codeblocks

2007-11-23 Thread Patrick Schoenfeld

On Fri, Nov 23, 2007 at 12:17:53PM +0530, Kartik Mistry wrote:
> Please fill the details you left out!

Additional I find the description very meaningless. I can't say from the
description what it is. IANADD so my opinion might not count, but I
don't feel like checking this package for packaging issues (and giving
hints) as long as I need to go and figure myself what this is.

Regards,
Patrick


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

Re: Ubuntu-to-Debian packaging

2007-11-26 Thread Patrick Schoenfeld

On Fri, Nov 23, 2007 at 06:23:50PM -0400, Jose Luis Rivas Contreras wrote:
> You need a new changelog for Debian starting from scratch and you could
> adapt the copyright (if the license allow it) or just make one new.

Why? Thats IMHO a very bad way to do it.

1) changelog is to track was has been done in the package since its
beginning. since it is orignating from an ubuntu package, why should its
history be dropped? That has several disadvantages, including that its
impossible to track any change that happened before the initial Debian
release. Very bad. Also its not fair to the Ubuntu maintainers that did
the initial and eventually biggest part of the work. You simply ignore
the fact that they did something in the history of the package.
Besides from beeing unfair it might be a license violation, depending on
how the ubuntu packaging has been licensed.

2) it is also not wise to start a new copyright file. Besides from the
fact that the Ubuntu maintainers might already have worked alot on it
and it would be a big waste of time, to just drop it and start from new,
you should honour their work beeing done and their packaging license.

Regards,
Patrick

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

Re: Ubuntu-to-Debian packaging

2007-11-26 Thread Patrick Schoenfeld

Hi,

[no need to CC me. I never expressed the wish that I want that]

On Mon, Nov 26, 2007 at 09:34:27PM +0100, José L. Redrejo Rodríguez wrote:
> Not too long ago, about 4 years, when Ubuntu didn't exist, I tried to
> upload my first package to Debian. It was a package we had been using in
> LinEx (our Extremadura Debian based distribution). My sponsor and some

so your handling of packages derives from a time were neither Ubuntu,
nor the Utnubu project existed and your only rationale for this is, that
your sponsors (when you have not been a DD like now) said that? Uh.

> other people at Debian told me that changelog should begin when the
> package begins in Debian, no matter if it had been used before somewhere

There is no consensous about this. See the list archive for -mentors.
Their have been several discussions on this topic and there are a lot of
Debian Developers that don't agree with this. Also I am quiet sure there
is the talking about *your own* work. The difference is that you can do
whatever you like with *your* work, while you can't just take the work
from others and do like they never did it.

> else. I don't know if there is a policy for this, but I would like to

Thats bad. You should not answer to such questions if you don't know it
for your self! Thats especially true because of your DD status that
causes others to give your saying more confidence.

> think there are no preferences between some derivatives and some others.
> I have not seen changelogs containing knoppix, progeny, mepis or linex
> entries...

Giving a preference to one derivative is probably not the best idea, but if
someone takes the work from others to integrate it into Debian or the
otherway round then he should not just drop the packages history. And
btw. Ubuntu does not do that. And: I gave you some rationales why it
is bad. Whats yours?
Compared to *that* case there is another case were I find it reasonable
to drop changelog history. Say for example a package that evolves in
your own private history. 

> Sure, and previous work should be mentioned, no matter who did it:
> Ubuntu or my grand mother.

Right.

Regards,
Patrick

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

Re: Ubuntu-to-Debian packaging

2007-12-02 Thread Patrick Schoenfeld

On Sun, Dec 02, 2007 at 02:04:43AM +0100, Romain Beauxis wrote:
> However, your arguments are not much consistent as well since you mix 
> copyright related issues ("take the work from others") and technical issues 
> ("track recent changes before initial debian upload").

I don't mix arguments. These two arguments are totally on its own and
both arguments are valid.
So read my arguments this way:

1) Copyright / license issues: By removing important information from
the previous packaging you might insult the packaging license.
Redistribution in Debian might therefore be illegal.

2) Removing changelog entries for packaging that you did not do yourself
might be problematic, because their might have been changes those
rationales are documented in the changelog and might be important in the
future. In fact this has often be the case. Besides beeing problematic
to the packager, you take the possibility for the user to see what has
been done to the package in the past. You make blackboxes out of Debian
packages.

> > Thats bad. You should not answer to such questions if you don't know it
> > for your self! Thats especially true because of your DD status that
> > causes others to give your saying more confidence.
> 
> Please, try to keep friendly, I don't think there's anything in this 
> discussion that needs this kind of langage..

Really, it may have sounded more rude to you, then it was meant to be.
But I was really annoyed by such a statement, because it was made on a
list where a lot of people come to actively _seek_ help and advise from
people who _should_ really know it better then themselves. More then
anywhere else beeing a DD is an important status here, because people
expect a DD to be the best mentor they can imagine and as those to know
policies, best practices or at least to be able to look for them during
a discussion.

> So that's definitly a personal taste for that. 
> You may miss important informations while erasing previous changelog, as well 
> as you could spam the changelog with minor changes that would be 
> uninteresting.

Not neccesarily a matter of personal taste. Debian Packages are subject
to change by not only one person. It _often_ happens that others need to
track changes in your package. So you may think of personal taste, but I
think about others that could do a NMU and don't know who did originally
create the package.

> I personally endorse the erase *personal* policy since I believe any 
> important 
> fact on the package should, hence, not be in the changelog but on a file like 
> README.Debian or else, and that I believe it's relevant to see on the debian 
> changelog only debian related changes.

You get the definition of "important facts" in _this_ context wrong. Not
everything is well-placed in README.Debian. Lets see an example:
Because of an issue with older kernels a binary in Debian had to be made
setuid root. Now those older kernels aren't supported anymore and
someone added a bug report about that setuid flag. What would you've
done if you were the one adding the setuid root flag? Or if it
originated in a package where you based your work on.
Adding a note about that to README.Debian? I don't think thats
proper. But besides from note-taking: Would you just change it or
search for a reasoning why this setuid root flag got added? I think the
latter is better, because by just removing something you could break
things. Now adding all those mini-informations to README.Debian would
bloat this file up, making it to a bad information source for users,
cause they would ignore it then (too much informations they don't care
for).

> Other don't do like this, so what's the point ? Perhaps that's the reason why 

Debian is much maintainer-centric, because every package maintainer can
decide on his own for his own package. But just because it is like this,
its not good in every case. With no consensous on doing some things
similar or better equal there is no chance for the user to definitive
know where to take informations from. Thats worse. So the point is to
discuss on such topics and see whats the best solution for our users, be
cause according to the Debian constitution thats all we do our work for.

> there's no official policy, and I think we don't need official policy for 
> everything.

You are right. We don't need an official policy for everything. And in
fact a lot of people think that policy should only document
well-established best practices. Thats fine, as we are all sane people
who can discuss things and use a common way after reaching a consensous.

> And yes, you credit initial maintainers on the copyright of course.

You should not only credit them, but see how they licensed their work
(because Debian packaging is a license-worth work as well!) and respect
their license.

Regards,
Patrick

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

Re: communication, friendlyness, DDs (Re: Ubuntu-to-Debian packaging)

2007-12-03 Thread Patrick Schoenfeld

Hi,

On Sun, Dec 02, 2007 at 09:08:54PM +0100, Holger Levsen wrote:
> On Sunday 02 December 2007 13:19, Patrick Schoenfeld wrote:
> > Really, it may have sounded more rude to you, then it was meant to be.
> > But I was really annoyed by such a statement, 
> 
> That rather implies you were unfriendly, at least I'm often (too) unfriendly, 

yes, I agree.

> when I'm "really annoyed". Also, in communication it is totally irrelevant 
> how you (the sending end) ment something. What matters in communication is 
> how the receiving end perceives it and what the sending end ment, is almost 
> totaly irrelevant.

Well, but its not really possible for the sending end to know before,
how the receiving end will perceive something. Besides that I'm feeling
hard to express some things properly, because english is just not my
native language. Its hard to try to respect feelings of receival ends
then.

> Then let me tell you with my oh-my-god-DD!-status, that most DDs expect 

You get me wrong. I don't say, nor did I mean that DDs are gods. The
problem is just the place were it happens (because of the audience)
and the simple fact that the argued thing is easy to look up.

> friendlyness when interacting with fellow developers (being them DDs or 
> not) :-) Sure, most of us can life with a flame here or a heated argument 
> there, but at least I do expect to be treated friendly. Anytime, everywhere.

Well, its not always that easy. What you feel as beeing unfriendly is
felt unfriendly by the receiving end. In fact my first thinking when
I read the mail about my unfriendlyness was: "What?! I don't really
understand why my mail has been unfriendly at all." Because I just
complained about something that I felt totally wrong. I did not call
Jose a moron or anything else insulting.

> And, DDs don't know everything and don't have to know everything as well. 
> José 

I agree with this. But the problem is not to know everything, but the
simple fact that informations can be looked up. If you argue with
someone about elementar questions on how things should be done, its
better to be informed. IMHO Debian Developers don't need to know
everything, but they should know where to get the information from. In
this case Jose knew the information source very well, but instead of
looking into it and _then_ answering he indicated that he was to lazy or
whatsoever to look into the policy and instead say that he does not
know. I should have said that I feel this beeing bad, then it my have
sounded different on the receiving end. But i cannot change things I
already did.

> shared his experiences with you and the list and when he was in NM he was 
> told by a DD (! :) that he should remove the old changelog and that he is not 
> sure if there is a policy for this. And he made it through NM with this 
> advice and all his NM communication was read by his AM, FD and DAM. Can't be 
> that wrong. 

I don't see how this argumentation works. Sorry.

> He also indicated he might be wrong (as things might have changed) and that 
> his knowledge is limited (doh! just like anybody elses on this planet) - 

Thats not true. In his first mail (the one that I first critizized) he
just stated how it should be. Quiet confident. Sureley anyone who does
not (yet) know better would see: Ah, the advise from a DD, additional
their is no policy for it and oh not even a documented best practice in
the DevRef, so I'll follow his advise. You see what I think is bad?
In his second mail he did. But this mail would have never happend if I
had not complained to him.

> what's wrong with that? It's rather good for two reasons: people know that 
> they should not take his advice (in this matter) for granted and people can 

Thats right, but the acting in this case is IMHO wrong anyways.
Because the information is so easy to lookup and proof. So why should someone
who really does know that something like the Debian policy exists and
where to find it (I assume that he does, because he is a DD) make statements 
about
contents of the policy without looking it up?

> correct him and inform the list and point out the policy about keeping 
> changelogs or not. 
> 

I don't like this way of doing things. You can stretch this in any
direction. Example: Not in a mentor-mentoree relationship, but in packaging:
Why lookup sth. in the policy at all? Someone will make a bugreport
and point out to the policy. Right?

> There are good arguments  [..]  but there are also good for removing 

Maybe. But the questioning of the topic starter surely wanted to ask for
a rule of thumb. Jose gave one, which is _at least_ questionable.

> it. For example if you dont plan to merge back and forth in future (IME I 

We are talking about Ubuntu-to-Debian. So this is not of concern, right?

> And, yes, the packagin

Re: Ubuntu-to-Debian packaging

2007-12-04 Thread Patrick Schoenfeld

Hi Miriam,

On Mon, Dec 03, 2007 at 11:35:31PM +0100, Miriam Ruiz wrote:
> While I do believe that, as a general rule, it's much better to keep
> old changelog entries, I'm pretty sure it's not illegal at all
> toremove them (IANAL) as long as you keep the copyright statements. It
> might not be polite, but it definitely doesn't look illegal.

yes, you are right. Someone already made that clear and I noticed that I
must have confused something.

Best Regards,
Patrick


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

Re: communication, friendlyness, DDs (Re: Ubuntu-to-Debian packaging)

2007-12-05 Thread Patrick Schoenfeld

Hi,

On Wed, Dec 05, 2007 at 01:46:49AM +0100, Ondrej Certik wrote:
> > > > Really, it may have sounded more rude to you, then it was meant to be.
> >   
> > > > But I was really annoyed by such a statement,
> > >
> > > That rather implies you were unfriendly, at least I'm often (too) 
> > > unfriendly,
> >
> > Misusing "then" and "than" can cause confusion. If it is read as "... than
> > it was meant to be." it takes on an entirely different meaning. :-)
> 
> Good point, I read the wrong meaning too.

yes, after all I see that I was making a mistake here. Off course the
really meant word was "than", so the sentence should read:

"Really, it may have sounded more rude to you, than it was meant to be."

Best Regards,
Patrick


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

Re: Ubuntu-to-Debian packaging

2007-12-08 Thread Patrick Schoenfeld

Hi,

On Fri, Dec 07, 2007 at 12:16:12PM -0800, C.J. Adams-Collier wrote:
> I'm sorry, what is an "SRU"?

with Google the first hit I found by earching for "SRU+Ubuntu" was
[1], so I think this are updates to a "stable" Ubuntu release.

Best Regards,

Patrick

[1] https://wiki.ubuntu.com/StableReleaseUpdates


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

Re: RFS: inkblot

2007-12-11 Thread Patrick Schoenfeld

Hi,

IANADD so I cannot sponsor your upload, but anyways some comments.

First of all:
You really should include the URL to the .dsc file of your package.
That way you make it a lot of easier for potential sponsors to find your
package and you higher the chances that a potential sponsor will have a
look at it.

General:
- inkblot links against libraries whose symbols it does not use.
  Therefore dpkh-shlibdeps. Therefore you should try to fix that.

debian/control:
- Build-Depends for debhelper is over-precise. It should
  be enough to depend on a version >= 5. Rationale: Specifying it more
  precises has no benefit and makes life harder for backporters.

debian/copyright:
- Homepage in "... was downloaded from .. " differs from Homepage
  field in debian/control. Why?
- You may want to consider adding machine-parseable informations to
  this file, as this proposal [1] suggest.
- Personally I find the copyright file to be quiet cluttered. I'd do it
  different. See for example dnsproxy or mantis from sid
  for an example on how I would do it.
- See the lintian warning

debian/rules:
- There is no need to keep the dh-make comments :-)
- Its gould to have DEB_HOST_GNU_TYPE and such in your rules file to
  make it behave better when beeing cross-built,  but you should do it 
different,
  because this might be problematic when not beeing cross built. See [2]
- Personally I would prefer to make configure call multi-line (with
  \ escaping the line break) for cosmetic reasons ;-)
- install target: You use make DESTDIR=foo install, dh_install and
  additional delete files from the DESTDIR. Why? dh_install is not
  really needed in here, you could do this with normal install
  calls.

debian/manpages: What is this file for?

Best Regards

Patrick

[1] http://wiki.debian.org/Proposals/CopyrightFormat
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423707

On Tue, Dec 11, 2007 at 12:13:08AM +0600, Sikon wrote:
> Original RFS: http://lists.debian.org/debian-mentors/2007/07/msg00735.html
> 
> I have uploaded inkblot version 0.99.9-1. Also filed an ITP: Debian bug 
> 455529, link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455529 .
> 
> Sikon



-- 
in medias res Gesellschaft für Kommunikationstechnologien mbH
Dahlenerstr. 570
D-41239 Mönchengladbach

tel. +49 (0) 2166 -  - 685
fax. +49 (0) 2616 -  - 800
email: [EMAIL PROTECTED]


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

Re: Removing parts of upstream tar-ball, parsers, autobuilding

2007-12-13 Thread Patrick Schoenfeld

Hi,

IANADD, but anyways some comments:

On Thu, Dec 13, 2007 at 07:03:54PM +0530, Y Giridhar Appaji Nag wrote:
> 1. I have an upstream source tar-ball that accidentally includes some
> files that are generated (and cleaned when a make distclean is issued)

the question to decide is: What files does the tarball include so that
you *must* remove them? AFAICS it seems to be general consensous that
changes to the upstream source tarball must not be done if there is no
good reason. I won't consider "they don't need to be here" a good
reason.

> Now, the best thing to do would be to copy the upstream tar-ball as-is
> to orig.tar.gz and have a patch that removes these files (this will
> result in a big diff).  However, is it OK to create an orig.tar.gz file

Why do you need to remove them? Are they causing any impact? If not: Why
not leave them alone?

> based on the upstream tar-ball with these files removed?  Do maintainers
> create a new orig.tar.gz based on the upstream tar-ball and use it (even
> in the non pkg-modified-to-be-dfsg case)?

There are rare cases where repackaging seems appropriate, e.g. for
removing an upstream provided debian directory, or in the (you named it)
case where upstream sources contains non-dfsg material.

> 2. Are there packages in our archive that directly include parsers
> (generated by bison etc.) in the orig.tar.gz directly rather than
> "Build-Depends"-ing on the parser-generator?

Hm. I don't know, but I would consider this quiet crappy.

> I am guessing that there shouldn't be any (unless the parser is
> hand-edited heavily later) because a bug in the generated parser because
> of the parser-generator would be difficult to spot.

But this case is one of the worst I could imagine. If it is hand-edited
later it would be impossible for someone else to recreate the parser
later. Better would be to patch the input files to create a parser as it
is needed.

Regards,
Patrick

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

Re: ITR: ustr (updated package)

2008-02-12 Thread Patrick Schoenfeld

Hey Neil,

On Tue, Feb 12, 2008 at 11:02:40AM +, Neil Williams wrote:
> Good, that's the kind of RFS I like to see - just one thing missing,
> this is an existing package:
> http://packages.qa.debian.org/u/ustr.html

just a quick note (and question): He indicated that this package isn't
new, by using the "updated package" subject. Shouldn't this be suffice?

Best Regards,
Patrick

signature.asc
Description: Digital signature

Re: RFS: lynis

2008-02-14 Thread Patrick Schoenfeld

Hi Francisco,

IANADD so I cannot sponsor your upload. However I think my comments may
be useful for you. CC'ing my AM: Eventually he has additional comments
and/or is willing to sponsor your upload, when everything okay.

On Thu, Feb 14, 2008 at 01:22:42AM +0100, Francisco García wrote:
> - dget http://mentors.debian.net/debian/pool/main/l/lynis/lynis_1.0.8-1.dsc

- debian/changelog:
I would suggest you to remove the changelog entry for 1.0.7-1, as
appearently 1.0.8-1 will be the first release in Debian. Some people argue
that there is no need to hide the development of a package from the target
audience of changelogs, but IMHO the first changelog entry contains
practical no information (its redundant, anyway) and is confusing (due to
its redundance)

- debian/control
- Misses a homepage header to indicate upstream url. See [1]

- debian/copyright:
- Should include a license excerpt. If you have dh-make installed,
see /usr/share/debhelper/dh_make/licenses/gpl for an example.
- IMHO the "," between the copyright year and your name is not needed
- nitpick: Not so beauty are the useless empty spaces at and eof line:)
- What do you think about adding the machine-parseable fields to copyright?
  [2]

- debian/dirs:
Are you sure you need it? Seems to me like you won't need it, if you'd do
minor modifications to your debian/rules file

- debian/rules:
- Dou you really need the (useless) comments that are added by dh-make?
- configure-stamp target misses a touch configure-stamp
- same for build-stamp (simply uncomment your touch ;)
- install: Please remove the commented make install call if you don't need
  it.
- you could use the install -D parameter with your install calls and avoid
  to create directories seperateley. However this only works for the install
  calls where you only install single files.
- it would make sense to delete the useless empty lines (1 or two lines
  between targets is fine, but it does not make much sense two have 5 or
  more onfollowing empty lines)
- where is the point to call dh_makeshlibs - your package does not contain
  shared libraries, does it?

- debian/lynis.manpages is useless as you only install one manpage. you can give
  it as an argument to dh_installmanpages.

- debian/watch is missing but is highly recommended! This enables you to track
  new upstream versions automatically via your qa page (and via mail
  notification!). See [3]

Best Regards,
Patrick

[1] http://wiki.debian.org/DpkgHomepageFieldTransition
[2] http://wiki.debian.org/Proposals/CopyrightFormat
[3] http://wiki.debian.org/DEHS



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

Re: RFS: nettee

2008-02-18 Thread Patrick Schoenfeld

Hi Joel,

IANADD, anyways here are some comments about your sponsoring request
that might be useful.

First of all:

On Mon, Feb 18, 2008 at 01:04:48AM -0300, Joel Franco wrote:
> It builds these binary packages:
> nettee - a network "tee" program

It would be a good idea to include a long description of the package.
Because some DDs say that they won't even consider sponsoring packages,
if it is missing. Remember: Your RFS is your advertising of the work
you've done. Make it interesting for others.

> - dget http://mentors.debian.net/debian/pool/main/n/nettee/nettee_0.1.8-3.dsc

Now to your package:

- debian/changelog
General I'm not a fan of multiple changelog entries for one upload,
but thats just my opinion. However you should note, that you need to
build the package with dpkg-buildpackage -v 0.1.8 so that the other
changelog entries get integrated. Otherwise the bug referenced in
the first changelog entry (Initial release) will not be closed by
the upload.

- debian/control
- lacks a Homepage header to indicate the homepage. See [1]
- Description is not very descriptive. See [2] for some tipps.

- debian/copyright
- Some copyright holders are missing in that file
- Its a good idea to include a "On Debian systems the license text
can be found.." notice to the license of the software, because the
link in the "packaging is licensed as following"-text looks like
it *is* for the packaging only on ordinary people IMHO.

- debian/dirs is useless. You can change the installation of the binary
to be install -D -m755 nettee debian/nettee/usr/bin/nettee and
remove both the file and dh_installdirs.

- debian/README.Debian: Hm. I'm unsure if the content is suited for
README.Debian. Why? Because it seems like it has no documenting
character, more beeing an advertising on how enthusiastic you are
about the tool ;) I would like to hear other opinions about this,
however.

- debian/rules:
- configure and configure-stamp target is not required by
the policy and you don't need it. so you could remove it.
- you could probably consider adding generating optimized binaries
(e.g. -O2)? If you do, please also add support for
DEB_BUILD_OPTIONS [3]

- debian/watch is missing, but highly recommended. it enables tracking of
new upstream versions via your QA page and even a mail notification if
you want. See [4] for more information.

Thats it for now. Feel free to inform me if you did changes on your
package and I will have another look at it.

Best Regards,
Patrick

[1] http://wiki.debian.org/HomepageFieldHOWTO
[2]
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-debian-control
[3] http://www.debian.org/doc/debian-policy/ch-files.html
[4] http://wiki.debian.org/DEHS

signature.asc
Description: Digital signature

Re: RFS: lynis

2008-02-20 Thread Patrick Schoenfeld

Hi Francisco,

On Wed, Feb 20, 2008 at 12:53:34AM +0100, Francisco García wrote:
> I have made the changes that you suggest me. I think
> the package is better now.

all at all good work. But still one comment:

Run lintian with -I and you will see this:

I: lynis: hyphen-used-as-minus-sign usr/share/man/man8/lynis.8.gz:28

Thats not a major problem (and no blocker for now) but i wouldn't
be good to fix it somewhere in the future. See [1] for some explanations.

Package should have been uploaded by pabs.

Best Regards,
Patrick

[1] http://lists.debian.org/debian-devel/2003/03/msg01481.html

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

Re: RFS: nettee

2008-02-23 Thread Patrick Schoenfeld

Hi,

On Fri, Feb 22, 2008 at 11:46:27PM -0300, Joel Franco wrote:
> A long description is really difficult because the 2 words say all :)

no, they don't. Imagine you would be someone who is interested in
cloning a system, but you never heard about tee or netcat. How could the
maintainer of such a program as nettee is, have written the description for
you to find it? BTW. have a look at the manpage. IMHO the description
which is used their is a good starting point.

> > - lacks a Homepage header to indicate the homepage. See [1]
> done

Please move it to the source package part of the package, for example
after the maintainer line.

> >- debian/copyright
> > - Some copyright holders are missing in that file
> Sorry. i did not understand.
> It's the original copyright missing? i have include it.
> my copyright too?

Well, the debian/copyright needs to contain the copyright of each
copyright holder, each file and every differing license. If I do a rgrep
-i '(c)' in the package source directory I still find copyrights that
are not mentioned in your copyright file.

> > - Its a good idea to include a "On Debian systems the license text
> >   can be found.." notice to the license of the software, because the
> >   link in the "packaging is licensed as following"-text looks like
> >   it *is* for the packaging only on ordinary people IMHO.
> I have included your text to precede the file location.

No. What I meant is soemthing like this:

License:

<.. License Excerpt ..>

On Debian Systems the complete text of the ... License can be found in
..

The Debian packaging is ...

> I'tried to do it, but i don't have sure that it's correct because it's
> not clear which data must be in debian/watch. I have included the
> original upstream version download url.

See the manpage for uscan. The format of the watch files is well
documented there.

Well, there are still some comments (besides what I've already written):
- debian/copyright: Wrap lines after 80 characters
- debian/rules:
- Your CFLAGS are not used. Needs some investigation.
- Its nitpicking, but please remove the useless empty
  whitespaces at some line endings (e.g. line 33 and 38)
- debian/changelog: Needs some work. Changelog entries are not as they
  should be. See [1] for some instructions.
- debian/docs: includes beowulf.master which does not seem to be a
  document, but instead an example. See the manpage for
  dh_installexamples on how to install examples
- debian/README.Debian is still in the package. Remember that I and Paul told
  you, that its content is not really what the README.Debian is for.
- debian/watch: No thats wrong. See the uscan manpage.

Best Regards,
Patrick

[1]
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-debian-changelog


signature.asc
Description: Digital signature

Re: RFS: nettee

2008-03-20 Thread Patrick Schoenfeld

Hi Joel,

sorry for answering myself so late, but I have been busy these days (and
I am still but I'm trying to keep up today).

On Wed, Mar 05, 2008 at 12:02:10AM -0300, Joel Franco wrote:
> However, if you look ate the Debian available packages today, you will
> see that the most do not follow that recommendation.

Thats true, but not a charter for upcoming packages. Its just a sign
that not everybody cares or cared about providing good descriptions.

> Well, i have changed the nettee short description.

Lets not focus too much on the short desc. Its more the long description
that I care about. Something like "a network tee program" as a short
description is okay, because tee is both a common tool and an English
word. But the long description should tell the reader what exactly is a
network tee program. I'm not very satisfied with that, because it uses
an engineer language, but a program to clone computers over the LAN
isn't obligatory used by an engineer. So the description must not be to
complicated (and even for technical packages I pledge for use of normal
language instead of technical terms).
Here is a proposal:

Description: a network tee program
nettee is a program that can be used to transfer data from one computer
to a number of computer nodes simultaneously at nearly full speed of the
network it is connected to.
.
A common use-case for this application is for cloning computer
partitions and disks or moving large database files.
.
Its advantage over netcat+tee is, that it is more simple and can
survive to error conditions like computer nodes dead and transfer
courruption.

> >Please move it to the source package part of the package, for example
> >after the maintainer line.
> 
> ok

Oh, got quiet high. Well, thats okay, while personally I would have
preferred to move it somewhat lower in the source package part (for
example below the maintainer line or so).

> :) now i understand. i made it.

Good.

> Sorry, but it isn't still very clear to me. I understand that the
> copyright file must refer to the Debian license files in a generic way
> and not in a particular way to this package.

Hu? Now I don't understand you.

> Right. That's fine and now i understand why it's useful.
> I have corrected it now :)

Good.

> >- debian/changelog: Needs some work. Changelog entries are not as they
> >  should be. See [1] for some instructions.
> 
> i'd read that, i'm more conscious about that and have changed somethings.
> However, i have to maintain the minimal changes mentionated because it's one 
> of
> my first packages.

The last entry is _very_ confusing. You describe about 6 changes in
_one_ changelog entry and no changelog describes _why_ something has
been changed. But thats bad. After all the sense of the changelog
is for someone else then you (and you, too, in the future) to understand
what has been changed and why it has been changed (which affect does the
change have?).

> >- debian/README.Debian is still in the package. Remember that I and Paul told
> >  you, that its content is not really what the README.Debian is for.
> 
> i don't know which is the better way to fix this issue: i should send it to 
> the
> upstream author or I should rename it to something reflecting the my 
> particular
> use?

I'd suggest you to send it upstream. But it is not suited for
README.Debian, because this file is for Debian specific notes, which
this certainly is not.

Best Regards,
Patrick

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

Re: RFS: nettee

2008-04-25 Thread Patrick Schoenfeld

Hi Joel,

I wonder if you got my mail below, because I saw that I did not send it
to you directly (it was only addressed to
debian-mentors@lists.debian.org). Did you receive my comments?
Any progress on your package?

Best Regards,
Patrick

On Thu, Mar 20, 2008 at 09:40:45AM +0100, Patrick Schoenfeld wrote:
> Hi Joel,
> 
> sorry for answering myself so late, but I have been busy these days (and
> I am still but I'm trying to keep up today).
> 
> On Wed, Mar 05, 2008 at 12:02:10AM -0300, Joel Franco wrote:
> > However, if you look ate the Debian available packages today, you will
> > see that the most do not follow that recommendation.
> 
> Thats true, but not a charter for upcoming packages. Its just a sign
> that not everybody cares or cared about providing good descriptions.
> 
> > Well, i have changed the nettee short description.
> 
> Lets not focus too much on the short desc. Its more the long description
> that I care about. Something like "a network tee program" as a short
> description is okay, because tee is both a common tool and an English
> word. But the long description should tell the reader what exactly is a
> network tee program. I'm not very satisfied with that, because it uses
> an engineer language, but a program to clone computers over the LAN
> isn't obligatory used by an engineer. So the description must not be to
> complicated (and even for technical packages I pledge for use of normal
> language instead of technical terms).
> Here is a proposal:
> 
> Description: a network tee program
> nettee is a program that can be used to transfer data from one computer
> to a number of computer nodes simultaneously at nearly full speed of the
> network it is connected to.
> .
> A common use-case for this application is for cloning computer
> partitions and disks or moving large database files.
> .
> Its advantage over netcat+tee is, that it is more simple and can
> survive to error conditions like computer nodes dead and transfer
> courruption.
> 
> 
> > >Please move it to the source package part of the package, for example
> > >after the maintainer line.
> > 
> > ok
> 
> Oh, got quiet high. Well, thats okay, while personally I would have
> preferred to move it somewhat lower in the source package part (for
> example below the maintainer line or so).
> 
> > :) now i understand. i made it.
> 
> Good.
> 
> > Sorry, but it isn't still very clear to me. I understand that the
> > copyright file must refer to the Debian license files in a generic way
> > and not in a particular way to this package.
> 
> Hu? Now I don't understand you.
> 
> > Right. That's fine and now i understand why it's useful.
> > I have corrected it now :)
> 
> Good.
> 
> > >- debian/changelog: Needs some work. Changelog entries are not as they
> > >  should be. See [1] for some instructions.
> > 
> > i'd read that, i'm more conscious about that and have changed somethings.
> > However, i have to maintain the minimal changes mentionated because it's 
> > one of
> > my first packages.
> 
> The last entry is _very_ confusing. You describe about 6 changes in
> _one_ changelog entry and no changelog describes _why_ something has
> been changed. But thats bad. After all the sense of the changelog
> is for someone else then you (and you, too, in the future) to understand
> what has been changed and why it has been changed (which affect does the
> change have?).
> 
> > >- debian/README.Debian is still in the package. Remember that I and Paul 
> > >told
> > >  you, that its content is not really what the README.Debian is for.
> > 
> > i don't know which is the better way to fix this issue: i should send it to 
> > the
> > upstream author or I should rename it to something reflecting the my 
> > particular
> > use?
> 
> I'd suggest you to send it upstream. But it is not suited for
> README.Debian, because this file is for Debian specific notes, which
> this certainly is not.
> 
> Best Regards,
> Patrick


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

dbconfig-common: running scripts _and_ an sql script in order

2008-04-29 Thread Patrick Schoenfeld

[CCing the maintainer of dbconfig-common because his input would be
highly useful]

Hi,

I have a question regarding database upgrades with dbconfig-common.
Currently I have the problem that I have some situations where a
database fix is needed (in case one had a very old version of the
package installed and upgraded to the least recent and now to the new
package, because there were a bug in the upgrade logic). Its no real big
problem to achieve that, because dbconfig-common supports calling
scripts. Now comes the real problem: Additional I need to run an SQL
script *after* this fix has been applied to upgrade the database.

But here is a cite from the dbconfig-common docs:
"If files exist in both data and scripts, they will both be executed in
an unspecified order."

So obvious I cannot do it this way. My first guess is to evaluate the SQL
file from within the script, but where should I install the sql file
then? Installing it to /usr/share/dbconfig-common/data/... would be the
best way, but it would lead into the installation to fail in case the
SQL script get evaluated before the script got executed. My opinion is
that dbconfig-common should be changed so that I can configure the
order. Otherwise it would be an option to run it in this order: script,
sql file. Because in a situation where you have a script AND an sql
script it is (IMHO) most likely that the script is wanted to be run
before the sql statements.

How would I handle this situation best? Any opinions?

Thanks in advance and best Regards,
Patrick


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

Re: dbconfig-common: running scripts _and_ an sql script in order

2008-04-29 Thread Patrick Schoenfeld

Hi,

On Tue, Apr 29, 2008 at 01:23:22PM +0200, Patrick Schoenfeld wrote:
> How would I handle this situation best? Any opinions?

forget the question :-) I already figured that I'm not in need for a
script, therefore the problem does not exist anymore.

Greets,
Patrick


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

Re: RFS: bluemindo

2008-06-24 Thread Patrick Schoenfeld

Hi,

On Tue, Jun 24, 2008 at 11:20:50AM +0200, Thibaut GIRKA wrote:
> I am looking for a sponsor for my package "bluemindo".

here it comes to my comments about your package. Please note that this is not a
complete list of possible issues or wishes about your package. As sponsoring is
an iterative process I will continue to tell you things, once you've changed
those which are mentioned below.

- Important: Your package fails to build twice in a row. That means building it
  and trying to build again from the source tree fails. This needs
  investigation.

- Important: debian/copyright misses copyright holders. That is very important
  and needs to be changed. Please check every file contained in the distribution
  precise for a) different copyright holders and b) different licenses. See [6]
  for policy about this.

- Important: debian/copyright seems to contain a wrong licence excerpt. It
  states "This package is free software (...) either version 3 of the License."
  Seems like this should have become a "either version 3 or later" but it
  isn't. Please use the proper license excerpt for the license also if it is 
  GPL v3 only.

- Usage of CDBS is not recommended to someone who starts with packaging. It
  takes you the chance to learn what is going on and has some serious flaws.
  There are a lot of Debian Developers that don't sponsor CDBS packages. So it
  might be worth for you to consider using a plain debhelper based debian/rules
  file. I know this is a major rework of your package, but it helps you to
  understand both technical details of the building process as well as policy.
  For me it is not a no-go (although I don't have much experience with CDBS and
  can't help you if problems shall ever occur, nor do I know the opinion of my
  AM). For further details about CDBS beeing problematic please see [1] and the
  following posts in the thread.

- Your package lacks a debian/watch file, although this is not mandatory its
  highly recommended, because it allows automatical tracking of new upstream
  versions. Please see [2] and the uscan(1) manpage (part of the devscripts
  package) for details.

- debian/menu is missing. This file is used by the Debian menu system
  which provides a standard interface between packages providing applications
  and window managers. It is important, because according to the Debian
  policy [3] you SHOULD add this file so that users See [3] and [4] for 
details. 

- debian/README.source is missing, but as your package contains patches it
  should document whats neccessary to get a fully patched source etc.
  See [5] in the policy for details about this file. Its okay to refer to the
  documentation in a common patchsys if it exists.

Thats it for now. Further comments will follow, once you have worked on this
points.

Best Regards,
Patrick

[1] http://lists.debian.org/debian-mentors/2006/12/msg00134.html
[2] http://wiki.debian.org/DEHS
[3] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-menus
[4] http://www.debian.org/doc/packaging-manuals/menu-policy/
[5] http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource
[6] http://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright


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

Re: Re: RFS: bluemindo

2008-06-24 Thread Patrick Schoenfeld

Hi,

not having reviewed your package again, yet, will look into it tomorror,
but some comments for now:

On Tue, Jun 24, 2008 at 08:24:04PM +0200, Thibaut GIRKA wrote:
> The original Makefile is incomplete and doesn't provide a clean target.
> As a result, the compiled locales are not removed after they are built.

Well the fix for that should be fairly simple, shouldn't it? All you need to do
is do it yourself in your clean target (which is somewhere hidden in
CDBS, but it should have something like {pre,post}-clean that you can use.

> For the debian/watch file, it may be a bit harder, see yourself:
> http://www.codingteam.net/bluemindo-down_en.html

Well, but it is fixable. Your upstream seem to have all his files in

http://www.codingteam.net/upload/

with a not so fixed filename in the form, for example,
77133a-bluemindo-0.2.1.tar.gz. I suspect this beeing a hash or
something, but it doesn't matter. You can let that match and then add a
filenamemangle. An example which works:

version=3
opts=filenamemangle=s/.*-(.*)/$1/ \
http://www.codingteam.net/upload/.*bluemindo-(.*).tar.gz

You probably want to talk to upstream if he intends to let it stay this
way or if he could ease situation for you.

> I think my patches name describes what they do. Not making a
> debian/README.source (at the moment).

Thats not about patch description, that is for others to find out what
needs to be done in order to get a patched source, add new patches etc.
Please see the policy about it, as I wrote you in the first mail. You
really should add this.

Regards,
Patrick

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

Re: RFS: bluemindo

2008-06-25 Thread Patrick Schoenfeld

On Tue, Jun 24, 2008 at 10:09:55PM +0200, Vincent Bernat wrote:
> OoO  Pendant le  journal télévisé  du mardi  24 juin  2008,  vers 20:24,
> Thibaut GIRKA <[EMAIL PROTECTED]> disait :
> 
> > I'll see about CDBS.
> 
> In case, I can sponsor CDBS  packages and give tips about solving issues
> with CDBS. Don't drop CDBS just because other developers do not like it.

Thats not what have been said. I referred to a thread on debian-mentors
about CDBS where advantages and disadvantages are communicated and
I told him that using CDBS keeps him away from learning important facts
about packaging. I also told him that he might think about not using
CDBS. That there are sponsors who don't like to sponsor CDBS packages
was just an additional hint, because there are quiet a lot people that
don't like to sponsor CDBS packages and somewhere in the future he might
search for a sponsor and you might not be around.

Best Regards,
Patrick

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

Re: Re: RFS: bluemindo

2008-06-25 Thread Patrick Schoenfeld

Hi,

your package now builds fince twice in a row. Well done!
As I said here are my further comments:

- Important: You install an extra-license file which causes a lintian
  warning. Refer to Policy Manual, section 12.5 for details. Please
  always check your package against a recent lintian from unstable.

- debian/rules:
  Hm. You use CDBS, but you don't use python-distutils. You may want to
  change that. Otherwise you need to handle some things yourself. See
  [5] for some informations.

- debian/copyright:
- Please don't throw copyright and license informations together. If
  you have parts in the source tarball that are not licensed the
  same way as the main program itself, then I recommend you to open
  another License block with an additional "(for ...)" that states
  which file is meant. BTW. what do you think about this [1] format?
- (C) has no legal meaning. You have to replace it with ©.

- debian/menu:
  So far so good. What about providing an icon? See [2] for some
  information.

- debian/README.source:
  You should rename it to .source instead of .Source because thats its
  filename according to policy. Otherwise its incomplete. It needs to
  document at a bare minimum: 1) Creating a fully-patched source, 2)
  Modifying the source and save those modifications to let them be
  applied during building 3) Remove applied modifications. See [3]
  for the mail originally sent by Russ.

- debian/watch:
  Is still missing. For now you could use the watch file I've
  constructed for you. Or do you see complications with this? See below,
  I've cited the relevant parts of my previous mail at the end of this
  mail.

- debian/compat:
  You use compat level 6. Do you really use any features from it?
  Because it has been said, that one should better use the highest
  supported version in a stable release, to make it easier for
  backports. See [4] for informations.

- debian/docs:
  Please include the upstream changelog so that it gets installed
  compressed to /usr/shared/doc/$pkg/changelog.gz

- debian/patches/*:
  You said that you think your patches speak for themselves. I disagree.
  There is no description what they do and the file name is not making
  it more obvious. You should better that by adding comments (if that is
  supported by simple patchsys) or by at least renaming the patches to
  something more meaningful.

- debian/control:
- Build-Depends seem to be wrong, given the python policy. See [5]
- Same as above for Depends
- BTW. are you sure that the Recommends are adequate? Consider that
  it should contain everything which the program at a whole does
  not neccesarily depend on, but provides functionality that is
  usually wanted by its users (recommends are installed by default
  usually)
- Description needs some overhaul. See [6] and [7]. Please also
  check it for spelling or grammar errors.

Thats it for now. More comments could follow in the next round.

Best Regards,
Patrick


[1] http://wiki.debian.org/Proposals/CopyrightFormat
[2] file:///usr/share/doc/menu/html/ch3.html#s3.7
[3] http://lwn.net/Articles/280471/
[4] http://lists.debian.org/debian-devel/2008/02/msg00184.html
[5] http://wiki.debian.org/DebianPython/NewPolicy
[6] 
http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis
[7] 
http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-desc


On Tue, Jun 24, 2008 at 09:40:56PM +0200, Patrick Schoenfeld wrote:
> Well, but it is fixable. Your upstream seem to have all his files in
> 
> http://www.codingteam.net/upload/
> 
> with a not so fixed filename in the form, for example,
> 77133a-bluemindo-0.2.1.tar.gz. I suspect this beeing a hash or
> something, but it doesn't matter. You can let that match and then add a
> filenamemangle. An example which works:
> 
> version=3
> opts=filenamemangle=s/.*-(.*)/$1/ \
> http://www.codingteam.net/upload/.*bluemindo-(.*).tar.gz


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

Re: Re: RFS: bluemindo

2008-07-02 Thread Patrick Schoenfeld

Hi,

sorry for my late reply. Has been a bit busy these days.

On Sat, Jun 28, 2008 at 02:13:17PM +0200, Thibaut GIRKA wrote:
> > - Important: You install an extra-license file which causes a lintian
> >   warning. Refer to Policy Manual, section 12.5 for details. Please
> >   always check your package against a recent lintian from unstable.
> 
> Hm. The fact is that bluemindo reads the file itself.

Due to the fact that its a GPL license you have the possibility to
create a symlink to the file in /u/s/common-licenes.
Or patch bluemindo. First choice probably preferrable.

> > - debian/rules:
> >   Hm. You use CDBS, but you don't use python-distutils. You may want to
> >   change that. Otherwise you need to handle some things yourself. See
> >   [5] for some informations.
> 
> Hm... Done (I think).

Hm. Why don't you use the way thats written down in the CDBS docs [1]?
Is there a special reason for your manual calling of dh_pysupport?
I also don't think that this is enough.

> > - debian/copyright:
> > - Please don't throw copyright and license informations together. If
> >   you have parts in the source tarball that are not licensed the
> >   same way as the main program itself, then I recommend you to open
> >   another License block with an additional "(for ...)" that states
> >   which file is meant. BTW. what do you think about this [1] format?
> > - (C) has no legal meaning. You have to replace it with ©.
> 
> I changed it. I it better now?

I see that you adopted the machine-parseable copyright format. So do you
like it?

However it seems still a bit bogus to me:
Most files use the GPL-3 as license so citing parts of the license
explicit is not needed and imho makes no sense, too. Additional you have
a "License.." block at the end of the file, which is possibly un-needed
(because the machine-parseable part replaces it) but in my opinion a
good approach, because I really prefer to still have a human-readable
part as long as there is no parser that makes the file more
human-readable by people who are not so technical experienced.

So to make your copyright perfect:
- Remove license excerpts for well known licenses
- Include complete license information for the PSF, because it is not in
  /u/s/common-licenses
- Make the human readable part complete (e.g. re-add a Copyright part).

> As the package provides a png file in the good place, can I use it? or
> do I have to make a xmp file?

Well, the most window managers probably don't understand the PNG format,
so yes this is required. However you can do this automatically by
converting the file with convert and build-depending on imagemagick.

> 
> > - debian/README.source:
> >   You should rename it to .source instead of .Source because thats its
> >   filename according to policy. Otherwise its incomplete. It needs to
> >   document at a bare minimum: 1) Creating a fully-patched source, 2)
> >   Modifying the source and save those modifications to let them be
> >   applied during building 3) Remove applied modifications. See [3]
> >   for the mail originally sent by Russ.
> 
> Er... I don't really understand how it works.
> Just use debian/rules patch to patch, debian/rules reverse-patches to
> remove the patches, and debian/rules binary to build?

Did you read the links I've posted? Its described in detail, there.
But to make it clear:
This file is for other people then you, so that they have a chance to
lookup how certain processes work with your package. E.g. for the
security team to read up, what they need to do, to get a fully patched
source, create new pages, remove patches. That is that people who
usually don't maintain your package and probably usually use other
methods (e.g. quilt and debhelper instead of CDBS and patchsys) have a
chance to update your package (for example due to a security issue).

Whats missing from your file is a documented way to create a new patch.

> I included the one you made, although upstream may change it at any
> time.

Well, thats true for most of the upstreams :-) Basically what you then
do is adapting the package. Hopefully watch files will at some point in
the future be cared for outside of the package at a central location
this will ease its maintainance.

> Compat is now 5.

Yeah right, but you missed the depend in debian/control.

> It may be a bit better, now.

It would be better to make two makefiles of the first one. So that
every patch is for exactly one change. BTW. please do not forget to
forward the patches upstream. The proposed seperating into two pages
also makes it easier for you if upstream integrates only one part of the
patch.

> I think Recommends are adequate. This packages aren't required to run
> bluemindo, but they are required to use several features. 

That sounds reasonable. But there is still a question that you should
clear: Are those features really common to the usual user of the
software? Is it someone one usually would expect? If yes, then
Recommends is fine

Re: RFS: lynis (updated package)

2008-07-03 Thread Patrick Schoenfeld

Hi,

On Wed, Jul 02, 2008 at 10:59:02AM +, Francisco M. García Claramonte wrote:
> I am looking for a sponsor for the new version 1.1.7-1
> of my package "lynis".

IANADD but as part of my NM process I'm going to review some packages
which will hopefully and likeley lead to an upload done by my AM.
So I'm intending to review this package. I will get back to you in a
while.

Best Regards,
Patrick

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

Re: RFS: lynis (updated package)

2008-07-03 Thread Patrick Schoenfeld

Hi again,

On Wed, Jul 02, 2008 at 10:59:02AM +, Francisco M. García Claramonte wrote:
> I am looking for a sponsor for the new version 1.1.7-1
> of my package "lynis".

a general comment: As our freeze is coming up soon I just want to ask
you if you are sure that introducing a new upstream version is good.
Please check carefully if something could break with this new upstream
version as there will not be much time to fix things.

Now to the review itself:
Mostly good, some not-to-bad issues and some nitpicks.

- debian/README.Debian: Thats really a nitpick, but you updated it, so its a
  good thing to update the timestamp at the end of the file, too, IMHO

- debian/changelog:
- "Changed menu title. Now is more descriptive" seems to me as it is
  no good changelog entry. What is this menu title you are referring
  to? And there is an 'it' missing to make the last sentence
  actually make sense :-)
- Just personal preference, but I would have written "Added a
  reference to lynis documentation website in README.Debian",
  because I think your changelog entry is not so good to understand
  for a not so technical experienced person and additional the word
  'link' is a bit awkward, because you can't link urls in textfiles.

- debian/copyright:
- Important: (C) has no legal meaning, therefore it has to be
  replaced with ©.
- The "License" part of the copyright file misses a license excerpt,
  which should usually be added.
- The "License" part of the copyright misses a reference to
  the license in /u/s/common-licenses. It should have an own
  reference to this file, just like your packaging has.

- README: Contains installation information. Not really bad, but some
  people prefer to remove them from the files they install (e.g. by
  patching the README file or using some magic). You can decide if you
  want to do so. I don't think it is a blocker.

As reviewing is an iterative process it might be that I might write you
additional points once you come back to, but for now this is all.

Best Regards,
Patrick


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

Re: Re: RFS: bluemindo

Hi,

On Thu, Jul 03, 2008 at 11:25:18AM +0200, Thibaut GIRKA wrote:
> > Due to the fact that its a GPL license you have the possibility to
> > create a symlink to the file in /u/s/common-licenes.
> > Or patch bluemindo. First choice probably preferrable.
> 
> Done, but not sure this is the cleanest way.

well, you've done it in an overcomplicated way. You call dh_link
manually, but thats not neccessary as CDBS already calls it. You just
have to add a file debian/links containing all the links that you need
to create. This also saves some build-time (not that many, but consider
1000 packages calling a perl script like dh_link twice for no reason),
what I consider quiet important, as some architectures are already overloaded.

BTW. this is one of the biggest disadvantages I see with CDBS. It seems
to call almost every dh_* script for no good reason, without having a
clue if it needs to call it or not. This way a CDBS run takes almost
always a bit longer, as if you had done it yourself.

> Bluemindo does not provide a setup.py file, so I've done what the New
> Policy says [2].

Okay. Good.

> > So to make your copyright perfect:
> > - Remove license excerpts for well known licenses
> > - Include complete license information for the PSF, because it is not in
> >   /u/s/common-licenses
> > - Make the human readable part complete (e.g. re-add a Copyright part).
> 
> Hm... The resulting file will be pretty large if I do so.

Only because of the PSF, but that is obligatory, because copyright is
the single-place to find copyright and licensing information. You have
no chance to link somewhere (like /u/s/common-licenses) so you need to
include the license. Its as simple as that.

> The human readable part... Hm... I switched to the machine-parseable one
> because there weren't any 'official' way to do when there are multiple
> copyrights/licenses...

Well, its okay if you want to keep the machine-parseable part only. I
just recommend you to keep a human-readable variant as well, because I
think that people who are not technical experienced will have trouble to
understand the format and a human-readable version would therefore be an
advantage. But obvious you can decide that you don't want that. You can
decide to only keep a machine-parseable version. But
then do it consistent. Don't include human readable information (like
the License block) if you don't intend to keep a human readable version
of the copyright file.

> I however made some modifications to debian/copyright.

Hm. IMHO It looks a bit weird, now, but except the not needed empty lines
between the machine parseable part and the human readable part it seems
okay. However I have a suggestion for you how the human-readable part
could look like. See [1] for it.

> > Well, the most window managers probably don't understand the PNG format,
> > so yes this is required. However you can do this automatically by
> > converting the file with convert and build-depending on imagemagick.
> 
> Done, but like the COPYING symlink, I don't know if I have done it in a
> clean way.

Given that it isn't a 'install' step you should move it to another
target. The CDBS documentation has 'build/foo' for it.

> Should be enough, now, provided that cdbs-edit-patch is available.

Nearly. I still don't know how I could disable certain patches from
beeing applied on build. For example: quilt has a file series which
stores the list of patches that will be applied. Its possible to remove
entries from there and the patches won't be applied. CDBS does not seem
to have such a file, so I wonder how to do it there. You need to
document that. Otherwise the fine is simple, but okay.

> > Yeah right, but you missed the depend in debian/control.
> 
> It should be ok now.

Yeah, alright.

> The first patch is now splitted into two patches: one for $DESTDIR and
> one for permissions.

Great.

> However, I'm working with the upstream developer, and we'll apply the
> patches as soon we are sure all is fine with the package.

Perfect.

> I've moved one of them to Suggests.

Okay, good.

> > - The enumeration in the description is confusing.

I still think that this is true and I would also prefer a more
terse description.

 Bluemindo is a really simple but powerful audio player in Python/PyGTK,
 using GStreamer.
 .
 Features include:
   * Download pictures for artists and album or lyrics of the current
 playing song
   * Different view modes (lightweight, basic, normal or full)
   * Plugin support
   * Desktop notifications
   * Change the status message of the Gajim Instant Messenger
   * Send music to your last.fm profile or your Jabber account

I think its not adequate to over-detailled describe the feature (like
the details of the view modes). Thats what documentation is for. The
user just needs a chance to decide weither this player is worth beeing
tried out. I'm open for discussion if the 3 items that are featured via
plugins should be handled seperately, but I'm arguing that they are part

Re: RFS: genwebgallery

Hi,

On Wed, Jun 18, 2008 at 07:29:49PM +0200, markus schnalke wrote:
> But back to `genwebgallery':
> 
> I think packages should be like programs according to the Unix
> philosophy:
> - small and simple
> - do one thing well

I would usually agree with you, but only to some extent.
After all each package has a given overhead, needs mirror space and
bandwith. If you package is only a 200 lines shell script its just
questionable if the ratio program ./ additional needed space for the
packaging is okay. Also consider that my argumentation is not that your
utility isn't worth to be included into Debian. My argumentation is,
that it would be good to add it to another package, which includes
similar tools. This way the general overhead is reduced, mirror space
isn't excessive used and the user who would otherwise install both tools
(which is very likeley if tools are similar) would save some wasted
space, too.

Just my 2 cents.

Best Regards,
Patrick

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

Re: Advice on project name change request

Hi Matteo,

On Fri, Jul 04, 2008 at 09:52:16AM +, Matteo Vescovi wrote:
> - how different should the new name be? I considered using names such as 
> "predict" or "guess", but they are already taken, so I thought about using 
> "soothie" (short for soothsayer, sort of :-) ), but would this name be 
> different enough? I'm currently leaning towards using "presage" as the new 
> name.

that is probably a question that a lawyer can answer only. Otherwise ask
the company who asked for the rename if they are okay with your
favorite.

> - what is the best way to ensure that users looking for soothsayer project 
> will easily find the new project name and that the publicity (such as the 
> review on Linux.com [4]) that soothsayer received will not be wasted?

Probably keep the soothsayer.sf.net site for a while, make a hint on the
page that this is not related to the product of the company you've
stated, that the project has been renamed to avoid confusions and then
redirect after some seconds. Talk to the company that this is the way
you want to go, because you also have an interest in protect. Consider
some grace period after which this project will be deleted. Probably you
also need to let the sf team acknowledge this, but I don't know.

> - how should this name change be handled in the BTS? Should I retitle the 
> ITP? Or close it and open a new one?

No need to open a new one. Just retitle it.

> Finally, how strong a case do Applied Human Factors have here?

What does that mean?

Best Regards,
Patrick

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

Re: RFS: genwebgallery